Re: Got IEC code working

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