[Coco] Socat drivewire relay to CoCo1

[jon bird]

Had a bit of a brainwave on this one earlier, although given the amount 
of times I've been stung like this I'm a bit of a berk for not thinking 
about it earlier. Linux has all these tty settings it on serial ports 
which seem to default to different things seemingly depending on the 
time of day. Sure enough, on my failing setup, there were a lot of 
"echo" type options enabled. Turning them all off and everything sprang 
into life. Still got the odd quirk to work through but looking much 
better now.

Thanks for the comments everyone.

j.

In article <672e03a8862efa0b263d15c1656805f4.squirrel at localhost>, jon 
bird <news at onastick.clara.co.uk> writes
>> On Mon, Mar 2, 2015 at 8:26 PM, jon bird wrote:
>>>> That checksum of $f9f7 is fairly consistent (although I have seen a 
>>few
>>>> instances where it comes back with something completely different). 
>>The
>>>> "good" trace I posted yesterday shows the server accepting a 
>>checksum of
>>>> $ff00.
>>>>
>>>> Possibly a bit of a random angle but I attempted to compute the 
>>checksum
>> myself given the algorithm at the back of the Drivewire 3 spec. For a
>> buffer
>> set entirely to $ff I get a result of $FE01 which doesn't tally up 
with
>> any
>> of this.
>>
>> I'm at a bit of a loss now to explain what exactly is causing this.
>
> To investigate further, I would have made a little DriveWire client
> that prints out all received bytes on the CoCo, so that you would see
> if it is the incoming data that gets corrupted or the outgoing
> checksum. See for instance the DWDOS code in toolshed, or my DWLOAD
> code at the Dragon forum.
>
> Of course, you may also be able to PEEK the incoming data if you know
> where the DIR command buffers it - if it is not in the command line
> buffer :) Although it may use the same buffer to send the checksum and
> receive the status byte so it might be partly overwritten.
>

Hi Tormod,

My feeling is that it's probably the receive side of things, the (albeit
few) transmits look ok and to me given the burst of data being sent to 
the
CoCo it's more likely for things to go wrong there (buffer overruns 
etc.).
Thinking ahead, I guess my issue would be even if I tracked down what 
was
happening, not entirely sure what I'd do to fix it. It's just very odd
that this setup works fine when going through the local loopback 
device...

So given I mentioned yesterday I have the bits on order to make up the
Dragon Drivewire adaptor, plus I'm more familiar with the architecture
(and have a working disk system with assemblers etc., something I'm
lacking with my CoCo setup) will probably see what that throws up.

The other thing I may do is try shortening & rewiring the CoCo serial
cable, see if that makes a difference.

Rgs,


Jon.


== mailto:jon at onasticksoftware.co.uk - in real life jon bird
==  http://www.onasticksoftware.co.uk - stuff, on-a-stick
==   "men love women, women love children, children love hamsters"
==    <technology out of control>



-- 
Coco mailing list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco

-- 
== 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