Zirias
commented
5 years ago Hi, I didn't see this message any sooner, as wasn't online for a long time. For point a, this is probably a feature request -- right now, you cannot have anything marked unused that is actually used. This was by design, because such a disk is very prone to accidental destruction and mkd64 was intended to master your own disks for your own software in your build process ;) Nevertheless, if there is a need to create such disks, it can be added.
As for point b, I really wonder why this is the case? The extra tracks module supports the two common formats (SpeedDos and DolphinDos) and I expected both to be properly recognized by DirMaster. Are you sure you used the '-X' option of xtracks, and you used it correctly (after loading the cbmdos module)? See 'mkd64 -h xtracks'.
Finally, depending on how exactly the copy protection works -- mkd64 will never be able to write on the physical level (e.g. intentionally erroneous GCR encoding). Just mentioning this because you're talking about a .G64 raw image :)
mrdudz
Fantastic tool; I'm doing a disassembly of C64 Elite and I'd like to be able to rebuild an exact byte-for-byte D64 image from the source to be able to spot mistakes immediately -- I need to be able to repack the files on the D64 as they were on the original including oddities designed for copy-protection.
The disk I'm using, if you want to compare is "elitefirebird_1986(v040486).g64" (converted to D64).
There are few limitations of mkd64 that prevent rebuilding this disk image:
The disc's BAM is shown as completely free ("8670 blocks free"). I'd need a way to exclude files from adding to the BAM and/or commands to alter the BAM as desired
The copy-protection relies on the existence of a track header on track 37, but within DirMaster the disk does not show as having extra tracks (they are actually there, just not recognised in the way it understands) -- how do I add extra tracks, without including them in the BAM? (as above)