From: Jim Brain (brain_at_jbrain.com)
Date: 2004-05-26 22:32:09
Marko Mäkelä wrote: >True. I confused your LISTEN directive with the LISTEN command of the >serial bus. But I still think that it's cleaner to list all device numbers >in a single atomic command. > > shorter, yes, cleaner is, I suppose, in the eye of the reader. Actually, I'm considering it, but with your escape command, it's get a bit icky: 00 LISTEN 0000 0000 0000 0010 (assuming 31-0 placement). I know from your earlier email you don't escape the 0's, but I feel that is much less elegant. The stream protocol then becomes "escape all 0 bytes, EXCEPT in the following circumstances" As a protocol designer, I dislike seeing that in protocols I have to support or implement. 00 is problematic as an escape char, as it has a high distribution in data streams, (ff is not a best choice either, I was carrying over my telnet protocol work I had been working on. It probably should be an unused or JAM opcode that is not in the normal PETSCII or ASCII matrix (something above 127), and is not a common screen code. In other words, a byte with a low incidence of occurence in a normal stream. >In my protocol, $00 is the escape command. A $00 data byte is escaped >as $00 $00. If an ATN interrupt arrives, it'll send some $00 xx escape >(see the comments). There are also $00 xx responses for indicating EOI, >end of ATN transmission, or talk-attention turn around. > > I like your idea of sending ATN as a command, as that allows the PC to react quickly to it getting fired (Does anyone what happens on the bus when you are loading a program and RUN-STOP RESTORE is hit? DOes the CBM unit send an ATN low? Or, does the 15XX byte send just timeout?) >I didn't want to do that, because I thought you would need a custom >application on the other end of the serial line anyway. Besides, the >Flash ROM of the 2313 was getting a little tight (especially if support >for burst mode transfers or JiffyDOS is going to be added later). It >would be a different matter if all protocols for the cassette port were >removed. Of course, as you have a bigger controller, the design constraints >are different. > > As I do. Although, even for your project, an ATMEGA8, which has 4 times the memory, shows as the same price as a 90s2313, and is a comparable pinout (it is a big bigger, at 28 pins, but still skinny DIP or PLCC formats). My project hopes to include Ethernet on board, so having a complete app running onboard would be a big plus. >Could you represent the diagram in an easily editable format? I'd start >with the input language of GraphViz, but maybe someone knows a better >approach that has been implemented in an open source or free software tool. > > I could try. I was waiting a bit until I put the JDos routines in before I laid out the diagram in a package, to make sure I actually capture all of the relevant states. I am still unsure what happens when you try to load a file that does not exist. I assume the listen and talk happens, but when the line turns, what does the 1541 send? Does it just do nothing? That is what I am doing now, and the 64 seems to respond with "File not found" like it should, but I happened upon this by sheer accident (because I simply go back to IDLE state when done sending data), so I have my doubts. Another is on a printer channel open. I know it is physically possible to do open 4,4,7,"data", but if you do not do that, does the 64 just send LISTEN SECOND(open) data UNLISTEN? As well, Is there ever a case where a command would be longer than 1 byte and would have an EOI sent? Questions, questions... Jim -- Jim Brain, Brain Innovations firstname.lastname@example.org 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.