From: Marko Mäkelä (marko.makela_at_hut.fi)
Date: 2004-06-10 21:57:44
Jim, > 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. How does this differ from my implementation? In my implementation, the microcontroller will send a control code to the RS-232 line when it observes ATN=0 during a serial bus transfer. It'll also send the low-order bits of the byte counter, so that the computer connected to the RS-232 line knows how many bytes were successfully send. It then drops all received bytes until it sees a special command. That arrangement should avoid any race conditions. > 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.). Have you experimented with a smaller transmission buffer? C-Kermit on GNU/Linux write()s as little as 1 byte at a time, and it achieves 38,400 bps without problems, at least when using a 16550 with built-in 16-byte FIFO buffer. Marko Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.