[Coco] 16550 wasRe: RS232 paks

[richec]

On Wednesday 04 March 2009 20:31:15 Tom Seagrove wrote:
Aw just "Hang-en High" 8-)


> Fist Full of Dollars?

>

> -----Original Message-----

> From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] On

> Behalf Of Mark Marlette

> Sent: Wednesday, March 04, 2009 8:29 PM

> To: CoCoList for Color Computer Enthusiasts

> Subject: Re: [Coco] 16550 wasRe: RS232 paks

>

> George,

>

> Do not forget that the chip does work. It just doesn't work in all

> conditions.

>

> If it didn't work they wouldn't sell it.

>

> In your application is obviously is working for you. I have stated the

> conditions, SockMaster did as well. It will fall flat on it's face.

>

> 'For a Few Dollars More', you can have the real deal. Problem is that the

> 16550 will not support the legacy term programs for the CoCo, there are all

> kinds of issues that we deal with when adding technology to an old

> computer. It is way more work to implement but that is why it is on the SB.

> Can't have lost data, ever.

>

> Clint Eastwood fans will get my movie title above.... :)

>

> Regards,

>

> Mark

>

>

> ----- Original Message -----

> From: "George Ramsower" <georgeramsower at gmail.com>

> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>

> Sent: Wednesday, March 4, 2009 7:19:25 PM GMT -06:00 US/Canada Central

> Subject: Re: [Coco] 16550 wasRe:  RS232 paks

>

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

>

> --

> Coco mailing list

> Coco at maltedmedia.com

> http://five.pairlist.net/mailman/listinfo/coco

>

> --

> Coco mailing list

> Coco at maltedmedia.com

> http://five.pairlist.net/mailman/listinfo/coco

> No virus found in this incoming message.

> Checked by AVG - www.avg.com

> Version: 8.0.237 / Virus Database: 270.11.6/1981 - Release Date: 03/04/09

> 07:41:00

>

>

> --

> Coco mailing list

> Coco at maltedmedia.com

> http://five.pairlist.net/mailman/listinfo/coco