keithWell, I’ve written my first .adf tonight!
I threw together a quick routine on the PC side to query the SX for both sides and all the tracks.
It generated a 901,120 byte .ADF file of a disk I had called “Disney Demoreel.”
While it wasn’t perfect, and ADF Opus reports adfReadBootBlock: incorrect checksum, it does manage to report correct filesizes, filenames, etc. Trying to actually execute the program fails in UAE because of read/write disk errors. I’m not horribly worried about those at this point because I don’t actually re-read bad tracks at any point.
UAE also shows the correct screen icons, so at least SOME of the data is ok. And the fact that it’s readable at all is somewhat telling.
CLICK ON THE IMAGE TO DISPLAY FULL SIZE
While I’m not sure if its any consolation, DiskMon on the amiga actually reports the bootblock as having a checksum error too. This has been true on multiple disks, so I think I’m just running into a “that’s how it is” type situation. The actual amiga and winUAE doesn’t complain.
I implemented some basic retry mechanism which resulted in a read that had only 4 bad sectors the whole disk. That’s 4/1760 sectors, or something like .2%, so I’m 99.8% good.
I’ll take it at this point!! 🙂
The disk I’m currently sampling has very large executable files, so a single bad bit here or there could cause problems. I’m going to format my all ascii disk, and try that again.
The (4) bad sectors were “hard errors”, or at least, after 5 retries they still error’d out. They errored in the same place across all 5 reads, so there’s something my SX doesn’t like about those sectors.
Each of the bad tracks had different problem sectors, so it looked like this:
Cylinder 5, sector 4 bad
Cylinder 22, sector 1 bad
Cylinder 33, sector 5 bad
Cylinder 53, sector 8 bad
It would be really nice to know if those just happened to be the sector before or after a gap. Wonder what they have in common?
Note that the amiga reads these cylinders fine — so its not a physical disk problem as far as I can tell.
I want to get a checksum program for the amiga and for the PC that will both spit out compatible checksums, so that I can test individual files for errors. Just a simple 8bit or 32bit checksum would do the trick.
Good progress for tonight. It’s 2:34am local time so I better go to bed!!
I tried another disk today, and still ended up with (4) hard errors.
This time I didn’t get a “boot block” checksum error, and I downloaded “MD5SUM” for the amiga. I ran checksums on the files, which were mostly .MOD files. .MOD files, or modules, were old-school music files for ProTracker, SoundTracker, etc various trackers which would play the music.
(6) of the (10) files checksummed perfectly which is a good start.
(3) of the other (4) played properly, despite there being bit errors. I suppose I could diff those files and see what the differences were.
The last one didn’t play at all, so perhaps there were bit errors in a crucial part of the file.
Same deal with the last disk I tested. There were certain sectors that wouldn’t checksum no matter how many times I read them.
I’ve really got to narrow down what’s different about those sectors than the THOUSANDS of others that read just fine.
Ok. Diff’d one file, mod.newworldman to be exact. It’s a .mod from one of my favorite bands RUSH. See https://en.wikipedia.org/wiki/Rush_%28band%29 for details.
Anyways, note in this comment I’m talking about ACTUAL REAL DECODED FILE DATA vs raw MFM encoded stuff. I usually refer to MFM data, but this is the exception.
Out of 116,172 bytes, 8 of them were corrupt. It’s worth noting that is .00007 worth of the file that’s actually corrupt. Or looked another way, out of 929,376 bits, only like 19 bits were corrupt.
0404 FEDA DEE2 E3E4 : good bytes
0555 FF8F 8FF7 F7A4: received bytes
Note that is really only 18-19 bad bits that have been spread and poisoned the 8 bytes. Roughly 70% of the bad bits were 1’s where 0’s should have been.
I’m not sure what this tells me.