[Coco] 16550 wasRe: RS232 paks
georgeramsower at gmail.com
Wed Mar 4 20:19:25 EST 2009
I think I'll have to find some time and see how I built that 3 port com
board. It works goodly. I'm wondering if I made those changes to the
All I know now is that it works. I ran two modems on two different
telephone exchanges and it eliminated long distance charges from one to the
other. I was lucky enough to be in the middle and didn't have to pay between
This was the old way to do BBS systems to avoid long distance charges. I
didn't join a network and therefore, I was not a hub.
"Hub" was that what it was called? Dammit, I can't remember.
----- Original Message -----
From: "Mark Marlette"
> Google a bit and you will see, it is a wonderful tool.
> Maybe you will believe our own SockMaster on the subject.......
> This is an extraction from his article from :
> Now for what IS in the diagram: The other problem with putting a
> modem on my BBS is a little less important, but fixing it makes
> much easier. With this modification the CPU gets less bogged down, the
> driver becomes easier to write, and the BBS *never* misses any incoming
> Normally, the 6551 simply has no way of telling my modem when it's data
> is full. If someone called my BBS at a high baud rate and tried uploading
> 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
> 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
> and 74ls00) that generates a new RTS control signal. Since modern modems
> a data buffer, it would be really neat to unload a lot of work from the
> and leave it for the modem to do. This hardware circuit simply creates a
> RTS line for the 6551. Every time the 6551 receives data, the circuit
> the RTS line (which tells the modem to stop sending to the CoCo) until
> 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
> break, or the disk drive comes into use... whatever, the modem is told not
> 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
> 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
> from the 6551 when the BBS wants input from the user. If the user
> stuff while the BBS is calculating, loading, thinking, etc... the modem
> buffer it for me.
> ----- Original Message -----
> From: "George Ramsower"
> ----- Original Message -----
> From: "Roger Taylor"
>> At 09:40 AM 3/4/2009, you wrote:
>>>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
>>>IMHO. 16xxx series offers GREAT buffers, programmable interrupt
>>>etc..... I guess that is why they are so common, oh they work too! :)
>> 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
>> 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
> 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
> incident..... I think.
More information about the Coco