Re: Interface progress and issues

From: Marko Mäkelä (
Date: 2004-06-10 21:57:44


> 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

> 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.


       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.