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.