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.