Changed Apple II Disk II sectors sometimes write to disk image as nulls #1227
Comments
|
With a little logging... --- a/Storage/Disk/Encodings/AppleGCR/SegmentParser.cpp
+++ b/Storage/Disk/Encodings/AppleGCR/SegmentParser.cpp
@@ -239,6 +239,9 @@ std::map<std::size_t, Sector> Storage::Encodings::AppleGCR::sectors_from_segment
uint_fast8_t shift_register = 0;
+ int i = 0;
+ fprintf(stderr, "sectors_from_segment\n");
+
const std::size_t scanning_sentinel = std::numeric_limits<std::size_t>::max();
std::unique_ptr<Sector> new_sector;
std::size_t sector_location = 0;
@@ -317,6 +321,7 @@ std::map<std::size_t, Sector> Storage::Encodings::AppleGCR::sectors_from_segment
// Potentially this is a Macintosh sector.
auto macintosh_sector = decode_macintosh_sector(had_header ? &header : nullptr, sector);
if(macintosh_sector) {
+ fprintf(stderr, "%2d. %5ld: macintosh sector\n", ++i, sector_location);
result.insert(std::make_pair(sector_location, std::move(*macintosh_sector)));
continue;
}
@@ -324,8 +329,12 @@ std::map<std::size_t, Sector> Storage::Encodings::AppleGCR::sectors_from_segment
// Apple II then?
auto appleii_sector = decode_appleii_sector(had_header ? &header : nullptr, sector, is_five_and_three);
if(appleii_sector) {
+ fprintf(stderr, "%2d. %5ld: apple ii sector\n", ++i, sector_location);
result.insert(std::make_pair(sector_location, std::move(*appleii_sector)));
+ continue;
}
+
+ fprintf(stderr, "%2d. %5ld: UNKNOWN SECTOR <----\n", ++i, sector_location);
} else {
new_sector->data.push_back(value);
}
@@ -341,5 +350,6 @@ std::map<std::size_t, Sector> Storage::Encodings::AppleGCR::sectors_from_segment
}
}
+ fprintf(stderr, "\n");
return result;
}...I see that the last sector parsed by Understandable that a 17th sector would be skipped if it were garbage, but often it's the 16th sector that can't be detected, and sometimes 17 valid sectors are detected... |
|
The reasons why CLK/Storage/Disk/Encodings/AppleGCR/SegmentParser.cpp Lines 178 to 182 in ec39c4a or the size check failed: CLK/Storage/Disk/Encodings/AppleGCR/SegmentParser.cpp Lines 144 to 147 in ec39c4a Both are because the data coming in to Printing out the These should all be 96's. When it fails due to the xor check (first three examples), it's because the lost bit(s) still resulted in a valid six-and-two byte (9d, ad, b4). When it fails due to the size check (fourth example), the bit corruption resulted in a byte that's not valid for six-and-two (95) so it aborted early. |
|
The bit corruption happens at the point when |
|
Now that you've bothered to do the research, it strikes me that data validity across rollover is an incredibly under-tested part of this emulator; most platforms align disk output to the index hole, to which a writeable segment will be aligned, and therefore don't try to write anything meaningful across the fold. I don't immediately know what the answer is, however. |
|
I'm now using a DOS disk image that just initializes track 15 of the current disk on startup, using Pieter Lechner's "INIT - reformat a single track" program from Beneath Apple DOS (pages A-12 through A-15): 1DATA32,227,3,132,0,133,1,165,2,160,4,145,0,169,0,160,12,145,0,169,0,160,3,145,0,32,227,3,32,217,3,189,137,192,165,2,133,68,165,3,133,65,169,170,133,62,169,40,133
2DATA69,160,86,169,0,153,255,187,136,208,250,153,0,187,136,208,250,32,13,191,169,8,176,25,169,48,141,120,5,56,206,120,5,240,14,32,68,185,176,245,165,45,208,241,32
3DATA220,184,144,31,160,13,145,0,169,135,32,237,253,169,45,32,237,253,169,195,32,237,253,169,189,32,237,253,160,13,177,0,32,218,253,189,136,192,169,0,133,72,96
4FORI=768TO904:READJ:POKEI,J:NEXT
5T=15:V=PEEK(47)
6?"INITIALIZING TRACK "T" VOLUME "V
7POKE2,T:POKE3,V:CALL768This is quicker and easier to debug than initializing the whole disk because I only have to wait for and analyze the data of a single track, and I don't have to swap in a blank disk. To prepare such a disk, boot another emulator like OpenEmulator with DOS 3.3, then insert a blank disk image, paste in the above program, and initialize the disk to run that program at startup using: After closing the other emulator, the disk image can be used to boot up Clock Signal, and the program can be rerun without rebooting with: The data corruption is already present in the data that is sent to I have also now seen the problem occur due to a header checksum mismatch here: CLK/Storage/Disk/Encodings/AppleGCR/SegmentParser.cpp Lines 165 to 167 in ec39c4a It's the same root cause, the missing bit just occurred within the address field this time. When no error occurs, it's because the missing bit occurred in a sync byte, from which the disk system is designed to recover since some sync bytes are expected to be partially overwritten during disk writes. |
If non-Apple systems use the index hole for synchronization and are happy with the data Clock Signal gives them following the index hole, then I guess the missing bit has to be considered to be at the end of the track serialization data. And of course no sooner have I posted the above analysis than I find a case where everything works fine and there is no missing bit. This happens the very first time I boot the disk after starting Clock Signal. Retrying with |
Using this patch to work around #1218...
...I can boot an Apple IIe and save some information to disk, for example let's save the ROM:
I can then load it back into RAM:
And see that they're the same because this command produces no output:
But if I then close the emulator, which writes the changes to the disk image, and boot up another emulated machine and load it in from disk again:
They're not the same now:
It shows large portions replaced with nulls:
...and so on.
I originally reported this to AppleCommander before I realized it was not a bug with reading the disk image; the problem had occurred when writing it.
The text was updated successfully, but these errors were encountered: