kryo2apd

Discuss using Kryoflux to image floppies
danielj
Posts: 64
Joined: Sun May 12, 2013 9:08 pm

Re: kryo2apd

Post by danielj »

Not yet, but I'm going to have a poke now...
danielj
Posts: 64
Joined: Sun May 12, 2013 9:08 pm

Re: kryo2apd

Post 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
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: kryo2apd

Post 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?
danielj
Posts: 64
Joined: Sun May 12, 2013 9:08 pm

Re: kryo2apd

Post 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).
Last edited by danielj on Sun Jul 21, 2013 9:52 pm, edited 1 time in total.
danielj
Posts: 64
Joined: Sun May 12, 2013 9:08 pm

Re: kryo2apd

Post 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.
Post Reply