re8 console — high-level technical specification

Document purpose. This is the normative specification of the re8 console: a boutique 2D games machine built from currently-manufactured parts, comprising a W65C02S CPU and a single custom ASIC (oito) that integrates the video display processor, a 16-voice audio unit, the cartridge mapper and all system glue.

It defines everything an implementer needs to build the hardware or a Tier 1 (compatibility) reference emulator (§14.5): machine-visible behaviour, electrical interfaces and bill of materials, timing, file and tool ABI, and the conformance contract.

Version 0.23.1 · 2026-07-30 · architecture draft. Revision history and the versioning rules are in §18.

Document map. This specification is normative; rationale and history live in re8-design-history.md.

Diagrams accompanying this document are in diagrams/ and are referenced from the sections they illustrate.

Requirement keywords. MUST, MUST NOT, SHOULD and MAY are used in the RFC 2119 sense and only for requirements; all other prose is descriptive and carries no obligation. Performance figures carry either a stated workload or the label estimate; no cross-machine comparisons are made.

Scope.

• In scope: all active components (BOM), console capabilities and restrictions, how active elements operate and interconnect (including pin/signal mapping and voltage domains), memory map, interrupts, debug-probe operation, SDK and tooling ABI, and the conformance contract. Analog video and audio buffering is in scope — buffers and line drivers are active components.
• Out of scope: PCB layout, ASIC internals (gate/RTL level), mechanical/enclosure design, production economics, and passive component values except where a value is required to define or substantiate an electrical-interface, safety or timing claim. Final passive selections live in the schematic/BOM evidence.

Status (2026-07-30): architecture draft. The memory map, register file, subsystem behaviour and BOM are specified to a level intended to support emulator implementation and schematic capture. The design has been through twenty-two adversarial reviews; every finding is dispositioned and the resulting changes are in this document, but validation remains open — a disposition is not closure. The items in §16.2 are the gap between the two. The decision log and review registers live in re8-design-history.md.

Explicitly outstanding across compatibility, SDK, schematic, RTL/tapeout, prototype and production-release gates (full criteria and stages in §16.2):

This list is complete and generated from §16.2 — tools-verify.py requires the same 18 entries in the same order and rejects missing, extra or duplicated rows. The ASRC filter design appears once here; §16.2.1 records that gate's deferral rather than creating a second gate.

1. System overview

re8 is a boutique 2D game console built exclusively from currently-manufactured ("factory-fresh") components — no New Old Stock. Its architecture deliberately sits between the 8-bit era (NES, Master System, PC Engine) and early-90s arcade hardware (Capcom CPS-1):

• CPU: WDC W65C02S, 8-bit, fully static CMOS, single 3.3V rail.
• oito: one custom ASIC (SkyWater 130nm, LQFP-176, custom pad ring) combining a Video Display Processor (hybrid tile renderer + mini-blitter, hardware sprites, hardware collision) and a 16-voice APU (PSG + wavetable + PCM).
• Memory: 16KB system SRAM (CPU bus) + 128KB VRAM (private bus to oito).
• Media: parallel NOR flash cartridges, 37-pin edge connector, console-side fixed-plus-switchable 16KB mapper; optional battery-free on-cart FRAM saves (§11.4).
• Video out: one digital pipeline (12-bit RGB + syncs from oito) fanned out to five simultaneous outputs: composite, S-Video, RGB SCART, 15 kHz analog RGBHV on DE-15 (not VGA timing), and 1080p60 HDMI with embedded 48 kHz stereo audio.
• Input: two DB9 ports, Sega Genesis/Mega Drive controller compatible; optional PS/2 keyboard and mouse through a port via a passive adaptor (§9.1/§9.2), the mouse with a fully hardware-rendered cursor.
• Developer hardware: 42-pin expansion header (CPU bus + oito JTAG) driving a USB debug probe.
• SDK: prog8 language → 64tass → flat ROM binary; re8.* event-driven library; VS Code extension with source-level debugging, VRAM inspector, and a WASM reference emulator.

Core philosophy.

1. Zero-emulation: real silicon executes game code; no soft-cores or interpretation layers.
2. No NOS: every part must be orderable new (this single rule drove the CPU, sound, video-encoder and flash choices).
3. First-time-right silicon: oito is 100% digital; every analog function (video encoding, DACs, audio filtering) lives on the motherboard in proven off-the-shelf parts, because analog blocks on a low-volume ASIC are hard to verify and risky.
4. ROM is cheap, RAM is precious: the SDK trades ROM space freely to preserve the 16KB RAM budget.

2. Bill of materials — active components

Notes:

• SRAM timing margin: at 7.159 MHz the CPU cycle is 139.7 ns with roughly half available for the access, so a 10 ns SRAM has enormous margin and even a 55 ns part meets timing — stated because it widens the sourcing pool considerably. The VRAM bus runs at 21.477 MHz (46.6 ns/cycle), where a 10 ns part leaves ≈36 ns of margin.
• The 16KB system-RAM limit is a design limit, not a component limit, and the decode is written as an equation because prose got it wrong: "RAM_CĒ ignores A14" would have meant A14 does not participate in chip select, mirroring RAM across $4000–$7FFF and colliding with oito's own register file. The actual decode is

RAM_CĒ = !( !A15 && !A14 && bus_cycle_valid ) ; asserts only for $0000–$3FFF

bus_cycle_valid is the owner-aware term of §11, and it replaces the cpu_memory_cycle an earlier revision used here. That term was never defined and was CPU-specific, so read literally it deasserted RAM_CĒ whenever BE was low — which is exactly when OAM DMA reads its source block from system RAM and when the probe's live-memory access reads or writes it. Neither feature could have reached its own documented storage. The complete decode for both motherboard memories is in §11, not here.

The SRAM's A14, A15 and A16 are hard-strapped to GND at the footprint, so only its lowest 16 KB is ever addressed. There is no future-expansion path without a board change: enabling more RAM would need both a different decode in oito and those three pins routed instead of strapped.

• Rail budget: each SRAM draws roughly ~30 mA active / <5 mA standby, included in the 3.3V budget alongside the probe allowance.
• The motherboard also carries R-2R resistor-ladder DACs (passive, out of scope) that convert oito's digital RGB to analog RGB, buffered per destination for SCART / DE-15 / AD725 (§7).
• Controllers themselves contain a 74HC157 multiplexer (3-button pads) powered at 5V from DB9 pin 5.
• Two flash families, in two places that never mix. The boot flash is SST39VF010 and uses the SST unlock sequence at $5555/$2AAA; cartridges are always Macronix and use the AMD-style sequence at $AAA/$555. The two drivers are selected by which device is being programmed, which the updater always knows, so no header field is needed and none exists.
• PS/2 keyboard/mouse adaptor (passive accessory, not in console) — a wiring-only DB9↔mini-DIN-6 adaptor (no MCU), serving keyboard and mouse alike (§9.1/§9.2); on the two PS/2-capable data lines per port the console adds ~4.7kΩ pull-ups + an open-drain driver (bidirectional PS/2, for mouse-enable and keyboard LEDs).

2.1 Power tree, reset & protection

A single 3.3V rail was never feasible — the design has always needed 5V (AD725, controllers) and 1.8V (oito core); the CH7035B needs 1.8V and 3.3V domains. So the board is multi-rail. What survives is the digital core: CPU + oito + all SRAM/flash + glue share one 3.3V rail (no level shifters in the CPU/memory domain — the original benefit). The extra rails serve only the analog/video/core-voltage parts, which is normal.

Input: 12V DC barrel jack, ≥1.5A recommended (typical board draw ~3–5W, to be confirmed by measurement/synthesis). Protection: series reverse-polarity FET (or Schottky), an input fuse that is not yet selected (§16.2), and a TVS on the jack. The "no polyfuses" rule of §2.1 applies to the protected output rails, where electronic switches replaced them; one input-side device upstream of everything remains, because there is no rail to switch there.

No part is named, deliberately. A previous revision named 0ZCJ0150FF2E, which does not exist — the nearest real member of that series is 0ZCJ0150FF2C, and its V_max is 8 V, unusable in series with a 12 V adapter. It was placed in the parts ledger with a family landing page as its source and a date that recorded no actual reading. Rather than guess a third time, the selection criteria are stated and the part is left open:

The reverse-polarity topology (series FET versus Schottky) and the jack TVS OPN and polarity are unselected on the same terms.

12V rather than 9V because SCART pin 8 requires 9.5–12V to signal 4:3 (§7). A 9V input cannot produce a voltage above itself, so aspect signalling would have been unimplementable or would have needed a boost converter. 12V/1.5A supplies are at least as common as 9V ones and give the 5V buck more headroom.

Rails:

(A single multi-output PMIC could consolidate the bucks/LDOs to save board area — an implementation option.)

Sequencing & reset. A dedicated voltage-supervisor / reset controller holds CPU RES̄, oito RES̄ and CH7035B RESETB asserted until every rail is up and stable (plus a settle delay), and re-asserts on brownout.

• CH7035B requirements: stable power for ≥20 ms before RESETB release, plus a ≥100 µs asserted pulse.
• Ordering constraint: the scaler self-boots from its configuration EEPROM at reset release (§7.1), so the EEPROM MUST be powered and stable before RESETB is released — otherwise it boots a blank configuration.
• Rail order: core 1.8V comes up before or with I/O 3.3V, per oito's requirement. oito may additionally hold its own core in reset via an internal power-on reset, but the system reset is driven by the supervisor.
• RES̄ is also exposed on the expansion header (§12).

Per-output current limiting — one implementation each. Every 5 V and 3.3 V output that leaves the board is protected by an electronic switch with a stated setting:

There are no polyfuses on the output rails. An electronic switch was chosen over a polyfuse on every rail because it limits rather than merely trips, recovers on a power cycle instead of after a cool-down, and has a defined inrush behaviour — three properties a polyfuse does not offer. The exact orderable part is TPS2553DBVR-1: TI orders the suffix device, package/carrier, then fault behaviour, so the trailing -1 is the latch-off variant, and TPS2553DBVR without the trailing -1 is the constant-current part that keeps regulating into a fault and may thermal-cycle. A latched part stays off until EN is toggled or input power is cycled; it does not periodically retry. TPS2553-1 is used as family shorthand in prose, TPS2553DBVR-1 wherever an orderable number is meant. All four R_ILIM values must be re-derived from the datasheet's minimum and maximum equations including resistor tolerance before schematic freeze (§16.2); the numbers above are nominal-table values, and that arithmetic was already got wrong once.

Controller-port draw. Typical: 3-button pad <5 mA, 6-button pad <10 mA, PS/2 mouse 20–50 mA, PS/2 keyboard 100–150 mA.

• Budget: 250 mA per port, 350 mA total across both — simultaneous maximum draw on both ports is not a design case.
• Protection: the per-port TPS2553-1 above, limiting at ≈500 mA against a 250 mA budget — the two numbers are deliberately different.
• Connector: the DB9 contact rating (~3 A) is never the limit; the current-limit switch and the PCB trace are.
• Short-circuit: the switch current-limits and then latches off, that port collapses, the console keeps running, and recovery is by power-cycle. This is explicitly not a hot-swap-safe design.
• Inrush: keyboards with bulk capacitance draw a brief surge, so the 5V buck needs headroom or soft-start (bring-up item).
• Out of scope: backlit or hub keyboards, unpowered USB hubs, and USB-style high-power devices via passive adaptors are not supported.

Connector protection, per pin. Assigning a protection part "by connector" is unsafe when one connector carries several voltage classes — SCART pin 8 is deliberately driven at 9.5–12 V, far outside a low-voltage array's working range, and clamping it would have shorted the aspect signal to ground.

Thermal: ~3–5W is passively cooled (no fan); the buck regulators and CH7035B want small copper pours and thermal vias.

Emulator note: power/reset is board-level and does not affect emulation; captured here for BOM correctness and to retire the "all-3.3V" misconception.

3. Clocks and frame timing

Emulator-relevant derived facts: CPU runs at exactly master/3, so 455 CPU cycles per scanline and 119,210 per frame. VBLANK ≈ 17,290 CPU cycles (~2.4ms).

Determinism caveat. Those figures are an exact bus budget, not a guaranteed instruction budget: three mechanisms stall the CPU with RDY and reduce the cycles actually available to code — the CPU VRAM port under contention (§6.5), OAM DMA (§5.1), and PCM sample fetch (§8.3, ~3–6% when four voices stream). The line/frame timing remains exact and deterministic; the CPU's work per line varies with those stalls. Cycle-exact raster code should account for them or suspend PCM (§14.2). The exact line-total/porch/sync timing and the 60.00-vs-59.94 selection are a separate video-timing item needed only for a cycle-accurate emulator; the baseline above is sufficient to run software.

4. CPU subsystem (W65C02S)

Choice rationale. By 2026 the W65C02S and W65C816S are the only classic-bus CPUs still in production: Z80 survives only as the bus-incompatible eZ80; 68000 only as ColdFire. The 65C816 was evaluated and rejected on pin count and toolchain complexity. With LQFP-176 an 816's extra host lines would fit, so the W65C02S choice rests on the remaining reasons: a simpler 8-bit bus matching the SDK's memory model, and the fully static core that is the foundation of the debug strategy (clock to 0 Hz with full state retention). Revisiting the CPU is not proposed here. (Calling the W65C02S "the last standalone classic-bus CPU" is inaccurate — the W65C816S is also in production.)

Electrical/operating decisions:

• Runs at 3.3V specifically so no level shifters are needed between CPU, oito, SRAM and flash (all 3.3V). 3.3V operation derates the max clock from 14MHz (5V) to 8MHz (WDC AC characteristics).
• Clocked at master ÷ 3 = 7.159 MHz (§3, PINNED): synchronous to oito for determinism, ~12% below the 8MHz rating for timing margin.
• Performance at 7.16MHz: ~1.8–2.7 MIPS — arithmetic from cycle counts (2–4 cycles/instruction), not a benchmark. Cross-machine comparisons are deliberately not made here.

Signals used by the system (pin mapping):

Standard 6502 conventions apply: zero page $0000–$00FF, hardware stack $0100–$01FF, vectors at $FFFA–$FFFF (reset $FFFC/D, IRQ/BRK $FFFE/F).

Control-line termination. The modern W65C02S has no internal pull-up on RDY, and RDY is bidirectional because WAI drives it low. re8 has three parties on that line (CPU via WAI, oito for VRAM/OAM-DMA/PCM stalls, probe for breakpoints), so termination must be specified rather than assumed. "Unused" is a design statement, not an electrical connection — every unused input MUST be terminated.

Implementation constraint: oito's RDY and BE pads are open-drain outputs, not push-pull (recorded for the pad-ring table, §6.3).

Note: an early section of the debug-probe design referenced a "HALT̄" pin; the later, corrected design uses RDY/BE/SYNC (the W65C02S has no HALT pin). The RDY/BE/SYNC version is normative.

5. Memory map

Canonical CPU address space (final iteration):

5.0 Zero-page allocation

Nothing in oito or the CPU decodes zero page — $0000–$00FF is ordinary system SRAM. The source re8-base.properties comment calling $0000–$001F "reserved for internal chip logic" was a misnomer; it is a software convention: the re8 runtime and prog8 boot stub reserve these 32 bytes for fast (single-byte-address) variables, and prog8's allocator is told to start user/compiler variables at $0020 (zeropage_start=0020). For an emulator this needs no special handling — it is plain RAM.

Runtime reservation $0000–$001F (illustrative; finalized when the library is written):

$0020–$007F = prog8 compiler zero-page variables (96 bytes). $0080–$00FF = free zero page (128 bytes) for hand-assigned fast variables. A pure bare-metal program that does not link the re8 runtime may reclaim $0000–$001F.

System RAM budget. The compile-time overflow check (§14.1) is only meaningful if every consumer of the 16 KB is declared. Several were added after that promise was written — notably the 1 KB shadow-OAM buffer that the shadow-OAM design makes mandatory — so the real figure is published here:

• SDK regions are declared to the build, so the linker/map fails on overlap rather than silently colliding, and the memory-allocation meter (§14.3) reports against the real remainder, not the gross 16 KB.
• The shadow-OAM kilobyte is reclaimed automatically by dead-code elimination when a game never links re8.sprites.

5.1 oito register map

The window $4000–$40FF is the register file (low 8 bits decode the register); $4FFF is the deliberately-isolated Ghost Debug Port. Everything unmapped follows the single rule below. All multi-byte fields are little-endian. R = read-only, W = write-only, R/W = both. Unlisted addresses read $00 and ignore writes — see the unmapped-access table below.

Base-register width. Every "2KB units" base register (BG0/BG1_MAP_BASE, BG0/BG1_PAT_BASE, OAM_BASE, SPR_PAT_BASE, TEXT_MAP_BASE) is 8-bit but VRAM is 128KB = 64 × 2KB, so only bits 0–5 are significant; bits 6–7 are not wired — ignored on write, read back as 0. Bases therefore always land inside VRAM (no undefined aliasing), and hardware and emulator agree by construction. CURSOR_TILE_LO/HI is a 12-bit tile index (matching the name-table/OAM index width, §6.6); its VRAM byte address is index × 32.

Design conventions. The CPU never touches VRAM or palette RAM directly — both are reached through auto-incrementing address/data ports. OAM (sprite attributes) and name-tables live in VRAM; a small dedicated palette RAM (64×12-bit) lives inside oito and has its own port. IRQ status bits are write-1-to-clear.

Block layout ($40xx):

System / video / IRQ ($4000–$400F):

Background scroll ($4010–$401F):

Blitter ($4020–$402F) — operates VRAM→VRAM on the private bus (never touches the CPU bus):

Collision ($4030–$403F):

VRAM access port ($4040–$404F) interface:

VRAM port semantics. This is the CPU's only path to VRAM, so its behaviour is pinned rather than sketched:

• Stride values as tabulated above — chosen to match the data structures: 2 = a name-table cell, 4 = one 4bpp tile row, 8 = an OAM entry, 32 = a whole tile, 128 = a name-table row (64 cells × 2 B).
• When VRAM_CTRL.0 is 1, every successful access — read or write — post-increments the pointer exactly once, after the transfer, by the selected stride and direction; reads and writes behave identically. When it is 0 the pointer never changes. That is the reset state, so software must set the bit before relying on auto-increment — the bit is functional, not decorative.
• Reads are true reads: there is no prefetch/read-buffer. VRAM_DATA returns the content at the current pointer, not a previously latched byte. Stated explicitly because NES-style VRAM ports do use a read buffer, and an implementer steeped in that would otherwise guess wrong.
• The pointer wraps modulo 128 KB (17 bits), consistent with the blitter and base-register arithmetic.
• VRAM_ADDR2 bits 1–7 are ignored (only bit 0 is A16) and read back 0.
• Pointer registers are latched when an access begins, so writing them while an access is RDY-stalled cannot redirect the in-flight transfer; the stalled access completes at its original address.
• Back-to-back accesses arbitrate independently (§6.5), so a burst may stall per byte during active display.

Palette access port ($4050–$405F) — dedicated internal 64×12-bit palette RAM:

Palette port semantics.

• Increment happens only on a PAL_DATA_HI write, and wraps 63 → 0, so the LO/HI pair is the natural unit and a stray LO write cannot desynchronise the index. Reads never increment, so a game may read an entry back without disturbing the pointer.
• LO and HI are independently visible: writing LO changes G/B immediately rather than being held until HI arrives. This keeps the port stateless; the cost is one transient intermediate colour if a game separates the writes, which the SDK avoids by writing them adjacently.
• Changes take effect at the very next pixel composited — palette RAM is read per pixel by the compositor, not latched per line or per frame. Mid-scanline palette swaps therefore work (the classic trick for exceeding 64 on-screen colours); the practical limit is how many writes the CPU can issue per 455-cycle line.
• Emulator consequence (important): a scanline renderer must sample palette state per pixel, not cache it once per line — caching silently breaks raster palette effects.

Sprite / OAM control ($4060–$406F) — OAM lives in VRAM; fast-path DMA from CPU RAM:

Input ($4070–$407F) — pad state latched inside oito (§9); active-high (1 = pressed):

Cartridge mapper ($4080–$408F):

Text overlay ($4090–$409F) — the top-priority character layer (§6.8); the char map lives in VRAM, glyphs in on-die font RAM reached through an indirect font port:

Mouse & hardware cursor ($40B0–$40BF) — §9.2; oito accumulates position from PS/2 deltas and renders the cursor; the game reads state + sets the cursor graphic:

Hit-test / pick ($40C0–$40CF) — §9.2; oito samples the compositor at the cursor hotspot (or PICK_X/Y) once per frame and latches what's under the pointer (cursor/text layers excluded):

APU — audio port ($40A0–$40AF) — the 16-voice APU (§8) is reached through an indirect port into an internal 16-bit-addressed register file + wave RAM; the CPU-visible footprint is tiny:

Ghost Debug Port:

Unmapped reads & writes. One rule, no open bus, no mirroring:

Rationale. Open bus is timing-dependent and is the largest single source of emulator divergence on comparable systems; oito is synchronous and drives $00, which is deterministic and trivially conformance-testable. The register file is not mirrored across $5000–$7FFF, so games cannot depend on aliases and register space stays open for expansion.

Consequence. A write-only register cannot be read back, so software must shadow any value it needs to read-modify-write. The runtime already keeps ZP shadows for BANK_SELECT and the VRAM pointer (§5.0), and the SDK does the same for VIDEO_CTRL.

Reset state. All registers clear to 0 at RES̄ except the three below, which is the complete and exhaustive list:

(This list and the §11.1.1 handoff table will be generated from one source, re8-registers-<ver>.csv (§16.3), which does not exist yet — both are currently maintained by hand, which is precisely why "all zero except" prose has twice drifted out of agreement with the sections that set the exceptions. Until the file exists and CI fails on drift, treat cross-section agreement as unverified.) Two zero values are load-bearing rather than incidental and are called out for clarity: BOOT_CTRL.BOOT_SRC = 0 selects the internal boot stub and BOOT_CTRL.BOOT_FLASH_WE = 0 disables boot-flash writes. Everything else is zero: screen off, all IRQs disabled and clear, blitter idle, scroll 0, bank 0, BOOT_BANK 0, cartridge geometry unprogrammed (CART_CONFIG_* = 0, unlocked), save window closed, boot-flash writes disabled (BOOT_FLASH_WE=0), PSG muted, text and cursor layers off. The boot code must enable video, program the palette, load VRAM, and enable IRQs before anything is displayed.

6. oito (custom ASIC)

6.1 Functions

oito integrates, on one 130nm die:

1. Video Display Processor — hybrid architecture: - Tile-based line renderer (NES/Genesis lineage): 8×8 tiles, tile grids 32×28 (lo-res) / 40×28 (hi-res); two independent background planes (Plane A / Plane B), each a 64×32-cell name-table (512×256px) with pixel-perfect scrolling (9-bit X, 8-bit Y). Full data formats, plane priority and VRAM layout are in §6.6. - Mini-blitter: writes raw pixels into a "Dynamic Tile Pool" region of VRAM, sharing the single private VRAM bus at priority 2 (behind display fetch — §6.5; it is not a separate bus); throughput ≥1,000 tiles/frame interleaved (≥350 blanking-only) under the §6.5 benchmark workload; a full 320×224 background is 1,120 tiles, so a whole-screen redraw per frame is possible only under the §6.5 benchmark workload, and sits just above the ≥1,000 floor.
2. Sprites — 128 hardware-tracked sprites, up to 32 per scanline, evaluated from an on-die shadow OAM with a line-buffer cache. Within that per-line budget rendering is flicker-free; the 33rd and beyond are dropped for that line — "zero flicker" is a property of staying inside the budget, not an unconditional guarantee.
3. Hardware collision — compares opaque sprite pixels during line rendering (index 0 ignored); on overlap latches both sprite IDs into COLLIDE_A/B and asserts IRQ. Latch/overflow/priority semantics are defined in §6.6.
4. Color — 4-bit indexed pixels; 12-bit master palette (4:4:4 = 4,096 colors); 4 sub-palettes × 16 colors = 64 simultaneous; palettes 0–1 backgrounds, 2–3 sprites/blitter; color 0 transparent.
5. APU — a 16-voice audio unit (4 enhanced PSG + 8 wavetable + 4 PCM), full detail in §8. Audio leaves the console three ways: embedded in the HDMI stream at 48 kHz (§7.1), on a stereo 3.5 mm line-out and an RCA pair at 1 Vᵣₘₛ, and on the SCART audio pins. One HDMI cable therefore carries picture and sound to a compatible 1080p60 sink.
6. Cartridge mapper — a console-side fixed-plus-switchable 16KB mapper: the bank register drives BANK0–BANK5 (64 × 16KB = 1MB addressable), swapping the $8000–$BFFF window in under a clock cycle while $C000–$FFFF stays fixed. Banking model resembles UxROM (fixed + switchable PRG window); it implements none of MMC3's PRG modes, CHR banking, scanline IRQ or serial write protocol — raster interrupts come from the VDP's RASTER_CMP instead (§5.1). The distinctive choice is that banking lives in the console, not the cartridge, which is why carts carry no mapper hardware — only the flash and a single inverter that sets OE# polarity (§11).
7. Address decoding / glue — decodes the $4000+ I/O window; drives the DB9 SELECT lines and reads the (always-enabled 74LVC244APW,118-translated) controller data directly (§9).
8. JTAG — IEEE 1149.1 boundary scan plus a custom debug TAP (§13, capability 9) reaching VDP internals: palette state, line-buffer flags, blitter status, wave RAM and a VRAM read window, independent of the CPU-side debug path. Boundary scan alone would expose only I/O-cell state, so the extra instructions and data registers are part of the design rather than an assumption.

6.2 Video output bus (all-digital rule)

oito never produces analog video. It outputs:

• 12-bit parallel digital RGB: R[3:0], G[3:0], B[3:0]
• HSYNC, VSYNC (both active-low), and chip-generated CSYNC = HSYNC XNOR VSYNC = NOT(HSYNC XOR VSYNC), active-low. With active-low inputs this is the standard formulation — horizontal pulses invert during vertical sync, which is what CRTs expect (full waveform in §7). Because SCART pin 20 and the VGA path need CSYNC too, generating it once in oito serves three outputs, and every consumer sees an identical waveform.
• DE (data enable) — marks the active rectangle for the CH7035B
• pixel clock (to CH7035B path)

Rationale: NTSC/PAL subcarrier generation on unproven low-volume silicon was judged too risky (an off-by-fraction error yields rolling B&W pictures); analog encoding is delegated to the AD725 (a proven, in-production encoder).

6.3 Pin budget — LQFP-176

oito targets LQFP-176 (0.5 mm pitch, 24×24 mm, standard OSAT part) on a custom pad ring (no Efabless Caravel harness — see §6.4). The complete signal budget, counting every interface the design actually requires:

~25 pins spare — real ECO headroom rather than the margin-free fit LQFP-144 would have given once the boot-page, PS/2 gate-control and cartridge-write signals were counted honestly.

This is a signal budget, not a sign-off pinout. It answers one question — does the design fit LQFP-176? — and the answer is yes, comfortably. It is not a pad-ring specification. Power/ground is derived, not measured: ≥1 VDD/VSS pair per ~8 simultaneously-switching outputs (~70 outputs → ~9 I/O pairs), plus separate core pairs, plus an isolated PLL VDDA/VSSA pair behind its own ferrite. The true count depends on the foundry I/O cell library, ESD clamp strategy, SSO current, bond-wire inductance and lead assignment — none of which are available until the fab route of §6.4 is engaged.

Every headline count in this document is derived from §6.3 and §11, and from nothing else. Pin and contact totals have drifted between sections three revisions running, so they are now stated once — 127 oito signal pins, ~151 total, 37 cartridge contacts, 42 header positions — and every other mention cites those sections rather than restating a number. Before tapeout they will come from re8-pins-<ver>.csv (§16.3); that file does not exist yet, so today these totals are hand-maintained and have drifted before.

Owed before tapeout (deliverable, not an estimate): a complete 176-pin table giving, per pin — number, name, direction in every bus-ownership state (normal / oito bus-master / probe bus-master / debug), pad type (open-drain for RDY, BE and IRQ̄), drive class, I/O bank supply, corner cells, no-connects, and the exposed-pad decision.

Signal reset states. Until that table exists, the signals whose unpowered and reset behaviour is safety-relevant are recorded here, because "it is in the pin table" is not a record while the pin table is a deliverable. A pin is not a register, so none of these belongs in §5.1.

The rule these share: the passive state is the inactive, non-driving, safe one, so a pad that is high-Z because a rail has not come up produces the same behaviour as a pad deliberately deasserted. Every external active-low enable and write strobe is in this table — an earlier revision listed only the cartridge signals, which left boot-flash W̄Ē and CĒ, both memory buses and every bus-master output with no stated behaviour during power sequencing or brownout, though they carry the same risk and BOOT_W̄Ē carries more. These states are cross-referenced from the 176-pin table and the bus waveforms (§16.2), which must also show that no partially powered target back-drives oito or the CPU.

Key resolutions captured here:

• VRAM is 8-bit data + 17 address = a real 128KB (2¹⁷ × 8 bits).
• Controllers are read into oito (6 data + 1 SELECT per port), so the joypad register is an oito register rather than external glue.
• PLL derives PCLK (5.37/6.71 MHz) and the render-core clock from one crystal (XIN/XOUT), hence the analog PLL supply pair. It no longer produces an audio clock: the audio output domain runs from the separate AUDXI oscillator (§8.4).

6.4 Production strategy (context)

RTL synthesized with open-source OpenLane against the open SkyWater 130nm PDK. The Efabless Caravel harness / chipIgnite base flow is abandoned (decision 2026-07): its ~38 user I/O cannot carry oito's 127 signal pins (§6.3), its base shuttle delivers ~100 QFN prototypes rather than a low-thousands LQFP-176 supply, and its RISC-V management core is dead weight in this console. oito therefore needs a custom pad ring and its own LQFP-176 package, taped out on SKY130 as a full-custom (bring-your-own-pad-ring) project — through a commercial MPW/fab engagement rather than the stock Caravel wrapper.

Open: which specific full-custom SKY130 route/foundry/shuttle, and its real NRE, per-unit cost and deliverable quantity. Economics is out of scope for this specification.

6.5 VRAM bus arbitration & bandwidth

The single 8-bit VRAM bus (VA0–16, VD0–7, 10 ns SRAM) has three masters. This section defines who wins, when the CPU can touch VRAM, and the resulting bandwidth — the last emulator-blocking unknown in the graphics path.

Bus clock & budget. The VRAM bus runs at the oito master clock (21.47727 MHz, 1 byte-access per cycle). Per frame that is 357,630 accesses (262 lines × 1,365 cycles); per scanline 1,365. At lo-res there are ~4 master cycles per output pixel (~3.2 at hi-res), and display fetch needs well under one access per pixel on average — so active display leaves spare VRAM cycles, and most blanking bandwidth is free — subject to the line-224 shadow-OAM snapshot and the line-261 prefetch of line 0, both detailed below. (Note the CPU runs at master ÷ 3, so 1 CPU cycle = 3 VRAM-bus cycles.)

Two time bases, and they must not be confused. A frame is 357,630 master ticks, and 357,630 mod 448 = 126 — so a counter that restarts every frame would place a mix tick 126 ticks after the previous one instead of 448, changing the sample rate and inserting a discontinuity at every frame boundary. There are therefore two independent counters:

Both count the master clock, so they never drift relative to one another; they simply have different reset points. At RES̄ both are zeroed, which fixes their relative phase for the life of the session and makes the golden audio vector reproducible. Everything below is expressed in master ticks. Two derived phases are also fixed rather than left to implementation:

• CPU cycle k occupies master ticks 3k, 3k+1, 3k+2. PHI2 falls at tick 3k, rises at 3k+1.5, and falls again at tick 3k+3 — that second fall retires cycle k if RDY is high at it (cpu_transfer_accept), and otherwise holds it. Falling edges land on integer ticks, and this is the document's single PHI2 origin; the earlier half-tick sampling model is withdrawn.
• The dot-clock PLL is line-locked: pixel 0 begins at tick_in_line = 341, and pixel n begins at tick 341 + floor(n × 1024 / W) where W is 256 or 320. Both resolutions therefore occupy the same 1,024-tick active window, which is why they fill the same width on a CRT. In lo-res that is exactly 4 ticks per pixel; in hi-res, 16 ticks per 5 pixels.
• A mix tick occurs when audio mod 448 == 0 (§8.5), and a tone tick when audio mod 12 == 0. Note the counter: these are not derived from raster.

Total event order within one master tick. When several events fall on the same tick they are processed in this order, which is normative because software can observe the difference:

1. raster position update (CUR_LINE, HBLANK/VBLANK flags, raster-compare latch)
2. CPU VRAM request detection — a $4044 access decoded during this tick becomes pending now, so it is visible to the arbitration that follows in the same tick
3. VRAM bus grant, per the slot table below
4. (reserved — CPU sampling and retirement are step 0 of the same tick, ordered before step 1; see below. Earlier revisions placed CPU completion off the whole-tick grid entirely, which the integer-edge origin withdrew.)
5. blitter byte retire and, if final, STATUS.2 clear plus the done IRQ
6. OAM DMA byte, if a transfer is in progress
7. APU mix tick — voices sampled, FIFOs drained, output frame emitted
8. PCM FIFO fill levels updated, refill requests raised, one voice granted (§8.5)
9. compositor pixel emission, including its font-RAM read (§6.8)
10. IRQ̄ recomputation from IRQ_STATUS & IRQ_ENABLE

Two orderings here are deliberate rather than incidental. Step 2 precedes step 3, so a request raised on a tick can be granted on that same tick — without it, two implementations could differ by a whole supercycle on every immediate grant. And step 7 precedes step 8, because a refill request is a consequence of the drain the mix tick performs and cannot be evaluated before its own cause.

The falling edge is step 0 of every third tick. Because falling edges land on integer ticks, at every tick that is a multiple of 3 the CPU's sample-and-retire is ordered before that tick's other steps:

tick 3k:          [0] PHI2 falls — the CPU samples read data, and oito samples address,
                      R/W̄ and write data. The cycle RETIRES ONLY IF RDY WAS HIGH at
                      this edge; if RDY was low the cycle is HELD and repeats.
                  [1..10] the ordinary steps listed above
tick 3k+1, 3k+2:  [1..10] only

Sampling and retirement are two events, not one. WDC's RDY halts the processor in its current state: a low RDY at the falling edge leaves the address, R/W̄ and data direction unchanged and re-presents the same cycle. So a stalled access sees the edge arrive repeatedly without the cycle ever advancing, and the specification must — and now does — distinguish sample, retire and hold. Writing "the cycle retires" unconditionally, as an earlier revision did, made a stalled read indistinguishable from a completed one and left four incompatible implementations open. See §6.5's read state machine.

Three kinds of falling edge, named separately. Every falling edge is a sample edge. What it does next depends on RDY, and using one word for all three is how an earlier revision came to tell a bus master to "wait for the acceptance edge" of a cycle it had just made unacceptable by definition:

owner_transfer_accept — one condition per owner, and everything with a side effect hangs off it. A held cycle re-presents itself, so an implementation that acts on every falling edge acts more than once per access: a held read of KBD_SCAN would pop two FIFO bytes, a held read of MOUSE_STATUS or an APU $A5 would clear a flag the CPU never saw, and a held AUDIO_DATA access would post-increment twice.

It is parameterised by owner, because the CPU is not the only master that touches the register file. §13 gives the probe direct access to the VRAM and palette ports and requires it to arm CART_WE_ENABLE during dev bootstrap — and the probe holds RDY low for the whole interval it owns the bus. A CPU-only acceptance condition commits none of those accesses: a probe write to VRAM_DATA or SAVE_CTRL would never take effect, no port pointer would advance, and the documented bootstrap path could not run. Releasing RDY to obtain acceptance is not a repair — with owner = probe that would clock the tri-stated CPU forward while another master owns its bus.

owner_transfer_accept(cpu)    = PHI2 falling edge AND RDY pin high at that edge
owner_transfer_accept(oito)   = PHI2 falling edge that latches one
                                cartridge byte (PCM) or one system-RAM
                                source byte (OAM); the later OAM VRAM write
                                is a private-bus grant, not host acceptance
owner_transfer_accept(probe)  = the falling edge of the PHI2 cycle oito GENERATES
                                for a probe request, at step 0 of that tick,
                                AND owner == probe AND probe_transfer_pending
                                -- oito withholds that edge until data is valid,
                                   so PHI2 itself is the ready signal (11.3)

cpu_transfer_accept           = owner_transfer_accept(cpu)         -- retained name

The probe case in full, because "the probe drives the ports directly" is not a protocol:

Every internal side effect is defined against owner_transfer_accept — register writes, font-RAM writes, FIFO pops, clear-on-read, accumulator consume, W1C and port pointer increments — not against the CPU's instance of it. That instance is:

cpu_transfer_accept  =  PHI2 falling edge  AND  RDY pin high at that edge

• It is the RDY pin, not oito's intent to drive it. RDY is open-drain and wired-AND: the debug probe also pulls it low for breakpoints (§13), so an oito that qualified on its own request signal would accept a transaction the probe was holding.
• Exactly one acceptance per CPU bus transaction, however many held edges intervene.
• Everything below fires at owner_transfer_accept and nowhere else: oito register writes, font-RAM writes, read side effects (FIFO pops, clear-on-read, accumulator consume), the W1C write commit, port pointer auto-increment, and — for the CPU's instance — the retirement of the CPU cycle itself. W1C is listed apart from the read side effects deliberately: its mask comes from the CPU's write data, not from a returned value, and an earlier revision filed it under reads in this very sentence while correctly calling it a write two paragraphs below. External write strobes are the exception, and they are handled by never creating the situation — see immediately below.
• RES̄ and the debug protocol do not use this rule to undo anything. Acceptance is a gate on committing, not a rollback.

An asynchronous write pulse cannot be retracted by a later edge, so oito does not stall an external write at all. RAM_W̄Ē, BOOT_W̄Ē and CART_W̄Ē are asynchronous strobes qualified by PHI2 high (§11), so they are already active from tick 3k+1.5. RDY need only be valid t_PCS = 15 ns before the falling edge, i.e. by 3k+2.68 — by which point 54.8 ns of a 69.8 ns write pulse has already reached the memory. A falling-edge decision arrives far too late to prevent it, and repeating the held cycle repeats the pulse. Gating the strobe off when RDY drops does not undo the elapsed write time; it just produces a runt.

This is concrete, not theoretical. The FM18W08 begins a write asynchronously on W̄Ē assertion and terminates it on the rising edge, so a duplicate consumes a further nonvolatile cycle; a duplicated NOR unlock or program write, or a smart-cartridge command write, can change the device's command state. Starting the strobe later instead — at oito's arbitration tick 3k+2 — leaves only 46.6 ns, below what a 70 ns FRAM needs, so the runt-pulse repair does not close either.

There are exactly two commit mechanisms, and each effect belongs to one of them:

The external rule is a scheduling rule, not a gating one:

No RDY puller may hold a cycle that will emit an external write strobe — RAM_W̄Ē, BOOT_W̄Ē or CART_W̄Ē. Any halt request waits for the first cycle that emits none of the three and creates its hold edge there.

The rule binds every external halt requester, because RDY is open-drain and wired-AND. cpu_transfer_accept already observes the pin precisely because more than one party pulls it; a rule scoped to one of them protects nothing. Three parties share the line and two are bound — the distinction is not who can pull it, but who can halt a cycle they did not choose:

3 parties share the pin; 2 of them are external halt requesters and are bound by the scheduling rule. Those are different sets, and calling the smaller one "every puller" is what an earlier revision did while §2 documented a third party on the same line.

An earlier revision scoped this rule to oito alone. The probe halts the CPU on host halt/run, on freeze (RDY) before register capture, for live-memory access and dev bootstrap, and on autonomous crash detection — and the stack-overflow heuristic triggers off a push write, so it could land squarely in the three-cycle interrupt push sequence and repeat a stack write, an FRAM write cycle or a NOR command. The preserve/abort table does not help: preserving the transaction is correct, and it is why the held external write would be re-presented. The SYNC-qualified hardware breakpoint is a separately safe case and keeps its existing timing — it matches an opcode fetch and holds the following cycle, which is an operand or dummy read, never an external write.

• Writes to oito's own registers are still freely held. They emit no asynchronous external pulse; their commit is internal and gated by owner_transfer_accept(current_owner) as above. The rule covers only system RAM, boot flash and the cartridge.
• The deferral is bounded at three CPU cycles. The longest run of back-to-back external write cycles a 65C02 produces is the interrupt/BRK push sequence — PCH, PCL, P, all to the stack in system RAM. JSR pushes two; PHA/PHP/PHX/PHY are one each and never adjacent. So a halt is delayed by at most 3 CPU cycles = 9 master ticks.
• It is deterministic, not merely bounded. An emulator knows R/W̄ and the decode, so it computes the same deferral the hardware does; nothing here depends on which lot closes timing.
• Consequences are recomputed rather than assumed: §8.5's steal onset and §6.6's OAM DMA cost both inherit this, and both say so.
• Reads are unaffected in their data path. oito drives the read value throughout the cycle and re-drives the same value across held edges; only the commit — the pop, the clear, the increment — waits for acceptance. The CPU has not taken the data until the accepted edge, so re-presenting it is correct.

Which byte, not just when — the read snapshot and its commit token. owner_transfer_accept says when a side effect commits; it does not say what the commit applies to, and for a producer whose state changes during a hold those are different questions. A KBD_SCAN read can find the FIFO empty and then have a scan byte arrive before acceptance; MOUSE_STATUS bits 1–3 or an APU $A5 flag can set after the first hold edge. Without a rule, an implementation can return $00 and pop the newly-arrived key, or return old status while clearing a flag that arrived later — and "the same value across held edges" would simply be false.

So each transaction carries a read-data latch — the byte the CPU will receive, re-driven unchanged at every subsequent hold edge — plus a commit token, both captured at the event that sets serviced (the grant for a VRAM read, decode completion at tick 3k+2 for an oito register read).

A snapshot alone is not enough, because a token that only records the old value cannot express an event that happened after it. Each side-effecting read therefore also runs a post-snapshot accumulator.

The accumulation interval is snapshot-to-acceptance, and it exists even when nothing is held. The snapshot is captured when serviced sets — decode completion at tick 3k+2 for an ordinary register read — while acceptance is a later falling edge, so there is always a gap, at minimum one tick, whether or not RDY ever goes low. Precisely: the accumulator collects every event processed after the snapshot's event step and at or before the acceptance edge's step 0, ordered by the §6.5 event list. "For the duration of the hold" was too narrow — it left an unstalled read's snapshot-to-acceptance window undefined, and an input or APU event landing there would have been consumed as part of a snapshot taken before it happened.

There are three commit types, and every side-effecting register belongs to exactly one:

Type 2 needs A, not just S, and this is the part a mask alone gets wrong. Suppose APU $A5.0 is already 1 when the read is snapshotted, and voice 0 underruns again during the hold. The CPU accepts the old value with bit 0 set — correctly — but clearing S would then clear bit 0 and lose the second underrun. A one-bit sticky latch carries no generation identity, so nothing in the live state distinguishes "the old 1 is still there" from "another event set this 1". Recording the post-snapshot sets separately is what preserves it. An earlier revision said "a flag that set after the snapshot survives", which is true only when that bit was 0 at snapshot time — the case that does not need fixing.

clear_on_read_mask is per register, and most of the returned byte is not clearable. S must be masked or a read would clear bits that only report state:

The worked example implied the right subfield, but the literal formula live ← (live & ~S) | A with S as "the returned bit mask" would have cleared present on every read of MOUSE_STATUS.

Type 3 cannot be done by subtraction. live − V is not generally correct: the accumulator saturates, and opposite-signed deltas make the operation non-invertible, so a wheel at +127 that receives further motion cannot be unwound. Accumulating post-snapshot deltas separately and replacing the live value is the only form that survives saturation. Saturation order is stated: each arriving delta is added to D and the result saturated immediately, so D never exceeds ±127 at any intermediate step.

W1C is a write, not a read, and is filed separately. Its clear mask comes from the current owner's write data — the CPU's for a CPU cycle, the probe's for a probe-owned one — not from a returned value. A held or stalled W1C write samples that byte into a current-owner write-data latch for the transaction and applies it once at owner_transfer_accept(current_owner). Saying "the CPU's write data" left the probe's W1C payload undefined while the probe table permits register writes. It was previously listed beside clear-on-read, which left its payload ambiguous.

One W1C precedence order, for every W1C register. Within a single event step, a bit may face a hardware set, an automatic clear and the CPU's acknowledgement at once. The order is:

1. automatic clear   (e.g. STATUS.3 at the active-frame boundary)
2. owner W1C mask    (applied at owner_transfer_accept(current_owner))
3. hardware set      (the event for this step)

Set is applied last, so a coincident set always wins and no event is lost — losing one to an acknowledgement that arrived in the same step would be a silent, unreproducible bug, and the worst case of set-wins is one redundant service. This resolves STATUS.3's three-way question — frame clear, event set, CPU W1C — with the same order as everything else, rather than a special case.

The rule covers all four W1C families, and applies identically to each: IRQ_STATUS, STATUS.3 (sprite overflow, plus its frame-boundary auto-clear), INPUT_STATUS, and KBD_STATUS.2 (FIFO overflow). Only IRQ_STATUS previously stated a coincidence rule, so two conforming implementations could disagree on a same-step keyboard, input or sprite-overflow event. §16.2's traces cover all four.

• Abort (RES̄ only, per the table below) discards the read-data latch, the token and the accumulator. A preserved transaction keeps all three, so a takeover changes neither the byte the CPU receives nor the events that survive it.
• On reset all accumulators are zero and no transaction is outstanding.

This is what makes "the same value across held edges" true rather than aspirational. §16.2 gates it with traces that begin with the tested bit already set, since a trace that sets a different bit passes without exercising the defect at all.

• Nothing needs to be predicted for the internal effects. §6.5 times oito's register writes and font-RAM writes from step 0 of the tick; acceptance is that same step-0 event with the RDY qualification retirement now carries. This does not extend to the three external strobes — RAM_W̄Ē, BOOT_W̄Ē and CART_W̄Ē are asynchronous PHI2-high signals (§11) and cannot be gated by a later edge at all; they are handled by the scheduling rule below and by nothing else.
• Bus takeover follows the same rule. BE is asserted one tick after the hold edge, so a takeover never straddles an accepted transfer. On resumption the CPU continues the same preserved transaction — see the preserve/abort table below.

Every oito register write and every font-RAM write is timed from step 0 of that tick and gated by owner_transfer_accept(current_owner) — for the CPU that means step 0 only if RDY was high at that edge; for the probe it means the falling edge of the oito-generated PHI2 cycle for that transfer, qualified by owner = probe and probe_transfer_pending (§11). DBACK rises once at acquisition and stays high; there is no per-transfer rise. The external strobes RAM_W̄Ē, BOOT_W̄Ē and CART_W̄Ē are explicitly excluded: they are PHI2-high asynchronous pulses and are governed by the scheduling rule rather than by acceptance. Font RAM is read at step 9 and written at step 0, so a pixel composited at tick 3k+1 or 3k+2 sees the byte written at step 0 of tick 3k, and one composited at tick 3k−1 does not.

The slot table. A per-line total does not say where in the line an access happens, and interleaved blitting is visible under the raster, so totals cannot be the contract. The line is instead divided into 105 supercycles of 13 master ticks — 105 × 13 = 1,365 exactly — and each supercycle is split by a fixed rule:

Display rarely needs its full capacity — and in the hi-res worst case it needs all of it. What it needs is bounded and content-derived, so an emulator computes the same free slots the hardware does:

Fine horizontal scroll costs a whole extra column. With BGn_SCROLL_X mod 8 ≠ 0 a wrapping plane shows part of a tile at the left edge and part of another at the right, so it needs C + 1 columns — 41 in hi-res, 33 in lo-res. Fetching only C would leave the right edge wrong at every non-zero fine offset. Each plane is counted independently, so a line may need 40 + 41 columns.

The sprite budget is therefore what the queue has left, not a fixed 512. Sprites are last in the fetch order, so they are what runs out: the admission limit is min(512, capacity − BG − text) and the 32-sprite cap applies as well. Both quantities are derived from VIDEO_CTRL, TEXT_CTRL, the two scroll registers and OAM, so both implementations compute the same number.

A fixed 512-byte budget with fine scroll on both hi-res planes would have demanded 1,164 accesses against 1,155 slots — nine fetches with no defined outcome.

The fetch queue — which access lands in which slot. Capacity alone does not determine behaviour: two implementations consuming the same totals in a different order expose different free ticks to the CPU and blitter, and can sample a pixel's source before or after a blitter write to the same address. That is Tier-1-observable, so the order is normative too.

The display engine runs one line ahead of the beam, into a double-buffered line buffer: during line N it fetches everything line N+1 will need, and the compositor emits line N from the buffer filled during line N−1.

The frame wraps on line 261. Line 0's data must be fetched somewhere, and the only line before it is the last line of the previous frame, so line 261 carries a display fetch and lines 223 to 260 carry none — line 223 is already fetching blank line 224. Three consequences follow and are normative:

• Frame-latched registers move to the start of line 261, not line 0: VIDEO_CTRL bit 1 (resolution), OAM_BASE, PICK_CTRL and PICK_X/Y are sampled there, because line 0's fetch has already happened by the time line 0 begins. §6.7's latch table says line 261 for exactly this reason.
• Blanking bandwidth is reduced accordingly. Line 261 gives up its ticks to line 0's fetch — up to 1,155 in hi-res, leaving 210, and up to 1,036 in lo-res, leaving 329 (table below).
• Priming, as three cases — a single rule could not cover reset, since at reset there is no preceding line 261:

The fetcher runs whenever the raster runs, regardless of screen enable. That is what makes the third case clean and confines the first to one line. For the line being fetched, the queue is built in exactly this order and consumed one access per display slot, in order:

1. Plane A, viewport columns 0 … C−1, plus column C when BG0_SCROLL_X mod 8 ≠ 0 — six accesses each: name-table low byte, name-table high byte, then pattern-row bytes 0–3.
2. Plane B, same, with its own BG1_SCROLL_X test — the two planes are independent, so a line may fetch 40 columns of one and 41 of the other.
3. Text overlay, if enabled: cell 0 … 79, two accesses each — character code then attribute.
4. Sprites, in ascending OAM index among those admitted for the line (§6.6), each contributing its pattern-row bytes in ascending VRAM address order.

C is 40 in hi-res and 32 in lo-res, and viewport column v maps to map column ((SCROLL_X div 8) + v) mod 64 — the queue is in viewport order, and wrap is applied per column. The map row is ((SCROLL_Y + display_line) mod 256) div 8, with the pattern row being that sum mod 8. Column C is the partial tile at the right edge; without it the rightmost pixels would be undefined at every non-zero fine offset, which is why its cost is in the budget above. A disabled plane or a disabled text layer contributes nothing and its slots fall through; sprites contribute only what the admitted set needs, up to the 512-byte ceiling. Slots the queue does not reach fall through to the CPU and then the blitter in the same tick — deterministic, not opportunistic, because the queue length follows from VIDEO_CTRL, TEXT_CTRL and OAM, all of which both implementations already model. VIDEO_CTRL.0 (screen enable) does not participate: the fetcher runs whenever the raster runs. Only the layer-enable bits 2/3/5, TEXT_CTRL.0 and the two SCROLL_X values change what the queue contains.

Consequence, stated plainly because it is a real behavioural cost. A per-line register (§6.7) is latched at the start of the line on which its data is fetched, which is one line before display. A write during line N therefore first affects the picture on line N+2. Raster splits must be programmed two lines early. This is the price of a fully determined fetch order, and it is a fixed, documented quantity rather than an implementation variable.

Sprite pattern budget — the reason "32 per line" needed qualifying. A 4bpp sprite row costs width/2 bytes: 4, 8, 16 or 32 for the four sizes. Thirty-two 64-px sprites would need 1,024 bytes on one line, which alone exceeds every free slot the line has. The contract is therefore two limits, whichever binds first:

• at most 32 sprites per line, and
• at most min(512, capacity − BG − text) sprite pattern bytes per line — 512 when the planes are tile-aligned, 503 in the hi-res worst case where both planes are fine-scrolled with text on (table above).

Sprites are evaluated in ascending OAM index and admitted until either limit would be exceeded; the rest are dropped for that line and STATUS.3 sets, exactly as sprite-count overflow already did. So on a tile-aligned line with the full 512 bytes a line carries 32 sprites of 8 px (128 bytes, count-limited), 32 of 16 px (256 bytes), 32 of 32 px (512 bytes, exactly at the limit) or 16 of 64 px. In the fine-scrolled hi-res worst case the budget is 503 bytes, so only 31 sprites of 32 px fit and the 32nd is dropped — the examples are conditional on the background and text state, not absolute. This is the same class of limit the Genesis and SNES impose, and without it the "32 per line, full stop" promise was unachievable at the two larger sizes.

CPU VRAM-port grant, with the handshake spelled out.

The bus cycle runs from one PHI2 falling edge to the next. Cycle k occupies ticks 3k…3k+2, PHI2 falls at tick 3k, rises at 3k+1.5 and falls again at tick 3k+3, which retires the cycle if RDY is high at that edge (cpu_transfer_accept, §6.5) and otherwise holds it. Both phases are 69.8 ns, over the 62/63 ns minima.

Address timing is referenced to the falling edge that starts the cycle, per WDC: t_ADS is 40 ns at 3.3 V — not the 30 ns of the 5 V column — so the address is valid at tick 3k+0.86.

Return margin +114.7 ns; the read takes 2 CPU cycles and the binding constraint is the request path, not the return path.

• A VRAM_DATA read takes two CPU cycles, and the binding constraint is the request path, not the return path. A one-cycle read would need the slot at tick 3k+1, leaving only 6.6 ns between address validity and that slot for pad, decode, synchroniser and arbitration — not realisable. Capturing at tick 3k+2 instead gives 53.1 ns for that path and 114.7 ns of return margin. An earlier revision claimed a one-cycle read on a +21.6 ns figure that measured only the data return and omitted the request path entirely; that claim is withdrawn.
• RDY is asserted by 3k+2.68, t_PCS = 15 ns before the edge that would otherwise retire cycle k, giving 84.7 ns from address validity — a comfortable path, and the one genuine improvement the corrected edge convention delivers.

• Waveforms are a deliverable (§16.2), drawn falling-edge to falling-edge against the 3.3 V AC column, showing the CPU's address separately from oito's decoded selects so the two delays are not conflated.

• A CPU write is accepted at the sampling edge at 3k+3.0 — subject to owner_transfer_accept(cpu), so a held write is accepted once and emits one strobe — and committed to VRAM on a later granted slot — a posted write, whose contract is:

• The read state machine, as one transition list. This replaces the earlier "becomes pending at the sampling edge that retires its CPU cycle — for a read, the edge of the preceding cycle" rule, which was the withdrawn one-cycle mechanism and contradicted capture at 3k+2 above. There is one capture rule for reads and one for writes:

Two pieces of state, not one. A single request latch cannot express this transaction, and trying to make it do so is how an earlier revision let one CPU access be serviced twice. There is a pending latch, which arbitration consumes, and a serviced flag, which records that this transaction already has its data:

serviced is what closes the duplicate. Clearing the request at grant while the CPU still presents $4044 would let step 2 of the next tick see an un-suppressed read of the same held cycle and enqueue it again — two VRAM accesses and two pointer increments for one instruction. The suppressing term therefore has to survive until acceptance, not until grant.

Across a bus takeover the CPU transaction is preserved, not abandoned. A takeover holds the CPU; it does not delete the access the CPU is in the middle of. WDC resumes the same internal bus state, so oito must resume the same service state:

An earlier revision said probe ownership and debug entry "abort the transaction". They do not: only reset does. Clearing oito's service state after a temporary takeover would force the same CPU access to be serviced twice — the very duplicate serviced exists to prevent. So resumption is not "a fresh transaction" — that phrasing is withdrawn; it is the same transaction reaching its acceptance edge at last.

Grant is at 3k+2, the same tick as detection. The event order exists to make this deterministic — step 2 is detection and step 3 is arbitration precisely so that "a request raised on a tick can be granted on that same tick" — and an earlier revision's "first arbitrated slot 3k+3" contradicted its own event order. This does not restore a one-cycle read: retiring at 3k+3 would need data by 3k+2.68 and it arrives at 3k+3.21, so the read is still two CPU cycles and the binding constraint is still the request path. What it changes is the return margin, now 114.7 ns rather than the 68.1 ns computed from the later slot.

So an uncontended read is two CPU cycles: cycle k plus one held repeat. Contention adds whole held cycles, never partial ones. A write is different and stays different: it is accepted at the retiring edge at 3k+3, costs one cycle, and asserts RDY only if the posted-write buffer is already occupied.

Request-to-grant is at most 11 master ticks in hi-res and 10 in lo-res, a bound that depends on same-tick eligibility at the end of a supercycle.

• Waveforms remain a deliverable (§16.2): read, write, immediate grant, worst-case wait, line-224 wait, the PCM steals at all three phases, and the OAM-DMA takeover at its single phase, each drawn falling-edge to falling-edge against the 3.3 V AC column.

• On blanking lines every tick is available and a grant is immediate, except during ticks 0–1023 of line 224 (the shadow-OAM snapshot, the machine's longest stall) and on line 261, which carries line 0's fetch and so behaves like an active line.

Blitter allowance, derived from the table above rather than asserted:

The display load is mode- and content-dependent, so the totals below are stated per mode at the legal worst case.

These are bus availability, not a blitter guarantee. The CPU port and OAM DMA outrank the blitter, so a program hammering VRAM_DATA, or a DMA in flight, consumes the same ticks. The throughput figures below therefore carry the condition "the CPU performs no VRAM-port accesses and no OAM DMA is in progress" — without it they are not floors at all.

These are floors under an idle CPU port and no OAM DMA: a line with no text and few sprites frees display slots and the real figure rises. Note that lo-res has more blanking-only bandwidth than hi-res, because its lighter line-261 load leaves more of that line free.

The blitter consumes its allowance in the byte order of the reference algorithm below, so a blit completes on a determined tick and the done IRQ latches there. STATUS.2 clears in step 4 of that tick's event order.

RDY is shared with the debug probe and with the CPU's own WAI; all three are wired-AND open-drain with an external pull-up.

Blitter operational definition. The reference implementation, which is normative:

Units are always whole bytes. BLIT_W counts tiles (32 bytes) or byte-pairs of pixels (1 byte = 2 pixels), selected by BLIT_MODE bit 2. There is no sub-byte addressing anywhere: BLIT_SRC, BLIT_DST and BLIT_MASK_SRC are byte addresses with no nibble selector and there is no X coordinate, so odd start-X and odd width do not exist and no boundary read-modify-write is defined. Software that needs an odd-aligned blit shifts its source data instead.

blit:                                    # all VRAM addresses are 17-bit, wrapping mod 128KB
  # A start write ALWAYS sets STATUS.2 for at least one tick and ALWAYS ends
  # with a done IRQ, so software sees one completion per start, no exceptions.
  if BLIT_W == 0 or BLIT_H == 0:          # zero means NO-OP (not 256)
      STATUS.2 = 0 ; raise blitter-done IRQ ; return
  unit_bytes = 32 if unit == tiles else 1
  row_bytes  = BLIT_W * unit_bytes
  mask_pitch = (row_bytes * 2 + 7) // 8  # 1 bit per pixel, 2 pixels per byte, rows byte-aligned
  src = BLIT_SRC ; dst = BLIT_DST ; msk = BLIT_MASK_SRC
  for row in 0 .. BLIT_H-1:              # rows ascend; bytes within a row ascend
    s = src ; d = dst ; mbit = row * mask_pitch * 8
    for i in 0 .. row_bytes-1:
      match op:
        copy:        write(d, read(s))
        transparent: b  = read(s)                        # per-NIBBLE test
                     hi = (b >> 4) ; lo = b & 15
                     o  = read(d)
                     if hi != 0: o = (o & 0x0F) | (hi << 4)
                     if lo != 0: o = (o & 0xF0) | lo
                     write(d, o)
        fill:        write(d, (BLIT_FILL & 15) * 0x11)   # nibble duplicated
        masked:      if (mbit & 7) == 0:                # one mask byte per 8 pixels
                         mcache = read(msk + (mbit >> 3))  # costs a bus slot
                     b  = read(s)
                     o  = read(d)
                     mh = bit(mcache, 7 - (mbit & 7))     # left  pixel = high nibble
                     ml = bit(mcache, 6 - (mbit & 7))     # right pixel = low  nibble
                     if mh: o = (o & 0x0F) | (b & 0xF0)
                     if ml: o = (o & 0xF0) | (b & 0x0F)
                     write(d, o)
      s += 1 ; d += 1 ; mbit += 2
    src += row_bytes + BLIT_SRC_PITCH
    dst += row_bytes + BLIT_DST_PITCH
  STATUS.2 = 0 ; raise blitter-done IRQ

• Masked mode, completely: the mask byte covering pixel n is at BLIT_MASK_SRC + (n div 8) and its bit 7 - (n mod 8) is that pixel — MSB is the leftmost. The byte is fetched once per eight pixels and held in a one-byte cache for the four loop iterations that consume it, which is why the cost is one mask read per 8 pixels rather than two per byte; the cache is reloaded at each mbit multiple of 8 and discarded at the end of every row, since rows are byte-padded. A mask bit of 1 copies the source pixel; a mask bit of 0 leaves the destination pixel untouched. Mask rows are padded to a whole byte and the row stride is mask_pitch above; the mask always starts at bit 7 of its first byte — there is no sub-byte start offset. Masked mode therefore costs three accesses per byte (source read, destination read, destination write) plus one mask read per 8 pixels. The mask address wraps modulo 128 KB like every other VRAM address.
• Nibble order: high nibble = left pixel (as §6.6).
• Overlap: the copy is strictly ascending, so overlapping regions with dst > src corrupt — the caller's responsibility, exactly as period blitters behaved.
• Busy semantics: a start while busy is ignored; register writes while busy are ignored. BLIT_CTRL.0 and STATUS.2 both read busy.
• Timing is normative, not free. The blitter consumes its per-line allowance from the arbitration schedule above, in the byte order shown. Completing a blit instantly is not a conforming implementation: software observes STATUS.2, the ordering of the blitter-done IRQ against raster and input IRQs, and — in interleaved mode — partially written VRAM as the raster passes over it. STATUS.2 clears and the done IRQ latches at the end of the line on which the final byte is written.

Shadow OAM. oito keeps a 1 KB on-die copy of OAM. Per-line sprite evaluation (§6.6) scans that internal copy, so sprite evaluation costs zero VRAM accesses; only the pattern rows of the ≤32 winning sprites are fetched from VRAM. This is standard VDP practice (the NES copies OAM internally; the Genesis caches the sprite list) and removes the largest, most variable term in the budget — a naive per-line scan of 128 VRAM entries would cost 57 K–229 K accesses/frame by itself.

• Snapshot event: line 224, master ticks 0–1023. The first VBLANK line is reserved: oito reads the 1 KB VRAM OAM into the on-die shadow at one byte per tick for exactly 1,024 ticks, then releases the remaining 341 ticks of that line to the CPU and blitter. The snapshot is not instantaneous and it does not compete with anything — the line is allocated to it. Nothing else may use ticks 0–1023 of line 224: a CPU VRAM_DATA request arriving there is RDY-stalled until tick 1024, which is the longest stall the machine can produce (1,024 ticks ≈ 341 CPU cycles) and is why the SDK does its VBLANK VRAM work after line 224.
• Sprite evaluation for every visible line of frame N uses the shadow captured at line 224 of frame N−1. A VRAM-port OAM write therefore lands on the next frame — which is precisely what "next frame" meant.
• OAM DMA writes both — CPU RAM into the VRAM OAM and into the shadow in the same pass — so its effect is visible on all lines rendered after the burst completes, not on lines already drawn. The dual write is why the cost in §6.6 counts one read and one write per byte.
• Consequence, documented rather than discovered: a mid-frame DMA tears — sprites above the raster line show old positions, below show new. This is why the SDK issues OAM DMA in VBLANK.
• Emulator rule: schedule the snapshot at line 224 and apply DMA effects at the cycle the burst completes; both are ordinary events in the scanline loop.
• Semantic consequence: OAM edits made through the VRAM port take effect on the next frame, not mid-frame — the classic shadow-OAM behaviour, and precisely why OAM DMA exists. Emulators MUST model this one-frame latency.

Bandwidth, per frame. The slot table already bounds this per line; the frame view is its consequence, at 320×224 with two planes and text on, against 357,630 accesses:

There is no unallocated remainder: every tick the display does not use falls through under the queue rule, including the whole of line 223, which fetches nothing.

Every row is a worst case, not a typical figure, which is what makes the remainder a guarantee.

Blitter throughput — a benchmark, not a slogan. Throughput is quoted only against a defined workload, with guaranteed minimums:

• Benchmark transaction: opaque copy, tile units, 8×8 tiles (32 B), source and destination pitch 0, measured with both BG planes enabled, and — because the CPU and OAM DMA outrank the blitter — with the CPU performing no VRAM-port accesses and no OAM DMA in progress. The display remainder is taken at its worst case per mode — text on, both planes fine-scrolled, and the sprite budget the queue leaves (503 hi-res, 512 lo-res), so the result is a floor under a busy picture rather than a best case under an empty one.
• Throughput under that workload is derived, not estimated. Each tile costs 64 bus accesses, and the slot table gives 49,691 (hi-res) / 49,810 (lo-res) accesses per frame blanking-only and 97,886 / 124,542 interleaved in the worst case — 776 / 778 and 1,529 / 1,945 tiles. Floors, since unused display slots fall through.
• Other workloads are estimates, and the spec says so: transparent mode costs three accesses per byte instead of two, and masked mode three plus the mask fetch, so both run at roughly two-thirds the tile rate; enabling the text layer subtracts ~36 K accesses/frame from the display budget, which is what the interleaved figure's 256 spare cycles per line already allows for.

The correct characterisation of the margin remains adequate, not large. A worst-case line (both planes plus 32 full-width 32 px sprites) can approach saturation; the renderer's contract in that case is unchanged — display always wins, and the blitter/CPU simply get fewer spare cycles that line.

Emulator guidance (Tier 1 — §14.5). Model per master tick against the event order and the slot table: run the CPU cycle by cycle applying RDY stalls where the grant rule says they occur; consume the blitter's allowance in the byte order of the reference algorithm; and fill the line buffer from the ordered fetch queue on the preceding line, rendering each display line from that buffer — not from VRAM as it stands at each pixel, which would miss every write that landed between the fetch and the display.

There is no Tier-2 residual in the fetch path. The ordered queue, the one-line-ahead line buffer and the slot assignment are Tier 1 in full, because together they decide CPU grants, blitter progress, and whether a fetch reads VRAM before or after a blitter write to the same address. A renderer that samples "VRAM state at each pixel" does not reproduce a buffer filled on the previous line and is not conforming. Tier 2 is reserved for genuinely unobservable electrical detail.

6.6 Graphics data formats & rendering

Everything the display-fetch model (§6.5) reads from VRAM, plus the sprite overflow/priority/collision contract — the complete renderer specification.

VRAM address arithmetic — one rule. Every VRAM address computation wraps modulo 128 KB (17 bits). This is not an edge case: a 12-bit tile index alone spans the whole 128 KB (4096 × 32 B = 131,072 B), so any non-zero pattern base can carry a high index past 17 bits — a game using tile 4000 with a 2 KB base is already out of range.

• The rule applies uniformly to pattern_base + index × 32, name-table fetches, sprite pattern fetches, the cursor tile (§9.2), the text char-map (§6.8), blitter addressing and the CPU VRAM port.
• No clamping, no "invalid tile" case, no error flag. Wrapping is simply what the hardware does — the address bus is 17 bits wide and the high bits do not exist — so it is free, deterministic, and matches era-appropriate VDPs. Clamping would need comparison logic that buys nothing.
• Consequence, documented rather than hidden: base and index spaces overlap, so a large base plus a large index aliases back into low VRAM. That is the programmer's responsibility; the SDK's asset packer warns when a bank's tile range would wrap.

Pixel & tile format. 4bpp indexed. One 8×8 tile = 32 bytes = 8 rows × 4 bytes; each byte holds two pixels, high nibble = left pixel, low nibble = right pixel; row 0 = top. Color index 0 = transparent. Tiles are addressed by a 12-bit index relative to a pattern base: VRAM address = (pattern_base + index × 32) mod 128 KB (base registers are in 2KB units → 64 tiles/step; wrap rule).

Palette (recap §5.1). Internal 64×12-bit RAM = 4 sub-palettes × 16 colors. Background planes use sub-palette 0 or 1; sprites use sub-palette 2 or 3. Index 0 of any sub-palette is transparent. The backdrop (shown where every layer is transparent) is sub-palette 0, entry 0.

Background: two planes. Plane A (BG0) and Plane B (BG1), independent, each:

• name-table 64 × 32 cells (512 × 256 px), 2 bytes/cell = 4KB, at BGn_MAP_BASE; wraps.
• pixel-perfect scrolling: X is 9-bit (0–511, wrapping the 512px map width), Y is 8-bit (0–255, wrapping the 256px height) — Y needs no ninth bit because the map has no 257th row.
• enabled by VIDEO_CTRL bit 2 (A) / bit 5 (B); tiles from BGn_PAT_BASE.

Name-table cell (16-bit, little-endian):

OAM DMA. OAM is 128 × 8 = 1024 bytes, so the DMA source is a 1KB-aligned block of CPU RAM (OAM_DMA_SRC $4061 holds the block number 0–15; address = block << 10) — not a 256-byte page. The SDK reserves one 1KB shadow-OAM buffer and always passes it, so games never compute the address. Entry size stays 8 bytes: it is fully spent on 9-bit X/Y, a 12-bit tile index, independent W/H, flip, palette and priority, and 1KB of the 16KB RAM budget is proportionally less than the NES spends (256B of 2KB).

• Cost — a state machine, with best and worst cases, not one fixed number. v0.4's unconditional 8N + 6 is withdrawn: §6.5 simultaneously subjected the VRAM write to slot arbitration and paused the transfer for the line-224 snapshot, and those cannot all hold. The transfer is defined as a two-phase loop per byte:

A two-entry write FIFO lets the read of byte k+1 proceed while byte k is still waiting for its slot; with only one entry the buffer is occupied by the waiting byte and the source read must pause, which is why the depth is two. When both entries are full the source read stalls until a write is granted, so under sustained contention the write rate, not the read rate, sets the pace.

OAM DMA has exactly one startup phase, not three. It is triggered by a CPU write to $4061, and every CPU write retires at the same PHI2 falling edge, so unlike a PCM refill — which arises on a free-running mix tick and genuinely cycles through m mod 3 — the trigger has one fixed phase. The 8N + 7 row therefore does not describe OAM DMA at all and is deleted. The three-phase table applies to PCM refills only.

8N + 6 is a floor, not a constant, because of the external-write deferral. oito cannot stall a cycle that emits an external write strobe (§6.5), and the cycle it must hold is whatever follows the trigger write to $4061 — which the program chooses. If that is a store to system RAM or the cartridge, the halt defers, by at most 3 CPU cycles (the interrupt-push bound). So a blanking-line transfer costs 8N + 6 to 8N + 9, set by the instructions immediately after the trigger and therefore computable by an emulator and controllable by the SDK — following STA $4061 with a non-write cycle makes it exactly 8N + 6. Earlier revisions said "always 8N + 6", which held only while a write could be halted mid-pulse, and it cannot be.

The 8N + 6 … 8N + 9 range is therefore the VBLANK cost, which is where the SDK issues it and where the number is meaningful. During active display it is bounded, not fixed. Each shadow-OAM byte becomes visible at the tick its VRAM write is granted, not when the transfer completes. It comfortably fits the 38-line VBLANK (17,290 CPU cycles) but is expensive mid-frame — it SHOULD be issued in VBLANK. Once started it is not abortable; OAM_DMA_CTRL.0 reads busy.

• Bus contract: OAM DMA requests owner = oito through §6.9.1; it does not publish a second RDY/BE sequence here. The CPU transaction is held and preserved, and each source byte accepts on the PHI2 falling edge that latches it. The later VRAM write is a private-bus grant. The host SRAM bus runs at the CPU rate, not the master rate — one source byte per CPU cycle — which sets the 8N + 6 floor above; the fixed overhead includes the §6.9.1 acquisition and release-wait states.
• Ordering against the other bus events, normatively:
• The line-224 shadow snapshot always wins. A DMA in flight when line 224 begins is paused for the duration of the snapshot and resumes afterwards; the snapshot therefore captures VRAM OAM as it stands mid-transfer, and the DMA's remaining entries land in the shadow directly.
• A PCM steal request during DMA is deferred until the DMA completes. PCM FIFOs are 16 bytes deep and a full DMA is at least 1,030 CPU cycles — longer under active display — so a four-voice underrun is likely rather than merely possible; that is a documented consequence, it sets the $A5 flags, and it is why the SDK issues DMA in VBLANK.
• A probe debug-mode request during DMA takes effect at the end of the DMA, never inside it. The probe cannot observe a half-transferred OAM.
• Partial updates: OAM_DMA_LEN ($4064) sets the entry count and OAM_DMA_OFS ($4065) sets the starting entry, so a run anywhere in OAM can be refreshed — with a length register alone only a prefix could be updated, making the saving illusory for sprites at high indices. Six moved entries = 48 bytes = 54–57 CPU cycles in VBLANK (8N + 6 … 8N + 9) instead of 1,030–1,033 — 54 exactly if the SDK follows the trigger with a non-write cycle, at any index; under active display the same transfer is bounded by the four-times range above — 198–201 cycles for six entries. OFS+LEN past entry 127 wraps within OAM; lengths 129–255 clamp to 128. Single entries can still be written through the ordinary VRAM port.

Sprites — OAM (in VRAM at OAM_BASE, 128 entries × 8 bytes = 1KB):

• Position: X,Y are 9-bit; the display origin sits at sprite-coordinate (64,64) — an on-screen pixel = (X−64, Y−64) — so a maximum-size 64 px sprite can be positioned fully off the top or left edge.
• Size: width and height independently ∈ {8, 16, 32, 64} px (1/2/4/8 tiles) — all four encodings of the 2-bit fields are assigned, so no value is undefined. A W×H-tile sprite occupies W·H consecutive tiles from its index in row-major order (left→right, then top→bottom). A 64×64 sprite costs 64 tiles and, at 8 tile-rows wide, one such sprite alone consumes a quarter of a line's sprite-pattern budget; the 32-sprites-per-line limit still applies by sprite, not by width.
• Sprites use sub-palette 2 or 3; index 0 transparent.

Recommended VRAM layout (all bases are register-relocatable):

Palette RAM is internal to oito, not in VRAM.

Per-pixel priority ladder (front → back). The topmost opaque pixel wins, tested in this fixed order:

Sprite per-line evaluation & overflow.

• Each scanline, oito scans its on-die shadow OAM (§6.5 — not VRAM) index 0→127 and collects sprites whose vertical span covers that line, up to 32 sprites and up to the per-line pattern-byte budget, whichever binds first (§6.5). Only the winners' pattern rows are fetched from VRAM. (Evaluation reads the shadow snapshotted at line 224 of the previous frame, so VRAM-port OAM writes land next frame; OAM DMA updates the shadow immediately.) Sprites beyond either limit are dropped for that line — lower OAM index always wins, and a sprite is admitted only if its whole pattern row fits in the remaining byte budget, so admission never depends on partial fetches. STATUS.3 sets if any line in the frame overflows and remains readable throughout VBLANK, clearing at the start of the next active frame (line 0) or on a write-1. Two accumulators are needed, not one, because line 0 of frame N+1 is evaluated during line 261 of frame N: an overflow there belongs to frame N+1 and must neither appear in frame N's latch nor be erased by the line-0 clear. oito keeps a current-frame latch, which STATUS.3 reads, and a next-frame accumulator written by line 261's evaluation; at the start of line 0 the accumulator is copied into the latch and then cleared. A W1C clears only the current-frame latch.
• The per-line limit is two limits, whichever binds first (§6.5): at most 32 sprites, and at most the pattern-byte budget the backgrounds and text leave — 512 when both planes are tile-aligned, 503 in the fine-scrolled hi-res worst case. A wide sprite costs one slot like any other, but it costs pattern bytes in proportion to its width, which is what the second limit exists to bound.
• Where sprites overlap on a line, lower OAM index draws on top (sprite 0 frontmost).

Collision.

• A collision registers wherever two rendered sprites both have an opaque (non-0) pixel at the same screen location — independent of which is visually on top and independent of the background. Sprites dropped by per-line overflow do not participate on that line.
• COLLIDE_A / COLLIDE_B ($4031/2) latch the first colliding pair in raster order (top→bottom, left→right) since the last COLLIDE_CLEAR; COLLIDE_A = lower index, COLLIDE_B = higher. COLLIDE_STATUS.1 (overflow) sets if further distinct pairs collide before the clear. The collision IRQ fires on the first latch.

Emulator note. Per visible line: take the ≤32 admitted sprites and both planes' tile data from the line buffer that the §6.5 fetch queue filled on the preceding line — not from VRAM as it stands now — then compose each pixel through the priority ladder (backdrop → BG/sprite levels → text → cursor), sampling palette and font RAM per pixel. The fetch order is part of the Tier-1 contract (§6.5): it decides CPU grants, blitter progress and whether a fetch saw a value before or after a blitter write. Tier 2 adds nothing here.

6.7 Raster timing

Both H-modes share identical line and frame timing — only the dot clock (hence horizontal resolution) changes — so switching resolution never re-syncs the display or the CH7035B. The CPU clock and the dot clocks are independent PLL outputs from the 21.47727 MHz master, so the dot count per line is exact even though the dot clock isn't a whole divisor of the master.

Common line & frame (both modes):

• Line = 1,365 master ticks = 455 CPU cycles = 63.56 µs; HSYNC rate 15.734 kHz (standard NTSC 240p).
• Frame = 262 lines = 357,630 master ticks = 119,210 CPU cycles; refresh 60.055 Hz.
• Vertical: 224 active + 38 blank (3 front porch, 3 VSYNC, 32 back porch). VBLANK = lines 224–261.

Horizontal — lo-res (256): dot clock ≈ 5.365 MHz, 341 dots/line = 256 active + 9 front porch + 25 HSYNC + 51 back porch.

Horizontal — hi-res (320): dot clock ≈ 6.702 MHz, 426 dots/line = 320 active + 14 front porch + 32 HSYNC + 60 back porch.

These porch/sync splits are pinned, not indicative. They fix HBLANK status timing, the CSYNC waveform the AD725 sees, the CH7035B qualification target and every mid-scanline effect, so they cannot be "fine-tuned" without a specification change and a re-issue of the conformance vectors. Changing them is a version bump (§18.1), not an implementation liberty.

Refresh, tolerance & compatibility. 60.055 Hz is the native rate — an NTSC-locked 240p line count does not land on an exact 60.00/59.94 with the ÷3 CPU line. The previous claim that "every 60 Hz display tolerates it" was an untestable universal and is replaced by a specification:

• Digital output is exact, not tolerant. The CH7035B frame-buffers and re-times to standard 1080p60 (60.000 Hz), so the sink always receives a compliant timing regardless of the input rate. This is why the digital path is compatible — a specification rather than a hope.
• Cadence: input and output differ by 0.09 %, so the scaler repeats or drops approximately one frame per ~1,100 (≈1 every 18 s). Stated as a number rather than "negligible".
• Analog outputs carry the native rate, quoted as a tolerance: 60.055 Hz ±0.01 % (+0.19 % relative to 59.94 Hz), line rate 15.734 kHz within ±0.1 % of NTSC. A display either accepts that or does not; the spec no longer asserts that all do.
• Compatibility is a test matrix, not an adjective. Validation set: consumer NTSC CRTs, PVMs, SCART CRTs, RetroTINK/OSSC-class upscalers, and capture devices — the same equipment as the AD725 240p validation, with results recorded.

When a register write takes effect — the complete latch table. A scanline renderer cannot infer this, and immediate, line-latched and frame-latched behaviour produce visibly different images, so every display-affecting register is classified here. There are exactly three classes:

Two columns are needed because the fetcher runs a line ahead of the beam: when a value is sampled and which picture line first shows it are different lines. There are three timing classes; the fourth row is not a class but an explanatory sub-row of per-frame, separated because cursor position and the cursor's appearance registers latch differently.

Font RAM is per-pixel, and saying so removes an ambiguity. A FONT_DATA write lands in font RAM and increments FONT_ADDR on the CPU cycle that performs it, with no queue and no shadow bank. Glyph rows are read by the compositor, per pixel — not by the fetcher — so a glyph byte written at master tick m is visible on every text pixel composited after m, including later pixels of the line already on screen. The previous "visible from the next line" promise became ambiguous the moment the fetcher moved a line ahead, since it did not say whether the sampling happened on the fetch line or the display line. Font RAM is dual-ported on the die — a single-entry write port against the compositor's read port — which is what makes a mid-line write safe without a commit mechanism. Cursor position — which the mouse updates continuously — is latched per frame at line 261, the same instant the hit-test coordinates latch (§9.2); applying PS/2 deltas per pixel would draw the top and bottom of a cursor at different X, and frame latching costs at most one frame of pointer lag while guaranteeing a cursor is never torn.

Resolution is per-frame because changing the dot clock mid-frame would change the line length, which §6.7 fixes at 1,365 master cycles. OAM_BASE is per-frame because sprite evaluation works from the line-224 shadow, so a mid-frame change would have no coherent meaning.

Emulator note. Model 262 lines × 455 CPU cycles/line; VBLANK on lines 224–261 (drives the VBLANK IRQ). The porch values above are needed for mid-scanline raster effects, HBLANK status and CH7035B input modelling; the active/blank split alone is what the renderer needs to draw a picture.

6.8 Text overlay layer

An optional monochrome character layer composited above both BG planes and all sprites — level 2 of the §6.6 priority ladder, beneath only the hardware mouse cursor (§9.2). It reuses the proven tile-plane and BG-scroll machinery; it has its own font, does not consume a BG plane, and its characters do not count against the 128-sprite / 32-per-line budgets. Characters cannot move independently or collide (§9 collision ignores this layer).

Transparent by default. The layer is a true overlay: each cell is transparent unless a glyph pixel is lit or the cell opts into an opaque background (textbox, below). When disabled (TEXT_CTRL.enable=0) the layer costs nothing.

Glyphs & font RAM. Characters are 8 pixels tall, 1bpp (glyph pixel = on/off). oito carries two 3 KB font-RAM banks (6 KB total; bank 0 = system default, bank 1 = cart font). Each bank holds both densities:

• 8×8 set — 2 KB (256 chars × 8 rows × 1 byte), used in 40-column mode;
• 4×8 set — 1 KB (256 chars × 8 rows × 4 bits, two glyph-rows packed per byte: the even row in the high nibble, the odd row in the low nibble, and within a nibble bit 3 is the leftmost pixel). The byte holding rows r and r+1 of character c is at $800 + c × 4 + (r >> 1), used in 80-column mode. A 4-pixel-wide glyph is a genuinely different bitmap, not a squeezed 8×8, so it is stored rather than derived — column-dropping an 8×8 face would mangle the letterforms.
• FONT_ADDR therefore spans 12 bits (0–3071) within the selected bank; the 4×8 set begins at offset $800.
• At boot, firmware copies the region default charset (ISO-8859-1 base; regional builds may ship Cyrillic/Kana) from the boot flash into bank 0 — 3 KB per region (both densities). Default font always survives, so system text (no-cart / error screens) works even mid-game. A cart font need only upload the densities it actually uses.
• A game uploads its own 256-glyph font from cartridge ROM into bank 1 through the font port (§5.1) — selecting the write bank with FONT_ADDR_HI bit 7, which is separate from the display bank so a game may rewrite the cart font while the default is on screen — then sets TEXT_CTRL.font_sel=1 to switch. The swap is instant and non-destructive.
• Only firmware may write bank 0. Bank-0 writes are accepted solely while the boot overlay is active (BOOT_SRC ≠ 2) and are silently ignored after handoff, which is what actually enforces the guarantee above that the default font always survives for system text. Without the gate, a game could overwrite bank 0 and break the no-cart/error screens.

Glyph width — two column densities (no new video timing):

• 40-column, 8×8 (default): 320/8 = 40 cols × 28 rows on hi-res; 32 cols on lo-res. Most legible.
• 80-column, 4×8 (TEXT_CTRL.narrow=1): a 4-pixel-wide glyph gives 320/4 = 80 cols × 28 rows at the same dot clock — this is how the 80×25 "2000-cell screen" is reached without a 640px mode. (A true 640px 8×8 text mode would need a second ~10.7 MHz dot clock and a 640-wide path through the CH7035B/DACs — deliberately not implemented; it would break the §6.7 shared-raster design.)

Placement — grid + fine scroll (not a second sprite engine):

• Cell grid (coarse) — fixed 80-cell stride: a character map in VRAM, one entry per cell = char code (1 byte) + attribute (1 byte). The map is a fixed 80 × 28 = 2,240-cell (4,480-byte) region with a row stride of 80 cells (160 bytes) in every mode; narrower configurations (cols = 32, 40 or 64) simply use the leftmost cols cells of each row and ignore the remainder.
• Why fixed rather than per-mode: a live resolution or narrow-mode switch then changes only how many cells are displayed, never where a cell lives — text at (col 5, row 3) occupies the same address in all four configurations, so switching mid-game never scrambles the screen or forces a re-layout. The cost is at most 4,480 B of 128 KB, partly unused in narrow modes: a trivial price for that property.
• No wrapping: cells beyond cols are not fetched, and rows beyond 27 do not exist.
• Scroll sign & range: TEXT_SCROLL_X/Y are unsigned 0–255, applied as a positive offset that shifts content up and left (so incrementing Y scrolls text upward — the natural direction for credits). Larger offsets simply push content off-screen.
• Off-screen cells are not fetched and cost no bandwidth: fine scroll moves the sampling window, it does not wrap content.
• Cells snap to the 8px lattice (4px in narrow mode).
• Whole-plane fine scroll: TEXT_SCROLL_X/Y apply a per-pixel offset to the entire text plane during compositing (same path as BG scroll, §6.2), positioning a text block at any exact pixel coordinate and enabling smooth credits/subtitles/tickers. It shifts all cells together; it does not move characters relative to each other.
• Free-floating single glyphs (a damage number, a bouncing letter) are drawn as ordinary 8×8 sprites from the font — a handful at most — rather than a 2000-entry per-line evaluator. re8 therefore does not build a character-OAM; arbitrary independent per-glyph positioning is out of scope by design.

Attribute byte (per cell). All colours are drawn from the layer sub-palette selected by TEXT_CTRL bits 5–6:

Per-cell inverse is deliberately dropped: it is exactly "swap the two colours", which an author encodes directly by choosing fg and bg in the same byte — spending a bit on a redundant operation would have cost background range. Four background entries is sufficient in practice (a panel colour plus a highlight for the selected row), and those entries can be chosen per sub-palette; foreground keeps all 16. The 2-byte cell stride is preserved — a 3-byte cell would have grown an 80×28 map from 4,480 to 6,720 bytes and broken easy addressing.

Blink & caret timing.

• One global 1 Hz counter with 50 % duty drives all blinking; its phase resets when TEXT_CTRL.3 transitions 0→1, so blink is deterministic and emulator-reproducible rather than free-running.
• A blinking cell alternates between its normal rendering and its background (transparent if attribute bit 6 = 0).
• The hardware caret (TEXT_CARET_X/Y) shares that counter and renders as a filled cell in the foreground colour of the attribute byte of the cell it occupies — not a fixed entry and not a separately latched value, so a caret moving across differently-coloured text takes each cell's own colour. If the cell is transparent the caret still paints; the attribute's foreground nibble is read regardless of attribute bit 6.
• Out-of-range caret coordinates simply do not render. TEXT_CARET_X ≥ the active column count (32/40/64/80) or TEXT_CARET_Y ≥ 28 hides the caret; no wrapping and no clamping. A caret pushed outside the visible sampling window by TEXT_SCROLL_X/Y is likewise clipped by the ordinary compositor clip, exactly as the glyph in that cell would be.
• Textbox: a rectangular run of opaque-background cells paints a solid dialogue or menu panel and its text within the text plane alone — no BG tiles, no sprites — and can slide in via fine scroll.

Cost & impact. Grid mode's per-line fetch ≈ one BG plane's worth (≤80 char codes + attributes; font rows come from on-die font RAM, not VRAM) — counted in the §6.5 budget, where text joins display priority. Silicon: +1 compositor level, +6 KB font RAM (2 banks × 3 KB), +char-map fetch, ~9 registers. VRAM: char map is a fixed 4,480 B (80×28) of 128 KB. No pins, no external parts, no video-timing change. Boot flash: +3 KB per regional charset (8×8 + 4×8).

Emulator note. A deterministic top-layer composite: char codes and attributes arrive through the §6.5 fetch queue on the preceding line; the glyph row is read from font RAM per pixel by the compositor and overlaid — honouring transparent/opaque, blink phase and the SCROLL_X/Y offset — after the sprite/BG composite.

6.9 Bus arbitration and ownership

This section is the single normative home for who owns which bus, when, and how ownership changes. Sections 6.5, 6.6, 8.3, 11 and 13 define the work performed after a grant; they do not define a second ownership protocol.

There are two independent buses:

The private VRAM bus has no ownership state: oito is its only electrical master. Its fixed request priority is display fetch > CPU port / OAM DMA > blitter (§6.5).

The host-bus state is:

owner ∈ { none, cpu, oito, probe }      -- exactly one value

owner = none is a real electrical turnaround state, not a fourth master. While it is active, every ordinary select is inactive and neither oito nor the probe may drive the host bus.

6.9.1 Requests, priority and host-owner transitions

At every arbitration point oito applies this total order:

“Completes” is deliberate: oito never suspends an OAM transfer or PCM burst and later resumes it. A probe request arriving during one waits for that bounded operation; no next internal takeover starts ahead of it. An OAM transfer remains non-abortable as §6.6 requires, and a PCM burst remains capped at eight bytes (§8.3).

Every change of electrical master includes a connector-level no-drive interval:

t_TA >= 1 PHI2 cycle = 139.7 ns

The interval starts only after the old master's last output is observed or guaranteed high-Z at the expansion-header connector; logic, buffer and board propagation occur before it. owner = none and every select remain inactive throughout it.

owner_transfer_accept(oito) is tied to a physical host-byte event, not to a generic “slot”:

6.9.2 Probe electrical topology and active-low enables

The receive path and drive path are electrically separate. No net joins two push-pull outputs, and no MCU pin is both a receive-buffer output and a drive-buffer input.

The other 12 header signals use 12 direct GPIO. The map is therefore 37 input/direct GPIO + 8 data-drive GPIO + 3 latch-control GPIO = 48, exactly the RP2350B total. The full package/PIO assignment remains a §16.2 gate; this count does not pretend to be that pinout.

The MCU controls values and the storage-latch edge, but does not control either outbound enable. These active-low equations are implemented by the exact LVC gates in BOM item 11f:

nDBACK  = NOT(DBACK)                              -- 74LVC1G04GV
/OE_ARW = nDBACK OR BE                            -- 74LVC2G32DP,125 gate 1
/OE_DATA = nDBACK OR (BE XOR R/W̄)                -- 74LVC1G86GV,125 + gate 2

probe_drive_addr = DBACK && !BE
probe_drive_rw   = DBACK && !BE
probe_drive_data = DBACK && (BE XOR R/W̄)

The equations produce these physical states:

Every /OE_ARW and /OE_DATA net has a passive pull-up, so a missing rail, invalid gate output or disconnected cable selects off. All named LVC parts specify Ioff partial-power-down behaviour. Gate and buffer propagation are included before the connector-level start of t_TA. DBACK is low whenever BE changes, and no storage-latch edge occurs during an access_phase; those sequencing rules prevent combinational enable glitches from becoming a drive pulse.

Within one OWNED interval DBACK stays high. Direction turnaround is local and does not re-grant ownership:

• read → write: finish the read and t_PHD; deassert its select; wait until the target is high-Z at the connector, then wait t_TA; place write data on the eight drive GPIO and latch the new address with R/W̄ = 0; only then request the write cycle;
• write → read: finish the write; latch R/W̄ = 1, which disables /OE_DATA; wait until D0–D7 are high-Z at the connector, then wait t_TA; only then request the read cycle;
• same direction: no drive-direction turnaround is required, but distinct external accesses still obey the 160.5 ns CĒ-high precharge in §11.

The first-transfer timer starts only on the explicit ACQUIRE_WAIT → OWNED_GRANT transition. It cannot restart on a direction change, and a jam grant cannot start it. The inter-transfer timer is restarted only by a validated OWNED request.

6.9.3 DBACK, DEBUG jam and probe ACQUIRE

DBACK means exactly one thing: oito authorises the probe's outbound hardware path. It is neither a ready signal (PHI2 is) nor the ownership state (owner is).

The jam sub-state machine is:

1. A committed ENTER DEBUG request blocks new internal steals; an active OAM transfer or PCM burst completes.
2. oito freezes the CPU using the external-write-safe RDY rule.
3. At a PHI2 falling edge oito asserts debug_select_suppress; every external select and internal register decode is inactive.
4. oito raises DBACK. On a CPU read/fetch, /OE_DATA becomes active and the probe supplies the byte. The byte is stable at least t_DSR = 15 ns before the falling edge and for t_PHD ≥ 20 ns after it.
5. On a CPU write—such as the stack writes in PHA, PHX, PHY and PHP—physical R/W̄ = 0 forces /OE_DATA inactive. The receive buffer remains enabled and the probe samples the pushed value at the falling edge. Restore instructions use the same rule: injected opcode/operand reads are driven; CPU writes are observed.
6. A committed STEP generates exactly one complete PHI2 bus cycle, then returns to the halted low phase.

There are exactly two ways out of jam:

• ACQUIRE: lower DBACK; wait until the D driver is high-Z at the connector plus t_TA; deassert debug_select_suppress at a falling edge; perform CPU→probe acquisition from §6.9.1; raise DBACK only after owner = probe.
• EXIT DEBUG: lower DBACK; wait for connector high-Z plus t_TA; deassert debug_select_suppress at a falling edge; then release the debug hold.

Thus the suppression window strictly contains the jam-drive window. No stable “DEBUG, no jam” state grants drive, and no implicit edge starts or ends jamming.

6.9.4 Relinquish, timeout and reset abort

All probe-owned returns to the CPU—normal RELINQUISH and every timeout—use one release-wait state:

1. lower DBACK, making every outbound enable inactive in hardware;
2. set owner = none and make every select inactive;
3. wait until every probe output is high-Z at the connector, then wait t_TA;
4. discard only probe-owned state (probe_transfer_pending, probe_access_phase) and re-present the preserved CPU transaction (§6.5);
5. set owner = cpu;
6. release BE, then RDY.

cpu_access_phase and probe_access_phase are distinct. Probe ownership preserves the CPU transaction; re-presentation produces exactly one falling CĒ edge for that transaction, not a duplicate.

Reset is necessarily different:

1. RES̄ forces DBACK low asynchronously, owner = none, and every select inactive;
2. if a probe or oito master held the bus, keep BE low until its connector outputs are high-Z plus t_TA; only then may BE be released while RES̄ remains asserted;
3. clear CPU, oito and probe transaction state, including pending, serviced, access phases, read-data latches and commit tokens;
4. keep owner = none for the entire reset assertion; set owner = cpu only on the separately defined reset-release event (§11.1).

7. Video output subsystem

Region: 60Hz-only, single global timing. No 50Hz PAL mode — games run full-speed worldwide and the HDMI output is region-agnostic 1080p60. Composite/S-Video use NTSC color (AD725 + 14.318MHz crystal); RGB SCART, DE-15 RGBHV and HDMI are region-agnostic (raw RGB / digital, no subcarrier) and work on any 60Hz-capable display. The only unsupported case is pure composite/S-Video into a 50Hz-only vintage PAL CRT.

One digital pipeline feeds all outputs simultaneously (no switching). Analog output stage. A single R-2R ladder cannot drive five outputs, so the buffering is specified rather than deferred (it consists of active parts and is therefore in scope, §1):

• One R-2R ladder set (R, G, B) is the sole source and is never loaded directly; each destination has its own buffer, so nothing double-loads.
• Ladder transfer function. Each ladder is 4-bit, R = 1 kΩ / 2R = 2 kΩ, 1 % thin film, driven from oito's 3.3 V CMOS outputs, giving an unloaded full scale of 3.3 V × 15/16 = 3.094 V at a source impedance of 1 kΩ.
• Loading, done properly. A 1 kΩ source into a 10 kΩ load loses 1/(1+10) = 9.1 %, not "<1 %" — the earlier figure was simply not the arithmetic. For loading below 1 % the total load must exceed 99 kΩ, so each buffer input network is specified at ≥100 kΩ and the OPA3691/THS7374 input impedances (both ≫ 1 MΩ) do not dominate it. The divider that sets each destination's level is part of that network and is counted in it, not added after it.
• Amplitude, with the back-termination included. A 75 Ω source resistor into a 75 Ω terminated input is a 2:1 divider, so the amplifier must produce twice the wanted level. For the standard 0.7 Vₚₚ at the display:

The AD725 branch is computed independently: it wants ≈0.714 V full scale at its own input, driven by the OPA3691 at unity gain into a high-impedance input with no back-termination, so its divider is 0.714 / 3.094 = 0.2308.

• Black level needs a clamp, not a bias resistor. AC coupling plus a fixed mid-rail bias removes the source's DC component but does not restore black level: the average picture level then moves the black reference and eats headroom, which is visible as brightness pumping on high-APL scenes. Each analog path therefore carries a back-porch clamp, gated by a clamp pulse derived from oito's HSYNC and asserted during the back porch (§6.7). Per-output levels, all into 75 Ω:

• Exact resistor values, tolerance stack-up, the INL/DNL that follows from 1 % parts, and the clamp circuit are a schematic-freeze deliverable (§16.2). What is fixed here is the source impedance, the ≥100 kΩ load rule, the three voltages above and the clamp requirement.
• SCART and VGA: one THS7374 each — 4 channels (RGB + CSYNC), integrated reconstruction filters, 2× gain, 5V single supply; 2× gain into a 75Ω series resistor produces the standard 0.7 Vₚₚ into 75Ω.
• AD725: a separate unity-gain buffer, because it requires ~0.714 V full-scale AC-coupled inputs with its own bias — which is why it cannot share the THS7374 outputs.
• SCART control: pin 16 held at 1–3V by a divider (forces RGB mode); pin 8 driven to 9.5–12V by an emitter follower from the 12V input rail (signals 4:3). This is why the input is 12V and not 9V (§2.1): a 9V rail cannot produce a voltage above itself, so aspect signalling would have needed a boost stage or would have had to be dropped, and dropping it also loses the TV's automatic input switching.
• Filtering: the THS7374's integrated filters suit 240p; a passive reconstruction filter follows the AD725 output.
• The analog stage runs from 5V and is included in that rail's budget (§2.1).

AD725 240p qualification. The AD725's application material specifies interlaced RGB at TV-standard rates and discusses equalisation/serration in composite sync, whereas re8 feeds it 262-line progressive 240p with a plain 3-line VSYNC and no equalisation pulses — the classic "240p is not a broadcast standard" situation. CRTs are tolerant; the encoder still has to lock subcarrier and vertical timing to a waveform its datasheet never promised. Two specific risks: colour-burst insertion and subcarrier phase across a 262-line frame (NTSC's 4-field colour sequence assumes 525-line interlace), and vertical lock without equalisation.

• Status: provisionally selected, pending bench validation — the same treatment as the CH7035B. Go/no-go: colour lock on 240p; correct burst insertion; stable vertical lock; acceptable output on representative CRTs and capture devices/upscalers (which are markedly less tolerant than CRTs, and are how most users will actually view this output).
• Sync waveform is normative, and stated line by line. oito emits negative-polarity HSYNC and VSYNC per §6.7 and derives CSYNC = XNOR(HSYNC, VSYNC) with both inputs active-low. Over a frame that produces:
• lines 0–223 and 227–261: one ordinary negative HSYNC pulse per line;
• lines 224–226 (VSYNC asserted): the output sits low for the whole line except where HSYNC is asserted, where it goes high — i.e. a broad, inverted vertical pulse interrupted at the horizontal rate. Those interruptions are what the XNOR produces and what a CRT or encoder uses to keep horizontal lock through vertical sync.

• No equalisation pulses and no half-line serrations are inserted; the horizontal-rate interruptions during VSYNC are the full-width HSYNC pulses themselves, not the half-line serrations of a broadcast interlaced signal. This is the "non-interlaced NTSC" convention consoles of the era used. Broadcast serrations are omitted; the XNOR's horizontal-rate interruptions are not — the two are different things.

• There is no fallback mode. The bench test is a go/no-go on the part. oito has one RGB bus, one sync set and one pixel clock, fanned to all five outputs, so any timing change reaches every output at once. A 480i contingency would therefore have been a second complete machine timing — different line and field totals, half-line sync, field parity, CPU cycles per line, CUR_LINE semantics, raster-IRQ positions, DMA windows and emulator behaviour — none of which was ever specified, and all of which software can observe.

• If the AD725 fails 240p qualification, it is replaced by an encoder that passes. That is the only outcome. §16.2 lists it as a schematic-freeze gate for exactly this reason, and §15 restriction 6 says 240p without qualification.

7.1 HDMI path (provisionally selected digital A/V design)

• Why a companion chip: 1080p60 needs a 148.5MHz pixel clock and 1.485GHz TMDS bit clock — impossible/uneconomical on the 130nm ASIC. DVI minimum pixel clock is 25MHz, so even raw 240p pass-through needs help. Candidate approaches rejected: RP2350/small-FPGA scaler (720p ceiling, RAM limits, 6-layer PCB for 1080p), plain serializers TFP410/ADV7513 (no scaling → TV compatibility risk at 240p), DisplayPort (no TV inputs), analog-only (pushes cost to user).
• What CH7035B provides: fixed-function display converter with integrated SDRAM frame buffer + frame-rate conversion, hardware scaler, HDMI/DVI transmitter (to 1080p), DDC master for EDID, hot-plug detect, and I²S audio inputs, which re8 uses (§8.4). Few dollars, no FPGA.
• Input-format mapping. The CH7035B's parallel input supports RGB-565 / RGB-666 / RGB-888 — not RGB-444 — so oito's 12-bit 4:4:4 bus cannot connect one-to-one. The scaler is therefore configured for 24-bit RGB-888 input, and oito's 12 lines fan out on the PCB with bit replication: R[7:4]←R[3:0] and R[3:0]←R[3:0] (same for G and B). Replication — not zero-fill — is required so full-scale white maps $F→$FF (100%) rather than $F0 (94%, a visibly dull white); it makes the 12-bit palette land exactly on the 8-bit range with correct endpoints. Cost: no extra parts and no oito pins — each of the 12 oito outputs drives two scaler inputs (fan-out of 2). The CH9904 EEPROM config must select 24-bit RGB-888 input (Strategy A, below).
• Configuration: self-boot — CH7035B acts as I²C master (SPCM/SPDM pins) and loads a fixed config from the CH9904 8KB I²C boot ROM at address 0x57 at power-on (that config selects 24-bit RGB-888 input, the fixed 1080p60 output, HDMI output mode rather than DVI, and the audio path: I²S slave input, 2-channel 16-bit LPCM, the Audio InfoFrame contents and N = 6144; the image is a versioned release artefact/E6). Zero CPU involvement; video alive even if the CPU crashed; no memory-map presence. The single shipping output mode is 1080p60 one fixed mode, no runtime switching.
• Sink handshake — fixed output, no EDID dependency. The CH7035B is not assumed to read EDID autonomously: the public brief describes HPD as raising an interrupt to a processor and EDID as read through programmed registers — both presuppose a host, and Strategy A deliberately gives the scaler none. re8 therefore does not depend on EDID at all:
• the scaler is configured once from EEPROM and drives 1080p60 unconditionally whenever powered — legitimate for a fixed-function console, since 1080p60 is the most universally supported digital TV mode and there is nothing to negotiate;
• failure mode, stated plainly: a sink that cannot accept 1080p60 shows nothing on the digital output; the remedy is the analog outputs, which is part of why re8 ships five;
• HPD is not acted upon — the output never varies, so nothing needs to change on hot-plug. Whether the part can be configured to enable TMDS independently of HPD is itself an open qualification item (§16.2), not an established property: the public material does not state it. If it cannot free-run, the digital output requires a connected, asserting sink, which for a fixed-function console is an acceptable but different behaviour that must be documented rather than discovered;
• connector-side circuit, not a checklist:
• +5 V (pin 18): fed from the 5 V rail through a TPS2553-1 current-limit switch set to a nominal 200 mA, using R_ILIM = 133 kΩ taken from TI's own selection table, not from arithmetic — the part's limit is inversely proportional to R_ILIM (≈26,600 / kΩ mA), so the 75 kΩ v0.4 named would have given ≈355 mA, not 250. The HDMI specification requires a source to supply at least 55 mA; 200 mA nominal clears that with room for cable inrush and the part's process/temperature spread. The final value must be re-derived from the datasheet's minimum and maximum equations including resistor tolerance before schematic freeze (§16.2).
• DDC (pins 15/16): routed to the CH7035B's DDC master through 1.8 kΩ pull-ups, the value its datasheet specifies for DDC_SC/DDC_SD, to a rail chosen per Chrontel AN-B008 — whose reference design isolates that rail specifically to stop a sink back-driving the console when it is off. Exact rail and isolation are a schematic-freeze deliverable (§16.2). DDC is routed, not omitted — that choice is made here rather than deferred, because a routed and an unconnected DDC are different schematics with potentially different compliance behaviour, and routing it costs two traces and keeps a future EDID read possible. The pull-up rail and its isolation device are the schematic-freeze deliverable; the topology is settled.
• HPD (pin 19): divided to 3.3 V and clamped, tolerant of the 5 V a sink may assert; it drives the scaler's HPD input, which the datasheet requires to carry a 47 kΩ pull-down.
• Receptacle: an exact model from HDMI LA's Approved Connector list. The licence requires every connector on a CTS 1.4b device to appear on that list by a single complete model number, not by a family or a generic "19-pin Type-A". Selecting it and recording its list status is a compliance gate (§16.2), and the BOM carries the chosen model once made.
• CH7035B reserved pins, per its datasheet: pin 43 to DVDD, pin 44 to DGND, pin 50 open or 10 kΩ to ground, and every unused D[23:0] input pulled low with 10 kΩ.

• TMDS pairs: 100 Ω differential, length-matched within 5 mil (0.127 mm) intra-pair, and 100 mil between pairs, per Chrontel AN-B008 §2.8.3 — not 5 mm, which is ~197 mil and misses the vendor's recommendation by about 39×, with a TPD4E02B04 0.3 pF ESD array per pair so the capacitance does not degrade the 1.485 GHz edges. The output topology is Chrontel's, taken from AN-B008 component for component — that note routes the TMDS pairs to the connector through its protection network and does not show series AC-coupling capacitors. Series AC-coupling capacitors would change the common-mode operating point and are not a layout preference. Every series and termination component is named in the schematic-freeze package (§16.2), and any departure from AN-B008 needs written Chrontel guidance. CEC is not implemented — a fixed-function console needs no consumer-electronics control, and implementing it would add silicon, firmware and compliance surface for no capability. (The former rationale, that the strict-DVI link could not carry it, no longer applies now that the link is HDMI.)

• Mode-switch tracking. Shared line/frame timing alone is not sufficient: constant HSYNC/VSYNC frequency does not tell a scaler where the active pixels are, and the two modes differ in dot clock (5.365 vs 6.703 MHz), total dots (341 vs 426) and active width. Resolution — two dot clocks are retained (§6.7 stands) and DE carries the active window: 1. oito outputs DE (data enable), marking the active rectangle explicitly in both modes, so the scaler locates active video by signal rather than by inference. Cost: +1 pin. 2. Both H-modes keep their native dot clock, so 256-mode still fills the screen on analog outputs (256 px at 5.365 MHz = 47.7 µs, identical to 320 px at 6.703 MHz). A single fixed 426-dot container with 256-mode pillarboxed is rejected: oito drives the analog R-2R ladder from the same RGB bus, so the pillarbox would appear on CRT as well as HDMI. 3. The burden therefore moves to the scaler: the CH7035B must track two input geometries from DE without reprogramming. This is added to the go/no-go qualification list (§16.2) rather than assumed, since the part is already provisional. If it cannot, the scaler is replaced. An oito-wide line-doubled 480p would have put 31 kHz on the SCART, DE-15 and composite outputs, which cannot accept it.

• Scaling — the required outcome, stated once. The digital output MUST be nearest-neighbour with no interpolation; bilinear is banned, because it destroys the pixel art the whole machine exists to draw. Integer scale factors are preferred but not required: 4× gives 1280×896 inside the 1080p raster and 5× with an overscan crop gives 1600×1120, both letterboxed, and a non-integer nearest-neighbour scale that fills more of the frame is acceptable. What is not acceptable is any filtering.

Whether the CH7035B accepts the two native input timings and performs genuine nearest-neighbour scaling is a qualification gate (§16.2), not an assumption — and it is a gate on the part, with replacement as the outcome if it fails. Once the part passes, the exact CH9904 register image, input and output timings, crop, scale ratio, measured latency and captured output are published as versioned artefacts (§16.3).

• Audio is embedded in the HDMI stream. oito's I²S port (BCLK, LRCLK, SDATA — three wires; the part has no MCLK pin) connects to the CH7035B's audio inputs, and the scaler packs it into TERC4 data islands with an Audio InfoFrame and an Audio Clock Regeneration packet. The stream is 2-channel 16-bit LPCM at 48 kHz nominal (±50 ppm, set by the AUDXI oscillator), which is the most universally supported HDMI audio format there is.
• Why a nominal 48 kHz and not the APU's native rate. HDMI's standard sample rates are the IEC 60958 set, and HDMI compliance testing exercises them specifically. A non-standard 47,940.3 Hz stream would in principle survive — the sink recovers the true rate from the measured CTS — but it would be a "most sinks cope" bet on the one path now subject to certification. Instead an output-path resampler (§8.4) converts the APU stream to a nominal 48 kHz, and N takes its standard value of 6144.
• This does not touch the APU or the conformance contract. The APU still mixes at master ÷ 448 = 47,940.3 Hz in a single clock domain, and §8.5's bit-exact golden audio vector is defined at its output. The resampler sits downstream, exactly as the delta-sigma PWM modulator does, and emulators do not model it.
• Clock domains and CTS. Audio arrives locked to the 12.288 MHz oscillator while the TMDS clock derives from the scaler's 27 MHz reference, so the two are asynchronous — which is precisely what the Audio Clock Regeneration mechanism exists to handle. Whether the CH7035B measures CTS correctly across its own frame-rate conversion is a qualification item (§16.2), not an assumption.
• No EDID needed, and this time that is a specification rather than a hope. 2-channel 16-bit LPCM at 48 kHz is the one audio format every HDMI sink is required to support, so re8 can transmit it unconditionally without reading EDID — which is exactly what the Strategy-A self-boot configuration does, since it gives the scaler no host to read EDID with. Choosing the mandatory format is what makes the no-EDID position safe for audio as well as video.
• No HDCP, no CEC, no ARC. None is required by HDMI and none is needed here: re8 transmits no protected content, a fixed-function console needs no device control, and there is no return path to use. Each would add a licence or a compliance surface for no capability.
• Cable & connector: a standard HDMI Type-A receptacle and an ordinary HDMI cable, carrying picture and sound together. The port is labelled HDMI.
• Licensing position — re8 is designed as an HDMI 1.4b source, and will be marketed with HDMI trademarks only after licensing and compliance close. The previous strict-DVI position existed to avoid the HDMI licence, and it worked, but it cost the one thing a console plugged into a modern television needs: sound on the same cable. That trade is no longer worth taking, so the design targets HDMI Adopter status and emits real HDMI. It is not a licensed product yet: HDMI LA treats a finished product as licensed only once its manufacturer is a registered Adopter and the product has passed self-test and Authorized Test Centre testing for the first article of its type. Both are open items (§16.2), so the HDMI name and logo may not be used on the product or its marketing until they close — and this document uses future tense until then. Commercial terms — publicly confirmable parts only. HDMI LA's registration page offers an Adopter option of $5,000 per year plus a $1.00 per-licensed-product administration fee, plus a royalty, and requires Authorized Test Centre testing of the first product of each type. The royalty rate, the volume band it applies to, and ATC cost are set out in current adopter materials rather than on the public page, so this document does not state them as technical facts. The per-console figure quoted in earlier revisions ("$3–4") assumed a royalty rate and a production volume neither of which is established here; it is withdrawn. Volume, royalty and test-cost arithmetic belong in a dated business model validated against the executed agreement, not in a hardware specification. What re8 implements: HDMI 1.4b, 1080p60, 2-channel 16-bit LPCM at 48 kHz. No HDCP, no CEC, no ARC. What remains for counsel: the Adopter Agreement itself, the trademark usage guidelines, and the certification path. This is now ordinary commercial licensing rather than the open legal question the DVI position left hanging — which is a real, if unglamorous, benefit of paying the fee.

8. Audio subsystem — the oito APU

A 16-voice hybrid APU integrated in oito — enhanced PSG + wavetable + PCM — sized to the graphics system. It needs no extra pins (output is still 2× PWM + I²S) and no external RAM (small on-die wave RAM; PCM streams from cartridge ROM).

8.1 Voice complement (16 total)

All 16 voices feed an internal digital mixer → stereo → a 2nd-order delta-sigma PWM stereo pair at master ÷ 8, which drives the active analog stage, and in parallel to the I²S port that carries HDMI audio to the CH7035B (§8.4). Output/mix rate is master ÷ 448 = 47,940.3 Hz.

8.2 Internal register file (via the $40A0 port, 16-bit internal address)

Port semantics ($40A0–$40A4). AUDIO_ADDR_L/AUDIO_ADDR_H form a 16-bit internal address; AUDIO_DATA reads or writes the addressed byte.

• When AUDIO_CTRL.0 is 1 (its reset value), the address post-increments by 1 after every AUDIO_DATA access, read or write alike, so block loads and block reads both work without re-addressing. When software clears that bit the address does not change, which is how a single register is polled repeatedly.
• The increment wraps modulo $10000. It is not clamped to any range.
• Writes to reserved or read-only addresses are discarded; reads of reserved addresses return $00. Both still increment the address.
• The CPU port and the mix tick never contend: the port writes into a shadow that the mixer samples at the start of each mix tick, so a mid-tick write takes effect on the next tick, deterministically. Wave-RAM writes are the one exception — they land in wave RAM immediately, which is what makes live waveform morphing audible within a tick.

PSG voice (8 bytes): +0 period[7:0] · +1 pulse: [0–3] period[11:8] (12-bit period), [6–7] duty (12.5/25/50/75%) / noise: [0–2] noise rate, [3] LFSR mode (0=15-bit long, taps 0⊕1; 1=short/periodic, taps 0⊕6) · +2 L volume (8-bit, 0–255) · +3 R volume (8-bit) · +4 ADSR attack[7:4]/decay[3:0] · +5 sustain-level[7:4]/release[3:0] · +6 sweep shift[2:0]/dir[3]/rate[6:4]/enable[7] · +7 key-gate[0]/enable[1]/retrigger[2].

Wavetable voice (8 bytes): +0 period[7:0] · +1 [0–3] period[11:8] (12-bit, same ÷12 tone clock) · +2 L volume (8-bit) · +3 R volume (8-bit) · +4 wave slot[3:0] (0–15 into wave RAM) · +5 ADSR attack/decay · +6 sustain/release · +7 key-gate[0]/enable[1]/loop[2].

All side volumes in all three voice classes are 8-bit, 0–255, so one mixing rule covers every voice.

PCM voice (16 bytes): +0…2 start address (20-bit linear cartridge-ROM byte address = the full 1MB cart space; stored in 3 bytes, top 4 bits reserved/must-be-0) · +3…5 loop address · +6…8 end address · +9…10 pitch (8.8 fixed point, $0100 = source rate) · +11 L volume · +12 R volume · +13 format[0] (0 = 8-bit PCM, 1 = 4-bit IMA-ADPCM) / loop-enable[1] / key-gate[2] / enable[3] / bits 4–7 reserved · +14…15 reserved, read $00.

Current position is not in the voice record — 16 bytes cannot hold three 20-bit addresses, a pitch, two volumes, a control byte and a 20-bit position. It is read from the separate $00B0 block above.

8.3 Behavior details (emulator-grade)

• Tone clock. Pulse and wavetable voices are clocked from a ÷12 prescaler off the master clock: 21.47727 MHz ÷ 12 = 1.7897725 MHz — exactly the NES APU clock, because both derive from the same 3.579545 MHz colorburst. Using the master clock directly (as originally written) put the lowest tone at 655 Hz ≈ E5 and made bass impossible.
• Pulse: 12-bit period → freq = 1.789773 MHz / (16 × (period+1)), giving 27.3 Hz (period 4095, below A0) to ~112 kHz (period 0) — a full musical range with an octave of headroom below the NES. Existing NES period tables port unchanged for 11-bit values. Duty as above. Noise: 15-bit LFSR clocked from its own noise-rate divider (unaffected); long mode taps 0⊕1, short mode 0⊕6.
• ADSR envelope (all voices): 4-bit attack/decay/release rate indices into a 16-entry ticks-per-step table, 4-bit sustain level; advanced per output sample; key-gate starts attack / release. Exact table and semantics in §8.5.
• Sweep (PSG): NES-style, clocked at a fixed 239.70 Hz (mix rate ÷ 200) and then divided again by the 3-bit rate field — each adjustment is period ± (period ≫ shift); rate 0 disables; out-of-range mutes (§8.5).
• Wavetable: the phase accumulator advances one of the slot's 32 samples every period + 1 tone ticks, giving 13.66 Hz – 55.9 kHz; samples are 8-bit signed. Wave RAM is CPU-writable through the audio port (live waveform morphing allowed).
• PCM — sample fetch by CPU-bus cycle-stealing. Sample data lives in cartridge ROM at 20-bit linear addresses spanning the whole 1MB cart. Because the cartridge is addressed by the CPU's own A0–A13, oito cannot fetch samples "independently"; instead oito briefly becomes a bus master, exactly as the NES 2A03's DMC channel does for DPCM: 1. a voice's read-ahead FIFO runs low and requests a refill; 2. the request enters the §6.9.1 priority and CPU→oito transition; an external write is never halted and an already-active OAM transfer completes first; 3. with owner = oito, oito drives A0–A15, R/W̄ = 1 and BANK0–BANK5 to the sample's linear address, and reads a burst of at most 8 bytes into the FIFO; 4. the §6.9.1 oito→CPU release-wait transition restores the preserved CPU transaction.

Bus-master timing (normative). WDC specifies that BE low tri-states Address, Data and R/W̄, so oito's R/W̄ pad is bidirectional and is driven high before address and throughout the steal. Ownership, BE, RDY and connector turnaround follow §6.9.1. Within the grant:

1. assert ROM_CĒ only after address, bank and R/W̄ = 1 are valid;
2. sample D0–D7 on the PHI2 falling edge after the flash access time; this edge is owner_transfer_accept(oito) for that byte;
3. deassert ROM_CĒ; repeat for the remaining bytes;
4. stop every oito host-bus output before entering the common connector-level t_TA release wait. A steal always asserts ROM_CĒ explicitly, so sample fetch is unaffected by SAVE_CTRL (§11.4) — that register redirects CPU accesses to $8000–$BFFF only, never oito's own bus-master cycles. PCM therefore keeps streaming correctly while a game has the save window open. A NOR read (~70 ns) does not fit one 46.6 ns master cycle, so each stolen access occupies a full CPU cycle (139.7 ns); bursting amortises the arbitration. 8-bit = signed raw; 4-bit = IMA-ADPCM (standard predictor + step-index table). Pitch resamples via the phase accumulator; loop between loop-address and end-address when loop-enabled. Because oito drives the bank lines during a steal, a sample may exceed 16KB and cross bank boundaries freely — unlike anything reachable through the CPU's window.

• Cost of streaming (a real, documented CPU tax). Workload: 4 PCM voices, 8-bit samples, unity pitch, 8-byte bursts. That is ≈192 K byte-fetches/s against 7.159 M CPU cycles/s → ≈2.7 % of cycles, rising to ≈6 % with per-burst arbitration overhead and shorter bursts. Fewer or 4-bit ADPCM voices cost proportionally less. Consequence: with PCM active the CPU's instruction throughput is below the nominal 455 cycles/line — see the determinism note in §3. Games needing a cycle-exact raster window can suspend PCM (audio.pcm_suspend, §14.2).
• Mixer: each voice → L/R accumulators (voice sample × envelope × side volume); sum 16 into a signed 24-bit accumulator → master L/R volume → hard-clamp (saturate) to 16-bit. That stream delta-sigma modulates the 2 PWM pins for the analog stage, and in parallel feeds the output-path resampler → I²S → HDMI (§8.4). Exact arithmetic in §8.5.

8.4 Output paths

Audio rides the HDMI cable and leaves on its own analog connectors, so every display arrangement gets sound.

Audio leaves the console three ways, all fed from the same mixer output (§8.5):

There is no optical S/PDIF: its transmitter is a last-time-buy part, and HDMI now serves the soundbar and AV-receiver case that optical used to.

The output-path resampler. The APU mixes at master ÷ 448 = 47,940.3 Hz, which is not one of HDMI's standard rates. Rather than bet certification on sinks honouring measured CTS over a declared rate, oito converts the stream on the way out:

• A 12.288 MHz oscillator (BOM 9b) drives oito's AUDXI input, and nothing else. oito derives BCLK and LRCLK from it and emits those two plus SDATA; no MCLK leaves the chip, because the scaler has no pin to receive it. It is a polyphase FIR, not a linear interpolator. Linear interpolation is not transparent merely because the ratio is near unity: its response is sinc² in the fractional phase, which droops −1.26 dB at 10 kHz, −2.89 dB at 15 kHz and −5.29 dB at 20 kHz, and because the fractional phase sweeps slowly across the whole interval, that droop modulates. Shipping it would make the HDMI output — the path most owners will use — audibly duller than the analog ones. The specification is therefore:

No filter is specified, and nothing below quietly reintroduces one. The only set this project ever published failed its own stopband; it now lives in §8.4.1 under a heading that says so, and nothing in §8.4.1 is normative. What is normative in §8.4 is the requirement, the parameter constraints above, the rate arithmetic, and the acceptance procedure below. Tap count T, phase count P, window, cut-off and coefficient width W are outputs of the design work, and the figures in the table above are targets, not achieved results.

The coefficient design is therefore a blocking deliverable (§16.2, §16.2.1), and the honest consequence is stated rather than softened: an implementer cannot build the resampler from this document today. Every other part of oito can be built; this block cannot, because its ROM depth, multiplier width, accumulator width, history length and latency all follow from parameters that do not yet have values.

The stopband edge is f_in − 20 kHz = 27,940 Hz, stated once. It is the lower edge of the first reconstruction image of the protected 0–20 kHz band, and at a 48 kHz output it aliases to about 20.06 kHz — so the end-to-end test must name which image it is measuring rather than treating 27.94 kHz as a directly representable output tone. Earlier revisions also said "the input Nyquist, 23.97 kHz", which is a single point rather than a band; that statement is withdrawn.

Acceptance is this executable procedure and nothing else — and its absence is why three attempts at measuring the rejected design produced three different numbers without any coefficient changing. The superseded criterion — "every one of the P quantised phases, evaluated on the assembled polyphase prototype" — is withdrawn as a category error, not merely reworded. A per-phase branch runs at f_in, so 27,940 Hz is above its Nyquist and is not a frequency that branch has; the interleaved prototype has one response, not P of them. Asking each phase for a stopband figure on the assembled prototype asks a question neither object answers. The committed acceptance script (§16.3) must define, and a candidate set must pass, all five:

Until that script exists and a coefficient set passes all five, no filter is specified.

• Nominal increment. f_in = master ÷ 448 = 21,477,270 ÷ 448 Hz exactly, f_out = AUDXI ÷ 256 = 12,288,000 ÷ 256 Hz exactly. The increment is computed from those integers — round(2³² × 21,477,270 × 256 / (448 × 12,288,000)) = $FFAE8982 — and not from the rounded decimal 47,940.3348, which would give $FFAE8980. One exact rational, one value.
• The increment is servo-trimmed, not fixed. The two oscillators are independent, each ±50 ppm, so their true ratio is not the nominal one and drifts with temperature. A fixed increment lets the FIFO walk off one end: at ±100 ppm worst case that is 4.8 samples per second, a drop or repeat every fifth of a second, audible as a periodic tick. The servo:

Stability is shown, not claimed. The plant is an integrator: over one update period a deviation δ in the increment moves the fill by −Kδ/2³², so the loop gain is g = K/2³² = 2⁻²⁰. With the PI law above the closed-loop characteristic polynomial is z² + (g·Kp + g·Ki − 2)z + (1 − g·Kp), giving poles at 0.912 and 0.822 — both inside the unit circle, overdamped, no overshoot. The slower pole gives a time constant of about 0.94 s and settling in roughly 3.8 s.

The previous design was integral-only — increment += e × 2¹² — whose poles sit at 1.000 and 0.996. That is marginally unstable: it does not converge, and with saturation and quantisation it becomes a limit cycle rather than a one-second settle. The proportional term is what moves the poles inside the circle.

Verification is required, not inferred: the RTL testbench must demonstrate settling time, peak FIFO excursion, absence of limit cycles, and correct behaviour at ±100 ppm corners in both directions over a run of at least 10⁸ output frames. One output frame, in full — the numeric tables above constrain the arithmetic but do not pick a unique sample sequence, so the order is pinned:

stereo_frame():                         # ONE call per output frame, both channels
    # prospective test first: never emit and then discover the FIFO was empty
    if (phase + increment) >= 2**32 and fifo.empty:
        underflow = 1                   # sticky
        return prev_L, prev_R           # phase, history and servo all unchanged
    ph    = phase >> (32 - log2P)       # top log2(P) bits select the phase
    coef  = ROM[ph * T .. ph * T + T - 1]
    # coef[0] multiplies the OLDEST sample in the window, coef[T-1] the NEWEST.
    # Phase 0 is aligned with the newest sample; increasing phase interpolates
    # forward, reducing group delay.
    outL  = convolve(histL, coef)       # both channels, ONE phase
    outR  = convolve(histR, coef)
    tmp    = phase + increment          # 33-BIT temporary, advanced ONCE per frame
    carry  = tmp >> 32 ; phase = tmp & 0xFFFFFFFF
    if carry: L, R = fifo.pop(); histL.shift_in(L); histR.shift_in(R)
    prev_L, prev_R = outL, outR
    return outL, outR

convolve(hist, coef):
    acc = 0
    for i in 0 .. T-1:  acc += hist[i] * coef[i]
    return saturate16( div_round_half_away( acc, DC_GAIN ) )   # NOT a shift

One call emits both channels and advances phase once. The previous scalar routine returned a single sample and advanced the phase, so calling it per channel advanced twice and calling it once produced only one channel. Carry is at most 1, because the increment is 32-bit (above), so at most one stereo frame is popped per output.

8.4.1 Rejected coefficient baseline — NON-NORMATIVE

Nothing in §8.4.1 is a requirement. This is the coefficient set the project published and then rejected, kept because the method is what the replacement must follow and because deleting a failure erases the reason for the constraint. It must not be implemented. Every literal in this subsection — 64 phases, 64 taps, 18-bit coefficients, 2**17, the 31.5 centre, the 32-sample delay — belongs to this rejected set alone and has no force in §8.4.

Why it was rejected — stated no more strongly than the evidence allows. This set is rejected because it has never been validated under §8.4's normative five-part procedure, which did not exist when it was written. That is the whole claim.

It is not claimed that the assembled prototype fails the ≥80 dB stopband. The number that prompted the rejection — a worst-phase −72.8 dB, against −96.3 dB for phase 0 alone — was produced by measuring each of the 64 phases as though it were the assembled high-rate prototype, and §8.4 now identifies that as a category error: a phase branch runs at f_in and cannot represent 27,940 Hz at all, while the assembled prototype has one response rather than P of them. A number obtained from a withdrawn measurement cannot be evidence for a conclusion under the procedure that replaced it. It is recorded here as a historical result under a superseded formulation, and as the thing that triggered the methodology review — not as a proven failure.

This matters more than it might look. Three attempts at measuring this set produced −72.8, −25.7 and −45.3 dB depending on formulation, with no coefficient changing. That spread is why the deferral exists, and it is exactly why the honest verdict is "not validated" rather than "failed" — the same discipline the rest of this document applies to numbers it cannot stand behind.

Two things did go wrong in the design method, and they survive the correction: the target came from a Kaiser order estimate, which predicts a single-rate filter's stopband and is not a substitute for measuring the actual polyphase set; and checking phase 0 alone would have shown a comfortable pass, because it is symmetric with a zero at Nyquist. That asymmetry is the reason §8.4's procedure tests the prototype and the branches as separate objects.

The rejected formula, in full — "Kaiser-windowed sinc" names a family, and every one of these choices changes the output:

for p in 0..63:                       # phase
  for i in 0..63:                     # tap
      # tap i is offset (i - 31.5) samples from the window centre;
      # phase p adds a fractional delay of p/64 sample.
      x      = (i - 31.5) - p/64.0
      s      = 1.0 if x == 0 else sin(pi*fc*x) / (pi*fc*x)     # fc = 2*21900/47940.3348
      beta   = 8.0
      r      = (i - 31.5) / 32.0                               # |r| <= 1 across the window
      w      = I0(beta * sqrt(max(0.0, 1.0 - r*r))) / I0(beta) # Kaiser, endpoints included
      h[p][i]= fc * s * w
  # quantise to signed 18-bit with unity DC gain per phase
  k        = 2**17 / sum(h[p])
  q[p][i]  = round_half_away(h[p][i] * k)
  # force the sum to exactly 2^17; residue goes to the tap of largest magnitude,
  # and on a tie to the LOWEST index i, so the choice is deterministic
  q[p][argmax_lowest_index] += 2**17 - sum(q[p])

Bullets specific to the rejected set, retained with it:

• The cut-off was normalised to the input rate, 47,940.3348 Hz, since that is the band being reconstructed. A replacement should keep that normalisation; the value of fc is a design output.
• The window was centred at 31.5, between taps 31 and 32, which is what made that kernel even-length linear-phase and gave its 32-sample group delay. The general statement is the (T−1)/2 − p/P expression in §8.4's table.
• I0 is the zeroth-order modified Bessel function, evaluated in the 50-digit context named in §8.4; the ROM hash, not the summation rule, is what implementations must match.

8.4.2 Rules that hold for whatever filter replaces it — NORMATIVE

These are independent of P, T and W, and survive the rejection above.

• Emit first, then advance. The output for a frame uses the phase in force when the frame began; the increment is applied afterwards. The opposite order shifts every sample by one output period.
• History orientation: hist[0] is the oldest sample in the window and hist[T−1] the newest; tap i multiplies hist[i]. The output corresponds to an input instant (T−1)/2 − p/P samples in the past, so the filter is causal; the "sample that has not arrived yet" phrasing of an earlier revision described a window the algorithm never had.
• div_round_half_away(a, d) is defined arithmetically, not as a shift: q = trunc(a/d), r = a − q·d; if 2·|r| ≥ d then q += sign(a). d is the per-phase DC gain, which is 2^(W−1). Writing round(acc >> 17) was meaningless — the shift has already discarded the fractional bits, so nothing remains to round, and on a negative accumulator a shift is a floor while trunc is not. Conformance vectors cover ±(2¹⁶−1), ±2¹⁶ and their neighbours.
• ROM layout: phase-major, tap-minor, P × T entries, signed values sign-extended into 32-bit little-endian words.
• Startup, as one state machine that fits the storage it has. The FIFO is 32 stereo frames, so it cannot itself hold T + 16 frames for any T > 16, and the rejected baseline's T = 64 would have needed 80 retained at once. The earlier three-step sequence was therefore not implementable as written. The consumer prefills the history as frames arrive, rather than after they have all arrived:

Peak simultaneous storage is T history registers + 16 FIFO frames, and the history registers already exist — they are not extra. So the sequence is realisable for any T, which the previous one was not.

• Pointer movement is ordinary FIFO popping, one frame at a time through the Gray-coded consumer pointer; no cross-domain reach is introduced.
• History order during prefill is the same as during operation: the first frame popped is the oldest, ending at hist[0].
• If the input pauses during prefill, the consumer simply waits — it stays muted, n holds, and nothing times out. A stalled prefill is silent, not faulted, because the alternative is emitting a partial window.
• Startup latency is T + 16 input frames (≈1.67 ms had T been 64); the group delay is inside that window, not additional to it.
• Underflow is the first branch of stereo_frame() above: prospective, before anything is emitted or advanced. Playback resumes on the first frame after the FIFO refills, with phase continuing from where it stopped, so an underflow costs exactly its own duration and leaves no permanent phase error.
• Overflow, in the producer's domain. Discarding "the oldest input frame" is a consumer-pointer operation and a Gray-pointer FIFO does not give the producer that reach. The rule is therefore inverted: on a full FIFO the producer drops the incoming frame rather than the oldest stored one, sets the same sticky bit, and does not move its own pointer. No cross-domain handshake is needed, which is the point.

• Left and right share the ROM and are computed in successive cycles from a common phase, so the two channels never drift.

• Conformance: the coefficient ROM, its generator script, a bit-exact input/output vector and the ±100 ppm corner run are named artefacts (§16.3). None of them exists yet, and an implementer cannot build the resampler from this text — not merely "cannot check it". The framing, rate arithmetic, servo, startup and I²S interface are complete; the filter is not, and §8.4's parameter constraints are what a design must satisfy, not a design.

• It is deliberately outside the conformance contract. §8.5's golden audio hash is taken at the mixer output, at 47,940.3 Hz, in the master clock domain — so the single-domain determinism that makes a bit-exact hash possible is untouched. Emulators do not model the resampler, exactly as they do not model the delta-sigma modulator; both are output-path analogue-facing stages.
• All three analog branches — jack, RCA and SCART — are fed from the mixer output directly, not through the resampler, so nothing about the analog sound depends on it.

Three wires go to the CH7035B, not four. The scaler's audio interface is I2S_CK (pin 58), I2S_WS (pin 57) and I2S_D/SPDIF (pin 56) — there is no MCLK input on the part, and oito therefore does not emit one. LRCLK = 48 kHz nominal, BCLK = 64 × fs = 3.072 MHz, both exact divisions of AUDXI (÷256 and ÷4). Standard I²S framing: one-BCLK delay after the LRCLK transition, MSB first, LRCLK low = left, 16-bit samples left-aligned in 32-bit slots. The scaler recovers its audio timing from BCLK/LRCLK alone, which is what a three-wire interface implies.

48 kHz is a documented input rate for the part: the datasheet lists 32, 44.1, 48, 88.2, 96, 176.4 and 192 kHz for its 2-channel I²S input, so the rate choice is supported by the device even though the surrounding HDMI behaviour is not yet qualified.

The protocol on those three wires is fixed; the electrical domain is not. oito's I/O runs at 3.3 V and the three signals go straight to pins 58/57/56, but the brief datasheet gives pin 56 (I2S_D/SPDIF) a 0–2.5 V signal level and publishes no V_IH/V_IL or absolute-maximum ratings for pins 56–58 in I²S mode. VDDIO = 3.3 V establishes the parallel-video bank, not necessarily these pins. The brief is ambiguous about whether 0–2.5 V describes only the default S/PDIF mode — and ambiguity is not evidence that a direct 3.3 V drive is safe. This is a schematic-freeze gate (§16.2), not a settled connection: closing it may require a three-channel level translator or moving those oito pads into a compatible voltage domain, either of which changes the BOM and the pin/power budget. Consequently §16.2.1's "board schematic capture is unblocked" is scoped to the deferred resampler and does not mean the board is otherwise closed.

Analog audio output stage. "PWM → RC → jack" is a filter with hopes attached, not a line output: wrong output impedance, no DC blocking, no defined level, and one node shared by two destinations that would load each other. Specified instead:

• PWM parameters: 2nd-order delta-sigma, 1-bit, clocked at master ÷ 8 = 2.685 MHz. Stating order and clock is what makes the filter designable and completes the emulator's output model.
• Reconstruction filter: 3rd-order active low-pass, −3 dB at 20 kHz, built around the line driver rather than a bare RC, so the carrier is attenuated hard instead of leaving noise in and above the audible band.
• Line driver: NJM4556AM, 5V single supply, 1 Vᵣₘₛ nominal output, ≤100 Ω output impedance, feeding the 3.5 mm jack, the RCA pair and the SCART audio pins through a separate series resistor per destination.
• Branch independence is partial, and the honest statement is bounded rather than absolute. One amplifier channel drives all three branches, so the series resistors reduce coupling but do not eliminate it: a shorted RCA cable, an unexpectedly low-impedance load, or a hot-plug transient still changes the shared amplifier's output current and can disturb the other branches. What is guaranteed is that each branch is short-circuit tolerant and no branch can pull another below 50 % of its nominal level under any legal load — and legal loads are line loads of ≥10 kΩ. If simultaneous independence under arbitrary loads were needed, it would take three buffers; it is not, and it does not.
• Mute is a circuit with a pin, a part and a pole count. The boundary is drawn inside oito: it evaluates

AUDIO_EN = rails_good AND AUDIO_CTRL.1 AND ( t > 50 ms since rails_good )

and drives the result on a dedicated AUDIO_EN output pin (§6.3 — this is a real signal in the budget, taking oito to 127 (§6.3), not the "existing mute pin" a previous revision referred to and which did not exist). rails_good reaches oito on its RES̄ input, which the supervisor already drives and which is asserted until every rail is valid, so no new input is needed; the 50 ms timer and the AND are on-die, where a timer is free and an external RC/Schmitt/AND network would have been three more parts.

• The switch is a bilateral analog switch, not a bare MOSFET. After the coupling capacitors the signal swings both sides of ground, and a single N-channel FET has a body diode that conducts on one polarity — it cannot mute. The part is a TS5A23159DGSR (TI dual SPDT, 5 V, low R_ON, audio-rated). Signal order, stated explicitly because the switch must sit on the mid-rail side where the signal never goes below ground:

driver + 3rd-order filter (mid-rail biased) → dual SPDT: COM = output, NO = signal, NC = mid-rail bias → branch split into three series resistors → one coupling capacitor per branch → connector

Switching to bias rather than open is what makes the transition quiet, and placing the switch before the coupling capacitors keeps it inside its 5 V single-supply analog range.

• Control polarity, corrected against the part's real function table. TI's TS5A23159 connects NC↔COM when IN is low and NO↔COM when IN is high. The previous table asserted the inverse, which meant reset, disabled audio and brownout all selected the signal path — the console would have come up unmuted and gone silent when playing. The signal is therefore renamed AUDIO_EN, active high for play, and the wiring is NO = signal, NC = mid-rail bias:

• The safe state is a pull-down to ground, not a pull-up to 3.3 V. The 3.3 V rail derives from 5 V, so the switch can be powered while 3.3 V is still ramping; a pull-up to that rail would be at 0 V precisely when it was needed, and could back-power the ASIC pad. A 100 kΩ pull-down to GND on the IN net is valid in every rail combination — 5 V only, 5 V + 3.3 V before reset release, normal operation, brownout, and both rails off — because ground is always present. Muted is the passive default by construction rather than by accident.
• Pad behaviour: AUDIO_EN is a plain push-pull output that is high-impedance until oito's I/O rail is valid, which is when the pull-down governs. Its reset state is recorded in the signal reset-state table of §6.3 — which now exists; an earlier revision cited it while §6.3 held only a pin count. It is not in §5.1's register table, because §5.1 covers registers and a pin is not a register.
• The 50 ms timer restarts from zero on any rails_good deassertion, so a short brownout re-mutes for the full interval.
• Two poles, not six. Muting before the split means one dual switch handles both channels for all three destinations — a deliberate shared stereo mute, rather than six switched conductors for three stereo branches. The three branches cannot be muted independently, which nothing requires.
• Failure behaviour, stated accurately. A switch stuck in the bias position leaves the output silent; stuck in the signal position it never mutes, which is audible at power-up but harmless. Neither failure passes DC into a load.
• Brownout re-asserts mute through rails_good, and reset holds it asserted because AUDIO_CTRL.1 resets to 0.
• The complete three-branch schematic — resistor and capacitor values, the mute switch, the ESD parts of §2.1, the ground scheme, and hot-plug and short-circuit test results — is a schematic-freeze deliverable (§16.2).
• DC blocking / bias: output coupling capacitors sized for 20 Hz into a 10 kΩ line load; mid-rail bias for single-supply operation. This is a line-output dimension and is the reason the jack is not a headphone output.
• Mute/pop: the driver stays muted until the supervisor releases reset and the APU is enabled, and re-mutes on brownout, so power cycling does not thump the speakers.
• Protection: series resistance plus coupling capacitors make the outputs tolerant of an indefinitely shorted jack.
• Connectors: a 3.5 mm TRS jack and an RCA pair, both stereo and both LINE LEVEL. Tip left, ring right, sleeve ground. Two connectors because AV amplifiers want RCA and powered speakers want the jack; a second connector costs a few tens of cents.
• The jack is not a headphone output, and the specification says so. The stage is dimensioned for a line load: coupling capacitors sized for 20 Hz into 10 kΩ, which into 32 Ω would put the corner at about 6.25 kHz, and a source impedance bounded only at ≤100 Ω, which into 32 Ω would attenuate severely. The NJM4556A's ±70 mA headline is specified into 150 Ω at a larger swing and supply than this stage runs, so it is not a 32 Ω guarantee either. Separately, there is no hardware volume control — level comes from an APU register that game software owns, which is not a safe way to drive something strapped to someone's head. Headphones require an external amplifier, and the documentation says so plainly rather than implying otherwise.
• The DE-15 carries no audio. The HDMI port carries audio embedded in the stream (§7.1).

Emulator model. Per output sample (~48 kHz): advance each active voice's phase accumulator and envelope, fetch its sample (pulse/noise/wave-RAM/PCM-from-ROM), apply envelope × L/R volume, sum all 16, apply master volume, emit stereo. Fully deterministic; no cycle accuracy required. The exact integer model is §8.5.

8.5 APU reference model

Voice layouts alone cannot produce identical audio across implementations; this section is the arithmetic contract. Every quantity below is an integer and every operation is exact — there is no floating point anywhere in the reference model.

Time base. A single free-running counter runs at the master clock. A tone tick occurs every 12 master ticks (1,789,772.5 Hz) and a mix tick every 448 master ticks (47,940.3 Hz). Both divisors are integers off the same clock, so the two rates stay in the exact ratio 112 : 3 forever and the model never has to resolve a fractional relationship.

Order of operations within one mix tick. Implementations MUST use this order; any other order produces different samples.

1. Latch the CPU-port shadow (§8.2) into the live register file.
2. Advance the sweep divider; if it fires, apply sweep to every enabled PSG voice.
3. Advance every voice's envelope by one step if its envelope divider fires.
4. Advance every voice's phase accumulator by the tone ticks that elapsed since the previous mix tick.
5. Sample every voice, in voice-index order 0…15.
6. Mix, apply master volume, saturate, emit one stereo frame.

Global registers ($00A0–$00AF).

Envelope (ADSR, all voices). Attack, decay and release are 4-bit rate indices into this table of mix ticks per level step; the envelope level is 8-bit and every step moves it by exactly 1.

The ladder doubles every two indices, so a full 0→255 attack spans 256 ticks (5.34 ms) at index 0 to 65,536 ticks (1.367 s) at index 15. It is a literal table, not a runtime exponential: implementations MUST use these sixteen numbers. Key-gate 1 starts attack from the current level; attack rises to 255, then decay falls to sustain << 4, where the level holds; key-gate 0 starts release, which falls to 0.

Pulse. freq = 1,789,772.5 / (16 × (period + 1)); the phase accumulator advances one of 16 phase steps every period + 1 tone ticks. Duty 12.5/25/50/75 % selects how many of those 16 steps are high. Output is +127 while high, −127 while low.

Noise. 15-bit LFSR, shifted right, feedback into bit 14 = bit0 XOR bit1 (long) or bit0 XOR bit6 (short). Reset seed = $0001; the all-zero state is unreachable by construction. Output is +127 when bit 0 is 0, −127 when it is 1. The 3-bit noise-rate field selects tone ticks per shift:

Sweep (PSG). The sweep divider fires at 239.70 Hz = mix rate ÷ 200, a fixed integer divider. An exact 240 Hz would require ÷199.75, which no divider can produce; nothing musical depends on the 0.13 % difference. The 3-bit rate field then selects how many divider firings pass between adjustments:

Each adjustment computes period ± (period >> shift) (dir 0 = add, 1 = subtract). A result below 8 or above $FFF mutes the voice until it is re-keyed; the period register itself is left at the last in-range value.

Wavetable. The phase accumulator selects one of the slot's 32 samples and advances by one sample every period + 1 tone ticks, so freq = 1,789,772.5 / (32 × (period + 1)) — 13.66 Hz to 55.9 kHz. No interpolation (nearest sample — it matches the aesthetic and is cheaper). Phase resets to 0 on key-on. Samples are 8-bit signed and used directly as the ±127-range waveform. loop = 1 cycles the table indefinitely; loop = 0 plays exactly one pass and then holds sample 31 until release.

PCM — stream contract.

• Pitch is 8.8 fixed-point; $0100 means one source sample is consumed per mix tick, so the source rate is the mix rate, 47,940.3 Hz. Authoring at that rate gives unity playback.
• Start, loop and end are always byte addresses, for 8-bit PCM and 4-bit ADPCM alike. ADPCM never counts in nibbles.
• End address is exclusive. On loop the position returns to the loop address.
• At key-on: position = start, predictor = 0, step index = 0, and for ADPCM the low nibble of the start byte is consumed first.
• Malformed ranges are defined, not undefined. If end ≤ start the voice keys off immediately and sets its $A5 flag. If the loop address is outside [start, end) it is treated as equal to start. Addresses beyond the physical cartridge read $00 per §11.1, which for ADPCM is a valid (silent-ish) nibble pair rather than a fault.
• IMA-ADPCM: the tables and decoder below, low nibble consumed first within each byte, with per-voice predictor and index. At the loop point the predictor/index snapshot taken when the loop address was first reached is restored — without which looped ADPCM drifts. If loop == start, that snapshot is the key-on state.
• FIFO: each voice has a 16-byte read-ahead FIFO and requests a refill when 8 or fewer bytes remain. Underrun holds the last output w (no click) and sets the $A5 flag; it never stalls the mixer.

FIFO refill arbitration. "Round-robin" alone did not say how many voices refill per tick or where the pointer starts, and the stolen CPU cycles are software-visible against raster IRQs, so this is pinned:

• A refill request is raised in step 8 of the tick's event order (§6.5) — after the step-7 mix tick that drains the FIFOs — by every voice at or below its threshold, tested in ascending voice order.
• At most one voice is granted per mix tick. A rotating pointer selects the first requesting voice at or after it, then advances past the granted voice; it starts at voice 0 on reset. Four starved voices are therefore served over four consecutive mix ticks, in rotation, never simultaneously.
• A grant transfers min(8, free_space, bytes_until_end) bytes — capped at 8, unconditionally. Bounding it only by free space was not enough: the 8.8 pitch field lets a voice consume up to 255 source samples in one mix tick, so it can go from above threshold to empty in a single tick and its next grant would be a full 16 bytes. Capping at 8 makes the arbitration cost a genuine maximum rather than one that holds only under unity pitch. Each byte occupies one full CPU cycle (§8.3) plus 2 CPU cycles of arbitration overhead per burst.
• Tax, and this time it is a maximum. One grant per mix tick of 8 + 2 = 10 CPU cycles gives 10 × 47,940 = 479,404 cycles/s, or 6.7 % of the CPU, and the 8-byte cap makes that a true ceiling under any pitch. At unity pitch a voice drains 8 bytes in 8 ticks, so four streaming voices need one grant every other tick: ≈3.4 % sustained, consistent with the 2.7–6 % of §8.3.
• The steal cannot begin on an arbitrary tick, and its placement is defined for all three CPU phases. Mix ticks recur every 448 master ticks and CPU cycles every 3; 448 and 3 are coprime, so a mix tick lands on each of the three phases in turn and the first stolen cycle must wait for the current CPU cycle to finish. From the mix tick at master tick m:

PHI2 falls at integer ticks 3k (§6.5), and the refill request is raised at step 8 of tick m. Whether RDY reaches the CPU before the next falling edge therefore depends on m mod 3:

The next falling edge strictly after step 8 of tick m is always 3 × (⌊m/3⌋ + 1) — the next multiple of 3 above m. When m mod 3 = 0 the edge at tick m is step 0 of that same tick and has therefore already passed by step 8.

In every phase the cycle in progress reaches its hold edge and the CPU halts there. "Completes" was the wrong verb and mattered: WDC holds the processor in its current state at a low-RDY edge, so the cycle is re-presented rather than finished, and only the edge that accepts it may fire its side effects (§6.5). There is no phase that defers by an extra cycle, and the halt rule is one expression rather than three cases. The shortest path is phase 2, not phase 1, and it leaves 31.6 ns for oito logic, the output pad and the open-drain RDY pull-down — thin enough to remain a measured gate (§16.2), comfortable enough to promise.

This corrects a real error rather than restating a choice. Earlier revisions gave these edges as m+1.5, m+0.5 and m−0.5 and derived from them an 8.3 ns phase-1 budget, a "phase 2 has already missed the edge" case, and a normative freeze making phases 1 and 2 defer. All of that was computed against half-tick falling edges, which §6.5 withdrew: with edges on integer ticks the arithmetic gives 3/2/1 ticks and no phase misses. The 8.3 ns figure, the deferral freeze and the phase-1 qualification gate are withdrawn together — a number and every conclusion drawn from it.

The hold edge lands at m+3, m+2 or m+1, and BE follows one tick later, so the steal begins 2–4 ticks after the mix tick depending on phase, and its whole span is determined by m and m mod 3. The "1–4 ticks" of earlier revisions was the half-tick arithmetic's shortest case and is withdrawn with it.

One deferral applies on top, and it is bounded. oito never stalls a cycle that emits an external write strobe (§6.5) — an asynchronous pulse qualified by PHI2 high is already 54.8 ns into a 69.8 ns write by the time RDY must be valid, so a hold edge cannot prevent it and a repeat would repeat it. When the cycle that would otherwise be held is an external write, oito evaluates the next cycle instead. The longest run of back-to-back external writes a 65C02 produces is the interrupt/BRK push sequence (PCH, PCL, P, all to the stack in system RAM), so the delay is at most 3 CPU cycles = 9 master ticks, and the worst-case onset is 13 ticks after the mix tick. Writes to oito's own registers are unaffected — they emit no external pulse and are held normally. The deferral is deterministic: an emulator sees the same R/W̄ and decode and computes the same delay.

This does not change the tax, only the latency. The 8-byte cap and one-grant-per-mix-tick rule are untouched, and 9 master ticks against a 448-tick mix period is 2 % of one period against 8 mix ticks of FIFO headroom — it cannot cause an underrun. OAM DMA does not inherit these three cases. A refill arises on a free-running mix tick, so m mod 3 genuinely varies; an OAM transfer is triggered by a CPU write, and every CPU write retires on the same falling edge, so it has one trigger phase. That is not the same as a constant cost: the trigger phase is fixed, but the first hold edge still moves by 0–3 CPU cycles depending on the external writes that follow (§6.5), so a blanking transfer costs 8N + 6 … 8N + 9 (§6.6). An earlier revision said "always costs 8N + 6" here, conflating one trigger phase with no deferral and negating §6.6. Both get published waveforms (§16.2).

• Current position (readable at $00B0 + 4n) is the byte address of the byte from which the most recently output sample was taken, and it updates in step 7 of the mix tick. For ADPCM both nibbles of a byte report that byte's address.

PCM voice — the complete per-tick algorithm. The 8.8 pitch field needed a resampler definition, not just a unit; this is it. phase is a 16-bit unsigned fractional accumulator, zeroed at key-on.

tick(voice):                              # once per mix tick, in voice-index order
    if not enabled: return held_w
    phase += pitch                        # 8.8; carry counts whole source samples
    steps  = phase >> 8                   # 0 … 255 source samples to consume
    phase &= 0x00FF
    for i in 1 .. steps:                  # ALL skipped samples are decoded, never jumped
        if fifo_empty:
            underrun = 1 ; $A5.voice = 1
            return held_w                 # hold, do not advance position
        held_w = next_sample(voice)       # advances position and ADPCM state
    return held_w                         # pitch < 1.0 repeats the held sample

• Add-then-consume, in that order. phase accumulates before samples are taken, so pitch $0100 consumes exactly one sample per tick from the first tick onward.
• No interpolation — the last decoded sample is held. Consistent with the wavetable rule and with the aesthetic.
• Every skipped sample is decoded. At pitch > 1.0 an ADPCM voice must run its decoder over each consumed nibble, because the predictor is stateful; skipping ahead would desynchronise it. This is why steps is a loop and not an address addition.
• Underrun mid-loop stops the whole tick: position and ADPCM state stay exactly where the FIFO ran out, so playback resumes seamlessly rather than jumping.
• next_sample consumes one byte (PCM8) or one nibble (ADPCM); on reaching the end address it either wraps to the loop address, restoring the predictor snapshot, or keys the voice off.

IMA-ADPCM — the literal decoder. "Standard IMA-ADPCM" names a family, not an algorithm: the table values, the reconstruction order, the saturation points and the clamp are all needed for a bit-exact hash. index is 0–88 and predictor is signed 16-bit.

step_table[89] = 7,8,9,10,11,12,13,14,16,17,19,21,23,25,28,31,34,37,41,45,50,55,
    60,66,73,80,88,97,107,118,130,143,157,173,190,209,230,253,279,307,337,371,408,
    449,494,544,598,658,724,796,876,963,1060,1166,1282,1411,1552,1707,1878,2066,
    2272,2499,2749,3024,3327,3660,4026,4428,4871,5358,5894,6484,7132,7845,8630,
    9493,10442,11487,12635,13899,15289,16818,18500,20350,22385,24623,27086,29794,32767

index_table[16] = -1,-1,-1,-1,2,4,6,8, -1,-1,-1,-1,2,4,6,8

decode(nibble):
    step  = step_table[index]
    diff  = step >> 3                       # the +step/8 bias term
    if nibble & 4: diff += step
    if nibble & 2: diff += step >> 1
    if nibble & 1: diff += step >> 2
    if nibble & 8: predictor -= diff
    else:          predictor += diff
    predictor = clamp(predictor, -32768, +32767)
    index     = clamp(index + index_table[nibble], 0, 88)
    return predictor

Bit 3 is the sign, bits 2–0 the magnitude; the shifts are unsigned (step is positive), the predictor clamps to signed 16-bit after each update, and the index clamps to 0…88. w is then clamp(asr(predictor, 8), −128, +127) per the mixer table above.

Waveform domain — what w actually is, per voice class. The mixer takes a signed value w; each class produces it differently, and the conversions are normative because they are where implementations silently diverge:

−128 is a legal value and is not folded to −127. The asymmetry is real and both hardware and emulator must carry it. On FIFO underrun or a frozen voice the held value is whatever w was last output, including −128.

Mixer. With e the 0–255 envelope and volL/volR the 0–255 side volumes:

s    = w * e                       ; −32,640 … +32,385
Ln   = asr(s * volL, 8)            ; −32,640 … +32,385
Rn   = asr(s * volR, 8)

asr(x,k) is defined as floor(x / 2^k) — an arithmetic shift with floor rounding, so asr(−1,8) = −1, not 0. This is spelled out because >> on a signed value means floor in some languages, truncation toward zero in others, and was undefined in older C; they differ on every negative product and would break the golden hash.

All 16 Ln sum into a signed 24-bit accumulator — wide enough that overflow is impossible, which is why the width is 24 and not 20. Then:

outL = clamp( asr(accL * masterL, 10), −32768, +32767 )

>> 10 is >> 7 for the unity-128 master volume plus >> 3 of headroom. A single voice at maximum contributes asr(127 × 255 × 255, 8) = 32,258, so eight simultaneous maximum-amplitude voices reach 32,258, about 1.6 % below full scale, and nine or more saturate. clamp is hard saturation to $7FFF/$8000.

Minimum intermediate widths, all exact and none relying on wrap: w × e 16-bit signed, s × vol 24-bit signed, the accumulator 24-bit signed, acc × master 32-bit signed. That stream feeds the delta-sigma PWM pair and the I²S port.

Enable, key-gate and retrigger.

• enable = 0 freezes the voice: phase, envelope and LFSR hold, and the voice contributes 0 to the mix. Setting it to 1 resumes from the frozen state.
• key-gate drives the envelope only, as described above. It never resets phase.
• PSG retrigger: writing 1 resets the phase accumulator to 0, reloads the LFSR with $0001 and restarts attack from the current level. The bit self-clears in the same mix tick and always reads 0.

Reset. All voice registers, envelopes and phases zero; $A0/$A1 = 128; output disabled. Wave RAM is undefined at power-on and is zeroed by boot firmware (§11.1).

Conformance. A golden test hashes the mixer output of a fixed register-write script plus a fixed sample ROM; any implementation must reproduce the hash bit-exactly. The script, the sample ROM and the expected hash are named release artefacts (§16.4).

9. Controller input

• 2× DB9 (DE-9) front ports, Sega Genesis/Mega Drive pinout; 3-button and 6-button pads supported (including modern remakes/clones).
• Controllers are powered at 5V (their internal 74HC157 needs it); each port's 4 joystick-only data lines pass inbound through a 74LVC244APW,118 translating 5V→3.3V into oito; the 2 PS/2-capable data lines use the specified bidirectional front-end (4.7kΩ pull-up to 5V, 1kΩ series into the receiver, BSS138 gate-driven pull-down) so oito can also drive them low without ever seeing 5V; and SELECT is driven outbound by a 5V-powered SN74AHCT125 — a 3.3V LVC output does not guarantee the ~0.7 × V_CC ≈ 3.5V high that the controller's 5V 74HC157 needs, which would make the 3-button multiplex and the 6-button handshake unreliable. One quad AHCT125 serves both ports' SELECT with channels to spare. LVC inputs are 5V-tolerant when the part is powered at 3.3V, so there is no clamp-diode conduction; per-port series resistors and ESD/TVS protection are added at the connector (board-level). The buffers are always-enabled translators (oito reads the pad state directly — §6.3).
• Read protocol (3-button): console toggles SELECT (DB9 pin 7); two button banks appear on the same six data lines:

• Architecture: controller data lines are routed into oito (6 data + 1 SELECT per port; §6.3), not onto the CPU data bus. oito latches pad state, exposes it in JOYPAD_1/2 ($4070/$4072) and their _EXT companions (§5.1), performs the SELECT toggling, and does edge detection in silicon — which is what makes the input-change IRQ (IRQ_STATUS bit 2, flagged per-source in INPUT_STATUS $4074) real. External LVC-class buffers still translate 5V→3.3V feeding oito.
• Software model: read $4070–$4073 (canonical §5.1). Edge detection (pressed = current & ~previous) is available either in the SDK's VBLANK handler or directly from oito's change latch.
• 6-button protocol. oito performs the Sega handshake in hardware; the pad's internal counter advances on each TH toggle. Pad outputs are active-low on the wire (0 = pressed) and oito inverts them, so JOYPAD_x reads active-high (§5.1). TH = DB9 pin 7. One acquisition is 8 samples with ≥2 µs settling after every TH change:

Device identification:

• 6-button ⟺ sample 6 reads D0–D3 = 0000 (the identification phase) and sample 8 reads D0–D3 = 1111. Both phases are required. Sample 6 is the third TH-low, where a six-button pad drives all four low to announce itself.
• 3-button ⟺ sample 6 shows the ordinary Up/Down/0/0 pattern → JOYPAD_x_EXT = 0; samples 1–2 carry every button.
• Master System pad ⟺ no TH multiplexing (TH is its Light-Phaser input), so samples do not vary with TH → treated as 2-button (mapped to A/B), EXT = 0.
• Unplugged ⟺ every line high in every one of the 8 samples, including the TH-low phases where any real pad drives D2/D3 low. This is why identification cannot rest on sample 8 alone: an unplugged port also reads 1111 there, so the single-sample rule declared empty ports to be six-button pads. Reported as no buttons and no signature, deliberately indistinguishable from "nothing pressed".
• Malformed/unknown → oito reports only the sample-1/2 subset and clears EXT; garbage is never latched into EXT.

Timeouts: the pad counter self-resets after ~1.5 ms of TH-high, so the mandated >2 ms idle guarantees each acquisition begins at counter state 0; an acquisition aborted mid-sequence simply retries after the idle. Game code never sees the protocol.

• Scan rate & latency. Sega's acquisition sequence requires TH to remain high for >2 ms between acquisitions so the pad's internal counter resets, which sets the cadence:
• one full sequence ≈ 50 µs (8 TH transitions with ≥2 µs settling after each change), followed by the mandated >2 ms TH-high idle → an acquisition cycle of ≈2.5 ms per port (≈400 Hz);
• worst-case button-to-register latency ≈2.5 ms, not ≤250 µs. Still well inside one 16.6 ms frame, so the "sub-frame, invisible to games" conclusion holds;
• the same cadence is used for 3-button pads (which have no such constraint) so there is one timing model to verify and emulate;

• validation required against representative original and modern clone pads. Registers reflect the most recent acquisition; INPUT_STATUS / change-IRQ fires when a polled state differs from the last.

• Emulator input model. Frame-granular input is not conformant: the hardware acquires at ≈400 Hz (≈2.5 ms) and raises change IRQs asynchronously, so a frame-granular model cannot reproduce sub-frame transitions, mid-frame IRQ timing, or a press-and-release inside one frame (entirely possible at 2.5 ms granularity). Since the change IRQ is a headline feature that games will use, its timing must match. Instead:

• Input is a queue of (timestamp, device, state) events, timestamped in CPU cycles since frame start, applied during the scanline loop exactly as raster and blitter events already are.
• The acquisition cadence is modelled, not the protocol: the emulator samples host input at ≈2.5 ms intervals and emits an event only on change — reproducing latency and change-IRQ timing without simulating a single TH edge (TH sequencing stays internal to oito, as above).
• Keyboard and mouse events carry their own timestamps from the PS/2 stream, driving KBD_SCAN / MOUSE_* / INPUT_STATUS at the correct cycle.
• Tiers: Tier 1 may quantise events to acquisition boundaries (~2.5 ms); Tier 2 places them at exact cycles. Both must fire the change IRQ at the modelled time — frame-granular input is conformant at neither.

9.1 Keyboard input — PS/2, via the controller ports

re8 supports a PS/2 keyboard with no dedicated connector and no new oito pins — it reuses a controller port. This unlocks keyboard-native genres (strategy, simulation, text/RPG, dev tools) while keeping all existing joystick games playable on a keyboard.

Bidirectional PS/2 host in oito. oito contains a small PS/2 host state machine on two of a port's data lines. On receive, the device drives the clock (~10–16 kHz) and DATA; oito samples DATA on each CLK falling edge, assembles the 11-bit frame (start + 8 data + parity + stop), checks parity, and pushes the byte into a small FIFO (KBD_SCAN, §5.1). On transmit (host→device — the mouse enable command §9.2, keyboard LEDs/config, and the identification sequence below), oito pulls CLK then DATA low through the external FETs and clocks out its command frame per the state machine below. Receive and transmit are separate oito pins: the receive path is a 74LVC244APW,118 input, and the transmit path is a push-pull gate-control output into a BSS138 — one line cannot serve both, which is why the pin budget carries four gate-control pins (§6.3). The two lines therefore carry ~4.7 kΩ pull-ups to 5V and a pull-low-only drive capability — a small front-end change on just those two of the six data lines (the other four data lines + SELECT keep the plain 74LVC244APW,118 input path). oito is only ever in the 3.3 V domain; it drives low through the open-drain device and reads through the 5V-tolerant path.

PS/2 line circuit. Per line (CLK, DATA), per port — a specified circuit, not a menu of alternatives:

Why gate-driven rather than the classic BSS138 bidirectional shifter: in this topology oito's pin never sees 5V — only the FET drain does, while the gate stays in the 3.3V domain and the source is grounded. The familiar bidirectional level-shifter arrangement ties both rails through the FET body diode, which is acceptable for 3.3V↔5V I²C but would give 5V a route toward the ASIC. Rise-time budget: PS/2 runs at 10–16.7 kHz (≥30 µs half-period); 4.7 kΩ with a realistic 50 pF gives τ ≈ 235 ns and a full rise ≈1 µs (~2 % of a half-period), and even a pessimistic 150 pF gives ≈3 µs.

Port mode & joystick-safety invariant. Mode selection is explicit, because the DB9 provides no plug-detect event and identification itself requires driving the lines:

• Every port is in joystick mode at reset, and oito never transmits in joystick mode — the gate-control outputs are held low, so both FETs stay off. The invariant is now non-circular: drive only where software has declared the port to be PS/2.
• PORT_MODE ($407C) holds 2 bits per port: 0 = joystick (reset default), 1 = PS/2. Only PS/2 mode releases the transmitters.
• Who sets it: the boot firmware's setup menu (a keyboard or mouse is a deliberate accessory purchase, so a one-time setting is reasonable), persisted in the boot flash; a game may also request it through re8.keyboard/re8.mouse.
• Passive hint — receive only, never drive. A PS/2 device spontaneously transmits its BAT-completion $AA ≈0.5 s after power-up with no host action. In joystick mode oito may therefore listen: a well-formed 11-bit frame with valid parity on an otherwise idle port sets PORT_HINT in KBD_STATUS, meaning "a PS/2 device may be attached here". Firmware can offer to switch modes. This recovers most of the convenience of auto-detection with zero risk to a joystick, since nothing is ever driven.
• Identification proper (Reset/Identify handshake, §9.1 below) runs only after the port is in PS/2 mode.
• The safety rule is conditional, and the condition is PORT_MODE. While a port is in joystick mode the FETs are held off and a controller's push-pull outputs are never contended — that part is unconditional. But software may set PORT_MODE = 1 on a port with a joystick attached, and oito will then pull CLK and DATA low during reset and identify, against the pad's driven-high outputs. The BSS138 and the 1 kΩ series resistors bound the resulting current to roughly 5 V / 1 kΩ = 5 mA per line, which neither device is damaged by, but it is contention. Mitigation is procedural: the boot menu sets the mode with the console powered down and prompts for a power cycle, and the SDK's re8.keyboard/re8.mouse request path checks PORT_HINT first before asking for PS/2 mode.
• In joystick mode the weak 5V pull-ups do not disturb joystick lines (a controller's push-pull output overrides a 4.7 kΩ pull-up) and are conventional for such inputs. Ports are independent, so mouse on one + joystick on the other (or keyboard + mouse) run without interaction.

PS/2 protocol & identification state machine. Runs only once PORT_MODE = PS/2. Reset returns $FA (ACK) then $AA (BAT pass); it is $F2 Identify that returns ID bytes — two distinct operations.

Host→device frame: pull CLK low ≥100 µs (inhibit) → pull DATA low (request-to-send) → release CLK → the device clocks out 11 bits (start, 8 data, odd parity, stop) → device returns an ACK bit → host releases both lines.

Every byte is acknowledged individually. A multi-byte command such as $F3 $C8 or $F0 $02 is two host→device frames, and the device returns $FA after the command byte and after the parameter byte. The rows above are written compactly; the wire protocol is not. Consequently:

• the host waits for each $FA before sending the next byte, with the ordinary 25 ms per-byte timeout;
• a $FE RESEND retransmits only the byte that was not acknowledged, not the whole command, within the 3-attempt cap;
• a timeout or a third failed retry abandons the whole command sequence and marks the port failed — a half-applied $F3 with no parameter is never left on the wire.

Error and recovery states:

• $FE RESEND received → retransmit the last byte, maximum 3 attempts.
• Parity error on receive → host sends $FE; same retry cap.
• Timeout — ~750 ms for Reset, ~25 ms for other commands — → mark the port failed.
• BAT failure ($FC) → treat as a failed device.
• Liveness and hot-unplug — polled, not inferred from silence. An idle keyboard sends nothing, and a stream-mode mouse sends nothing while it is still, so "no valid frame for 2 s ⇒ unplugged" would have disconnected a perfectly healthy device the moment the player stopped typing. Instead oito polls: every 1 s of receive inactivity it sends $EE Echo (keyboard) or $EB Read Data (mouse) and expects a reply within 25 ms. A device is declared gone only after three consecutive missed polls (~3 s worst case). Any spontaneous frame resets the inactivity timer, so an actively used device is never polled at all. On declaring the device gone: clear present(), flush the scan FIFO, clear every injected joypad bit, and drop this port as a pointer source (§9.2 arbitration).
• Failure has a defined resting state. On any failed or timed-out state oito drives both gate outputs low, releasing the lines, and then:
• PORT_MODE for that port is forced back to 0 (joystick) by hardware. Without this the port sat in PS/2 mode with nothing driving it, and neither the spec nor software could say whether pad registers were live.
• KBD_STATUS.0 (present) clears, the scan FIFO flushes, injected joypad bits clear, and the port is dropped as a pointer source (§9.2).
• Joystick acquisition restarts at the next 2.5 ms boundary, so JOYPAD_x becomes meaningful again within one acquisition cycle.
• INPUT_STATUS.0/.1 sets for that port, raising the input-change IRQ if unmasked, so software learns the mode changed without polling.
• There is no automatic retry. Software or the boot menu must set PORT_MODE = 1 again deliberately; an automatic retry loop on a port with a joystick plugged in would drive the lines repeatedly.
• PORT_HINT listening resumes, since the port is back in joystick mode where that mechanism is defined.

Passive DB9↔PS/2 adaptor (no MCU). The DB9 already carries +5V and GND, and PS/2 keyboards are 5V devices, so the adaptor is pure wiring: DB9 pin 5→PS/2 +5V, DB9 GND→PS/2 GND, and two DB9 data pins→PS/2 CLK and DATA (mini-DIN-6). When a keyboard is on a port, oito routes those two data pins to the PS/2 host instead of the joypad mux (mode set explicitly via PORT_MODE; KBD_STATUS.present flags a device once identified); the port's other lines and SELECT are unused. The same passive adaptor serves a mouse (§9.2) — identical wiring, since a PS/2 mouse is the same 4-wire interface.

Keyboard resource rules.

• FIFO depth 16 bytes — ample at ≈2.5 ms per frame against a VBLANK-rate drain, including multi-byte sequences and burst typing.
• Two keyboards: if both ports are in PS/2 keyboard mode, the lower-numbered port owns the scan FIFO and the other's data is discarded — merging two streams buys nothing for a degenerate case.
• Hot-unplug (the polled liveness rule, §9.1) flushes the FIFO, clears present(), and clears every injected joypad bit, so a yanked cable cannot leave a button stuck on.
• Lock keys and LEDs have an owner. By default (KBD_CTRL.4 = 0) oito owns them: it toggles CapsLock, NumLock and ScrollLock on the make event only — never on break, and never on typematic repeat, so holding CapsLock toggles once — updates KBD_MODS/KBD_LEDS, and queues an $ED Set-LEDs command with the new state. With KBD_CTRL.4 = 1 software owns them: oito stops toggling and sends $ED only when the CPU writes KBD_LEDS.
• LED command failures are bounded. $ED follows the ordinary per-byte ACK and 3-retry rules; if it still fails, oito abandons that update and leaves KBD_LEDS at the value software asked for — the register is the source of truth, and the LEDs are cosmetic. It does not mark the port failed for a cosmetic command.
• A layout change does not reset locks. Layout tables map scan codes to characters and are entirely a firmware/SDK concern; lock state lives in oito and survives.

Key→joypad injection (compatibility). When a port is a keyboard, oito can map a fixed key set (arrows→D-pad, and e.g. Z/X→A/B, Enter→Start) straight into a chosen player's JOYPAD registers (KBD_CTRL bits 1–2; map in KBD_MAP_IDX/VAL, firmware-loaded defaults). The mapping happens below the game, so every existing joystick title becomes keyboard-playable with zero game or SDK cooperation — a raw $4070 read just sees buttons. Keyboard-aware games disable passthrough (joypad_passthrough(false)) while taking text, so typing keys don't also fire buttons.

SDK & firmware. Keyboard-aware games use the re8.keyboard module (§14.2) for cooked characters, a line-input field widget (echoes into the §6.8 text overlay + hardware caret), raw make/break key events, and modifier state. Scan-code→character translation uses a region keyboard-layout table in the boot flash, selected to match — and shipped alongside — the §6.8 region charset (US/UK/DE/…). Cooked characters are Latin-1 codes, identical to the §6.8 glyph indices, so echoing typed text is a direct write.

Impact.

• oito: bidirectional PS/2 host, scan FIFO, key→joypad LUT and the KBD registers ($4075–$407A) — no new pins and no new connector.
• Board: on the two PS/2 lines per port, the circuit specified in §9.1 (shared with the mouse, §9.2). The 5V rail budgets 250 mA per port / 350 mA total for accessories, with the per-port current-limit switch at ≈500 mA.
• Firmware: region layout tables (small).
• Restrictions: PS/2 only — USB-HID would need a host stack, which is out of scope. With two ports total, keyboard use is typically one joystick + one keyboard. Simultaneous-key limits come from the keyboard's own matrix ghosting, not the interface: PS/2 is NKRO-capable.

Emulator note. Host keystrokes → the KBD_SCAN FIFO (Set-2 make/break) + the same key→joypad injection; layout translation and the field widget are SDK-side. Fully deterministic; the PS/2 bit-timing is internal to oito and need not be simulated.

9.2 Mouse input & hardware cursor

re8 supports a PS/2 mouse on a controller port (same passive adaptor, §9.1) with a fully hardware-rendered cursor: the game sets a cursor graphic once and thereafter only receives move/click events — oito owns all cursor rendering and all mouse-hardware interaction.

Why the §9.1 host is bidirectional. Unlike a keyboard, a PS/2 mouse reports nothing until the host sends Enable Data Reporting (0xF4) (plus optional sample-rate/resolution and the Microsoft wheel "knock" sequence). That host→device path is exactly the bidirectional PS/2 upgrade folded into §9.1; the mouse is the reason for it. After the $F4 enable (§9.1 state machine) the mouse streams 3-byte packets (button byte + signed X delta + signed Y delta), or 4-byte once the IntelliMouse wheel is enabled by the 200/100/80 sample-rate knock and confirmed by an Identify returning $03. A second 200/200/80 knock, attempted only if the first succeeded, negotiates Microsoft's 5-button extension (ID $04). The fourth byte differs between the two:

MOUSE_STATUS bits 4–5 report which protocol is live. Without the second knock the buttons 4/5 the register map advertises could never be reported, because ID $03 has nowhere to put them.

A plain three-button mouse is fully supported and is not a failure case. If the first knock does not return $03 the device stays at ID $00 and streams 3-byte packets — button byte, signed X, signed Y, with no fourth byte at all. MOUSE_STATUS reports protocol 0, present is set normally, MOUSE_WHEEL reads 0 and never changes, and MOUSE_BUTTONS bits 3–4 read 0. The packet length oito expects follows the negotiated protocol, so the receiver must not assume four bytes;A receiver that assumed four bytes would reject the most common mouse there is.

oito maintains the cursor; the game does nothing to draw it.

• Position from deltas. Mouse motion is relative. oito accumulates the signed deltas, scales them by the game-set velocity/sensitivity (CURSOR_SCALE, fixed-point) with an optional 2-tier acceleration, and clamps to the active screen (or to CURSOR_BOUNDS if a sub-rect is set). The game never handles raw deltas unless it wants them.
• The cursor is the new top-most composite layer — above everything, including the §6.8 text overlay, so the pointer is always visible. It draws from VRAM at CURSOR_TILE (4bpp, index-0 transparent, sub-palette selectable): one 32-byte tile in 8×8 mode, or four consecutive tiles (128 bytes) in 16×16 mode, arranged row-major — index+0 top-left, +1 top-right, +2 bottom-left, +3 bottom-right, the same convention as multi-tile sprites (§6.6). No H/V flip is provided — a pointer never needs it. It is positioned so the game-specified hotspot pixel (CURSOR_HOTSPOT_X/Y, the pointer tip within the tile) lands on the logical cursor coordinate. Reported click coordinates are at the hotspot. It does not count against the sprite budget. Changing the pointer graphic (arrow→hand→busy) is a single CURSOR_TILE write.
• Events only. The game reads MOUSE_X/Y (absolute, at hotspot), MOUSE_BUTTONS (L/M/R + btn4/5), MOUSE_WHEEL (signed accumulator), and is notified on move / button-change via the input-change IRQ (INPUT_STATUS, shared with joypad/keyboard).

Cursor arithmetic. Cursor feel is immediately noticeable to players, so none of this is left to implementers:

• CURSOR_SCALE is 3.5 fixed-point in bits 0–6 (1.0 = $20), usable range 0.03125–3.96875, because bit 7 is the acceleration flag and cannot also be a magnitude bit. A value of 0 is treated as 1.0, never as "frozen" — a pointer stuck by a zeroed register is a nasty failure mode. Fractional remainders are retained between packets, so slow movement is not lost to truncation; this is what makes fine positioning feel correct.
• Acceleration (CURSOR_SCALE bit 7): when |delta| > 4 in a packet the scaled result is doubled. One threshold, one multiplier — deliberately simple and exactly reproducible.
• Rounding truncates toward zero after scaling; results saturate at the clamp/bounds rather than wrapping.
• Mouse Y is inverted on input (PS/2 reports +Y as up, the screen counts downward), and a packet's X/Y overflow bits mean "discard this delta" — an overflowed delta carries no usable magnitude.
• D-pad fallback (no mouse present): 1 px per frame initially, accelerating to 4 px per frame after 250 ms held; diagonals move both axes at the full rate (no √2 compensation — simpler, and indistinguishable at these speeds).
• MOUSE_STATUS bits 1–3 clear on a read of MOUSE_STATUS itself, not on reads of X/Y/buttons — "since last read" now names which read.
• Coordinate atomicity: reading MOUSE_X_LO latches MOUSE_X_HI and MOUSE_Y into a shadow, so a packet arriving mid-sequence cannot tear the pair; LO→HI→Y always yields one coherent position.
• MOUSE_WHEEL saturates at ±127 rather than wrapping, and clears on read.
• The rendered cursor position is frame-latched at line 261, the same instant the pick coordinates latch (§6.7 latch table). Deltas accumulate continuously into an internal position, but the compositor uses the value latched at line 261 for the whole frame. Applying deltas per pixel would draw the top and bottom halves of a moving cursor at different X — visible tearing on exactly the object the eye is tracking. The cost is at most one frame (16.6 ms) of pointer lag.

Pointer ownership — mouse-first, single source. Several devices can potentially move the cursor, so oito arbitrates to exactly one authoritative source at a time, defaulting to the physically-connected pointing device:

1. A detected PS/2 mouse owns the pointer — D-pad and keyboard cannot move it (two mice: lower port wins).
2. With no mouse present, the pointer follows the game-designated fallback = a chosen player's D-pad (CURSOR_CTRL bit 7). Keyboard arrow keys reach that D-pad through the §9.1 key→joypad injection, so "keyboard moves the pointer" needs no separate path.
3. Hot-plug takes over: attaching a mouse seizes the pointer; removing it reverts to the fallback. Never additive.

System pointer without a mouse. Because oito already turns deltas into a rendered cursor, menus and point-and-click UIs get a working pointer via the D-pad fallback even with no mouse attached, at zero extra game cost. The game may override the default arbitration with CURSOR_CTRL.source (auto / mouse-only / D-pad-only / off) for accessibility or a deliberate control scheme.

Hit-test sampling timing. Which scroll and sprite state a pick reflects depends on exactly when it is taken:

• The sample is taken when the raster reaches the pick point — during that active pixel — latching whatever the compositor computed there. This is the natural implementation (it taps the existing compositor) and automatically yields the scroll, OAM and palette state in effect at that pixel, with no extra bookkeeping.
• The pick coordinates and the cursor position are latched at the start of line 261, alongside the other frame-latched registers (§6.7), so mid-frame writes to PICK_X/Y — or moves of the cursor hotspot — take effect next frame. Line 261 rather than line 0 because that is when line 0's sprites are evaluated; one instant serves both. Otherwise a game writing PICK_X after the raster had passed that line would receive a result for a point the beam never sampled — nondeterministic and unreproducible.
• HIT_STATUS.5 ("sample valid") sets when the raster passes the pick point and clears at the start of line 0. A pick point outside the active area simply never sets it that frame — a defined "no result" rather than stale data.
• Results persist until the next frame's sample overwrites them, so the natural read time is during VBLANK, right after a click is noticed.

This deliberately mirrors the shadow-OAM decision: one named event, inputs latched at frame start, results read in VBLANK — two features sharing a single timing idiom.

Hardware hit-testing ("pick"). oito already computes, per pixel, which sprite and which BG cell win the composite — so it reports what is under the pointer at the cost of one coordinate comparator and a few latches. Once per frame — at the moment the raster reaches the cursor hotspot or the game-set pick point (timing above) — oito latches into the pick registers ($40C0–$40CF, §5.1): the topmost opaque sprite index under the point (HIT_SPRITE, 0xFF = none → maps to a game object); for each BG plane, the name-table cell (col,row) and the tile ID under the point, with scroll/wrap already applied (→ indexes a tile-grid map array directly); and HIT_STATUS flags (sprite present / plane-A opaque / plane-B opaque / a 2-bit winner field naming the layer that actually shows). On a click the game reads these directly — no pixel→cell math, no scroll compensation, no per-object bounding-box tests on the CPU — turning "what did the player click?" into a register read. The pick point defaults to the hotspot; a game may set an arbitrary PICK_X/Y to probe any location (e.g. what lies ahead of a projectile), making it a general hit-test facility. The cursor and text-overlay layers are excluded (you get what's under the pointer). Silicon cost: one coordinate comparator plus the latches listed in §5.1, tapping the existing compositor.

SDK. re8.mouse (§14.2): present(), set_cursor(TILE, hotx, hoty), set_speed(n), set_bounds(...), show()/hide(), on_move(&fn(x,y)), on_button(&fn(buttons)), on_wheel(&fn(delta)), and pollable x()/y()/buttons().

Impact: oito +mouse-packet parser + position accumulator/scaler/clamp + the top-layer cursor compositor (1 tile in 8×8, 4 in 16×16) + the MOUSE/CURSOR registers ($40B0–$40BF, §5.1); the bidirectional PS/2 host is already counted in §9.1. No new connector; no new pins (the two PS/2 lines are the same bidirectional port I/O). Board: shares §9.1's pull-ups + open-drain drive; a PS/2 mouse draws only 20–50 mA, well within the §2.1 per-port allowance. VRAM: the cursor is one existing tile (8×8) or four (16×16). Restrictions: PS/2 only; a mouse occupies one of the two ports (so joystick + mouse, or keyboard + mouse — not all three).

Emulator note. Host mouse deltas → the scaled position accumulator → top-tile cursor composite; buttons/wheel → events. Fully deterministic; the PS/2 packet timing is internal to oito.

10. Interrupts

• Single IRQ line from oito to the CPU. NMI unused ($FFFA/B → the address of a real RTI instruction in the fixed bank). Vectors at $FFFA–$FFFF: at power-on these are the boot ROM's (overlay active); after the boot handoff (§11.1) they are the cartridge's (reset $FFFC/D → game entry; IRQ $FFFE/F → the syslib __irq_entry trampoline, which calls the RAM-installed handler via a pushed return address + JMP ($0014) — §14.4).
• IRQ sources — five, matching IRQ_ENABLE/IRQ_STATUS (§5.1): bit0 VBLANK (60Hz), bit1 sprite collision (mid-frame, at the overlap moment), bit2 input change (joypad 1/2, keyboard scan-code, or mouse event — INPUT_STATUS $4074 says which; §9/§9.1/§9.2), bit3 raster-compare (RASTER_CMP $4004), bit4 blitter-done.
• Dispatcher contract (per canonical map §5.1): read IRQ_STATUS ($4002); bit0 = VBLANK, bit1 = collision (then read COLLIDE_A/B $4031/2, then write 1 to COLLIDE_CLEAR $4033), bit2 = input change (read INPUT_STATUS $4074 to see which of joypad-1/2, keyboard or mouse; then read JOYPAD_x / KBD_SCAN / MOUSE_* and write 1 to the serviced INPUT_STATUS bits), bit3 = raster-compare, bit4 = blitter-done. Acknowledge by writing 1 to the serviced IRQ_STATUS bits. prog8 binding: sys.set_irqd() → sys.set_irq(&dispatcher) → sys.clear_irqd(); handler returns 0 (consume) or 1 (fall through to system routine).
• Acknowledge & priority: IRQ_STATUS is write-1-to-clear and there is no fixed hardware priority — the dispatcher reads IRQ_STATUS and services bits in whatever order it chooses. The exact semantics, all software-observable:
• IRQ̄ = NOT(any(IRQ_STATUS & IRQ_ENABLE)) — asserted low, purely combinational from the two registers, not an edge or a latch of its own.
• Masked events still set IRQ_STATUS. The mask gates assertion, never recording — which is exactly why a source can be polled while its interrupt is disabled (the basis of INPUT_IRQ_MASK).
• Enabling a mask for an already-pending event asserts IRQ̄ immediately, which follows from the combinational definition and is what prevents lost interrupts.
• Set and W1C-clear in the same cycle: the set wins (the bit stays set), per the global W1C precedence order of §6.5 — automatic clear, then the CPU mask, then the hardware set — which applies identically to IRQ_STATUS, STATUS.3, INPUT_STATUS and KBD_STATUS.2.
• IRQ_STATUS bits are edge-latched: set by the event, cleared only by W1C. VBLANK latches at line 224, blitter-done at the final byte written, raster-compare at the start of the compared line. (They are deliberately not level-derived: a level-derived VBLANK bit would re-set the instant it was acknowledged during VBLANK, producing an interrupt storm.)
• STATUS ($4003) bits 0–1 are level, not events — they report in VBLANK / in HBLANK, i.e. current raster position, and are not acknowledged.
• INPUT_STATUS.2 re-latches immediately if keyboard FIFO data remains, because it reflects FIFO non-empty — a level. A handler MUST drain the FIFO, not merely acknowledge.
• Raster-compare fires at the start of the compared line (CUR_LINE == RASTER_CMP, evaluated at line start). Values > 261 never fire. Writing RASTER_CMP after that line has passed takes effect next frame — there is no retroactive firing.
• Timing: VBLANK window = 38 lines ≈ 52,000 master ticks; conversation's collision latency storyboard: silicon detect at t=0, IRQ ~1µs, dispatch ~3µs, user callback ~5µs.
• Main loops either while true (event-driven model) or the WAI instruction to sleep until VBLANK. Handlers set flags; the main loop does the work — the normative idiom, since only @irqsafe routines may be called from interrupt context.