You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: AI/TESTING.md
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -94,6 +94,10 @@ This checklist should move only when one of the following becomes true:
94
94
## External ROM harness policy
95
95
96
96
- Test ROM execution must be automatable; manual inspection of the LCD is an auxiliary debugging aid, not the primary acceptance path.
97
+
- When working on already-known external ROM failures, timing regressions, or exploratory PPU/MMIO fixes, always preserve a baseline snapshot of `/.roms/test/test-report.md` before making the validation run, preserve the final report again after the run, and compare the two before deciding whether the iteration is worth keeping.
98
+
- That baseline/final comparison is mandatory for go/no-go decisions on exploratory ROM-driven work. Save the raw markdown report first; also save a rendered image of the report when practical so visual status drift is easy to review later.
99
+
- If the current tree is not already a clean baseline, compare against a clean reference such as `main` in a separate branch or worktree rather than hand-waving the previous state from memory.
100
+
- Do not summarize a ROM-driven iteration as "no regressions" unless the before/after report comparison has been done explicitly and the changed rows have been named.
97
101
- The harness should support at least framebuffer capture and serial / link-port capture when the ROM exposes machine-readable output there.
98
102
- When an external suite prints self-validating text through a documented screen-console protocol, the harness should also support a typed text-extraction path for that protocol rather than falling back to a circular framebuffer fixture generated by this project.
99
103
- Prefer serial / link-port capture for suites such as Blargg `cpu_instrs` when that path is available, because it avoids treating a scrolling framebuffer as the primary machine-readable result channel.
Copy file name to clipboardExpand all lines: AI/hardware/PPU.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -107,6 +107,7 @@ For this project, the PPU should be modeled dot-by-dot, where `1 dot = 1 T-cycle
107
107
-`stat_mode1_enable && mode == 1`
108
108
-`stat_mode2_enable && mode == 2`
109
109
-`stat_lyc_enable && ly == lyc`
110
+
- In the current DMG-family baseline, the Mode `2` STAT enable should also request LCD STAT at the exact VBlank-entry transition on line `144`, but it should not be treated as a continuously active source for the rest of VBlank.
110
111
- LCD STAT interrupt requests should be emitted only on a rising edge of that internal line, not merely because one contributing condition is true.
111
112
- STAT blocking should be preserved: if one enabled source keeps the internal line high while another source becomes true, no new LCD STAT interrupt should be requested until the line first drops low and rises again.
112
113
- Mode `3` must not be treated as a direct STAT interrupt source.
Copy file name to clipboardExpand all lines: AI/index.md
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,6 +2,10 @@
2
2
3
3
Read the matching file directly; this index is a routing guide plus a summary of document authority boundaries, but detailed behavioral rules still live in the owning file.
4
4
5
+
## Mandatory external-ROM regression workflow
6
+
7
+
When working on already-known external ROM failures or rerunning curated ROM suites to evaluate a timing-sensitive change, always capture a baseline copy of `/.roms/test/test-report.md` before the work, capture the final report again after the run, and compare the two before deciding whether the change is worth keeping. Treat that before/after report-delta check as mandatory, not optional; see `TESTING.md` for the authoritative workflow details.
8
+
5
9
## Global docs
6
10
7
11
-`ARCHITECTURE.md`: project goals, crate layout, subsystem boundaries, and portability rules.
0 commit comments