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.