#963 Writing PRG files to D80 images causes data corruption

[Michau]

Unzip the attached archive and run the batch file. It uses c1541 to create an empty D80 disk and put three PRG files on it. The third file is corrupted - reading it gives an error "Track 0, Sector 0 out of bounds".

The problem disappears when D82 is used instead of D80.

I am using latest version of C1541 (4.1), I checked that the same problem happens with version 4.0.

[compyx]

Odd, indead the "8088.prg" causes problems. The rest of the files can be read properly, even adding "boot.prg" or "6509.prg" again under different file names works, as does reading them back and writing them to the host OS. The problem seems to be the 8088.prg file, trying to write that back to the host causes the "track 0, sector 0 out of bounds" message.

[compyx]

Did a little forensics on the image:

Part of the directory:

compyx@asus-p5k:~/c64/d80-test$ hd -n 256 -s 0x44f00 foo.d80 
00044f00  00 ff 82 26 01 42 4f 4f  54 2e 50 52 47 a0 a0 a0  |...&.BOOT.PRG...|
00044f10  a0 a0 a0 a0 a0 00 00 00  00 00 00 00 00 00 01 00  |................|
00044f20  00 00 82 26 02 36 35 30  39 2e 50 52 47 a0 a0 a0  |...&.6509.PRG...|
00044f30  a0 a0 a0 a0 a0 00 00 00  00 00 00 00 00 00 07 00  |................|
00044f40  00 00 82 26 05 38 30 38  38 2e 50 52 47 a0 a0 a0  |...&.8088.PRG...|
00044f50  a0 a0 a0 a0 a0 00 00 00  00 00 00 00 00 00 0e 00  |................|

So "8088.PRG" has its first sector at (38,5) ($26,$05)

00043600  26 0b 00 05 eb 08 00 00  00 00 00 00 00 00 bb 00  |&...............|

Pointing to (38,11) ($26, $0b):

00043c00  26 11 00 00 00 00 9a 03  f0 00 f0 c3 31 c9 8e d9  |&...........1...|

Pointing to (38,17) ($26,$11):

00044200  26 17 04 ff a1 0c 00 1f  59 c3 1e 51 88 e5 b1 03  |&.......Y..Q....|

Pointing to (38,23) ($26,$17):

00044800  26 06 e8 25 00 b9 96 00  01 e9 e8 fd fd 1f 59 fa  |&..%..........Y.|

Which points to (38,6) ($26,$06):

compyx@asus-p5k:~/c64/d80-test$ hd -n 256 -s 0x43700 foo.d80 
00043700  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00043800

Which is a full sector with 0x00, which isn't how CBM DOS terminates files, If the final block of a CBM file exactly fits in a sector, the T/S link data would be $00, $fe).

We're also left with a 5 block file, not 11 blocks as the original file would be.

I haven't tested d82 images yet, but I think we can conclude vdrive's d80 handling might have a few bugs.

[Michau]

Substituting the 8088.prg file with another file (for example, writing two copies of 6509.prg under different names) will give the same error, as long as the third file is more than 1 sector long.

If you do the same test with D82, you will notice that (38,5) points to (38,12) not to (38,11). It seems that the sectors for this file in D80 image are improperly interleaved, with a value that is off by 1.

[Greg King]

To confuse things even more: DirMaster interleaves D80 sectors by 10.

D80 vdrive doesn't write sectors 6 and 9 on track 38. That bug leaves two holes in the "8088" file. If you pre-allocate those blocks, then a good copy of the file is written.

c1541 -format test,01 d80 tmp.d80
c1541 tmp.d80 -@ "b-a 0 38 6" -@ "b-a 0 38 9" -write boot.prg boot -write 6509.prg 6509 -write 8088.prg 8088
c1541 tmp.d80 -chain 38 5

(38, 5) -> (38,11) -> (38,17) -> (38,23) -> (38, 7) -> (38,13) -> (38,19) -> (38,25) -> (38,12) -> (38,18) -> (38,24) -> (38,15) -> (38,21) -> (38,27) -> 44

[Michau]

Great, this workaround works well. I suppose I can free the sectors again after all files are placed using the B-D command.

[gpz]

does this work now? i vaguely remember some related fix, perhaps? :)

[compyx]

I also remember a fix for this. I've tested this with trunk and it appears to work: I used the commands in the .bat file to create a d80 and write the three files to it. When I read them back with the read command in c1541 I get all three files back properly (equal content).

So I suspect we fixed this but never closed this bug. Closing now.

[Greg King]

Fixed by revision 37368.