[Coco] Socat drivewire relay to CoCo1
Gene Heskett
gheskett at wdtv.com
Sat Feb 28 07:11:56 EST 2015
On Saturday 28 February 2015 06:21:02 jon bird wrote:
> Hi,
>
> Now I've got my CoCo 1 up and running again I thought I'd give
> Drivewire a go. A couple of initial queries then - I made the cable up
> iaw with the diagram here:
>
> http://www.cocopedia.com/wiki/index.php/Getting_Started_with_DriveWire
>
> I'm not entirely sure of the significance of the CD/"turbo mode"
> option and there seems to be some differences in the baud rate you
> need to set the server end to - either 38400 or 57600. Currently the
> only configuration I get anything sensible with is 38400 with or
> without CD connected.
>
> That aside, I can get something basic up and running.
>
> For logistical reasons though, I can't really run it near the same
> machine that is hosting the Drivewire server. So my plan was to hook
> the CoCo up to a Raspberry Pi, then have the protocol relayed over TCP
> using something like 'socat'.
>
> I've configured Drivewire to use TCP client mode & run on the Pi the
> following:
>
> socat -v tcp-l:65505,reuseaddr,nodelay,fork file:/dev/ttyUSB0
>
> The server connects up to it ok however all I get on the CoCo end is
> an I/O Error.
>
> Running up a Wireshark trace does show semi-sensible things happening
> - I see what looks like a read sector request go in, the response back
> but
>
> the checksum computed by the CoCo is bounced by the server:
> >>>>>>>>>> ---------START--------------------- <<<<<
> >>>>>>>>>> ----------------------------------- <<<<<
> >>>>>>>>>> ----------------------------------- <<<<<
> >>>>>>>>>> ----------------------------------- <<<<<
> >>>>>>>>>> ----------------------------------- <<<<<
>
> No. Time Source Destination
> Protocol Length Info
> 628 2.426343 192.168.0.109 192.168.0.201 TCP 68
> 65505 > 49552 [PSH, ACK] Seq=1 Ack=1 Win=453 Len=2 TSval=44814
> TSecr=229029303
>
> Data (2 bytes)
> 0000 d2 00 ..
> Data: d200
> [Length: 2]
>
> No. Time Source Destination
> Protocol Length Info
> 632 2.428268 192.168.0.109 192.168.0.201 TCP 69
> 65505 > 49552 [PSH, ACK] Seq=3 Ack=1 Win=453 Len=3 TSval=44814
> TSecr=229032266
>
> Data (3 bytes)
> 0000 00 01 42 ..B
> Data: 000142
> [Length: 3]
>
> No. Time Source Destination
> Protocol Length Info
> 634 2.430765 192.168.0.201 192.168.0.109 TCP
> 322 49552 > 65505 [PSH, ACK] Seq=1 Ack=6 Win=115 Len=256
> TSval=229032267 TSecr=44814
>
> Data (256 bytes)
>
> 0000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ................ 0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ................ 0020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ff ................ 0030 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ff ff ................ 0040 ff ff ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ................ 0050 ff ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff ................ 0060 ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff ff ................ 0070 ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff ff ff ................ 0080 ff ff ff ff ff ff ff ff ff
> ff ff ff ff ff ff ff ................ 0090 ff ff ff ff ff ff ff ff
> ff ff ff ff ff ff ff ff ................ 00a0 ff ff ff ff ff ff ff
> ff ff ff ff ff ff ff ff ff ................ 00b0 ff ff ff ff ff ff
> ff ff ff ff ff ff ff ff ff ff ................ 00c0 ff ff ff ff ff
> ff ff ff ff ff ff ff ff ff ff ff ................ 00d0 ff ff ff ff
> ff ff ff ff ff ff ff ff ff ff ff ff ................ 00e0 ff ff ff
> ff ff ff ff ff ff ff ff ff ff ff ff ff ................ 00f0 ff ff
> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ Data:
> ffffffffffffffffffffffffffffffffffffffffffffffff... [Length: 256]
>
> No. Time Source Destination
> Protocol Length Info
> 645 2.499146 192.168.0.109 192.168.0.201 TCP 68
> 65505 > 49552 [PSH, ACK] Seq=6 Ack=257 Win=498 Len=2 TSval=44821
> TSecr=229032267
>
> Data (2 bytes)
>
> 0000 fb 6d .m
> Data: fb6d
> [Length: 2]
>
> No. Time Source Destination
> Protocol Length Info
> 646 2.502481 192.168.0.201 192.168.0.109 TCP 67
> 49552 > 65505 [PSH, ACK] Seq=257 Ack=8 Win=115 Len=1 TSval=229032285
> TSecr=44821
>
> Data (1 byte)
>
> 0000 f3 .
> Data: f3
> [Length: 1]
>
> >>>>>>>>>> --------END------------------------ <<<<<
> >>>>>>>>>> ----------------------------------- <<<<<
> >>>>>>>>>> ----------------------------------- <<<<<
> >>>>>>>>>> ----------------------------------- <<<<<
> >>>>>>>>>> ----------------------------------- <<<<<
>
> Now of interest, is if I take the Pi out of the equation and use the
> same approach but on the machine running the Drivewire server (ie.
> socat
>
> is relaying on the localhost) it works:
> >>>>>>>>>> ---------START--------------------- <<<<<
> >>>>>>>>>> ----------------------------------- <<<<<
> >>>>>>>>>> ----------------------------------- <<<<<
> >>>>>>>>>> ----------------------------------- <<<<<
> >>>>>>>>>> ----------------------------------- <<<<<
>
> No. Time Source Destination
> Protocol Length Info
> 17 2.567686 127.0.0.1 127.0.0.1 TCP 67
> 65505 > 56229 [PSH, ACK] Seq=1 Ack=1 Win=400 Len=1 TSval=228967531
> TSecr=228963225
>
> Data (1 byte)
>
> 0000 d2 .
> Data: d2
> [Length: 1]
>
> No. Time Source Destination
> Protocol Length Info
> 18 2.568189 127.0.0.1 127.0.0.1 TCP 68
> 65505 > 56229 [PSH, ACK] Seq=2 Ack=1 Win=400 Len=2 TSval=228967531
> TSecr=228963225
>
> Data (2 bytes)
>
> 0000 00 00 ..
> Data: 0000
> [Length: 2]
>
> No. Time Source Destination
> Protocol Length Info
> 20 2.568789 127.0.0.1 127.0.0.1 TCP 68
> 65505 > 56229 [PSH, ACK] Seq=4 Ack=1 Win=400 Len=2 TSval=228967532
> TSecr=228963225
>
> Data (2 bytes)
>
> 0000 01 42 .B
> Data: 0142
> [Length: 2]
>
> No. Time Source Destination
> Protocol Length Info
> 25 2.572117 127.0.0.1 127.0.0.1 TCP
> 322 56229 > 65505 [PSH, ACK] Seq=1 Ack=6 Win=342 Len=256
> TSval=228967532 TSecr=228967532
>
> Data (256 bytes)
>
> 0000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ................ 0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ................ 0020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ff ................ 0030 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ff ff ................ 0040 ff ff ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ................ 0050 ff ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff ................ 0060 ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff ff ................ 0070 ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff ff ff ................ 0080 ff ff ff ff ff ff ff ff ff
> ff ff ff ff ff ff ff ................ 0090 ff ff ff ff ff ff ff ff
> ff ff ff ff ff ff ff ff ................ 00a0 ff ff ff ff ff ff ff
> ff ff ff ff ff ff ff ff ff ................ 00b0 ff ff ff ff ff ff
> ff ff ff ff ff ff ff ff ff ff ................ 00c0 ff ff ff ff ff
> ff ff ff ff ff ff ff ff ff ff ff ................ 00d0 ff ff ff ff
> ff ff ff ff ff ff ff ff ff ff ff ff ................ 00e0 ff ff ff
> ff ff ff ff ff ff ff ff ff ff ff ff ff ................ 00f0 ff ff
> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ Data:
> ffffffffffffffffffffffffffffffffffffffffffffffff... [Length: 256]
>
> No. Time Source Destination
> Protocol Length Info
> 29 2.646025 127.0.0.1 127.0.0.1 TCP 67
> 65505 > 56229 [PSH, ACK] Seq=6 Ack=257 Win=409 Len=1 TSval=228967551
> TSecr=228967532
>
> Data (1 byte)
>
> 0000 ff .
> Data: ff
> [Length: 1]
>
> No. Time Source Destination
> Protocol Length Info
> 30 2.646903 127.0.0.1 127.0.0.1 TCP 67
> 65505 > 56229 [PSH, ACK] Seq=7 Ack=257 Win=409 Len=1 TSval=228967551
> TSecr=228967532
>
> Data (1 byte)
>
> 0000 00 .
> Data: 00
> [Length: 1]
>
> No. Time Source Destination
> Protocol Length Info
> 32 2.647339 127.0.0.1 127.0.0.1 TCP 67
> 56229 > 65505 [PSH, ACK] Seq=257 Ack=8 Win=342 Len=1 TSval=228967551
> TSecr=228967551
>
> Data (1 byte)
>
> 0000 00 .
> Data: 00
> [Length: 1]
>
> >>>>>>>>>> --------END------------------------ <<<<<
> >>>>>>>>>> ----------------------------------- <<<<<
> >>>>>>>>>> ----------------------------------- <<<<<
> >>>>>>>>>> ----------------------------------- <<<<<
> >>>>>>>>>> ----------------------------------- <<<<<
>
> The exchange looks good, it's just a duff checksum in the first case.
> The only obvious difference is how the serial data is packeted up
> which would cause some subtle timing differences maybe...?
>
> In both instances I'm using the same Prolific USB serial port
> converter. I've also tried swapping out the Rasperry Pi with a Linux
> laptop and get the same behaviour.
There is a magic swear word to me, Prolific. Often bad dogs, throwing
away the first byte of a usb packet when it come from a slow source so
it has time to go to sleep. I have never been able to get one to talk to
a UPS as the UPS's data output is so slow.
FDTI stuff just works.
My coco3 is in the basement, and I have an FDTI adaptor plugged into a 7
port hub on top of the "computer" desk its sitting on, with a 10 meter
USB2 extension cable coming up this linux box where the dw jar is
running. And I have a couple of the Prolific PL-2303 adaptors too. But
the sure way to kill the whole system is to swap the FTDI out & put
either of the prolifics in the system between the bit banger and the usb
hub.
The hub is needed because there is a Brother HL2140 B&W laser printer,
setup to be driven by cups, and I have some scripts that tie drivewires
printer to cups. So I can list file >/p on the coco, and a few seconds
later the drum warms up and the listing spits out of that printer at 19
PPM. Way prettier output, best printer I have ever used with the coco.
It of course does not understand the coco's text output, but with cups
in the middle doing the translation, all problems are solved.
I don't recall the brand of that extension cable but let me see if lsusb
will tell me. See what goggle spits out for "Terminus Technology".
Not very many makers of USB extension hubs. These violate, at 10 meters,
by a wide margin, the max length (5') of a USB cable and cost around $40
USD, but they Just Work(TM).
A possibility since ISTR you mentioned the RPi, is to run linux on it,
and set its cups server up to do that. But my way also makes that
printer available to any of the other 4 machines on my home network.
> Does anyone have any experience of this or can explain the behaviour
> I'm seeing?
>
> Rgs,
>
>
> Jon.
> --
> == jon bird - software engineer
> == <reply to address _may_ be invalid, real mail below>
> == <reduce rsi, stop using the shift key>
> == posted as: news 'at' onastick 'dot' clara.co.uk
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>
More information about the Coco
mailing list