OXYGENHUB

spec: document the NEC PC-FX (mednafen) platform appendix c17f852c2a5a

The Doomsday One mednafen fork vendors the core as a submodule and implements
the full 0.3.0 backend for PC-FX: V810 regs, 2 MB flat RAM, RGB888-decoded
framebuffer, stereo audio drain, and pad injection over a WASD-style key map.

Git-Commit: 6d02d4eb4c08cd329b210610d2d69d0026797a7c
Git-Author: Andy McCall <[email protected]>
Author
Andy McCall @andymccall <[email protected]>
When
· 2026-07-21 20:05 UTC
Signature
◈ sealed by Andy McCall
Hash
c17f852c2a5aa7754ddf3a51eb378da648d077b60f7cb33c734d4642c8dff0bf
Depends on
961b3c610c66
Depended on by
398756c0e9b2 4c0b050e9a25
In bookmarks
main perf-6
Edits
1 atom, 0 tree operations, 1 file

Browse the tree at this change

modified SPEC.md +22 −0
…
149 unchanged lines
150 150
- Registers (ADL): `af bc de hl ix iy sp pc mbase` + ADL-mode flag.
151 151
- Framebuffer: from `vgabuf` (the VDP output), server swizzles to PPM RGB.
152 152
153 +
### NEC PC-FX — `mednafen` (Doomsday One fork)
154 +
- **Adoption:** vendors the shared core as a git submodule
155 +
  (`src/extern/retro-remote-debug-controller`), built in with `./configure
156 +
  --enable-rrdc`. Dispatched per running console, so PC Engine and Saturn can
157 +
  reuse the same core once their backends land.
158 +
- Control port: the `MEDNAFEN_CONTROLPORT=<N>` environment variable (Mednafen
159 +
  exposes no free-form CLI flag for a driver add-on). Unset ⇒ server off.
160 +
- Address space: V810, flat **2 MB** main RAM (`0x000000–0x1FFFFF`); `addr`
161 +
  wraps in that space and `bank` is ignored.
162 +
- Registers: `pc` + `r0`–`r31` (33 × 32-bit), from the V810 core.
163 +
- Framebuffer: the active display rect (typically 256×240), decoded to RGB888
164 +
  by the fork with the surface's channel shifts, so it is correct regardless of
165 +
  Mednafen's display-dependent pixel order.
166 +
- Audio: stereo, at Mednafen's configured output rate (`espec.SoundRate`),
167 +
  teed from the per-frame `SoundBuf`.
168 +
- Input: the PC-FX has a gamepad, not a keyboard, so `/key?text=<c>` and
169 +
  `/key?code=<n>` are both read as a character over a WASD-style pad map —
170 +
  `w/a/s/d` = up/left/down/right, space or Enter = RUN (start), `c` = SELECT,
171 +
  `1`–`6` = buttons I–VI. A held button is re-asserted each frame (the frontend
172 +
  rewrites the pad from physical input every frame), so holds persist across
173 +
  `/step`. `/reset` power-cycles the machine.
174 +
153 175
---
154 176
155 177
## Reference implementations in this repo
…
7 unchanged lines