[Coco] Becker port

[Gene Heskett]

On Saturday 20 April 2019 22:32:49 Jeff Teunissen wrote:

> On the IRC channel, some of us were discussing the DriveWire "Becker
> port" implemented in emulators and the CoCo FPGA. Specifically,
> someone thought it was something that you would build a cable for with
> a regular CoCo, perhaps thinking it was related to the bit-banger. We
> got the confused person straightened out without too much trouble, and
> explained what the Becker port really was, a dedicated serial
> DriveWire link.
>
> We started wondering how useful it might be to have a real-life
> version of the Becker port -- a serial port connection that presents
> as a read status port at $ff41 and a read/write port at $ff42, with
> enough buffer space to fully contain a 'sector read' response, and
> possibly be able to run at very high bit rates without requiring all
> the CPU a CoCo can apply to it.
>
> Might such a thing (a high-speed DriveWire accelerator program pak) be
> useful/desirable?

Might be usefull, but the "drivewire" cable, in byte wide mode would need 
a hardware adapter built at the coco end, something along the lines of 
the J&M-CP floppy controller with it 26 pin side port that some of us 
tried to drive printers from, and probably would be subject to cable 
length limitations that do not now exist when you put a usb adapter into 
the mix. My present connection is 10 meters long using a buffered usb 
extension cable. The bit banger cable itself is only about 3 feet long.

Any such cable of a usable length MUST be treated as a transmission line, 
properly terminated on both ends.  With the not very tightly controlled 
but common ribbon cable, I find in my machine control work with 
linuxcnc, 6 or 7 feet is the practical limit for high speed parallel TTL 
signals if signal integrity w/o error checking is to be maintained.

One must also bear in mind that once the byte has been delivered to the 
coco end the coco's ability to move that byte from $ff42 still has an 11 
seconds a megabyte moved speed limit.  Our scsi controllers regularly do 
that already.  And I'd expect similar rates from the IDE controllers but 
with the 15" cable length limit the IDE's near total lack of 
terminations also imposes.

The J&M-CP controller could drive some very old parport printers from a 
coco or coco2, but when the fcc made the printers subject to emitted 
noise limits, it failed because it was not buffered, the data was only 
valid for E-clock duration, and that wasn't long enough for the printer 
to capture once the signals had to be noise filtered and the coco3 was 
twice as fast, so your printers printed about half of what you sent 
them. Garbage text on paper.  Readable only by cryptography experts.

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>