From: Greg King (gngking_at_erols.com)
Date: 2004-06-15 16:57:44
From: Spiro Trikaliotis; on Date: Saturday, June 12, 2004, at 06:24 AM
>
> On Thu, Jun 10, 2004 at 01:22:00AM -0500 Jim Brain wrote:
>
>> Does a DOS command get executed upon receipt of EOI char., or when
>> UNLISTEN is sent?
>
> I have not checked too deeply (in fact, the 1541 side really is a mess,
> compared with the C64 part), but it seems to me that it is executed
> immediately after the EOI is recognized.
>
> I do not see the necessity for an UNLISTEN before,
> but I'm willing to be corrected.
>
> I tried with VICE and true drive emulation: I set breakpoints to
> UNLISTEN ($E88B), the command-execution call at $EBF5, and the store to
> $0255 at $CFED. My idea seems to be supported, although I always
> received the UNLISTEN before the command was executed. That is because
> $EA2E-$EA56 calls $E9C9 to get a data-byte from the bus, which itself
> tests for ATN. Thus, the UNLISTEN is processed before the main loop is
> called again.
>
> I disabled the sending of UNLISTEN on the C64 side by putting RTS at
> $EDFE. $CFED was not called after this, unless a CLOSE 1 was executed.
> (I executed open 1,8,15,"v0" for these tests, as well as CLOSE1.)
> Thus, something in my logic is wrong: Without the UNLISTEN, the 1541
> does not recognize the command.
>
> I checked again: OPEN1,8,15,"V0": $CFED was not called. OPEN
> 2,8,15,"I0": Now, $CFED was called. It seems that the processing of the
> commands need a subsequent ATN, whatever it is (LISTEN, UNLISTEN, TALK,
> UNTALK). Good, point taken.
The LISTEN, UNLISTEN, TALK, and UNTALK functions send EOI and flush the
buffer, if there is a byte waiting in it. You stopped that act when you
disabled UNTALK/UNLISTEN. CLOSE and the second OPEN worked because you
didn't disable TALK/LISTEN. So, your idea that EOI is the trigger probably
is correct.
From: Jim Brain; on Date: Saturday, June 12, 2004, at 02:12 PM
>
> Spiro Trikaliotis wrote:
>
> > On Thu, Jun 10, 2004 at 01:22:00AM -0500 Jim Brain wrote:
> >
> >> It looks like you can use channel 0 and 1 in regular open commands,
> >> but 0 must be used for reading, and 1 must be used for writing.
> >> Can someone confirm?
> >>
> > Yes, channel 0 assumes ",P,R" at the end, while channel 1 assumes
> > ",P,W".
>
> Wonder why they did that, as opposed to simply adding the ,p,w to the
> save-logic in the CPU units?
The channels allow us to override their assumptions -- if the SAVE function
added ",p,w", then we couldn't change it.
Channel Assumption
------- ----------
0 ",p,r"
1 ",p,w"
2-14 ",r" (any file-type)
Example:
We can give the BASIC command:
save "0:program,u",8
The program on the disk will be marked as USR. A standard LOAD of that
file will be rejected. But,
load "0:program,u",8
will be accepted!
Yes, yes ... I can hear all of you thinking, "Why the <beep> would we want
to do a crazy thing like that?!" [Hey, if something can be done, then
somebody will want to do it! ;-) But, seriously, folks ...] The answer is,
security and error-prevention. Suppose a program is so big that it must be
stored in 3 files. Program 1 runs the other two when it needs their
functions. Those two must not be run by themselves. If they are marked as
USR, then you won't load them by mistake!
[ Of course, most fast-loaders don't allow that trick
-- they're broken! ;-P ]
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.