Force track/sector/byte geometry and fill missing/bad blocks with provided value

[wohali]

Sometimes, a raw flux dump will have bad or missing sectors. This leads to output from disk-analyse that will have missing blocks, which can lead to an unusable, truncated image.

Example of a standard IBM 3740 8" disk (77 tracks of 26 128-byte sectors) with this issue:

$ disk-analyse -v -i --format=ibm --ss=0 --end-cyl=76 unk02.hfe unk02.img
T0.0-61.0: IBM-FM DD (26 128-byte sectors, 3328 bytes)
T62.0-63.0: IBM-FM DD (25 128-byte sectors, 3200 bytes)
T64.0-67.0: IBM-FM DD (26 128-byte sectors, 3328 bytes)
T68.0: IBM-FM DD (25 128-byte sectors, 3200 bytes)
T69.0-75.0: IBM-FM DD (26 128-byte sectors, 3328 bytes)
T76.0: IBM-FM DD (25 128-byte sectors, 3200 bytes)
$ ls -la unk02.img
-rw-r--r-- 1 1001 1001 255744 Nov 29 16:49 unk02.img
$ dc
26 128 * 77 * p
256256
255744 - p
512
128 / p
4

In this case, the OS knew there are 4 bad blocks and mapped around them, but the truncated image produced by disk-analyse cannot be used by the system (or its emulation).

It would be nice in these cases to replace the bad or missing blocks with a static byte - for instance, e5 or 00. Otherwise, hex editing of the file is required to produce a usable sector dump.

[wohali]

I'd be happy to contribute a fix for this, but I'd like some guidance on whether this is desired, and what shape the CLI should take to support this option - as both the C/H/S format and fill value would need to be specified. The former may be best as an extension of the already-provided format functionality, but I'm not sure.

[keirf]

Yes there are two options. One is to allow specification of C/H/S/R/N etc on command line (or probably more likely within the formats file) and plumb that through to ibm.c. Another easier but less morally righteous approach would be to extend ibm_img.c to support FM. You will see this latter analyser has the track structure described in an extended struct track_handler.

[wohali]

A disadvantage to only using formats is that it could be painful to override for unusual disks - but if we adopted a simple mnemonic, or allowed multiple options per format, that might work well. As an example, you have ibm_pc_dd right now, but that can be 1- or 2-sided, 8 or 9 sectors per track, etc. Do you split ibm_pc_dd out into all of the subtypes? Or do you have the code make a best guess - which it might get wrong, and you'd need to override on the cli anyway?

That said I see how big formats has gotten with special cases for video game copy protection special cases, so maybe that's the best approach in the long run. It'd require a large effort (read: more than I could do myself) to retrofit that file with all of the information.

In C/H/S/R/N what are R and N?

[keirf]

The specific handler such as ibm_pc_dd don't really guess at all. That one is hardcoded to 9spt. However single- vs double-sided can be specified on the command line, and that should work.

The original purpose of the analyser was specifically for copy protections. Hence lots of single-purpose analysers. The IBM stuff got added later and the more flexible parameterisation that would make sense for IBM was missing and never got added.

CHRN is the 4-tuple in every IBM sector header, Cyl, Head, Sector ID (called R for some reason), Sector Size (N = log_2(Size/128)). S is another name for R or N, I suppose that's why the proper docs don't use S!