[Coco] 16550 wasRe: RS232 paks

[Mark Marlette]

George,

Google a bit and you will see, it is a wonderful tool.

Maybe you will believe our own SockMaster on the subject.......

http://www.axess.com/twilight/sock/cocofile/rs232mod.txt

This is an extraction from his article from :

   Now for what IS in the diagram:  The other problem with putting a high-speed
modem on my BBS is a little less important,  but fixing it makes everything
much easier.  With this modification the CPU gets less bogged down, the RS-232
driver becomes easier to write, and the BBS *never* misses any incoming data.
Normally, the 6551 simply has no way of telling my modem when it's data buffer
is full.  If someone called my BBS at a high baud rate and tried uploading a
text file, my driver simply didn't read the data fast enough to get it all
without missing bytes. Every time the disk drive went on, the CPU halts and the
6551 misses more data.  In order not to miss data, the RS-232 driver would have
to immediately read data from the 6551 every time a byte came in.  The
solution?  I made a little circuit that sits on top of the 6551 chip (a 74ls32
and 74ls00) that generates a new RTS control signal.  Since modern modems have
a data buffer, it would be really neat to unload a lot of work from the CoCo
and leave it for the modem to do.  This hardware circuit simply creates a new
RTS line for the 6551.  Every time the 6551 receives data, the circuit raises
the RTS line (which tells the modem to stop sending to the CoCo) until that
data is read by the software.  If the driver reads the data at the full
incoming speed, there is no slowdown in throughput.  If the driver goes on a
break, or the disk drive comes into use... whatever, the modem is told not to
send any more data to the 6551 until the 6551 is ready to recieve it!
Effectively, the circuit disallows the 6551 from missing any data.  It also
places the job of buffering incoming data on the modem, and not the CoCo.
The CoCo doesn't have to keep reading the 6551 every time a byte comes in,
since it won't lose the data if it lets it wait.  Now it can read the data
when it actually wants it.  This speeds up my BBS quite a bit,  I only read
from  the 6551 when the BBS wants input from the user.  If the user transmits
stuff while the BBS is calculating, loading, thinking, etc... the modem will
buffer it for me.


Regards,

Mark
Cloud-9
----- Original Message -----
From: "George Ramsower" <georgeramsower at gmail.com>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Wednesday, March 4, 2009 5:51:29 PM GMT -06:00 US/Canada Central
Subject: Re: [Coco] 16550 wasRe:  RS232 paks

----- Original Message ----- 
From: "Roger Taylor"
> At 09:40 AM 3/4/2009, you wrote:
>>Willard,
>>
>>The NitrOS-9/Driver is already written for a 16550 device. I have had a 
>>homebrew card running for almost 10yrs based upon that chipset.
>>
>>Yes, it would break all the old term programs. A caveat of adding new 
>>technology to an old machine. Not a problem in NitrOS-9 as the driver/dd 
>>is not part of the actual program, when properly written.
>>
>>The SuperBoard has a multi-function chip on it that has the 16550 in it. 
>>Anyone that has done high speed serial testing in a system will design it 
>>with hardware handshaking. It is no secret that the ACIA(6551) has issues 
>>with this, plus almost no buffer space. Not a good choice for new designs, 
>>IMHO. 16xxx series offers GREAT buffers, programmable interrupt thresholds 
>>etc..... I guess that is why they are so common, oh they work too! :)
>>
>>Regards,
>>
>>Mark
>>Cloud-9
>
>
> Mark,
>
> Exactly what problems have you yourself had with the 6551 so that I may 
> try to offer a software solution?  I'm not claiming to have all the 
> answers, but I've done a serious amount of 6551 coding in the past, and I 
> can assure you that the chip itself is not always the problem.  The 
> programmer is 90% of the problem.  The OS is 90% of the problem.  If 
> there's some little bug or dislike about a certain chip, I guarantee that 
> there's the same number or more in the 16550.  I've read about that chip 
> and based on how many variants are floating around, how can anyone ever 
> agree on a right way to code the routines?  It appears to be a mess, no 
> less than what you claim about the 6551.  I'm not saying any certain chip 
> is BETTER than the other.. I'm saying that TOO many programmers and 
> nonprogrammers have clashed about these chips and in the end, they're all 
> still being used today.  You can always tell when the programmer took 
> shortcuts or just didn't know what he was doing.
>
> When you say the 6551 is not a wise choice for any new designs, your 
> intent is clear but the statement is not true.  Someone who's put out a 
> new wireless RS-232 pak didn't just wake up yesterday and discover the 
> 6551.  People who know how to write good software aren't afraid of the 
> 6551.
>
> My wireless RS-232 pak has been connected to 7 CoCo units (2 CoCo 1's, 1 
> CoCo 3, 4 CoCo 2's) and to 2 PCs @ 115200 bps running lengthy looping 
> tests (1-2 days sometimes), and I haven't seen it bomb out yet.  Can you 
> please tell me what circumstances I need in order to break my protocol ?

 I'm not a guru on all this but, it seems to me that if there was a bug in 
the original 6551, over the years it's been produced and cloned that 
somewhere, someone would have fixed it.
 I think Roger may be correct inasmuch that programming may have been the 
problem... although I don't know. It just seems that way because the darned 
chip would have been fixed by now.
 I'm happy with my 6551 chips in my (OS9) coco. I'm not using Nitros9 so it 
would naturally be a little slower but, I've done megs of transfers without 
incident..... I think.


--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco