From: Jim Brain (brain_at_jbrain.com)
Date: 2004-06-12 20:04:47
Spiro Trikaliotis wrote:
>Hello Jim,
>
>* On Thu, Jun 10, 2004 at 01:22:00AM -0500 Jim Brain wrote:
>
>
>
>>For reading of files using GET# and such, I found the CBM would simply
>>drop ATN when it had enough data to fulfill the request.
>>
>>
>
>Hu? The ATN is dropped immediately after an OPEN, CLOSE, LISTEN/TALK or
>UNLISTEN/UNTALK (with perhaps the secondary address) is sent. If you
>
>
Actually, ATN is dropped BEFORE they are sent. ATN signals that the
bytes to follow are commands.
>want to send something, you have to wait for the listener to signal
>"ready" (see, for example, wait_for_listener() in CBM4LINUX, or
>$ED5A-$ED5E in the C64 ROM disassembly, or $E94B-$E957 in the Floppy
>1541, ROM -03 and -05). The TALKer sets CLOCK to LOW to signal it
>wants to send, and the LISTENer can hold this until it sets DATA to
>HIGH. The programmer's reference guide has a good diagram of this in
>chapter 6, "the serial bus". Look for T_H ("Listener hold off"). So,
>there is no need to send bytes more than once.
>
>
There is in my case. TO cut down on the chat between the PC and the
intermediate interface, I send bytes from the PC to the interface,
typically more than 1 at a time. It is possible for the 64 to read in 1
byte, then decide it has had enough, so it drops ATN and issues
UNLISTEN. When that happens, I've already sent more than 1 byte to the
interface from the PC, so I need a way to signal that the 64 only
accepted 1 byte that I sent to the interface. My trigger for doing that
is ATN LO. Since it is possible for a program to issue:
TALK,TKSA,turn,<byte>,TALK,TKSA... I found I could not rely on getting
an UNLISTEN/UNTALK as an indicator as to the end of the communication
(the 1541 seems to handle the above construction fine.) Therefore, I
use ATN lo as a signal that no more bytes can be sent and relay how many
bytes were successfully sent back to the PC from the interface. The PC
then manages the buffer to account for that.
>As the EOI is sent *before* the last byte (the TALKer does not set the
>clock after at most 200 us after the LISTENer signalled "I'm ready" by
>setting DATA to HIGH, as above, with CLOCK going low (T_NE, "Non-EOI
>
>
>
My EOI code is as you described. What I am saying is that the somehow,
I need to send 2 chars in my stream of data to the interface. The
interface send EOI, sends the last char, eats the extra char (does not
send it), and life is good. Still, it is a bug I need to fix...
>>Does a DOS command get executed upon receipt of EOI char, or when
>>UNLISTEN is sent?
>>
>>
>
>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.
>
>
OK, I'll take that into account. When ATN LO occurs, the PC side gets
an event, so I'll wait for that event before handling command.
>>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?
Jim
--
Jim Brain, Brain Innovations
brain@jbrain.com http://www.jbrain.com
Dabbling in WWW, Embedded Systems, Old CBM computers, and Good Times!
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.