Split out of #533. Sub-issue candidate for #509.
Why this is less speculative than it sounds
The repo already has a Jaguar ROM build path: make jaguar-demos-build drives lyxass/rmac against the pinned 42Bastian/JaguarDemos sources (test/jaguar-demos/run.sh build). So the assembler toolchain question — usually the blocker for 'let's write a test ROM' — is already answered.
What real titles cannot give us
Commercial and demo ROMs mix all five engines, so a measurement on one is always a blend. #520 hit this directly: the corpus split is GPU 47.2% / DSP 34.9%, and the DSP figure was initially misread as a 75% idle-poll loop purely because the census was taken during menus rather than gameplay. A workload you wrote has none of that ambiguity.
A microbenchmark ROM can guarantee properties no real title offers:
Scope sketch
- A small set (4-6) of
.s sources in-tree with a build rule, not vendored.
- One per engine: GPU arithmetic loop, GPU branch-heavy loop, DSP loop, blitter fill/copy throughput, 68K loop.
- Each prints or parks a known completion marker the harness can assert on.
- Committed
.j64 alongside source so CI needs no assembler (the JaguarDemos job already takes this approach — 'CI only runs .j64 files already committed').
Sequencing
Do #533's measurement of the ROMs we already have first. jagniccc.j64 and the JaguarDemos GPU-only carts may cover enough of this for free. This ticket is for the gap that remains after that — which is most likely the isolation and exact-termination properties, not raw coverage.
Parked in Icebox pending that answer; promote once #533 says what is actually missing.
Split out of #533. Sub-issue candidate for #509.
Why this is less speculative than it sounds
The repo already has a Jaguar ROM build path:
make jaguar-demos-builddrives lyxass/rmac against the pinned 42Bastian/JaguarDemos sources (test/jaguar-demos/run.sh build). So the assembler toolchain question — usually the blocker for 'let's write a test ROM' — is already answered.What real titles cannot give us
Commercial and demo ROMs mix all five engines, so a measurement on one is always a blend. #520 hit this directly: the corpus split is GPU 47.2% / DSP 34.9%, and the DSP figure was initially misread as a 75% idle-poll loop purely because the census was taken during menus rather than gameplay. A workload you wrote has none of that ambiguity.
A microbenchmark ROM can guarantee properties no real title offers:
move/addvs one that is branch-heavy, to test dispatch-vs-body hypotheses ([perf] Hoist loop-invariant globals out of the GPU interpreter loop #532) directly instead of inferring them from a census.--pressscripting needed.Scope sketch
.ssources in-tree with a build rule, not vendored..j64alongside source so CI needs no assembler (the JaguarDemos job already takes this approach — 'CI only runs .j64 files already committed').Sequencing
Do #533's measurement of the ROMs we already have first.
jagniccc.j64and the JaguarDemos GPU-only carts may cover enough of this for free. This ticket is for the gap that remains after that — which is most likely the isolation and exact-termination properties, not raw coverage.Parked in Icebox pending that answer; promote once #533 says what is actually missing.