Emulation, Archiving, and Disk Images
Preserving and emulating copy-protected C64 software is a problem that started in the 1990s and hasn't been fully solved even now. The challenge: most emulators and disk image formats were designed for data, not for the physical magnetic geometry on which copy protection depends.
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.
What "flux-level" capture means. A conventional nibbler — even a hardware one like Burst Nibbler with a parallel cable — still reads decoded bits: the 1541's own data separator hardware decides whether each magnetic transition represents a 1 or a 0, and that's what gets transferred to the PC. Flux-level devices bypass the data separator entirely. They measure the exact time in microseconds between every magnetic transition on the disk surface. The result is not a stream of bits but a stream of transition timing values. From this timing data, every possible interpretation of the disk — GCR, MFM, FM, even completely custom formats — can be reconstructed in software, after the fact, without ever going back to the original disk.
This means flux captures handle everything that byte-level tools cannot: true weak bits appear as a probabilistic spread of transition timings (no two reads are the same); slowed-motor tracks show their characteristic compressed timing signature; absolute angular position is preserved because the capture starts from a known reference point (the index hole). Flux images are the only format from which a perfect physical duplicate can theoretically be written back to a blank disk — assuming a drive and write hardware that can reproduce arbitrary flux timings. These have become the gold standard for long-term preservation.
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.