[Coco] Preserving old CoCo diskettes...

[Roger Taylor]

At 04:30 AM 5/18/2010, you wrote:
>On Tuesday 18 May 2010, Roger Taylor wrote:
> >At 11:04 PM 5/17/2010, you wrote:
> >>I, and Robert Gould, have spent quite a bit of time with this over the
> >> last year or so, and I have come to the conclusion that the SC6551 is a
> >> drain bamaged chip and that the only real cure is a different uart.
> >> However, at 4800 baud, where no flow controls are needed, its as bullet
> >> proof as any.
> >
> >The UM6551 can handle 230400 bps with a 3.6864 mhz crystal as long as
> >the CoCo uses tight code and can keep up.
> >
>Does it handle DTR/RTS/CTS etc differently from the SC6551?  Or am I wiring
>my null modem cables incorrectly?  The problem is that sc5551.dr has no tx
>buffer, only rx.  The only way to stop incoming data from this machine is to
>stop the transmitter which drops the CTS line, stopping this machine.
>
>Unforch, if an rz originated ack byte arrives to be sent during this time,
>since there is no tx ring buffer, the tx chain is frozen and rz is put to
>sleep by the sc6551.dr.   Boom, full rx buffer and rz is sleeping and cannot
>empty the buffer which would re-enable the 7 wire protocol.
>
>The older aciapak.dr had buffers going both ways and did NOT have this
>problem.



If somebody hasn't figured out a way around those quirks after 20 
years by writing new software that bypasses these so-called glitches, 
then I don't know what to say.  I write the software for both 
computers and do the protocol totally from software.  Cured, with a 
major speed increase.




-- 
~ Roger Taylor