[Coco] DW4 problems
Bob Devries
devries.bob at gmail.com
Tue Oct 23 19:32:16 EDT 2012
Just a quick update...
I connected the drivewire cable to COM1 of the PC, and it's currently doing
a backup from /h0 to /x2. It's at LSN 238000 and counting. Only three
warnings:
Wed Oct 24 2012 06:59:02.437 WARN DWProtocolHandler dwproto-0-10
OP_READEX took 500ms.
Wed Oct 24 2012 07:02:23.546 WARN DWProtocolHandler dwproto-0-10
OP_READEX took 281ms.
Wed Oct 24 2012 07:33:31.764 WARN DWProtocolHandler dwproto-0-10
OP_WRITE took 10108ms.
The first two were likely me starting Outlook Express, but who knows about
the third. It's a very long timeout >10secs.
I'm quietly confident that it's been the USB dongle all along. Strange
though. I have used it for other connections, with no problems, albeit at
lower baud rates.
Regards, Bob Devries
Dalby, QLD, Australia
----- Original Message -----
From: "Aaron Wolfe" <aawolfe at gmail.com>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Tuesday, October 23, 2012 7:08 PM
Subject: Re: [Coco] DW4 problems
On Tue, Oct 23, 2012 at 4:23 AM, Bob Devries <devries.bob at gmail.com> wrote:
> Some more interesting things: It may be coincidence but...
>
> I got this error:
>
> Tue Oct 23 2012 17:46:26.218 WARN DWProtocolHandler dwproto-0-10
> DoOP_WRITE: Bad checksum, drive: 2 LSN: 159015 CocoSum: 23 ServerSum: 6127
>
> Please note that the HEX value of the Coco checksum is $17, and that of
> the
> server is $17EF. Note also that the next line:
>
> Tue Oct 23 2012 17:46:26.218 WARN DWProtocolHandler dwproto-0-10
> UNKNOWN OPCODE: 239 ï
>
> The hexadecimal of 239 is....$EF
>
> Coincidence? Could be...
> In cases where I get a checksum error, it appears that when converted to
> hexadecimal, the first byte of the server checksum is the same as the
> second
> byte of the coco checksum. Makes you wonder, right?
>
>
in an op_write, the coco sends 262 bytes:
Byte Value
0 OP_WRITE ($57)
1 Drive number
2 Bits 23-16 of LSN
3 Bits 15-8 of LSN
4 Bits 7-0 of LSN
5-260 256 bytes of sector data to write
261 Bits 15-8 of checksum (computed by CoCo)
262 Bits 7-0 of checksum (computed by CoCo)
this is a fixed size operation, so the server always reads 262 bytes as
well.
Is the first byte of the coco checksum (as reported by DW) always 0?
If the checksums line up otherwise, we're getting an extra byte from
somewhere but the data bytes are transferring OK (or the checksums
would be different).
Assuming that's correct, it almost means it has to be an extra 0 (or
non zero if you've seen that) *after* the sector data and *before* the
coco sends its checksum. This would mean somehow a byte is coming out
of nowhere.. I think I am even more suspicious of the buffering in
your adapter now. If you have any way to swap it out, I think that
will be a very good test to do next.
--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco
More information about the Coco
mailing list