[Coco] Preserving old CoCo diskettes...

[Gene Heskett]

On Tuesday 18 May 2010, Roger Taylor wrote:
>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.

The architecture of that driver as it sits today would need enough changes to 
constitute a total re-write.  Which, FWIW, is exactly what I did with the 
serial mouse driver 2 years ago, what survived the re-organization of nitros9 
between version 1.15 and the current 3.0, bears little or no resemblance to 
the original, didn't work at all, so I simply re-wrote it.  And while the 8 
byte packet I am generating now seems to be properly organized, there now 
appears to be button translation issues in the Clib call that translates that 
to the 32 byte packet multivue uses. 15 years ago, running pieces of nitros9 
combined from the 1.15 through 1.22 releases, all 3 buttons on this mouse 
were alive and usable in all the gfx editors, now only one, the left one, 
actually works.  And I could format a floppy without running out of system 
ram at any time.

Roger, why not contribute that code to the nitros9 project?

I might be able to do a new driver based on what I have learned thrashing 
about in the mud pit of this one, and come up with a totally different design 
that works only against this linux box.  That wouldn't be very good.  If you 
have a wheel that works, lets beat on it and maybe make it the std version.  
Everyone would benefit, including you because the driver would already be in 
the OS distribution.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Elegance and truth are inversely related.
		-- Becker's Razor