Block 5 census (stage 5.0)

How the exact model's ARM9 waits, polls and is interrupted, per logical frame, measured with the 5.0 oracle recorder. It decides how much of 5.3 (OS time/IRQ scheduler) and 5.4 (budget removal) is mechanical.

How it was measured

• Build: branch b5-harness (Block 4 head + the 5.0 probe), fiber mode, exact hardware model.
• Run: acceptance rom.nds route.csv OUT 15000 --record REC, the reference route: boot, menus (frames 0–2279), one 3-lap race (finish at frame 11,462 in 1st), results. Menus beyond the route, battle and mission are not covered yet; rerun the same command with other input scripts (--replay inputs.csv) to extend it.
• Logical frame = the SDK V-blank count (OS_GetVBlankCount, 0x027FFC3C, incremented by the ARM7's OS V-blank handler 0x037F86AC). One sample per logical frame when the ARM9 takes the V-blank IRQ.
• Counters come from ds_mem::Probe (off by default): IRQs taken (IE & IF bits at entry; one IRQ can count for several sources), ARM9 reads of polled registers, ARM9 wait entries (Machine::wait_hook), and runs of consecutive slices ending within 64 bytes of one pc ("tight loops", > 1,000 instructions).
• Summary script: python census.py REC dictionary (scratch; reads census.csv / spins.csv).

Results (12,343 logical frames, V-blank count 0..12,361)

Tight loops over 1,000 instructions

35,418 runs at 94 pcs (157 M instructions, 9% of the run; 13,710 runs before frame 2,280, 21,708 after). Top sites:

What this means for 5.3 / 5.4

• Time is consumed by waiting in one place. The game never polls VCOUNT and never uses SWI 5/4/6 in its loop: every frame ends in OS_WaitIrq (thread sleep) and the idle thread's CP15 halt. 5.3 can turn "wait for the next V-blank" into an event jump in that one place; per-site work is not needed for frame pacing.
• IRQ sources to schedule natively: V-blank (1/frame), timer 1 = OS alarms (~8/frame), timer 0 = tick overflow (rare), IPC receive (~5/frame, from the ARM7 / hle7), DMA end (~32/frame) and GX FIFO (loading only). No H-blank, V-count, card, keypad or IPC-sync IRQs at run time. DMA-end and alarm IRQs are the ones to model as immediate events.
• Tick reads: ~28 OS_GetTick reads per frame. Under 5.3 these values change; expect masked differences in tick-derived fields only (the 5.0 tick perturbation test found them at 0x022CC610..0x022CC630, 0x023D9700..0x023D9800 and in DTCM, then a further difference 613 frames later in 0x02170000..; see the test below), so each of those needs a reason in the mask.
• Busy-waits: only the boot PXI_Init handshake (IPCSYNC, 1.2 M instructions) and a few display waits during loading. The card driver polls the data port while reading (5.1 removes it with native FS). The other long loops are copies, fills and computation, not waits: removing the budget (5.4) does not need per-site changes for them.
• Lag: 19 lag frames, all during loading; the race loop is lag-free in the exact model, so logical frames line up 1:1 with V-blanks there.

Oracle self-test (5.0 done-check)

• Exact vs exact open-loop replay of the reference inputs: EQUAL, 12,045 logical frames, every region, 71,326 PXI events. The open-loop replay also matches the closed-loop recording in every common frame (it reproduces the reference race, finish at frame 11,462).
• Flat-mode recording vs fiber-mode recording: EQUAL.
• MKDS_ORACLE_POKE=5000:0x0236D9AC:... (kart 0 x position): first difference frame 5000, regions kart0 main_02360000.
• MKDS_ORACLE_TICK=3000:1 (TM0CNT_L + 1, i.e. OS_GetTick + 1 from frame 3000): first difference frame 3001 (the first sample after the change), regions dtcm main_022c0000 main_023d0000. With those three masked (by range or by region) the first difference moves to frame 3,614 (main_02170000).

Wider census: battle, mission, menus (lane b5-finish, 2026-10-28)

Same recorder, exact model (MKDS_HW_* unset), open-loop replays of input scripts written for this purpose (4_docs/inputs/{battle,mission,menus}.csv, generated by 4_docs/inputs/mkscript.py; button rows only):

• battle: Single Player → Battle → Balloon Battle, Mario, default settings, stage "Nintendo DS", 7 CPU karts; driving (A held, weaving, items) from logical frame 3000; 6,500 frames.
• mission: Single Player → Missions → Level 1 → Mission 1-1 (drive through 5 gates, 35 s; the script fails it); driving from frame 1900; 4,800 frames.
• menus: title, nickname / emblem prompts, Records (+ the empty friend-roster dialog), Options (+ the erase-data dialog, answered No), mode select, VS character select, mission level select; 3,400 frames. (Selecting Nintendo WFC stalls the exact model's V-blank count — wireless is out of scope — so the walk avoids it.)

Tight loops: no new waits. The new long loops are compute: battle analyses the microphone buffer every frame (mic_detect_blow_level 0x0201EC30, up to 16 K instructions per run; it reads a buffer, it does not wait on the ARM7), and loading decompression / fills / CRC as before. PXI MIC (tag 9) words: none on any route; the battle's mic analysis works on the auto-sampling buffer.

What changes for 5.3 / 5.4: nothing new. Every mode ends its frames in the OS idle thread's CP15 halt; no mode reads VCOUNT, TM1–3 or DISPSTAT after boot, and no mode uses H-blank / V-count IRQs. Plan 5.4 condition 2 holds in all four routes. The one new fact is lag: the exact model overruns frames during balloon battle on the "Nintendo DS" stage (111 lag frames, about one in 40 during play), so battle cannot be equal per logical frame to a lag-free native run (see BLOCK5_DEFAULTS.md).