CP/M 2.23 Disk-Sector Map

This is a comprehensive map of every physical sector in the 140 KB CP/M 2.23 SoftCard disk image (CPMV233.DSK). For each of the 35 × 16 = 560 sectors, the table shows:

• First 8 bytes — a quick signature for identification
• Role — what the sector does in the boot sequence (boot stub iteration, LOAD_CPM call, unused, filesystem area, etc.)
• Final Apple address — where the bytes end up in Apple ][ memory after the loader runs (or “not loaded” / “deferred” for sectors not touched by the boot pipeline)

The full 560-row table is too long for inline embedding here. The map lives in the Orchard repository at docs/CPM_DiskSectorMap.md.

What the map tells you

Knowing which sector ends up at which address lets you:

• Read code in the place it executes, even before boot. If you want to disassemble what runs at Apple $0A00 after PREP_HANDOFF, the map points to track 2 sector $02 (= staging $9700, which the second PREP_HANDOFF copy moves to Apple $0A00).
• Identify “missing” code. Several sectors of track 2 ($08-$0B) are entirely zero on disk. Those address ranges in the runtime BIOS are populated by the cold-boot code generator, not from disk. The map flags those sectors explicitly.
• Understand which sectors are CP/M files. Tracks 3-34 are the CP/M filesystem area, accessed once CP/M reaches A> and the user issues DIR. They aren’t part of the boot pipeline.

How sectors map to file offsets

The .DSK file stores sectors in DOS 3.3 logical order (not physical). The file offset for physical sector (track, sector) is:

file_offset = (track * 16 + DOS33_INTERLEAVE[sector]) * 256

where DOS33_INTERLEAVE is the 16-entry table [0, 7, $E, 6, $D, 5, $C, 4, $B, 3, $A, 2, 9, 1, 8, $F].

For a .po (ProDOS-order) image, replace DOS33_INTERLEAVE with the ProDOS interleave. Both 2.20 (.po) and 2.23 (.dsk) follow the same physical-sector LOAD_CPM pattern; only the file-offset arithmetic differs.

How the map is generated

A Python script at cpm-investigation/sector_map.py reads the .DSK file, applies the interleave to extract each physical sector, classifies its role using the boot-sequence findings documented across the cpm-videx article series, and emits the Markdown table. Re-running the script against any future-discovered LOAD_CPM behavior or sector usage updates the map without manual editing.

What’s settled and what’s deferred

The map is settled for tracks 0-2 (the boot pipeline) and tracks 3-34 (the CP/M filesystem area at the file-system level — not byte-by-byte). Within track 2, sectors $08-$0B are confirmed all-zero on disk; sectors $0C-$0F are flagged “deferred / not loaded by stage-2,” meaning a possible second LOAD_CPM call (post-handoff) might read them. Verifying which tracks the post-handoff loader touches is a future extension.

Companion documentation

• The cpm-videx article series — narrative explanation of the boot pipeline this map is derived from
• The cpm-videx dev log — chronological investigation entries, including dead ends and corrections
• Apple II Technical Note Misc #8 — the Pascal firmware protocol that triggered this whole investigation