Interface progress and issues

From: Jim Brain (brain_at_jbrain.com)
Date: 2004-06-10 08:22:00

The good news:

I now have an interface that will listen on the IEC bus and respond as a 
drive or printer would.  I also have implemented a server daemon that 
works in conjunction with the interface.

I have saved files, loaded files, written out data, and read it back 
in.  As well, the command channel is working*.

For reading of files using GET# and such, I found the CBM would simply 
drop ATN when it had enough data to fulfill the request.  TO handle that 
without having a buffer on board the interface, I implemented a byte 
counter and a message that communicates the number of bytes sent back to 
the server.  So, if a user does:

open1,8,15,"jim,s,r":get#1,a$

the PC will send a buffer of data, but the 64 will bring ATN low after 1 
byte.  So, the interface will tell the PC that it transmitted 1 byte.  
The next time the 64 asks for data, the PC resends the buffer, minus the 
1 character already transmitted. (As an optimization, it fills the 
buffer back up to 256 characters, but that's not absolutely needed).  
This seemed a bit non-optimal (in tests using BASIC, a loop that does 
GET#1,A$ will cause lots of data to be sent over the RS232 link (you 
send 256 bytes, 1 gets transmitted, you send 255 bytes, 1 gets 
transmitted, etc.).  The way to fix, I guess, is to provide a small 
buffer in the interface and only transmit when the buffer is empty, or 
the device/channel combo changes (which would invalidate the cache).  
However, I am interested in other ideas, as the buffer idea starts 
getting into creating a packet based approach to the interface protocol.

As of right now, I seem to be having one issue that shows up when 
sending the command channel results back to the interface.  FOr some 
reason, my code wants an extra byte to be sent after the EOI character 
(the last char to be sent).  Due to the way I wrote the interface code, 
sending an extra 0 doesn;t hurt, but I need to figure out what the issue 
is at some point.

It looks like the code is currently JDos tolerant (to steal a Nick C. 
term), but does not have JDos support as yet.  It looks pretty easy, now 
that I think I have all of the states defined, but I hesitate to start 
on it, as I am having so much success in the other areas.

A couple questions have popped up on the server code end:

Does a DOS command get executed upon receipt of EOI char, or when 
UNLISTEN is sent?
It looks like you can use channel 0 and 1 in regular open commands, but 
0 must be used for reading, and 1 must be used for writing.  Can someone 
confirm?
If you get a LISTEN, then a TKSA, what should you do?
If you get a LISTEN, then a SECOND, then a TALK/TKSA, what do you do?
And, to save space, there's a theme going here.  Do you use the last 
commands received, or do you error out?

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.