Before, when .dsk and .do images were nibblized, the physical
sectors were laid out incorrectly on the track:
Physical: 0 F 8 1 9 2 A 3 B 4 C 5 D 6 E 7
Logical: 0 F E D C B A 9 8 7 6 5 4 3 2 1
This was due to two issuse in the DOS(options) function. First, it
iterated backwards through the DOS sectors. Second, it used the DOS
sector to map backwards to the physical sector.
Now the function has been corrected to iterate through the physical
sectors in order and maps the physical sector to the DOS sector. The
resulting layout is:
Physical: 0 1 2 3 4 5 6 7 8 9 A B C D E F
Logical: 0 7 E 6 D 5 C 4 B 3 A 2 9 1 8 F
I verified the physical with Locksmith's nibble editor. New tests
ensure that this remains correct.
Also, the original explodeSector16 function used a data epilogue of
DE AA F2 instead of the correct epilogue of DE AA EB. Apparently
this doesn't matter as Beneath Apple DOS says:
Oddly, the $EB is always written during initialization but is
never verified when the Address Field is read.
I'm guessing that this is true for the Data Field as well. This is
now part of the tests.
Before, when
.dskand.doimages were nibblized, the physical sectors were laid out incorrectly on the track:This was due to two issuse in the
DOS(options)function. First, it iterated backwards through the DOS sectors. Second, it used the DOS sector to map backwards to the physical sector.Now the function has been corrected to iterate through the physical sectors in order and maps the physical sector to the DOS sector. The resulting layout is:
I verified the physical with Locksmith's nibble editor. New tests ensure that this remains correct.
Also, the original
explodeSector16function used a data epilogue ofDE AA F2instead of the correct epilogue ofDE AA EB. Apparently this doesn't matter as Beneath Apple DOS says:I'm guessing that this is true for the Data Field as well. This is now part of the tests.