[Coco] 16550 wasRe: RS232 paks

[Mark Marlette]

Roger,

As Mike and Darren have indicated, this is very much the case. No offense Mike as I don't recall, but for Darren his posts are so correct, enjoyable to read on my end. His CoCo testing on slew rate was enjoyable to read, true engineer or one that thinks as one.

Not matter what you do in your software you will not fix the internal flaws of the ACIA. Your application might be able to live with it but does not remove the fact. IE: retransmit a packet of lost data or corrupt data etc....

You probably are not invoking hardware handshaking in your design.

This is a requirement of my design(s). You can have any requirement you want. The fact is that when the OS tells the sending device to stop because it is full and processing the data, it better stop and without data loss. This again is not the case with the 6551.

You can try and powercode around it but once you move out of your app the under lying problem is still present.

Your test condition. Make one of your PCs so busy that they can't service the data stream from the CoCo. The PC, normally, if programmed to, would use RTS/CTS to stop the flow. I have done extensive testing using at Atmel AVR which at 230.4K baud can cause a Win XP box 3.2GHZ Dual Core, blahblah, machine to loose data. So if you aren't using hardware handshaking and you just assume that the PC is fast enough to keep up with the data stream, then you will have issues. Not all PC are created equal. Most CoCos are, on the RSDOS side. Move away from DECB which is NOT an OS but sorts of a loader, deal with REAL world interrupts, you will see. 

How is your device performing in NitrOS-9? Test case: Start a stream of data from the PC, then do a dir of a hard drive or floppy. You will see that the RTS/CTS lines will activate to slow the data transmission until full attention can be given back to the stream. No RTS/CTS, hardware shake, watch the data loss. Pretty simple.

I have done both designs, The ACIA does work, just not well in higher bandwidth situations due to the flow problems. Thus my requirement. I am curious how you device is performing in NitrOS-9. Do you have any test cases running there?

Hopefully that helps. ???

Regards,

Mark
Cloud-9 



----- Original Message -----
From: "Roger Taylor" <operator at coco3.com>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Wednesday, March 4, 2009 1:39:59 PM GMT -06:00 US/Canada Central
Subject: Re: [Coco] 16550 wasRe:  RS232 paks

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 ?






-- 
Roger Taylor

http://www.wordofthedayonline.com


--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco