Page 2 of 2

Re: kryo2apd

Posted: Sat Jul 20, 2013 8:08 pm
by danielj
Not yet, but I'm going to have a poke now...

Re: kryo2apd

Posted: Sat Jul 20, 2013 8:21 pm
by danielj
OK, this is probably non-trivial as I don't have the code written to look in any detail at MFM tracks - it's been on my todo list, but impending baby and decorating have kicked that into low earth orbit. My gut feeling is it's the write-splice issue raising its head again unless that's been fixed?

d

Re: kryo2apd

Posted: Sun Jul 21, 2013 5:38 am
by JonAbbott
The two issues with this disc set are:

1. FM on disc 1 is causing a crash
2. MFM on every other track is corrupt, with or without "-f"

Are you saying that issue 2 is caused by write-splice issues?

Re: kryo2apd

Posted: Sun Jul 21, 2013 9:23 pm
by danielj
JonAbbott wrote:The two issues with this disc set are:

1. FM on disc 1 is causing a crash
2. MFM on every other track is corrupt, with or without "-f"

Are you saying that issue 2 is caused by write-splice issues?
I think issue 2 could be, but I can't tell as I don't have the analysis code adjusted to deal with MFM tracks unfortunately. However, bit more of a look. There do seem to be FM tracks actually there (I'll look more closely at these to double check now). There's an arrayIndexOutOfBounds exception on track 83 side 0 when it's creating the APD as there's data on that track.

I think the description of APD is slightly off, or the format can't actually deal with tracks 166/167

8 bytes for ID, then 12 bytes per track (4sd, 4dd, 4qd).

Maximum possible tracks = 168 (84x2), so that's 168x12 + 8 bytes required for the header = 0x7E8 bytes, data should start at 0x7E8?

d.

(edit: not thinking, header starts at byte 0, not 1).

Re: kryo2apd

Posted: Sun Jul 21, 2013 9:45 pm
by danielj
Ok, there's no FM data, but there are *lots* of FM sector markers with invalid CRCs...

I think these are mostly just artefacts in the data when it's read as FM, not anything valid.

Without decoding the MFM data myself I can't tell if it's the write splicing that's causing the problem, but I suspect it probably is. There's no way an accurate GAP size can be assumed between the sector header and the sector data. It will only ever be perfect if the disk was mastered "in one go". If whatever copy protection was employed adjusted sectors subsequently you will frequently find extra bits in the gap (like I found in the Zarch image -the APD generated from this was correct, it really was what was in the kryoflux dump, but it didn't work with ADFFS as, I think, the write splice in the FM tracks threw the data off kilter by a couple of bits).

d.