[Coco] 16550 wasRe: RS232 paks

[George Ramsower]

hmm.
 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 
intended design.
 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 
them.
 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.

George

----- Original Message ----- 
From: "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"
> ----- 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.