Re: Got IEC code working

From: Jim Brain (
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 
>>(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:


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
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)

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 Brain, Brain Innovations                      
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.