Conversion from P64 to G64 is broken #1
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Conversion from P64 to G64 is broken. With the attached example, the first 17 tracks get a read error.
td.p64.zip
for reference, I also attached the g64 that has been converted with my new beta of g64conv in combination with p64sync.
td.p64.convertedTo.g64.zip
Comparing the output of micro64disktool with that g64 shows that tracks 1 to 17 are stripped, many bits are missing.
Edit: One remark: Some syncs are made 1 bit longer in my g64 such track length in bits is a multiple of 8 (required by g64 format).
Same here.
converting a c64 formatted P64 created in VICE, does not converto to g64. produces nothing.
also 0 byte log if dumping the same p64 image.
To create such image download the latest version of VICE from here: https://mega.nz/folder/Xw8GiKxR#hl2BIeqgBwWYXRsILADDwQ
Then create an empty P64 image and then format it using the emulator:
open15,8,15,"n:empty,d1":close15
then try to convert it to g64 or dump it.
no joy :(
How did you test that?
I have done what you suggested. I got a p64 file from vice. micro64disktool converted it to g64 with the described problem.
Another problem is that nibconv cannot deal with that g64 file. That is because it has an uncommon but valid header. nibconv does not like every valid g64 file.
Well, no problem, there is my g64conv tool - it can handle such images.
BTW:
p64conv empry-vice.p64 empry-vice.p64.txt
g64conv empry-vice.p64.txt empry-vice.g64 sstd
using g64conv beta does convert the image without any bug - overriding speedzone detection with default speed zones. For standard disks, speed zone detection has no benefit.
thanks I didn't know about those two... will check immediately