And here, the details from what we have done, summarized by codex.
For clarity below text is complete written by AI !!
Bert
Summary
We built a working MFC-based Dame Challenger emulator shell around the original ROM, with a visual board, seven-segment display, keypad/buttons, debugger support, sound, and a first bridge from the ROM’s internal board memory to the GUI board.
What We Implemented
We created the main emulator application around the Z80 ROM and memory map. The emulator loads dc.rom, executes it through the Z80 core, and exposes the machine state to the GUI through a snapshot model. The GUI reads that snapshot on a timer and redraws the display, board, status/debug text, and controls.
The LED display is driven from the ROM’s normal writes to the emulated hardware addresses. We mapped the ROM’s LED select/control behavior into four seven-segment digits, so the GUI display follows what the emulated machine is doing rather than using a separate fake display state.
We added input injection for the physical buttons and board squares. The square scan codes were updated from your measured values, so GUI square clicks now feed the ROM the same kind of row/column sensory-board values it expects.
We added the emulator beep by detecting entry into the ROM’s beep routine at 0x0199. Instead of replacing ROM behavior, the emulator simply observes that the ROM entered the sound routine and plays a short host beep.
We added search detection around the ROM search routine at 0x0F5B. While the ROM is inside search, board snapshot updates are suppressed so the GUI does not display temporary internal search positions.
We connected the internal ROM board state to the GUI board. The GUI board is updated when the ROM reads the sensory-board address 0x8000, because that read is naturally related to board/input processing. We also refresh when search exits.
Important Architecture Choices
The main principle was: let the ROM remain authoritative.
The emulator does not try to reimplement Dame Challenger game rules. The ROM still owns move legality, search, display output, button scanning, sound timing, and internal state. The GUI only visualizes and injects hardware-like inputs.
For board state, we chose to read the ROM’s internal board array from RAM at 0xA000. The important discovery was that the board is mirrored internally: GUI square 1 maps to internal index 0x36, and GUI square 50 maps to internal index 0x01. So we now use the ROM’s own external-to-internal conversion table instead of a guessed geometric formula.
We also discovered that internal board values were color-coded opposite from our first guess. Internal 0x04 represents a black man, not white. The piece decoder was corrected so GUI colors remain stable after the first board refresh.
To avoid showing invalid startup data, the board refresh refuses to replace the GUI board with an all-empty snapshot. This prevents early reads of 0x8000, before ROM board initialization is complete, from wiping the initial visible board.
For sound, we chose a non-invasive hook: detect ROM routine entry and play host audio. That keeps the ROM code path intact and avoids needing to emulate the original sound hardware perfectly at this stage.
For the GUI controls, we simplified the button panel and removed the unused J button. The remaining buttons map to the useful ROM inputs and piece-selection controls.
Current State
The project builds cleanly in Debug x64 with no warnings or errors. The emulator now has a faithful ROM-driven core, visible board/display state, hardware-style input injection, search-aware board updates, and basic beep support.
