Re: Interface progress and issues

From: Greg King (
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)

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.