Emulation, Archiving, and Disk Images
Preserving and emulating copy-protected C64 software is a problem that started in the 1990s and still isn't fully solved. The challenge is simple: most emulators and disk image formats were designed for data, not for the physical magnetic geometry that copy protection depends on.
The D64 Format — Useful but Incomplete
The D64 disk image format stores 35 tracks × up to 21 sectors × 256 bytes = at most 174,848 bytes. It represents the logical content of a disk — the data after CBM DOS has decoded it. D64 simply can't represent tracks 36–40, half-track data, non-standard bit rates, weak bits, custom GCR, long tracks, or sync mark signatures. A D64 image of a copy-protected game either contains the cracked (protection-stripped) version, or the image simply fails to load because the protection check can't find what it's looking for. The ZipCode distribution format (four files named 1!name through 4!name) is a compression layer on top of D64-equivalent logical data — same limitations, compressed for BBS transfer.
The NIB Format — First Raw GCR Standard
Before the G64 format was established, the standard output format of MNIB (Markus Brenner's parallel-cable nibbler) was the .NIB file. A NIB file stores each track as a fixed-length block of raw GCR bytes — typically 8192 bytes per track position, padded with sync data if the track is shorter. Unlike D64, NIB preserves the raw bit stream including sync marks, bad sectors, non-standard formats, and most signature tracks. NIB does not store density information per-track, which is a limitation compared to G64: NIB assumes each track was read at its standard zone density, which means non-standard-density tracks may be stored at the wrong rate. For most protections this is acceptable; for density-varying protections it is not.
NIB has been superseded by G64 for new captures, but it still matters — the bulk of the community's non-D64 archive was grabbed as NIB files during 2000–2010. The nibconv utility (part of NIBTools) converts NIB ↔ G64 ↔ D64 with protection-type awareness.
The G64 Format — Raw GCR Tracks
G64 stores raw GCR data on a per-track basis, including half-track data, up to 84 track positions, and variable track lengths. This handles most physical protection techniques — bad sectors, extra tracks, bit-rate variations, signature tracks, and long tracks are all representable. What G64 still can't encode: the absolute angular starting position of each track (needed for track skew checks), and true weak bits (which by definition must read differently every time).
Converting V-MAX! v3+ games to G64 was problematic precisely because the drive's 2 KB buffer wasn't sufficient to read the protected tracks without the extra RAM expansion. As Forrest noted in 1999, a modified "sixpacker" using the full 8 KB drive RAM was the theoretical solution — but no such public utility existed at the time.
Markus Brenner's Emulation Compatibility Analysis
At VCF East 3, Markus Brenner presented a comprehensive analysis of which protection types were handled by D64 vs G64 emulation versus not at all:
Hardware Devices for Physical Archiving
The modern C64 preservation community uses several hardware solutions to capture physical disks. The Catweasel ISA/PCI card (mentioned in the original 1999 comp.sys.cbm thread as an early emerging tool) was the first widely available device capable of reading raw magnetic flux from 5.25" disks. Modern equivalents are the Kryoflux and the GreaseWeazle.
Flux-level capture. A conventional nibbler — even hardware like Burst Nibbler with a parallel cable — still reads decoded bits: the 1541's own data separator decides whether each magnetic transition is a 1 or 0. Flux devices bypass the separator entirely. They measure the exact time in microseconds between every magnetic transition. The output isn't a stream of bits but a stream of transition timings. From those timings, any encoding scheme — GCR, MFM, FM, entirely custom formats — can be reconstructed in software, after the fact, without ever going back to the original disk.
Weak bits show up as a probabilistic spread of timing values (no two reads identical). Slowed-motor tracks have a characteristic compressed signature. Absolute angular position is preserved because the capture starts from a known reference — the index hole. Flux images are the only format from which a perfect physical duplicate can theoretically be written back to a blank disk.
The 1999-era community workflow (pre-Kryoflux): Burst Nibbler v1.4–v1.9 with a parallel cable was the preferred tool for making physical 1541-to-1541 copies of most protected disks. Burst Nibbler v1.9 required PAL hardware and did not run on NTSC machines, limiting its availability for American users. MNIB with an XP1541 parallel cable was the preferred tool for creating NIB/G64 image files. For V-MAX! v3+, only a RAMBoard-equipped 1541 running compatible software could make a true physical duplicate — standard 2 KB drive RAM was insufficient to buffer the long tracks.