Graphics Backend Micro-Codes

1. Overview

Yes: the SNES PPU's Mode 7 can be accelerated using graphics-backend micro-codes. Mode 7 maps screen pixels through an affine coordinate transformation, then fetches tilemap/texture data. That pixel-level workload maps well to GPU shaders.

GPU acceleration is a performance strategy, not a fix for inaccurate PPU registers, DMA/HDMA, synchronization, or missing rendering features. ActRaiser's partially working intro and Mystic Quest's black screen must still be diagnosed against hardware behavior.

2. Proposed execution architecture

The intermediate representation (IR) describes what the rendering program does, not which graphics API it uses. Backend libraries translate this shared IR into supported shader programs and GPU resource operations. A CPU fallback executes equivalent primitives for reference testing and unsupported backend features.

3. Responsibility boundaries

Existing support chips remain the source of device state. A graphics program consumes snapshots of that state; it does not create a second competing set of SNES registers.

4. Candidate graphics micro-code primitives

These are proposed instruction names for the design, not a claim that PHLEGM already implements them.

5. SNES Mode 7 as an example

Mode 7 is part of the SNES PPU, controlled by background mode register $2105 and associated Mode 7 registers including $211A–$2120. The PPU definitions specify register widths, write-latch behavior, matrix values, center offsets, scrolling, repeat modes, pixel lookup, and final layer/color composition.

SNES-PPU definition (illustrative pseudocode; not current .phlegm syntax)

on BGMODE == 7:
    load matrix      = { M7A, M7B, M7C, M7D }
    load origin      = { M7X, M7Y }
    load scroll      = { M7HOFS, M7VOFS }
    for each visible raster segment:
        AFFINE_2D      screen_xy -> sample_xy
        COORD_WRAP     sample_xy using configured repeat rules
        TILE_FETCH     tilemap, sample_xy -> tile
        TEXEL_FETCH    tile, sample_xy -> color_index
        PALETTE_LOOKUP color_index -> rgb
        MASK_TEST     visibility/priority
        LAYER_COMPOSE backgrounds and sprites
        COLOR_MATH    configured screen/subscreen operations
        RASTER_OUTPUT framebuffer

Conceptually, affine mapping uses a matrix such as x' = A·x + B·y, y' = C·x + D·y. This is not sufficient for cycle-accurate SNES behavior: the hardware's origin, scrolling, signed fixed-point calculations, intermediate truncation, and repeat/out-of-range semantics must also be modeled.

The graphics program should use the existing PPU's VRAM/CGRAM/OAM and registers. It should not require a fictional separate “Mode 7 chip.”

6. Graphics backend mapping

Keep backend capability negotiation explicit. The same IR should produce equivalent output regardless of the selected supported backend. Graphics backend support must not change the machine's externally visible behavior.

7. Compilation, caching, and lifecycle

1. On machine load: Read that machine's current .phlegm definitions, validate operations, and compile its graphics micro-code into a machine-scoped IR.
2. On session restore: Rebuild graphics micro-code from the active definitions when needed; restore only emulated hardware state from the session.
3. On first backend use: Translate validated IR and compile backend GPU programs; reuse the resulting objects during the same machine session.
4. On machine change / reload: Dispose of machine-specific compiled programs and recompile for the newly active definitions.
5. During native build / bootstrap / packaging: Do not precompile machine-specific micro-codes.

Compiled micro-codes are non-persistent across machine loads and session restores. Any backend shader object cache must observe that boundary as well; it must never silently reuse a program for changed definitions. An optional, future persistent cache would require a separate explicit architecture decision.

8. Raster timing and accuracy

SNES games can alter PPU registers during a frame. A single whole-frame set of register values can therefore be incorrect. For HDMA and mid-frame changes, capture a sequence of scanline/raster-segment state snapshots, then dispatch corresponding GPU batches.

• Fixed-point fidelity: Reproduce hardware signedness, precision, clipping, wrapping, and intermediate rounding/truncation. Avoid floating-point shortcuts unless proved equivalent.
• Register effects: Match PPU write order and latching semantics, including Mode 7's shared write behavior.
• Temporal accuracy: Preserve VBLANK/HBLANK, NMI and DMA/HDMA timing independently of GPU rendering speed.
• Composition: Mode 7 output still passes through layer priority, windows, backdrop, color math, and forced-blank behavior.
• Synchronization: Ensure CPU writes to emulated VRAM/registers are visible to the correct GPU raster segments.

9. Validation and regression tests

Keep a deterministic CPU reference implementation. Compare software and GPU output frame-by-frame using matching PPU snapshots and pixel-level checksums. Where exact equality is expected, use exact comparisons rather than approximate image similarity.

Suggested diagnostic fields: background mode, matrix coefficients, overscan status, raster segment count, active backend, shader compilation status, VRAM/CGRAM revision counters, CPU-versus-GPU frame hash, and per-stage GPU timings.

10. Recommended implementation order

1. Define the IR contract. Instruction typing, resource access, format descriptions, integer precision, deterministic validation, and explicit capability requirements.
2. Implement a software reference path. Use the same validated IR and establish pixel-perfect Mode 7 tests.
3. Move Mode 7-specific rules into .phlegm. Retain only generic, hardware-neutral primitives in native libraries.
4. Add OpenGL execution first. Verify fixed-point correctness, uploads, shader outputs, and performance on the current OpenGL runtime.
5. Add D3D11 and Vulkan. Match reference output; handle feature variation without changing emulated hardware behavior.
6. Add raster-segment dispatch. Support mid-frame register updates, then broader PPU layers and color math.
7. Expand beyond SNES. Reuse the graphics IR for NES backgrounds, Commodore displays, sprite engines and other emulated devices where appropriate.

11. Non-goals and cautions

• Not a new SNES support chip: Mode 7 remains functionality of SNES-PPU.
• Not shipped firmware: No proprietary ROM images are needed for the graphics micro-code design.
• Not backend-specific machine behavior: SNES semantics must live in definitions, not GLSL/HLSL/SPIR-V branches that only one backend implements.
• Not automatic speedup: Profile first. Uploads, synchronizations or per-scanline dispatch overhead can erase GPU gains.
• Not an implemented feature: This document proposes an architecture; it does not attest that PHLEGM currently has a shader IR, generic graphics micro-code compiler, or validated GPU Mode 7 path.