1
0
mirror of https://github.com/TomHarte/CLK.git synced 2024-11-17 10:06:21 +00:00

Eliminates test code, adds a caveat.

This commit is contained in:
Thomas Harte 2020-03-25 21:22:30 -04:00
parent 5fd2be3c8e
commit ea26f4f7bf
2 changed files with 9 additions and 4 deletions

View File

@ -87,7 +87,10 @@ std::shared_ptr<::Storage::Disk::Track> NIB::get_track_at_position(::Storage::Di
++length;
}
// Record a sync position only if there were at least five FFs.
// Record a sync position only if there were at least five FFs, and
// sync only in the final five. One of the many crazy fictions of NIBs
// is the fixed track length in bytes, which is quite long. So the aim
// is to be as conservative as possible with sync placement.
if(length == 5) {
sync_starts.insert((start + 1) % track_data.size());
@ -118,11 +121,8 @@ std::shared_ptr<::Storage::Disk::Track> NIB::get_track_at_position(::Storage::Di
track_data.begin() + off_t(index),
track_data.begin() + off_t(location));
segment += PCMSegment(data_segment);
} else {
printf("");
}
// Add a sync from sync_start to end of 0xffs, if there are
// any before the end of data.
index = location;

View File

@ -188,6 +188,11 @@ std::map<std::size_t, Sector> Storage::Encodings::AppleGCR::sectors_from_segment
sector->data.resize(sector->data.size() - 1);
if(is_five_and_three) {
// TODO: the above is almost certainly incorrect; Beneath Apple DOS partly documents
// the process, enough to give the basic outline below of how five source bytes are
// mapped to eight five-bit quantities, but isn't clear on the order those bytes will
// end up in on disk.
std::vector<uint8_t> buffer(256);
for(size_t c = 0; c < 0x33; ++c) {
const uint8_t *const base = &sector->data[0x032 - c];