Print

[paule]

I have a Lisa 2/10 with XENIX installed on the Widget. I'm trying to image the drive using BLU Read from Disk to Serial Port, but when I do, after the transfer completes, and after a bit of a delay I get this:

OPERATION COMPLETED
POSSIBLY INCORRECT BLOCK CHECKSUMS - 255A

I first got this using Serial, which would then give me an error and not save the resulting data. Using ZOC8 I was at least able to save the image, but I'm concerned about whether something went wrong with the transfer. The above transfer was done at 57600/8N1. I also tried at 19200/8N1 and got a similar result, with the checksum of 255B.

Transferring the CPU and I/O board ROMs worked without any errors.

Any ideas of what might be causing problem with the Widget image, and a remedy?

[paule]

In case it is significant, I am using a DB25M to DE9F Adapter - Straight Through connected to a USB to RS-232 Adapter using the FTDI chipset (both from retrofloppy.com), connected to an iMac (Retina 5K, 27-inch, Late 2015) running MacOS 10.12.6.

[sigma7]

image the drive using BLU Read from Disk ... I get this:
POSSIBLY INCORRECT BLOCK CHECKSUMS - 255A

It is normal for this message to appear for non-MacWorks disks: The checksums referred to here are used only by MacWorks hard disks.

(The message is not related to xmodem block checksums.)

One of the bytes in the sector's tags is set by the hard disk driver to the xor of the other 531 bytes (so xor of the 532 bytes == 0).

In MacWorks, if this checksum is wrong when reading a sector, you'll get a fatal system error.

The checksum (if any) used by other operating environments is different (and not calculated by current version of BLU).

The message is a warning only, and doesn't (or not supposed to at least) interfere with the xmodem transmission, so if the transferred data isn't saved to a file, the cause is something else.

[paule]

Oh, excellent. Thank you for the thorough explanation.

Now I am wondering why the 57600 image would be 512 bytes shorter than the 19200 image (10,351,616 vs 10,351,104)...

[sigma7]

wondering why the 57600 image would be 512 bytes shorter than the 19200 image (10,351,616 vs 10,351,104)...

The padding character to fill a partial block at the end of a transfer is 0x1A, so if that's the difference they are the same

Why different, dunno... maybe one transfer used 1K blocks and the other not?

Although... since one warned about 255A block checksums and the other 255B, perhaps there was indeed an extra block... any possibility you have two versions of BLU? IIRC, an earlier version sent an extra block.

[paule]

Yep, 0x1A fills the difference. The block size explanation sounds as good as an I'm learning by trial and error here and I really appreciate your gentle help!