TomHarte
commented
9 months ago All I've figured out so far is that I don't understand how that NIB can be a valid disk; in particular from byte offset 2022 it has a run of bytes of the form C0C0C0... which really shouldn't be possible. Cf. the WOZ write-up on weak bits:
One very popular copy protection is referred to as “fake bits” or “weak bits” – this technique is actually an exploit against the MC3470. It comes from the idea of what happens when we make it read more than two 0 bits in a row. What happens is that our poor MC3470 thinks that it is doing a bad job reading the disk and keeps trying to turn up its amp to find the flux signal. It does this until it gets to the point that it amplifies background electrical noise so much that it thinks that it sees a transition and sends out a false pulse, which the computer happily records as a 1 bit.
Switching off noise generation didn't solve the problem, so this isn't necessarily a good lead but it possibly indicates that either:
- NIB files are actually not just a capture of what the Disk II saw when reading a disk during capture (with a bunch of redundancy to pad out the track size); or
- there's some way to encode
C0s that is beyond my comprehension.
Or a third option I haven't thought of yet.
Regardless, this is mystery #1.
Despite the recent improvements in reading nib files, spectre.nib does not load at all in Clock Signal; it just stays on the "Apple ][" boot screen. It's encountering a checksum problem on the last sector of the track here:
https://github.com/TomHarte/CLK/blob/def1f90d86078ff02be19d48d28548d6de1a9b6f/Storage/Disk/Encodings/AppleGCR/SegmentParser.cpp#L178-L182
MAME, Virtual ][ and OpenEmulator can load this disk image.