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.