D64 to G64 300 RPM glitch

[0wwafa]

The result G64 track 1 starts with FF FF FF FF and ends with 55 55 55 FF.

That's quite wrong (even if logically right) and will lead to errors when writing them.

To reproduce:

g64conv.exe empty.d64 empty.g64 300

000002a0h: 00 00 00 00 00 00 00 00 00 00 00 00 0C 1E FF FF 
000002b0h: FF FF 52 6E F5 29 4B 9A DC F5 55 55 55 55 55 55
...
000020a0h: 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
000020b0h: 55 55 55 55 55 55 55 55 55 FF 00 00 00 00 00 00

[0wwafa]

         $ret .="   sync 32\n   gcr 08\n"
	       ."   begin-checksum\n      checksum\n"
	       ."      gcr ".sprintf("%02x", $j)."\n"      
	       ."      gcr ".sprintf("%02x", $i)."\n"
	       ."      extgcr 165a3 1\n"
	       ."      extgcr 165a2 1\n"
	       ."   end-checksum\n"
	       ."   gcr 0f\n"
	       ."   gcr 0f\n"
	       ."   bytes 55 55 55 55 55 55 55 55 55 ff\n"
	       ."\n"
	       ."   sync 32\n   gcr 07\n"
	       ."   begin-checksum\n"
	       ."      extgcr ".sprintf("%2x", $o)." 100\n"
	       ."      checksum\n"
	       ."   end-checksum\n"
	       ."   gcr 00\n"
	       ."   gcr 00\n"
	       .$extraspace
	       ."   bytes 55 55 55 55 55 55 55 55 ff\n";

should be:

         $ret .="   sync 40\n   gcr 08\n"
	       ."   begin-checksum\n      checksum\n"
	       ."      gcr ".sprintf("%02x", $j)."\n"      
	       ."      gcr ".sprintf("%02x", $i)."\n"
	       ."      extgcr 165a3 1\n"
	       ."      extgcr 165a2 1\n"
	       ."   end-checksum\n"
	       ."   gcr 0f\n"
	       ."   gcr 0f\n"
	       ."   bytes 55 55 55 55 55 55 55 55 55 ff\n"
	       ."\n"
	       ."   sync 32\n   gcr 07\n"
	       ."   begin-checksum\n"
	       ."      extgcr ".sprintf("%2x", $o)." 100\n"
	       ."      checksum\n"
	       ."   end-checksum\n"
	       ."   gcr 00\n"
	       ."   gcr 00\n"
	       .$extraspace
	       ."   bytes 55 55 55 55 55 55 55 55\n";

[markusC64]

Understood what you want me to change. You want to rotate the whole track so that the first FF is at the start of the track and not at the end of the track.

Since there is a "begin-at" token that does that job, I'll probably use that.

I found yet another bug in d71 to g71 conversion, so I'll probably make a final commit to fix both problems. Bit in general note that g64conv is quite slow, especially for larger images (e. g. CMD FD), therefore I am working on a new solution written as powershell module.

Spoiler: The same call in my new module will be: New-FloppyDiskTemplate -Floppy floppy1541 | Convert-FloppyDiskImage -TemplateToText -DataFilename empty.d64 | Convert-FloppyDiskImage -TextToBitstream | Export-FloppyDiskImage -Bitstream -Filename empty.g64

BTW: What are the exact steps to get the errors when writing to such an image? Using an emulator or writing it back to disk (in that case: How?)?

[0wwafa]

BTW: What are the exact steps to get the errors when writing to such an image? Using an emulator or writing it back to disk (in that case: How?)?

If you write such image on a slower drive, the last thing written will be the FF FF FF FF FF sync but there will be lots of "55" afterwards (the emptied track below). So unless the writing drive is exactly at 300 RPM (which never happens) the disk won't work and have missing 0 sectors for every track (or worse).