From: Jim Brain (brain_at_jbrain.com)
Date: 2004-05-26 16:18:03
Marko Mäkelä wrote:
>On Tue, May 25, 2004 at 04:50:08PM -0500, Jim Brain wrote:
>
>
>>I came up with this, but it's just a stab at something, comments are
>>appreciated:
>>
>>(all data in hex)
>>FF is "command" char. If it appears in data stream, replace with FF FE
>>
>>FF 00 reset interface
>>FF 01 X listen as device X
>>FF 02 X unlisten as device X
>>
>>
>
>I don't think that it is good idea to allow listening for only one device
>number at time. A file and print server application running behind the
>serial line may need to emulate several devices at the same time. There's
>not enough time to notify the application over serial bus requests and wait
>for the decision whether the request should be replied. That's why I
>went for a command "listen to these device numbers" that takes 31 bits as
>a parameter (actually 32, but device number 31 is ignored).
>
>
True, my command can be repeated:
LISTEN 4
LISTEN 5
LISTEN 8
etc.
I noticed the bit fields, but all my other commands (CONFIG 8 for
JiffyDOS, etc.) didn;t work well as a bit field, so I thought a command
sequence like the above would be better. Your option is good for
quickly setting up devices, though.
And, yes, I struggled with the idea of having the controller just
forward the requests onto the PC for all processing, because I thought
it was more elegant (the PC just "knows" what devices to deal with, the
AVR just blindly sends IEC data). BUt, it required more states (have to
timeout on the waiting for the response from PC, so as to not tie up the
IEC bus forever waiting in case the PC is disconnected or not
responsive. Have to hook into the UART receive IRQ to make sure code
gets triggered when the response comes, and there's a possibility the
response is not for that IEC bus device). In the end, I think it best
to tell the AVR what devices to act like, as you did.
>My format should be adequate for all uses, expect defining custom fastloader
>protocols.
>
I'm still trying to decipher your protocol. How does it deal with a
resynchronization of the serial line (to prevent interpreting commands
as data or vice versa? I also want to support higher level commands
(get file, let the AVR deal with the IEC commands), and status (LED,
potential LCD screen, etc.), so I'd like the protocol to offer options
for more than just raw IEC commands. I am not sure custom speeders will
work with mine either (I had that as a design goal, but sending the raw
line state transitions over the rs232 link is just not possible).
>Maybe it would help if you constructed the transition diagram for
>the serial bus and had a look at the serial bus routines in the Vic-20
>and 1541. I can't find the PNG file I made from my diagram, but I have the
>piece of paper somewhere. Anyway, it would be a good idea to produce it
>independently. I used three kinds of transitions: timeouts, inputs (waiting
>for state transition) and outputs (changing the state of a line).
>
>
I've got routines working, and I have a state diagram (had to generate
one for my state machine in the AVR.
My diagram includes the following as transition triggers (read, these
are what I IRQ off of)
timeouts
line changes
And, the following as input to next state: (these are what I use to
decide next state)
timeouts (as above)
line changes (as above)
CMD_MODE (TALK, LISTEN, IDLE) (to know when to turn the line, read
data, ignore data)
EOI (to know when to do the EOI handshake or wait for it)
I have looked at the VIC (well, 64) and 1541 routines. I am a bit
sloppy on timings right now, as I didn;t want to get near the limits
during initial work, but I can save and load on my 64 at present.
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.