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