01-22-2018, 09:43 AM
(This post was last modified: 01-22-2018, 12:46 PM by Jackson.
Edit Reason: Fixed file opening errors.
)
"Yes, but I want MFM, not GCR - these are for Kaypro SSDD 48tpi CP/M."
The file is completely flux transitions. Disk types are minor details for emulators and file readers to use. You can archive these as C64 disks and get along with your day. HxC has autodetection where it can tell the encoding directly from the flux, so MFM streams will get decoded correctly regardless of disk type. However, HxC will not read the tracks correctly nor export them correctly to raw sector images because archived C64 SCP files tracks store twice the amount of tracks and have byte 0x0A (head count) set to zero to account for both heads, which are stored regardless of whether one head is used or not.
HxC's implementation parses this in a broken manner where 80 tracks, 40 of which are duplicates, are all stored on one head. You might be better off trying to dump these as IBM PC 360k disks, but I'm not sure how that fares when importing and exporting them that way in HxC either.
For my SSDD DOS 1.x/2.x disks, reading the raw sector export correctly from a C64 image requires making a new file which has every odd numbered 4096 byte chunk from the original. I have written a small tool to aid me in this situation: https://pastebin.com/zTp7yj3U
You can adjust the HUNK_SIZE define as well if the pattern of repeated bytes is bigger or smaller, i.e. 1024 bytes.
The file is completely flux transitions. Disk types are minor details for emulators and file readers to use. You can archive these as C64 disks and get along with your day. HxC has autodetection where it can tell the encoding directly from the flux, so MFM streams will get decoded correctly regardless of disk type. However, HxC will not read the tracks correctly nor export them correctly to raw sector images because archived C64 SCP files tracks store twice the amount of tracks and have byte 0x0A (head count) set to zero to account for both heads, which are stored regardless of whether one head is used or not.
HxC's implementation parses this in a broken manner where 80 tracks, 40 of which are duplicates, are all stored on one head. You might be better off trying to dump these as IBM PC 360k disks, but I'm not sure how that fares when importing and exporting them that way in HxC either.
For my SSDD DOS 1.x/2.x disks, reading the raw sector export correctly from a C64 image requires making a new file which has every odd numbered 4096 byte chunk from the original. I have written a small tool to aid me in this situation: https://pastebin.com/zTp7yj3U
You can adjust the HUNK_SIZE define as well if the pattern of repeated bytes is bigger or smaller, i.e. 1024 bytes.