The code that isn't the code

Found the custom read routine. It lives in the HELLO program — the autorun — loaded by DOS 3.3 from tracks 0–2. Set a breakpoint at the point where the HELLO program starts executing and let it rip.

The first 40 bytes of execution are not what’s on disk. The bytes at $0800 look like garbage when read from the image, but the emulator is executing valid 6502 opcodes. Something decoded them before we got here.

Stepped back. There’s a small bootstrap in the tail end of the DOS 3.3 loader area that runs before the HELLO program. It XORs the first 256 bytes of the HELLO program address range with a key byte — $A5 — before jumping to $0800. The encoded bytes on disk become valid 6502 when XOR’d.

The decoded code then calls the custom RWTS with the non-standard prologue byte, loads the remaining game tracks into memory, and before jumping to the game it overwrites itself with zeros. By the time you can examine memory interactively, every trace of the decoder is gone.

This explains why every nibble copier failed: they copied the disk successfully, but they copied the encoded HELLO program. When the copy’s loader decoded the first 256 bytes with $A5, it got garbage, and the machine hung.

To copy this disk you’d need to intercept execution after the decode step and dump the decoded program — which requires running the original disk, not copying it.

Key byte: $A5. Custom RWTS prologue: D5 AA AD. Loader self-destruct: confirmed.