RAM map: re-derive documented entries from code; JP check of unverified entries #17

New issue

Open

opened 2026-10-29 10:17:15 +00:00 by Gatchan · 0 comments

Gatchan commented

2026-10-29 10:17:15 +00:00

Owner

Follow-up of the RAM map slice 1 (refs #7).

About 90 entries have confidence = "documented": taken from the disassembly's notes/*-ram.txt, not re-derived from code. Each port that touches one should confirm it from the code (and fix it if wrong: four ff6rewrite names were already found wrong).
JP coverage: "same" was checked mechanically by tools/ram_map_check.py (equal .dbg label values, or equal counts of listing lines referencing the address). Four entries have no literal reference at all (jp_check = "unverified ...") and need a JP measurement or code read.

Not blocking; progress with the ports.

Follow-up of the RAM map slice 1 (refs #7). - About 90 entries have `confidence = "documented"`: taken from the disassembly's `notes/*-ram.txt`, not re-derived from code. Each port that touches one should confirm it from the code (and fix it if wrong: four ff6rewrite names were already found wrong). - JP coverage: "same" was checked mechanically by `tools/ram_map_check.py` (equal `.dbg` label values, or equal counts of listing lines referencing the address). Four entries have no literal reference at all (`jp_check = "unverified ..."`) and need a JP measurement or code read. Not blocking; progress with the ports.

Gatchan added the

task

labels

2026-10-29 10:17:15 +00:00

Gatchan referenced this issue from a commit

2026-10-29 10:20:20 +00:00

docs: RAM map slice 1 in re/ram_map.toml, format and decisions in docs/ram_map.md (refs #7)

Gatchan referenced this issue

2026-10-29 10:37:17 +00:00

RAM map slice 1, generated state accessors, peek/poke by name #18

Gatchan referenced this issue

2026-10-29 10:40:35 +00:00