Unable to identify filesystem on 'Blank3.2.1.nib' - for newly INIT'ed DOS 3.2 .nib file

[tomcw]

Hi Andy,

Let me start by saying that I really enjoy using CP, and appreciate the effort you have put into it.

I'm using CP 4.0.3, and the DOS 3.2 .nib file was created with AppleWin 1.25.0.4 (or a patched version of 1.27.0.0). NB. AppleWin 1.26.x and 1.27.0.0 have a bug that results in DOS 3.2 INIT failing with an I/O ERROR.

Firstly it's worth stating that DOS 3.2 (or DOS 3.2.1) INIT (during the formatter pass for tracks $00-$22), only writes the addr field for each sector, and not the data field. After the 35 tracks have been formatted, then it writes some sectors with actual data (eg. for boot, VTOC and HELLO), and these sectors will be the only ones with data fields.

I've stepped through the latest CP 4.0.3 code, and the issue is that CP assumes that the tracks it verifies (1,16,17,26) have sectors with data on them.

In Nibble.cpp: DIError DiskImg::AnalyzeNibbleData(void)

    /*
     * Try to read sectors from tracks 1, 16, 17, and 26.  If we can get
     * at least 13 out of 16 (or 10 out of 13) on three out of four tracks,
     * we have a winner.
     */

The specifics are:

DOS 3.2 INIT writes to these tracks:

• formats tracks $00-$22 as described above
• $11
• $00,$01,$02
• $11,$12 (17,18)

For CP's disk type (NibbleDescr): 'DOS 3.2 Standard'

Using CiderPress to count readable sectors for INIT tracks (after formatting $00-$22):

track	sector count
$00	13
$01	13
$02	9
$11	13
$12	2

Using CiderPress to count readable sectors for default CP tracks:

track	sector count
1	13
16	0
17	13
27	0

goodTracks = 2, which is less than 3, so CP fails to identify the disk as DOS 3.2 Standard.

Here's a .nib INIT'ed using a patched AppleWin 1.27.0.0: Blank3.2.1.nib.zip

[fadden]

Seems like we can either change it to use the current algorithm with a different set of tracks, or change the algorithm to try to take unwritten sectors into account. I haven't looked at the code in a while so I'm not sure which makes more sense.

[tomcw]

Perhaps just special case for the "DOS 3.2 Standard" case (so that there's no chance of regression for the other supported nibble formats).

EG. in DIError DiskImg::AnalyzeNibbleData(void), if nibble format == "DOS 3.2 Standard":

• test for goodTracks >= 2 (instead of 3), or
• switch to testing tracks: 0,1,17,18 (instead of 1,16,17,27)

btw. why did you choose tracks 1,16,17,27?

[fadden]

Track 0 can be a hybrid -- some 13-sector disks had a 6&2 encoded sector 0 so that the disk would boot on both old and new systems. Some copy-protected disks left track 0 open. So track 1 seemed a safer test in general.

IIRC, 16 and 27 were somewhat arbitrary.

[fadden]

This will not be addressed in CiderPress. It is correct handled by https://github.com/fadden/ciderpress2, which I know because your disk image is part of the test suite.

Thank you for bringing this to my attention way back when. It made me think about readable vs. writable sectors when developing the new code.