NewRisingSun wrote:ijor wrote:So I don't know exactly what the protection expects from that sector.
The keydisk checking code expects the sector to be as decoded from the Kryoflux image which you already wrote you had taken a look at. If there is a way of decoding the SCP image to yield that result, then it is a question of interpreting the SCP data; otherwise, the SCP image is merely a bad dump.
Again, you have to be more specific. The sector is truncated by the write splice. So after the point of truncation, what you decode is not very reliable in either image. That sector has a theoretical size of 8K. I assume that the code doesn't actually check 8K worth of bytes, does it? I assume it checks less.
So the question is how many bytes it checks. If it checks for the exact number of bytes that the Kryoflux image has before truncation ($93), then it would fail.
But then it means the disk that was imaged with the SCP is bad, not that it is a bad dump.
Note that it is very possible that the number of bytes checked depends on the exact copy. That is, it is possible that
after the original disk was recorded, after each copy, the duplication process checks how many bytes were actually written on that particular copy, and adjusts the keydisk checking code accordingly.
This is sector 11 on track 0/0 on the Kryoflux image you posted:
Code: Select all
00001980 FB 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E ûNNNNNNNNNNNNNNN
00001990 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
000019A0 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
000019B0 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
000019C0 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
000019D0 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
000019E0 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
000019F0 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
00001A00 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
00001A10 4E 4E 4E NNN
And this is the same sector on the SCP image:
Code: Select all
00001990 .. .. .. .. .. .. FB 4E 4E 4E 4E 4E 4E 4E 4E 4E ......ûNNNNNNNNN
000019A0 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
000019B0 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
000019C0 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
000019D0 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
000019E0 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
000019F0 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
00001A00 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
00001A10 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
00001A20 4E 4E NN
You can see that I decoded across the index correctly. The sector on the SCP image is shorter, but this is because it was recorded like that. It's $93 bytes vs $8D bytes. After that, the write splice is present.
But the sector on the SCP image crosses the index. As I said in the previous post, from these $8D bytes, only $85 are before the index. But as you can see, I can decode the rest of the bytes across the index correctly.
Again, don't know if this will work or not. But decoding across the index is not the problem. At least not in this case.