[Coco] What do people want?

[Gene Heskett]

On Saturday 13 December 2014 14:27:52 David Ladd did opine
And Gene did reply:
> On Sat, Dec 13, 2014 at 1:03 PM, Allen Huffman <alsplace at pobox.com> 
wrote:
> ><cut>
> >
> > Someone will have to track this down, but I believe it was Roger
> > Taylor who discovered the RS232 pak was capable of much higher
> > speeds by giving it some undocumented setting. I do not know if I
> > read this on coco3.com <http://coco3.com/>’s message forum or in
> > this list, years ago. It was around the time of his bluetooth pak
> > and such.
> 
> Well I did a quick search on google and found a website at:
> http://www.cocopedia.com/wiki/index.php/Deluxe_RS232_Pak
> Now the thing is it looks like the 6551 only goes up to 19200 unless
> you hack the crap out of the RS232 pak.  At this point I personally
> think it might be better to just acquire a RS232 pak of some type that
> uses a 16550 type UART chip that can handle higher speeds by default,
> but that is my opinion anyway.  Not sure what your take on it is.
> 
> > Anyone recall?

I think the math and the i/o requirements of the 16550 preclude its us on 
the coco because one would, due to its number of registers, need $10 bytes 
of i/o space, which the coco-3 is extremely limited on. And since each of 
these registers needs some SW to at least init it for use, the driver, 
unless its a one time setup changeable only by re-assembling the driver, 
could easily expand to half the coco's available at any one instant, 64k 
of ram.

What we really need is a bug fixed 6551 with an internal caching buffer of 
at least 256 bytes going both ways.  But I have not personally done any 
searching for that. I say bug fixed because we have to play heavy duty 
tricks with the 6551 to even make the 7 wire flow control protocol work.  
Thats BS, from right behind the bovine, and I would not waste further time 
on trying to make the 6551 function at more than 4800/9600.  The coco-3's 
I have played with, even with flow control working well, top out at about 
470cps for a 6809 version, and about 640 cps for the 6309 version and that 
is with flow controls being liberally exercised so that no data is lost.

I am convinced there is a better ACIA chip out there, has to be, we just 
haven't managed to find it.  A huge plus if we could drop it into the 
RS-232 packs 6551 socket. perhaps with a cut & bridge hardware hack of 
some sort.  Or, if its a tsop package, a socket adapter to make it a drop 
in.

The major speed limit now is not the 6551, broken though it is, but to 
total lack on any on-chip cache.  The amount of processor it takes to 
handle incoming data one byte at a time is horrendous.  This is the same 
exact problem with rzsz in the version we are using as both its incoming 
data AND the crc calcs to check errors are one byte at a time.  With the 
modern table lookup crc methods I put in the last version, a 256 byte 
buffer would probably take rzsz from 400 cps to 4000 cps if the software 
had that resource to use.  First, collect the buffer full, rx the expected 
crc, pass the buffer to the table lookup and compare the crc's.  Done.
Hand that buffer to the os and use a second one for the next 256 bytes.

It would be a from scratch engineering project, but would give us an RS232 
pack lookalike that might be able to do 56kbd on any lazy day.

The top speed of the tfr can be obtained from the megaread command on your 
machine.  If its 12 seconds n your machine, then a 1 way transfer of data 
rate is 83,333.333333333333333 bytes per second, so it should be able to 
handle 56 kilobaud error free. 
 
The possibility is there, we just have to invent if from  whole cloth for 
our platform.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS