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