From: Jim Brain (brain_at_jbrain.com)
Date: 2004-05-26 16:14:00
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. 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 email@example.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.