WinUAE icon indicating copy to clipboard operation
WinUAE copied to clipboard

Formatting HD disks ( floppy_get_rootblock)

Open dirkwhoffmann opened this issue 5 years ago • 4 comments

Hi there. This is about a bug in SAE which is also present in UAE (disk.cpp). In SAE, it's in function floppy_get_rootblock(dst, block, label, type):

if (type == SAEC_Disk_Create_Type_35_DD)
            dst[512 + 0x72] = 0x3f;
        else
            dst[512 + 0xdc] = 0x3f;

If a HD disk is selected, byte $DC in the bitmap block is set to $3F to mark the root and bitmap block as being used.

As far as I know, the root block is located at 1760 for HDs, so shouldn’t be

(1760 / 8) + 4 = 224 = $E0 the correct location for the 0x3f byte? (The +4 is for skipping the checksum long word).

dirkwhoffmann avatar May 11 '19 12:05 dirkwhoffmann

Current offset matches formatted HD disk contents. I don't remember how bitmap is calculated..

tonioni avatar May 12 '19 16:05 tonioni

Hi Toni, I've tested both values in SAE.

0x3f does give a "bad disk", but 0xe0 is working and seems to be correct.

naTmeg avatar May 13 '19 05:05 naTmeg

I meant if I format DF0: with HD disk in WB, and check it with disk editor: 0x3f is in offset 0xdc. Both 0xdc and 0xe0 can't be true and I am not sure whats going on..

EDIT: DF0: of course..

tonioni avatar May 17 '19 13:05 tonioni

The correct code in disk.cpp, line 2573 should be:

if (!hd)
dst[512 + 0x72] = 0x3f;
else
dst[512 + 0xdc] = 0xe0;

At least this does work in SAE. Maybe there's an additional bug somewhere. From WB, I can re-format the HD-image and copy files to it as expected. No disk-errors. But 0x3f in the 2nd line does give a bad disk from start.

naTmeg avatar May 17 '19 15:05 naTmeg