[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