FPGA Verified Against

Was each MiSTer arcade core checked against the original arcade hardware, or against MAME? This page answers from what each core's own source says: its code comments, readme and shipped documentation. Statements pointing to MAME move the meter's white marker left; statements pointing to the original hardware move it right. Open a core's “▶ Statements” to see every statement, linked to its line at that commit; items that point at MAME link to the matching line in MAME (commit 78e14fa58b). Covered: every arcade core in update_all's three default databases, in six independent databases developers publish themselves, and in public repositories found by search, each read at the commit its distributed build came from.

Taken at face value. These are the developers' own statements, not independently checked. A core may be verified more, or less, than its comments say. Open source makes a false claim easy to expose, which is why developers' own words are a reasonable starting point. This method reads source code, so closed-source cores cannot be assessed this way and are shown separately; black-box testing against the original hardware or MAME would still be possible, but is far more work and is not done here.

Rules v0.12 · tool 0.12.0 · generated 2026-10-12T11:06:33+00:00 · shared CPU/sound libraries and the MiSTer framework are excluded · below "low" confidence the bar is an outline with no needle · readings: under 40 mostly MAME, over 60 mostly hardware, otherwise both.

Core	Database	Reading	Confidence	Coverage
ActFancer# Act-Fancer Cybernetick Hyper Weapon MiSTer-devel/Arcade-ActFancer_MISTer @ 267b81a4 MAME compared: dataeast/actfancr.cpp + 4 related file(s) Read: 31 HDL files, 14,912 lines (Quartus project)	MiSTer official	Mostly MAME	medium	27%
Statements: 1 toward hardware, 53 toward MAME Cites hardware documentation that MAME's driver does not — 1 rtl/actfancer/jtcop_bac06.v:41 The /NUDS and /NLDS inputs of all chips are gated via a 74LS32 chip by the /DSP chip select signal. Cites MAME source — 42 ActFancer.sv:316 MAME actfancr.cpp port mapping: P1 bit 0=UP, 1=DOWN, 2=LEFT, 3=RIGHT, 4=BUTTON1, 5=BUTTON2, 7=START1 SYSTEM bit 0=COIN1, 1=COIN2 MiSTer hps_io with jn keywords (pattern BoogieWings/Darius DataEast): D-pad joy[0..3] = R,L,D,U J1 buttons base rtl/actfancer/actfancer_bac06_wrap.sv:3 ActFancer's H6280 main CPU is 8-bit; MAME accesses BAC06 via pf_data_8bit_swap_w(): A0 selects high/low byte of the 16-bit word. rtl/actfancer/actfancer_bac06_wrap.sv:6 We translate: cpu_8bit_addr[12:0] → cpu_dout[15:0] / cpu_dsn[1:0] / cpu_addr[12:1] such that for A0=0 → write hi byte, A0=1 → write lo byte (the "swap" variant in MAME swaps endianness vs the plain one). rtl/actfancer/actfancer_bac06_wrap.sv:65 MAME pf_data_8bit_swap_w (decbac06.cpp:625-660): A0=0 → byte BASSO del word A0=1 → byte ALTO del word (validato in sim/tb_bac06_swap.sv) rtl/actfancer/actfancer_chars.sv:3 Stessa architettura di actfancer_tiles ma con tile 8x8 + index VRAM da MAME tile_shape0_8x8_scan (cpp:173). rtl/actfancer/actfancer_chars.sv:92 MAME tile_shape0_8x8_scan: idx = (col & 0x1f) + ((row & 0x1f) << 5) + ((col & 0x60) << 5) rtl/actfancer/actfancer_main.sv:4 MAME reference: dataeast/actfancr.cpp::actfancr_state::prg_map (lines 154-173) rtl/actfancer/actfancer_main.sv:132 MAME: 0x110000-0x110001 (buffer_spriteram_w 2 byte). rtl/actfancer/actfancer_main.sv:162 SYSTEM port MAME (active-low except bit7=VBL active-high): bit 0 = COIN1, bit 1 = COIN2, bit 7 = VBL rtl/actfancer/actfancer_main.sv:186 PF bus fanout (BAC06 wrapper esterno gestisce 8-bit→16-bit) MAME maps tightly: pf0: 0x060000-0x060007 ctrl0, 0x060010-0x06001F ctrl1, 0x062000-0x063FFF VRAM pf1: 0x070000-0x070007 ctrl0, 0x070010-0x07001F ctrl1, 0x072000-0x0727FF VRAM mod rtl/actfancer/actfancer_main.sv:194 PF1 VRAM: MAME limita a 2KB (0x072000-0x0727FF) — restringo per evitare aliasing rtl/actfancer/actfancer_obj_wrap.sv:10 MAME spriteram ActFancer (actfancr.cpp:150 buffer_spriteram_w): m_spriteram16[i] = m_spriteram[i2] \| (m_spriteram[(i2)+1] << 8); LO byte HI byte Cioè LITTLE-ENDIAN dentro il word16: spriteram byte 2i = LO byte (= cpu A0=0) s rtl/actfancer/actfancer_obj_wrap.sv:76 little-endian (MAME buffer_spriteram_w): A0=0 -> LO byte -> dsn = 2'b10 (we[0]=1 enable LO) A0=1 -> HI byte -> dsn = 2'b01 (we[1]=1 enable HI) rtl/actfancer/actfancer_rom_bram32.sv:6 Layout MAME chars 8x8 4bpp = RGN_FRAC(1,4): 4 planes from {0/4, 1/4, 2/4, 3/4} of the region. rtl/actfancer/actfancer_rom_bram32.sv:7 So: plane 0 = bytes 0x00000..0x07FFF plane 1 = bytes 0x08000..0x0FFFF plane 2 = bytes 0x10000..0x17FFF plane 3 = bytes 0x18000..0x1FFFF (vedi gfx_layout layout_8x8x4 in actfancr.cpp riga 308-317) rtl/actfancer/actfancer_snd.sv:4 MAME reference: dataeast/actfancr.cpp::dec0_s_map (lines 196-204) rtl/actfancer/actfancer_snd.sv:149 PIN7_HIGH (MAME) rtl/actfancer/actfancer_sprites.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Act-Fancer DECO MXC06 sprite engine — 1:1 MAME decmxc06::draw_sprites. rtl/actfancer/actfancer_sprites.sv:4 Reference: reference/decmxc06.cpp rtl/actfancer/actfancer_sprites.sv:6 Sprite layout (4 word × 16 bit per sprite, big-endian sprite RAM 2KB = 256 sprite): word0 (byte0,1) = {byte0:[en, yflip, xflip, h[1:0], w[1:0], yh], byte1:[ylo[7:0]]} bit 15 : enable bit 14 : Y flip bit 13 : X flip bit 12:11 : height (1x, 2 rtl/actfancer/actfancer_sprites.sv:23 MAME conversion (cpp:80-85): sx = data2 & 0x01ff; if (sx >= 256) sx -= 512; sx = 240 - sx; sy = data0 & 0x01ff; if (sy >= 256) sy -= 512; sy = 240 - sy; rtl/actfancer/actfancer_sprites.sv:44 MRA sprites interleave (B0..B3): B0 = region 1/4 B1 = region 3/4 B2 = region 0 B3 = region 2/4 MAME planes = {0, 1/4, 2/4, 3/4} → pen[3]=B2, pen[2]=B0, pen[1]=B3, pen[0]=B1. rtl/actfancer/actfancer_sprites.sv:128 512 wide per gestire sx negativo (signed wrap MAME). rtl/actfancer/actfancer_sprites.sv:270 Y: 9-bit (byte0 bit0 = Y[8]) - MAME conversion rtl/actfancer/actfancer_sprites.sv:314 code per tile row in multi-h sprite: code = (code_base & ~(h-1)) if (parentFlipY) y_offset = -tile_yi else y_offset = (h-1) - tile_yi For multi-width (x_iter > 0): MAME consumes additional spriteram entries. rtl/actfancer/actfancer_sprites.sv:327 rom_addr = {code_y[11:0], row_in_tile[3:0], half} (code_y truncated to 12 bit per MAME tile region size 1536 ≈ 11 bit) word32-index shiftato di 1 (bridge fa [17:1]<<1, preserva [1:17]) rtl/actfancer/actfancer_tiles.sv:13 VRAM indexing MAME (decbac06.cpp): - shape0 col-major: idx = (row & 0xf) + ((0xFF - col[7:0]) << 4) - shape0 row-major: idx = (col & 0xf) + ((row & 0xf) << 4) + ((col & 0x1f0) << 4) - shape1: idx = (col & 0xf) + ((row & 0x1f) << 4) + ((col rtl/actfancer/actfancer_tiles.sv:97 scroll x invertito per col-major (MAME cpp:274-278) rtl/actfancer/actfancer_tiles.sv:124 VRAM index calculation (MAME tile_shape_scan) rtl/actfancer/actfancer_tiles.sv:255 hflip from MAME: column-major -> TILE_FLIPX rtl/actfancer/actfancer_top.sv:396 MAME ROM_REGION 256KB ma file "18" e` solo 64KB (vedi actfancr.cpp:471). rtl/actfancer/actfancer_video.sv:4 Two tile layers via Jotego's jtcop_bac06 (wrapped for 8-bit CPU bus): PF0 = MASTER (16x16 background), provides H/V timing reference PF1 = SLAVE (8x8 chars overlay) DECO MXC06 sprite engine (bespoke MAME-faithful actfancer_sprites). rtl/actfancer/actfancer_video.sv:10 Video timing: jtframe_vtimer internal to PF0 (384x272 total @ 6 MHz pixel clock -> 256x240 active @ 57.45 Hz, hardware-accurate to MAME). rtl/actfancer/actfancer_video.sv:285 Compositing: PF1 (chars) > sprite > PF0 (tiles) Indici palette base (MAME GFXDECODE): chars → 0x000 tiles → 0x100 sprite → 0x200 rtl/actfancer/actfancer_video.sv:347 MAME pf_data_8bit_swap_w (decbac06.cpp:496+641): CPU A0=0 → MAME offset^1 → odd → mask 0x00ff → write LO byte CPU A0=1 → MAME offset^1 → even → mask 0xff00 → write HI byte rtl/actfancer/jtcop_bac06.v:282 hflip = TILE_FLIPX MAME: ON quando col-major (mode[0] bit1 = 0). rtl/actfancer/jtcop_bac06.v:292 MAME decbac06.cpp ActFancer m_wide=2: GEOM_4X1 16x16: 256 cols × 16 rows tile_shape0_scan column-major: idx = (row & 0xf) + ((0xFF - col[7:0]) << 4) row-major: idx = (col & 0xf) + ((row & 0xf) << 4) + ((col & 0x1f0) << 4 rtl/actfancer/jtcop_bac06.v:306 In jtcop convention, msbrow_en=0 means "MAME column-major" (TILE_FLIPX implicit). rtl/actfancer/jtcop_bac06.v:307 In jtcop convention, msbrow_en=1 means "MAME row-major". rtl/actfancer/jtcop_bac06.v:321 column-major MAME: (row[3:0]) + ((0xFF - col[7:0]) << 4) rtl/actfancer/jtcop_bac06.v:481 MAME byte plane offset = 16+y (y=0..7) → DDR byte = T128 + 64 + y4 → rom_addr (word16-idx) = T32 + 16 + y README.md:30 YM2203 OPN + YM3812 OPL2 + OKI M6295 ADPCM, MAME-accurate clocks Shares text with the MAME driver without saying so — 11 rtl/actfancer/actfancer_chars.sv:92 MAME tile_shape0_8x8_scan: idx = (col & 0x1f) + ((row & 0x1f) << 5) + ((col & 0x60) << 5) — shares text with dataeast/decbac06.cpp:173 rtl/actfancer/actfancer_sprites.sv:24 sx = data2 & 0x01ff; if (sx >= 256) sx -= 512; sx = 240 - sx; — shares text with dataeast/decmxc06.cpp:81 rtl/actfancer/actfancer_sprites.sv:31 if (parentFlipY) incy = -1; else { code += h-1; incy = 1; } — shares text with dataeast/decmxc06.cpp:116 rtl/actfancer/actfancer_tiles.sv:15 - shape0 row-major: idx = (col & 0xf) + ((row & 0xf) << 4) + ((col & 0x1f0) << 4) — shares text with dataeast/decbac06.cpp:145 rtl/actfancer/actfancer_tiles.sv:16 - shape1: idx = (col & 0xf) + ((row & 0x1f) << 4) + ((col & 0xf0) << 5) — shares text with dataeast/decbac06.cpp:159 rtl/actfancer/actfancer_tiles.sv:17 - shape2: idx = (col & 0xf) + ((row & 0x3f) << 4) + ((col & 0x70) << 6) — shares text with dataeast/decbac06.cpp:166 rtl/actfancer/jtcop_bac06.v:295 row-major: idx = (col & 0xf) + ((row & 0xf) << 4) + ((col & 0x1f0) << 4) — shares text with dataeast/decbac06.cpp:145 rtl/actfancer/jtcop_bac06.v:297 tile_shape1_scan: idx = (col & 0xf) + ((row & 0x1f) << 4) + ((col & 0xf0) << 5) — shares text with dataeast/decbac06.cpp:159 rtl/actfancer/jtcop_bac06.v:299 tile_shape2_scan: idx = (col & 0xf) + ((row & 0x3f) << 4) + ((col & 0x70) << 6) — shares text with dataeast/decbac06.cpp:166 rtl/actfancer/jtcop_bac06.v:301 GEOM_4X1: 128×32 → idx = (col & 0x1f) + ((row & 0x1f) << 5) + ((col & 0x60) << 5) — shares text with dataeast/decbac06.cpp:173 rtl/actfancer/jtcop_bac06.v:302 GEOM_2X2: 64×64 → idx = (col & 0x1f) + ((row & 0x1f) << 5) + ((row & 0x20) << 5) + ((col & 0x20) << 6) — shares text with dataeast/decbac06.cpp:172
Aleck64# Eleven Beat, Hanabi de Doon! - Don-chan Puzzle, Hi Pai Paradise, Hi Pai Paradise 2 … MiSTer-devel/N64_MiSTer @ 399e6594 MAME compared: nintendo/aleck64.cpp + 11 related file(s) Read: 84 HDL files, 42,940 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	5%
Statements: 10 toward MAME Cites MAME source — 10 N64.sv:628 MAME keyboard controls ///////////////////////// N64.sv:662 MAME's default mahjong panel bindings. N64.sv:759 MAME buttons 3/4 correspond to the MRA's logical C/D controls at R/C-Right. N64.sv:780 Aleck64 PIF titles use the N64 analog stick for their MAME directions. rtl/Aleck64.vhd:9 The E90 renderer below follows the currently documented MAME behaviour: each enabled list entry draws one 8x8, palette-shaded puzzle block over the N64 video output. README.md:28 \| MAME set \| Game \| Input/hardware status \| README.md:51 The E90 puzzle-piece overlay extends the reference MAME implementation with the tile `0x0400` playfield-background mode. README.md:56 Magical Tetris's separate 128-byte S2D board memory is initialized from the MAME `at24c01.u34` dump and appended to the same persistent NVRAM file. README.md:72 Mahjong games use MAME's panel defaults: A-N, left Ctrl for Kan, left Alt for Pon, Space for Chi, left Shift for Reach, and Z for Ron. README.md:75 Games with physical DIP banks expose their MAME-defined settings through the standard MiSTer DIP Switches OSD entry.
Arabian# Arabian MiSTer-devel/Arcade-Arabian_MiSTer @ 42fef5ac MAME compared: sunelectronics/arabian.cpp Read: 11 HDL files, 2,679 lines (Quartus project)	MiSTer official	Mostly MAME	medium	75%
Statements: 4 toward hardware, 52 toward MAME Cites hardware documentation that MAME's driver does not — 2 rtl/Arabian_CPU.sv:366 12 MHz master (XTAL, SP-237 sheet 8B), 6 MHz dot clock. rtl/Arabian_CPU.sv:783 Confirmed against SP-237 sheet 11B: plane B reaches red (BZ/BR via IC118) and green (BG via IC118, BB via IC120) but never blue -- the blue driver TR6 is fed only from the plane-A path. Ships hardware documentation files — 1 Useful Information/Arabian (1983) - Schematics (1st Printing).pdf Notes where it differs from MAME — 1 rtl/cpu/mb88_sv/mb88_core.sv:31 NOT MODELLED — NONE are gaps (MAME doesn't model them for the default part, or no target device uses them): * STANDBY (stby_n pin): MAME has no standby/STOP state for mb88. Cites MAME source — 43 Arcade-Arabian.sv:222 Service inputs — MAME keeps these separate rtl/Arabian.sv:14 Player inputs (active HIGH, per MAME port definitions) rtl/Arabian_CPU.sv:5 The video timing, VRAM and blitter blocks are still the kangaroo.cpp implementation by Ville Laitinen and Aaron Giles, pending their port. rtl/Arabian_CPU.sv:63 Generate clock enables from the 12 MHz master (MAIN_OSC, arabian.cpp) cen_6m = 12/2 = 6 MHz (pixel clock — provisional, see Video Timing) rtl/Arabian_CPU.sv:82 Holds the Z80 while the blitter owns the bitmap: arabian.cpp blits inside the $E006 write and the board's DMA holds the bus for the same span, so the blit must be atomic. rtl/Arabian_CPU.sv:189 arabian.cpp blitter_w: $E000-$E006, mirror $0FF8 rtl/Arabian_CPU.sv:214 NMI is not connected on this board (arabian.cpp memory map header). rtl/Arabian_CPU.sv:220 Wiring mirrors arabian.cpp: rtl/Arabian_CPU.sv:230 MAME converts pin clocks at (clocks+5)/6, so the 2 MHz pin rate is divided by 6. rtl/Arabian_CPU.sv:291 --- flip screen --- MAME latches this only when the MCU writes R0. rtl/Arabian_CPU.sv:313 MAME's read_r returns the output latch; R0 additionally reads bit2 high ("RAM mode enabled") rtl/Arabian_CPU.sv:344 MAME: standard IM1 interrupt, RST 38h every vblank IRQ fires on vblank rising edge rtl/Arabian_CPU.sv:462 arabian.cpp blit_area(): a source byte pair (offs, offs+0x4000) carries four pixels; pixel m takes bit m and bit m+4 from each plane byte. rtl/Arabian_CPU.sv:487 arabian.cpp videoram_w(): the CPU writes four pixels of two bits each, pixel m taking data[m] and data[m+4]. rtl/Arabian_CPU.sv:490 MAME's comments on that function do not match the palette bit order; the code does. rtl/Arabian_CPU.sv:536 MAME's loop is X outer, Y inner, source advancing per step. rtl/Arabian_CPU.sv:737 arabian.cpp screen_update is a straight bitmap scanout: the pen IS the pixel byte, with the five AY port-A control bits forming the upper half of a 13-bit colour-table index: pen = ((video_control >> 3) << 8) \| pixel_byte There is no scroll rtl/Arabian_CPU.sv:746 MAME's screen_update does dest_x = 255-x, dest_y = 255-y on a 256x256 bitmap (arabian.cpp:475-484), which is this XOR. rtl/Arabian_CPU.sv:783 Colour derivation, arabian.cpp palette(). rtl/Arabian_CPU.sv:793 MAME's weights match the sheet-11B network: red 1.2K/1.8K = 1.5 (153/102), green 750R/1.2K = 1.6 (156/99), 510R pull-ups. rtl/cpu/mb88_sv/mb88.sv:56 Generate it here: one ena_timer pulse per 32 `ena` machine-cycle enables — MAME mb88 burn_cycles /32 (full timer overflow = ÷8192 of `ena`). rtl/cpu/mb88_sv/mb88_core.sv:6 Oracle: MAME cpu/mb88xx/mb88xx.cpp (opcode-for-opcode). rtl/cpu/mb88_sv/mb88_core.sv:14 STATUS (2026-07-18): COMPLETE vs MAME mb88xx.cpp — opcode AND non-opcode. rtl/cpu/mb88_sv/mb88_core.sv:16 OPCODES: all 256 bytes, verified byte-for-byte vs mb88xx.cpp execute_run() (0x00-2f individual; 0x30-3f sbit/rbit/tbit/rti/jpa/en/dis; 0x40-7f setD/ rstD/tstD/tba/xd/xyd/lxi/call/jpl/ai; 0x80-bf lyi/li/cyi/ci; 0xc0-ff jmp). rtl/cpu/mb88_sv/mb88_core.sv:23 * Timer: internal (pio7, ÷32 prescale) OR external TC pin (pio6) per MAME increment_timer() (2026-07-11 + 2026-07-17 fixes). rtl/cpu/mb88_sv/mb88_core.sv:29 * O-port PLA: 8-bit cf-nibble-select outO = MAME write_pla with pla_bits==8 (the device default; what the Namco 5xxx use). rtl/cpu/mb88_sv/mb88_core.sv:34 * External-clock serial (pio 0x10/0x30): MAME fatalerror's it (unsupported). rtl/cpu/mb88_sv/mb88_core.sv:58 interrupt injection (harness drives from the MAME trace during bug hunt) rtl/cpu/mb88_sv/mb88_core.sv:88 ---- SERIAL (2026-07-18; faithful to MAME mb88xx.cpp serial_timer()/pio_enable()) ---- 4-bit RECEIVE shift register clocked at clock()/SERIAL_PRESCALE(=6), armed when pio[5:4]==2'b10 (MAME's (m_pio & 0x30)==0x20 = internal serial clock). rtl/cpu/mb88_sv/mb88_core.sv:92 sf blocks further shifting until tsts clears it; SBcount runaway-disables at THRESH (MAME anti-hang). rtl/cpu/mb88_sv/mb88_core.sv:93 External-clock serial (pio 0x10/0x30) is unsupported by MAME (fatalerror) so we just don't tick. rtl/cpu/mb88_sv/mb88_core.sv:94 SO/transmit is not modeled in MAME's mb88 either. rtl/cpu/mb88_sv/mb88_core.sv:98 MAME SERIAL_DISABLE_THRESH rtl/cpu/mb88_sv/mb88_core.sv:154 SP[] and ram[] intentionally NOT reset (MAME device_reset doesn't clear data RAM/stack; ROM inits RAM; Verilator zero-inits arrays). rtl/cpu/mb88_sv/mb88_core.sv:160 MAME mb88xx.cpp: `if (m_ctr && !state && (m_pio & 0x40)) increment_timer(); m_ctr = state;` i.e. on a FALLING edge of the TC pin, if external-counter mode (pio bit6/0x40) is enabled, tick the SAME timer. rtl/cpu/mb88_sv/mb88_core.sv:163 This drives the 51xx's per-frame timer, which MAME clocks from screen vblank (namco51.cpp vblank() -> MB88XX_TC_LINE). rtl/cpu/mb88_sv/mb88_core.sv:168 Two mutually-exclusive sources feed the ONE counter (a chip uses internal OR external mode, never both): internal clock (ena_timer & pio7 = MAME 0x80), OR external TC falling edge (pio6 = MAME 0x40). rtl/cpu/mb88_sv/mb88_core.sv:172 MCU-TIMER-FIX-2026-07-11: pio7 gate (MAME 0x80); TC-TIMER-FIX-2026-07-17: + external TC path (pio6/MAME 0x40) rtl/cpu/mb88_sv/mb88_core.sv:179 ---- SERIAL receive engine (MAME serial_timer). rtl/cpu/mb88_sv/mb88_core.sv:188 MAME: SB = (SB>>1) \| (si?8:0) rtl/cpu/mb88_sv/mb88_core.sv:201 MAME executes the instruction first, pushes the POST-instruction PC, then burn_cycles(3). rtl/cpu/mb88_sv/mb88_core.sv:217 outO: cf=1->oh, cf=0->ol (MAME write_pla 8-bit / VHDL) rtl/cpu/mb88_sv/mb88_core.sv:324 {PA,PC} here is already the POST-instruction PC = MAME's GETPC(). Says it matches, follows or was checked against MAME — 7 rtl/Arabian_CPU.sv:372 Visible window matches MAME's visarea (0,255, 11,244): 256 across, 234 down. rtl/cpu/mb88_sv/mb88_core.sv:64 PC of the executing instruction (matches MAME) rtl/cpu/mb88_sv/mb88_core.sv:105 IRQ-CYCLES-FIX-2026-08-21: interrupt entry costs 3 ce, matching MAME's burn_cycles(3) (mb88xx.cpp:481). rtl/cpu/mb88_sv/mb88_core.sv:211 executing instruction's own PC (matches MAME) rtl/cpu/mb88_sv/mb88_core.sv:294 jmp within page (INCPC-then-override, matches MAME) rtl/cpu/mb88_sv/mb88_core.sv:322 IRQ-CYCLES-FIX-2026-08-21: entry work + 2 idle ce = 3 ce total, so an instruction plus an interrupt costs 4 ce, matching MAME's 1 + 3. rtl/ram_rom/rom_loader.sv:3 Arabian ROM loader ROM layout matched to MAME arabian.cpp Says it was translated, ported or taken from MAME — 2 rtl/Arabian.sv:3 Arabian top-level module Copyright (C) 2026 Rodimus Based on MAME arabian.cpp by Dan Boris rtl/Arabian_CPU.sv:3 Arabian Main CPU Board Based on MAME arabian.cpp by Dan Boris.
Arkanoid# Arkanoid MiSTer-devel/Arcade-Arkanoid_MISTer @ bea1771c MAME compared: taito/arkanoid.cpp + 3 related file(s) Read: 8 HDL files, 2,222 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	34%
Statements: 2 toward MAME Cites MAME source — 1 Arcade-Arkanoid.sv:583 DIP switches are in reverse order when compared to this table (sourced from MAME Arkanoid driver): Shares text with the MAME driver without saying so — 1 Arcade-Arkanoid.sv:583 DIP switches are in reverse order when compared to this table (sourced from MAME Arkanoid driver): +-----------------------------+------------------------------ — shares text with taito/arkanoid.cpp
Asteroids# Asteroids Deluxe, Asteroids, Lunar Lander MiSTer-devel/Arcade-Asteroids_MiSTer @ 0f1369fa MAME compared: atari/asteroid.cpp + 3 related file(s) Read: 46 HDL files, 22,126 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	6%
Statements: 3 toward hardware Cites hardware documentation that MAME's driver does not — 3 rtl/asteroids_audio_board.sv:144 Nominal 555/DAC frequencies from the Asteroids board schematic. rtl/asteroids_core.sv:7 The address map and RAM arbitration follow the Asteroids main-board schematics. README.md:13 This core reconstructs all three machines from Atari's schematics and pairs them with a high-resolution vector renderer and CRT-effects pipeline.
Astrocade# Extra Bases, Gorf, The Adventures of Robby Roto!, Sea Wolf II … MiSTer-devel/Arcade-Astrocade_MiSTer @ ea231f0f MAME compared: bally/astrocde.cpp + 2 related file(s) Read: 40 HDL files, 17,784 lines (Quartus project)	MiSTer official	Mostly MAME	low	7%
Statements: 16 toward MAME Cites MAME source — 4 rtl/bally_io.vhd:312 2+4, 6 bit up counter as per patent and Mame = 7 bit counter = x3F or max 63 rtl/sc01a/sc01a.vhd:12 Key differences from MAME reference: - All arithmetic in s(2.15) fixed-point (no floating point) - Filter coefficients pre-computed as static ROM tables - IIR filters implemented as sequential state machines - Clock enables (sclock_en, cclo README.txt:62 Sound uses samples, originally from mame but modified to closer match the hardware README.txt:76 (as per Mame) analogue should work the same as the real game. Says it was translated, ported or taken from MAME — 3 rtl/sc01a/sc01a.vhd:9 Based on the Votrax SC01-A simulation from MAME Copyright (c) Olivier Galibert README.txt:79 SC-01 speech implemented using a fixed-point VHDL port of MAME’s Votrax SC-01 core. README.txt:90 SC-01 speech implemented using a fixed-point VHDL port of MAME’s Votrax SC-01 core. Shares text with the MAME driver without saying so — 9 rtl/bally_pattern.vhd:136 address is selected between source/dest based on mode.d0 — shares text with bally/astrocde_v.cpp:769 rtl/bally_pattern.vhd:149 if mode.d3 is set, then the last byte fetched per row is forced to 0 (address = gorf hack for the moment) — shares text with bally/astrocde_v.cpp:772 rtl/bally_pattern.vhd:185 if the flip-flop at U13 is high and mode.d2 is 1 we can increment source — shares text with bally/astrocde_v.cpp:693 rtl/bally_pattern.vhd:186 however, if mode.d3 is set and we're on the last byte of a row, the increment is suppressed — shares text with bally/astrocde_v.cpp:694 rtl/bally_pattern.vhd:193 if mode.d1 is 1, toggle the flip-flop; otherwise leave it preset — shares text with bally/astrocde_v.cpp:698 rtl/bally_pattern.vhd:198 destination increment is suppressed for the last byte in a row — shares text with bally/astrocde_v.cpp:706 rtl/bally_pattern.vhd:200 at the end of each row, the skip value is added to the dest value — shares text with bally/astrocde_v.cpp:801 rtl/bally_pattern.vhd:203 carry behavior into the top byte is controlled by mode.d4 — shares text with bally/astrocde_v.cpp:805 rtl/bally_pattern.vhd:214 if mode.d5 is 1, we increment — shares text with bally/astrocde_v.cpp:709
atarisys1# Indiana Jones and the Temple of Doom, Marble Madness, Peter Pack Rat, Road Blasters … MiSTer-devel/Arcade-Atari-system1_MiSTer @ 475e26f7 MAME compared: atari/atarisy1.cpp + 6 related file(s) Read: 20 HDL files, 6,271 lines (Quartus project)	MiSTer official	Both	medium	89%
Statements: 44 toward hardware, 8 toward MAME, 25 not counted Cites hardware documentation that MAME's driver does not — 44 Arcade-atarisys1.sv:645 SP-276 SP-277 SP-282 SP-286 SP-298 ######################################### rtl/atarisys1/AUDIO.vhd:160 sheet 5 -- rtl/atarisys1/AUDIO.vhd:287 sheet 6 -- rtl/atarisys1/CART.vhd:13 Indiana Jones and the Temple of Doom cartridge for Atari System 1 From SP-282 schematic (identical to SP-280 just different page order) rtl/atarisys1/CART.vhd:184 sheet 11 SP-299 INT3 schema -- rtl/atarisys1/CART.vhd:188 counter 4/5F is kept in "hold" mode (pins ENT, ENP grounded) so just (ab)used as a 1 bit latch deviation from schematic, it was determined that INT3 was occuring too early and causing video problems with roadblasters due to V offset being l rtl/atarisys1/CART.vhd:225 sheet 2 SP-282 -- (sheet 8 SP-280) -- sheet 3 SP-282 -- (sheet 7 SP-280) -- rtl/atarisys1/CART.vhd:243 sheet 4 SP-282 -- (sheet 2 SP-280) -- rtl/atarisys1/CART.vhd:349 schematic variation between games sheet 4 SP-282 vs sheet 12 SP-299 rtl/atarisys1/CART.vhd:353 common address for PROMs 4/5A, 7A on SP-282 or 2D, 1/2D on SP-299 rtl/atarisys1/CART.vhd:386 -- PROM 1/2D , decoder 1D, buffers 2H, 3H, 4H on SP-299 slv_GBA <= I_PD7A & slv_MGRA(11 downto 1); rtl/atarisys1/CART.vhd:429 else if others default to SP-282 rtl/atarisys1/CART.vhd:431 PROM 4/5A on SP-282 rtl/atarisys1/CART.vhd:443 PROM 7A on SP-282 convert ROM selects back into an address vector rtl/atarisys1/CART.vhd:486 sheet 5 SP-282 -- (sheet 4 SP-280) -- rtl/atarisys1/CART.vhd:508 sheet 6 SP-282 -- (sheet 5 SP-280) -- rtl/atarisys1/CART.vhd:530 sheet 7 SP-282 -- (sheet 6 SP-280) -- rtl/atarisys1/CART.vhd:551 sheet 8 SP-282 -- (sheet 3 SP-280) -- rtl/atarisys1/GPC.vhd:70 These equations describe the PROM 3E contents, top 2 data bits are the same as bottom 2 data bits as can be seen in PROM dump rtl/atarisys1/GPC.vhd:98 3H latch rtl/atarisys1/GPC.vhd:117 1B, 5B latch rtl/atarisys1/LINECTR.vhd:72 4J, 3D on SP-277 schema sheet 8 rtl/atarisys1/LINECTR.vhd:93 latch 3J rtl/atarisys1/LS299.vhd:17 simplified 74LS299 shifter as used in SLAGS rtl/atarisys1/MAIN.vhd:260 sheet 2 -- rtl/atarisys1/MAIN.vhd:451 sheet 3 -- rtl/atarisys1/MAIN.vhd:465 sheet 4 -- rtl/atarisys1/MOHLB_LSI.vhd:13 Motion Object Horizontal Line Buffer based on SP-286 schematic sheet 7 rtl/atarisys1/MOHLB_LSI.vhd:67 sheet 7 -- rtl/atarisys1/PFHS.vhd:67 11E latch rtl/atarisys1/PFHS.vhd:80 two 74LS189 16x4 bit RAMs, arranged as one 16x8 RAM but only 3 address lines used, so really one 8x8 RAM IMPORTANT: data out is the COMPLEMENT of data in!!! rtl/atarisys1/SLAGS.vhd:73 In schema SP-276 when /NOROM signals are asserted they cause the shifters to hold their state and also they cause /CPAL signals to pull low the D0/D7 lines of the ROMS (which are not fitted to PCB, hence the /NOROM signal) the final effect rtl/atarisys1/SYNGEN.vhd:124 From SP-313 this is /HBLANK rtl/atarisys1/VIDEO.vhd:248 sheet 7 -- rtl/atarisys1/VIDEO.vhd:345 sheet 8 -- rtl/atarisys1/VIDEO.vhd:390 9C latch rtl/atarisys1/VIDEO.vhd:416 2C latch rtl/atarisys1/VIDEO.vhd:427 5F latch rtl/atarisys1/VIDEO.vhd:458 sheet 9 -- rtl/atarisys1/VIDEO.vhd:541 1/2A, 3C latch on SP-299 addr bit 13 is taken from VRD9 but on SP-286 it is connected to ALBNK selector the only games that uses a 16K ALPHA ROM are indytempc and roadblstcg rtl/atarisys1/VIDEO.vhd:552 2/3B ROM (same as 5F) rtl/atarisys1/VIDEO.vhd:570 sheet 10 -- rtl/atarisys1/VIDEO.vhd:612 6A, 6B latch color palette output README.md:5 Based primarily on the SP-280, SP-286 schematics with additional support from SP-277, SP-298 Cites hardware references or measurements that MAME's driver also gives — 25 rtl/atarisys1/AUDIO.vhd:164 Location J16 and J17 implements a halt to 6502 for 8 video frames after a /RST or /IRQ A 74LS164 shit register is configured as: 74LS164 inputs A,B tied High, CLK tied to /VBLANK, /RST tied to output of AND gate with inputs /6502IRQ 6502 pi — also in MAME: 74LS164 atari/atarisy1.cpp:36, 74LS164 atari/atarisy1.cpp:36, 74LS164 atari/atarisy1.cpp:36 rtl/atarisys1/CART.vhd:359 if Roadrunner or Roadblasters use variation SP-298 / SP-299 !!! — also in MAME: SP-298 atari/atarisy1.cpp:1763, SP-299 atari/atarisy1.cpp:1765 rtl/atarisys1/CART.vhd:361 PROM 2D on SP-299 if I_MATCHn = '0' then sl_NOROM7n <= '0'; sl_NOROM6n <= '0'; sl_NOROM5n <= I_PD4A(5); sl_NOROM4n <= I_PD4A(4); sl_NOROM3n <= I_PD4A(7); sl_GD7P7 <= I_PD4A(3); sl_GD7P6 <= I_PD4A(2); sl_GD7P5 <= I_PD4A(1); sl_GD7P4 — also in MAME: 2D atari/atarisy1.cpp:1614, SP-299 atari/atarisy1.cpp:1765 rtl/atarisys1/CART.vhd:389 if Roadrunner or Roadblasters use this variation derived from MAME source code since schema SP-299 doesn't work — also in MAME: SP-299 atari/atarisy1.cpp:1765 rtl/atarisys1/GPC.vhd:13 Graphic Priority Control (Atari custom chip 137419-101) This GPC was derived from System I SP-277 schematic — also in MAME: SP-277 atari/atarisy1.cpp:941 rtl/atarisys1/GPC.vhd:82 9D latch — also in MAME: 9D atari/atarisy1.cpp:1613 rtl/atarisys1/GPC.vhd:107 3F latch — also in MAME: 3F atari/atarisy1.cpp:1599 rtl/atarisys1/MAIN.vhd:11 For full details, see the GNU General Public License at www.gnu.org/licenses Based on SP-286 schematic — also in MAME: SP-286 atari/atarisy1.cpp:942 rtl/atarisys1/MAIN.vhd:518 14E latch sound data out — also in MAME: 14E atari/atarisy1.cpp:1785 rtl/atarisys1/MAIN.vhd:528 15E latch sound data in — also in MAME: 15E atari/atarisy1.cpp:1585 rtl/atarisys1/PFHS.vhd:13 Play Field Horizontal Scroll (Atari custom chip 137419-104) This PFHS was derived from System I SP-277 schematic — also in MAME: SP-277 atari/atarisy1.cpp:941 rtl/atarisys1/PFHS.vhd:93 4D latch — also in MAME: 4D atari/atarisy1.cpp:1612 rtl/atarisys1/SLAGS.vhd:13 Storage/Logic Array Graphics Shifter (Atari custom chip 137415-101) This SLAGS was derived from Marble Madness SP-276 schematic — also in MAME: SP-276 atari/atarisy1.cpp:1000 rtl/atarisys1/SLAGS.vhd:81 latch 8B — also in MAME: 8B atari/atarisy1.cpp:1598 rtl/atarisys1/SLAGS.vhd:92 latch 11A — also in MAME: 11A atari/atarisy1.cpp:1572 rtl/atarisys1/SYNGEN.vhd:13 System Clock and Sync Generator (Atari custom chip 137419-103) This SYNGEN was derived from System I SP-277 schematic — also in MAME: SP-277 atari/atarisy1.cpp:941 rtl/atarisys1/SYNGEN.vhd:152 82S129 256x4 TTL BIPOLAR PROM (Atari chip 136032.102) — also in MAME: 82S129 atari/atarisy1.cpp:807, 136032.102 atari/atarisy1.cpp:969 rtl/atarisys1/SYNGEN.vhd:179 Equations for PLA chip 7F Signetics 82S153 aka PLS153A (Atari custom chip 136032.103) /o19 = /i1 & i2 & i3 & i7 & i8 & i9 o18 = i1 & /i2 o17 = i1 & /i2 & /i3 + /i1 & i2 & /i3 + i1 & /i2 & i3 o16 = /i2 + i1 & i2 & /i3 + /i1 & i2 & i3 — also in MAME: 7F atari/atarisy1.cpp:1605, 82S153 atari/atarisy1.cpp:970, 136032.103 atari/atarisy1.cpp:970 rtl/atarisys1/VIDEO.vhd:11 For full details, see the GNU General Public License at www.gnu.org/licenses From SP-286 schematic — also in MAME: SP-286 atari/atarisy1.cpp:942 rtl/atarisys1/VIDEO.vhd:446 ALBNK is CTF in SP-299 — also in MAME: SP-299 atari/atarisy1.cpp:1765 rtl/atarisys1/VIDEO.vhd:497 as per SP-299 — also in MAME: SP-299 atari/atarisy1.cpp:1765 rtl/atarisys1/VIDEO.vhd:516 as per SP-299 — also in MAME: SP-299 atari/atarisy1.cpp:1765 rtl/atarisys1/VIDEO.vhd:521 as per SP-299 — also in MAME: SP-299 atari/atarisy1.cpp:1765 rtl/atarisys1/VIDEO.vhd:524 latch 4F — also in MAME: 4F atari/atarisy1.cpp:1594 rtl/atarisys1/VIDEO.vhd:550 slv_ROM_2B_addr(13) <= sl_ALBNK_CTF; -- not used because 2/3B ROM is only 8K — also in MAME: 3B atari/atarisy1.cpp:1597, 8K atari/atarisy1.cpp:1782 Cites MAME source — 5 Arcade-atarisys1.sv:304 Default MAME Controls Assignment rtl/atarisys1/AUDIO.vhd:162 Atari System 1 TTL motherboard PCB factory modification according to atarisy1.cpp from MAME Location A2 simply fixes a PCB layout pin swap issue with /COMPSYNC to match the schematic. rtl/atarisys1/CART.vhd:389 if Roadrunner or Roadblasters use this variation derived from MAME source code since schema SP-299 doesn't work rtl/atarisys1/TMS5220.vhd:13 References: TMS5220 datasheet, US Patent US4335277 and TMS5220.cpp from MAME source code. README.md:7 System-1 supported game cartridges according to MAME Says it was translated, ported or taken from MAME — 2 rtl/atarisys1/SLAPSTIC.vhd:13 SLAPSTIC 137412-104 GAUNTLET This SLAPSTIC was translated from MAME "slapstic.cpp" source code pretty much verbatim :) The original MAME C++ code is left in as comments rtl/atarisys1/TMS5220.vhd:15 IMPORTANT NOTES: 1) This implementation does NOT implement the schematic in US4335277 2) It is based primarily on MAME source code and aims to be "functionally equivalent" to the "TMS5220" chip but not identical in terms of electrical circu Shares text with the MAME driver without saying so — 1 rtl/atarisys1/SYNGEN.vhd:16 H 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 — shares text with atari/atarisy1_v.cpp:50
atarisys2# 720 Degrees, APB - All Points Bulletin, Championship Sprint, Paperboy … MiSTer-devel/Arcade-AtariSystem2_MiSTer @ 7ad07997 MAME compared: atari/atarisy2.cpp + 6 related file(s) Read: 34 HDL files, 9,303 lines (Quartus project)	MiSTer official	Mostly MAME	high	82%
Statements: 35 toward hardware, 106 toward MAME Cites hardware documentation that MAME's driver does not — 28 atarisys2.sv:124 paperboy TM-275 Table 1-3 (unchanged, and its labels predate this work) 720 TM-294 Table 1-3 + Figure 3-22, the game's own game options screen ssprint TM-290 Table 3-2 + Figure 3-20, the game's own switch settings screen TM-290 kee atarisys2.sv:1012 Loaded into the sound-bus eeprom[] so the game has valid coinage -- otherwise it powers up blank and "INSERT COIN" never credits (the coin input path itself is correct; verified vs SP-275 sheet 9A). atarisys2.sv:1436 SP-275 sheet 9A has it as the third/aux coin-door input; MAME called it IPT_COIN3 until commit 76f3936 reclassified it as IPT_SERVICE1, which is what the cabinet actually wires there. atarisys2.sv:1453 Physical option DIP switches (SP-275 sheet 9B, TM-275 tables 1-2/1-3), exposed in the OSD "Game Options" page and fed to the two POKEYs' pot lines (ALLPOT). atarisys2.sv:1659 SP-308 is the authority, and it is unambiguous: sheet 1B "Control Panel" S5A/S5B = FIRE (J24 pin 7, orange) S3A/S3B = SIREN (J24 pin 8, yellow) sheet 6A "Control Panel Inputs" SW5 -> LS244 5P in 11 -> out 9 = DAL1 (IN0 bit 1) SW3 -> LS atarisys2.sv:2028 LEVELS (schematic-derived rebalance): SP-275 sheet 9B "Audio Output Drivers" sums each chip into the TDA2002 through its own input resistor -- YM (YAM) R141/R144=47K, POKEY (PAUD) R139/R142=47K, TMS (TIAUD) R140/R143=68K -- so the board's i atarisys2.sv:2044 TMS5220 speech (tms_snd, signed 14-bit) is mono on real hardware (a single "TIAUD" net feeding the shared resistor mixer, sheet 9A) -- summed into BOTH channels equally. atarisys2.sv:2050 Two consequences: (1) The TMS `<<2` becomes the unity (loudest) speech level; the game runs speech at TMS bits 5-7 = 000 (gain 0.5, verified in MAME: 0x187a only ever = 0x1f/0x1e), so typical speech now plays at <<2 * 0.5 = <<1 -- i.e. 6 atarisys2.sv:2063 Base per-chip terms (schematic-derived, see LEVELS above): YM at 1/2 FS and POKEY <<9 (~1/2 FS) => ~1:1 (SP-275 sheet 9B equal 47K sums); TMS <<2 (mono -> summed into both channels equally; real speech is well under its 8191 FS, so <<2 is a atarisys2.sv:2066 Schematic-accurate chain (derived from SP-275 sheets 9A/9B). atarisys2.sv:2075 Analog audio chain -- SP-275 sheets 9A/9B. atarisys2.sv:2148 See the SP-308 note above. rtl/adc/adc0809.sv:19 The conversion time is settled: the default 64 clocks on the exact 625 kHz enable = 102.4 us sits inside the data-sheet 90-116 us window, and the handlebar, calibration and TM-275 control diagnostics all behave correctly on hardware at this rtl/main/sys2_analog_map.sv:40 SP-290 sheet 8B shows the pedal pot going into the ADC0809 through a 100 R series resistor with NO divider, i.e. the converter sees the full rail. rtl/main/sys2_main_bus.sv:616 See SP-275 sheet 6B. rtl/mem/sys2_sdram.sv:293 Measured on the fitted netlist, that slot was open at BOTH ends of the PVT range: the data reaches this flop at 35.003..42.192 ns while the 31.250 edge reaches it at 39.217..40.679 -- the unwanted edge sits INSIDE the arrival window, so whi rtl/sys2_video_timing.sv:5 Sources: SP-275 sheet 11A and MAME atarisy2.cpp commit d066f16. rtl/video/sys2_mob_decode.sv:8 The field masks are the MAME `atari_motion_objects_config` s_mob_config for atarisy2 (atarisy2_v.cpp @ d066f16), cross-checked against the schematics. rtl/video/sys2_mob_walker.sv:11 This follows the SCHEMATIC, not MAME. rtl/video/sys2_mob_walker.sv:43 This is the real hardware budget, not MAME's. The linked-list address advances on a strobe generated once every 16 of the 640 horizontal clocks and the pointer resets to the head each line, so the board visits exactly 640/16 = 40 entries pe rtl/video/sys2_mob_walker.sv:239 The 82S131 at 5P (confirmed from schematic sheet 12A) takes only MOPIC[2:0] as input and its three outputs supply MO graphics ROM address [8:6]; the higher MOPIC bits bypass the PROM entirely into the ROM address latches. rtl/video/sys2_palette.sv:7 Each channel is (colormap[nibble] * intensity[I]) >> 4, using the resistor/intensity ladders from schematic sheets SP16A-SP17A (integer reference values from MAME's atarisy2_v.cpp). rtl/video/sys2_priority.sv:6 Paperboy per-pixel layer priority (SP-275 sheet 15B; confirmed against MAME's atarisy2_v.cpp). rtl/video/sys2_priority.sv:11 The hardware rule (SP-275 sheet 15B): 1. rtl/video/sys2_video_render.sv:26 Scroll value fields per SP-275 sheet 15A: X = xscroll[15:6] (pixels, 0-1023) + bank0 = xscroll[3:0], effective on the following scanline after the CPU write. rtl/video/sys2_video_render.sv:344 Final per-pixel priority (SP-275 sheet 15B): the motion object competes with the playfield using the carried category, then the alpha layer is placed on top. README.md:171 Native raster. 640 × 416 total, 512 × 384 visible, 16 MHz pixel clock, ~60.096 Hz, with the blanking, sync, 32V and VBLANK edges transcribed off SP-275 shee README.md:175 Analog audio chain. The board filters per chip, not on the sum — SP-275 sheets 9A/9B give each of the YM, POKEY and TMS paths its own preamp pole, inter Says it was checked on “real hardware” — 6 atarisys2.sv:1617 positive Y is DOWN on the pad -- confirmed on hardware rtl/clocks/sys2_clocks.sv:32 T-11 headroom caveat: pinning the T-11 to EXACTLY 10 MHz drops it below the prior +6.7 % (10.67 MHz) rate, which had "masked a new-objects-arrive- late symptom." That symptom (graphic pop-in of houses/objects) was later root-caused to the s rtl/main/sys2_analog_map.sv:26 This block used to be a two-part VERIFY; both parts were answered by research and the whole path was then confirmed on hardware. rtl/main/sys2_analog_map.sv:43 Confirmed on hardware via APB's Pedal Test, which prints lo/hi/range/raw/ normalized rather than the Sprints' bare lo/value/hi: raw moves 00 -> 3F and normalized 00 -> FF as the pedal travels. rtl/main/sys2_main_bus.sv:598 Left in the mailbox, a stale byte becomes data-byte-1 of the next readout (cmd 0x0B high-score table) and shifts the whole 180-byte transfer by one -> the T-11's terminator check reads a data byte ('E'=0x45) instead of 0x55 -> $01C0=04 -> $ rtl/mem/sys2_sprite_byte_fifo.sv:45 DEPTH=16 / margin 4 is silicon-validated: on hardware the full inverted sum of the original 256 KiB sprite image matched, so the FIFO delivered every byte to the writer with no overflow. Notes where it differs from MAME — 1 atarisys2.sv:1784 Rate conversion (deflection -> turn rate) lives in sys2_analog_spin; see its header for why a springing thumbstick cannot map one-to-one onto a continuous-rotation encoder, and for the deliberate divergence from MAME's angle mapping on 720. Cites MAME source — 86 atarisys2.sv:112 MAME only fills in csprint's 0x80 bit and leaves bits 5:0 inheriting Paperboy's Lives/Bonus Life -- impossible for a racing game. atarisys2.sv:120 MAME uses generic `DEF_STR` stand-ins where a game has no matching enum -- 720's "Bonus Life" is really first bonus ticket at and its "Difficulty" is timer for STREET; APB's "Max Continues" is Add-A-Coin Control. atarisys2.sv:135 ssprint has NO switch-1 option; csprint's Auto High Score Reset is the one place the two Sprints genuinely differ, and MAME has that right. atarisys2.sv:138 However, refer to the Report Options screen in self-test to be sure" -- the manual hedges, so MAME's "Attract Lights" is kept rather than dropping the option. atarisys2.sv:140 APB's Add-A-Coin maximum reads "Unlimited" on the manual's top setting; MAME calls it 199, which is presumably the internal counter cap. atarisys2.sv:491 The raster is the same 512x384 as every other game; it is the MONITOR that is turned, which is why MAME renders APB 384x512 and why its self-test screen only matches ours after a rotation. atarisys2.sv:493 The direction is measured, not assumed: rotated CCW our frame is 0 px against MAME's, rotated CW it is 2432 px. atarisys2.sv:544 CCW, measured against MAME rather than guessed (see above). atarisys2.sv:1247 The board's tile ROM decodes only as many address lines as it has, so an over-range code wraps -- MAME writes that as `rawcode % gfx->elements()`. atarisys2.sv:1251 elements = HALF/16, i.e. MAME's tiles region / 32. atarisys2.sv:1392 joystick_0[4]=Throw R [5]=Throw L [6]=Coin [7]=Service Credit (J1 order in CONF_STR; the release MRA <buttons> MUST list them in the SAME order -- an MRA name list overrides the OSD labels, and a mismatch silently drives the wrong core b atarisys2.sv:1436 SP-275 sheet 9A has it as the third/aux coin-door input; MAME called it IPT_COIN3 until commit 76f3936 reclassified it as IPT_SERVICE1, which is what the cabinet actually wires there. atarisys2.sv:1479 MAME's ioport `defvalue` is NOT a transcription of those arrows -- it says 00 for paperboy DSW0 and 0x55 for 720 DSW1, and BOTH disagree with the manuals. atarisys2.sv:1480 Do not re-derive this from MAME. atarisys2.sv:1508 DSW1 is NOT game-independent -- see PB_DIP_MENU for the sourcing and the csprint deviation from MAME. atarisys2.sv:1659 SP-308 is the authority, and it is unambiguous: sheet 1B "Control Panel" S5A/S5B = FIRE (J24 pin 7, orange) S3A/S3B = SIREN (J24 pin 8, yellow) sheet 6A "Control Panel Inputs" SW5 -> LS244 5P in 11 -> out 9 = DAL1 (IN0 bit 1) SW3 -> LS atarisys2.sv:1667 Neither MAME nor the TM can tell you this. atarisys2.sv:1737 Rather than writing spinner deltas into the counter -- which is what MAME does, and which would bypass the 156 kHz sample rate, the 2x decode and the resolution bit -- each channel gets a `sys2_quad_gen` that emits REAL quadrature edges for atarisys2.sv:1743 Channel map, from each game's MAME PORT_MODIFY("LETAn"): atarisys2.sv:1757 What is OPEN is the DISTRIBUTION of those four counts, NOT a phase offset: MAME emits all four within +/-3 of the top, we emit one every 36. atarisys2.sv:2048 sys2_sound_bus decodes 0x187a into three Q0.8 gains (mix_gain_ym/pk/tms, 256 = unity) via the MAME atarisy2 mixer_w resistor model; each chip's base term below is scaled by its gain. rtl/adc/adc0809.sv:18 Source: National ADC0808/ADC0809 data sheet (8 clocks/bit, 64-clock nominal conversion at f_CLK); MAME d066f16 adc0808_device functional model. rtl/main/sys2_analog_map.sv:14 Channel assignment, from each game's MAME PORT_MODIFY("ADCn"): rtl/main/sys2_analog_map.sv:31 MAME declares the Sprint/APB pedals `PORT_MINMAX(0x00,0x3f) ... rtl/main/sys2_analog_map.sv:35 PORT_INVERT IS a bitwise `~` of the accumulated value -- `src/emu/ioport.h` comments it "positional control bits are active low" and `ioport.cpp` applies a plain `value = ~value`. rtl/main/sys2_analog_map.sv:54 TM-290 Fig 3-9 prints a REAL Super Sprint cabinet's Pedal Test: rest ~0x67, pressed ~0x96 -- mid-scale, ~0x2F of travel, and INCREASING with press, i.e. opposite in direction and offset to the MAME-derived 0xff -> 0xc0 here. rtl/main/sys2_main_bus.sv:105 IN0 is not the only such port -- MAME's ssprint also does PORT_MODIFY("IN1"), which ROTATES the coin bits (paperboy 0x20/0x40/0x80 = COIN3/COIN1/COIN2; ssprint = COIN1/COIN2/COIN3). rtl/main/sys2_main_bus.sv:149 MAME 0.288 bankselect_w, exactly: bank = bitswap(page ^ 3, 5,4,1,0,3,2) -- the XOR comes FIRST, then the low bit-pairs swap. rtl/main/sys2_main_bus.sv:160 ssprint's region mirrors only pairwise (2=4, 3=5, ...), and bank^0xC crosses the pair: without the XOR its map-source read (bankselect 0x1000, MAME bank 13, region 0x2A000 = track data) served region 0x12000 = a sea of 0x0F0F -- which the d rtl/main/sys2_main_bus.sv:395 Derived from MAME 0.288 atarisy2.cpp INPUT_PORTS_START(paperboy) plus each game's PORT_MODIFY("IN0"): rtl/main/sys2_main_bus.sv:533 Per MAME d066f16 and the SP6A transcription, each latch samples its own enable bit at the set event; delivery to the T-11 is ungated, so clearing an enable bit never clears an already-pending latch. rtl/main/sys2_main_bus.sv:578 ssprint's boot checks fast: it found nothing, touched sound_reset (0x15A0 -- the failure branch MAME's IO-read trace never takes), and never started attract. rtl/rom/sys2_char_rom.sv:35 16 KiB: Paperboy populates only the first 8 KiB (512 chars) and the rest is 0xff fill, but 720/ssprint/csprint/apb all ship 0x4000 and MAME masks the alpha code to 10 bits (`code = data & 0x3ff`) for every game in the driver. rtl/rom/sys2_maincpu_rom.sv:9 The MAME maincpu region is a sparse 0x90000-byte logical image populated only in 0x8000-byte windows selected by the 0x8000-granular index addr[19:15] -- Paperboy uses {1, 2, 6, 10, 14}, the family union is {1, 2, 3, 6, 10, 11, 14, 15}. rtl/rom/sys2_maincpu_rom.sv:121 MAME's ASSEMBLED region replicates each banked ROM across the region (ROM_RELOAD): paperboy's units mirror 4-way (2=3=4=5, 6=7=8=9, 10=11=12=13, 14=15=16=17), the Sprints' pairwise (2=4, 3=5, 10=12, 11=13, 14=16, 15=17). rtl/rom/sys2_rom_loader.sv:6 The MiSTer MRA emits the six MAME logical regions as one ordered index-0 byte stream (see rtl/rom/sys2_rom_layout.vh); index 1 carries the four-byte game descriptor. rtl/rom/sys2_sprite_rom_arb.sv:16 The MO parameter field is 14 bits ((word0&7)<<11 \| (word1&0x7ff)) but NO region here can be indexed by 14 -- masking to 11 or 13 is MAME's `tile_data::set()` wrap (rawcode % gfx->elements()), the same rule the playfield already follows. rtl/rom/sys2_sprite_rom_arb.sv:159 MAME's code % elements, expressed as the mask it actually is. rtl/slapstic/sys2_slapstic.sv:20 Reference cores are weighed rather than trusted, and that is a second copy of MAME rather than independent evidence: the type-105 column is the one with hardware behind it, and simulation proves this module reproduces the proven 105 impleme rtl/slapstic/sys2_slapstic.sv:23 The other four columns rest on MAME alone. rtl/slapstic/sys2_slapstic.sv:129 On System 2 the slapstic is configured at 0x8000-0x81FF -- MAME gives all five games `set_range(m_maincpu, AS_PROGRAM, 0100000, 0100777, 0)`, octal. rtl/slapstic/sys2_slapstic.sv:138 For chips 103-110 -- which is all five of ours -- `active_103_110` builds alt1 with test_any, and MAME says why in its own section header: "Active state, 103-110, has direct, alt and bitwise, and alt can be done ANYWHERE". rtl/slapstic/sys2_slapstic.sv:144 Verified exhaustively over all 65536 addresses for all five types: this pairing reproduces MAME's matcher set exactly, matcher for matcher. rtl/slapstic/sys2_slapstic.sv:148 Reading MAME's `checker::test_in` and generalising it to every matcher is the natural mistake, but the call sites are four lines of C++ that say `test_any` in plain sight, under a comment that states the rule in English. rtl/slapstic/sys2_slapstic.sv:154 MAME's `checker::test_any`: the matcher's own mask and value ONLY, with no window folded in, so it fires anywhere in the 64K space. rtl/sys2_video_timing.sv:5 Sources: SP-275 sheet 11A and MAME atarisy2.cpp commit d066f16. rtl/t11/t11_core.sv:5 Behavioral sources: DEC DCT11-AA User's Guide and MAME t11 at d066f16. rtl/video/sys2_mob_decode.sv:8 The field masks are the MAME `atari_motion_objects_config` s_mob_config for atarisy2 (atarisy2_v.cpp @ d066f16), cross-checked against the schematics. rtl/video/sys2_mob_vscan.sv:8 This is the subtle, MAME-derived coordinate math, locked into a tested module so the sprite layer cannot repeat the playfield colour bug's "shapes fine, placement wrong" class of error. rtl/video/sys2_mob_vscan.sv:12 From MAME atarimo.cpp render_object (atarisy2: m_xoffset=m_xscroll=m_yscroll=0, no vflip, no width; motion objects are screen-absolute): ypos = -Y_field; ypos -= height << 4; // height in 16px tiles ypos &= 0x1ff; // bi rtl/video/sys2_mob_walker.sv:6 Paperboy motion-object linked-list walker (MAME atarimo.cpp build_active_list / render_object @ d066f16). rtl/video/sys2_mob_walker.sv:15 MAME does two things the PCB does not: it sets maxperline = 0 (effectively unlimited) and it keeps a visited[] bitmap and stops the moment a link repeats. rtl/video/sys2_mob_walker.sv:17 Consequences of the real behaviour: a terminal self-linked object is re-processed until the 40 slots expire (harmless when it re-renders identical pixels), and a short CYCLIC list of overlapping visible objects can end with a different fina rtl/video/sys2_mob_walker.sv:24 Objects are composited in walk order with later writes overwriting earlier opaque pixels -- MAME draws the active list front-to-back into one bitmap, so the last list entry covering a pixel wins. rtl/video/sys2_mob_walker.sv:28 render_object coordinate order (verbatim from MAME, atarisy2 xoffset/scroll/ nextneighbor all 0): xpos = X_field; (next_xpos hold inert); if neighbor xpos = last_xpos + 16; last_xpos = xpos (pre-fold); then xpos &= 0x3ff and if xpos >= 512 rtl/video/sys2_mob_walker.sv:32 last_xpos is an 11-bit register here (MAME uses an unbounded int); they differ only for a neighbour chain whose raw xpos exceeds 2047, which does not occur in Paperboy. rtl/video/sys2_mob_walker.sv:55 MAME uses maxperline = 0 (unlimited) and we previously followed it at 256, so this is a DELIBERATE divergence from our own oracle. rtl/video/sys2_mob_walker.sv:56 Override to 256 to reproduce MAME when comparing against MAME rather than against the board. rtl/video/sys2_mob_walker.sv:136 rawx is 11-bit; the neighbor add wraps mod 2048 (the documented finite-width deviation from MAME's unbounded int, immaterial for Paperboy's lists). rtl/video/sys2_mob_walker.sv:230 last_xpos updates for every object (MAME: unconditional, pre-fold). rtl/video/sys2_mob_walker.sv:244 MAME increments the combined integer code and DOES carry, so this is a deliberate divergence from our own oracle -- and one no MAME-comparison can detect, because MAME shares the error. rtl/video/sys2_palette.sv:7 Each channel is (colormap[nibble] * intensity[I]) >> 4, using the resistor/intensity ladders from schematic sheets SP16A-SP17A (integer reference values from MAME's atarisy2_v.cpp). rtl/video/sys2_palette.sv:44 Colour steps -- the one palette value still resting on MAME rather than the schematic. rtl/video/sys2_palette.sv:46 MAME's `color_table` is a bare hand-written array with no derivation comment, unlike its `intensity_table` which is built from named conductances (round 4 proved those ARE the branch conductances normalised to 256). rtl/video/sys2_palette.sv:53 We ship MAME's table anyway, deliberately. rtl/video/sys2_palette.sv:53 MAME is the only oracle we can actually validate against -- the frame comparison is pixel-exact against it on three scenes -- so swapping in a table validated by nothing would break that comparison and trade a known-good approximation for a rtl/video/sys2_palette.sv:61 Expect the MAME frame comparison to fail when it is defined -- that is correct and expected, because that check measures agreement with MAME, which is exactly what this option changes. rtl/video/sys2_palette.sv:63 Default (undefined) = MAME: 0,3,4,5,6,7,8,9,10,11,12,13,14,14,15,15 PALETTE_SPICE_COLORMAP 0,6,7,7,8,9,9,10,10,11,12,12,13,14,14,15 rtl/video/sys2_pen4.sv:6 Shared 4-pixel 4bpp pen kernel for the Atari System II planar packing (MAME RGN_FRAC(1,2): planeoffset { 0, 4, RGN_FRAC(1,2)+0, RGN_FRAC(1,2)+4 }, MSB-first within each byte). rtl/video/sys2_pf_linebuf.sv:251 The real board's tile ROM only decodes as many address lines as it has, so an over-range code wraps; MAME reproduces that as `rawcode % gfx->elements()`. rtl/video/sys2_priority.sv:6 Paperboy per-pixel layer priority (SP-275 sheet 15B; confirmed against MAME's atarisy2_v.cpp). rtl/video/sys2_priority.sv:17 This is exactly MAME's `!((mopri + pfpri) & 2) \|\| !(pf & 8)`. rtl/video/sys2_video_render.sv:15 Tile word: code[9:0], bank-select[10], colour group[13:11], category[15:14] inverted (MAME (~data>>14)&3, fed to the priority mixer). rtl/video/sys2_video_render.sv:18 4bpp pen via the MAME pflayout planar packing: the first ROM half (rom_lo) holds pen bits 3,2 and the second half (rom_hi) pen bits 1,0, MSB-first within each nibble. rtl/video/sys2_video_render.sv:149 MAME's yscroll_w updates m_playfield_tile_bank[1] OUTSIDE its `if (!(newscroll & 0x10))` conditional (src/mame/atari/atarisy2_v.cpp) -- bit 4 schedules the scroll load, the bank takes effect on the write in both modes, followed by mark_all_ rtl/video/sys2_video_render.sv:162 bank0/xscroll is NOT the same case and is deliberately left alone: it is applied at the next line_start, and MAME's segment granularity (update_partial on scroll writes) makes that the same scanline boundary. rtl/video/sys2_video_render.sv:263 MAME: code = (bank[(data>>10)&1] << 10) \| (data & 0x3ff), with a FOUR-bit bank (xscroll&0x0f / yscroll&0x0f) -- 14 bits, up to 16384 tiles for APB. rtl/video/sys2_video_render.sv:272 Dropping them is exactly `code % 4096`, and 4096 is Paperboy's decoded tile-element count, so this reproduces MAME's own wrap: tile_data::set() does `rawcode % gfx->elements()` before the fetch. rtl/video/sys2_video_render.sv:292 4bpp playfield pen via the shared sys2_pen4 kernel (MAME `pflayout` planar packing: FIRST region half rom_lo = pf_rom_data[7:0] -> pen bits 3,2; SECOND half rom_hi = pf_rom_data[15:8] -> pen bits 1,0). rtl/video/sys2_video_render.sv:417 MAME (~data >> 14) & 3 README.md:24 All 29 remaining MAME clone sets — other revisions and the German, French and Spanish releases — ship under `releases/_alternatives/`. README.md:27 `Paperboy (prototype)` is `MACHINE_NOT_WORKING` in MAME with every ROM a `BAD_DUMP`. README.md:189 MAME differs on all three, and following MAME instead breaks Championship Sprint and 720. README.md:190 720's "MO Height Test" produces a ragged staircase 44 pixels taller than MAME's — that staircase is what the hardware draws. README.md:302 The MAME team — `atarisy2.cpp` and `atarisy2_v.cpp` were the functional cross-reference for everything the schematics do not settle. README.md:303 References in the RTL comments of the form `mame/atarisy2.cpp` point at MAME's own sources. Says it matches, follows or was checked against MAME — 14 atarisys2.sv:109 sw7 is the HIGH bit of each pair and sw8 the low one (verified: MAME's ssprint values reproduce TM-292's switch table exactly under that mapping). atarisys2.sv:118 Every field below was checked against its operator manual; every encoding MAME had was correct, and what the manuals changed was the NAMES. atarisys2.sv:1655 The bus's bit numbers were always right -- sys2_main_bus puts btn2 on IN0 bit1 and btn3 on bit3, matching MAME's 0x02/0x08 -- but the joystick bits feeding them were inverted, so the button the MRA labels "Siren" sounded nothing and fired i atarisys2.sv:2050 Two consequences: (1) The TMS `<<2` becomes the unity (loudest) speech level; the game runs speech at TMS bits 5-7 = 000 (gain 0.5, verified in MAME: 0x187a only ever = 0x1f/0x1e), so typical speech now plays at <<2 * 0.5 = <<1 -- i.e. 6 rtl/main/sys2_analog_map.sv:49 All four hops were traced: this module emits `PEDAL_RELEASED - travel` (0xFF idle / 0xC0 floored, matching MAME) -> `adc_in` -> `adc0809` straight capture -> {8'hff, data}. rtl/main/sys2_main_bus.sv:119 Playfield scroll/bank registers, the raw 16-bit values latched on the CPU write (matching MAME's shared m_xscroll/m_yscroll). rtl/main/sys2_main_bus.sv:164 Verified against MAME bank writes: 0x1000->13, 0xE000->62, 0xF000->63 (bankoffset[] table in atarisy2.cpp agrees). rtl/main/sys2_main_bus.sv:586 The command is the low byte, so only a low-byte write strobes the latch and its pending flag (matching MAME's even-byte soundlatch handler). rtl/slapstic/sys2_slapstic.sv:127 Two matchers, because MAME has two, and the difference is not an oversight. rtl/slapstic/sys2_slapstic.sv:130 But it taps the WHOLE address space and decides per matcher whether the window applies (MAME slapstic.cpp): rtl/slapstic/sys2_slapstic.sv:155 Used by exactly one matcher -- alt1 -- and only because MAME uses it there for chips 103-110. rtl/video/sys2_pen4.sv:16 The four pens are spelled out with constant bit-selects (the verified form from the MAME reference) -- pure combinational. rtl/video/sys2_video_render.sv:409 10 code bits, matching MAME's `code = data & 0x3ff` for every System 2 game. README.md:201 The video path is pixel-exact against MAME frame captures on four of the five games, and service-mode video RAM is byte-identical to MAME on every game that kee Says it was translated, ported or taken from MAME — 2 rtl/main/sys2_main_bus.sv:406 That is MAME's mapping verbatim, not an omission here -- APB's remaining controls are the LETA wheel and the ADC pedal, which do not pass through this word. rtl/slapstic/sys2_slapstic.sv:18 Transcribed from the tables in the Arcade-Atari-system1 core's `SLAPSTIC.vhd`, which carries MAME's `slapstic_data` structs verbatim as comments. Shares text with the MAME driver without saying so — 4 rtl/video/sys2_palette.sv:21 Intensity ladder: ZB=115, Z3=78, Z2=37, Z1=17, Z0=9. — shares text with atari/atarisy2_v.cpp:160 rtl/video/sys2_pen4.sv:7 (MAME RGN_FRAC(1,2): planeoffset { 0, 4, RGN_FRAC(1,2)+0, RGN_FRAC(1,2)+4 }, — shares text with atari/atarisy2.cpp:1144 rtl/video/sys2_pf_linebuf.sv:89 code = (bank[(data>>10)&1] << 10) \| (data & 0x3ff) — shares text with atari/atarisy2_v.cpp:31 rtl/video/sys2_video_render.sv:263 MAME: code = (bank[(data>>10)&1] << 10) \| (data & 0x3ff), with a FOUR-bit bank — shares text with atari/atarisy2_v.cpp:31
AtariTetris# Tetris (Atari) MiSTer-devel/Arcade-ATetris_MiSTer @ adde7f86 MAME compared: atari/atetris.cpp + 2 related file(s) Read: 20 HDL files, 5,715 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	1%
Statements: 2 toward hardware Cites hardware documentation that MAME's driver does not — 2 rtl/Pokey/pokey_poly_17_9.vhdl:53 next state (as pokey decap) rtl/Pokey/pokey_poly_17_9.vhdl:74 from pokey schematics
Athena# Athena, Country Club, Lee Trevino's Fighting Golf MiSTer-devel/Arcade-Athena_MiSTer @ c475eba6 MAME compared: snk/snk.cpp + 2 related file(s) Read: 82 HDL files, 9,729 lines (Quartus project)	MiSTer official	Both	low	29%
Statements: 13 toward hardware, 4 toward MAME Cites hardware documentation that MAME's driver does not — 13 rtl/clocks/A5001_1.v:1 Author: @RndMnkIII Date: 13/03/2022 Converted from ArmoredScrumObject_pal16r6a_3.jed using MAME's jedutil tool Many thanks to pldarchive.co.uk for the JED file. rtl/clocks/A6001_1.v:1 Athena A6001-1 PAL16R6 Author: @RndMnkIII Date: 03/06/2022 Converted from SNK_A6001-1_PAL16R6.jed using MAME's jedutil tool Many thanks to @Porchy and pldarchive.co.uk for the JED files. rtl/clocks/TNKIIICore_Clocks_Sync.sv:203 74LS30 8-input positive NAND gate rtl/final_video/A5001_3.v:1 A5001_3.v Author: @RndMnkIII Date: 23/05/2022 Derived from TNKIII schematics and ASO PAL. rtl/front/TNKIIICore_LineBuffer_sync.sv:120 74LS20 4-input NAND gate rtl/ttl/ttl_74107a_AsyncClr.v:1 74LS107A: Dual J-/K flip-flop with clear; negative-edge-triggered Inputs Outputs rtl/ttl/ttl_74107a_sync.v:1 74LS107A: Dual J-/K flip-flop with clear; negative-edge-triggered Inputs Outputs rtl/ttl/ttl_74163a_sync.v:1 4-bit modulo 16 binary counter with parallel load, * FOR SYNTHESIS * Synchronous Reset (SRn) -> LS163A <START_TEMPLATE> ttl_74161a #(.DELAY_RISE(20), .DELAY_FALL(25)) <NAME> (.Clear_bar(), .Load_bar(), .ENT(), .ENP(), .D(), .Clk(), .RCO rtl/ttl/ttl_74373.sv:1 ttl_74373.sv Octal D transparent latch function table, logic diagrams and switching characteristics extracted from TI 74LS373 Datasheet. rtl/ttl/ttl_74374_sync.sv:1 ttl_74374_sync.sv Octal D edge triggered FF function table, logic diagrams and switching characteristics extracted from TI 74LS374 Datasheet. rtl/ym3526/jtopl_exprom.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots. rtl/ym3526/jtopl_logsin.v:16 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots. rtl/ym3526/jtopl_op.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots. Cites MAME source — 2 rtl/clocks/A5001_1.v:1 Author: @RndMnkIII Date: 13/03/2022 Converted from ArmoredScrumObject_pal16r6a_3.jed using MAME's jedutil tool Many thanks to pldarchive.co.uk for the JED file. rtl/cpuA_B/AthenaCore_CPU_A_B_sync.sv:582 ONLY WRITABLE VIDEO RELATED REGISTERS (TNKIII) 1 1 1 1 1 \| 1 \| Address: 5 4 3 2 1 \| 0 9 8 \| 7 6 5 4 3 2 1 0 16'hC800 1 1 0 0 1 \| 0 0 0 \| x x x x x x x x MSB 16'hC900 1 1 0 0 1 \| 0 0 1 \| x x x x x x x x FSX 16'hCA00 Says it was translated, ported or taken from MAME — 1 rtl/clocks/A6001_1.v:1 Athena A6001-1 PAL16R6 Author: @RndMnkIII Date: 03/06/2022 Converted from SNK_A6001-1_PAL16R6.jed using MAME's jedutil tool Many thanks to @Porchy and pldarchive.co.uk for the JED files. Shares text with the MAME driver without saying so — 1 rtl/cpuA_B/AthenaCore_CPU_A_B_sync.sv:227 void snk_state::countryc_trackball_w(uint8_t data) — shares text with snk/snk.cpp:1196
Badlands# Bad Lands MiSTer-devel/Arcade-Badlands_MiSTer @ f1589516 MAME compared: atari/badlands.cpp + 4 related file(s) Read: 33 HDL files, 7,410 lines (Quartus project)	MiSTer official	Both	medium	78%
Statements: 113 toward hardware, 46 toward MAME, 35 not counted Cites hardware documentation that MAME's driver does not — 109 rtl/badlands_core.sv:11 badlands_main sheets 1 and 2 plus the whole memory path: fx68k 22E, the GAL 26C / LS138 24C decode, the 28R LS163A wait sequencer, the 8 K x 8 22V video/work RAM and its GAL 21R slot schedule, the 22J VBLANK latch and 13J IPL encoder, the rtl/badlands_core.sv:38 ce_14m = clk_sys / 4 = 14.318181 MHz 14M: CRAM byte rate, GAL 21R clock ce_7m = clk_sys / 8 = 7.159091 MHz 7M: pixel, H counter, 68000 ce_1h = clk_sys / 16 = 3.579545 MHz 1H: YM2151 phiM, LETA CK ce_2h = clk_sys / 32 = 1.78 rtl/badlands_core.sv:80 The 2816A's self-timed byte write, in clk_sys cycles: the data-sheet 10 ms at 57.272724 MHz. rtl/badlands_core.sv:335 GAL 9N pin 12: /MISC2 and R/W come from the main board, AUDFULL from the 15J flag on sheet 5, and the D8 pair goes back into badlands_main's read mux. rtl/badlands_core.sv:350 SOUND — sheet 5 (there is no separate audio PCB) rtl/main/badlands_addr_decode.sv:3 Bad Lands address decode -- the GAL 26C (136074-1001), the LS138 24C it enables, and the program-ROM chip/output enables, from schematic sheet 2. rtl/main/badlands_addr_decode.sv:11 ---- GAL 26C, a GAL16V8 in 16L8 mode, all outputs combinatorial ---------- pins 1..8 = /AS, R/W, A13, A14, A15, A16, A17, A23 pins 9, 11 = BS0, BS1 from the empty SLAPSTIC socket 28C: in no product term, so there is no SLAPSTIC to implem rtl/main/badlands_addr_decode.sv:40 ---- LS138 24C ---------------------------------------------------------- G1 (6) = +5 V, /G2A (4) = GND, /G2B (5) = /MISC, C,B,A (3,2,1) = A15,A14,A13 rtl/main/badlands_addr_decode.sv:84 ---- LS138 24C outputs, active low ----------------------------------- rtl/main/badlands_addr_decode.sv:128 ---------------- LS138 24C ------------------------------------------- /G2A = GND, G1 = +5 V, /G2B = /MISC ; C,B,A = A15,A14,A13 rtl/main/badlands_cpu.sv:3 Bad Lands main CPU -- fx68k (cycle-exact 68000) wired as schematic sheet 2 draws the 22E MC68000. rtl/main/badlands_cpu.sv:13 ---- the clock phase, and why it matters -------------------------------- The SOS-2's 7M pin drives one load: 23R 74F74 half 2's D input, clocked by 14M rising. rtl/main/badlands_cpu.sv:17 7M -> GAL 26R CLK, GAL 21R input, GAL 9N, LB ACLK, the H counter /7M -> 68000 22E CLK (pin 15), 28R LS163A CLK (pin 2), 7N, 10K rtl/main/badlands_cpu.sv:20 The CPU and the /DTACK sequencer run on /7M while GAL 26R and the video side run on 7M; that half-cycle stagger is deliberate. rtl/main/badlands_cpu.sv:35 badlands_dtack takes the same (pcnt == 4) tick, which is what sheet 2 wires to its LS163A. rtl/main/badlands_cpu.sv:38 ---- pins as sheet 2 wires them ----------------------------------------- rtl/main/badlands_cpu.sv:55 The same net drives the 28R LS163A's ENT, so an IACK gets no /DTACK and can only end through the CPU's own VPA path -- badlands_dtack's business, not this module's. Here we just publish `fc` and take `vpa_n`. rtl/main/badlands_cpu.sv:97 the /7M rising tick, so badlands_dtack's LS163A can use the very same edge sheet 2 wires to its pin 2 rtl/main/badlands_cpu.sv:137 double bus fault; no load on sheet 2 rtl/main/badlands_dtack.sv:3 Bad Lands /DTACK -- the 28R 74LS163A wait-state sequencer of schematic sheet 2, plus the 19J LS08 that ORs in the video RAM's /RTIME. rtl/main/badlands_dtack.sv:7 Structure ported from `Arcade-Blasteroids_MiSTer/rtl/main/blstroid_dtack.sv` (GPL-3.0, same author, a 12C LS163A doing the same job). rtl/main/badlands_dtack.sv:11 ---- the part, as sheet 2 wires it -------------------------------------- 6,5,4,3 D,C,B,A = /RAM , /AUDRESD , /EEROM , /AUDRESD rtl/main/badlands_dtack.sv:20 19J LS08: pin 2 = /RTIME (GAL 21R pin 14), pin 1 = /RCO, pin 3 = /DTACK => /DTACK = /RTIME AND /RCO, i.e. asserted when RCO = 1 or /RTIME = 0. rtl/main/badlands_dtack.sv:65 GAL 21R pin 14 -> 19J LS08 pin 2 rtl/main/badlands_dtack.sv:75 On the LS163A the ripple carry is RCO = QA.QB.QC.QD.ENT, so /VPA kills RCO as well as the count. rtl/main/badlands_eeprom_2816.sv:3 Xicor 2816A (2 K x 8) EEPROM at 27J plus the 22J F74 unlock flop and the 19J LS08 that gates its /OE -- schematic sheet 2. rtl/main/badlands_eeprom_2816.sv:14 ---- wiring ------------------------------------------------------------- 19,22,23,1 A10..A7 = 68000 A11, A10, A9, A8 2-8 A6..A0 = 68000 A7, A6, A5, A4, A3, A2, A1 17..9 D7..D0 = the 68000's D7:0 -- the odd / low byte lane rtl/main/badlands_eeprom_2816.sv:27 ---- the unlock / lock protocol ----------------------------------------- 22J F74 half 1: D(2) = GND CLK(3) = /WRL (rising = the end of any 68000 write) /PRE(4)= /UNLOCK (a write to 0xFEE001, LS138 24C Y7) /CLR(1)= /RES Q(5) -> 1 rtl/main/badlands_inputs.sv:3 Bad Lands inputs -- /SWITCHES (18C LS244), the LETA 20C, the two steering quadrature generators and the LM556 pedal timers of schematic sheet 1. rtl/main/badlands_inputs.sv:65 ============ pedals ==================================================== One LM556 at 26A, both halves used. rtl/main/badlands_inputs.sv:171 badlands_pedal_556 -- one half of the LM556 at 26A plus its two RC networks. rtl/main/badlands_irq.sv:3 Bad Lands interrupts -- the 22J 74F74 VBLANK latch and the 13J 74F00 that encodes /IPL0, from schematic sheet 2. rtl/main/badlands_irq.sv:44 LS138 24C Y1, level, active low (write 0xFE2001) rtl/main/badlands_irq.sv:45 15J sheet 5, active low -> /IPL1 directly rtl/main/badlands_irq.sv:51 ---------------- 22J 74F74 half 2 ----------------------------------- Set by the rising edge of VBLANK, cleared while /VIRQACK is low. rtl/main/badlands_irq.sv:53 /CLR dominates the clock on a 74F74, so the clear is tested first. rtl/main/badlands_irq.sv:64 ---------------- 13J 74F00 pin 8 and the two direct nets ------------- rtl/main/badlands_main.sv:28 Several reads drive only part of it: /MISC2 read -- GAL 9N drives D8 only /SWITCHES -- 18C LS244 drives D7:0 only /LETA -- the LETA drives D7:0 only /AUDRD -- 13F LS374 drives D15:8 only /CRAM -- 8F LS245 drives D15: rtl/main/badlands_main.sv:44 A23 = 0 there, so /RAM, /EEROM and /AUDRESD are all inactive and the 28R LS163A loads V = 15, where RCO asserts /DTACK at once: zero wait states, the cycle completes, the 68000 does not hang and the watchdog is not invoked. rtl/main/badlands_main.sv:99 GAL 9N pin 12 sits in the video block on the real board (sheet 4), so the D8 = AUDFULL read at 0xFC0000 comes in here rather than being formed locally; `misc2_n` and `cpu_rw` go out to that same GAL. rtl/main/badlands_main.sv:198 /MISC only enables the LS138 24C, whose eight Y outputs are the strobes this module actually uses; a13s/a14s are the empty SLAPSTIC socket's pass-throughs and are already folded into `rom_a`, and rom_oe_lo/hi pick which 27512 pair answers, rtl/main/badlands_main.sv:298 the 28R LS163A wait sequencer rtl/main/badlands_watchdog.sv:3 Bad Lands power-on reset and watchdog -- the Q1 2N5306 / R30 / C33 POR node and the 28A 74LS197 of schematic sheet 1. rtl/main/badlands_watchdog.sv:21 ---- 28A 74LS197 -------------------------------------------------------- D (11) = +5 V ; C (3) = B (10) = A (4) = GND => the preset is 8 CLK1 (8) = VBLANK ; CLK2 (6) = QA (5) (the two stages cascade) /CLR (13) = the POR node rtl/main/badlands_watchdog.sv:55 It does not reach the SOS-2, the LETA, the PF bank flop 18S, the MO/priority flops 15V/18R, the PIXCLK flop 14E, the sound IRQ latch 14E or either mailbox flag in 15J; the sound section is reset only by /AUDRES. rtl/main/badlands_watchdog.sv:74 LS138 24C Y0, level, active low (write 0xFE0001) rtl/main/badlands_watchdog.sv:111 ---------------- 28A 74LS197 ---------------------------------------- Counts on the falling edge of CLK1 = VBLANK, i.e. at the start of vertical blank. rtl/mem/badlands_prog_rom.sv:21 SLAPSTIC socket 28C is empty and GAL 26C passes A13/A14 straight through (`o18 = i3`, `o19 = i4`), so 0x008000-0x00FFFF is plain ROM with nothing to bank. rtl/mem/badlands_vram.sv:3 Bad Lands video / work RAM -- the one 8 K x 8 SRAM at 22V, its four address multiplexers, GAL 21R (136074-1002), the 1H byte-lane scheme and the 19N / 22K / 28N / 28L / 22N data path. rtl/mem/badlands_vram.sv:13 ---- the part ------------------------------------------------------------ One 8 K x 8 100 ns SRAM (137535-004) at 22V. rtl/mem/badlands_vram.sv:60 ---- the sampling phase, which is forced --------------------------------- 23R (which makes 7M) and GAL 21R are both clocked by 14M rising, so the GAL samples 7M, 1H, 2H, 4H pre-edge. rtl/mem/badlands_vram.sv:83 /RAMWP = 17J F32 OR( GAL 21R pin 15 , MODCLK ) -> 22V /WE and MODCLK (= 7M delayed a quarter period, 50 % duty) is low over pcnt 2..5, so /RAMWP is one clean ~70 ns pulse inside each H count. rtl/mem/badlands_vram.sv:240 26T 74F153 -> A12, A6 rtl/mem/badlands_vram.sv:247 28T 74F153 -> A8, A7 rtl/mem/badlands_vram.sv:254 23T 74F157 (SEL = 2H, /E = 4H) -> A11, A10, A9, A1 rtl/mem/badlands_vram.sv:259 21T 74F157 (SEL = /UTIME, /E = GND) -> A5, A4, A3, A2 rtl/mem/badlands_vram.sv:322 28N is a 74F373 transparent latch, not a register: LE = /2H, so D7:0 follows the RAM bus for the whole of h = 0 and h = 1 and only closes at the start of h = 2. rtl/video/badlands_cram.sv:3 Bad Lands — the colour-RAM port: the 2 K x 8 SRAM at 8K, the 10K F374 address latch, the 8J A0 mux, the 19K/8F CPU path, the 3K byte-0 holding register, the 1K/5K HC273 output registers and the 14E/4J PIXCLK gate. rtl/video/badlands_cram.sv:6 Schematic sheet 4 grids 8K, 10K, 19K, 8F, 8J, 3K, 1K, 5K, 14E, 4J. rtl/video/badlands_cram.sv:23 10K latches at 7M falling; then 7M = 0 gives A0 = 0 (byte 0 = colour word D15:8, held by 3K at the next 7M rising edge) and 7M = 1 gives A0 = 1 (byte 1 = D7:0, taken by 5K directly). rtl/video/badlands_cram.sv:33 That is the only blanking mechanism on the board; sheet 6 has no /BLANK input. rtl/video/badlands_cram.sv:94 10K 74F374 — the video address latch (CK = /7M rising = 7M falling) rtl/video/badlands_dac.sv:5 Schematic sheet 6. rtl/video/badlands_dac.sv:50 the raw gun codes, for anyone reproducing sheet 6 rtl/video/badlands_hstrobes.sv:3 Bad Lands — GAL 26R (136074-2000) at 26R, the horizontal strobe generator, plus the 13J F00 inverter that makes `8HD6H` and the 13V LS175 `/HSYNC` delay network (R98/R99/R100). rtl/video/badlands_hstrobes.sv:43 The /HSYNC delay: 13V 74LS175 is clocked by PVCLK rising (once per 16 counts, at the n = 5 -> 6 boundary). rtl/video/badlands_hstrobes.sv:79 ---- GAL 26R pins (all registered on 7M rising) ---------------------- rtl/video/badlands_hstrobes.sv:214 13J 74F00 pins 1 = /8HD6H, 2 = +5 V, 3 = 8HD6H (a NAND as an inverter). rtl/video/badlands_hstrobes.sv:229 13V 74LS175 — the /HSYNC delay line, clocked by PVCLK rising rtl/video/badlands_hstrobes.sv:232 A 74LS175 clocked by PVCLK therefore captures the value /HSYNCDO held during that n = 5 count, i.e. `hsyncdo_n` before this cycle's update. rtl/video/badlands_lb.sv:3 Bad Lands — the motion-object LINE BUFFER, Fujitsu MB87316 at 15N. rtl/video/badlands_lb.sv:4 Schematic sheet 4 grid 15N. rtl/video/badlands_lb.sv:11 WE1/WE0 = /MOW1 //MOW0 DIE1/DIE0 = /MOD1 //MOD0 MOR1/MOL1 = /MOR1 //MOL1 MOR0/MOL0 = /MOR0 //MOL0 DI7:DI4 = 17K /Q = NOT {RAMD3,RAMD2,RAMD1,RAMD0} = /priority, /palette DI3:DI0 = /MO3:0 (7T/7R high nibble) DOE = /MO (the tri-state rtl/video/badlands_lb.sv:55 in which GAL 9N evaluates the priority (during the 7M = 0 half of count k) and 10K latches the winner's index (at the next 7M falling edge). rtl/video/badlands_lb_ctrl.sv:3 Bad Lands — GAL 16S (136074-1003) at 16S, plus the two 16P F00 gates that turn its o14/o15 into /MOW0 and /MOW1. rtl/video/badlands_lb_ctrl.sv:4 Schematic sheet 4 grid 16S / 16P. rtl/video/badlands_lb_ctrl.sv:64 ---- GAL 16S / 16P outputs ------------------------------------------- rtl/video/badlands_mo.sv:3 Bad Lands — the MOTION-OBJECT engine: VMATCH 17U, the 13V/15V chip selects and the three stamp ROMs, 17K's palette/priority latch, 18S/2's VMD flop, 24J's pen-zero test, GAL 16S + 16P, and the MB87316 line buffer at 15N. rtl/video/badlands_mo.sv:6 Schematic sheet 4. rtl/video/badlands_mo.sv:39 8H, 8HD6H and H mod 16 do not divide 456, so the group beginning at H = 448 is only 8 counts long, and: * /8H produces no rising edge between H = 448 and H = 16, so 17K (palette + priority) and 18S/2 (VMD) hold entry 27's values across the rtl/video/badlands_mo.sv:72 1V -> RSEL and GAL 16S pin 9 rtl/video/badlands_mo.sv:178 GAL 16S + 16P F00 rtl/video/badlands_mo.sv:198 The MB87316 line buffer at 15N rtl/video/badlands_mo_fetch.sv:5 Schematic sheet 4 grids 13V, 15V, 14R/10R/14T. rtl/video/badlands_pf.sv:5 Schematic sheet 3. rtl/video/badlands_pf.sv:29 The pipeline, inside a group of eight counts c: the PF word is complete on RAMD15:0 at 8c+3, where 9V/7V latch it (4H rising) and PFA17/16 and A15:A5 settle; ROM byte 0 ({/4H,2H} = 00) is read over 8c+4 and 8c+5; at 8c+5 11V latches the pal rtl/video/badlands_pf.sv:45 18S 74F74 half 1 has /PRE and /CLR both tied to +5 V, so the bank bit's power-on value is indeterminate; `BANK_POR` parameterises it and 0 matches MAME. rtl/video/badlands_pf.sv:59 Only the low three H and V bits reach sheet 3: the stamp arrives through the VRAM word, the row is {4V,2V,1V} and the byte index is {/4H,2H}. rtl/video/badlands_pf.sv:87 18S 74F74 half 1 — the playfield bank bit rtl/video/badlands_pf.sv:110 Only the ROM-address and chip-select fields are needed here; the palette (D15:13) is taken from the 9V latch by 11V two counts later. rtl/video/badlands_prio.sv:3 Bad Lands — GAL 9N (136074-1004) at 9N and the 18R F74 half 2 that registers its decision. rtl/video/badlands_prio.sv:4 Schematic sheet 4 grids 9N, 18R. rtl/video/badlands_prio.sv:109 ---- 18R 74F74 half 2: D = pin 19, CK = 14M rising, no reset --------- rtl/video/badlands_sos2_sync.sv:3 Bad Lands — the SOS-2 sync generator (Atari 137550-001 at 25M, schematic 047194-01 sheet 1 grid 25M). rtl/video/badlands_sos2_sync.sv:12 The SOS-2's own HBLANK (pin 21) and /HSYNC (pin 23) outputs are unconnected on this board: horizontal blanking and sync are regenerated in GAL 26R (136074-2000) and the sync is delayed through 13V, so they live in badlands_hstrobes.sv, and rtl/video/badlands_sos2_sync.sv:19 ---- horizontal --------------------------------------------------------- H_TOTAL = 456 counts of 7M follows from GAL 26R alone: its /FIRSTH product-term set {453,454,455,0,1,2,3,4} is contiguous only if 455 wraps to 0. rtl/video/badlands_sos2_sync.sv:49 Two independent facts fix this: GAL 26R is clocked by 7M rising and its registered /FIRSTH, /BLANK and /8HD6H sets are the solved sums shifted late by exactly one 7M period, which only holds if the SOS-2's H counter also advances on 7M risi rtl/video/badlands_sos2_sync.sv:58 Everything downstream — GAL 26R's registers, GAL 21R, 18R's two decisions per pixel, 7N/10K on /7M, 3K on 7M, PIXCLK = NOR(14E./Q, 7M) — is written against this convention. rtl/video/badlands_sos2_sync.sv:269 /VRES — the frame reset the SOS-2 shares with the VMATCH custom at 17U, low over the last line of the frame. rtl/video/badlands_video.sv:19 count k 7T/7R present /PF3:0 and /MO3:0 for count k; the LB presents DO for count k from ph 4 ph 4..7 of k GAL 9N evaluates the rule (7M = 0) on those pens ph 0..3 of k+1 18R publishes the winner; 7N (latched at ph 4 of k) or the L rtl/video/badlands_video.sv:42 It clears 1K/5K, which is the only blanking mechanism — sheet 6 has no /BLANK input of its own. rtl/video/badlands_video.sv:164 GAL 26R (26R) + the 13J inverter + the 13V /HSYNC delay rtl/video/badlands_video.sv:185 The playfield (sheet 3) rtl/video/badlands_video.sv:207 The motion objects (sheet 4) rtl/video/badlands_video.sv:242 The shared /CRAMA7:1 bus and GAL 9N (sheet 4) rtl/video/badlands_vmatch.sv:4 Schematic sheet 4 grid 17U. README.md:155 \| GALs \| All six GAL16V8s — address decode, video-RAM timing, line-buffer control, priority, sound decode, horizontal strobes — implemented verbatim from th README.md:182 The six GALs were decoded with MAME's `jedutil` and their equations are implemented verbatim. README.md:337 Thanks to the MAME team, whose `badlands.cpp`, `badlands_v.cpp` and `atarimo.cpp` served as the functional oracle throughout — and whose PCB notes record the re Cites hardware references or measurements that MAME's driver also gives — 35 rtl/badlands_core.sv:216 GAL 9N pin 12: the D8 = AUDFULL read at 0xFC0000 lives in the VIDEO block on the real board — also in MAME: 9N atari/badlands.cpp:505 rtl/main/badlands_addr_decode.sv:7 Structure ported from `Arcade-Blasteroids_MiSTer/rtl/main/blstroid_addr_decode.sv` (GPL-3.0, same author); the equations are out of the 136074-1001 fuse map. — also in MAME: 136074-1001 atari/badlands.cpp:152 rtl/main/badlands_addr_decode.sv:31 /RAM has no /AS qualifier, so it can be asserted while the bus is idle; GAL 21R takes /AS separately on its pin 3, so do not AND the two here. — also in MAME: 21R atari/badlands.cpp:503 rtl/main/badlands_addr_decode.sv:75 ---- GAL 26C outputs, active low exactly as the pins are named ------- — also in MAME: 26C atari/badlands.cpp:502 rtl/main/badlands_addr_decode.sv:109 ---------------- GAL 26C (136074-1001) ------------------------------- Written as the active-low pin: pin = ~(sum of products). — also in MAME: 26C atari/badlands.cpp:502, 136074-1001 atari/badlands.cpp:152 rtl/main/badlands_main.sv:289 /RAM arrives with no /AS term, exactly as GAL 26C emits it — also in MAME: 26C atari/badlands.cpp:502 rtl/main/badlands_main.sv:490 Nothing in GAL 26C or the LS138 looks at the lanes, which is why the qualification has to be here: the program loads the palette as pairs of byte writes, an even byte carrying the colour and an odd byte carrying a constant the board throws — also in MAME: 26C atari/badlands.cpp:502 rtl/main/badlands_main.sv:536 D8 comes from GAL 9N pin 12, which is in the video block; its own enable term is /MISC2 & R/W, i.e. exactly this branch's condition. — also in MAME: 9N atari/badlands.cpp:505 rtl/mem/badlands_prog_rom.sv:12 20F 136074-1008 /OE = A17 D15:8 0x000000-0x01FFFF even bytes — also in MAME: 20F atari/badlands.cpp:114, 136074-1008 atari/badlands.cpp:137 rtl/mem/badlands_prog_rom.sv:13 27F 136074-1006 /OE = A17 D7:0 0x000000-0x01FFFF odd bytes — also in MAME: 27F atari/badlands.cpp:116, 136074-1006 atari/badlands.cpp:139 rtl/mem/badlands_prog_rom.sv:14 17F 136074-1009 /OE = /A17 D15:8 0x020000-0x03FFFF even 24F 136074-1007 /OE = /A17 D7:0 0x020000-0x03FFFF odd /CE = A23 on all four; ROM address = {A16,A15,A14S,A13S,A12..A1}. — also in MAME: 17F atari/badlands.cpp:113, 136074-1009 atari/badlands.cpp:136, 24F atari/badlands.cpp:115, 136074-1007 atari/badlands.cpp:138 rtl/mem/badlands_sdram_loader.sv:12 Bad Lands' MO stamps come from three ordinary 27512s at 14R / 10R / 14T selected by {MOA17,MOA16}, so the socket index is just the top two bits of a flat byte address and one stamp row is eight consecutive bytes. — also in MAME: 14R atari/badlands.cpp:109, 10R atari/badlands.cpp:108, 14T atari/badlands.cpp:109 rtl/mem/badlands_vram.sv:32 ---- GAL 21R (136074-1002), verbatim ------------------------------------- GAL16V8 registered. — also in MAME: 21R atari/badlands.cpp:503, 136074-1002 atari/badlands.cpp:156 rtl/mem/badlands_vram.sv:177 ------------------------------------------------ GAL 21R, registered — also in MAME: 21R atari/badlands.cpp:503 rtl/mem/badlands_vram.sv:216 ------------------------------------------ GAL 21R, combinatorial pins — also in MAME: 21R atari/badlands.cpp:503 rtl/video/badlands_cram.sv:71 GAL 9N pin 17 — also in MAME: 9N atari/badlands.cpp:505 rtl/video/badlands_hstrobes.sv:75 ---- GAL 26R inputs (pins 2-9, 12, 19) ------------------------------- — also in MAME: 26R atari/badlands.cpp:507 rtl/video/badlands_hstrobes.sv:102 GAL 26R — the equations verbatim in net names. — also in MAME: 26R atari/badlands.cpp:507 rtl/video/badlands_lb_ctrl.sv:55 ---- GAL 16S inputs --------------------------------------------------- — also in MAME: 16S atari/badlands.cpp:504 rtl/video/badlands_mo.sv:73 GAL 26R pin 17 — also in MAME: 26R atari/badlands.cpp:507 rtl/video/badlands_mo.sv:74 GAL 26R pin 18 (wired to 16S, unused) — also in MAME: 26R atari/badlands.cpp:507, 16S atari/badlands.cpp:504 rtl/video/badlands_mo.sv:78 ---- GAL 26R strobes used as clocks ---------------------------------- — also in MAME: 26R atari/badlands.cpp:507 rtl/video/badlands_mo.sv:96 DO7:0 -> /CRAMA7:1 and GAL 9N — also in MAME: 9N atari/badlands.cpp:505 rtl/video/badlands_pf.sv:41 A playfield pen of 0 is a normal opaque colour on this board — GAL 9N tests /PF3 only, so the playfield has no transparency. — also in MAME: 9N atari/badlands.cpp:505 rtl/video/badlands_prio.sv:64 ---- GAL 9N inputs ---------------------------------------------------- — also in MAME: 9N atari/badlands.cpp:505 rtl/video/badlands_sos2_sync.sv:39 * VBLANK (pin 22) is an active-high output, taken raw to /SWITCHES D6, the watchdog clock, GAL 26R pin 12 and the sound IRQ. — also in MAME: 26R atari/badlands.cpp:507 rtl/video/badlands_sos2_sync.sv:145 GAL 26R pin 12, watchdog CLK) — also in MAME: 26R atari/badlands.cpp:507 rtl/video/badlands_video.sv:3 Bad Lands — the whole raster-time video block: sheets 1 (SOS-2, GAL 26R), 3 (playfield), 4 (motion objects, priority, colour RAM) and 6 (the DACs and composite sync). — also in MAME: 26R atari/badlands.cpp:507 rtl/video/badlands_video.sv:13 DO7 does not reach the bus: it is the stored priority bit and goes only to GAL 9N pin 11. — also in MAME: 9N atari/badlands.cpp:505 rtl/video/badlands_video.sv:41 The board has one blanking net, /BLANK (GAL 26R pin 13), and it already contains VBLANK. — also in MAME: 26R atari/badlands.cpp:507 rtl/video/badlands_video.sv:43 MiSTer's `arcade_video` wants separate hblank and vblank, so this module exports GAL 26R's own sum with the VBLANK term removed as `hblank`, and the SOS-2's VBLANK as `vblank`. — also in MAME: 26R atari/badlands.cpp:507 rtl/video/badlands_video.sv:90 ---- GAL 9N pin 12: AUDFULL on D8 at 0xFC0000 ------------------------ — also in MAME: 9N atari/badlands.cpp:505 rtl/video/badlands_video.sv:299 The DACs settle at PIXCLK (ph 4) and the blanking / sync nets are per-count values out of GAL 26R, so one common ce_7m register keeps them aligned to the count and hands `arcade_video` a clean one-pixel-per-ce_pix stream. — also in MAME: 26R atari/badlands.cpp:507 README.md:149 \| Priority \| GAL16V8 9N (`136074-1004`), from the dumped fuse map \| — also in MAME: 9N atari/badlands.cpp:505, 136074-1004 atari/badlands.cpp:154 README.md:270 Two of the six GAL dumps have no second read. `136074-1004` (priority, 9N) and `136074-2000` (horizontal strobes, 26R) have a single dump each; the other four — also in MAME: 136074-1004 atari/badlands.cpp:154, 9N atari/badlands.cpp:505, 136074-2000 atari/badlands.cpp:157, 26R atari/badlands.cpp:507 Notes where it differs from MAME — 4 README.md:11 Where a schematic and MAME disagree, the schematic wins and the disagreement is recorded — see [Where this core differs from MAME](#where-this-core-differs-from README.md:219 Where this core differs from MAME README.md:222 It is where the A047193-01 schematics document something MAME's model does not. README.md:250 The pedal model and the self-test bit** are cases where MAME's model is not a model of this circuit. Cites MAME source — 40 Arcade-Badlands.sv:13 Bad Lands runs on a horizontal monitor (MAME ROT0), so there is no rotation. rtl/main/badlands_eeprom_2816.sv:58 ---- programming time --------------------------------------------------- The 2816A data sheet gives a self-timed byte write of typically 5 ms and at most 10 ms, with the I/O pins high-Z throughout; MAME models no write time at all. rtl/main/badlands_inputs.sv:85 PEDAL_IDLE_SILENT stops the idle oscillator so the LETA reads a flat 0x00, as MAME's does, for simulation only. rtl/main/badlands_inputs.sv:95 Why a generator and not "add the delta into the counter", which is what MAME does: making real edges keeps the 3.58 MHz sample rate, the decode factor and the direction logic in the path, so a player who spins faster than /1H can sample los rtl/main/badlands_inputs.sv:327 Simulation only: 1 stops the idle oscillator so the LETA reads the flat 0x00 MAME's does. rtl/main/badlands_main.sv:38 `UNDRIVEN_DATA = 0xFFFF` is the default because that is what MAME returns; `UNDRIVEN_LAST_VALUE = 1` models the board instead. rtl/main/badlands_watchdog.sv:61 MAME uses a generic WATCHDOG_TIMER with library-default seconds-scale timing, about 20x too long; this module is the schematic's. rtl/mem/badlands_rom_loader.sv:13 stream base size MAME region destination rtl/video/badlands_cram.sv:43 Touching colour RAM during active display therefore shows on screen; MAME has no equivalent artefact. rtl/video/badlands_dac.sv:11 MAME uses `palette_device::IRGB_1555`, in which colour-word bit 15 adds an LSB to all three guns — the board wires that bit to the green ladder alone, so do not implement IRGB_1555. rtl/video/badlands_dac.sv:14 Expect a small systematic colour difference from MAME on any entry with bit 15 set. rtl/video/badlands_gfx_client.sv:46 MAME's `ROMREGION_INVERT` is MAME's, not the board's: the pen buses `/PF3:0` and `/MO3:0` are active low, which is the polarity the 27512 already holds. rtl/video/badlands_lb.sv:19 512 locations per bank (A8:A0 = 9 bits) = MAME's `xposmask = 0xff80`. rtl/video/badlands_lb.sv:60 With this phase the MOH X field maps straight to the screen column with no offset, exactly as MAME's atarimo does. rtl/video/badlands_mo.sv:29 Objects per line — a hard limit with no MAME counterpart: entries 0..26 fetched at H = 0..431, drawn at H = 16..447, fully drawn rtl/video/badlands_mo_fetch.sv:56 0 = the schematic (code[11:10] bypasses the row adder through 13V/15V), 1 = MAME (the whole 12-bit code is incremented). rtl/video/badlands_pf.sv:17 D12 bank D11 \| device \| tiles offset MAME code rtl/video/badlands_pf.sv:25 MAME's `code = (data & 0x1fff) + (BIT(data,12) ? rtl/video/badlands_prio.sv:51 The rule this produces: the motion object wins when mo_pen != 0 AND ( priority OR NOT pf_pen[3] ), which is what MAME's `screen_update_badlands` does. rtl/video/badlands_video.sv:32 8c+7 — the visible window is columns 0..41 exactly, with no scroll and no offset, which is what MAME's un-scrolled 64 x 32 TILEMAP_SCAN_ROWS produces; * the LB read pointer is reset at H = 5 and location L is read during count L+6, so LB lo rtl/video/badlands_video.sv:54 0 = schematic, 1 = MAME's row carry rtl/video/badlands_vmatch.sv:21 The internals are inferred: this is the only algorithm consistent with the pin widths, the MO RAM layout, the ROM geometry and MAME. rtl/video/badlands_vmatch.sv:40 This reproduces MAME's atarimo arithmetic exactly: MAME draws the sprite from `ypos = (-Y - 8height) mod 512` downwards, and solving `sy = ypos + 8t + line` for the scanline gives the same D. rtl/video/badlands_vmatch.sv:47 MAME increments the full 12-bit code instead; `code_hi_carry` exports MAME's version of the top two bits so `badlands_mo`'s `MO_CODE_CARRY` parameter can select either behaviour. rtl/video/badlands_vmatch.sv:73 (code + row)[11:10] — the MAME leg rtl/video/badlands_vmatch.sv:130 ...and this is what MAME would produce instead. README.md:39 \| ROMs \| Supplied by you from a MAME archive; none are included here \| README.md:182 The six GALs were decoded with MAME's `jedutil` and their equations are implemented verbatim. README.md:185 Main CPU boot — the 68000 bus is co-simulated against MAME: 912,548 consecutive bus cycles agree (address, R/W, data, size) through reset, the ROM check README.md:191 Video — MAME is instrumented to capture complete video state (playfield, motion-object and colour RAM) at chosen frames; those states are replayed through t README.md:194 21 frames — 8 attract, 12 gameplay, 1 power-on — are pixel-exact over the 1,122,902 compared pixels. The pixels left out are the scanlines where the CPU wri README.md:199 Sound — the sound section is compared to MAME over 12 seconds / 719 frames: 586 mailbox commands and 584 responses order-exact, the YM2151 register writ README.md:201 The one divergence is the inverted self-test bit described below; flipping that single bit reproduces MAME's streams exactly, which shows it is the only diffe README.md:221 MAME is this project's functional oracle and every gate above measures the core against it, so this is a narrow list, not a general claim. README.md:226 \| Behaviour \| MAME \| This core \| README.md:228 \| Motion-object entries \| 64 entries at a 2-byte stride \| The video-side address bit `A1` is forced low, so entries are 4 bytes apart and there are 32. README.md:233 \| Sound self-test bit polarity \| D7 = 1 when self-test is off \| The inverting LS240 and the game ROM both give D7 = 1 when the switch is on. MAME's pola README.md:240 The 27-object limit and the 32-entry list are the two places where a crowded screen could in principle look different from MAME. README.md:247 On a colour word with bit 15 set, MAME brightens all three guns and the board brightens only green. README.md:337 Thanks to the MAME team, whose `badlands.cpp`, `badlands_v.cpp` and `atarimo.cpp` served as the functional oracle throughout — and whose PCB notes record the re Says it matches, follows or was checked against MAME — 4 rtl/video/badlands_lb.sv:35 The idle value is 8'hFF: DI3:0 are the active-low pens /MO3:0, so all-ones decodes to pen 0 = transparent, matching MAME's transparent pen 0. rtl/video/badlands_pf.sv:45 18S 74F74 half 1 has /PRE and /CLR both tied to +5 V, so the bank bit's power-on value is indeterminate; `BANK_POR` parameterises it and 0 matches MAME. rtl/video/badlands_vmatch.sv:14 OE = GND (always enabled) VFLIPEN = GND HFLD = no connect -> Bad Lands motion objects cannot flip, matching MAME's hflipmask = 0 / vflipmask = 0. README.md:266 Its alignment is proved pixel-exact against MAME over 21 frames; its idle output value, read latency and strobe widths as silicon facts are not. Says it was translated, ported or taken from MAME — 1 rtl/video/badlands_mo_fetch.sv:75 MAME's carried code[11:10] Shares text with the MAME driver without saying so — 1 rtl/video/badlands_pf.sv:25 MAME's `code = (data & 0x1fff) + (BIT(data,12) ? (bank << 12) : 0)` is the — shares text with atari/badlands_v.cpp:24
Bagman# Bagman, Botanic, Pickin', Super Bagman … MiSTer-devel/Arcade-Bagman_MiSTer @ ee2393eb MAME compared: valadon/bagman.cpp + 3 related file(s) Read: 9 HDL files, 2,527 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	44%
Statements: 5 toward MAME Cites MAME source — 4 rtl/bagman_pal16r6.vhd:6 MAME show a complete pal16r6 simulation from fusemap. rtl/bagman_pal16r6.vhd:45 Clock scheme within MAME seems to be missing. rtl/plc10_speech_synthetizer.vhd:4 Main part of the TMS5110 simulation - algorithm is from MAME source Job here includes parsing the bit stream from PROM data and computes speech samples rtl/ym_2149_linmix.vhd:44 Clues from MAME sound driver and Kazuhiro TSUJIKAWA Says it was translated, ported or taken from MAME — 1 rtl/bagman_pal16r6.vhd:4 Pal contents comes from MAME src/machine/bagman.c fusemap.
BankPanic# Bank Panic, Combat Hawk MiSTer-devel/Arcade-BankPanic_MiSTer @ 6f30da47 MAME compared: sanritsu/bankp.cpp Read: 15 HDL files, 7,485 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	23%
Statements: 2 toward hardware Cites hardware documentation that MAME's driver does not — 2 rtl/core.v:529 shift & select high or low bits of ROM data translated to verilog to avoid a lot of 74LS194 instances rtl/sn76489_audio.vhd:52 * The SN76489 datasheet * Insight gained from the AY-3-8910/YM-2149 die-shot and reverse-engineered schematics (similar audio chips from the same era).
Batman# Batman MiSTer-devel/Arcade-Batman_MiSTer @ 34783858 MAME compared: atari/batman.cpp + 8 related file(s) Read: 37 HDL files, 7,334 lines (Quartus project)	MiSTer official	Both	high	79%
Statements: 78 toward hardware, 69 toward MAME, 8 not counted Cites hardware documentation that MAME's driver does not — 72 Arcade-Batman.sv:127 (index 2) 0x000800 eeprom 28C16 at 12R, NVRAM save/restore BRAM rtl/batman_core.sv:34 The 6502's /RESET from the game board's LS273 1S latch (sndres_n) is a separate net. rtl/batman_core.sv:43 R80 * C115 = 10 ms of power-on reset (from the schematic). rtl/batman_core.sv:205 Driven by batman_main, used by batman_sound: /SNDRES from the LS273 1S, the two /SCOM strobes with the 68000's odd byte, and /AUDIRQ, /AUDFULL and the mailbox byte coming back. rtl/batman_core.sv:214 the LS273 1S output latch bits that leave the main board rtl/batman_core.sv:300 the rest of the LS273 1S rtl/main/batman_cpu.sv:4 Batman main CPU: fx68k (cycle-exact 68000) wired as the MC68000 at 6L/M. rtl/main/batman_decode.sv:3 Batman main-board address decode: GAL 136085-1002 at 9L, the 74F138 device decoder at 5/6K and the 74LS138 I/O-strobe decoder at 1P/R (from the schematic, pages 42 and 44). rtl/main/batman_decode.sv:26 ---- GAL 9L outputs (not qualified by /AS) ---- rtl/main/batman_decode.sv:38 Y1 28C16 at 12R +0x20000 rtl/main/batman_decode.sv:46 ---- LS138 1P/R, the I/O strobes (MA6:MA4 inside /CIO) ---- rtl/main/batman_decode.sv:52 Y5 +0x50 LS273 1S clock rtl/main/batman_decode.sv:58 9L: GAL16V8A 136085-1002, in its own pin numbers rtl/main/batman_decode.sv:83 5/6K: 74F138, the device block rtl/main/batman_decode.sv:105 1P/R: 74LS138, the I/O strobes rtl/main/batman_dtack.sv:3 Batman /DTACK: the 74F163 wait counter at 8K and the LS04 at 12M that inverts its RCO into the 68000's /DTACK (from the schematic, page 44). rtl/main/batman_dtack.sv:45 ---------------- 74F163 8K ------------------------------------------- rtl/main/batman_eeprom_28c16.sv:4 Batman 28C16 (2K x 8) EEPROM at 12R and the 74LS74 unlock flop at 11N/P that drives its /OE (from the schematic, page 44). rtl/main/batman_eeprom_28c16.sv:148 ---- LS74 11N/P half A ----------------------------------------------- /CLR = /SYSRES; /PRE (unlock) is a level and wins over its own /WL edge. rtl/main/batman_gal_9l.sv:3 Batman GAL16V8A 136085-1002 at 9L (label B_MAIN): the 68000 address decoder. rtl/main/batman_gal_9l.sv:4 Equations from the GAL fuse map; pin names from the schematic, page 44. rtl/main/batman_gal_9l.sv:16 It uses both BAS and /AS, which stretches the enable slightly past /AS rising and gives the LS273 at 1S its clock edge inside the data-hold window. rtl/main/batman_inputs.sv:3 Batman controls, status word and output latch: the 74LS257 muxes at 1P, 2P and 2S, the empty 1R/S expansion socket and the 74LS273 output latch at 1S (from the schematic, page 42). rtl/main/batman_inputs.sv:17 LS273 at 1S: clocked on the rising (releasing) edge of /LATCH, cleared by /SYSRES. rtl/main/batman_inputs.sv:54 ---- the LS273 1S ---- rtl/main/batman_inputs.sv:93 1S: the 74LS273 output latch rtl/main/batman_irq.sv:3 Batman interrupts: the LS08 IPL encoder at 10K and the LS20 /VPA gate at 7D (from the schematic, page 44). rtl/main/batman_main.sv:3 Batman game PCB A048987-01, 68000 side: the CPU at 6L/M, the address decode, the wait counter, 64 KB work RAM, the 28C16 EEPROM, the watchdog, the input muxes, the LS273 output latch and the interrupt encoder, plus the MiSTer ROM loader and rtl/main/batman_main.sv:61 -> GAL 9L pin 9 rtl/main/batman_main.sv:69 pin 1, latch 3Q, a level rtl/main/batman_main.sv:79 ================= the rest of the LS273 1S ========================== rtl/main/batman_main.sv:161 the whole LS273 1S rtl/main/batman_main.sv:173 the 68000 at 6L/M rtl/main/batman_main.sv:211 the decode: GAL 9L + F138 5/6K + LS138 1P/R rtl/main/batman_main.sv:311 inputs, the status word and the LS273 1S output latch rtl/main/batman_main.sv:405 the EEPROM at 12R and the 11N/P unlock flop rtl/main/batman_nvram_io.sv:4 MiSTer load/save controller for the Batman 28C16 EEPROM at 12R. rtl/main/batman_watchdog.sv:3 Batman power-on reset and watchdog: the R80/C115/Q7 POWER-ON node (schematic page 41) and the 74LS197 counter at 12N/P (page 44). rtl/main/batman_watchdog.sv:14 /SYSRES reaches the 68000, the EEPROM unlock flop and the LS273 at 1S; it does not reset the VAD. rtl/main/batman_watchdog.sv:60 ---------------- 74LS197 12N/P --------------------------------------- /VBLANK falls at the start of blanking = rising edge of active-high vblank. rtl/video/batman_alpha.sv:11 Cell word (as MAME decodes it; the video sheets are not in the manual): bits 9-0 character code bit 10 bank enable: 1 -> code + ALBK * 0x400 bits 14-11 colour (ALC3:0) bit 15 opaque (ALBG): pen 0 is drawn too ALBK2:0 is LS273 outp rtl/video/batman_alpha.sv:41 LS273 1S bits 14:12 rtl/video/batman_cram.sv:3 Batman colour RAM at 6A/6B: 2048 x 16 at 0x2E0000-0x2E0FFF, shared by the video scan and the 68000. rtl/video/batman_dac.sv:3 Batman video DAC: the three R2R 1K/2K ladders R11/R12/R13, the 74LS260 pen-zero NORs at 3A/B and 3B/C and the 7406 black clamp at 3C/D (schematic page 43). rtl/video/batman_dac.sv:14 A 74LS260 NOR over the five upper bits of each gun drives a 7406 that pulls the gun to black when they are all zero; I is not in the NOR, so {0, I=1} is black on the board. rtl/video/batman_gal_11d.sv:3 Batman GAL16V8A 136085-1005 at 11D: motion-object line-buffer phase control and the "stain" (shadow run) latch. rtl/video/batman_gal_9b.sv:3 Batman GAL20V8A 136085-1004 at 9B: colour-RAM address bits CRA1..CRA4 and the layer-select pair CS0 / CS1. rtl/video/batman_gal_9b.sv:19 The MO pixel bits arrive active low (the stamp ROM is stored inverted), unlike the MO colour bits at 9C; this is the board's wiring, not an error. rtl/video/batman_gal_9c.sv:3 Batman GAL20V8A 136085-1003 at 9C: colour-RAM address bits CRA5..CRA10. rtl/video/batman_gal_9d.sv:3 Batman GAL16V8A 136085-1006 at 9D: PF/M (playfield-over-motion-object priority), its complement, and an "MO byte == 0x01" decode. rtl/video/batman_lb.sv:3 Batman motion-object line buffers: the two 137536-001 customs at 11B and 11C. rtl/video/batman_mixer.sv:3 Batman colour-RAM address generator: GALs 136085-1006 (9D), 1004 (9B), 1003 (9C) and 1005 (11D) wired together, plus the stain run latch. rtl/video/batman_mixer.sv:82 9D (136085-1006): PF/M rtl/video/batman_mixer.sv:108 9B (136085-1004): CS0, CS1 and CRA4:1 rtl/video/batman_mixer.sv:126 9C (136085-1003): CRA10:5 rtl/video/batman_mixer.sv:146 11D (136085-1005): line-buffer phase and the stain markers rtl/video/batman_mob.sv:3 Batman motion-object engine: the MOB 137593-001 custom at 10F. rtl/video/batman_pf.sv:26 MAME stores the region inverted, and the MRA ships raw bytes, so ROM_INVERT applies the board's inversion here (the playfield pen reaches GAL 9B active high). rtl/video/batman_vad_regs.sv:3 Batman VAD 137656-002 at 6F: the 32-word register file at 0x2EFFC0, the end-of-frame (EOF) reload and the parameter-word (scroll) decoder. rtl/video/batman_vad_sync.sv:3 Batman VAD 137656-002 at 6F: the raster counters, sync, blanking and the scanline interrupt, all generated from the register file (no timing constants in the data path). rtl/video/batman_vad_sync.sv:29 The counters free-run from power-up whatever reg 00 says: the main board's LS197 at 12N/P holds the 68000 in reset until it has counted eight /VBLANK edges, so the raster must run before the CPU can program the VAD. rtl/video/batman_video.sv:3 Batman video block: the Atari VAD 137656-002 at 6F, the MOB 137593-001 at 10F, the two 137536-001 line buffers, the four priority GALs, the colour RAM and the DACs, all behind the board's single /VRAM strobe. rtl/video/batman_video.sv:21 The 0x2Exxxx and 0x3Exxxx aliases reach the same hardware (GAL 9L decides whether the 68000 waits). rtl/video/batman_video.sv:70 -> GAL 9L pin 9 rtl/video/batman_video.sv:73 ---- the LS273 1S output latch ---------------------------------------- README.md:9 The address decoding, the sound board and the video mixer come from Atari's schematics and from the dumped GAL chips. README.md:11 Where the schematics and MAME disagree, the core follows the schematics, so a few things deliberately differ from MAME. README.md:107 Address decoding from the actual chips. The 68000's memory map is the dumped GAL 136085-1002 at 9L, together with the 74-series decoders drawn on the schema README.md:112 Bus timing. Wait states come from the board's F163 counter, and interrupts use the schematic's priority encoding: level 4 for the video scanline interrupt, README.md:120 Analog audio. The board's filter and mixer stages are modelled from the component values on the schematics, which were cross-checked against Atari's parts l README.md:150 FM : ADPCM balance. The filter shapes come from the schematic, but the overall level ratio between the two sound chips depends on their output levels, which README.md:225 Reading the source. Comments name chips by their position on the Atari board, such as "GAL at 9L" or "LS273 at 1S", and the GAL modules name their ports by Cites hardware references or measurements that MAME's driver also gives — 8 Arcade-Batman.sv:120 0x000000 0x0C0000 maincpu 6 x 27C010 at 10R 7R 9/10R 6R 9R 5R SDRAM — also in MAME: 10R atari/batman.cpp:502, 7R atari/batman.cpp:503, 10R atari/batman.cpp:502, 6R atari/batman.cpp:505, 9R atari/batman.cpp:506, 5R atari/batman.cpp:507 Arcade-Batman.sv:121 0x0C0000 0x020000 chars 1 x 1 Mbit at 10M BRAM — also in MAME: 10M atari/batman.cpp:513 Arcade-Batman.sv:124 0x2E0000 0x010000 jsa:cpu 1 x 27C512 at 12C BRAM — also in MAME: 12C atari/batman.cpp:510 Arcade-Batman.sv:125 0x2F0000 0x080000 jsa:oki1 4 x 1 Mbit at 19E 17E 15E 12E SDRAM — also in MAME: 19E atari/batman.cpp:536, 17E atari/batman.cpp:537, 15E atari/batman.cpp:538, 12E atari/batman.cpp:539 rtl/mem/batman_prog_rom.sv:4 Batman 68000 program ROM: the six 27C010s at 10R/7R, 9-10R/6R and 9R/5R (schematic page 45), served from SDRAM through a direct-mapped cache with 4-word lines and next-line prefetch. — also in MAME: 10R atari/batman.cpp:502, 7R atari/batman.cpp:503, 10R atari/batman.cpp:502, 6R atari/batman.cpp:505, 9R atari/batman.cpp:506, 5R atari/batman.cpp:507 rtl/mem/batman_rom_loader.sv:45 ---- JSA 6502 program (64 KB ROM at 12C) -> block RAM ---- — also in MAME: 12C atari/batman.cpp:510 README.md:116 The whole JSA III sound board. Its two GALs (136085-1038 and -1039) come from their fuse maps. — also in MAME: 136085-1038 atari/batman.cpp:551 README.md:131 Video mixing and colour. The four priority GALs (136085-1003, -1004, -1005 and -1006) come from their fuse maps. — also in MAME: 136085-1003 atari/batman.cpp:547 Notes where it differs from MAME — 6 rtl/main/batman_dtack.sv:18 then /DTACK two CPU clocks later interrupt acknowledge P = 2 frozen: /DTACK never asserts (autovector) Wait states come from the GAL fuse map; MAME models none. rtl/main/batman_inputs.sv:16 MAME ignores A1 on the status read. rtl/video/batman_vad_dma.sv:11 The game sets bit 14 around every edit of these tables; MAME ignores reg 00, but those critical sections only make sense if bit 14 suspends the DMA. rtl/video/batman_vad_regs.sv:9 The manual lacks the VAD sheet; this follows MAME's atarivad, corrected where the game's own behaviour shows MAME is incomplete: * Reg 00: bit 15 master enable, bit 14 suspends the VAD's DMA channel (the game sets it around every edit of th README.md:11 Where the schematics and MAME disagree, the core follows the schematics, so a few things deliberately differ from MAME. README.md:132 The colour DACs follow the resistor ladder on the schematic, including the black-level clamp, which MAME does not model. Cites MAME source — 58 Arcade-Batman.sv:24 The MRA also carries MAME's batman-eeprom.bin as a seed so a first boot without a save file gets the factory settings. Arcade-Batman.sv:129 MAME inverts `tiles` and `sprites` after loading; this core applies the board's own active-low sense in the video RTL. rtl/batman_core.sv:40 1 = 14.318181 MHz (as MAME), 0 = 7.159 MHz. rtl/main/batman_cpu.sv:11 MAME runs the CPU at 14.318 MHz; sibling Atari boards use 7.16 MHz. rtl/main/batman_cpu.sv:11 This core follows MAME (CPU_14M = 1); batman_dtack must get the same value because its wait counter is clocked from the same node. rtl/main/batman_cpu.sv:25 1 = 14.318 MHz (ce_14m, as MAME), 0 = 7.159 MHz (ce_7m). rtl/main/batman_eeprom_28c16.sv:17 WRITE_CYCLES models the byte programming time (MAME treats writes as instant). rtl/main/batman_inputs.sv:36 JAMMA 17 STRT1 ("JAMMA START 1"; MAME calls it unused) rtl/main/batman_main.sv:13 The data bus has no buffers or pull-ups, so any lane nothing drives reads as UNDRIVEN_DATA (0xFFFF, as MAME). rtl/main/batman_main.sv:23 1 = 68000 at 14.318 MHz (as MAME), 0 = 7.159 MHz. rtl/main/batman_main.sv:395 Block RAM powers up at 0x00, as MAME's work RAM does. rtl/main/batman_watchdog.sv:12 MAME uses its 3-frame default instead. rtl/mem/batman_rom_loader.sv:77 In MAME's order the four bit planes of one stamp row are 0x40000 bytes apart, i.e. in four SDRAM rows. rtl/video/batman_alpha.sv:11 Cell word (as MAME decodes it; the video sheets are not in the manual): bits 9-0 character code bit 10 bank enable: 1 -> code + ALBK * 0x400 bits 14-11 colour (ALC3:0) bit 15 opaque (ALBG): pen 0 is drawn too ALBK2:0 is LS273 outp rtl/video/batman_dac.sv:12 Each gun is a 6-bit ladder whose LSB is the shared intensity bit I (colour-RAM bit 15): gun = {channel[4:0], I}, expanded to 8 bits the way MAME does. rtl/video/batman_dac.sv:16 MAME has no clamp and shows that code as 4/255; BLACK_CLAMP = 0 reproduces MAME. rtl/video/batman_dac.sv:41 MAME's pal6bit: (v << 2) \| (v >> 4), equal to round(255 * v / 63). rtl/video/batman_gal_11d.sv:14 The manual lacks the video sheets, so the pin names below are inferred from sibling boards and MAME. rtl/video/batman_gal_9d.sv:13 The manual lacks the video sheets, so pin names are inferred from ThunderJaws' GAL and MAME. rtl/video/batman_gal_9d.sv:14 PF/M reproduces MAME's rule for the selected playfield's priority PFX9:8 against MO priority MPR1:0: 3: playfield always wins 2: wins if MPR < 2 and not upper pen 1: wins if MPR == 0 and not upper pen 0: never Pins 15/16 are tak rtl/video/batman_gal_9d.sv:20 ThunderJaws ORs it into PF/M; Batman does not, and MAME has no such rule, so the mixer leaves pin 19 unconnected. rtl/video/batman_lb.sv:21 FIRST_WINS: MAME draws Batman's object list in reverse, so the first entry ends up on top. rtl/video/batman_mixer.sv:17 Stain (MAME's name for it): a motion object with priority bit MPR2 set is not drawn. rtl/video/batman_mixer.sv:34 ---- what 9D pins 15 and 16 are wired to (the sheet is missing) ------ 0 = PFX3 of the selected playfield and PFXS; reproduces MAME. rtl/video/batman_mixer.sv:51 An MPR2 object draws no visible pixel (as in MAME), but 11D still needs its pen to run the stain. rtl/video/batman_mixer.sv:171 Behaviour follows MAME's atarimo apply_stain: * a start pixel stains itself and opens the run; * every pixel inside the run is stained; * an end pixel arms `offnext`, and the run closes after the next pixel unless that pixel is itself a sta rtl/video/batman_mixer.sv:176 MAME runs it to the bitmap edge instead; that makes no visible difference. rtl/video/batman_mob.sv:9 The manual lacks the video sheets, so Batman's settings follow MAME's atarimo configuration: 10-bit links, 4-word entries at MOBASE + 4 * link, 8 x 8 stamps, a 64-word SLIP table of 8-line bands, no vertical flip. rtl/video/batman_mob.sv:25 X offset; MAME uses -1. rtl/video/batman_mob.sv:31 MAME's bitmap geometry, used by the coordinate folds. rtl/video/batman_mob.sv:98 MAME masks 0x0007 rtl/video/batman_pf.sv:3 Batman playfield layer, instantiated twice: PF1 (P1BASE 0x2F0000, the transparent foreground, MAME's `playfield2`) and PF2 (P2BASE 0x2F2000, the opaque background, MAME's `playfield`). rtl/video/batman_pf.sv:26 MAME stores the region inverted, and the MRA ships raw bytes, so ROM_INVERT applies the board's inversion here (the playfield pen reaches GAL 9B active high). rtl/video/batman_vad_dma.sv:17 It runs during vertical blanking, the only time the video RAM has DMA slots (MAME does it at line 0). rtl/video/batman_vad_dma.sv:31 1 = take the autostore byte when the write reaches the RAM; 0 = at the CPU write, as MAME does. rtl/video/batman_vad_regs.sv:28 last EOF index replayed (as MAME) rtl/video/batman_vad_regs.sv:29 skip zero words (as MAME) rtl/video/batman_vad_regs.sv:30 Regs 01-1F read back their last value, as in MAME; the game never reads them, so this is unobservable. rtl/video/batman_vad_regs.sv:84 tag A (MAME m_pf1_xscroll_raw) rtl/video/batman_vad_regs.sv:85 tag B (MAME m_pf0_xscroll_raw), rtl/video/batman_vad_regs.sv:224 The two playfields share one horizontal fetch pipeline, so PF2's scroll includes the low three bits of PF1's (confirmed against MAME's frames). rtl/video/batman_vad_sync.sv:12 Register fields (register layout as in MAME; the VAD sheet is not in the manual) and Batman's values: reg 01 V_SY_S [11:3] V_SY_E [2:0] 0795 rtl/video/batman_vad_sync.sv:43 ---- scanline interrupt ------------------------------------------------- 0 = a comparator on the V counter (fires every frame); 1 = MAME's one-shot timer, re-armed by each reg 03 write. rtl/video/batman_video.sv:459 An MPR2 object is hidden from 9B/9C/9D (as in MAME) but still seen by 11D. rtl/video/batman_vram.sv:14 (The VAD sheet is not in the manual; this schedule is inferred from MAME, the VAD registers and frame matching.) clk_sys gives eight clocks per pixel, so here each pixel is split into eight phases: ph 0-4 the layers, ph 5 MO, ph 6 CPU, ph 7 README.md:10 MAME is used as a cross-reference for what the schematics do not cover. README.md:25 MAME has one Batman set, with no clones. README.md:50 First boot. Before a save file exists, the core fills the EEPROM from the factory image in the MAME set (`batman-eeprom.bin`). README.md:117 The 6502's 4 ms interrupt timer only restarts after the 6502 acknowledges it, as on the board; MAME runs it freely. README.md:122 MAME applies no filtering, so this core sounds darker than MAME, as the real board does. README.md:123 The ADPCM and FM chips are mixed 33 : 15, as the mixer resistors set it; MAME uses 0.75 : 0.60. README.md:126 MAME uses a flat ×2. README.md:128 ADPCM ROM banking from the GAL. In one bank, the GAL on the sound board selects a different sample ROM than MAME's hard-coded mapping. README.md:147 The core uses 14.318 MHz, as MAME does. README.md:171 \| Boot \| 338,939 bus cycles of the 68000 from power-on (every write, and every access outside the program ROM), compared one by one with MAME \| Same cycles in t README.md:172 \| Video \| 44 frames (attract, gameplay, the staircase scene, all four self-test screens, synthetic states) compared pixel by pixel with MAME, with graphics fetc README.md:176 The test benches, MAME captures and development notes behind these results are not part of this repository. README.md:265 The MAME team: `batman.cpp`, `atarivad`, `atarimo` and `atarijsa` (Aaron Giles and contributors) were the cross-reference for everything the schematics do n Says it matches, follows or was checked against MAME — 11 rtl/video/batman_lb.sv:12 The manual lacks the video sheets, so this follows MAME's atarimo. rtl/video/batman_mixer.sv:30 1 = joined after the 9B/9C mux, so alpha pixels are stained too; the core uses this, and it matched MAME's frames. rtl/video/batman_mob.sv:94 Vertical match, in MAME's arithmetic so the wrap-around folds agree rtl/video/batman_pf.sv:30 XOFF defaults to 0; batman_video sets the offsets that match MAME's frames. rtl/video/batman_vad_dma.sv:9 The manual lacks the VAD sheets; this follows MAME's atarivad plus what the game program does. rtl/video/batman_vad_regs.sv:9 The manual lacks the VAD sheet; this follows MAME's atarivad, corrected where the game's own behaviour shows MAME is incomplete: * Reg 00: bit 15 master enable, bit 14 suspends the VAD's DMA channel (the game sets it around every edit of th rtl/video/batman_video.sv:12 The kit manual does not include the video schematic sheets (VAD, MOB, video RAM, line buffers), so this block follows MAME's atarivad / atarimo, the GAL fuse maps and sibling Atari cores, checked against MAME's frames. rtl/video/batman_video.sv:34 ---- tuning; the defaults match MAME's frames pixel for pixel -------- README.md:143 That part of the core follows MAME's behaviour, the fuse maps of the GALs around it and sibling Atari cores, and it was checked frame by frame against MAME and README.md:173 \| Sound \| 3 s of attract and 22 s of gameplay replayed against MAME recordings \| Every sound-chip write made in answer to a game command matches MAME in order a README.md:174 \| Whole core \| Built with Quartus 17.0.2 and run on DE10-Nano boards by the author and by other testers \| Boots and plays with no problems reported. Screenshots
BattleZone# Bradley Trainer, Battlezone, Red Baron MiSTer-devel/Arcade-BattleZone_MiSTer @ 14207b4f MAME compared: atari/bzone.cpp + 6 related file(s) Read: 32 HDL files, 5,795 lines (Quartus project)	MiSTer official	Mostly hardware	low	27%
Statements: 5 toward hardware Cites hardware documentation that MAME's driver does not — 1 rtl/POKEY.sv:495 This instance name made sense at 4AM when I typed it Ships hardware documentation files — 4 kicad_pcb/_autosave-red_baron_aux_pcb_analog_bang.sch kicad_pcb/red_baron_aux_pcb.sch kicad_pcb/red_baron_aux_pcb_analog_bang.sch kicad_pcb/red_baron_aux_pcb_shifters.sch
Berzerk# Berzerk MiSTer-devel/Arcade-Berzerk_MiSTer @ 737c3995 MAME compared: stern/berzerk.cpp Read: 9 HDL files, 2,612 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	45%
Statements: 3 toward MAME Cites MAME source — 2 rtl/berzerk.vhd:62 Mame command reminder wpiset 40,1,w,1,{printf "a:%08x d:%02X",wpaddr,wpdata; g} wpiset 40,1,w,(wpdata!=0) && (wpdata!=90) && (wpdata!=92),{printf "a:%08x d:%02X",wpaddr,wpdata; g} rtl/berzerk_speech.vhd:6 By Jonathan Gevaryahu ("Lord Nightmare") with help from Kevin Horton ("kevtris") MAME conversion and integration by R. Belmont Clock Frequency control updated by Zsolt Vasvari Other fixes by AtariAce Says it was translated, ported or taken from MAME — 1 rtl/berzerk_speech.vhd:4 s14001a speech synthesis based on Mame source code : TSI S14001A emulator v1.32
BlackWidow# Black Widow, Gravitar MiSTer-devel/Arcade-BlackWidow_MiSTer @ e560fd8b MAME compared: atari/bwidow.cpp + 2 related file(s) Read: 40 HDL files, 16,352 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	11%
Statements: 12 toward hardware, 1 toward MAME, 4 not counted Cites hardware documentation that MAME's driver does not — 12 Arcade-BlackWidow.sv:484 The numbers in parentheses will appear on the BONUS ADDER line in the Operator Information Display (Figure 2-1) for these settings. rtl/avg/avg_prom_core.vhd:105 On hardware, this is latched by the LS175 (6L, schematic p.25 Fig.1) from DVY10-DVY8, and drives the LS191 down-counter that gates additional fill-bit shifts into the timer at STROBE 1. rtl/avg/avg_prom_core.vhd:114 GO flag (schematic p.24 Fig.3: 2E LS32 pin 8). rtl/avg/avg_prom_core.vhd:136 Bin_scale shift mechanism at STROBE 1 (schematic p.25 Fig.1: Vector Scaling). rtl/avg/avg_prom_core.vhd:251 /LATCH1 clears three chip groups (schematic p.23): 5F,5H (Fig.2): DVY0-7 async cleared to 0 5A,5B,5C (Fig.2): DVX0-11 async cleared to 0 3C (Fig.0): Z0-Z2 + DVX12 async cleared to 0 6H(DVY8-11) has /CLR=PR110 (not cleared here). rtl/avg/avg_prom_core.vhd:288 STROBE0 + OP0=0 sets NORM (LS74 5K, p.24 Fig.0). rtl/avg/avg_prom_core.vhd:299 STROBE 1 (action $D): SP adjust for JSR/RTS, or Vector Scaling (schematic p.25 Fig.1) for VCTR/SVEC. rtl/avg/avg_prom_core.vhd:326 Scale (0111_SSS LLLLLLLL) SSS = bin_scale -> LS175 latch (6L) -> LS191 counter (6M) LLLLLLLL = linear_scale -> LF13201 DAC (schematic p.26) rtl/avg/avg_prom_core.vhd:393 Schematic p.23 Fig.2: LS194 shift registers (3A-3D, 4A-4D) shift DVX/DVY left at 12 MHz, gated by ENORM. rtl/avg/avg_prom_core.vhd:395 Schematic p.25 Fig.0: LS161 timer chain (1D/1C/1B/2B) shifts right simultaneously, filling from the top. rtl/avg/avg_prom_core.vhd:436 Schematic p.25 Fig.1: Vector Scaling circuit. rtl/avg/vector_drawer.vhd:59 Linear scale velocity multiplier (schematic p.26: LF13201 multiplying DAC). Cites hardware references or measurements that MAME's driver also gives — 4 rtl/avg/avg_prom_core.vhd:63 Hardware: 136002-125.n4 bipolar PROM — also in MAME: 136002-125 atari/bwidow.cpp:865 rtl/avg/avg_prom_core.vhd:110 PROM state machine signals (256x4 PROM 136002-125.n4) — also in MAME: 136002-125 atari/bwidow.cpp:865 rtl/pgmrom.vhd:57 136017-101.d1 4096 0 0000 000000000000 136017-102.ef1 4096 4096 0001 000000000000 136017-103.h1 4096 8192 0010 000000000000 136017-104.j1 4096 12288 0011 000000000000 136017-105.kl1 4096 16384 0100 000000000000 136017-106.m1 4096 2048 — also in MAME: 136017-101 atari/bwidow.cpp:855, 136017-102 atari/bwidow.cpp:856, 136017-103 atari/bwidow.cpp:857, 136017-104 atari/bwidow.cpp:858, 136017-105 atari/bwidow.cpp:859, 136017-106 atari/bwidow.cpp:860 rtl/vecrom.vhd:50 136017-107.l7 2048 24576 0110 000000000000 blank 2048 26624 0110 100000000000 136017-108.mn7 4096 28672 0111 000000000000 136017-109.np7 4096 32768 1000 000000000000 136017-110.r7 4096 36864 1001 000000000000 — also in MAME: 136017-107 atari/bwidow.cpp:850, 136017-108 atari/bwidow.cpp:851, 136017-109 atari/bwidow.cpp:852, 136017-110 atari/bwidow.cpp:853 Shares text with the MAME driver without saying so — 1 Arcade-BlackWidow.sv:449 ------------------------------------------------------------------------------- Settings of 8-Toggle Switch on Black Widow CPU PCB (at D4) 8 7 6 5 4 — shares text with atari/bwidow.cpp:30
Blasteroids# Blasteroids MiSTer-devel/Arcade-Blasteroids_MiSTer @ f8ceffb0 MAME compared: atari/blstroid.cpp + 8 related file(s) Read: 32 HDL files, 7,475 lines (Quartus project)	MiSTer official	Both	high	82%
Statements: 165 toward hardware, 64 toward MAME, 1 not counted Cites hardware documentation that MAME's driver does not — 160 Arcade-Blasteroids.sv:46 The Whirly-Gig counter is the Atari LETA custom at 8A, inside blstroid_main. Arcade-Blasteroids.sv:153 Button 4 is sheet 12's D3 "spare", which is unwired in a cabinet but IS displayed by the self test, so it is mapped rather than tied off - that is what lets a user confirm the whole input path from the Switch Test. Arcade-Blasteroids.sv:281 The counter itself is the Atari LETA custom at 8A, inside blstroid_main where sheet 4 puts it; this module only synthesises the CLK/DIR pin pair that reaches it. Arcade-Blasteroids.sv:426 DW = 24: the colour RAM is xRGB 5:5:5 (SP-316 sheet 12) and the core expands it through the R/2R DAC transfer, so it hands over 8 bits per channel. rtl/blstroid_core.sv:12 blstroid_rom_loader / _prog_rom / _ram8 / _sdram_loader / _gfx_mem / _sdram the ioctl download, the 256 KB program ROM and the 64 KB sound ROM in BRAM, and the graphics SDRAM blstroid_main SP-316 sheets 2-5 and 12: fx68k, the addre rtl/blstroid_core.sv:45 `blstroid_vram` still drives `vram_a` and still latches VD15 into the 4K LS174B on 4H, so `PFM2` — the row-interrupt condition — still comes from the sheet-6 latch regardless of who owns the array. rtl/blstroid_core.sv:104 The SOS-2 counts V internally and the schematics do not settle 262 against the 263 the same Atari sync-generator family produces, so this is a build-time parameter; rebuild with 263 to try it. rtl/blstroid_core.sv:143 `blstroid_whirly` in Arcade-Blasteroids.sv synthesises them from the MiSTer spinner / paddle / mouse / d-pad; the COUNTER is the LETA custom at 8A, inside blstroid_main where sheet 4 puts it. rtl/blstroid_core.sv:153 D3 is sheet 12's "spare" and it is not a Start button. rtl/blstroid_core.sv:167 ---- video out (single clk_sys domain, qualified by ce_pix) ---- 8 bits per channel: colour RAM is xRGB 5:5:5 (sheet 12) and the DAC transfer widens it to 8, so the core's output bus is 8-bit and arcade_video is instantiated with DW = 24. rtl/blstroid_core.sv:376 Video board — SP-316 sheets 4 to 11 rtl/blstroid_core.sv:473 Main board — SP-316 sheets 2, 3, 4, 5 and 12 rtl/blstroid_core.sv:536 JSA I audio PCB — SP-316 sheets 14 to 17 rtl/blstroid_core.sv:561 The board's own self-clearing periodic divider (sheet 17), not MAME's free-running model of it; the sheet-16 low-pass is real hardware and stays in circuit. rtl/main/blstroid_addr_decode.sv:3 Blasteroids 68000 address decode — SP-316 sheet 3, gate for gate. rtl/main/blstroid_addr_decode.sv:6 Structure from the Xybots MiSTer core's rtl/main/xybots_addr_decode.sv (GPL-3.0, same author); every equation below is read off SP-316 sheet 3 rather than taken from MAME's main_map. rtl/main/blstroid_addr_decode.sv:61 ---- the SLAPSTIC socket ------------------------------------------------- Decoded and exported because sheet 3 draws it; it reaches nothing. rtl/main/blstroid_addr_decode.sv:62 The 2A socket is empty ("The SLAPSTIC chip is not installed", sheet 3) and the 4A LS157 that would substitute its bank bits is strapped to its B inputs by R77, so 038000-03FFFF is plain program ROM. rtl/main/blstroid_addr_decode.sv:160 A22..A18, A17 (the ROM-pair /CE, consumed inside blstroid_prog_rom) and A8..A1 (consumed by the RAMs, the priority RAM, the LETA's A2 and the button mux's A1) reach no decoder on sheet 3. rtl/main/blstroid_cpu.sv:3 Blasteroids main CPU — fx68k (cycle-exact 68000) wired as SP-316 sheet 2 draws the 2C U68000. rtl/main/blstroid_cpu.sv:19 ---- clock enables ------------------------------------------------------ fx68k is fully synchronous on `clk` (= clk_sys, 57.272724 MHz) and takes TWO enables per CPU clock, one per phase of the nominal 7.15909 MHz /7M: enPhi1 -> the CPU cl rtl/main/blstroid_cpu.sv:29 ---- pins as sheet 2 wires them ---------------------------------------- rtl/main/blstroid_cpu.sv:52 `oHALTEDn` (fx68k's double-bus-fault output) has no load on sheet 2 and is left open. rtl/main/blstroid_cpu.sv:57 BERRn is tied inactive: sheet 2 has no bus-error source at all. rtl/main/blstroid_cpu.sv:59 ---- /VPA and autovectoring -------------------------------------------- Sheet 2 makes /VPA = ~(AS & FC0 & FC1 & FC2) (1D LS20) and wires it both to the 68000's VPA pin and to the 12C LS163A's ENT, so an FC = 7 cycle deliberately gets no /D rtl/main/blstroid_cpu.sv:128 double bus fault; no load on sheet 2 rtl/main/blstroid_dpram_be.sv:13 Byte writes on either lane must be honoured independently (SP-316 sheet 12); * the colour RAM at FFA000-FFA3FE, 512 x 16 (AW = 9): 0x000-0x0FF are the motion-object palettes, 0x100-0x1FF the playfield palettes, xRGB 5:5:5. rtl/main/blstroid_dtack.sv:3 Blasteroids /DTACK generator — SP-316 sheet 2 (12C LS163A + 11C LS11 + 11D LS74 + 14/15B LS74 upper + 16A LS260). rtl/main/blstroid_dtack.sv:7 Derived from the Xybots MiSTer core's rtl/main/xybots_dtack.sv (GPL-3.0, same author), re-done gate for gate off SP-316 sheet 2. rtl/main/blstroid_dtack.sv:15 ---- 12C LS163A, the wait-state counter -------------------------------- CK (2) = /7M (the 68000 clock) CLR (1) = 11C LS11 pin 12 = /WAITHBL & /VIDRAM & AS (sync clear) LD (9) = QD (11) (self-load fee rtl/main/blstroid_dtack.sv:37 and the clock chain, all sheet 2: g12B = 12B LS32 (9,10->8) = /1H \| 2H g13D = 13D LS10 (1,2,13->12) = ~( /1H & 2H & 4H ) rtl/main/blstroid_dtack.sv:61 A write to FF8E00 asserts /WAITHBL, which also holds the LS163A cleared (11C LS11), so no acknowledge is produced until the rising edge of HBLANK — the CPU stalls inside the bus cycle for up to a whole scan line (~63.7 us). rtl/main/blstroid_dtack.sv:108 ---- 12C LS163A ------------------------------------------------------ rtl/main/blstroid_eeprom_2804.sv:3 Xicor X2804A (512 x 8) EEPROM at 2A/B, plus the 14/15B LS74 unlock latch — SP-316 sheet 3. rtl/main/blstroid_eeprom_2804.sv:18 The socket is wired for a 2816 (2 K x 8) but the fitted X2804A is 512 x 8 (A0..A8 only), so the device repeats four times over FFB001-FFBFFF — which is what sheet 12's "a = ADDRESS BITS ON 2816 ONLY" note means and what MAME's `.mirror(0x03 rtl/main/blstroid_inputs.sv:3 Blasteroids status and button ports, FF9C01 / FF9C03 — SP-316 sheet 4 (12L F244, 10A LS257). rtl/main/blstroid_inputs.sv:14 BD7 A17 -> Y3 SELFTEST active LOW (R1 1 K pull-up on sheet 3; the rtl/main/blstroid_inputs.sv:20 Sheet 12 prints "XXXX XX01" on the HBLANK row and "XXXX XXX1" on the three above it; the hardware makes all four A1-independent, so that is a drafting slip — D7:D4 read identically at both addresses. rtl/main/blstroid_inputs.sv:29 An LS257 selects its A inputs when SELECT is low, so FF9C01 (A1 = 0) is player 1 and FF9C03 (A1 = 1) is player 2, matching sheet 12. rtl/main/blstroid_inputs.sv:33 SPARE1/SPARE2 land on CTRA-9/CTRA-10, which sheet 13's cabinet harness leaves unconnected — they read 1 on a real machine. rtl/main/blstroid_irq.sv:3 Blasteroids interrupt latches and priority encoder — SP-316 sheet 2 (11C LS11, 1D LS20, 13C LS74, 13D LS10, 11B F00). rtl/main/blstroid_irq.sv:7 Structure from the Xybots MiSTer core's rtl/main/xybots_irq.sv (GPL-3.0, same author); the equations are read off SP-316 sheets 2 and 6. rtl/main/blstroid_irq.sv:19 and PFM2 is SP-316 sheet 6, 4K LS174B: D (3) = VD15, Q (2) = PFM2, CK = 4H — bit 15 of the last playfield word the video side fetched, which for the non-displayed column-40 word of a row is sheet 12's ROW PROGRAMMABLE INTERRUPT flag. rtl/main/blstroid_irq.sv:31 /IRQACK is still implemented, because sheet 3 decodes it. rtl/main/blstroid_irq.sv:75 sheet 6, 4K LS174B pin 2 (latched VD15) rtl/main/blstroid_leta.sv:3 Atari LETA at 8A — the Whirly-Gig counters, FF9801 / FF9805. rtl/main/blstroid_leta.sv:4 SP-316 sheet 4. rtl/main/blstroid_leta.sv:11 ---- wiring, off sheet 4 ------------------------------------------------ 24 VCC 12 GND rtl/main/blstroid_leta.sv:40 The decode here follows the Atari System 2 core's, which is calibrated against a game whose service mode counts encoder pulses (720's 72-tooth disc = 144 counts/rev, i.e. 2x decoding): * the pin pair is treated as quadrature, CLK = phase A, rtl/main/blstroid_main.sv:3 Blasteroids main board — SP-316 sheets 2, 3, 4, 5 and 12 as one block. rtl/main/blstroid_main.sv:6 Structure from the Xybots MiSTer core's rtl/main/xybots_main_bus.sv (GPL-3.0, same author); the board-specific parts are read off SP-316. rtl/main/blstroid_main.sv:20 * The video RAM, the colour RAM and the priority RAM live inside this module, because their CPU-side arbitration is sheet 2/5 logic. rtl/main/blstroid_main.sv:24 `pfm2` is sheet 6's 4K LS174B pin 2 — bit 15 of the last playfield word fetched, latched at 4H — and it is what arms the row interrupt; see blstroid_irq. rtl/main/blstroid_main.sv:47 ---- the /RESET net ----------------------------------------------------- The watchdog's /RESET drives the 68000's RESET+HALT pins (one net) and, leaving sheet 2 for sheet 3 only, the EEPROM unlock flip-flop's /CLR and the 14B LS08 that gat rtl/main/blstroid_main.sv:79 sheet 6, 4K LS174B pin 2 (latched VD15) rtl/main/blstroid_main.sv:160 Decode (sheet 3) rtl/main/blstroid_main.sv:182 /SLAPSTIK is decoded because sheet 3 draws it and reaches nothing (the 2A socket is empty); FF9000 is an unused LS139 output. rtl/main/blstroid_main.sv:281 Sheet 12: XX0P PPPC CCC0 = 256 motion-object entries (16 palettes x 16) at FFA000-FFA1FE, XX10 PPPC CCC0 = 128 playfield entries (8 x 16) at FFA200-FFA2FE, and FFA300-FFA3FE is addressable RAM nothing uses. rtl/main/blstroid_main.sv:283 The colour RAM is arbitrated by the 14C F74 pair on sheet 10 and does not gate /DTACK: it takes the normal one-/7M-edge acknowledgement. rtl/main/blstroid_main.sv:298 Priority RAM — 256 x 1, write only (sheet 10, 17E 27LS00A) rtl/main/blstroid_main.sv:300 Sheet 12: FF8800-FF89FE, address `H PPP MMMM` = BA8..BA1 (H = playfield pen bit 3, P = playfield palette, M = motion-object palette), data D0, 1 = motion object on top. rtl/main/blstroid_main.sv:338 Interrupts (sheet 2) rtl/main/blstroid_main.sv:439 DTACK (12C LS163A + 11D LS74 pair + 16A LS260) rtl/main/blstroid_watchdog.sv:3 Blasteroids watchdog — SP-316 sheet 2 (14D LS00, 1B LS90, Q4 2N3904). rtl/main/blstroid_watchdog.sv:53 power-on reset, active high (sheet 2, 8C LS14) rtl/main/blstroid_whirly.sv:3 Blasteroids Whirly-Gig encoder — a MiSTer spinner, paddle, mouse or d-pad turned into the CLK+DIR pin pair the LETA at 8A actually sees. rtl/main/blstroid_whirly.sv:11 ---- what this stands in for ------------------------------------------- SP-316 sheet 13: LET-5/6 = P1-CLK / P1-DIR, LET-7/8 = P2-CLK / P2-DIR, each with a 3.3 K pull-down, a 0.01 uF cap and a 1 K series resistor into the LETA (sheet 4). rtl/mem/blstroid_prog_rom.sv:12 ---- the four sockets ---------------------------------------------------- SP-316 sheet 12 labels the region "256K BYTES PROGRAM ROM": four 27512s in two even/odd pairs, rtl/mem/blstroid_prog_rom.sv:21 Sheet 12 reserves 0x038000-0x03FFFF as "32K BYTES SLAPSTIC PROGRAM ROM SPACE", but no slapstic is fitted on a Blasteroids board and MAME's driver has none either, so this is a plain ROM. rtl/mem/blstroid_rom_loader.sv:26 ---- the sprite region is TWO 512 KB halves ------------------------------ `sprites` is 1 MB: bytes 0x00000-0x7FFFF are the board's M row MO stamp ROMs (sheet 8) and 0x80000-0xFFFFF the N row (sheet 7). rtl/video/blstroid_cram.sv:3 Blasteroids — SP-316 sheet 10: the PF/MO decision register (14C F74), the two colour-address drivers (17D F374 for the motion object, 16D F374A for the playfield), the CRA8 multiplexer, the 512 x 16 colour RAM (15/16B + 15/16C) with its 680 rtl/video/blstroid_cram.sv:21 which is sheet 12's `XX0P PPPC CCC0` (MO) and `XX10 PPPC CCC0` (PF). rtl/video/blstroid_cram.sv:157 The colour word is xRGB 5:5:5 (sheet 12; MAME's xRGB_555): rtl/video/blstroid_dac.sv:3 Blasteroids video DACs — SP-316 sheet 11: three identical packaged R/2R ladders (RN3 red, RN2 green, RN1 blue) driven from the HC273 output registers, plus the LS260 + 15A U06 code-0 pedestal sink. rtl/video/blstroid_dac.sv:22 ---- the one non-linearity, and why it is not emulated ------------------- A 74LS260 5-input NOR per channel detects "all five bits zero" and drives a 15A U06 open-collector inverter that sinks the ladder node through 1 K, cancelling the pu rtl/video/blstroid_mo.sv:3 Blasteroids — the motion-object engine: SP-316 sheets 7, 8 and 9 tied together. rtl/video/blstroid_mo.sv:11 This module carries three of the four blocks that are one pipeline on the board — the fourth, the LINK WALK (13E LS74 + 7D LS273A + 7E LS374, sheet 5), lives in `blstroid_vram.sv` with the address multiplexers it drives: rtl/video/blstroid_mo.sv:15 VMATCH 8K the vertical match / size compare and the stamp ROM address (sheet 7, Atari 137552-001) the ROM read sixteen 27512s (sheets 7 + 8) as ONE burst-8-byte read through the blstroid_gfx_mem MO client SOS-1 10K rtl/video/blstroid_mo.sv:21 `blstroid_mo_linebuf` (sheet 9) is instantiated at the bottom. rtl/video/blstroid_mo.sv:51 Link 56 (the 57th) is fetched over 448..455 and drawn over 454..461, i.e. counts 454, 455 of this line and 0..5 of the next — finishing EXACTLY at the 5->6 boundary where `1VD6H` (4E LS174C, clocked by 4HD2H) flips the buffers over. rtl/video/blstroid_mo.sv:142 ---- SOS-2 3F (sheet 4), via blstroid_sos2_sync ---- rtl/video/blstroid_mo.sv:148 4E LS174C Q10 — 1V retimed on 4HD2H rtl/video/blstroid_mo.sv:369 The two line buffers (sheet 9) rtl/video/blstroid_mo.sv:371 The F163 chains on sheet 9 are clocked at 14M with a synchronous /LD, so a strobe two 14M periods wide would load the counter twice — and the second load would land on the 16th pixel of the object being drawn, writing it at the next object' rtl/video/blstroid_mo_linebuf.sv:3 Blasteroids — SP-316 sheet 9: the two motion-object line buffers (14K and 14F, 2K x 8 35 ns), their F163 address counter chains (14L/15L/13L and 14J/15J/13J), the transparency write gate and the read-and-clear cycle. rtl/video/blstroid_mo_linebuf.sv:18 \| free-runs at 14M = the \| X by /MOHLD1 = the WRITE \| DISPLAY address \| address pixel bus D3:0 \| undriven -> R65/66/69/70 \| MOPIX3:0 from SOS-1 \| pull-ups -> 0xF \| /OE \| enabled while 14M is high \| dis rtl/video/blstroid_mo_linebuf.sv:66 The /OE and pixel-bus selection uses 1VD6H, which is 1V retimed by 4E LS174C on 4HD2H — it flips at the h%8 5->6 boundary, exactly where the 57th link's sixteen pixels finish. rtl/video/blstroid_mo_linebuf.sv:87 ---- SOS-2 strobes (sheet 4 pins 26/27) and the retimed 1V ---- rtl/video/blstroid_mo_linebuf.sv:91 4E LS174C Q10 rtl/video/blstroid_pf.sv:3 Blasteroids — SP-316 sheet 6: the playfield picture latches (4K LS174B, 4L LS374C, 6F F174A), the four PF graphics ROMs (1L, 1M, 3L, 3M), the 2J/1J LS194A shifters and the 4E LS174C re-timing latch. rtl/video/blstroid_pf.sv:8 Structurally derived from the Xybots MiSTer core's rtl/video/xybots_pf.sv (GPL-3.0, same author); every number below is re-derived for Blasteroids from sheet 6. rtl/video/blstroid_pf.sv:29 Sheet 5's slot schedule gives the playfield exactly one video-RAM slot per 8 counts, at `H[2:0]` = 3, and sheet 6 latches the word on the `4H` rising edge at the 3->4 boundary. rtl/video/blstroid_pf.sv:34 4K/4L/6F latch it on the board; here the 13-bit code goes straight out as ONE `blstroid_gfx_mem` PF request for the whole 4-byte stamp row, and the previously completed row moves down the prefetch pipe (`row_new` -> `row_mid`). rtl/video/blstroid_pf.sv:66 The 2J / 1J LS194A shifters and the horizontal doubling rtl/video/blstroid_pf.sv:79 The board recovers the same alignment downstream (sheet 10's 14C F74 on `/14M` and the two F374s on `14M`); doing it here keeps `pf_pix` exactly on the `hpos` grid the compositor uses: rtl/video/blstroid_pf.sv:90 `4E LS174C` (CK = `4HD2H`, rising at the 5->6 boundary) re-times three unrelated signals two counts after the map latch: D3 = PFM2 -> Q2 = PFPAL2 D13 = PMLNK8 -> Q12 = MOLNK8 rtl/video/blstroid_pf.sv:94 D6 = PFM0 -> Q7 = PFPAL0 `MOLNK8` goes back to sheet 5 as `VRAM10` in the four motion-object slots (`blstroid_vram.molnk8`) and `1VD6H` is the sheet-9 line-buffer ping-pong select, so this module exports both even though neither is a pixel. rtl/video/blstroid_pf.sv:98 `PFM2:0` themselves are the 4K LS174B latch, modelled in `blstroid_vram` so that the IRQ1 path does not have to depend on the playfield module. rtl/video/blstroid_pf.sv:120 4K LS174B Q2/Q5/Q7 = PFM2, PFM1, PFM0 rtl/video/blstroid_pf.sv:133 ---- 4E LS174C, the two non-playfield signals it re-times ------------ rtl/video/blstroid_pf.sv:135 Q10 -> sheet 9 line-buffer ping-pong rtl/video/blstroid_pf.sv:146 4HD2H rising — 4E LS174C rtl/video/blstroid_pf.sv:152 4E LS174C — PFPAL2:0, MOLNK8, 1VD6H (CK = 4HD2H) rtl/video/blstroid_pf.sv:212 4K / 4L / 6F latch the new map word; the fetch starts here rtl/video/blstroid_pf.sv:227 2J / 1J LS194A — parallel load, then one shift, per ROM byte rtl/video/blstroid_prio.sv:3 Blasteroids — SP-316 sheet 10: the priority RAM 17E (27LS00A, 256 x 1), its two inverting 74F158 address multiplexers (15E, 16E) and the /CS3 gate that makes a transparent motion-object pixel mean "playfield". rtl/video/blstroid_prio.sv:8 Module shape from the Xybots MiSTer core's rtl/video/xybots_prio.sv (GPL-3.0, same author); Blasteroids' network is a one-bit lookup rather than Xybots' 74S85 comparator, so nothing else is shared. rtl/video/blstroid_prio.sv:13 ---- the address ------------------------------------------------------- 15E/16E F158 are inverting 2:1 muxes, but they invert the CPU write address and the video lookup address identically, so the inversion cancels and software sees sheet rtl/video/blstroid_prio.sv:33 i.e. a stored 1 means "MO on top", which is what sheet 12 says and what MAME's `if (mo[x] != 0xffff)` guard does. rtl/video/blstroid_prio.sv:65 sheet 12's address uses PFPIX3 rtl/video/blstroid_sos2_sync.sv:3 Blasteroids — SP-316 sheet 4: the SOS-2 sync generator (3F, Atari 137550-001) and every discrete gate on that sheet that shapes its outputs into the nets the other video sheets consume. rtl/video/blstroid_sos2_sync.sv:13 ---- what the sheet gives, and what it does not ------------------------- 3F is a 40-pin Atari custom and SP-316 draws only its pinout, so the counters are derived rather than read: rtl/video/blstroid_sos2_sync.sv:19 It cannot be clocked at 14M (912 does not fit in 9 bits), so it runs at 7M, and the only value in 257..512 that yields a standard 15.7 kHz line is 456: 7 159 090 / 456 = 15 700.6 Hz, 63.709 us. rtl/video/blstroid_sos2_sync.sv:93 263 is what the Atari System 1 / Xybots sync-generator family produces from its dumped sync PROM (240 visible + 22 blanked + one extra line made by /VRES loading 0xFF), and the SOS-2 exposes the same /VRES net. rtl/video/blstroid_sos2_sync.sv:96 The SOS-2 counts V internally and the schematics do not settle it, so this stays a build-time parameter: 59.9227 Hz at 262, 59.6949 Hz at 263. rtl/video/blstroid_sos2_sync.sv:165 pin 25 -> 13E LS74 /CLR, 7D LS273A /CLR rtl/video/blstroid_sos2_sync.sv:169 ---- the video-RAM slot schedule (sheet 5) -------------------------- rtl/video/blstroid_sos2_sync.sv:191 ---- the two HBLANK edges, one clk_sys cycle wide, aligned to ce_7m -- `hblank_rise` is the edge sheet 2 uses twice: it clocks 13C LS74 (the row-programmable IRQ1) and 11D LS74 upper (halt-until-HBLANK). rtl/video/blstroid_sos2_sync.sv:280 That is unobservable: every one of those lines is inside VBLANK, the playfield row address only matters while `vde`, and the IRQ1 gate is qualified by /VBLANK (sheet 2). rtl/video/blstroid_sos2_sync.sv:357 SELCPU = ~(/4H & 1H) = 4H \| /1H (14D LS00, sheet 5); RAMFREE = ~((1H & /4H) \| /2H) = 2H & SELCPU (11J LS02 + 14B LS08, sheet 2): rtl/video/blstroid_testpat.sv:40 The blanking split below (front porch, sync width, back porch, and the VSYNC line) is this module's own and is not taken from the SP-316 sheets: it is Xybots' measured SP-313 split (456 total: 32 front, 32 sync, 56 back) scaled x2 to this l rtl/video/blstroid_video.sv:3 Blasteroids — the whole video board (SP-316 sheets 4 to 11) as one module: the SOS-2 sync generator, the video/work RAM and its 8-count slot schedule, the playfield pipeline, the motion-object engine, the priority RAM, the colour RAM and th rtl/video/blstroid_video.sv:56 Sheet 2 clocks the IRQ1 latch on the rising edge of HBLANK and samples `PFM2`, and `PFM2` is the 4K LS174B's latched VD15 of the last playfield word fetched — a value that changes once every 8 H counts all the way across the line, because t rtl/video/blstroid_video.sv:60 Sheet 12 puts the row-interrupt flag in column 40 only. rtl/video/blstroid_video.sv:89 /MOL loads the line-buffer write counter from VD15:6 while MOHPOS is on the video bus, and sheet 5 puts MOHPOS at H[2:0] = 5. rtl/video/blstroid_video.sv:186 4K LS174B Q2 — the IRQ1 row condition rtl/video/blstroid_video.sv:226 SOS-2 at 3F — sheet 4 rtl/video/blstroid_video.sv:240 /MOL must land on the count that carries MOHPOS (sheet 5, H[2:0] = 5) — see the header. rtl/video/blstroid_video.sv:276 Video / work RAM — sheet 5 rtl/video/blstroid_video.sv:298 ---- 4K LS174B (sheet 6): PFM2:0 = the map word's D15:13, on 4H ------- The latch itself lives in blstroid_vram, so the IRQ1 path does not depend on whether the playfield module is drawing; both consumers read it here. rtl/video/blstroid_video.sv:304 Playfield — sheet 6 rtl/video/blstroid_video.sv:334 Priority RAM — sheet 10 rtl/video/blstroid_video.sv:348 Colour RAM and the output registers — sheet 10 rtl/video/blstroid_video.sv:368 The DACs — sheet 11 rtl/video/blstroid_vram.sv:3 Blasteroids — SP-316 sheet 5: the 16 KB video / work RAM (5L, 6/7L), its address multiplexers, the eight-count slot arbiter, the CPU data path and the motion-object link registers. rtl/video/blstroid_vram.sv:8 Structurally derived from the Xybots MiSTer core's video-RAM arbiter (GPL-3.0, same author), with every gate re-derived from sheet 5. rtl/video/blstroid_vram.sv:12 The crux of sheet 5: /OE is tied low rtl/video/blstroid_vram.sv:17 This module reproduces that: `vd` is the registered read of whatever address the multiplexers select, valid from the second clk_sys cycle of each `1H` count and therefore stable at that count's `ce_7m` — the edge on which sheet 6's 4K/4L/6F rtl/video/blstroid_vram.sv:58 cpu_we_hi LEVEL = ~/WH -> writes vd[15:8] (6/7L, the high byte lane) cpu_we_lo LEVEL = ~/WL -> writes vd[7:0] (5L, the low byte lane) A write reaches the RAM only when RAMFREE & cpu_sel & the lane & 7M is high (sheet 2: /VWRH = /VM rtl/video/blstroid_vram.sv:93 The 4K LS174B / 4L LS374C / 6F F174A map-word latches and the 4E LS174C re-timing latch (PFPAL2:0, MOLNK8, 1VD6H) are on sheet 6 and live in `blstroid_pf.sv`, with the rest of the playfield pipeline they belong to. rtl/video/blstroid_vram.sv:96 This module therefore EXPORTS `pmlnk8` (13E LS74 Q, sheet 5) and IMPORTS `molnk8` (4E LS174C Q12, sheet 6) — exactly the two wires that cross between the sheets. rtl/video/blstroid_vram.sv:117 ---- from blstroid_pf (sheet 6, 4E LS174C Q12) ---------------------- rtl/video/blstroid_vram.sv:134 ---- 4K LS174B, the playfield map word's palette field --------------- Q2, Q5, Q7 = PFM2, PFM1, PFM0 = the latched VD15, VD14, VD13, captured on the `4H` rising edge once per stamp column. rtl/video/blstroid_vram.sv:136 `pfm[2]` (PFM2) is BOTH the playfield palette MSB and the row-programmable-interrupt condition that sheet 2's 11C LS11 / 1D LS20 / 13C LS74 chain turns into IRQ1, which is why it leaves this module rather than `blstroid_pf`: the interrupt p rtl/video/blstroid_vram.sv:144 ---- motion-object link walk (13E LS74 / 7D LS273A / 7E LS374) ------ rtl/video/blstroid_vram.sv:145 13E LS74 Q5 -> sheet 6 4E LS174C D13 rtl/video/blstroid_vram.sv:161 The motion-object link registers — 13E LS74, 7D LS273A, 7E LS374 rtl/video/blstroid_vram.sv:172 7D LS273A — the link just latched off VD rtl/video/blstroid_vram.sv:192 4K LS174B — CK 9 = `4H`, /C 1 = PR2. rtl/video/blstroid_vram.sv:208 Address multiplexers — 5F LS253, 4F LS253A, 6E/5E LS257, 11C LS11 rtl/video/blstroid_vram.sv:234 Write strobes — sheet 2, 11E LS32 chain rtl/video/blstroid_vram.sv:296 `v[2:0]` is the line inside the stamp — sheet 6's PF ROM address, formed in blstroid_pf, not part of the map address. README.md:7 The core reconstructs the original PCB set — the 68000 game board plus an Atari JSA I sound board — from Atari's SP-316 schematic package, with MAME used as a f README.md:162 \| Protection \| None — SP-316 sheet 3 notes "The SLAPSTIC chip is not installed" \| README.md:221 It applies where the SP-316 schematics document something MAME's model does not. README.md:226 \| Row-programmable interrupt (IRQ1) \| Stubbed out; MAME takes zero level-1 interrupts \| Real and fully wired: sheet 6 latches VD15 as PFM2 and sheet 2's LS74 is README.md:228 \| Video DAC \| Linear `xRGB_555` \| The three R/2R ladders on sheet 11, including their code-0 pedestal \| README.md:231 \| Watchdog \| Generic timer with default timing \| Sheet 2's LS90: reset after 8 frames without a write, held for two frames, parked at 9 on power-up \| README.md:254 Which YM2151 channel is left. SP-316 does not label them, so the core follows MAME. README.md:302 Thanks to the MAME team, whose `blstroid.cpp`, `atarijsa` and `atarimo` code served as the functional oracle throughout, and to whoever preserved the Atari SP-3 Cites hardware references or measurements that MAME's driver also gives — 1 rtl/video/blstroid_mo_linebuf.sv:57 Between strobes both free-run at 14M, which is why one object's sixteen pixels land at X, X+1 ... — also in MAME: 14M atari/blstroid.cpp:451 Notes where it differs from MAME — 5 rtl/main/blstroid_irq.sv:10 ---- IRQ1, the row-programmable playfield interrupt -------------------- Real hardware, fully wired, and the one thing MAME stubs out: README.md:10 Where a schematic and MAME disagree, the schematic wins and the disagreement is recorded — see [Where this core differs from MAME](#where-this-core-differs-from README.md:200 All three interrupt levels are taken, including the row-programmable playfield interrupt that MAME does not implement, and the sound mailbox closes between the README.md:218 Where this core differs from MAME README.md:221 It applies where the SP-316 schematics document something MAME's model does not. Cites MAME source — 58 Arcade-Blasteroids.sv:15 Blasteroids runs on a horizontal monitor (MAME ROT0), so there is no rotation: the raster goes straight through arcade_video. Arcade-Blasteroids.sv:120 MAME's INPUT_PORTS_START(blstroid) has only the two dial ports and the two button/status words, and every operator setting lives in the X2804 EEPROM at 0xFFB000, changed from the game's own self test. Arcade-Blasteroids.sv:150 TM-316's Switch Test lists exactly four inputs per player (Spare, Xform, Thrust, Fire), the control-panel figure and the CTRA connector carry three buttons per player, and MAME's blstroid.cpp defines no IPT_START1/2. rtl/blstroid_core.sv:104 The SOS-2's vertical total: 262 lines, MAME's figure. rtl/blstroid_core.sv:111 1 = MAME's xRGB_555 transfer, 0 = the sheet-11 R/2R ladder value. rtl/blstroid_core.sv:153 The operator manual lists exactly four inputs per player in the Switch Test (Spare, Xform, Thrust, Fire), the control-panel figure and the CTRA connector carry three buttons per player, and MAME defines no IPT_START1/2 either. rtl/main/blstroid_addr_decode.sv:8 The two descriptions agree over the whole 24-bit space: the mirrors MAME documents are simply the address bits the drawn decoders never look at. rtl/main/blstroid_addr_decode.sv:47 ---- what the mirrors are ------------------------------------------------ A22-A15 reach no decoder at all, so the whole FF8000-FFFFFF register/RAM map repeats every 32 KB over 800000-FFFFFF (MAME: `global_mask(0x83ffff)` plus per-entry `.m rtl/main/blstroid_addr_decode.sv:50 Inside FF8000-FF8FFF only A11-A9 are decoded, so each write strobe answers over a whole 512-byte page (MAME: `.mirror(0x0381fe)`) — except /PRIRAM, whose A8-A1 are the priority RAM's own address. rtl/main/blstroid_dtack.sv:64 MAME spins the CPU instead, which is observationally equivalent but is not what the board does. rtl/main/blstroid_eeprom_2804.sv:18 The socket is wired for a 2816 (2 K x 8) but the fitted X2804A is 512 x 8 (A0..A8 only), so the device repeats four times over FFB001-FFBFFF — which is what sheet 12's "a = ADDRESS BITS ON 2816 ONLY" note means and what MAME's `.mirror(0x03 rtl/main/blstroid_eeprom_2804.sv:36 * the first following low-byte write clocks D = 0 on the /WL rising edge, so the part re-locks after exactly one write — MAME's `lock_after_write(true)`. rtl/main/blstroid_eeprom_2804.sv:56 ---- programming time --------------------------------------------------- The X2804A data sheet gives a self-timed byte write of typically 5 ms and at most 10 ms with the I/O pins high-Z throughout; MAME models no write time at all. rtl/main/blstroid_eeprom_2804.sv:207 There are no pull-ups on BD0-BD7, so the modelled float value is the 0xFF an unmapped MAME read gives. rtl/main/blstroid_inputs.sv:35 MAME maps them as BUTTON4 and the self test displays them, so they are exposed here. rtl/main/blstroid_leta.sv:38 ---- how the CLK/DIR pair is decoded ------------------------------------ No LETA data sheet is public and MAME has no LETA device at all (it reads these addresses as plain IPT_DIAL ports, sensitivity 60). rtl/main/blstroid_main.sv:55 ---- reads of write-only strobes --------------------------------------- Nothing drives the board bus for them, so they read 0xFFFF, which is also MAME's `unmap_value_high()`. rtl/main/blstroid_main.sv:304 A CPU read returns the undriven bus (0xFFFF); MAME keeps a readable shadow instead, so the two disagree there. rtl/main/blstroid_watchdog.sv:36 MAME instantiates `WATCHDOG_TIMER(config, "watchdog")` with default timing: neither the 8-frame period, nor the 2-frame pulse, nor the park-at-9 power-up is modelled there. rtl/main/blstroid_whirly.sv:71 d-pad Left/Right stepped at a fixed rate, the same idea as MAME's PORT_KEYDELTA, so a gamepad or keyboard can play at all. rtl/main/blstroid_whirly.sv:79 MAME uses PORT_SENSITIVITY(60) PORT_KEYDELTA(10). rtl/mem/blstroid_prog_rom.sv:21 Sheet 12 reserves 0x038000-0x03FFFF as "32K BYTES SLAPSTIC PROGRAM ROM SPACE", but no slapstic is fitted on a Blasteroids board and MAME's driver has none either, so this is a plain ROM. rtl/mem/blstroid_rom_loader.sv:11 ---- the index-0 stream map ---------------------------------------------- The MRA concatenates MAME's ROM regions in this order, and the offsets below must match it byte for byte: rtl/mem/blstroid_rom_loader.sv:15 stream base size MAME region destination rtl/mem/blstroid_rom_loader.sv:36 ---- byte order (the one thing that must not be guessed) ----------------- maincpu is emitted as BIG-ENDIAN INTERLEAVED WORDS — the even-offset MAME ROM (6C / 4C) is `map="01"`, the FIRST byte of each output word, i.e. D15:8. rtl/mem/blstroid_sdram_loader.sv:16 tiles (MAME gfx_8x8x4_packed_msb): 32 bytes per 8x8 stamp, byte = code[12:0]32 + row[2:0]4 + (A1,A0); one PF stamp row = 4 CONSECUTIVE bytes = 2 words = ONE burst-2. rtl/mem/blstroid_sdram_loader.sv:20 A Blasteroids MO stamp is 16 x 8 and its pixels come alternately from the two 512 KB halves of the `sprites` region — the board's M row and N row banks of MO stamp ROMs (sheets 8 and 7), addressed with the SAME within-half address (MAME `mo rtl/mem/blstroid_sdram_loader.sv:25 sprites (MAME molayout): 32 bytes per 16x8 stamp PER HALF, within-half byte = code[13:0]32 + row[2:0]4 + (A1,A0); one MO stamp row = 4 bytes from M AND 4 bytes from N, both at the SAME within-half offset -> 8 bytes, 4 words. rtl/video/blstroid_cram.sv:23 MAME's `GFXDECODE_SCALE("tiles", 0, ..., 256, 16, 2, 1)` uses the same base 256 with 8 of the 16 groups. rtl/video/blstroid_cram.sv:55 MAME behaves the same way. rtl/video/blstroid_cram.sv:157 The colour word is xRGB 5:5:5 (sheet 12; MAME's xRGB_555): rtl/video/blstroid_dac.sv:30 ---- the two transfers --------------------------------------------------- DAC_MAME_COMPAT = 1 (default) MAME's `pal5bit(x) = (x << 3) \| (x >> 2)` — bit replication, what `xRGB_555` does. rtl/video/blstroid_dac.sv:36 The default is the MAME curve so that a frame captured from this core can be compared bit for bit with one captured from MAME; the ladder's own answer is 0. rtl/video/blstroid_mo.sv:82 That is MAME's `molayout` x-offset list {RGN_FRAC(1,2)+0, RGN_FRAC(1,2)+4, 0, 4, ...} read back out. rtl/video/blstroid_mo.sv:109 and the first VISIBLE pixel is (h, pix) = (HB_END, 0), so making the line-buffer address equal the screen column — which is MAME's `xpos` exactly, atarimo.cpp folding xpos >= 640 by -1024 where the 10-bit counter wraps — needs rtl/video/blstroid_mo.sv:123 1 = walk the full 14-bit code when a tall object crosses a 1024-stamp boundary (MAME's `code++`). rtl/video/blstroid_mo.sv:226 which is atarimo.cpp's `ypos = -(Y + 8height)` covering 8height lines, re-derived: the object covers D iff U >= 512 - 8height. rtl/video/blstroid_mo.sv:238 MAME draws the stamp rows bottom-up and flips inside the stamp; the shipping ROM never sets the bit, so this path is unexercised by the game and is here only because the sheet wires the pin. rtl/video/blstroid_mo.sv:247 MO_CODE_CARRY = 1 restores MAME's full 14-bit add for comparison. rtl/video/blstroid_mo_linebuf.sv:38 So an untouched location reads pen 0, and pen 0 is transparent — MAME's "transparent pen index = 0" exactly. rtl/video/blstroid_mo_linebuf.sv:61 The counters are TEN bits and the RAMs' A10 is grounded, so a column starting near 1023 wraps into the left edge — which is exactly atarimo.cpp's `xpos &= 0x3ff` followed by its `xpos >= width ? rtl/video/blstroid_pf.sv:58 chip = {PFPIC12, PFPIC11} -> MAME `tiles` offset 0x10000 so the linear byte address is `code * 32 + line * 4 + byte_in_row` and the `blstroid_gfx_mem` request address (bits 17:2 of it) is simply `{code[12:0], line[2:0]}` — no multiply rtl/video/blstroid_prio.sv:23 which is byte-for-byte MAME's `priaddr = ((pf & 8) << 4) \| (pf & 0x70) \| ((mo & 0xf0) >> 4)`. rtl/video/blstroid_prio.sv:33 i.e. a stored 1 means "MO on top", which is what sheet 12 says and what MAME's `if (mo[x] != 0xffff)` guard does. rtl/video/blstroid_prio.sv:41 The sheet has no CPU read path to 17E: the 68000's `clr.w` over this region is a read-modify-write whose read only has to terminate, and MAME maps the region write-only as well. rtl/video/blstroid_sos2_sync.sv:22 That is MAME's 4562, arrived at independently. rtl/video/blstroid_sos2_sync.sv:27 The visible window is 40 stamps x 16 px = 640 = 320 counts, and 30 stamp rows x 8 lines = 240 — MAME's 640 x 240 exactly. rtl/video/blstroid_sos2_sync.sv:91 ---- vertical ------------------------------------------------------- 262 is MAME's figure, whose own comment says it comes from published specs rather than measurement. README.md:7 The core reconstructs the original PCB set — the 68000 game board plus an Atari JSA I sound board — from Atari's SP-316 schematic package, with MAME used as a f README.md:20 Five MAME sets run on identical RTL — they differ only in the main CPU ROMs. README.md:43 \| ROMs \| Supplied by you from a MAME archive; none are included here \| README.md:82 The operator manual lists exactly four switches per player, and the MAME driver defines no Start input. README.md:220 MAME 0.288 was this project's functional oracle and every gate above measures the core against it, so this is a narrow claim. README.md:224 \| Behaviour \| MAME \| This core \| README.md:226 \| Row-programmable interrupt (IRQ1) \| Stubbed out; MAME takes zero level-1 interrupts \| Real and fully wired: sheet 6 latches VD15 as PFM2 and sheet 2's LS74 is README.md:247 The core uses 262 (MAME's published figure) as a compile-time parameter; rebuild with `V_TOTAL = 263` to try the other. README.md:254 Which YM2151 channel is left. SP-316 does not label them, so the core follows MAME. README.md:302 Thanks to the MAME team, whose `blstroid.cpp`, `atarijsa` and `atarimo` code served as the functional oracle throughout, and to whoever preserved the Atari SP-3 Says it matches, follows or was checked against MAME — 2 README.md:204 Pixel-exact compositor gate — MAME is instrumented to capture complete video state at chosen frames; that state is replayed through the real core RTL and th README.md:233 On every captured frame they are observationally identical to MAME, because the per-band chains the game installs are short and no captured scanline exceeds 57 Keeps a MAME approximation — 1 rtl/video/blstroid_mo.sv:130 /VRES's phase is inside the SOS-2 and cannot be probed, but this is the only reading under which line 0 of the picture is correct, and it is what MAME's `ypos` arithmetic assumes. Shares text with the MAME driver without saying so — 3 rtl/main/blstroid_whirly.sv:22 counting up (0,0) -> (0,1) -> (1,1) -> (1,0) -> (0,0) — shares text with atari/atarimo.cpp:14 rtl/main/blstroid_whirly.sv:80 uses PORT_SENSITIVITY(60) PORT_KEYDELTA(10). — shares text with atari/blstroid.cpp:313 rtl/video/blstroid_mo.sv:83 MAME's `molayout` x-offset list {RGN_FRAC(1,2)+0, RGN_FRAC(1,2)+4, 0, 4, — shares text with atari/blstroid.cpp:357
Blockade# Blasto, Blockade, CoMotion, Hustle MiSTer-devel/Arcade-Blockade_MiSTer @ dba47dc9 MAME compared: sega/blockade.cpp Read: 9 HDL files, 2,628 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	24%
Statements: 1 toward MAME Cites MAME source — 1 rtl/blockade.v:326 This is an analog noise generator which I can't replicate, so we have wave playback of a MAME-source sample
BloodBros# Blood Bros. MiSTer-devel/Arcade-BloodBros_MiSTer @ 2abeab3f MAME compared: seibu/bloodbro.cpp + 4 related file(s) Read: 19 HDL files, 5,778 lines (Quartus project)	MiSTer official	Mostly MAME	medium	70%
Statements: 2 toward hardware, 50 toward MAME, 1 not counted Cites hardware documentation that MAME's driver does not — 2 rtl/BloodBros/BloodBros_main_top.sv:31 Memory map SD Gundam (da MAME dcon.cpp + SD Gundam override): $000000-$07FFFF ROM 68K (512KB) $080000-$08BFFF Main RAM (48KB) $08C000-$08C7FF BG tile RAM (2KB) $08C800-$08CFFF FG tile RAM (2KB) $08D000-$08D7FF MG tile RAM rtl/BloodBros/BloodBros_maincpu_map.sv:29 Memory map SD Gundam (da MAME dcon.cpp + sdgndmps_map override): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $080000-$08BFFF Main RAM (48KB) → BRAM $08C000-$08C7FF BG tile RAM → BRAM dual-port $08C800-$ Cites hardware references or measurements that MAME's driver also gives — 1 rtl/BloodBros/BloodBros_video_timing.sv:26 PCB measurement Blood Bros: VSync 59.4094 Hz, HSync 15.6246 kHz, master XTAL 20 MHz. — also in MAME: 59.4094 seibu/bloodbro.cpp:970, 15.6246 seibu/bloodbro.cpp:971 Cites MAME source — 44 BloodBros.sv:215 I valori di calibrazione pixel-perfect MAME sono hardcodati DENTRO i rispettivi renderer / cablature: - BG X+0 Y+16 : .yoff(10'sd16) sotto - MG X+0 Y+0 : .yoff(10'sd0) - FG X+0 Y+16 : .yoff(10'sd16) - SPR X+0 Y-16 : sprite rende BloodBros.sv:293 --- Joystick to SD Gundam input mapping --- MAME P1_P2 port ($E0002): active low. BloodBros.sv:296 MiSTer joy bits: joy[0]=R, joy[1]=L, joy[2]=D, joy[3]=U, joy[4]=A, joy[5]=B. MAME bloodbro IN0: bit0..3 = U/D/L/R, bit4=Btn1 Fire, bit5=Btn2 Roll, bit6=Btn3 Dynamite (active low) BloodBros.sv:597 ── Flip screen (CRTC reg 0x1A bit 0) ─────────────────────────────────────── MAME: BIT(reg_1a, 0) → flip_screen. BloodBros.sv:639 Blood Bros Text: no scroll (MAME bloodbro.cpp non chiama set_scroll su tx_tilemap) BloodBros.sv:673 Blood Bros CRTC scroll passthrough — nessun offset (MAME bloodbro.cpp:427-430) Blood Bros usa scroll_ram[0/1] per BG e scroll_ram[2/3] per FG (MAME bloodbro.cpp:427-430). BloodBros.sv:696 Blood Bros: tilemap 32x16 (MAME bloodbro.cpp:292) BloodBros.sv:731 Blood Bros FG: palette base 0x500 (MAME bloodbro.cpp:808 = 0x5016) MAME bloodbro fg_tile_info: tile = (vram & 0xFFF) + 0x1000 hardcoded. BloodBros.sv:738 Blood Bros: tilemap 32x16 (MAME bloodbro.cpp:293) BloodBros.sv:743 Blood Bros: bit 1 = FG (MAME bloodbro.cpp layer_en_w) BloodBros.sv:790 MAME bloodbro.cpp:379-382 pri_cb: pri=0 → mask 0 (above all), pri=1 → mask 0x02. BloodBros.sv:791 MAME draw order (riga 434-441): BG → FG → sprites → Text. rtl/BloodBros/BloodBros_audio_z80.sv:25 Spec da MAME (reference/mame_seibu/seibusound.cpp + bloodbro.cpp): - Z80 @ 3.579545 MHz (XTAL 7.159090 / 2) - YM3812 (jtopl2) @ 3.579545 MHz - OKI M6295 (jt6295) @ 1.000 MHz (XTAL 12/12), PIN7=HIGH rtl/BloodBros/BloodBros_audio_z80.sv:31 Main↔sub comm @ 0xA0000-0xA000D: standard MAME seibu_sound_device. rtl/BloodBros/BloodBros_audio_z80.sv:315 ─── OKI M6295 (jt6295) — PIN7_HIGH (bloodbro.cpp:872) ────────────────── rtl/BloodBros/BloodBros_main_top.sv:31 Memory map SD Gundam (da MAME dcon.cpp + SD Gundam override): $000000-$07FFFF ROM 68K (512KB) $080000-$08BFFF Main RAM (48KB) $08C000-$08C7FF BG tile RAM (2KB) $08C800-$08CFFF FG tile RAM (2KB) $08D000-$08D7FF MG tile RAM rtl/BloodBros/BloodBros_main_top.sv:198 VBLANK IRQ4 — MAME dcon.cpp: m_maincpu->set_vblank_int(irq4_line_hold) Rising edge di vblank → assert IRQ4 pending; IACK CPU → clear. rtl/BloodBros/BloodBros_main_top.sv:342 XOR 0x400 lato CPU per allineare BRAM[N] = MAME text_vram[N] (renderer parte da addr 0). rtl/BloodBros/BloodBros_main_top.sv:350 Quindi MAME palette[N] sta in vram_addr = (N + 0x400) & 0x7FF. rtl/BloodBros/BloodBros_main_top.sv:351 Per allineare BRAM[N] = MAME palette[N] applichiamo XOR 0x400 SOLO al lato CPU (a_addr). rtl/BloodBros/BloodBros_main_top.sv:352 Il renderer passa pen_index MAME nativo (BG=0x400+, MG=0x500+, ecc) e la BRAM è già allineata. rtl/BloodBros/BloodBros_main_top.sv:362 Sprite RAM CPU-side (write/read) — Blood Bros: 4KB = 2048 word (AW=11) MAME bloodbro.cpp:467 map(0x08b000, 0x08bfff).ram().share(m_spriteram) → 4KB. rtl/BloodBros/BloodBros_maincpu_map.sv:29 Memory map SD Gundam (da MAME dcon.cpp + sdgndmps_map override): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $080000-$08BFFF Main RAM (48KB) → BRAM $08C000-$08C7FF BG tile RAM → BRAM dual-port $08C800-$ rtl/BloodBros/BloodBros_maincpu_map.sv:107 ─── Region detect (MAME bloodbro.cpp:465-483) ────────────────────────── rtl/BloodBros/BloodBros_maincpu_map.sv:161 ─── GFX bank register ─────────────────────────────────────────────────── MAME dcon.cpp gfxbank_w: SOLO bit0 → m_gfx_bank_select = 0x1000 oppure 0. rtl/BloodBros/BloodBros_palette.sv:25 MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_444, 2048); Address space CPU: 0x08E800..0x08F7FF (4 KB = 2048 word). rtl/BloodBros/BloodBros_palette.sv:34 Espansione 5→8 bit con replica top-bits (standard MiSTer / MAME palette_device). rtl/BloodBros/BloodBros_palette.sv:86 Blood Bros: xBGR_444 → RGB888 (MAME bloodbro.cpp:859 set_format xBGR_444) Layout: bit[11:8]=R, bit[7:4]=G, bit[3:0]=B. 4 bit per canale. rtl/BloodBros/BloodBros_palette.sv:88 Replica 4→8 standard: {nibble, nibble} (MAME palette_device standard expansion) rtl/BloodBros/BloodBros_seibu_crtc.sv:23 Seibu CRTC fedele a MAME (src/mame/seibu/seibu_crtc.cpp). rtl/BloodBros/BloodBros_seibu_crtc.sv:117 MAME mappa: bit0=screen0(BG), bit1=screen2(MG), bit2=screen1(FG), bit3=screen3(Text) (vedi seibu_crtc.cpp commento "screen 0=BG, screen 1=FG, screen 2=MG, screen 3=Text") In SD Gundam dcon.cpp layer_en_w gira la maschera così: ~layer_en bit rtl/BloodBros/BloodBros_seibu_crtc.sv:126 Il dispatcher MAME usa "if (BIT(~m_layer_en, n))" per saltare = layer disabilitato quando il bit è 1. rtl/BloodBros/BloodBros_sprite_renderer.sv:26 Formato "alt" (vedi MAME sei021x_sei0220_spr.cpp). rtl/BloodBros/BloodBros_sprite_renderer.sv:126 Decoded fields — Blood Bros ALT FORMAT (MAME sei021x_sei0220_spr.cpp:124-140) W0: bit 15 Disable (1=skip!) - INVERSO vs std (era enable) rtl/BloodBros/BloodBros_sprite_renderer.sv:145 SEI0211 get_coordinate (MAME sei021x_sei0220_spr.h): coord &= 0x1ff; return (coord >= 0x180) ? rtl/BloodBros/BloodBros_sprite_renderer.sv:178 Tile code finale Y-MAJOR (MAME draw_internal: ax=outer, ay=inner, code++): sub_index = axsizey + ay → cur_tile = code + eff_tile_xsp_h + eff_tile_y rtl/BloodBros/BloodBros_text_renderer.sv:25 Specifiche da MAME (src/mame/seibu/dcon.cpp): rtl/BloodBros/BloodBros_tile_layer.sv:25 Differenze fra layer (da MAME dcon.cpp): rtl/BloodBros/BloodBros_tile_layer.sv:58 BB FG hardcoded +0x1000 (MAME bloodbro fg_tile_info) rtl/BloodBros/BloodBros_tile_layer.sv:176 Tile index con eventuale gfx_bank (MG ha bit 12 = 13-bit totali, BG/FG = 12 bit) + TILE_CODE_OFS hardcoded (BB FG aggiunge 0x1000 secondo MAME bloodbro fg_tile_info). rtl/BloodBros/BloodBros_video_timing.sv:35 Active area da MAME (sdgndmps_map): visarea 0..408-1, 28..308-1 quindi 320×224, V offset = 16 (top blank). rtl/BloodBros/BloodBros_video_timing.sv:72 ── Constants timing ───────────────────────────────────────────────────── Blood Bros: 256x224 active (MAME bloodbro.cpp:846-851 set_visarea 0..255, 16..239). rtl/BloodBros/sdram_bridge.sv:296 FG layer: Blood Bros shares ROM with BG (MAME bloodbro:807-808) README.md:18 YM3812 OPL2 FM (jtopl2) + OKI M6295 ADPCM (jt6295) with MAME-accurate mixer Says it matches, follows or was checked against MAME — 2 BloodBros.sv:208 Shift fisso aggiunto per match MAME 1:1 (misurato HW 2026-05-14): BG X+0 Y+16 FG X+0 Y+16 SPR X+0 Y+0 TXT X-1 Y+16 L'OSD resta editabile ±32 attorno al valore corretto. BloodBros.sv:302 Blood Bros SYSTEM port ($0E0004) IN1 — verified MAME bloodbro.cpp:688 bit0 = START1 (active LOW) bit4 = START2 (active LOW) bit12 = SERVICE1 (0x1000, active LOW) IPT_SERVICE1 altri = UNKNOWN/UNUSED → tied 1 Coin inputs NON sono Says it was translated, ported or taken from MAME — 1 BloodBros.sv:208 Shift fisso aggiunto per match MAME 1:1 (misurato HW 2026-05-14): BG X+0 Y+16 FG X+0 Y+16 SPR X+0 Y+0 TXT X-1 Y+16 L'OSD resta editabile ±32 attorno al valore corretto. Shares text with the MAME driver without saying so — 3 rtl/BloodBros/BloodBros_main_top.sv:363 MAME bloodbro.cpp:467 map(0x08b000, 0x08bfff).ram().share(m_spriteram) → 4KB. — shares text with seibu/bloodbro.cpp:467 rtl/BloodBros/BloodBros_palette.sv:23 Palette RAM Seibu Blood Bros (xBGR_444, 2048 entries). MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_444, 2048); Address space CPU: — shares text with seibu/bloodbro.cpp:859 rtl/BloodBros/BloodBros_video_timing.sv:23 Video timing single-screen Seibu D-Con. SD Gundam Psycho Salamander gira su Seibu D-Con (PB91008), stessa famiglia di Blood Bros (1990). PCB measuremen — shares text with seibu/bloodbro.cpp
BluePrint# Blue Print, Grasspin, Saturn MiSTer-devel/Arcade-BluePrint_MiSTer @ aff7508d MAME compared: jaleco/blueprnt.cpp Read: 7 HDL files, 1,626 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	54%
Statements: 1 toward hardware, 2 toward MAME Ships hardware documentation files — 1 Useful Information/Blueprint Schematics & Manual.pdf Cites MAME source — 1 rtl/BluePrint_CPU.sv:96 H counter 0-319, V counter 0-263 From MAME: set_raw(5MHz, 320, 0, 256, 264, 16, 240) Shares text with the MAME driver without saying so — 1 rtl/BluePrint_CPU.sv:97 From MAME: set_raw(5MHz, 320, 0, 256, 264, 16, 240) — shares text with jaleco/blueprnt.cpp:600
BombJack# Bomb Jack MiSTer-devel/Arcade-BombJack_MiSTer @ 14f52332 MAME compared: tecmo/bombjack.cpp Read: 26 HDL files, 5,827 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	50%
Statements: 7 toward hardware, 2 toward MAME Cites hardware documentation that MAME's driver does not — 7 rtl/bombjack/bombjack.vhd:14 This is a VHDL implementation of the arcade game "Bomb Jack" (c) 1984 Tehkan Translated from schematic to VHDL Q1 2012, d18c7db rtl/bombjack/bombjack.vhd:353 chip 6P10 page 1 (deviation from schematic to cleanup the wait pulse by taking s_7P5 into account as well) added user/hiscore system controlled pause rtl/bombjack/p3_timing.vhd:236 chip 5P9 page 3 - original as per schematic U5P9 : process begin wait until rising_edge(I_CLK_12M); s_16V_t1 <= s_16V; -- detect rising edge of s_16V if (s_16V = '1' and s_16V_t1 = '0') then -- chip 4N8 page 3 s_vblank_n <= not (s_32V and s rtl/bombjack/p3_timing.vhd:248 chip 5P9 page 3 - deviation from schematic to extend the blanking signal rtl/bombjack/p4_sprites.vhd:180 ROMs 8K, 8H, 8E in separate file rtl/bombjack/p6_char_gen.vhd:140 ROMs 8K, 8H, 8E in separate file rtl/bombjack/p7_bgnd_tiles.vhd:105 ROMs 4P, 8R, 8N, 8L in separate file Cites MAME source — 2 rtl/bombjack_top.vhd:1 -----------------------------------------------------------------[07.09.2015] MAME Bomb Jack implementation in FPGA rtl/ym2149/YM2149_linmix.vhd:47 Clues from MAME sound driver and Kazuhiro TSUJIKAWA
BoogieWings# The Great Ragtime Show MiSTer-devel/Arcade-BoogieWings_MiSTer @ 84085e3d MAME compared: dataeast/boogwing.cpp + 12 related file(s) Read: 20 HDL files, 18,347 lines (Quartus project)	MiSTer official	Mostly MAME	medium	44%
Statements: 180 toward MAME Cites MAME source — 164 Template.sv:253 w-mode: posizione 1°/2° blocco come MAME Template.sv:255 w-mode: code nell'ordine MAME Template.sv:256 0 = MAME -16 Template.sv:446 --- BoogieWings INPUT mapping (MAME boogwing.cpp:561-633 INPUT_PORTS_START) --- MiSTer joy bit layout (MiSTer convention): [0]=Right, [1]=Left, [2]=Down, [3]=Up [4]=A (FIRE/BTN1), [5]=B (BOMB/BTN2), [6]=X (SPECIAL/BTN3) [10]=Start, [11]=Coi Template.sv:452 INPUTS port (MAME "INPUTS", 16-bit, tutto active LOW): Template.sv:475 SYSTEM port (MAME "SYSTEM", 16-bit): bit 0: COIN1 (active LOW) bit 1: COIN2 (active LOW) bit 2: SERVICE1 (active LOW) bit 3: VBLANK (active HIGH — da screen device) bit 4..15: unused (idle HIGH) Template.sv:483 bit 3 VBLANK (active HIGH MAME → 1 quando in vblank) Template.sv:946 OSD audio gain decoder: 4 bit → gain 4.4 fixed point 0=Default 1=Mute 2=MAME 3=25% 4=50% 5=75% 6=100% 7=125% 8=150% 9=200% 10=250% 11=300% 12=400% 13=500% 14=700% 15=1000% % indicato è scaling rispetto al Default (= valore base per ogni chi Template.sv:971 Default HW-tested (= valori RTL applicati con foto utente OSD 200%/300%/400%): FM=0x08 (0.5), OKI0=0xFF (15.94, =sat max), OKI1=0x80 (8.0) MAME esatti: FM=0x05 (0.32), OKI0=0x09 (0.56), OKI1=0x02 (0.12) Template.sv:992 OSD sel passati direttamente al chip audio (Default/MAME hardcoded dentro). Template.sv:1169 BoogieWings video timing: 320×240 60Hz (boogwing.cpp:731: htot=442, hact=320, vtot=274, vact=240) Pixel clock: 96/14 = 6.857 MHz (divisore intero). rtl/boogwings/boogwings_audio.sv:5 MAME boogwing.cpp: - HuC6280A (audio CPU) @ SOUND_XTAL/4 ≈ 8.055 MHz - YM2151 @ SOUND_XTAL/9 ≈ 3.580 MHz - OKI M6295 #0 @ SOUND_XTAL/32 ≈ 1.007 MHz (PIN7_HIGH) - OKI M6295 #1 @ SOUND_XTAL/16 ≈ 2.014 MHz (PIN7_HIGH) rtl/boogwings/boogwings_audio.sv:11 Memory map H6280 (audio_map boogwing.cpp:547): 0x000000-0x00FFFF: ROM (64 KB, audiocpu.bin) 0x100000-0x100001: NOP (read/write) 0x110000-0x110001: YM2151 r/w 0x120000-0x120001: OKI #0 r/w 0x130000-0x130001: OKI #1 r/w 0x140000: sou rtl/boogwings/boogwings_audio.sv:83 OSD audio sel (4 bit each: 0=Default, 1=Mute, 2=MAME, 3-15 = percentual scale) rtl/boogwings/boogwings_audio.sv:107 Default = bilanciamento del mix di MAME, misurato sull'attract: le scritture ai chip registrate in MAME suonate sui chip del core (banco AudioTrack_Compare), e i tre guadagni adattati perche' il mix coincida con l'uscita di MAME banda per b rtl/boogwings/boogwings_audio.sv:364 Bank switch OKI: MAME port_write_handler riceve {CT2, CT1} (= bit 7:6 del dato scritto al YM2151 register 0x1B). rtl/boogwings/boogwings_audio.sv:365 MAME boogwing.cpp:694-695: oki[1].bank = (data & 2) >> 1 = CT2 bit oki[0].bank = data & 1 = CT1 bit Quindi devo prendere data[7:6] = {CT2,CT1} e mapparli ai bank. rtl/boogwings/boogwings_audio.sv:448 MAME oki bank: 0x40000 (256 KB) finestra dentro 512 KB ROM. rtl/boogwings/boogwings_audio.sv:461 MAME oki bank: 0x40000 (256 KB) finestra dentro 512 KB ROM. rtl/boogwings/boogwings_audio.sv:751 soundlatch IRQ (MAME IRQ0 → H6280 IRQ1) rtl/boogwings/boogwings_audio.sv:752 YM2151 timer IRQ → H6280 IRQ2 (MAME IRQ2) rtl/boogwings/boogwings_audio.sv:780 MAME pesi BoogieWings: ym=0.32, oki0=0.56, oki1=0.12. rtl/boogwings/boogwings_audio.sv:780 In 4.4 fixed: ym = 0.32 × 16 = 5.12 → 0x05 oki0 = 0.56 × 16 = 8.96 → 0x09 oki1 = 0.12 × 16 = 1.92 → 0x02 MA jtcps1 amplifica più di MAME float-equivalent perché jt6295 14-bit ≠ MAME peak. rtl/boogwings/boogwings_audio.sv:851 Correzione verso MAME (low-shelf 498 Hz +1.8 dB, peaking 5773 Hz -3.0 dB) a 192 kHz, ricavata da registrazioni allineate MAME/core dell'attract. rtl/boogwings/boogwings_top.sv:5 Hardware MAME (boogwing.cpp): rtl/boogwings/boogwings_top.sv:14 Memory map main (boogwing.cpp:504): 0x000000-0x0FFFFF ROM (1MB, encrypted) 0x200000-0x20FFFF work RAM (64KB) 0x220000 priority_w 0x240000/0x244000 spriteram DMA trigger 0x242000/0x246000 spriteram1/2 (2KB ciascuno) 0x24E000-0x rtl/boogwings/boogwings_top.sv:29 Memory map audio H6280 (boogwing.cpp:547): 0x000000-0x00FFFF ROM (64KB) 0x110000 YM2151 r/w 0x120000 OKI1 r/w 0x130000 OKI2 r/w 0x140000 sound latch read 0x1F0000-0x1F1FFF work RAM (8KB) rtl/boogwings/boogwings_top.sv:54 Inputs MAME-mapping BoogieWings (vedi docs/99_discovery_log.md): inputs_port = INPUTS (16-bit, P1+P2 joy+button+start, active LOW) system_port = SYSTEM (16-bit, coin+service+vblank, active LOW eccetto vblank) rtl/boogwings/boogwings_top.sv:137 OSD audio sel (4 bit each) — Default/MAME hardcoded dentro boogwings_audio rtl/boogwings/boogwings_top.sv:224 MAIN CPU M68000 @ 14 MHz (target, MAME = 28MHz/2) Pattern: jtframe_68kdtack_cen genera cpu_cen/cpu_cenb con cycle recovery quando bus è busy (es. rtl/boogwings/boogwings_top.sv:229 Clock divider: clk_sys 96 MHz × 7/48 = 14.000 MHz esatti MAME M68K main = 28 MHz / 2 = 14.000 MHz (boogwing.cpp:715,719) Prima era 1/7 ≈ 13.71 MHz = -2% troppo lento rtl/boogwings/boogwings_top.sv:254 Noprw range MAME (boogwing.cpp:510, 534, 535) — devono produrre DTACK ma scrittura/lettura senza effetti (read=FFFF, write=ignorata). rtl/boogwings/boogwings_top.sv:368 MAME: irq6_line_hold = mantieni IRQ6 alto, MAME lo abbassa quando CPU fa IACK. rtl/boogwings/boogwings_top.sv:416 DE102 decryption (DECO102 chip) — selettore via `BYPASS_DECRYPT` address scramble: i_logical → i_physical (ROM offset) data decrypt: din × addr × select_xor → plain Parametri boogwing.cpp:1027: address_xor=0x42BA, data_select_xor=0x00, rtl/boogwings/boogwings_top.sv:450 MAIN address decoder (boogwing.cpp:504) rtl/boogwings/boogwings_top.sv:465 MAME: 0x242000-0x2427FF (2 KB = 0x800 byte). rtl/boogwings/boogwings_top.sv:484 Noprw ranges (MAME boogwing.cpp:510, 534, 535): 0x220002-0x22FFFF : after priority_w 0x280000-0x28000F : palette setup (eccetto 0x282008 = paldma) 0x282000-0x282001 : palette setup rtl/boogwings/boogwings_top.sv:604 MAME boogwing.cpp:529-530: chip1 pf1/pf2 mappati con `.ram().w(deco16ic)`. rtl/boogwings/boogwings_top.sv:893 chip0 ctrl[0] bit 7 (MAME boogwing.cpp:419) rtl/boogwings/boogwings_top.sv:894 Render x/y flippati quando flip_screen=1 (MAME flip_screen_set). rtl/boogwings/boogwings_top.sv:896 Schermo BoogieWings: hcnt 0..441 attivo 0..319 → x flip = 319-x. Template.sv: render_x=hcnt (= x di MAME), render_y=vcnt+1 (tutta l'immagine alzata di 1 px). rtl/boogwings/boogwings_top.sv:898 In MAME l'asse dello specchio verticale e' 255; nello spazio alzato di 1 diventa 255+21 = 257, non 255. rtl/boogwings/boogwings_top.sv:899 Misurato: col flip gli sprite, che dentro usano le costanti di MAME (240-y, 304-x), cadono esattamente sull'asse 257 (banco NsSprites_Flip_Bench, 0 differenze su 76160 confronti). rtl/boogwings/boogwings_top.sv:923 BoogieWings bank callbacks (boogwing.cpp:749, 761): tilegen[0]: bank1=none, bank2=bank_callback (mode 1) tilegen[1]: bank1=bank_callback2, bank2=bank_callback2 (mode 2) GFX base address SDRAM (tile_byte_addr relativo a TILE_BASE): tiles1 (t rtl/boogwings/boogwings_top.sv:1075 Buffer side (DMA write dest + renderer read source) — buffered_spriteram MAME-style rtl/boogwings/boogwings_top.sv:1168 MAME buffered_spriteram16: copy LIVE -> BUFFER a VBlank rise (bufsprite.h). rtl/boogwings/boogwings_top.sv:1234 CPU readback NON serve (write-only dal punto di vista di MAME boogwing: il chip è palette device, leggere è debug). rtl/boogwings/boogwings_top.sv:1240 Palette DECO_ACE 24-bit RGB888 (MAME deco_ace.cpp): m_paletteram[2048] è uint32: bits 23:16 = B byte, 15:8 = G byte, 7:0 = R byte. rtl/boogwings/boogwings_top.sv:1433 Palette index base (boogwing.cpp:gfx_boogwing entries): tiles1 (text 8×8) = palette base 0x800 tiles2 (deco16_0) = palette base 0x100 tiles3 (deco16_1) = palette base 0x300 rtl/boogwings/boogwings_top.sv:1446 Palette index per layer (MAME gfx_boogwing boogwing.cpp:671): tiles1 (text) → base 0x800, 16 set × 16 col (4bpp) tiles2 (BG1) → base 0x100, 16 set × 32 col (5bpp → ora 4bpp, upper half vuota finché plane 4 non impl) tiles3 (BG2) → base rtl/boogwings/boogwings_top.sv:1462 La logica MAME ha 5 modi diversi via priority_reg[2:0] (vedi screen_update); per ora implemento solo l'ordine default. rtl/boogwings/boogwings_top.sv:1464 (col_bank di chip1 pf2 è già dentro d16_1_pf2_col → non sommato qui) Palette base per layer — MAME GFXDECODE (boogwing.cpp:672-674): tiles1 text = 0x800, tiles2 BG1 = 0x100, tiles3 BG2 = 0x300. rtl/boogwings/boogwings_top.sv:1474 Layer mixer con priority register MAME-compliant (5 modi). rtl/boogwings/boogwings_top.sv:1475 Riferimento: boogwing.cpp:417-477 screen_update. rtl/boogwings/boogwings_top.sv:1509 MAME formula: pal_idx = base + col_5b 16 + pen[3:0]. rtl/boogwings/boogwings_top.sv:1529 Sprite chip0 (sprites1): MAME GFXDECODE 0x500, 32 banks x 16 colors. rtl/boogwings/boogwings_top.sv:1530 MAME mixer: pal_idx = 0x500 + (pix1 & 0x1ff) dove pix1 = {color[7:0], pen[3:0]} → pal_idx = 0x500 + {color[4:0], pen[3:0]} (= 5 bit color = 32 banks) Bug fix: era color[3:0] (= solo 16 banks), ora color[4:0] (= 32 banks MAME-corretto). rtl/boogwings/boogwings_top.sv:1541 Sprite chip1 (sprites2): MAME 0x700, 16 banks x 16 colors. rtl/boogwings/boogwings_top.sv:1549 MAME boogwing.cpp mix() priorità sprite vs sprite dinamica (pixel-by-pixel). rtl/boogwings/boogwings_top.sv:1551 MAME (priority_reg & 0x7) default case → spri1 = 2/8/32, spri2 = 4/16/64. rtl/boogwings/boogwings_top.sv:1552 pri_bits = {color[6], color[5]} = {x_bit15, x_bit14} MAME spri1: 0x600=0b11 → 2 ; 0x400=0b10 → 8 ; else → 32 MAME spri2: 0x600=0b11 → 4 ; (0x400 OR 0x200)=non-zero → 16 ; else → 64 rtl/boogwings/boogwings_top.sv:1558 MAME spri1 (boogwing.cpp:240-262) ha un CASE su priority: case 0x00: (pix1&0x600)==0x600 -> 2 ; ==0x400 -> 8 ; else -> 32 default (priority!=0): (pix1&0x400) -> 8 ; else -> 32 (MAI 2!) Il core usava SEMPRE lo schema 0x00 (2/8/32). rtl/boogwings/boogwings_top.sv:1561 In priority 4 (cutscene pre-boss, il testo e' uno sprite chip0) questo dava spri1=2 quando spr_pri=2'b11, mentre MAME da' spri1=8. rtl/boogwings/boogwings_top.sv:1564 Fix: rispettare il case priority come MAME. rtl/boogwings/boogwings_top.sv:1574 MAME default: (pix1 & 0x400) ? rtl/boogwings/boogwings_top.sv:1583 chip1 sopra chip0 se spri2 > spri1 (MAME default). rtl/boogwings/boogwings_top.sv:1590 MAME invece calcola spri1 = 32 (perche' p1 in {0,1} finisce nel ramo else) e spri2 = 16 (perche' p2 = 1 entra in "else if (pix2 & 0x600)"): con bit9 = 1 su entrambi la condizione spri2 > spri1 e' falsa e il pixel del chip 1 viene buttato vi rtl/boogwings/boogwings_top.sv:1599 === MAME priority bitmap (bg_pri) per sprite vs playfield === MAME boogwing.cpp:437-471: dopo screen.priority().fill(0), ogni tilemap_draw passa un priority_value che viene scritto nella priority bitmap per i pixel opachi disegnati. rtl/boogwings/boogwings_top.sv:1604 MAME draw sequence (pri_reg & 0x7): case 0x5: PF2[0] OPAQUE=0, combine[1] pri=32 case 0x4: combine[1] OPAQUE=0, PF2[0] pri=32 case 0x1/0x2: PF2[1] OPAQUE=0, PF2[0] pri=8, PF1[1] pri=32 case 0x3: PF2[1] OPAQUE=0, PF2[0] pri=8, PF1[1] alpha ( rtl/boogwings/boogwings_top.sv:1649 pri1 = sprite chip0 priority vs playfield (MAME boogwing.cpp:264-295) pri2 = sprite chip1 priority vs playfield (MAME boogwing.cpp:316-338) IMPORTANTE: MAME checks tipo "(pix & 0x400) == 0x400" testano SOLO il bit 10 (= spr_pri[1]), NON l'e rtl/boogwings/boogwings_top.sv:1677 Sprite-vs-playfield: visible solo se pri > bg_pri (MAME mix() linee 359/371) rtl/boogwings/boogwings_top.sv:1681 drawnpixe1 flags MAME (mix() line 357-387): pixel sprite EFFETTIVAMENTE disegnato rtl/boogwings/boogwings_top.sv:1686 MODE 3 shadow apply (MAME line 396-411): pri3 = 32. rtl/boogwings/boogwings_top.sv:1704 MAME mix() linea 369: dstline[x] = paldata[tmappix] (= ultimo tilemap drawn). rtl/boogwings/boogwings_top.sv:1706 BACKDROP: dove tutti i layer sono trasparenti, MAME mostra pen 0x400 (boogwing.cpp:435 bitmap.fill(pen(0x400))), NON pen 0 (nero). rtl/boogwings/boogwings_top.sv:1743 === Sprite chip1 alpha-blend (MAME boogwing.cpp:305-314) === pix2 = (colour << 4) \| pen → mapping al mio sistema: pix2[3:0] = spr2_pen[3:0] pix2[7:4] = spr2_color[3:0] (= 4 bit colour LSB visibili nel pal_idx) rtl/boogwings/boogwings_top.sv:1752 MAME alpha2 logic: default: alpha2 = get_alpha((pix2 >> 4) & 0xf) = get_alpha(spr2_color[3:0]) if pix2[8]: if pix2[11]: alpha2 = (pix2&8) ? rtl/boogwings/boogwings_top.sv:1759 MAME get_alpha(N): regval = ace_regs[N][7:0]; if regval > 0x20: return 0x80 (special) else: return clamp_unsigned(255 - (regval << 3)) rtl/boogwings/boogwings_top.sv:1788 PROVATO A TOGLIERLA E RIMESSA (2026-09-23): boogwing.cpp:309 dichiara opaco il pixel col bit 3 del pen acceso senza leggere la LUT dell'ACE. rtl/boogwings/boogwings_top.sv:1790 Sembrava una semplificazione dell'emulatore da scavalcare, ma il confronto a schermo con MAME dice il contrario: senza, le esplosioni diventano brunastre e trasparenti dove in MAME sono piene e brillanti. rtl/boogwings/boogwings_top.sv:1815 DECO_ACE alpha-blend (MAME deco_ace.cpp + boogwing.cpp mix()): Quando priority_reg[2:0]==3 e FG0 (chip1.pf1) ha pen != 0 → blend FG0 con strato sotto (di solito BG1 o FG1). rtl/boogwings/boogwings_top.sv:1834 Text TOP sempre (drawn dopo mix sprite in MAME). rtl/boogwings/boogwings_top.sv:1837 Sprite priority DINAMICA pixel-by-pixel (MAME mix() spri1 vs spri2 + pri vs bg). rtl/boogwings/boogwings_top.sv:1886 MAME: bg2_drawed = (bgpri==8) → BG1 disegnato + ombra cade su BG1. rtl/boogwings/boogwings_top.sv:1923 === DECO_ACE FADE (deco_ace.cpp:165-199) — ESATTO, identico a MAME bit-per-bit. rtl/boogwings/boogwings_top.sv:1939 Palette RAW vs FADED (deco_ace.cpp:175-198): la palette deco_ace ha 4096 pen: 0x000-0x7FF = palette CON fade (set_pen_color(i)). rtl/boogwings/boogwings_top.sv:1942 MAME indicizza con paldata[pal_idx]: se pal_idx >= 0x800 -> RAW (no fade). rtl/boogwings/boogwings_top.sv:1943 Gli sprite/BG (base <0x800) vanno raw solo col calculated_coloffs (priority bit3 -> +0x800, boogwing.cpp:355). rtl/boogwings/boogwings_top.sv:1946 Il bit 11 dell'indice (0x800) marca "raw" = bypass del fade, PER-PIXEL su top e bot separati (come MAME: l'offset 0x800 e' per-sorgente, NON globale). rtl/boogwings/boogwings_top.sv:1952 Alpha factor — MAME deco_ace.cpp get_alpha(): alpha = m_ace_ram[val] & 0xff; if (alpha > 0x20) return 0x80; // special blending command else alpha = 255 - (alpha << 3); clamp 0; Boogwing usa val=0x1f per tilemap alpha (chip1.pf1). rtl/boogwings/boogwings_top.sv:1985 Formule MAME invariate, bit per bit: fade mult (0x1100): c = clamp(0,255, c + ((fadept - c) * fadeps) / 255) /255 esatto = (\|prod\| * 32897) >> 23, quoziente troncato verso zero fade add (0x1000): c = min(c + fadeps, 255) alpha_blend_r32: ( rtl/boogwings/boogwings_top.sv:1992 Mapping: dst = bot_color (BG1), src = top_color (FG0 ombra) - MAME line 408. rtl/boogwings/boogwings_top.sv:2339 sprite_romaddr e' in spazio MAME (= source 4MB). rtl/boogwings/boogwings_top.sv:2459 Sprite download interleave: layout MAME tile_16x16_layout richiede plane 0,1 da LO region, plane 2,3 da HI region. rtl/boogwings/boogwings_top.sv:3009 Coordinate GREZZE: il flip degli sprite lo fa bw_sprites (flipscreen_spr = ~flip_screen -> x=304-x, y=240-y, mult=-16), nello stesso spazio della bitmap MAME. rtl/boogwings/boogwings_top.sv:3060 Coordinate GREZZE: il flip degli sprite lo fa bw_sprites (flipscreen_spr = ~flip_screen -> x=304-x, y=240-y, mult=-16), nello stesso spazio della bitmap MAME. rtl/boogwings/bw_sprites.sv:11 MAME equivalente: m_sprite_bitmap full-frame 320×256 + draw_sprites_common. rtl/boogwings/bw_sprites.sv:25 Output identico al MAME m_sprite_bitmap se scan ordinata correttamente. rtl/boogwings/bw_sprites.sv:28 MAME standard format (offs +0/+1/+2): +0: efFbSssyyyyyyyyy e=priority, f=flipy, F=flipx, b=flash, S=w, ss=h +1: tttttttttttttttt tile code +2: ppcccccxxxxxxxxx pp=priority, ccccc=color (5b), x=xpos rtl/boogwings/bw_sprites.sv:112 flipscreen sprite — MAME boogwing.cpp:424 set_flip_screen(!BIT(flip,7)) → SEMPRE invertito rispetto a flip_screen input (= tilemap flip). rtl/boogwings/bw_sprites.sv:135 Frame parity per il FLASH sprite (MAME decospr.cpp:227: flag y_word[12], lo sprite e' nascosto sui frame DISPARI -> if(!(flash && (frame_number & 1))) draw). rtl/boogwings/bw_sprites.sv:146 ~pause_in: in pausa il vblank continua (display vivo) ma la parita' frame resta ferma -> il FLASH si congela come su PCB/MAME (niente flicker in pausa). rtl/boogwings/bw_sprites.sv:317 MAME decospr.cpp:267-282 + 297-314 — formula completa boogwing con flipscreen=ON: rtl/boogwings/bw_sprites.sv:326 MAME boogwing.cpp:424 set_flip_screen(!BIT(flip,7)) → default ON (flip[7]=0). rtl/boogwings/bw_sprites.sv:338 Solo "sign-ext" con soglia 320 (MAME decospr.cpp:267-269): x = x & 0x1ff; (9-bit 0..511) if (x >= 320) x -= 512; (0..319 unsigned, 320..511 → -192..-1) Risultato: signed -192..319 (10-bit signed sufficiente). rtl/boogwings/bw_sprites.sv:444 Col flip MAME mette il blocco a 240-sy e i blocchi successivi vanno verso l'alto (mult=-16), quindi la cima e' 240 - sy - 16multi = 256 - sy - height: simmetrica, non 0. rtl/boogwings/bw_sprites.sv:548 fx_eff = flipx ^ flipscreen_spr (MAME riga 306-313: flipscreen invertito m_flipallx=0) NB: fx_eff (dai reg FSM) serve SOLO all'address-gen (half_use in S_ROM_REQ); la catena pen del DRAW usa lo snapshot d_flipx/d_pix (il draw gira in parall rtl/boogwings/bw_sprites.sv:574 MAME planeoffset = {hi+8, hi+0, lo+8, lo+0} → plane 0 = byte 3 (mbd-05 alto), plane 1 = byte 2, plane 2 = byte 1, plane 3 = byte 0 (mbd-06 basso). rtl/boogwings/bw_sprites.sv:587 MAME order: pen={p4,planes1..4}. rtl/boogwings/bw_sprites.sv:746 Se OFF, doppia inversione MAME (240-y, 304-x). rtl/boogwings/bw_sprites.sv:776 MAME decospr.cpp:297-304: flipscreen OFF: mult = -16, tile cresce verso l'alto da sy → bounding box [sy - 16multi, sy + 16) → dy_top = scan_y - (sy - 16multi) = (scan_y - sy) + 16multi flipscreen ON: mult = +16, tile cresce verso il bas rtl/boogwings/bw_sprites.sv:814 MAME: non-intersecante = nulla. rtl/boogwings/bw_sprites.sv:841 FIX flipx half-swap: quando fx_eff=1 (sprite specchiato), MAME inverte anche l'ordine dei 2 half del tile (oltre al flip pixel-in-byte già fatto da bit_x). rtl/boogwings/bw_sprites.sv:908 FIX BUG #2: MAME decospr.cpp:351 → 2° blocco a (x+16) per flipscreen_spr=1, (x-16) per flipscreen_spr=0. rtl/boogwings/deco16ic.sv:5 Riferimento C++: reference/mame/deco16ic.cpp (Bryan McPhail / David Haywood) Riferimento BoogieWings: reference/mame/boogwing.cpp rtl/boogwings/deco16ic.sv:30 Bank callback mode (boogwing.cpp:699-711): 0 = identity (no callback, bank=0) 1 = boogwing bank_callback: offset = ((bank >> 4) & 7) << 12 2 = boogwing bank_callback2: offset = bank_callback + (bank & 0xF == 0xA ? rtl/boogwings/deco16ic.sv:39 Colour bank + mask (MAME boogwing.cpp:744-760): output_colour = (raw_colour & COL_MASK) + COL_BANK BoogieWings: chip 0 pf1/pf2: COL_BANK=0, COL_MASK=0x0F chip 1 pf1 : COL_BANK=0, COL_MASK=0x0F chip 1 pf2 : COL_BANK=16, COL_MASK=0x0F rtl/boogwings/deco16ic.sv:146 Control registers (8 word @ 0x00-0x0F) Layout (deco16ic.cpp:94-134): [0] bit 7 = flip screen, bit 6:0 = ? rtl/boogwings/deco16ic.sv:149 [1] = pf2 scroll X [2] = pf2 scroll Y [3] = pf1 scroll X [4] = pf1 scroll Y [5] = enables + rowscroll/colscroll style [6] = mode bits (8x8 vs 16x16, rowscroll en, colscroll en, flip behavior) [7] = bank hi: [15:8] = pf1 gfx bank, [7:0] = pf rtl/boogwings/deco16ic.sv:176 Bank callback (deco16ic.cpp:903-931) bank1_cb input = pf12_control[7] & 0xff (byte basso) bank2_cb input = pf12_control[7] >> 8 (byte alto) Output = m_pf1_bank / m_pf2_bank, sommato a tile_code in rendering rtl/boogwings/deco16ic.sv:181 BoogieWings (boogwing.cpp:699-711): bank_callback: offset = ((bank >> 4) & 7) * 0x1000 → max 0x7000 bank_callback2: bank_callback + ((bank & 0xF) == 0xA ? rtl/boogwings/deco16ic.sv:208 VRAM CPU readback ritorna 0 (MAME raramente rilegge VRAM tile; sopprimere il read port libera la 2a porta del M10K). rtl/boogwings/deco16ic.sv:233 VRAM layout 64x32 (deco16ic.cpp:291): tile_index = (col & 0x1F) + ((row & 0x1F) << 5) + ((col & 0x20) << 5) + ((row & 0x20) << 6) Cioè blocchi 32x32 disposti in 2x1 (col[5] e row[5] selezionano blocco). rtl/boogwings/deco16ic.sv:238 Layout 16x16 4bpp (boogwing.cpp tile_16x16_layout): 32 byte per riga (16 px × 2 byte plane = 32 byte = 8 word ROM) No, ricalcolo: 16x16 4bpp = 16164 / 8 = 128 byte per tile = 32 word 32-bit (4 byte) In gfx_layout: plane_offset = { 1/2+8, rtl/boogwings/deco16ic.sv:282 VRAM swizzle layout DECO_64x32 (deco16ic.cpp:291) tile_index = (col & 0x1F) + ((row & 0x1F) << 5) + ((col & 0x20) << 5) + ((row & 0x20) << 6) Per 64×32: row 5-bit (max 0x1F), col 6-bit (max 0x3F) → bit [11] = row[5] (= 0 sempre per 32 ro rtl/boogwings/deco16ic.sv:297 Tile decode (deco16ic.cpp:294-352, pf1 usa control[6] byte basso) rtl/boogwings/deco16ic.sv:317 ROM addressing 16x16 4bpp PLANAR (MAME gfx tile_16x16_layout): Per metà-riga (8 pixel) servono 2 fetch 16-bit del bridge: fetch 1: planeLo region → word con plane0+plane1 (8 pixel × 2 plane) fetch 2: planeHi region → word con plane2+plane3 rtl/boogwings/deco16ic.sv:337 formula MAME: 16x16 4bpp planar 2 region: tile=64 byte/region * 2 region = 128 byte Region = 64 byte/tile (2 plane * 16x16 / 8 = 64 byte). rtl/boogwings/deco16ic.sv:346 16x16: byte_per_region = tile_code64 + xhalf32 + 2y → {tile_code, xhalf, pix_y[3:0], 1'b0} 8x8 : byte_per_region = tile_code16 + 2y → {tile_code, pix_y[2:0], 1'b0} MAME tile_16x16_layout x_offsets: STEP8(1682,1) per pixel 0. rtl/boogwings/deco16ic.sv:380 rom_data 32-bit PLANAR (MAME gfx tile_16x16_layout): tile_data[15:0] = plane_lo_word = {plane1_byte, plane0_byte} (8 pixel × 2 plane) tile_data[31:16] = plane_hi_word = {plane3_byte, plane2_byte} pixel i (0..7) bit_pos = 7 - i (MSB first) rtl/boogwings/deco16ic.sv:392 MAME convention: pixel 0 (leftmost) = MSB del byte plane (bit 7), pixel 7 (rightmost) = LSB (bit 0). rtl/boogwings/deco16ic.sv:405 MAME: output_colour = (raw & col_mask) + col_bank rtl/boogwings/deco16ic_jt.sv:77 Flip screen globale (MAME boogwing.cpp:419-425: pf_control_r(0) bit 7). rtl/boogwings/deco16ic_jt.sv:78 Sponta solo da chip 0 (chip1 ha il suo ma MAME usa solo chip0). rtl/boogwings/deco16ic_jt.sv:117 Combine 8bpp (MAME tilemap_12_combine_draw, priority 4/5): pf1 e pf2 sono lo STESSO pixel (nibble basso/alto). rtl/boogwings/deco16ic_jt.sv:277 Flip screen globale (MAME boogwing.cpp:419-425): flip = m_deco_tilegen[0]->pf_control_r(0); flip_screen = BIT(flip,7); rtl/boogwings/deco16ic_jt.sv:281 MAME deco16ic.cpp:899-900 (codice, NON il commento header che è invertito): PF1 scroll = ctrl[1] (X), ctrl[2] (Y) PF2 scroll = ctrl[3] (X), ctrl[4] (Y) rtl/boogwings/deco16ic_jt.sv:289 Rowscroll enable + style (MAME deco16ic.cpp header riga 94-130) pf12_control[5] (word 0xa): bit 15 = pf1 enable bit 14:11 = pf1 rowscroll style bit 10:8 = pf1 colscroll style bit 7 = pf2 enable bit 6:3 = pf2 rowscroll style bit 2: rtl/boogwings/deco16ic_jt.sv:306 dissolvenza logo Data East) MAME passa al renderer custom (:847-850) che applica bit6 e bit5 INDIPENDENTI, insieme. rtl/boogwings/deco16ic_jt.sv:311 MAME riga 761: (control0 >> 3) & 0xf -> bit 6:3 per pf1 row style. rtl/boogwings/deco16ic_jt.sv:318 COLSCROLL Y-per-column (MAME deco16ic.cpp:492-497, 812): col_type = 8 << (control0 & 7) ∈ {8,16,32,64,128,256,512,1024} col_idx = (src_x & 0x1ff) / col_type col_offset = rowscroll_ptr[0x200 + col_idx] // 16-bit Y offset veff_eff = veff + rtl/boogwings/deco16ic_jt.sv:334 PLAYFIELD DISABLE (MAME deco16ic.cpp:465: if(!BIT(control0,7)) return;). rtl/boogwings/deco16ic_jt.sv:356 MAME riga 482: src_x = scrollx + rowscroll_ptr[src_y / row_type] rows = total scanlines / row_type. rtl/boogwings/deco16ic_jt.sv:377 Per text 8x8 MAME dimezza numrows (riga 798); equivalente a >> 1 sull'idx. rtl/boogwings/deco16ic_jt.sv:389 16x16: veff MASCHERATO a [8:0] (= & height_mask 511, MAME deco16ic.cpp:477/:534) PRIMA dello shift. rtl/boogwings/deco16ic_jt.sv:405 FIX colonne durante scroll (MAME deco16ic.cpp:493 col_idx da src_x = pixel REALE): src_x deve azzerare il sub-tile offset scroll_x[3:0] (16x16) o [2:0] (8x8). rtl/boogwings/deco16ic_jt.sv:568 VRAM swizzle hardcoded: 8x8 (text) = Linear idx = {row[4:0], col[5:0]} 16x16 (BG) = DECO_64x32 idx = {col[5], row[4:0], col[4:0]} MAME deco16ic.cpp:245 — TILEMAP_SCAN_ROWS per 8x8, deco16_scan_rows per 16x16. rtl/boogwings/deco16ic_jt.sv:596 Flip per-tile (MAME deco16ic.cpp:330-341 get_pf1_tile_info): if (vram[15] && ctrl[6][0]) → FLIPX, colour &= 7 if (vram[15] && ctrl[6][1]) → FLIPY, colour &= 7 Per pf2 (16x16): ctrl[6][8] e ctrl[6][9]. rtl/boogwings/deco16ic_jt.sv:644 Sub-tile X offset: scan parte da tile-aligned, buf_waddr inizia negativo (wrap 9-bit) per scartare i primi N pixel del primo tile (= MAME src_x = scroll_x + render_x). rtl/boogwings/deco16ic_jt.sv:692 MAME: colour = tile[15:12], if tile[15] && flipctrl colour &= 7 rtl/boogwings/deco16ic_jt.sv:912 Colscroll attivo: veff_eff = render_y + scroll + cs (MAME esatto). rtl/boogwings/deco16ic_jt.sv:914 Il -1 vale SOLO per colscroll-ONLY (0x20 = path tilemap STANDARD MAME, dove e' stato tarato e validato: camini, commit 36a9671 — NON TOCCARE quel caso). rtl/boogwings/deco16ic_jt.sv:915 Con row+col SIMULTANEI (0x60 = path custom MAME, dissolvenza logo Data East) MAME fa y=src_y+coloff SENZA -1: applicarlo li' spostava il layer di 1 riga rispetto allo stato statico -> SALTO del logo alla fine dell'effetto (riprodotto in SIM rtl/boogwings/deco16ic_jt.sv:938 Flip per-tile pf2 (MAME deco16ic.cpp:300-311): ctrl[6][8] = FLIPX, ctrl[6][9] = FLIPY (per pf2) rtl/boogwings/deco16ic_jt.sv:981 Sub-tile X offset: waddr inizia negativo (= 9-bit wrap) per scartare primi N pixel del primo tile = MAME src_x pixel-by-pixel. rtl/boogwings/deco16ic_jt.sv:1048 Bit position MAME-natural: sc2_pen_p4 = p4_byte[bit_pos]. rtl/boogwings/mix_eq.sv:3 mix_eq — correzione del mix audio verso MAME, 4 biquad in cascata per canale a 192 kHz: S0 low-shelf 461 Hz +1.80 dB S1 peaking 1525 Hz -0.72 dB Q 6.00 S2 peaking 6107 Hz -3.33 dB Q 1.39 S3 high-shelf 6019 Hz +1.26 dB rtl/boogwings/mix_eq.sv:9 I parametri vengono da due registrazioni allineate dello stesso attract, MAME e core (MiSTer_Utility/AudioTrack_Compare: match_eq4.py, adattamento pesato sull'incertezza di misura); coefficienti e modello intero bit-esatto da eq_rtl_gen.py. rtl/boogwings/mix_eq.sv:11 Dopo la correzione nessuna banda (50 Hz - 12.5 kHz) resta fuori dall'incertezza e l'rms coincide con MAME entro 0.07 dB. README.md:12 This core reimplements the hardware in SystemVerilog from MAME references and hardware observation. README.md:55 Documentation: the board's priority PROM (`kj-00.15n`, the one MAME loads and marks "not used") is decoded in [docs/](docs/) — input mapping proved with z README.md:64 DECO104 protection (I/O + data scramble) reproduced from MAME README.md:65 MAME-accurate DECO16IC tilemaps (per-row / per-column scroll) and the DECO ACE alpha-blend + fade mixer, including the simultaneous row+column scroll used by th README.md:84 Two DECO16IC tilemap chips: BG0/BG1 (chip 0) + FG0/FG1 (chip 1), 16×16 and 8×8 tiles, per-row and per-column scroll — MAME-accurate Says it was translated, ported or taken from MAME — 7 rtl/boogwings/deco16ic_jt.sv:143 State allargato a 5 bit per supportare colscroll lookup per-half (MAME 1:1). rtl/boogwings/deco16ic_jt.sv:402 COLSCROLL idx (per-half lookup, MAME 1:1 per pixel collassato a per-half perché cs_off è costante nei 8 px consecutivi per col_type≥8). rtl/boogwings/deco16ic_jt.sv:500 MAME 1:1: colscroll lookup PER PIXEL (in pratica per HALF di 8 px quando col_type≥8). rtl/boogwings/deco16ic_jt.sv:560 MAME 1:1. rtl/boogwings/deco16ic_jt.sv:742 MAME 1:1 per-pixel collapsed per HALF perché cs_off è costante negli 8 px consecutivi con col_type≥8. rtl/boogwings/deco16ic_jt.sv:906 COLSCROLL Y latched pf2 per-half (MAME 1:1). README.md:47 Audio: 4× OKI interpolation with a flat-band FIR, mix EQ, inter-chip balance taken from MAME, and a 10-bit mixer. Keeps a MAME approximation — 1 Template.sv:955 MAME (placeholder, gestito sotto) Shares text with the MAME driver without saying so — 8 rtl/boogwings/boogwings_top.sv:1689 E poi filtro: ((pix2 & 0x900) != 0x900) \|\| ((spri2 <= spri1) && sprite1_drawed) — shares text with dataeast/boogwing.cpp:403 rtl/boogwings/boogwings_top.sv:1755 if pix2[11]: alpha2 = (pix2&8) ? 0xff : get_alpha(0x14 + ((pix2-1) & 0x7)) — shares text with dataeast/boogwing.cpp:309 rtl/boogwings/boogwings_top.sv:1953 alpha = m_ace_ram[val] & 0xff; — shares text with dataeast/deco_ace.cpp:211 rtl/boogwings/bw_sprites.sv:112 flipscreen sprite — MAME boogwing.cpp:424 set_flip_screen(!BIT(flip,7)) — shares text with dataeast/boogwing.cpp:424 rtl/boogwings/bw_sprites.sv:326 MAME boogwing.cpp:424 set_flip_screen(!BIT(flip,7)) → default ON (flip[7]=0). — shares text with dataeast/boogwing.cpp:424 rtl/boogwings/deco16ic.sv:235 + ((col & 0x20) << 5) + ((row & 0x20) << 6) — shares text with dataeast/deco16ic.cpp:277 rtl/boogwings/deco16ic.sv:244 x_offset = STEP8(168*2,1), STEP8(0,1) → 16 pixel x usando 2 byte — shares text with dataeast/boogwing.cpp:654 rtl/boogwings/deco16ic.sv:283 tile_index = (col & 0x1F) + ((row & 0x1F) << 5) + ((col & 0x20) << 5) + ((row & 0x20) << 6) — shares text with dataeast/deco16ic.cpp:277
Bosconian# Bosconian - Star Destroyer MiSTer-devel/Arcade-Bosconian_MiSTer @ 439b554c MAME compared: namco/bosco.cpp + 14 related file(s) Read: 28 HDL files, 9,261 lines (Quartus project)	MiSTer official	Mostly MAME	low	30%
Statements: 32 toward hardware, 41 toward MAME, 5 not counted Cites hardware documentation that MAME's driver does not — 32 rtl/bosco_video_render.vhd:44 (inverted) outputs from RAM 2E, small-object registers rtl/bosco_video_render.vhd:364 7J: 74LS175 DFF Produces delayed hblank signals. rtl/bosco_video_render.vhd:393 6L: 74LS08 AND 7J 2Q seems to be a slightly "tweaked" version of the hblank_n signal. rtl/bosco_video_render.vhd:456 1J, 1K: 74LS374 DFF playfield_posix and playfield_posiy represent the internal state of registers 1J and 1K; posix and posiy are those registers' outputs, which are pulled up when not in the playfield rtl/bosco_video_render.vhd:470 2K, 2J: 2x 74LS283 4-bit adder, combined to make an 8-bit adder When outside the playfield, since posiy is pulled up to 11111111 and PF_n is the lower carry in, this will just be vcount. rtl/bosco_video_render.vhd:475 3M, 2L: 2x 74LS283 4-bit adder, combined to make a 6-bit adder The playfield flag is used as the low carry input. rtl/bosco_video_render.vhd:485 2N: 74LS244 Line Driver Applies the upper bits of the playfield-adjusted x/y positions to the address bus. rtl/bosco_video_render.vhd:497 2P: 74LS257 MUX rtl/bosco_video_render.vhd:517 6K: 74LS175 DFF with Clear Strangely, on the schematic, PF_n is input at 2D, but there is neither a 2Q nor a /2Q. rtl/bosco_video_render.vhd:533 4C: 74LS243 8-Bit Register with Clear This latches the upper bits of the graphics ROM address (used for fetching both sprite and tile data), along with the flip flags for sprites. rtl/bosco_video_render.vhd:551 5F: 74LS174 DFF with Clear rtl/bosco_video_render.vhd:569 6H, 6F: 74LS157 MUX Always enabled. rtl/bosco_video_render.vhd:668 7F: 74LS08 AND - outpin 8; mislabeled on schematic as outpin 11 Determine if the screen is flipped AND we're not in hblank. rtl/bosco_video_render.vhd:675 6J: 74LS86 XOR - outpin 11 Determine whether the next batch of pixels should be flipped while being shifted out. rtl/bosco_video_render.vhd:680 4L: 74LS377 D-Register with Common Enable and Clock Original has 6MHZ as the clock and /COLSET as the enable rtl/bosco_video_render.vhd:696 6D, 6C: 74LS194 Bidirectional Universal Shift Register Original hardware clocked by 6MHZ. rtl/bosco_video_render.vhd:721 7C: 74LS157 MUX Always enabled; selector is output 5Q from 4L NOTE: The schematic here appears to have some errors; if implemented exactly as diagrammed, the pixel shifter doesn't work properly. rtl/bosco_video_render.vhd:785 3H, 3K: 74LS283 4-bit adders, paired to make an 8-bit adder. rtl/bosco_video_render.vhd:787 3J: 74LS20 4-input NAND, outpin 6 rtl/bosco_video_render.vhd:792 3J: 74LS20 4-input NAND, outpin 8 rtl/bosco_video_render.vhd:795 6J: 74LS86 XOR (but one operand is P, so this is functionally an inverter) rtl/bosco_video_render.vhd:798 5H: 74LS174 DFF with Clear Original hardware clocked by /VPSET. rtl/bosco_video_render.vhd:816 3D, 3E: 74LS163 Binary Counters, Fully Synchronous Note: On the 74LS163, the reset is also synchronous. rtl/bosco_video_render.vhd:836 3N: 74LS20 dual 4-input NAND rtl/bosco_video_render.vhd:843 7F: 74LS08 AND, outpin 3 rtl/bosco_video_render.vhd:845 4B: 74LS365 Buffer Original hardware enables (active low) are 6MHZ and /HBLANK. rtl/bosco_video_render.vhd:879 2C, 3F, 3C: 74LS163 Binary Counters, Fully Synchronous Note: On the 74LS163, the reset is also synchronous. rtl/bosco_video_render.vhd:898 1D: 74LS377 D-Register with Common Enable and Clock Original hardware: 6MHZ clock, LD_n as active-low enable Sets up the address for reading the Small Object ROM. rtl/bosco_video_render.vhd:950 4B: 74LS365 Hex Buffer - Just used as a simple buffer, so not implemented. rtl/bosco_video_render.vhd:951 74LS365 has output enables, but they're not used according to the schematic. rtl/bosco_video_render.vhd:953 7F: 74LS08 AND, outpin6 rtl/bosco_video_render.vhd:991 7D: 74LS174 DFF with Clear The clock for this flip-flop is /6MHZ. Cites hardware references or measurements that MAME's driver also gives — 5 rtl/bosco_video_render.vhd:106 PROM 2R timing signals — also in MAME: 2R namco/bosco.cpp:862 rtl/bosco_video_render.vhd:110 PROM 7H timing signals — also in MAME: 7H namco/bosco.cpp:868 rtl/bosco_video_render.vhd:302 The 07xx and the 2R PROM produce the following sync timings: HSync: the 07xx HSync output is ignored; timing comes from PROM 2R. — also in MAME: 07xx namco/bosco.cpp:21, 2R namco/bosco.cpp:862, 07xx** namco/bosco.cpp:21, 2R namco/bosco.cpp:862 rtl/bosco_video_render.vhd:840 The CS (active low) for RAM 4J is low when either: * hblank_xx is low (we are displaying a line) * or nand_3N_outpin8 is low (we are writing a sprite to RAM) — also in MAME: 4J namco/galaga.cpp:1245 rtl/bosco_video_render.vhd:1006 5A: PAL (BS-8) 5A has not been dumped as far as I'm aware, so its function here is inferred from the inputs it is given and the output it is supposed to produce (based on comparisons to MAME.) — also in MAME: 5A namco/bosco.cpp:504, 5A namco/bosco.cpp:504 Cites MAME source — 12 rtl/bosco_video_render.vhd:1006 5A: PAL (BS-8) 5A has not been dumped as far as I'm aware, so its function here is inferred from the inputs it is given and the output it is supposed to produce (based on comparisons to MAME.) rtl/bosconian.vhd:1 TODO - MAME runs the 50xx, 51xx, and 54xx at MASTER_CLOCK/12, or 1.536 MHz. rtl/bosconian.vhd:6 TODO - The 06xx in MAME runs at MASTER_CLOCK/6/64, which is very slow compared to what I have? rtl/bosconian.vhd:30 Features : TV 15KHz mode only (atm) Coctail mode ok Sound ok Starfield from MAME information rtl/bosconian.vhd:50 Namco 05XX Starfield 4 sets, 63 stars/set, 2 set displayed at one time for blinking 6bits colors: 2red/2green/2blue full emulation in vhdl (from MAME information) rtl/bosconian.vhd:429 Not sure why yet - may be related to the shot sound regression they saw in MAME (and fixed by manually extending the 54xx IRQ duration.) rtl/bosconian.vhd:964 cs50xx #0 - part of the main board MAME sources says that Bosconian is the only game to use the 50xx "to its full potential". rtl/bosconian.vhd:1132 The division by 32 for the timer is a guess, originally made by MAME rtl/bosconian.vhd:1417 shared work RAM 1 - 0x7800-0x7FFF - called "share1" in MAME implementation rtl/namco_06xx.vhd:5 From MAME documentation: rtl/namco_06xx.vhd:136 NOTE: MAME checks for the individual bits, without caring whether or not the last four bits are one-hot. rtl/namco_06xx.vhd:227 NOTE: I'm not seeing yet how this is implemented in MAME. Shares text with the MAME driver without saying so — 29 rtl/bosconian.vhd:328 reset sub and sound CPU, and 5Xxx chips on main board — shares text with namco/bosco.cpp:84 rtl/bosconian.vhd:329 reset 5Xxx chips on video board — shares text with namco/bosco.cpp:117 rtl/bosconian.vhd:596 10011----000xxxx W ----xxxx SOWR bullets shape and X pos msb — shares text with namco/bosco.cpp:102 rtl/bosconian.vhd:599 10011----001---- W xxxxxxxx POSI X playfield X scroll — shares text with namco/bosco.cpp:103 rtl/bosconian.vhd:603 10011----010---- W xxxxxxxx POSI Y playfield Y scroll — shares text with namco/bosco.cpp:104 rtl/bosconian.vhd:607 10011----011---- W -----xxx STAR to 05XX: starfield X scroll speed — shares text with namco/bosco.cpp:105 rtl/bosconian.vhd:608 10011----011---- W --xxx--- STAR to 05XX: starfield Y scroll speed — shares text with namco/bosco.cpp:105 rtl/bosconian.vhd:613 10011----100---- W -------- STARCLR to 05XX: starfield enable(?) — shares text with namco/bosco.cpp:107 rtl/bosconian.vhd:618 10011----111-000 W -------x FLIP flip screen — shares text with namco/bosco.cpp:110 rtl/bosconian.vhd:622 10011----111-100 W -------x BLK 0 \ to 05XX: starfield blink — shares text with namco/bosco.cpp:114 rtl/bosconian.vhd:623 10011----111-101 W -------x BLK 1 / (select active subset) — shares text with namco/bosco.cpp:115 rtl/bosconian.vhd:629 10011----111-111 W -------x RESET reset 5xXX chips on video board — shares text with namco/bosco.cpp:117 rtl/bosconian.vhd:1246 In Bosconian, address lines 15-12 (52xx pins 17-20) are direct active-low chip enables. — shares text with namco/namco52.cpp:42 rtl/bosconian.vhd:1374 Tilemap RAM 1: tile code (1st half is radar + sprite registers; 2nd half is scrolling playfield) — shares text with namco/bosco.cpp:123 rtl/bosconian.vhd:1385 Tilemap RAM 2: tile attribute (1st half is radar + sprite registers; 2nd half is scrolling playfield) — shares text with namco/bosco.cpp:123 rtl/namco_06xx.vhd:7 This chip is used as an interface to up to 4 other custom chips. — shares text with namco/namco06.cpp:7 rtl/namco_06xx.vhd:8 It signals IRQs to the custom MCUs when writes happen, and generates — shares text with namco/namco06.cpp:8 rtl/namco_06xx.vhd:9 NMIs to the controlling CPU to drive reads based on a clock. — shares text with namco/namco06.cpp:9 rtl/namco_06xx.vhd:11 It uses a clock divider that's used to pulse the NMI and custom chip select — shares text with namco/namco06.cpp:11 rtl/namco_06xx.vhd:14 The control register controls chip as such: the low 4 bits are chip selects — shares text with namco/namco06.cpp:14 rtl/namco_06xx.vhd:15 (active high), the 5th bit is read/!write, and the upper 3 bits are the — shares text with namco/namco06.cpp:15 rtl/namco_06xx.vhd:18 SD0-SD7 are data I/O lines connecting to the controlling CPU — shares text with namco/namco06.cpp:18 rtl/namco_06xx.vhd:19 SEL selects either control (1) or data (0), usually connected to — shares text with namco/namco06.cpp:19 rtl/namco_06xx.vhd:20 an address line of the controlling CPU — shares text with namco/namco06.cpp:20 rtl/namco_06xx.vhd:21 /NMI is an NMI signal line for the controlling CPU — shares text with namco/namco06.cpp:21 rtl/namco_06xx.vhd:23 ID0-ID7 are data I/O lines connecting to the other custom chips — shares text with namco/namco06.cpp:23 rtl/namco_06xx.vhd:24 /IO1-/IO4 are IRQ signal lines for each custom chip — shares text with namco/namco06.cpp:24 rtl/namco_06xx.vhd:43 [1] on polepos, galaga, xevious, and bosco: connected to K3 of the 51xx — shares text with namco/namco06.cpp:43 rtl/namco_06xx.vhd:44 on bosco and xevious, connected to R8 of the 50xx — shares text with namco/namco06.cpp:44
Breakout# Breakout MiSTer-devel/Arcade-Breakout_MiSTer @ e0132557 MAME compared: atari/pong.cpp + 8 related file(s) Read: 40 HDL files, 3,137 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	15%
Statements: 1 toward hardware Cites hardware documentation that MAME's driver does not — 1 Arcade-Breakout.sv:3 Based on Rev.F schematics
BubSys# TwinBee (Bubble System) MiSTer-devel/Arcade-BubSys_MiSTer @ 3959a820 MAME driver: not found Read: 38 HDL files, 15,595 lines (Quartus project)	MiSTer official	Mostly hardware	low	38%
Statements: 6 toward hardware, 5 toward MAME Cites hardware documentation that MAME's driver does not — 5 rtl/BubSys_emu.v:64 0x0004_3200 0x0000_0100 2a 400-a01 82S129 BRAM wavetable rtl/BubSys_emu.v:65 0x0004_3300 0x0000_0100 1a 400-a02 82S129 BRAM wavetable rtl/ipcores/K005297/K005297.v:74 Konami 005296/005297 Bubble Memory Controller(BMC) cell level implementation based on the die shot below: rtl/ipcores/K005297/K005297.v:76 Die shot: https://www.siliconpr0n.org/archive/doku.php?id=caps0ff:konami:005297 README.md:2 Current status: Fixable, custom chip known as K005295 will be decapped. Ships hardware documentation files — 1 resources/BubbleSystem_schematics.pdf Cites MAME source — 5 BubSys.sv:378 Bubble System resistor network gamma LUT, caculated by MAME's resnet.cpp rtl/BubSys_emu.v:60 start addr length comp num mame rom parts num location description rtl/BubSys_sound.v:321 MAME PSG1(4F on the board) rtl/BubSys_sound.v:347 MAME PSG2(4H on the board) rtl/GX400_video/K005293.v:180 The chip showed us a total of 26 results and suggested that the source of MAME was a very empirical result.
BubSysROM# Gradius (ROM version), Galactic Warriors, TwinBee MiSTer-devel/Arcade-BubSysROM_MiSTer @ eb372c15 MAME compared: konami/nemesis.cpp + 3 related file(s) Read: 36 HDL files, 12,455 lines (Quartus project)	MiSTer official	Both	low	56%
Statements: 4 toward hardware, 11 toward MAME Cites hardware documentation that MAME's driver does not — 3 rtl/BubSysROM_emu.v:62 0x0005_2000 0x0000_0100 2j 400-a01 82S129 BRAM wavetable rtl/BubSysROM_emu.v:63 0x0005_2100 0x0000_0100 3j 400-a02 82S129 BRAM wavetable README.md:2 Current status: Fixable, custom chip known as K005295 will be decapped. Ships hardware documentation files — 1 resources/BubbleSystemROM_schematics.pdf Cites MAME source — 5 BubSysROM.sv:361 Bubble System resistor network gamma LUT, caculated by MAME's resnet.cpp rtl/BubSysROM_emu.v:56 start addr length comp num mame rom parts num location description rtl/BubSysROM_sound.v:326 MAME PSG1(4F on the board) rtl/BubSysROM_sound.v:352 MAME PSG2(4H on the board) rtl/GX400_video/K005293.v:180 The chip showed us a total of 26 results and suggested that the source of MAME was a very empirical result. Shares text with the MAME driver without saying so — 6 BubSysROM.sv:213 0 1 2 3 4 5 6 — shares text with konami/nemesis.cpp:2898 rtl/GX400_video/GX400_video.v:294 FETCHES HSCROLL(1 PIXEL ROW) VALUE WHEN VCLK = 1 MCLK 0 1 2 3 4 5 0 1 2 3 4 5 CLK18M _\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\| — shares text with konami/nemesis.cpp rtl/GX400_video/GX400_video.v:438 MCLK 0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5 CLK18M _\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯ — shares text with konami/nemesis.cpp rtl/GX400_video/GX400_video.v:681 MCLK 1 1 0 1 2 3 4 5 6 7 8 9 0 1 CLK18M _\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯ — shares text with konami/nemesis.cpp:2898 rtl/GX400_video/K005290.v:38 pixel 0 1 2 3 4 5 6 7 1H _\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\| 2H ___\|¯¯¯ — shares text with konami/nemesis.cpp:2898 rtl/ipcores/vlm5030_gl/vlm5030_gl.vhd:1343 9 8 7 6 5 4 3 2 1 0 — shares text with konami/nemesis.cpp:279
BurgerTime# Burger Time MiSTer-devel/Arcade-BurgerTime_MiSTer @ d7cdb626 MAME compared: dataeast/btime.cpp + 4 related file(s) Read: 11 HDL files, 4,610 lines (Quartus project)	MiSTer official	Mostly MAME	low	32%
Statements: 1 toward hardware, 17 toward MAME Cites hardware documentation that MAME's driver does not — 1 rtl/burger_time.vhd:241 make hcnt and vcnt video scanner (from schematics !) Cites MAME source — 1 rtl/YM2149_linmix_sep.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA Shares text with the MAME driver without saying so — 16 rtl/burger_time.vhd:273 ROM_LOAD( "aa04.9b", 0xc000, 0x1000, CRC(368a25b5) SHA1(ed3f3712423979dcb351941fa85dce6a0a7bb16b) ) — shares text with dataeast/btime.cpp:2548 rtl/burger_time.vhd:274 ROM_LOAD( "aa06.13b", 0xd000, 0x1000, CRC(b4ba400d) SHA1(8c77397e934907bc47a739f263196a0f2f81ba3d) ) — shares text with dataeast/btime.cpp:2549 rtl/burger_time.vhd:275 ROM_LOAD( "aa05.10b", 0xe000, 0x1000, CRC(8005bffa) SHA1(d0da4e360039f6a8d8142a4e8e05c1f90c0af68a) ) — shares text with dataeast/btime.cpp:2550 rtl/burger_time.vhd:276 ROM_LOAD( "aa07.15b", 0xf000, 0x1000, CRC(086440ad) SHA1(4a32bc92f8ff5fbe112f56e62d2c03da8851a7b9) ) — shares text with dataeast/btime.cpp:2551 rtl/burger_time.vhd:279 ROM_LOAD( "ab14.12h", 0xe000, 0x1000, CRC(f55e5211) SHA1(27940026d0c6212d1138d2fd88880df697218627) ) — shares text with dataeast/btime.cpp:2554 rtl/burger_time.vhd:282 ROM_LOAD( "aa12.7k", 0x0000, 0x1000, CRC(c4617243) SHA1(24204d591aa2c264a852ee9ba8c4be63efd97728) ) /* charset #1 / — shares text with dataeast/btime.cpp:2557 rtl/burger_time.vhd:283 ROM_LOAD( "ab13.9k", 0x1000, 0x1000, CRC(ac01042f) SHA1(e64b6381a9298eaf74e79fa5f1ea8e9596c58a49) ) — shares text with dataeast/btime.cpp:2558 rtl/burger_time.vhd:284 ROM_LOAD( "ab10.10k", 0x2000, 0x1000, CRC(854a872a) SHA1(3d2ecfd54a5a9d68b53cf4b4ee1f2daa6aef2123) ) — shares text with dataeast/btime.cpp:2559 rtl/burger_time.vhd:285 ROM_LOAD( "ab11.12k", 0x3000, 0x1000, CRC(d4848014) SHA1(0a55b091cd4e7f317c35defe13d5051b26042eee) ) — shares text with dataeast/btime.cpp:2560 rtl/burger_time.vhd:286 ROM_LOAD( "aa8.13k", 0x4000, 0x1000, CRC(8650c788) SHA1(d9b1ee2d1f2fd66705d497c80252861b49aa9254) ) — shares text with dataeast/btime.cpp:2561 rtl/burger_time.vhd:287 ROM_LOAD( "ab9.15k", 0x5000, 0x1000, CRC(8dec15e6) SHA1(b72633de6268ce16742bba4dcba835df860d6c2f) ) — shares text with dataeast/btime.cpp:2562 rtl/burger_time.vhd:290 ROM_LOAD( "ab00.1b", 0x0000, 0x0800, CRC(c7a14485) SHA1(6a0a8e6b7860859f22daa33634e34fbf91387659) ) / charset #2 / — shares text with dataeast/btime.cpp:2565 rtl/burger_time.vhd:291 ROM_LOAD( "ab01.3b", 0x0800, 0x0800, CRC(25b49078) SHA1(4abdcbd4f3362c3e4463a1274731289f1a72d2e6) ) — shares text with dataeast/btime.cpp:2566 rtl/burger_time.vhd:292 ROM_LOAD( "ab02.4b", 0x1000, 0x0800, CRC(b8ef56c3) SHA1(4a03bf011dc1fb2902f42587b1174b880cf06df1) ) — shares text with dataeast/btime.cpp:2567 rtl/burger_time.vhd:294 ROM_REGION( 0x0800, "bg_map", 0 ) / background tilemaps */ — shares text with dataeast/btime.cpp:2569 rtl/burger_time.vhd:295 ROM_LOAD( "ab03.6b", 0x0000, 0x0800, CRC(d26bc1f3) SHA1(737af6e264183a1f151f277a07cf250d6abb3fd8) ) — shares text with dataeast/btime.cpp:2570
BurningRubber# Burnin' Rubber MiSTer-devel/Arcade-BurningRubber_MiSTer @ 55212a97 MAME compared: dataeast/btime.cpp + 4 related file(s) Read: 11 HDL files, 4,488 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	33%
Statements: 1 toward hardware, 10 toward MAME Cites hardware documentation that MAME's driver does not — 1 rtl/burnin_rubber.vhd:248 make hcnt and vcnt video scanner (from schematics !) Cites MAME source — 1 rtl/YM2149_linmix_sep.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA Shares text with the MAME driver without saying so — 9 rtl/burnin_rubber.vhd:291 /* a000-bfff space for the service ROM */ — shares text with dataeast/btime.cpp:2862 rtl/burnin_rubber.vhd:292 ROM_LOAD( "brubber.12c", 0xc000, 0x2000, CRC(b5279c70) SHA1(5fb1c50040dc4e9444aed440e2c3cf4c79b72311) ) — shares text with dataeast/btime.cpp:2863 rtl/burnin_rubber.vhd:293 ROM_LOAD( "brubber.12d", 0xe000, 0x2000, CRC(b2ce51f5) SHA1(5e38ea24bcafef1faba023def96532abd6f97d38) ) — shares text with dataeast/btime.cpp:2864 rtl/burnin_rubber.vhd:296 ROM_LOAD( "bnj6c.bin", 0xe000, 0x1000, CRC(8c02f662) SHA1(1279d564e65fd3ccac25b1f9fbb40d910de2b544) ) — shares text with dataeast/btime.cpp:2867 rtl/burnin_rubber.vhd:299 ROM_LOAD( "bnj4e.bin", 0x0000, 0x2000, CRC(b864d082) SHA1(cacf71fa6c0f7121d077381a0ff6222f534295ab) ) — shares text with dataeast/btime.cpp:2870 rtl/burnin_rubber.vhd:300 ROM_LOAD( "bnj4f.bin", 0x2000, 0x2000, CRC(6c31d77a) SHA1(5e52554f594f569527af4768d244cc40a7b4460a) ) — shares text with dataeast/btime.cpp:2871 rtl/burnin_rubber.vhd:301 ROM_LOAD( "bnj4h.bin", 0x4000, 0x2000, CRC(5824e6fb) SHA1(e98f0eb476b8f033f5cc70a6e503afc4e651fd45) ) — shares text with dataeast/btime.cpp:2872 rtl/burnin_rubber.vhd:304 ROM_LOAD( "bnj10e.bin", 0x0000, 0x1000, CRC(f4e9eb49) SHA1(b356512d2ebd4e2005e76496b434e5ecebadb251) ) — shares text with dataeast/btime.cpp:2875 rtl/burnin_rubber.vhd:305 ROM_LOAD( "bnj10f.bin", 0x1000, 0x1000, CRC(a9ffacb4) SHA1(49d5f9c0b695f474197fbb761bacc065b6b5808a) ) — shares text with dataeast/btime.cpp:2876
CanyonBomber# Canyon Bomber MiSTer-devel/Arcade-CanyonBomber_MiSTer @ 0e83812f MAME compared: atari/canyon.cpp + 2 related file(s) Read: 18 HDL files, 4,890 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	13%
Statements: 4 toward hardware Cites hardware documentation that MAME's driver does not — 4 rtl/cpu_mem.vhd:424 74LS153 dual selector/multiplexer at H7 reads configuration DIP switches rtl/cpu_mem.vhd:436 74LS153 dual selector/multiplexer at K8 reads Fire buttons rtl/cpu_mem.vhd:447 Steer and Thrust inputs are shown on schematic connected to this selector but not used by Canyon Bomber. rtl/playfield.vhd:123 74LS195 video shift register
Cave# DoDonPachi, DonPachi, ESP Ra.De., Dangun Feveron … MiSTer-devel/Arcade-Cave_MiSTer @ 375d1843 MAME compared: atlus/cave.cpp + 4 related file(s) Read: 75 HDL files, 47,400 lines (Quartus project)	MiSTer official	Mostly MAME	low	31%
Statements: 1 toward hardware, 4 toward MAME Cites hardware documentation that MAME's driver does not — 1 rtl/cave/savestate/CavePwrInst2JT03.sv:2154 Trying to synthesize this memory as M-9K RAM in Altera devices Cites MAME source — 2 rtl/cave/AudioMixer.sv:144 MAME's routing is PSG A/B/C at 0.40, FM at 0.80, OKI0 at 0.80, and OKI1 at 1.00; these anchors account for the implementations' differing raw scales. rtl/cave/savestate/CavePwrInst2JT03.sv:10900 same values as in MAME Says it was translated, ported or taken from MAME — 2 README.md:22 \| [Power Instinct 2](http://adb.arcadeitalia.net/dettaglio_mame.php?game_name=pwrinst2&arcade_only=0&autosearch=1) \| WIP \| Based on Mame - No hardware-accu README.md:23 \| [Gogetsuji Legends](http://adb.arcadeitalia.net/dettaglio_mame.php?game_name=plegends&arcade_only=0&autosearch=1) \| WIP \| Based on Mame - No hardware-accu
CaveBanpresto# Akuu Gallet, Hotdog Storm, Mazinger Z, Oni - The Ninja Master … MiSTer-devel/Arcade-CaveBanpresto_MiSTer @ 26ecac93 MAME compared: atlus/cave.cpp + 4 related file(s) Read: 109 HDL files, 74,290 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	22%
Statements: 1 toward hardware, 4 toward MAME Cites hardware documentation that MAME's driver does not — 1 rtl/cave/savestate/CaveBanprestoJT03Exact.sv:2163 Trying to synthesize this memory as M-9K RAM in Altera devices Cites MAME source — 4 rtl/cave/Sound.sv:374 The 32 MHz master-clock accumulator steps are fixed by the MAME 0.288 board profiles: 0x0873 ~= 1.056 MHz, 0x1000 = 2.000 MHz, and 0x10E5 ~= 2.112 MHz. rtl/cave/savestate/CaveBanprestoJT03Exact.sv:10920 same values as in MAME README.md:10 \| Hotdog Storm \| WIP \| MAME-based. No hardware-accurate comparison made \| README.md:12 \| Metamoqester \| WIP \| MAME-based. No hardware-accurate comparison made \|
Centipede# Centipede MiSTer-devel/Arcade-Centipede_MiSTer @ 7f5d1636 MAME compared: atari/centiped.cpp + 2 related file(s) Read: 25 HDL files, 6,579 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	18%
Statements: 2 toward hardware, 1 not counted Cites hardware documentation that MAME's driver does not — 2 rtl/centipede.v:2 Atari Centipede, from the schematics rtl/centipede.v:757 a guess, based on millipede schematics Cites hardware references or measurements that MAME's driver also gives — 1 rtl/centipede.v:336 136001-407.d1 2048 0 0000 0000 00000000 prog_rom_1 136001-408.e1 2048 2048 0000 1000 00000000 prog_rom_1 136001-409.fh1 2048 4096 0001 0000 00000000 prog_rom_1 136001-410.j1 2048 6144 0001 1000 00000000 prog_rom_1 136001-211.f7 2048 819 — also in MAME: 136001-407 atari/centiped.cpp:2031, 136001-408 atari/centiped.cpp:2032, 136001-409 atari/centiped.cpp:2033, 136001-410 atari/centiped.cpp:2034, 136001-211 atari/centiped.cpp:2037, 136001-212 atari/centiped.cpp:2038, 136001-213 atari/centiped.cpp:2041
Chameleon# Chameleon MiSTer-devel/Arcade-Chameleon_MiSTer @ 1a8da936 MAME compared: snk/lasso.cpp Read: 13 HDL files, 5,470 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	25%
Statements: 1 toward hardware, 1 toward MAME Cites hardware documentation that MAME's driver does not — 1 rtl/sn76489_audio.vhd:52 * The SN76489 datasheet * Insight gained from the AY-3-8910/YM-2149 die-shot and reverse-engineered schematics (similar audio chips from the same era). Cites MAME source — 1 rtl/core.v:33 AUDIO CPU: 0.6MHz from MAME, too slow comparing to the original game MAIN CPU: 0.7MHz, good SN89: 3.5MHz, not sure!
ChampionBaseball# Champion Base Ball, Champion Base Ball Part-2, Exciting Soccer II, Exciting Soccer … MiSTer-devel/Arcade-ChampionBaseball_MiSTer @ 117c4a4a (matched by date) MAME compared: alpha/champbas.cpp + 2 related file(s) Read: 16 HDL files, 4,374 lines (Quartus project)	MiSTer official	Mostly MAME	medium	81%
Statements: 2 toward hardware, 95 toward MAME, 1 not counted Cites hardware references or measurements that MAME's driver also gives — 1 rtl/ChampionBaseball_MAIN.sv:173 LS259 mainlatch @ 9D (champbas.cpp:970-978), written with D0. — also in MAME: 9D alpha/champbas.cpp:970 Ships hardware documentation files — 2 Useful Information/schematics/Championship Baseball 2 Schematics.pdf Useful Information/schematics/Championship Baseball Schematics.pdf Cites MAME source — 88 Arcade-ChampionBaseball.sv:208 champbas has THREE buttons (INPUT_PORTS champbas, champbas.cpp:761-771): Arcade-ChampionBaseball.sv:254 MAME port assembly. rtl/ChampionBaseball.sv:16 ---- controls, already assembled into MAME port order by the wrapper rtl/ChampionBaseball.sv:233 Both boards are mono — one SPEAKER each (champbas.cpp:998, :1115) rtl/ChampionBaseball_MAIN.sv:5 The AY lives at 0x7000-0x7001 on THIS board, not the sound board (champbas.cpp:579). rtl/ChampionBaseball_MAIN.sv:18 ---- controls (active LOW at the port, as MAME reads them) rtl/ChampionBaseball_MAIN.sv:78 Address decode — champbas_map (champbas.cpp:576) rtl/ChampionBaseball_MAIN.sv:122 The MRA is already correct — it pads 0x1800 to place the ROM 0x7800-0x7FFF must also win over cs_ay: in MAME the later `.rom()` entry rtl/ChampionBaseball_MAIN.sv:148 exctsccr adds a SECOND sprite position RAM at A040-A04F (champbas.cpp:645) rtl/ChampionBaseball_MAIN.sv:173 LS259 mainlatch @ 9D (champbas.cpp:970-978), written with D0. rtl/ChampionBaseball_MAIN.sv:222 wdog_cnt counts UP from a kick, so it is ALREADY MAME's (0x10 - counter): MAME's m_counter loads 0x10 and counts DOWN (watchdog.cpp:112 / :165). rtl/ChampionBaseball_MAIN.sv:361 LS259 bit 6 -> mcu_start_w, bit 7 -> bus_dir_w (champbas.cpp:935-936). rtl/ChampionBaseball_MAIN.sv:390 champbasja fake protection (champbas.cpp:532-563). rtl/ChampionBaseball_SND.sv:4 The AY is on the MAIN board (champbas.cpp:579); this CPU never sees it. rtl/ChampionBaseball_SND.sv:31 Address decode — champbas_sound_map (champbas.cpp:659) decodes it. rtl/ChampionBaseball_SND.sv:52 Sound latch (MAME GENERIC_LATCH_8). rtl/ChampionBaseball_SND.sv:152 MAME routes the AY at 0.3 and the DAC at 0.7 (:1002, :1004), so the rtl/ChampionBaseball_VIDEO.sv:22 ---- control bits from the LS259 mainlatch (champbas.cpp:970-978) rtl/ChampionBaseball_VIDEO.sv:46 champbas splits them across TWO memories: code/colour/flip in MAIN RAM 0x8FF0-0x8FFF (champbas.cpp:395-403) rtl/ChampionBaseball_VIDEO.sv:87 first visible line (MAME visarea min_y) rtl/ChampionBaseball_VIDEO.sv:88 one past last (MAME visarea max_y = 239) rtl/ChampionBaseball_VIDEO.sv:296 champbas : colour = (attr & 0x1f) \| 0x20 (champbas.cpp:348) exctsccr : colour = (attr & 0x0f) (champbas.cpp:356) Low 5 bits are stored either way; champbas's \|0x20 is a constant rtl/ChampionBaseball_VIDEO.sv:351 SPRITE ENGINE (champbas.cpp:387-418) 8 sprites, 16x16, 2bpp. rtl/ChampionBaseball_VIDEO.sv:352 MAME iterates offs = 0x0E down to 0 step -2, code = (attr[offs] >> 2 & 0x3f) \| (gfx_bank << 6) color = (attr[offs+1] & 0x1f) \| (palette_bank << 6) rtl/ChampionBaseball_VIDEO.sv:383 MAME draws 3bpp first then 4bpp, each offs 0x0E->0, so later writes win. rtl/ChampionBaseball_VIDEO.sv:396 MAME draws the 4bpp bank with transpen_mask(gfx, colour, 0x10) ctabentry = (color_prom[0x100 + i] & 0x0f) \| 0x10 that MAME drops were drawn in colour-index 0x10 — the black masks rtl/ChampionBaseball_VIDEO.sv:414 MAME order: 7 first, 0 last rtl/ChampionBaseball_VIDEO.sv:434 MEASURED, not derived: comparing "FPGA - Soccer 2.png" against height where MAME has them at 0.60-0.65 — a MIRROR (0.60->0.40), not a shift — and the trophy sign moves left->right. rtl/ChampionBaseball_VIDEO.sv:467 Talbot's gfx1/gfx2 are 0x1000 each (champbas: 0x2000 each), so the MRA's sprite code is 6 bits -- MAME masks 0x3f and talbot nops gfxbank rtl/ChampionBaseball_VIDEO.sv:583 exctsccr indexes its LUT through a bitswap (champbas.cpp:324): rtl/ChampionBaseball_VIDEO.sv:589 exctsccr_palette (champbas.cpp:329-334) splits the pen space in two: pens 0x000-0x0FF (chars + 3bpp sprites): ctabentry = (color_prom[bitswap(i)] & 0x0f) \| ((i & 0x80) >> 3) pens 0x100-0x1FF (4bpp sprites, :330): ctabentry = (color_prom[0x1 rtl/ChampionBaseball_VIDEO.sv:619 Resistor-network DAC (champbas.cpp:243-251) 0x21 / 0x47 / 0x97 triple (the same constants exctsccr_palette :301 0x51 / 0xAE. rtl/ChampionBaseball_VIDEO.sv:640 champbas normalises its (champbas.cpp:310-313), so its blue tops out at 0xDE rather than 0xFF. rtl/ExcitingSoccer_SND.sv:226 MAME (:1120-1129): each AY 0.08, each DAC 0.3 rtl/cpu/hmcs40/alpha8201.sv:8 mcu_start / bus_dir <- LS259 mainlatch Q6/Q7 (champbas.cpp:935-936) ext_* <- champbas_map 0x6000-0x63FF shared RAM mcu_addr / mcu_data -> champbas_rom's 13-bit MCU ROM port CEN_DIV generates the machine-cycle enable; pause rtl/cpu/hmcs40/alpha8201.sv:21 Z80-side control (LS259 mainlatch, champbas.cpp:935-936) rtl/cpu/hmcs40/alpha8201.sv:119 mcu_update_address() (alpha8201.cpp:357-361): m_mcu_address = (m_mcu_d<<8 & 0x300) \| m_mcu_r[2]<<4 \| m_mcu_r[3]; rtl/cpu/hmcs40/alpha8201.sv:124 mcu_data_r gate, alpha8201.cpp:368 rtl/cpu/hmcs40/alpha8201.sv:125 mcu_writeram gate, alpha8201.cpp:353 rtl/cpu/hmcs40/alpha8201.sv:133 Z80 side — unconditional (alpha8201.cpp:418-428 comment: "going by rtl/cpu/hmcs40/alpha8201.sv:136 MCU side — read (mcu_data_r, alpha8201.cpp:364-376): R0 gets the rtl/cpu/hmcs40/alpha8201.sv:138 R-PORT-READBACK-FIX-2026-08-07 (part 2): MAME read_r() (hmcs40.cpp:387-396) IS_CMOS (hmcs40.cpp:123), so m_polarity is truthy -> the AND branch. rtl/cpu/hmcs40/alpha8201.sv:144 MCU side — write (mcu_writeram, alpha8201.cpp:350-355). rtl/cpu/hmcs40/alpha8201.sv:149 MAME, not two. rtl/cpu/hmcs40/alpha8201.sv:149 Both port writers funnel through mcu_update_address(): mcu_data_w() (write_r<0..3>, alpha8201.cpp:378-384) -> update_address -> writeram rtl/cpu/hmcs40/alpha8201.sv:174 pin 19 !HLT tied to Vcc — never halted (alpha8201.cpp:52) rtl/cpu/hmcs40/alpha8201.sv:181 R2-R7 have NO read_r<> bind in device_add_mconfig, so they take MAME's on at $0ECF -> "TESTING 6" hangs forever. rtl/cpu/hmcs40/alpha8201.sv:189 (alpha8201.cpp:329 binds write_d only), and the core already applies rtl/cpu/hmcs40/alpha8201.sv:196 pin 30 INT0 = GO (alpha8201.cpp:57) rtl/cpu/hmcs40/alpha8201.sv:197 pin 31 INT1 = n.c. (alpha8201.cpp:58) rtl/cpu/hmcs40/hmcs40.sv:11 HD44801 = HMCS44 family (hmcs40.cpp:46, :113-128): stack_levels = 4, pcwidth = 11, prgwidth = 12 (program_2k, 4096 words), datawidth = 8, data_160x4 (160 x 4-bit RAM), polarity = CMOS. rtl/cpu/hmcs40/hmcs40.sv:16 cen : one clk-wide pulse per machine cycle, generated by the WRAPPER, not here — one cen per MAME cycle() call (hmcs40.cpp:647-651). rtl/cpu/hmcs40/hmcs40.sv:21 Approximation: an INT1-edge counter bump (hmcs40.cpp:598-599) landing on an FSM commit edge is dropped. rtl/cpu/hmcs40/hmcs40.sv:30 HMCS40_INPUT_LINE_HLT (hmcs40.cpp:578) — active high halts the core rtl/cpu/hmcs40/hmcs40.sv:42 D0-D15 discrete i/o (hmcs40.cpp:406-424). rtl/cpu/hmcs40/hmcs40.sv:47 This is MAME's `m_write_d(...)` callback -> alpha_8201_device::mcu_d_w(), rtl/cpu/hmcs40/hmcs40.sv:50 MAME binds write_r<0..3> to alpha_8201_device::mcu_data_w(), which calls mcu_update_address() -> mcu_writeram(). rtl/cpu/hmcs40/hmcs40.sv:55 INT0/INT1 pins (HMCS40_INPUT_LINE_INT0/1, hmcs40.cpp:573-603) rtl/cpu/hmcs40/hmcs40.sv:59 debug/observability (not part of the MAME model — added for the rtl/cpu/hmcs40/hmcs40.sv:96 LPU-latched upper bits (hmcs40op.cpp:462-476) rtl/cpu/hmcs40/hmcs40.sv:99 hardware call stack (hmcs40op.cpp:24-36) rtl/cpu/hmcs40/hmcs40.sv:163 Step1(LPU fixup)+Step2(shift regs)+Step3(int check) — hmcs40.cpp:663-676 rtl/cpu/hmcs40/hmcs40.sv:164 wait for cen: push_stack + redirect to vector (take_interrupt, hmcs40.cpp:551-571) rtl/cpu/hmcs40/hmcs40.sv:171 reversed 4-bit immediate (hmcs40.cpp:681, m_i) rtl/cpu/hmcs40/hmcs40.sv:180 LFSR PC increment — bit-exact transcription of hmcs40.cpp:632-645 rtl/cpu/hmcs40/hmcs40.sv:241 -- register-to-register (hmcs40op.cpp:49-99) ---------- rtl/cpu/hmcs40/hmcs40.sv:252 -- RAM address instructions (hmcs40op.cpp:104-173) ---- rtl/cpu/hmcs40/hmcs40.sv:266 -- RAM register instructions (hmcs40op.cpp:178-224), rtl/cpu/hmcs40/hmcs40.sv:300 -- immediate instructions (hmcs40op.cpp:229-246) ------ rtl/cpu/hmcs40/hmcs40.sv:308 -- arithmetic (hmcs40op.cpp:251-369) ------------------- rtl/cpu/hmcs40/hmcs40.sv:334 -- compare (hmcs40op.cpp:374-414), all set S only ------ rtl/cpu/hmcs40/hmcs40.sv:343 -- RAM bit manipulation (hmcs40op.cpp:419-435) --------- rtl/cpu/hmcs40/hmcs40.sv:348 -- ROM address instructions (hmcs40op.cpp:440-489) ----- rtl/cpu/hmcs40/hmcs40.sv:375 -- interrupt instructions (hmcs40op.cpp:494-609) ------- rtl/cpu/hmcs40/hmcs40.sv:396 -- input/output (hmcs40op.cpp:614-690) ----------------- rtl/cpu/hmcs40/hmcs40.sv:412 I_ILL — hmcs40op.cpp:41-44, no state change beyond pc advance rtl/cpu/hmcs40/hmcs40.sv:447 P write-back (hmcs40op.cpp:673-689), applied once the pattern word rtl/cpu/hmcs40/hmcs40.sv:475 hmcs40.cpp:273-290 device_reset(): cf/ie/iri/irt=0, if0/if1/tf=1 rtl/cpu/hmcs40/hmcs40.sv:495 hmcs40.cpp:656-661: internal clock stopped, nothing advances rtl/cpu/hmcs40/hmcs40.sv:517 consumed unconditionally, hmcs40.cpp:676 rtl/cpu/hmcs40/hmcs40.sv:520 take_interrupt() (hmcs40.cpp:551-571): push return addr, rtl/cpu/hmcs40/hmcs40.sv:613 cycle()->clock_prescaler() (hmcs40.cpp:618-625): normal rtl/ram_rom/champbas_rom.sv:63 Index 0 — maincpu: MAME ROM_REGION "maincpu", main Z80 program. rtl/ram_rom/champbas_rom.sv:80 Index 1 — audiocpu: MAME ROM_REGION "audiocpu", audio Z80 program. rtl/ram_rom/champbas_rom.sv:97 Index 2 — gfx_p01: MAME ROM_REGION "gfx1"/"gfx2", planes 0/1 of an address bit downstream (0x2000 for champbas family, 0x1000 for rtl/ram_rom/champbas_rom.sv:114 Index 6 — mcu: MAME ROM_REGION "alpha_8201:mcu", ALPHA-8201/8302/8303 rtl/ram_rom/champbas_rom.sv:130 Index 7 — prom: MAME ROM_REGION "proms", colour PROMs (palette + pen->color LUT, one or two PROMs depending on set). rtl/ram_rom/champbas_rom.sv:165 Index 9 — gfx3: MAME ROM_REGION "gfx3", 4bpp sprites. Says it matches, follows or was checked against MAME — 2 rtl/ChampionBaseball_MAIN.sv:140 A[7:6] picks the quadrant, matching MAME's A000/A040/A080/A0C0. rtl/ChampionBaseball_MAIN.sv:209 16 vblanks without an $A0C0 kick resets the CPU side (MAME: Without it the boot spin at $003F ("jr c,$003F", a jump to itself) never ends, and wdog_cnt runs past 0x10 so the bit-2 readback stops matching MAME -- which is the bit Talbot's MC Says it was translated, ported or taken from MAME — 2 rtl/cpu/hmcs40/alpha8201.sv:6 Ported from MAME's alpha8201.cpp (license BSD-3-Clause, copyright hap). rtl/cpu/hmcs40/hmcs40.sv:6 Ported from MAME's cpu/hmcs40/{hmcs40.cpp,hmcs40op.cpp,hmcs40.h} (license BSD-3-Clause, copyright hap), staged under Useful Information/mame/cpu/hmcs40/. Shares text with the MAME driver without saying so — 3 rtl/ChampionBaseball_VIDEO.sv:397 ctabentry = (color_prom[0x100 + i] & 0x0f) \| 0x10 — shares text with alpha/champbas.cpp:332 rtl/ChampionBaseball_VIDEO.sv:576 ctabentry = (lut[i & 0xff] & 0x0f) \| ((i & 0x100) >> 4) — shares text with alpha/champbas.cpp:282 rtl/ChampionBaseball_VIDEO.sv:593 ctabentry = (color_prom[0x100 + i] & 0x0f) \| 0x10 — shares text with alpha/champbas.cpp:332
ChinaGate# Sai Yu Gou Ma Roku MiSTer-devel/Arcade-ChinaGate_MiSTer @ d6d7cb31 MAME compared: technos/chinagat.cpp + 2 related file(s) Read: 20 HDL files, 5,384 lines (Quartus project)	MiSTer official	Mostly MAME	low	50%
Statements: 2 toward hardware, 36 toward MAME Cites hardware documentation that MAME's driver does not — 2 rtl/chinagate/jtcg_main.sv:28 It exposes chip-select strobes and write data to the surrounding modules: - shared 8K RAM (with sub CPU) - FG vram, BG vram, sprite RAM, palette - banked + fixed program ROM and consumes: - cabinet inputs (P1, P2, SYSTEM) - DSW - read-back rtl/chinagate/jtcg_shared_ram.sv:23 China Gate FPGA core Shared RAM 8K, dual-port, between main and sub CPU. Cites MAME source — 29 ChinaGate.sv:560 Coin Gong (FM CH7) mode: Polite (25%, default) o MAME (100%) Polite: ch_tl_offset[7] = 16 (~-12 dB, attenua effetti CH7 troppo forti) MAME: ch_tl_offset[7] = 0 (passa TL del game invariato, come MAME) CH0..CH6 sempre invariati (offset 0). ChinaGate.sv:801 OSD label "MAME,Polite" → 0=MAME (default), 1=Polite ChinaGate.sv:828 In quella zona MAME mostra cornice nera del FG; mio FG ha pen=0 lì e mostra sprite/BG sotto. rtl/chinagate/chinagate_audio.sv:76 Quando 0, comportamento MAME esatto. rtl/chinagate/chinagate_audio.sv:295 Mixer: replica MAME chinagat (mono, gain 0.8 entrambi) + OSD vol rtl/chinagate/chinagate_audio.sv:297 MAME normalization (verificato chinagat.cpp + ymfm_mame.h + okim6295.cpp): YM2151: output / 32768 → ±1.0 (16-bit a unità) OKI M6295: output / 2048 → ±1.0 per voce (acc 4 voci 14-bit) Per allineare OKI a YM: oki << 4 (×16 = 32768/2048). rtl/chinagate/jtcg_colmix.sv:25 References: - chinagat.cpp:709-713 (gfx decode regions: chars=0,16; sprites=128,8; tiles=256,8) - ddragon_v.cpp:220-232 (drawing order: BG, sprites, FG) - crossref §6 (palette is xBGR_444, split lo/hi at $3000/$3400) rtl/chinagate/jtcg_colmix.sv:35 Priority (hardcoded, MAME-correct): FG (pen != 0) > sprite (pen != 0) > BG rtl/chinagate/jtcg_draw.sv:25 Disegna 16 pixel di una riga di tile 16x16 4bpp applicando il MAME chinagat tilelayout direttamente: per ogni X-quad q (0..3): fetch 1 word 16-bit da SDRAM @ word_addr = T64 + q16 + y byte_lo = SDRAM[2word_addr] (j7/j8: planes 2,3) rtl/chinagate/jtcg_draw.sv:123 perm 0123 (verificato tool tile_viewer su sprite reale code 0x08b6 color 1 vs MAME ground truth): p0 = byte_lo[bit_pos] p1 = byte_lo[bit_pos + 4] p2 = byte_hi[bit_pos] p3 = byte_hi[bit_pos + 4] rtl/chinagate/jtcg_obj.sv:31 References: - ddragon_v.cpp::draw_sprites() in mame_ref/ - jtdd_obj.v in jtdd_ref/ - crossref_chinagate.md §6 rtl/chinagate/jtcg_obj.sv:39 - China Gate "sprite clip" wrap-around for negative coords [-15,-8] is not implemented yet; jtframe_objdraw's natural wrap handles -15..0 and 256..271 differently from MAME. rtl/chinagate/jtcg_obj.sv:129 MAME draw_sprites: flipx = attr & 8 (= bit 3), flipy = attr & 4 (= bit 2). rtl/chinagate/jtcg_obj.sv:138 mask del code in funzione di size (MAME draw_sprites: which &= ~size). rtl/chinagate/jtcg_obj.sv:147 selector tile interno al metatile: bit 0 = top/bottom (sumy[4] inverso, top=0 bottom=1) MAME: size=1: top=which+0, bottom=which+1 → tile_y = ~ypos[4] in nostre coord RTL ChinaGate aveva: id[0] <= id[0] ^ ypos[4] → equivalente bit 1 = left/r rtl/chinagate/jtcg_obj.sv:158 xpos: il tile sinistro è a xpos+dx (= xpos-16 con dx=-16, MAME), il tile destro a xpos. rtl/chinagate/jtcg_obj.sv:159 Cioè: half_x=0 (left): xpos_draw = xpos - 16 (MAME: sx + dx) half_x=1 (right): xpos_draw = xpos (MAME: sx) Per size_x=0 c'è solo half_x=0 ma con xpos_draw = xpos (non shift). rtl/chinagate/jtcg_obj.sv:238 MAME chinagat (ddragon_v.cpp:152-153): sx = 240 - byte4 + (X_MSB << 8) if (sx in [-15,-8]) sx += 256; // wrap MAME chinagat-specific Sottrazione 9-bit completa con borrow corretto. rtl/chinagate/jtcg_obj.sv:242 Range wrap MAME: -15..-8 = 9'd497..9'd504 unsigned. rtl/chinagate/jtcg_obj.sv:247 wrap a destra (MAME chinagat clip fix) rtl/chinagate/jtcg_scroll.sv:25 Decodifica MAME chinagat tilelayout (16x16 4bpp, 64 byte/tile): - planes 2,3 nei primi 0x20000 byte SDRAM region (a-13 + a-12) - planes 0,1 negli 0x20000 byte successivi (a-15 + a-14) - byte_idx (within half) = T64 + 16qf + pyf - byte SDR rtl/chinagate/jtcg_scroll.sv:158 Tiles ROM in BRAM locale (256KB = 2 x 128KB) tiles_dl_addr[17] = 0 → lo half (planes 2,3 according to MAME, ma con v32 confermato che è byte_HI nel decoder) tiles_dl_addr[17] = 1 → hi half (byte_LO nel decoder) rtl/chinagate/jtcg_scroll.sv:163 hi half MAME = byte_lo rtl/chinagate/jtcg_scroll.sv:164 lo half MAME = byte_hi rtl/chinagate/jtcg_scroll.sv:168 dl_addr[17]=0 → MAME prima half → byte_hi nel decoder dl_addr[17]=1 → MAME seconda half → byte_lo nel decoder rtl/chinagate/jtcg_video.sv:25 Decodifica MAME chinagat charlayout (8x8 4bpp, 32 byte/char): - 4 byte per row, byte_idx = T32 + 8qx + y (qx in 0..3, 2 pixel/byte) - 1 byte SDRAM = 2 pixel x 4 plane (planes interleavati) - pixel pari (left, subx=0): pen = {b[7], b[5] README.md:10 The core reimplements the hardware in SystemVerilog from the MAME driver, the PCB schematics and pixel-accurate validation against MAME and original PCB footage README.md:25 YM2151 FM (jt51) + OKI M6295 ADPCM (jt6295) with MAME-accurate mixer README.md:122 The MAME* project for invaluable hardware reference (chinagat.cpp, ddragon.cpp, ddragon_v.cpp). Says it matches, follows or was checked against MAME — 1 rtl/chinagate/jtcg_draw.sv:39 Verificato 100% match MAME via _dev/scripts/tile_viewer.py (decoder xrev_perm_3210 + MRA US). Shares text with the MAME driver without saying so — 6 ChinaGate.sv:198 "P3O[43:38],BG X Offset,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,-32,-31,-30,-29,-28,-27,-26,-25,-24,-23,-22,-21,-2 — shares text with technos/ddragon.cpp:230 ChinaGate.sv:199 "P3O[49:44],BG Y Offset,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,-32,-31,-30,-29,-28,-27,-26,-25,-24,-23,-22,-21,-2 — shares text with technos/ddragon.cpp:230 ChinaGate.sv:200 "P3O[55:50],FG X Offset,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,-32,-31,-30,-29,-28,-27,-26,-25,-24,-23,-22,-21,-2 — shares text with technos/ddragon.cpp:230 ChinaGate.sv:201 "P3O[61:56],FG Y Offset,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,-32,-31,-30,-29,-28,-27,-26,-25,-24,-23,-22,-21,-2 — shares text with technos/ddragon.cpp:230 ChinaGate.sv:202 "P3O[67:62],Sprite X Offset,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,-32,-31,-30,-29,-28,-27,-26,-25,-24,-23,-22,-2 — shares text with technos/ddragon.cpp:230 ChinaGate.sv:203 "P3O[73:68],Sprite Y Offset,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,-32,-31,-30,-29,-28,-27,-26,-25,-24,-23,-22,-2 — shares text with technos/ddragon.cpp:230
CityConnection# City Connection MiSTer-devel/Arcade-CityConnection_MiSTer @ 57407191 MAME compared: jaleco/citycon.cpp Read: 22 HDL files, 9,262 lines (Quartus project)	MiSTer official	Mostly MAME	medium	42%
Statements: 8 toward hardware, 79 toward MAME, 3 not counted Cites hardware documentation that MAME's driver does not — 8 rtl/citycon/pld/pal_h7.v:23 PAL H7 (CCP-1) — sprite line buffer sequencer (City Connection) Decompilazione JEDEC via jedutil → reference/pld_decoded/pal_h7_eqn.txt rtl/citycon/pld/pal_l5.v:23 PAL L5 — funzione non ancora identificata (City Connection) Decompilazione JEDEC via jedutil → reference/pld_decoded/pal_l5_eqn.txt rtl/citycon/pld/pal_l5.v:44 - i1, i2, i3 selezionano quale output attivare → 8 combinazioni = 1 per ognuno degli 8 output (decoder 3→8, simile a 74LS138). rtl/citycon/pld/pal_u7.v:23 PAL U7 (CCP-2) — sync/timing generator (City Connection) Decompilazione JEDEC via jedutil → reference/pld_decoded/pal_u7_eqn.txt rtl/citycon/pld/ttl_74ls157.v:2 74LS157 — Quad 2-to-1 multiplexer con select e enable 16-pin DIP. rtl/citycon/pld/ttl_74ls161.v:2 74LS161 — Synchronous 4-bit binary counter with parallel load 16-pin DIP. rtl/citycon/pld/ttl_74ls283.v:2 74LS283 — 4-bit binary full adder con carry-in/out 16-pin DIP. rtl/citycon/pld/ttl_74ls86.v:2 74LS86 — Quad XOR gate 14-pin DIP. Cites hardware references or measurements that MAME's driver also gives — 3 rtl/citycon/pld/prom_82s123.v:2 82S123 — Bipolar PROM 32 word × 8 bit (Signetics/TI/AMD) 16-pin DIP, 5 address (A0..A4), 8 output tri-state Sul PCB City Connection: N5 (address decoder CPU) e R4 (funzione ignota). — also in MAME: 82S123 jaleco/citycon.cpp:496 rtl/citycon/pld/prom_82s129.v:2 82S129 — Bipolar PROM 256 word × 4 bit (Signetics/TI/AMD) 16-pin DIP, 8 address (A0..A7), 4 output tri-state Sul PCB City Connection: L6 (funzione ignota). — also in MAME: 82S129 jaleco/citycon.cpp:498 rtl/citycon/pld/prom_82s129.v:6 Implementazione FPGA: simile a 82S123 ma 256×4. — also in MAME: 82S123 jaleco/citycon.cpp:496 Cites MAME source — 65 Template.sv:29 Sprite stage gate-level (PCB Jaleco): commentare per usare il renderer "MAME-style" originale del core. Template.sv:201 Audio volume boost: 0=100% (default 1.5x MAME), 1=125%, 2=150%, 3=175%, 4=200% Template.sv:280 Joystick → City Connection input mapping MAME P1 port (active-low): b7=START2, b6=START1, b5=FIRE2, b4=FIRE1, b3=LEFT, b2=RIGHT, b1=DOWN, b0=UP MiSTer joy: [0]=R [1]=L [2]=D [3]=U [4]=A(Fire) [5]=B(Jump) [10]=Start [11]=Coin Template.sv:355 CHAR ROM BRAM (4KB source) ///////////// Region "chars" c4: MRA offset 0x14000-0x14FFF (usiamo solo primi 4KB, come fa init_citycon MAME). Template.sv:359 Noi leggiamo src[i] e componiamo il byte espanso come MAME fa in init_citycon. rtl/citycon/citycon_audio.sv:22 City Connection — Audio subsystem Reference MAME citycon.cpp:384-431, sound_map 244-251 rtl/citycon/citycon_audio.sv:37 soundlatch1 ($3001 main → audio) → YM2203 port A (read by audio CPU via YM2203) soundlatch2 ($3002 main → audio) → YM2203 port B AY8910 ports A/B: not connected (MAME default) rtl/citycon/citycon_audio.sv:41 IRQ audio CPU = vblank rising edge (MAME: irq0_line_hold "actually unused") rtl/citycon/citycon_audio.sv:49 edge for IRQ (MAME irq0_line_hold) rtl/citycon/citycon_audio.sv:53 0=100% (1.5x MAME) ... rtl/citycon/citycon_audio.sv:146 AY8910 (jt49) — address latch + jt49 instance MAME address_data_w: offs=0 latch addr (regnum), offs=1 write data rtl/citycon/citycon_audio.sv:221 IRQ vblank (MAME irq0_line_hold "actually unused" ma cablato) rtl/citycon/citycon_audio.sv:228 Quando audio CPU non lo serve (= MAME "actually unused"), nessuno legge IRQ ack register, quindi rilascio dopo 1 ck per evitare hang. rtl/citycon/citycon_audio.sv:234 MIXER — MAME volumi: AY8910 mono = (A+B+C) × 0.40 YM2203 FM = fm_snd × 0.40 YM2203 PSG = psg_snd × 0.20 AY8910 outputs 8-bit (0..255), psg_snd 10-bit (0..1023), fm_snd signed 16-bit rtl/citycon/citycon_audio.sv:240 Calcolo precisione: AY8910 sum 8+8+8 = 10-bit unsigned (0..765) ×0.40 ≈ ×102/256 (= 0.3984, errore 0.4%) — uso shift: ×102 / 256 con ×26 shift 6 = ×0.40625 Per restare nei valori MAME senza approssimazione bisogna usare moltiplicatori. rtl/citycon/citycon_audio.sv:256 step \| total scale vs MAME \| AY/FM mul (0.40 base) \| PSG mul (0.20 base) rtl/citycon/citycon_top.sv:99 Clock enables (clk_sys = 40 MHz — MAME MASTER_CLOCK / 2) ce_pix = clk/8 = 5 MHz (MAME PIXEL_CLOCK esatto) rtl/citycon/citycon_top.sv:101 ce_E = clk/32 = 1.25 MHz (MAME CPU_CLOCK esatto) rtl/citycon/citycon_top.sv:115 ogni 20 clk → 2 MHz (MAME) rtl/citycon/citycon_top.sv:156 Memory map (da citycon.cpp main_map): $0000-$0FFF WRAM (4KB) $1000-$1FFF FG VRAM (4KB) $2000-$27FF linecolor RAM (256B + mirror 0x700) $2800-$2FFF sprite RAM (256B + mirror 0x700) $3000 IN / background_w $3001 DSW1 r / sou rtl/citycon/citycon_top.sv:263 Il +4 X era per compensare cliprect MAME 240 px; con area 256 px PCB non serve più. rtl/citycon/citycon_video.sv:22 City Connection — video renderer (MAME-accurate, versione "step finale") rtl/citycon/citycon_video.sv:24 Implementazione fedele a citycon.cpp: - FG 5bpp via expansion on-the-fly (crom_i/crom_k interface) - FG palette: virtual palette @ 640 + 4scanline + pen[1:0] (MAME update loop) - BG 4bpp via two-half tilelayout (c6..c9 + planes 2/3 @ +0xC0 rtl/citycon/citycon_video.sv:145 CONVENZIONE COORDINATE UNIFICATA (Codex audit fix): screen_x = coord X in bitmap MAME (visibile 8..247) screen_y = coord Y in bitmap MAME (visibile 16..239) Tutti i layer usano queste coord. rtl/citycon/citycon_video.sv:151 = bitmap_y MAME rtl/citycon/citycon_video.sv:154 SCROLL per-row FG (MAME: rows 0..5 → 0, rows 6..31 → scroll_x) rtl/citycon/citycon_video.sv:156 MAME: bitmap_y rtl/citycon/citycon_video.sv:164 FG TILEMAP (MAME mapper) scan(col,row) = {col[6:5], row[4:0], col[4:0]} (12-bit) Pixel ROM (5bpp expansion): i_low = code8 + r i_high = code8 + r + 0x800 Per ogni mezzo-tile servono 3 byte (planes 0/1 in byte0, 2/3 in byte1, 4 in byte2) rtl/citycon/citycon_video.sv:174 MAME: fg_col = bitmap_x + scroll. rtl/citycon/citycon_video.sv:292 MAME drawgfx.cpp readbit: MSB-first. rtl/citycon/citycon_video.sv:306 MAME char 5bpp pen = row_sub4 + pen_visibile. rtl/citycon/citycon_video.sv:316 BG TILEMAP (MAME) scan(col,row) = {col[6:5], row[4:0], col[4:0]} (stesso del FG) code_addr = 0x1000bg_image + tile_index pal_addr = 0xC000 + 0x100bg_image + code pix_addr: gfxset (3+bg_image) entry base = 0x2000bg_image + code8 + r (c rtl/citycon/citycon_video.sv:325 MAME: bg_col = bitmap_x + scroll>>1 rtl/citycon/citycon_video.sv:328 MAME: bitmap_y rtl/citycon/citycon_video.sv:383 BG pixel ROM layout (MAME tilelayout, 4bpp 8x8): base = (3 + bg_image) * 0x1000 + code8 + row + (col<4 ? rtl/citycon/citycon_video.sv:477 Extract BG 4bpp pen — MAME tilelayout planes = {4, 0, 0xC0008+4, 0xC0008+0} Convenzione MAME (src/emu/drawgfx.cpp): bit offset 0 = bit 7 del byte (MSB). rtl/citycon/citycon_video.sv:487 MAME drawgfx.cpp readbit: src[n/8] & (0x80 >> (n%8)) → MSB-first bit order. rtl/citycon/citycon_video.sv:501 SPRITE RENDERER (line buffer ping-pong, scanner FSM fedele MAME) rtl/citycon/citycon_video.sv:515 Draw order MAME: dall'ultimo sprite al primo → il primo è "on top" (sovrascrive). rtl/citycon/citycon_video.sv:538 MAME: sy = 239 - sy_raw. rtl/citycon/citycon_video.sv:552 sprite_addr/sprrom_addr — mux MAME-style vs PCB-gate-level vedi blocco `ifdef SPRITE_GATE_LEVEL più sotto. rtl/citycon/citycon_video.sv:628 MAME letterale: yscan_next = screen_y (= bitmap_y). rtl/citycon/citycon_video.sv:633 MAME: scan da 63 -> 0 (ultimo scritto = on-top = idx 0) rtl/citycon/citycon_video.sv:852 Lo scanner MAME-style (citycon_video.sv:571-749) continua a girare in parallelo ma le sue uscite vengono ignorate dal mux finale. rtl/citycon/citycon_video.sv:905 Palette mapping: sprite: base 0 + spr_pal16 + spr_pen (16 banks × 16 pen) FG: MAME scrive ogni frame palram[640+4y+i] copiando da palram[512+4linecolor[y]+i]. rtl/citycon/citycon_video.sv:908 Invece di replicare il writeback in HW, leggo DIRETTAMENTE da palram[512 + 4linecolor[y] + pen[1:0]] (sorgente MAME). rtl/citycon/citycon_video.sv:912 MAME fa palram[640+4y+i]=palram[512+4linecolor[y]+i] per i=0..3. rtl/citycon/citycon_video.sv:914 linecolor indicizzato da y_fg (non y_active) perché MAME fa changecolor(640+4offs+...) dove offs = char_color8 + row_sub = y_fg. rtl/citycon/citycon_video.sv:1065 Output mixing (MAME order: BG base → FG trans 0 → sprite trans 0) rtl/citycon/pld/hv_counter.v:33 Numeri PCB confermati MAME/decompilazione: HTOTAL=320, HBEND=8, HBSTART=248 VTOTAL=262, VBEND=16, VBSTART=240 rtl/citycon/pld/sprite_pcb.v:119 HREV sul PCB = attr2[4] raw (NON invertito come nel MAME-style flipx). rtl/citycon/pld/sprite_pcb.v:120 MAME: flipx = ~attr2[4]; PCB: HREV = attr2[4]. rtl/citycon/pld/sprite_pcb.v:263 SEMPLIFICAZIONE FPGA: il PCB usa pulse periodico ogni 8 ck con LS166 shift register, ma FSM-MAME-style serializza in 2 metà 4-pixel ognuna. rtl/citycon/pld/sprite_pcb.v:464 Su FPGA con il modello FSM-MAME-style del scanner, il counter scrive solo durante draw_active e fermerebbe a fine HBLANK, quindi serve un read addr basato su hcnt come nel legacy. rtl/citycon/pld/sprite_stage.v:39 SCANNER (pagina 10) NON è ancora gate-level — resta MAME-style sopra di noi (citycon_video.sv:571-749). rtl/citycon/pld/sprite_stage.v:58 Input dal scanner sprite (MAME-style upstream per ora) rtl/citycon/pld/sprite_stage.v:140 NOTA: per ora HREV upstream è già applicato dallo scanner MAME-style che invia in_pen_col post-flipx. rtl/citycon/pld/sprite_stage.v:216 Cablaggio input (ipotesi consolidata da pin_mapping.md): i1..i4 = S0..S3 (sprite pen, da B11) i5..i8 = V counter primati (qui sostituito con vcnt[3:0] come prossimità, nota: il PCB usa V primati post-flip; scanner upstream è MAME-style, l'e README.md:10 This core reimplements the hardware in SystemVerilog from MAME references and pixel-accurate validation against original PCB footage. README.md:24 AY-3-8910 (jt49) and YM2203 (jt03) sound chips with MAME-accurate mixer README.md:25 247×224 active video area (PCB-accurate, not MAME's 240×224 clip) README.md:39 Two weeks of pixel hunt: sprites and the platform "trail" effect were all consistently a few pixels off vs MAME. README.md:46 One frame revealed it: the PCB outputs 247 pixels wide, not 240 as MAME's clipping suggests. README.md:48 MAME crops 7 pixels and adjusts everything internally to fit. README.md:148 The MAME project for invaluable hardware reference. Says it matches, follows or was checked against MAME — 7 rtl/citycon/citycon_audio.sv:245 Uso volumi MAME 1:1 con calcolo intero: AY8910 = sum * 26 / 64 = sum * 0.40625 (errore 1.5%) YM2203 FM = fm_snd * 26 / 64 YM2203 PSG = psg_snd * 13 / 64 (= 0.203) Per match esatto MAME servirebbero divisioni reali — accettiamo 1-2% di error rtl/citycon/citycon_top.sv:107 ce_pix = clk/8 = 5 MHz (match MAME PIXEL_CLOCK). rtl/citycon/citycon_top.sv:112 CPU MC6809 E clock = 2 MHz (match MAME CPU_CLOCK/4 = 8/4). rtl/citycon/citycon_video.sv:148 Match MAME 1:1. rtl/citycon/citycon_video.sv:197 Match MAME (tile pipeline=X+3 ↔ vram[X+3]). rtl/citycon/citycon_video.sv:312 fg_opaque = (fg_pen != 0) — match MAME drawer transparent pen check. rtl/citycon/pld/sprite_pcb.v:121 Il NAND A3 produce NSM = NAND(match, HREV), quindi: attr2[4]=1 (sprite "naturale" MAME) → HREV=1 → NSM=0 in match → A0=Q0 (lineare) attr2[4]=0 (sprite flipx MAME) → HREV=0 → NSM=1 in match → A0=~Q0 (flip) Says it was translated, ported or taken from MAME — 7 rtl/citycon/citycon_audio.sv:245 Uso volumi MAME 1:1 con calcolo intero: AY8910 = sum * 26 / 64 = sum * 0.40625 (errore 1.5%) YM2203 FM = fm_snd * 26 / 64 YM2203 PSG = psg_snd * 13 / 64 (= 0.203) Per match esatto MAME servirebbero divisioni reali — accettiamo 1-2% di error rtl/citycon/citycon_video.sv:148 Match MAME 1:1. rtl/citycon/citycon_video.sv:311 MAME 1:1: set_transparent_pen(0) è sul pen 5bpp completo (0..31), non solo pen visibile. rtl/citycon/citycon_video.sv:313 MAME 1:1: trasparente sse pen 5bpp = 0 rtl/citycon/citycon_video.sv:641 MAME 1:1: sy = 239 - sy_raw (no flip), sy = 238 - sy in flip mode. rtl/citycon/citycon_video.sv:917 MAME 1:1: FG legge dalla VIRTUAL palette palram[640+4y+pen[1:0]]. rtl/citycon/citycon_video.sv:949 VIRTUAL PALETTE WRITEBACK FSM (MAME 1:1 implementation) Ogni frame in vblank esegue il loop: for offs=0..255: indx=linecolor[offs]; for i=0..3: palette[640+4offs+i] = palette[512+4*indx+i] 1024 entries × 2 byte = 2048 byte trasferiti per f
ComputerSpace# Computer Space MiSTer-devel/Arcade-ComputerSpace_MiSTer @ c9912443 MAME driver: not found Read: 13 HDL files, 7,046 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	77%
Statements: 14 toward hardware Cites hardware documentation that MAME's driver does not — 14 rtl/computer_space_logic.vhd:11 Naming convention: -- Sync Star Board inputs/outputs are labelled SB_<nn>, where <nn> is -- according to original schematics input/output labels. rtl/computer_space_logic.vhd:13 -- Motion Board inputs/outputs are labelled MB_<nn>, where <nn> is -- according to original schematics input/output labels. rtl/computer_space_logic.vhd:15 -- Memory Board inputs/outputs are labelled MemBrd_<nn>, where <nn> is -- according to original schematics input/output labels. rtl/computer_space_top.vhd:33 -- * Computerspacefan.com - who has provided sound samples and -- original schematics -- * Chris (http://www.pyroelectro.com/) whose code for interlaced -- ntsc signalling I have kindly used as a basis for creating an -- rtl/computer_space_top.vhd:54 Turn and both missiles sounds are produced exactly in the same way as in the original desing (based on schematics analysis) : gated frequency from saucer and missile counters on motion board. rtl/computer_space_top.vhd:61 From schematics one gets that these sounds come from a single noise generator. rtl/memory_board.vhd:3 -- Implementation of Computer Space's Memory Board -- "wire by wire" and "component by component"/"gate by gate" -- according to original schematics. rtl/memory_board.vhd:41 -- Memory Board inputs/outputs are labelled MemBrd_<nn>, where <nn> is -- according to original schematics input/output labels. rtl/memory_board.vhd:962 otherwise include logic as per schematics to get sound frequency input via e6_13. rtl/motion_board.vhd:3 -- Implementation of Computer Space's Motion Board -- "wire by wire" and "component by component"/"gate by gate" based on -- original schematics. rtl/motion_board.vhd:29 -- Motion Board inputs/outputs are labelled MB_<nn>, where <nn> is -- according to original schematics input/output labels. rtl/sync_star_board.vhd:2 SYNC STAR BOARD -- For use with Computer Space FPGA emulator -- Implementation of Computer Space's Sync Star Board -- "wire by wire" and "component by component"/"gate by gate" based on -- original schema rtl/sync_star_board.vhd:32 -- Sync Star Board inputs/outputs are labelled SB_<nn>, where <nn> is -- according to original schematics input/output labels. rtl/sync_star_board.vhd:302 As it is not according to original schematics it is -- placed in a separate entity to isolate from rest of original -- schematics.
CongoBongo# Congo Bongo MiSTer-devel/Arcade-CongoBongo_MiSTer @ 22dbeae5 MAME compared: sega/zaxxon.cpp + 7 related file(s) Read: 14 HDL files, 4,286 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	35%
Statements: 2 toward MAME Cites MAME source — 2 rtl/congo_bongo.vhd:34 Use with MAME roms from congo.zip rtl/sn76489/sn76489_noise.vhd:199 Tapped bits according to MAME's sn76496.c, implemented in function lfsr_tapped_f.
Cosmic# Cosmic Alien, Devil Zone, Magical Spot, Sengoku no Jieitai … MiSTer-devel/Arcade-Cosmic_MiSTer @ 33b7ede2 MAME compared: universal/cosmic.cpp + 2 related file(s) Read: 13 HDL files, 7,124 lines (Quartus project)	MiSTer official	Mostly MAME	low	31%
Statements: 20 toward MAME Cites MAME source — 2 Arcade-Cosmic.sv:367 JPAC/IPAC/MAME Style Codes rtl/Cosmic_video.vhd:626 _N zero = no sprite to be drawn bit 7 : 0 = 32x32,1 = 16x16 bit 6 : 0 = left to right, 1 = right to left rest : inverse of sprite number (see C) _X horizontal position inverted _Y vertical position inverted - 1 (from Mame) _C bit Shares text with the MAME driver without saying so — 18 rtl/Cosmic.vhd:311 map(0x4000, 0x5fff).ram().share("videoram"); — shares text with universal/cosmic.cpp:286 rtl/Cosmic.vhd:312 map(0x6000, 0x601f).writeonly().share("spriteram"); — shares text with universal/cosmic.cpp:287 rtl/Cosmic.vhd:317 map(0x7000, 0x700b).w(FUNC(cosmic_state::panic_sound_output_w)); — shares text with universal/cosmic.cpp:292 rtl/Cosmic.vhd:318 map(0x700c, 0x700e).w(FUNC(cosmic_state::cosmic_color_register_w)); — shares text with universal/cosmic.cpp:293 rtl/Cosmic.vhd:319 map(0x700f, 0x700f).w(FUNC(cosmic_state::flip_screen_w)); — shares text with universal/cosmic.cpp:294 rtl/Cosmic.vhd:320 map(0x7800, 0x7801).w(FUNC(cosmic_state::panic_sound_output2_w)); — shares text with universal/cosmic.cpp:295 rtl/Cosmic.vhd:324 map(0x3800, 0x3807).r(FUNC(cosmic_state::magspot_coinage_dip_r)); — shares text with universal/cosmic.cpp:317 rtl/Cosmic.vhd:325 map(0x4000, 0x401f).writeonly().share("spriteram"); — shares text with universal/cosmic.cpp:318 rtl/Cosmic.vhd:326 map(0x4800, 0x4800).w(FUNC(cosmic_state::dac_w)); — shares text with universal/cosmic.cpp:319 rtl/Cosmic.vhd:327 map(0x480c, 0x480d).w(FUNC(cosmic_state::cosmic_color_register_w)); — shares text with universal/cosmic.cpp:320 rtl/Cosmic.vhd:328 map(0x480f, 0x480f).w(FUNC(cosmic_state::flip_screen_w)); — shares text with universal/cosmic.cpp:321 rtl/Cosmic.vhd:333 map(0x6000, 0x7fff).ram().share("videoram"); — shares text with universal/cosmic.cpp:326 rtl/Cosmic.vhd:337 map(0x4000, 0x5fff).ram().share("videoram"); — shares text with universal/cosmic.cpp:286 rtl/Cosmic.vhd:338 map(0x6000, 0x601f).writeonly().share("spriteram"); — shares text with universal/cosmic.cpp:287 rtl/Cosmic.vhd:342 map(0x6803, 0x6803).r(FUNC(cosmic_state::cosmica_pixel_clock_r)); — shares text with universal/cosmic.cpp:307 rtl/Cosmic.vhd:343 map(0x7000, 0x700b).w(FUNC(cosmic_state::cosmica_sound_output_w)); — shares text with universal/cosmic.cpp:292 rtl/Cosmic.vhd:344 map(0x700c, 0x700d).w(FUNC(cosmic_state::cosmic_color_register_w)); — shares text with universal/cosmic.cpp:309 rtl/Cosmic.vhd:345 map(0x700f, 0x700f).w(FUNC(cosmic_state::flip_screen_w)); — shares text with universal/cosmic.cpp:294
CosmicGuerilla# Cosmic Guerilla MiSTer-devel/Arcade-CosmicGuerilla_MiSTer @ 3d39320a MAME compared: universal/cosmicg.cpp Read: 11 HDL files, 4,588 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	31%
Statements: 3 toward MAME Cites MAME source — 2 Arcade-CosmicGuerilla.sv:373 JPAC/IPAC/MAME Style Codes README.md:25 It also does this in Mame. Shares text with the MAME driver without saying so — 1 rtl/CosmicGuerilla.vhd:435 map(0x2000, 0x3fff).ram().share("videoram"); — shares text with universal/cosmicg.cpp:232
CrazyBalloon# Crazy Balloon MiSTer-devel/Arcade-CrazyBalloon_MiSTer @ 7ea1d452 MAME compared: taito/crbaloon.cpp + 3 related file(s) Read: 13 HDL files, 7,935 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	4%
Statements: 1 toward hardware Cites hardware documentation that MAME's driver does not — 1 rtl/CrazyBalloon_audio.vhd:90 Music circuit (74LS273, 2 x 74LS161 & 74LS93) similar to one in galaxian, different divider chip
CrazyClimber# Crazy Climber MiSTer-devel/Arcade-CrazyClimber_MiSTer @ c52b6e8b MAME compared: nichibutsu/cclimber.cpp Read: 15 HDL files, 6,106 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	11%
Statements: 1 toward MAME Cites MAME source — 1 rtl/ym_2149_linmix.vhd:44 Clues from MAME sound driver and Kazuhiro TSUJIKAWA
CrazyKong# Crazy Kong, Crazy Kong Part II MiSTer-devel/Arcade-CrazyKong_MiSTer @ ee03d1cb MAME compared: nichibutsu/cclimber.cpp Read: 14 HDL files, 5,940 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	11%
Statements: 1 toward MAME Cites MAME source — 1 rtl/ym_2149_linmix.vhd:44 Clues from MAME sound driver and Kazuhiro TSUJIKAWA
CrystalCastles# Crystal Castles MiSTer-devel/Arcade-CrystalCastles_MiSTer @ 8df9caf3 MAME compared: atari/ccastles.cpp Read: 25 HDL files, 3,774 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	8%
Statements: 2 toward hardware, 1 not counted Cites hardware documentation that MAME's driver does not — 2 rtl/SupportChips.v:186 82S09 64 X 9 RAM Color RAM README.md:46 Created using original schematics, and insight from own tools and tests with a custom diagnostic rom. Cites hardware references or measurements that MAME's driver also gives — 1 README.md:48 82S129 PROMs were replaced by their equivalent logic expressions. — also in MAME: 82S129 atari/ccastles.cpp:913
Darius# Darius MiSTer-devel/Arcade-Darius_MiSTer @ a85cac5e MAME compared: taito/darius.cpp + 4 related file(s) Read: 42 HDL files, 17,074 lines (Quartus project)	MiSTer official	Mostly MAME	medium	34%
Statements: 1 toward hardware, 41 toward MAME Cites hardware documentation that MAME's driver does not — 1 Template.sv:746 Base periodo Darius = 16 quarti (4 clk @96M = 24MHz pixel): clamp minimo 8 quarti (2 clk) — hsize molto negativo non puo' azzerare il periodo. Cites MAME source — 33 Template.sv:293 --- Joystick to Darius input mapping --- MiSTer joy bits: 0=R, 1=L, 2=D, 3=U, 4=Fire(A), 5=Bomb(B), 6=Start1P, 7=Start2P, 8=Coin Darius P1 ($C00008): active low, bits: 7=unused,6=unused,5=Fire2,4=Fire1,3=U,2=D,1=L,0=R Darius P2 ($C0000A): s Template.sv:304 MAME SYSTEM port ($C0000C) bit layout: bit 7:6 = unused (idle=0, IP_ACTIVE_HIGH) bit 5 = start2 (active LOW, idle=1) bit 4 = start1 (active LOW, idle=1) Template.sv:309 bit 2 = service(active LOW, idle=1) — not mapped, hardcode idle bit 1 = coin2 (active HIGH, idle=0) bit 0 = coin1 (active HIGH, idle=0) MiSTer joy bits: [3:0]=R,L,D,U [4]=A [5]=B [10]=Start [11]=Coin [12]=Pause MAME SYSTEM port rtl/darius/audio_mixer_gain.sv:45 DEFAULT PER CANALE — UNICO PUNTO DA MODIFICARE Valori iniziali = coefficienti MAME-ratio attuali del mixer (FM:PSG:MSM = 0.60:0.08:1.00). rtl/darius/audio_mixer_gain.sv:50 Default x4 vs coeff MAME originali (154/5284/4071): base forte (oltre il 200% della taratura precedente). rtl/darius/darius_audio_z80.sv:27 MAME memory maps: Z80 #1: 0000-3FFF ROM (fixed), 4000-7FFF ROM (banked, 4×16KB), 8000-8FFF RAM (4KB), 9000-9001 YM2203#1, A000-A001 YM2203#2, B000 PC060HA port_w, B001 PC060HA comm R/W, C000/C400/C800/CC00/D000 pan regs, D400 ADPCM cmd, DC0 rtl/darius/darius_audio_z80.sv:248 Z80 #1 reset: global reset OR PC060HA sub-reset (MAME: only main audio CPU) rtl/darius/darius_audio_z80.sv:468 Volume registers from YM2203 I/O ports (MAME: write_portA0/B0/A1/B1) rtl/darius/darius_audio_z80.sv:494 Volume directly from YM2203 I/O port outputs (combinatorial, no extra registers) MAME: write_portA0 = YM1 IOA, write_portB0 = YM1 IOB, etc. rtl/darius/darius_audio_z80.sv:540 NMI enable gate + data write (MAME: port 0x00=nmi_disable, 0x01=nmi_enable, 0x02=adpcm_data) rtl/darius/darius_audio_z80.sv:562 MSM5205 data + reset (MAME: m_msm->data_w(data), m_msm->reset_w(!(data & 0x20))) rtl/darius/darius_audio_z80.sv:642 --- Z80 #2 I/O read: port 0x00=cmd, 0x02/0x03=0 (MAME), else 0xFF --- rtl/darius/darius_audio_z80.sv:696 Audio mixer — MAME-ratio-matched, 3-stage pipeline rtl/darius/darius_audio_z80.sv:698 Coefficients scaled for jt03 integer output ranges (not MAME floats). rtl/darius/darius_audio_z80.sv:703 --- Stage 0: pv quantization (MAME-exact: (pan * vol) >> 8) — REGISTERED --- rtl/darius/darius_dual68k_top.sv:75 MAME SYSTEM port: {00,start2,start1,tilt,service,coin2,coin1} rtl/darius/darius_maincpu_map.sv:63 MAME SYSTEM port: {00,start2,start1,tilt,service,coin2,coin1} rtl/darius/darius_maincpu_map.sv:238 Coin lockout/counter register (MAME: m_coin_word, written at $C00060, read back at $C0000E) rtl/darius/darius_maincpu_map.sv:747 Coin lockout: MAME coin_lockout_w(0, ~data & 0x02) → bit1=0 locks COIN1 MAME coin_lockout_w(1, ~data & 0x04) → bit2=0 locks COIN2 rtl/darius/darius_panel_renderer.sv:256 Source pixel coordinates with scroll + panel offset (selects by current layer) MAME set_offsets(-16, 8): L0 xoff=-16, L1 xoff=+8 MAME Y: L0 +8, L1 0 rtl/darius/darius_sprite_renderer.sv:27 Sprite RAM format (MAME, 4 words per entry at $E00100): word[0]: Y position → sy = (256 - data) & 0x1FF word[1]: X position → sx = data & 0x3FF word[2]: tile code[12:0], flipX[14], flipY[15] word[3]: priority[7], color[6:0] rtl/darius/darius_sprite_renderer.sv:48 X offset (scroll-dependent, from MAME draw_sprites x_offs parameter) rtl/darius/darius_sprite_renderer.sv:93 y_offs = -8 from MAME + north adjust rtl/darius/darius_sprite_renderer.sv:314 Pixel extraction: bit-per-plane (MAME method) rtl/darius/darius_sprite_renderer.sv:322 This was confirmed by: - Debug overlay showing PA=646 (pixel 6) where MAME expects pixel 5 - Systematic HW testing of 8+ permutations - PA lookup live showing correct bank 0x64x entries with this mapping The effective byte layout observed o rtl/darius/darius_sprite_renderer.sv:333 MAME pixel = {plane3_bit, plane2_bit, plane1_bit, plane0_bit} rtl/darius/darius_sprite_renderer.sv:610 Draw 8 pixels from current ROM word (bit-per-plane, MAME method) rtl/darius/pc060ha_link.sv:25 Single-clock rewrite ispirato a jtrastan_pc060 (JTCORES by Jose Tejada), implementato secondo la descrizione di pc060ha_device in MAME. rtl/darius/triple_screen_test.sv:127 Sprite overlay (MAME priority: prio_transpen + primask) sprite_prio=1 (primask=0): covers everything sprite_prio=0 (GFX_PMASK_2): covers L0 (tile_prio=01) but NOT L1 (tile_prio=10) README.md:9 This core reimplements the hardware in SystemVerilog from MAME references and hardware observation on original PCBs. README.md:76 Dual 68000 main/sub with shared RAM (FX68K core), PC060HA master/slave communication reproduced from MAME README.md:82 Palette with MAME-verified byte order README.md:105 Palette with MAME-verified byte order Says it matches, follows or was checked against MAME — 5 rtl/darius/darius_audio_z80.sv:586 S1=1, S0=0 → divide by 48 → 384K/48 = 8KHz (matches MAME) rtl/darius/darius_audio_z80.sv:699 FM:PSG:MSM ratios match MAME route gains (0.60 : 0.08 : 1.00). rtl/darius/darius_audio_z80.sv:730 --- Stage 0b: coefficients (coeff × pv) — REGISTERED --- Ratios FM:PSG:MSM match MAME route gains (0.60 : 0.08 : 1.00). rtl/darius/darius_panel_renderer.sv:420 prio: L0=01, L2=10 (matches MAME priority bitmap values) rtl/darius/darius_sprite_renderer.sv:227 Verificato: MAME attract (slot 7 = code $3E6 128/128 frame demo) + Darius-Native main_annotated.md ("La nave è a $E00138, code $3E6"). Shares text with the MAME driver without saying so — 3 rtl/darius/darius_audio_z80.sv:562 MSM5205 data + reset (MAME: m_msm->data_w(data), m_msm->reset_w(!(data & 0x20))) — shares text with taito/darius.cpp:701 rtl/darius/darius_maincpu_map.sv:747 Coin lockout: MAME coin_lockout_w(0, ~data & 0x02) → bit1=0 locks COIN1 — shares text with taito/darius.cpp:400 rtl/darius/darius_maincpu_map.sv:748 MAME coin_lockout_w(1, ~data & 0x04) → bit2=0 locks COIN2 — shares text with taito/darius.cpp:401
Darius2NinjaWarriors# Darius II, The Ninja Warriors MiSTer-devel/Arcade-Darius2NinjaWarriors_MiSTer @ 03224c45 MAME compared: taito/ninjaw.cpp + 7 related file(s) Read: 31 HDL files, 11,243 lines (Quartus project)	MiSTer official	Mostly MAME	medium	69%
Statements: 2 toward hardware, 106 toward MAME Notes where it differs from MAME — 2 rtl/darius2/darius2_dual68k_top.sv:1418 Port B VRAM addr/we/din: chip MAME non usa SA/SDout/WE legacy; l'arbiter Port B è guidato da scn_m_vram_b_addr (vedi mux scn_pb_addr più sotto). rtl/darius2/tc_mame/tc0100scn_mame.sv:207 Chip MAME non finisce la scansione dentro hblank window (2652 clk a 96/24). Cites MAME source — 86 Template.sv:253 --- Joystick to Darius 2 / Ninja Warriors input mapping --- MAME ninjaw.cpp IN0 (= p1_input, TC0040IOC port $02): bit 0: UNKNOWN ACTIVE_HIGH ("Stops working if this is high") — MUST be 0 bit 1: UNKNOWN ACTIVE_LOW — idle=1 bit 2: COIN1 Template.sv:266 MAME ninjaw.cpp IN2 (= system_input, TC0040IOC port $07): bit 0: SERVICE1 ACTIVE_LOW — idle=1 bit 1: TILT ACTIVE_LOW — idle=1 bit 2: START1 ACTIVE_LOW — idle=1 (pressed=0) bit 3: START2 ACTIVE_LOW — idle=1 bit 4: P1 BTN1 ACTIVE Template.sv:276 Layout MAME: [3:0] P1 U D R L, [7:4] P2 U D R L (Right prima di Left). Template.sv:282 MAME ninjaw IN2 (= system_input, TC0040IOC port $07): bit 0: SERVICE1 ACTIVE_LOW — idle=1 bit 1: TILT ACTIVE_LOW — idle=1 bit 2: START1 ACTIVE_LOW — idle=1 (pressed=0) bit 3: START2 ACTIVE_LOW — idle=1 bit 4: P1 BTN1 ACTIVE_LOW Template.sv:507 Hardcoded 12 MHz (Darius 2 original MAME rate). Template.sv:589 1-bit OSD: 0=Polite (default), 1=MAME (100%) Template.sv:751 MAME warning overlay: "DON'T BREAK YOUR WOOFER!" per ~3s su edge status[95] rtl/darius2/darius2_audio_top.sv:150 Sound RAM 8 KB (0xC000-0xDFFF MAME) rtl/darius2/darius2_audio_top.sv:165 MAME ninjaw_state::sound_bankswitch_w mappa 0xF200 (memory write, non I/O). rtl/darius2/darius2_audio_top.sv:273 Routing MAME ninjaw.cpp:633-652: pan_data[0] = FM L gain ($E401 dopo XOR^1) pan_data[1] = FM R gain ($E400 dopo XOR^1) pan_data[2] = ADPCM L gain ($E403 dopo XOR^1) pan_data[3] = ADPCM R gain ($E402 dopo XOR^1) (offset ^= 1 prima rtl/darius2/darius2_audio_top.sv:285 MAME: offset ^= 1 rtl/darius2/darius2_audio_top.sv:303 PSG resta non panneggiato (in MAME va al subwoofer mono, qui lo sommo a entrambi i canali). rtl/darius2/darius2_audio_top.sv:341 PSG: solo 2 valori OSD (Polite=12% default, MAME=100%). rtl/darius2/darius2_audio_top.sv:342 0=Polite (1/8), 1=MAME (8/8) rtl/darius2/darius2_audio_top.sv:345 MIXER NUOVO — interpretazione MAME-fedele basata su audit ymfm + ninjaw.cpp rtl/darius2/darius2_audio_top.sv:353 MAME ninjaw routing (ninjaw.cpp:992-1003): add_route(0, "subwoofer", 0.75) → PSG mono 0.75 add_route(1, "2610.1.l", 1.0) → FM_L → flt[0] (m_2610_l[0]) add_route(1, "2610.1.r", 1.0) → FM_L → flt[1] (m_2610_r[0]) ← stesso input! rtl/darius2/darius2_audio_top.sv:360 pancontrol_w (ninjaw.cpp:633-652) decode con offset XOR^1: $E400 → flt[1] (FM_L verso speaker R) = pan_data[1] mio $E401 → flt[0] (FM_L verso speaker L) = pan_data[0] mio $E402 → flt[3] (FM_R verso speaker R) = pan_data[3] mio $E403 → flt[2 rtl/darius2/darius2_audio_top.sv:370 PSG va al subwoofer mono (in MAME) — qui sommato a entrambi audio_l/r. rtl/darius2/darius2_dual68k_top.sv:75 MAME SYSTEM port: {00,start2,start1,tilt,service,coin2,coin1} rtl/darius2/darius2_dual68k_top.sv:90 SCN rate selector rimosso — SCN ora usa ce_13m fisso (13.33 MHz, MAME-accurate). rtl/darius2/darius2_dual68k_top.sv:426 Main CPU clock divider (96MHz / den) Default 0 = 12 MHz (Darius 2 originale MAME: XTAL 24MHz/2). rtl/darius2/darius2_dual68k_top.sv:430 96/8 = 12MHz (original MAME default) rtl/darius2/darius2_dual68k_top.sv:439 Sub CPU clock divider (96MHz / den) Default 0 = 12 MHz (Darius 2 originale MAME). rtl/darius2/darius2_dual68k_top.sv:443 96/8 = 12MHz (original MAME default) rtl/darius2/darius2_dual68k_top.sv:779 --- CPU → TC0100SCN chip selects --- From MAME darius2_master_map: $280000-$293FFF → SCN[0] RAM (read + write-through to all 3) $2A0000-$2A000F → SCN[0] ctrl $2C0000-$2D3FFF → SCN[1] RAM $2E0000-$2E000F → SCN[1] ctrl $300000-$313FFF → SCN[2 rtl/darius2/darius2_dual68k_top.sv:807 TC0140SYT sound comm (MAME ninjaw_master_map): 0x220000-0x220001 = master_port_w (MA1=0) 0x220002-0x220003 = master_comm_r/w (MA1=1) rtl/darius2/darius2_dual68k_top.sv:868 TC0100SCN ce_pixel: fisso a 13.33 MHz (MAME-accurate Darius 2 XTAL 26.686/2). rtl/darius2/darius2_dual68k_top.sv:943 Fix #36: triple_screen_w writethrough (MAME ninjaw_state::tc0100scn_triple_screen_w). rtl/darius2/darius2_dual68k_top.sv:944 Per MAME ninjaw.cpp:655-660, scritture CPU a $280000-$293FFF (range SCN0) sono replicate SIMULTANEAMENTE su tutti e 3 i TC0100SCN. rtl/darius2/darius2_dual68k_top.sv:1028 MAME TC0100SCN wide mode: 0x00000-0x0FFFF = SCE0 (64KB = 32K word), 0x10000-0x13FFF = SCE1 (16KB = 8K word). rtl/darius2/darius2_dual68k_top.sv:1224 Il chip MAME ha cen=1 solo quando scn_arb_phase == suo indice → FSM renderer avanza 1/3 dei clk, ma quando avanza il dato Port B è già il suo (nessuna collisione su mirror VRAM, nessuna latenza arbiter da gestire). rtl/darius2/darius2_dual68k_top.sv:1247 Seleziona addr corrente in base a phase MAME chip emette vram_b_addr[15:0] direttamente (bit 15 = main/ext selector, stesso encoding di scn{N}_ram_full_addr del Donlon). rtl/darius2/darius2_dual68k_top.sv:1310 --- TC0100SCN instances (Donlon reference RTL) --- MAME Darius 2: set_offsets(22,0), multiscr_xoffs 0/2/4 per chip 0/1/2. rtl/darius2/darius2_dual68k_top.sv:1386 DONLON TIE-OFFS — wire ex-Donlon ora guidati dai chip MAME o costanti. rtl/darius2/darius2_dual68k_top.sv:1390 render_x per pannello (moved up da sotto: servono ai chip MAME e agli assign hcnt qui sotto. rtl/darius2/darius2_dual68k_top.sv:1397 CPU path: redirigi dout/dack dai chip MAME (CRITICO per CPU reads/DTACK) rtl/darius2/darius2_dual68k_top.sv:1405 SC → palette (MAME chip emette SC diretto a render_x) rtl/darius2/darius2_dual68k_top.sv:1410 Tile ROM interface → MAME chip rtl/darius2/darius2_dual68k_top.sv:1433 main selector (unused with chip MAME) rtl/darius2/darius2_dual68k_top.sv:1459 MAME-model TC0100SCN instances (3×) — PARALLEL with Donlon for now. rtl/darius2/darius2_dual68k_top.sv:1461 In Step 3 Donlon will be disconnected and MAME will drive SC, rom_req, etc. rtl/darius2/darius2_dual68k_top.sv:1480 MAME chip signals (parallel to Donlon, not connected to system yet) rtl/darius2/darius2_dual68k_top.sv:1584 Palette chip selects (from MAME darius2_master_map) rtl/darius2/darius2_dual68k_top.sv:1758 --- Palette lookup: BYPASS scn_line_buffer esterno (Donlon-legacy) --- Il chip MAME emette SC sincrono a render_x, NON serve ping-pong 13→24. rtl/darius2/darius2_dual68k_top.sv:1760 Replica la logica sprite_wins del TC0110PR per blending corretto: FG vince sempre Sprite prio 0 vince su BG top (mid in MAME primask) e BG bottom Sprite prio 1 vince solo su BG bottom (sotto BG top/mid) SC[14:13] encoding (da tc0100scn_mame rtl/darius2/darius2_maincpu_map_new.sv:24 MAME: darius2_master_map (ninjaw.cpp) rtl/darius2/darius2_maincpu_map_new.sv:266 --- CPUA ctrl --- MAME cpua_ctrl_w: if only high byte is written (UDS only), shift high→low so bit 0 of the low byte is correctly set. rtl/darius2/darius2_maincpu_map_new.sv:275 MAME-style high-byte-only normalization rtl/darius2/darius2_maincpu_map_new.sv:285 --- TC0140SYT sound comm (real, no stub) --- MAME: $220001=master_port_w, $220003=master_comm_r/w Pilotiamo cs/wr/rd/a1 al TC0140SYT vero in audio_top. rtl/darius2/darius2_sprite_renderer.sv:27 Sprite RAM format (MAME, 4 words per entry at $E00100): Darius 2 sprite format (ninjaw.cpp): word[0]: X position → sx = (data - 32) & 0x3FF word[1]: Y position → sy = data & 0x1FF word[2]: tile code[14:0] (0 = skip) word[3]: flipX[0], flipY rtl/darius2/darius2_sprite_renderer.sv:45 X offset (scroll-dependent, from MAME draw_sprites x_offs parameter) rtl/darius2/darius2_sprite_renderer.sv:87 y_offs = -8 from MAME + north adjust rtl/darius2/darius2_sprite_renderer.sv:236 Priority mask MAME bit3 attr "unknown priority": pixel scritto da sprite con attr[3]=1 → prio_lb=1, vince anche su pixel gia' scritti da sprite con attr[3]=0. rtl/darius2/darius2_sprite_renderer.sv:332 scn_sc[T+2] = pixel render_x[T] = render_x[T+2] - 2 (chip MAME stessa pipeline). rtl/darius2/darius2_sprite_renderer.sv:351 Pixel extraction — formula derivata da MAME drawgfx.cpp readbit: src[bitnum/8] & (0x80 >> (bitnum%8)) → bit 0 del char = MSB del byte. rtl/darius2/darius2_sprite_renderer.sv:581 bit3 MAME rtl/darius2/darius2_sprite_renderer.sv:604 bit3 MAME rtl/darius2/darius2_sprite_renderer.sv:655 Lancia req ROM direttamente in RD_POP (mask 14-bit MAME drawgfx) rtl/darius2/darius2_sprite_renderer.sv:817 sprite_ob combinatorio da spr_disp_word (già registrato 1 clk da line buffer), allineato a scn_sc (anche registrato 1 clk dal chip MAME). rtl/darius2/darius2_subcpu_map_new.sv:24 MAME: darius2_slave_map (ninjaw.cpp) rtl/darius2/darius2_subcpu_map_new.sv:109 MAME ninjaw_slave_map (ninjaw.cpp:699-701): sub scrive palette dei 3 schermi. rtl/darius2/mame_warning_overlay.sv:22 mame_warning_overlay.sv — testo statico "DON'T BREAK YOUR WOOFER!" che appare per ~3 secondi quando l'utente attiva PSG=MAME nell'OSD audio mixer. rtl/darius2/pc060ha_link.sv:25 Single-clock rewrite ispirato a jtrastan_pc060 (JTCORES by Jose Tejada), implementato secondo la descrizione di pc060ha_device in MAME. rtl/darius2/tc0040ioc.sv:14 In MAME è un singolo chip con un solo m_port register. rtl/darius2/tc0110pr.sv:110 MAME chip behaviour: cpu_mode only closes on explicit VA=10. rtl/darius2/tc0110pr.sv:132 Priority MAME ninjaw (draw_sprites + primask): sprite prio 0 (OB[13]=0): sotto FG, sopra tutto il resto sprite prio 1 (OB[13]=1): sotto FG, sotto MID layer, sopra BOTTOM SC[14:13] dal chip MAME tc0100scn codifica il RUOLO del layer visibile rtl/darius2/tc0110pr.sv:154 layer BG "top" → MAME mid rtl/darius2/tc0140syt.sv:101 MAME ninjaw usa NMI per svegliare Z80 al ricevimento comando audio. rtl/darius2/tc_mame/tc0100scn_mame.sv:22 tc0100scn_mame.sv — TC0100SCN, MAME-accurate scanline renderer. rtl/darius2/tc_mame/tc0100scn_mame.sv:24 Reference: MAME tc0100scn.cpp + ninjaw.cpp (Darius 2). rtl/darius2/tc_mame/tc0100scn_mame.sv:25 Scroll math, tile lookup, pixel decode follow MAME exactly. rtl/darius2/tc_mame/tc0100scn_mame.sv:33 MAME VRAM layout (wide mode, word offsets): $0000-$3FFF BG0 attrib+code (128×64 tiles, 2 words/tile) $4000-$7FFF BG1 attrib+code (128×64 tiles, 2 words/tile) $8000-$81FF BG0 row scroll (256 words) $8200-$83FF BG1 row scroll (256 words) rtl/darius2/tc_mame/tc0100scn_mame.sv:53 0 = primo chip, 1 = chip successivi (flag MAME) rtl/darius2/tc_mame/tc0100scn_mame.sv:118 Formula MAME (tc0100scn.cpp:285-286): xd = -m_x_offset - m_multiscrn_xoffs; yd = 8 - m_y_offset; → Chip 0: xd=-22, chip 1: xd=-24, chip 2: xd=-26; yd uguale per tutti (8). rtl/darius2/tc_mame/tc0100scn_mame.sv:122 cliprect.top di ninjaw.cpp:938 = 38 = 24. rtl/darius2/tc_mame/tc0100scn_mame.sv:122 MAME fa src_y += cliprect.top, equivale a usare effettivo scrolldy = yd - cliprect.top = 8 - 24 = -16. rtl/darius2/tc_mame/tc0100scn_mame.sv:141 VRAM bases CONDIZIONATI su wide/single (MAME spec). rtl/darius2/tc_mame/tc0100scn_mame.sv:344 BUG3 fix: Row scroll index MAME (tc0100scn.cpp:623). rtl/darius2/tc_mame/tc0100scn_mame.sv:345 MAME mappa j-esimo rowscroll_ram a tilemap row (j + bgscrolly). rtl/darius2/tc_mame/tc0100scn_mame.sv:395 MAME lo fa internamente nel gfx_element (drawgfx code % elements()). rtl/darius2/tc_mame/tc0100scn_mame.sv:424 BUG3 fix: BG1 rowscroll index = (rline - SCROLLDY) & 0x1ff (MAME). rtl/darius2/tc_mame/tc0100scn_mame.sv:442 Col scroll per-tile (MAME tc0100scn.cpp:656): column_offset = colscroll_ram[src_x/8]; src_y_tile = line_sy - column_offset. rtl/darius2/triple_screen_test.sv:166 Sprite overlay (MAME ninjaw.cpp priority: "1 = low") prio=0 (primask GFX_PMASK_4): sprite sopra tutto tranne FG prio=1 (primask GFX_PMASK_4\|GFX_PMASK_2): sprite sotto L1 (tile_prio=10) Draw se: no tile opaco, OR prio=0, OR tile NON è L1. README.md:13 This core reimplements the hardware in SystemVerilog from MAME references and hardware observation. README.md:26 Three TC0100SCN tilemap chips (BG0 + BG1 + FG0 per panel) — MAME-accurate README.md:177 The MAME* project — invaluable hardware reference (TC0100SCN, memory maps, timing) Says it matches, follows or was checked against MAME — 1 rtl/darius2/sdram_bridge.sv:266 Word-swap concat (SIM-verified MAME-compliant). Says it was translated, ported or taken from MAME — 1 README.md:28 Sprite renderer with priority, flip, 16×16 4bpp tiles, MAME 1:1 wrap math Shares text with the MAME driver without saying so — 18 Template.sv:193 "P2O[43:38],BG0 X offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29,-2 — shares text with taito/tc0100scn.cpp:240 Template.sv:194 "P2O[49:44],BG0 Y offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29,-2 — shares text with taito/tc0100scn.cpp:240 Template.sv:195 "P2O[55:50],BG1 X offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29,-2 — shares text with taito/tc0100scn.cpp:240 Template.sv:196 "P2O[61:56],BG1 Y offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29,-2 — shares text with taito/tc0100scn.cpp:240 Template.sv:197 "P2O[67:62],Sprite X offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29 — shares text with taito/tc0100scn.cpp:240 Template.sv:198 "P2O[73:68],Sprite Y offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29 — shares text with taito/tc0100scn.cpp:240 Template.sv:199 "P2O[79:74],FG X offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29,-28 — shares text with taito/tc0100scn.cpp:240 Template.sv:200 "P2O[85:80],FG Y offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29,-28 — shares text with taito/tc0100scn.cpp:240 Template.sv:255 bit 0: UNKNOWN ACTIVE_HIGH ("Stops working if this is high") — MUST be 0 — shares text with taito/ninjaw.cpp:780 rtl/darius2/darius2_audio_top.sv:354 add_route(0, "subwoofer", 0.75) → PSG mono * 0.75 — shares text with taito/ninjaw.cpp:995 rtl/darius2/darius2_audio_top.sv:355 add_route(1, "2610.1.l", 1.0) → FM_L → flt[0] (m_2610_l[0]) — shares text with taito/ninjaw.cpp:996 rtl/darius2/darius2_audio_top.sv:356 add_route(1, "2610.1.r", 1.0) → FM_L → flt[1] (m_2610_r[0]) ← stesso input! — shares text with taito/ninjaw.cpp:997 rtl/darius2/darius2_audio_top.sv:357 add_route(2, "2610.2.l", 1.0) → FM_R → flt[2] (m_2610_l[1]) — shares text with taito/ninjaw.cpp:998 rtl/darius2/darius2_audio_top.sv:358 add_route(2, "2610.2.r", 1.0) → FM_R → flt[3] (m_2610_r[1]) — shares text with taito/ninjaw.cpp:999 rtl/darius2/darius2_dual68k_top.sv:943 Fix #36: triple_screen_w writethrough (MAME ninjaw_state::tc0100scn_triple_screen_w). — shares text with taito/ninjaw.cpp:656 rtl/darius2/darius2_maincpu_map_new.sv:269 if ((data & 0xff00) && ((data & 0xff) == 0)) data = data >> 8; — shares text with taito/ninjaw.cpp:606 rtl/darius2/tc_mame/tc0100scn_mame.sv:119 xd = -m_x_offset - m_multiscrn_xoffs; — shares text with taito/tc0100scn.cpp:287 rtl/darius2/triple_screen_test.sv:168 prio=1 (primask GFX_PMASK_4\|GFX_PMASK_2): sprite sotto L1 (tile_prio=10) — shares text with taito/ninjaw.cpp:480
Darius2WarriorBlade# Warrior Blade - Rastan Saga Episode III MiSTer-devel/Arcade-Darius2WarriorBlade_MiSTer @ 613c2453 MAME compared: taito/warriorb.cpp + 7 related file(s) Read: 29 HDL files, 10,674 lines (Quartus project)	MiSTer official	Mostly MAME	medium	68%
Statements: 3 toward hardware, 110 toward MAME Notes where it differs from MAME — 3 rtl/darius2/darius2_dual68k_top.sv:1156 MAME chip TC0100SCN (2× warriorb.cpp) — wire driver per Port A BRAM e segnali ausiliari ex-Donlon (tied 0/1'b1 dato che MAME non li espone). rtl/darius2/darius2_dual68k_top.sv:1188 Port B VRAM addr/we/din: chip MAME non usa SA/SDout/WE legacy; l'arbiter Port B è guidato da scn_m_vram_b_addr (vedi mux scn_pb_addr più sotto). rtl/darius2/tc_mame/tc0100scn_mame.sv:255 Chip MAME non finisce la scansione dentro hblank window (2652 clk a 96/24). Cites MAME source — 103 Template.sv:244 --- Joystick to game inputs --- IN0/IN1/IN2 per warriorb.cpp (TC0220IOC/TC0510NIO direct-mapped): IN0 (offset $02): bit0=SERVICE1, bit1=TILT, bit2=COIN1, bit3=COIN2, bit4=START1, bit5=START2, bit6-7=unknown (active_low). Template.sv:493 CPU clock parametrizzato per board (MAME-accurate), niente OSD: darius2d/sagaia : 68000 @ 12 MHz (XTAL 24MHz/2) → clk_sel code 0 warriorb : 68000 @ 16 MHz (warriorb.cpp) → clk_sel code 2 clk_sel code (divisore in darius2_dual68k_to Template.sv:498 Sub-CPU non esiste in warriorb.cpp (single 68000): allineato per coerenza. Template.sv:578 1-bit OSD: 0=Polite (default), 1=MAME (100%) Template.sv:741 MAME warning overlay: "DON'T BREAK YOUR WOOFER!" per ~3s su edge status[95] rtl/darius2/darius2_audio_top.sv:153 Sound RAM 8 KB (0xC000-0xDFFF MAME) rtl/darius2/darius2_audio_top.sv:168 MAME ninjaw_state::sound_bankswitch_w mappa 0xF200 (memory write, non I/O). rtl/darius2/darius2_audio_top.sv:276 Routing MAME ninjaw.cpp:633-652: pan_data[0] = FM L gain ($E401 dopo XOR^1) pan_data[1] = FM R gain ($E400 dopo XOR^1) pan_data[2] = ADPCM L gain ($E403 dopo XOR^1) pan_data[3] = ADPCM R gain ($E402 dopo XOR^1) (offset ^= 1 prima rtl/darius2/darius2_audio_top.sv:288 MAME: offset ^= 1 rtl/darius2/darius2_audio_top.sv:306 PSG resta non panneggiato (in MAME va al subwoofer mono, qui lo sommo a entrambi i canali). rtl/darius2/darius2_audio_top.sv:344 PSG: solo 2 valori OSD (Polite=12% default, MAME=100%). rtl/darius2/darius2_audio_top.sv:345 0=Polite (1/8), 1=MAME (8/8) rtl/darius2/darius2_audio_top.sv:348 MIXER NUOVO — interpretazione MAME-fedele basata su audit ymfm + ninjaw.cpp rtl/darius2/darius2_audio_top.sv:356 MAME ninjaw routing (ninjaw.cpp:992-1003): add_route(0, "subwoofer", 0.75) → PSG mono 0.75 add_route(1, "2610.1.l", 1.0) → FM_L → flt[0] (m_2610_l[0]) add_route(1, "2610.1.r", 1.0) → FM_L → flt[1] (m_2610_r[0]) ← stesso input! rtl/darius2/darius2_audio_top.sv:363 pancontrol_w (ninjaw.cpp:633-652) decode con offset XOR^1: $E400 → flt[1] (FM_L verso speaker R) = pan_data[1] mio $E401 → flt[0] (FM_L verso speaker L) = pan_data[0] mio $E402 → flt[3] (FM_R verso speaker R) = pan_data[3] mio $E403 → flt[2 rtl/darius2/darius2_audio_top.sv:373 PSG va al subwoofer mono (in MAME) — qui sommato a entrambi audio_l/r. rtl/darius2/darius2_audio_top.sv:384 MAME pancontrol_w (warriorb.cpp:378): gain = data3/100; ninjaw.cpp:649: data/255. rtl/darius2/darius2_audio_top.sv:440 Il PSG resta com'era (Polite=1/8, MAME=8/8 — non si tocca). rtl/darius2/darius2_audio_top.sv:561 Base offset per variant warriorb.cpp (selettore: board_warriorb): darius2d: main 1MB + (no sub) → Z80 0x100000 warriorb: main 2MB + (no sub) → Z80 0x200000 Layout: main → Z80 128KB → sprite → tile → ADPCM-A → [ADPCM-B solo d2d] rtl/darius2/darius2_dual68k_top.sv:70 Board variant: warriorb.cpp hardware (sempre 2-screen, single 68000). rtl/darius2/darius2_dual68k_top.sv:85 MAME SYSTEM port: {00,start2,start1,tilt,service,coin2,coin1} rtl/darius2/darius2_dual68k_top.sv:100 SCN rate selector rimosso — SCN ora usa ce_13m fisso (13.33 MHz, MAME-accurate). rtl/darius2/darius2_dual68k_top.sv:204 Forward decl per VRAM read data (Port A read-back chip MAME). rtl/darius2/darius2_dual68k_top.sv:218 Sub-CPU rimosso (warriorb.cpp = single 68000). rtl/darius2/darius2_dual68k_top.sv:393 Main CPU clock divider (96MHz / den) Default 0 = 12 MHz (Darius 2 originale MAME: XTAL 24MHz/2). rtl/darius2/darius2_dual68k_top.sv:397 96/8 = 12MHz (original MAME default) rtl/darius2/darius2_dual68k_top.sv:406 Sub CPU clock divider (96MHz / den) Default 0 = 12 MHz (Darius 2 originale MAME). rtl/darius2/darius2_dual68k_top.sv:410 96/8 = 12MHz (original MAME default) rtl/darius2/darius2_dual68k_top.sv:431 SCN/PAL range — warriorb.cpp: d2d : 0x200000-0x26FFFF SCN, 0x400000-0x42000F PAL wb : 0x300000-0x36FFFF SCN, 0x400000-0x42000F PAL rtl/darius2/darius2_dual68k_top.sv:518 Sub-CPU rimossa: warriorb.cpp = single 68000 (no shared RAM, no sub). rtl/darius2/darius2_dual68k_top.sv:555 darius2_subcpu_map rimosso (sub-CPU non esiste in warriorb.cpp). rtl/darius2/darius2_dual68k_top.sv:571 darius_shared_ram (shared main↔sub) rimossa: warriorb.cpp non ha sub-CPU, la mappa CPU non decoda quel range. rtl/darius2/darius2_dual68k_top.sv:649 --- CPU → TC0100SCN chip selects --- From MAME darius2_master_map: $280000-$293FFF → SCN[0] RAM (read + write-through to all 3) $2A0000-$2A000F → SCN[0] ctrl $2C0000-$2D3FFF → SCN[1] RAM $2E0000-$2E000F → SCN[1] ctrl $300000-$313FFF → SCN[2 rtl/darius2/darius2_dual68k_top.sv:665 SCN chip selects — warriorb.cpp: darius2d : SCN0 0x200000+ ctrl 0x220000 ; SCN1 0x240000+ ctrl 0x260000 warriorb : SCN0 0x300000+ ctrl 0x320000 ; SCN1 0x340000+ ctrl 0x360000 Niente SCN2 (esiste solo nel chip 3 di ninjaw). rtl/darius2/darius2_dual68k_top.sv:690 TC0140SYT sound comm (MAME ninjaw_master_map): 0x220000-0x220001 = master_port_w (MA1=0) 0x220002-0x220003 = master_comm_r/w (MA1=1) rtl/darius2/darius2_dual68k_top.sv:748 TC0100SCN ce_pixel: fisso a 13.33 MHz (MAME-accurate Darius 2 XTAL 26.686/2). rtl/darius2/darius2_dual68k_top.sv:817 Fix #36: triple_screen_w writethrough (MAME ninjaw_state::tc0100scn_triple_screen_w). rtl/darius2/darius2_dual68k_top.sv:818 Per MAME ninjaw.cpp:655-660, scritture CPU a $280000-$293FFF (range SCN0) sono replicate SIMULTANEAMENTE sui TC0100SCN. rtl/darius2/darius2_dual68k_top.sv:880 MAME TC0100SCN wide mode: 0x00000-0x0FFFF = SCE0 (64KB = 32K word), 0x10000-0x13FFF = SCE1 (16KB = 8K word). rtl/darius2/darius2_dual68k_top.sv:1110 MAME chip emette vram_b_addr[15:0] (bit 15 = main/ext selector). rtl/darius2/darius2_dual68k_top.sv:1160 render_x per pannello (moved up da sotto: servono ai chip MAME e agli assign hcnt qui sotto. rtl/darius2/darius2_dual68k_top.sv:1163 warriorb.cpp: 2 panel × 320 = 640 totali. rtl/darius2/darius2_dual68k_top.sv:1169 CPU path: redirigi dout/dack dai chip MAME (CRITICO per CPU reads/DTACK). rtl/darius2/darius2_dual68k_top.sv:1175 SC → palette (MAME chip emette SC diretto a render_x). rtl/darius2/darius2_dual68k_top.sv:1182 Tile ROM interface → MAME chip rtl/darius2/darius2_dual68k_top.sv:1199 main selector (unused with chip MAME) rtl/darius2/darius2_dual68k_top.sv:1210 MAME-model TC0100SCN instances (3×) — PARALLEL with Donlon for now. rtl/darius2/darius2_dual68k_top.sv:1212 In Step 3 Donlon will be disconnected and MAME will drive SC, rom_req, etc. rtl/darius2/darius2_dual68k_top.sv:1230 MAME chip signals rtl/darius2/darius2_dual68k_top.sv:1322 u_scn_mame_2 (chip 3 ninjaw) rimosso: warriorb.cpp = 2 chip SCN. rtl/darius2/darius2_dual68k_top.sv:1426 pal2 (TC0110PR chip 3) rimossa: warriorb.cpp = 2 palette chip. rtl/darius2/darius2_dual68k_top.sv:1431 scn0_sc/scn1_sc emessi sincroni dai chip MAME → consumati direttamente dal compositor sotto. rtl/darius2/darius2_dual68k_top.sv:1434 --- Palette lookup: BYPASS scn_line_buffer esterno (Donlon-legacy) --- Il chip MAME emette SC sincrono a render_x, NON serve ping-pong 13→24. rtl/darius2/darius2_dual68k_top.sv:1436 Replica la logica sprite_wins del TC0110PR per blending corretto: FG vince sempre Sprite prio 0 vince su BG top (mid in MAME primask) e BG bottom Sprite prio 1 vince solo su BG bottom (sotto BG top/mid) SC[14:13] encoding (da tc0100scn_mame rtl/darius2/darius2_dual68k_top.sv:1582 Range MRA per variant (warriorb.cpp): darius2d: main 1MB + Z80 128KB → sprite a 0x120000-0x31FFFF (2MB) warriorb: main 2MB + Z80 128KB → sprite a 0x220000-0x61FFFF (4MB) rtl/darius2/darius2_dual68k_top.sv:1604 Output mux: select panel based on render_x Tile-RGB mux per warriorb.cpp: 2 panel a 320 px (threshold 320). rtl/darius2/darius2_maincpu_map_new.sv:24 MAME: darius2_master_map (ninjaw.cpp) rtl/darius2/darius2_maincpu_map_new.sv:142 --- Decode tables for warriorb.cpp variants (single 68000, 2-screen) --- darius2d: ROM 0x000000-0x0FFFFF (1MB: 512KB code + 512KB data) RAM 0x100000-0x10FFFF SCN0 0x200000-0x213FFF / ctrl 0x220000 SCN1 0x240000-0x253FFF / ctrl 0x26000 rtl/darius2/darius2_maincpu_map_new.sv:160 ROM mirror non usato: warriorb.cpp ha main 1MB (d2d) o 2MB (wb), niente mirror. rtl/darius2/darius2_maincpu_map_new.sv:308 --- CPUA ctrl --- MAME cpua_ctrl_w: if only high byte is written (UDS only), shift high→low so bit 0 of the low byte is correctly set. rtl/darius2/darius2_maincpu_map_new.sv:317 MAME-style high-byte-only normalization rtl/darius2/darius2_maincpu_map_new.sv:327 --- TC0140SYT sound comm (real, no stub) --- MAME: $220001=master_port_w, $220003=master_comm_r/w Pilotiamo cs/wr/rd/a1 al TC0140SYT vero in audio_top. rtl/darius2/darius2_sprite_renderer.sv:27 Sprite RAM format (MAME, 4 words per entry at $E00100): Darius 2 sprite format (ninjaw.cpp): word[0]: X position → sx = (data - 32) & 0x3FF word[1]: Y position → sy = data & 0x1FF word[2]: tile code[14:0] (0 = skip) word[3]: flipX[0], flipY rtl/darius2/darius2_sprite_renderer.sv:48 X offset (scroll-dependent, from MAME draw_sprites x_offs parameter) rtl/darius2/darius2_sprite_renderer.sv:88 warriorb.cpp: 2 panel × 320 = 640 px wide. rtl/darius2/darius2_sprite_renderer.sv:89 V_ACTIVE varia per variant (MAME visarea Y): darius2d : 232 (riga 38..328-1) warriorb : 240 (riga 28..328-1) rtl/darius2/darius2_sprite_renderer.sv:94 Sprite Y baseline (sub-component "y_offs = -8 MAME + north adjust"). rtl/darius2/darius2_sprite_renderer.sv:100 Sprite Y baseline 2 (formula MAME warriorb-family: `- sy - 24`). rtl/darius2/darius2_sprite_renderer.sv:262 Priority mask MAME bit3 attr "unknown priority": pixel scritto da sprite con attr[3]=1 → prio_lb=1, vince anche su pixel gia' scritti da sprite con attr[3]=0. rtl/darius2/darius2_sprite_renderer.sv:361 scn_sc[T+2] = pixel render_x[T] = render_x[T+2] - 2 (chip MAME stessa pipeline). rtl/darius2/darius2_sprite_renderer.sv:383 Pixel extraction — formula derivata da MAME drawgfx.cpp readbit: src[bitnum/8] & (0x80 >> (bitnum%8)) → bit 0 del char = MSB del byte. rtl/darius2/darius2_sprite_renderer.sv:388 16 : 0 bp = pix_idx[1:0] p0 = row_data[half_off + 12 + bp] p1 = row_data[half_off + 8 + bp] p2 = row_data[half_off + 4 + bp] p3 = row_data[half_off + 0 + bp] pixel = {p3, p2, p1, p0} gfx_16x16x4_packed_lsb (warriorb.cpp): row_data rtl/darius2/darius2_sprite_renderer.sv:706 Lancia req ROM direttamente in RD_POP (mask 14-bit MAME drawgfx) rtl/darius2/darius2_sprite_renderer.sv:718 Layout ROM addressing per variant: warriorb.cpp packed_lsb 16x16x4: d2d : {code[13:0], row[3:0], half_lr, 2'b00} — 2MB ROM wb : {code[14:0], row[3:0], half_lr, 2'b00} — 4MB ROM rtl/darius2/darius2_sprite_renderer.sv:875 sprite_ob combinatorio da spr_disp_word (già registrato 1 clk da line buffer), allineato a scn_sc (anche registrato 1 clk dal chip MAME). rtl/darius2/mame_warning_overlay.sv:22 mame_warning_overlay.sv — testo statico "DON'T BREAK YOUR WOOFER!" che appare per ~3 secondi quando l'utente attiva PSG=MAME nell'OSD audio mixer. rtl/darius2/pc060ha_link.sv:25 Single-clock rewrite ispirato a jtrastan_pc060 (JTCORES by Jose Tejada), implementato secondo la descrizione di pc060ha_device in MAME. rtl/darius2/sdram_bridge.sv:395 sub-CPU non esiste in warriorb.cpp (port unused) rtl/darius2/tc0040ioc.sv:4 Author: Umberto Parisi (rmonic79) Version: 2.0 (warriorb.cpp only — TC0220IOC / TC0510NIO direct-mapped) rtl/darius2/tc0040ioc.sv:8 tc0040ioc — I/O controller per warriorb.cpp. rtl/darius2/tc0040ioc.sv:12 Read map (warriorb.cpp): 0x00: DSWA 0x01: DSWB 0x02: IN0 (player1 + coin/start) 0x03: IN1 (player2 joystick) 0x04: coin counters (regs[4]) 0x07: IN2 (buttons + freeze) Write a 0x00 = watchdog reset (ignorato), 0x04 = coin counters. rtl/darius2/tc0110pr.sv:110 MAME chip behaviour: cpu_mode only closes on explicit VA=10. rtl/darius2/tc0110pr.sv:132 Priority MAME ninjaw (draw_sprites + primask): sprite prio 0 (OB[13]=0): sotto FG, sopra tutto il resto sprite prio 1 (OB[13]=1): sotto FG, sotto MID layer, sopra BOTTOM SC[14:13] dal chip MAME tc0100scn codifica il RUOLO del layer visibile rtl/darius2/tc0110pr.sv:154 layer BG "top" → MAME mid rtl/darius2/tc0140syt.sv:101 MAME ninjaw usa NMI per svegliare Z80 al ricevimento comando audio. rtl/darius2/tc_mame/tc0100scn_mame.sv:22 tc0100scn_mame.sv — TC0100SCN, MAME-accurate scanline renderer. rtl/darius2/tc_mame/tc0100scn_mame.sv:24 Reference: MAME tc0100scn.cpp + ninjaw.cpp (Darius 2). rtl/darius2/tc_mame/tc0100scn_mame.sv:25 Scroll math, tile lookup, pixel decode follow MAME exactly. rtl/darius2/tc_mame/tc0100scn_mame.sv:33 MAME VRAM layout (wide mode, word offsets): $0000-$3FFF BG0 attrib+code (128×64 tiles, 2 words/tile) $4000-$7FFF BG1 attrib+code (128×64 tiles, 2 words/tile) $8000-$81FF BG0 row scroll (256 words) $8200-$83FF BG1 row scroll (256 words) rtl/darius2/tc_mame/tc0100scn_mame.sv:53 0 = primo chip, 1 = chip successivi (flag MAME) rtl/darius2/tc_mame/tc0100scn_mame.sv:145 Formula MAME (tc0100scn.cpp:285-286): xd = -m_x_offset - m_multiscrn_xoffs; yd = 8 - m_y_offset; → Chip 0: xd=-22, chip 1: xd=-24, chip 2: xd=-26; yd uguale per tutti (8). rtl/darius2/tc_mame/tc0100scn_mame.sv:149 cliprect.top di ninjaw.cpp:938 = 38 = 24. rtl/darius2/tc_mame/tc0100scn_mame.sv:149 MAME fa src_y += cliprect.top, equivale a usare effettivo scrolldy = yd - cliprect.top = 8 - 24 = -16. rtl/darius2/tc_mame/tc0100scn_mame.sv:162 SCROLLDY = 8 (MAME yd) - P_Y_OFFSET - cliprect.top (24). rtl/darius2/tc_mame/tc0100scn_mame.sv:189 VRAM bases CONDIZIONATI su wide/single (MAME spec). rtl/darius2/tc_mame/tc0100scn_mame.sv:394 Row scroll index MAME (tc0100scn.cpp:649): indice = (y_cliprect - 8) & 0x1FF. rtl/darius2/tc_mame/tc0100scn_mame.sv:443 MAME lo fa internamente nel gfx_element (drawgfx code % elements()). rtl/darius2/tc_mame/tc0100scn_mame.sv:495 Col scroll per-tile (MAME tc0100scn.cpp:656): column_offset = colscroll_ram[src_x/8]; src_y_tile = line_sy - column_offset. rtl/darius2/tc_mame/tc0100scn_mame.sv:562 FG text Y: warriorb mostra 1 scanline del tile adiacente (puntini sopra E sotto i glifi, assenti in MAME) → off-by-one sul FG. rtl/darius2/triple_screen_test.sv:90 warriorb.cpp 2-screen: 640 px active (2 × 320), V variabile per variant: darius2d : 232 (MAME set_visarea(0, 319, 38, 328-1) = righe 24..255) warriorb : 240 (MAME set_visarea(0, 319, 28, 328-1) = righe 16..255) rtl/darius2/triple_screen_test.sv:171 Sprite overlay (MAME ninjaw.cpp priority: "1 = low") prio=0 (primask GFX_PMASK_4): sprite sopra tutto tranne FG prio=1 (primask GFX_PMASK_4\|GFX_PMASK_2): sprite sotto L1 (tile_prio=10) Draw se: no tile opaco, OR prio=0, OR tile NON è L1. README.md:12 This core reimplements the hardware in SystemVerilog from MAME references and hardware observation. README.md:60 Two TC0100SCN tilemap chips (MAME-accurate): BG0, BG1 with per-row scroll and per-column scroll, plus the FG0 text layer Says it matches, follows or was checked against MAME — 1 rtl/darius2/sdram_bridge.sv:280 Word-swap concat (SIM-verified MAME-compliant). Shares text with the MAME driver without saying so — 6 rtl/darius2/darius2_audio_top.sv:357 add_route(0, "subwoofer", 0.75) → PSG mono * 0.75 — shares text with taito/warriorb.cpp:648 rtl/darius2/darius2_audio_top.sv:358 add_route(1, "2610.1.l", 1.0) → FM_L → flt[0] (m_2610_l[0]) — shares text with taito/warriorb.cpp:649 rtl/darius2/darius2_audio_top.sv:359 add_route(1, "2610.1.r", 1.0) → FM_L → flt[1] (m_2610_r[0]) ← stesso input! — shares text with taito/warriorb.cpp:650 rtl/darius2/darius2_audio_top.sv:360 add_route(2, "2610.2.l", 1.0) → FM_R → flt[2] (m_2610_l[1]) — shares text with taito/warriorb.cpp:651 rtl/darius2/darius2_audio_top.sv:361 add_route(2, "2610.2.r", 1.0) → FM_R → flt[3] (m_2610_r[1]) — shares text with taito/warriorb.cpp:652 rtl/darius2/tc_mame/tc0100scn_mame.sv:146 xd = -m_x_offset - m_multiscrn_xoffs; — shares text with taito/tc0100scn.cpp:287
DCon# D-Con MiSTer-devel/Arcade-Dcon_MiSTer @ 3ad65361 MAME compared: seibu/dcon.cpp + 4 related file(s) Read: 19 HDL files, 5,847 lines (Quartus project)	MiSTer official	Mostly MAME	medium	63%
Statements: 3 toward hardware, 43 toward MAME Cites hardware documentation that MAME's driver does not — 2 rtl/DCon/DCon_main_top.sv:31 Memory map SD Gundam (da MAME dcon.cpp + SD Gundam override): $000000-$07FFFF ROM 68K (512KB) $080000-$08BFFF Main RAM (48KB) $08C000-$08C7FF BG tile RAM (2KB) $08C800-$08CFFF FG tile RAM (2KB) $08D000-$08D7FF MG tile RAM rtl/DCon/DCon_maincpu_map.sv:29 Memory map SD Gundam (da MAME dcon.cpp + sdgndmps_map override): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $080000-$08BFFF Main RAM (48KB) → BRAM $08C000-$08C7FF BG tile RAM → BRAM dual-port $08C800-$ Reports a measurement taken on the original PCB — 1 rtl/DCon/DCon_video_timing.sv:26 PCB measurement Blood Bros: VSync 59.4094 Hz, HSync 15.6246 kHz, master XTAL 20 MHz. Cites MAME source — 39 DCon.sv:208 I valori di calibrazione pixel-perfect MAME sono hardcodati DENTRO i rispettivi renderer: - Sprite X+1, Y+0 (rimosso -16 + +16 OSD): DCon_sprite_renderer.sv:178-179 - Text X+2, Y+0: DCon_text_renderer.sv (vedi sotto) - BG/MG/FG: nessun of DCon.sv:282 --- Joystick to SD Gundam input mapping --- MAME P1_P2 port ($E0002): active low. DCon.sv:586 ── Flip screen (CRTC reg 0x1A bit 0) ─────────────────────────────────────── MAME: BIT(reg_1a, 0) → flip_screen. DCon.sv:628 D-Con Text: niente scroll (MAME screen_update_dcon non chiama set_scroll su text layer) DCon.sv:662 D-Con CRTC scroll passthrough — nessun offset HW (MAME screen_update_dcon:214-219). DCon.sv:771 Pixel pipeline con sprite + priority callback (MAME pri_cb dcon.cpp). DCon.sv:772 pri_code semantics (MAME pri_mask 0xF0/0xFC/0xFE/0): pri=3 → sprite ABOVE ALL (mask=0, copre Text/FG/MG/BG, INSERT COIN, HUD) pri=0 → sprite ABOVE FG (copre FG, MG, BG; coperto solo da Text) pri=1 → sprite ABOVE MG (copre MG, BG; coperto rtl/DCon/DCon_audio_z80.sv:25 Spec da MAME (reference/mame_seibu/seibusound.cpp + dcon.cpp:dcon): - Z80 @ 4.000000 MHz - YM3812 (jtopl2) @ 4.000000 MHz - OKI M6295 (jt6295) @ 1.320000 MHz, PIN7=LOW rtl/DCon/DCon_audio_z80.sv:98 ─── Clock enable: clk_sys (96 MHz) → Z80/YM 4 MHz, OKI 1.32 MHz ───────── Z80/YM: 96/4 = 24 esatto → div 24, target 4.000 MHz (MAME dcon.cpp:541) OKI: 96/1.32 = 72.73 → div 73, target 1.315 MHz (errore 0.4%, accettabile) rtl/DCon/DCon_audio_z80.sv:153 MAME audiocpu region layout (dcon): rtl/DCon/DCon_audio_z80.sv:334 snd_rdata: D-Con usa main_r standard (MAME seibusound.cpp:287). rtl/DCon/DCon_main_top.sv:31 Memory map SD Gundam (da MAME dcon.cpp + SD Gundam override): $000000-$07FFFF ROM 68K (512KB) $080000-$08BFFF Main RAM (48KB) $08C000-$08C7FF BG tile RAM (2KB) $08C800-$08CFFF FG tile RAM (2KB) $08D000-$08D7FF MG tile RAM rtl/DCon/DCon_main_top.sv:197 VBLANK IRQ4 — MAME dcon.cpp: m_maincpu->set_vblank_int(irq4_line_hold) Rising edge di vblank → assert IRQ4 pending; IACK CPU → clear. rtl/DCon/DCon_main_top.sv:340 XOR 0x400 lato CPU per allineare BRAM[N] = MAME text_vram[N] (renderer parte da addr 0). rtl/DCon/DCon_main_top.sv:348 Quindi MAME palette[N] sta in vram_addr = (N + 0x400) & 0x7FF. rtl/DCon/DCon_main_top.sv:349 Per allineare BRAM[N] = MAME palette[N] applichiamo XOR 0x400 SOLO al lato CPU (a_addr). rtl/DCon/DCon_main_top.sv:350 Il renderer passa pen_index MAME nativo (BG=0x400+, MG=0x500+, ecc) e la BRAM è già allineata. rtl/DCon/DCon_maincpu_map.sv:29 Memory map SD Gundam (da MAME dcon.cpp + sdgndmps_map override): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $080000-$08BFFF Main RAM (48KB) → BRAM $08C000-$08C7FF BG tile RAM → BRAM dual-port $08C800-$ rtl/DCon/DCon_maincpu_map.sv:160 ─── GFX bank register ─────────────────────────────────────────────────── MAME dcon.cpp gfxbank_w: SOLO bit0 → m_gfx_bank_select = 0x1000 oppure 0. rtl/DCon/DCon_palette.sv:25 MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 2048); Address space CPU: 0x08E800..0x08F7FF (4 KB = 2048 word). rtl/DCon/DCon_palette.sv:34 Espansione 5→8 bit con replica top-bits (standard MiSTer / MAME palette_device). rtl/DCon/DCon_palette.sv:86 xBGR_555 → RGB888 con replica bit alti (5→8 standard MiSTer/MAME) rtl/DCon/DCon_seibu_crtc.sv:23 Seibu CRTC fedele a MAME (src/mame/seibu/seibu_crtc.cpp). rtl/DCon/DCon_seibu_crtc.sv:117 MAME mappa: bit0=screen0(BG), bit1=screen2(MG), bit2=screen1(FG), bit3=screen3(Text) (vedi seibu_crtc.cpp commento "screen 0=BG, screen 1=FG, screen 2=MG, screen 3=Text") In SD Gundam dcon.cpp layer_en_w gira la maschera così: ~layer_en bit rtl/DCon/DCon_seibu_crtc.sv:126 Il dispatcher MAME usa "if (BIT(~m_layer_en, n))" per saltare = layer disabilitato quando il bit è 1. rtl/DCon/DCon_sprite_renderer.sv:27 Format word (formato "comune", non alt_format) da MAME src/mame/seibu/sei021x_sei0220_spr.cpp: w0 bit 15 = enable (0=skip, 1=draw) w0 bit 14 = flip_x w0 bit 13 = flip_y w0 bit 12..10 = sizex (3-bit, +1) → 1..8 tile larghezza rtl/DCon/DCon_sprite_renderer.sv:42 Multi-tile: tile_code += 1 per sub-tile (TODO: ordine x-major o y-major da verificare con dump MAME — assunto x-major per ora). rtl/DCon/DCon_sprite_renderer.sv:45 Priority callback dcon.cpp::pri_cb: pri=0 → above FG pri=1 → above MG pri=2 → above BG pri=3 → above Text (= sotto Text) rtl/DCon/DCon_sprite_renderer.sv:164 SEI0211 get_coordinate (MAME sei021x_sei0220_spr.h): coord &= 0x1ff; return (coord >= 0x180) ? rtl/DCon/DCon_sprite_renderer.sv:173 Hardcode pixel-perfect MAME (valori netti commit 28adc3a, OSD a 0): X = sp_x_raw + 1 Y = sp_y_raw + 0 (era +16 OSD - 16 HW = 0 netto) xoff/yoff porte conservate per compat ma non più cablate al top. rtl/DCon/DCon_sprite_renderer.sv:200 Tile code finale Y-MAJOR (MAME draw_internal: ax=outer, ay=inner, code++): sub_index = axsizey + ay → cur_tile = code + eff_tile_xsp_h + eff_tile_y rtl/DCon/DCon_text_renderer.sv:25 Specifiche da MAME (src/mame/seibu/dcon.cpp): rtl/DCon/DCon_text_renderer.sv:126 --- Stage 0: tile coords --- Hardcode +2 X per pixel-perfect MAME (commit 28adc3a). rtl/DCon/DCon_text_renderer.sv:184 --- Stage 3: pen decode --- MAME readbit: bit MSB-first → src[bn/8] & (0x80 >> (bn%8)) In Verilog LSB-first, bit position = 7 - (bn%8). rtl/DCon/DCon_tile_layer.sv:25 Differenze fra layer (da MAME dcon.cpp): rtl/DCon/DCon_video_timing.sv:35 Active area da MAME (sdgndmps_map): visarea 0..408-1, 28..308-1 quindi 320×224, V offset = 16 (top blank). README.md:18 YM3812 OPL2 FM (jtopl2) + OKI M6295 ADPCM (jt6295) with MAME-accurate mixer README.md:59 \| Custom video CRTC\| Seibu CRTC (legionna.cpp / seibu_crtc.cpp) \| README.md:130 The MAME* project for invaluable hardware reference (`seibu/dcon.cpp`, `seibu/seibu_crtc.cpp`). Says it matches, follows or was checked against MAME — 1 DCon.sv:290 SD Gundam SYSTEM port ($E0004) — verified MAME dcon.cpp:345-356 bit0 = START1 (active LOW) bit4 = START2 (active LOW) bit8 = SERVICE (active LOW) PORT_SERVICE_NO_TOGGLE altri = UNKNOWN/UNUSED → tied 1 Coin inputs NON sono qui Shares text with the MAME driver without saying so — 3 rtl/DCon/DCon_palette.sv:23 Palette RAM Seibu D-Con (xBGR_555, 2048 entries). MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 2048); Address space CPU: 0x08E — shares text with seibu/dcon.cpp:559 rtl/DCon/DCon_text_renderer.sv:23 Text layer renderer Seibu D-Con (8x8, 4bpp, 64x32). Specifiche da MAME (src/mame/seibu/dcon.cpp): // get_text_tile_info tile = textram[tile_i — shares text with seibu/dcon.cpp rtl/DCon/DCon_video_timing.sv:23 Video timing single-screen Seibu D-Con. SD Gundam Psycho Salamander gira su Seibu D-Con (PB91008), stessa famiglia di Blood Bros (1990). PCB measuremen — shares text with seibu/dcon.cpp
Deco16# Crude Buster, Tatakae Genshizin Joe & Mac, The Cliffhanger - Edward Randy, Kuhga - Operation Code 'Vapor Trail' MiSTer-devel/Arcade-Deco16_Mister @ 5e1ca62f MAME compared: dataeast/cbuster.cpp, dataeast/cninja.cpp, dataeast/vaportra.cpp + 14 related file(s) Read: 48 HDL files, 20,333 lines (Quartus project)	MiSTer official	Mostly MAME	medium	19%
Statements: 43 toward MAME Cites MAME source — 35 rtl/cninja/jtcbuster_decoder.v:3 Crude Buster / Two Crude board decoder (doc/cbuster.cpp ::main_map). rtl/cninja/jtcbuster_decoder.v:54 TC-4 registered-PAL protection HLE (doc/cbuster.cpp ::prot_w) rtl/cninja/jtcbuster_decoder.v:58 MAME masks the write by mem_mask before matching, so mask cpu_dout by the active byte lanes: otherwise a byte write arrives with a stale high byte and never matches. rtl/cninja/jtcninja_colmix.v:6 Each board has its own layer order, taken from its screen_update in MAME. rtl/cninja/jtcninja_deco104.v:3 DECO 104 protection / I/O mux for Data East cninja.cpp (Joe & Mac). rtl/cninja/jtcninja_deco104.v:11 Behaviour (see doc/deco146.cpp read_protport / write_protport): real_address = addr*2 & 0x7ff (addr = word offset) WRITE: store din to rambank[(ra&0xff)>>1]; special ports: 0x42 -> XOR reg, 0xee -> NAND reg, 0xa8 -> sound latch (+ rtl/cninja/jtcninja_deco104.v:32 The 146 (edrandy) is the SAME engine with its own port table and constants and NO magic read-address xor (deco146.cpp: m_magic_read_address_xor_enabled = false), so it is a second instantiation with the parameters below rather than a second rtl/cninja/jtcninja_deco104.v:88 ---- I/O ports (MAME cninja PORT_START) ---- INPUTS (port A): P1 low byte, P2 high byte (active low). rtl/cninja/jtcninja_deco104.v:89 Per MAME cninja PORT_START("INPUTS"): bits0-3 joyUDLR, b4 B1, b5 B2, b6 unused, b7 START1; bits8-11 joyUDLR(P2), b12 B1, b13 B2, b14 unused, b15 START2. rtl/cninja/jtcninja_deco104.v:251 Log every completed protection READ so the values can be diffed against MAME. rtl/cninja/jtcninja_deco16.v:7 Scroll modes (control1[6:5], per deco16ic.cpp deco16_pf_update / custom_tilemap_draw): rtl/cninja/jtcninja_deco16ic.v:5 Per MAME (deco16ic.cpp device_start) the chip owns its own state, so it is modelled here: m_pf1_data 0x2000 bytes -> u_pf1 (AW=12) m_pf2_data 0x2000 bytes -> u_pf2 m_pf12_control 0x10 bytes -> u_mmr (jtdeco16ic_mmr, cfg/mmr.yaml) rtl/cninja/jtcninja_decoder.v:3 Caveman Ninja / Joe & Mac board decoder (doc/cninja.cpp ::cninja_map). rtl/cninja/jtcninja_decospr.v:4 MAME ref: decospr.cpp (mirrored in cores/cninja/doc). rtl/cninja/jtcninja_game.v:19 SCAFFOLD -- Data East DECO 16-bit (cninja.cpp), Caveman Ninja / Joe & Mac. rtl/cninja/jtcninja_game.v:103 The deco16ic register dump has no consumer: JTFRAME_IOCTL_RD is not set, so the core has no ioctl_din output and scenes are captured from MAME, not from hardware. rtl/cninja/jtcninja_game.v:124 tiles2 also needs the MAME ROM_CONTINUE de-interleave (mame2mra emits mag-00\|mag-01 naive; the real region swaps the middle 256kB blocks = word bits 17<->18), folded into the rotate. rtl/cninja/jtcninja_game.v:305 xor (deco146.cpp disables it) rtl/cninja/jtcninja_main.v:3 Main 68000 subsystem for the Data East cninja.cpp family. rtl/cninja/jtcninja_main.v:220 A superset of MAME's PCs because of prefetch, so diff it as an in-order subsequence against the MAME trace. rtl/cninja/jtcninja_main.v:236 Heartbeat: per-frame liveness + cumulative palette/tilegen/sprite write counts (compare to MAME: full boot writes 4096 palette + ~50k tilegen). rtl/cninja/jtcninja_obj.v:59 cninja and cbuster both use MAME's tilelayout (dp straight) - cbuster verified at 98% vs screen.png. rtl/cninja/jtcninja_snd.v:3 Sound subsystem for Data East cninja.cpp (Joe & Mac). rtl/cninja/jtcninja_snd.v:13 HuC6280 physical sound_map (doc/cninja.cpp ::sound_map): 000000-00ffff program ROM A[20:16]==0 100000-100001 YM2203 A[20] & A[19:16]==0 110000-110001 YM2151 A[20] & A[19:16]==1 120000-120001 rtl/cninja/jtcninja_snd.v:227 The cninja attract is silent (only the YM2151 tempo timer) until the main CPU sends a play command (~frame 1106 in MAME, cmd 0x14) which drives the YM2203 music. rtl/cninja/jtcninja_video.v:3 Video subsystem for the Data East 16-bit family (cninja.cpp and friends). rtl/cninja/jtcninja_video.v:243 deco16ic bank callback (driver-provided in MAME). rtl/cninja/jtcninja_video.v:383 vaportra uses the MXC-06 instead (vaportra.cpp: "same as Bad Dudes") - a different chip with a different sprite word format, vendored from cores/cop as jtcninja_mxc06 with the dec0 seallayout plane order. rtl/cninja/jtdarkseal_decoder.v:3 Dark Seal / Gate of Doom board decoder (doc/darkseal.cpp ::main_map). rtl/cninja/jtdarkseal_decoder.v:51 MAME does it once over the whole ROM in driver_init; the ROM is stored RAW in SDRAM and undone here, the only place it CAN live - it permutes bits inside a byte, which neither the MRA (byte/file level) nor the byte-serial download can expre rtl/cninja/jtdeco_irq.v:3 Data East deco_irq (doc/deco_irq.cpp): vblank plus two programmable raster interrupts. rtl/cninja/jtedrandy_decoder.v:3 The Cliffhanger - Edward Randy board decoder (doc/cninja.cpp ::edrandy_map). rtl/cninja/jtedrandy_decoder.v:66 MAME runs edrandy with empty_init: the 68k ROM is not scrambled. rtl/cninja/jtvaportra_decoder.v:3 Vapor Trail / Kuhga board decoder (doc/vaportra.cpp ::main_map). rtl/cninja/jtvaportra_decoder.v:6 000000-07ffff program ROM ffc000-ffffff work RAM 100000 PLAYERS r / priority[0] w 100002 COINS r / priority[1] w 100004 DSW r 100007 soundlatch w (byte) 200000/202000 tilegen[1] data 240000-24000f Says it matches, follows or was checked against MAME — 6 rtl/cninja/jtcbuster_decoder.v:94 H out={in4,in6,in7,in5,in3:0} L out={in7,in1,in5,in4,in6,in2,in3,in0} verified vs MAME: SSP=0x084000, PC=0x600, 0x606 = 46 FC 27 00 rtl/cninja/jtcninja_deco104.v:210 bankswitch side effect, deferred one cycle so the registered tw (e_port/e_off) matches the current access (MAME: off==0x66 on a non-latch read toggles the rambank). rtl/cninja/jtcninja_decospr.v:25 The whole table is always covered, matching MAME's decospr, which has no per-line cap. rtl/cninja/jtcninja_decospr.v:194 cninja AND cbuster both use MAME's `tilelayout` (same planeoffset), so they take dp straight - verified: cbuster sprite render matches MAME screen.png at 98% with dp, vs 21-29% for any swap. rtl/cninja/jtcninja_game.v:126 Verified end-to-end against the MAME gfxdecode (0 px mismatch). rtl/cninja/jtcninja_snd.v:229 Verified vs MAME. Says it was translated, ported or taken from MAME — 1 rtl/cninja/jtcninja_deco104.v:5 Ported from MAME deco146.cpp / deco104.cpp (deco_146_base_device + deco104 specialisation). Shares text with the MAME driver without saying so — 1 rtl/ikaopm/IKAOPM_lfo.v:431 TAP MSB 6 5 4 3 2 1 0 LSB Base value shift register 0 1 1 0 1 0 1 Volume register(AMD/PM — shares text with dataeast/cninja.cpp:70
DECOCassette# Fishing, Astro Fantasia, Boulder Dash, Hamburger … MiSTer-devel/Arcade-DECOCassette_MiSTer @ afc8122f MAME compared: dataeast/decocass.cpp + 7 related file(s) Read: 61 HDL files, 16,512 lines (Quartus project)	MiSTer official	Both	high	51%
Statements: 2 toward hardware, 285 toward MAME Ships hardware documentation files — 1 Useful Information/schematics/decocassette.pdf Notes where it differs from MAME — 1 rtl/mcu/mcu_tape_iface.v:142 The ORIGINAL forward decode drives the tape INTO the data region (RCLK@read lit, $05 delivered), so forward is empirically correct for THIS streamer's layout, even though it diverges from MAME's bit5-sign. Cites MAME source — 237 Arcade-DECOCassette.sv:231 Keyboard coin/start (MAME defaults): 1 = 1P Start, 2 = 2P Start, 5 = Coin 1, 6 = Coin 2. Arcade-DECOCassette.sv:281 MAME factory defaults (decocass.cpp DSW1/DSW2): sw[2]=DSW1=0x3F : Coin 1C/1C, "Type of Tape"=MD(Small)=0x30 (SW1:5,6, "Used by the bios"), Upright sw[3]=DSW2=0xFF : option bits all-default + "Country Code"=A=0xe0 (SW2:6,7,8, "DON'T CHANGE") Arcade-DECOCassette.sv:418 2026-05-17 — Render-side charram lives in video_fg.v as 3 separate planes (per MAME `charlayout` 3bpp). Arcade-DECOCassette.sv:444 MEMORY: decocrom overlay-PCB ROM (MAME "user3" region) — ctisland/ctisland2/ ctisland3/cexplore only. Arcade-DECOCassette.sv:445 Banked over charram $6000-$AFFF via $E900 (decocass_e900_w -> m_rombank, decocass.cpp:2095-2105/130-135). Arcade-DECOCassette.sv:579 MAIN CPU: DECO-222 @ 750 kHz (ce_hclk4 = HCLK4, per MAME decocass.cpp:1018) Arcade-DECOCassette.sv:600 750 kHz CPU clock (HCLK4 per MAME decocass.cpp:1018) Arcade-DECOCassette.sv:647 If the loader regresses on this build, flip back to the commented line below (joy[14]) to isolate — no rebuild-from-memory needed: .coin_in (joystick_0[14] \| joystick_1[14]), // P1 or P2 coin → main-CPU NMI (MAME decocass_m.cpp:1 Arcade-DECOCassette.sv:756 2026-05-18 — full 8-bit dongle output (per MAME) Arcade-DECOCassette.sv:908 2026-05-18: 8-bit per MAME Arcade-DECOCassette.sv:911 2026-05-18 — dongle reads MCU host-bus registers per MAME `upi41_master_r(0)/(1)`. Arcade-DECOCassette.sv:926 MAME decocass_e5xx_r: (offset & E5XX_MASK)==2 -> composite STATUS byte; else -> m_dongle_r(offset). Arcade-DECOCassette.sv:933 MAME reads 0 there. Arcade-DECOCassette.sv:942 e5xx_dongle : dongle_din_full); E5XX-STATUS-ROUTING-FIX-2026-06-10: MAME decocass_e5xx_r returns the 8041/tape STATUS for $E5x2/3 on ALL dongle types incl. Arcade-DECOCassette.sv:944 Darksoft (darksoft_r is the ELSE branch = offset 0/1 only; decocass_m.cpp:1200,1229). Arcade-DECOCassette.sv:951 dongle_din_full : 8'h00); DONGLE-DATA-UNGATE-2026-06-27: MAME decocass_e5xx_r (decocass_m.cpp:1227-1232) returns m_dongle_r(offset) for $E5x0/1 on ALL dongle types — NO OBF / 8041-status gate. Arcade-DECOCassette.sv:953 The OBF gate below forced $E5x0/1 to 0x00 whenever OBF=0, which holds throughout type3 PROM-mode reads (data = m_donglerom[ctr], decocass_m.cpp:630, independent of the 8041) → BurgerTime's decrypt stream read back as 0x00 = garbage. Arcade-DECOCassette.sv:959 e5xx_dongle // $E5x2/3 = STATUS byte, ALL types (MAME) : (dongle_type == 4'd7) ? Arcade-DECOCassette.sv:962 $E5x2/3 = STATUS byte, ALL types (MAME) Arcade-DECOCassette.sv:963 $E5x0/1 = dongle data, ALL types UNGATED (MAME m_dongle_r) Arcade-DECOCassette.sv:1103 Prepare input signals from joysticks/buttons (inverted per MAME) Arcade-DECOCassette.sv:1105 CONTROLS-ACTIVEHIGH-FIX-2026-06-10: MAME decocass IN0/IN1 are ACTIVE-HIGH (decocass.cpp:154-159, IP_ACTIVE_HIGH; bit0=R 1=L 2=U 3=D 4=B1 5=B2, bits6-7 UNUSED). Arcade-DECOCassette.sv:1109 ORIGINAL (active-low = stuck-on), uncomment to restore: assign in0 = {2'b11, ~joystick_0[5:0]}; assign in1 = {2'b11, ~joystick_1[5:0]}; CONTROLS-UD-SWAP-2026-06-10: MiSTer joystick [3]=Up/[2]=Down, MAME IN0 bit2=Up/bit3=Down (decocass.cpp:1 Arcade-DECOCassette.sv:1220 Per MAME decocass.cpp, audio NMI enable is set by main CPU writes to $E416. Arcade-DECOCassette.sv:1330 Sprites (task 10) SPRITE-DESC-SWIZZLE-FIX-2026-06-11: the sprite descriptor mirror must be a TRUE copy of fgvideoram, which applies the $C800-$CBFF mirror-swizzle (video_fg.v:71-74 / MAME mirrorvideoram_w: swap upper-5/lower-5 bits). Arcade-DECOCassette.sv:1387 Per MAME decocass_v.cpp:323-333 (`decocass_paletteram_w`): offset = (offset & 31) ^ 16; m_palette->set_indirect_color(offset, ...); The hardware XORs bit 4 (and mod-32s) the CPU's write offset before committing it to the indirect-color tabl rtl/clock_div.v:4 Single 96 MHz PLL output -> six CEs that match the DECO Cassette divider tree (decocass.cpp lines 59-63 + decocass_tape.cpp TAPE_CLOCKRATE). rtl/cpu/T48/upi41_db_bus.vhd:220 MAME mcs48.cpp in_a_dbb: "acknowledge the IBF IRQ and clear the bit in STS"; the IBF interrupt is LEVEL-sensitive on STS_IBF (mcs48.cpp:1299). rtl/cpu/deco222.v:5 Reference: MAME src/devices/cpu/m6502/deco222.cpp bswap = ((byte & 0x9F) \| ((byte & 0x40) >> 1) \| ((byte & 0x20) << 1)) i.e. swap bits D5 and D6 (corrected 2026-05-30 — was wrongly D1<->D6) rtl/cpu/deco222.v:32 MAME formula: (b & 0x9F) \| ((b&0x40)>>1) \| ((b&0x20)<<1). rtl/decocass.v:36 750 kHz CPU clock enable (HCLK4 = MASTER/16, per MAME decocass.cpp:1018) rtl/decocass.v:75 MAME's rtl/decocass.v:108 decocrom (MAME decocrom_map/init_decocrom): $6000-$AFFF banked read source, selected by $E900 (decocass_e900_w -> m_rombank->set_entry). rtl/decocass.v:109 Writes are UNAFFECTED by the bank (always land in charram — decocass_de0091_w always calls decocass_charram_w regardless of bank, per MAME's own comment "cexplore requires us to allow them"). rtl/decocass.v:184 Main CPU NMI generation — MAME-faithful (decocass_m.cpp:150-159). rtl/decocass.v:186 The previous implementation asserted NMI on every VBLANK rising edge, citing "per the hardware." But MAME asserts main-CPU NMI EXCLUSIVELY on coin insert (`INPUT_CHANGED_MEMBER(coin_inserted)` at decocass_m.cpp:155-159 → `set_input_line(NMI rtl/decocass.v:191 No screen_vblank_callback / set_periodic_int / vblank-NMI binding exists anywhere in MAME's decocass machine config. rtl/decocass.v:202 MAME treats coin as active-low and triggers on falling edge; translated here as rising edge of active-high coin_in = coin press. rtl/decocass.v:223 MAME proof: DECO main CPU NMI is coin-ONLY (decocass_m.cpp:158), has NO IRQ, and NO vblank interrupt — the BIOS POLLS vblank via DSW1[7]/$E300 (decocass.cpp:214, already wired in cpu_din_mux ~line 454). rtl/decocass.v:244 Address decode (lines 88-127 of decocass.cpp) rtl/decocass.v:286 Per MAME `decocass.cpp:939-948` `charlayout`, the FG character set is 3 planes × 1024 tiles × 8 bytes = 24 KB, and each plane occupies a distinct 8 KB CPU window: Plane 0: $6000-$7FFF cpu_addr[15:13] == 3'b011 Plane 1: $8000-$9FFF cpu rtl/decocass.v:335 paletteram: $E000-$E0FF (CPU readback dpram, no XOR — MAME stores the raw byte at `m_paletteram[offset]` so CPU readback returns the last-written value at the same offset. rtl/decocass.v:378 Reference: decocass.cpp lines 105-118 for register semantics. rtl/decocass.v:412 MAME: m_color_missiles = data & 0x77 rtl/decocass.v:424 decocass_e900_w: m_de0091_enable = data&3; set_entry SKIPPED (register unchanged) when data&3==3 (MAME's "invalid" guard) -> only actually load 0/1/2. rtl/decocass.v:451 Reference: decocass.cpp lines 88-127 for read sources. rtl/decocass.v:458 RAM: $0000-$5FFF (lines 94-97 of spec) NOTE: first arm narrowed to 00xx (was 0xxx) so $6000-$7FFF correctly routes to charram_q below, per decocass.cpp memory map. rtl/decocass.v:474 Charram: $B000-$BFFF — NEVER banked (decocrom_map only overrides $6000-$AFFF; MAME's base decocass_map .ram() still owns this range even under init_decocrom). rtl/decocass.v:499 DSW1: $E300 (line 110 of spec) Per MAME decocass.cpp PORT_START("DSW1"): bit[7] is VBLANK custom port, bits[6:0] are DIP switches. rtl/dongle/dongle_darksoft.v:2 Darksoft multigame dongle (MAME: decocass_darksoft_state, decocass_m.cpp:1157-1187) rtl/dongle/dongle_darksoft.v:28 low address byte (the MAME "offset") rtl/dongle/dongle_darksoft.v:43 MAME offsets are exact 0 / 1 within the $E5xx window rtl/dongle/dongle_mux.v:9 - Data input is `mcu_dbb_dout` (host DBBOUT, 8-bit) and `mcu_dbb_sts` (host DBBSTS, 8-bit), per MAME `upi41_master_r(0)/(1)`. rtl/dongle/dongle_mux.v:39 MCU host-bus registers (DBBOUT/DBBSTS) per MAME `upi41_master_r(0/1)` rtl/dongle/dongle_mux.v:111 Darksoft multigame dongle — 20-bit counter into a 1 MB ROM (MAME decocass_darksoft_state) rtl/dongle/dongle_mux.v:123 Widel multigame dongle — 20-bit counter/latch into a 1 MB ROM (MAME decocass_widel_state) rtl/dongle/dongle_mux.v:154 DONGLE-TYPE4-ADDR-FIX-2026-06-27: type4 (Scrum Try/Oozumou) PROM is 32 KB and the counter is 15-bit (decocass_m.cpp:887/891). rtl/dongle/dongle_nodong.v:4 Per MAME `decocass_nodong_r` (decocass_m.cpp:1026-1058): offset & 1 == 0 → upi41_master_r(0) = MCU DBBOUT offset & 1 == 1 → upi41_master_r(1) = MCU DBBSTS rtl/dongle/dongle_nodong.v:8 2026-05-18: takes MCU host-bus registers (NOT P2 outputs — the old `mcu_status_low` wiring was incorrect per MAME). rtl/dongle/dongle_type1.v:4 Faithful to MAME decocass_type1_r (decocass_m.cpp:266-339), the per-game machine_resets (1457-1561), and the flags tables (357-460). rtl/dongle/dongle_type1.v:10 Map VALUES from MAME via /tmp/gen_type1.py. rtl/dongle/dongle_type1.v:38 Swap source = the 8041 host DATA byte (DBBOUT), per MAME decocass_type1_r. rtl/dongle/dongle_type1.v:47 Regenerated from MAME (see header). rtl/dongle/dongle_type1.v:113 ctisland3 (handcrafted dongle PROM; MAME comment: "correct for rtl/dongle/dongle_type1.v:114 handcrafted prom" -> identity in/out maps, decocass_m.cpp:1563-1570) rtl/dongle/dongle_type1.v:130 Latched MCU data byte (previous A0==0 read), per decocass_m.cpp:336. rtl/dongle/dongle_type1.v:133 T1MAP(i,map) = (map >> i3) & 7 (decocass_m.cpp:32-35) rtl/dongle/dongle_type2.v:12 Reference: decocass_m.cpp lines 541-602 rtl/dongle/dongle_type2.v:14 State variables (from decocass_m.cpp): - m_type2_promaddr : PROM address (8 bits) from cpu_addr_lo on even-address write - m_type2_d2_latch : D2 status latch (bit 2 of initialization write) - m_type2_xx_latch : Enable latch (set when cpu rtl/dongle/dongle_type2.v:19 Write behavior (decocass_m.cpp:569-602): - Odd address ($E5x1): Write initialization/D2 latch If xx_latch == 1: (no-op) If cpu_dout[7:4] == 0xC0: Set xx_latch = 1, D2 latch = (cpu_dout[2]) Otherwise: Forward to MCU - Even address ($E5x0): W rtl/dongle/dongle_type2.v:28 Read behavior (decocass_m.cpp:541-567): - Odd address ($E5x1): Return PROM byte if xx_latch == 1, else MCU status - Even address ($E5x0): Return 0xFF (floating) if xx_latch == 1, else MCU data - PROM address: {D2_latch, promaddr[7:0]} rtl/dongle/dongle_type2.v:46 2026-05-18: 8-bit per MAME rtl/dongle/dongle_type2.v:64 Synchronous state updates (decocass_m.cpp:569-602, decocass_type2_w) rtl/dongle/dongle_type2.v:74 Write handler (decocass_m.cpp:569-602) rtl/dongle/dongle_type2.v:78 Activate PROM latch and capture D2 status bit (decocass_m.cpp:590-594) rtl/dongle/dongle_type2.v:95 PROM address generation: {D2_latch, promaddr[7:0]} (decocass_m.cpp:549) rtl/dongle/dongle_type2.v:101 Output data mux: PROM vs. MCU passthrough (decocass_m.cpp:541-567) rtl/dongle/dongle_type3.v:14 Reference: decocass_m.cpp lines 622–851 rtl/dongle/dongle_type3.v:22 Counter behavior (decocass_m.cpp line 633): - Increments on cpu_re when offset & 1 == 1 and m_type3_pal_19 == 1 - Wraps to 0 at 4096 rtl/dongle/dongle_type3.v:31 Swap modes (TYPE3_SWAP_ enum, decocass_m.cpp lines 39–51): 0: TYPE3_SWAP_01 — swap bits 0 (d0_latch) and 1 (save[1]) 1: TYPE3_SWAP_12 — swap bits 1 (save[2]) and 2 (save[1]) 2: TYPE3_SWAP_13 — swap bits 1 (save[3]), 2 (save[2]), 3 (s rtl/dongle/dongle_type3.v:44 Burger Time (cbtime) uses TYPE3_SWAP_12 (mode 1) — decocass_m.cpp line 1590. rtl/dongle/dongle_type3.v:58 2026-05-18: 8-bit per MAME rtl/dongle/dongle_type3.v:86 Write handler: cpu_we and cpu_addr_lo[0] == 1 (decocass_m.cpp lines 827–851) rtl/dongle/dongle_type3.v:101 Read handler: cpu_re and cpu_addr_lo[0] == 1 (decocass_m.cpp lines 626–634) rtl/dongle/dongle_type3.v:116 FIX 2026-05-30: MAME line 798 latches `save & 1` = the 8041 DATA byte's bit 0 (DBBOUT[0]), and only in the pal_19==0 path. rtl/dongle/dongle_type3.v:126 PROM address generation: full 12-bit counter when pal_19 is active (decocass_m.cpp line 630: `data = m_donglerom[m_type3_ctrs];`) Counter wraps at 4096 — full 4 KB PROM is addressable. rtl/dongle/dongle_type3.v:145 NOTE: For even address reads in PROM mode, return 0xFF (open bus) This is handled at line 654 in MAME and returns 0xFF. rtl/dongle/dongle_type3.v:151 8041 status mode: apply bit-swap transformation Bit 0 is always D0 latch in most modes (except SWAP_34_7) FIX 2026-05-30: MAME swaps `save = upi41_master_r(0)` = the 8041 DATA byte (DBBOUT), NOT prom_q. rtl/dongle/dongle_type3.v:157 Decode the swap mode and apply bit permutation (decocass_m.cpp lines 662–795) rtl/dongle/dongle_type3.v:305 2026-05-18 — 8-bit per MAME decocass_type3_r. rtl/dongle/dongle_type3.v:307 Output mux — MAME decocass_type3_r (dispatcher already gated offset&2==0): A0==1: pal_19 ? rtl/dongle/dongle_type4.v:13 Reference: decocass_m.cpp lines 866-939 rtl/dongle/dongle_type4.v:15 State variables (from decocass_m.cpp): - m_type4_ctrs : 15-bit counter (0–0x7FFF, wraps at 0x8000) - m_type4_latch : Enable latch (set when cpu_dout[7:4] == 0xC on odd-address write) rtl/dongle/dongle_type4.v:19 Write behavior (decocass_m.cpp:912-939): - Odd address ($E5x1): Load MSB of counter If latch == 1: Set m_type4_ctrs[14:8] = {cpu_dout[6:0], 1'b0} (7 bits) If cpu_dout[7:4] == 0xC0: Set latch = 1 Otherwise: Forward to MCU - Even address ($E5 rtl/dongle/dongle_type4.v:28 Read behavior (decocass_m.cpp:866-910): - Odd address ($E5x1): Return MCU status if latch == 1, else 0xFF - Even address ($E5x0): Return PROM byte if latch == 1 (auto-increment after) Counter increments after read: (m_type4_ctrs + 1) & 0x7F rtl/dongle/dongle_type4.v:47 2026-05-18: 8-bit per MAME rtl/dongle/dongle_type4.v:63 Synchronous state updates (decocass_m.cpp:912-939, decocass_type4_w) rtl/dongle/dongle_type4.v:72 Write handler (decocass_m.cpp:912-939) rtl/dongle/dongle_type4.v:76 Load MSB: counter[14:8] = {cpu_dout[6:0], 1'b0} (decocass_m.cpp:918, note the mask is 0x7f) rtl/dongle/dongle_type4.v:87 Load LSB: counter[7:0] = cpu_dout (decocass_m.cpp:932) rtl/dongle/dongle_type4.v:94 Read handler: auto-increment counter on even-address read (decocass_m.cpp:884-892) rtl/dongle/dongle_type4.v:109 PROM address generation: 15-bit counter (decocass_m.cpp:887) rtl/dongle/dongle_type4.v:115 Output data mux: PROM vs. MCU passthrough (decocass_m.cpp:866-910) rtl/dongle/dongle_type5.v:11 Reference: decocass_m.cpp lines 950-1016 rtl/dongle/dongle_type5.v:13 State variables (from decocass_m.cpp): - m_type5_latch : Enable latch (set when cpu_dout[7:4] == 0xC on odd-address write) rtl/dongle/dongle_type5.v:16 Write behavior (decocass_m.cpp:992-1016): - Odd address ($E5x1): Set latch If latch == 1: No-op (line 998) If cpu_dout[7:4] == 0xC0: Set latch = 1 (line 1002) Otherwise: Forward to MCU (line 1015) - Even address ($E5x0): Handled by MCU pass rtl/dongle/dongle_type5.v:23 Read behavior (decocass_m.cpp:950-990): - Odd address ($E5x1): Return MCU status (line 958) - Even address ($E5x0): Return 0x55 if latch == 1 (line 971) Otherwise: Return MCU data or open-bus (lines 978-985) rtl/dongle/dongle_type5.v:43 2026-05-18: 8-bit per MAME rtl/dongle/dongle_type5.v:52 Synchronous state updates (decocass_m.cpp:992-1016, decocass_type5_w) rtl/dongle/dongle_type5.v:60 Write handler (decocass_m.cpp:992-1016) rtl/dongle/dongle_type5.v:75 Output data mux: Fixed 0x55 vs. MCU passthrough (decocass_m.cpp:950-990) rtl/dongle/dongle_widel.v:8 Reference: decocass_m.cpp:1068-1146 (decocass_widel_r/_w), decocass.h:445-464. rtl/dongle/dongle_widel.v:10 MAME semantics (offset bit1 already resolved upstream — the wrapper only routes here when cpu_addr[1]==0, i.e. $E5x0/$E5x1; $E5x2/$E5x3 go to the shared STATUS byte path outside this module, same convention as type1-5): rtl/dongle/dongle_widel.v:18 Read $E501 (odd): - data = mcu_dbb_sts ALWAYS (latched or not) - latched ONLY: ctrs += 0x100 as a READ side effect (wraps mod 0x100000) (the counter still advances even though the returned byte is MCU status, not PROM data — this is genuine rtl/dongle/dongle_widel.v:24 Write $E501 (odd): - latched: ctrs <= 0 (BOTH halves cleared; the written value is ignored — comment in MAME source: Treasure Island depends on this clearing the lower bits too) - not latched, (data[7:4]==0xC): latch <= 1 (activation rtl/io/inputs.v:30 Raw input bus (from MiSTer hps_io via Arcade-DECOCassette.sv, task 26) Active-low for joysticks, buttons, coins per MAME INPUT_PORTS_START rtl/io/inputs.v:40 TODO(verify-with-mame): MCU controls input mux for cdsteljn mahjong rtl/io/inputs.v:47 Address decode for $E6xx (combinational read mux) Reference: decocass_m.cpp line 182-199, decocass_input_r(offset) rtl/io/inputs.v:64 TODO(verify-with-mame): handled by separate module rtl/io/inputs.v:73 Note: decocass.cpp line 214 defines DSW1[7] as: PORT_BIT( 0x80, IP_ACTIVE_HIGH, IPT_CUSTOM) PORT_READ_LINE_DEVICE_MEMBER("screen", FUNC(screen_device::vblank)) rtl/io/mahjong_panel.v:4 MAME init_cdsteljn: $E413 bits 3:2 select one of 4 rows; $E600/$E601 read the selected row for P1/P2, active-high: row 0: unused (0x00) row 1: A B C D E F G (bits 0-6) row 2: H I J K L M N (bits 0-6) row 3: Chi Pon Kan Reach Ron (bi rtl/io/quadrature_adc.v:5 Cycle-accurate relative to MAME decocass_m.cpp: - decocass_quadrature_decoder_reset_w (line 161-166): latches all 4 axes - decocass_adc_w (line 168-170): no-op (ADC not actually used in cfishing) - decocass_input_r (line 182-199): reads qua rtl/io/quadrature_adc.v:11 MAME simply latches analog[4] at reset and reads back. rtl/io/quadrature_adc.v:43 Per MAME decocass_m.cpp line 161-166: void decocass_quadrature_decoder_reset_w(uint8_t data) { for (int i = 0; i < 4; i++) m_quadrature_decoder[i] = m_analog[i]->read(); // 0x10..0xf0 rtl/io/quadrature_adc.v:57 Center position (matches default 0x80 from decocass.cpp) rtl/io/quadrature_adc.v:70 cpu_we_adc at $E420-$E42F is a no-op in MAME (line 168-170) No action needed. rtl/io/quadrature_adc.v:83 For now, MAME cfishing emulation does NOT require true quadrature simulation—it only latches and reads back raw ADC values. rtl/io/watchdog.v:16 Screen update at line 741 of decocass_v.cpp computes: flip_screen_set(m_watchdog_flip & BIT(m_dsw[0]->read(), 6)) where m_dsw[0] is DSW1 and bit 6 is the Cabinet (cocktail) bit. rtl/io/watchdog.v:44 Watchdog counter logic Reference: decocass_v.cpp lines 388-393 rtl/io/watchdog.v:61 CPU writes to $E300: reload counter and clear reset Reference: decocass.cpp line 391-392 rtl/io/watchdog.v:78 Flip register and screen-flip output Reference: decocass_v.cpp lines 395-400, screen_update_decocass line 741 rtl/io/watchdog.v:95 CPU writes to $E301: store data Reference: decocass_v.cpp line 399 rtl/io/watchdog.v:101 Compute flip_screen: XOR of the flip register with cocktail DSW bit Reference: decocass_v.cpp line 741 (slightly reinterpreted for Verilog) flip_screen_set(m_watchdog_flip & BIT(m_dsw[0]->read(), 6)) rtl/io/watchdog.v:105 In MAME, this appears to AND the register with the DSW bit, but the task description says "XOR with DSW1[6]". rtl/io/watchdog.v:106 Let's verify: - MAME line 741: flip_screen_set(m_watchdog_flip & BIT(m_dsw[0]->read(), 6)) - This is an AND, not XOR. rtl/io/watchdog.v:110 TODO(verify-with-mame): Confirm flip_screen polarity. rtl/io/watchdog.v:111 Currently implementing the MAME version (AND). rtl/io/watchdog.v:116 AND as per MAME line 741 rtl/io/watchdog.v:123 Unused inputs (for reference): - cpu_dout[7:4] during $E300 write: ignored by watchdog (used for other purposes) - cpu_dout[7:4] during $E301 write: TODO(verify-with-mame) — not documented - BIT(cpu_dout, 3) on $E301 write: enables/disables rtl/mcu/i8041_top.v:134 DMEM-RAM-128-2026-06-04: the DECO MCU is an I8041A (decocass.cpp:1025) = 128 bytes of internal RAM, NOT 64. rtl/mcu/mcu_tape_iface.v:9 Pin mappings per decocass_m.cpp (lines 1734-1835): rtl/mcu/mcu_tape_iface.v:11 P1 (tape data/status in; motor/direction/speed out): P1.0 ← tape_data (MAME: ~data bit if set, see decocass_m.cpp line 1778) P1.1 ← tape_clock (MAME: ~clk bit if set, line 1779) P1.2 ← tape_bot (MAME: ~BOT# if set, line 17 rtl/mcu/mcu_tape_iface.v:24 T0/T1 (timer inputs): T0 ← tape direction sensor (TODO: verify mapping in MAME) T1 ← tape status bit (TODO: verify mapping in MAME) rtl/mcu/mcu_tape_iface.v:96 P1 Wiring (decocass_m.cpp lines 1734-1789) rtl/mcu/mcu_tape_iface.v:99 That was WRONG: per MAME's i8041_p1_r (decocass_m.cpp:1768-1789), P1 reads return `m_i8041_p1` unchanged — i.e. whatever the MCU LAST WROTE. rtl/mcu/mcu_tape_iface.v:115 For OUR tape_streamer, we need to derive motor/direction/speed from P1.4/5/2 according to the MAME-decoded LOG semantics: FAST = ~P1.2 (bit 2 = 0 means fast) REW = ~P1.4 (bit 4 = 0 means rewind active) FWD = ~P1.5 (bit 5 = 0 means forward rtl/mcu/mcu_tape_iface.v:124 No external drives on P1 (per MAME) rtl/mcu/mcu_tape_iface.v:129 TAPE-DIR-2026-06-04: a MAME-LITERAL swap (rew=~P1.5, fwd=P1.5&~P1.4, from i8041_p1_w where bit5=0 => NEGATIVE speed) was TRIED and REVERTED — it REGRESSED on FPGA: with the ORIGINAL decode the tape reads blocks (counter 999->998, then ERROR rtl/mcu/mcu_tape_iface.v:135 MAME's bit5=0=>negative is a DIFFERENT physical convention (reads while rewinding) that does NOT map onto this streamer's clockpos layout. rtl/mcu/mcu_tape_iface.v:144 (Why MAME's negative-speed read works in MAME but not ported = unresolved; not the bug to chase — the $05 garbage on a FORWARD read is.) MAME-literal kept for reference (do NOT re-enable — proven worse): wire rew_active = ~mcu_p1_out[5]; w rtl/mcu/mcu_tape_iface.v:162 P2 Wiring (decocass_m.cpp lines 1791-1835) rtl/mcu/mcu_tape_iface.v:165 Per MAME's i8041_p2_r (line 1816): data = (m_i8041_p2 & ~0xe0) \| m_cassette->get_status_bits(); So P2[7:5] are OR'd with the cassette status bits, while P2[4:0] come from the MCU's own latched writes. rtl/mcu/mcu_tape_iface.v:171 From decocass_tape.cpp:288-338 (get_status_bits): bit 0x20 = BOT/EOT (set in LEADER, BOT, EOT, TRAILER regions) bit 0x40 = RCLK (read clock — active in data region) bit 0x80 = RDATA (read data bit) rtl/mcu/mcu_tape_iface.v:192 T0/T1 Wiring — MAME does NOT register callbacks for T0/T1 on the MCU (decocass.cpp:1026-1029 only wires P1/P2). rtl/mcu/mcu_tape_iface.v:291 MAME-PARITY 2026-05-30: route the host strobe to the i8041 ONLY for $E5x0/$E5x1 (offset bit1 == 0). rtl/mcu/mcu_tape_iface.v:292 MAME `decocass_e5xx_w` sends a 6502 write to `upi41_master_w` only when (offset & E5XX_MASK[0x02]) == 0; $E5x2/$E5x3 are STATUS/dongle space and must NOT reach the MCU. rtl/mcu/mcu_tape_iface.v:312 MAME-PARITY 2026-05-30: gated e5_we_mcu/e5_re_mcu (was cpu_e5_we/cpu_e5_re) so only $E5x0/$E5x1 reach the MCU; $E5x2/$E5x3 no longer strobe it. rtl/mcu/mcu_tape_iface.v:378 DONGLE-E5XXMASK-GATE-2026-06-27: MAME routes ONLY $E5x0/$E5x1 (offset & E5XX_MASK[0x02])==0 to the dongle (decocass_e5xx_r:1200/1227, decocass_e5xx_w); $E5x2/$E5x3 are STATUS and NEVER reach m_dongle_r/_w. rtl/mcu/mcu_tape_iface.v:392 Return result to main CPU — MAME splits behavior on (offset & E5XX_MASK) where E5XX_MASK = 0x02 (decocass_m.cpp:212): rtl/mcu/mcu_tape_iface.v:395 (offset & 2) == 2 → STATUS byte composed from MCU/cassette state (decocass_m.cpp:1199-1213) (offset & 2) == 0 → dongle data path (decocass_m.cpp:1227-1233) rtl/mcu/mcu_tape_iface.v:406 Status byte mapping (MAME decocass_m.cpp:1204-1212): D7 = !cassette_present (active-low; 0 = present) D6 = 1 (floating input) D5 = 1 (floating input) D4 = bot_eot (BOT/EOT direct from drive rtl/mcu/mcu_tape_iface.v:446 MAME `decocass_e5xx_r` returns DBBOUT LIVE (m_dongle_r, no latch). rtl/mcu/mcu_tape_iface.v:461 TODO(verify-with-mame): P2[7:4] status bit sources (tape BOT/EOT, etc.) TODO(verify-with-mame): T0/T1 timer input mapping in decocass_m.cpp TODO(new-signal-decocass.v): Add cpu_re_e5xx strobe (currently only cpu_we_e5xx exists) TODO(new-sig rtl/mcu/tape_streamer.v:1 DECO Cassette System — Tape Streamer Synthesized implementation of decocass_tape.cpp rtl/mcu/tape_streamer.v:7 Mirroring MAME decocass_tape.cpp: maintains clockpos (tape position), computes region/byte/bit from clockpos, reads image bytes, applies CRC16, and outputs serial stream with framing. rtl/mcu/tape_streamer.v:39 Constants from decocass_tape.cpp rtl/mcu/tape_streamer.v:59 Data block structure (MAME decocass_tape.h BYTE_BLOCK_TOTAL = 331): PRE_GAP(34) + LEADIN(1) + HEADER(1) + DATA(256) + CRC_MSB(1) + CRC_LSB(1) + TRAILER(1) + LEADOUT(1) + LONGCLOCK(1) + POSTGAP(34) = 331 bytes FIX 2026-05-30: was 297 — the p rtl/mcu/tape_streamer.v:132 MAME \|speed\| is 7 (fast) or 1 (normal); speed_select==2'b10 = fast. rtl/mcu/tape_streamer.v:207 Region detection (mirrors MAME lines 232-275) rtl/mcu/tape_streamer.v:242 TAPE-EOT-FIX-2026-06-04: mirror of the leader side, measured down from total_clocks (MAME decocass_tape.cpp:251-258). rtl/mcu/tape_streamer.v:266 Current byte value selection Mirrors MAME get_status_bits() logic rtl/mcu/tape_streamer.v:293 MAME never sees this (lockstep functional model, no async sampling). rtl/mcu/tape_streamer.v:296 RCLK unchanged (still MAME-faithful). rtl/mcu/tape_streamer.v:311 Output: tape_clock (active high during clocked regions, MAME line 304-315) rtl/mcu/tape_streamer.v:318 MAME decocass_tape.cpp:305 — read clock (bit 0x40) is HIGH when (clockpos-offset) is EVEN. rtl/mcu/tape_streamer.v:319 even -> 1, odd -> 0 (== MAME 0x40) rtl/mcu/tape_streamer.v:321 FIX 2026-05-30: was `~clk_bit`, which inverted the read clock vs MAME -> MCU sampled tape data on the wrong edge -> no valid bytes -> "deck not responding". rtl/mcu/tape_streamer.v:324 alternating read clock (MAME polarity) rtl/mcu/tape_streamer.v:328 Output: tape_bot and tape_eot (hole sense signals) Mirrors MAME get_status_bits() lines 292-294 rtl/mcu/tape_streamer.v:332 TAPE-EOT-FIX-2026-06-04: MAME sets the 0x20 hole-sense in LEADER\|BOT\|EOT\|TRAILER rtl/mcu/tape_streamer.v:333 (get_status_bits, decocass_tape.cpp:293). rtl/mcu/tape_streamer.v:339 end-side holes (combined = MAME 0x20) rtl/ram_rom/cassette_loader.v:8 CRC16 implementation per MAME `decocass_tape.cpp:136-145` (`tape_crc16_byte`): for (i = 0; i < 8; i++) { crc = (crc >> 1) \| (crc << 15); // rotate right crc ^= (data << 7) & 0x80; // current data bit -> bit 7 if (crc & 0x80) crc ^= rtl/ram_rom/cassette_loader.v:20 MAME brute-forces `testval` (decocass_tape.cpp:109-112) but always lands on the running CRC, so storing the running CRC directly is exactly correct — no brute-force needed. rtl/ram_rom/cassette_loader.v:71 FIX 2026-05-30: the original omitted MAME's `data >>= 1;` (line 144), so it XORed bit 0 of `d` on all 8 iterations instead of bits 0..7 — i.e. it dropped 7 of every 8 data bits. rtl/ram_rom/cassette_loader.v:91 MAME line 144 — advance to next data bit rtl/ram_rom/cassette_loader.v:111 NUMBLOCKS-FIX-2026-06-07: track the LAST NON-ZERO byte (MAME: numblocks = ((last_nonzero\|0xFF)+1)/256), NOT the full file size. rtl/video/video_bg.v:8 This is the MAME-faithful structure (decocass_v.cpp draw_edge:625, get_bg_l/r:199-219, video_start:700-704, tile_offset[3232]:130-163). rtl/video/video_bg.v:16 If BurgerTime/LnC shift by ~256px on the first build, that pins the hcnt/vcnt-vs-MAME origin delta (read it via MAME's screen_update popmessage: key 'I' → mode/h/vl/vr) and we add a constant origin offset. rtl/video/video_bg.v:24 MAME reference (decocass.cpp:961-970 tilelayout, decocass_v.cpp:130-163 tile_offset, decocass_v.cpp:199-228 get_bg__tile_info): - 32×32 tilemap of 16×16-pixel tiles - 16 unique tile bitmaps (4-bit tile_code), 3 bits per pixel - tilemap cod rtl/video/video_bg.v:34 Pixel-byte mapping (per MAME tilelayout): tile N, row y, pixel x (16 pixels per row): rtl/video/video_bg.v:57 FG color register — also drives BG color (decocass_v.cpp:201-204) rtl/video/video_bg.v:109 tile_offset LUT — full 32×32 (decocass_v.cpp:130-163). rtl/video/video_bg.v:152 BG-SKEWFIX-2026-06-28: the tile-code BRAM (bg_tilecodes) has 1-cycle read latency, so `tilecode_byte` reflects the tile from hcnt N-1 while pix_x/eff_pix_y/blank_comb are from hcnt N. Latching them together (original s1 below) drew tile N-1 rtl/video/video_bg.v:227 Extract pixel bits from the bytes: plane 0: byte[4 + pix_x[1:0]] — upper nibble of $D0xx byte plane 1: byte[0 + pix_x[1:0]] — lower nibble of $D4xx byte plane 2: byte[4 + pix_x[1:0]] — upper nibble of $D4xx byte BG-BITMAP-FIX-2026-06-10: MS rtl/video/video_bg.v:242 Output: palette index per MAME get_bg_l_tile_info (decocass_v.cpp:199-208): color = (m_color_center_bot >> 7) & 1 (1 bit) tileinfo.set(2, tile_code, color * 4 + 1, 0) Use {1'b0, color, pen[2:0]} (5-bit). rtl/video/video_bg.v:249 PALETTE-BG-COLORSET-2026-06-28: emit the FULL 6-bit pen per MAME gfx(2) color = `color4+1`. rtl/video/video_fg.v:5 Geometry: 32 cols × 32 rows × 8×8 pixels = 256×256 px tilemap Scan order: column-major per MAME decocass_v.cpp:187-192 fgvideoram_scan_cols rtl/video/video_fg.v:21 Previous version was 2 planes × 4 KB = 8 KB total (vs. MAME's 3 planes × 8 KB = 24 KB), used 8-bit tile codes (vs. 10-bit), and built fg_pen as `{attr[2:0], pen[1:0]}` (vs. MAME's `{0, color_center_bot[0], pen[2:0]}`). rtl/video/video_fg.v:28 See `Common-Pitfalls/MAME palette address transforms are load-bearing` and [[decocass_white_screen_audit_2026-05-16]] for the full investigation. rtl/video/video_fg.v:48 FG color register (decocass.cpp E410 — get_fg_tile_info uses BIT(.,0)) rtl/video/video_fg.v:85 fgvram & colorram have a SWIZZED MIRROR at $C800-$CFFF per MAME `mirrorvideoram_w` (decocass_m.cpp:72-73): swap upper 5 bits and lower 5 bits of the 10-bit offset. rtl/video/video_fg.v:112 10-bit tile code per MAME get_fg_tile_info: tile_index = 256 (attr & 3) + code = {attr[1:0], code[7:0]} rtl/video/video_fg.v:155 FLIP-FIX 2026-05-30: MAME's gfx decode is MSB-FIRST — pixel x reads bit (7-x) via the `(src >> (7 - (bit&7)))` extraction, NOT "bit x". rtl/video/video_fg.v:184 FG palette index — MAME get_fg_tile_info: tileinfo.set(0, // gfx 0 (charlayout) 256 * (attr & 3) + code, // tile index BIT(m_color_center_bot, 0), // color = 0 or 1 0); g rtl/video/video_missiles.v:7 MAME decocass_v.cpp:572-617 draw_missiles. rtl/video/video_missiles.v:99 upper drawn after lower in MAME → upper wins on overlap rtl/video/video_mixer.v:1 DECO Cassette — Final pixel mixer + LS148 priority encoder (task 11) Implements the priority order from MAME screen_update_decocass (decocass_v.cpp:719-784) and draw_special_priority / draw_edge / draw_center effects. rtl/video/video_mixer.v:5 Priority order (from decocass_v.cpp 743-780): 1. rtl/video/video_mixer.v:7 If mode_set & 0x08: draw_edge ×2 (opaque, decocass_v.cpp:747-751) 3. rtl/video/video_mixer.v:8 If mode_set & 0x20: draw_center (opaque, decocass_v.cpp:753-755) Else: draw_center, then draw_edge ×2 (transparent, decocass_v.cpp:757-764) 4. rtl/video/video_mixer.v:10 FG tilemap (transparent on pen 0, decocass_v.cpp:771) 5. rtl/video/video_mixer.v:11 Sprites (transparent on pen 0, decocass_v.cpp:774) 6. rtl/video/video_mixer.v:12 Missiles (transparent on pen 0, decocass_v.cpp:777) 7. rtl/video/video_mixer.v:13 draw_special_priority (headlight/tunnel pen-bit-4 modulation, decocass_v.cpp:780) rtl/video/video_mixer.v:60 Priority multiplexer following decocass_v.cpp 719-784 rtl/video/video_mixer.v:63 Base fill color (pen 8, from decocass_v.cpp:744) rtl/video/video_mixer.v:72 TODO(verify-with-mame): draw_special_priority headlight/tunnel detection decocass_v.cpp:235-290 checks: - crossing = mode_set[1:0] (0=outside, 1=exiting, 2=inside, 3=entering) - pri2 condition depends on crossing and back_h_shift (tunnel en rtl/video/video_mixer.v:95 Step 2: Draw edge opaque if bkg_ena and edge_valid From decocass_v.cpp:747-751 rtl/video/video_mixer.v:104 Step 3: Draw center or edge transparent From decocass_v.cpp:753-765 rtl/video/video_mixer.v:107 Center color from decocass_v.cpp:292-304 Bits [4:2] of color_center_bot -> pen color [2:0] But decocass_paletteram_w uses bits [2:0] of written byte as color index For center: use color_center_bot bits as direct pen value TODO(verify-with-m rtl/video/video_mixer.v:122 Step 4: FG tilemap (transparent on pen 0, decocass_v.cpp:771) rtl/video/video_mixer.v:128 Step 5: Sprites (transparent on pen 0, decocass_v.cpp:774) rtl/video/video_mixer.v:134 Step 6: Missiles (transparent on pen 0, decocass_v.cpp:777) rtl/video/video_mixer.v:140 Step 7: draw_special_priority (decocass_v.cpp:780) TODO(verify-with-mame): full headlight/tunnel logic From decocass_v.cpp:235-290: - crossing = mode_set[1:0] - if (crossing == 0 && !tunnel_active) return - if (!cross_on) return - color = b rtl/video/video_palette.v:4 Architecture (from decocass_v.cpp and decocass.cpp): - 64 logical pens (0-63) - Pens 0-31 map directly to CLUT entries 0-31 - Pens 32-63 map to CLUT entries with bitswap applied (bit flip for headlight mode) - Palette RAM ($E000-$E0FF, 256 rtl/video/video_palette.v:12 From decocass_v.cpp:323-333 (decocass_paletteram_w): - offset = (offset & 31) ^ 16 // XOR A4 (bit 4) into the CLUT index - RGB output is inverted: ~data[2:0] for R, ~data[5:3] for G, ~data[7:6] for B - pal3bit(x) = (x<<5)\|(x<<2)\|(x>>1) // rtl/video/video_palette.v:18 From decocass.cpp:1004-1012 (decocass_palette): - Pens 0-31: set_pen_indirect(i, i) - Pens 32-63: set_pen_indirect(32+i, bitswap(i, 7,6,5,4,3,1,2,0)) rtl/video/video_palette.v:42 Palette RAM: 256-byte dual-port BRAM Stores PROM color indices (5 bits per entry) CPU writes at $E000-$E0FF; read indexed by pen[4:0] Note: pen[5] selects between two alternate palettes (direct vs. bitswapped) which is handled by the indire rtl/video/video_palette.v:50 INVERT-AT-WRITE 2026-05-16: real hardware has inverters on the palette ROM output (the `~data` in MAME's decocass_paletteram_w). rtl/video/video_palette.v:59 Any actual BIOS-written byte gets its bits inverted on storage; the downstream decode then takes the bits directly, producing the same final RGB as MAME's `~data` formula. rtl/video/video_palette.v:64 PALETTE-BG-COLORSET-2026-06-28: pens 32-63 use MAME's BITSWAPPED indirect half (decocass_palette: set_pen_indirect(32+i, bitswap<8>(i,7,6,5,4,3,1,2,0)) = swap pen bits 1↔2). rtl/video/video_palette.v:80 Direct RGB decode from the palette byte (MAME decocass_paletteram_w). rtl/video/video_palette.v:83 The byte stored in the palette encodes RGB directly per decocass_v.cpp:323-333: m_palette->set_indirect_color(offset, rgb_t(pal3bit(~data >> 0), // R pal3bit(~data >> 3), // G pal2bit(~data >> 6))); // B rtl/video/video_sprites.v:5 References: MAME decocass_v.cpp:524-569 draw_sprites MAME decocass.cpp:950-959 spritelayout (16,16, 256, planes=3, the offsets below) rtl/video/video_sprites.v:10 Per slot, interleave 0x20: [offs+0x00] flags : bit0 = enable, bit1 = flipy, bit2 = flipx [offs+0x20] code : 0..255 (index into the 16×16 sprite set in charram) [offs+0x40] Y : sy = 240 - Y [offs+0x60] X : sx = 240 - X Draw order s rtl/video/video_timing.v:1 DECO Cassette — Video timing generator (task 07) Raster counters + HSYNC/VSYNC/HBLANK/VBLANK generation Derived from MAME's set_raw(HCLK, 384, 08, 256, 272, 18, 248) Says it matches, follows or was checked against MAME — 19 Arcade-DECOCassette.sv:936 This drops the rt_seen05E2 game-PC dependency and matches MAME's idle $E500=0. Arcade-DECOCassette.sv:955 Ungated now, matching the darksoft path and MAME. Arcade-DECOCassette.sv:1485 The hblank/vblank windows themselves already match MAME set_raw(384,0,256,272,8,248), so ONLY this alignment delay is needed -- nothing in vcnt/vblank. rtl/decocass.v:12 This matches MAME's DECO_222(config, m_maincpu, HCLK4) at decocass.cpp:1018. rtl/dongle/dongle_darksoft.v:11 The read returns the byte at the CURRENT address; the increment lands on the next ce_hclk4 edge, so the 6502 (which samples cpu_din_full combinationally during its slow ce_main read) always sees the pre-increment byte — matching MAME order. rtl/dongle/dongle_mux.v:7 2026-05-18 — REWORKED interface to match MAME: - Each dongle returns 8-bit `cpu_din_full` (was 4-bit `cpu_din_low4`). rtl/dongle/dongle_type1.v:9 2026-05-30 RE-KEY: game_id is now the DECO RELEASE NUMBER (8-bit), matching MAME's numbering (decocass.cpp per-game release-number comments). rtl/io/quadrature_adc.v:63 Latch the four analog inputs at reset time This matches MAME's behavior exactly: rtl/mcu/mcu_tape_iface.v:139 DIRECTION: tested MAME-literal (rew=~P1.5/fwd=P1.5&~P1.4) WITH the probe 2026-06-04 → MEASURABLY WORSE: tape ran to the clockpos-0 wall, read_block never dispatched ($2E8 dark), nothing delivered (ROW2/3 = $00), BOT-now lit. rtl/mcu/mcu_tape_iface.v:154 FIX 2026-05-30: speed_select now encodes MAGNITUDE only (direction is tape_direction above); 00=stop, 01=normal(1x), 10=fast(7x) — matches MAME \|speed\| 0/1/7. rtl/mcu/mcu_tape_iface.v:384 Gate the strobes to $E5x0/1 to match MAME's E5XX_MASK. rtl/mcu/tape_streamer.v:322 Now matches MAME line 305. rtl/ram_rom/cassette_loader.v:70 CRC16 step matching MAME `tape_crc16_byte` (decocass_tape.cpp:136-145) exactly. rtl/ram_rom/cassette_loader.v:73 (The predecessor's "only bit 0 contributes" comment was them missing line 144.) With the shift, the CRC is correct, and since testval == running-CRC for this polynomial (verified), storing the running CRC below is exactly MAME's brute-force rtl/video/video_fg.v:8 CHARACTER FORMAT — VERIFIED FROM MAME decocass.cpp:939-948 `charlayout`: - 8×8 pixel characters - 1024 characters total (10-bit tile code) - 3 bits per pixel — THREE planes - Plane offsets: 0, 8192, 16384 bytes (in CPU $6000-$BFFF region) - rtl/video/video_palette.v:93 pal3bit (3-bit → 4-bit) closed-form: out = {x, x[2]} verifies: 0→0, 1→2, 2→4, 3→6, 4→9, 5→11, 6→13, 7→15 (matches MAME) pal2bit (2-bit → 4-bit) closed-form: out = {x, x} verifies: 0→0, 1→5, 2→10, 3→15 (matches MAME) rtl/video/video_palette.v:105 That makes default-0 BRAM decode to BLACK (matching MAME's default state) and BIOS-written bytes decode to the same final RGB as MAME's `~data`. rtl/video/video_sprites.v:106 Per-pixel priority select: highest slot index covering (hcnt,vcnt) wins (matches MAME draw order). rtl/video/video_timing.v:67 TOP-EXPAND-2026-06-29: high edge 255->257 = +2 rows at the display-TOP (high hcnt) to restore the 2 truncated BG rows / match MAME. Says it was translated, ported or taken from MAME — 5 rtl/cpu/deco222.v:28 The old D1<->D6 swap was WRONG (predecessor mis-transcribed MAME): it turned the BIOS reset entry $F053 (raw 38 B8 C2 FF 9A) into SEC/CLV/illegal garbage, and $F615 raw $DD into illegal $9F (CPU jammed there = the black-screen hang). rtl/decocass.v:7 Based on MAME src/mame/deco/decocass.cpp: - decocass_map (lines 88-127): address map decode - decocrom_map (lines 130-134): extended banking (not yet implemented) rtl/io/inputs.v:8 Based on MAME src/mame/deco/decocass_m.cpp: - decocass_input_r (lines 182-199): dispatches by offset[2:0] rtl/io/watchdog.v:9 Based on MAME src/mame/deco/decocass_v.cpp: - decocass_watchdog_count_w (lines 388-393): loads counter with (data & 0x0f) + 1, calls watchdog_reset() to clear overflow. rtl/mcu/tape_streamer.v:213 Ported MAME's symmetric end-of-tape boundaries (decocass_tape.cpp:251-258), measured DOWN from total_clocks (mirror of the leader side). Shares text with the MAME driver without saying so — 24 Arcade-DECOCassette.sv:282 sw[2]=DSW1=0x3F : Coin 1C/1C, "Type of Tape"=MD(Small)=0x30 (SW1:5,6, "Used by the bios"), Upright — shares text with dataeast/decocass.cpp:206 Arcade-DECOCassette.sv:1389 m_palette->set_indirect_color(offset, ...); — shares text with dataeast/decocass_v.cpp:332 rtl/dongle/dongle_type1.v:57 chwy (DECO release 1) -latch_27_pass_3_inv_2 — shares text with dataeast/decocass_m.cpp:413 rtl/dongle/dongle_type1.v:65 cterrani (DECO release 4) -latch_26_pass_3_inv_2 — shares text with dataeast/decocass_m.cpp:357 rtl/dongle/dongle_type1.v:73 castfant (DECO release 7) -latch_16_pass_3_inv_1 — shares text with dataeast/decocass_m.cpp:439 rtl/dongle/dongle_type1.v:81 csuperas (DECO release 9) -latch_26_pass_3_inv_2 flip4-5 — shares text with dataeast/decocass_m.cpp:357 rtl/dongle/dongle_type1.v:89 clocknch (DECO release 11) -latch_26_pass_3_inv_2 flip2-3 — shares text with dataeast/decocass_m.cpp:357 rtl/dongle/dongle_type1.v:97 cprogolf (DECO release 13) -latch_26_pass_3_inv_2 flip0-1 — shares text with dataeast/decocass_m.cpp:357 rtl/dongle/dongle_type1.v:101 cdsteljn (DECO release 14) -latch_27_pass_3_inv_2 — shares text with dataeast/decocass_m.cpp:413 rtl/dongle/dongle_type1.v:105 cluckypo (DECO release 15) -latch_26_pass_3_inv_2 flip1-3 — shares text with dataeast/decocass_m.cpp:357 rtl/dongle/dongle_type1.v:109 ctisland (DECO release 16) -latch_26_pass_3_inv_2 flip0-2 — shares text with dataeast/decocass_m.cpp:357 rtl/dongle/dongle_type1.v:118 cexplore (DECO release 18) -latch_26_pass_5_inv_2 — shares text with dataeast/decocass_m.cpp:426 rtl/dongle/dongle_type3.v:127 (decocass_m.cpp line 630: `data = m_donglerom[m_type3_ctrs];`) — shares text with dataeast/decocass_m.cpp:630 rtl/dongle/dongle_widel.v:1 ============================================================================ Widel Dongle — 20-bit Counter + 1 MB ROM (David Widel multigame kit) Implement — shares text with dataeast/decocass_m.cpp rtl/io/quadrature_adc.v:44 void decocass_quadrature_decoder_reset_w(uint8_t data) { — shares text with dataeast/decocass.h:182 rtl/io/quadrature_adc.v:45 for (int i = 0; i < 4; i++) — shares text with dataeast/decocass_m.cpp:164 rtl/io/quadrature_adc.v:46 m_quadrature_decoder[i] = m_analog[i]->read(); // 0x10..0xf0 — shares text with dataeast/decocass_m.cpp:165 rtl/mcu/mcu_tape_iface.v:167 data = (m_i8041_p2 & ~0xe0) \| m_cassette->get_status_bits(); — shares text with dataeast/decocass_m.cpp:1816 rtl/video/video_bg.v:243 color = (m_color_center_bot >> 7) & 1 (1 bit) — shares text with dataeast/decocass_v.cpp:201 rtl/video/video_fg.v:187 BIT(m_color_center_bot, 0), // color = 0 or 1 — shares text with dataeast/decocass_v.cpp:227 rtl/video/video_palette.v:20 - Pens 32-63: set_pen_indirect(32+i, bitswap(i, 7,6,5,4,3,1,2,0)) — shares text with dataeast/decocass.cpp:1010 rtl/video/video_palette.v:65 (decocass_palette: set_pen_indirect(32+i, bitswap<8>(i,7,6,5,4,3,1,2,0)) = swap pen bits 1↔2). — shares text with dataeast/decocass.cpp:1010 rtl/video/video_palette.v:85 m_palette->set_indirect_color(offset, — shares text with dataeast/decocass_v.cpp:332 rtl/video/video_timing.v:3 Derived from MAME's set_raw(HCLK, 384, 08, 256, 272, 18, 248) — shares text with dataeast/decocass.cpp:1039
Defender# Colony 7, Defender, Jin, Mayday MiSTer-devel/Arcade-Defender_MiSTer @ 041e62c7 MAME compared: williams/williams.cpp + 5 related file(s) Read: 11 HDL files, 12,720 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	6%
Statements: 2 toward MAME Cites MAME source — 1 rtl/defender.vhd:30 Use with MAME roms from defender.zip Shares text with the MAME driver without saying so — 1 rtl/defender.vhd:323 pixels \|0\|1\|2\|3\|4\|5\|0\|1\|2\|3\|4\|5\| — shares text with williams/williamsblitter.cpp:50
DenjinMakai# Denjin Makai MiSTer-devel/Arcade-DenjinMakai_MiSTer @ eb980034 MAME compared: seibu/legionna.cpp + 8 related file(s) Read: 24 HDL files, 10,836 lines (Quartus project)	MiSTer official	Mostly MAME	medium	71%
Statements: 5 toward hardware, 212 toward MAME, 1 not counted Cites hardware references or measurements that MAME's driver also gives — 1 rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:23 Main CPU memory map Denjin Makai (MAME legionna.cpp denjinmk_map:296-322): $000000-$0FFFFF ROM 68K (1MB) → SDRAM via bridge $100000-$1003FF RAM scratch (1KB) → BRAM (Main RAM low) $100400-$1006FF COP3 region — also in MAME: 68K seibu/legionna.cpp:46 Reports a measurement taken on the original PCB — 1 rtl/DenjinMakai/DenjinMakai_video_timing.sv:26 PCB measurement Blood Bros: VSync 59.4094 Hz, HSync 15.6246 kHz, master XTAL 20 MHz. Says it was checked on “real hardware” — 4 rtl/DenjinMakai/DenjinMakai_cop3.sv:336 0 : 1 (unsigned <320 provato su HW = REGRESSIONE; il signed [-160,320) dell'intento MAME e' il comportamento giusto sul core) rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:216 byte_lo = pf_rom_data[31:24]/[15:8], byte_hi = [23:16]/[7:0] Plane order DCBA (verificato su HW, come BG/MG/FG): pen[0] dal bit "D" (byte_hi[3-sub]), pen[3] dal bit "A" (byte_lo[7-sub]). rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:333 Scan INVERSO 511→0 (verificato su HW: ordine sprite-su-sprite opposto al loop MAME 0→511). rtl/DenjinMakai/DenjinMakai_tile_layer.sv:322 Plane order verificato su HW: BG/MG = DCBA (PEN_ORDER=0), FG = BADC (PEN_ORDER=1). Cites MAME source — 188 DenjinMakai.sv:186 Offset per-layer DenjinMakai: MAME visarea parte da (0,0) (set_raw vbend=0, legionna.cpp:1318) e denjinmk NON definisce scrolldx/dy per BG/MG/FG ne' sprite offset (nessun set_offset, legionna.cpp:1331) → tutti 0. DenjinMakai.sv:191 NB: denjinmk ha anche tile_scroll_base_w (legionna_v.cpp:58-65): reg base 7 → text set_scrolldy(0x1ef - data). DenjinMakai.sv:304 --- Joystick to SD Gundam input mapping --- MAME P1_P2 port ($E0002): active low. DenjinMakai.sv:307 MiSTer joy bits: joy[0]=R, joy[1]=L, joy[2]=D, joy[3]=U, joy[4]=A, joy[5]=B. MAME PLAYERS12 (legionna.cpp:439-444): bit[0]=UP, [1]=DOWN, [2]=LEFT, [3]=RIGHT, [4]=BTN1, [5]=BTN2, [6]=BTN3, [7]=unused (active low). DenjinMakai.sv:317 DenjinMakai SYSTEM port ($10074C) — MAME legionna.cpp:427-436 bit0 = START1 (active LOW) bit1 = START2 (active LOW) bit2..7 = UNKNOWN → tied 1 bit8..15 = UNKNOWN → tied 1 Coin inputs NON sono qui: vanno via SEIBU_COIN_INPUTS → Z80 → soundla DenjinMakai.sv:678 ── Flip screen (CRTC reg 0x1A bit 0) ─────────────────────────────────────── MAME: BIT(reg_1a, 0) → flip_screen. DenjinMakai.sv:724 ── Text layer renderer (8x8, 4bpp, 64x32 grid) ───────────────────────────── DenjinMakai MAME (ROM_START denjinmk): "char" = REGIONE PROPRIA 128KB (11.620/10.615, ROM_LOAD16_BYTE), NON dentro user1 come Legionnaire. DenjinMakai.sv:737 DenjinMakai text scroll-base (CRTC reg 0x3A, hook denjinmk-only legionna.cpp:1326). DenjinMakai.sv:738 Calibrazione HW di famiglia (dump vregs in seibu_crtc.cpp): Legionnaire reg=0x01FF, visarea da riga 16 → 0x1FF-0x1EF=+16 = ESATTAMENTE il vecchio yoff text +16 del core Legionnaire funzionante; D-Con reg=0xFFEF (low9=0x1EF), visarea da 0 → DenjinMakai.sv:742 La formula MAME set_scrolldy(0x1EF-data) è INVERTITA rispetto all'HW (convenzione dy del tilemap.cpp) — mai fidarsi del verso MAME. DenjinMakai.sv:745 DENJIN MAKAI: la scrolldy dinamica del text dal CRTC reg $3A NON si applica — in MAME layer_scroll_base_callback e' collegata SOLO a godzilla (legionna.cpp:1326, commento in tile_scroll_base_w: "specific for Godzilla"). DenjinMakai.sv:784 DenjinMakai CRTC scroll passthrough (MAME legionna_v.cpp:34-49 tile_scroll_w): scroll_ram[0/1] → BG (m_background_layer) scroll_ram[2/3] → MG (m_midground_layer) scroll_ram[4/5] → FG (m_foreground_layer) Nel nostro CRTC: xscroll_l0 = ram[0/ DenjinMakai.sv:802 DenjinMakai BG: tilemap 32x32 (legionna_v.cpp:204). DenjinMakai.sv:803 MAME GFXDECODE "back" color base = 0 (gfx_legionna riga 1168), 32 colorset. DenjinMakai.sv:804 HAS_TRANSP=1 perché m_background_layer->set_transparent_pen(15) in legionna_v.cpp:216 (pen 15 = trasparente, NON opaco come Blood Bros). DenjinMakai.sv:826 DenjinMakai MG: 16x16, 4bpp, 32x32 tilemap (MAME legionna_v.cpp:204). DenjinMakai.sv:827 get_mid_tile_info_share_bgrom (legionna_v.cpp:158): MG share BG ROM, tile = (vram & 0xfff) \| 0x1000 (= seconda metà della BG ROM) color = ((vram >> 12) & 0xf) \| 0x10 (= palette set superiore: bit 4 = 1) In palette MAME "back" base = 0, DenjinMakai.sv:854 DenjinMakai FG: tilemap 32x32 (legionna_v.cpp:213). DenjinMakai.sv:856 MAME GFXDECODE "fore" color base = 3216 = 0x200, 16 colorset. DenjinMakai.sv:866 DENJINMAKAI: fore = bg2.619 ROM_LOAD16_WORD_SWAP (legionna.cpp:1987) = IDENTICO alla back bg1.618 → stesso decode DCBA di BG/MG (riscontro HW utente: col BADC il FG era sbagliato). DenjinMakai.sv:874 DenjinMakai: bit 2 = FG (MAME legionna_v.cpp:344) DenjinMakai.sv:962 Anticipando di 1 l'indirizzo e il DE, il dato campionato al tick e' quello del pixel CORRENTE: allineamento coi tile ripristinato (= calibrazione +1 pixel-hunting MAME, fatta prima del fix CRT) e colonna 0 coperta. DenjinMakai.sv:996 MAME riferimenti (DENJINMAKAI — diverso da legionna!): legionna_v.cpp:247-251 m_sprite_pri_mask[0..3] per denjinmk: pri=0 → 0xFFF0 (copre pri-value 0,1,2 → bg,mg,fg → SOTTO text) pri=1 → 0xFFFC (copre 0,1 → bg,mg → sotto fg,text) pri=2 → DenjinMakai.sv:1016 MAME denjinmk legionna_v.cpp:382 bitmap.fill(0xff) "matches PCB recording" DenjinMakai.sv:1020 DENJIN MAKAI: pri 3 → mask 0x0000 = copre TUTTO, text incluso (MAME VIDEO_START denjinmk: "briefing guy in pre-stage and portraits before a boss fight"). DenjinMakai.sv:1041 Backdrop = palette[0x0FF] reale (MAME denjinmk: bitmap.fill(0xff), match PCB). rtl/DenjinMakai/DenjinMakai_audio_z80.sv:25 Spec da MAME (legionna.cpp denjinmk machine config :1295-1355): - Z80 @ 14.318180/4 = 3.579545 MHz (seibu_sound_map + denjinmk_sound_io_map) - YM2151/OPM (jt51) @ 3.579545 MHz, route ch0+ch1 0.50 su mono - OKI M6295 (jt6295) @ 20MHz/20 = 1. rtl/DenjinMakai/DenjinMakai_audio_z80.sv:364 MAME seibu_sound_device::main_r (seibusound.cpp:279): case 2,3: return sub2main[offset-2] (soundlatch data: coin/input dal Z80) case 5: return main2sub_pending ? rtl/DenjinMakai/DenjinMakai_audio_z80.sv:379 ─── YM2151 (jt51) — DENJINMAKAI usa OPM, non OPL2 (legionna.cpp:1340) ────── Il driver Z80 programma i timer OPM (reg 0x10-0x14): su jtopl2 non scattava mai l'IRQ → RST10 morto → sequencer musica fermo. rtl/DenjinMakai/DenjinMakai_audio_z80.sv:458 MAME: route 0.50+0.50 su mono (legionna.cpp:1342-1343) rtl/DenjinMakai/DenjinMakai_audio_z80.sv:461 ─── OKI bank — DENJINMAKAI: Z80 "OUT (0),A" → banco ROM OKI (512KB = 2×256KB) MAME denjinmk_sound_io_map (legionna.cpp:282-286) port 0 → denjinmk_oki_bank_w: m_oki->set_rom_bank(data & 1) (write tipica 0x02/0x03). rtl/DenjinMakai/DenjinMakai_audio_z80.sv:470 ─── OKI M6295 (jt6295) — PIN7_HIGH (20MHz/20 = 1.0 MHz, legionna.cpp:1345) rtl/DenjinMakai/DenjinMakai_cop3.sv:4 MAME-faithful implementation of the Seibu SEI300 chip as used by the `legionna` driver (DenjinMakai 1992 — Banpresto/TAD). rtl/DenjinMakai/DenjinMakai_cop3.sv:7 Reference (in this repo): MAME seibucop.cpp MAME seibucop_cmd.ipp MAME seibucop_dma.ipp MAME legionna.cpp rtl/DenjinMakai/DenjinMakai_cop3.sv:136 MAME cop_itoa_digits[10]: BCD digits of cop_itoa (low<<0 \| high<<16). rtl/DenjinMakai/DenjinMakai_cop3.sv:140 Il vecchio loop a sottrazioni ripetute era O(valore) (~valore/9 clk): con i long 32-bit di denjinmk (score, writer $156E/$1F93E) il 68k restava congelato (dma_busy include bcd_pending) fino a MILLISECONDI per chiamata — su MAME/HW reale i d rtl/DenjinMakai/DenjinMakai_cop3.sv:153 MAME cop_program command table (seibucop.cpp lines 318-457) At boot, game code uploads 32 macro slots × 8 micro-op words via pgm_addr (0x100434) → slot8 + sub-index pgm_data (0x100432) → micro-op word pgm_value (0x100438) → cop_func_valu rtl/DenjinMakai/DenjinMakai_cop3.sv:160 MAME calls find_trigger_match(triggerval, 0xff00) to find the slot whose cop_func_trigger matches. rtl/DenjinMakai/DenjinMakai_cop3.sv:256 Triggers (write-only addresses) MAME legionna.cpp:172 maps cop_cmd_w to $100500-$100505 (3 words). rtl/DenjinMakai/DenjinMakai_cop3.sv:330 0x100410 sprite_dma_inc (MAME cop_sprite_dma_inc_w): if x_clip in [-160, 320): cop_regs[4] += 8. rtl/DenjinMakai/DenjinMakai_cop3.sv:331 MA in MAME sprite_x e' uint16_t assegnato a int -> MAI negativo -> il -160 e' codice morto: check EFFETTIVO = unsigned < 320 (X "negative" 0xFFxx NON avanzano il puntatore entry). rtl/DenjinMakai/DenjinMakai_cop3.sv:336 0 : 1 (unsigned <320 provato su HW = REGRESSIONE; il signed [-160,320) dell'intento MAME e' il comportamento giusto sul core) rtl/DenjinMakai/DenjinMakai_cop3.sv:343 A size==0 NON wrappare (il size-- uint di MAME wrapperebbe a $FFFF: il loop del builder su status[1] andrebbe in livelock — provato peggio). rtl/DenjinMakai/DenjinMakai_cop3.sv:378 Macro program upload — MAME seibucop.cpp lines 318-457 pgm_data writes one micro-op word to cop_program[latch_addr] AND latches the slot's trigger/value/mask from current latch regs. rtl/DenjinMakai/DenjinMakai_cop3.sv:479 itoa_digits (MAME 0x100590-99, 5 word). rtl/DenjinMakai/DenjinMakai_cop3.sv:491 Status / dist / angle (MAME seibucop.cpp:916 cop_status_r → cop_status) rtl/DenjinMakai/DenjinMakai_cop3.sv:502 MAME open bus rtl/DenjinMakai/DenjinMakai_cop3.sv:569 commit write al dst ASSOLUTO (fill/mr), 1:1 MAME write_word(dst) rtl/DenjinMakai/DenjinMakai_cop3.sv:605 LEGACY sprite-DMA (MAME seibucop_cmd.ipp): 6880 (carica rel_xy), c480 (single-step: compone l'entry sprite a cop_regs[4]+offs con X/Y = rel + (obj - abs)). rtl/DenjinMakai/DenjinMakai_cop3.sv:629 write angolo (word {0,angle} come MAME host_endian) rtl/DenjinMakai/DenjinMakai_cop3.sv:641 Trigger latches — MAME seibucop.cpp cop_cmd_w line 1069. rtl/DenjinMakai/DenjinMakai_cop3.sv:642 MAME dispatches on raw data after clearing cop_status bit 15. rtl/DenjinMakai/DenjinMakai_cop3.sv:696 DMA mode 0x80-0x87: MAME dma_palette_brightness() fa FADE solo con pal_brightness_mode 4/5; con qualsiasi altro valore fa una COPIA SEMPLICE src->dst (ramo else, seibucop_dma.ipp:119-123) verso QUALUNQUE dst — incl. rtl/DenjinMakai/DenjinMakai_cop3.sv:704 DMA generici 0x09/0x0E: MAME write_word(dst) va nello spazio host = arriva a QUALSIASI RAM mappata, incluse le BRAM video ($101000-$105FFF: staging tilemap, palette-stage $104000, sprite $105000). rtl/DenjinMakai/DenjinMakai_cop3.sv:712 Output del fade/blend 0x8x: MAME dma_palette_brightness fa write_word(dst) nello SPAZIO HOST = raggiunge QUALUNQUE RAM mappata (pal-stage $104000, sprite $105800, Main RAM...). rtl/DenjinMakai/DenjinMakai_cop3.sv:715 Ora: pal_val registrato in D_FADE_WRITE e committato in D_FADE_COMMIT via canale fill (decode per dst assoluto in main_top: bg/fg/mg/txt/pal/spr) o mr (dst in Main RAM) — 1:1 MAME. rtl/DenjinMakai/DenjinMakai_cop3.sv:718 (Il vecchio dma80_to_spr era INVERTITO: il blit pietre e' src=$105800 dst=$104000, non il contrario — MAME map: $100478=SRC, $10047C=DST.) rtl/DenjinMakai/DenjinMakai_cop3.sv:721 LEGACY sprite-DMA state (MAME m_sprite_dma_rel_x/y, m_sprite_dma_x_clip) rtl/DenjinMakai/DenjinMakai_cop3.sv:824 MAME cop_cmd_w (seibucop.cpp:1075): rtl/DenjinMakai/DenjinMakai_cop3.sv:860 Restituisce canonical trigger value del slot (NB: MAME LEGACY_cop_cmd_w usa il match slot per dispatchare; in pratica equivale a restituire cop_func_trigger[slot]). rtl/DenjinMakai/DenjinMakai_cop3.sv:881 fade_table — MAME seibucop.cpp:733 (reverse engineered from Seibu Cup Soccer bootleg) v = pal_channel(5-bit) \| (brightness_val_xor_X) [10-bit input] low = v & 0x1F high = v & 0x3E0 return (low * (high \| (high>>5)) + 0x210) >> 10 [8-bit o rtl/DenjinMakai/DenjinMakai_cop3.sv:920 ── Hitbox b100/b900 scratch (MAME cop_collision_update_hitbox) ────────────── dx[i] = int8 (signed) byte basso, size[i] = uint8 (unsigned) byte alto del word descrittore @ hitadr2+2i. 3 assi (Y,X,Z) per DenjinMakai. rtl/DenjinMakai/DenjinMakai_cop3.sv:927 num_axis: MAME seibucop.cpp:1010 "if (data & 0x100) num_axis = 3" else 2. rtl/DenjinMakai/DenjinMakai_cop3.sv:929 res init 7 vs 3 (seibucop.cpp:1038-39). rtl/DenjinMakai/DenjinMakai_cop3.sv:956 Con 16-bit frac + 24 iter + z>>16: 0 divergenze di decisione vs MAME int(atan(dx/dy)128/pi) su ~640k casi (dimostrato numericamente). rtl/DenjinMakai/DenjinMakai_cop3.sv:1199 MAME cop_dma_trigger_w: NON modifica cop_status (vedi seibucop.cpp:741). rtl/DenjinMakai/DenjinMakai_cop3.sv:1207 MAME dma_tilemap_buffer: copy staging RAM → renderer BRAM src = cop_dma_src[mode] << 6 (byte addr 0x101000+ = staging) dst = i (loop counter 0..0x13FF = renderer index) count = 0x2800/2 = 5120 words rtl/DenjinMakai/DenjinMakai_cop3.sv:1217 MAME dma_palette_buffer: copy staging palette → renderer src = cop_dma_src[mode] << 6 (0x104000 = palette staging) dst = i (loop counter 0..0x7FF = renderer index) count = 0x1000/2 = 2048 words rtl/DenjinMakai/DenjinMakai_cop3.sv:1227 MAME write_word(dst) su spazio host: con dst nelle BRAM video ($101000-$105FFF: staging/pal/spr, es. rtl/DenjinMakai/DenjinMakai_cop3.sv:1240 simplified, MAME size>>1 rtl/DenjinMakai/DenjinMakai_cop3.sv:1245 MAME seibucop_dma.ipp dma_palette_brightness() mode 5/4. rtl/DenjinMakai/DenjinMakai_cop3.sv:1248 MAME formulas: src = cop_dma_src[mode] << 6 dst = cop_dma_dst[mode] << 6 size = ((cop_dma_size << 5) - (cop_dma_dst << 6) + $20)/2 Init: src=$106000, dst=$104000, size=($827F<<5 - $4100<<6 + $20)/2 = ($104FE0 - $104000 + $20)/2 = $1000 rtl/DenjinMakai/DenjinMakai_cop3.sv:1259 MAME size = (((size<<5) - (dst<<6) + 0x20)/2) rtl/DenjinMakai/DenjinMakai_cop3.sv:1265 MAME: mode 4/5 = fade palette; QUALSIASI ALTRO = copia semplice src->dst (seibucop_dma.ipp:119-123). rtl/DenjinMakai/DenjinMakai_cop3.sv:1275 MAME seibucop.cpp cop_dma_trigger_w case 0x116 — DENJINMAKAI: fill come 0x118 ma SENZA guard dst!=0 e length bytes = (size+1)<<4 (metà). rtl/DenjinMakai/DenjinMakai_cop3.sv:1277 legionna.cpp:56-61: "The COP-MCU appears to write to the work ram area, otherwise it RESETS in mid-animation of the title screen" → senza questo fill il gioco torna al logo da solo. rtl/DenjinMakai/DenjinMakai_cop3.sv:1288 Skip if dst != 0 (MAME guard, dma.ipp:135) rtl/DenjinMakai/DenjinMakai_cop3.sv:1301 MAME cop_cmd_w (seibucop.cpp:1073): cop_status &= 0x7fff (clear bit 15). rtl/DenjinMakai/DenjinMakai_cop3.sv:1303 MAME: cop_status &= 0x7fff (clear bit 15). rtl/DenjinMakai/DenjinMakai_cop3.sv:1318 MAME LEGACY_cop_cmd_w: find_trigger_match(data, 0xF800) → slot per GRUPPO f800, poi handler dal microcodice caricato. rtl/DenjinMakai/DenjinMakai_cop3.sv:1344 MAME execute_0205: read dword at cop_regs[0]+4+offset4 (ppos) rtl/DenjinMakai/DenjinMakai_cop3.sv:1365 0x138e / 0x338e — atan(dx/dy) MAME execute_338e. rtl/DenjinMakai/DenjinMakai_cop3.sv:1367 Parte da r1+4 hi (offset 0x0004), come 3BB0/MAME. rtl/DenjinMakai/DenjinMakai_cop3.sv:1375 r1+4 hi (MAME read_dword(r1+4) primo) rtl/DenjinMakai/DenjinMakai_cop3.sv:1390 MAME: raw_angle = cop_read_word(r0+0x34) = host_read_word(0x34^2 = 0x36); amp = cop_read_word(r0+0x36) = host_read_word(0x36^2 = 0x34). rtl/DenjinMakai/DenjinMakai_cop3.sv:1407 0xa180 — collision read pos for slot 0 MAME cop_collision_read_pos: cop_read_word(spradr+N) = host_read_word((spradr+N)^2) per host_endian=true. rtl/DenjinMakai/DenjinMakai_cop3.sv:1428 b000 NON e' un no-op: il dispatcher LEGACY di denjinmk (seibucop.cpp:1365) matcha con mask 0xf800, quindi la patch init_denjinmk (b100->b000) ESEGUE comunque l'update ma con num_axis=2 (bit8=0 = Z disattivata). rtl/DenjinMakai/DenjinMakai_cop3.sv:1536 Mode 4 (DENJINMAKAI/Denjin, seibucop_dma.ipp:87-117): indice = (val2)[4:0], val 0x0010/0xFFFF = TARGET PURO, NESSUN bypass bit15. rtl/DenjinMakai/DenjinMakai_cop3.sv:1583 MAME: m_host_space->write_word(dst, pal_val) — dst ASSOLUTO. rtl/DenjinMakai/DenjinMakai_cop3.sv:1617 MAME (0x118 e 0x116): write_dword(i, v1 \| v2<<16) su spazio BE 68k → word a i = v2, word a i+2 = v1 (alternati). rtl/DenjinMakai/DenjinMakai_cop3.sv:1630 Macro 0x0205 — linear movement (MAME execute_0205) ppos = read_dword(cop_regs[0]+0x04) vel = read_dword(cop_regs[0]+0x10) npos = ppos + vel write_dword(cop_regs[0]+0x04, npos) delta = (npos>>16) - (ppos>>16) write_word(cop_regs[0]+0x1E, re rtl/DenjinMakai/DenjinMakai_cop3.sv:1673 MAME cop_read/write_word(cop_regs[0]+0x1e) = host word @ (0x1e^2)=0x1c (host endianness word^2; conferma doc 06 micro-op 'addmem16 0x1C(r0)'). rtl/DenjinMakai/DenjinMakai_cop3.sv:1691 Macro 0x0905/0x0904 — jump (MAME execute_0904) write_dword(cop_regs[0]+0x10, read_dword(cop_regs[0]+0x10) ± read_dword(cop_regs[0]+0x28)) 0x0905 (bit 0=1) = +, 0x0904 (bit 0=0) = - rtl/DenjinMakai/DenjinMakai_cop3.sv:1717 MAME execute_0904: bit 0 di data = 1 → add, =0 → sub tmp32_a = vel ± grav. rtl/DenjinMakai/DenjinMakai_cop3.sv:1748 0x138E/0x338E atan(dx/dy) — MAME execute_338e (cmd.ipp:159) dx = read_dword(r1+4) - read_dword(r0+4) dy = read_dword(r1+8) - read_dword(r0+8) if(!dy){status\|=0x8000; angle=0} else angle=atan(dx/dy)128/pi; dy<0→+0x80 if(data&0x80) write_byt rtl/DenjinMakai/DenjinMakai_cop3.sv:1796 MAME: angle = atan(dx/dy)128/pi (+0x80 se dy<0). rtl/DenjinMakai/DenjinMakai_cop3.sv:1798 Cosi' z = atan(dx/dy) e il +0x80 (in WR) copre solo il quadrante, come MAME. rtl/DenjinMakai/DenjinMakai_cop3.sv:1800 NIENTE prescale: i dword diff sono FIXED-POINT coord<<16 (come il 3BB0 che usa dx32[31:16] e MAME dx>>16), NON interi piccoli. rtl/DenjinMakai/DenjinMakai_cop3.sv:1841 MAME (int)(...) tronca VERSO ZERO. rtl/DenjinMakai/DenjinMakai_cop3.sv:1843 BUG TROVATO (validato vs MAME su 29241 casi): il CORDIC SOTTO-CONVERGE di 1 LSB sulle DIAGONALI (es. rtl/DenjinMakai/DenjinMakai_cop3.sv:1848 Compenso l'epsilon di sotto-convergenza con +1 toward-zero PRIMA del troncamento: bias=1 azzera tutte le 133 divergenze (bias=0) -> 0/29241 vs MAME. rtl/DenjinMakai/DenjinMakai_cop3.sv:1857 MAME execute_338e (seibucop_cmd.ipp:175-188): la write dell'angolo in RAM (obj+0x34 host, gated da data&0x80) e' FUORI dall'if/else di dy -> avviene SEMPRE, anche a dy==0 (dove cop_angle=0 -> scrive 0^0x80 = 0x80). rtl/DenjinMakai/DenjinMakai_cop3.sv:1863 Ora calcolo ang_byte in entrambi i rami e scrivo SEMPRE, come MAME. rtl/DenjinMakai/DenjinMakai_cop3.sv:1870 Scrivere l'angolo anche a dy==0 ("1:1 MAME") REGREDISCE: il martello scivola/moonwalk. rtl/DenjinMakai/DenjinMakai_cop3.sv:1873 MAME: dy==0 -> cop_angle=0 rtl/DenjinMakai/DenjinMakai_cop3.sv:1896 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197) dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (aritmetico) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = sqrt(dxdx + dydy) if(data&0x80) write_word(r0 + (data&0x200?0x3a:0x38 rtl/DenjinMakai/DenjinMakai_cop3.sv:2005 (Il fix MAME-aligned 0x3a:0x38 faceva fuggire i nemici -> MAME invertito vs HW. rtl/DenjinMakai/DenjinMakai_cop3.sv:2012 MAME: macro completata → cop_status = 7 (gate-poll del gioco). rtl/DenjinMakai/DenjinMakai_cop3.sv:2098 0x8100/0x8900 sin/cos (MAME execute_8100/8900) raw_angle = cop_read_word(cop_regs[0]+0x34) & 0xff amp = (65536>>5) * (cop_read_word(cop_regs[0]+0x36) & 0xff) = 2048 * amp_byte if (raw_angle == 0xC0 sin / 0x80 cos): amp = 2 res = int( rtl/DenjinMakai/DenjinMakai_cop3.sv:2137 MAME special-case: sin && raw==0xC0 OR cos && raw==0x80 → amp = 2 rtl/DenjinMakai/DenjinMakai_cop3.sv:2183 0xa180/0xa980 — read pos (MAME cop_collision_read_pos) flags_swap = cop_read_word(spradr+2) → host_read_word(spradr+0) pos[0] = cop_read_word(spradr+6) → host_read_word(spradr+4) pos[1] = cop_read_word(spradr+10) → host_read_word( rtl/DenjinMakai/DenjinMakai_cop3.sv:2190 Però MAME cop_read_word(+2) = host_read_word(+2^2) = host_read_word(+0). rtl/DenjinMakai/DenjinMakai_cop3.sv:2201 rdata = word @ host+0 = flags (MAME cop_read_word(spradr+2) ^ 2). rtl/DenjinMakai/DenjinMakai_cop3.sv:2210 rdata = word @ host+4 = pos[0] (Y axis per MAME) rtl/DenjinMakai/DenjinMakai_cop3.sv:2230 0xb100/0xb900 — update hitbox & compute intersection (1:1 MAME cop_collision_update_hitbox, seibucop.cpp:1003-1065). rtl/DenjinMakai/DenjinMakai_cop3.sv:2277 2 assi (b000/b800): terza word NON letta, dx/size azzerati (MAME seibucop.cpp:1014-1022) rtl/DenjinMakai/DenjinMakai_cop3.sv:2316 2 assi: l'asse 2 (Z) NON viene aggiornato (loop MAME i<num_axis) rtl/DenjinMakai/DenjinMakai_cop3.sv:2335 res init: 3 assi = 111, 2 assi = 011 (MAME seibucop.cpp:1038-39: bit Z gia' 0 = "collide banale" -> hit deciso solo da X/Y) rtl/DenjinMakai/DenjinMakai_cop3.sv:2359 LEGACY 6880 — carica rel_xy per il prossimo c480 (MAME LEGACY_execute_6980: rel_xy = read_word(spr_src+4+offs)) rtl/DenjinMakai/DenjinMakai_cop3.sv:2372 LEGACY c480 — single-step sprite DMA (MAME LEGACY_execute_c480): info = read(spr_src+offs) + (param & 0x3f) -> entry+0 abs = read(regs[0]+8/+4) - spr_dma_abs_x/y X(fx/dx/rel_x) -> entry+4 (+ x_clip per l'inc $410) Y(fy/rel_y) -> entry+6 rtl/DenjinMakai/DenjinMakai_cop3.sv:2478 6200 — rotate-towards (MAME execute_6200, variante grainbow che denjinmk CARICA nella tabella): angle(obj host+0x37) ruota verso cop_angle_target di cop_angle_step; flags(host+2) bit2=raggiunto. rtl/DenjinMakai/DenjinMakai_cop3.sv:2481 Dominio angolo: il nostro 138e scrive in RAM plain^0x80 (is_yflip) -> lavoro nel dominio stored con target^0x80: il DELTA e' rotazione-invariante => matematica IDENTICA a MAME. rtl/DenjinMakai/DenjinMakai_cop3.sv:2484 Write angolo = WORD {0,angle} (MAME host_endian write-word). rtl/DenjinMakai/DenjinMakai_cop3.sv:2505 wrap a signed 8-bit (MAME: +=/-=256 su int) rtl/DenjinMakai/DenjinMakai_main_top.sv:216 VBLANK IRQ4 — MAME legionna.cpp: m_maincpu->set_vblank_int(irq4_line_hold) MAME HOLD_LINE: IRQ asserted on edge, released ONLY at IACK (= when CPU fetches vector). rtl/DenjinMakai/DenjinMakai_main_top.sv:221 VBLANK IRQ4 — MAME legionna.cpp: m_maincpu->set_vblank_int(irq4_line_hold) MAME HOLD_LINE: IRQ asserted on edge, released ONLY at IACK (= when CPU fetches vector). rtl/DenjinMakai/DenjinMakai_main_top.sv:479 COP3 cmd 0x14 dma_tilemap_buffer (MAME legionna_v.cpp:86 videowrite_cb_w): offset 0x000..0x3FF → BG (back_data) offset 0x400..0x7FF → FG (fore_data) offset 0x800..0xBFF → MG (mid_data) offset 0xC00..0x13FF → Text (textram, 0x800 word) rtl/DenjinMakai/DenjinMakai_main_top.sv:503 Il fill scrive le BRAM STAGING (= la host RAM di MAME): il per-frame DMA 0x14/0x15 le propaga al renderer. rtl/DenjinMakai/DenjinMakai_main_top.sv:516 ── SPLIT STAGING vs RENDERER (semantica MAME 2-stadi, come la palette) ───── MAME denjinmk: $101000-$103FFF e' .ram() PURO (handler background_w/… COMMENTATI nel map, legionna.cpp) — le scritture CPU NON toccano i tilemap. rtl/DenjinMakai/DenjinMakai_main_top.sv:519 I tilemap leggono m_back/fore/mid_data/m_textram = buffer SEPARATI (make_unique_clear, legionna_v.cpp) scritti SOLO da videowrite_cb_w = DMA 0x14. rtl/DenjinMakai/DenjinMakai_main_top.sv:524 u_XX_ram = STAGING: porta A = CPU (+fill 0x116/0x118, come MAME che filla la host RAM), porta B = sorgente del DMA 0x14. rtl/DenjinMakai/DenjinMakai_main_top.sv:527 Coppia contenuto/scroll = atomica a livello ISR, come MAME. rtl/DenjinMakai/DenjinMakai_main_top.sv:599 ── Palette: split STAGING ($104000) vs RENDERER (semantica MAME 2-stadi) ─── MAME: la CPU e il fade (cmd 0x80) scrivono la STAGING RAM a $104000. rtl/DenjinMakai/DenjinMakai_main_top.sv:609 In MAME il fade DMA (mode 0x8x) fa m_host_space->write_word(dst): con dst in $104000-$104FFF quella write ATTRAVERSA la map, quindi passa per palette_swap_w (offset^=1) esattamente come le write della CPU. rtl/DenjinMakai/DenjinMakai_main_top.sv:615 Le LETTURE (porta B, sorgente del cmd 0x15) restano LINEARI come in MAME. rtl/DenjinMakai/DenjinMakai_main_top.sv:631 MAME denjinmk: $104000 e' RAM pura (legionna.cpp:262, handler palette commentato) — la palette VISIBILE si aggiorna SOLO via paletteramout_cb = dma_palette_buffer 0x15 (seibucop_dma.ipp:27); il fade DMA scrive lo STAGING (host RAM, dma.ipp: rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:23 Main CPU memory map Denjin Makai (MAME legionna.cpp denjinmk_map:296-322): $000000-$0FFFFF ROM 68K (1MB) → SDRAM via bridge $100000-$1003FF RAM scratch (1KB) → BRAM (Main RAM low) $100400-$1006FF COP3 region rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:139 Text VRAM: $102800-$1037FF = 4KB = 2048 word (MAME common_video_allocate_ptr alloca textram a 0x1000/2 word, videowrite_cb_w smista offset < 0x2800/2). rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:149 denjinmk_map (legionna.cpp:311): 0x100800-0x100FFF .ram() rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:183 MAME palette_swap_w (legionna.cpp:288-294): "Looks like they specifically swapped address line A1 in this range" — offset^=1 poi COMBINE_DATA. rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:229 MAME legionna_map: main_r/main_w(offset>>1) con umask16(0x00ff). rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:233 Vedi seibusound.cpp main_r/main_w. rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:237 ─── GFX bank — denjinmk_setgfxbank (MAME legionna_v.cpp:...) ──────────── "this is either 0x0000 or 0xe000, except in two endings (MT #07416)" back = (data & 0x2000) >> 1 → bit13 → +0x1000 mid = (data & 0x4000) >> 2 → bit14 → +0x1000 for rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:282 denjinmk: MAME empty_init, nessuna patch ROM. rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:309 MAME denjinmk_sound_comms_r (legionna.cpp:99-106): "Routine at 5FDC spins indefinitely until the lowest bit becomes 1" → l'offset 10 (= word index 10 = $100714) ritorna SEMPRE 1, non passa dal seibu_sound. rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:344 Replica la latenza-zero-osservabile di MAME (cop_cmd_w sincrono): il gioco legge cop_hit_val_stat/cop_angle ($188/$1b4) nell'istruzione dopo il trigger. rtl/DenjinMakai/DenjinMakai_palette.sv:25 MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 12816); (legionna.cpp:1212, 12816 = 2048 entry) Address space CPU: 0x104000..0x104FFF (4 KB = 2048 word). rtl/DenjinMakai/DenjinMakai_palette.sv:35 Espansione 5→8 standard MAME palette_device: {val5, val5[4:2]} (bit replication che riempie i 3 LSB con i 3 MSB del valore 5-bit). rtl/DenjinMakai/DenjinMakai_palette.sv:85 DenjinMakai: xBGR_555 → RGB888 (MAME legionna.cpp:1212) Layout: bit[4:0]=R, bit[9:5]=G, bit[14:10]=B. 5 bit per canale. rtl/DenjinMakai/DenjinMakai_palette.sv:87 Espansione 5→8 standard MAME palette_device: {val5, val5[4:2]} (replica i 3 MSB nei 3 LSB → range 0..255 con monotonia preservata). rtl/DenjinMakai/DenjinMakai_seibu_crtc.sv:23 Seibu CRTC fedele a MAME (seibu_crtc.cpp). rtl/DenjinMakai/DenjinMakai_seibu_crtc.sv:120 MAME mappa: bit0=screen0(BG), bit1=screen2(MG), bit2=screen1(FG), bit3=screen3(Text) (vedi seibu_crtc.cpp commento "screen 0=BG, screen 1=FG, screen 2=MG, screen 3=Text") In SD Gundam dcon.cpp layer_en_w gira la maschera così: ~layer_en bit rtl/DenjinMakai/DenjinMakai_seibu_crtc.sv:129 Il dispatcher MAME usa "if (BIT(~m_layer_en, n))" per saltare = layer disabilitato quando il bit è 1. rtl/DenjinMakai/DenjinMakai_seibu_crtc.sv:134 DenjinMakai layer ordering (MAME legionna_v.cpp:384-390 screen_update_DENJINMAKAI): bit 0 = BG (background) bit 1 = MG (midground) bit 2 = FG (foreground) bit 3 = Text bit 4 = Sprites ATTENZIONE: e' l'OPPOSTO di legionna (screen_update_legi rtl/DenjinMakai/DenjinMakai_seibu_crtc.sv:155 Scroll-base Screen3(text) Y = reg 0x3A (blocco layer_scroll_base 0x2C-0x3B, offset word 7 — MAME seibu_crtc.cpp:243 + legionna_v.cpp:58-65 denjinmk-only: text set_scrolldy(0x1ef - data). rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:25 Formato spriteram quasi identico (entrambi MAME sei021x_sei0220_spr.cpp) — differenze: - Spriteram @ 0x105000-0x105FFF (4KB, 1024 word, 256 entry × 4 word) - w3 bit 15 = tile bank extra bit (denjinmk usa, DenjinMakai base = 0) rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:30 Format word (MAME legionna_v.cpp:288-312): w0 bit 15 = enable (0=draw, 1=skip — TODO verify DenjinMakai) w0 bit 14 = flip_x w0 bit 13 = flip_y (??? rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:46 Priority callback legionna_v.cpp:314-317: pri_mask[0] = 0x0000 (sopra tutto) pri_mask[1] = 0xFFF0 pri_mask[2] = 0xFFFC pri_mask[3] = 0xFFFE rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:140 0..511 (MAME size/2/4 = 4096/2/4 = 512) rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:145 Decoded fields — MAME sei0210_device::draw (non-alt format, riga 143): if (BIT(~spriteram[i], 15)) continue; → draw quando w0[15]==1. rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:157 SEI0211 get_coordinate (MAME sei021x_sei0220_spr.h): coord &= 0x1ff; return (coord >= 0x180) ? rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:165 MAME SEI0211 default m_xoffset/m_yoffset = 0 (sei021x_sei0220_spr.cpp:40-41). rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:166 DenjinMakai NON chiama set_offset (legionna.cpp:1214) → offset 0,0. rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:198 Tile code finale Y-MAJOR (MAME draw_internal: ax=outer, ay=inner, code++): sub_index = axsizey + ay → cur_tile = code + eff_tile_xsp_h + eff_tile_y Banking denjinmk_tile_cb (legionna_v.cpp:327-334): ext→\|0x4000, y→\|0x8000, applicato PRI rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:538 MAME gfx_legionna_spr: color base = 6416 = 0x400 (64 colorset × 16 pen). rtl/DenjinMakai/DenjinMakai_text_renderer.sv:25 Specifiche da MAME (legionna.cpp:1117-1126, 1167): rtl/DenjinMakai/DenjinMakai_text_renderer.sv:47 Char ROM in MAME: "char" region 64KB = ROM_COPY user1[0x10000..0x1FFFF]. rtl/DenjinMakai/DenjinMakai_text_renderer.sv:140 MAME `legionna_v.cpp:214`: text tilemap = 64×32 (8x8 tiles, TILEMAP_SCAN_ROWS). rtl/DenjinMakai/DenjinMakai_text_renderer.sv:186 --- Stage 3: pen decode (charlayout planes packed in nibbles) --- Per col c (0..3 dentro la half-tile), bit position = 3 - c. pen[0] = word[bit_pos + 0] (plane 0) pen[1] = word[bit_pos + 4] (plane 1) pen[2] = word[bit_pos + 8] (plane rtl/DenjinMakai/DenjinMakai_text_renderer.sv:192 MAME readbit usa MSB-first: bit_offs N → byte[N/8] bit (7-N%8). rtl/DenjinMakai/DenjinMakai_text_renderer.sv:193 In Verilog word concat (lo=byte0[7:0], hi=byte1[7:0]) → MAME pos N = word[(7-N%8) + (N>=8?8:0)]. rtl/DenjinMakai/DenjinMakai_text_renderer.sv:210 MAME GFXDECODE char: color base = 4816 = 0x300 (16 colorset × 16 pen). rtl/DenjinMakai/DenjinMakai_text_renderer.sv:211 DENJIN MAKAI: trasparente pen 7 (MAME VIDEO_START_MEMBER(denjinmk): m_text_layer->set_transparent_pen(7) — famiglia usa 15). rtl/DenjinMakai/DenjinMakai_tile_layer.sv:25 Differenze fra layer (da MAME dcon.cpp): rtl/DenjinMakai/DenjinMakai_tile_layer.sv:58 BB FG hardcoded +0x1000 (MAME bloodbro fg_tile_info) rtl/DenjinMakai/DenjinMakai_tile_layer.sv:175 denjinmk 320x256 (MAME visarea 0..255) rtl/DenjinMakai/DenjinMakai_tile_layer.sv:221 Tile index con eventuale gfx_bank (MG ha bit 12 = 13-bit totali, BG/FG = 12 bit) + TILE_CODE_OFS hardcoded (BB FG aggiunge 0x1000 secondo MAME bloodbro fg_tile_info). rtl/DenjinMakai/DenjinMakai_video_timing.sv:35 Active area da MAME (sdgndmps_map): visarea 0..408-1, 28..308-1 quindi 320×224, V offset = 16 (top blank). rtl/DenjinMakai/DenjinMakai_video_timing.sv:60 ── Pixel clock enable: 96 MHz / 14 = 6.857 MHz ───────────────────────── DenjinMakai reale (MAME legionna.cpp:1318 set_raw): pclk 14.318180/2 = 7.15909 MHz. rtl/DenjinMakai/DenjinMakai_video_timing.sv:64 DENJIN MAKAI: 56 Hz nominali (MAME set_refresh_hz(56), "Value from doc") con la riga Seibu standard ~15.73 kHz → 281 righe totali. rtl/DenjinMakai/DenjinMakai_video_timing.sv:87 ── Constants timing ───────────────────────────────────────────────────── DenjinMakai REALE (MAME legionna.cpp:1318): set_raw(14318180/2, 455, 0, 320, 258, 0, 224) = 320x224, HTotal 455 @7.159MHz = 15.734 kHz, VTotal 258 → 60.985 Hz. rtl/DenjinMakai/DenjinMakai_video_timing.sv:122 DENJIN MAKAI: 256 righe visibili (MAME visarea 0..255), CONFERMATE dal riscontro visivo sull'hardware — a 240 si taglierebbero 16 righe di contenuto in basso. rtl/DenjinMakai/sdram_bridge.sv:151 Differenza chiave vs Godzilla: il MG ha la SUA ROM (bg-2-ab.617, MAME gfx_heatbrl + get_mid_tile_info_split) invece di condividere la back con offset +0x1000 → MG_BASE propria e TILE_CODE_OFS=0 nel tile layer. rtl/DenjinMakai/sdram_bridge.sv:315 --- FG address descramble (MAME legionna.cpp:1129 descramble_legionnaire_gfx) --- MAME applica un bitswap<24> agli indirizzi della ROM "fore" durante init: src_descrambled[i] = src_raw[bitswap<24>(i, ... rtl/DenjinMakai/sdram_bridge.sv:362 bitswap MAME del byte offset README.md:6 Denjin Makai is a beat-'em-up running on the Seibu `legionna.cpp` hardware family* — an M68000 board with a Seibu CRTC, the SEI252 sprite chip and the SEI300 README.md:12 This core reimplements the hardware in SystemVerilog from MAME references (`seibu/legionna.cpp`, `seibu/legionna_v.cpp`, `seibu/seibu_crtc.cpp`, `seibu/seibucop README.md:34 The game runs at 56 Hz. That is the board's own rate — MAME reads it from the documentation (`set_refresh_hz(56)`) — and the core reproduces it exactly: 436 Says it matches, follows or was checked against MAME — 7 DenjinMakai.sv:200 -1 = sprite 1px a OVEST (sinistra), match MAME su HW DenjinMakai.sv:228 NB: gli offset per-layer (ex P5) sono HARDCODATI (osd__xoff/yoff costanti, match pixel-perfect MAME). rtl/DenjinMakai/DenjinMakai_cop3.sv:858 find_trigger_match (MAME seibucop.cpp:464) Cerca slot N tale che (trigger & 0xf800) == (cop_func_trigger[N] & 0xf800) && cop_func_trigger[N] != 0. rtl/DenjinMakai/DenjinMakai_cop3.sv:1313 LEGACY sprite-DMA (match a maschera, MAME find_trigger_match): c480 mask $FF00 -> qualunque c4xx; 6880 mask $FFF3. rtl/DenjinMakai/DenjinMakai_cop3.sv:2152 res = prod >> 4 (= /16 per matchare formula MAME 2048/32768 = 1/16) rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:167 +1 pixel a destra: offset verificato con pixel hunting su MAME (rmonic79). rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:333 Scan INVERSO 511→0 (verificato su HW: ordine sprite-su-sprite opposto al loop MAME 0→511). Says it was translated, ported or taken from MAME — 2 rtl/DenjinMakai/DenjinMakai_cop3.sv:1904 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197): 1:1 dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (signed) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = floor(sqrt(dxdx + dydy)) if(data&0x80) write_word(r0+(data&0x200?0x3 rtl/DenjinMakai/DenjinMakai_cop3.sv:2021 0x42C2/0x4AA0 divide — MAME execute_42c2/4aa0 (cmd.ipp:219/247): 1:1 DIVIDEND = cop_dist << (5 - cop_scale) (cop_scale 0..3 → shift 5..2) 42c2: div=cop_read_word(r0+0x36)→host 0x34; if(!div){status\|=0x8000; write 0 a host 0x3a} else write Shares text with the MAME driver without saying so — 15 DenjinMakai.sv:804 HAS_TRANSP=1 perché m_background_layer->set_transparent_pen(15) in — shares text with seibu/legionna_v.cpp:216 DenjinMakai.sv:827 get_mid_tile_info_share_bgrom (legionna_v.cpp:158): MG share BG ROM, — shares text with seibu/legionna.h:80 DenjinMakai.sv:1021 VIDEO_START denjinmk: "briefing guy in pre-stage and portraits before a — shares text with seibu/legionna_v.cpp:261 rtl/DenjinMakai/DenjinMakai_audio_z80.sv:463 denjinmk_oki_bank_w: m_oki->set_rom_bank(data & 1) (write tipica 0x02/0x03). — shares text with seibu/legionna.cpp:277 rtl/DenjinMakai/DenjinMakai_main_top.sv:609 In MAME il fade DMA (mode 0x8x) fa m_host_space->write_word(dst): con dst — shares text with seibu/seibucop.cpp:810 rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:184 swapped address line A1 in this range" — offset^=1 poi COMBINE_DATA. — shares text with seibu/legionna.cpp:288 rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:238 "this is either 0x0000 or 0xe000, except in two endings (MT #07416)" — shares text with seibu/legionna_v.cpp:76 rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:310 spins indefinitely until the lowest bit becomes 1" → l'offset 10 — shares text with seibu/legionna.cpp:101 rtl/DenjinMakai/DenjinMakai_palette.sv:23 Palette RAM Seibu DenjinMakai (xBGR_555, 2048 entries). MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 12816); (legionna. — shares text with seibu/legionna.cpp:1212 rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:146 if (BIT(~spriteram[i], 15)) continue; → draw quando w0[15]==1. — shares text with seibu/sei021x_sei0220_spr.cpp:128 rtl/DenjinMakai/DenjinMakai_text_renderer.sv:23 Text layer renderer Seibu DenjinMakai (8x8, 4bpp, 64x32). Specifiche da MAME (legionna.cpp:1117-1126, 1167): // charlayout 8x8, RGN_FRAC(1,1), — shares text with seibu/legionna.cpp rtl/DenjinMakai/DenjinMakai_text_renderer.sv:212 m_text_layer->set_transparent_pen(7) — famiglia usa 15). — shares text with seibu/legionna_v.cpp:219 rtl/DenjinMakai/DenjinMakai_video_timing.sv:23 Video timing single-screen Seibu D-Con. SD Gundam Psycho Salamander gira su Seibu D-Con (PB91008), stessa famiglia di Blood Bros (1990). PCB measuremen — shares text with seibu/legionna.cpp rtl/DenjinMakai/DenjinMakai_video_timing.sv:88 DenjinMakai REALE (MAME legionna.cpp:1318): set_raw(14318180/2, 455, 0, — shares text with seibu/legionna.cpp:1318 rtl/DenjinMakai/sdram_bridge.sv:317 src_descrambled[i] = src_raw[bitswap<24>(i, ... 6,5,15,14,13,12, 11,10,9,8, 7,4, 3..0)] — shares text with seibu/legionna.cpp:1141
DigDug# Dig Dug MiSTer-devel/Arcade-DigDug_MiSTer @ 57956d0d MAME compared: namco/digdug.cpp + 12 related file(s) Read: 18 HDL files, 6,982 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	0%
No statements found
Dominos# Dominos MiSTer-devel/Arcade-Dominos_MiSTer @ faa35f90 MAME compared: atari/sprint2.cpp + 2 related file(s) Read: 16 HDL files, 4,422 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	4%
Statements: 2 toward hardware Cites hardware documentation that MAME's driver does not — 2 rtl/playfield.vhd:91 Some glue logic, may be re-written later to be cleaner and easier to follow without referring to schematic rtl/playfield.vhd:148 74LS166 video shift register
DonkeyKong# Donkey Kong, Radar Scope MiSTer-devel/Arcade-DonkeyKong_MiSTer @ 53971b3c MAME compared: nintendo/dkong.cpp + 3 related file(s) Read: 54 HDL files, 12,045 lines (Quartus project)	MiSTer official	Both	low	8%
Statements: 3 toward hardware, 2 toward MAME, 1 not counted Cites hardware documentation that MAME's driver does not — 3 rtl/dkong_top.v:24 This description is largely based on the TKG4 schematics, with some extensions to support Radarscope and Donkey Kong Jr (although MiSter currently has a separate DKJR core). rtl/dkong_top.v:27 In the schematics, ICs are denoted by their position on the board, i.e. IC 6M is the IC in column 6, row M. Unfortunataly, this makes reverse lookup from Verilog to schematic hard, but at least ICs with similar coordinates are often cloase rtl/dkongjr_dac.sv:8 Components R20, C32 and Q4 on schematics. Cites hardware references or measurements that MAME's driver also gives — 1 rtl/dkong_sound.v:83 ---- DATA ROM 3H --------------------------- — also in MAME: 3H nintendo/dkong.cpp:2554 Says it was translated, ported or taken from MAME — 2 rtl/mister-discrete/astable_555_vco.sv:40 Drawing based on a drawing from MAME discrete rtl/mister-discrete/invertor_square_wave_oscilator.sv:33 Drawing based on a drawing from MAME discrete
DonkeyKong3# Donkey Kong 3 MiSTer-devel/Arcade-DonkeyKong3_MiSTer @ 52aff38b MAME compared: nintendo/dkong.cpp + 3 related file(s) Read: 29 HDL files, 11,167 lines (Quartus project)	MiSTer official	Mostly hardware	low	22%
Statements: 18 toward hardware, 19 not counted Cites hardware documentation that MAME's driver does not — 18 rtl/apu.sv:441 Values read directly from the netlist rtl/apu.sv:718 This is implemented from the original LSFR frame counter logic taken from the 2A03 netlists. rtl/dkong3_adec.v:74 CPU can clear the NMI via register @ 3E. rtl/dkong3_adec.v:102 74LS139 @ 3B rtl/dkong3_adec.v:126 74LS138 @ 2A rtl/dkong3_adec.v:145 74LS138 @ 3A rtl/dkong3_adec.v:163 74LS138 @ 4E Same as 4F except used for writes. rtl/dkong3_adec.v:183 74LS138 @ 4F Enable signals for reading inputs and and DIP switches rtl/dkong3_adec.v:206 74LS259 @ 3E Misc control signals (7E80H - 7E87H) rtl/dkong3_adec.v:236 74LS174 @ 5H Reset signal to sub CPU's rtl/dkong3_col_pal.v:34 Parts 3M, 3L (74LS157) Selects sprites or backgound pixels Sprites take priority rtl/dkong3_obj.v:94 Object RAM 6P, 6R rtl/dkong3_roms.v:11 0x00000 - 0x01FFF 7B PROGRAM ROM (8KB) 0x02000 - 0x03FFF 7C PROGRAM ROM (8KB) 0x04000 - 0x05FFF 7D PROGRAM ROM (8KB) 0x06000 - 0x06FFF 3P GFX ROM (4KB) 0x07000 - 0x07FFF 3N GFX ROM (4KB) 0x08000 - 0x09FFF 7E PROGRAM ROM (8KB) 0x0A000 - 0x0A rtl/dkong3_sound.v:125 74LS374 @ 4J Input port 0 for Sub CPU 1 rtl/dkong3_sound.v:150 74LS374 @ 4H Input port 1 for sub CPU 1 rtl/dkong3_sound.v:206 ROM 6M for Sub CPU 2 rtl/dkong3_sound.v:217 RAM @ 6F for Sub CPU 2 rtl/dkong3_sound.v:240 74LS374 @ 5F Input port for Sub CPU 2 Cites hardware references or measurements that MAME's driver also gives — 19 rtl/dkong3_adec.v:90 Address Decoder PROM @ 5E — also in MAME: 5E nintendo/dkong.cpp:292 rtl/dkong3_main.v:174 Main CPU RAM 7F (2KB) — also in MAME: 7F nintendo/dkong.cpp:2564 rtl/dkong3_main.v:196 Main CPU RAMs 7H (2KB) This is also read by the DMA controller. — also in MAME: 7H nintendo/dkong.cpp:2913 rtl/dkong3_roms.v:119 Object/Sprite ROMs 7C,7D,7E,7F. — also in MAME: 7C nintendo/dkong.cpp:2561, 7D nintendo/dkong.cpp:2562, 7E nintendo/dkong.cpp:2563, 7F nintendo/dkong.cpp:2564 rtl/dkong3_roms.v:193 CLUT PROM 1D (512x8) Only 256 entries are used. — also in MAME: 1D nintendo/dkong.cpp:2148 rtl/dkong3_roms.v:221 CLUT PROM 1C (512x4) Only 256 entries are used. — also in MAME: 1C nintendo/dkong.cpp:1058 rtl/dkong3_roms.v:249 Colour palette PROM 2N (256x4) 4-bit output. — also in MAME: 2N nintendo/dkong.cpp:2569 rtl/dkong3_roms.v:276 Address decoder PROM 5E (32x8) — also in MAME: 5E nintendo/dkong.cpp:292 rtl/dkong3_roms.v:302 Sub CPU 1 (Sound) ROM 5L. — also in MAME: 5L nintendo/dkong.cpp:2050 rtl/dkong3_roms.v:330 Sub CPU 2 (Sound) ROM 6H. — also in MAME: 6H nintendo/dkong.cpp:804 rtl/dkong3_sound.v:59 Sub CPU 1 @ 4M (Ricoh 2A03) — also in MAME: 4M nintendo/dkong.cpp:2172 rtl/dkong3_sound.v:91 ROM 5L for Sub CPU 1 — also in MAME: 5L nintendo/dkong.cpp:2050 rtl/dkong3_sound.v:102 RAM @ 5K — also in MAME: 5K nintendo/dkong.cpp:333 rtl/dkong3_sound.v:174 Sub CPU 2 @ 5J (Ricoh 2A03) — also in MAME: 5J nintendo/dkong_a.cpp:865 rtl/dkong3_vram.v:47 VRAM 2 x 2114 @ 2P, 2R (1KB) — also in MAME: 2P nintendo/dkong.cpp:2932, 2R nintendo/dkong.cpp:2931 rtl/dkong3_vram.v:74 Colour PROM 2N — also in MAME: 2N nintendo/dkong.cpp:2569 rtl/dkong3_vram.v:106 Video ROMs 3N, 3P — also in MAME: 3N nintendo/dkong.cpp:2557, 3P nintendo/dkong.cpp:2558 rtl/dkong3_vram.v:178 VRAM BUSY signal @ 2K — also in MAME: 2K nintendo/dkong.cpp:2178 rtl/dkong3_vram.v:194 ESBLK signal @ 2K This signal doesn't go anywhere on the schematic. — also in MAME: 2K nintendo/dkong.cpp:2178
DonkeyKongJunior# Donkey Kong Junior MiSTer-devel/Arcade-DonkeyKongJunior_MiSTer @ 8d576e70 MAME compared: nintendo/dkong.cpp + 3 related file(s) Read: 51 HDL files, 15,067 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	1%
Statements: 1 toward hardware, 4 not counted Cites hardware documentation that MAME's driver does not — 1 rtl/dkongjr_dac.sv:8 Components R20, C32 and Q4 on schematics. Cites hardware references or measurements that MAME's driver also gives — 4 rtl/dkongjr_rom.v:11 0x00000 - 0x01FFF 5B PROGRAM ROM (8KB) 0x02000 - 0x03FFF 5C PROGRAM ROM (8KB) 0x04000 - 0x05FFF 5E PROGRAM ROM (8KB) 0x06000 - 0x06FFF 3P GFX ROM (4KB) 0x07000 - 0x07FFF 3N GFX ROM (4KB) 0x08000 - 0x09FFF 5B PROGRAM ROM REPEAT (8KB) 0x0A000 — also in MAME: 5B nintendo/dkong.cpp:290, 5C nintendo/dkong.cpp:291, 5E nintendo/dkong.cpp:292, 3P nintendo/dkong.cpp:2558, 3N nintendo/dkong.cpp:2557, 5B nintendo/dkong.cpp:290, 7C nintendo/dkong.cpp:2561, 7C nintendo/dkong.cpp:2561, 7D nintendo/dkong.cpp:2562, 7D nintendo/dkong.cpp:2562, 7E nintendo/dkong.cpp:2563, 7E nintendo/dkong.cpp:2563, 7F nintendo/dkong.cpp:2564, 7F nintendo/dkong.cpp:2564, 3H nintendo/dkong.cpp:2554, 2E nintendo/dkong.cpp:2567, 2F nintendo/dkong.cpp:2568, 2N nintendo/dkong.cpp:2569 rtl/dkongjr_rom.v:56 Program ROMs are addressed as follows: 0x0000 - 0x0FFF ROM 5B [0x0000 - 0x0FFF] (4KB) 0x1000 - 0x17FF ROM 5C [0x1000 - 0x17FF] (2KB) 0x1800 - 0x1FFF ROM 5E [0x1800 - 0x1FFF] (2KB) 0x2000 - 0x27FF ROM 5C [0x0000 - 0x07FF] (2KB) 0x280 — also in MAME: 5B nintendo/dkong.cpp:290, 5C nintendo/dkong.cpp:291, 5E nintendo/dkong.cpp:292, 5C nintendo/dkong.cpp:291, 5E nintendo/dkong.cpp:292, 5B nintendo/dkong.cpp:290, 5E nintendo/dkong.cpp:292, 5C nintendo/dkong.cpp:291, 5E nintendo/dkong.cpp:292, 5C nintendo/dkong.cpp:291 rtl/dkongjr_sound.v:105 ---- PROG ROM 3H --------------------------- — also in MAME: 3H nintendo/dkong.cpp:2554 rtl/dkongjr_vram.v:99 ----- ROM 2N ----- — also in MAME: 2N nintendo/dkong.cpp:2569
DottoriKun# Dottori Kun MiSTer-devel/Arcade-DottoriKun_MiSTer @ 96993eda MAME compared: sega/dotrikun.cpp Read: 9 HDL files, 5,323 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	7%
Statements: 1 toward MAME Shares text with the MAME driver without saying so — 1 Arcade-DottoriKun.sv:6 Which was based on information from Chris Covell: http://www.chrismcovell.com/dottorikun.html — shares text with sega/dotrikun.cpp:54
Druaga# Dig Dug II, Grobda, Mappy, Motos … MiSTer-devel/Arcade-Druaga_MiSTer @ 67d5bb18 MAME compared: namco/mappy.cpp + 4 related file(s) Read: 11 HDL files, 6,445 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	8%
Statements: 1 toward MAME Cites MAME source — 1 Arcade-Druaga.sv:307 JPAC/IPAC/MAME Style Codes
Escape# Escape from the Planet of the Robot Monsters MiSTer-devel/Arcade-Escape_MiSTer @ 13642d85 MAME compared: atari/eprom.cpp + 6 related file(s) Read: 24 HDL files, 16,347 lines (Quartus project)	MiSTer official	Both	medium	44%
Statements: 17 toward hardware, 64 toward MAME Cites hardware documentation that MAME's driver does not — 14 rtl/core/escape_core.vhd:106 Escape shipped in two cabinet variants with different CPUs and both are confirmed from photographs: the dedicated board carries MC68010P8 (Motorola, date code A71R8813, matching SP-332's "U68010" at 45J/20P - SP-332 IS the dedicated-cabinet rtl/core/escape_core.vhd:698 SP-332 - which IS the dedicated-cabinet package - draws both CPUs "U68010" (sheet 4 designator 45J "VCPU"; sheet 5 designator 20P "ECPU"). rtl/core/escape_core.vhd:704 (The old comment here claimed "real boards carry 68000s" as against the schematic. rtl/core/escape_core.vhd:723 Same part as the video CPU on both variants (schematic 20P "ECPU"), and run in the same mode - see the video CPU comment above. rtl/core/escape_core.vhd:751 autovector: assert VPA during interrupt acknowledge (FC=111), per schematic 60L/55L rtl/core/escape_core.vhd:1071 On the real part that works because /AS stays asserted across the whole read-modify-write - M68000UM Rev 9 section 5.1.3 p.53, "The address strobe (AS) remains asserted throughout the entire cycle, making the cycle indivisible" - and the bo rtl/core/escape_decode.vhd:2 Original RTL derived from the authoritative memory map (schematic SP-332, sheet 16; see docs/ARCHITECTURE.md). rtl/core/escape_jsa.vhd:343 v63: WRIO (bank/YAMRES/squeak/TMS strobes) and MIX live in LS273s cleared only by /POR on the real board (SP-332 sheets 12/13) - they survive a 68k sound reset rtl/core/escape_jsa.vhd:517 LANE4b: 2A00 write latches the byte onto the chip's data bus (the 74LS374 on the real board); the firmware's WRIO writes strobe WS. rtl/core/escape_mob.v:116 MOPAIR-131: each line buffer is TWO banks, even and odd screen columns, written in the same clock - which is what the REAL BOARD does: sheet 9 of SP-332 shows the line buffer as a PAIR of LB customs (92U/85U) handling MOL0/1 and MOR0/1 with rtl/core/escape_mob.v:322 This is the structure the real board has: Escape's PAL16L8 at 70J drives a dedicated /LINK memory slot (SP-332 sheet 7), so list walking never competes with the pixel pipeline. README.md:15 The dual-CPU program boots and runs on two genuinely concurrent 68010s with shared RAM and the mailbox handshake, as the board does (68000 selectable — the dedi README.md:45 Authentic (schematic-verified): clock frequencies (7.159 MHz CPUs, true pixel clock, all clocks derived from the board's 14.318 MHz colorburst family); rast README.md:55 Approximate: per-instruction CPU cycle counts (TG68K is instruction-accurate, not cycle-exact); bus-cycle timing off-ROM (the original gave every subsystem Says it was checked against the original PCB — 2 README.md:12 This LLM-assisted build has been refined extensively through testing and benchmarking against an original dedicated cabinet and PCB, with architecture decisions README.md:42 Performance references are against actual machine gameplay, with MAME as the secondary reference. Says it was checked on “real hardware” — 1 README.md:68 Animation cadence: the walk cycle advances every 8 frames, locked against real-cabinet captures. Cites MAME source — 58 rtl/core/TMS5220.vhd:14 This copy is vendored from third_party/Arcade-Atari-system1_MiSTer (GPL-3, (c) 2020 d18c7db) with the LANE3z lattice-filter fix: MAME-faithful matrix_multiply wrap semantics (see MM function), widened u/x accumulators, and output saturation rtl/core/TMS5220.vhd:19 References: TMS5220 datasheet, US Patent US4335277 and TMS5220.cpp from MAME source code. rtl/core/TMS5220.vhd:81 MAME's lattice keeps u/x in int32 and wraps them to 15 bits only at the multiplier input (matrix_multiply: a wraps to 10 bits, b to 15 bits); the 13-bit ranges overflowed on loud speech (Escape announcer, energy 14-15) - GHDL bound crash in rtl/core/TMS5220.vhd:241 LANE3z: MAME tms5220.cpp matrix_multiply, faithful wrap semantics: coefficient wraps to 10-bit two's complement, sample to 15-bit, then signed product >> 9. rtl/core/escape_core.vhd:106 Escape shipped in two cabinet variants with different CPUs and both are confirmed from photographs: the dedicated board carries MC68010P8 (Motorola, date code A71R8813, matching SP-332's "U68010" at 45J/20P - SP-332 IS the dedicated-cabinet rtl/core/escape_core.vhd:178 Fetches in range are served zero-wait through the proven BRAM dtack path - restoring the real board's ~4-cycle fetch budget the game's frame architecture assumes (MAME fetches in zero time; SDRAM cost 15-25 cycles and starved the main loop rtl/core/escape_core.vhd:191 Byte-wide because the real part is: MAME maps it umask16(0x00ff), so only the LOW byte of each word is EEPROM. rtl/core/escape_core.vhd:209 Channel order per MAME eprom: IN0 = P1 Y, IN1 = P1 X, IN2 = P2 Y, IN3 = P2 X. X axes arrive pre-reversed (0x00 = full right), Y normal (0x00 = full up) — the harness wiring, not something we invert here. rtl/core/escape_core.vhd:221 260000 D0: factory step/continue switch (unpopulated on production cabs, MAME marks it unused, but the self-test error loop reads it: 0x776 btst #0,$260000 — held low = step past a failed region) rtl/core/escape_core.vhd:321 Direct speed meter against the MAME reference - answers "are the processors actually at speed?" rtl/core/escape_core.vhd:328 docs/investigations/PERF_CADENCE.md measures the original in the units that matter - LOGIC UPDATES PER VIDEO FRAME, 0.9977 video / 0.9999 world in MAME - by tapping the two re-entrancy flags each ISR writes: $50 to $16CCD4 (main/video) and rtl/core/escape_core.vhd:332 These count the $50 writes over 256 video frames, so 0100 hex IS 1.0000 updates/frame and the number is directly comparable to MAME's without assuming anything about clocks, bus cycles or wait states. rtl/core/escape_core.vhd:348 The attract wipe covers the old scene with alpha tiles (~380 wr/frame in MAME); the stalled red panel on device is either those writes missing (game-logic divergence) or written-but-not-rendered. rtl/core/escape_core.vhd:419 watchdog: game strobes 2E0000 (MAME eprom.cpp truth); if no strobe for 64 vblanks (~1.07s, authentic recover-by-reboot) this pulses high once rtl/core/escape_core.vhd:456 v83: pending scroll (written any time) vs applied scroll (latched at frame start) - MAME eprom scanline_update applies alpha 780/781 only at scanline 0; instant application tore animated-scroll screens rtl/core/escape_core.vhd:568 LANE4n gameplay shadows: MAME PC profile of demo gameplay showed 85% of MAIN-CPU time at 0x40000-0x57FFF (page 0x4E000 alone = 51%) and 21% of EXTRA time at 0xF000 - all outside the v58 shadows = the gameplay slowdown (audio at 100% proved rtl/core/escape_core.vhd:701 This is what MAME's eprom driver models with M68000. rtl/core/escape_core.vhd:703 So the schematic and MAME never actually contradicted each other; they describe different machines. rtl/core/escape_core.vhd:1268 The watch arms on each video-CPU 5A5A command post-boot and clears on the extra's 4321 ack; ~4.7s unanswered (MAME warm ack: instant; 10x margin) latches mbox_dead. rtl/core/escape_core.vhd:1311 Compare against MAME's cycles/frame for ground truth. rtl/core/escape_core.vhd:1528 MOSDRAM-72: MAME miss-profiles (attract incl. rtl/core/escape_core.vhd:1994 MAME's extra_map has video_int_ack_w at 360000 and clearing is shared: EITHER CPU's write drops IRQ4 for both. rtl/core/escape_core.vhd:2040 LANE4j: EXACT register widths (MAME eprom.cpp truth). rtl/core/escape_core.vhd:2041 The old 16-byte-wide windows were THE mid-game restart bug: MAME maps the run latch at the single byte 360011; our whole-window decode let game writes to unmapped 360012-1F stop the extra CPU (restart count 16 by mid-game on '58' vs MAME's rtl/core/escape_core.vhd:2091 A read of 260020+2n returns the last completed conversion in the low byte, then latches channel n (A2..A1) and starts a new one (the read strobe doubles as ALE/START; behavioral reference: MAME eprom adc_r = data_r + address_offset_start_w) rtl/core/escape_core.vhd:2143 -------------------------------------------------------------- JSA-I sound board link strobes: level-per-bus-cycle is safe (data stable across the cycle; escape_jsa's full/NMI logic is edge-derived internally) LANE4j: exact widths here too rtl/core/escape_core.vhd:2222 v61 coin-chain probes: count 68k response reads (frozen while resp_full is up = the game stopped listening to the JSA), latch the last response byte, count raw coin-line edges, and snoop the game's own credit counter (work-RAM byte $3F7F55, rtl/core/escape_core.vhd:2250 LANE3r engine-state probes (MAME attract study): the actor table head word 3F5000 is 0x12xx-patterned when the demo/game engine has spawned actors, 0000 on art pages; mode bytes 3F7F16 (60 art / 54 demo) and 3F7F23 (18 art / 2a demo). rtl/core/escape_core.vhd:2330 LANE3q: the EXTRA CPU's IO reads were never decoded - every read of 260000/260010/ADC/SCOM returned 0x0000 (MAME's extra_map maps them all). rtl/core/escape_jsa.vhd:2 Re-implemented from the behavior documented in reference/atarijsa.cpp (MAME, BSD-3-Clause) — no code copied. rtl/core/escape_jsa.vhd:142 TMS5220 (LANE3u: the real chip - d18c7db's MAME-faithful core from the System 1 tree; Speak External mode is exactly what JSA firmware uses). rtl/core/escape_jsa.vhd:153 MAME 6502-bus trace (mix_trace.lua) proved the firmware strobes WS through the WRIO latch on EVERY byte (2A04=07 -> 2A00=data -> 2A04=05), exactly the real board's LS273 wiring and the donor CART.vhd hookup. rtl/core/escape_jsa.vhd:222 -------------------------------------------------------------- 6502 + reset snd_res (68k 360020) pulses a short internal reset, MAME sound_reset_w rtl/core/escape_jsa.vhd:379 LANE3v: a 2A00 write IS a complete TMS byte transfer (MAME data_w semantics). rtl/core/escape_jsa.vhd:437 D7 self-test (MAME nets 0 in normal play) rtl/core/escape_jsa.vhd:444 The schematic doc calls these "+5V", but the JSA harness wires 0x04 as a third coin input (MAME JSAI port: Coin 3, IP_ACTIVE_HIGH; measured idle 2804 = 0x50/0x40, D3:2 = 00). rtl/core/escape_jsa.vhd:451 D1:0 coins ACTIVE HIGH (MAME JSAI: IP_ACTIVE_HIGH; measured: idle 0, held coin reads 1) rtl/core/escape_mob.v:3 During each scanline, builds the NEXT line into a line buffer: SLIP[band] -> linked list of 4-word entries (link4 layout) -> per-tile chunky gfx fetches via the shared video SDRAM channel -> first-write-wins pixels (equivalent to MAME's re rtl/core/escape_mob.v:431 That is checked, not argued: sim/tools/mob_order_check.py diffs the per-line sprite load sequence against the depth-1 engine's (the shorter run must be an exact prefix of the longer) and sim/tools/mob_vs_mame.py scores the rendered layer ag rtl/core/escape_mob.v:615 v80: MAME atarimo ground truth - the entry Y field is NEGATED and offset by the sprite height: top = -yfield - (height+1)8. rtl/core/escape_mob.v:896 The old "+2" made every sprite land one scanline too high; cross-correlating the engine's output against MAME's showed a clean (dx=0, dy=+1) peak covering 88% of the matched pixels. rtl/core/escape_mob.v:1113 MOPRI-1: eprom MO config, "mask for the priority" = 0x0070 in word 2 (reference/eprom.cpp s_mob_config). rtl/core/escape_mob.v:1194 eprom's MO config sets "render in reverse order" (reference/eprom.cpp s_mob_config), so atarimo draws the linked list from its TAIL back to its HEAD - the head entry is painted last and therefore wins every pixel it touches. rtl/core/escape_prio.v:4 Purely combinational; replaces the old fixed "MO always in front of PF" ladder in core_top.v. Transcribed from the GAL equations verified off the real PCB and quoted in reference/eprom.cpp (screen_update_eprom): rtl/core/escape_prio.v:21 Signal mapping into this core's pixel pipeline (derived from MAME's tile-info + pen construction for eprom - see docs/investigations/mo_priority.md): rtl/core/escape_prio.v:24 MPR2:MPR0 motion-object entry word 2 bits [6:4] (config mask 0x0070) MPX7:MPX4 motion-object colour = mo_pen[7:4] MPX3:MPX0 motion-object pixel = mo_pen[3:0] PFX5:PFX4 playfield priority = low two bits of the playfield tile colo rtl/core/escape_stain.v:15 The reference (reference/atarimo.cpp, apply_stain) is: rtl/core/escape_stain.v:24 restarted at every marker pixel by eprom.cpp's second iterate_dirty_rects pass. rtl/core/hall_stick.v:7 X axes are reversed on the real harness (full right = 0x00, per MAME's PORT_REVERSE on ADC1/ADC3), so targets are pre-reversed here; escape_core's ADC model digitizes exactly what it is handed. rtl/escape_mister.v:265 MAME declares this region ROMREGION_INVERT, so every byte is complemented first; then plane bits are gathered into 4-bit pixels, two per output byte, plane0 = MSB. rtl/escape_mister.v:700 PF has the only hard realtime deadline in the system, and its demand is bounded (two fetches per 8-px cell), so the CPUs wait at most ~two reads - the attract-cycle benchmark has the game running slightly FASTER than MAME, so that headroom rtl/escape_mister.v:937 column-major map scan (MAME SCAN_COLS semantics) README.md:10 A MiSTer (DE10-Nano) port of the [Atari Dual 68k](https://github.com/spoonelli/Atari-Dual-68k) core, implementing Atari Games' 1989 arcade release (MAME set `ep README.md:45 Authentic (schematic-verified): clock frequencies (7.159 MHz CPUs, true pixel clock, all clocks derived from the board's 14.318 MHz colorburst family); rast README.md:65 Frame-level pacing: attract-loop period accuracy exceeding 99.6% against MAME, story-panel timers in exact lockstep — and the residual is MAME slowing * README.md:70 Slowdown character: in heavy crowds the game software slows on every platform; a MAME longplay spends ~1.5x more of its crowd time slowed than this core — c README.md:74 This port specifically: crowd-scene scroll-velocity distributions measured identical to the Analogue Pocket release, with zero sub-half-speed dips where MAM README.md:77 Pixels: motion-object output replays MAME scene dumps at 100.0000% agreement and coverage on crowd, door, spawn-flash and factory-map fixtures. Says it matches, follows or was checked against MAME — 1 README.md:33 \| Video: alpha / playfield / motion objects, IRGB palette + intensity \| ✅ pixel-verified vs MAME scene replay \| Says it was translated, ported or taken from MAME — 1 rtl/core/TMS5220.vhd:21 IMPORTANT NOTES: 1) This implementation does NOT implement the schematic in US4335277 2) It is based primarily on MAME source code and aims to be "functionally equivalent" to the "TMS5220" chip but not identical in terms of electrical circu Shares text with the MAME driver without saying so — 4 rtl/core/escape_prio.v:12 !SHADE = !MPX0 + MPX1 + MPX2 + MPX3 + !MPX4!MPX5!MPX6!MPX7 + FORCEMC0 — shares text with atari/eprom.cpp:328 rtl/core/escape_prio.v:14 !PF/M = MPR0MPR1 + PFX3 + !PFX4MPR1 + !PFX5MPR1 + !PFX5*MPR0 — shares text with atari/eprom.cpp:336 rtl/core/escape_stain.v:32 START_MARKER = (4 << PRIORITY_SHIFT) \| 2 — shares text with atari/atarimo.cpp:241 rtl/core/escape_stain.v:33 END_MARKER = (4 << PRIORITY_SHIFT) \| 4 — shares text with atari/atarimo.cpp:242
Exerion# Exerion MiSTer-devel/Arcade-Exerion_MiSTer @ e4c3ef79 MAME compared: jaleco/exerion.cpp Read: 12 HDL files, 3,291 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	16%
Statements: 3 toward hardware Cites hardware documentation that MAME's driver does not — 3 rtl/ttl_chips.v:6 74LS74 Chip pinout: rtl/ttl_chips.v:57 74LS107 Chip pinout: rtl/ttl_chips.v:102 74LS139 Chip pinout:
Exidy2# Hard Hat, Mouse Trap, Pepper II, Spectar … MiSTer-devel/Arcade-Exidy2_MiSTer @ 91864236 MAME compared: exidy/exidy.cpp Read: 7 HDL files, 2,922 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	36%
Statements: 4 toward hardware Cites hardware documentation that MAME's driver does not — 4 rtl/audio_board.v:95 The PIAs @9B & 8B of the audio expansion board provide a handshake between the main CPU and the audio CPU rtl/ttl_chips.v:6 74LS74 Chip pinout: rtl/ttl_chips.v:57 74LS107 Chip pinout: rtl/ttl_chips.v:102 74LS139 Chip pinout:
ExpressRaider# Western Express MiSTer-devel/Arcade-ExpressRaider_MiSTer @ 970e8f54 MAME compared: dataeast/exprraid.cpp Read: 94 HDL files, 18,311 lines (Quartus project)	MiSTer official	Mostly hardware	low	30%
Statements: 8 toward hardware, 1 toward MAME Cites hardware documentation that MAME's driver does not — 7 rtl/audio/ym2203/jt12_exprom.v:19 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots. rtl/audio/ym2203/jt12_logsin.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots. rtl/audio/ym2203/jt12_op.v:19 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots. rtl/audio/ym2203/jt12_reg.v:329 memory for CH registers Block/fnum data is latched until fnum low byte is written to Trying to synthesize this memory as M-9K RAM in Altera devices turns out worse in terms of resource utilization. rtl/audio/ym3526/jtopl_exprom.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots. rtl/audio/ym3526/jtopl_logsin.v:16 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots. rtl/audio/ym3526/jtopl_op.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots. Ships hardware documentation files — 1 _schematics/Express Raider Schematics.pdf Cites MAME source — 1 rtl/audio/ym2203/jt12_lfo.v:78 same values as in MAME
Finalizer# Finalizer: Super Transformation MiSTer-devel/Arcade-Finalizer_MiSTer @ d4828f09 MAME compared: konami/finalizr.cpp + 3 related file(s) Read: 10 HDL files, 7,227 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	15%
Statements: 1 toward MAME Cites MAME source — 1 rtl/custom/k005885.sv:388 The 005885 has five 8-bit registers set up as follows according to information in konamiic.txt found in MAME's source code:
FoodFight# Food Fight MiSTer-devel/Arcade-FoodFight_MiSTer @ 0e055157 MAME compared: atari/foodf.cpp Read: 25 HDL files, 7,857 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	1%
Statements: 2 toward hardware Cites hardware documentation that MAME's driver does not — 2 rtl/Pokey/pokey_poly_17_9.vhdl:53 next state (as pokey decap) rtl/Pokey/pokey_poly_17_9.vhdl:74 from pokey schematics
freeze# Freeze, Jack the Giantkiller, Super Casino, Tri-Pool: 3-In-One … MiSTer-devel/Arcade-Freeze_MiSTer @ c68025bd MAME compared: cinematronics/jack.cpp Read: 35 HDL files, 7,820 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	0%
No statements found
Frenzy# Frenzy MiSTer-devel/Arcade-Frenzy_MiSTer @ 94841c8a MAME compared: stern/berzerk.cpp Read: 9 HDL files, 2,598 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	45%
Statements: 3 toward MAME Cites MAME source — 2 rtl/berzerk.vhd:62 Mame command reminder wpiset 40,1,w,1,{printf "a:%08x d:%02X",wpaddr,wpdata; g} wpiset 40,1,w,(wpdata!=0) && (wpdata!=90) && (wpdata!=92),{printf "a:%08x d:%02X",wpaddr,wpdata; g} rtl/berzerk_speech.vhd:6 By Jonathan Gevaryahu ("Lord Nightmare") with help from Kevin Horton ("kevtris") MAME conversion and integration by R. Belmont Clock Frequency control updated by Zsolt Vasvari Other fixes by AtariAce Says it was translated, ported or taken from MAME — 1 rtl/berzerk_speech.vhd:4 s14001a speech synthesis based on Mame source code : TSI S14001A emulator v1.32
Fuuki# Asura Blade - Sword of Dynasty, Asura Buster - Eternal Warriors, Susume! Mile Smile / Go Go! Mile Smile, Gyakuten!! Puzzle Bancho MiSTer-devel/Arcade-Fuuki_MiSTer @ 2964ff4b MAME compared: fuuki/fuukifg2.cpp, fuuki/fuukifg3.cpp + 4 related file(s) Read: 27 HDL files, 6,817 lines (Quartus project)	MiSTer official	Mostly MAME	medium	61%
Statements: 1 toward hardware, 65 toward MAME Notes where it differs from MAME — 1 Fuuki.sv:669 The DIP "Flip Screen" (which both MAME drivers get wrong) stays commented out of the .mra files. Cites MAME source — 52 Fuuki.sv:164 Both boards drive one speaker (fuukifg2.cpp / fuukifg3.cpp), so the default, status value 0, is mono. Fuuki.sv:335 Every port is IP_ACTIVE_LOW in MAME; hps_io's joysticks are active high, hence the `~`. Fuuki.sv:340 P1_P2 ($810000), from fuukifg2.cpp / fuukifg3.cpp INPUT_PORTS_START. rtl/cpu/maincpu.sv:95 Interrupt sources: levels held by the video timing, MAME's HOLD_LINE. rtl/cpu/maincpu.sv:192 FG-2 mirrors sprite RAM at +0x8000 (MAME: .mirror(0x008000)). rtl/cpu/maincpu.sv:203 FG-2 sound latch: MAME maps the one byte at 0x8a0001. rtl/cpu/maincpu.sv:213 FG-3's 0x508000-0x517FFF: MAME calls it "more tilemap, or linescroll? rtl/fuuki_core.sv:648 Reference: gogomile's clouds (MAME capture: bands at 2, 1, 1/2, 0, 0 px/frame from lines 0, 30, 64, 89, 119) and pbancho's per-line scroll. rtl/fuuki_core.sv:893 xRGB-555 as MAME decodes it (palette_device::xRGB_555 is standard_rgb_decoder<5,5,5, 10,5,0>): bits 14:10 red, 9:5 green, 4:0 blue. rtl/memory/fuuki_sdram_top.sv:109 ---- address map, FG-3 ---- Sizes are the ROM_REGION declarations in fuukifg3.cpp, not the ROMs loaded: asurabld leaves the first 4 MB of its 32 MB sprite region empty and the sprite tile bank can address it, so the hole is part of the map. rtl/memory/fuuki_sdram_top.sv:118 2 MB (MAME "tiles_bg") rtl/memory/fuuki_sdram_top.sv:120 4 MB (MAME "ymf", OPL4 samples) rtl/video/compositor.sv:5 MAME draws back, middle, front with priority codes 1, 2, 4, ORing each into a priority bitmap where the layer is opaque, so a pixel carries a 3-bit value saying which layers covered it. rtl/video/compositor.sv:23 The backdrop is the last palette pen, 0x1fff, not pen 0: MAME fills with (0x8004)-1 and the game writes black there at boot. rtl/video/sprite_line_engine.sv:104 Separate non-zoomed path, as MAME: the zoom path draws 17 pixels at full size (sprite_zoom_lut.sv). rtl/video/sprite_line_engine.sv:118 ---- code index ---- MAME increments the tile code in loop order and positions by the loop variable, so with flip the code is counted from the far end: iteration number, not position. rtl/video/sprite_line_list.sv:10 This is the order measured on MiSTer (asurabld high-score table, in-game sprites, character-name flashes) and the opposite of what fuukispr.cpp's backwards walk for pdrawgfx suggests. rtl/video/sprite_line_list.sv:62 ---- geometry, from the four latched words ---- Signed 10-bit positions, MAME's (v & 0x1ff) - (v & 0x200). rtl/video/sprite_line_list.sv:74 MAME's separate non-zoomed path when both fields are zero; the zoom path draws 17 pixels at full size (sprite_zoom_lut.sv). rtl/video/sprite_zoom_lut.sv:3 MAME hands zoom_transpen a 16.16 scale of 512 (zoom + 8), zoom = 128 - 4field, so a 16-pixel tile draws (zoom + 8) / 8 wide and destination pixel d samples source pixel (d << 16) / scale. rtl/video/sprite_zoom_lut.sv:13 That is why the engine keeps MAME's separate non-zoomed path. rtl/video/sprite_zoom_lut.sv:26 step = (128 << 16) / (zoom_t + 8), truncated as MAME's integer division. rtl/video/spriteram_dbuf.sv:5 A frame is therefore drawn from the sprite RAM as it was at one instant, as MAME's single-pass screen_update does. rtl/video/spriteram_dbuf.sv:13 FG-3 (fuukifg3.cpp screen_vblank) appears to hold sprites two generations back. rtl/video/tilemap_line_engine.sv:49 MAME does not flip by rotating the output: fuukitmap.cpp substitutes offset constants and fuukispr.cpp recomputes sprite positions, so it has to be done here. rtl/video/video_timing.sv:3 Neither driver calls set_raw(); fuukifg2.cpp and fuukifg3.cpp give only set_refresh_hz(60) and a visible area, so htotal, vtotal and sync positions are derived (docs/ROADMAP.md, "Screen timing"): rtl/video/video_timing.sv:52 maincpu.sv edge-detects them into a held pending flag cleared only by acknowledge (MAME's HOLD_LINE). rtl/video/video_timing.sv:54 Positions from fuukitmap.cpp's timers: level 1 screen().time_until_pos(248) -> line 248, x=0 level 3 screen().time_until_vblank_start() -> line 240, x=0 level 5 screen().time_until_pos(vregs[0x1c], max_x + rtl/video/video_timing.sv:83 losing the effect's first five lines and adding five spurious interrupts a frame (checked against MAME traces in debug/). rtl/video/video_timing.sv:123 raster_line arrives from vregs.sv already reduced as MAME's time_until_pos() reduces it, so every register value fires once a frame. rtl/video/video_timing.sv:126 Level 5 fires at the hblank one line before the programmed line, not at that line's own hblank as MAME's timer does: the engines render two lines ahead of the display and a raster ISR's write is caught at the hblank after the interrupt. rtl/video/video_timing.sv:132 lead 2 : bands start at 29, 63, 88, 118 (MAME: 30, 64, 89, 119) lead 1 : bands start at 30, 64, 89, 119 exact rtl/video/vregs.sv:1 Fuuki video registers (FI-003K), from fuukitmap.cpp. rtl/video/vregs.sv:7 sel 1 0x8D0000 "unknown, flipscreen related" (MAME's words) rtl/video/vregs.sv:10 Register map (fuukitmap.cpp's own comment block): rtl/video/vregs.sv:95 ---- raster line: the low 8 bits of regs[0x1c], as MAME ---- fuukitmap.cpp hands the value to screen::time_until_pos(), which reduces it modulo the screen height, 256 on both boards (fuukifg2.cpp set_size(320, 256); fuukifg3.cpp set_size(51 rtl/video/vregs.sv:111 ---- scroll offsets ---- From fuukitmap.cpp::prepare(), operators included: rtl/video/vregs.sv:143 16-bit wrapping arithmetic, as MAME's u16. rtl/video/vregs.sv:154 ---- layer order ---- The low 4 bits of the priority register index a table of orderings (fuukitmap.cpp: "not independent bits causing layers to switch"). rtl/video/vregs.sv:156 MAME indexes a six-entry table with `& 0x0f`, so 6-15 read out of bounds there; here they fall through to entry 0 (docs/ROADMAP.md open item 5). README.md:109 Put the MAME merged or split ROMs in `games/mame` README.md:141 The MAME drivers being ported here, `fuukifg2.cpp` and `fuukifg3.cpp` are based on my and others, work. README.md:147 Hardware facts come from the MAME driver. README.md:149 The graphics layouts were rendered to PNG from real ROM data before any RTL used them; the CPU is diffed against a real MAME trace; the video pipeline is diffed README.md:152 Where the reference and the hardware disagree, or where MAME's own comments disclaim accuracy, that is recorded as an open question rather than silently resolve README.md:159 MAME is the accuracy reference, with its own acknowledged uncertainties noted where they matter (both Fuuki drivers flag raster effects and flipped-screen scrol README.md:167 Ground truth captured from MAME automatically.* `scripts/mame_capture.py` drives MAME headlessly over its Lua interface and dumps every region the video hard README.md:171 That makes "compare against MAME" a single command rather than a hand-driven debugger session. README.md:172 Offline proofs before building. ROM interleaves are scored against MAME's disassembly, and graphics layouts rendered to PNG, before any RTL depends on them. README.md:191 The MAMEdev team — in particular Luca Elia, David Haywood and my own earlier work — for [MAME](https://github.com/mamedev/mame)'s `fuukifg2.cpp`, `f README.md:227 \| `debug` \| reference captures from MAME used as ground truth (gitignored) \| README.md:228 \| `roms` \| your own MAME sets (gitignored, never committed) \| Says it matches, follows or was checked against MAME — 1 README.md:116 Same as MAME, but would love to see real hardware Shares text with the MAME driver without saying so — 12 rtl/cpu/maincpu.sv:214 Seems to be empty all of the time". Decoded so accesses terminate, not — shares text with fuuki/fuukifg3.cpp:396 rtl/fuuki_core.sv:371 layer 0 layer 1 layer 2 — shares text with fuuki/fuukifg2.cpp:127 rtl/video/tilemap_line_engine.sv:170 exceed the granularity there ("256 colour tiles with palette selectable — shares text with fuuki/fuukifg2.cpp:157 rtl/video/vregs.sv:12 00.w Layer 0 Scroll Y 0c.w Layers Y Offset — shares text with fuuki/fuukitmap.cpp:194 rtl/video/vregs.sv:13 02.w Layer 0 Scroll X 0e.w Layers X Offset — shares text with fuuki/fuukitmap.cpp:195 rtl/video/vregs.sv:14 04.w Layer 1 Scroll Y 1c.w Trigger a level 5 irq on this raster line — shares text with fuuki/fuukitmap.cpp:196 rtl/video/vregs.sv:15 06.w Layer 1 Scroll X 1e.w bit 0 Flip screen — shares text with fuuki/fuukitmap.cpp:197 rtl/video/vregs.sv:16 08.w Layer 2 Scroll Y bit 6 Layer 2 VRAM buffer select — shares text with fuuki/fuukitmap.cpp:198 rtl/video/vregs.sv:17 0a.w Layer 2 Scroll X — shares text with fuuki/fuukitmap.cpp:199 rtl/video/vregs.sv:114 scrolly_offs = m_vregs[0xc/2] - (m_flip ? m_xoffs_flip : m_xoffs); — shares text with fuuki/fuukitmap.cpp:245 rtl/video/vregs.sv:115 scrollx_offs = m_vregs[0xe/2] - (m_flip ? m_yoffs_flip : m_yoffs); — shares text with fuuki/fuukitmap.cpp:246 rtl/video/vregs.sv:156 (fuukitmap.cpp: "not independent bits causing layers to switch"). MAME — shares text with fuuki/fuukitmap.cpp:229
Galaga# Galaga MiSTer-devel/Arcade-Galaga_MiSTer @ c84be1c7 MAME compared: namco/galaga.cpp + 12 related file(s) Read: 23 HDL files, 8,015 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	26%
Statements: 9 toward MAME Cites MAME source — 9 rtl/galaga.vhd:34 Features : TV 15KHz mode only (atm) Coctail mode ok Sound ok Starfield from MAME information rtl/galaga.vhd:40 Use with MAME roms from galagamw.zip rtl/galaga.vhd:69 Namco 05XX Starfield 4 sets, 63 stars/set, 2 set displayed at one time for blinking 6bits colors: 2red/2green/2blue full emulation in vhdl (from MAME information) rtl/stars.vhd:6 Done from only available MAME information rtl/stars.vhd:24 Scan line number are 1 less than MAME list because of way of realisation Scan line number are ordered from lower to higher. rtl/stars_machine.vhd:6 Done from only available MAME information rtl/stars_machine.vhd:24 Scan line number are 1 less than MAME list because of way of realisation Scan line number are ordered from lower to higher. README.md:65 /quote from [MAME sources](https://github.com/mamedev/mame/blob/a32810d97465ae077ece35984a98a92abbf3462f/src/mame/drivers/galaga.cpp#L584-L587)/: There is a bug README.md:78 [Source](https://github.com/mamedev/mame/blob/a32810d97465ae077ece35984a98a92abbf3462f/src/mame/drivers/galaga.cpp#L555-L559)
Galaxian# Azurian Attack, Black Hole, Catacomb, Galaxian … MiSTer-devel/Arcade-Galaxian_MiSTer @ 9fecadef MAME compared: galaxian/galaxian.cpp + 7 related file(s) Read: 22 HDL files, 4,906 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	12%
Statements: 2 toward MAME Cites MAME source — 1 Arcade-Galaxian.sv:452 NOTE: mame order matches order in mc_inport, mc_inport reorders these Shares text with the MAME driver without saying so — 1 rtl/mc_inport.vhd:17 DIP SW 0 1 2 3 4 5 — shares text with galaxian/galaxian.cpp:2796
Galivan# Ufo Robo Dangar, Cosmo Police Galivan MiSTer-devel/Arcade-Galivan_MiSTer @ 08c16a1d MAME compared: nichibutsu/galivan.cpp + 4 related file(s) Read: 42 HDL files, 10,306 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	8%
Statements: 3 toward hardware Cites hardware documentation that MAME's driver does not — 3 rtl/ym3526/jtopl_exprom.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots. rtl/ym3526/jtopl_logsin.v:16 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots. rtl/ym3526/jtopl_op.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.
Gaplus# Gaplus MiSTer-devel/Arcade-Gaplus_MiSTer @ 718b413d MAME compared: namco/gaplus.cpp + 7 related file(s) Read: 16 HDL files, 7,148 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	0%
No statements found
Gauntlet# Gauntlet II, Gauntlet, Vindicators Part II MiSTer-devel/Arcade-Gauntlet_MiSTer @ a27c3f1a MAME compared: atari/gauntlet.cpp + 4 related file(s) Read: 26 HDL files, 6,302 lines (Quartus project)	MiSTer official	Both	medium	92%
Statements: 64 toward hardware, 5 toward MAME, 12 not counted Cites hardware documentation that MAME's driver does not — 63 rtl/gauntlet/AUDIO.vhd:212 sheet 5 -- rtl/gauntlet/AUDIO.vhd:345 sheet 6 -- rtl/gauntlet/AUDIO.vhd:376 15S latch - 3 bit volume control rtl/gauntlet/AUDIO.vhd:485 sheet 7 -- rtl/gauntlet/CRAMS.vhd:51 sheet 15 Color RAM -- rtl/gauntlet/CRAMS.vhd:61 10L, 10M RAM rtl/gauntlet/GPC.vhd:13 Graphic Priority Control (Atari custom chip 137419-101) This GPC was derived from System I SP-277 schematic rtl/gauntlet/GPC.vhd:73 These equations describe the PROM 3E contents, top 2 data bits are the same as bottom 2 data bits as can be seen in PROM dump rtl/gauntlet/GPC.vhd:85 9D latch rtl/gauntlet/GPC.vhd:101 3H latch rtl/gauntlet/GPC.vhd:124 3F latch rtl/gauntlet/LINEBUF.vhd:74 1X, 1W, 2X, 2W RAM rtl/gauntlet/LS299.vhd:17 simplified 74LS299 shifter as used in SLAGS rtl/gauntlet/MAIN.vhd:221 sheet 2 rtl/gauntlet/MAIN.vhd:407 sheet 3 rtl/gauntlet/MAIN.vhd:506 sheet 4 rtl/gauntlet/MAIN.vhd:538 sheet 7 rtl/gauntlet/MAIN.vhd:566 RAMs 11A/B rtl/gauntlet/MAIN.vhd:567 RAMs 12A/B rtl/gauntlet/MOHLB.vhd:44 sheet 13 Motion Object Line Buffer -- rtl/gauntlet/MOHLB.vhd:47 5S latch rtl/gauntlet/PFHS.vhd:13 Play Field Horizontal Scroll (Atari custom chip 137419-104) This PFHS was derived from System I SP-277 schematic rtl/gauntlet/PFHS.vhd:76 11E latch rtl/gauntlet/PFHS.vhd:89 two 74LS189 16x4 bit RAMs, arranged as one 16x8 RAM but only 3 address lines used, so really one 8x8 RAM IMPORTANT: data out is the COMPLEMENT of data in!!! rtl/gauntlet/PFHS.vhd:102 4D latch rtl/gauntlet/SLAGS.vhd:13 Storage/Logic Array Graphics Shifter (Atari custom chip 137415-101) This SLAGS was derived from Marble Madness SP-276 schematic rtl/gauntlet/SLAGS.vhd:73 latch 8B rtl/gauntlet/SLAGS.vhd:84 latch 11A rtl/gauntlet/SYNGEN.vhd:13 System Clock and Sync Generator (Atari custom chip 137419-103) This SYNGEN was derived from System I SP-277 schematic rtl/gauntlet/SYNGEN.vhd:106 From SP-313 this is /HBLANK rtl/gauntlet/SYNGEN.vhd:161 Equations for PLA chip 7F Signetics 82S153 aka PLS153A (Atari custom chip 136032.103) /o19 = /i1 & i2 & i3 & i7 & i8 & i9 o18 = i1 & /i2 o17 = i1 & /i2 & /i3 + /i1 & i2 & /i3 + i1 & /i2 & i3 o16 = /i2 + i1 & i2 & /i3 + /i1 & i2 & i3 rtl/gauntlet/VIDEO.vhd:255 sheet 2 control signals -- rtl/gauntlet/VIDEO.vhd:270 sheet 8 RAM banks -- rtl/gauntlet/VIDEO.vhd:287 sheet 9 VRAM addr and data bus muxes -- rtl/gauntlet/VIDEO.vhd:291 8F, 8J latches sheet 9 D transfered to Q on the rising edge of clock if enable /G is low rtl/gauntlet/VIDEO.vhd:311 7S latch rtl/gauntlet/VIDEO.vhd:346 sheet 10 rtl/gauntlet/VIDEO.vhd:350 3C, 3K latch sheet 10 rtl/gauntlet/VIDEO.vhd:363 5C, 5K latches sheet 10 rtl/gauntlet/VIDEO.vhd:378 4E latch rtl/gauntlet/VIDEO.vhd:413 PROM 5L is 82S147 512x8 TTL BIPOLAR PROM (Atari chip 136037.102) Top 2 address bits tied low so only 128x8 used rtl/gauntlet/VIDEO.vhd:459 4C, 4K latch rtl/gauntlet/VIDEO.vhd:470 4D latch rtl/gauntlet/VIDEO.vhd:484 sheet 11 - plane 0 and plane 1 ROMs and SLAG -- sheet 12 - plane 2 and plane 3 ROMs and SLAG -- ROMs total 256KB and are stored outside the FPGA rtl/gauntlet/VIDEO.vhd:529 sheet 13 Play Field Scroll -- rtl/gauntlet/VIDEO.vhd:564 sheet 14 rtl/gauntlet/VIDEO.vhd:569 4N, 3N latches sheet 14 rtl/gauntlet/VIDEO.vhd:592 3P latch rtl/gauntlet/VIDEO.vhd:658 6U latch with 7U PROM equations rtl/gauntlet/VIDEO.vhd:662 82S147 512x8 TTL BIPOLAR PROM (Atari chip 136037.101) These equations replace the 7U PROM rtl/gauntlet/VIDEO.vhd:797 sheet 15 rtl/gauntlet/VIDEO.vhd:854 9N, 10N latch color palette output rtl/gauntlet/VIDEO.vhd:918 4P latch rtl/gauntlet/VIDEO.vhd:923 7R latch rtl/gauntlet/VRAMS.vhd:76 sheet 9 RAM decoder -- rtl/gauntlet/VRAMS.vhd:93 sheet 8 RAM banks -- rtl/gauntlet/VRAMS.vhd:103 PF video RAMs 6J, 7J rtl/gauntlet/VRAMS.vhd:116 PF video RAMs 6D, 7D rtl/gauntlet/VRAMS.vhd:129 MO video RAMs 6F, 7F rtl/gauntlet/VRAMS.vhd:142 MO video RAMs 6C, 7C rtl/gauntlet/VRAMS.vhd:155 AL video RAMs 6K, 7K rtl/gauntlet/VRAMS.vhd:168 AL video RAMs 6E, 7E readme.md:5 This is an FPGA implementation of Atari's arcade game "Gauntlet" from 1985, based on the SP-284 schematic circuit diagram. Cites hardware references or measurements that MAME's driver also gives — 12 Arcade-Gauntlet.sv:523 ioctl_addr 000000..01FFFF = video ROMs 2L 2A 1L 1A (432KB) ioctl_addr 020000..03FFFF = video ROMs 2MN 2B 1MN 1B (432KB) ioctl_addr 040000..05FFFF = video ROMs 2P 2C 1P 1C (432KB) ioctl_addr 060000..07FFFF = video ROMs 2R 2D 1 — also in MAME: 2L atari/gauntlet.cpp:887, 2A atari/gauntlet.cpp:885, 1L atari/gauntlet.cpp:883, 1A atari/gauntlet.cpp:881, 2MN* atari/gauntlet.cpp:888, 2B atari/gauntlet.cpp:886, 1MN atari/gauntlet.cpp:884, 1B atari/gauntlet.cpp:882, 2P atari/gauntlet.cpp:1639, 2C atari/gauntlet.cpp:1635, 1P atari/gauntlet.cpp:1631, 1C atari/gauntlet.cpp:1627, 2R atari/gauntlet.cpp:1902, 2D atari/gauntlet.cpp:1895, 1R atari/gauntlet.cpp:1888, 1D atari/gauntlet.cpp:1881, 2ST atari/gauntlet.cpp:1903, 2EF atari/gauntlet.cpp:1896, 1ST atari/gauntlet.cpp:1889, 1EF atari/gauntlet.cpp:1882, 2U atari/gauntlet.cpp:1904, 2J atari/gauntlet.cpp:1897, 1U atari/gauntlet.cpp:1890, 1J atari/gauntlet.cpp:1883 Arcade-Gauntlet.sv:545 ioctl_addr 140000..147FFF = AUDIO ROM 16S (32KB) — also in MAME: 16S atari/gauntlet.cpp:875 Arcade-Gauntlet.sv:547 ioctl_addr 148000..14BFFF = AUDIO ROM 16R (16KB) — also in MAME: 16R atari/gauntlet.cpp:874 Arcade-Gauntlet.sv:549 ioctl_addr 14C000..14FFFF = CHAR ROM 6P (16KB) — also in MAME: 6P atari/gauntlet.cpp:878 rtl/gauntlet/GPC.vhd:134 1B, 5B latch — also in MAME: 1B atari/gauntlet.cpp:882, 5B atari/gauntlet.cpp:1863 rtl/gauntlet/MAIN.vhd:564 ROMs 10A/B, 9A/B, 7A/B — also in MAME: 10A atari/gauntlet.cpp:866, 9A atari/gauntlet.cpp:862, 7A atari/gauntlet.cpp:868 rtl/gauntlet/SYNGEN.vhd:134 82S129 256x4 TTL BIPOLAR PROM (Atari chip 136032.102) — also in MAME: 82S129 atari/gauntlet.cpp:1645 rtl/gauntlet/VIDEO.vhd:244 Vindicators II uses ROM 2J which is the only ROM with a scrambled address -- FIXME — also in MAME: 2J atari/gauntlet.cpp:1897 rtl/gauntlet/VIDEO.vhd:602 PROM 4R is 74S287 (256x4) TTL PROM "136037-103" — also in MAME: 4R atari/gauntlet.cpp:893, 74S287 atari/gauntlet.cpp:893, 136037-103 atari/gauntlet.cpp:893 rtl/gauntlet/VIDEO.vhd:654 Vindicators has tweaked equations in PROM 7U for signal /NEWMON Select between Vindicators or Gauntlet equations — also in MAME: 7U atari/gauntlet.cpp:891 rtl/gauntlet/VIDEO.vhd:771 UNUSED this /BUFCLR replaced by signal from PROM 7U — also in MAME: 7U atari/gauntlet.cpp:891 readme.md:32 WARNING: In order to play Vindicators part 2, you must run the python script "descramble_2J.py 136059-1184.2j 136059-1184.des.2j" then copy the binary output — also in MAME: 136059-1184 atari/gauntlet.cpp:1897, 136059-1184 atari/gauntlet.cpp:1897, 136059-1184 atari/gauntlet.cpp:1897 Ships hardware documentation files — 1 doc/SP-284 Gauntlet schematic.pdf Cites MAME source — 3 Arcade-Gauntlet.sv:336 Gauntlet I and II - Default MAME Controls Assignment rtl/gauntlet/ROMS.G1/EEP_14A.vhd:20 signal RAM : RAM_ARRAY:=(others=>(others=>'0')); initialized EEPROM contents dumped from MAME rtl/gauntlet/TMS5220.vhd:13 References: TMS5220 datasheet, US Patent US4335277 and TMS5220.cpp from MAME source code. Says it was translated, ported or taken from MAME — 2 rtl/gauntlet/SLAPSTIC.vhd:13 SLAPSTIC 137412-104 GAUNTLET This SLAPSTIC was translated from MAME "slapstic.cpp" source code pretty much verbatim :) The original MAME C++ code is left in as comments rtl/gauntlet/TMS5220.vhd:15 IMPORTANT NOTES: 1) This implementation does NOT implement the schematic in US4335277 2) It is based primarily on MAME source code and aims to be "functionally equivalent" to the "TMS5220" chip but not identical in terms of electrical circu
Godzilla# Godzilla MiSTer-devel/Arcade-Godzilla_MiSTer @ 3cbc8514 MAME compared: seibu/legionna.cpp + 8 related file(s) Read: 24 HDL files, 10,625 lines (Quartus project)	MiSTer official	Mostly MAME	medium	71%
Statements: 5 toward hardware, 195 toward MAME, 1 not counted Cites hardware references or measurements that MAME's driver also gives — 1 rtl/Godzilla/Godzilla_maincpu_map.sv:23 Main CPU memory map Godzilla (legionna.cpp legionna_map): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $100000-$1003FF RAM scratch (1KB) → BRAM (Main RAM low) $100400-$1006FF COP3 region → m — also in MAME: 68K seibu/legionna.cpp:46 Reports a measurement taken on the original PCB — 1 rtl/Godzilla/Godzilla_video_timing.sv:26 PCB measurement Blood Bros: VSync 59.4094 Hz, HSync 15.6246 kHz, master XTAL 20 MHz. Says it was checked on “real hardware” — 4 rtl/Godzilla/Godzilla_cop3.sv:336 0 : 1 (unsigned <320 provato su HW = REGRESSIONE; il signed [-160,320) dell'intento MAME e' il comportamento giusto sul core) rtl/Godzilla/Godzilla_sprite_renderer.sv:216 byte_lo = pf_rom_data[31:24]/[15:8], byte_hi = [23:16]/[7:0] Plane order DCBA (verificato su HW, come BG/MG/FG): pen[0] dal bit "D" (byte_hi[3-sub]), pen[3] dal bit "A" (byte_lo[7-sub]). rtl/Godzilla/Godzilla_sprite_renderer.sv:333 Scan INVERSO 511→0 (verificato su HW: ordine sprite-su-sprite opposto al loop MAME 0→511). rtl/Godzilla/Godzilla_tile_layer.sv:322 Plane order verificato su HW: BG/MG = DCBA (PEN_ORDER=0), FG = BADC (PEN_ORDER=1). Cites MAME source — 177 Godzilla.sv:208 Offset per-layer Godzilla: MAME visarea parte da (0,0) (set_raw vbend=0, legionna.cpp:1318) e godzilla NON definisce scrolldx/dy per BG/MG/FG ne' sprite offset (nessun set_offset, legionna.cpp:1331) → tutti 0. Godzilla.sv:213 NB: godzilla ha anche tile_scroll_base_w (legionna_v.cpp:58-65): reg base 7 → text set_scrolldy(0x1ef - data). Godzilla.sv:328 --- Joystick to SD Gundam input mapping --- MAME P1_P2 port ($E0002): active low. Godzilla.sv:331 MiSTer joy bits: joy[0]=R, joy[1]=L, joy[2]=D, joy[3]=U, joy[4]=A, joy[5]=B. MAME PLAYERS12 (legionna.cpp:439-444): bit[0]=UP, [1]=DOWN, [2]=LEFT, [3]=RIGHT, [4]=BTN1, [5]=BTN2, [6]=BTN3, [7]=unused (active low). Godzilla.sv:341 Godzilla SYSTEM port ($10074C) — MAME legionna.cpp:427-436 bit0 = START1 (active LOW) bit1 = START2 (active LOW) bit2..7 = UNKNOWN → tied 1 bit8..15 = UNKNOWN → tied 1 Coin inputs NON sono qui: vanno via SEIBU_COIN_INPUTS → Z80 → soundlatch Godzilla.sv:695 ── Flip screen (CRTC reg 0x1A bit 0) ─────────────────────────────────────── MAME: BIT(reg_1a, 0) → flip_screen. Godzilla.sv:741 ── Text layer renderer (8x8, 4bpp, 64x32 grid) ───────────────────────────── Godzilla MAME (ROM_START godzilla): "char" = REGIONE PROPRIA 128KB (11.620/10.615, ROM_LOAD16_BYTE), NON dentro user1 come Legionnaire. Godzilla.sv:754 Godzilla text scroll-base (CRTC reg 0x3A, hook godzilla-only legionna.cpp:1326). Godzilla.sv:755 Calibrazione HW di famiglia (dump vregs in seibu_crtc.cpp): Legionnaire reg=0x01FF, visarea da riga 16 → 0x1FF-0x1EF=+16 = ESATTAMENTE il vecchio yoff text +16 del core Legionnaire funzionante; D-Con reg=0xFFEF (low9=0x1EF), visarea da 0 → Godzilla.sv:759 La formula MAME set_scrolldy(0x1EF-data) è INVERTITA rispetto all'HW (convenzione dy del tilemap.cpp) — mai fidarsi del verso MAME. Godzilla.sv:797 Godzilla CRTC scroll passthrough (legionna_v.cpp:34-49 tile_scroll_w): scroll_ram[0/1] → BG (m_background_layer) scroll_ram[2/3] → MG (m_midground_layer) scroll_ram[4/5] → FG (m_foreground_layer) Nel nostro CRTC: xscroll_l0 = ram[0/1], xscr Godzilla.sv:815 Godzilla BG: tilemap 32x32 (legionna_v.cpp:204). Godzilla.sv:816 MAME GFXDECODE "back" color base = 0 (gfx_legionna riga 1168), 32 colorset. Godzilla.sv:817 HAS_TRANSP=1 perché m_background_layer->set_transparent_pen(15) in legionna_v.cpp:216 (pen 15 = trasparente, NON opaco come Blood Bros). Godzilla.sv:839 Godzilla MG: 16x16, 4bpp, 32x32 tilemap (legionna_v.cpp:204). Godzilla.sv:840 get_mid_tile_info_share_bgrom (legionna_v.cpp:158): MG share BG ROM, tile = (vram & 0xfff) \| 0x1000 (= seconda metà della BG ROM) color = ((vram >> 12) & 0xf) \| 0x10 (= palette set superiore: bit 4 = 1) In palette MAME "back" base = 0, Godzilla.sv:867 Godzilla FG: tilemap 32x32 (legionna_v.cpp:213). Godzilla.sv:869 MAME GFXDECODE "fore" color base = 3216 = 0x200, 16 colorset. Godzilla.sv:879 GODZILLA: fore = bg2.619 ROM_LOAD16_WORD_SWAP (legionna.cpp:1987) = IDENTICO alla back bg1.618 → stesso decode DCBA di BG/MG (riscontro HW utente: col BADC il FG era sbagliato). Godzilla.sv:887 Godzilla: bit 2 = FG (legionna_v.cpp:344) Godzilla.sv:974 Anticipando di 1 l'indirizzo e il DE, il dato campionato al tick e' quello del pixel CORRENTE: allineamento coi tile ripristinato (= calibrazione +1 pixel-hunting MAME, fatta prima del fix CRT) e colonna 0 coperta. Godzilla.sv:1008 MAME riferimenti (GODZILLA — diverso da legionna!): legionna_v.cpp:247-251 m_sprite_pri_mask[0..3] per godzilla: pri=0 → 0xFFF0 (copre pri-value 0,1,2 → bg,mg,fg → SOTTO text) pri=1 → 0xFFFC (copre 0,1 → bg,mg → sotto fg,text) pri=2 → 0x Godzilla.sv:1028 MAME godzilla legionna_v.cpp:382 bitmap.fill(0xff) "matches PCB recording" Godzilla.sv:1049 Backdrop = palette[0x0FF] reale (MAME godzilla: bitmap.fill(0xff), match PCB). rtl/Godzilla/Godzilla_audio_z80.sv:25 Spec da MAME (legionna.cpp godzilla machine config :1295-1355): - Z80 @ 14.318180/4 = 3.579545 MHz (seibu_sound_map + godzilla_sound_io_map) - YM2151/OPM (jt51) @ 3.579545 MHz, route ch0+ch1 0.50 su mono - OKI M6295 (jt6295) @ 20MHz/20 = 1. rtl/Godzilla/Godzilla_audio_z80.sv:57 Godzilla pcm.922 = 512KB: bit 18 = bank (Z80 IO port 0, MAME godzilla_oki_bank_w: set_rom_bank(data&1)). rtl/Godzilla/Godzilla_audio_z80.sv:364 MAME seibu_sound_device::main_r (seibusound.cpp:279): case 2,3: return sub2main[offset-2] (soundlatch data: coin/input dal Z80) case 5: return main2sub_pending ? rtl/Godzilla/Godzilla_audio_z80.sv:379 ─── YM2151 (jt51) — GODZILLA usa OPM, non OPL2 (legionna.cpp:1340) ────── Il driver Z80 programma i timer OPM (reg 0x10-0x14): su jtopl2 non scattava mai l'IRQ → RST10 morto → sequencer musica fermo. rtl/Godzilla/Godzilla_audio_z80.sv:419 MAME: route 0.50+0.50 su mono (legionna.cpp:1342-1343) rtl/Godzilla/Godzilla_audio_z80.sv:422 ─── OKI bank — GODZILLA: Z80 "OUT (0),A" → banco ROM OKI (512KB = 2×256KB) MAME godzilla_sound_io_map (legionna.cpp:282-286) port 0 → godzilla_oki_bank_w: m_oki->set_rom_bank(data & 1) (write tipica 0x02/0x03). rtl/Godzilla/Godzilla_audio_z80.sv:434 ─── OKI M6295 (jt6295) — PIN7_HIGH (20MHz/20 = 1.0 MHz, legionna.cpp:1345) rtl/Godzilla/Godzilla_cop3.sv:4 MAME-faithful implementation of the Seibu SEI300 chip as used by the `legionna` driver (Godzilla 1992 — Banpresto/TAD). rtl/Godzilla/Godzilla_cop3.sv:7 Reference (in this repo): MAME seibucop.cpp MAME seibucop_cmd.ipp MAME seibucop_dma.ipp MAME legionna.cpp rtl/Godzilla/Godzilla_cop3.sv:136 MAME cop_itoa_digits[10]: BCD digits of cop_itoa (low<<0 \| high<<16). rtl/Godzilla/Godzilla_cop3.sv:140 Il vecchio loop a sottrazioni ripetute era O(valore) (~valore/9 clk): con i long 32-bit di godzilla (score, writer $156E/$1F93E) il 68k restava congelato (dma_busy include bcd_pending) fino a MILLISECONDI per chiamata — su MAME/HW reale i d rtl/Godzilla/Godzilla_cop3.sv:153 MAME cop_program command table (seibucop.cpp lines 318-457) At boot, game code uploads 32 macro slots × 8 micro-op words via pgm_addr (0x100434) → slot8 + sub-index pgm_data (0x100432) → micro-op word pgm_value (0x100438) → cop_func_valu rtl/Godzilla/Godzilla_cop3.sv:160 MAME calls find_trigger_match(triggerval, 0xff00) to find the slot whose cop_func_trigger matches. rtl/Godzilla/Godzilla_cop3.sv:256 Triggers (write-only addresses) MAME legionna.cpp:172 maps cop_cmd_w to $100500-$100505 (3 words). rtl/Godzilla/Godzilla_cop3.sv:330 0x100410 sprite_dma_inc (MAME cop_sprite_dma_inc_w): if x_clip in [-160, 320): cop_regs[4] += 8. rtl/Godzilla/Godzilla_cop3.sv:331 MA in MAME sprite_x e' uint16_t assegnato a int -> MAI negativo -> il -160 e' codice morto: check EFFETTIVO = unsigned < 320 (X "negative" 0xFFxx NON avanzano il puntatore entry). rtl/Godzilla/Godzilla_cop3.sv:336 0 : 1 (unsigned <320 provato su HW = REGRESSIONE; il signed [-160,320) dell'intento MAME e' il comportamento giusto sul core) rtl/Godzilla/Godzilla_cop3.sv:343 A size==0 NON wrappare (il size-- uint di MAME wrapperebbe a $FFFF: il loop del builder su status[1] andrebbe in livelock — provato peggio). rtl/Godzilla/Godzilla_cop3.sv:378 Macro program upload — MAME seibucop.cpp lines 318-457 pgm_data writes one micro-op word to cop_program[latch_addr] AND latches the slot's trigger/value/mask from current latch regs. rtl/Godzilla/Godzilla_cop3.sv:479 itoa_digits (MAME 0x100590-99, 5 word). rtl/Godzilla/Godzilla_cop3.sv:491 Status / dist / angle (seibucop.cpp:916 cop_status_r → cop_status) rtl/Godzilla/Godzilla_cop3.sv:502 MAME open bus rtl/Godzilla/Godzilla_cop3.sv:569 commit write al dst ASSOLUTO (fill/mr), 1:1 MAME write_word(dst) rtl/Godzilla/Godzilla_cop3.sv:605 LEGACY sprite-DMA (seibucop_cmd.ipp): 6880 (carica rel_xy), c480 (single-step: compone l'entry sprite a cop_regs[4]+offs con X/Y = rel + (obj - abs)). rtl/Godzilla/Godzilla_cop3.sv:629 write angolo (word {0,angle} come MAME host_endian) rtl/Godzilla/Godzilla_cop3.sv:641 Trigger latches — MAME seibucop.cpp cop_cmd_w line 1069. rtl/Godzilla/Godzilla_cop3.sv:642 MAME dispatches on raw data after clearing cop_status bit 15. rtl/Godzilla/Godzilla_cop3.sv:696 DMA mode 0x80-0x87: MAME dma_palette_brightness() fa FADE solo con pal_brightness_mode 4/5; con qualsiasi altro valore fa una COPIA SEMPLICE src->dst (ramo else, seibucop_dma.ipp:119-123) verso QUALUNQUE dst — incl. rtl/Godzilla/Godzilla_cop3.sv:704 DMA generici 0x09/0x0E: MAME write_word(dst) va nello spazio host = arriva a QUALSIASI RAM mappata, incluse le BRAM video ($101000-$105FFF: staging tilemap, palette-stage $104000, sprite $105000). rtl/Godzilla/Godzilla_cop3.sv:712 Output del fade/blend 0x8x: MAME dma_palette_brightness fa write_word(dst) nello SPAZIO HOST = raggiunge QUALUNQUE RAM mappata (pal-stage $104000, sprite $105800, Main RAM...). rtl/Godzilla/Godzilla_cop3.sv:715 Ora: pal_val registrato in D_FADE_WRITE e committato in D_FADE_COMMIT via canale fill (decode per dst assoluto in main_top: bg/fg/mg/txt/pal/spr) o mr (dst in Main RAM) — 1:1 MAME. rtl/Godzilla/Godzilla_cop3.sv:718 (Il vecchio dma80_to_spr era INVERTITO: il blit pietre e' src=$105800 dst=$104000, non il contrario — MAME map: $100478=SRC, $10047C=DST.) rtl/Godzilla/Godzilla_cop3.sv:721 LEGACY sprite-DMA state (MAME m_sprite_dma_rel_x/y, m_sprite_dma_x_clip) rtl/Godzilla/Godzilla_cop3.sv:824 MAME cop_cmd_w (seibucop.cpp:1075): rtl/Godzilla/Godzilla_cop3.sv:858 find_trigger_match (seibucop.cpp:464) Cerca slot N tale che (trigger & 0xf800) == (cop_func_trigger[N] & 0xf800) && cop_func_trigger[N] != 0. rtl/Godzilla/Godzilla_cop3.sv:860 Restituisce canonical trigger value del slot (NB: MAME LEGACY_cop_cmd_w usa il match slot per dispatchare; in pratica equivale a restituire cop_func_trigger[slot]). rtl/Godzilla/Godzilla_cop3.sv:881 fade_table — MAME seibucop.cpp:733 (reverse engineered from Seibu Cup Soccer bootleg) v = pal_channel(5-bit) \| (brightness_val_xor_X) [10-bit input] low = v & 0x1F high = v & 0x3E0 return (low * (high \| (high>>5)) + 0x210) >> 10 [8-bit o rtl/Godzilla/Godzilla_cop3.sv:920 ── Hitbox b100/b900 scratch (MAME cop_collision_update_hitbox) ────────────── dx[i] = int8 (signed) byte basso, size[i] = uint8 (unsigned) byte alto del word descrittore @ hitadr2+2i. 3 assi (Y,X,Z) per Godzilla. rtl/Godzilla/Godzilla_cop3.sv:927 num_axis: MAME seibucop.cpp:1010 "if (data & 0x100) num_axis = 3" else 2. rtl/Godzilla/Godzilla_cop3.sv:929 res init 7 vs 3 (seibucop.cpp:1038-39). rtl/Godzilla/Godzilla_cop3.sv:956 Con 16-bit frac + 24 iter + z>>16: 0 divergenze di decisione vs MAME int(atan(dx/dy)128/pi) su ~640k casi (dimostrato numericamente). rtl/Godzilla/Godzilla_cop3.sv:1199 MAME cop_dma_trigger_w: NON modifica cop_status (vedi seibucop.cpp:741). rtl/Godzilla/Godzilla_cop3.sv:1207 MAME dma_tilemap_buffer: copy staging RAM → renderer BRAM src = cop_dma_src[mode] << 6 (byte addr 0x101000+ = staging) dst = i (loop counter 0..0x13FF = renderer index) count = 0x2800/2 = 5120 words rtl/Godzilla/Godzilla_cop3.sv:1217 MAME dma_palette_buffer: copy staging palette → renderer src = cop_dma_src[mode] << 6 (0x104000 = palette staging) dst = i (loop counter 0..0x7FF = renderer index) count = 0x1000/2 = 2048 words rtl/Godzilla/Godzilla_cop3.sv:1227 MAME write_word(dst) su spazio host: con dst nelle BRAM video ($101000-$105FFF: staging/pal/spr, es. rtl/Godzilla/Godzilla_cop3.sv:1240 simplified, MAME size>>1 rtl/Godzilla/Godzilla_cop3.sv:1245 MAME seibucop_dma.ipp dma_palette_brightness() mode 5/4. rtl/Godzilla/Godzilla_cop3.sv:1248 MAME formulas: src = cop_dma_src[mode] << 6 dst = cop_dma_dst[mode] << 6 size = ((cop_dma_size << 5) - (cop_dma_dst << 6) + $20)/2 Init: src=$106000, dst=$104000, size=($827F<<5 - $4100<<6 + $20)/2 = ($104FE0 - $104000 + $20)/2 = $1000 rtl/Godzilla/Godzilla_cop3.sv:1259 MAME size = (((size<<5) - (dst<<6) + 0x20)/2) rtl/Godzilla/Godzilla_cop3.sv:1265 MAME: mode 4/5 = fade palette; QUALSIASI ALTRO = copia semplice src->dst (seibucop_dma.ipp:119-123). rtl/Godzilla/Godzilla_cop3.sv:1275 MAME seibucop.cpp cop_dma_trigger_w case 0x116 — GODZILLA: fill come 0x118 ma SENZA guard dst!=0 e length bytes = (size+1)<<4 (metà). rtl/Godzilla/Godzilla_cop3.sv:1277 legionna.cpp:56-61: "The COP-MCU appears to write to the work ram area, otherwise it RESETS in mid-animation of the title screen" → senza questo fill il gioco torna al logo da solo. rtl/Godzilla/Godzilla_cop3.sv:1288 Skip if dst != 0 (MAME guard, dma.ipp:135) rtl/Godzilla/Godzilla_cop3.sv:1301 MAME cop_cmd_w (seibucop.cpp:1073): cop_status &= 0x7fff (clear bit 15). rtl/Godzilla/Godzilla_cop3.sv:1303 MAME: cop_status &= 0x7fff (clear bit 15). rtl/Godzilla/Godzilla_cop3.sv:1318 MAME LEGACY_cop_cmd_w: find_trigger_match(data, 0xF800) → slot per GRUPPO f800, poi handler dal microcodice caricato. rtl/Godzilla/Godzilla_cop3.sv:1344 MAME execute_0205: read dword at cop_regs[0]+4+offset4 (ppos) rtl/Godzilla/Godzilla_cop3.sv:1365 0x138e / 0x338e — atan(dx/dy) MAME execute_338e. rtl/Godzilla/Godzilla_cop3.sv:1367 Parte da r1+4 hi (offset 0x0004), come 3BB0/MAME. rtl/Godzilla/Godzilla_cop3.sv:1375 r1+4 hi (MAME read_dword(r1+4) primo) rtl/Godzilla/Godzilla_cop3.sv:1390 MAME: raw_angle = cop_read_word(r0+0x34) = host_read_word(0x34^2 = 0x36); amp = cop_read_word(r0+0x36) = host_read_word(0x36^2 = 0x34). rtl/Godzilla/Godzilla_cop3.sv:1407 0xa180 — collision read pos for slot 0 MAME cop_collision_read_pos: cop_read_word(spradr+N) = host_read_word((spradr+N)^2) per host_endian=true. rtl/Godzilla/Godzilla_cop3.sv:1428 b000 NON e' un no-op: il dispatcher LEGACY di godzilla (seibucop.cpp:1365) matcha con mask 0xf800, quindi la patch init_godzilla (b100->b000) ESEGUE comunque l'update ma con num_axis=2 (bit8=0 = Z disattivata). rtl/Godzilla/Godzilla_cop3.sv:1536 Mode 4 (GODZILLA/Denjin, seibucop_dma.ipp:87-117): indice = (val2)[4:0], val 0x0010/0xFFFF = TARGET PURO, NESSUN bypass bit15. rtl/Godzilla/Godzilla_cop3.sv:1583 MAME: m_host_space->write_word(dst, pal_val) — dst ASSOLUTO. rtl/Godzilla/Godzilla_cop3.sv:1617 MAME (0x118 e 0x116): write_dword(i, v1 \| v2<<16) su spazio BE 68k → word a i = v2, word a i+2 = v1 (alternati). rtl/Godzilla/Godzilla_cop3.sv:1630 Macro 0x0205 — linear movement (MAME execute_0205) ppos = read_dword(cop_regs[0]+0x04) vel = read_dword(cop_regs[0]+0x10) npos = ppos + vel write_dword(cop_regs[0]+0x04, npos) delta = (npos>>16) - (ppos>>16) write_word(cop_regs[0]+0x1E, re rtl/Godzilla/Godzilla_cop3.sv:1673 MAME cop_read/write_word(cop_regs[0]+0x1e) = host word @ (0x1e^2)=0x1c (host endianness word^2; conferma doc 06 micro-op 'addmem16 0x1C(r0)'). rtl/Godzilla/Godzilla_cop3.sv:1691 Macro 0x0905/0x0904 — jump (MAME execute_0904) write_dword(cop_regs[0]+0x10, read_dword(cop_regs[0]+0x10) ± read_dword(cop_regs[0]+0x28)) 0x0905 (bit 0=1) = +, 0x0904 (bit 0=0) = - rtl/Godzilla/Godzilla_cop3.sv:1717 MAME execute_0904: bit 0 di data = 1 → add, =0 → sub tmp32_a = vel ± grav. rtl/Godzilla/Godzilla_cop3.sv:1748 0x138E/0x338E atan(dx/dy) — MAME execute_338e (cmd.ipp:159) dx = read_dword(r1+4) - read_dword(r0+4) dy = read_dword(r1+8) - read_dword(r0+8) if(!dy){status\|=0x8000; angle=0} else angle=atan(dx/dy)128/pi; dy<0→+0x80 if(data&0x80) write_byt rtl/Godzilla/Godzilla_cop3.sv:1796 MAME: angle = atan(dx/dy)128/pi (+0x80 se dy<0). rtl/Godzilla/Godzilla_cop3.sv:1798 Cosi' z = atan(dx/dy) e il +0x80 (in WR) copre solo il quadrante, come MAME. rtl/Godzilla/Godzilla_cop3.sv:1800 NIENTE prescale: i dword diff sono FIXED-POINT coord<<16 (come il 3BB0 che usa dx32[31:16] e MAME dx>>16), NON interi piccoli. rtl/Godzilla/Godzilla_cop3.sv:1841 MAME (int)(...) tronca VERSO ZERO. rtl/Godzilla/Godzilla_cop3.sv:1843 BUG TROVATO (validato vs MAME su 29241 casi): il CORDIC SOTTO-CONVERGE di 1 LSB sulle DIAGONALI (es. rtl/Godzilla/Godzilla_cop3.sv:1848 Compenso l'epsilon di sotto-convergenza con +1 toward-zero PRIMA del troncamento: bias=1 azzera tutte le 133 divergenze (bias=0) -> 0/29241 vs MAME. rtl/Godzilla/Godzilla_cop3.sv:1857 MAME execute_338e (seibucop_cmd.ipp:175-188): la write dell'angolo in RAM (obj+0x34 host, gated da data&0x80) e' FUORI dall'if/else di dy -> avviene SEMPRE, anche a dy==0 (dove cop_angle=0 -> scrive 0^0x80 = 0x80). rtl/Godzilla/Godzilla_cop3.sv:1863 Ora calcolo ang_byte in entrambi i rami e scrivo SEMPRE, come MAME. rtl/Godzilla/Godzilla_cop3.sv:1870 Scrivere l'angolo anche a dy==0 ("1:1 MAME") REGREDISCE: il martello scivola/moonwalk. rtl/Godzilla/Godzilla_cop3.sv:1873 MAME: dy==0 -> cop_angle=0 rtl/Godzilla/Godzilla_cop3.sv:1896 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197) dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (aritmetico) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = sqrt(dxdx + dydy) if(data&0x80) write_word(r0 + (data&0x200?0x3a:0x38 rtl/Godzilla/Godzilla_cop3.sv:2005 (Il fix MAME-aligned 0x3a:0x38 faceva fuggire i nemici -> MAME invertito vs HW. rtl/Godzilla/Godzilla_cop3.sv:2012 MAME: macro completata → cop_status = 7 (gate-poll del gioco). rtl/Godzilla/Godzilla_cop3.sv:2098 0x8100/0x8900 sin/cos (MAME execute_8100/8900) raw_angle = cop_read_word(cop_regs[0]+0x34) & 0xff amp = (65536>>5) * (cop_read_word(cop_regs[0]+0x36) & 0xff) = 2048 * amp_byte if (raw_angle == 0xC0 sin / 0x80 cos): amp = 2 res = int( rtl/Godzilla/Godzilla_cop3.sv:2137 MAME special-case: sin && raw==0xC0 OR cos && raw==0x80 → amp = 2 rtl/Godzilla/Godzilla_cop3.sv:2183 0xa180/0xa980 — read pos (MAME cop_collision_read_pos) flags_swap = cop_read_word(spradr+2) → host_read_word(spradr+0) pos[0] = cop_read_word(spradr+6) → host_read_word(spradr+4) pos[1] = cop_read_word(spradr+10) → host_read_word( rtl/Godzilla/Godzilla_cop3.sv:2190 Però MAME cop_read_word(+2) = host_read_word(+2^2) = host_read_word(+0). rtl/Godzilla/Godzilla_cop3.sv:2201 rdata = word @ host+0 = flags (MAME cop_read_word(spradr+2) ^ 2). rtl/Godzilla/Godzilla_cop3.sv:2210 rdata = word @ host+4 = pos[0] (Y axis per MAME) rtl/Godzilla/Godzilla_cop3.sv:2230 0xb100/0xb900 — update hitbox & compute intersection (1:1 MAME cop_collision_update_hitbox, seibucop.cpp:1003-1065). rtl/Godzilla/Godzilla_cop3.sv:2277 2 assi (b000/b800): terza word NON letta, dx/size azzerati (seibucop.cpp:1014-1022) rtl/Godzilla/Godzilla_cop3.sv:2316 2 assi: l'asse 2 (Z) NON viene aggiornato (loop MAME i<num_axis) rtl/Godzilla/Godzilla_cop3.sv:2335 res init: 3 assi = 111, 2 assi = 011 (seibucop.cpp:1038-39: bit Z gia' 0 = "collide banale" -> hit deciso solo da X/Y) rtl/Godzilla/Godzilla_cop3.sv:2359 LEGACY 6880 — carica rel_xy per il prossimo c480 (MAME LEGACY_execute_6980: rel_xy = read_word(spr_src+4+offs)) rtl/Godzilla/Godzilla_cop3.sv:2372 LEGACY c480 — single-step sprite DMA (MAME LEGACY_execute_c480): info = read(spr_src+offs) + (param & 0x3f) -> entry+0 abs = read(regs[0]+8/+4) - spr_dma_abs_x/y X(fx/dx/rel_x) -> entry+4 (+ x_clip per l'inc $410) Y(fy/rel_y) -> entry+6 rtl/Godzilla/Godzilla_cop3.sv:2478 6200 — rotate-towards (MAME execute_6200, variante grainbow che godzilla CARICA nella tabella): angle(obj host+0x37) ruota verso cop_angle_target di cop_angle_step; flags(host+2) bit2=raggiunto. rtl/Godzilla/Godzilla_cop3.sv:2481 Dominio angolo: il nostro 138e scrive in RAM plain^0x80 (is_yflip) -> lavoro nel dominio stored con target^0x80: il DELTA e' rotazione-invariante => matematica IDENTICA a MAME. rtl/Godzilla/Godzilla_cop3.sv:2484 Write angolo = WORD {0,angle} (MAME host_endian write-word). rtl/Godzilla/Godzilla_cop3.sv:2505 wrap a signed 8-bit (MAME: +=/-=256 su int) rtl/Godzilla/Godzilla_main_top.sv:213 VBLANK IRQ4 — MAME legionna.cpp: m_maincpu->set_vblank_int(irq4_line_hold) MAME HOLD_LINE: IRQ asserted on edge, released ONLY at IACK (= when CPU fetches vector). rtl/Godzilla/Godzilla_main_top.sv:218 VBLANK IRQ4 — MAME legionna.cpp: m_maincpu->set_vblank_int(irq4_line_hold) MAME HOLD_LINE: IRQ asserted on edge, released ONLY at IACK (= when CPU fetches vector). rtl/Godzilla/Godzilla_main_top.sv:473 COP3 cmd 0x14 dma_tilemap_buffer (legionna_v.cpp:86 videowrite_cb_w): offset 0x000..0x3FF → BG (back_data) offset 0x400..0x7FF → FG (fore_data) offset 0x800..0xBFF → MG (mid_data) offset 0xC00..0x13FF → Text (textram, 0x800 word) SRC rtl/Godzilla/Godzilla_main_top.sv:497 Il fill scrive le BRAM STAGING (= la host RAM di MAME): il per-frame DMA 0x14/0x15 le propaga al renderer. rtl/Godzilla/Godzilla_main_top.sv:510 ── SPLIT STAGING vs RENDERER (semantica MAME 2-stadi, come la palette) ───── MAME godzilla: $101000-$103FFF e' .ram() PURO (handler background_w/… COMMENTATI nel map, legionna.cpp) — le scritture CPU NON toccano i tilemap. rtl/Godzilla/Godzilla_main_top.sv:513 I tilemap leggono m_back/fore/mid_data/m_textram = buffer SEPARATI (make_unique_clear, legionna_v.cpp) scritti SOLO da videowrite_cb_w = DMA 0x14. rtl/Godzilla/Godzilla_main_top.sv:518 u_XX_ram = STAGING: porta A = CPU (+fill 0x116/0x118, come MAME che filla la host RAM), porta B = sorgente del DMA 0x14. rtl/Godzilla/Godzilla_main_top.sv:521 Coppia contenuto/scroll = atomica a livello ISR, come MAME. rtl/Godzilla/Godzilla_main_top.sv:593 ── Palette: split STAGING ($104000) vs RENDERER (semantica MAME 2-stadi) ─── MAME: la CPU e il fade (cmd 0x80) scrivono la STAGING RAM a $104000. rtl/Godzilla/Godzilla_main_top.sv:617 MAME godzilla: $104000 e' RAM pura (legionna.cpp:262, handler palette commentato) — la palette VISIBILE si aggiorna SOLO via paletteramout_cb = dma_palette_buffer 0x15 (seibucop_dma.ipp:27); il fade DMA scrive lo STAGING (host RAM, dma.ipp: rtl/Godzilla/Godzilla_maincpu_map.sv:23 Main CPU memory map Godzilla (legionna.cpp legionna_map): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $100000-$1003FF RAM scratch (1KB) → BRAM (Main RAM low) $100400-$1006FF COP3 region → m rtl/Godzilla/Godzilla_maincpu_map.sv:129 Text VRAM: $102800-$1037FF = 4KB = 2048 word (MAME common_video_allocate_ptr alloca textram a 0x1000/2 word, videowrite_cb_w smista offset < 0x2800/2). rtl/Godzilla/Godzilla_maincpu_map.sv:139 godzilla_map (legionna.cpp:257): 0x100800-0x100FFF .ram() — SOLO godzilla, legionna non ce l'ha (buco ereditato dal porting). rtl/Godzilla/Godzilla_maincpu_map.sv:215 MAME legionna_map: main_r/main_w(offset>>1) con umask16(0x00ff). rtl/Godzilla/Godzilla_maincpu_map.sv:219 Vedi seibusound.cpp main_r/main_w. rtl/Godzilla/Godzilla_maincpu_map.sv:226 MAME godzilla_setgfxbank: (data&0x4000)>>2 rtl/Godzilla/Godzilla_maincpu_map.sv:267 ─── init_godzilla (legionna.cpp:2624-2634) ───────────────── Kludge Z-axis collisioni (seibucop.cpp:52-54: "Super X missiles, Tokyo's tower ... rtl/Godzilla/Godzilla_maincpu_map.sv:322 Replica la latenza-zero-osservabile di MAME (cop_cmd_w sincrono): il gioco legge cop_hit_val_stat/cop_angle ($188/$1b4) nell'istruzione dopo il trigger. rtl/Godzilla/Godzilla_palette.sv:25 MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 12816); (legionna.cpp:1212, 12816 = 2048 entry) Address space CPU: 0x104000..0x104FFF (4 KB = 2048 word). rtl/Godzilla/Godzilla_palette.sv:35 Espansione 5→8 standard MAME palette_device: {val5, val5[4:2]} (bit replication che riempie i 3 LSB con i 3 MSB del valore 5-bit). rtl/Godzilla/Godzilla_palette.sv:85 Godzilla: xBGR_555 → RGB888 (legionna.cpp:1212) Layout: bit[4:0]=R, bit[9:5]=G, bit[14:10]=B. 5 bit per canale. rtl/Godzilla/Godzilla_palette.sv:87 Espansione 5→8 standard MAME palette_device: {val5, val5[4:2]} (replica i 3 MSB nei 3 LSB → range 0..255 con monotonia preservata). rtl/Godzilla/Godzilla_seibu_crtc.sv:23 Seibu CRTC fedele a MAME (seibu_crtc.cpp). rtl/Godzilla/Godzilla_seibu_crtc.sv:120 MAME mappa: bit0=screen0(BG), bit1=screen2(MG), bit2=screen1(FG), bit3=screen3(Text) (vedi seibu_crtc.cpp commento "screen 0=BG, screen 1=FG, screen 2=MG, screen 3=Text") In SD Gundam dcon.cpp layer_en_w gira la maschera così: ~layer_en bit rtl/Godzilla/Godzilla_seibu_crtc.sv:129 Il dispatcher MAME usa "if (BIT(~m_layer_en, n))" per saltare = layer disabilitato quando il bit è 1. rtl/Godzilla/Godzilla_seibu_crtc.sv:134 Godzilla layer ordering (legionna_v.cpp:384-390 screen_update_GODZILLA): bit 0 = BG (background) bit 1 = MG (midground) bit 2 = FG (foreground) bit 3 = Text bit 4 = Sprites ATTENZIONE: e' l'OPPOSTO di legionna (screen_update_legionna :342-3 rtl/Godzilla/Godzilla_seibu_crtc.sv:155 Scroll-base Screen3(text) Y = reg 0x3A (blocco layer_scroll_base 0x2C-0x3B, offset word 7 — MAME seibu_crtc.cpp:243 + legionna_v.cpp:58-65 godzilla-only: text set_scrolldy(0x1ef - data). rtl/Godzilla/Godzilla_sprite_renderer.sv:25 Formato spriteram quasi identico (entrambi MAME sei021x_sei0220_spr.cpp) — differenze: - Spriteram @ 0x105000-0x105FFF (4KB, 1024 word, 256 entry × 4 word) - w3 bit 15 = tile bank extra bit (denjinmk usa, Godzilla base = 0) rtl/Godzilla/Godzilla_sprite_renderer.sv:30 Format word (legionna_v.cpp:288-312): w0 bit 15 = enable (0=draw, 1=skip — TODO verify Godzilla) w0 bit 14 = flip_x w0 bit 13 = flip_y (??? rtl/Godzilla/Godzilla_sprite_renderer.sv:46 Priority callback legionna_v.cpp:314-317: pri_mask[0] = 0x0000 (sopra tutto) pri_mask[1] = 0xFFF0 pri_mask[2] = 0xFFFC pri_mask[3] = 0xFFFE rtl/Godzilla/Godzilla_sprite_renderer.sv:140 0..511 (MAME size/2/4 = 4096/2/4 = 512) rtl/Godzilla/Godzilla_sprite_renderer.sv:145 Decoded fields — MAME sei0210_device::draw (non-alt format, riga 143): if (BIT(~spriteram[i], 15)) continue; → draw quando w0[15]==1. rtl/Godzilla/Godzilla_sprite_renderer.sv:165 MAME SEI0211 default m_xoffset/m_yoffset = 0 (sei021x_sei0220_spr.cpp:40-41). rtl/Godzilla/Godzilla_sprite_renderer.sv:166 Godzilla NON chiama set_offset (legionna.cpp:1214) → offset 0,0. rtl/Godzilla/Godzilla_sprite_renderer.sv:198 Tile code finale Y-MAJOR (MAME draw_internal: ax=outer, ay=inner, code++): sub_index = axsizey + ay → cur_tile = code + eff_tile_xsp_h + eff_tile_y Banking godzilla_tile_cb (legionna_v.cpp:327-334): ext→\|0x4000, y→\|0x8000, applicato PRI rtl/Godzilla/Godzilla_sprite_renderer.sv:538 MAME gfx_legionna_spr: color base = 6416 = 0x400 (64 colorset × 16 pen). rtl/Godzilla/Godzilla_text_renderer.sv:25 Specifiche da MAME (legionna.cpp:1117-1126, 1167): rtl/Godzilla/Godzilla_text_renderer.sv:47 Char ROM in MAME: "char" region 64KB = ROM_COPY user1[0x10000..0x1FFFF]. rtl/Godzilla/Godzilla_text_renderer.sv:140 MAME `legionna_v.cpp:214`: text tilemap = 64×32 (8x8 tiles, TILEMAP_SCAN_ROWS). rtl/Godzilla/Godzilla_text_renderer.sv:186 --- Stage 3: pen decode (charlayout planes packed in nibbles) --- Per col c (0..3 dentro la half-tile), bit position = 3 - c. pen[0] = word[bit_pos + 0] (plane 0) pen[1] = word[bit_pos + 4] (plane 1) pen[2] = word[bit_pos + 8] (plane rtl/Godzilla/Godzilla_text_renderer.sv:192 MAME readbit usa MSB-first: bit_offs N → byte[N/8] bit (7-N%8). rtl/Godzilla/Godzilla_text_renderer.sv:193 In Verilog word concat (lo=byte0[7:0], hi=byte1[7:0]) → MAME pos N = word[(7-N%8) + (N>=8?8:0)]. rtl/Godzilla/Godzilla_text_renderer.sv:210 MAME GFXDECODE char: color base = 4816 = 0x300 (16 colorset × 16 pen). rtl/Godzilla/Godzilla_tile_layer.sv:25 Differenze fra layer (da MAME dcon.cpp): rtl/Godzilla/Godzilla_tile_layer.sv:58 BB FG hardcoded +0x1000 (MAME bloodbro fg_tile_info) rtl/Godzilla/Godzilla_tile_layer.sv:221 Tile index con eventuale gfx_bank (MG ha bit 12 = 13-bit totali, BG/FG = 12 bit) + TILE_CODE_OFS hardcoded (BB FG aggiunge 0x1000 secondo MAME bloodbro fg_tile_info). rtl/Godzilla/Godzilla_video_timing.sv:35 Active area da MAME (sdgndmps_map): visarea 0..408-1, 28..308-1 quindi 320×224, V offset = 16 (top blank). rtl/Godzilla/Godzilla_video_timing.sv:60 ── Pixel clock enable: 96 MHz / 14 = 6.857 MHz ───────────────────────── Godzilla reale (legionna.cpp:1318 set_raw): pclk 14.318180/2 = 7.15909 MHz. rtl/Godzilla/Godzilla_video_timing.sv:78 ── Constants timing ───────────────────────────────────────────────────── Godzilla REALE (legionna.cpp:1318): set_raw(14318180/2, 455, 0, 320, 258, 0, 224) = 320x224, HTotal 455 @7.159MHz = 15.734 kHz, VTotal 258 → 60.985 Hz. rtl/Godzilla/sdram_bridge.sv:308 --- FG address descramble (legionna.cpp:1129 descramble_legionnaire_gfx) --- MAME applica un bitswap<24> agli indirizzi della ROM "fore" durante init: src_descrambled[i] = src_raw[bitswap<24>(i, ... rtl/Godzilla/sdram_bridge.sv:355 bitswap MAME del byte offset README.md:6 Godzilla is a licensed Toho kaiju action game running on the Seibu `legionna.cpp` hardware family* — an M68000 board with a Seibu CRTC, the SEI252 sprite chi README.md:12 This core reimplements the hardware in SystemVerilog from MAME references (`seibu/legionna.cpp`, `seibu/legionna_v.cpp`, `seibu/seibu_crtc.cpp`, `seibu/seibucop Says it matches, follows or was checked against MAME — 6 Godzilla.sv:222 -1 = sprite 1px a OVEST (sinistra), match MAME su HW Godzilla.sv:252 NB: gli offset per-layer (ex P5) sono HARDCODATI (osd__xoff/yoff costanti, match pixel-perfect MAME). rtl/Godzilla/Godzilla_cop3.sv:1313 LEGACY sprite-DMA (match a maschera, MAME find_trigger_match): c480 mask $FF00 -> qualunque c4xx; 6880 mask $FFF3. rtl/Godzilla/Godzilla_cop3.sv:2152 res = prod >> 4 (= /16 per matchare formula MAME 2048/32768 = 1/16) rtl/Godzilla/Godzilla_sprite_renderer.sv:167 +1 pixel a destra: offset verificato con pixel hunting su MAME (rmonic79). rtl/Godzilla/Godzilla_sprite_renderer.sv:333 Scan INVERSO 511→0 (verificato su HW: ordine sprite-su-sprite opposto al loop MAME 0→511). Says it was translated, ported or taken from MAME — 2 rtl/Godzilla/Godzilla_cop3.sv:1904 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197): 1:1 dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (signed) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = floor(sqrt(dxdx + dydy)) if(data&0x80) write_word(r0+(data&0x200?0x3 rtl/Godzilla/Godzilla_cop3.sv:2021 0x42C2/0x4AA0 divide — MAME execute_42c2/4aa0 (cmd.ipp:219/247): 1:1 DIVIDEND = cop_dist << (5 - cop_scale) (cop_scale 0..3 → shift 5..2) 42c2: div=cop_read_word(r0+0x36)→host 0x34; if(!div){status\|=0x8000; write 0 a host 0x3a} else write Shares text with the MAME driver without saying so — 10 Godzilla.sv:817 HAS_TRANSP=1 perché m_background_layer->set_transparent_pen(15) in — shares text with seibu/legionna_v.cpp:216 Godzilla.sv:840 get_mid_tile_info_share_bgrom (legionna_v.cpp:158): MG share BG ROM, — shares text with seibu/legionna.h:80 rtl/Godzilla/Godzilla_audio_z80.sv:424 godzilla_oki_bank_w: m_oki->set_rom_bank(data & 1) (write tipica 0x02/0x03). — shares text with seibu/legionna.cpp:277 rtl/Godzilla/Godzilla_maincpu_map.sv:269 Tokyo's tower ... Z axis check makes no sense"): le 2 call-site — shares text with seibu/seibucop.cpp:54 rtl/Godzilla/Godzilla_palette.sv:23 Palette RAM Seibu Godzilla (xBGR_555, 2048 entries). MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 12816); (legionna.cpp — shares text with seibu/legionna.cpp:1212 rtl/Godzilla/Godzilla_sprite_renderer.sv:146 if (BIT(~spriteram[i], 15)) continue; → draw quando w0[15]==1. — shares text with seibu/sei021x_sei0220_spr.cpp:128 rtl/Godzilla/Godzilla_text_renderer.sv:23 Text layer renderer Seibu Godzilla (8x8, 4bpp, 64x32). Specifiche da MAME (legionna.cpp:1117-1126, 1167): // charlayout 8x8, RGN_FRAC(1,1), 4 — shares text with seibu/legionna.cpp rtl/Godzilla/Godzilla_video_timing.sv:23 Video timing single-screen Seibu D-Con. SD Gundam Psycho Salamander gira su Seibu D-Con (PB91008), stessa famiglia di Blood Bros (1990). PCB measuremen — shares text with seibu/legionna.cpp rtl/Godzilla/Godzilla_video_timing.sv:79 Godzilla REALE (legionna.cpp:1318): set_raw(14318180/2, 455, 0, — shares text with seibu/legionna.cpp:1318 rtl/Godzilla/sdram_bridge.sv:310 src_descrambled[i] = src_raw[bitswap<24>(i, ... 6,5,15,14,13,12, 11,10,9,8, 7,4, 3..0)] — shares text with seibu/legionna.cpp:1141
Guardians# Guardians / Denjin Makai II MiSTer-devel/Arcade-Guardians_MiSTer @ 68eaafee (matched by date) MAME compared: seta/seta2.cpp Read: 23 HDL files, 6,682 lines (Quartus project)	MiSTer official	Mostly MAME	low	39%
Statements: 9 toward MAME Cites MAME source — 7 rtl/gd_cpu_subsystem.sv:351 MAME bit order: left, right, up, down, B1, B2, B3, start. rtl/gd_dx101_video.sv:7 Format and drawing rules are derived from MAME's BSD-licensed device model by Luca Elia and David Haywood. rtl/gd_dx101_video.sv:709 MAME's STEP8(0,1) plane offsets and STEP8(7*8,-8) X offsets mean that source byte 7 supplies pen bit 7, byte 6 supplies bit 6, ... rtl/gd_tmp68301.sv:2 Behaviour follows MAME's BSD-licensed TMP68301 device model. rtl/gd_tmp68301.sv:165 The MAME device treats an asserted input as the active state for level mode and its rising transition as the event for edge mode. rtl/gd_video_timing.sv:22 MAME deliberately substitutes 512x256 at exactly 60 Hz; use the programmed board timing here for correct native analog RGB: approximately 15.244 kHz horizontal and 59.085 Hz vertical. rtl/gd_x1_010.sv:2 Register layout, rate and phase arithmetic follow MAME's BSD-licensed x1_010 device model. Says it matches, follows or was checked against MAME — 2 rtl/gd_sprite_ram.sv:117 Bound the private table and synthesize one in its last slot, matching the finite hardware/MAME scan. rtl/gd_x1_010.sv:87 A factor of two gives the hardware mix headroom and matches MAME closely without a large divider.
GulfWarII# Gulf War II MiSTer-devel/Arcade-GulfWarII_MiSTer @ 5b12749a MAME compared: toaplan/twincobr.cpp + 8 related file(s) Read: 20 HDL files, 5,167 lines (Quartus project)	MiSTer official	Mostly MAME	low	54%
Statements: 1 toward hardware, 12 toward MAME Cites hardware documentation that MAME's driver does not — 1 Arcade-GulfWarII.sv:694 from outzone schematic Cites MAME source — 8 Arcade-GulfWarII.sv:442 total 446, ~54.9 Hz native/MAME raster Arcade-GulfWarII.sv:501 MAME only inverts Gulf War II's readable VBLANK input bit. Arcade-GulfWarII.sv:1439 MAME flips only the tilemaps from the main latch. Arcade-GulfWarII.sv:1528 SCU sprite RAM writes use the MAME 0x040000-0x040fff map. Arcade-GulfWarII.sv:1683 MAME's tilemap core positions maps at dx-scroll/dy-scroll, so sampling Arcade-GulfWarII.sv:1724 MAME's Toaplan SCU consumes sprite RAM as native 16-bit words. rtl/gulfwar2/gulfwar2_palette_ram.sv:59 MAME models this RAM as xBGR_555: bit 15 unused, then B/G/R. README.md:26 Behavioral reference: MAME's Toaplan driver behavior for Gulf War II, `toaplan_dsp.cpp`, and shared Toaplan video devices. Says it matches, follows or was checked against MAME — 2 Arcade-GulfWarII.sv:1457 Match MAME's toaplan_dsp_device: DSP INT enable unhalts the DSP and halts the 68K; disable halts the DSP but does not itself release the 68K. README.md:6 IT HAS BEEN EXTENSIVELY TESTED AND MATCHED TO MAME BEHAVIOR (TO THE BEST OF MY ABILITY) Says it was translated, ported or taken from MAME — 2 README.md:5 THIS IS A VIBE CODED CORE BASED ON MAME AND ERIN OLAFSON'S [EXCELLENT TOAPLAN MiSTer FRAMEWORK](https://github.com/va7deo/). README.md:28 ROM definitions and MRAs: based on MAME 0.287 set definitions.
Gyruss# Gyruss MiSTer-devel/Arcade-Gyruss_MiSTer @ 50646883 MAME compared: konami/gyruss.cpp + 3 related file(s) Read: 16 HDL files, 8,213 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	9%
Statements: 1 toward hardware Cites hardware documentation that MAME's driver does not — 1 rtl/Gyruss_SND.sv:563 Two of Gyruss's AY-3-8910s contain selectable low-pass filters with the following cutoff frequencies: 3386.28Hz, 723.43Hz, 596.09Hz Model this here (the PCB handles this via 3 74HC4066 switching ICs located at 9E, 9F and 10F)
HeatedBarrel# Heated Barrel MiSTer-devel/Arcade-HeatedBarrel_MiSTer @ 6a878e4f MAME compared: seibu/legionna.cpp + 8 related file(s) Read: 23 HDL files, 9,301 lines (Quartus project)	MiSTer official	Mostly MAME	medium	74%
Statements: 4 toward hardware, 153 toward MAME, 1 not counted Cites hardware references or measurements that MAME's driver also gives — 1 rtl/HeatedBarrel/HeatedBarrel_maincpu_map.sv:23 Main CPU memory map HeatedBarrel (MAME legionna.cpp legionna_map): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $100000-$1003FF RAM scratch (1KB) → BRAM (Main RAM low) $100400-$1006FF COP3 region — also in MAME: 68K seibu/legionna.cpp:46 Reports a measurement taken on the original PCB — 1 rtl/HeatedBarrel/HeatedBarrel_video_timing.sv:25 PCB measurement: VSync 59.4094 Hz, HSync 15.6246 kHz. Says it was checked on “real hardware” — 3 rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:208 byte_lo = pf_rom_data[31:24]/[15:8], byte_hi = [23:16]/[7:0] Plane order DCBA (verificato su HW, come BG/MG/FG): pen[0] dal bit "D" (byte_hi[3-sub]), pen[3] dal bit "A" (byte_lo[7-sub]). rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:325 Scan INVERSO 511→0 (verificato su HW: ordine sprite-su-sprite opposto al loop MAME 0→511). rtl/HeatedBarrel/HeatedBarrel_tile_layer.sv:297 Plane order verificato su HW: BG/MG = DCBA (PEN_ORDER=0), FG = BADC (PEN_ORDER=1). Cites MAME source — 138 HeatedBarrel.sv:218 SPR X=0 Y=-16 TXT X=-1 Y=+16 ── OFFSET PER-LAYER esposti nell'OSD (calibrazione 1:1 con MAME) ────────────── Azzerati gli hardcoded di Legionnaire/224. HeatedBarrel.sv:221 Calibrare uno a uno confrontando con MAME, Offset per-layer HARDCODATI (calibrati su HW confronto MAME, pagina OSD Calibration rimossa). HeatedBarrel.sv:337 --- Joystick input mapping --- MAME P1_P2 port ($E0002): active low. HeatedBarrel.sv:340 MiSTer joy bits: joy[0]=R, joy[1]=L, joy[2]=D, joy[3]=U, joy[4]=A, joy[5]=B. MAME PLAYERS12 (legionna.cpp:439-444): bit[0]=UP, [1]=DOWN, [2]=LEFT, [3]=RIGHT, [4]=BTN1, [5]=BTN2, [6]=BTN3, [7]=unused (active low). HeatedBarrel.sv:345 Corretto invertendo i 4 bit.) bit6/7 = UNKNOWN in MAME PLAYERS12 heatbrl -> tied 1 (no input fantasma; joy[6] attivo metterebbe bit6=0 = "premuto" -> trigger display DIP al power-on). HeatedBarrel.sv:357 Heated Barrel SYSTEM port ($10074C) — MAME heatbrl (4 player): bit0=START1, bit1=START2, bit3=COIN3, bit4=START3, bit5=START4, bit7=COIN4 (active LOW) HeatedBarrel.sv:702 ── Flip screen (CRTC reg 0x1A bit 0) ─────────────────────────────────────── MAME: BIT(reg_1a, 0) → flip_screen. HeatedBarrel.sv:747 Blood Bros Text: no scroll (MAME bloodbro.cpp non chiama set_scroll su tx_tilemap) HeatedBarrel.sv:781 HeatedBarrel CRTC scroll passthrough (MAME legionna_v.cpp:34-49 tile_scroll_w): scroll_ram[0/1] → BG (m_background_layer) scroll_ram[2/3] → MG (m_midground_layer) scroll_ram[4/5] → FG (m_foreground_layer) Nel nostro CRTC: xscroll_l0 = ram[0 HeatedBarrel.sv:799 HeatedBarrel BG: tilemap 32x32 (legionna_v.cpp:204). HeatedBarrel.sv:800 MAME GFXDECODE "back" color base = 0 (gfx_legionna riga 1168), 32 colorset. HeatedBarrel.sv:801 HAS_TRANSP=1 perché m_background_layer->set_transparent_pen(15) in legionna_v.cpp:216 (pen 15 = trasparente, NON opaco come Blood Bros). HeatedBarrel.sv:824 MAME gfx_heatbrl: "mid" ha ROM INDIPENDENTE (get_mid_tile_info_split): tile = (vram & 0xfff) [offset 0, NO +0x1000], color = (vram >> 12) & 0xf. HeatedBarrel.sv:848 HeatedBarrel FG: tilemap 32x32 (legionna_v.cpp:213). HeatedBarrel.sv:850 MAME GFXDECODE "fore" color base = 3216 = 0x200, 16 colorset. HeatedBarrel.sv:864 HeatedBarrel: bit 2 = FG (MAME legionna_v.cpp:344) HeatedBarrel.sv:973 MAME riferimenti: legionna_v.cpp:226-229 m_sprite_pri_mask[0..3] per HeatedBarrel: pri=0 → 0x0000 (cover bit 0,1,2,4 → mg,bg,fg,text → SOPRA TUTTO) pri=1 → 0xFFF0 (cover bit 0,1,2 → mg,bg,fg → sotto text) pri=2 → 0xFFFC (cover bit 0,1 → HeatedBarrel.sv:994 pen 0 (= nero su palette MAME BLACK init) HeatedBarrel.sv:1000 MAME legionna_v.cpp:340 fills bitmap with m_palette->black_pen() before drawing layers. HeatedBarrel.sv:1022 MAME legionna_v.cpp:340 fa bitmap.fill(black_pen()) prima dei layer. rtl/HeatedBarrel/HeatedBarrel_audio_z80.sv:25 Spec da MAME (reference/mame_seibu/seibusound.cpp + bloodbro.cpp): - Z80 @ 3.579545 MHz (XTAL 7.159090 / 2) - YM3812 (jtopl2) @ 3.579545 MHz - OKI M6295 (jt6295) @ 1.000 MHz (XTAL 12/12), PIN7=HIGH rtl/HeatedBarrel/HeatedBarrel_audio_z80.sv:31 Main↔sub comm @ 0xA0000-0xA000D: standard MAME seibu_sound_device. rtl/HeatedBarrel/HeatedBarrel_audio_z80.sv:359 MAME seibu_sound_device::main_r (reference/mame_seibu/seibusound.cpp:279): case 2,3: return sub2main[offset-2] (soundlatch data: coin/input dal Z80) case 5: return main2sub_pending ? rtl/HeatedBarrel/HeatedBarrel_audio_z80.sv:392 ─── OKI M6295 (jt6295) — PIN7_HIGH (bloodbro.cpp:872) ────────────────── rtl/HeatedBarrel/HeatedBarrel_cop3.sv:4 MAME-faithful implementation of the Seibu SEI300 chip as used by the `legionna` driver (HeatedBarrel 1992 — Banpresto/TAD). rtl/HeatedBarrel/HeatedBarrel_cop3.sv:7 Reference (in this repo): reference/mame_seibu/seibucop.cpp reference/mame_seibu/seibucop_cmd.ipp reference/mame_seibu/seibucop_dma.ipp reference/mame_seibu/legionna.cpp rtl/HeatedBarrel/HeatedBarrel_cop3.sv:134 MAME cop_itoa_digits[10]: BCD digits of cop_itoa (low<<0 \| high<<16). rtl/HeatedBarrel/HeatedBarrel_cop3.sv:144 MAME cop_program command table (seibucop.cpp lines 318-457) At boot, game code uploads 32 macro slots × 8 micro-op words via pgm_addr (0x100434) → slot8 + sub-index pgm_data (0x100432) → micro-op word pgm_value (0x100438) → cop_func_valu rtl/HeatedBarrel/HeatedBarrel_cop3.sv:151 MAME calls find_trigger_match(triggerval, 0xff00) to find the slot whose cop_func_trigger matches. rtl/HeatedBarrel/HeatedBarrel_cop3.sv:215 Triggers (write-only addresses) MAME legionna.cpp:172 maps cop_cmd_w to $100500-$100505 (3 words). rtl/HeatedBarrel/HeatedBarrel_cop3.sv:289 0x100410 sprite_dma_inc (MAME seibucop.cpp:1279): if x_clip in [-160, 320): cop_regs[4] += 8 cop_sprite_dma_src += 6; cop_sprite_dma_size--; cop_status bit 1 = (size > 0) ? rtl/HeatedBarrel/HeatedBarrel_cop3.sv:292 0 : 1 (Sprite DMA x_clip non implementato: assumiamo in-range come MAME default per HeatedBarrel — il game non usa sprite DMA via COP comunque) rtl/HeatedBarrel/HeatedBarrel_cop3.sv:330 Macro program upload — MAME seibucop.cpp lines 318-457 pgm_data writes one micro-op word to cop_program[latch_addr] AND latches the slot's trigger/value/mask from current latch regs. rtl/HeatedBarrel/HeatedBarrel_cop3.sv:429 itoa_digits (MAME 0x100590-99, 5 word). rtl/HeatedBarrel/HeatedBarrel_cop3.sv:441 Status / dist / angle (MAME seibucop.cpp:916 cop_status_r → cop_status) rtl/HeatedBarrel/HeatedBarrel_cop3.sv:452 MAME open bus rtl/HeatedBarrel/HeatedBarrel_cop3.sv:565 Trigger latches — MAME seibucop.cpp cop_cmd_w line 1069. rtl/HeatedBarrel/HeatedBarrel_cop3.sv:566 MAME dispatches on raw data after clearing cop_status bit 15. rtl/HeatedBarrel/HeatedBarrel_cop3.sv:605 MAME converte itoa ISTANTANEO (seibucop.cpp:858). rtl/HeatedBarrel/HeatedBarrel_cop3.sv:713 MAME cop_cmd_w (seibucop.cpp:1075): rtl/HeatedBarrel/HeatedBarrel_cop3.sv:749 Restituisce canonical trigger value del slot (NB: MAME LEGACY_cop_cmd_w usa il match slot per dispatchare; in pratica equivale a restituire cop_func_trigger[slot]). rtl/HeatedBarrel/HeatedBarrel_cop3.sv:770 fade_table — MAME seibucop.cpp:733 (reverse engineered from Seibu Cup Soccer bootleg) v = pal_channel(5-bit) \| (brightness_val_xor_X) [10-bit input] low = v & 0x1F high = v & 0x3E0 return (low * (high \| (high>>5)) + 0x210) >> 10 [8-bit o rtl/HeatedBarrel/HeatedBarrel_cop3.sv:807 ── Hitbox b100/b900 scratch (MAME cop_collision_update_hitbox) ────────────── dx[i] = int8 (signed) byte basso, size[i] = uint8 (unsigned) byte alto del word descrittore @ hitadr2+2i. 3 assi (Y,X,Z) per HeatedBarrel. rtl/HeatedBarrel/HeatedBarrel_cop3.sv:815 MAME: res init = (3axis ? rtl/HeatedBarrel/HeatedBarrel_cop3.sv:842 Con 16-bit frac + 24 iter + z>>16: 0 divergenze di decisione vs MAME int(atan(dx/dy)128/pi) su ~640k casi (dimostrato numericamente). rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1074 MAME cop_dma_trigger_w: NON modifica cop_status (vedi seibucop.cpp:741). rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1080 MAME dma_tilemap_buffer: copy staging RAM → renderer BRAM src = cop_dma_src[mode] << 6 (byte addr 0x101000+ = staging) dst = i (loop counter 0..0x13FF = renderer index) count = 0x2800/2 = 5120 words rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1090 MAME dma_palette_buffer: copy staging palette → renderer src = cop_dma_src[mode] << 6 (0x104000 = palette staging) dst = i (loop counter 0..0x7FF = renderer index) count = 0x1000/2 = 2048 words rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1106 simplified, MAME size>>1 rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1111 MAME seibucop_dma.ipp dma_palette_brightness() mode 5/4. rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1114 MAME formulas: src = cop_dma_src[mode] << 6 dst = cop_dma_dst[mode] << 6 size = ((cop_dma_size << 5) - (cop_dma_dst << 6) + $20)/2 Init: src=$106000, dst=$104000, size=($827F<<5 - $4100<<6 + $20)/2 = ($104FE0 - $104000 + $20)/2 = $1000 rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1125 MAME size = (((size<<5) - (dst<<6) + 0x20)/2) rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1135 Skip if dst != 0 (MAME guard, dma.ipp:135) rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1149 MAME cop_cmd_w (seibucop.cpp:1073): cop_status &= 0x7fff (clear bit 15). rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1151 MAME: cop_status &= 0x7fff (clear bit 15). rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1170 MAME execute_0205: read dword at cop_regs[0]+4+offset4 (ppos) rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1191 0x138e / 0x338e — atan(dx/dy) MAME execute_338e. rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1193 Parte da r1+4 hi (offset 0x0004), come 3BB0/MAME. rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1201 r1+4 hi (MAME read_dword(r1+4) primo) rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1216 MAME: raw_angle = cop_read_word(r0+0x34) = host_read_word(0x34^2 = 0x36); amp = cop_read_word(r0+0x36) = host_read_word(0x36^2 = 0x34). rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1404 Macro 0x0205 — linear movement (MAME execute_0205) ppos = read_dword(cop_regs[0]+0x04) vel = read_dword(cop_regs[0]+0x10) npos = ppos + vel write_dword(cop_regs[0]+0x04, npos) delta = (npos>>16) - (ppos>>16) write_word(cop_regs[0]+0x1E, re rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1447 MAME cop_read/write_word(cop_regs[0]+0x1e) = host word @ (0x1e^2)=0x1c (host endianness word^2; conferma doc 06 micro-op 'addmem16 0x1C(r0)'). rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1465 Macro 0x0905/0x0904 — jump (MAME execute_0904) write_dword(cop_regs[0]+0x10, read_dword(cop_regs[0]+0x10) ± read_dword(cop_regs[0]+0x28)) 0x0905 (bit 0=1) = +, 0x0904 (bit 0=0) = - rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1491 MAME execute_0904: bit 0 di data = 1 → add, =0 → sub tmp32_a = vel ± grav. rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1522 0x138E/0x338E atan(dx/dy) — MAME execute_338e (cmd.ipp:159) dx = read_dword(r1+4) - read_dword(r0+4) dy = read_dword(r1+8) - read_dword(r0+8) if(!dy){status\|=0x8000; angle=0} else angle=atan(dx/dy)128/pi; dy<0→+0x80 if(data&0x80) write_byt rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1570 MAME: angle = atan(dx/dy)128/pi (+0x80 se dy<0). rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1572 Cosi' z = atan(dx/dy) e il +0x80 (in WR) copre solo il quadrante, come MAME. rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1574 NIENTE prescale: i dword diff sono FIXED-POINT coord<<16 (come il 3BB0 che usa dx32[31:16] e MAME dx>>16), NON interi piccoli. rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1615 MAME (int)(...) tronca VERSO ZERO. rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1617 BUG TROVATO (validato vs MAME su 29241 casi): il CORDIC SOTTO-CONVERGE di 1 LSB sulle DIAGONALI (es. rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1622 Compenso l'epsilon di sotto-convergenza con +1 toward-zero PRIMA del troncamento: bias=1 azzera tutte le 133 divergenze (bias=0) -> 0/29241 vs MAME. rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1631 MAME execute_338e (seibucop_cmd.ipp:175-188): la write dell'angolo in RAM (obj+0x34 host, gated da data&0x80) e' FUORI dall'if/else di dy -> avviene SEMPRE, anche a dy==0 (dove cop_angle=0 -> scrive 0^0x80 = 0x80). rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1637 Ora calcolo ang_byte in entrambi i rami e scrivo SEMPRE, come MAME. rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1644 Scrivere l'angolo anche a dy==0 ("1:1 MAME") REGREDISCE: il martello scivola/moonwalk. rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1647 MAME: dy==0 -> cop_angle=0 rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1670 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197) dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (aritmetico) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = sqrt(dxdx + dydy) if(data&0x80) write_word(r0 + (data&0x200?0x3a:0x38 rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1779 (Il fix MAME-aligned 0x3a:0x38 faceva fuggire i nemici -> MAME invertito vs HW. rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1786 MAME: macro completata → cop_status = 7 (gate-poll del gioco). rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1872 0x8100/0x8900 sin/cos (MAME execute_8100/8900) raw_angle = cop_read_word(cop_regs[0]+0x34) & 0xff amp = (65536>>5) (cop_read_word(cop_regs[0]+0x36) & 0xff) = 2048 * amp_byte if (raw_angle == 0xC0 sin / 0x80 cos): amp = 2 res = int( rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1911 MAME special-case: sin && raw==0xC0 OR cos && raw==0x80 → amp = 2 rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1957 0xa180/0xa980 — read pos (MAME cop_collision_read_pos) flags_swap = cop_read_word(spradr+2) → host_read_word(spradr+0) pos[0] = cop_read_word(spradr+6) → host_read_word(spradr+4) pos[1] = cop_read_word(spradr+10) → host_read_word( rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1964 Però MAME cop_read_word(+2) = host_read_word(+2^2) = host_read_word(+0). rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1975 rdata = word @ host+0 = flags (MAME cop_read_word(spradr+2) ^ 2). rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1984 rdata = word @ host+4 = pos[0] (Y axis per MAME) rtl/HeatedBarrel/HeatedBarrel_cop3.sv:2004 0xb100/0xb900 — update hitbox & compute intersection (1:1 MAME cop_collision_update_hitbox, seibucop.cpp:1003-1065). rtl/HeatedBarrel/HeatedBarrel_cop3.sv:2049 MAME seibucop.cpp:1010 (data & 0x0100). rtl/HeatedBarrel/HeatedBarrel_cop3.sv:2106 MAME seibucop.cpp:1038: res init = (num_axis==3 ? rtl/HeatedBarrel/HeatedBarrel_main_top.sv:213 VBLANK IRQ4 — MAME legionna.cpp: m_maincpu->set_vblank_int(irq4_line_hold) MAME HOLD_LINE: IRQ asserted on edge, released ONLY at IACK (= when CPU fetches vector). rtl/HeatedBarrel/HeatedBarrel_main_top.sv:218 VBLANK IRQ4 — MAME legionna.cpp: m_maincpu->set_vblank_int(irq4_line_hold) MAME HOLD_LINE: IRQ asserted on edge, released ONLY at IACK (= when CPU fetches vector). rtl/HeatedBarrel/HeatedBarrel_main_top.sv:473 COP3 cmd 0x14 dma_tilemap_buffer (MAME legionna_v.cpp:86 videowrite_cb_w): offset 0x000..0x3FF → BG (back_data) offset 0x400..0x7FF → FG (fore_data) offset 0x800..0xBFF → MG (mid_data) offset 0xC00..0x13FF → Text (textram, 0x800 word) rtl/HeatedBarrel/HeatedBarrel_main_top.sv:485 DMA tilemap (cmd 0x14): dma_vram_addr = INDICE renderer 0-based del chip SEI300 (MAME videowrite_cb_w: i=0..0x3FF BG, 0x400-0x7FF FG, 0x800-0xBFF MG, 0xC00-0x13FF TEXT). rtl/HeatedBarrel/HeatedBarrel_main_top.sv:518 SCRATCH BG: CPU-write + DMA-src-read + FILL-write (= MAME .ram() $100800). rtl/HeatedBarrel/HeatedBarrel_main_top.sv:531 RENDER BG: scritto SOLO dal DMA cmd 0x14 (= MAME m_back_data), letto dal renderer. rtl/HeatedBarrel/HeatedBarrel_main_top.sv:596 ── Palette: split STAGING ($104000) vs RENDERER (semantica MAME 2-stadi) ─── MAME: la CPU e il fade (cmd 0x80) scrivono la STAGING RAM a $104000. rtl/HeatedBarrel/HeatedBarrel_main_top.sv:618 Il mirror serve al FADE-SOFTWARE della CPU (presentazione, routine $263E) che fa read-modify-write sulla palette assumendo palette UNICA (come MAME/HW): senza mirror la CPU scrive solo lo staging e il risultato non e' visibile fino al pross rtl/HeatedBarrel/HeatedBarrel_main_top.sv:639 In MAME m_spriteram=make_unique_clear (tutte 0 -> bit15=0 -> skip). rtl/HeatedBarrel/HeatedBarrel_maincpu_map.sv:23 Main CPU memory map HeatedBarrel (MAME legionna.cpp legionna_map): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $100000-$1003FF RAM scratch (1KB) → BRAM (Main RAM low) $100400-$1006FF COP3 region rtl/HeatedBarrel/HeatedBarrel_maincpu_map.sv:119 Heated Barrel memory map (MAME heatbrl_map): VRAM shiftata -0x800 vs legionna, CRTC +0x40, sound @1007c0, irqack @100600, spriteram @103000. rtl/HeatedBarrel/HeatedBarrel_maincpu_map.sv:215 MAME legionna_map: main_r/main_w(offset>>1) con umask16(0x00ff). rtl/HeatedBarrel/HeatedBarrel_maincpu_map.sv:219 Vedi reference/mame_seibu/seibusound.cpp main_r/main_w. rtl/HeatedBarrel/HeatedBarrel_maincpu_map.sv:311 Replica la latenza-zero-osservabile di MAME (cop_cmd_w sincrono): il gioco legge cop_hit_val_stat/cop_angle ($188/$1b4) nell'istruzione dopo il trigger. rtl/HeatedBarrel/HeatedBarrel_palette.sv:25 MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 12816); (legionna.cpp:1212, 12816 = 2048 entry) Address space CPU: 0x104000..0x104FFF (4 KB = 2048 word). rtl/HeatedBarrel/HeatedBarrel_palette.sv:35 Espansione 5→8 standard MAME palette_device: {val5, val5[4:2]} (bit replication che riempie i 3 LSB con i 3 MSB del valore 5-bit). rtl/HeatedBarrel/HeatedBarrel_palette.sv:85 HeatedBarrel: xBGR_555 → RGB888 (MAME legionna.cpp:1212) Layout: bit[4:0]=R, bit[9:5]=G, bit[14:10]=B. 5 bit per canale. rtl/HeatedBarrel/HeatedBarrel_palette.sv:87 Espansione 5→8 standard MAME palette_device: {val5, val5[4:2]} (replica i 3 MSB nei 3 LSB → range 0..255 con monotonia preservata). rtl/HeatedBarrel/HeatedBarrel_seibu_crtc.sv:23 Seibu CRTC fedele a MAME (src/mame/seibu/seibu_crtc.cpp). rtl/HeatedBarrel/HeatedBarrel_seibu_crtc.sv:119 MAME mappa: bit0=screen0(BG), bit1=screen2(MG), bit2=screen1(FG), bit3=screen3(Text) (vedi seibu_crtc.cpp commento "screen 0=BG, screen 1=FG, screen 2=MG, screen 3=Text") MAME (legionna_v.cpp) layer_en_w gira la maschera così: ~layer_en bit rtl/HeatedBarrel/HeatedBarrel_seibu_crtc.sv:128 Il dispatcher MAME usa "if (BIT(~m_layer_en, n))" per saltare = layer disabilitato quando il bit è 1. rtl/HeatedBarrel/HeatedBarrel_seibu_crtc.sv:133 HeatedBarrel layer ordering (MAME legionna_v.cpp:342-345): bit 0 = MG (midground) bit 1 = BG (background) bit 2 = FG (foreground) bit 3 = Text bit 4 = Sprites (Diverso da BB/DCon/Gundam dove bit 0=BG, bit 1=MG.) rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:25 Formato spriteram quasi identico (entrambi MAME sei021x_sei0220_spr.cpp) — differenze: - Spriteram @ 0x105000-0x105FFF (4KB, 1024 word, 256 entry × 4 word) - w3 bit 15 = tile bank extra bit (denjinmk usa, HeatedBarrel base = 0) rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:30 Format word (MAME legionna_v.cpp:288-312): w0 bit 15 = enable (0=draw, 1=skip — TODO verify HeatedBarrel) w0 bit 14 = flip_x w0 bit 13 = flip_y (??? rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:46 Priority callback legionna_v.cpp:314-317: pri_mask[0] = 0x0000 (sopra tutto) pri_mask[1] = 0xFFF0 pri_mask[2] = 0xFFFC pri_mask[3] = 0xFFFE rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:140 0..511 (MAME size/2/4 = 4096/2/4 = 512) rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:145 Decoded fields — MAME sei0210_device::draw (non-alt format, riga 143): if (BIT(~spriteram[i], 15)) continue; → draw quando w0[15]==1. rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:155 SEI0211 get_coordinate (MAME sei021x_sei0220_spr.h): coord &= 0x1ff; return (coord >= 0x180) ? rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:163 MAME SEI0211 default m_xoffset/m_yoffset = 0 (sei021x_sei0220_spr.cpp:40-41). rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:164 HeatedBarrel NON chiama set_offset (legionna.cpp:1214) → offset 0,0. rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:196 Tile code finale Y-MAJOR (MAME draw_internal: ax=outer, ay=inner, code++): sub_index = axsizey + ay → cur_tile = code + eff_tile_xsp_h + eff_tile_y rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:530 MAME gfx_legionna_spr: color base = 6416 = 0x400 (64 colorset × 16 pen). rtl/HeatedBarrel/HeatedBarrel_text_renderer.sv:25 Specifiche da MAME (legionna.cpp:1117-1126, 1167): rtl/HeatedBarrel/HeatedBarrel_text_renderer.sv:47 Char ROM in MAME: "char" region 64KB = ROM_COPY user1[0x10000..0x1FFFF]. rtl/HeatedBarrel/HeatedBarrel_text_renderer.sv:142 MAME `legionna_v.cpp:214`: text tilemap = 64×32 (8x8 tiles, TILEMAP_SCAN_ROWS). rtl/HeatedBarrel/HeatedBarrel_text_renderer.sv:188 --- Stage 3: pen decode (charlayout planes packed in nibbles) --- Per col c (0..3 dentro la half-tile), bit position = 3 - c. pen[0] = word[bit_pos + 0] (plane 0) pen[1] = word[bit_pos + 4] (plane 1) pen[2] = word[bit_pos + 8] (plane rtl/HeatedBarrel/HeatedBarrel_text_renderer.sv:194 MAME readbit usa MSB-first: bit_offs N → byte[N/8] bit (7-N%8). rtl/HeatedBarrel/HeatedBarrel_text_renderer.sv:195 In Verilog word concat (lo=byte0[7:0], hi=byte1[7:0]) → MAME pos N = word[(7-N%8) + (N>=8?8:0)]. rtl/HeatedBarrel/HeatedBarrel_text_renderer.sv:212 MAME GFXDECODE char: color base = 4816 = 0x300 (16 colorset × 16 pen). rtl/HeatedBarrel/HeatedBarrel_tile_layer.sv:25 Differenze fra layer (da MAME legionna_v.cpp): rtl/HeatedBarrel/HeatedBarrel_tile_layer.sv:58 BB FG hardcoded +0x1000 (MAME bloodbro fg_tile_info) rtl/HeatedBarrel/HeatedBarrel_tile_layer.sv:176 heatbrl 256x256 (MAME visarea 0..255) rtl/HeatedBarrel/HeatedBarrel_tile_layer.sv:196 Tile index con eventuale gfx_bank (MG ha bit 12 = 13-bit totali, BG/FG = 12 bit) + TILE_CODE_OFS hardcoded (BB FG aggiunge 0x1000 secondo MAME bloodbro fg_tile_info). rtl/HeatedBarrel/HeatedBarrel_video_timing.sv:33 Active area Heated Barrel (MAME heatbrl): visarea 0..328-1, 0..328-1 quindi 256×256. rtl/HeatedBarrel/HeatedBarrel_video_timing.sv:70 ── Constants timing ───────────────────────────────────────────────────── Blood Bros: 256x224 active (MAME bloodbro.cpp:846-851 set_visarea 0..255, 16..239). rtl/HeatedBarrel/HeatedBarrel_video_timing.sv:86 MAME heatbrl (legionna.cpp:1258-1259): set_size(368,368), set_visarea(0,255,0,255) = 256x256 visibile @ 60Hz. rtl/HeatedBarrel/sdram_bridge.sv:295 heatbrl: nessun de-scramble gfx (empty_init in MAME) — fetch lineare per tutte le region (back/mid/fore/sprite caricate gia' nel formato corretto, WORD_SWAP via MRA). README.md:12 This core reimplements the hardware in SystemVerilog from MAME references and hardware observation. README.md:41 Seibu SEI300 / COP coprocessor reproduced from the MAME `raiden2cop` reference: sincos / atan (CORDIC) math, distance / divide, object DMA, collision detect README.md:45 MAME-accurate Seibu CRTC tilemaps with per-layer scroll and graphics banking README.md:49 xBGR-555 palette, MAME-accurate layer priority and sprite/tilemap mixing Says it matches, follows or was checked against MAME — 8 HeatedBarrel.sv:209 Shift fisso aggiunto per match MAME 1:1 (misurato HW 2026-05-14): BG X+0 Y+16 FG X+0 Y+16 SPR X+0 Y+0 TXT X-1 Y+16 L'OSD resta editabile ±32 attorno al valore corretto. HeatedBarrel.sv:215 Offset per-layer HARDCODATI = match pixel-perfect MAME (trovati via OSD, ora fissi; menu P5 rimosso). HeatedBarrel.sv:257 NB: gli offset per-layer (ex P5) sono HARDCODATI (osd__xoff/yoff costanti, match pixel-perfect MAME). rtl/HeatedBarrel/HeatedBarrel_cop3.sv:747 find_trigger_match (MAME seibucop.cpp:464) Cerca slot N tale che (trigger & 0xf800) == (cop_func_trigger[N] & 0xf800) && cop_func_trigger[N] != 0. rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1926 res = prod >> 4 (= /16 per matchare formula MAME 2048/32768 = 1/16) rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:165 +1 pixel a destra: offset verificato con pixel hunting su MAME (rmonic79). rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:325 Scan INVERSO 511→0 (verificato su HW: ordine sprite-su-sprite opposto al loop MAME 0→511). rtl/HeatedBarrel/HeatedBarrel_video_timing.sv:87 V_VISIBLE portato 224->256 per matchare MAME. Says it was translated, ported or taken from MAME — 3 HeatedBarrel.sv:209 Shift fisso aggiunto per match MAME 1:1 (misurato HW 2026-05-14): BG X+0 Y+16 FG X+0 Y+16 SPR X+0 Y+0 TXT X-1 Y+16 L'OSD resta editabile ±32 attorno al valore corretto. rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1678 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197): 1:1 dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (signed) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = floor(sqrt(dxdx + dydy)) if(data&0x80) write_word(r0+(data&0x200?0x3 rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1795 0x42C2/0x4AA0 divide — MAME execute_42c2/4aa0 (cmd.ipp:219/247): 1:1 DIVIDEND = cop_dist << (5 - cop_scale) (cop_scale 0..3 → shift 5..2) 42c2: div=cop_read_word(r0+0x36)→host 0x34; if(!div){status\|=0x8000; write 0 a host 0x3a} else write Shares text with the MAME driver without saying so — 4 rtl/HeatedBarrel/HeatedBarrel_palette.sv:23 Palette RAM Seibu HeatedBarrel (xBGR_555, 2048 entries). MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 12816); (legionna — shares text with seibu/legionna.cpp:1212 rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:146 if (BIT(~spriteram[i], 15)) continue; → draw quando w0[15]==1. — shares text with seibu/sei021x_sei0220_spr.cpp:128 rtl/HeatedBarrel/HeatedBarrel_text_renderer.sv:23 Text layer renderer Seibu HeatedBarrel (8x8, 4bpp, 64x32). Specifiche da MAME (legionna.cpp:1117-1126, 1167): // charlayout 8x8, RGN_FRAC(1,1) — shares text with seibu/legionna.cpp rtl/HeatedBarrel/HeatedBarrel_video_timing.sv:86 MAME heatbrl (legionna.cpp:1258-1259): set_size(368,368), set_visarea(0,255,0,255) — shares text with seibu/legionna.cpp:1201
Hyprduel# Hyper Duel, Magical Error wo Sagase MiSTer-devel/Arcade-HyperDuel_MiSTer @ 7f154f1e MAME compared: metro/hyprduel.cpp Read: 18 HDL files, 8,144 lines (Quartus project)	MiSTer official	Both	medium	49%
Statements: 6 toward hardware, 29 toward MAME Reports a measurement taken on the original PCB — 4 rtl/hyprduel_sys.sv:400 Real-board OKI clock = 4 MHz OSC / 2 = 2.000 MHz, measured from the PCB 1cc video: announcer-voice pitch ratio 1.0532 against our previous 2.105 MHz divider => 1.999 MHz on hardware. rtl/hyprduel_sys.sv:423 YM level keeps the 2026-07-05 MAME stream calibration (x1.20); the OKI level is calibrated against REAL HARDWARE (PCB 1cc video line capture, 2026-07-11): title-voice peak vs title-music RMS measured 2.20 on the PCB against 5.13 with the ol rtl/i4220_vdp.sv:318 Frame total: MEASURED at 261 lines (60.2408 Hz with the 424-dot line at 6.6665 MHz) from two PCB recordings by three agreeing methods (docs/plan_refresh_measurement.md, ACCURACY.md 3.6); the game itself only ever programs 261 raster lines. rtl/i4220_vdp.sv:504 v14: the game runs TWO write disciplines (measured in sim and with the silicon write-landing histogram, 2026-07-19). Notes where it differs from MAME — 2 README.md:55 Where the core differs from MAME, and why. README.md:58 Visible area. The CRTC registers MAME ignores set the monitor's visible window. Cites MAME source — 21 Arcade-Hyprduel.sv:130 DIPs arrive as raw DSW port bytes on ioctl index 254 (MRA switches, default bf,ff = 0xFFBF = MAME defaults, demo sounds ON) Arcade-Hyprduel.sv:223 inputs (board ports are active low; MAME hyprduel.cpp:348-372) P1/P2: bit0 U, 1 D, 2 L, 3 R, 4 shot, 5 change, 6 bomb MiSTer joystick: bit0 R, 1 L, 2 D, 3 U, then J1 order from bit 4 rtl/hyprduel_sys.sv:41 audio (signed mono mix, MAME weights: YM 0.80, OKI 0.57) rtl/hyprduel_sys.sv:295 The sound program never writes the YM2151 twice within 0.5 us (MAME: 6.6 us minimum), so one pending write is enough. rtl/hyprduel_sys.sv:333 It samples IC_n only on its phiM enable (IKAOPLL_timinggen), and opll_cen is held at 0 while crst_n is low, so the chip never saw the reset: from power-on it put out a 0.18 s decaying offset before the game's first write (MAME silent), and rtl/hyprduel_sys.sv:402 MAME's 2.0625 MHz is ~3% sharp and flagged unverified in their own source. rtl/hyprduel_sys.sv:423 YM level keeps the 2026-07-05 MAME stream calibration (x1.20); the OKI level is calibrated against REAL HARDWARE (PCB 1cc video line capture, 2026-07-11): title-voice peak vs title-music RMS measured 2.20 on the PCB against 5.13 with the ol rtl/hyprduel_sys.sv:427 MAME's 0.57 route gain is ~3x hot vs the real board. rtl/hyprduel_sys.sv:438 NOT PCB-verified: if MAME's OKI route is as far off here as on Hyper Duel (~3.5x), the board value is ~x2.8. rtl/hyprduel_sys.sv:462 MAME's 0.57/0.80 routing (~a=0.71) is ~11 dB quieter than the real board. rtl/i4220_blitter.sv:109 invalid tilemap: stay idle, no done (MAME: return, no IRQ) rtl/i4220_render.sv:7 Per line: three sequential tilemap passes (layer 2 -> 1 -> 0, keep the lowest priority value, later pass wins ties => lowest layer wins), then one sprite pass in list order keeping the smallest priority group per pixel (first writer wins wi rtl/i4220_vdp.sv:29 (MAME encodes the same fact by forcing the enable register OR 0xFD.) rtl/i4220_vdp.sv:331 Measured on silicon (ladder probe, 2026-07-18): the game parks a scratch accumulator in the scroll registers across vblank and its frame-top write flurry lands during line 1, by (1,h160) - later than any simulation shows, because the SDRAM- rtl/i4220_vdp.sv:345 A real monitor therefore shows chip lines 2..225; lines 0/1 are a hidden work area (the scratch accumulator and the boss-zone outlier live there), which is why a PCB's top of screen is clean while MAME - which latches these registers but ig README.md:11 There is no datasheet for the chip, so it was built against MAME and then checked against photos and recordings of real boards. README.md:29 Shows the same 224 lines as a real cabinet, so the top-of-screen glitch seen in MAME is gone README.md:61 Reported to MAME in [mamedev/mame#15732](https://github.com/mamedev/mame/issues/15732). README.md:66 OKI sample clock. 2.000 MHz (the 4 MHz crystal halved), about 3% lower than MAME's unverified value. README.md:69 MAME misses around 14%, which shows as stepped parallax. README.md:108 The I4220 work relies on MAME's Imagetek driver by Luca Elia, David Haywood, Angelo Salese and others. Says it matches, follows or was checked against MAME — 6 Arcade-Hyprduel.sv:239 SERVICE port: bit15 service mode (low = on), bit14 Show Warning off SERVICE port: bit15 = Service Mode (1 = off), bit14 = Show Warning (0 = show, matching MAME's default and the unmodified PCB line; our old constant FFFF silently skipped th rtl/hyprduel_sys.sv:433 magerror: x9.90 = MAME 0.288 PARITY, measured 2026-09-27 (docs/magerror_audio_fix.md): over 6.9 s of attract music with an identical 2930-write YM stream, MAME's YM2413 stream is 7.03x the IKAOPLL ACC and MAME's OKI stream is 2.13x our pre- rtl/i4220_blitter.sv:4 Semantics verified against the MAME-port oracle (sim/oracle/i4220_blitter_oracle.py) by sim/tb/tb_blitter.sv. rtl/i4220_blitter.sv:17 A start with an invalid destination tilemap returns to idle without o_done, matching MAME. rtl/i4220_render.sv:5 Semantics as verified against the M1 oracle and real MAME frame dumps. rtl/i4220_vdp.sv:76 Video timing: 0 = measured 261-line frame (60.2408 Hz, hardware -verified), 1 = legacy MAME 262-line frame (60.011 Hz) for displays that reject 60.24 Hz in sync-locked HDMI modes. Keeps a MAME approximation — 2 rtl/hyprduel_sys.sv:8 MAME's inter-CPU spin hacks are deliberately NOT modelled; shared RAM is true dual-port. rtl/i4220_vdp.sv:321 i_compat60 selects the legacy MAME-assumed 262-line frame (60.011 Hz) for displays that reject 60.24 Hz in sync-locked HDMI modes.
IGSPGM# DoDonPachi II, DoDonPachi Dai-Ou-Jou, Demon Front / Moyu Zhanxian, Chuugokuryuu 3 Special … MiSTer-devel/Arcade-IGSPGM_MiSTer @ 899c0a3e MAME compared: igs/pgm.cpp + 27 related file(s) Read: 56 HDL files, 30,661 lines (Quartus project)	MiSTer official	Mostly MAME	medium	29%
Statements: 2 toward hardware, 30 toward MAME Cites hardware documentation that MAME's driver does not — 2 rtl/joy_db15.sv:9 The two pads are read out of a 74HC165 chain: JOY_LOAD is pulsed low to latch the switches, then each JOY_CLK rising edge shifts the next bit out on JOY_DATA. README.md:62 [GUS GF1 Decap](https://github.com/nukeykt/LPC-GUS) - Coming from the same hardware lineage, the GF1 source was a useful reference for how things might be done Cites MAME source — 20 rtl/exrom_decrypt.sv:20 IGS027A external ARM ROM address-bit XOR ("svg" / MAME pgm_<game>_decrypt). rtl/exrom_decrypt.sv:33 IGS27_CRYPT* primitives (MAME pgmcrypt.cpp): each returns 1 when the corresponding output bit must be XORed for word index i. rtl/exrom_decrypt.sv:53 type3 (55857G) high-byte tables (MAME pgmcrypt.cpp dfront_tab/theglad_tab), indexed by (word_idx >> 1) & 0xff = i[8:1]. rtl/ics2115/ics2115.sv:862 Port 0: IRQ status — MAME read() case 0 rtl/ics2115/ics2115_osc.sv:21 Processing order per spec §8.4 and MAME fill_output(): 1. rtl/ics2115/ics2115_osc.sv:427 MAME/reference: (s8(sample_byte) << 8). rtl/ics2115/ics2115_osc.sv:493 OSC_UPDATE: Advance oscillator accumulator (spec §6.1) fc bit 0 is unused; MAME uses fc<<2 on 32-bit acc, equivalent to fc>>1 in 29-bit space. rtl/igs025.sv:63 Region/game-id values latched at reset (MACHINE_RESET in MAME). rtl/igs025_src_tables.sv:3 Do not edit by hand; regenerate if the MAME tables change. rtl/igs027a.sv:592 MAME inits counter to 1 rtl/pgm_asic3.sv:13 MAME "Region" port value: 0,1 = World variants 2 = Korea 3 = China 4 = Taiwan / orlegend111t protection sequence rtl/pgm_asic3.sv:23 command : data) in MAME. rtl/pgm_asic3.sv:145 Signature / self-test constants from MAME. rtl/pgm_asic3.sv:234 0x03, 0x04, 0x05 are intentionally ignored by MAME. rtl/pgm_asic3.sv:240 0x41-0x47 are intentionally ignored by MAME. rtl/pgm_asic3.sv:255 0x50 is intentionally ignored by MAME. rtl/rom_decrypt.sv:103 CAVE type1 (recreated internal ROM) 68k decrypt tables (MAME pgmcrypt.cpp). rtl/rom_decrypt.sv:207 rom_size 0x100000 bytes -> 0x80000 words (MAME pgm_puzzli2_decrypt) rtl/rom_decrypt.sv:220 rom_size 0x100000 bytes -> 0x80000 words (MAME pgm_pstar_decrypt) README.md:56 [MAME](https://www.mamedev.org/) - Tons of information about the PGM system and especially its protection mechanisms. Says it matches, follows or was checked against MAME — 3 rtl/ics2115/ics2115.sv:612 recalc_irq — combinational IRQ state computation Matches MAME recalc_irq(): scans all 32 voices for pending IRQs rtl/ics2115/ics2115.sv:666 Register read mux — matches MAME reg_read() layout rtl/ics2115/ics2115.sv:813 Host bus read output mux — matches MAME read() at offsets 0-3 Says it was translated, ported or taken from MAME — 4 rtl/igs022.sv:2 Converted from MAME src/mame/igs/igs022.cpp. rtl/igs025.sv:2 Converted from MAME src/mame/igs/igs025.cpp + pgmprot_igs025_igs022.cpp. rtl/igs025_src_tables.sv:1 AUTO-GENERATED from MAME src/mame/igs/pgmprot_igs025_igs022.cpp killbld_source_data[0x0c][0xec] and dw3_source_data[0x08][0xec]. rtl/pgm_asic3.sv:4 Converted from MAME src/mame/igs/pgmprot_orlegend.cpp copyright-holders: Olivier Galibert, iq_132 Shares text with the MAME driver without saying so — 3 rtl/PGM.sv:986 IGS022 + IGS025 protection (The Killing Blade / Dragon World 3). — shares text with igs/pgmprot_igs025_igs022.cpp:11 rtl/PGM.sv:1091 type2/3 games have an external ARM ROM served from DDR; type1 (kovsh/photoy2k) — shares text with igs/pgmprot_igs027a_type1.cpp:46 rtl/address_translator.sv:96 IGS022/IGS025 protection (The Killing Blade / Dragon World 3). — shares text with igs/pgmprot_igs025_igs022.cpp:11
IkariWarriors# Ikari, Dogou Souken MiSTer-devel/Arcade-IkariWarriors_MiSTer @ 3e5f3457 MAME compared: snk/snk.cpp + 2 related file(s) Read: 86 HDL files, 10,589 lines (Quartus project)	MiSTer official	Mostly hardware	low	36%
Statements: 13 toward hardware, 1 toward MAME Cites hardware documentation that MAME's driver does not — 12 rtl/clocks/A5004_1.v:1 Ikari Warriors A5004-1 PAL16R6 (same as Athena A6001-1 PAL16R6) Author: @RndMnkIII Date: 15/06/2022 Converted from Ikari-A5004-1-GAL.jed using MAME's jedutil tool Many thanks to @Porchy and pldarchive.co.uk for the JED files. rtl/clocks/IkariWarriorsCore_Clocks.sv:205 74LS30 8-input positive NAND gate rtl/front/IkariWarriorsCore_LineBuffer.sv:102 74LS20 4-input NAND gate rtl/front_turbo/IkariWarriorsCore_FrontTurbo.sv:95 Register file: in hardware implemented using four 74LS670 4bitx4 Latch registers dual ported Implemented using 8bit registersx4 rtl/ttl/ttl_74107a_AsyncClr.v:1 74LS107A: Dual J-/K flip-flop with clear; negative-edge-triggered Inputs Outputs rtl/ttl/ttl_74107a_sync.v:1 74LS107A: Dual J-/K flip-flop with clear; negative-edge-triggered Inputs Outputs rtl/ttl/ttl_74163a_sync.v:1 4-bit modulo 16 binary counter with parallel load, * FOR SYNTHESIS * Synchronous Reset (SRn) -> LS163A <START_TEMPLATE> ttl_74161a #(.DELAY_RISE(20), .DELAY_FALL(25)) <NAME> (.Clear_bar(), .Load_bar(), .ENT(), .ENP(), .D(), .Clk(), .RCO rtl/ttl/ttl_74373.sv:1 ttl_74373.sv Octal D transparent latch function table, logic diagrams and switching characteristics extracted from TI 74LS373 Datasheet. rtl/ttl/ttl_74374_sync.sv:1 ttl_74374_sync.sv Octal D edge triggered FF function table, logic diagrams and switching characteristics extracted from TI 74LS374 Datasheet. rtl/ym3526/jtopl_exprom.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots. rtl/ym3526/jtopl_logsin.v:16 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots. rtl/ym3526/jtopl_op.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots. Ships hardware documentation files — 1 docs/IkariWarriorsSchematic_RndMnkIII_edited.pdf Says it was translated, ported or taken from MAME — 1 rtl/clocks/A5004_1.v:1 Ikari Warriors A5004-1 PAL16R6 (same as Athena A6001-1 PAL16R6) Author: @RndMnkIII Date: 15/06/2022 Converted from Ikari-A5004-1-GAL.jed using MAME's jedutil tool Many thanks to @Porchy and pldarchive.co.uk for the JED files.
Inferno# Inferno MiSTer-devel/Arcade-Inferno_MiSTer @ 7b85212b MAME compared: williams/williams.cpp + 5 related file(s) Read: 12 HDL files, 13,196 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	28%
Statements: 3 toward hardware, 2 toward MAME Cites hardware documentation that MAME's driver does not — 2 rtl/inferno_cmos_ram.vhd:26 @00-01: Extra life - BCD 00 to 99 @02-03: Men for for 1 credit - BCD 01 to 99 @04-05: High score to date - BCD 00 to 01 - No / Yes @06-07: Pricing selection - BCD 00 to 09 - Custom / free play @08-09: Left coi rtl/inferno_cmos_ram.vhd:47 @8A-8B: Position line 1 - HEX x08 to x46 @8C-8D: Position line 2 - HEX x08 to x46 @8E-8F: control sum of settings @90-91: ? Ships hardware documentation files — 1 doc/Inferno Manual and Schematics.pdf Cites MAME source — 1 rtl/williams2.vhd:32 Use with MAME roms from inferno.zip Shares text with the MAME driver without saying so — 1 rtl/williams2.vhd:356 pixels \|0\|1\|2\|3\|4\|5\|0\|1\|2\|3\|4\|5\| — shares text with williams/williamsblitter.cpp:50
IremM107# Fire Barrel, Dream Soccer '94 MiSTer-devel/Arcade-IremM107_MiSTer @ bfdfd292 MAME compared: irem/m107.cpp + 3 related file(s) Read: 38 HDL files, 15,273 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	6%
Statements: 2 toward hardware Cites hardware documentation that MAME's driver does not — 1 rtl/m107.sv:166 Global signals from schematics Notes where it differs from MAME — 1 rtl/nec_core/alu.sv:128 TODO - MAME doesn't update these flags, but documentation says it should flags.AC = ta[3:0] > 4'd0 ?
IremM62# The Battle-Road, Horizon, Kaiketsu Yanchamaru, Spartan X … MiSTer-devel/Arcade-IremM62_MiSTer @ 5ee82326 MAME compared: irem/m62.cpp + 8 related file(s) Read: 30 HDL files, 9,979 lines (Quartus project)	MiSTer official	Mostly MAME	low	16%
Statements: 1 toward hardware, 9 toward MAME Cites hardware documentation that MAME's driver does not — 1 rtl/iremm62_video_controller.vhd:72 from M52 schematics Shares text with the MAME driver without saying so — 9 rtl/input_mapper.vhd:89 /* Bits 4,5,6 are different in each game, see below */ — shares text with irem/m62.cpp:412 rtl/platform.vhd:965 J1: selects whether bit 4 of obj color code selects or not high priority over tiles — shares text with irem/m62.cpp:41 rtl/platform.vhd:966 J2: selects whether bit 4 of obj color code goes to A7 of obj color PROMS — shares text with irem/m62.cpp:42 rtl/platform.vhd:968 JP1-4 - Tiles with color code >= the value set here have priority over sprites — shares text with irem/m62.cpp:54 rtl/platform.vhd:969 J1: selects whether bit 4 of obj color code selects or not high priority over tiles — shares text with irem/m62.cpp:41 rtl/tilemapctl.vhd:184 J1: selects whether bit 4 of obj color code selects or not high priority over tiles — shares text with irem/m62.cpp:41 rtl/tilemapctl.vhd:185 J2: selects whether bit 4 of obj color code goes to A7 of obj color PROMS — shares text with irem/m62.cpp:42 rtl/tilemapctl.vhd:187 JP1-4 - Tiles with color code >= the value set here have priority over sprites — shares text with irem/m62.cpp:54 rtl/tilemapctl.vhd:188 J1: selects whether bit 4 of obj color code selects or not high priority over tiles — shares text with irem/m62.cpp:41
IremM72# Air Duel, Dragon Breed, Armed Police Unit Gallop, Daiku no Gensan … MiSTer-devel/Arcade-IremM72_MiSTer @ b8ba3fae MAME compared: irem/m72.cpp + 7 related file(s) Read: 52 HDL files, 37,954 lines (Quartus project)	MiSTer official	Mostly hardware	medium	48%
Statements: 13 toward hardware, 11 toward MAME Cites hardware documentation that MAME's driver does not — 5 rtl/joy_db15.sv:9 The two pads are read out of a 74HC165 chain: JOY_LOAD is pulsed low to latch the switches, then each JOY_CLK rising edge shifts the next bit out on JOY_DATA. rtl/m72.v:244 Global signals from schematics. rtl/v30/v30u_eu.sv:58 The behaviour is identical either way and the full ladder was re-scored to say so; the NETLIST is not. rtl/v30/v30u_eu.sv:969 Both are booked UNLANDABLE-AS-DESIGNED with the block characterised, not the mechanism condemned: `docs/notes/ghost8f_results_2026-08-09.md` §9 measured the FULL family at 15.3 MHz on two draws with every worst setup path launching from rtl/v30/v30u_eu.sv:3050 Falsifier: a `v30u_eu` state register with no `ena` in the post-fit netlist, or a ladder cell that moves. Reports a measurement taken on the original PCB — 5 rtl/v30/v30u_biu.sv:2249 MEASURED: silicon's second acknowledge is `display + 7` at every delay and the model's/ucore's was `T1 + 6`; they part only where a T1 WAITED, which in this whole corpus is the acknowledge after a woken HALT. rtl/v30/v30u_biu.sv:2884 MEASURED on silicon, 1,189 HALT pseudo-cycles over the 725 retained fz2 captures, chip leg only: the HALT publishes the value the AD output latch ALREADY HOLDS, on both lanes, 1,189 of 1,189 with no exception. rtl/v30/v30u_eu.sv:332 MEASURED against silicon on a directed board cell built for it (§85.2b): the floor is 3 clocks, 121,890 rows at 0 row-diffs, with no other value in [1,7] within four orders of magnitude. rtl/v30/v30u_eu.sv:2226 MEASURED, silicon, FLASH #17, `docs/notes/tf0f_cell_results_2026-08-11.md`: 512 directed cells x 4 waits x 4 alignments, 2,880 scored traps per engine, derivation 16/16 and a DISJOINT validation 14/14. rtl/v30/v30u_eu.sv:3670 F` is exactly two ROM rows, 007A (POP PSW) and 01EA (RETI) -- which is the same pair E1 measured on silicon ("mu01EA's flag commit obeys the SAME race table as POP PSW's mu007A", 108/108 H-IDENTICAL). Ships hardware documentation files — 2 docs/Irem_M72_schematics.pdf docs/Irem_M84_schematics.pdf Notes where it differs from MAME — 1 rtl/nu8051/nu8051_uart.sv:13 MAME is NOT the oracle for anything bit-timing here (PQ12): its mode-0 output is "highly simplified and incorrect" by its own comment, its mode-0 input is not emulated at all, and its receiver samples once per bit with no 2-of-3 majority. Cites MAME source — 10 rtl/kna70h015.sv:77 From MAME Legend of Hero TONMA (c)1989 Irem rtl/m72.v:199 Tie the MCU CE to the V30 CE phase: the MCU advances (and stalls) in lockstep with the bursty catch-up V30, holding the shared-RAM protection handshake at a constant V30<->MCU phase relationship (the effect MAME gets from synchronize() on e rtl/nu8051/nu8051_alu.sv:234 B == 0 (IQ2, mirror-MAME): A/B echoed back unchanged, OV = 1 rtl/nu8051/nu8051_irq.sv:125 The level cleared is the CURRENT one - high if a high-priority routine is in progress, otherwise low (periph §6.2: MAME's `clear_current_irq`, and the manual's "the interrupt in progress is done"). rtl/nu8051/nu8051_ports.sv:179 The sampled PIN is the resolved node, not the external driver alone: a latch bit of 0 turns the output nFET on and pulls the pin low whatever the outside world drives (periph §3.2 quasi-bidirectional, §3.3 P0 open-drain), which is exactly t rtl/nu8051/nu8051_seq.sv:1541 That is the cheap implementation, it is MAME's (`manage_idle_on_interrupt` runs on any taken interrupt), and it is the only one that settles the corner the manual does not mention - a write of IDL on the very edge that vectors - without the rtl/nu8051/nu8051_timer.sv:244 Tx 1->0 : 1) GATE consumes the S5P2-SAMPLED INTx# pin level (PQ1 - the manual; MAME gates on the latched IEx flag and carries a TODO saying so). rtl/nu8051/nu8051_uart.sv:199 QUESTION-P54-4: this puts the modes-2/3 RI one bit time EARLIER than periph §5.2/§5.7 say - the figures are unambiguous (no bit-detector sample and no shift pulse anywhere in the modes-2/3 stop bit) and MAME sets it a bit time late. rtl/v30/v30u_eu.sv:304 --- the interrupt recognition (U2 pass 5; docs/facts/interrupt_model.md) --- The pins reach the decision through flops, and THAT is the whole mechanism: the ucore does NOT render `timed_runner.cpp`'s `D = max(B, A + pipe)`, which the third rtl/v30/v30u_eu.sv:2561 `timed_runner.cpp` states the geometry and it falls straight out of `B = D + 1`, `entry = B + 2`: Shares text with the MAME driver without saying so — 1 rtl/kna70h015.sv:77 From MAME Legend of Hero TONMA (c)1989 Irem M72 System Horizontal Freq. = 15.625KHz H.Period = 64.0us (512) H.Blank = 16.0us (128) H.Sync Puls — shares text with irem/m72.cpp:2743
IremM90# Bomber Man World, Bomber Man, Gussun Oyoyo MiSTer-devel/Arcade-IremM90_MiSTer @ 06d05255 MAME compared: irem/m90.cpp + 7 related file(s) Read: 27 HDL files, 7,347 lines (Quartus project)	MiSTer official	Both	low	13%
Statements: 3 toward hardware, 1 toward MAME Cites hardware documentation that MAME's driver does not — 2 rtl/m90.sv:151 Global signals from schematics rtl/sound.sv:189 NMI frequency is 7812.5Khz On original hardware this is derived from the 32Mhz CPU clock, divided by 4096 4Mhz signal is divided by the 74LS161 counters IC71 and IC72 Here since we have a 40Mhz sys_clk, we divide by 5120 Notes where it differs from MAME — 1 rtl/V35/alu.sv:128 TODO - MAME doesn't update these flags, but documentation says it should flags.AC = ta[3:0] > 4'd0 ? Shares text with the MAME driver without saying so — 1 rtl/sound.sv:22 void m90_state::m90_sound_cpu_map(address_map &map) { map(0x0000, 0xefff).rom(); map(0xf000, 0xffff).ram(); } void m90_state::m90_sound_cpu_io_map(address_ma — shares text with irem/m90.cpp:127
IremM92# Cross Blades!, Geo Storm, Gunforce: Battle Fire Engulfed Terror Island, Hook … MiSTer-devel/Arcade-IremM92_MiSTer @ 492cc21c (matched by date) MAME compared: irem/m92.cpp + 5 related file(s) Read: 40 HDL files, 15,247 lines (Quartus project)	MiSTer official	Mostly hardware	low	25%
Statements: 26 toward hardware Cites hardware documentation that MAME's driver does not — 1 rtl/m92.sv:166 Global signals from schematics Ships hardware documentation files — 24 docs/PALs/M92-A-3M-.eqn docs/PALs/M92-A-7J-.eqn docs/PALs/M92-A-9J-.eqn docs/PALs/M92-B-2L-.eqn docs/PALs/M92-B-7H-.eqn docs/PALs/M92-B-7H-D.eqn docs/PALs/M92-C-2L-.eqn docs/PALs/M92-C-7H-C.eqn docs/m92_A-B_B-F/audio.kicad_sch docs/m92_A-B_B-F/audio_cpu.kicad_sch docs/m92_A-B_B-F/audio_mix.kicad_sch docs/m92_A-B_B-F/b_board_support.kicad_sch docs/m92_A-B_B-F/b_interface.kicad_sch docs/m92_A-B_B-F/bank_switching.kicad_sch docs/m92_A-B_B-F/clock_gen.kicad_sch docs/m92_A-B_B-F/connectors.kicad_sch docs/m92_A-B_B-F/ga21.kicad_sch docs/m92_A-B_B-F/ga22.kicad_sch docs/m92_A-B_B-F/m92_A-B_B-F.kicad_sch docs/m92_A-B_B-F/palette_ram.kicad_sch docs/m92_A-B_B-F/sample_filters.kicad_sch docs/m92_A-B_B-F/shared_memory.kicad_sch docs/m92_A-B_B-F/untitled.kicad_sch docs/m92_A-B_B-F/vram.kicad_sch Notes where it differs from MAME — 1 rtl/nec_core/alu.sv:128 TODO - MAME doesn't update these flags, but documentation says it should flags.AC = ta[3:0] > 4'd0 ?
IronHorse# Dai Ressya Goutou MiSTer-devel/Arcade-IronHorse_MiSTer @ 98ee94aa MAME compared: konami/ironhors.cpp + 1 related file(s) Read: 9 HDL files, 7,127 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	23%
Statements: 1 toward hardware, 1 toward MAME Cites hardware documentation that MAME's driver does not — 1 rtl/IronHorse.sv:536 Iron Horse also uses 3 switchable low-pass filters on the SSG side of its YM2203 with a cutoff frequency of 723.432Hz (actually closer to 492.130Hz due to internal resistance inside the 74HC4066 handling the filter switching). Cites MAME source — 1 rtl/custom/k005885.sv:388 The 005885 has five 8-bit registers set up as follows according to information in konamiic.txt found in MAME's source code:
Jackal# Tokushu Butai Jackal MiSTer-devel/Arcade-Jackal_MiSTer @ 1bc48c37 MAME compared: konami/jackal.cpp + 1 related file(s) Read: 12 HDL files, 7,789 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	14%
Statements: 1 toward MAME Cites MAME source — 1 rtl/custom/k005885.sv:388 The 005885 has five 8-bit registers set up as follows according to information in konamiic.txt found in MAME's source code:
Jailbreak# Manhattan 24 Bunsyo MiSTer-devel/Arcade-Jailbreak_MiSTer @ d564ee0b MAME compared: konami/jailbrek.cpp + 7 related file(s) Read: 10 HDL files, 6,780 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	0%
No statements found
Joust2# Joust 2 - Survival of the Fittest MiSTer-devel/Arcade-Joust2_MiSTer @ dd09dfa5 MAME compared: williams/williams.cpp + 5 related file(s) Read: 15 HDL files, 18,090 lines (Quartus project)	MiSTer official	Both	low	32%
Statements: 3 toward hardware, 5 toward MAME Cites hardware documentation that MAME's driver does not — 2 rtl/joust2_cmos_ram.vhd:26 @00-01: Extra man every - BCD 00 to 99 @02-03: Men for for 1 credit - BCD 01 to 99 @04-05: High score to date allwd - BCD 00 to 01 - No / Yes @06-07: Sound in attract mode - BCD 00 to 01 - No / Yes @08-09: Pricing selection rtl/joust2_cmos_ram.vhd:47 @8A-8B: Position line 1 - HEX x08 to x46 @8C-8D: Position line 2 - HEX x08 to x46 @8E-8F: control sum of settings @90-91: ? Ships hardware documentation files — 1 doc/inferno-schematics.pdf Cites MAME source — 2 rtl/williams2.vhd:32 Use with MAME roms from joust2.zip rtl/williams_cvsd_board.vhd:30 Use with MAME roms from joust2.zip Shares text with the MAME driver without saying so — 3 Arcade-Joust2.sv:209 0 1 2 3 4 5 6 — shares text with williams/williamsblitter.cpp:50 rtl/joust2_sound_board.vhd:163 cpu_2764_ic8_rom1_rev1.0f (84517c3c) — shares text with williams/williams.cpp:3852 rtl/williams2.vhd:363 pixels \|0\|1\|2\|3\|4\|5\|0\|1\|2\|3\|4\|5\| — shares text with williams/williamsblitter.cpp:50
JunoFirst# Juno First MiSTer-devel/Arcade-JunoFirst_MiSTer @ efeb8e46 MAME compared: konami/junofrst.cpp + 5 related file(s) Read: 23 HDL files, 11,760 lines (Quartus project)	MiSTer official	Both	low	29%
Statements: 5 toward hardware, 13 toward MAME Cites hardware documentation that MAME's driver does not — 4 rtl/JunoFirst_CPU.sv:222 Juno First I/O decoding (memory-mapped in 0x8000-0x80FF region) Reference: MAME junofrst.cpp main_map and Juno First schematics rtl/JunoFirst_SND.sv:274 Real arcade hardware doesn't need this delay; the 8039's pins on the JF schematic are wired identically to our setup (T0/T1 are floating NC, /EA pulled to VCC, /RESET from the system reset network, /INT from a 74LS74 we faithfully model). rtl/custom/k526.sv:3 SystemVerilog implementation of the Konami 526, an 82S153 PLA used for address decoding on Time Pilot Converted from dump available at the PLD Archive http://wiki.pldarchive.co.uk/index.php?title=Time_Pilot Copyright (C) 2021 Ace rtl/custom/k528.sv:3 SystemVerilog implementation of the Konami 528, an 82S153 PLA used for controlling the vertical counter outputs on Time Pilot's Konami 082 Converted from dump available at the PLD Archive http://wiki.pldarchive.co.uk/index.php?title=Time_Pi Ships hardware documentation files — 1 Useful Information/juno_schem_text.pdf Cites MAME source — 10 rtl/JunoFirst_CPU.sv:222 Juno First I/O decoding (memory-mapped in 0x8000-0x80FF region) Reference: MAME junofrst.cpp main_map and Juno First schematics rtl/JunoFirst_CPU.sv:248 Juno First hardware blitter — 16x16 nibble-addressed sprite copy/clear Reference: MAME junofrst.cpp blitter_w() rtl/JunoFirst_CPU.sv:576 Generate VBlank IRQ for MC6809E MAME: IRQ fires every other vblank frame when irq_enable is set. rtl/JunoFirst_SND.sv:133 Z80 address decoding (MAME audio_map): 0x0000-0x0FFF = ROM (4KB) 0x2000-0x23FF = RAM (1KB) 0x3000 = soundlatch read 0x4000 = AY-8910 address write 0x4001 = AY-8910 data read 0x4002 = AY-8910 data write 0x5000 rtl/JunoFirst_SND.sv:158 Z80 IRQ — edge detect on irq_trigger (MAME sh_irqtrigger_w: fires on 0->1) rtl/JunoFirst_SND.sv:220 IRQ latch — exactly as real hardware / MAME does it Z80 write → assert INT (active low) MCU writes P2.7 low → clear latch rtl/JunoFirst_SND.sv:333 Multiplexed bus input to the 8039: /PSEN asserted → program ROM byte (instruction fetch) /RD asserted → soundlatch2 (8039 MOVX read of Z80-side command) else → 8'hFF (idle pull-ups) MAME's mcu_io_map maps 0x00-0xFF all to soundl rtl/JunoFirst_SND.sv:386 Port A read: timer[3:0] in bits 7:4, i8039_status in bits 2:0 Timer = Z80 cycle count / 512 (MAME: total_cycles / (1024/2)) rtl/JunoFirst_SND.sv:423 MAME portB_w: bits [1:0]=ch.A filter, [3:2]=ch.B, [5:4]=ch.C Each pair selects capacitance: bit0=47nF, bit1=220nF (additive) For initial implementation, no dynamic filter switching — just DC removal. rtl/JunoFirst_SND.sv:454 MAME reference: AY=0.30 per voice (x3 = 0.90), DAC=0.25 — i.e. DAC quieter than the AY total. Says it matches, follows or was checked against MAME — 2 rtl/JunoFirst_CPU.sv:591 Clear IRQ when irq_enable is turned off (matches MAME irq_enable_w) rtl/JunoFirst_SND.sv:351 T0/T1 are pin-1 / pin-39 on the real 8039 — NC on the JF schematic, but we tie to 0 to match the working Gyruss reference; MAME's junofrst.cpp does not bind T0/T1 callbacks either. Says it was translated, ported or taken from MAME — 1 rtl/JunoFirst_SND.sv:3 Juno First sound board Based on MAME junofrst.cpp audio implementation
Kangaroo# Funky Fish, Kangaroo MiSTer-devel/Arcade-Kangaroo_MiSTer @ 5fd65cd5 MAME compared: sunelectronics/kangaroo.cpp Read: 12 HDL files, 3,037 lines (Quartus project)	MiSTer official	Mostly MAME	medium	78%
Statements: 5 toward hardware, 57 toward MAME Ships hardware documentation files — 4 Useful Information/schematics/Kangaroo - Operator's Manual (2nd Printing).pdf Useful Information/schematics/Kangaroo - Schematic Package (3rd Printing).pdf Useful Information/schematics/MB8841.pdf Useful Information/schematics/kang-sp_text.pdf Notes where it differs from MAME — 1 rtl/cpu/mb88_sv/mb88_core.sv:31 NOT MODELLED — NONE are gaps (MAME doesn't model them for the default part, or no target device uses them): * STANDBY (stby_n pin): MAME has no standby/STOP state for mb88. Cites MAME source — 49 Arcade-Kangaroo.sv:259 2x pixel clock: arcade_video renders 512 px/line (each of the 256 source columns doubled) for the MAME-style dimmed-copy interleave, and the scaler shrinks it back. rtl/Kangaroo.sv:14 Player inputs (active HIGH, per MAME port definitions) rtl/Kangaroo_CPU.sv:21 h_center is in PIXELS and scaled x2 below because h_cnt runs at the double-rate 10 MHz clock (MAME: 3202 / 2562), so one displayed pixel is two h_cnt counts. rtl/Kangaroo_CPU.sv:193 Blitter has 4 x 4KB ROMs, banked into 0xC000-0xDFFF via bank select (video_control[8]) MAME banks one contiguous 8K window over the 16K image (kangaroo.cpp:427, :532), and the image loads v0,v2,v1,v3 (kangaroo.cpp:772-775), so blit0=v0 blit rtl/Kangaroo_CPU.sv:200 MAME: (data & 0x05) ? rtl/Kangaroo_CPU.sv:239 MAME: m_video_control[0..10], written at 0xE800-0xE80A Only bits [3:0] of the address select the register (mirrored with 0x03F0) rtl/Kangaroo_CPU.sv:278 MAME: m_maincpu->pulse_input_line(INPUT_LINE_NMI, attotime::zero); On original HW (mcu_present) the MB8841 drives NMI instead (see MCU block below) — this pulse is unused. rtl/Kangaroo_CPU.sv:300 Per MAME kangaroo.cpp:153 — besides the boot NMI it "acts like a timer to determine the intervals of the big ape enemy appearing." Wiring mirrors kangaroo_mcu_state (kangaroo.cpp:455-504): CPU wr 0xEF00 -> main_data rtl/Kangaroo_CPU.sv:305 protrom[addr] : F) (mcu_port_k_r) O port (oh:ol) -> protrom addr A0-A7 ; R3.1 -> A8 (A9,A10=GND) (mcu_port_o_w / mcu_port_r_w) R3.3 -> main-CPU NMI (mcu_port_r_w) MCU clock = 10MHz/4 rtl/Kangaroo_CPU.sv:309 darfpga mb88 has separate R in/out ports and no external drive on kangaroo's R pins, so tie in<-out (MAME's read_r returns the output latch). rtl/Kangaroo_CPU.sv:312 MAME converts pin clocks at (clocks+5)/6, so the 2.5 MHz pin rate is divided by 6. rtl/Kangaroo_CPU.sv:384 MAME: standard IM1 interrupt, RST 38h every vblank IRQ fires on vblank rising edge rtl/Kangaroo_CPU.sv:406 Kangaroo video timing from MAME: screen.set_raw(10_MHz_XTAL, 3202, 02, 2562, 260, 8, 248); Total: 640 pixel clocks horizontal (at 5 MHz that's 320 positions at 10 MHz) But the screen uses 10 MHz as raw pixel clock with 640 total, 512 vis rtl/Kangaroo_CPU.sv:436 Sync and blank generation MAME visible: x = 02 to 2562-1 = 0 to 511, y = 8 to 247 The scanout pipeline is 2 clk_10m cycles deep, so hblank/hsync are delayed to match. rtl/Kangaroo_CPU.sv:561 MAME videoram_write expand logic — pure combinational functions Expand 8-bit CPU data to 32-bit (DCBADCBA → 4 bytes) rtl/Kangaroo_CPU.sv:661 MAME's blitter_execute() is synchronous inside the $E805 write, so software can issue the next trigger a few instructions later. rtl/Kangaroo_CPU.sv:751 Adjust mask per MAME: OR top/bottom 2-bit pairs during DMA rtl/Kangaroo_CPU.sv:794 Apply low-half blit: LOW-half ROM pairs with mask & 0x05 (kangaroo.cpp:344) rtl/Kangaroo_CPU.sv:798 Now apply high-half blit: HIGH-half ROM pairs with mask & 0x0a (kangaroo.cpp:345) rtl/Kangaroo_CPU.sv:846 MAME screen_update variables derived from video_control registers rtl/Kangaroo_CPU.sv:849 MAME exact rtl/Kangaroo_CPU.sv:851 FLIP A / FLIP B (video_control[9] bits 5/4, kangaroo.cpp:364-365), XORed with the OSD CRT Flip so it reuses the game's own mirror rather than adding a second one. rtl/Kangaroo_CPU.sv:910 Priority compositing (MAME logic) Even pixels (first of pair): full brightness, no KOS1 masking Odd pixels (second of pair): apply KOS1 color mask for Z=0 pixels arcade_video samples the core's RGB once per h_cnt at ce_pix_2x, so consecutiv rtl/Kangaroo_CPU.sv:932 Output — BGR 3-bit palette (MAME: PALETTE(config, m_palette, palette_device::BGR_3BIT)) rtl/Kangaroo_SND.sv:175 Simple mix: sum three unsigned 8-bit channels, apply 50% gain, output as signed 16-bit MAME: AY8910 route ALL_OUTPUTS to mono at 0.50 rtl/cpu/mb88_sv/mb88.sv:57 Generate it here: one ena_timer pulse per 32 `ena` machine-cycle enables — MAME mb88 burn_cycles /32 (full timer overflow = ÷8192 of `ena`). rtl/cpu/mb88_sv/mb88_core.sv:6 Oracle: MAME cpu/mb88xx/mb88xx.cpp (opcode-for-opcode). rtl/cpu/mb88_sv/mb88_core.sv:14 COMPLETE vs MAME mb88xx.cpp — opcode AND non-opcode. rtl/cpu/mb88_sv/mb88_core.sv:16 OPCODES: all 256 bytes, verified byte-for-byte vs mb88xx.cpp execute_run() (0x00-2f individual; 0x30-3f sbit/rbit/tbit/rti/jpa/en/dis; 0x40-7f setD/ rstD/tstD/tba/xd/xyd/lxi/call/jpl/ai; 0x80-bf lyi/li/cyi/ci; 0xc0-ff jmp). rtl/cpu/mb88_sv/mb88_core.sv:23 Timer: internal (pio7, ÷32 prescale) OR external TC pin (pio6) per MAME increment_timer() (2026-07-11 + 2026-07-17 fixes). rtl/cpu/mb88_sv/mb88_core.sv:29 * O-port PLA: 8-bit cf-nibble-select outO = MAME write_pla with pla_bits==8 (the device default; what the Namco 5xxx use). rtl/cpu/mb88_sv/mb88_core.sv:34 * External-clock serial (pio 0x10/0x30): MAME fatalerror's it (unsupported). rtl/cpu/mb88_sv/mb88_core.sv:55 MAME's write_pla() ends with an unconditional `m_write_o(0, m_o_output, mask)` (mb88xx.cpp:373), so consumers that latch the O port (e.g. namco_51xx's shared mailbox = MAME m_portO) must re-latch on every write, not on a value change. rtl/cpu/mb88_sv/mb88_core.sv:65 interrupt injection (harness drives from the MAME trace during bug hunt) rtl/cpu/mb88_sv/mb88_core.sv:95 ---- SERIAL (2026-07-18; faithful to MAME mb88xx.cpp serial_timer()/pio_enable()) ---- 4-bit RECEIVE shift register clocked at clock()/SERIAL_PRESCALE(=6), armed when pio[5:4]==2'b10 (MAME's (m_pio & 0x30)==0x20 = internal serial clock). rtl/cpu/mb88_sv/mb88_core.sv:99 sf blocks further shifting until tsts clears it; SBcount runaway-disables at THRESH (MAME anti-hang). rtl/cpu/mb88_sv/mb88_core.sv:100 External-clock serial (pio 0x10/0x30) is unsupported by MAME (fatalerror) so we just don't tick. rtl/cpu/mb88_sv/mb88_core.sv:101 SO/transmit is not modeled in MAME's mb88 either. rtl/cpu/mb88_sv/mb88_core.sv:105 MAME SERIAL_DISABLE_THRESH rtl/cpu/mb88_sv/mb88_core.sv:155 SP[] and ram[] intentionally NOT reset (MAME device_reset doesn't clear data RAM/stack; ROM inits RAM; Verilator zero-inits arrays). rtl/cpu/mb88_sv/mb88_core.sv:161 MAME mb88xx.cpp: `if (m_ctr && !state && (m_pio & 0x40)) increment_timer(); m_ctr = state;` i.e. on a FALLING edge of the TC pin, if external-counter mode (pio bit6/0x40) is enabled, tick the SAME timer. rtl/cpu/mb88_sv/mb88_core.sv:164 This drives the 51xx's per-frame timer, which MAME clocks from screen vblank (namco51.cpp vblank() -> MB88XX_TC_LINE). rtl/cpu/mb88_sv/mb88_core.sv:169 Two mutually-exclusive sources feed the ONE counter (a chip uses internal OR external mode, never both): internal clock (ena_timer & pio7 = MAME 0x80), OR external TC falling edge (pio6 = MAME 0x40). rtl/cpu/mb88_sv/mb88_core.sv:173 MCU-TIMER-FIX-2026-07-11: pio7 gate (MAME 0x80); TC-TIMER-FIX-2026-07-17: + external TC path (pio6/MAME 0x40) rtl/cpu/mb88_sv/mb88_core.sv:180 ---- SERIAL receive engine (MAME serial_timer). rtl/cpu/mb88_sv/mb88_core.sv:184 MAME SERIAL_PRESCALE=6 divides the MB88 PIN clock; `ce` is already pin/6 (MCU_CEN_DIV), so the /6 must not be applied twice. rtl/cpu/mb88_sv/mb88_core.sv:192 MAME: SB = (SB>>1) \| (si?8:0) rtl/cpu/mb88_sv/mb88_core.sv:211 MAME clears all pending on take rtl/cpu/mb88_sv/mb88_core.sv:218 outO: cf=1->oh, cf=0->ol (MAME write_pla 8-bit / VHDL). Says it matches, follows or was checked against MAME — 4 rtl/cpu/mb88_sv/mb88_core.sv:71 PC of the executing instruction (matches MAME) rtl/cpu/mb88_sv/mb88_core.sv:213 executing instruction's own PC (matches MAME) rtl/cpu/mb88_sv/mb88_core.sv:297 jmp within page (INCPC-then-override, matches MAME) rtl/ram_rom/rom_loader.sv:3 Kangaroo ROM loader ROM layout matched to MAME kangaroo.cpp Says it was translated, ported or taken from MAME — 4 rtl/Kangaroo.sv:3 Kangaroo top-level module Copyright (C) 2026 Rodimus Based on MAME kangaroo.cpp rtl/Kangaroo_CPU.sv:3 Kangaroo Main CPU Board (TVG-1-CPU-B) Based on MAME kangaroo.cpp by Ville Laitinen, Aaron Giles rtl/Kangaroo_CPU.sv:445 The horizontal BLANKING BUDGET here is correct and copied from MAME (kangaroo.cpp: set_raw(10_MHz_XTAL, 3202, 02, 256*2, 260, 8, 248) -> htotal 640, active 512, so 128 clocks / 12.8 us of blanking). rtl/Kangaroo_SND.sv:3 Kangaroo Sound Board (TVG-1-CPU-B, sound section) Based on MAME kangaroo.cpp
KickAndRun# Kick and Run MiSTer-devel/Arcade-KickAndRun_MiSTer @ 4224a5dd MAME compared: taito/kikikai.cpp Read: 111 HDL files, 22,035 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	9%
Statements: 6 toward hardware, 1 toward MAME Cites hardware documentation that MAME's driver does not — 6 rtl/core.v:128 bit 2 is ROM1/0 switch, pin14 is connected to the bank register through PAL16G rtl/ym2203/deprecated/jt12_opram.v:20 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots. rtl/ym2203/jt12_exprom.v:19 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots. rtl/ym2203/jt12_logsin.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots. rtl/ym2203/jt12_op.v:19 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots. rtl/ym2203/jt12_reg.v:329 memory for CH registers Block/fnum data is latched until fnum low byte is written to Trying to synthesize this memory as M-9K RAM in Altera devices turns out worse in terms of resource utilization. Cites MAME source — 1 rtl/ym2203/jt12_lfo.v:78 same values as in MAME
Klax# Klax MiSTer-devel/Arcade-Klax_MiSTer @ c071c8da MAME compared: atari/klax.cpp + 2 related file(s) Read: 24 HDL files, 6,027 lines (Quartus project)	MiSTer official	Both	medium	76%
Statements: 49 toward hardware, 57 toward MAME, 7 not counted Cites hardware documentation that MAME's driver does not — 43 Klax.sv:238 Leaving self-test resetting the game is authentic, not a defect: the test code stops petting the watchdog, the LS197 @5B bites and reboots the board. rtl/klax_addr_decode.v:4 Transcribed from the DUMPED production decode PAL: GAL16V8 136075-1000 at 11C (136075-1000.11c.bin, jedutil) feeding the 74F138 at 11B (schematic Sheet 3). rtl/klax_addr_decode.v:6 The schematic draws a 24-pin PAL20L10 at 11C, but Sheet 3 notes "USE 16L8 IF SLAPSTIK IS NOT USED" — production Klax has no slapstic, and the 16L8-class GAL at 11C is exactly what MAME dumped. rtl/klax_addr_decode.v:21 MA16 sub-selects color RAM (0x3E pages, /CTIME path, F257 @5N) vs the single 8Kx16 video RAM (2X/2Y). rtl/klax_addr_decode.v:86 74F138 @11B: Y = {SELC,SELB,SELA} pin levels. rtl/klax_addr_decode.v:105 /VRAM sub-decode (video side, Sheets 4/5/8): MA16=0 -> color RAM (/CTIME = MA16 during the CPU slot, F257 @5N) MA16=1 -> 8Kx16 video RAM; chip select VRA14=MA14, MA15 unused. rtl/klax_audio_filter.v:2 Klax Analog Audio Output Filter (board-level, Sheet 4) rtl/klax_audio_filter.v:4 The MSM6295 @14D drives a 6779.44 Hz zero-order-hold DAC. rtl/klax_audio_filter.v:11 SILICON REFERENCE - Klax schematic package, Figure 5-1 Sheet 4 of 9 (the sheet spans two pages: MSM6295 + first stage, then the rest): rtl/klax_cpu_bus.v:9 DTACK (schematic Sheet 2): every bus cycle COMPLETES on real hardware — there is no such thing as a stalling unmapped access. rtl/klax_cpu_bus.v:10 The LS163A at 10B (clock RCLOCK = the 7.16 MHz pixel/CPU clock, sync-cleared while BAS is idle) loads {D,C,B,A} = {+5V, PVCPU\|/VRAM, /PCM, /EEPROM} once per cycle (LD/ENP self-sequenced from QD) and counts to 15; RCO -> DTACK -> /DTACK. rtl/klax_cpu_bus.v:20 PVCPU comes from the VRAM arbitration state machine: the dumped 9W GAL (136075-1003 "MOBL2", registered at 14.318 MHz) generates the pre-VAS slot code from the H-counter phase; PVCPU = PVAS0 & PVAS1 & VREQ (LS11 @10U), VREQ = NOR(DTACK, /VR rtl/klax_cpu_bus.v:28 Interrupt acknowledge: VPA = NAND(BAS,FC2,FC1,FC0) (F20 @9B) asserts combinationally during an IACK cycle, while DTACK needs at least one RCLOCK edge — VPA always wins the race and the 68000 autovectors. rtl/klax_cpu_bus.v:121 Input mapping (schematic Sheet 5 + the 6W dump for the markers): i2=VREQ i3/i4/i5=1H/2H/4H (SOS hcnt bits = (hc+12) mod 8) i6=RCLOCKB i7=HBLANK (hc>=336) i8=NXL^NXLDL line-boundary marker i9=/PFHST (low hc 430..445, from the dumped 6W /P rtl/klax_cpu_bus.v:201 Combinational PVAS outputs (o13/o18) at the RCLOCK sample point (tick0 inputs: i6=0, i8=nxlmark_t0) and PVCPU (LS11 @10U). rtl/klax_cpu_bus.v:214 LS163A @10B wait-state counter (RCLOCK cadence). rtl/klax_irq.v:4 Schematic Sheets 5 and 2: an LS74 at 5K with D = P = +5V, clocked by CK = VBLANK \| ~32V (LS32 @10N + LS04 @9N), cleared by /VACK (the 0x360000 write). rtl/klax_irq.v:6 /Q = /VINT drives IPL2 through the LS08 @7B (the other input is the pulled-up /SINT from the unstuffed AUX connector); IPL1/IPL0 are tied high, so /VINT is IRQ level 4. rtl/klax_palette.v:4 Silicon (schematic Sheet 8): one 2Kx8/35 SRAM at 11J holds TWO banks of 512 IRGB_1555 entries. rtl/klax_playfield.v:187 Silicon DAC truth (schematic Sheet 9): each channel is a 6-bit R/2R ladder whose LSB is the shared intensity bit — channel = {color5, I}. rtl/klax_sys.v:298 === Output Latch (0x260000 write) === Documented in the Klax manual memory map (Figure 5-2, "LATCH"). rtl/klax_sys.v:316 Silicon notes (schematic Sheet 2): the latch is an LS174 at 2A clocked by /LATCH = R//W \| /PAR — i.e. ANY write anywhere in the 0x26 page (P1 and P2 word addresses alike) clocks it, so the strobe below covers cs_input_p1 and cs_input_p2. rtl/klax_sys.v:323 D13 = CBANK, the color-RAM bank select (color RAM A9, Sheet 8) — routed to the palette below; the game never sets it. rtl/klax_sys.v:342 === OKI MSM6295 ADPCM Sound === u_oki is the chip (bit-exact vs MAME); u_audio_filter is the board's analog output stage around it (Sheet 4). rtl/klax_sys.v:368 === Analog output filter (LM324 18C sections, Sheet 4) === 5-pole low-pass between the DAC pin and the speaker: -3 dB at 790 Hz, -49.6 dB at the 6779.4 Hz first image. rtl/klax_sys.v:380 === EEPROM === sys_reset: the write-unlock latch (LS74 @5K) is cleared by /SYSRES on the PCB, so a watchdog bite re-locks it. rtl/klax_top_mister.v:134 The SOS-2 custom chip (9Y) emits the 1H..256H counter taps; the 6W PAL decodes /PHSYNC = hc 352..379 (28 px) and HBLANK (336 visible). rtl/klax_top_mister.v:138 VSYNC/VBLANK are generated inside the SOS-2 custom chip (not in any dumped PAL), so exact placement needs a scope capture. rtl/klax_top_mister.v:142 The PCB delays it through the LS174 @17K (2H clock, R102 tap = stage 3 stuffed, Sheet 8) before the monitor: +10 px. rtl/klax_top_mister.v:651 Silicon DAC truth (schematic Sheet 9): 6-bit R/2R ladder per channel, LSB = the shared intensity bit ({color5, I}); MAME's IRGB_1555 decoder is identical (pal6bit((c << 1) \| i)). rtl/klax_watchdog.v:4 Schematic Sheet 2: an LS197 4-bit counter at 5B clocked by VBLANK (QA ripples into CK2), with data inputs {D,C,B,A} = {+5V,GND,GND,GND}, count/load pin driven by /WDOG (the 0x2E0000 write, gated by the WDIS service jumper), async /CLR = POW README.md:8 It was built from the PCB schematics and the dumped on-board PALs, with MAME as a cross-reference rather than as the specification. README.md:118 What makes this core worth having is how much of it came off the schematics and the dumped PALs rather than out of an emulator: README.md:130 Every bus cycle completes. DTACK comes from the LS163A at 10B, loaded from the decode: 0 wait states by default, +1 for EEPROM, +2 for the OKI, and 0-or-4 f README.md:133 IACK is handled too — `VPA` from the F20 at 9B always beats DTACK. README.md:135 IRQ from the LS74 at 5K, clocked by `VBLANK \| ~32V` and cleared by `/VACK`, giving IRQ4 at scanlines 64, 128, 192 and 240 only. README.md:139 LS197 watchdog at 5B, fully modelled including its power-on state: it clears to 0, which holds the board in reset for 8 frames before the game starts. README.md:146 DAC-exact colour. Sheet 9 is a 6-bit R/2R ladder per channel whose LSB is a shared intensity bit, so the output follows the ladder rather than a naive bit e README.md:151 JAMMA-accurate HSync. `/PHSYNC` from the dumped 6W PAL is delayed through the LS174 at 17K — only the stage-3 tap is stuffed — for +10 pixels, putting monit README.md:154 OKI MSM6295 ADPCM decoding that is bit-exact against a MAME-0.288 golden model, plus — unlike MAME, which models none — the PCB's analog audio output filt README.md:180 It appears in no dumped PAL, so it needs a scope capture on the 9Y VSync pin. README.md:201 \| Address decode, DTACK, IACK \| Dumped GAL equations transcribed and replicated, then exercised by the real TG68K in a mixed-language simulation \| Reset-vector README.md:207 \| Analog audio filter \| Against a golden model re-derived from the Sheet 4 component values. The generator also asserts that the coefficient literals in the RTL Cites hardware references or measurements that MAME's driver also gives — 7 rtl/klax_addr_decode.v:65 --- 11C GAL dedicated outputs (single product terms) --- — also in MAME: 11C atari/klax.cpp:526 rtl/klax_addr_decode.v:73 --- 11C GAL F138 select encoder (o12=SELA, o13=SELB, o14=SELC) --- Active-low sums straight from the dump; pin low when a term matches. — also in MAME: 11C atari/klax.cpp:526 rtl/klax_cpu_bus.v:4 Owns the 68000 address decode boundary: - chip selects from the dumped 11C decode GAL (klax_addr_decode) - DTACK generation modeled on the real wait-state hardware - CPU read-data mux (open bus = 0xFFFF, data-bus pull-ups) — also in MAME: 11C atari/klax.cpp:526 rtl/klax_cpu_bus.v:113 VRAM arbitration replica: 9W GAL (MOBL2) + LS11 PVCPU — also in MAME: 9W atari/klax.cpp:529 rtl/klax_cpu_bus.v:158 Equations verbatim from jedutil on 136075-1003.9w.bin. — also in MAME: 136075-1003 atari/klax.cpp:529 rtl/klax_top_mister.v:133 H SYNC: GROUND TRUTH reverse-engineered from the dumped sync PAL16R6 at 6W (Atari 136075-1004; 136075-1004.6w.bin) via jedutil. — also in MAME: 6W atari/klax.cpp:530, 136075-1004 atari/klax.cpp:530, 136075-1004 atari/klax.cpp:530 rtl/klax_top_mister.v:142 /PHSYNC from the dumped 6W PAL = hc 352..379. — also in MAME: 6W atari/klax.cpp:530 Says it was checked on “real hardware” — 1 README.md:213 The logic in this release is the same logic that was validated on hardware on 2026-07-27. Notes where it differs from MAME — 5 Klax.sv:240 MAME cannot reproduce that at all - its Klax watchdog is instantiated but never enabled, so MAME gets stuck in self-test forever (verified: frames 699-1900 byte-identical). rtl/klax_addr_decode.v:12 Headline hardware facts modeled here (all differ from MAME's klax_map): - MA22/MA23 reach no decoder: the whole map MIRRORS x4 across the 24-bit space (only cpu_addr[21:0] participates below). README.md:10 Where the two disagree, the silicon wins — so a few behaviours here deliberately differ from MAME. README.md:96 MAME cannot reproduce this, because its Klax watchdog is never enabled. README.md:154 OKI MSM6295 ADPCM decoding that is bit-exact against a MAME-0.288 golden model, plus — unlike MAME, which models none — the PCB's analog audio output filt Cites MAME source — 49 Klax.sv:4 Debuted 1989; MAME dates every set 1990 from the ROMs' own internal build stamps (parent set: 13FEB1990 11:10:09), and the MRAs follow. Klax.sv:211 JAMMA "Button 2" is an alternative pin, not a second function, which is why MAME declares only BUTTON1 per player. rtl/klax_addr_decode.v:6 The schematic draws a 24-pin PAL20L10 at 11C, but Sheet 3 notes "USE 16L8 IF SLAPSTIK IS NOT USED" — production Klax has no slapstic, and the 16L8-class GAL at 11C is exactly what MAME dumped. rtl/klax_cpu_bus.v:36 MAME differs on both counts (no wait states, unmapped reads return 0) — silicon over MAME. rtl/klax_eeprom.v:5 MAME map: 0x0E0000-0x0E0FFF, .umask16(0x00ff) 0x1F0000-0x1FFFFF write unlock rtl/klax_inputs.v:5 P1 bit 11 is the active-high screen vblank status line from MAME's P1 port definition. rtl/klax_inputs.v:8 MAME reference: klax.cpp input_ports, P1/P2 definitions. rtl/klax_irq.v:19 MAME divergence (intentional, silicon over MAME): MAME's scanline timer (klax.cpp scanline_update, every 32 lines, "(scanline & 32) == 0 && !vblank") fires an EXTRA IRQ4 at scanline 0 that the real circuit cannot generate. rtl/klax_mob_ram.v:4 CPU-visible storage from the MAME Klax map: 0x3F0F80-0x3F0FFF: Motion object SLIP RAM, 128 bytes / 64 words 0x3F2000-0x3F27FF: Motion object RAM, 2 KB / 1024 words rtl/klax_motion_objects.v:20 mame/sprite.h draw_async() — sprite bitmap sized to the rtl/klax_motion_objects.v:22 mame/klax.cpp s_mob_config — all field masks; gfx layout rtl/klax_motion_objects.v:25 Coordinate model (equivalent to MAME's clipping; proved in simulation against the atarimo.cpp reference quoted above): top9 = (0 - (yfield + height8)) & 511 delta9 = (line - top9) & 511, covers iff delta9 < height8 X writes wrap mod 51 rtl/klax_motion_objects.v:39 Measured over the attract-mode gameplay demo (MAME, frames 2400-3600): Klax peaks at only 4 motion objects on any scanline (<=14 distinct/frame), vs the 1024-link iteration cap (MAME's MAX_PER_BANK, implemented below) and the time budget (p rtl/klax_motion_objects.v:142 Decoded object (atarimo.cpp render_object field extraction) rtl/klax_motion_objects.v:152 Y coverage (verified atarimo.cpp math, 9-bit domain) rtl/klax_motion_objects.v:177 Tile column draw position: with hflip the first code is drawn at the rightmost column (atarimo.cpp:479-484) rtl/klax_oki6295.v:4 MAME reference (0.288): okim6295.cpp / okiadpcm.cpp; klax.cpp configures OKIM6295(config, "oki", 14.318181 MHz / 4 / 4, PIN7_HIGH) and maps byte read/write at 0x270001 on the 68000 lower data lane. rtl/klax_oki6295.v:22 - The MAME region is 0x40000 bytes with only 0x00000-0x1FFFF loaded from ROM; the rest is zero-filled, so byte reads above 128KB return 0x00 (phrases reaching there decode silence-ish ramps, busy stays set for the programmed length). rtl/klax_oki6295.v:29 This is the integer-exact equivalent of MAME's float stream (add_int scale 2048, stream unit mapped to 32768). rtl/klax_oki6295.v:39 - The busy bit rises a few hundred ns after the second command byte (phrase table fetch); MAME models it as instant. rtl/klax_oki6295.v:77 Phrase addresses are 18 bits (masked to 0x3FFFF like MAME); nibble addresses carry one extra LSB. rtl/klax_oki6295.v:200 Byte feeding the decoder: addresses above the 128KB ROM load read as 0x00 (MAME zero-fills the unloaded top half of the 0x40000 region). rtl/klax_oki6295.v:403 Any byte is consumed here, even one with bit 7 set (MAME: the voice mask is simply bits 7:4). rtl/klax_oki6295.v:459 signal * volume_fraction with MAME's truncate-toward-zero rounding then a >>>5 scale. rtl/klax_oki6295.v:472 clamp(16 * sum, -32768, +32767): one full-volume voice spans the full output range; concurrent loud voices saturate, exactly like MAME's stream conversion. rtl/klax_oki6295.v:608 MAME okim6295 volume table: ~3dB steps, indexes >= 9 are silent. rtl/klax_palette.v:12 The game never sets CBANK, so bank 0 is the only one it ever uses — MAME models exactly that slice (1KB byte palette at 0x3E0000-0x3E07FF on the upper data lane, klax.cpp .umask16(0xff00)). rtl/klax_playfield.v:12 Tile entry format (from MAME klax.cpp:125-132): data1 = pf_ram[tile_index]: [12:0] = tile code (0..8191, indexes into tile ROM) [15] = flip_x (horizontal flip) data2 = pfx_ram[tile_index]: [11:8] = color bank (0..15) rtl/klax_playfield.v:32 MAME references: klax.cpp:125-132 get_playfield_tile_info klax.cpp:405 TILEMAP config: TILEMAP_SCAN_COLS, 60, 32 klax.cpp:403 PALETTE: IRGB_1555, 512 entries, 8-bit membits klax.cpp:366 GFXDECODE: tiles at palette base 2 rtl/klax_playfield.v:119 Klax hardware has NO playfield scroll registers: the tilemap is drawn at a fixed origin (MAME agrees - klax.cpp instantiates TILEMAP_SCAN_COLS 60x32 and never calls set_scrollx/set_scrolly), and all three klax_playfield instantiations tie s rtl/klax_playfield.v:189 MAME is identical: IRGB_1555 -> pal6bit((c << 1) \| i). rtl/klax_prog_rom.v:43 Convert the flat MRA stream to the MAME/68000 byte layout in hardware. rtl/klax_sys.v:152 See klax_watchdog.v for the silicon reference and the note on MAME leaving its watchdog disabled. rtl/klax_sys.v:302 D10 coin counter 2 (right) D11 coin counter 1 (left) D12 spare D13 color-RAM bank select MAME models the write as a no-op (klax.cpp latch_w() is empty). rtl/klax_sys.v:304 A MAME trace of a full boot+attract+demo run shows the game only ever drives D8 -- written 0 then 1 once at boot (pc 0x005c7c/94, ~frame 6) and never touched again; D13 is never set and the coin counters only click an external mechanical me rtl/klax_sys.v:344 Keeping them separate keeps the chip model pure and independently verifiable against MAME. rtl/klax_top_mister.v:651 Silicon DAC truth (schematic Sheet 9): 6-bit R/2R ladder per channel, LSB = the shared intensity bit ({color5, I}); MAME's IRGB_1555 decoder is identical (pal6bit((c << 1) \| i)). README.md:8 It was built from the PCB schematics and the dumped on-board PALs, with MAME as a cross-reference rather than as the specification. README.md:132 MAME models no wait states at all. README.md:136 MAME fires an extra IRQ4 at scanline 0 that the silicon cannot produce; this core follows the silicon. README.md:141 MAME leaves its Klax watchdog disabled, so it never fires at all. README.md:177 These cannot be settled from dumps, schematics or MAME, and would need measurement on a real PCB. README.md:202 \| Playfield renderer \| MAME-dumped tilemap and palette RAM rendered through the RTL pipeline, compared against MAME's own frame \| Pixel-exact \| README.md:203 \| Motion objects \| MAME-dumped MOB, SLIP, tilemap and palette RAM rendered through the full MiSTer top, compared against MAME at 336 × 240 \| 98.50 % match at of README.md:205 \| Tile pixel decode \| Compared pixel-by-pixel against the MAME tile formula \| Exact \| README.md:206 \| OKI MSM6295 \| Sample-for-sample against a MAME-0.288-equivalent golden model, driven by the real sample ROMs \| Bit-exact in audio and status, zero mismatches README.md:311 Klax debuted in 1989; the ROMs' own internal build stamps read 1990, which is why MAME dates every set 1990 and the MRAs follow. README.md:319 The MAME team — `klax.cpp` (Aaron Giles), `atarimo.cpp`, `okim6295.cpp` and `okiadpcm.cpp` were the cross-reference for everything the schematics do not set README.md:321 References in the RTL comments of the form `mame/klax.cpp` point at MAME's own sources. Says it matches, follows or was checked against MAME — 7 rtl/klax_motion_objects.v:10 Behavior is implemented from verified MAME 0.288 sources: mame/atarimo.cpp build_active_list() — SLIP[line>>3] start link, linked walk on word0[7:0], visited-array stop, MAX_PER_BANK=1024 iteration cap (maxperline=0) mame/atarimo.cpp ren rtl/klax_motion_objects.v:43 The line abort is therefore unreachable by Klax content (~250x margin); MAME models no time-based dropout (maxperline=0 -> the 1024 cap only), so the RTL matches MAME in every case the game produces. rtl/klax_oki6295.v:9 Verified bit-exact against a MAME-0.288-equivalent golden model by a sample-for-sample parity testbench driven by the real Klax sample ROMs. rtl/klax_oki6295.v:13 Behavioral contract (matches MAME exactly): - Command protocol: a byte with bit 7 latches a pending sample number; the next byte (any value, even with bit 7 set) is the second half: voice mask in bits 7:4, volume index in bits 3:0. rtl/klax_sys.v:342 === OKI MSM6295 ADPCM Sound === u_oki is the chip (bit-exact vs MAME); u_audio_filter is the board's analog output stage around it (Sheet 4). rtl/klax_top_mister.v:132 Totals/visible: verified from MAME klax.cpp set_raw. README.md:154 OKI MSM6295 ADPCM decoding that is bit-exact against a MAME-0.288 golden model, plus — unlike MAME, which models none — the PCB's **analog audio output filt Shares text with the MAME driver without saying so — 1 rtl/klax_oki6295.v:6 OKIM6295(config, "oki", 14.318181 MHz / 4 / 4, PIN7_HIGH) and maps byte — shares text with atari/klax.cpp:432
Kyugo# Airwolf, Flashgal, Gyrodine, Legend … MiSTer-devel/Arcade-Kyugo_MiSTer @ 2243bbd8 MAME compared: orca/kyugo.cpp Read: 8 HDL files, 2,319 lines (Quartus project)	MiSTer official	Mostly MAME	low	68%
Statements: 1 toward hardware, 41 toward MAME Says it was checked on “real hardware” — 1 rtl/Kyugo_CPU.sv:1068 The flip_req branch (sy_calc - 16) is a MEASURED offset against a matched MAME reference frame, confirmed on hardware. Cites MAME source — 31 Arcade-Kyugo.sv:66 Kyugo is MIXED-orientation per MAME ROT (vertical: Gyrodine/Repulse/99/SonOfPhoenix/SRD; horizontal: Flashgal/Legend/Airwolf). rtl/Kyugo_CPU.sv:6 MAME reference: kyugo.cpp Hardware: Z80 CPU1 + Z80 CPU2 @ 3.072 MHz (XTAL 18.432 / 6) 2x AY-3-8910 @ 1.536 MHz (18.432 / 12) Screen: 396x260 total, visible 288x224 (lines 16-239), 59.66 Hz rtl/Kyugo_CPU.sv:201 ------------------------------------------------------- Watchdog (Gyrodine) -------------------------------------------------// Watchdog (the cold-boot SUB-CHECK recovery mechanism — see wdog_arm above): MAME gyrodine() adds WATCHDOG_TIMER; rtl/Kyugo_CPU.sv:273 Sub CPU memory decode — variant-aware (kyugo.cpp 484-532) rtl/Kyugo_CPU.sv:313 I/O port decode — variant-aware (kyugo.cpp 547-583) AY1 base port: Gyro/Repulse = 0x00, Flashgal = 0x40, SRD/Legend = 0x80 AY2 base port: Gyro = 0xC0, Repulse = 0x40, Flashgal = 0x80, SRD/Legend = 0x84 Coin counter: Repulse/Flashgal = 0xC0/ rtl/Kyugo_CPU.sv:338 Coin counter (bit 0 of data per MAME coin_counter_w) rtl/Kyugo_CPU.sv:423 CPU1 data bus mux — spram1 reads return value \| 0xF0 (lower nibble only per MAME spriteram_2_r) rtl/Kyugo_CPU.sv:550 MAME negates BG scroll_x whenever the game requests flip (kyugo.cpp:409-412: set_scrollx(0, -(lo+hi256)) if flip_screen() else positive; scroll_y is never negated, :414). rtl/Kyugo_CPU.sv:557 World offset when not flipped is +32 (MAME set_scrolldx(-32, ...), kyugo.cpp:271; world offset = -dx). rtl/Kyugo_CPU.sv:573 base_h_cnt's total period (396, kyugo.cpp:946 screen.set_raw(...,396,0,288,260, 16,240)) is not a multiple of 8, and v_cnt only increments on the same tick base_h_cnt wraps 395->0 -- too late for column 0 of the new row to be ready via the rtl/Kyugo_CPU.sv:663 Per-tile attr flips (bit2=flipX, bit3=flipY, MAME get_bg_tile_info) still apply as normal. rtl/Kyugo_CPU.sv:715 MAME get_bg_tile_info: TILE_FLIPYX((attr&0x0c)>>2) -> flipX = attr bit 2, flipY = attr bit 3. rtl/Kyugo_CPU.sv:719 flipX = attr bit 2 (MAME) rtl/Kyugo_CPU.sv:720 flipY = attr bit 3 (MAME) rtl/Kyugo_CPU.sv:750 Pen = {plane0, plane1, plane2}: MAME planeoffset[0] (= first ROM third, bg0) is the MSB. rtl/Kyugo_CPU.sv:780 6-bit colour code: MAME color = color_codes[4:0]<<1 \| fgcolor rtl/Kyugo_CPU.sv:855 Pen = {plane0, plane1}: plane0 (fg_p0_bit, high nibble) is the MSB per MAME planeoffset[0]. rtl/Kyugo_CPU.sv:860 {color_codes[4:0], fgcolor, pen[1:0]} per MAME rtl/Kyugo_CPU.sv:937 MAME sy/sx wrap (sy = (257 - y_raw); if > 240 then -256) rtl/Kyugo_CPU.sv:941 MAME computes this sx wrap in a wide int (kyugo.cpp:369-370: sx = (x>320) ? rtl/Kyugo_CPU.sv:950 Row hit (in SS_FR0): diff = eval_y - sy_full (9-bit two's complement); hit if diff[8:8]=0 (positive) Sprite row-stacking direction: MAME draws cell row y at `sx, flip ? rtl/Kyugo_CPU.sv:951 sy - 16y : sy + 16y` (kyugo.cpp:401) -- when flipped, the 16 cells of a sprite stack UPWARD from sy instead of downward. rtl/Kyugo_CPU.sv:974 Per-sprite flip attributes must invert when the game requests flip (MAME kyugo.cpp:391-395: if (flip) { flipx = !flipx; flipy = !flipy; }). rtl/Kyugo_CPU.sv:978 flipx is XORed with flip_req: the screen_x pre-mirror below (screen_x_signed) cancels the rotation's position mirror on this axis but not MAME's per-cell mirror, so flipx must supply that mirror itself. rtl/Kyugo_CPU.sv:980 flipy needs no XOR: the rotation's Y mirror already supplies MAME's flipy inversion, sy mirror, and stacking reversal together. rtl/Kyugo_CPU.sv:997 Pen = {plane0, plane1, plane2}: MAME planeoffset[0] (= first ROM third, spr0) is the MSB. rtl/Kyugo_CPU.sv:1003 MAME's sprite flip is asymmetric: it mirrors sy (240-sy), inverts flipx/flipy and reverses stacking, but passes sx through UNCHANGED (kyugo.cpp:401). rtl/Kyugo_CPU.sv:1004 screen_rotate mirrors both render axes, which is correct for BG (MAME's tilemap flip also does both) but over-mirrors sprites on X -- render X is the displayed vertical on the ROT90 sets. rtl/Kyugo_CPU.sv:1062 Sprite Y mirror: MAME applies `if (flip) sy = 240 - sy;` AFTER the 257-raw wrap (kyugo.cpp:376-377), so it applies to sy_calc here, not to sy_y_raw. rtl/Kyugo_CPU.sv:1063 MAME does NOT mirror sprite X when flipped -- sx is passed through unchanged at kyugo.cpp:401 -- so sx_full stays as-is; that asymmetry is intentional on the reference hardware, not a bug here. rtl/Kyugo_CPU.sv:1069 The algebra from MAME's `240 - raw` predicts -17; the measured, HW-confirmed value is -16. Says it matches, follows or was checked against MAME — 6 rtl/Kyugo_CPU.sv:47 Pixel clock: 49.152 MHz 4/32 = 6.144 MHz = XTAL/3 (matches MAME set_raw(XTAL/3, 396, 0, 288, 260, 16, 240) → 59.6575 Hz). rtl/Kyugo_CPU.sv:945 Computed in an 11-bit signed field instead so 256..320 stays positive and only 321..511 goes negative, matching MAME exactly. rtl/Kyugo_CPU.sv:1006 Pre-mirroring here cancels the rotation's X mirror, leaving sprites unmirrored in display space to match MAME; mirroring preserves the in-range test since out-of-range values stay out on both sides. rtl/Kyugo_CPU.sv:1009 Cell-internal orientation and stacking direction need no separate correction: the rotation's both-axis mirror already matches MAME inverting both flipx and flipy, and the +16y stacking used here plus the rotation lands the same as MAME's -1 rtl/Kyugo_CPU.sv:1068 The flip_req branch (sy_calc - 16) is a MEASURED offset against a matched MAME reference frame, confirmed on hardware. rtl/Kyugo_CPU.sv:1142 Matches MAME screen_update, which draws BG → sprites → FG, so FG is always on top. Shares text with the MAME driver without saying so — 4 rtl/Kyugo_CPU.sv:47 Pixel clock: 49.152 MHz * 4/32 = 6.144 MHz = XTAL/3 (matches MAME set_raw(XTAL/3, 396, 0, 288, 260, 16, 240) → 59.6575 Hz). — shares text with orca/kyugo.cpp:946 rtl/Kyugo_CPU.sv:928 Slot offset: offs = 2(n%12) + 64(n/12), then base 0x28 — shares text with orca/kyugo.cpp:366 rtl/Kyugo_CPU.sv:951 Sprite row-stacking direction: MAME draws cell row y at `sx, flip ? sy - 16y : sy + 16y` — shares text with orca/kyugo.cpp:401 rtl/Kyugo_CPU.sv:975 if (flip) { flipx = !flipx; flipy = !flipy; }). Unlike the BG, which gets its mirror for free — shares text with orca/kyugo.cpp:391
LadyBug# Cosmic Avenger, Dorodon, Lady Bug, Snap Jack MiSTer-devel/Arcade-LadyBug_MiSTer @ c91b6267 MAME compared: universal/ladybug.cpp + 2 related file(s) Read: 30 HDL files, 10,443 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	5%
Statements: 2 toward hardware Cites hardware documentation that MAME's driver does not — 2 rtl/ladybug_video_timing.vhd:353 From the schematics, it is the same as /VBL (just buffered). rtl/ttl_393.vhd:3 TTL 74LS393 - Dual 4-Bit Binary Counter
LaserdiscGames# Cliff Hanger, Dragon's Lair, Space Ace MiSTer-devel/Arcade-LaserdiscGames_MiSTer @ d0ba4d41 MAME driver: not found Read: 38 HDL files, 11,677 lines (Quartus project)	MiSTer official	Both	medium	67%
Statements: 25 toward hardware, 53 toward MAME Cites hardware documentation that MAME's driver does not — 3 Arcade-LaserdiscGames.sv:137 Program bytes occupy a different slice of ioctl index 0 per game, so the write MUST be gated per board -- ungated, Super Don's char and PROM data would land on top of program space, and Mach 3's tile and sprite data would wrap round the 64K rtl/DragonsLair_CPU.sv:162 Bank select = A15:A13, device select = A5:A3 (A3/A4/A5 per the schematics) rtl/superdon/SuperDon.sv:4 Memory: 0x0000-0x3FFF ROM (16K) 0x4000-0x47FF RAM (2K) 0x5C00-0x5FFF video RAM (1K, 32x32 tile codes) Ports: IN 00 joystick 01 buttons/coins 02 DSW1 03 DSW2 04 LD status OUT 00 LD command 04 SN76496 08 latch 0C/0D HD46505 (fixe Ships hardware documentation files — 21 Useful Information/schematics/9900.PDF Useful Information/schematics/Badlands_Manual.pdf Useful Information/schematics/Begas_Battle_Manual.pdf Useful Information/schematics/Cliff_Hanger_and_Goal_to_Go_Schematics.pdf Useful Information/schematics/Cobra_Command_Conversion_for_Cliff_Hanger_Installation_Instructions.pdf Useful Information/schematics/Cobra_Command_Conversion_for_Dragons_Lair_Installation_Instructions.pdf Useful Information/schematics/DL2_Wiring.txt Useful Information/schematics/Dragons Lair 2 Schematics.pdf Useful Information/schematics/Dragons_Lair_II_Owners_Manual.pdf Useful Information/schematics/Dragons_Lair_II_Schematics_Australia.pdf Useful Information/schematics/Dragons_Lair_and_Space_Ace_Operation_and_Maintenance_Manual.pdf Useful Information/schematics/Firefox_Operators_Manual_with_Illustrated_Parts_Lists_1st_printing.pdf Useful Information/schematics/GPW_Sound.jpg Useful Information/schematics/PR-8210 Technical Manual.pdf Useful Information/schematics/Schematic_Package_Supplement_to_Firefox_Operators_Manual_2nd_printing.pdf Useful Information/schematics/Thayers_Quest_Operation_and_Service_Manual.pdf Useful Information/schematics/Votrax_SC-02_SSI-263A_Phoneme_Speech_Synthesizer_Data_Sheet_1985_text.pdf Useful Information/schematics/mach3_s.pdf Useful Information/schematics/superdon_m.pdf Useful Information/schematics/superdon_s.pdf rtl/cpu/MCL86/Core/Lattice_XO2_Small_Example/MCL86_Lattice_XO2_impl1.jed Notes where it differs from MAME — 1 rtl/superdon/SuperDon.sv:17 Read off the Main PCB (1) schematic -- MAME's MASTER_CLOCK/8 is wrong, Daphne's 5 MHz is right. Cites MAME source — 43 Arcade-LaserdiscGames.sv:106 One Gottlieb/Mylstar rev-2 board runs all three; MAME's cobram3 config differs from g2laser only in sound-board mods. Arcade-LaserdiscGames.sv:148 Dragon's Lair II has NO scoreboard: the original scored nothing, Daphne's lair2.cpp contains no scoreboard code at all (unlike lair.cpp) and MAME's dlair2.cpp instantiates no such device. Arcade-LaserdiscGames.sv:780 4-way stick + one action button; MAME superdq IN0/IN1 rtl/DragonsLair_CPU.sv:208 SSI-263 speech chip, ports 0x00-0x07 (MAME thayers.cpp maps all eight; the chip ignores the register address on reads). rtl/DragonsLair_CPU.sv:369 XCK is 860 kHz (MAME thayers.cpp: SSI263HLE(config, m_ssi, 860000)). rtl/DragonsLair_CPU.sv:517 ------------------------------------------------- Thayer's COP421 + interrupts -----------------------------------------------// The COP is Thayer's only MCU: its D port drives the timer tick (D0) and keyboard data-ready (D1), both active l rtl/DragonsLair_CPU.sv:534 The periodic source is a board one-shot: T = 1.1 * R30 * C53 = 8.25 ms (MAME thayers.cpp). rtl/DragonsLair_CPU.sv:555 IN (0x40): b7 and b1:0 read 0, b3 is tied to +5V (MAME irqstate_r). rtl/DragonsLair_CPU.sv:588 Z80 writes a 4-bit digit code: 0xE038-0xE03F (led_den1) -> digits[0..7] (MAME led_den1_w: m_digits[0\|off]) 0xE030-0xE037 (led_den2) -> digits[8..15] (MAME led_den2_w: m_digits[8\|off]) The 7-seg lookup (led_map in MAME) is applied at rend rtl/DragonsLair_CPU.sv:598 den1 (E038) -> digits 0..7 (MAME dlair.cpp:332) rtl/DragonsLair_CPU.sv:599 den2 (E030) -> digits 8..15 (MAME dlair.cpp:338) rtl/Thayers_COP.sv:135 The COP free-runs SK; on each FALLING edge the panel shifts out one bit of a 10-bit frame (Daphne/MAME thayers.cpp kbclk_w): rtl/cliff/CliffHanger.sv:11 Memory map (MAME mainmem): 0x0000-0x9FFF program ROM (5 x 8KB; the map extends to 0xBFFF, unpopulated) 0xE000-0xE7FF battery-backed NVRAM (5126) -- volatile here, see note 0xE800-0xEFFF RAM (2128) rtl/cliff/CliffHanger.sv:117 --------------------------------------------------------- I/O decode ----- MAME mainport (global mask 0xFF). rtl/cliff/CliffHanger.sv:133 --------------------------------------------------------- input banks ---- MAME port_r: banks 0..6 are mapped, anything above reads pulled-up 0xFF. rtl/cliff/CliffHanger.sv:145 Bit assignments are MAME's (INPUT_PORTS_START(cliffhgr) BANK5/BANK6); Daphne only labels these "button data" / "joystick data". rtl/cliff/CliffHanger.sv:233 ---- Philips VBI picture code (MAME philips_code_r) ---- 24 bits: 0xF in the top nibble marks a valid picture number, so bit 23 is set and the IRQ fires; the low 20 bits are the frame as 5 BCD digits. rtl/cliff/CliffHanger.sv:395 --------------------------------------------------------- interrupts ----- IRQ: asserted when a valid Philips code arrives each field, cleared by reading port 0x53 (MAME irq_ack_r). rtl/cliff/CliffHanger.sv:407 --------------------------------------------------------- sound ---------- Discrete: two gated 555 astables mixed (MAME cliffhgr_a.cpp). rtl/cliff/CliffHanger.sv:457 MAME stern/cliffhgr.cpp: `m_led = offset ^ 1`, offset 0 = 0x6E = lit. rtl/cliff/CliffHanger.sv:477 MAME returns 0 rtl/cliff/tms9928a_render.sv:29 Measured against MAME on the title screen: 453 wrong pixels, 86% of them at cell pixel 0 or 7. rtl/cliff/tms9928a_render.sv:129 ---- Graphics II tables ------------------------------------------------ Bases and masks per MAME tms9928a.cpp (update_table_masks + the mode-2 draw loop). rtl/cliff/tms9928a_render.sv:181 A zero nibble means "use the backdrop", as MAME's mode-2 loop does. rtl/cliff/tms9928a_render.sv:230 MAME makes that conditional on EXTVID (reg0[0]) and otherwise paints colour 0 as a real pen; we do not, deliberately. rtl/cliff/tms9928a_render.sv:236 It resolves to the backdrop, and a non-zero backdrop really does cover the picture on a real TMS -- MAME only makes pen 0 transparent, never the backdrop as such. rtl/dlair2/DragonsLair2.sv:4 I8088 in MAX mode at 10 MHz (MAME cinematronics/dlair2.cpp: XTAL(30MHz)/3, "Schematics show I8088 'max' CPU"), Sony LDP-1450 on a serial port. rtl/dlair2/DragonsLair2.sv:11 Memory map (MAME mainmem): 0x00000-0xEFFFF RAM -- external port, backed by DDR (ddram_cpu_ram); it cannot live on-chip, the core is at 75% of its M10K blocks. rtl/dlair2/DragonsLair2.sv:17 IO map (MAME, commented there; corroborated by Daphne lair2.cpp's header "IO_PORT = 0x201, COIN_PORT = 0x202, CNTL_PORT = 0x202"): 0x020 interrupt controller 0x042/0x043, 0x061 sound 0x200-0x203 io / coin / eeprom 0x2F8-0x2FF COM rtl/dlair2/DragonsLair2.sv:45 ---- controls ---- DL2 has NO DIP switches: its settings live in an EEPROM (port 0x202 b0), which is why MAME's dlair2 DIPs are explicit dummies and the OSD shows no DIP page. rtl/dlair2/DragonsLair2.sv:287 MAME is no reference here: dlair2.cpp attaches SPEAKER with no sound device, so it emulates none of this. rtl/dlair2/DragonsLair2.sv:427 --------------------------------------------------- 8259 + timer -------- MAME models two interrupts: a 60 Hz periodic one whose vector_r returns 0x20/4 = 8, and a serial one at 0x2c/4 = 11. rtl/gpworld/GPWorld.sv:4 Memory: 0x0000-0xBFFF ROM (48K) 0xC000-0xC7FF sprite RAM (64 x 8) 0xC800-0xCFFF colour RAM 0xD000-0xD7FF tile RAM (64x32 codes) 0xD800 LD-V1000 latch 0xDA00-0xDA03 8255 (sound board) 0xDA20 pedal ADC 0xE000-0xFF rtl/gpworld/GPWorld.sv:203 IN0 b4 SHIFT; IN1 b0 COIN1, b1 COIN2, b2 TEST, b3 SERVICE, b4 START (MAME). rtl/gpworld/gpw_spr_mem.sv:13 Download: ioctl index 0, 0x10000-0x3FFFF = MAME's gfx2 region (0x8000 bytes of plane 0 then 0x8000 of plane 1, per 64K bank). rtl/ldp/ldp_ldp1450.sv:72 ACK latencies from the LDP-1000A programming manual (ldp1000.cpp:99-102). rtl/ldp/ldp_transport.sv:67 MAME update_audio_enable(): unmute only at mode==PLAY && speed==1x && both channels on. rtl/mach3/Mach3.sv:5 MAME gottlieb/gottlieb.cpp `g2laser`; schematics in Useful Information/schematics/mach3_s.pdf (Logic Board A1, Interface A2). rtl/mach3/Mach3.sv:23 A write to 5805 latches a byte and the board clocks 12 bits out to the player as pulse INTERVALS: 998us = 0, 1996us = 1 (555 at 40083Hz /10, then /4 or /8 — gottlieb.cpp:876). rtl/mach3/Mach3.sv:364 MAME reads these ports straight through; the top level assembles them with the right polarity (SERVICE b0 and TILT b5 of IN1 are active LOW, everything else active HIGH). rtl/mach3/mach3_video.sv:4 Shared by M.A.C.H. 3, Cobra Command and Us vs Them: MAME's cobram3 machine config differs from g2laser only in sound-board mods, so the video hardware is identical across all three. rtl/mach3/mach3_video.sv:23 Values below are that ladder normalised to full scale; they come from MAME's documented resistances (gottlieb.cpp video_start) — sweep these first if colours look wrong on hardware, since the Logic Board A1 sheet was not available to confir rtl/superdon/SuperDon.sv:162 Active-LOW banks (MAME superdq INPUT_PORTS). Says it matches, follows or was checked against MAME — 4 rtl/DragonsLair_CPU.sv:581 The COP asserts on the falling edge of its D pins, matching MAME's cop_d_w. rtl/ldp/ldp_ldv1000.sv:67 known-inert group (matches MAME's own unimplemented stubs) rtl/ram_rom/rom_loader.sv:3 Kangaroo ROM loader ROM layout matched to MAME kangaroo.cpp rtl/video/led_band.v:11 (matches MAME dlair.lay / DragonsLair_CPU) Says it was translated, ported or taken from MAME — 5 Arcade-LaserdiscGames.sv:2 Dragon's Lair / Space Ace (US set) for MiSTer Copyright (C) 2026 Rodimus Based on MAME dlair.cpp; converted in place from the Kangaroo core copy Permission is hereby granted, free of charge, to any person obtaining a copy of this software a rtl/DragonsLair.sv:2 Dragon's Lair / Space Ace (US set) top-level game module Copyright (C) 2026 Rodimus Based on MAME dlair.cpp Thin wrapper around DragonsLair_CPU (which now contains the Z80, AY-3-8910, work RAM, program ROM, the LaserDisc HLE, the LED latche rtl/DragonsLair_CPU.sv:2 Dragon's Lair / Space Ace (US set) Main CPU Board Based on MAME dlair.cpp (dlus_map / dlair_ldv1000) by Aaron Giles Single Z80 @ (real 4 MHz) + AY-3-8910 (real 2 MHz) + Pioneer LD-V1000 laserdisc. rtl/cliff/CliffHanger.sv:3 Based on MAME stern/cliffhgr.cpp (authoritative for the I/O map and the discrete sound) and Daphne game/cliff.cpp (authoritative for PR-8210 use). rtl/ldp/ldp_ldv1000.sv:4 Ported from MAME pioneer_ldv1000hle_device. Keeps a MAME approximation — 1 rtl/gpworld/GPWorld.sv:413 MAME swaps R and B; both are guesses -- flip PAL_RB_SWAP to try MAME's.
Legionnaire# Legionnaire MiSTer-devel/Arcade-Legionnaire_MiSTer @ 39c3eb79 MAME compared: seibu/legionna.cpp + 8 related file(s) Read: 23 HDL files, 9,221 lines (Quartus project)	MiSTer official	Mostly MAME	medium	74%
Statements: 4 toward hardware, 145 toward MAME, 1 not counted Cites hardware references or measurements that MAME's driver also gives — 1 rtl/Legionnaire/Legionnaire_maincpu_map.sv:23 Main CPU memory map Legionnaire (MAME legionna.cpp legionna_map): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $100000-$1003FF RAM scratch (1KB) → BRAM (Main RAM low) $100400-$1006FF COP3 region — also in MAME: 68K seibu/legionna.cpp:46 Reports a measurement taken on the original PCB — 1 rtl/Legionnaire/Legionnaire_video_timing.sv:26 PCB measurement Blood Bros: VSync 59.4094 Hz, HSync 15.6246 kHz, master XTAL 20 MHz. Says it was checked on “real hardware” — 3 rtl/Legionnaire/Legionnaire_sprite_renderer.sv:208 byte_lo = pf_rom_data[31:24]/[15:8], byte_hi = [23:16]/[7:0] Plane order DCBA (verificato su HW, come BG/MG/FG): pen[0] dal bit "D" (byte_hi[3-sub]), pen[3] dal bit "A" (byte_lo[7-sub]). rtl/Legionnaire/Legionnaire_sprite_renderer.sv:325 Scan INVERSO 511→0 (verificato su HW: ordine sprite-su-sprite opposto al loop MAME 0→511). rtl/Legionnaire/Legionnaire_tile_layer.sv:296 Plane order verificato su HW: BG/MG = DCBA (PEN_ORDER=0), FG = BADC (PEN_ORDER=1). Cites MAME source — 130 Legionnaire.sv:330 --- Joystick to SD Gundam input mapping --- MAME P1_P2 port ($E0002): active low. Legionnaire.sv:333 MiSTer joy bits: joy[0]=R, joy[1]=L, joy[2]=D, joy[3]=U, joy[4]=A, joy[5]=B. MAME PLAYERS12 (legionna.cpp:439-444): bit[0]=UP, [1]=DOWN, [2]=LEFT, [3]=RIGHT, [4]=BTN1, [5]=BTN2, [6]=BTN3, [7]=unused (active low). Legionnaire.sv:343 Legionnaire SYSTEM port ($10074C) — MAME legionna.cpp:427-436 bit0 = START1 (active LOW) bit1 = START2 (active LOW) bit2..7 = UNKNOWN → tied 1 bit8..15 = UNKNOWN → tied 1 Coin inputs NON sono qui: vanno via SEIBU_COIN_INPUTS → Z80 → soundla Legionnaire.sv:686 ── Flip screen (CRTC reg 0x1A bit 0) ─────────────────────────────────────── MAME: BIT(reg_1a, 0) → flip_screen. Legionnaire.sv:719 ── Text layer renderer (8x8, 4bpp, 64x32 grid) ───────────────────────────── Legionnaire MAME (legionna.cpp:1563-1571): "user1" region 128KB caricato da 7.u077 + 8.u072 interleaved a 16-bit. Legionnaire.sv:740 Blood Bros Text: no scroll (MAME bloodbro.cpp non chiama set_scroll su tx_tilemap) Legionnaire.sv:774 Legionnaire CRTC scroll passthrough (MAME legionna_v.cpp:34-49 tile_scroll_w): scroll_ram[0/1] → BG (m_background_layer) scroll_ram[2/3] → MG (m_midground_layer) scroll_ram[4/5] → FG (m_foreground_layer) Nel nostro CRTC: xscroll_l0 = ram[0/ Legionnaire.sv:792 Legionnaire BG: tilemap 32x32 (legionna_v.cpp:204). Legionnaire.sv:793 MAME GFXDECODE "back" color base = 0 (gfx_legionna riga 1168), 32 colorset. Legionnaire.sv:794 HAS_TRANSP=1 perché m_background_layer->set_transparent_pen(15) in legionna_v.cpp:216 (pen 15 = trasparente, NON opaco come Blood Bros). Legionnaire.sv:816 Legionnaire MG: 16x16, 4bpp, 32x32 tilemap (MAME legionna_v.cpp:204). Legionnaire.sv:817 get_mid_tile_info_share_bgrom (legionna_v.cpp:158): MG share BG ROM, tile = (vram & 0xfff) \| 0x1000 (= seconda metà della BG ROM) color = ((vram >> 12) & 0xf) \| 0x10 (= palette set superiore: bit 4 = 1) In palette MAME "back" base = 0, Legionnaire.sv:844 Legionnaire FG: tilemap 32x32 (legionna_v.cpp:213). Legionnaire.sv:846 MAME GFXDECODE "fore" color base = 3216 = 0x200, 16 colorset. Legionnaire.sv:860 Legionnaire: bit 2 = FG (MAME legionna_v.cpp:344) Legionnaire.sv:968 MAME riferimenti: legionna_v.cpp:226-229 m_sprite_pri_mask[0..3] per Legionnaire: pri=0 → 0x0000 (cover bit 0,1,2,4 → mg,bg,fg,text → SOPRA TUTTO) pri=1 → 0xFFF0 (cover bit 0,1,2 → mg,bg,fg → sotto text) pri=2 → 0xFFFC (cover bit 0,1 → Legionnaire.sv:989 pen 0 (= nero su palette MAME BLACK init) Legionnaire.sv:995 MAME legionna_v.cpp:340 fills bitmap with m_palette->black_pen() before drawing layers. Legionnaire.sv:999 MAME screen_update_legionna (legionna_v.cpp:342-348): MG draw pri 0 → buffer bit 0 BG draw pri 1 → buffer bit 1 FG draw pri 2 → buffer bit 2 TXT draw pri 4 → buffer bit 4 sprite con pri_mask[N]: [0]=0x0000 (sopra tutti), [1]=0xFFF0 (sotto T Legionnaire.sv:1046 MAME legionna_v.cpp:340 fa bitmap.fill(black_pen()) prima dei layer. rtl/Legionnaire/Legionnaire_audio_z80.sv:25 Spec da MAME (reference/mame_seibu/seibusound.cpp + bloodbro.cpp): - Z80 @ 3.579545 MHz (XTAL 7.159090 / 2) - YM3812 (jtopl2) @ 3.579545 MHz - OKI M6295 (jt6295) @ 1.000 MHz (XTAL 12/12), PIN7=HIGH rtl/Legionnaire/Legionnaire_audio_z80.sv:31 Main↔sub comm @ 0xA0000-0xA000D: standard MAME seibu_sound_device. rtl/Legionnaire/Legionnaire_audio_z80.sv:359 MAME seibu_sound_device::main_r (reference/mame_seibu/seibusound.cpp:279): case 2,3: return sub2main[offset-2] (soundlatch data: coin/input dal Z80) case 5: return main2sub_pending ? rtl/Legionnaire/Legionnaire_audio_z80.sv:392 ─── OKI M6295 (jt6295) — PIN7_HIGH (bloodbro.cpp:872) ────────────────── rtl/Legionnaire/Legionnaire_cop3.sv:4 MAME-faithful implementation of the Seibu SEI300 chip as used by the `legionna` driver (Legionnaire 1992 — Banpresto/TAD). rtl/Legionnaire/Legionnaire_cop3.sv:7 Reference (in this repo): reference/mame_seibu/seibucop.cpp reference/mame_seibu/seibucop_cmd.ipp reference/mame_seibu/seibucop_dma.ipp reference/mame_seibu/legionna.cpp rtl/Legionnaire/Legionnaire_cop3.sv:128 MAME cop_itoa_digits[10]: BCD digits of cop_itoa (low<<0 \| high<<16). rtl/Legionnaire/Legionnaire_cop3.sv:138 MAME cop_program command table (seibucop.cpp lines 318-457) At boot, game code uploads 32 macro slots × 8 micro-op words via pgm_addr (0x100434) → slot8 + sub-index pgm_data (0x100432) → micro-op word pgm_value (0x100438) → cop_func_valu rtl/Legionnaire/Legionnaire_cop3.sv:145 MAME calls find_trigger_match(triggerval, 0xff00) to find the slot whose cop_func_trigger matches. rtl/Legionnaire/Legionnaire_cop3.sv:209 Triggers (write-only addresses) MAME legionna.cpp:172 maps cop_cmd_w to $100500-$100505 (3 words). rtl/Legionnaire/Legionnaire_cop3.sv:283 0x100410 sprite_dma_inc (MAME seibucop.cpp:1279): if x_clip in [-160, 320): cop_regs[4] += 8 cop_sprite_dma_src += 6; cop_sprite_dma_size--; cop_status bit 1 = (size > 0) ? rtl/Legionnaire/Legionnaire_cop3.sv:286 0 : 1 (Sprite DMA x_clip non implementato: assumiamo in-range come MAME default per Legionnaire — il game non usa sprite DMA via COP comunque) rtl/Legionnaire/Legionnaire_cop3.sv:324 Macro program upload — MAME seibucop.cpp lines 318-457 pgm_data writes one micro-op word to cop_program[latch_addr] AND latches the slot's trigger/value/mask from current latch regs. rtl/Legionnaire/Legionnaire_cop3.sv:423 itoa_digits (MAME 0x100590-99, 5 word). rtl/Legionnaire/Legionnaire_cop3.sv:435 Status / dist / angle (MAME seibucop.cpp:916 cop_status_r → cop_status) rtl/Legionnaire/Legionnaire_cop3.sv:446 MAME open bus rtl/Legionnaire/Legionnaire_cop3.sv:559 Trigger latches — MAME seibucop.cpp cop_cmd_w line 1069. rtl/Legionnaire/Legionnaire_cop3.sv:560 MAME dispatches on raw data after clearing cop_status bit 15. rtl/Legionnaire/Legionnaire_cop3.sv:687 MAME cop_cmd_w (seibucop.cpp:1075): rtl/Legionnaire/Legionnaire_cop3.sv:723 Restituisce canonical trigger value del slot (NB: MAME LEGACY_cop_cmd_w usa il match slot per dispatchare; in pratica equivale a restituire cop_func_trigger[slot]). rtl/Legionnaire/Legionnaire_cop3.sv:744 fade_table — MAME seibucop.cpp:733 (reverse engineered from Seibu Cup Soccer bootleg) v = pal_channel(5-bit) \| (brightness_val_xor_X) [10-bit input] low = v & 0x1F high = v & 0x3E0 return (low * (high \| (high>>5)) + 0x210) >> 10 [8-bit o rtl/Legionnaire/Legionnaire_cop3.sv:781 ── Hitbox b100/b900 scratch (MAME cop_collision_update_hitbox) ────────────── dx[i] = int8 (signed) byte basso, size[i] = uint8 (unsigned) byte alto del word descrittore @ hitadr2+2i. 3 assi (Y,X,Z) per Legionnaire. rtl/Legionnaire/Legionnaire_cop3.sv:813 Con 16-bit frac + 24 iter + z>>16: 0 divergenze di decisione vs MAME int(atan(dx/dy)128/pi) su ~640k casi (dimostrato numericamente). rtl/Legionnaire/Legionnaire_cop3.sv:1045 MAME cop_dma_trigger_w: NON modifica cop_status (vedi seibucop.cpp:741). rtl/Legionnaire/Legionnaire_cop3.sv:1051 MAME dma_tilemap_buffer: copy staging RAM → renderer BRAM src = cop_dma_src[mode] << 6 (byte addr 0x101000+ = staging) dst = i (loop counter 0..0x13FF = renderer index) count = 0x2800/2 = 5120 words rtl/Legionnaire/Legionnaire_cop3.sv:1061 MAME dma_palette_buffer: copy staging palette → renderer src = cop_dma_src[mode] << 6 (0x104000 = palette staging) dst = i (loop counter 0..0x7FF = renderer index) count = 0x1000/2 = 2048 words rtl/Legionnaire/Legionnaire_cop3.sv:1077 simplified, MAME size>>1 rtl/Legionnaire/Legionnaire_cop3.sv:1082 MAME seibucop_dma.ipp dma_palette_brightness() mode 5/4. rtl/Legionnaire/Legionnaire_cop3.sv:1085 MAME formulas: src = cop_dma_src[mode] << 6 dst = cop_dma_dst[mode] << 6 size = ((cop_dma_size << 5) - (cop_dma_dst << 6) + $20)/2 Init: src=$106000, dst=$104000, size=($827F<<5 - $4100<<6 + $20)/2 = ($104FE0 - $104000 + $20)/2 = $1000 rtl/Legionnaire/Legionnaire_cop3.sv:1096 MAME size = (((size<<5) - (dst<<6) + 0x20)/2) rtl/Legionnaire/Legionnaire_cop3.sv:1106 Skip if dst != 0 (MAME guard, dma.ipp:135) rtl/Legionnaire/Legionnaire_cop3.sv:1119 MAME cop_cmd_w (seibucop.cpp:1073): cop_status &= 0x7fff (clear bit 15). rtl/Legionnaire/Legionnaire_cop3.sv:1121 MAME: cop_status &= 0x7fff (clear bit 15). rtl/Legionnaire/Legionnaire_cop3.sv:1140 MAME execute_0205: read dword at cop_regs[0]+4+offset4 (ppos) rtl/Legionnaire/Legionnaire_cop3.sv:1161 0x138e / 0x338e — atan(dx/dy) MAME execute_338e. rtl/Legionnaire/Legionnaire_cop3.sv:1163 Parte da r1+4 hi (offset 0x0004), come 3BB0/MAME. rtl/Legionnaire/Legionnaire_cop3.sv:1171 r1+4 hi (MAME read_dword(r1+4) primo) rtl/Legionnaire/Legionnaire_cop3.sv:1186 MAME: raw_angle = cop_read_word(r0+0x34) = host_read_word(0x34^2 = 0x36); amp = cop_read_word(r0+0x36) = host_read_word(0x36^2 = 0x34). rtl/Legionnaire/Legionnaire_cop3.sv:1203 0xa180 — collision read pos for slot 0 MAME cop_collision_read_pos: cop_read_word(spradr+N) = host_read_word((spradr+N)^2) per host_endian=true. rtl/Legionnaire/Legionnaire_cop3.sv:1376 Macro 0x0205 — linear movement (MAME execute_0205) ppos = read_dword(cop_regs[0]+0x04) vel = read_dword(cop_regs[0]+0x10) npos = ppos + vel write_dword(cop_regs[0]+0x04, npos) delta = (npos>>16) - (ppos>>16) write_word(cop_regs[0]+0x1E, re rtl/Legionnaire/Legionnaire_cop3.sv:1419 MAME cop_read/write_word(cop_regs[0]+0x1e) = host word @ (0x1e^2)=0x1c (host endianness word^2; conferma doc 06 micro-op 'addmem16 0x1C(r0)'). rtl/Legionnaire/Legionnaire_cop3.sv:1437 Macro 0x0905/0x0904 — jump (MAME execute_0904) write_dword(cop_regs[0]+0x10, read_dword(cop_regs[0]+0x10) ± read_dword(cop_regs[0]+0x28)) 0x0905 (bit 0=1) = +, 0x0904 (bit 0=0) = - rtl/Legionnaire/Legionnaire_cop3.sv:1463 MAME execute_0904: bit 0 di data = 1 → add, =0 → sub tmp32_a = vel ± grav. rtl/Legionnaire/Legionnaire_cop3.sv:1494 0x138E/0x338E atan(dx/dy) — MAME execute_338e (cmd.ipp:159) dx = read_dword(r1+4) - read_dword(r0+4) dy = read_dword(r1+8) - read_dword(r0+8) if(!dy){status\|=0x8000; angle=0} else angle=atan(dx/dy)128/pi; dy<0→+0x80 if(data&0x80) write_byt rtl/Legionnaire/Legionnaire_cop3.sv:1542 MAME: angle = atan(dx/dy)128/pi (+0x80 se dy<0). rtl/Legionnaire/Legionnaire_cop3.sv:1544 Cosi' z = atan(dx/dy) e il +0x80 (in WR) copre solo il quadrante, come MAME. rtl/Legionnaire/Legionnaire_cop3.sv:1546 NIENTE prescale: i dword diff sono FIXED-POINT coord<<16 (come il 3BB0 che usa dx32[31:16] e MAME dx>>16), NON interi piccoli. rtl/Legionnaire/Legionnaire_cop3.sv:1587 MAME (int)(...) tronca VERSO ZERO. rtl/Legionnaire/Legionnaire_cop3.sv:1589 BUG TROVATO (validato vs MAME su 29241 casi): il CORDIC SOTTO-CONVERGE di 1 LSB sulle DIAGONALI (es. rtl/Legionnaire/Legionnaire_cop3.sv:1594 Compenso l'epsilon di sotto-convergenza con +1 toward-zero PRIMA del troncamento: bias=1 azzera tutte le 133 divergenze (bias=0) -> 0/29241 vs MAME. rtl/Legionnaire/Legionnaire_cop3.sv:1603 MAME execute_338e (seibucop_cmd.ipp:175-188): la write dell'angolo in RAM (obj+0x34 host, gated da data&0x80) e' FUORI dall'if/else di dy -> avviene SEMPRE, anche a dy==0 (dove cop_angle=0 -> scrive 0^0x80 = 0x80). rtl/Legionnaire/Legionnaire_cop3.sv:1609 Ora calcolo ang_byte in entrambi i rami e scrivo SEMPRE, come MAME. rtl/Legionnaire/Legionnaire_cop3.sv:1616 Scrivere l'angolo anche a dy==0 ("1:1 MAME") REGREDISCE: il martello scivola/moonwalk. rtl/Legionnaire/Legionnaire_cop3.sv:1619 MAME: dy==0 -> cop_angle=0 rtl/Legionnaire/Legionnaire_cop3.sv:1642 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197) dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (aritmetico) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = sqrt(dxdx + dydy) if(data&0x80) write_word(r0 + (data&0x200?0x3a:0x38 rtl/Legionnaire/Legionnaire_cop3.sv:1751 (Il fix MAME-aligned 0x3a:0x38 faceva fuggire i nemici -> MAME invertito vs HW. rtl/Legionnaire/Legionnaire_cop3.sv:1758 MAME: macro completata → cop_status = 7 (gate-poll del gioco). rtl/Legionnaire/Legionnaire_cop3.sv:1844 0x8100/0x8900 sin/cos (MAME execute_8100/8900) raw_angle = cop_read_word(cop_regs[0]+0x34) & 0xff amp = (65536>>5) (cop_read_word(cop_regs[0]+0x36) & 0xff) = 2048 * amp_byte if (raw_angle == 0xC0 sin / 0x80 cos): amp = 2 res = int( rtl/Legionnaire/Legionnaire_cop3.sv:1883 MAME special-case: sin && raw==0xC0 OR cos && raw==0x80 → amp = 2 rtl/Legionnaire/Legionnaire_cop3.sv:1929 0xa180/0xa980 — read pos (MAME cop_collision_read_pos) flags_swap = cop_read_word(spradr+2) → host_read_word(spradr+0) pos[0] = cop_read_word(spradr+6) → host_read_word(spradr+4) pos[1] = cop_read_word(spradr+10) → host_read_word( rtl/Legionnaire/Legionnaire_cop3.sv:1936 Però MAME cop_read_word(+2) = host_read_word(+2^2) = host_read_word(+0). rtl/Legionnaire/Legionnaire_cop3.sv:1947 rdata = word @ host+0 = flags (MAME cop_read_word(spradr+2) ^ 2). rtl/Legionnaire/Legionnaire_cop3.sv:1956 rdata = word @ host+4 = pos[0] (Y axis per MAME) rtl/Legionnaire/Legionnaire_cop3.sv:1976 0xb100/0xb900 — update hitbox & compute intersection (1:1 MAME cop_collision_update_hitbox, seibucop.cpp:1003-1065). rtl/Legionnaire/Legionnaire_main_top.sv:212 VBLANK IRQ4 — MAME legionna.cpp: m_maincpu->set_vblank_int(irq4_line_hold) MAME HOLD_LINE: IRQ asserted on edge, released ONLY at IACK (= when CPU fetches vector). rtl/Legionnaire/Legionnaire_main_top.sv:217 VBLANK IRQ4 — MAME legionna.cpp: m_maincpu->set_vblank_int(irq4_line_hold) MAME HOLD_LINE: IRQ asserted on edge, released ONLY at IACK (= when CPU fetches vector). rtl/Legionnaire/Legionnaire_main_top.sv:462 COP3 cmd 0x14 dma_tilemap_buffer (MAME legionna_v.cpp:86 videowrite_cb_w): offset 0x000..0x3FF → BG (back_data) offset 0x400..0x7FF → FG (fore_data) offset 0x800..0xBFF → MG (mid_data) offset 0xC00..0x13FF → Text (textram, 0x800 word) rtl/Legionnaire/Legionnaire_main_top.sv:532 ── Palette: split STAGING ($104000) vs RENDERER (semantica MAME 2-stadi) ─── MAME: la CPU e il fade (cmd 0x80) scrivono la STAGING RAM a $104000. rtl/Legionnaire/Legionnaire_main_top.sv:554 Il mirror serve al FADE-SOFTWARE della CPU (presentazione, routine $263E) che fa read-modify-write sulla palette assumendo palette UNICA (come MAME/HW): senza mirror la CPU scrive solo lo staging e il risultato non e' visibile fino al pross rtl/Legionnaire/Legionnaire_maincpu_map.sv:23 Main CPU memory map Legionnaire (MAME legionna.cpp legionna_map): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $100000-$1003FF RAM scratch (1KB) → BRAM (Main RAM low) $100400-$1006FF COP3 region rtl/Legionnaire/Legionnaire_maincpu_map.sv:130 Text VRAM: $102800-$1037FF = 4KB = 2048 word (MAME common_video_allocate_ptr alloca textram a 0x1000/2 word, videowrite_cb_w smista offset < 0x2800/2). rtl/Legionnaire/Legionnaire_maincpu_map.sv:212 MAME legionna_map: main_r/main_w(offset>>1) con umask16(0x00ff). rtl/Legionnaire/Legionnaire_maincpu_map.sv:216 Vedi reference/mame_seibu/seibusound.cpp main_r/main_w. rtl/Legionnaire/Legionnaire_maincpu_map.sv:308 Replica la latenza-zero-osservabile di MAME (cop_cmd_w sincrono): il gioco legge cop_hit_val_stat/cop_angle ($188/$1b4) nell'istruzione dopo il trigger. rtl/Legionnaire/Legionnaire_palette.sv:25 MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 12816); (legionna.cpp:1212, 12816 = 2048 entry) Address space CPU: 0x104000..0x104FFF (4 KB = 2048 word). rtl/Legionnaire/Legionnaire_palette.sv:35 Espansione 5→8 standard MAME palette_device: {val5, val5[4:2]} (bit replication che riempie i 3 LSB con i 3 MSB del valore 5-bit). rtl/Legionnaire/Legionnaire_palette.sv:85 Legionnaire: xBGR_555 → RGB888 (MAME legionna.cpp:1212) Layout: bit[4:0]=R, bit[9:5]=G, bit[14:10]=B. 5 bit per canale. rtl/Legionnaire/Legionnaire_palette.sv:87 Espansione 5→8 standard MAME palette_device: {val5, val5[4:2]} (replica i 3 MSB nei 3 LSB → range 0..255 con monotonia preservata). rtl/Legionnaire/Legionnaire_seibu_crtc.sv:23 Seibu CRTC fedele a MAME (src/mame/seibu/seibu_crtc.cpp). rtl/Legionnaire/Legionnaire_seibu_crtc.sv:119 MAME mappa: bit0=screen0(BG), bit1=screen2(MG), bit2=screen1(FG), bit3=screen3(Text) (vedi seibu_crtc.cpp commento "screen 0=BG, screen 1=FG, screen 2=MG, screen 3=Text") In SD Gundam dcon.cpp layer_en_w gira la maschera così: ~layer_en bit rtl/Legionnaire/Legionnaire_seibu_crtc.sv:128 Il dispatcher MAME usa "if (BIT(~m_layer_en, n))" per saltare = layer disabilitato quando il bit è 1. rtl/Legionnaire/Legionnaire_seibu_crtc.sv:133 Legionnaire layer ordering (MAME legionna_v.cpp:342-345): bit 0 = MG (midground) bit 1 = BG (background) bit 2 = FG (foreground) bit 3 = Text bit 4 = Sprites (Diverso da BB/DCon/Gundam dove bit 0=BG, bit 1=MG.) rtl/Legionnaire/Legionnaire_sprite_renderer.sv:25 Formato spriteram quasi identico (entrambi MAME sei021x_sei0220_spr.cpp) — differenze: - Spriteram @ 0x105000-0x105FFF (4KB, 1024 word, 256 entry × 4 word) - w3 bit 15 = tile bank extra bit (denjinmk usa, Legionnaire base = 0) rtl/Legionnaire/Legionnaire_sprite_renderer.sv:30 Format word (MAME legionna_v.cpp:288-312): w0 bit 15 = enable (0=draw, 1=skip — TODO verify Legionnaire) w0 bit 14 = flip_x w0 bit 13 = flip_y (??? rtl/Legionnaire/Legionnaire_sprite_renderer.sv:46 Priority callback legionna_v.cpp:314-317: pri_mask[0] = 0x0000 (sopra tutto) pri_mask[1] = 0xFFF0 pri_mask[2] = 0xFFFC pri_mask[3] = 0xFFFE rtl/Legionnaire/Legionnaire_sprite_renderer.sv:140 0..511 (MAME size/2/4 = 4096/2/4 = 512) rtl/Legionnaire/Legionnaire_sprite_renderer.sv:145 Decoded fields — MAME sei0210_device::draw (non-alt format, riga 143): if (BIT(~spriteram[i], 15)) continue; → draw quando w0[15]==1. rtl/Legionnaire/Legionnaire_sprite_renderer.sv:155 SEI0211 get_coordinate (MAME sei021x_sei0220_spr.h): coord &= 0x1ff; return (coord >= 0x180) ? rtl/Legionnaire/Legionnaire_sprite_renderer.sv:163 MAME SEI0211 default m_xoffset/m_yoffset = 0 (sei021x_sei0220_spr.cpp:40-41). rtl/Legionnaire/Legionnaire_sprite_renderer.sv:164 Legionnaire NON chiama set_offset (legionna.cpp:1214) → offset 0,0. rtl/Legionnaire/Legionnaire_sprite_renderer.sv:196 Tile code finale Y-MAJOR (MAME draw_internal: ax=outer, ay=inner, code++): sub_index = axsizey + ay → cur_tile = code + eff_tile_xsp_h + eff_tile_y rtl/Legionnaire/Legionnaire_sprite_renderer.sv:535 MAME gfx_legionna_spr: color base = 6416 = 0x400 (64 colorset × 16 pen). rtl/Legionnaire/Legionnaire_text_renderer.sv:25 Specifiche da MAME (legionna.cpp:1117-1126, 1167): rtl/Legionnaire/Legionnaire_text_renderer.sv:47 Char ROM in MAME: "char" region 64KB = ROM_COPY user1[0x10000..0x1FFFF]. rtl/Legionnaire/Legionnaire_text_renderer.sv:142 MAME `legionna_v.cpp:214`: text tilemap = 64×32 (8x8 tiles, TILEMAP_SCAN_ROWS). rtl/Legionnaire/Legionnaire_text_renderer.sv:188 --- Stage 3: pen decode (charlayout planes packed in nibbles) --- Per col c (0..3 dentro la half-tile), bit position = 3 - c. pen[0] = word[bit_pos + 0] (plane 0) pen[1] = word[bit_pos + 4] (plane 1) pen[2] = word[bit_pos + 8] (plane rtl/Legionnaire/Legionnaire_text_renderer.sv:194 MAME readbit usa MSB-first: bit_offs N → byte[N/8] bit (7-N%8). rtl/Legionnaire/Legionnaire_text_renderer.sv:195 In Verilog word concat (lo=byte0[7:0], hi=byte1[7:0]) → MAME pos N = word[(7-N%8) + (N>=8?8:0)]. rtl/Legionnaire/Legionnaire_text_renderer.sv:212 MAME GFXDECODE char: color base = 4816 = 0x300 (16 colorset × 16 pen). rtl/Legionnaire/Legionnaire_tile_layer.sv:25 Differenze fra layer (da MAME dcon.cpp): rtl/Legionnaire/Legionnaire_tile_layer.sv:58 BB FG hardcoded +0x1000 (MAME bloodbro fg_tile_info) rtl/Legionnaire/Legionnaire_tile_layer.sv:195 Tile index con eventuale gfx_bank (MG ha bit 12 = 13-bit totali, BG/FG = 12 bit) + TILE_CODE_OFS hardcoded (BB FG aggiunge 0x1000 secondo MAME bloodbro fg_tile_info). rtl/Legionnaire/Legionnaire_video_timing.sv:35 Active area da MAME (sdgndmps_map): visarea 0..408-1, 28..308-1 quindi 320×224, V offset = 16 (top blank). rtl/Legionnaire/Legionnaire_video_timing.sv:72 ── Constants timing ───────────────────────────────────────────────────── Blood Bros: 256x224 active (MAME bloodbro.cpp:846-851 set_visarea 0..255, 16..239). rtl/Legionnaire/sdram_bridge.sv:287 --- FG address descramble (MAME legionna.cpp:1129 descramble_legionnaire_gfx) --- MAME applica un bitswap<24> agli indirizzi della ROM "fore" durante init: src_descrambled[i] = src_raw[bitswap<24>(i, ... rtl/Legionnaire/sdram_bridge.sv:334 bitswap MAME del byte offset README.md:11 This core reimplements the hardware in SystemVerilog from MAME references and hardware observation. README.md:32 Seibu SEI300 / COP coprocessor* reproduced from the MAME `raiden2cop` reference: sincos / atan (CORDIC) math, distance / divide, object DMA, collision detect README.md:36 MAME-accurate Seibu CRTC tilemaps: BG / MG / FG / TEXT with per-layer scroll README.md:38 xBGR-555 palette, MAME-accurate layer priority and sprite/tilemap mixing Says it matches, follows or was checked against MAME — 7 Legionnaire.sv:209 Shift fisso aggiunto per match MAME 1:1 (misurato HW 2026-05-14): BG X+0 Y+16 FG X+0 Y+16 SPR X+0 Y+0 TXT X-1 Y+16 L'OSD resta editabile ±32 attorno al valore corretto. Legionnaire.sv:215 Offset per-layer HARDCODATI = match pixel-perfect MAME (trovati via OSD, ora fissi; menu P5 rimosso). Legionnaire.sv:253 NB: gli offset per-layer (ex P5) sono HARDCODATI (osd__xoff/yoff costanti, match pixel-perfect MAME). rtl/Legionnaire/Legionnaire_cop3.sv:721 find_trigger_match (MAME seibucop.cpp:464) Cerca slot N tale che (trigger & 0xf800) == (cop_func_trigger[N] & 0xf800) && cop_func_trigger[N] != 0. rtl/Legionnaire/Legionnaire_cop3.sv:1898 res = prod >> 4 (= /16 per matchare formula MAME 2048/32768 = 1/16) rtl/Legionnaire/Legionnaire_sprite_renderer.sv:165 +1 pixel a destra: offset verificato con pixel hunting su MAME (rmonic79). rtl/Legionnaire/Legionnaire_sprite_renderer.sv:325 Scan INVERSO 511→0 (verificato su HW: ordine sprite-su-sprite opposto al loop MAME 0→511). Says it was translated, ported or taken from MAME — 3 Legionnaire.sv:209 Shift fisso aggiunto per match MAME 1:1 (misurato HW 2026-05-14): BG X+0 Y+16 FG X+0 Y+16 SPR X+0 Y+0 TXT X-1 Y+16 L'OSD resta editabile ±32 attorno al valore corretto. rtl/Legionnaire/Legionnaire_cop3.sv:1650 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197): 1:1 dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (signed) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = floor(sqrt(dxdx + dydy)) if(data&0x80) write_word(r0+(data&0x200?0x3 rtl/Legionnaire/Legionnaire_cop3.sv:1767 0x42C2/0x4AA0 divide — MAME execute_42c2/4aa0 (cmd.ipp:219/247): 1:1 DIVIDEND = cop_dist << (5 - cop_scale) (cop_scale 0..3 → shift 5..2) 42c2: div=cop_read_word(r0+0x36)→host 0x34; if(!div){status\|=0x8000; write 0 a host 0x3a} else write Shares text with the MAME driver without saying so — 5 rtl/Legionnaire/Legionnaire_palette.sv:23 Palette RAM Seibu Legionnaire (xBGR_555, 2048 entries). MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 12816); (legionna. — shares text with seibu/legionna.cpp:1212 rtl/Legionnaire/Legionnaire_sprite_renderer.sv:146 if (BIT(~spriteram[i], 15)) continue; → draw quando w0[15]==1. — shares text with seibu/sei021x_sei0220_spr.cpp:128 rtl/Legionnaire/Legionnaire_text_renderer.sv:23 Text layer renderer Seibu Legionnaire (8x8, 4bpp, 64x32). Specifiche da MAME (legionna.cpp:1117-1126, 1167): // charlayout 8x8, RGN_FRAC(1,1), — shares text with seibu/legionna.cpp rtl/Legionnaire/Legionnaire_video_timing.sv:23 Video timing single-screen Seibu D-Con. SD Gundam Psycho Salamander gira su Seibu D-Con (PB91008), stessa famiglia di Blood Bros (1990). PCB measuremen — shares text with seibu/legionna.cpp rtl/Legionnaire/sdram_bridge.sv:289 src_descrambled[i] = src_raw[bitswap<24>(i, ... 6,5,15,14,13,12, 11,10,9,8, 7,4, 3..0)] — shares text with seibu/legionna.cpp:1141
Leland# Ataxx, Brute Force, Danny Sullivan's Indy Heat, Ironman Ivan Stewart's Super Off-Road … MiSTer-devel/Arcade-Leland_MiSTer @ 2dc128ae MAME compared: cinematronics/leland.cpp + 5 related file(s) Read: 83 HDL files, 15,476 lines (Quartus project)	MiSTer official	Mostly MAME	medium	49%
Statements: 130 toward MAME Cites MAME source — 118 rtl/KF8253/kf8253_leland_bus.sv:6 Scope boundary: this module does NOT decode a real system address into "is this access for me" -- that is the PCS-window job (MAME's leland_a.cpp peripheral_r/w, `select = offset >> 6`, PCS2/PCS3 sub-windows). rtl/audio/leland_dac_mixer.sv:6 Takes the sound board's digital DAC register outputs (six 8-bit sample+volume pairs and one 10-bit sample) and produces one mono signed 16-bit PCM stream; the top level duplicates it to both channels (leland_a.cpp has a single front_center rtl/audio/leland_dac_mixer.sv:15 Gains: leland_a.cpp routes each 8-bit channel at 0.2 and dac9 at 1.0. rtl/audio/leland_dac_mixer.sv:15 MAME's volume DAC (DAC_8BIT_BINARY_WEIGHTED) has a gain of 2.0, which doubles every 8-bit channel (measured against a MAME capture of Indy Heat). rtl/audio/leland_sound.sv:16 Reference: MAME leland_a.cpp leland_80186_map_program (RAM 0x00000-0x1FFFF mirrored, ROM 0x20000-0xFFFFF identity-mapped into the audiocpu region). rtl/audio/leland_sound.sv:55 Core interrupt/debug ports: INT0/INT1 are decoded by leland_sound_board straight from control_data; NMI is unused per leland_a.cpp. rtl/audio/leland_sound.sv:228 leland_sound_board -- PIT clock enable: the two discrete PIT8254s run at 4 MHz (leland_a.cpp `set_clk<N>(4000000)`); clk_sys/12 is exactly 4 MHz at 48 MHz. rtl/audio/leland_sound_board.sv:6 Sits downstream of i186_periph's system-side data bus (everything i186_periph did not claim as an internal register): decodes the external PCS peripheral window (command/response latch, PIT0/PIT1, dac9, clock-active status; leland_a.cpp per rtl/audio/leland_sound_board.sv:16 MAME's peripheral_r/w and dac_w are 16-bit handlers whose `offset` is a word offset in the same units (PIT0 programming at byte address 0x20100 is word offset 0x80, `>>6` = select 2), so the constants below come straight from leland_a.cpp. rtl/audio/leland_sound_board.sv:21 clock_active[6:2] (leland_a.cpp m_clock_active, the PCS select-0 status read) is an edge-triggered latch, not a level follower: MAME calls set_clock_line() only on a pin transition event, and bit 6 (TMROUT0) only ever transitions high in th rtl/audio/leland_sound_board.sv:63 Ataxx sound board variant (leland_a.cpp ATAXX_80186): peripherals sit in an I/O-space window (not memory), there is no whole-I/O-space DAC port and no second PIT, and the three DACs plus their volumes are written through PCS select 5. rtl/audio/leland_sound_board.sv:159 Outside Ataxx mode select 5 falls through to the "unimplemented read returns 0xFFFF, write ignored" default below, like leland_a.cpp's `m_type <= TYPE_REDLINE` guard. rtl/audio/leland_sound_board.sv:269 --- clock_active status (select-0 read; bits [1:0] unused -- DMA-fed dac 0/1 never SET a clock_active bit in leland_a.cpp, only dac_w's unconditional set_clock_line(dac,0) clear ever touches them, which is a permanent no-op since they start rtl/audio/leland_sound_board.sv:290 A byte write merges into the 16-bit register like MAME's COMBINE_DATA. rtl/audio/leland_sound_board.sv:439 --- local read mux (pcs0/1; pcs4/5 and io-space are write-only, read as 0xFFFF matching leland_a.cpp's fallthrough-to-default warn+0xffff) --- rtl/cpu/i186_periph.sv:5 Written from MAME's i186.cpp as a behavioural reference (no code reuse). rtl/cpu/i186_periph.sv:8 It sits inline on the s80x86 core's data bus only (MAME also intercepts only data accesses): an access to the relocation-selected internal page is serviced here, everything else passes through to the system bus. rtl/cpu/i186_periph.sv:17 count/maxA/maxB are live registers compared every tick, which is equivalent to MAME's event-scheduled model. rtl/cpu/i186_periph.sv:23 The s80x86 core requires irq[7:0] to stay stable from the moment `intr` asserts until the `inta` pulse, which MAME's model does not guarantee. rtl/cpu/i186_periph.sv:76 every timer-0 terminal count, regardless of the interrupt-enable bit (i186.cpp drives tmrout0 on every TC). rtl/cpu/i186_periph.sv:120 --- Relocation register --- Reset default 0x20FF: I/O mode (bit12=0), page 0xFF -> window 0xFF00-0xFFFF (i186.cpp device_reset: m_reloc = 0x20ff), before the ROM reprograms it. rtl/cpu/i186_periph.sv:134 External PCS window, recomputed continuously from PACS/MPCS (matches leland_a.cpp peripheral_ctrl: temp = (PACS & 0xffc0) << 4, space chosen by MPCS bit 6 of the stored (forced-bits-included) value). rtl/cpu/i186_periph.sv:242 Byte-swap quirk: bytesel==10 (high lane only) is the odd-byte-address case in i186.cpp and targets the register word's high byte; bytesel==01 is the low byte. rtl/cpu/i186_periph.sv:273 write-only (EOI); i186.cpp reads log an error and return nothing rtl/cpu/i186_periph.sv:291 Hi-address (source/dest upper 4 bits) registers read back with the unused upper 12 bits as 0, matching i186.cpp's `source >> 16` (source stored as a plain integer wider than the real 20-bit bus). rtl/cpu/i186_periph.sv:401 Selection is by RIU, not by "ALT enabled" (i186.cpp: `(control & 0x1000) ? rtl/cpu/i186_periph.sv:424 Control-register write masking: bits in `resbits` are hardware-owned (preserved from the old value, never settable by a CPU write); INH (bit14) gates whether EN (bit15) actually updates from this write, and always reads back 0 (i186.cpp int rtl/cpu/i186_periph.sv:445 Post-elapse control mutation (i186.cpp timer_elapsed): MC (bit5) always sets; CONT (bit0) or mid-ALT-cycle (ALT && !RIU) reprimes (toggling RIU on the ALT case) and keeps EN running, otherwise the timer stops (EN and RIU both clear). rtl/cpu/i186_periph.sv:454 i186.cpp: RIU sets only when (ALT && !RIU) [starting the B half]; every other reprime case (not ALT, or ALT&&RIU finishing the B half under CONT) unconditionally clears it back to 0 -- NOT "leave unchanged". rtl/cpu/i186_periph.sv:554 --- Priority resolver (i186.cpp update_interrupt_state, non-iRMX scan order: for each priority 0..7 check timer, then dma0, dma1, ext0..ext3; masked sources never match because a stored field with MSK=1 cannot equal 0-7). rtl/cpu/i186_periph.sv:556 A source at the current priority that is already in service aborts the whole scan, as MAME's `return;`. rtl/cpu/i186_periph.sv:605 EXT0 (0x10 -> in_service[4]); an in-service source with SFNM (bit 6) set also ends the scan in i186.cpp, so no nested request is ever granted here (cascade/SFNM support is omitted). rtl/cpu/i186_periph.sv:690 Reading POLL (0x12) while a request is pending is treated identically to a real `inta` pulse (i186.cpp internal_port_r case 0x12: `if (poll_status & 0x8000) inta_callback(...)`); poll-mode firmware relies on it. rtl/cpu/i186_periph.sv:699 Rescan trigger: every event that calls update_interrupt_state() in i186.cpp (register writes, EOI, an INT0/1 edge, a timer_irq pulse, a DMA interrupt pulse, or the inta/poll-read ack). rtl/cpu/i186_periph.sv:714 EOI (i186.cpp handle_eoi, non-iRMX): the specific form clears one in_service bit by explicit vector; the nonspecific form (bit 15 set) scans priority 0..7 and clears the first in-service source whose priority field's low 3 bits match (the m rtl/cpu/i186_periph.sv:780 --- Timer status latch (per-timer strobe -> sticky status bits, i186.cpp timer_elapsed: `m_intr.status \|= 0x01 << which`) --- rtl/cpu/i186_periph.sv:787 Unlike a literal port of i186.cpp external_int(), edge-triggered mode (LTM=0, the reset default and what this board uses) latches a rising edge as a sticky request that only a genuine ack clears. rtl/cpu/i186_periph.sv:793 Level-triggered mode (LTM=1) tracks the live pin level as in MAME. rtl/cpu/i186_periph.sv:796 LTM=1: MAME's literal level-tracking behavior rtl/cpu/i186_periph.sv:824 --- Register writes (plain field stores; every one of these triggers a rescan in i186.cpp, folded into the shared rescan block below via `intc_reg_write`/`wr_eoi`) --- rtl/cpu/i186_periph.sv:849 Ack processing (a real `inta` pulse from the core, or a POLL register read), as i186.cpp int_callback. rtl/cpu/i186_periph.sv:862 Clear the request bit(s) this ack covers, UNLESS it's an LTM-mode external source (0xf0 of ack_mask) -- a level-triggered request stays sticky until the pin itself deasserts, matching i186.cpp's LTM check exactly. rtl/cpu/i186_periph.sv:992 M/IO bit semantics per i186.cpp (SRC_MIO/DEST_MIO set == memory space): this bus's d_io is the opposite sense (1 == I/O). rtl/cpu/i186_periph.sv:1053 update_dma_control (i186.cpp): CHG_NOCHG (bit2) clear -> preserve the old ST_STOP (bit1) instead of taking the write's; CHG_NOCHG itself always reads back 0 afterward. rtl/cpu/i186_periph.sv:1107 Pointer increment/decrement, count decrement, TC stop/interrupt -- as i186.cpp drq_callback. rtl/cpu/i186_periph.sv:1132 Terminate: explicit TERMINATE_ON_ZERO, or unsync mode (which always self-stops on TC regardless of that bit -- i186.cpp: `(control&TERMINATE_ON_ZERO) \|\| !(control&SYNC_MASK)`). rtl/cpu/leland_master.sv:7 Leland Master Z80 memory map (validated against MAME leland.cpp): 0x0000-0x1FFF ROM fixed bank (always master_rom[0x00000..0x01FFF]) 0x2000-0x9FFF Banked ROM window (32 KB, bank register selects offset) 0xA000-0xDFFF Fixed ROM (region of rtl/cpu/leland_master.sv:19 I/O port map (validated against MAME leland.cpp master_map_io and redline_state::init_offroad): 0xF0 ROM bank register (write, bits [2:0] used) 0xF8 Player 3 wheel read (offroad_wheel_3_r, dial-encoded) 0xF9 Player 1 wh rtl/cpu/leland_master.sv:29 Banking (validated against MAME leland_m.cpp offroad_bankswitch): bank_reg [2:0] indexes a fixed lookup table of ROM base offsets. rtl/cpu/leland_master.sv:32 bank_list (MAME): rtl/cpu/leland_master.sv:55 Battery-backed RAM (0xA000-0xDFFF, 16 KB), master-private: normally fixed ROM (region offset 0xA000), overlaid by MAME's battery_ram_view only when bank_reg == 1. rtl/cpu/leland_master.sv:68 VRAM I/O port op stream (to leland_board's VRAM sequencer) -- leland_mvram_port_r/w, installed by init_master_ports at mvram_base=0x00 and 0x40 (see leland.cpp init_offroad()). rtl/cpu/leland_master.sv:79 /MCONT control outputs (I/O port 0x09, validated MAME leland_master_output_w) bit0: slave_reset_n (0=hold Slave in reset, 1=run) bit2: slave_nmi_n (0=assert NMI) bit3: slave_int_req (0=assert Slave INT) rtl/cpu/leland_master.sv:87 80186 sound-board control latch: port 0xF0 is both the graphics bank register (bank_reg) and the sound board's control register (/RESET, ZNMI, INT0, /TEST, INT1 in bits [7:3]); MAME's redline_master_alt_bankswitch_w forwards the same byte t rtl/cpu/leland_master.sv:94 Sound command latch writes (ports 0xF2/0xF4, leland_a.cpp command_lo_w/command_hi_w). rtl/cpu/leland_master.sv:109 Background scroll registers (MAME scroll_w at io_base+0x0C-0x0F: ports 0xCC-0xCF and 0x8C-0x8F for Off-Road). rtl/cpu/leland_master.sv:114 Graphics bank (MAME m_gfxbank / leland_video gfxbank), set through the AY-3-8910 port A write callback: the ROM writes a register select (I/O 0x0A, /OGIA) then data (0x0B, /OGID), relocated like /MCONT. rtl/cpu/leland_master.sv:133 Raster line counter (from leland_video), used to generate the periodic "VA10" interrupt every 16 scanlines starting at line 8 (validated against MAME leland_m.cpp leland_interrupt_callback). rtl/cpu/leland_master.sv:138 Pedal (MAME AN0-AN2, IPT_PEDAL): raw value, read directly at ports 0xFD/0xFE/0xFF. rtl/cpu/leland_master.sv:143 Wheel (MAME AN3-AN5, IPT_DIAL): a free-spinning encoder, so only the direction and magnitude of motion since the last read is reported (dial_compute_value). rtl/cpu/leland_master.sv:214 Periodic "VA10" interrupt — validated against MAME leland_m.cpp leland_interrupt_callback(): fires every 16 scanlines starting at line 8. rtl/cpu/leland_master.sv:216 This is the only Master INT source in MAME. rtl/cpu/leland_master.sv:231 The periodic VA10 raster interrupt is the only master INT source in MAME; the CPUs otherwise communicate through the shared VRAM mailbox and the SLAVEHALT/GIN1 poll (see leland_slave.sv). rtl/cpu/leland_master.sv:237 ROM banking — validated against MAME offroad_bankswitch() rtl/cpu/leland_master.sv:248 bank_list from MAME offroad_bankswitch (offsets into master_rom region) rtl/cpu/leland_master.sv:342 leland_mvram_port_r/w range, parameterised by mvram_base (MAME init_master_ports). rtl/cpu/leland_master.sv:351 TRANS_EN=0: the Master is num=0 in MAME's vram_port_w, so its bit-4 transparency bit is ignored (transparency is Slave-only). rtl/cpu/leland_master.sv:383 MAME redline_state::init_offroad installs the shared leland_master_input_r/output_w handlers (GIN, mcont, ay, scroll) at io_base+offset, aliased at both io_base=0xC0 and 0x80, so the physical /MCONT port is 0xC9 (mirrored at 0x89), not the rtl/cpu/leland_master.sv:388 P1 pedal, raw (MAME port 0xFD) rtl/cpu/leland_master.sv:391 Wheel ports (MAME init_offroad/init_offroadt): fixed dial-encoded reads at 0xF9 (P1), 0xFB (P2) and 0xF8 (P3), separate from the pedal ports; unused by Pig Out. rtl/cpu/leland_master.sv:397 The relocated leland_master_input_r/output_w window (GIN0/1/3, mcont, ay, scroll) is parameterised by io_base (MAME init_master_ports(mvram_base, io_base)); dual_io_window reproduces Off-Road's double install (base and base^0x40). rtl/cpu/leland_master.sv:399 Offsets inside the window are fixed by MAME: 0x00/0x01 GIN0/1, 0x09 mcont, 0x0A/0x0B ay, 0x0C-0x0F scroll, 0x11 GIN3. rtl/cpu/leland_master.sv:413 MAME master_redline_map_io: 0xF2 = 80186 response_r / command_lo_w, 0xF4 = command_hi_w (write-only). rtl/cpu/leland_master.sv:419 Background scroll registers (MAME scroll_w, offset 0x0C-0x0F relative to io_base -- see leland.cpp init_offroad()/init_offroadt()/init_pigout()). rtl/cpu/leland_master.sv:426 Wheel dial encoder (MAME leland_m.cpp dial_compute_value): each read reports the direction (bit 7) and magnitude (bits 4:0, clamped to 0x1F, accumulated mod 32) of wheel motion since the last read of the same port, never an absolute angle. rtl/cpu/leland_master.sv:472 GIN input ports — validated against MAME INPUT_PORTS and leland_master_input_r (leland_m.cpp), parameterized by io_base (see io_win() above). rtl/cpu/leland_master.sv:488 bit1=COIN3, bit2=COIN2, bit3=COIN1 (MAME offroad INPUT_PORTS IN1 order is NOT P1/P2/P3). rtl/cpu/leland_master.sv:496 JOY4_DIGITAL (pigout) GIN0 (leland.cpp INPUT_PORTS_START(pigout), IN0 @ io_base+0): bit1=P3BTN2, bit2=P3right, bit3=P3down, bit5=P2BTN2, bit6=P2left, bit7=P2up. rtl/cpu/leland_master.sv:548 Pig Out: fixed IN4 at raw 0x7F (MAME init_pigout install_read_port, outside the io_base window): P1 joystick, two buttons and start. rtl/cpu/leland_master.sv:560 I/O writes The sound command latch (leland_a.cpp command_lo_w/command_hi_w) lives in the sound board; ports 0xF2/0xF4 are forwarded to it through cmd_wr_data/cmd_wr_lo/cmd_wr_hi. rtl/cpu/leland_master.sv:574 MAME's diff==0 early-out is a software optimisation, not bus behaviour, and control_wr is idempotent. rtl/cpu/leland_master.sv:636 MAME: set_input_line(NMI, BIT(data,2) ? rtl/cpu/leland_master.sv:640 /MCONT bit 3 is a held level (MAME: set_input_line(IRQ0, BIT(data,3) ? rtl/cpu/leland_master.sv:648 MAME leland_master_output_w: /MCONT bit 1 selects the palette view. rtl/cpu/leland_master.sv:662 Palette RAM is readable while /MCONT bit 1 selects the palette view (MAME: ram().w(palette write8)). rtl/cpu/leland_master_ataxx.sv:4 Ataxx master Z80 (MAME leland.cpp master_map_program_2 / master_map_io_2). rtl/cpu/leland_slave.sv:7 Memory map (MAME leland.cpp slave_large_map_program, used by the `lelandi` machine config): 0x0000-0x1FFF ROM bank 0 (fixed) 0x2000-0x3FFF unmapped (reads 0xFF) 0x4000-0xBFFF banked ROM window, 32 KB 0xC000 ROM bank register (wri rtl/cpu/leland_slave.sv:51 Master asserted /MCONT bit3 → assert Slave INT (the only Slave INT source in MAME; there is no Master->Slave command port) rtl/cpu/leland_slave.sv:78 Slave INT: /MCONT bit3 (leland_master_output_w case 0x09) is the only Slave INT source in MAME. rtl/cpu/leland_slave.sv:133 ROM banking (MAME slave_large_map_program / slave_large_banksw_w): the bank register at 0xC000 (bits [3:0]) selects a 32 KB window at 0x4000-0xBFFF: bankaddress = 0x10000 + 0x8000 * bank_reg, and bank_reg >= 14 falls back to 0x10000. rtl/cpu/leland_slave.sv:136 Offsets are within the slave ROM region (leland_board adds ADDR_SLAVE_BASE): 0x00000 u3 (8 KB, fixed bank) 0x02000-0x2FFFF zero fill 0x30000 u4t bank_reg 4/5 0x40000 u5t bank_reg 6/7 0x50000 u6t bank_reg 8/9 0x6000 rtl/cpu/leland_slave.sv:154 MAME's init_offroad() calls rotate_memory("slave") twice, which left-rotates every 32 KB block from 0x10000 by 8 KB per call: a net rotation of half a block. rtl/cpu/leland_slave.sv:175 MAME slave_map_io installs this handler at 0x00-0x1F with .mirror(0x40), i.e. bit 6 is a don't-care -- the same port also answers at 0x40-0x5F. rtl/cpu/leland_slave.sv:211 Bank register write: exactly 0xC000 (MAME slave_large_banksw_w). rtl/cpu/leland_slave_ataxx.sv:4 Ataxx slave Z80 (MAME leland.cpp ataxx_state::slave_map_program / slave_map_io_2). rtl/io/steering_input.sv:9 The cabinet's wheel is a free-spinning rotary encoder (MAME IPT_DIAL): only the change between two reads matters. rtl/io/trackball_input.sv:4 Like MAME's IPT_TRACKBALL with PORT_KEYDELTA(4) at 80% sensitivity, a held D-pad direction adds a small fixed step every frame (no ramp, stops when released); the stick adds a step proportional to its deflection beyond a dead zone. rtl/leland_board.sv:79 Wheel: free-running mod-256 virtual dial (stick + d-pad + spinner combined by steering_input.sv); leland_master turns it into MAME's dial_compute_value() encoding. rtl/leland_board.sv:82 Pedal: raw 8-bit value (0 = released, 255 = full), read directly as MAME's IPT_PEDAL AN0/AN1/AN2 do. rtl/leland_board.sv:955 Transparent writes (vp_trans, Slave-only in MAME) implement the exact leland_v.cpp vram_port_w merge: if (!(data & 0xf0)) data \|= old & 0xf0; if (!(data & 0x0f)) data \|= old & 0x0f; by inserting a read phase before the write phase. rtl/leland_board.sv:1063 Work RAM: 4 KB per CPU, private (MAME: the master's 0xE000-0xEFFF is 'mainram', the slave's is a separate RAM). rtl/leland_board_pkg.sv:143 The Leland games share the same master/slave bank tables (MAME's offroad_bankswitch is shared); only the I/O bases, input scheme and flags differ per row. rtl/mem/leland_eeprom_93c46.sv:7 Standard Microwire protocol, as in MAME leland.cpp/leland_m.cpp (64 words x 16 bits). rtl/mem/leland_eeprom_93c56.sv:4 Start bit, 2-bit opcode, 8-bit address (MAME EEPROM_93C56_16BIT with streaming reads: CS held high keeps shifting out the next word). rtl/video/leland_video.sv:7 Leland hardware timing (MAME leland_v.cpp): pixel clock 7.159090 MHz (14.318181 MHz / 2) 424 x 256 total, 320 x 240 active -> 16.88 kHz / 65.95 Hz rtl/video/leland_video.sv:55 Graphics bank (MAME m_gfxbank), written by the master through the AY-3-8910 port A: [5:4] character bank, [3] PROM bank rtl/video/leland_video.sv:115 The scroll registers are used live, not latched per frame: MAME's scroll_w() calls update_partial() first, so the game relies on mid-frame scroll changes (HUD/status split). rtl/video/leland_video.sv:139 Stride is 256 bytes per line (MAME: y << 8). rtl/video/leland_video.sv:157 Background tilemap (MAME leland_get_tile_info / leland_scan) rtl/video/leland_video.sv:396 Low tile byte at index, high byte at index \| 0x4000 (MAME ataxx_get_tile_info) rtl/video/leland_video.sv:578 Bit order: MAME's leland_layout uses xoffset STEP8(0,1), which its decoder reads MSB-first, so pixel column 0 is bit 7 of the plane byte. rtl/video/leland_video.sv:588 Plane weights are reversed relative to bg_gfx ROM order: MAME's leland_layout lists its plane offsets ascending, and the decoder gives plane offset 0 the most significant bit. rtl/video/leland_vram_port.sv:7 Implements MAME leland_v.cpp exactly: - video_addr_w (memory-mapped address latch, 0xF800/0xF801) - vram_port_w (I/O ports 0x00-0x1F, mirrored at 0x40-0x5F) - vram_port_r (same range) rtl/video/leland_vram_port.sv:27 Address latch (video_addr_w): low (0xF800): addr = (addr & 0xFE00) \| ((data << 1) & 0x01FE) high (0xF801): addr = ((data << 9) & 0xFE00) \| (addr & 0x01FE), buffer = data[7] The buffer bit is tracked but unused, exactly like MAME (VRAM's up rtl/video/leland_vram_port.sv:77 tracked like MAME's m_buffer, never used (see header) rtl/video/leland_vram_port.sv:119 MAME op 3: addr += inc & (addr << 1); addr ^= 1 (increment only lands when inc is set AND the address is odd) rtl/video/leland_vram_port.sv:188 MAME: warning only -- no write, no addr change rtl/video/leland_vram_port.sv:210 MAME: unknown read op returns 0 Says it matches, follows or was checked against MAME — 5 Leland.sv:428 Nitro and Coin are J1 buttons 1-2 (joystick bits 4-5): p1_btn[1] is nitro and p1_btn[3] is coin, matching MAME's GIN0/GIN1 bit layout. rtl/cpu/leland_master.sv:283 Banked-low (0x2000-0x9FFF), verified against MAME's live execution: bank_reg 0/1 (bank_offset 0x2000): rom_addr == cpu_addr bank_reg >= 2: rom_addr == bank_offset + cpu_addr[14:0]. rtl/cpu/leland_master.sv:595 matches MAME machine_reset()'s sound_port_w(0) rtl/cpu/leland_slave.sv:156 For a 15-bit offset "+0x4000 mod 0x8000" is the same as inverting bit 14, so one XOR reproduces it (verified byte-exact against MAME's region dump). rtl/cpu/leland_slave.sv:211 The reset value 0 matches MAME machine_reset(). Shares text with the MAME driver without saying so — 7 rtl/cpu/leland_master.sv:636 MAME: set_input_line(NMI, BIT(data,2) ? CLEAR_LINE : ASSERT_LINE), so with the — shares text with cinematronics/leland_m.cpp:1062 rtl/cpu/leland_master.sv:644 leland_master_output_w: m_eeprom->di_write(BIT(data,4)); clk_write(BIT(data,5)); cs_write(BIT(data,6)); — shares text with cinematronics/leland_m.cpp:775 rtl/mem/leland_eeprom_93c46.sv:11 via PORT_READ_LINE_DEVICE_MEMBER("eeprom", ...::do_read). — shares text with cinematronics/leland.cpp:417 rtl/video/leland_video.sv:166 leland_scan: idx = (col&0xff) \| ((row&0x1f)<<8) \| ((row&0xe0)<<9) — shares text with cinematronics/leland_v.cpp:62 rtl/video/leland_vram_port.sv:22 op 3: write data -> addr; addr += inc & (addr<<1); addr ^= 1 — shares text with cinematronics/leland_v.cpp:233 rtl/video/leland_vram_port.sv:32 64 KB is a TODO there: "accessing upper half of video RAM is not — shares text with cinematronics/leland.cpp:39 rtl/video/leland_vram_port.sv:119 MAME op 3: addr += inc & (addr << 1); addr ^= 1 — shares text with cinematronics/leland_v.cpp:234
MajorHavoc# Major Havoc MiSTer-devel/Arcade-MajorHavoc_MiSTer @ 6933b852 MAME compared: atari/mhavoc.cpp Read: 43 HDL files, 18,808 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	11%
Statements: 7 toward hardware Cites hardware documentation that MAME's driver does not — 7 rtl/avg/major_havoc_avg_core.vhd:58 State PROM 136002-125 at 6C (SP-252 sheet 6B). rtl/major_havoc_core.sv:6 Implements the production dual-6502 main board from Atari drawing package SP-252 with its independent 10.000 MHz CPU/audio and 12.096 MHz AVG clocks. rtl/major_havoc_core.sv:222 SP-252 sheet 4B stretches Alpha's 400 ns cycle while /VMEM is active. rtl/major_havoc_core.sv:242 SP-252 sheet 4B clocks the watchdog at 10 MHz / 4096. rtl/major_havoc_watchdog.sv:6 Models the cascaded counter and Alpha reset flip-flop on SP-252 sheet 4B. rtl/videodr0me_fb/vfb_readout.sv:579 SP-252 sheet 9A uses 5.6K main-color branches and a 22K fine-red branch. README.md:7 This core reconstructs the original dual-processor arcade hardware from Atari's schematics and pairs it with a high-resolution vector renderer and CRT-effects p
MarbleMadness2# MiSTer-devel/Arcade-MarbleMadness2_MiSTer @ 25265baf MAME driver: not found Read: 23 HDL files, 6,229 lines (Quartus project)	MiSTer official	Mostly MAME	low	37%
Statements: 10 toward MAME Cites MAME source — 9 rtl/mm2_address_decode.sv:1 Motorola 68000 byte-address decoder derived from MAME marblmd2_map(). rtl/mm2_core.sv:351 MAME's IRGB1555 decoder treats the intensity bit as the least significant bit of each six-bit color component. rtl/mm2_cpu_subsystem.sv:130 Infer it for an odd-byte cycle so the byte-granular MAME-derived decoder can retain its documented addresses. rtl/mm2_jsa_iii.sv:3 Clock ratios, address decode, banking, command polarity, and mixer controls follow MAME's atarijsa implementation. rtl/mm2_playfield.sv:3 Each tile row is decoded from four SDRAM words using the split-half eight-bit MAME layout, then written into the line buffer for the following scanline. rtl/mm2_vad.sv:3 This implements the scanline register/IRQ behavior, indexed playfield scroll parameters, and the end-of-frame register shadow described by MAME's atarivad device. rtl/mm2_video_timing.sv:1 Raster timing documented by MAME's marblmd2 driver: 14.318181 MHz CPU/master reference, 7.1590905 MHz pixels, 456 clocks/line, 262 lines/frame, 336x240 visible. rtl/mm2_video_timing.sv:5 The sync positions are provisional because the MAME driver explicitly lists the crystals/timing as unverified. README.md:72 MAME documents that the prototype itself can report service RAM-test issues, so a reported RAM failure is not necessarily an FPGA fault. Says it matches, follows or was checked against MAME — 1 rtl/mm2_motion_objects.sv:6 Later objects in the list overwrite earlier objects, matching the non-reversed MAME configuration.
MarioBros# Mario Bros. MiSTer-devel/Arcade-MarioBros_MiSTer @ a934eecf MAME compared: nintendo/mario.cpp + 2 related file(s) Read: 48 HDL files, 12,019 lines (Quartus project)	MiSTer official	Both	low	21%
Statements: 20 toward hardware, 3 toward MAME, 7 not counted Cites hardware documentation that MAME's driver does not — 20 rtl/mario_adec.v:111 74LS139 @ 4A rtl/mario_adec.v:123 This output goes to a LS245 @ 7H enable which is not used in the FPGA implementation. rtl/mario_adec.v:136 74LS138 @ 3A Address decoding 7000H - 7FFFH (R) rtl/mario_adec.v:152 7400H - 77FFH - VRAM (R) rtl/mario_adec.v:155 74LS138 @ 3B Address decoding 7000H - 7FFFH (W) rtl/mario_adec.v:172 7400H - 77FFH - VRAM (W) rtl/mario_adec.v:175 74LS138 @ 3C Address decoding 6000H - 6FFFH (R/W) RAM0 @ 7B - 6000H - 67FFH RAM1 @ 7A - 6800H - 6FFFH rtl/mario_adec.v:195 74LS138 @ 4B Address decoding 7C00H - 7FFFH (R) Enable signals for reading inputs and and DIP switches rtl/mario_adec.v:217 74LS138 @ 4C Address decoding 7C00H - 7FFFH (W) Miscellaneous addressing. rtl/mario_adec.v:243 74LS259 @ 2L Misc control signals (7E80H - 7E87H) rtl/mario_adec.v:273 74LS259 @ 7M Sound Port (7F00H - 7F07H) Tiggers sound effects. rtl/mario_adec.v:305 74LS374 @ 7J Sound data (7E00H) Data latch for sound CPU rtl/mario_col_pal.v:35 Parts 4U, 5T (74LS157) Selects sprites or backgound pixels Sprites take priority rtl/mario_main.v:184 Main CPU RAM 7A, 7B 2 x 2KB (6116) rtl/mario_obj.v:132 Object RAM 8B, 8C 2 x 2148 (1KB) Sprite data is written to these RAM's via DMA. rtl/mario_obj.v:279 RAM 8E 64 x 9 bits bipolar RAM with inverted O/C outputs. rtl/mario_roms.v:11 0x00000 - 0x01FFF 7F PROGRAM ROM (8KB) 0x02000 - 0x03FFF 7E PROGRAM ROM (8KB) 0x04000 - 0x05FFF 7D PROGRAM ROM (8KB) 0x06000 - 0x06FFF 3F GFX ROM (4KB) 0x07000 - 0x07FFF 3J GFX ROM (4KB) 0x08000 - 0x08FFF 7C PROGRAM ROM (4KB) 0x09000 - 0x09 rtl/mario_roms.v:258 Sub CPU (Sound) External ROM 5K. rtl/mario_roms.v:296 It is not known if the internal ROM has been dumped. rtl/mario_vram.v:78 VRAM 2 x 2114 @ 3D, 3E (1KB) Cites hardware references or measurements that MAME's driver also gives — 7 rtl/mario_adec.v:77 CPU can clear the NMI via register @ 2L. — also in MAME: 2L nintendo/mario.cpp:845 rtl/mario_adec.v:100 Address Decoder PROM @ 5B — also in MAME: 5B nintendo/mario.cpp:954 rtl/mario_col_pal.v:61 Colour PROM 4P (512 x 8bit) The PROM actually contains 2 versions of the colour palette: 0 - 255 = Inverted palette 256 - 512 = Standard palette Link CL2 on the PCB is used for selecting the palette. — also in MAME: 4P nintendo/mario.cpp:951 rtl/mario_roms.v:123 Object/Sprite ROMs 7M,7N,7P,7S,7T,7U. — also in MAME: 7M nintendo/mario.cpp:943, 7N nintendo/mario.cpp:944, 7P nintendo/mario.cpp:945, 7S nintendo/mario.cpp:946, 7T nintendo/mario.cpp:947, 7U nintendo/mario.cpp:948 rtl/mario_roms.v:204 CLUT PROM 4P (512x8) Only 256 entries are used. — also in MAME: 4P nintendo/mario.cpp:951 rtl/mario_roms.v:232 Address decoder PROM 5B (32x8) — also in MAME: 5B nintendo/mario.cpp:954 rtl/mario_vram.v:126 Video ROMs 3F, 3J — also in MAME: 3F nintendo/mario.cpp:939, 3J nintendo/mario.cpp:940 Cites MAME source — 1 Arcade-MarioBros.sv:301 JPAC/IPAC/MAME Style Codes Says it was translated, ported or taken from MAME — 1 rtl/mario_roms.v:296 The solution below was taken from MAME. Shares text with the MAME driver without saying so — 1 rtl/mario_input.v:12 BIT 0 1 2 3 4 5 6 7 — shares text with nintendo/mario.cpp:800
MCR1# Kick, Solar Fox MiSTer-devel/Arcade-MCR1_MiSTer @ 7cc5f869 MAME compared: bally/mcr.cpp + 7 related file(s) Read: 13 HDL files, 3,748 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	41%
Statements: 1 toward hardware, 1 toward MAME, 1 not counted Cites hardware documentation that MAME's driver does not — 1 rtl/mcr1.vhd:73 Sprite are 32x32 pixels with 1x1 pixel definition, 16 lines for odd 1/2 frame and 16 lines for even 2/2 frame thanks to V8 on sprite rom ROMAD2 (look at 74ls86 G1 pin 9 on video genration board schematics) Cites hardware references or measurements that MAME's driver also gives — 1 rtl/mcr1.vhd:841 sprite graphics ROM 1E/1D/1B/1A — also in MAME: 1E bally/mcr.cpp:1991, 1D bally/mcr.cpp:1990, 1B bally/mcr.cpp:1989, 1A bally/mcr.cpp:572 Cites MAME source — 1 rtl/YM2149_linmix_sep.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA
MCR2# Domino Man, Kozmik Kroozr, Satan's Hollow, Tron … MiSTer-devel/Arcade-MCR2_MiSTer @ 756fb64d MAME compared: bally/mcr.cpp + 7 related file(s) Read: 13 HDL files, 3,887 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	37%
Statements: 1 toward hardware, 1 toward MAME, 1 not counted Cites hardware documentation that MAME's driver does not — 1 rtl/mcr2.vhd:74 Sprite are 32x32 pixels with 1x1 pixel definition, 16 lines for odd 1/2 frame and 16 lines for even 2/2 frame thanks to V8 on sprite rom ROMAD2 (look at 74ls86 G1 pin 9 on video genration board schematics) Cites hardware references or measurements that MAME's driver also gives — 1 rtl/mcr2.vhd:793 sprite graphics ROM 1E/1D/1B/1A — also in MAME: 1E bally/mcr.cpp:1991, 1D bally/mcr.cpp:1990, 1B bally/mcr.cpp:1989, 1A bally/mcr.cpp:572 Cites MAME source — 1 rtl/YM2149_linmix_sep.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA
MCR3# Discs of Tron, Journey, Tapper, Timber MiSTer-devel/Arcade-MCR3_MiSTer @ f74cb762 MAME compared: bally/mcr.cpp + 7 related file(s) Read: 15 HDL files, 4,460 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	33%
Statements: 1 toward hardware, 2 toward MAME, 2 not counted Cites hardware documentation that MAME's driver does not — 1 rtl/mcr3.vhd:74 Sprite are 32x32 pixels with 1x1 pixel definition, 16 lines for odd 1/2 frame and 16 lines for even 2/2 frame thanks to V8 on sprite rom ROMAD2 (look at 74ls86 G1 pin 9 on video genration board schematics) Cites hardware references or measurements that MAME's driver also gives — 2 rtl/mcr3.vhd:838 background graphics ROM 6F — also in MAME: 6F bally/mcr.cpp:2578 rtl/mcr3.vhd:856 background graphics ROM 5F — also in MAME: 5F bally/mcr.cpp:2579 Cites MAME source — 2 rtl/YM2149_linmix_sep.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA rtl/mcr3.vhd:34 Use with MAME roms from timber.zip
MCR3Mono# Demolition Derby, Max RPM, Power Drive, Rampage … MiSTer-devel/Arcade-MCR3Mono_MiSTer @ 780d31bc MAME compared: bally/mcr3.cpp + 8 related file(s) Read: 15 HDL files, 10,239 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	11%
Statements: 1 toward hardware, 2 toward MAME Cites hardware documentation that MAME's driver does not — 1 rtl/mcr3mono.vhd:74 Sprite are 32x32 pixels with 1x1 pixel definition, 16 lines for odd 1/2 frame and 16 lines for even 2/2 frame thanks to V8 on sprite rom ROMAD2 (look at 74ls86 G1 pin 9 on video genration board schematics) Cites MAME source — 1 rtl/mcr3mono.vhd:34 Use with MAME roms from timber.zip Shares text with the MAME driver without saying so — 1 rtl/turbo_cheap_squeak.vhd:1 Midway Turbo Cheap Squeak sound board — shares text with bally/midway_sound.cpp:34
MCR3Scroll# Crater Raider, Spy Hunter, Turbo Tag MiSTer-devel/Arcade-MCR3Scroll_MiSTer @ 120a1612 MAME compared: bally/mcr3.cpp + 8 related file(s) Read: 16 HDL files, 5,245 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	32%
Statements: 1 toward hardware, 1 toward MAME, 3 not counted Cites hardware documentation that MAME's driver does not — 1 rtl/mcr3scroll.vhd:73 Sprite are 32x32 pixels with 1x1 pixel definition, 16 lines for odd 1/2 frame and 16 lines for even 2/2 frame thanks to V8 on sprite rom ROMAD2 (look at 74ls86 G1 pin 9 on video genration board schematics) Cites hardware references or measurements that MAME's driver also gives — 3 rtl/mcr3scroll.vhd:1017 char graphics ROM 10G — also in MAME: 10G bally/mcr3.cpp:1528 rtl/mcr3scroll.vhd:1034 background graphics ROM 3A/4A — also in MAME: 3A bally/mcr3.cpp:1434, 4A bally/mcr3.cpp:1435 rtl/mcr3scroll.vhd:1051 background graphics ROM 5A/6A — also in MAME: 5A bally/mcr3.cpp:1436, 6A bally/mcr3.cpp:1437 Cites MAME source — 1 rtl/YM2149_linmix_sep.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA
MissileCommand# Missile Command MiSTer-devel/Arcade-MissileCommand_MiSTer @ a0bea970 MAME compared: atari/missile.cpp Read: 24 HDL files, 5,367 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	15%
Statements: 4 toward hardware Cites hardware documentation that MAME's driver does not — 4 rtl/ls42.v:2 74LS42 - BCD to decimal decoder rtl/micro.v:49 L3 - 74S86 - XOR rtl/micro.v:51 C4 - 74S32 - OR rtl/missile.v:473 This part diverges from the original schematics quite a bit.
MoonPatrol# Moon Patrol MiSTer-devel/Arcade-MoonPatrol_MiSTer @ ff2845ca MAME compared: irem/m52.cpp + 5 related file(s) Read: 41 HDL files, 14,453 lines (Quartus project)	MiSTer official	Both	low	12%
Statements: 1 toward hardware, 6 toward MAME Cites hardware documentation that MAME's driver does not — 1 rtl/iremm52_video_controller.vhd:68 from M52 schematics Cites MAME source — 3 rtl/moon_patrol_sound_board.vhd:42 MAME claims that reading 8800 should return Z80's DE register value but PACE do something that seems to be (very) different. rtl/tilemapctl.vhd:85 extract R,G,B from colour palette MAME says there are 512 palette entries although the code uses 6 bits of colour only the highest colour in the PROM is 83 so we're going with 128 (5+2 bits) rtl/ym_2149_linmix.vhd:44 Clues from MAME sound driver and Kazuhiro TSUJIKAWA Shares text with the MAME driver without saying so — 3 rtl/bitmap1_ctl.vhd:87 /* the colors to pick is as follows: / — shares text with irem/m52.cpp:202 rtl/bitmap2_ctl.vhd:87 / the colors to pick is as follows: / — shares text with irem/m52.cpp:202 rtl/bitmap3_ctl.vhd:87 / the colors to pick is as follows: */ — shares text with irem/m52.cpp:202
MrDo# Mr. Do! MiSTer-devel/Arcade-MrDo_MiSTer @ 9a4aed0c MAME compared: universal/mrdo.cpp + 2 related file(s) Read: 12 HDL files, 3,281 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	48%
Statements: 1 toward hardware Cites hardware documentation that MAME's driver does not — 1 Arcade-MrDo.sv:776 address clock on the streaming buffer is at 5M.
MrJong# Mr. Jong MiSTer-devel/Arcade-MrJong_MiSTer @ f78655f6 MAME compared: sanritsu/mrjong.cpp Read: 24 HDL files, 7,608 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	12%
Statements: 1 toward hardware Cites hardware documentation that MAME's driver does not — 1 rtl/audio/sn76489_audio.vhd:52 * The SN76489 datasheet * Insight gained from the AY-3-8910/YM-2149 die-shot and reverse-engineered schematics (similar audio chips from the same era).
MysticMarathon# Mystic Marathon MiSTer-devel/Arcade-MysticMarathon_MiSTer @ adf358ef MAME compared: williams/williams.cpp + 5 related file(s) Read: 10 HDL files, 12,747 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	11%
Statements: 1 toward hardware, 2 toward MAME, 2 not counted Cites hardware documentation that MAME's driver does not — 1 rtl/mystic_marathon_cmos_ram.vhd:29 @04-05: High score to date - BCD 00 to 01 - No / Yes @06-07: Pricing selection - BCD 00 to 09 - Custom / free play @08-09: Left coin slot units - BCD 00 to 99 @0A-0B: Center coin slot units - BCD 00 to 99 @0C-0D: Right co Cites hardware references or measurements that MAME's driver also gives — 2 rtl/mystic_marathon_cmos_ram.vhd:47 @88-89: Position line 1 - HEX x08 to x44 @8A-8B: Position line 2 - HEX x08 to x44 — also in MAME: 8A williams/williams.cpp:2552, 8B williams/williams.cpp:2552 rtl/williams2.vhd:418 ic79 74LS85 controls low background color bank bit w.r.t ligne number (vcnt) — also in MAME: 74LS85 williams/williams_v.cpp:542 Cites MAME source — 1 rtl/williams2.vhd:36 Use with MAME roms from mysticm.zip Shares text with the MAME driver without saying so — 1 rtl/williams2.vhd:329 pixels \|0\|1\|2\|3\|4\|5\|0\|1\|2\|3\|4\|5\| — shares text with williams/williamsblitter.cpp:50
NaughtyBoy# Naughty Boy MiSTer-devel/Arcade-NaughtyBoy_MiSTer @ 519a5a6e MAME compared: phoenix/naughtyb.cpp + 4 related file(s) Read: 12 HDL files, 4,957 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	0%
No statements found
NightSlashers# Night Slashers MiSTer-devel/Arcade-NightSlashers_MiSTer @ 52b0d5b3 MAME compared: dataeast/fghthist.cpp + 14 related file(s) Read: 33 HDL files, 27,713 lines (Quartus project)	MiSTer official	Mostly MAME	medium	43%
Statements: 1 toward hardware, 193 toward MAME, 3 not counted Cites hardware documentation that MAME's driver does not — 1 rtl/nightslashers/ns_audio_z80.sv:10 MAME deco32.cpp (autorevole): Z80 @ 32.22/9 = 3.58 MHz (qui cen 96/27 = 3.556, -0.68%) z80_sound_map: 0000-7FFF ROM, 8000-87FF RAM, A000-A001 YM2151, B000 OKI0, C000 OKI1, D000 soundlatch_r (DECO104) IRQ0 = merger(soundlatch \| ym_irq) (:23 Cites hardware references or measurements that MAME's driver also gives — 3 rtl/nightslashers/nightslashers_top.sv:2595 Quindi la HuC salva: RAM 8K (M10K, porta di lettura UNICA muxata = zero logica), stato CPU (298 bit) e stato bus (32 bit). — also in MAME: 8K dataeast/fghthist.cpp:83 rtl/nightslashers/ns_audio_huc.sv:76 0..8191 = RAM 8K, 8192..8447 = shadow YM — also in MAME: 8K dataeast/fghthist.cpp:83 rtl/nightslashers/ns_audio_huc.sv:366 Lo stato FM/ADPCM del set USA non entra nel savestate; CPU HuC, RAM 8K (M10K) e stato bus si'. — also in MAME: 8K dataeast/fghthist.cpp:83 Cites MAME source — 171 Template.sv:192 FIX 2026-07-03: brev8 text=0 — combo PROVATA DIFF=0 su 262144 pen vs golden MAME (work/tile_text_chain_verify.py); con brev8=1 ogni riga del text era specchiata in X. 2026-07-09 HARDCODED DEFINITIVI — convalidati A SCHERMO dall'utente via O Template.sv:244 Default 0 = MAME -16. Template.sv:288 ATTENZIONE 2026-08-28: il "~70-75% di MAME" che stava scritto qui era una IPOTESI (quantizzazione tick), MAI misurata, e da qui si e' propagata nei documenti come se fosse un dato. Template.sv:291 Ho provato a misurarla con sim/tb/tb_ns_runtime.sv, ma anche quei numeri sono INVALIDI: confrontando la traccia col golden di arm.cpp, quel banco consegna alla CPU una istruzione su due sbagliata (0xFFFFFFFF), quindi misurava un processore Template.sv:295 Quello che resta vero e' solo: la CPU gira a 7,065 MHz contro i 7,000 di MAME (ARM(config, m_maincpu, 28_MHz_XTAL/4)), e Night Slashers rallenta di suo anche in sala — quindi alzare il clock porta il gioco OLTRE la PCB e nasconde anche i ra Template.sv:432 I tile NS SONO criptati (deco32.cpp init_nslasher: deco56 tiles1 + deco74 tiles2, + bitplane reorder). Template.sv:559 --- BoogieWings INPUT mapping (MAME boogwing.cpp:561-633 INPUT_PORTS_START) --- MiSTer joy bit layout (MiSTer convention): [0]=Right, [1]=Left, [2]=Down, [3]=Up [4]=A (FIRE/BTN1), [5]=B (BOMB/BTN2), [6]=X (SPECIAL/BTN3) [10]=Start, [11]=Coi Template.sv:565 INPUTS port (MAME "INPUTS", 16-bit, tutto active LOW): Template.sv:588 SYSTEM port (MAME "SYSTEM", 16-bit): bit 0: COIN1 (active LOW) bit 1: COIN2 (active LOW) bit 2: SERVICE1 (active LOW) bit 3: VBLANK (active HIGH — da screen device) bit 4..15: unused (idle HIGH) Template.sv:595 bit 15..8 = P3 (MAME IN1). Template.sv:607 bit 3 VBLANK (active HIGH MAME → 1 quando in vblank) Template.sv:1016 Il core divide /6 (CPU_CLK_CNT 0..5) -> ciclo macchina = 24/6 = 4.0 MHz = clock HuC MAME (4.0275 MHz, 32.22/8). Template.sv:1119 OSD audio gain decoder: 4 bit → gain 4.4 fixed point 0=Default 1=Mute 2=MAME 3=25% 4=50% 5=75% 6=100% 7=125% 8=150% 9=200% 10=250% 11=300% 12=400% 13=500% 14=700% 15=1000% % indicato è scaling rispetto al Default (= valore base per ogni chi Template.sv:1144 Default HW-tested (= valori RTL applicati con foto utente OSD 200%/300%/400%): FM=0x08 (0.5), OKI0=0xFF (15.94, =sat max), OKI1=0x80 (8.0) MAME esatti: FM=0x05 (0.32), OKI0=0x09 (0.56), OKI1=0x02 (0.12) Template.sv:1165 OSD sel passati direttamente al chip audio (Default/MAME hardcoded dentro). Template.sv:1348 BoogieWings video timing: 320×240 60Hz (boogwing.cpp:731: htot=442, hact=320, vtot=274, vact=240) Pixel clock: 96/14 = 6.857 MHz (divisore intero). Template.sv:1371 2026-07-10 FIX pixel 319 (confronto screenshot MAME dell'utente: a noi mancava l'ultima colonna): rgb_out_q campiona su ce_pix = immagine in ritardo di 1 px vs DE -> la colonna 319 usciva a DE gia' caduto. rtl/cpu_arm/a23_copro_deco156.v:30 bcd<->dec use 8 nibbles (32-bit), base-10, exactly as MAME. rtl/cpu_arm/a23_copro_deco156.v:40 Reproduces public-domain documented behaviour from MAME. rtl/cpu_arm/a23_core.v:358 L'assunzione "zero copro ops" era SBAGLIATA: 2860 istruzioni coproc nel codice, e MAME HandleCoPro implementa il BCD (crn==2 -> add/mul/sub in cr[5]). rtl/cpu_arm/a23_core.v:360 FIX: istanzio a23_copro_deco156 (gia' scritto, fedele a MAME) + disabilito und_request sulle coproc in a23_decode. rtl/cpu_arm/a23_decode.v:79 reset = IRQ MASCHERATO (MAME arm.cpp:319 R15=SVC\|I_MASK\|F_MASK). rtl/cpu_arm/a23_decode.v:79 PROVATO co-sim: con irq_mask=0 l'Amber prende un IRQ nel bit-bang EEPROM (n=41054, 0x3e7a0) dove MAME tiene I=1 -> boot interrotto -> NERO rtl/cpu_arm/a23_decode.v:477 BUG BOOT-FATAL (nero): per un data-processing con operando IMMEDIATO ruotato (instruction[25]=1 && rotate instruction[11:8]!=0) e S-bit, MAME/golden pongono C = bit31 dell'immediato RUOTATO (arm.cpp:788 sc=op2&SIGN_BIT). rtl/cpu_arm/a23_decode.v:571 DECO156 (Night Slashers): MAME arm.cpp:405-410 instrada CDP/MRC/MCR (encoding 0x0e000000) a HandleCoPro SENZA eccezione; solo cio' che NON e' coproc va a Undefined (arm.cpp:422). rtl/cpu_arm/a23_decode.v:580 NB verificato col disassembler: il codice eseguibile NS non contiene coproc reali (tutte nei blocchi dati) -> questa regola e' per fedelta' a MAME, non e' la causa nero. rtl/cpu_arm/a23_execute.v:177 reset = IRQ MASCHERATO (MAME arm.cpp:319). rtl/cpu_arm/a23_execute.v:499 reset = IRQ MASCHERATO (MAME arm.cpp:319). rtl/cpu_arm/a23_execute.v:545 BUG BOOT-FATAL fix: per immediato ruotato il C ai logici = bit31 dell'immediato (gia' ruotato in barrel_shift_in = i_imm32), come MAME arm.cpp:788 (sc=op2&SIGN_BIT). rtl/nightslashers/deco16ic_jt.sv:81 Flip screen globale (MAME boogwing.cpp:419-425: pf_control_r(0) bit 7). rtl/nightslashers/deco16ic_jt.sv:82 Sponta solo da chip 0 (chip1 ha il suo ma MAME usa solo chip0). rtl/nightslashers/deco16ic_jt.sv:125 Combine 8bpp (MAME tilemap_12_combine_draw, priority 4/5): pf1 e pf2 sono lo STESSO pixel (nibble basso/alto). rtl/nightslashers/deco16ic_jt.sv:288 Flip screen globale (MAME boogwing.cpp:419-425): flip = m_deco_tilegen[0]->pf_control_r(0); flip_screen = BIT(flip,7); rtl/nightslashers/deco16ic_jt.sv:292 MAME deco16ic.cpp:899-900 (codice, NON il commento header che è invertito): PF1 scroll = ctrl[1] (X), ctrl[2] (Y) PF2 scroll = ctrl[3] (X), ctrl[4] (Y) rtl/nightslashers/deco16ic_jt.sv:300 Rowscroll enable + style (MAME deco16ic.cpp header riga 94-130) pf12_control[5] (word 0xa): bit 15 = pf1 enable bit 14:11 = pf1 rowscroll style bit 10:8 = pf1 colscroll style bit 7 = pf2 enable bit 6:3 = pf2 rowscroll style bit 2: rtl/nightslashers/deco16ic_jt.sv:319 MAME riga 761: (control0 >> 3) & 0xf -> bit 6:3 per pf1 row style. rtl/nightslashers/deco16ic_jt.sv:326 COLSCROLL Y-per-column (MAME deco16ic.cpp:492-497, 812): col_type = 8 << (control0 & 7) ∈ {8,16,32,64,128,256,512,1024} col_idx = (src_x & 0x1ff) / col_type col_offset = rowscroll_ptr[0x200 + col_idx] // 16-bit Y offset veff_eff = veff + rtl/nightslashers/deco16ic_jt.sv:342 PLAYFIELD DISABLE (MAME deco16ic.cpp:465: if(!BIT(control0,7)) return;). rtl/nightslashers/deco16ic_jt.sv:365 Per text 8x8 MAME dimezza numrows (riga 798); equivalente a >> 1 sull'idx. rtl/nightslashers/deco16ic_jt.sv:388 FIX colonne durante scroll (MAME deco16ic.cpp:493 col_idx da src_x = pixel REALE): src_x deve azzerare il sub-tile offset scroll_x[3:0] (16x16) o [2:0] (8x8). rtl/nightslashers/deco16ic_jt.sv:435 MAME deco32.cpp:918 bank_callback = (bank & ~0xf) << 8 = bank[7:4]<<12, UNIFORME, indipendente dal nibble basso. rtl/nightslashers/deco16ic_jt.sv:436 Il vecchio mode 2 aggiungeva un +0x800 inventato su nibble==0xA (non in MAME) -> mis-bank scenografia chip1 in scene con control[7] nibble 0xA -> tile trasparenti -> sfondo blu. rtl/nightslashers/deco16ic_jt.sv:554 VRAM swizzle hardcoded: 8x8 (text) = Linear idx = {row[4:0], col[5:0]} 16x16 (BG) = DECO_64x32 idx = {col[5], row[4:0], col[4:0]} MAME deco16ic.cpp:245 — TILEMAP_SCAN_ROWS per 8x8, deco16_scan_rows per 16x16. rtl/nightslashers/deco16ic_jt.sv:582 Flip per-tile (MAME deco16ic.cpp:330-341 get_pf1_tile_info): if (vram[15] && ctrl[6][0]) → FLIPX, colour &= 7 if (vram[15] && ctrl[6][1]) → FLIPY, colour &= 7 Per pf2 (16x16): ctrl[6][8] e ctrl[6][9]. rtl/nightslashers/deco16ic_jt.sv:630 Sub-tile X offset: scan parte da tile-aligned, buf_waddr inizia negativo (wrap 9-bit) per scartare i primi N pixel del primo tile (= MAME src_x = scroll_x + render_x). rtl/nightslashers/deco16ic_jt.sv:677 MAME: colour = tile[15:12], if tile[15] && flipctrl colour &= 7 rtl/nightslashers/deco16ic_jt.sv:896 Colscroll attivo: veff_eff = render_y + scroll + cs (MAME esatto). rtl/nightslashers/deco16ic_jt.sv:915 Flip per-tile pf2 (MAME deco16ic.cpp:300-311): ctrl[6][8] = FLIPX, ctrl[6][9] = FLIPY (per pf2) rtl/nightslashers/deco16ic_jt.sv:957 Sub-tile X offset: waddr inizia negativo (= 9-bit wrap) per scartare primi N pixel del primo tile = MAME src_x pixel-by-pixel. rtl/nightslashers/deco16ic_jt.sv:1022 Bit position MAME-natural: sc2_pen_p4 = p4_byte[bit_pos]. rtl/nightslashers/nightslashers_top.sv:11 Hardware MAME (deco32.cpp; boogwing.cpp per l'ossatura condivisa): rtl/nightslashers/nightslashers_top.sv:20 Memory map main (boogwing.cpp:504): 0x000000-0x0FFFFF ROM (1MB, encrypted) 0x200000-0x20FFFF work RAM (64KB) 0x220000 priority_w 0x240000/0x244000 spriteram DMA trigger 0x242000/0x246000 spriteram1/2 (2KB ciascuno) 0x24E000-0x rtl/nightslashers/nightslashers_top.sv:35 Memory map audio H6280 (boogwing.cpp:547): 0x000000-0x00FFFF ROM (64KB) 0x110000 YM2151 r/w 0x120000 OKI1 r/w 0x130000 OKI2 r/w 0x140000 sound latch read 0x1F0000-0x1F1FFF work RAM (8KB) rtl/nightslashers/nightslashers_top.sv:60 Inputs MAME-mapping BoogieWings (vedi docs/99_discovery_log.md): inputs_port = INPUTS (16-bit, P1+P2 joy+button+start, active LOW) system_port = SYSTEM (16-bit, coin+service+vblank, active LOW eccetto vblank) rtl/nightslashers/nightslashers_top.sv:134 24 MHz -> CE_IN HuC (core /6 = 4.0 MHz = MAME) rtl/nightslashers/nightslashers_top.sv:151 OSD audio sel (4 bit each) — Default/MAME hardcoded dentro boogwings_audio rtl/nightslashers/nightslashers_top.sv:284 Noprw range MAME (boogwing.cpp:510, 534, 535) — devono produrre DTACK ma scrittura/lettura senza effetti (read=FFFF, write=ignorata). rtl/nightslashers/nightslashers_top.sv:291 2026-07-10 CPU SPEED OSD: la quantizzazione dei tick (LDR/STR=2 tick, branch=3-4) porta l'effettivo a ~70-75% di MAME -> sforamenti frame nelle scene piene = rallentoni dove l'originale non li ha. rtl/nightslashers/nightslashers_top.sv:456 NS ARM memory map (bytes), from MAME deco32.cpp nslasher_map: 0x000000-0x0FFFFF ROM (SDRAM) 32-bit 0x100000-0x11FFFF work RAM 128KB 32-bit 0x140000-0x140003 vblank ack (write) 0x150000 EEPROM (CS/CLK/DI=6/5/4 rtl/nightslashers/nightslashers_top.sv:485 nslasher_debug_r (0x200000 lower 16) = 0xFFFF fisso (come MAME nslasher_debug_r()). rtl/nightslashers/nightslashers_top.sv:488 NS priority register m_pri: deco32_v.cpp eeprom_w (the 0x150000 write) calls pri_w(data & 0x07). rtl/nightslashers/nightslashers_top.sv:500 ── EEPROM 93C46 seriale (NS) ─────────────────────────────────────────────── MAME deco32.cpp eeprom_w (0x150000 byte): bit6=CS, bit5=CLK, bit4=DI. rtl/nightslashers/nightslashers_top.sv:523 (NS: MAME port_b = eeprom do_read lshift 0. rtl/nightslashers/nightslashers_top.sv:523 I coin NS NON sono in port_b.) FIX STALLO 2026-07-03: system_port[3] dal Template e' VBlank (layout SYSTEM BoogieWings) ma per il firmware NS bit3 = tasto SERVICE active-LOW (MAME IN1, deco32.cpp): col VBlank il gioco vede SERVICE premuto p rtl/nightslashers/nightslashers_top.sv:530 bit 15..4 IDLE fissi: da quando system_port[15:8] porta il P3 (Template 2026-07-11), il port_b NON deve vederlo — MAME port_b = solo EEPROM DO. rtl/nightslashers/nightslashers_top.sv:552 port_c verso il DECO146 = IN1 (MAME deco32.cpp:2021 port_c_cb=IN1, def riga 1554): bit0=COIN1, bit1=COIN2, bit2=SERVICE1, bit3=SERVICE(no-toggle), bit4 (0x0010) = VBLANK active-HIGH (PORT_READ_LINE screen vblank), bit8-10/12-14 = BUTTON rtl/nightslashers/nightslashers_top.sv:572 2026-08-29 — DIMOSTRATO DALLA ROM (non da MAME: il difetto del boss c'e' anche li', quindi come oracolo non vale). rtl/nightslashers/nightslashers_top.sv:750 MAME deco32.cpp ioprot_r/w: deco146_addr = (BIT(real,14,4)<<11) \| BIT(real,0,11), real = in-region byte addr. rtl/nightslashers/nightslashers_top.sv:752 Verified numerically (work/arm_decrypt/deco146_map.py): the 11 LOW bits used by MAME ioprot_r (deco32.cpp:711-714): offset = byte_addr>>2 (umask32 0xffff0000, one 16-bit prot word per 32-bit dword); real_address = offset2 = byte_addr>>1; d rtl/nightslashers/nightslashers_top.sv:777 Tilegen1 (DECO16IC #1): pf1 0x1c2000, pf2 0x1c4000, rowscroll 0x1d2000/0x1d4000, control 0x1e0000 (deco32.cpp nslasher_map). rtl/nightslashers/nightslashers_top.sv:788 The actual buffer copy is done at vblank (MAME buffered_spriteram), the trigger write is a NOP here. rtl/nightslashers/nightslashers_top.sv:797 NS palette/ACE (deco32.cpp nslasher_map): ACE 'Ace' RAM 0x163000-0x16309F (ace_r/ace_w, 40 words) color banks 0x164000 / 0x164004 / 0x164008 (tilemap / spr1 / spr2) buffered palette 0x168000-0x169FFF (8KB = 4096 words = 2048 RGB entri rtl/nightslashers/nightslashers_top.sv:838 ── Read data assembly back to the 32-bit ARM bus ── 16-bit chips return data in the lower half with a 0xFFFF0000 endianness XOR (MAME deco16ic/deco32 dword readers). rtl/nightslashers/nightslashers_top.sv:843 16-bit video chips return their word in the LOWER half with upper=0xFFFF (this IS the MAME 0xFFFF0000 dword XOR, same as the ROM line). rtl/nightslashers/nightslashers_top.sv:1031 MAME boogwing.cpp:529-530: chip1 pf1/pf2 mappati con `.ram().w(deco16ic)`. rtl/nightslashers/nightslashers_top.sv:1197 DECO104 magic xor value (deco104.cpp ctor) rtl/nightslashers/nightslashers_top.sv:1212 NS: IN1 = coin/service + bit4 VBLANK (MAME), NON i DIP rtl/nightslashers/nightslashers_top.sv:1279 NS colour bank registers (0x164000/4/8) — deco32_v.cpp tilemap/sprite_color_bank_w 0x164000 tilemap_color_bank_w: tilegen1 pf1 bank = ((d>>0)&7)<<4, tilegen1 pf2 bank = ((d>>3)&7)<<4 0x164004 sprite1_color_bank_w: sprgen0 colorbase = (d&7)< rtl/nightslashers/nightslashers_top.sv:1308 Decoded fields (raw, consumed by the NS mixer in the palette-index step): tilegen1 pf1 bank field = data[2:0], pf2 bank field = data[5:3] (MAME <<4) sprite0/1 colorbase field = data[2:0] (MAME <<8) Step 1 only CAPTURES these registers; the rtl/nightslashers/nightslashers_top.sv:1341 chip0 ctrl[0] bit 7 (MAME boogwing.cpp:419) rtl/nightslashers/nightslashers_top.sv:1342 Render x/y flippati quando flip_screen=1 (MAME flip_screen_set). rtl/nightslashers/nightslashers_top.sv:1346 Mantengo formula MAME-coerente. rtl/nightslashers/nightslashers_top.sv:1368 BoogieWings bank callbacks (boogwing.cpp:749, 761): tilegen[0]: bank1=none, bank2=bank_callback (mode 1) tilegen[1]: bank1=bank_callback2, bank2=bank_callback2 (mode 2) GFX base address SDRAM (tile_byte_addr relativo a TILE_BASE): tiles1 (t rtl/nightslashers/nightslashers_top.sv:1389 NS: chip0.pf2 (BG) e' 4bpp (deco32.cpp tilelayout, verificato max pen 0xF), NON 5bpp come il BG1 di BoogieWings. rtl/nightslashers/nightslashers_top.sv:1523 Buffer side (DMA write dest + renderer read source) — buffered_spriteram MAME-style rtl/nightslashers/nightslashers_top.sv:1543 MAME (buffer_spriteram_w = memcpy istantanea) non perde MAI una write. rtl/nightslashers/nightslashers_top.sv:1543 Con la CPU al ~70-75% di MAME le scene piene sforano il frame -> la build della lista nuova parte mentre la copia gira -> prime entry (boss) droppate = pezzi col frame vecchio = movimenti nervosi. rtl/nightslashers/nightslashers_top.sv:1546 Write-through sempre: la copia prende vecchio-o-nuovo per word (jitter +/-77us, MAME-legale). rtl/nightslashers/nightslashers_top.sv:1610 ── FIX STIRAMENTO 2026-07-19 (correla con rallentamenti CPU) ── MAME (deco32.cpp:842 buffer_spriteram_w): il copy live->buffer avviene SOLO quando la CPU scrive 0x174010/0x17c010 (= lista sprite COMPLETA). rtl/nightslashers/nightslashers_top.sv:1643 copy LIVE -> BUFFER a VBlank rise, SOLO se la CPU ha triggerato (0x174010/ 0x17c010 = lista completa, MAME buffer_spriteram_w). rtl/nightslashers/nightslashers_top.sv:1711 CPU readback NON serve (write-only dal punto di vista di MAME boogwing: il chip è palette device, leggere è debug). rtl/nightslashers/nightslashers_top.sv:1717 Palette DECO_ACE 24-bit RGB888 (MAME deco_ace.cpp): m_paletteram[2048] è uint32: bits 23:16 = B byte, 15:8 = G byte, 7:0 = R byte. rtl/nightslashers/nightslashers_top.sv:1728 MAME deco_ace.cpp:131/177: m_paletteram[entry]=data; b=d[23:16] g=d[15:8] r=d[7:0]. rtl/nightslashers/nightslashers_top.sv:1779 CPU READBACK VERO (MAME buffered_palette_r) — copia dedicata: le 2 porte di pal_cpu_ent sono gia' occupate (write CPU/SS + read DMA). rtl/nightslashers/nightslashers_top.sv:1835 FIX: trigger = pulse di 1 ck (rising edge), come MAME. rtl/nightslashers/nightslashers_top.sv:1873 FIX 2026-07-03 stride ACE: MAME umask32 (deco32.cpp:630) = 1 reg per DWORD -> idx = aa[7:2]. rtl/nightslashers/nightslashers_top.sv:1961 Palette index base (boogwing.cpp:gfx_boogwing entries): tiles1 (text 8×8) = palette base 0x800 tiles2 (deco16_0) = palette base 0x100 tiles3 (deco16_1) = palette base 0x300 rtl/nightslashers/nightslashers_top.sv:1974 Palette index per layer (MAME gfx_boogwing boogwing.cpp:671): tiles1 (text) → base 0x800, 16 set × 16 col (4bpp) tiles2 (BG1) → base 0x100, 16 set × 32 col (5bpp → ora 4bpp, upper half vuota finché plane 4 non impl) tiles3 (BG2) → base rtl/nightslashers/nightslashers_top.sv:1990 La logica MAME ha 5 modi diversi via priority_reg[2:0] (vedi screen_update); per ora implemento solo l'ordine default. rtl/nightslashers/nightslashers_top.sv:1992 (col_bank di chip1 pf2 è già dentro d16_1_pf2_col → non sommato qui) Palette base per layer — MAME GFXDECODE (boogwing.cpp:672-674): MAME gfx_nslasher (deco32.cpp:1870): text(tiles1 charlayout)=0x800, BG1(tiles1 tilelayout)=0x000, BG2/3(til rtl/nightslashers/nightslashers_top.sv:1998 Base NS = 0x000 + color bank runtime (0x164000) sommato sopra, come MAME deco16_tilemap_colour_bank. rtl/nightslashers/nightslashers_top.sv:2001 BG1 (MAME tiles1 tilelayout base 0) rtl/nightslashers/nightslashers_top.sv:2002 BG2 (MAME tiles2 tilelayout base 0) rtl/nightslashers/nightslashers_top.sv:2006 Layer mixer con priority register MAME-compliant (5 modi). rtl/nightslashers/nightslashers_top.sv:2007 Riferimento: boogwing.cpp:417-477 screen_update. rtl/nightslashers/nightslashers_top.sv:2026 FIX 2026-07-03 (MAME deco32.cpp:1152 + deco32_v.cpp:492): i modi sono BIT, non valori: bit0=ordine layer, bit1=BG2/3 joint 8bpp, bit2=fade. rtl/nightslashers/nightslashers_top.sv:2027 Il vecchio decode (pri==4\|\|pri==5) teneva il mixer in combine-mode con pri=4 runtime, dove MAME (m_pri&2=0) disegna i layer SEPARATI. rtl/nightslashers/nightslashers_top.sv:2035 FIX 2026-07-03 COLOR BANK (MAME deco32.cpp:2326 pf2_col_bank=0x10 statico su chip0; deco32_v.cpp:56-59 cbank runtime <<4 colori = <<8 entry su chip1): il fix di giugno "basi a 0x000" era incompleto — i BG indicizzano a +0x100/+0x200/+0x300 rtl/nightslashers/nightslashers_top.sv:2046 Pal_idx singoli (per modi separati) BG1 (chip0.pf2): bank statico MAME 0x10 (=+0x100 entry) + stride 4bpp col16 (il vecchio col<<5 era eredita' 5bpp BoogieWings). rtl/nightslashers/nightslashers_top.sv:2052 MAME formula: pal_idx = base + bank + col_5b * 16 + pen[3:0]. rtl/nightslashers/nightslashers_top.sv:2061 NS sprite palette (mix_nslasher, ns_video.cpp:346/395): chip0 (5bpp, gfx0): col0 = (color[4:0] % 16) * granularity(32); base = colorbase = sprite1_color_bank_w (data&7)<<8. rtl/nightslashers/nightslashers_top.sv:2083 NS MIX — FEDELE a mix_nslasher (reference/ns_video.cpp:322-462) + screen_update_nslasher (:464-522). rtl/nightslashers/nightslashers_top.sv:2089 get_alpha (deco_ace.cpp): regval>0x20 -> 0x80; else clamp(255 - reg<<3). rtl/nightslashers/nightslashers_top.sv:2100 Attributi sprite (bit del temp-word MAME priColAlphaPal0/1): rtl/nightslashers/nightslashers_top.sv:2115 else: FG1 (primask 1) sotto; m_pri&1: BG1 (2), FG0 (4 -> alpha bitmap se ns_at_en, NIENTE priority) else: FG0 (2), BG1 (4 -> alpha bitmap se ns_at_en) BACKDROP = pen 0x300 (deco32_v.cpp:476). rtl/nightslashers/nightslashers_top.sv:2118 ns_tm_pri = tilemapPri MAME (4/2/1/0). rtl/nightslashers/nightslashers_top.sv:2188 coloffs del ramo sprite1 e alpha-tilemap (mix :387): 0x800 SOLO se (m_pri&4)==0 E sprite0 ha disegnato (il nome MAME 'sprite1_drawn' = s0 drew, fuorviante). rtl/nightslashers/nightslashers_top.sv:2227 TEXT: MAME lo disegna ULTIMO, sopra tutto (screen_update :65) rtl/nightslashers/nightslashers_top.sv:2262 === DECO_ACE FADE (deco_ace.cpp:165-199) — ESATTO, identico a MAME bit-per-bit. rtl/nightslashers/nightslashers_top.sv:2304 Palette RAW vs FADED (deco_ace.cpp:175-198): la palette deco_ace ha 4096 pen: 0x000-0x7FF = palette CON fade (set_pen_color(i)). rtl/nightslashers/nightslashers_top.sv:2307 MAME indicizza con paldata[pal_idx]: se pal_idx >= 0x800 -> RAW (no fade). rtl/nightslashers/nightslashers_top.sv:2308 Gli sprite/BG (base <0x800) vanno raw solo col calculated_coloffs (priority bit3 -> +0x800, boogwing.cpp:355). rtl/nightslashers/nightslashers_top.sv:2311 Il bit 11 dell'indice (0x800) marca "raw" = bypass del fade, PER-PIXEL su top e bot separati (come MAME: l'offset 0x800 e' per-sorgente, NON globale). rtl/nightslashers/nightslashers_top.sv:2344 MAME alpha_blend_r32 convention: result = (src * alpha + dst * (256 - alpha)) >> 8. rtl/nightslashers/nightslashers_top.sv:2360 MAME sub_blend_r32 (boogwing.cpp:180-188): INVERTE la source (s ^= 0xffffff), poi blend tra src_invertita e dst con shift >>9: result = (inv_src * level + dst * (256 - level)) >> 9 (level = alpha) Output SEMPRE in range, mai sotto zero ( rtl/nightslashers/nightslashers_top.sv:2379 In MAME line 408: alpha_blend_r32(dstline[x] = BG, pix3 = FG0). rtl/nightslashers/nightslashers_top.sv:2399 Fade sul colore at (stessa formula, raw-exempt su idx bit11) — il fade e' affine: commuta col blend convesso, quindi l'ordine fade->blend qui equivale al MAME (pen gia' fadate). rtl/nightslashers/nightslashers_top.sv:2496 2026-07-10 AUDIO VERO (set World/Korea/Japan): Z80 (T80pa) + YM2151 (jt51) + 2x OKI (jt6295) secondo MAME deco32.cpp z80_sound_map/nslasher config. rtl/nightslashers/nightslashers_top.sv:2668 24 MHz -> CE_IN HuC (core /6 = 4.0 MHz = MAME) rtl/nightslashers/nightslashers_top.sv:2825 sprite_romaddr e' in spazio MAME (= source 4MB). rtl/nightslashers/nightslashers_top.sv:2934 NS tile layout (deco32.cpp): only 2 regions, both 2MB, both 4bpp. rtl/nightslashers/nightslashers_top.sv:2977 Sprite download interleave: layout MAME tile_16x16_layout richiede plane 0,1 da LO region, plane 2,3 da HI region. rtl/nightslashers/ns_audio_huc.sv:15 MAME deco32.cpp nslasheru: the US release uses HuC6280 instead of the Z80. rtl/nightslashers/ns_audio_huc.sv:19 HuC clock: CE_IN = frac_cen 16.11 MHz; firmware CSH -> /6 = 2.685 MHz MAME-exact. rtl/nightslashers/ns_audio_huc.sv:20 HuC internal PSG NOT used (MAME: internal sound unused). rtl/nightslashers/ns_audio_huc.sv:30 24 MHz pulse -> CE_IN HuC (core /6 = 4.0 MHz = MAME) rtl/nightslashers/ns_audio_huc.sv:141 Il core divide /6 (CPU_CLK_CNT 0..5) -> ciclo macchina = 24/6 = 4.0 MHz = clock HuC MAME (4.0275 MHz = 32.22/8). rtl/nightslashers/ns_audio_huc.sv:143 VALIDATO coi numeri MAME (screenshot): YM/OKI corretti (<1%), solo l'HuC era fuori. rtl/nightslashers/ns_audio_huc.sv:195 -- Decode h6280_sound_map — STRETTO, identico alla build che suonava (brjbx8300 ricostruita): periferiche su finestre 16 byte come la mappa MAME (110000-110001 ecc.), NON pagine intere 64K (pattern BW). rtl/nightslashers/ns_audio_huc.sv:245 Il firmware HuC ASSUME RAM=0 (come MAME .ram() power-on clear): il suo TAI init la azzera, ma sul ferro il timing puo' far saltare la sincronizzazione -> RAM indefinita -> avvio a caso a ogni reset (dimostrato sul ferro). rtl/nightslashers/ns_audio_huc.sv:281 -- Soundlatch MAME-exact — LATCH SINGOLO, non FIFO (2026-07-14) ------------- La build che SUONAVA sul ferro (brjbx8300, ricostruita bit-exact dagli archivi di sessione) usava QUESTO schema: un byte (ultima write vince) + flag IRQ level, CL rtl/nightslashers/ns_audio_z80.sv:10 MAME deco32.cpp (autorevole): Z80 @ 32.22/9 = 3.58 MHz (qui cen 96/27 = 3.556, -0.68%) z80_sound_map: 0000-7FFF ROM, 8000-87FF RAM, A000-A001 YM2151, B000 OKI0, C000 OKI1, D000 soundlatch_r (DECO104) IRQ0 = merger(soundlatch \| ym_irq) (:23 rtl/nightslashers/ns_audio_z80.sv:93 La voce OSD "MAME" resta ai pesi route MAME fedeli (ym 0.40, oki0 0.80, oki1 0.10 in Q4.4) per confronto. rtl/nightslashers/ns_audio_z80.sv:193 ── Decode (mappa MAME z80_sound_map) ─────────────────────────────────────── rtl/nightslashers/ns_audio_z80.sv:224 ── Soundlatch MAME-exact (deco146 soundlatch_r / write_soundlatch) ───────── FIX 2026-07-10: il latch REALE e' UN byte + flag IRQ level: ogni write SOVRASCRIVE (l'ultima vince), la read Z80 di D000 CLEARA l'IRQ e restituisce il byte corrent rtl/nightslashers/ns_audio_z80.sv:233 Semantica MAME = per makeup. rtl/nightslashers/ns_audio_z80.sv:312 ── IRQ merger (MAME :2380): soundlatch \| YM -> IRQ0 ──────────────────────── rtl/nightslashers/ns_audio_z80.sv:510 ── DIN mux Z80 ────────────────────────────────────────────────────────────── FIX 2026-07-10 — LA CAUSA DEL "motore muto": MAME z80_sound_io (deco32.cpp:688) mappa TUTTI i 64KB della ROM nello spazio I/O: map(0x0000, 0xffff).rom().region("a rtl/nightslashers/ns_sprites.sv:9 MAME equivalente: m_sprite_bitmap full-frame 320×256 + draw_sprites_common. rtl/nightslashers/ns_sprites.sv:23 Output identico al MAME m_sprite_bitmap se scan ordinata correttamente. rtl/nightslashers/ns_sprites.sv:26 MAME standard format (offs +0/+1/+2): +0: efFbSssyyyyyyyyy e=priority, f=flipy, F=flipx, b=flash, S=w, ss=h +1: tttttttttttttttt tile code +2: ppcccccxxxxxxxxx pp=priority, ccccc=color (5b), x=xpos rtl/nightslashers/ns_sprites.sv:106 flipscreen sprite — MAME boogwing.cpp:424 set_flip_screen(!BIT(flip,7)) → SEMPRE invertito rispetto a flip_screen input (= tilemap flip). rtl/nightslashers/ns_sprites.sv:129 Frame parity per il FLASH sprite (MAME decospr.cpp:227: flag y_word[12], lo sprite e' nascosto sui frame DISPARI -> if(!(flash && (frame_number & 1))) draw). rtl/nightslashers/ns_sprites.sv:140 ~pause_in: in pausa il vblank continua (display vivo) ma la parita' frame resta ferma -> il FLASH si congela come su PCB/MAME (niente flicker in pausa). rtl/nightslashers/ns_sprites.sv:348 MAME decospr.cpp:267-282 + 297-314 — formula completa boogwing con flipscreen=ON: rtl/nightslashers/ns_sprites.sv:357 MAME boogwing.cpp:424 set_flip_screen(!BIT(flip,7)) → default ON (flip[7]=0). rtl/nightslashers/ns_sprites.sv:369 Solo "sign-ext" con soglia 320 (MAME decospr.cpp:267-269): x = x & 0x1ff; (9-bit 0..511) if (x >= 320) x -= 512; (0..319 unsigned, 320..511 → -192..-1) Risultato: signed -192..319 (10-bit signed sufficiente). rtl/nightslashers/ns_sprites.sv:572 fx_eff = flipx ^ flipscreen_spr (MAME riga 306-313: flipscreen invertito m_flipallx=0) NB: fx_eff (dai reg FSM) serve SOLO all'address-gen (half_use in S_ROM_REQ); la catena pen del DRAW usa lo snapshot d_flipx/d_pix (il draw gira in parall rtl/nightslashers/ns_sprites.sv:598 MAME planeoffset = {hi+8, hi+0, lo+8, lo+0} → plane 0 = byte 3 (mbd-05 alto), plane 1 = byte 2, plane 2 = byte 1, plane 3 = byte 0 (mbd-06 basso). rtl/nightslashers/ns_sprites.sv:611 MAME order: pen={p4,planes1..4}. rtl/nightslashers/ns_sprites.sv:739 Se OFF, doppia inversione MAME (240-y, 304-x). rtl/nightslashers/ns_sprites.sv:769 MAME decospr.cpp:297-304: flipscreen OFF: mult = -16, tile cresce verso l'alto da sy → bounding box [sy - 16multi, sy + 16) → dy_top = scan_y - (sy - 16multi) = (scan_y - sy) + 16multi flipscreen ON: mult = +16, tile cresce verso il bas rtl/nightslashers/ns_sprites.sv:807 MAME: non-intersecante = nulla. rtl/nightslashers/ns_sprites.sv:834 FIX flipx half-swap: quando fx_eff=1 (sprite specchiato), MAME inverte anche l'ordine dei 2 half del tile (oltre al flip pixel-in-byte già fatto da bit_x). rtl/nightslashers/ns_sprites.sv:901 FIX BUG #2: MAME decospr.cpp:351 → 2° blocco a (x+16) per flipscreen_spr=1, (x-16) per flipscreen_spr=0. README.md:12 This core reimplements the hardware in SystemVerilog from MAME references and hardware observation. README.md:127 MAME does exactly the same thing, step for step, which points at the game code itself rather than at the emulation: the geometry of the trap traces back to README.md:141 DECO104 protection (I/O + data scramble) reproduced from MAME README.md:142 MAME-accurate DECO16IC tilemaps (per-row / per-column scroll) README.md:146 Z80 audio chain fully working*: YM2151 + 2× OKI M6295, DECO104 sound latch, song data served through the Z80 I/O-mapped ROM (MAME `z80_sound_io`) README.md:165 Two DECO16IC tilemap chips: BG0/BG1 (chip 0) + FG0/FG1 (chip 1), 16×16 and 8×8 tiles, per-row and per-column scroll — MAME-accurate Says it matches, follows or was checked against MAME — 6 Template.sv:433 Ogni decode verificato bit-exact vs golden MAME. rtl/cpu_arm/a23_copro_deco156.v:13 Behaviour is reproduced BIT-EXACT from MAME // src/devices/cpu/arm/arm.cpp (HandleCoPro, BCDToDecimal, // DecimalToBCD): // rtl/cpu_arm/a23_copro_deco156.v:101 Combinational BCD <-> decimal (8 nibbles), matches MAME loops. rtl/cpu_arm/a23_register_bank.v:322 Stessi reg che tb_cosim.sv confronta bit-exact vs golden MAME (vis_reg/vis_r15). rtl/nightslashers/nightslashers_top.sv:559 Provato bit-exact in golden MAME + co-sim RTL (work/arm_decrypt). rtl/nightslashers/nightslashers_top.sv:810 ── STRIDE FIX (causa NERO provata bit-exact via golden): il DECO156 e' ARM 32-bit, MAME mappa il video con handler _dword_w => indice = byteaddr>>2 (÷4). Says it was translated, ported or taken from MAME — 7 rtl/nightslashers/deco16ic_jt.sv:154 State allargato a 5 bit per supportare colscroll lookup per-half (MAME 1:1). rtl/nightslashers/deco16ic_jt.sv:385 COLSCROLL idx (per-half lookup, MAME 1:1 per pixel collassato a per-half perché cs_off è costante nei 8 px consecutivi per col_type≥8). rtl/nightslashers/deco16ic_jt.sv:487 MAME 1:1: colscroll lookup PER PIXEL (in pratica per HALF di 8 px quando col_type≥8). rtl/nightslashers/deco16ic_jt.sv:546 MAME 1:1. rtl/nightslashers/deco16ic_jt.sv:727 MAME 1:1 per-pixel collapsed per HALF perché cs_off è costante negli 8 px consecutivi con col_type≥8. rtl/nightslashers/deco16ic_jt.sv:890 COLSCROLL Y latched pf2 per-half (MAME 1:1). rtl/nightslashers/nightslashers_top.sv:2364 Questa replica MAME 1:1. Keeps a MAME approximation — 1 Template.sv:1128 MAME (placeholder, gestito sotto) Shares text with the MAME driver without saying so — 8 Template.sv:296 MAME (ARM(config, m_maincpu, 28_MHz_XTAL/4)), e Night Slashers rallenta di — shares text with dataeast/fghthist.cpp:938 Template.sv:309 "P5O[43:38],BG0 X offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29,-2 — shares text with dataeast/deco146.h:71 Template.sv:310 "P5O[49:44],BG0 Y offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29,-2 — shares text with dataeast/deco146.h:71 Template.sv:311 "P5O[55:50],BG1 X offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29,-2 — shares text with dataeast/deco146.h:71 Template.sv:312 "P5O[61:56],BG1 Y offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29,-2 — shares text with dataeast/deco146.h:71 Template.sv:313 "P5O[79:74],FG X offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29,-28 — shares text with dataeast/deco146.h:71 Template.sv:314 "P5O[85:80],FG Y offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29,-28 — shares text with dataeast/deco146.h:71 rtl/nightslashers/ns_audio_z80.sv:513 map(0x0000, 0xffff).rom().region("audiocpu", 0); — shares text with dataeast/fghthist.cpp:733
NinjaKun# Ninjakun Majou no Bouken, Nova 2001, Raiders5 MiSTer-devel/Arcade-NinjaKun_MiSTer @ 9f15cbc9 MAME compared: upl/nova2001.cpp + 2 related file(s) Read: 20 HDL files, 6,760 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	8%
Statements: 2 toward MAME Cites MAME source — 2 rtl/YM2149_linmix_sep.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA README.txt:64 Note for Nova 2001 (From Mame)
OffTheWall# Off the Wall MiSTer-devel/Arcade-OffTheWall_MiSTer @ bf0f9281 MAME compared: atari/offtwall.cpp + 8 related file(s) Read: 37 HDL files, 4,243 lines (Quartus project)	MiSTer official	Mostly hardware	low	28%
Statements: 17 toward hardware, 9 toward MAME, 10 not counted Cites hardware documentation that MAME's driver does not — 16 rtl/io/offtwall_inputs.sv:1 SPDX-License-Identifier: GPL-3.0-or-later The I/O block at 260000: LS138 decoder 12J, player and status muxes, output latch 10J and the LETA at 16A. rtl/io/offtwall_inputs.sv:73 LS174 10J: clocked by the rising edge of /LATCH, cleared by /SYSRES. rtl/main/offtwall_cpu.sv:1 SPDX-License-Identifier: GPL-3.0-or-later 68000 at 13F: fx68k with its two clock-phase enables. rtl/main/offtwall_decode.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Main address decode: the GAL at 15F and the F138 at 10F behind it. rtl/main/offtwall_dtack.sv:1 SPDX-License-Identifier: GPL-3.0-or-later /DTACK: the 74F163 wait counter at 15J. rtl/main/offtwall_eeprom_28c16.sv:1 SPDX-License-Identifier: GPL-3.0-or-later 28C16 EEPROM at 19L (2K x 8) and the flop that locks it. rtl/main/offtwall_nvram_io.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Loads and saves the image of the 28C16 EEPROM at 19L (MiSTer only). rtl/main/offtwall_watchdog.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Power-on reset and watchdog: the 74LS197 counter at 8D. rtl/video/offtwall_lb.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Motion object line buffers (LB 137536-001 at 2N and its RAM): two banks, one written by the MOB for the next line while the other is displayed and erased behind the beam. rtl/video/offtwall_mob.sv:1 SPDX-License-Identifier: GPL-3.0-or-later MOB 137593-001 at 8N: for every line, read the first link from the SLIP table, walk the linked list of motion objects in video RAM and draw the stamp rows that cross the line into the line buffer. rtl/video/offtwall_vad_regs.sv:1 SPDX-License-Identifier: GPL-3.0-or-later VAD 137656-002 at 8F: the 32-word register file, the end-of-frame reload and the parameter-word decoder. rtl/video/offtwall_vad_sync.sv:1 SPDX-License-Identifier: GPL-3.0-or-later VAD 137656-002 at 8F: beam counters, sync, blanking and the scanline interrupt, programmed by registers 01-05. README.md:9 It was built from Atari's schematics and from the equations of the board's GAL chips, with MAME used as a cross-reference where the published documents are sile README.md:107 \| Address decode \| GAL 136090-1003, with wait states from a 74F163 counter \| README.md:113 \| Watchdog \| a 74LS197 counting frames; also the power-on reset \| README.md:134 The I/O block, the LETA, the sound board's latches, mailbox, interrupt timer and analog filters follow Atari's schematics. Cites hardware references or measurements that MAME's driver also gives — 10 rtl/gal/offtwall_gal_1003.sv:1 SPDX-License-Identifier: GPL-3.0-or-later GAL16V8 136090-1003 at 15F: main address decoder. — also in MAME: 136090-1003 atari/offtwall.cpp:593, 15F atari/offtwall.cpp:593 rtl/gal/offtwall_gal_1006.sv:1 SPDX-License-Identifier: GPL-3.0-or-later GAL16V8 136090-1006 at 5F. — also in MAME: 136090-1006 atari/offtwall.cpp:595, 5F atari/offtwall.cpp:595 rtl/gal/offtwall_gal_1007.sv:1 SPDX-License-Identifier: GPL-3.0-or-later GAL16V8 136090-1007 at 3F. — also in MAME: 136090-1007 atari/offtwall.cpp:596, 3F atari/offtwall.cpp:596 rtl/main/offtwall_sloop.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Program ROM bank device, 136090-1001 (a GAL6001 next to the program ROMs). — also in MAME: 136090-1001 atari/offtwall.cpp:591 rtl/mem/offtwall_prog_rom.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Program ROM, 256 KB (two 27C010 at 17E and 17J), held in block RAM so that every read takes the same time, as it does on the board. — also in MAME: 17E atari/offtwall.cpp:569, 17J atari/offtwall.cpp:570 rtl/video/offtwall_mixer.sv:2 5F (136090-1006) chooses the pen and 3F (136090-1007) the colour: the motion object wins wherever the line buffer holds one. — also in MAME: 5F atari/offtwall.cpp:595, 136090-1006 atari/offtwall.cpp:595, 3F atari/offtwall.cpp:596, 136090-1007 atari/offtwall.cpp:596 README.md:106 \| Program ROM \| 256 KB; the top 32 KB is bank-switched by the GAL 136090-1001 \| — also in MAME: 136090-1001 atari/offtwall.cpp:591 README.md:108 \| Video \| VAD 137656-002 (timing, one scrolling playfield of 8 x 8 tiles, video RAM), MOB 137593-001 (motion objects) and its line buffer, mixer GALs 136090-100 — also in MAME: 136090-1006 atari/offtwall.cpp:595, 136090-1007 atari/offtwall.cpp:596 README.md:131 The main address decoder, the video mixer and the sound board's decoder use the equations of the board's GAL chips (136090-1003, -1006, -1007 and the JSA III's — also in MAME: 136090-1003 atari/offtwall.cpp:593, 136085-1038 atari/offtwall.cpp:587 README.md:153 Atari's schematics of this board's CPU, decode and video sections were never published, and the bank-switching GAL 136090-1001 has never been read out. — also in MAME: 136090-1001 atari/offtwall.cpp:591 Notes where it differs from MAME — 1 README.md:139 Where this core differs from MAME Cites MAME source — 8 rtl/video/offtwall_vad_sync.sv:8 Register fields (layout as in MAME; the VAD sheet was never published): 01 vsync start line (11-3), vsync end (2-0) 02 last line (15-9), vblank start line (8-0) 03 scanline interrupt line (8-0) 04 hsync end / 2 (15-10), hsync start (9-0 README.md:9 It was built from Atari's schematics and from the equations of the board's GAL chips, with MAME used as a cross-reference where the published documents are sile README.md:48 Until a save file exists the core starts from the factory settings in the MAME set. README.md:141 \| Behaviour \| MAME \| This core \| README.md:182 Every block has its own test bench, and the whole core was simulated with the real 68000 (fx68k), 6502 (T65) and YM2151 (jt51) models, loading the ROMs exactly README.md:187 Attract mode and a full game, 1,480 frames of each set: every frame is a MAME frame, or lies between two consecutive MAME frames where the game changes the README.md:194 Sound board, driven by MAME's command log: every byte between the two CPUs is passed in the same order as in MAME. README.md:259 Thanks to the MAME team, whose `offtwall.cpp`, `atarijsa`, `atarivad` and `atarimo` code was the cross-reference throughout, and to the people who recovered the Says it matches, follows or was checked against MAME — 1 rtl/video/offtwall_vad_regs.sv:7 The VAD sheet was never published; this follows MAME's atarivad and what the game program does.
Pacman# Ali Baba and 40 Thieves, Birdiy, Pacman Club / Club Lambada, Korosuke Roller … MiSTer-devel/Arcade-Pacman_MiSTer @ 9bcb0b6d MAME compared: pacman/jrpacman.cpp, pacman/pacman.cpp + 3 related file(s) Read: 21 HDL files, 8,553 lines (Quartus project)	MiSTer official	Mostly MAME	low	21%
Statements: 156 toward MAME, 3 not counted Cites hardware references or measurements that MAME's driver also gives — 3 rtl/pacman.vhd:628 8 bit addressable latch 7K (made into register) — also in MAME: 7K pacman/pacman.cpp:3710 rtl/pacman.vhd:720 Pac-Man latch2 (0x5070-0x5077, LS259 1H) and scroll (0x5080), gated on mod_jr. — also in MAME: 1H pacman/jrpacman.cpp:281 rtl/pacman_rom_descrambler.vhd:49 Also the graphics ROMs at 5E, 5F on the main board are replaced. — also in MAME: 5E pacman/pacman.cpp:196, 5F pacman/pacman.cpp:245 Cites MAME source — 8 rtl/pacman.vhd:232 Pac-Man program-ROM DECRYPTION (jrpacman.cpp init_jrpacman, lines 384-425). rtl/pacman.vhd:233 MAME decrypts by walking the maincpu region linearly and XORing each byte with a run-length-encoded value. rtl/pacman.vhd:499 Pac-Man video RAM address (mod_jr) — faithful jrpacman_scan_rows (pacman_v.cpp:607; 36x54 map, per-column scroll) + per-column colour. rtl/pacman.vhd:502 MAME's col-=2 / row+=2 therefore land on the 256H/256V boundary (0x20), NOT 0x02. rtl/pacman.vhd:507 mc = map col = (hcnt 8:3) - 0x20 (== MAME col-2, wrap-correct); HUD edges when mc & 0x20. rtl/pacman.vhd:508 mr = map row = ((vcnt[+scroll]) 8:3) - 0x20 (== MAME row+2; scroll applied to PLAYFIELD only). rtl/pacman_rom_descrambler.vhd:39 The following comments and source code in the comments are from MAME source code and are included here to help make sense of the logic used in the VHDL address mapper and descrambler rtl/sn76489/sn76489_noise.vhd:199 Tapped bits according to MAME's sn76496.c, implemented in function lfsr_tapped_f. Shares text with the MAME driver without saying so — 148 rtl/pacman.vhd:233 The aux-board encryption PALs garble bits 0, 2, 7. MAME decrypts by walking the — shares text with pacman/jrpacman.cpp:369 rtl/pacman_rom_descrambler.vhd:49 Ms. Pac-Man has an auxiliary PCB with ribbon cable that plugs into the Z-80 CPU socket of a Pac-Man main PCB. Also the — shares text with pacman/pacman.cpp:906 rtl/pacman_rom_descrambler.vhd:50 graphics ROMs at 5E, 5F on the main board are replaced. — shares text with pacman/pacman.cpp:907 rtl/pacman_rom_descrambler.vhd:52 The aux board contains three ROMs (two 2532 at U6, U7 and one 2716 at U5), a Z-80, and four PAL/HAL logic chips. — shares text with pacman/pacman.cpp:909 rtl/pacman_rom_descrambler.vhd:54 The aux board logic decodes the Z-80 address and determines whether to enable the main board ROMs (containing Pac-Man — shares text with pacman/pacman.cpp:911 rtl/pacman_rom_descrambler.vhd:55 code) or the aux board ROMs (containing Ms. Pac-Man code). Normally the Pac-Man ROMs reside at address 0x0000-0x3fff — shares text with pacman/pacman.cpp:912 rtl/pacman_rom_descrambler.vhd:56 and are mirrored at 0x8000-0xbfff (Z-80 A15 is not used in Pac-Man). The aux board logic modifies the address map and — shares text with pacman/pacman.cpp:913 rtl/pacman_rom_descrambler.vhd:57 enables the aux board ROMs for addresses 0x3000-0x3fff and 0x8000-0x97ff. Furthermore there are forty 8-byte "patch" — shares text with pacman/pacman.cpp:914 rtl/pacman_rom_descrambler.vhd:58 regions which reside in the 0x0000-0x2fff address range. Any access to these patch addresses will disable the Pac-Man — shares text with pacman/pacman.cpp:915 rtl/pacman_rom_descrambler.vhd:59 ROMs and enable the aux board ROM. Aux board ROM addresses 0x8000-0x81ef are mapped onto the patch regions. These — shares text with pacman/pacman.cpp:916 rtl/pacman_rom_descrambler.vhd:60 patches typically insert jumps to new code above 0x8000. — shares text with pacman/pacman.cpp:917 rtl/pacman_rom_descrambler.vhd:62 The aux board logic also acts as a software protection circuit which inhibits dumping of the ROMs (e.g., using a — shares text with pacman/pacman.cpp:919 rtl/pacman_rom_descrambler.vhd:63 microprocessor emulator system). There are several "trap" address regions which enable and disable the decode — shares text with pacman/pacman.cpp:920 rtl/pacman_rom_descrambler.vhd:64 functions. In order to properly operate as Ms. Pac-Man you must access one of the "latch set" trap addresses. This — shares text with pacman/pacman.cpp:921 rtl/pacman_rom_descrambler.vhd:65 enables the decode. If a "latch clear" address is accessed then decode is disabled and all you get is Pac-Man. For — shares text with pacman/pacman.cpp:922 rtl/pacman_rom_descrambler.vhd:66 more info see U.S. Patent 4,525,599 "Software protection methods and apparatus". — shares text with pacman/pacman.cpp:923 rtl/pacman_rom_descrambler.vhd:68 The trap regions are 8 bytes in length starting on the following addresses: — shares text with pacman/pacman.cpp:925 rtl/pacman_rom_descrambler.vhd:82 Any memory access will trigger the trap behavior: instruction fetch, data read, data write. The latch clear addresses — shares text with pacman/pacman.cpp:939 rtl/pacman_rom_descrambler.vhd:83 should never be accessed during normal Ms. Pac-Man operation, so when the circuitry detects an access it clears the — shares text with pacman/pacman.cpp:940 rtl/pacman_rom_descrambler.vhd:84 latch and prevents any further dumping of the aux board ROMs. — shares text with pacman/pacman.cpp:941 rtl/pacman_rom_descrambler.vhd:86 The Pac-Man self-test code does a checksum of the ROM 0x0000-0x2fff. This works because the checksum routine walks the — shares text with pacman/pacman.cpp:943 rtl/pacman_rom_descrambler.vhd:87 ROM starting from the low address and hits the latch clear trap at 0x0038 prior to encountering any of the patch — shares text with pacman/pacman.cpp:944 rtl/pacman_rom_descrambler.vhd:88 regions. The decode stays disabled for the rest of the checksum routine, and thus the checksum is calculated for the — shares text with pacman/pacman.cpp:945 rtl/pacman_rom_descrambler.vhd:89 Pac-Man ROMs with no patches applied. — shares text with pacman/pacman.cpp:946 rtl/pacman_rom_descrambler.vhd:91 During normal operation every VBLANK (60.6Hz) interrupt will fetch its interrupt vector from the 0x3ff8 trap region, so — shares text with pacman/pacman.cpp:948 rtl/pacman_rom_descrambler.vhd:92 the latch is continually being enabled. — shares text with pacman/pacman.cpp:949 rtl/pacman_rom_descrambler.vhd:94 In a further attempt to thwart copying, the aux board ROMs have a simple encryption scheme: their address and data — shares text with pacman/pacman.cpp:959 rtl/pacman_rom_descrambler.vhd:95 lines are bit flipped (i.e., wired in a nonstandard fashion). The specific bit flips were selected to minimize the — shares text with pacman/pacman.cpp:960 rtl/pacman_rom_descrambler.vhd:96 vias required to lay out the aux PCB. — shares text with pacman/pacman.cpp:961 rtl/pacman_rom_descrambler.vhd:104 /* copy forty 8-byte patches into Pac-Man code / — shares text with pacman/pacman.cpp:8640 rtl/pacman_rom_descrambler.vhd:107 ROM[0x0410+i] = ROM[0x8008+i]; — shares text with pacman/pacman.cpp:8643 rtl/pacman_rom_descrambler.vhd:108 ROM[0x08E0+i] = ROM[0x81D8+i]; — shares text with pacman/pacman.cpp:8644 rtl/pacman_rom_descrambler.vhd:109 ROM[0x0A30+i] = ROM[0x8118+i]; — shares text with pacman/pacman.cpp:8645 rtl/pacman_rom_descrambler.vhd:110 ROM[0x0BD0+i] = ROM[0x80D8+i]; — shares text with pacman/pacman.cpp:8646 rtl/pacman_rom_descrambler.vhd:111 ROM[0x0C20+i] = ROM[0x8120+i]; — shares text with pacman/pacman.cpp:8647 rtl/pacman_rom_descrambler.vhd:112 ROM[0x0E58+i] = ROM[0x8168+i]; — shares text with pacman/pacman.cpp:8648 rtl/pacman_rom_descrambler.vhd:113 ROM[0x0EA8+i] = ROM[0x8198+i]; — shares text with pacman/pacman.cpp:8649 rtl/pacman_rom_descrambler.vhd:115 ROM[0x1000+i] = ROM[0x8020+i]; — shares text with pacman/pacman.cpp:8651 rtl/pacman_rom_descrambler.vhd:116 ROM[0x1008+i] = ROM[0x8010+i]; — shares text with pacman/pacman.cpp:8652 rtl/pacman_rom_descrambler.vhd:117 ROM[0x1288+i] = ROM[0x8098+i]; — shares text with pacman/pacman.cpp:8653 rtl/pacman_rom_descrambler.vhd:118 ROM[0x1348+i] = ROM[0x8048+i]; — shares text with pacman/pacman.cpp:8654 rtl/pacman_rom_descrambler.vhd:119 ROM[0x1688+i] = ROM[0x8088+i]; — shares text with pacman/pacman.cpp:8655 rtl/pacman_rom_descrambler.vhd:120 ROM[0x16B0+i] = ROM[0x8188+i]; — shares text with pacman/pacman.cpp:8656 rtl/pacman_rom_descrambler.vhd:121 ROM[0x16D8+i] = ROM[0x80C8+i]; — shares text with pacman/pacman.cpp:8657 rtl/pacman_rom_descrambler.vhd:122 ROM[0x16F8+i] = ROM[0x81C8+i]; — shares text with pacman/pacman.cpp:8658 rtl/pacman_rom_descrambler.vhd:123 ROM[0x19A8+i] = ROM[0x80A8+i]; — shares text with pacman/pacman.cpp:8659 rtl/pacman_rom_descrambler.vhd:124 ROM[0x19B8+i] = ROM[0x81A8+i]; — shares text with pacman/pacman.cpp:8660 rtl/pacman_rom_descrambler.vhd:126 ROM[0x2060+i] = ROM[0x8148+i]; — shares text with pacman/pacman.cpp:8662 rtl/pacman_rom_descrambler.vhd:127 ROM[0x2108+i] = ROM[0x8018+i]; — shares text with pacman/pacman.cpp:8663 rtl/pacman_rom_descrambler.vhd:128 ROM[0x21A0+i] = ROM[0x81A0+i]; — shares text with pacman/pacman.cpp:8664 rtl/pacman_rom_descrambler.vhd:129 ROM[0x2298+i] = ROM[0x80A0+i]; — shares text with pacman/pacman.cpp:8665 rtl/pacman_rom_descrambler.vhd:130 ROM[0x23E0+i] = ROM[0x80E8+i]; — shares text with pacman/pacman.cpp:8666 rtl/pacman_rom_descrambler.vhd:131 ROM[0x2418+i] = ROM[0x8000+i]; — shares text with pacman/pacman.cpp:8667 rtl/pacman_rom_descrambler.vhd:132 ROM[0x2448+i] = ROM[0x8058+i]; — shares text with pacman/pacman.cpp:8668 rtl/pacman_rom_descrambler.vhd:133 ROM[0x2470+i] = ROM[0x8140+i]; — shares text with pacman/pacman.cpp:8669 rtl/pacman_rom_descrambler.vhd:134 ROM[0x2488+i] = ROM[0x8080+i]; — shares text with pacman/pacman.cpp:8670 rtl/pacman_rom_descrambler.vhd:135 ROM[0x24B0+i] = ROM[0x8180+i]; — shares text with pacman/pacman.cpp:8671 rtl/pacman_rom_descrambler.vhd:136 ROM[0x24D8+i] = ROM[0x80C0+i]; — shares text with pacman/pacman.cpp:8672 rtl/pacman_rom_descrambler.vhd:137 ROM[0x24F8+i] = ROM[0x81C0+i]; — shares text with pacman/pacman.cpp:8673 rtl/pacman_rom_descrambler.vhd:138 ROM[0x2748+i] = ROM[0x8050+i]; — shares text with pacman/pacman.cpp:8674 rtl/pacman_rom_descrambler.vhd:139 ROM[0x2780+i] = ROM[0x8090+i]; — shares text with pacman/pacman.cpp:8675 rtl/pacman_rom_descrambler.vhd:140 ROM[0x27B8+i] = ROM[0x8190+i]; — shares text with pacman/pacman.cpp:8676 rtl/pacman_rom_descrambler.vhd:141 ROM[0x2800+i] = ROM[0x8028+i]; — shares text with pacman/pacman.cpp:8677 rtl/pacman_rom_descrambler.vhd:142 ROM[0x2B20+i] = ROM[0x8100+i]; — shares text with pacman/pacman.cpp:8678 rtl/pacman_rom_descrambler.vhd:143 ROM[0x2B30+i] = ROM[0x8110+i]; — shares text with pacman/pacman.cpp:8679 rtl/pacman_rom_descrambler.vhd:144 ROM[0x2BF0+i] = ROM[0x81D0+i]; — shares text with pacman/pacman.cpp:8680 rtl/pacman_rom_descrambler.vhd:145 ROM[0x2CC0+i] = ROM[0x80D0+i]; — shares text with pacman/pacman.cpp:8681 rtl/pacman_rom_descrambler.vhd:146 ROM[0x2CD8+i] = ROM[0x80E0+i]; — shares text with pacman/pacman.cpp:8682 rtl/pacman_rom_descrambler.vhd:147 ROM[0x2CF0+i] = ROM[0x81E0+i]; — shares text with pacman/pacman.cpp:8683 rtl/pacman_rom_descrambler.vhd:148 ROM[0x2D60+i] = ROM[0x8160+i]; — shares text with pacman/pacman.cpp:8684 rtl/pacman_rom_descrambler.vhd:159 / Pac-Man code is in low bank / — shares text with pacman/pacman.cpp:8692 rtl/pacman_rom_descrambler.vhd:162 / decrypted Ms. Pac-Man code is in high bank / — shares text with pacman/pacman.cpp:8695 rtl/pacman_rom_descrambler.vhd:168 DROM[0x0000+i] = ROM[0x0000+i]; / pacman.6e / — shares text with pacman/pacman.cpp:8701 rtl/pacman_rom_descrambler.vhd:169 DROM[0x1000+i] = ROM[0x1000+i]; / pacman.6f / — shares text with pacman/pacman.cpp:8702 rtl/pacman_rom_descrambler.vhd:170 DROM[0x2000+i] = ROM[0x2000+i]; / pacman.6h / — shares text with pacman/pacman.cpp:8703 rtl/pacman_rom_descrambler.vhd:171 DROM[0x3000+i] = BITSWAP8(ROM[0xb000+BITSWAP16(i,15,14,13,12,11,3,7,9,10,8,6,5,4,2,1,0)],0,4,5,7,6,3,2,1); / decrypt u7 / — shares text with pacman/pacman.cpp:8704 rtl/pacman_rom_descrambler.vhd:175 DROM[0x8000+i] = BITSWAP8(ROM[0x8000+BITSWAP16(i,15,14,13,12,11,8,7,5,9,10,6,3,4,2,1,0)],0,4,5,7,6,3,2,1); / decrypt u5 / — shares text with pacman/pacman.cpp:8708 rtl/pacman_rom_descrambler.vhd:176 DROM[0x8800+i] = BITSWAP8(ROM[0x9800+BITSWAP16(i,15,14,13,12,11,3,7,9,10,8,6,5,4,2,1,0)],0,4,5,7,6,3,2,1); / decrypt half of u6 / — shares text with pacman/pacman.cpp:8704 rtl/pacman_rom_descrambler.vhd:177 DROM[0x9000+i] = BITSWAP8(ROM[0x9000+BITSWAP16(i,15,14,13,12,11,3,7,9,10,8,6,5,4,2,1,0)],0,4,5,7,6,3,2,1); / decrypt half of u6 / — shares text with pacman/pacman.cpp:8704 rtl/pacman_rom_descrambler.vhd:178 // 15,14,13,12,11,10,9,8,7,6,5,4,3,2,1,0 — shares text with pacman/pacman.cpp:8614 rtl/pacman_rom_descrambler.vhd:179 DROM[0x9800+i] = ROM[0x1800+i]; / mirror of pacman.6f high / — shares text with pacman/pacman.cpp:8711 rtl/pacman_rom_descrambler.vhd:183 DROM[0xa000+i] = ROM[0x2000+i]; / mirror of pacman.6h / — shares text with pacman/pacman.cpp:8715 rtl/pacman_rom_descrambler.vhd:184 DROM[0xb000+i] = ROM[0x3000+i]; / mirror of pacman.6j / — shares text with pacman/pacman.cpp:8716 rtl/pacman_rom_descrambler.vhd:189 / mirror Pac-Man ROMs into upper addresses of normal bank / — shares text with pacman/pacman.cpp:8722 rtl/pacman_rom_descrambler.vhd:192 ROM[0x8000+i] = ROM[0x0000+i]; — shares text with pacman/pacman.cpp:8725 rtl/pacman_rom_descrambler.vhd:193 ROM[0x9000+i] = ROM[0x1000+i]; — shares text with pacman/pacman.cpp:8726 rtl/pacman_rom_descrambler.vhd:194 ROM[0xa000+i] = ROM[0x2000+i]; — shares text with pacman/pacman.cpp:8727 rtl/pacman_rom_descrambler.vhd:195 ROM[0xb000+i] = ROM[0x3000+i]; — shares text with pacman/pacman.cpp:8728 rtl/pacman_rom_descrambler.vhd:199 machine().root_device().membank("bank1")->configure_entries(0, 2, &ROM[0x00000], 0x10000); — shares text with pacman/pacman.cpp:698 rtl/pacman_rom_descrambler.vhd:205 ROM_LOAD( "pacman.6e", 0x0000, 0x1000, CRC(c1e6ab10) SHA1(e87e059c5be45753f7e9f33dff851f16d6751181) ) — shares text with pacman/pacman.cpp:4318 rtl/pacman_rom_descrambler.vhd:206 ROM_LOAD( "pacman.6f", 0x1000, 0x1000, CRC(1a6fb2d4) SHA1(674d3a7f00d8be5e38b1fdc208ebef5a92d38329) ) — shares text with pacman/pacman.cpp:4319 rtl/pacman_rom_descrambler.vhd:207 ROM_LOAD( "pacman.6h", 0x2000, 0x1000, CRC(bcdd1beb) SHA1(8e47e8c2c4d6117d174cdac150392042d3e0a881) ) — shares text with pacman/pacman.cpp:4320 rtl/pacman_rom_descrambler.vhd:208 ROM_LOAD( "prg7", 0x3000, 0x0800, CRC(b6289b26) SHA1(d249fa9cdde774d5fee7258147cd25fa3f4dc2b3) ) — shares text with pacman/pacman.cpp:4155 rtl/pacman_rom_descrambler.vhd:209 ROM_LOAD( "prg8", 0x3800, 0x0800, CRC(17a88c13) SHA1(eb462de79f49b7aa8adb0cc6d31535b10550c0ce) ) — shares text with pacman/pacman.cpp:4156 rtl/pacman_rom_descrambler.vhd:212 ROM_REGION( 0x20000, "maincpu", 0 ) / 64k for code+64k for decrypted code */ — shares text with pacman/pacman.cpp:6273 rtl/pacman_rom_descrambler.vhd:213 ROM_LOAD( "pacman.6e", 0x0000, 0x1000, CRC(c1e6ab10) SHA1(e87e059c5be45753f7e9f33dff851f16d6751181) ) — shares text with pacman/pacman.cpp:4318 rtl/pacman_rom_descrambler.vhd:214 ROM_LOAD( "pacman.6f", 0x1000, 0x1000, CRC(1a6fb2d4) SHA1(674d3a7f00d8be5e38b1fdc208ebef5a92d38329) ) — shares text with pacman/pacman.cpp:4319 rtl/pacman_rom_descrambler.vhd:215 ROM_LOAD( "pacman.6h", 0x2000, 0x1000, CRC(bcdd1beb) SHA1(8e47e8c2c4d6117d174cdac150392042d3e0a881) ) — shares text with pacman/pacman.cpp:4320 rtl/pacman_rom_descrambler.vhd:216 ROM_LOAD( "pacman.6j", 0x3000, 0x1000, CRC(817d94e3) SHA1(d4a70d56bb01d27d094d73db8667ffb00ca69cb9) ) — shares text with pacman/pacman.cpp:4321 rtl/pacman_rom_descrambler.vhd:218 ROM_LOAD( "u5", 0x8000, 0x0800, CRC(f45fbbcd) SHA1(b26cc1c8ee18e9b1daa97956d2159b954703a0ec) ) — shares text with pacman/pacman.cpp:6278 rtl/pacman_rom_descrambler.vhd:219 ROM_LOAD( "u6", 0x9000, 0x1000, CRC(a90e7000) SHA1(e4df96f1db753533f7d770aa62ae1973349ea4cf) ) — shares text with pacman/pacman.cpp:6279 rtl/pacman_rom_descrambler.vhd:220 ROM_LOAD( "u7", 0xb000, 0x1000, CRC(c82cd714) SHA1(1d8ac7ad03db2dc4c8c18ade466e12032673f874) ) — shares text with pacman/pacman.cpp:6280 rtl/pacman_rom_descrambler.vhd:223 Normally the Pac-Man ROMs reside at address 0x0000-0x3fff and are mirrored at 0x8000-0xbfff (Z-80 A15 is not used in Pac-Man). — shares text with pacman/pacman.cpp:912 rtl/pacman_rom_descrambler.vhd:224 The aux board logic modifies the address map and enables the aux board ROMs for addresses 0x3000-0x3fff and 0x8000-0x97ff. — shares text with pacman/pacman.cpp:913 rtl/pacman_rom_descrambler.vhd:310 The trap regions are 8 bytes in length starting on the following addresses: — shares text with pacman/pacman.cpp:925 rtl/pacman_rom_descrambler.vhd:397 Mr TNT program ROMs have data lines D3 and D5 swapped — shares text with pacman/pacman.cpp:8624 rtl/pacman_rom_descrambler.vhd:398 Mr TNT video ROMs have data lines D4 and D6 and address lines A0 and A2 swapped — shares text with pacman/pacman.cpp:8631 rtl/pacman_rom_descrambler.vhd:404 forty 8-byte patches into Pac-Man code — shares text with pacman/pacman.cpp:8640 rtl/pacman_rom_descrambler.vhd:409 ROM[0x0410+i] = ROM[0x8008+i] — shares text with pacman/pacman.cpp:8643 rtl/pacman_rom_descrambler.vhd:410 ROM[0x08E0+i] = ROM[0x81D8+i] — shares text with pacman/pacman.cpp:8644 rtl/pacman_rom_descrambler.vhd:411 ROM[0x0A30+i] = ROM[0x8118+i] — shares text with pacman/pacman.cpp:8645 rtl/pacman_rom_descrambler.vhd:412 ROM[0x0BD0+i] = ROM[0x80D8+i] — shares text with pacman/pacman.cpp:8646 rtl/pacman_rom_descrambler.vhd:413 ROM[0x0C20+i] = ROM[0x8120+i] — shares text with pacman/pacman.cpp:8647 rtl/pacman_rom_descrambler.vhd:414 ROM[0x0E58+i] = ROM[0x8168+i] — shares text with pacman/pacman.cpp:8648 rtl/pacman_rom_descrambler.vhd:415 ROM[0x0EA8+i] = ROM[0x8198+i] — shares text with pacman/pacman.cpp:8649 rtl/pacman_rom_descrambler.vhd:417 ROM[0x1000+i] = ROM[0x8020+i] — shares text with pacman/pacman.cpp:8651 rtl/pacman_rom_descrambler.vhd:418 ROM[0x1008+i] = ROM[0x8010+i] — shares text with pacman/pacman.cpp:8652 rtl/pacman_rom_descrambler.vhd:419 ROM[0x1288+i] = ROM[0x8098+i] — shares text with pacman/pacman.cpp:8653 rtl/pacman_rom_descrambler.vhd:420 ROM[0x1348+i] = ROM[0x8048+i] — shares text with pacman/pacman.cpp:8654 rtl/pacman_rom_descrambler.vhd:421 ROM[0x1688+i] = ROM[0x8088+i] — shares text with pacman/pacman.cpp:8655 rtl/pacman_rom_descrambler.vhd:422 ROM[0x16B0+i] = ROM[0x8188+i] — shares text with pacman/pacman.cpp:8656 rtl/pacman_rom_descrambler.vhd:423 ROM[0x16D8+i] = ROM[0x80C8+i] — shares text with pacman/pacman.cpp:8657 rtl/pacman_rom_descrambler.vhd:424 ROM[0x16F8+i] = ROM[0x81C8+i] — shares text with pacman/pacman.cpp:8658 rtl/pacman_rom_descrambler.vhd:425 ROM[0x19A8+i] = ROM[0x80A8+i] — shares text with pacman/pacman.cpp:8659 rtl/pacman_rom_descrambler.vhd:426 ROM[0x19B8+i] = ROM[0x81A8+i] — shares text with pacman/pacman.cpp:8660 rtl/pacman_rom_descrambler.vhd:428 ROM[0x2060+i] = ROM[0x8148+i] — shares text with pacman/pacman.cpp:8662 rtl/pacman_rom_descrambler.vhd:429 ROM[0x2108+i] = ROM[0x8018+i] — shares text with pacman/pacman.cpp:8663 rtl/pacman_rom_descrambler.vhd:430 ROM[0x21A0+i] = ROM[0x81A0+i] — shares text with pacman/pacman.cpp:8664 rtl/pacman_rom_descrambler.vhd:431 ROM[0x2298+i] = ROM[0x80A0+i] — shares text with pacman/pacman.cpp:8665 rtl/pacman_rom_descrambler.vhd:432 ROM[0x23E0+i] = ROM[0x80E8+i] — shares text with pacman/pacman.cpp:8666 rtl/pacman_rom_descrambler.vhd:433 ROM[0x2418+i] = ROM[0x8000+i] — shares text with pacman/pacman.cpp:8667 rtl/pacman_rom_descrambler.vhd:434 ROM[0x2448+i] = ROM[0x8058+i] — shares text with pacman/pacman.cpp:8668 rtl/pacman_rom_descrambler.vhd:435 ROM[0x2470+i] = ROM[0x8140+i] — shares text with pacman/pacman.cpp:8669 rtl/pacman_rom_descrambler.vhd:436 ROM[0x2488+i] = ROM[0x8080+i] — shares text with pacman/pacman.cpp:8670 rtl/pacman_rom_descrambler.vhd:437 ROM[0x24B0+i] = ROM[0x8180+i] — shares text with pacman/pacman.cpp:8671 rtl/pacman_rom_descrambler.vhd:438 ROM[0x24D8+i] = ROM[0x80C0+i] — shares text with pacman/pacman.cpp:8672 rtl/pacman_rom_descrambler.vhd:439 ROM[0x24F8+i] = ROM[0x81C0+i] — shares text with pacman/pacman.cpp:8673 rtl/pacman_rom_descrambler.vhd:440 ROM[0x2748+i] = ROM[0x8050+i] — shares text with pacman/pacman.cpp:8674 rtl/pacman_rom_descrambler.vhd:441 ROM[0x2780+i] = ROM[0x8090+i] — shares text with pacman/pacman.cpp:8675 rtl/pacman_rom_descrambler.vhd:442 ROM[0x27B8+i] = ROM[0x8190+i] — shares text with pacman/pacman.cpp:8676 rtl/pacman_rom_descrambler.vhd:443 ROM[0x2800+i] = ROM[0x8028+i] — shares text with pacman/pacman.cpp:8677 rtl/pacman_rom_descrambler.vhd:444 ROM[0x2B20+i] = ROM[0x8100+i] — shares text with pacman/pacman.cpp:8678 rtl/pacman_rom_descrambler.vhd:445 ROM[0x2B30+i] = ROM[0x8110+i] — shares text with pacman/pacman.cpp:8679 rtl/pacman_rom_descrambler.vhd:446 ROM[0x2BF0+i] = ROM[0x81D0+i] — shares text with pacman/pacman.cpp:8680 rtl/pacman_rom_descrambler.vhd:447 ROM[0x2CC0+i] = ROM[0x80D0+i] — shares text with pacman/pacman.cpp:8681 rtl/pacman_rom_descrambler.vhd:448 ROM[0x2CD8+i] = ROM[0x80E0+i] — shares text with pacman/pacman.cpp:8682 rtl/pacman_rom_descrambler.vhd:449 ROM[0x2CF0+i] = ROM[0x81E0+i] — shares text with pacman/pacman.cpp:8683 rtl/pacman_rom_descrambler.vhd:450 ROM[0x2D60+i] = ROM[0x8160+i] — shares text with pacman/pacman.cpp:8684
Pengo# Pengo MiSTer-devel/Arcade-Pengo_MiSTer @ 46d16b21 MAME compared: pacman/pengo.cpp + 2 related file(s) Read: 13 HDL files, 5,779 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	17%
Statements: 2 toward MAME, 1 not counted Cites hardware references or measurements that MAME's driver also gives — 1 rtl/pengo.vhd:337 8 bit addressable latch 7K (made into register) — also in MAME: 7K pacman/pacman.cpp:3710 Cites MAME source — 1 rtl/pengo.vhd:381 Sega ROM descrambler adapted from MAME segacrpt.c source code Shares text with the MAME driver without saying so — 1 Arcade-Pengo.sv:366 \| 1 \| 2 \| 3 \| 4 \| 5 \| 6 \| 7 \| 8 \| \|ON \| \| \| \| \| \| \| \| Bonus - 30,000* \|OFF\| \| \| \| \| \| \| \| Bonus - 50,000 \| \|ON \| \| \| \| \| — shares text with pacman/pacman.cpp:9012
PenguinKunWars# Penguin-Kun Wars MiSTer-devel/Arcade-PenguinKunWars_MiSTer @ 9243c087 MAME compared: upl/nova2001.cpp + 2 related file(s) Read: 12 HDL files, 2,292 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	45%
Statements: 2 toward MAME Cites MAME source — 2 Arcade-PenguinKunWars.sv:295 JPAC/IPAC/MAME Style Codes rtl/YM2149_linmix_sep_mod.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA
Performan# Performan MiSTer-devel/Arcade-Performan_MiSTer @ 74652aee MAME compared: toaplan/slapfght.cpp + 3 related file(s) Read: 20 HDL files, 4,521 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	21%
Statements: 3 toward hardware, 1 toward MAME Cites hardware documentation that MAME's driver does not — 3 rtl/ttl_chips.v:6 74LS74 Chip pinout: rtl/ttl_chips.v:57 74LS107 Chip pinout: rtl/ttl_chips.v:102 74LS139 Chip pinout: Shares text with the MAME driver without saying so — 1 Arcade-Performan.sv:110 0 1 2 3 4 5 6 — shares text with toaplan/slapfght.cpp:820
Phoenix# Phoenix, Pleiads MiSTer-devel/Arcade-Phoenix_MiSTer @ e4bc0d5c MAME compared: phoenix/phoenix.cpp + 6 related file(s) Read: 14 HDL files, 5,165 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	0%
No statements found
PinballAction# Pinball Action MiSTer-devel/Arcade-PinballAction @ 8a9fb51f MAME compared: tecmo/pbaction.cpp Read: 17 HDL files, 3,448 lines (Quartus project)	MiSTer official	Both	low	26%
Statements: 1 toward hardware, 7 toward MAME Says it was checked against the original PCB — 1 README.md:88 Video timing verification against original hardware Cites MAME source — 6 PinballAction.sv:55 MRA file will map MAME ROM regions to these indices rtl/pbaction_sprites.v:68 MAME draws from offs=124 down to 0. rtl/pbaction_sprites.v:329 MAME draws lower offsets later, therefore lower offsets have priority. README.md:89 Remaining edge-case rendering differences from MAME README.md:106 MAME README.md:108 MAME serves as an invaluable reference for hardware behavior, device mappings, graphics layouts, and verification. Says it matches, follows or was checked against MAME — 1 README.md:72 A small band approximately three scanlines tall does not perfectly match MAME:
Pleiads# MiSTer-devel/Arcade-Pleiads_MiSTer @ 4144e0e8 MAME driver: not found Read: 13 HDL files, 5,009 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	0%
No statements found
PolePosition# Pole Position, Pole Position II MiSTer-devel/Arcade-PolePosition_MiSTer @ 278079e4 (matched by date) MAME compared: namco/polepos.cpp + 14 related file(s) Read: 37 HDL files, 11,611 lines (Quartus project)	MiSTer official	Mostly MAME	high	95%
Statements: 9 toward hardware, 505 toward MAME, 2 not counted Cites hardware documentation that MAME's driver does not — 2 rtl/cpu/z8002/z8002.sv:10 This core is COMPLETE for everything Pole Position exercises: both sub ROMs co-sim-run to completion (pp_sub1 ~15M / pp_sub2 ~12M retires @30M cyc, ZERO dbg_illegal), and the NVI/ISR/IRET selftest passes. rtl/custom/pp_road_gen.sv:233 The ONE input never observed on hardware is what the sub-CPUs write into road16_memory -- the CHA0-CHA9 lines on operators-manual Sheet 12B. Cites hardware references or measurements that MAME's driver also gives — 2 rtl/PolePosition_CPU.sv:7 Ground truth: MAME polepos.cpp z80_map / z80_io / machine_config (LS259 @8E). — also in MAME: 8E namco/polepos.cpp:182 rtl/PolePosition_CPU.sv:193 IRQ generation (polepos.cpp scanline() :392-403) maincpu IRQ asserted at 64V and 192V when q0=1; q0=0 acks/clears. — also in MAME: 64V namco/polepos.cpp:396 Says it was checked on “real hardware” — 1 rtl/video/gen_video.sv:159 User confirmed on real HW the excess 32px is entirely on the LEFT, so trim only the deassert (left-edge/start-of-active) side by the full 32px; the assert (right edge) point is untouched. Ships hardware documentation files — 4 Useful Information/schematics/MB8841.pdf Useful Information/schematics/Pole Position - Operators Manual.pdf Useful Information/schematics/The Z8000 Handbook.pdf Useful Information/schematics/Z8000 Technical Manual.pdf Notes where it differs from MAME — 2 rtl/PolePosition_CPU.sv:240 Was plain `spram` (powers up 0x00, diverging from MAME); swapped to dpram_dc (already used above for prog_rom, same 1-cycle read latency — outdata_reg_a defaults UNREGISTERED, matching spram's registered-q timing) so its init_file generic c rtl/cpu/mb88_sv/mb88_core.sv:31 NOT MODELLED — NONE are gaps (MAME doesn't model them for the default part, or no target device uses them): * STANDBY (stby_n pin): MAME has no standby/STOP state for mb88. Cites MAME source — 427 Arcade-PolePosition.sv:104 Slot 4 is now Service Mode = MAME IN0 bit 7 (PORT_SERVICE, the cabinet self-test toggle) on physical Y. Keep this list and the MRA <buttons> element character-for-character identical. Arcade-PolePosition.sv:116 MAME reads both ports with NO inversion -- polepos.cpp:905-906 (53xx input<2>/<3> = DSWA nibbles) and :888-889 (51xx input<0>/<1> = DSWB nibbles) -- so an MRA byte now equals the MAME DSW byte exactly, and every <dip> ids list in the MRA ca Arcade-PolePosition.sv:123 NOTE the set mapping: MAME's WORLD set uses the poleposa port table -- GAME(1982, polepos, 0, polepos, poleposa, ...) at polepos.cpp:2556. Arcade-PolePosition.sv:127 Power-on values are the MAME defaults (DSWA 0xFF, DSWB 0x74) so a stale MRA with no <switches> still gives 1C/1C, 90 secs, 3 laps rather than the all-zero Free Play / 120 secs / 4 laps / Rank G+H that the missing block used to produce. Arcade-PolePosition.sv:261 MAME polepos.cpp:503 declares it PORT_BIT(0x02,...,IPT_BUTTON3) POLEPOS_TOGGLE, and :252 is `#define POLEPOS_TOGGLE PORT_TOGGLE` -- each press flips Lo<->Hi and it HOLDS. Arcade-PolePosition.sv:275 It is now Service Mode (MRA / CONF_STR slot 4, physical Y) = MAME IN0 bit 7, PORT_SERVICE -- the cabinet's self-test toggle. Arcade-PolePosition.sv:355 `audio` is the Namco WSG mixer's signed two's-complement sum (namco_wsg8.sv, MAME namco.cpp mixing math) -- was 0 (arbitrary) while audio was tied off. Arcade-PolePosition.sv:381 Watchdog defeat switch (rtl/pp_watchdog.sv wdog_en, MAME polepos.cpp:925 set_vblank_count(...,16)). Arcade-PolePosition.sv:388 MAME polepos "chars" = ioctl INDEX 1, offset 0x0000, 0x1000 bytes (pp3_28.1f, crc 2e77187e). Arcade-PolePosition.sv:431 Index-1 stream, padded to MAME's declared region sizes so one gate set serves PP1 and PP2. Arcade-PolePosition.sv:434 road 0x18000 \| scalelut 0x1D000 end 0x1E000 bigsprites keeps MAME's internal 0x2000 gap at sprite_rom[0xA000-0xBFFF]. Arcade-PolePosition.sv:449 Namco WSG waveform PROM — ioctl INDEX 2, region-relative 0x1040-0x113F (256 bytes, right after the 0x1040-byte "proms" block; MAME polepos "namco" region, pp1-5.3b crc 8568decc; 8 waveforms x 32 4-bit samples). Arcade-PolePosition.sv:473 Engine sound waveform ROM — ioctl index 5, region-relative 0x0000-0x3FFF (pp1_15.6a + pp1_16.5a, MAME's "engine" region). Arcade-PolePosition.sv:487 Steering (MAME "STEER" IPT_DIAL) — no real spinner/analog input is wired at this top level yet (#unverified / KNOWN ITERATION POINT). Arcade-PolePosition.sv:527 Full scale is 0x90, NOT 0xFF, per MAME PORT_MINMAX(0,0x90) on both ACCEL and BRAKE. Arcade-PolePosition.sv:531 PEDALS-2026-09-23: OSD "Pedals" = Analog reads one combined axis (up = accelerate, down = brake), \|Y\| 0..128 -> 0..0x90 (MAME PORT_MINMAX(0,0x90)) with a dead zone. Arcade-PolePosition.sv:609 NOTE: `service` is MAME IN0 bit 6 = IPT_SERVICE1, the service-CREDIT button -- a DIFFERENT control from the self-test switch above. rtl/PolePosition_CPU.sv:34 ---- LS259 control-latch outputs (MAME polepos.cpp:931-943) ---------------- rtl/PolePosition_CPU.sv:35 q4 0 = Z8002 #1 held in reset (MAME .invert()) rtl/PolePosition_CPU.sv:36 q5 0 = Z8002 #2 held in reset (MAME .invert()) rtl/PolePosition_CPU.sv:37 q1 Namco 51/52/53/54xx reset (polarity #unverified vs namco51.cpp) rtl/PolePosition_CPU.sv:42 q6 auto_start_mask = !q6 in MAME rtl/PolePosition_CPU.sv:148 Address decode (z80_map, MAME polepos.cpp:435-453) — mirrors folded in rtl/PolePosition_CPU.sv:171 Z80 I/O space: ADC0804 at port 0x00 (z80_io, polepos.cpp:456-460) rtl/PolePosition_CPU.sv:193 IRQ generation (polepos.cpp scanline() :392-403) maincpu IRQ asserted at 64V and 192V when q0=1; q0=0 acks/clears. rtl/PolePosition_CPU.sv:206 q0=0 forces clear (MAME .invert()) rtl/PolePosition_CPU.sv:212 READY read (0xA000, polepos.cpp ready_r :291-302) bit1 ^= 1 when vpos>=128 ; bit3 ^= 1 when ADC INTR asserted (done) rtl/PolePosition_CPU.sv:236 NVRAM (0x3000-0x37FF, battery-backed in MAME) — 2 KB MAME ground truth: polepos.cpp:927 NVRAM(config, "nvram", nvram_device::DEFAULT_ALL_1) -> a fresh/unbacked NVRAM powers up filled with 0xFF. rtl/PolePosition_subcpu.sv:7 Z80 BYTE LANE (verified in polepos_v.cpp): sprite_r/w, road_r/w, alpha_r/w, view_r/w ALL read/write ONLY THE LOW BYTE of the 16-bit word: sprite_r: return mem[offset] & 0xff; sprite_w: mem[offset] = (mem[offset] & 0xff00) \| data; identical rtl/PolePosition_subcpu.sv:52 #deviation: Z8002-side buffer/register accesses are treated as WORD-ONLY (wordacc/addr[0] byte lane not modeled on the Z8002 side — only the Z80 side is genuinely byte-oriented per polepos_v.cpp). rtl/PolePosition_subcpu.sv:58 NVI: nvi_latch_subN is armed at each sub_nvi_trig pulse (from that CPU's nvi_enable at that instant) and cleared when that CPU writes 0 to 0x6000, per polepos.cpp:319. rtl/PolePosition_subcpu.sv:64 0x6000/0xC000/0xC100 mirror-mask decodes derived from the given MAME AM_MIRROR masks (0x1FFE, 0x38FE): significant-bit mask = ~mirror_mask. rtl/PolePosition_subcpu.sv:261 MAME's declared 0x8000 sub regions; must match SUB_WINDOW in mra_emit.py. rtl/PolePosition_subcpu.sv:331 The Z80 writes the LOW byte only (polepos_v.cpp byte lane) => it drives the lo-array write-enable but never the hi array; the z8002s write the full word. rtl/PolePosition_subcpu.sv:410 // road16_memory layout (MAME draw_road): // 0x000-0x1FF : yoffs -> roadpal in bits [3:0] rtl/PolePosition_subcpu.sv:520 NVI line: armed at each sub_nvi_trig pulse (gated by that CPU's nvi_enable at that instant), and de-asserted when that CPU writes 0 to its own nvi_enable -- polepos.cpp:319 set_input_line(NVI_LINE, CLEAR). rtl/cpu/mb88_sv/mb88.sv:57 Generate it here: one ena_timer pulse per 32 `ena` machine-cycle enables — MAME mb88 burn_cycles /32 (full timer overflow = ÷8192 of `ena`). rtl/cpu/mb88_sv/mb88_core.sv:6 Oracle: MAME cpu/mb88xx/mb88xx.cpp (opcode-for-opcode). rtl/cpu/mb88_sv/mb88_core.sv:14 COMPLETE vs MAME mb88xx.cpp — opcode AND non-opcode. rtl/cpu/mb88_sv/mb88_core.sv:16 OPCODES: all 256 bytes, verified byte-for-byte vs mb88xx.cpp execute_run() (0x00-2f individual; 0x30-3f sbit/rbit/tbit/rti/jpa/en/dis; 0x40-7f setD/ rstD/tstD/tba/xd/xyd/lxi/call/jpl/ai; 0x80-bf lyi/li/cyi/ci; 0xc0-ff jmp). rtl/cpu/mb88_sv/mb88_core.sv:23 * Timer: internal (pio7, ÷32 prescale) OR external TC pin (pio6) per MAME increment_timer() (2026-07-11 + 2026-07-17 fixes). rtl/cpu/mb88_sv/mb88_core.sv:29 * O-port PLA: 8-bit cf-nibble-select outO = MAME write_pla with pla_bits==8 (the device default; what the Namco 5xxx use). rtl/cpu/mb88_sv/mb88_core.sv:34 * External-clock serial (pio 0x10/0x30): MAME fatalerror's it (unsupported). rtl/cpu/mb88_sv/mb88_core.sv:40 0 = legacy 1-ce entry (51xx/52xx/53xx rely on it; the global MAME-exact change broke the 51xx and the main-CPU POST on 2026-09-19). rtl/cpu/mb88_sv/mb88_core.sv:41 3 = MAME burn_cycles(3); the 54xx needs it or its IRQ handler reads the command latch before the 06xx byte lands (verilator/n54_cosim). rtl/cpu/mb88_sv/mb88_core.sv:59 MAME's write_pla() ends with an unconditional `m_write_o(0, m_o_output, mask)` (mb88xx.cpp:373), so consumers that latch the O port (e.g. namco_51xx's shared mailbox = MAME m_portO) must re-latch on every write, not on a value change. rtl/cpu/mb88_sv/mb88_core.sv:69 interrupt injection (harness drives from the MAME trace during bug hunt) rtl/cpu/mb88_sv/mb88_core.sv:100 ---- SERIAL (2026-07-18; faithful to MAME mb88xx.cpp serial_timer()/pio_enable()) ---- 4-bit RECEIVE shift register clocked at clock()/SERIAL_PRESCALE(=6), armed when pio[5:4]==2'b10 (MAME's (m_pio & 0x30)==0x20 = internal serial clock). rtl/cpu/mb88_sv/mb88_core.sv:104 sf blocks further shifting until tsts clears it; SBcount runaway-disables at THRESH (MAME anti-hang). rtl/cpu/mb88_sv/mb88_core.sv:105 External-clock serial (pio 0x10/0x30) is unsupported by MAME (fatalerror) so we just don't tick. rtl/cpu/mb88_sv/mb88_core.sv:106 SO/transmit is not modeled in MAME's mb88 either. rtl/cpu/mb88_sv/mb88_core.sv:110 MAME SERIAL_DISABLE_THRESH rtl/cpu/mb88_sv/mb88_core.sv:160 SP[] and ram[] intentionally NOT reset (MAME device_reset doesn't clear data RAM/stack; ROM inits RAM; Verilator zero-inits arrays). rtl/cpu/mb88_sv/mb88_core.sv:166 MAME mb88xx.cpp: `if (m_ctr && !state && (m_pio & 0x40)) increment_timer(); m_ctr = state;` i.e. on a FALLING edge of the TC pin, if external-counter mode (pio bit6/0x40) is enabled, tick the SAME timer. rtl/cpu/mb88_sv/mb88_core.sv:169 This drives the 51xx's per-frame timer, which MAME clocks from screen vblank (namco51.cpp vblank() -> MB88XX_TC_LINE). rtl/cpu/mb88_sv/mb88_core.sv:174 Two mutually-exclusive sources feed the ONE counter (a chip uses internal OR external mode, never both): internal clock (ena_timer & pio7 = MAME 0x80), OR external TC falling edge (pio6 = MAME 0x40). rtl/cpu/mb88_sv/mb88_core.sv:178 MCU-TIMER-FIX-2026-07-11: pio7 gate (MAME 0x80); TC-TIMER-FIX-2026-07-17: + external TC path (pio6/MAME 0x40) rtl/cpu/mb88_sv/mb88_core.sv:185 ---- SERIAL receive engine (MAME serial_timer). rtl/cpu/mb88_sv/mb88_core.sv:189 MAME SERIAL_PRESCALE=6 divides the MB88 PIN clock; `ce` is already pin/6 (MCU_CEN_DIV), so the /6 must not be applied twice. rtl/cpu/mb88_sv/mb88_core.sv:197 MAME: SB = (SB>>1) \| (si?8:0) rtl/cpu/mb88_sv/mb88_core.sv:218 MAME clears all pending on take rtl/cpu/mb88_sv/mb88_core.sv:226 outO: cf=1->oh, cf=0->ol (MAME write_pla 8-bit / VHDL). rtl/cpu/z8002/z8002.sv:5 References: MAME z8000ops.hxx / z8000tbl.hxx / z8000cpu.h (behavioral oracle). rtl/cpu/z8002/z8002.sv:65 RRn register-pair select truncates bit0 (RRn = R[n&0xE]:R[n&0xE+1]) -- authority is MAME z8000cpu.h:41 `#define RL(n) m_regs.L[BYTE_XOR_BE((n) >> 1)]`, i.e. bit0 of the nibble is discarded. rtl/cpu/z8002/z8002.sv:93 RQ(n) (quad/64-bit register group for MULTL/DIVL) truncates n's LOW TWO bits (MAME `#define RQ(n) m_regs.Q[(n)>>2]`) -- base = {n[3:2],2'b00}, big-endian word order R[base]:R[base+1]:R[base+2]:R[base+3] MSW-first (verified structurally cons rtl/cpu/z8002/z8002.sv:171 SKIPPED: COMB @rd (0x0C, NIB3=0) -- z8000ops.hxx's handler reads GET_DST(OP0,NIB3) instead of NIB2 like every sibling sub-op, which (since NIB3 is the fixed sub-op-selector, always 0 here) means MAME itself always resolves dst=R0 for this o rtl/cpu/z8002/z8002.sv:198 RLDB/RRDB were traced term-by-term through the actual MAME C body (not the mnemonic's naive "rotate" implication) -- RLDB's second register (b) algebraically comes out UNCHANGED (tmp captured before any write, then re-OR'd back into itself) rtl/cpu/z8002/z8002.sv:250 FCW interrupt-enable masks (MAME z8000cpu.h): F_NVIE=bit11 F_VIE=bit12 F_S_N=bit14 rtl/cpu/z8002/z8002.sv:272 real internal-trap infrastructure (EPU/privileged-instruction trap/system-call), modeled EXACTLY on the already-verified NVI accept sequence (S_NVI_PC/FCW/VEC/RDFCW/RDPC) -- push PC, push OLD fcw, push the trapping opcode word (MAME: "for i rtl/cpu/z8002/z8002.sv:290 This trap sequence inherits the SAME single-SP simplification for consistency with the rest of this core, not because it's what MAME's literal source does. rtl/cpu/z8002/z8002.sv:300 `mode` (MAME's RDPORT/WRPORT first param, 0=standard I/O space / 1=special I/O space) is NOT modeled as a separate signal -- this core's bus has exactly one `iorq` pin (no second "special I/O" strobe), so both spaces collapse onto the same rtl/cpu/z8002/z8002.sv:317 repeat-rewind (MAME's `m_pc -= 4`) combinational scratch for the block-form register bump (S_IOB_WR) rtl/cpu/z8002/z8002.sv:336 BATCH 3: RQ (quad, 4x16-bit) base register index for MULTL/DIVL = {dst[3:2],2'b00} (MAME `#define RQ(n) m_regs.Q[(n)>>2]` truncates the low TWO bits of n, one level wider than RL's bit0 truncation). rtl/cpu/z8002/z8002.sv:527 MAME z8000ops.hxx SRAW/SRAL/SRLW/ SRLL bodies verified: right-arithmetic-shift NEVER sets V despite the "flags CZSV--" doc-comment (CLR_CZSV then no `if(...)SET_V` at all) -- matched exactly below, not assumed from the mnemonic. rtl/cpu/z8002/z8002.sv:535 ---- BATCH 8 2026-07-27: remaining ISA gaps found via full-trace audit against the user's MAME boot-to-attract traces (pp_sub1_fullboot.trace/pp_sub2_fullboot.trace) -- every opcode word ACTUALLY EXECUTED by either sub, cross-referenced aga rtl/cpu/z8002/z8002.sv:540 Families: 0x4D indexed (CP/TEST/LD-imm with a base+index addr), 0x5C direct LOAD direction (0x5C09's STORE sibling), 0x5D indexed (LDL store), 0x71 (LD word, register+register indexed -- the last confirmed-needed sibling of the 0x70-0x77 fa rtl/cpu/z8002/z8002.sv:616 `iorq` (previously hardwired 0) now asserts during these four states; addr/dout/ wordacc follow the SAME byte-lane-vs-plain-word convention this file already uses uniformly for every other byte/word pair (RDPORT_B/WRPORT_B are structurally rtl/cpu/z8002/z8002.sv:657 BATCH 19: 0x3A/0x3B block-I/O read-side byte extraction (S_IOB_RD stages the full word read into `operand`; S_IOB_WR extracts the byte MAME actually transfers). rtl/cpu/z8002/z8002.sv:659 True for the word family (io_wide) OR the ONE confirmed MAME quirk (Z3A_ssss_0011/SOUTIB reads via RDIR_W(src) where every sibling byte block-op uses RDIR_B/RDPORT_B -- transcribed LITERALLY per z8000ops.hxx, not "corrected" to match its si rtl/cpu/z8002/z8002.sv:935 ---- BATCH 18: INB (read-only byte-discard, like every other _RD byte state above) and OUTB (byte write, no RMW needed for I/O -- MAME's WRPORT_B replicates+byte-enable-masks, it never reads the old port value first) are both genuine byte rtl/cpu/z8002/z8002.sv:1076 parity flag (byte AND/OR/XOR P/V, MAME z8000_zsp[]) rtl/cpu/z8002/z8002.sv:1148 level-triggered NVI latch (MAME execute_input_edge_triggered==false for NVI): ================= NVIEDGE-2026-09-05 ============================== Was `if (!nvi_n) nvi_pending <= 1'b1;` -- level-sampled every ce, so the accept's clear was un rtl/cpu/z8002/z8002.sv:1155 MAME sets the request ONLY in execute_set_input(), which the scheduler calls on line TRANSITIONS -- z8000.cpp: ASSERT does `m_irq_req \|= Z8000_NVI`, accept does `m_irq_req &= ~Z8000_NVI`, and nothing re-sets it while the line stays asserted rtl/cpu/z8002/z8002.sv:1180 `cyc_count` ticks every ce cycle unconditionally (the default assignment at the top of this block, same idiom as `retire`) starting from the instant an instruction is dispatched (reset to 1 below); `target_cycles` is that instruction's real rtl/cpu/z8002/z8002.sv:1196 ---- NVI accept (instruction-boundary check, ahead of decode) ---- MAME z8002_device::Interrupt(): (m_irq_req&Z8000_NVI)&&(m_fcw&F_NVIE) rtl/cpu/z8002/z8002.sv:1238 ---- LD @rd,rs store (0x2F, NIB2=dst(ptr)!=0) : ptr=NIB2, data=NIB3 ---- MAME Z2F_ddN0_ssss requires ptr!=0 (R0-as-pointer is undefined here, same "N0" convention as every other @rd-pointer family in this file); the guard was missing -- fou rtl/cpu/z8002/z8002.sv:1250 ==== BATCH 7: SLA/SRA rd,#imm (0xB3, NIB3=9) : MAME ZB3_dddd_1001_imm8 ==== rtl/cpu/z8002/z8002.sv:1254 ==== BATCH 7: SLAL/SRAL rrd,#imm (0xB3, NIB3=D) : MAME ZB3_dddd_1101_imm8 == rtl/cpu/z8002/z8002.sv:1258 ==== BATCH 7: SLLL/SRLL rrd,#imm (0xB3, NIB3=5) : MAME ZB3_dddd_0101_imm8 == rtl/cpu/z8002/z8002.sv:1262 ==== BATCH 7: LDA prd,addr (0x7600-0x760f, NIB2==0) : MAME Z76_0000_dddd_addr rtl/cpu/z8002/z8002.sv:1266 ==== BATCH 7: LDA prd,addr(rs) (0x7610-0x76ff, NIB2!=0) : MAME Z76_ssN0_dddd_addr ==== rtl/cpu/z8002/z8002.sv:1271 ==== BATCH 8: LD rd,rs(rx) (0x71, NIB2!=0) : MAME Z71_ssN0_dddd_0000_xxxx_0000_0000. rtl/cpu/z8002/z8002.sv:1315 ==== BATCH 16: JP cc,addr (0x5E00-0x5E0F, NIB2=0) : MAME Z5E_0000_cccc_addr "jp cc,addr". rtl/cpu/z8002/z8002.sv:1321 ==== BATCH 16 BUG FIX: JP cc,addr(rd) (0x5E10-0x5EFF, NIB2=dst!=0) : MAME Z5E_ddN0_cccc_addr "jp cc,addr(rd)". rtl/cpu/z8002/z8002.sv:1338 ---- LD @rd,#imm16 (0x0D, NIB3=5, dst!=0): EA=R[dst] ---- MAME Z0D_ddN0_0101_imm16 requires dst!=0 (R0-as-pointer undefined, same "N0" convention used elsewhere); guard was missing, found via the cycle-accuracy audit (dst==0 maps to MAME's rtl/cpu/z8002/z8002.sv:1345 ---- direct group (0x4D, NIB2=0): 1=CP#imm 5=LD#imm 8=CLR 4=TEST ---- CP-DIRECT-FIX-2026-08-09: 4'h1 (CP addr,#imm16 -- MAME Z4D_0000_0001_addr_imm16) was MISSING here and fell to the default -> S_ILLEGAL, which is a silent terminal hang (` rtl/cpu/z8002/z8002.sv:1370 ==== BATCH 8: indexed group (0x4D, NIB2!=0): addr(rx) instead of plain addr -- 1=CP#imm(NEW: MAME Z4D_ddN0_0001_addr_imm16, compare mem@addr(rx) against a fetched imm16, discard result, CZSV flags per the existing S_ALU CP shape) 5=LD#imm(M rtl/cpu/z8002/z8002.sv:1374 "dst" here is really the INDEX register (MAME's own naming, kept only for its GET_DST macro use) -- reused as `idxr` per this file's convention. rtl/cpu/z8002/z8002.sv:1375 ==== BATCH 10: added 4'h0/2/6 (COM/NEG/TSET via dadop+S_DAD_FETCHX) AND 4'h8 (CLR -- MAME Z4D_ddN0_1000_addr, was MISSING from this indexed case entirely, a second CP-DIRECT-FIX-shaped gap: it silently fell to S_ILLEGAL just like 4D01 did b rtl/cpu/z8002/z8002.sv:1401 MAME QUIRK: Z4C_0000_0000_addr (COMB addr, direct, no index) reads via RDMEM_W not RDMEM_B in z8000ops.hxx -- an apparent source typo (every OTHER member of this family, incl. rtl/cpu/z8002/z8002.sv:1434 ==== BATCH 10: LDB addr(rd),rbs (0x4E) -- MAME QUIRK: z8000tbl.hxx's ONLY table entry for this handler is `{0x4e11,0x4ef0,16,...}`, which (per the verified beg/end/step init loop in z8000.cpp: `for(val=beg;val<=end; val+=step) z8000_exec[va rtl/cpu/z8002/z8002.sv:1439 Its semantic sibling Z6E_ddN0_ssss_addr (0x6E, already implemented) uses a DENSE step=1 table for the identical shape (index reg + byte value reg + fetched addr) -- confirming 2-free-nibble instructions normally get dense tables in this sou rtl/cpu/z8002/z8002.sv:1500 MAME z8000ops.hxx ZF_dddd_0dsp7: RB(dst)-=1; if (RB(dst)) set_pc(m_pc - 2dsp7); Same shape as the word form directly above. rtl/cpu/z8002/z8002.sv:1532 No multiprocessor cascade exists on this board (single Z8002, mu pins unconnected) -- MAME's own bodies are LITERALLY EMPTY beyond the privilege check (just a comment: "/* set mu-0 line /" etc, no state/flag change at all, confirmed by rea rtl/cpu/z8002/z8002.sv:1544 ==== BATCH 18: MREQ rd (0x7B_dddd_1101) : MAME Z7B_dddd_1101, flags -ZS---. rtl/cpu/z8002/z8002.sv:1547 With mu-I tied low (no multiprocessor peer -- same "unconnected pin" precedent as vi_n/nmi_n elsewhere in this core), MAME's own body resolves UNCONDITIONALLY to Z=1,S=0 (verified term-by-term against the C body's two `if(m_mi)` branches wi rtl/cpu/z8002/z8002.sv:1568 ==== BATCH 18: LDPS @rs (0x3910-0x39F0, NIB2=src!=0, NIB3=0 FIXED -- z8000tbl.hxx's ONLY entry is `{0x3910,0x39f0,16,...}`) : MAME Z39_ssN0_0000. rtl/cpu/z8002/z8002.sv:1575 Single unified memory space (this core has never modeled a separate stack-vs-data space anywhere -- MAME's `src==SP?m_stack:m_data` distinction collapses to the same bus here, consistent with every other instruction in this file). rtl/cpu/z8002/z8002.sv:1586 ==== BATCH 18: LDPS addr[,(rs)] (0x7900 exact / 0x7910-0x79F0, NIB3=0 FIXED in both) : MAME Z79_0000_0000_addr / Z79_ssN0_0000_addr. rtl/cpu/z8002/z8002.sv:1613 ---- ==== BATCH 17: real internal traps, per MAME z8000ops.hxx/z8000.cpp exactly, using the S_TRAP_ sequence added this batch. rtl/cpu/z8002/z8002.sv:1615 ==== ---- Z0E/Z0F/Z8E/Z8F (ext0e/ext0f/ext8e/ext8f) : MAME body calls CHECK_EXT_INSTR() = "if (!(m_fcw & F_EPU)) { trap; return; }" FIRST. rtl/cpu/z8002/z8002.sv:1622 When F_EPU IS set, MAME's body does nothing beyond consuming imm8 (the "Z8001 EPU code goes here" branch is a literal empty comment in z8000ops.hxx, verified -- not guessed). rtl/cpu/z8002/z8002.sv:1630 ---- Z36_0000_0000 (BPT, 0x3600 exact) : MAME body is `m_irq_req \|= Z8000_TRAP;` UNCONDITIONALLY (no CHECK_ macro at all -- this one always traps, in any mode). rtl/cpu/z8002/z8002.sv:1636 ---- Z7F_imm8 (SC, system call, 0x7F00-0x7FFF) : MAME body is `GET_IMM8(0); m_irq_req \|= Z8000_SYSCALL;` UNCONDITIONALLY (no CHECK_ macro -- SC always traps, that's its entire purpose; imm8 is word0's own low byte, already consumed, no PC e rtl/cpu/z8002/z8002.sv:1643 ==== BATCH 15 (still no-op, confirmed genuinely correct per MAME -- see report): Z38/Z78/Z7E/Z9D/Z9F/ZBF/Z36_imm8 have NO CHECK_EXT_INSTR call at all in their real C bodies (verified line-by-line) -- they just test `if (m_fcw & F_EPU)` and rtl/cpu/z8002/z8002.sv:1647 Since F_EPU is realistically never set on this board, MAME's own source treats these as UNCONDITIONAL no-ops, never traps -- this is not a corner cut, it is the literal, correct behavior per the authoritative source. rtl/cpu/z8002/z8002.sv:1677 ==== ---- INB rbd,@rs (0x3C) : MAME Z3C_ssss_dddd. rtl/cpu/z8002/z8002.sv:1684 ---- IN rd,@rs (0x3D) : MAME Z3D_ssss_dddd. rtl/cpu/z8002/z8002.sv:1690 ---- OUTB @rd,rbs (0x3E) : MAME Z3E_dddd_ssss. rtl/cpu/z8002/z8002.sv:1696 ---- OUT @rd,rs (0x3F) : MAME Z3F_dddd_ssss. rtl/cpu/z8002/z8002.sv:1703 UNLIKE the size=1 bucket above, these are genuinely SPARSE (multiple distinct sub-ops packed into one top byte, each pinned to specific NIB2/NIB3 values by its own table line) -- guards below reproduce each family's exact true valid set (NO rtl/cpu/z8002/z8002.sv:1766 ---- DI/EI i2 (0x7C00-0x7C07): NIB2=0, bit2 0=DI/1=EI, imm2=din[1:0] ---- MAME: di fcw&=(imm2<<11)\|0xe7ff ; ei fcw\|=(~imm2<<11)&0x1800 i.e. per interrupt bit: imm2 bit=1 -> leave alone, bit=0 -> act (set/clear) rtl/cpu/z8002/z8002.sv:1807 ==== BATCH 1: stack + control flow ==================================== ---- CALL @Rd indirect (0x1F, NIB2=dst!=0,NIB3=0) : MAME Z1F_ddN0_0000 ---- push PC (=pc2, already the post-fetch return addr), jump to R[dst]. rtl/cpu/z8002/z8002.sv:1813 ---- CALL addr direct (0x5F00 exact) : MAME Z5F_0000_0000_addr ---- fetch target word, then push PC(=old_pc+4)/jump. rtl/cpu/z8002/z8002.sv:1818 ==== BATCH 11: CALL addr(rd) indexed (0x5F10-0x5FF0, NIB2=dst!=0) : MAME Z5F_ddN0_0000_addr. rtl/cpu/z8002/z8002.sv:1819 NIB3 is a FIXED "0000" field here (unlike the 0x51/53/ 55/57 families where the low nibble is a genuine free index-register operand) -- z8000tbl.hxx's single table line `{0x5f10,0x5ff0,16,...}` confirms NIB3=0 always (BUG FOUND AND FIXED he rtl/cpu/z8002/z8002.sv:1861 Indexed reuses S_LDA76_FETCH/GO verbatim -- its `operand + (lda76_has_src?R[src]:0)` formula IS R[src]+idx16 (addition commutes; MAME's own RDBX_/add_to_ addr_reg helpers add register+fetched-word in either order, see report). rtl/cpu/z8002/z8002.sv:1888 ---- CALR dsp12 (0xD000-0xDFFF) : MAME ZD_dsp12 ---- target = pc2 - 2sext12(din[11:0]). rtl/cpu/z8002/z8002.sv:1890 MAME (z8000ops.hxx:6834) writes this piecewise: dsp12 = (dsp12 & 2048) ? rtl/cpu/z8002/z8002.sv:1895 Note the default direction is BACKWARD (bit11 clear => negative), which is why MAME's expression looks inverted. rtl/cpu/z8002/z8002.sv:1901 ---- RET cc (0x9E, NIB2=0) : MAME Z9E_0000_cccc ---- conditional pop-PC; if cc false, stack is UNTOUCHED (MAME only pops inside the taken case) -- just retire in place. rtl/cpu/z8002/z8002.sv:1911 ---- PUSH @Rd,Rs (0x93, NIB2=dst!=0) : MAME Z93_ddN0_ssss ---- rtl/cpu/z8002/z8002.sv:1915 ---- PUSH @Rd,#imm16 (0x0D, NIB2=dst!=0, NIB3=9) : MAME Z0D_ddN0_1001_imm16 ---- rtl/cpu/z8002/z8002.sv:1919 ---- PUSH @Rd,addr direct (0x53, NIB2=dst!=0,NIB3=0) : MAME Z53_ddN0_0000_addr ---- rtl/cpu/z8002/z8002.sv:1923 ==== BATCH 11: PUSH @Rd,addr(rs) indexed (0x53, NIB2=dst!=0,NIB3=src!=0) : MAME Z53_ddN0_ssN0_addr. rtl/cpu/z8002/z8002.sv:1929 ---- POP Rd,@Rs (0x97, NIB2=src!=0) : MAME Z97_ssN0_dddd ---- rtl/cpu/z8002/z8002.sv:1933 ---- POP addr,@Rs direct (0x57, NIB2=src!=0,NIB3=0) : MAME Z57_ssN0_0000_addr ---- rtl/cpu/z8002/z8002.sv:1937 ==== BATCH 11: POP addr(rd),@Rs indexed (0x57, NIB2=src!=0,NIB3=dst!=0) : MAME Z57_ssN0_ddN0_addr. rtl/cpu/z8002/z8002.sv:1938 src(NIB2)=POP source pointer register (postincrement, unchanged from the direct form); dst(NIB3)=index register added to the fetched addr (MAME names it "dst" only because GET_DST's macro shape fits -- it's a plain index register here, no r rtl/cpu/z8002/z8002.sv:1946 ---- PUSHL @Rd,RRs (0x91, NIB2=dst!=0) : MAME Z91_ddN0_ssss ---- dst=pointer reg (plain); src=value register PAIR select (bit0 truncated, see file header). rtl/cpu/z8002/z8002.sv:1953 ---- POPL RRd,@Rs (0x95, NIB2=src!=0) : MAME Z95_ssN0_dddd ---- src=pointer reg (plain); dst=dest register PAIR select (bit0 truncated). rtl/cpu/z8002/z8002.sv:1959 ==== BATCH 11: PUSHL @Rd,addr[,(rs)] (0x51, NIB2=dst!=0) : MAME Z51_ddN0_0000_addr / Z51_ddN0_ssN0_addr. rtl/cpu/z8002/z8002.sv:1970 ==== BATCH 11: POPL addr[,(rd)],@Rs (0x55, NIB2=src!=0) : MAME Z55_ssN0_0000_addr / Z55_ssN0_ddN0_addr. rtl/cpu/z8002/z8002.sv:1979 ==== BATCH 11: SUBL rrd,addr[,(rs)] (0x52) : MAME Z52_0000_dddd_addr / Z52_ssN0_dddd_addr. rtl/cpu/z8002/z8002.sv:1988 ==== BATCH 11: ADDL rrd,addr[,(rs)] (0x56) : MAME Z56_0000_dddd_addr / Z56_ssN0_dddd_addr. rtl/cpu/z8002/z8002.sv:1995 ==== BATCH 11: MULTL rqd,addr[,(rs)] (0x58) : MAME Z58_0000_dddd_addr / Z58_ssN0_dddd_addr. rtl/cpu/z8002/z8002.sv:2002 ==== BATCH 11: DIVL rqd,addr[,(rs)] (0x5A) : MAME Z5A_0000_dddd_addr / Z5A_ssN0_dddd_addr. rtl/cpu/z8002/z8002.sv:2009 ==== BATCH 11: MULT rrd,addr[,(rs)] (0x59) : MAME Z59_0000_dddd_addr / Z59_ssN0_dddd_addr. rtl/cpu/z8002/z8002.sv:2016 ==== BATCH 11: DIV rrd,addr[,(rs)] (0x5B) : MAME Z5B_0000_dddd_addr / Z5B_ssN0_dddd_addr. rtl/cpu/z8002/z8002.sv:2023 ---- LDL RRd,RRs (0x94, full range) : MAME Z94_ssss_dddd ---- single-cycle reg-pair move, no memory access. rtl/cpu/z8002/z8002.sv:2036 MAME Z94_ssss_dddd: RL(dst) = RL(src). rtl/cpu/z8002/z8002.sv:2043 ---- LDL RRd,#imm32 (0x14, NIB2=0) : MAME Z14_0000_dddd_imm32 ---- imm32 = {word1(hi),word2(lo)} (verified via GET_IMM32 macro). rtl/cpu/z8002/z8002.sv:2048 ---- LDL RRd,@Rs (0x14, NIB2=src!=0) : MAME Z14_ssN0_dddd ---- rtl/cpu/z8002/z8002.sv:2052 ---- LDL @Rd,RRs (0x1D, NIB2=dst!=0) : MAME Z1D_ddN0_ssss ---- rtl/cpu/z8002/z8002.sv:2056 ---- LDL RRd,addr direct (0x54, NIB2=0) : MAME Z54_0000_dddd_addr ---- rtl/cpu/z8002/z8002.sv:2060 ==== BATCH 7 (post-verify): LDL RRd,addr(rs) indexed (0x54, NIB2!=0) : MAME Z54_ssN0_dddd_addr. rtl/cpu/z8002/z8002.sv:2066 ---- LDL addr,RRs direct (0x5D, NIB2=0) : MAME Z5D_0000_ssss_addr ---- rtl/cpu/z8002/z8002.sv:2070 ==== BATCH 8: LDL addr(rx),RRs indexed (0x5D, NIB2!=0) : MAME Z5D_ddN0_ssss_addr (dst here is the INDEX reg per z8000ops.hxx GET_DST, src is the reg-pair stored). rtl/cpu/z8002/z8002.sv:2078 ---- LDM rd,@rs,n (0x1C, NIB2=src!=0,NIB3=1) : MAME Z1C_ssN0_0001_0000_dddd_0000_nmin1 ---- word2 = {4'b0,dst[11:8],4'b0,cnt[3:0]}; transfers cnt+1 words mem->regs, dst wraps mod 16 each step (natural 4-bit reg wrap == MAME's (dst+1)&15). rtl/cpu/z8002/z8002.sv:2084 ---- LDM @rd,rs,n (0x1C, NIB2=dst!=0,NIB3=9) : MAME Z1C_ddN0_1001_0000_ssss_0000_nmin1 ---- rtl/cpu/z8002/z8002.sv:2088 ==== BATCH 15: TESTL @rd (0x1C, NIB2=dst!=0,NIB3=8) : MAME Z1C_ddN0_1000 "testl @rd", flags -ZS---. rtl/cpu/z8002/z8002.sv:2097 ==== BATCH 7 (post-verify): LDM addr,rs,n (0x5C09) direct-address STORE : MAME Z5C_0000_1001_0000_ssss_0000_nmin1_addr. rtl/cpu/z8002/z8002.sv:2104 ==== BATCH 11: LDM addr(rd),rs,n (0x5CN9, NIB2=idx!=0) indexed sibling of 0x5C09 above : MAME Z5C_ddN0_1001_0000_ssN0_0000_nmin1_addr. rtl/cpu/z8002/z8002.sv:2111 ==== BATCH 8: LDM rd,addr,n (0x5C01) direct-address LOAD, the load-direction sibling of 0x5C09 above : MAME Z5C_0000_0001_0000_dddd_0000_nmin1_addr. rtl/cpu/z8002/z8002.sv:2118 ==== BATCH 11: LDM rd,addr(rs),n (0x5CN1, NIB2=idx!=0) indexed sibling of 0x5C01 above : MAME Z5C_ssN0_0001_0000_dddd_0000_nmin1_addr. rtl/cpu/z8002/z8002.sv:2124 ==== BATCH 11: TESTL addr (0x5C08 exact) : MAME Z5C_0000_1000_addr. rtl/cpu/z8002/z8002.sv:2130 ==== BATCH 11: TESTL addr(rd) indexed (0x5CN8, NIB2=idx!=0) : MAME Z5C_ddN0_1000_addr. rtl/cpu/z8002/z8002.sv:2135 ==== BATCH 2 PART A: indirect-indirect PUSHL/PUSH/POPL/POP ================ ---- PUSHL @Rd,@Rs (0x11) : MAME Z11_ddN0_ssN0 "pushl @rd,@rs" ---- value = long read INDIRECTLY at R[src] (src ptr unmodified); pushed (pre-decrement by 4) to R[ds rtl/cpu/z8002/z8002.sv:2156 ---- PUSH @Rd,@Rs (0x13) : MAME Z13_ddN0_ssN0 "push @rd,@rs" ---- value = word read INDIRECTLY at R[src] (unmodified); hands off to the existing S_PUSH_W commit (addr=R[dst]-2,dout=operand,we=1) unchanged. rtl/cpu/z8002/z8002.sv:2165 ---- POPL RRd,@Rs (0x15) : MAME Z15_ssN0_ddN0 "popl rd,@rs" ---- Body is BYTE-IDENTICAL to the already-implemented 0x95 (POPL RRd,@Rs): dst is a DIRECT register-pair write (RL(dst)=POPL(src)), never indirect -- despite MAME's disassembler ( rtl/cpu/z8002/z8002.sv:2180 ---- POP @Rd,@Rs (0x17) : MAME Z17_ssN0_ddN0 "pop @rd,@rs" ---- dst(NIB3)=target pointer (WRITTEN indirectly, itself never modified); src(NIB2)=source pointer (POPPED: read then +2). rtl/cpu/z8002/z8002.sv:2192 ==== BATCH 2 PART B: byte ALU/LDB, LDB store, CPL, JP/EX, BIT/RES/SET ===== Shared byte pipeline (S_IMMB/S_MEMRDB/S_ALUB) mirrors the existing word ALU pipeline (S_IMM/S_MEMRD/S_ALU) exactly, but for the byte register file (RB(n): dst[3]?LO rtl/cpu/z8002/z8002.sv:2200 ---- ADDB rd,#imm8 (0x00, NIB2=0) : MAME Z00_0000_dddd_imm8 ---- rtl/cpu/z8002/z8002.sv:2204 ---- SUBB rd,#imm8/@rs (0x02) : MAME Z02_0000_dddd_imm8 / Z02_ssN0_dddd ---- rtl/cpu/z8002/z8002.sv:2209 ---- ORB rd,#imm8/@rs (0x04) : MAME Z04_0000_dddd_imm8 / Z04_ssN0_dddd ---- rtl/cpu/z8002/z8002.sv:2214 ---- ANDB rd,#imm8/@rs (0x06) : MAME Z06_0000_dddd_imm8 / Z06_ssN0_dddd ---- rtl/cpu/z8002/z8002.sv:2219 ---- XORB rd,#imm8/@rs (0x08) : MAME Z08_0000_dddd_imm8 / Z08_ssN0_dddd ---- rtl/cpu/z8002/z8002.sv:2224 ---- CPB rd,#imm8/@rs (0x0A) : MAME Z0A_0000_dddd_imm8 / Z0A_ssN0_dddd ---- rtl/cpu/z8002/z8002.sv:2229 ---- LDB rd,#imm8/@rs (0x20) : MAME Z20_0000_dddd_imm8 / Z20_ssN0_dddd ---- rtl/cpu/z8002/z8002.sv:2246 ---- LDB @Rd,rbs store (0x2E, NIB2=dst!=0) : MAME Z2E_ddN0_ssss "ldb @rd,rbs" ---- RMW-safe byte store, see S_LDBST_RD/WR header comment (wordacc unconnected). rtl/cpu/z8002/z8002.sv:2251 ---- JP cc,@Rd (0x1E, NIB2=dst!=0) : MAME Z1E_ddN0_cccc "jp cc,@rd" ---- addr_from_reg(dst) reduces to plain RW(dst) in non-segmented (Z8002) mode -- despite the MAME disassembler cosmetically showing "@rr1" (a segmented-mode register-pair rtl/cpu/z8002/z8002.sv:2261 ---- CPL rrd,@rs (0x10, NIB2=src!=0) : MAME Z10_ssN0_dddd "cpl rrd,@rs" ---- compare-only long, no writeback. rtl/cpu/z8002/z8002.sv:2267 ---- CPL rrd,rrs (0x90, full range) : MAME Z90_ssss_dddd "cpl rrd,rrs" ---- compare-only, no writeback, no memory access -- routed through S_CPL_RR (shares the same flag-compute code shape as the indirect form above). rtl/cpu/z8002/z8002.sv:2273 ---- BITB @Rd,#imm4 (0x26, NIB2=dst!=0) : MAME Z26_ddN0_imm4, flags -Z---- ---- read-only (no RMW hazard). rtl/cpu/z8002/z8002.sv:2279 ---- BIT @Rd,#imm4 (0x27, NIB2=dst!=0) : MAME Z27_ddN0_imm4, flags -Z---- ---- rtl/cpu/z8002/z8002.sv:2289 ---- RES @Rd,#imm4 (0x23, NIB2=dst!=0) : MAME Z23_ddN0_imm4, flags ------ ---- rtl/cpu/z8002/z8002.sv:2294 ---- SET @Rd,#imm4 (0x25, NIB2=dst!=0) : MAME Z25_ddN0_imm4, flags ------ ---- rtl/cpu/z8002/z8002.sv:2317 ---- EX rd,@rs (0x2D, NIB2=src!=0) : MAME Z2D_ssN0_dddd "ex rd,@rs", flags ------ ---- word-only exchange (safe, full-word RMW). rtl/cpu/z8002/z8002.sv:2323 ==== BATCH 3 ============================================================= ---- INC addr,#n direct (0x6900-0x690F, NIB2=0) : MAME Z69_0000_imm4m1_addr, flags -ZSV--. rtl/cpu/z8002/z8002.sv:2333 ---- DEC addr,#n direct (0x6B00-0x6B0F, NIB2=0) : MAME Z6B_0000_imm4m1_addr, flags -ZSV--. rtl/cpu/z8002/z8002.sv:2338 ---- MULT rrd,#imm16 (0x1900-0x190F, NIB2=0) : MAME Z19_0000_dddd_imm16 ---- flags CZS--- ; V is NEVER set by MULTW despite the MAME doc-comment saying "CZSV--" -- the function body only calls CLR_CZSV, no SET_V anywhere. rtl/cpu/z8002/z8002.sv:2345 ---- MULT rrd,@rs (0x1910-0x19FF, NIB2!=0) : MAME Z19_ssN0_dddd ---- rtl/cpu/z8002/z8002.sv:2349 ---- MULT rrd,rs (0x9900-0x99FF, full range) : MAME Z99_ssss_dddd ---- rtl/cpu/z8002/z8002.sv:2353 ---- DIV rrd,#imm16 (0x1B00-0x1B0F, NIB2=0) : MAME Z1B_0000_dddd_imm16 ---- flags CZSV--. rtl/cpu/z8002/z8002.sv:2358 ---- DIV rrd,@rs (0x1B10-0x1BFF, NIB2!=0) : MAME Z1B_ssN0_dddd ---- rtl/cpu/z8002/z8002.sv:2362 ---- DIV rrd,rs (0x9B00-0x9BFF, full range) : MAME Z9B_ssss_dddd ---- rtl/cpu/z8002/z8002.sv:2366 ---- MULTL rqd,@rs (0x1810-0x18FF, NIB2!=0) : MAME Z18_ssN0_dddd ---- RQ(dst) truncates dst's low TWO bits (see header comment); the 32-bit dest value MULTL actually reads is the LOW half of the quad, i.e. RL(dst\|2). rtl/cpu/z8002/z8002.sv:2372 ==== BATCH 14: MULTL rqd,#imm32 (0x1800-0x180F, NIB2=0) : MAME Z18_00N0_dddd_imm32. rtl/cpu/z8002/z8002.sv:2380 ---- MULTL rqd,rrs (0x9800-0x98FF, full range) : MAME Z98_ssss_dddd ---- src is a 32-bit register PAIR here (unlike MULT's plain-register src) -- staged combinationally straight off `din`, same convention already used by ADDL/SUBL reg-reg b rtl/cpu/z8002/z8002.sv:2390 ---- DIVL rqd,@rs (0x1A10-0x1AFF, NIB2!=0) : MAME Z1A_ssN0_dddd ---- Dividend is the FULL 64-bit quad (read live off the regfile in S_DIVL_GO); only the 32-bit divisor needs fetching here. rtl/cpu/z8002/z8002.sv:2396 ==== BATCH 14: DIVL rqd,#imm32 (0x1A00-0x1A0F, NIB2=0) : MAME Z1A_0000_dddd_imm32. rtl/cpu/z8002/z8002.sv:2402 ---- DIVL rqd,rrs (0x9A00-0x9AFF, full range) : MAME Z9A_ssss_dddd ---- rtl/cpu/z8002/z8002.sv:2408 ---- ADDL rrd,#imm32 (0x1600-0x160F, NIB2=0) : MAME Z16_0000_dddd_imm32 ---- rtl/cpu/z8002/z8002.sv:2412 ---- ADDL rrd,@rs (0x1610-0x16FF, NIB2!=0) : MAME Z16_ssN0_dddd ---- rtl/cpu/z8002/z8002.sv:2416 ---- ADDL rrd,rrs (0x9600-0x96FF, full range) : MAME Z96_ssss_dddd ---- rtl/cpu/z8002/z8002.sv:2422 ---- SUBL rrd,#imm32 (0x1200-0x120F, NIB2=0) : MAME Z12_0000_dddd_imm32 ---- rtl/cpu/z8002/z8002.sv:2426 ---- SUBL rrd,@rs (0x1210-0x12FF, NIB2!=0) : MAME Z12_ssN0_dddd ---- rtl/cpu/z8002/z8002.sv:2430 ---- SUBL rrd,rrs (0x9200-0x92FF, full range) : MAME Z92_ssss_dddd ---- rtl/cpu/z8002/z8002.sv:2436 ---- LDB rbd,addr direct-load (0x6000-0x600F, NIB2=0) : MAME Z60_0000_dddd_addr "ldb rbd,addr", flags ------. rtl/cpu/z8002/z8002.sv:2444 ---- LDB addr,rbs direct-store (0x6E00-0x6E0F, NIB2=0) : MAME Z6E_0000_ssss_addr "ldb addr,rbs", flags ------. rtl/cpu/z8002/z8002.sv:2452 ---- CLRB rbd (0x8Cd8, NIB1=8) : MAME Z8C_dddd_1000, flags ------ ---- 0x8C is actually a 7-way static-op family (comb/negb/testb/tsetb/ldctlb-r/ clrb/ldctlb-w, selected by NIB1) -- the task brief's "CLRB/TESTB static" framing undersold the rtl/cpu/z8002/z8002.sv:2463 ---- TESTB rbd (0x8Cd4, NIB1=4) : MAME Z8C_dddd_0100, flags -ZSP-- ---- Z/S/parity via the same z8000_zsp[]-equivalent formula already used for Batch 2's byte AND/OR/XOR P/V (parity, not overflow). rtl/cpu/z8002/z8002.sv:2472 ---- RLB rbd,#1\|#2 (0xB2d0/0xB2d2, NIB1={0,2}) : MAME ZB2_dddd_00I0, flags CZSV--. rtl/cpu/z8002/z8002.sv:2484 ---- RRB rbd,#1\|#2 (0xB2d4/0xB2d6, NIB1={4,6}) : MAME ZB2_dddd_01I0, flags CZSV--. rtl/cpu/z8002/z8002.sv:2485 QUIRK (verified in RRB(), not the doc-comment): if result==0 only Z is set; else if result[7] BOTH S and C are set together (MAME SET_SC macro); else (positive nonzero) neither Z/S/C is touched. rtl/cpu/z8002/z8002.sv:2499 ---- RRCB rbd,#1\|#2 (0xB2dC/0xB2dE, NIB1={C,E}) : MAME ZB2_dddd_11I0 "rotate right through carry", flags CZSV-- (doc-comment says "-Z----", WRONG -- the RRCB() body clearly does CLR_CZSV + SET_C + SET_V, trusted the code). rtl/cpu/z8002/z8002.sv:2518 ==== BATCH 14: RLCB rbd,#1\|#2 (0xB2d8/0xB2dA, NIB1={8,A}) : MAME ZB2_dddd_10I0 "rotate left through carry", flags CZSV--. rtl/cpu/z8002/z8002.sv:2537 ---- SLLB/SRLB rbd,#imm8 (0xB2d1, NIB1=1) : MAME ZB2_dddd_0001_imm8, sign of imm8 selects direction (matches the existing word S_SHIFT convention exactly, negative=right/SRLB, positive=left/SLLB). rtl/cpu/z8002/z8002.sv:2547 ==== BATCH 14: SDLB rbd,rs (0xB2d3) : MAME ZB2_dddd_0011_0000_ssss_0000_0000, flags CZSV-- (its doc-comment AND body both confirm V IS set here, unlike SLLB's imm8 sibling above -- verified, not assumed from the "SD" prefix's resemblance to rtl/cpu/z8002/z8002.sv:2550 Dynamic (register- count) sibling of SLLB/SRLB: count = sign-extended R[word2 NIB1][7:0], positive=left/negative=right (same convention as every imm-shift in this file), computed as a single barrel shift + explicit carry-capture -- proven e rtl/cpu/z8002/z8002.sv:2562 ---- SDAB rbd,rs (0xB2dB) : MAME ZB2_dddd_1011_0000_ssss_0000_0000, flags CZSV--. rtl/cpu/z8002/z8002.sv:2569 ==== BATCH 15: SLAB/SRAB rbd,#imm8 (0xB2d9) : MAME ZB2_dddd_1001_imm8, flags CZSV-- (byte arithmetic sibling of the already-implemented SLLB/ SRLB imm8, S_SHIFTB). rtl/cpu/z8002/z8002.sv:2576 ==== BATCH 14: RL/RR/RLC/RRC rd,#1\|#2 (0xB3d0/d2/d4/d6/d8/dA/dC/dE) : MAME ZB3_dddd_00I0/01I0/10I0/11I0, flags CZSV--. rtl/cpu/z8002/z8002.sv:2651 ---- CPL rrd,addr direct (0x5000-0x500F, NIB2=0) : MAME Z50_0000_dddd_addr "cpl rrd,addr", compare-only, no writeback. rtl/cpu/z8002/z8002.sv:2670 ---- LDB rbd,addr(Rs) indexed load (0x6010-0x60FF, NIB2=idx!=0) : MAME Z60_ssN0_dddd_addr. rtl/cpu/z8002/z8002.sv:2675 ---- LDB addr(Rs),rbs indexed store (0x6E10-0x6EFF, NIB2=idx!=0) : MAME Z6E_ddN0_ssss_addr (field named "dd" but is the INDEX reg, not a dest -- same misleading-macro-name pattern already flagged for Z69/Z6B). rtl/cpu/z8002/z8002.sv:2683 ---- CPL rrd,addr(Rs) indexed (0x5010-0x50FF, NIB2=idx!=0) : MAME Z50_ssN0_dddd_addr. rtl/cpu/z8002/z8002.sv:2688 ---- INC addr(Rd),#n indexed (0x6910-0x69FF, NIB2=idx!=0) : MAME Z69_ddN0_imm4m1_addr. rtl/cpu/z8002/z8002.sv:2694 ---- DEC addr(Rd),#n indexed (0x6B10-0x6BFF, NIB2=idx!=0) : MAME Z6B_ddN0_imm4m1_addr. rtl/cpu/z8002/z8002.sv:2699 ==== BATCH 4: register-only bonus opcodes ================================== ---- NEG rd (0x8Dd2, NIB0=2) : MAME Z8D_dddd_0010, flags CZSV--. rtl/cpu/z8002/z8002.sv:2712 ---- COM rd (0x8Dd0, NIB0=0) : MAME Z8D_dddd_0000, flags -ZS---. rtl/cpu/z8002/z8002.sv:2720 ---- EXTSB rd (0xB1d0, NIB0=0) : MAME ZB1_dddd_0000 "extsb rd", flags ------. rtl/cpu/z8002/z8002.sv:2729 ==== BATCH 8: DAB rbd (0xB0d0, NIB0=0) : MAME ZB0_dddd_0000 "dab rbd", flags CZS---. rtl/cpu/z8002/z8002.sv:2733 idx into dab_rom = {DA,H,C,byte-value} per z8000dab.h's own header comment; CZS recomputed from the RESULT byte (CLR_CZS+CHK_XXXB_ZS: Z=(result==0), S=result[7]; H is left UNCHANGED -- MAME's DAB never touches F_H, matching CLR_CZS's mask e rtl/cpu/z8002/z8002.sv:2745 ---- EXTS rrd (0xB1dA, NIB0=A) : MAME ZB1_dddd_1010 "exts rrd", flags ------. rtl/cpu/z8002/z8002.sv:2754 ---- RESB @Rd,#imm4 (0x2210-0x22FF, NIB2=dst!=0) : MAME Z22_ddN0_imm4 "resb @rd,imm4", flags ------. rtl/cpu/z8002/z8002.sv:2762 ---- SETB @Rd,#imm4 (0x2410-0x24FF, NIB2=dst!=0) : MAME Z24_ddN0_imm4 "setb @rd,imm4", flags ------. rtl/cpu/z8002/z8002.sv:2769 ---- EXB rbd,@rs (0x2C10-0x2CFF, NIB2=src!=0) : MAME Z2C_ssN0_dddd "exb rbd,@rs", flags ------. rtl/cpu/z8002/z8002.sv:2776 ---- EXB rbd,rbs (0xAC, full range) : MAME ZAC_ssss_dddd "exb rbd,rbs", flags ------. rtl/cpu/z8002/z8002.sv:2785 ---- ADCB rd,rs (0xB4, full range) : MAME ZB4_ssss_dddd, flags CZSVDH (DA cleared -- CLR_DA in the macro body, like ADDB). rtl/cpu/z8002/z8002.sv:2801 ---- ADC rd,rs (0xB5, full range) : MAME ZB5_ssss_dddd, flags CZSV-- (no H/DA, matches ADDW). rtl/cpu/z8002/z8002.sv:2813 ---- SBCB rd,rs (0xB6, full range) : MAME ZB6_ssss_dddd, flags CZSVDH (DA SET unconditionally -- SET_DA in the macro body, like SUBB). rtl/cpu/z8002/z8002.sv:2828 ---- SBC rd,rs (0xB7, full range) : MAME ZB7_ssss_dddd, flags CZSV-- (no H/DA, matches SUBW). rtl/cpu/z8002/z8002.sv:2844 ---- RESB addr[,(rd)],#imm4 (0x6200-0x62FF) : MAME Z62_0000_imm4_addr / Z62_ddN0_imm4_addr, byte RMW, flags ------. rtl/cpu/z8002/z8002.sv:2854 ---- RES addr[,(rd)],#imm4 (0x6300-0x63FF) : MAME Z63_0000_imm4_addr / Z63_ddN0_imm4_addr, word RMW, flags ------. rtl/cpu/z8002/z8002.sv:2863 ---- SETB addr[,(rd)],#imm4 (0x6400-0x64FF) : MAME Z64_0000_imm4_addr / Z64_ddN0_imm4_addr, byte RMW, flags ------. rtl/cpu/z8002/z8002.sv:2872 ---- SET addr[,(rd)],#imm4 (0x6500-0x65FF) : MAME Z65_0000_imm4_addr / Z65_ddN0_imm4_addr, word RMW, flags ------. rtl/cpu/z8002/z8002.sv:2881 ---- BITB addr[,(rd)],#imm4 (0x6600-0x66FF) : MAME Z66_0000_imm4_addr / Z66_ddN0_imm4_addr, read-only byte, flags -Z----. rtl/cpu/z8002/z8002.sv:2890 ---- BIT addr[,(rd)],#imm4 (0x6700-0x67FF) : MAME Z67_0000_imm4_addr / Z67_ddN0_imm4_addr, read-only word, flags -Z----. rtl/cpu/z8002/z8002.sv:2899 ---- EXB rbd,addr[(rs)] (0x6C00-0x6CFF) : MAME Z6C_0000_dddd_addr / Z6C_ssN0_dddd_addr, byte RMW exchange, flags ------. rtl/cpu/z8002/z8002.sv:2910 ---- EX rd,addr[(rs)] (0x6D00-0x6DFF) : MAME Z6D_0000_dddd_addr / Z6D_ssN0_dddd_addr, word exchange, flags ------. rtl/cpu/z8002/z8002.sv:2919 ---- EX rd,rs reg-reg (0xAD, full range) : MAME ZAD_ssss_dddd "ex rd,rs", flags ------. rtl/cpu/z8002/z8002.sv:2929 z8000tbl.hxx's table range for this whole family starts at NIB2=1 (0x0c10/0x0d10, NOT 0x0c00/ 0x0d00) -- dst=R0 is UNDEFINED here (falls to illegal on real MAME), so every arm below is gated din[7:4]!=0, matching the file's existing convent rtl/cpu/z8002/z8002.sv:2944 COMB @rd (0x0C_x_0, NIB3=0000) : MAME Z0C_ddN0_0000 body reads GET_DST(OP0,NIB3) instead of NIB2 like EVERY sibling (NEGB/TESTB/TSETB/ CLRB/LDB/CPB all correctly use NIB2) -- since NIB3 is the FIXED sub-op selector here (always 0000 for thi rtl/cpu/z8002/z8002.sv:2956 NEGB @rd (0x0C_x_2, NIB3=0010) : MAME Z0C_ddN0_0010, flags CZSV--. rtl/cpu/z8002/z8002.sv:2960 CPB @rd,imm8 (0x0C_x_1, NIB3=0001) : MAME Z0C_ddN0_0001_imm8, flags CZSV--. rtl/cpu/z8002/z8002.sv:2964 LDB @rd,imm8 (0x0C_x_5, NIB3=0101) : MAME Z0C_ddN0_0101_imm8, flags ------. rtl/cpu/z8002/z8002.sv:2968 ---- TESTB @rd (0x0C10-0x0CF0, NIB3=4) : MAME Z0C_ddN0_0100 "testb @rd", read-only, flags -ZSP-- (same formula as the register-direct TESTB rbd, 0x8Cd4). rtl/cpu/z8002/z8002.sv:2974 ---- TSETB @rd (0x0C16-0x0CF6, NIB3=6) : MAME Z0C_ddN0_0110 "tsetb @rd", byte RMW (wordacc rule), flags --S---. rtl/cpu/z8002/z8002.sv:2980 ---- CLRB @rd (0x0C18-0x0CF8, NIB3=8) : MAME Z0C_ddN0_1000 "clrb @rd", byte RMW (wordacc rule, unconditional 0), flags ------. rtl/cpu/z8002/z8002.sv:2985 ---- COM @rd (0x0D10-0x0DF0, NIB3=0) : MAME Z0D_ddN0_0000 "com @rd", word RMW, flags -ZS--- (same formula as the register-direct COM rd, 0x8Dd0). rtl/cpu/z8002/z8002.sv:2991 ---- CP @rd,#imm16 (0x0D11-0x0DF1, NIB3=1) : MAME Z0D_ddN0_0001_imm16 "cp @rd,imm16", read-only compare, flags CZSV-- (same formula as the existing word CP aluop in S_ALU). rtl/cpu/z8002/z8002.sv:2997 ---- NEG @rd (0x0D12-0x0DF2, NIB3=2) : MAME Z0D_ddN0_0010 "neg @rd", word RMW, flags CZSV-- (same formula as the register-direct NEG rd, 0x8Dd2). rtl/cpu/z8002/z8002.sv:3003 ---- TEST @rd (0x0D14-0x0DF4, NIB3=4) : MAME Z0D_ddN0_0100 "test @rd", read-only, flags -ZS--- (same formula as the existing DA_TST direct-address test). rtl/cpu/z8002/z8002.sv:3009 ---- TSET @rd (0x0D16-0x0DF6, NIB3=6) : MAME Z0D_ddN0_0110 "tset @rd", word RMW, flags --S---. rtl/cpu/z8002/z8002.sv:3015 ---- CLR @rd (0x0D18-0x0DF8, NIB3=8) : MAME Z0D_ddN0_1000 "clr @rd", plain word write (no read needed), flags ------. rtl/cpu/z8002/z8002.sv:3044 ==== BATCH 6: CPL rrd,imm32 (0x1000-0x100F, task item 2) ================ MAME Z10_0000_dddd_imm32, compare-only long against a 32-bit immediate (imm32={word1(hi),word2(lo)}, same GET_IMM32 convention as the existing LDL RRd,#imm32). rtl/cpu/z8002/z8002.sv:3097 ==== BATCH 6: register-only closures (zero new states) =================== ---- COMB rbd (0x8Cd0) : MAME Z8C_dddd_0000, flags -ZSP-- (CHK_XXXB_ZSP, same parity convention as the already-implemented byte AND/OR/XOR/TESTB -- verified against rtl/cpu/z8002/z8002.sv:3109 ---- NEGB rbd (0x8Cd2) : MAME Z8C_dddd_0010, flags CZSV-- (same formula as the already-implemented word NEG rd, 0x8Dd2, one level narrower). rtl/cpu/z8002/z8002.sv:3118 ---- TSETB rbd (0x8Cd6) : MAME Z8C_dddd_0110, flags --S--- (S=old bit7, unconditional 0xFF -- same formula as the already-implemented register- INDIRECT TSETB @rd, S_TSETBI_RD, one level more direct: no memory access at all). rtl/cpu/z8002/z8002.sv:3128 ---- LDCTLB rbd,flags (0x8Cd1) : MAME Z8C_dddd_0001 "ldctlb rbd,flags" -- reads the CURRENT flag byte (FCW bits[7:2] = C/Z/S/V/D/H, exactly this file's MC/MZ/MS/MV/MDA/MH bit positions) into rbd. rtl/cpu/z8002/z8002.sv:3137 ---- LDCTLB flags,rbd (0x8Cd9) : MAME Z8C_dddd_1001 "ldctlb flags,rbd" -- writes rbd's value into FCW bits[7:2], mirror of the read form above. rtl/cpu/z8002/z8002.sv:3144 ---- NOP (0x8D07 EXACT) : MAME Z8D_0000_0111 "nop" -- single exact opcode (not a NIB-varying family like its 0x8D siblings), no effect. rtl/cpu/z8002/z8002.sv:3149 ---- TEST rd (0x8Dd4) : MAME Z8D_dddd_0100 "test rd", flags -ZS--- (same TESTW formula as the existing direct-address TEST, DA_TST). rtl/cpu/z8002/z8002.sv:3155 ---- TSET rd (0x8Dd6) : MAME Z8D_dddd_0110 "tset rd", flags --S--- (S=old bit15, unconditional 0xFFFF -- same formula as the already-implemented register-INDIRECT TSET @rd, S_TSETI_RD). rtl/cpu/z8002/z8002.sv:3168 ---- SETFLG/RESFLG/COMFLG imm4 (0x8D_imm4_0001/0011/0101, NIB0=1/3/5) : MAME Z8D_imm4_0001/0011/0101 -- set/clear/toggle FCW bits[7:4] (C/Z/S/V) directly from the OPCODE WORD's own bits[7:4] (m_fcw\|=/&=~/^= m_op[0]& 0x00f0), no register/mem rtl/cpu/z8002/z8002.sv:3182 ---- TESTL rrd (0x9C00-0x9CF8, NIB3={0,8} only per z8000tbl.hxx's step=8 table row -- the handler body ignores NIB3 entirely, GET_DST uses NIB2) : MAME Z9C_dddd_1000 "testl rrd", flags -ZS--- (32-bit long test, register-only; pair-select = rtl/cpu/z8002/z8002.sv:3193 ---- RESB/RES/SETB/SET/BITB/BIT rd,imm4 register-DIRECT forms (0xA2- 0xA7, full range each) : MAME ZA2-ZA7_dddd_imm4 -- register-only bit-ops (no memory access at all), distinct from the already-implemented memory-form @Rd,#imm4 family (0x2 rtl/cpu/z8002/z8002.sv:3229 ---- TCCB cc,rbd / TCC cc,rd (0xAE/0xAF, full range) : MAME ZAE/ZAF_ dddd_cccc "tccb/tcc cc,rbd/rd", flags ------ -- bit0 UNCONDITIONALLY replaced by cc_true(cc) (not OR'd -- MAME clears bit0 first, then conditionally sets it, net effect = rtl/cpu/z8002/z8002.sv:3244 ---- LDK rd,imm4 (0xBD, full range) : MAME ZBD_dddd_imm4 "ldk rd,imm4", flags ------ -- zero-extended 4-bit immediate load, cheapest possible instruction (no memory access, no flags, single word). rtl/cpu/z8002/z8002.sv:3251 ---- RLDB rba,rbb (0xBC, full range) : MAME ZBC_aaaa_bbbb "rldb rba,rbb" -- a=NIB2,b=NIB3 (both plain byte-reg-codes, NOT gated non-zero). rtl/cpu/z8002/z8002.sv:3268 ---- RRDB rba,rbb (0xBE, full range) : MAME ZBE_aaaa_bbbb "rrdb rba,rbb" -- same term-by-term trace discipline as RLDB above. rtl/cpu/z8002/z8002.sv:3284 ---- EXTSL rqd (0xB1d7, NIB0=7) : MAME ZB1_dddd_0111 "extsl rqd", flags ------ -- sign-extends the LOW 32 bits of the quad (R[qbase+2]: R[qbase+3]) into the HIGH 32 bits (R[qbase]:R[qbase+1]), one level wider than the already-implemented EX rtl/cpu/z8002/z8002.sv:3295 ---- LDB rd,imm8 short form (0xC000-0xCFFF, full range) : MAME ZC_dddd_imm8 "ldb rbd,imm8" -- dst=NIB1(din[11:8], byte-reg-code), imm8=din[7:0] (the SAME opcode word's low byte -- single-word instruction, no second-word fetch at all). rtl/cpu/z8002/z8002.sv:3523 V: left sets it on a sign change (MAME `if((result^dest)&S16)SET_V`); right NEVER sets it -- SRAW's actual body has no SET_V call at all despite the "flags CZSV--" doc-comment, verified against the macro body, not assumed from the mnemonic. rtl/cpu/z8002/z8002.sv:3581 No memory access at all -- `addr` is a raw absolute 16-bit operand word (MAME GET_ADDR_RAW, no PC-relative resolution needed off-segment), NOT a pointer to dereference. rtl/cpu/z8002/z8002.sv:3590 `pc` here already equals the address of the dsp16 word being read as `din` this cycle (decode set pc<=pc2 one cycle earlier) -- MAME's GET_DSP16 evaluates addr_add(m_pc, (int16_t)tmp16) AFTER get_operand(1) has advanced m_pc PAST that word, rtl/cpu/z8002/z8002.sv:3724 MAME: if(--RW(cnt)){CLR_V; if(cc==0)m_pc-=4;} else SET_V; rtl/cpu/z8002/z8002.sv:3964 Flags CZSV per MAME CPL()/CHK_SUBL_V. rtl/cpu/z8002/z8002.sv:4064 ---- MULT rrd,{#imm16\|@rs\|rs}: dest16 = LOW word of RL(dst) (MAME truncates RL(dst) to uint16_t for MULTW's `dest` param); product overwrites the FULL RL(dst) pair. rtl/cpu/z8002/z8002.sv:4066 V is NEVER set (verified in MULTW's body -- only CLR_CZSV runs, no SET_V despite the doc-comment saying CZSV--); C uses MAME's exact asymmetric bounds (< -32767 or >= 32767), not +-32768. rtl/cpu/z8002/z8002.sv:4309 ---- SLLB/SRLB rbd,#imm8: byte version of the existing word S_SHIFT, imm8 = LOW byte of the fetched word (MAME GET_IMM8 truncates get_operand() to uint8_t). rtl/custom/adc0804.sv:11 conversion_done(): m_result = m_vin_callback(); set_interrupt(true); (the analog input is sampled AT completion, NOT at the start-conversion write) read(offset): set_interrupt(false); return m_result; (RD_STROBED mode — the default; polepo rtl/custom/adc0804.sv:20 Instantiation (src/mame/namco/polepos.cpp): ADC0804(config, m_adc, MASTER_CLOCK/8/8); MASTER_CLOCK=24.576MHz -> 384 kHz m_adc->vin_callback().set(FUNC(polepos_state::analog_r)); z80_io: map(0x00,0x00).rw(m_adc, read, write); IN A,($00)=r rtl/custom/adc0804.sv:25 Channel select (LS259 q3, MAME polepos.h/.cpp — VERIFIED, an earlier comment elsewhere in this codebase had this backwards): m_analog_io(this, {"BRAKE", "ACCEL"}) // index 0 = BRAKE, index 1 = ACCEL analog_r() { return m_analog_io[m_adc_ rtl/custom/adc0804.sv:34 Pedal range: MAME PORT_MINMAX(0, 0x90) — full scale is 0x90, NOT 0xFF. rtl/custom/adc0804.sv:53 ---- 384 kHz tick generator: clk_sys/128 clock-enable --------------------- 49.152 MHz / 128 = 384 kHz = MAME's ADC0804(config, m_adc, MASTER_CLOCK/8/8) with MASTER_CLOCK = 24.576 MHz (= clk_sys/2). rtl/custom/adc0804.sv:65 MAME adc0804.cpp s_conversion_cycles rtl/custom/adc0804.sv:70 mirrors MAME's m_intr_active (1 = INTR asserted/active) rtl/custom/adc0804.sv:82 conversion_start(): ignored while a conversion is already in progress (MAME: `if (!m_timer->enabled())`). … 127 more Says it matches, follows or was checked against MAME — 54 Arcade-PolePosition.sv:265 Powers up 0 = Lo (matches MAME's PORT_TOGGLE off state -> in0_byte bit1 reads 1, inactive on the active-low IN0). Arcade-PolePosition.sv:382 status[2]=0 (default) -> watchdog ON, matching MAME; status[2]=1 -> OFF. rtl/PolePosition_CPU.sv:7 Ground truth: MAME polepos.cpp z80_map / z80_io / machine_config (LS259 @8E). rtl/PolePosition_CPU.sv:40 (verified: MAME polepos.h m_analog_io{"BRAKE","ACCEL"} indexed by gasel via analog_r()/gasel_w()) rtl/PolePosition_subcpu.sv:4 Ground truth: MAME polepos.cpp (z8002_map / z8002_map_1/2) + polepos_v.cpp (sprite_r/w, road_r/w, alpha_r/w, view_r/w — Z80 byte-lane handlers). rtl/PolePosition_subcpu.sv:406 // Basis: pp_road_gen is bit-exact vs MAME draw_road() on the REAL road ROM // (32,768 px, 0 mismatches, verilator/road `make view`), so the renderer is // already exonerated in sim -- this confirms it on hardware. rtl/PolePosition_subcpu.sv:416 // VALIDATED 2026-08-10 by verilator/road `make view`: these exact two values // render a correct road (green grass, grey surface, red/white rumble stripes // converging to a vanishing point) identical to the MAME draw_road oracle. rtl/cpu/mb88_sv/mb88_core.sv:75 PC of the executing instruction (matches MAME) rtl/cpu/mb88_sv/mb88_core.sv:221 executing instruction's own PC (matches MAME) rtl/cpu/mb88_sv/mb88_core.sv:305 jmp within page (INCPC-then-override, matches MAME) rtl/cpu/z8002/z8002.sv:35 PP ties vi_n inactive (matches MAME: subs take NVI ONLY, asserted at vblank scanline 240). rtl/cpu/z8002/z8002.sv:50 Baked-in (verified vs MAME): BIG-ENDIAN (word@A={mem[A]hi,mem[A+1]lo}); PC even; SP=R15; 16x16 regfile, byte reg n -> R[n&7] HIGH if n<8 else LOW; FCW C=b7 Z=b6 S=b5 P/V=b4 DA=b3 H=b2 ; reset reads FCW@mem[2], PC@mem[4]. rtl/cpu/z8002/z8002.sv:97 DIV/DIVL use Verilog's native signed `/`/`%` (truncate-toward-zero, remainder takes the dividend's sign) which is algebraically IDENTICAL to MAME's manual abs/sign-restore dance in DIVW/DIVL -- verified term-by-term, not assumed. rtl/cpu/z8002/z8002.sv:314 against exactly 0, NOT run through cc_true() -- matches MAME's literal `if (cc == 0) m_pc -= 4;`) rtl/cpu/z8002/z8002.sv:627 ---- BATCH 18: LDPS real functional sequence (0x39 @rs / 0x79 addr[(rs)]) -- shared RDFCW/RDPC tail (fcw=mem[ea], pc=mem[ea+2], matches both MAME bodies exactly once `ea` is set correctly per sub-form: 0x39 sets it directly from a register, rtl/cpu/z8002/z8002.sv:675 OUT direction (io_sub[1]==1) writes to a PORT, which (matching MAME's WRPORT_B replicate+byte-enable-mask, no RMW) just replicates the byte into both halves, same as the standalone S_OUTB_GO built in Batch 18. rtl/cpu/z8002/z8002.sv:691 NVI push / IRET pop addresses: SP=R[15]; pushes pre-decrement (addr=R15-2, and R15 itself is updated -=2 on the same edge), pops read at current R15 then post-increment (matches MAME PUSHW/POPW exactly). rtl/cpu/z8002/z8002.sv:1021 ---- BATCH 17: trap accept push order (PC, then OLD fcw, then the trapping opcode word) -- matches MAME's PUSH_PC()/PUSHW(SP,fcw)/ PUSHW(SP,m_op[0]) sequence exactly (see S_TRAP_ state comments). rtl/cpu/z8002/z8002.sv:1027 ---- BATCH 18: OUTB/OUT -- matches MAME's WRPORT_B(value16=value\| (value<<8)) / WRPORT_W(value) exactly: byte form replicates the byte into both halves (the address-derived lane/lane-mask on the other end of the bus picks the real one, same rtl/cpu/z8002/z8002.sv:1091 Magnitude division + sign restore reproduces Verilog's signed `/`,`%` semantics exactly (truncate toward zero; remainder takes the DIVIDEND's sign) -- which the old code's header already established is algebraically identical to MAME's DIVW rtl/cpu/z8002/z8002.sv:1444 Implemented CONSERVATIVELY matching MAME's LITERAL dispatch only (src fixed at reg-code 1, dst/idxr=1..E) rather than guessing the broader "any src, any dst" interpretation -- flagged in report for the user's call. rtl/cpu/z8002/z8002.sv:1529 ==== BATCH 18: MSET/MRES/MBIT (0x7B08/09/0A, exact match) : MAME Z7B_0000_1000/1001/1010 -- CHECK_PRIVILEGED_INSTR gated (traps to VEC_TRAP unless fcw[14]/F_S_N set). rtl/cpu/z8002/z8002.sv:1560 ==== BATCH 18: HALT (0x7A00, exact match) : MAME Z7A_0000_0000. rtl/cpu/z8002/z8002.sv:1618 F_EPU (fcw bit13) is never set anywhere in this core (no Z8001 EPU exists on this board) UNLESS a real ROM explicitly writes it via LDCTL FCW,Rn (a plain whole-fcw overwrite, already implemented) -- so this reads the LIVE fcw bit, matching rtl/cpu/z8002/z8002.sv:2274 bit = 1<<NIB3 (NIB3 8-15 => bmask[7:0]==0, byte test naturally always-false, matching MAME's own uint8_t&uint16_t promotion). rtl/cpu/z8002/z8002.sv:3304 All are UNREACHABLE by the Pole Position sub ROMs (co-sim runs both to completion, 0 illegal): 0x30-0x37 load-relative / base+displacement (LDR/LDRB/LDRL, LDB base+disp) 0x38-0x3F I/O + block I/O (IN/OUT/SIN/SOUT/INIR/OTIR...) - no I/O de rtl/cpu/z8002/z8002.sv:3607 ---- Z34 direct: LDAR prd,dsp16 -- register-ONLY (no memory read of the target at all, matches MAME's addr_to_reg): single-cycle, computes the PC- relative address and writes it straight to R[dst]. rtl/cpu/z8002/z8002.sv:3643 BATCH 16 fix: when taken and jpx, add R[idxr] to the fetched addr (matches MAME's addr_add(addr,RW(dst)) BEFORE the cc test -- the addend is added whether or not cc is ultimately true, but since it's only ever CONSUMED on the taken path, co rtl/cpu/z8002/z8002.sv:3647 Not-taken path is unaffected by indexing either way (matches MAME: the switch does nothing on !cc, leaving m_pc at its already-advanced-past-both-words value = our pc+2). rtl/cpu/z8002/z8002.sv:3656 ---- BATCH 17: internal-trap accept sequence (EPU/TRAP/SYSCALL) -- push PC, push OLD fcw, push the trapping opcode word (`ir`, matches MAME's m_op[0]), then load new FCW/PC from PSAP+trap_vec/+trap_vec+2. rtl/cpu/z8002/z8002.sv:3905 Read-then-write ordering (not read-both-then-write-both) matches MAME's own evaluation order for PUSHL(dst,RDIR_L(src)) since RDIR_L has no side effect on `src`, so any read/write region overlap resolves identically either way ---- rtl/cpu/z8002/z8002.sv:4082 Verilog signed `/`/`%` truncate toward zero with the remainder taking the dividend's sign -- algebraically IDENTICAL to MAME's manual abs/sign-restore dance in DIVW (verified term-by-term against z8000ops.hxx, see header). rtl/custom/adc0804.sv:5 Ground truth: MAME src/devices/machine/adc0804.cpp/.h. adc0804_device::s_conversion_cycles = 74 (device clock ticks per conversion) write(offset,data): set_interrupt(false); conversion_start(); conversion_start(): only (re)starts the conv rtl/custom/adc0804.sv:36 Fabric clock: clk_sys = CLK_49M = 49.152 MHz = 2x MASTER_CLOCK, so the 384 kHz ADC clock here = clk_sys / 128 (49.152MHz/128 = 384kHz, matching MAME's MASTER_CLOCK/8/8 exactly since MASTER_CLOCK = clk_sys/2). rtl/custom/pp_road_gen.sv:230 XOFFS-BAR-DIAG-2026-08-10 ------------------------------------------------ The road renderer is PROVEN correct (bit-exact vs MAME draw_road on the real road ROM, verilator/road `make view`), and the ioctl ROM offsets are proven correct. rtl/custom/pp_sprite_gen.sv:194 WHY NOT HERE YET: this engine is currently VERIFIED CORRECT against the MAME zoom_sprite/draw_sprites oracle (sprite co-sim: 0 / 57,344 px). rtl/namco/namco_06xx.sv:4 Ground truth: MAME src/devices/machine/namco06.cpp (namco_06xx_device). rtl/namco/namco_06xx.sv:7 Only chip0/chip1 are wired to real wrappers in this increment; chip2/chip3 read as 0xFF (matches MAME's devcb_read8 default) and have no write sink. rtl/namco/namco_51xx.sv:4 Ground truth: MAME src/devices/machine/namco51.cpp (namco_51xx_device) + src/mame/namco/polepos.cpp machine_config (:887-893, :914-917). rtl/namco/namco_51xx.sv:28 mb88_core's `o_out` register only models the MCU's own half of this; the external Z80-write half is modeled here as `mailbox`, which mirrors o_out whenever the MCU changes it, but a CPU write (wr_en) takes priority and temporarily overrides rtl/namco/namco_51xx.sv:78 Now driven by mb88's real o_wr strobe, matching MAME exactly. rtl/namco/namco_51xx.sv:99 Z80 write wins (matches MAME order) rtl/namco/namco_52xx.sv:24 reset = LS259 q1 (namco_reset, shared with 51/53/54xx) chip_sel = 06xx chipsel[2] -> IRQ Like 54xx: namco52.cpp has NO read() method and polepos.cpp binds no read_callback<2> -- the Z80 never reads this chip back through 06xx, so (a) no rtl/namco/namco_53xx.sv:4 Ground truth: MAME src/devices/machine/namco53.cpp (namco_53xx_device) + src/mame/namco/polepos.cpp machine_config (:901-906, :918-919) + the polepos_state steering helpers (polepos.cpp :362-389, steering_changed_r / steering_delta_r — thes rtl/namco/namco_54xx.sv:10 polepos machine_config port wiring (namco54.cpp): K3:0 = command[7:4] (K_r() = m_latched_cmd >> 4) R0 = command[3:0] (R0_r() = m_latched_cmd & 0x0f) O-port = discrete circuit inputs NAMCO_54XX_0_DATA (ol, O0-O3) / NAMCO_54XX_1 rtl/namco/namco_wsg8.sv:5 Ground truth: MAME src/devices/sound/namco.cpp (namco_device::polepos_sound_r/w + namco_audio_device::{device_clock_changed,build_decoded_waveform, namco_update_one,sound_stream_update}). rtl/namco/namco_wsg8.sv:42 volume[0] = (soundregs[base+3]>>4 + soundregs[base+0x23]>>4) / 2 volume[1] = (soundregs[base+3]&0xf + soundregs[base+2]>>4) / 2 (all other byte offsets in 0x00-0x3F are dead register-file bytes on real hardware: stored, but polepos_sound_w' rtl/namco/namco_wsg8.sv:67 Running our own accumulator once per REAL 48kHz tick instead (matching the actual namco clock) and shifting the read window down by the same factor (17-2=15) yields IDENTICAL pitch: MAME: Hz = freq * 192000 / 2^22 (fracbits=17, +5-bit fi rtl/namco/namco_wsg8.sv:100 - channels 0/1 are expected to read as silent/near-silent in normal play (their ch4+0x23 ext-select bit routes them to 54xx/52xx instead, which are NOT built this pass) — that matches MAME's own comment, not a bug. rtl/poleposition.vhd:578 Feeds ONLY u_pp_cpu (Z80 + both Z8002s), matching MAME's watchdog_fired()->schedule_soft_reset(). rtl/poleposition.vhd:619 The CPU divider WAS re-derived for the new clock (cen = clk/16 = 3.072 MHz, matching MAME's Z80 MASTER_CLOCK/8), which is why boot speed matches MAME while everything downstream of the first EI breaks. rtl/poleposition.vhd:947 52xx and 54xx (both built 2026-07-28) legitimately have NO read_callback<2>/<3> bound in polepos.cpp -- namco52.cpp/namco54.cpp have no read() method at all -- so chip2_din/chip3_din staying tied to this 0xFF stub is CORRECT and permanent, rtl/video/pp_palette_alpha.sv:19 128V banks 0x020+/0x060+ are physically IDENTICAL colours on real HW (MAME comment polepos_v.cpp:42-51) — we still implement the bank select for faithfulness; it is visually irrelevant, so first-light works with either. rtl/video/pp_tile_decode.sv:4 Covers BOTH tilemap layers — alpha ("chars") and view ("tiles") — because they use the IDENTICAL MAME charlayout_2bpp (polepos.cpp:862-864). Says it was translated, ported or taken from MAME — 10 rtl/cpu/z8002/z8002.sv:256 ==== BATCH 8: DAB (0xB0) result ROM, ported verbatim from MAME's Useful Stuff/mame/z8000/z8000dab.h (2048 x 9-bit, mechanically extracted -- NOT hand-transcribed -- and spot-checked against the source header: idx[8..0]=0 ->9'h008, idx=9->9' rtl/cpu/z8002/z8002.sv:1537 True no-ops when privileged -- this is not a corner cut, it's what MAME's real C body does verbatim once past the privilege gate. rtl/custom/adc0804.sv:2 adc0804.sv — ADC0804 8-bit A/D converter (Pole Position accelerator/brake pedal input), faithful port of MAME's device model. rtl/custom/pp_ic25.sv:4 Based on MAME namco/polepos.cpp, polepos2_ic25_r() by the MAME team. rtl/custom/pp_road_gen.sv:4 Faithful RTL port of MAME draw_road() (polepos_v.cpp:304-373). rtl/custom/pp_sprite_gen.sv:4 Faithful RTL port of MAME draw_sprites()/zoom_sprite() (polepos_v.cpp :375-448). rtl/video/pp_palette_alpha.sv:4 Ports MAME's polepos_palette() index arithmetic verbatim (polepos_v.cpp :30-135) for the alpha layer, per the audit's recommendation (avoid reverse-engineering the real PROM address-pin order). rtl/video/pp_palette_road.sv:4 Ports MAME's polepos_palette() index arithmetic verbatim for the road layer (polepos_v.cpp:123-126), the sibling of pp_palette_view but with a 10-bit index (the road pen is (roadpal<<6)\|roadval, not {color,pixel}): rtl/video/pp_palette_sprite.sv:4 Ports MAME's polepos_palette() sprite arithmetic verbatim (polepos_v.cpp :106-114). rtl/video/pp_palette_view.sv:4 Ports MAME's polepos_palette() index arithmetic verbatim for the bg/view layer (polepos_v.cpp:94-103), the sibling of pp_palette_alpha: Keeps a MAME approximation — 1 rtl/cpu/z8002/z8002.sv:2949 Implemented with NIB2 instead, matching every sibling and the already-fixed Z4C_0000_0000_addr COMB precedent (same MAME-source-typo category) -- flagged in report, not silently guessed past. Shares text with the MAME driver without saying so — 13 Arcade-PolePosition.sv:59 0 1 2 3 4 5 6 — shares text with namco/polepos.cpp:2311 rtl/PolePosition_CPU.sv:237 MAME ground truth: polepos.cpp:927 NVRAM(config, "nvram", nvram_device::DEFAULT_ALL_1) — shares text with namco/polepos.cpp:927 rtl/custom/pp_watchdog.sv:5 WATCHDOG_TIMER(config, "watchdog").set_vblank_count(m_screen, 16); — shares text with namco/polepos.cpp:925 rtl/custom/pp_watchdog.sv:7 map(0xa100, 0xa100).mirror(0x0cff).w("watchdog", FUNC(watchdog_timer_device::reset_w)); — shares text with namco/polepos.cpp:451 rtl/namco/namco_06xx.sv:38 simplification of MAME's attotime-based "delay to the next falling clock — shares text with namco/namco06.cpp:219 rtl/namco/namco_51xx.sv:62 MAME: m_screen->screen_vblank().set("51xx", vblank); vblank(state) drives — shares text with namco/polepos.cpp:953 rtl/namco/namco_52xx.sv:14 SI = constant 1 (namco_52xx_si_r(): "pulled to +5V") — shares text with namco/polepos.cpp:350 rtl/namco/namco_53xx.sv:14 k_port_callback = namco_53xx_k_r, HARDWIRED TO 0 in polepos.cpp (comment: — shares text with namco/polepos.cpp:356 rtl/namco/namco_wsg8.sv:18 NAMCO(config, m_namco_sound, MASTER_CLOCK/512) MASTER_CLOCK=24.576MHz — shares text with namco/polepos.cpp:964 rtl/namco/namco_wsg8.sv:21 m_latch->q_out_cb<2>().set(m_namco_sound, FUNC(namco_device::sound_enable_w)); — shares text with namco/polepos.cpp:937 rtl/poleposition.vhd:611 set_raw(MASTER_CLOCK/4, 384, 0, 256, 264, ...) with MASTER_CLOCK=24.576 MHz), — shares text with namco/polepos.cpp:950 rtl/video/pp_tile_decode.sv:54 MAME: code = (word & 0xff) \| ((word & 0x4000) >> 6) = {word[14],word[7:0]} — shares text with namco/polepos_v.cpp:148 rtl/video/pp_tile_decode.sv:72 planeoffset{0,4}, xoffset{0,1,2,3, 88+0..3}, MSB-first bit addressing — shares text with namco/polepos.cpp:826
PolyPlay# Poly-Play, Poly-Play MiSTer-devel/Arcade-PolyPlay_MiSTer @ 800350bd MAME compared: ddr/polyplay.cpp + 3 related file(s) Read: 14 HDL files, 2,320 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	8%
Statements: 2 toward MAME Cites MAME source — 2 rtl/periph/ctc_channel.vhd:163 now behaves like mame??? README.md:5 All information taken from [mame/polyplay.cpp](https://github.com/mamedev/mame/blob/master/src/mame/drivers/polyplay.cpp).
Pong# Pong MiSTer-devel/Arcade-Pong_MiSTer @ 3f7413bb MAME compared: atari/pong.cpp + 8 related file(s) Read: 45 HDL files, 3,116 lines (Quartus project)	MiSTer official	Mostly hardware	low	39%
Statements: 20 toward hardware Cites hardware documentation that MAME's driver does not — 20 rtl/ls00.v:26 74LS00 rtl/ls02.v:26 74LS02 rtl/ls04.v:26 74LS04 rtl/ls10.v:26 74LS10 rtl/ls107.v:26 74LS107 rtl/ls153.v:26 74LS153 rtl/ls20.v:26 74LS20 rtl/ls25.v:26 74LS25 rtl/ls27.v:26 74LS27 rtl/ls30.v:26 74LS30 rtl/ls48.v:26 74LS48 rtl/ls50.v:26 74LS50 rtl/ls74.v:26 74LS74 rtl/ls83.v:26 74LS83 rtl/ls86.v:26 74LS86 rtl/ls90.v:26 74LS90 rtl/ls93.v:26 74LS93 rtl/pong.v:26 Arcade: Atari Pong (1972) A Verilog implementation based on the original schematics. README.txt:3 ** A Verilog implementation based on the original schematics. README.txt:39 A: This implementation is based on the original Atari schematics.
Pooyan# Pooyan MiSTer-devel/Arcade-Pooyan_MiSTer @ 858c6fb2 MAME compared: konami/pooyan.cpp + 1 related file(s) Read: 10 HDL files, 2,711 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	54%
Statements: 3 toward MAME Cites MAME source — 3 rtl/YM2149_linmix_sep.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA rtl/pooyan.vhd:35 Use with MAME roms from pooyan.zip rtl/pooyan.vhd:319 cpu input address decoding (mirror mostly from Mame)
Popeye# Popeye, Sky Skipper MiSTer-devel/Arcade-Popeye_MiSTer @ 9226c11b MAME compared: nintendo/popeye.cpp + 4 related file(s) Read: 5 HDL files, 2,645 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	79%
Statements: 1 toward hardware, 4 toward MAME, 4 not counted Cites hardware documentation that MAME's driver does not — 1 rtl/popeye.vhd:51 Popeye Hardware caracteristics from schematics TPP2: Cites hardware references or measurements that MAME's driver also gives — 4 rtl/popeye.vhd:1279 char graphics ROM 5N ch_graphics : entity work.popeye_ch_bits port map( clk => clock_vidn, addr => ch_code_line, data => ch_graphx_do — also in MAME: 5N nintendo/popeye.cpp:655 rtl/popeye.vhd:1301 sprite graphics ROM 1E sprite_graphics1 : entity work.popeye_sp_bits_1 port map( clk => clock_vidn, addr => sp_code_line, data => sp_graphx1_do — also in MAME: 1E nintendo/nl_popeye.cpp:44 rtl/popeye.vhd:1326 sprite graphics ROM 1F sprite_graphics2 : entity work.popeye_sp_bits_2 port map( clk => clock_vidn, addr => sp_code_line, data => sp_graphx2_do — also in MAME: 1F nintendo/popeye.cpp:660 rtl/popeye.vhd:1346 sprite graphics ROM 1J sprite_graphics3 : entity work.popeye_sp_bits_3 port map( clk => clock_vidn, addr => sp_code_line, data => sp_graphx3_do — also in MAME: 1J nintendo/popeye.cpp:661 Cites MAME source — 3 rtl/popeye.vhd:15 release rev 01 : added protection algorithm (straight forward from MAME) (01/01/2020) : tested ok for Popeye rev D level 1 at least... rtl/popeye.vhd:45 Use with MAME roms from popeye.zip & popeyeu.zip rtl/ym_2149_linmix.vhd:44 Clues from MAME sound driver and Kazuhiro TSUJIKAWA Says it was translated, ported or taken from MAME — 1 rtl/popeye.vhd:321 Protection device (7K/7J): Algorithm is taken from MAME source code and seems to be ok for Popeye and Sky skipper.
PrimalRage# Primal Rage, T-MEK MiSTer-devel/Arcade-PrimalRage_MiSTer @ c3394c33 MAME compared: atari/atarigt.cpp + 8 related file(s) Read: 17 HDL files, 9,688 lines (Quartus project)	MiSTer official	Mostly MAME	medium	93%
Statements: 1 toward hardware, 85 toward MAME Cites hardware documentation that MAME's driver does not — 1 README.md:137 The sound board boot ROM of this prototype was never dumped; MAME uses the one from a later set (marked BAD_DUMP), and so does this core. Cites MAME source — 71 Arcade-PrimalRage.sv:731 joystick_x bits: 0 right,1 left,2 down,3 up,4..7 buttons1-4,8 coin,9 start set_jan picks the primrage (1) or primrageo (0) button/start layout; see rtl/atarigt_inputs.sv for the MAME atarigt.cpp port mapping. Arcade-PrimalRage.sv:1026 the game tells a cold boot from a watchdog reset by what it finds in work RAM, so zero it after the download like MAME does at power-up rtl/atarigt_inputs.sv:69 T-MEK (MAME atarigt.cpp common INPUT_PORTS): one seat, P1/P2 buttons 1-2 are the right/left trigger and thumb on one pad; the service test shows no button 3, button4, start2 or P2 d-pad, so those stay released rtl/atarigt_inputs.sv:78 One T-MEK board is one seat, so MAME P1/P2 are its right/left handles (service menu stick test): right = ch7/ch6 (AN3 X, AN2 Y), left = ch3/ch2 (AN1 X, AN4 Y); handle forward = low byte, so the right handle alone forward turns left rtl/atarigt_video.sv:2 Reference: MAME atarigt_v.cpp (get_playfield_tile_info, get_alpha_tile_info, playfield_scan, scanline_update, screen_update Primal Rage branch) and MAME atarigt.cpp (pflayout, pftoplayout). rtl/atarigt_video.sv:206 colorram_r in MAME returns whatever was last written at ANY word in 0x20000-0x27fff/0x30000-0x37fff, not just the 128 entries the mixer cares about. rtl/c31/c31_core.sv:2 Semantics follow MAME's 320c3x_ops.ipp instruction by instruction, not real silicon. rtl/c31/c31_core.sv:98 mod19 (bit-reversed) and 0x1A-0x1F: MAME's handlers just log and return address 0 with no AR side effect, and the access still happens, so match that rather than aborting the instruction rtl/c31/c31_core.sv:173 float helpers, matching 320c3x_ops.ipp bit for bit rtl/c31/c31_core.sv:266 AND/ANDN/NOT/OR/RPTS/TSTB/XOR take a zero-extended imm16 (MAME uint16_t), the rest sign-extend rtl/c31/c31_core.sv:2100 MAME zeroes dst in this branch but then overwrites it on the way out with the locals it never touched, so src passes through rtl/cage.sv:351 dsp_re/dsp_we come from the C31's own 0xA00000 window, decoded in cage_mem (MAME cage.cpp 0xA00000 rw) rtl/cage.sv:363 latch bit21 (MAME reset_w) stays unwired: Primal Rage drops it only once at boot, while control_reg still holds the DSP in reset rtl/cage_host.sv:1 CAGE host interface: the 68020 side registers at C00000, MAME atarigt.cpp sound_data_r/sound_data_w, and the DSP side of the handshake, MAME cage.cpp main_r/main_w/control_r/control_w/cage_from_main_r/cage_to_main_w. rtl/cage_host.sv:26 C31 interrupt lines, active-low (int_n convention): int0_n is the host command-ready IRQ0 (MAME cage.cpp cage_deferred_w/ cage_from_main_r), int1_n mirrors TMS320C3X_IRQ1, asserted whenever (control & 3) == 0 (MAME cage.cpp control_w). rtl/cage_host.sv:29 Both are levels, unlike cage_periph's TINT/DINT pulses, because MAME explicitly asserts and clears these two rather than only ever asserting them. rtl/cage_host.sv:34 IOF bits this device drives: bit3 = cpu_to_cage_ready, bit7 = cage_to_cpu_ready (MAME cage.cpp update_control_lines: val &= ~0x88). rtl/cage_host.sv:39 held while the DSP must stay in reset: control bits 0/1 both 0, or ext_reset (the 0xE08000 latch bit21 path, MAME atarigt.cpp reset_w) rtl/cage_mem.sv:3 Address map: MAME cage.cpp. rtl/cage_mem.sv:45 CAGE host latch, word address 0xA00000 (MAME cage.cpp cage_from_main_r/ cage_to_main_w): re/we are one-clock pulses, exactly one per access even if req is held rtl/cage_mem.sv:80 Only the populated part of the 0xC00000-0xFFFFFF sound ROM bank (MAME cage.cpp: "the DSP sees the pair at 0xD00000-0xDFFFFF ... rtl/cage_mem.sv:142 MAME cage set_mcbl_mode: the C31 boot ROM overlays 0x000000-0x000FFF and trap n loads its vector from word n there, which holds 0x809FC0+n rtl/cage_mem.sv:145 sound ROM and boot ROM are read-only (MAME cage.cpp 3.1): a write to either is simply dropped rather than allocating/dirtying a line rtl/cage_mem.sv:495 boot ROM direct path: uncached, byte-wide (MAME cage.cpp 3.1: one file byte per DSP word, stored packed as 512KB in DDR3) rtl/cage_periph.sv:2 Register map, timer/serial/DMA timing: MAME cage.cpp tms320c31_io_r/w, update_timer, update_serial, update_dma_state. rtl/cage_periph.sv:3 Register offsets below are the DSP's own word address within the block (periph_addr), identical to the offs_t values cage.cpp indexes m_tms320c31_io_regs with. rtl/cage_periph.sv:6 The 0x808064 primary bus control mask (0x1FFE) and reset value (0x10F8) are not in cage.cpp (MAME never touches that register); they come from an observed hardware trace. rtl/cage_periph.sv:12 held while the DSP is in reset (control bits 0/1 both 0, cage_host's dsp_hold_reset): mirrors MAME cage.cpp control_w, which zeroes offsets 0x00-0x5F of the peripheral array on this condition. rtl/cage_periph.sv:28 xint/rint are not modeled, MAME cage.cpp never asserts them for CAGE. rtl/cage_periph.sv:43 audio out, MAME cage.cpp 3.3 and atarigt.cpp atarigt_stereo routing (channels 0/3 -> right, 1/2 -> left) rtl/cage_periph.sv:75 register offsets, MAME cage.cpp macros rtl/cage_periph.sv:86 generic storage: every offset 0x00-0xFF is a plain read/write register, MAME cage.cpp COMBINE_DATA into m_tms320c31_io_regs[0x100]. rtl/cage_periph.sv:108 timers: real down-counters clocked by h1_tick (MAME's own COUNTER register, offset 0x24/0x34, is write-through storage only -- see the generic regs[] array above; this is separate internal state driving the interrupt cadence MAME models, 2* rtl/cage_periph.sv:160 serial word clock chain, MAME cage.cpp update_serial: h1_tick -> /2 or /4 serial clock -> /SPORT_TIMER_PERIOD bit clock -> /bits_per_word word clock. rtl/cage_periph.sv:162 The divider constants are latched from the register file one clock after a write to SPORT_GLOBAL_CTL/SPORT_TIMER_PERIOD, and only when the candidate rate is valid (TPER!=0, derived freq <100kHz) -- MAME cage.cpp update_serial's own dmadac g rtl/cage_periph.sv:186 Rejecting it needs sp_ctl_reg != 0 at candidate time (below) -- an earlier attempt at this fixed the audio rate but broke the host<->DSP handshake, traced to the DINT timer stop rule using live register bits instead of MAME's internal dma_e rtl/cage_periph.sv:317 H1_HZ/88200 = 192 exactly, and h1_ticks_per_word = serial_div * tper * bits_per_word by construction of the divider chain above, so comparing that count to 192 reproduces MAME's frequency check without any real division. rtl/cage_periph.sv:334 DMA, MAME cage.cpp update_dma_state/dma_timer_callback (258-331). rtl/cage_periph.sv:342 MAME cage.cpp tracks enable with its OWN m_dma_enabled flag, separate from the register bits: dma_enabled_reg mirrors that. rtl/cage_periph.sv:361 forward this cycle's write into the enable check, mirroring MAME's update_dma_state which runs after COMBINE_DATA already applied it rtl/cage_periph.sv:394 clamp derived from MAME's mixer formula (atarigt.cpp atarigt_stereo: add_route(0/3, "speaker", 1.0, right), add_route(1/2, "speaker", 1.0, left) -- two unity-gain routes summed per output, saturated to the 16-bit DAC range) rtl/cage_periph.sv:423 MAME cage.cpp update_dma_state: runs only on a write to one of the four DMA regs, comparing enabled_new to the internal flag rtl/cage_periph.sv:427 MAME cage.cpp update_dma_state starts every transfer at channel 0 rtl/cage_periph.sv:546 MAME cage.cpp control_w: memset(m_tms320c31_io_regs, 0, 0x604); 0x64 and above are outside that range and left alone clear once on the edge: a held level is a 96-way loop every clock in sim rtl/cage_periph.sv:557 MAME cage.cpp tms320c31_io_w, SPORT_DATA_TX case rtl/cage_periph.sv:562 MAME cage.cpp dma_timer_callback: DMA_SOURCE_ADDR/ DMA_TRANSFER_COUNT only change at DINT, to the final address / 0 -- never incrementally, matching what the CPU can observe (the transfer already happened up front) rtl/cage_periph.sv:577 MAME cage.cpp tms320c31_io_r assigns the array's uint32_t element into a uint16_t before returning it, truncating every read to 16 bits (zero-extended back to 32); that MAME quirk is reproduced here deliberately, on the read side only -- th rtl/cpu_bus.sv:89 MAME adc0808.cpp: 1 + 64 ADC clocks to convert, EOC 1 clock later; ADC clock = 14.318181 MHz/16 = 894.9 kHz, 66 clocks = 73.8 us, clk_cpu = 42.955 MHz -> 3168 clk_cpu ticks (research notes, adc finding) rtl/cpu_bus.sv:104 T-MEK: colour writes are dropped while set (MAME atarigt.cpp colorram_protection_w) rtl/cpu_bus.sv:106 T-MEK ADC0809 model (MAME atarigt.cpp analog_port_r): adc_q is the shared result register; clk_cpu may get no reset edge before its first use, so eoc (SERVICE bit3) derives from adc_busy instead of its own register rtl/cpu_bus.sv:150 bit 7 is the live VBLANK signal (atarigt.cpp SERVICE port), not a switch; bit 3 is A2D.EOC when tmek (MAME atarigt.cpp:472), else the switch as-is rtl/cpu_bus.sv:299 control_r has no side effect in MAME cage.cpp, only main_r does rtl/cpu_bus.sv:373 MAME latch_w: ACCESSING_BITS_24_31 (uds, MO control) and ACCESSING_BITS_16_23 (lds, cage/coin) are masked separately, so an lds-only write must not touch the MO control bits that live in the uds byte rtl/rle_objects.sv:1 Reference: MAME atarirle.cpp, modesc masks in MAME atarigt.cpp. rtl/rle_objects.sv:472 vblank frame-aligns the accumulator (mirrors MAME's m_partial_scanline reset at vblank); mogo consumes it. rtl/rle_objects.sv:586 clear the checksum BRAM first (MAME memsets m_checksums before accumulating; real BRAM power-on content is likewise undefined) rtl/rle_objects.sv:894 draw command: whole-buffer erase (simplification: MAME does a partial erase from the current scanline; a full clear is simpler and cheap enough here), then sort_and_render rtl/xga_prot.sv:14 word addresses = byte offset (atarixga.cpp PR_) >> 1 rtl/xga_prot.sv:26 T-MEK word addresses (MAME atarixga.cpp TM_* byte offsets in the D80000 window >> 1) rtl/xga_prot.sv:79 bit permutation of the query index, transcribed from atarixga.cpp rtl/xga_prot.sv:93 kmap[k]: number of LFSR clocks for key byte k, verbatim from atarixga.cpp rtl/xga_prot.sv:250 a write in DECIPHER mode (re)arms the engine and aborts any run still in progress (MAME: last write wins); busy stays high up to about 6 us at clk_cpu = 42.955 MHz rtl/xga_prot.sv:343 T-MEK: write16 returns to IDLE right on the triggering write (MAME atarixga.cpp:526-530), not deferred to the RESULT read; a later write here would otherwise be misread as a second query rtl/xga_prot.sv:390 restart from the SETUP start state (eng_x0), not the raw ciphertext: when c==0 that start state is 1, and eng_c==0 is a fixed point of the LFSR (MAME atarixga.cpp:100) README.md:46 \| MAME description \| Set \| Zip files needed \| README.md:103 XGA protection chip modelled after MAME README.md:118 The core uses the MAME sets listed under Sets, as of MAME 0.289. README.md:128 Put the zip files for the sets you want (see Sets) into `/games/mame`. README.md:137 The sound board boot ROM of this prototype was never dumped; MAME uses the one from a later set (marked BAD_DUMP), and so does this core. README.md:153 The sound DSP runs in lockstep against MAME's TMS320C31 core: a million instructions of the real CAGE program plus random instruction stress. README.md:183 FPGA core development: Nortido Hardware reference: MAME `atarigt.cpp` and `cage.cpp` (Aaron Giles and contributors), `atarixga.cpp` (Morten Shearman Kirkegaard, Says it matches, follows or was checked against MAME — 11 rtl/c31/c31_core.sv:27 for bits where iof_in_mask is set, the IOF register reads iof_in instead of its stored bit (bits 3 and 7 are driven by the CAGE host interface, matching MAME's set_state_int(TMS320C3X_IOF)); writes to IOF always go to storage, masked bits a rtl/cage_host.sv:79 dsp_re/dsp_we/host_re apply first, using this cycle's pre-update state; host_we (main_w) applies after, so a same-cycle "DSP reads the old command" + "host posts a new one" ends with the new command's ready flag set, matching MAME's machine rtl/cage_periph.sv:14 0x64 (primary bus control) is outside that range and is left alone, matching MAME. rtl/cage_periph.sv:24 interrupts to the (not yet built) C31 core: one clk_sys pulse per event, matching MAME's set_input_line() with no explicit clear for TINT0/TINT1/DINT0 -- the core's own IF register is a rising-edge latch, so a level-with-ack scheme here wou rtl/cage_periph.sv:312 matches MAME cage.cpp SPORT_DATA_TX special case: MAME compares the derived word rate to 220504 Hz (int(m_serial_period_per_word. rtl/cage_periph.sv:334 Two independent pieces, matching MAME's split between the (instant) bulk transfer and the deferred periodic timer: rtl/cage_periph.sv:338 (1) DINT timer: a free-running word-tick countdown, period = the transfer count latched at the FIRST arm after the timer was stopped (MAME cage.cpp only calls timer.adjust() when !m_dma_timer_enabled; a re-arm that lands while the timer is rtl/cage_periph.sv:507 playback: one word every word_tick, gated on the SPORT being configured (rate_valid) only -- the stream runs whether or not the DMA is on, repeating the stale/silent holding_reg when nothing is queued or the prefetch hasn't refilled yet, sa rtl/rle_objects.sv:1022 width==0 or height==0 means prescan found an invalid data offset for this object (matches MAME bailing on info.data == nullptr in draw_rle, before it ever divides by scaled_width/height) README.md:102 Full CAGE sound: TMS320C31 DSP written from scratch and checked against MAME README.md:155 A Verilator simulation runs the game ROMs through attract mode and play, and the sound output is checked against MAME's CAGE model. Shares text with the MAME driver without saying so — 3 rtl/cpu_bus.sv:132 T-MEK's palette write-enable colour word (xga_prot's TM_COLOR, word 0x18000 = byte DB0000) — shares text with atari/atarigt.cpp:359 rtl/xga_prot.sv:79 bit permutation of the query index, transcribed from atarixga.cpp — shares text with atari/atarixga.cpp:632 rtl/xga_prot.sv:165 spclords_key_offset(index): bitswap<12>(index2, 12,11,10,9,6,3,5,4,1,7,2,8) ^ 0x0b3; — shares text with atari/atarixga.cpp:86
Psikyo# Battle K-Road, Gunbird, Strikers 1945, Sengoku Ace … MiSTer-devel/Arcade-Psikyo_MiSTer @ e2f717e1 MAME compared: psikyo/psikyo.cpp + 2 related file(s) Read: 41 HDL files, 9,989 lines (Quartus project)	MiSTer official	Mostly MAME	high	64%
Statements: 4 toward hardware, 118 toward MAME Says it was checked against the original PCB — 1 rtl/cpu/maincpu.sv:232 ---- 16 MHz CPU clock enable ---- The real SH201B/KA302C board clocks the 68EC020 at 32MHz/2 = 16 MHz (MAME psikyo.cpp sngkace(), "verified on pcb"). Says it was checked on “real hardware” — 1 Psikyo.sv:519 FM timers drive music tempo -- with the IRQ disabled samuraia plays no music at all (verified by ear on hardware). Notes where it differs from MAME — 2 rtl/cpu/s1945_mcu.sv:3 The real chip is a PIC16C57, but MAME never executes it (`PIC16C57(...).set_disable()`); psikyo.cpp instead simulates the protection as ~9 bytes of state plus a command decoder (`s1945_mcu_`), and this module is a direct translation of tha rtl/psikyo_core.sv:1249 MAME's boot never executes any of the loop's addresses, so this is a fault path, not game logic. Cites MAME source — 91 Psikyo.sv:29 Input port bit layout is taken from psikyo.cpp's INPUT_PORTS: sngkace has a separate COIN port, gunbird/btlkroad fold coin/service/z80-nmi into the P1_P2 low byte instead. Psikyo.sv:70 Every Psikyo board is mono (psikyo.cpp routes both chips' ALL_OUTPUTS to a single "mono" speaker), but the OPL4's PCM channels are panned, so the OSD's Stereo Mix defaults to mono: status 0 Mono (AUDIO_MIX 3), 1 None (0), 2 25% (1), 3 50% ( Psikyo.sv:285 ce_pix: exact 1-in-12 divide of clk_sys down to 7.159091 MHz, matching psikyo_v.cpp's real 14.31818MHz/2 screen clock exactly (see pll_0002.v's header for why 85.909091/12 lands on this exactly, not approximately). Psikyo.sv:326 bit 1: samuraia/samuraiak/sngkace/sngkacea's ADPCM-A ROM needs MAME's init_sngkace() bit 6/7 swap applied at download time -- gunbird/btlkroad do not, despite sharing the same sound hardware (mod_board bit 0 alone can't distinguish them: bt Psikyo.sv:360 Confirmed against psikyo.cpp's sngkace_input_r()/INPUT_PORTS_START (docs/ROADMAP.md's own "Progress" cites the exact fetch), not assumed: P1P2 is a 32-bit port with P2 in bits 23:16 and P1 in bits 31:24 (each laid out UP,DOWN,RIGHT,LEFT,B1, Psikyo.sv:371 The LOW half differs: sngkace leaves it unused and puts coin/service/z80-nmi in the separate COIN port at $C00008, while gunbird/btlkroad have no COIN port and fold those same bits into this port's low byte instead (psikyo.cpp INPUT_PORTS): Psikyo.sv:377 Bits 15:8 are where Battle K-Road's buttons 4-6 live -- it is a 6-button fighter sharing gunbird's board and memory map, and MAME's btlkroad PORT_MODIFY("P1_P2") puts them in this port's HIGH byte (checked against psikyo.cpp, not assumed): Psikyo.sv:429 MAME's psikyo DSW port (psikyo.cpp, PORT_START("DSW") / c00004 -> c00007 /) puts every DIP in the UPPER half of that long and leaves the lower half unused: PORT_BIT( 0x0000ffff, IP_ACTIVE_LOW, IPT_UNUSED ) 0x00010000 Flip Screen 0x00 Psikyo.sv:483 Freeze the 68020 so a frame can be captured and compared against a MAME dump of the same moment. Psikyo.sv:518 MAME wires ymsnd.irq_handler() to the audiocpu. Psikyo.sv:529 MAME's memory map calls the sprites "buffered by two frames (list buffered + fb buffered)": the list buffer is spriteram_dbuf's snapshot, and this is the fb half. Psikyo.sv:596 COIN port (sngkace-only): COIN1 = bit16, COIN2 = bit17, both IP_ACTIVE_LOW; bit23 is MAME's z80_nmi_r() (IP_ACTIVE_HIGH, not inverted) -- rtl/psikyo_top.sv's own nmi_pending output mirrors that exact status (see rtl/sound/sound_cpu_sngkace. Psikyo.sv:605 In MAME the equivalent read returns 0 almost immediately (the poll loop exits after a handful of iterations), so a constant 0 is the MAME-matching behaviour and costs no waiting. Psikyo.sv:609 vblank_wait_en (OSD bit 53) selects: 0 = constant 0 (MAME-like, default), 1 = ~vblank (the previous behaviour). Psikyo.sv:619 which MAME executes too, but MAME's falls through to 00044A and then copies 0x800 longs from $fffee000 to $400000 -- a sprite-RAM DMA, which is exactly the thing you time to vertical blanking. Psikyo.sv:624 Inferred from the code's behaviour and MAME's execution path rather than read out of psikyo.cpp's INPUT_PORTS (not available locally), so treat the exact bit position as verified-by-experiment, not by source. rtl/cpu/maincpu.sv:57 Requesting level 4 (Psikyo's vblank IRQ, `irq4_line_hold` in MAME) means driving IPL=3'b011 (NOT 3'b100). rtl/cpu/maincpu.sv:193 Gates the 16 MHz clock enable, so the 68020 simply stops stepping; video timing and the debug overlay keep running, which is what makes a frame comparable against a MAME dump. rtl/cpu/maincpu.sv:232 ---- 16 MHz CPU clock enable ---- The real SH201B/KA302C board clocks the 68EC020 at 32MHz/2 = 16 MHz (MAME psikyo.cpp sngkace(), "verified on pcb"). rtl/cpu/maincpu.sv:311 psikyo.cpp maps 0xc00000-0xc0000b to the input reader for sngkace and gunbird alike -- three longs: P1_P2, DSW, COIN. rtl/cpu/maincpu.sv:326 An exact compare only fires for a move.b addressed at 0xC00013 itself; a move.w to 0xC00012 or a move.l to 0xC00010 (whose second word beat is 0xC00012 with the command byte on the low lane -- byte-lane dispatch MAME's address map performs rtl/cpu/maincpu.sv:410 ---- read mux (BRAM + input ports; ROM comes via rom_data) ---- SH404 overrides (each replaces only the bits MAME's s1945 handlers own -- docs/phase2_sh404.md "Bit polarity" for why every bit here is deliberate): - P1_P2 low word bit 2: the rtl/cpu/maincpu.sv:521 SH404 MCU register writes, byte-lane addressed exactly like MAME's byte handlers: a word write to 0xC00006 hits data (UDS) and bctrl (LDS) in the same cycle, each from its own lane. rtl/cpu/s1945_mcu.sv:13 The index is 8-bit into a zero-filled 256-byte array, exactly like MAME's `static const u8 table[256]` with 44 initializers -- unwritten entries read 0. rtl/cpu/s1945_mcu.sv:39 MAME sets the latching bit AFTER returning the data ("the read consumes it"). rtl/cpu/s1945_mcu.sv:58 ---- state (reset values = MAME machine_start init) ---- rtl/cpu/s1945_mcu.sv:103 MAME: switch (data \| (direction ? rtl/cpu/s1945_mcu.sv:126 unhandled commands are ignored, as in MAME rtl/memory/gfxrom_byte_reorder.sv:13 This module is the seam between two self-consistent but OPPOSITE byte-order conventions: sdram.sv's is ordinary ascending-address-ascending-bit-position, matching standard little-endian ROM/CPU word semantics (and correct as-is for rtl/memo rtl/memory/gfxrom_byte_reorder.sv:20 Neither side is wrong on its own, so the reorder belongs here, not in sdram.sv (correct for general ROM access) or in tilemap_line_engine.sv/sprite_render_engine.sv (correct against MAME's real tile format, and independently unit-tested tha rtl/memory/psikyo_sdram_top.sv:123 SH201B (samuraia/sngkace) has no separate delta-T ROM -- MAME's YM2610 serves the deltat channel from the adpcma image, so the caller keeps bit 20 low and the samuraia/sngkace bit 6/7 download swap covers B automatically. rtl/memory/rom_loader.sv:76 Per BYTE, and only inside the 1MB ADPCM-A window -- a ROM-mastering artifact of the individual sample bytes (MAME's init_sngkace). rtl/psikyo_core.sv:17 ---- Sprite pipeline per-frame sequencing (the one genuinely new piece of control logic this module adds, not just wiring) ---- Per-scanline sprites, sequenced to psikyo_v.cpp's screen_vblank(): at frame_start, sprite_line_list rebuilds its rtl/psikyo_core.sv:121 Freeze the main CPU, so a frame can be captured and compared against a MAME dump of the same moment without the game advancing underneath it. rtl/psikyo_core.sv:170 ---- Flip Screen DIP (SW2:1, DSW bit 16, active low) ---- Wired straight to the video hardware: psikyo_v.cpp's flip_screen_set is "hardwired to a DSW bit", and the games do not react to it themselves -- a MAME capture of every set with the rtl/psikyo_core.sv:331 Indexing by {vcnt[3:0],hcnt[7:0]} puts all 4096 words of both layers into 32 scanlines, so one screenshot carries the complete tilemap RAM for comparison against a MAME dump. rtl/psikyo_core.sv:367 Precise on the first try when the target address+value are already known (e.g. from a MAME investigation), and immune to any timing jitter in the boot sequence, because it fires on the semantic event itself rather than a fixed offset. rtl/psikyo_core.sv:529 Reads the CPU-VISIBLE buffer (the one spriteram_dbuf's cpu_addr/cpu_rdata port serves, i.e. the SAME buffer MAME's own debugger/memory viewer shows -- not the render engine's snapshot copy) so a probed value is directly comparable to a MAME rtl/psikyo_core.sv:728 BOARD_GUNBIRD selects gunbird/btlkroad, which are exactly the Phase 1 boards with MAME's m_ka302c_banking (s1945n is the third, Phase 2). rtl/psikyo_core.sv:762 Ruled out as a MAME register-level offset: psikyo_v.cpp's video_start() calls tilemap_create with no set_scrolldx/set_scrolldy at all, and get_tile_info<Layer> applies m_vram[Layer] directly with no per-layer adjustment. rtl/psikyo_core.sv:967 ---- sprite pipeline sequencing ---- MAME's screen_vblank() (psikyo_v.cpp) runs get_sprites() and THEN m_spriteram->copy(). rtl/psikyo_core.sv:969 Here: at frame_start, sprite_line_list rebuilds the compact per-line table FROM the snapshot (the get_sprites step), and build_done triggers the snapshot refresh (the copy step) -- the capture lands at the frame boundary, MAME's instant, an rtl/psikyo_core.sv:1202 backdrop_black is MAME's m_palette->black_pen() screen-clear fallback (see compositor.sv): no palette entry can stand in for it here, so it rides alongside sprite_sel and forces black at this mux. rtl/psikyo_core.sv:1206 A sprite still paints over it: MAME fills the bitmap first and draws sprites afterwards, and primask entry 0x00/0xFC/0xFE all leave bit 0 clear, so a sprite over bare backdrop wins. rtl/psikyo_top.sv:92 Mirrors MAME's psikyo_state::z80_nmi_r() -- see rtl/sound/sound_cpu.sv's own comment for the full derivation. rtl/psikyo_top.sv:335 ---- YM2610 (jt10) ---- 8 MHz on both boards: sngkace XTAL(32MHz)/4, gunbird 16MHz/2 (psikyo.cpp machine configs). rtl/psikyo_top.sv:432 Address bit 20 selects the delta-T ROM: KA302C boards (gunbird/btlkroad/s1945n) have their OWN delta-T image (u64) at +0x100000 in the sample region, while SH201B (samuraia/sngkace) has none and MAME's YM2610 serves deltat from the adpcma i rtl/video/compositor.sv:8 The screen-clear/backdrop rule follows MAME PR 16050, "psikyo.cpp: Fix background colour", which replaced screen_update()'s dead `layers_ctrl` branch (a local hardcoded to -1, so only its first arm ever ran and the clear always came from la rtl/video/compositor.sv:64 MAME's screen clear falls back to m_palette->black_pen() when neither layer offers a clear colour. rtl/video/compositor.sv:89 {0x00, 0xFC, 0xFE, 0xFF} -- table per the author of MAME's Psikyo renderer (published psikyo_v.cpp reads {0,fc,ff,ff}; fe for field 2 makes it visible over backdrop where ff never draws). rtl/video/compositor.sv:93 The mask is BIT-INDEXED by the destination priority value, exactly MAME's pdrawgfx convention: the sprite pixel is BLOCKED when primask[priority_val] is set. rtl/video/compositor.sv:134 ---- backdrop / screen clear ---- MAME PR 16050 replaced the old dead-code `layers_ctrl` chain with: rtl/video/compositor.sv:170 Confirmed 2026-09-05 by the author of PR 16050, who also wrote MAME's Psikyo renderer: 0x400 is intentional, and this core follows MAME rather than the inference above. rtl/video/sprite_display_list_walker.sv:54 It was tried -- scan for the terminator, then emit from the last entry down to 0, on the reading that psikyo_v.cpp's `while (...) { sprite_ptr--; }` puts entry 0 on top. rtl/video/sprite_line_list.sv:31 Ordering contract with spriteram_dbuf: build_done is the "get_sprites() finished with the buffer" moment -- psikyo_core triggers the snapshot refresh from it, preserving psikyo_v.cpp's get_sprites()-then-copy() generation ordering with the rtl/video/sprite_pos_transform.sv:1 Applies the position offset correction and zoom-factor transform that get_sprites() does between decoding the raw record and iterating sub-tiles (psikyo_v.cpp:235-239): rtl/video/sprite_pos_transform.sv:17 flip_screen (the DIP-controlled screen flip, psikyo_v.cpp:241-247) is not handled here: the core renders the mirrored source line and reads the line buffer right to left instead (psikyo_core.sv's flip_screen), which flips sprites and tilema rtl/video/sprite_record_decode.sv:1 Decodes one raw 8-byte spriteram attribute record (4 x 16-bit words) into its constituent fields, per get_sprites() (psikyo_v.cpp:185-235, BEFORE the zoom-transform/position-offset math those fields feed into -- see sprite_pos_transform for rtl/video/sprite_record_fetch.sv:3 Record layout (docs/phase1_memory_map.md, psikyo_v.cpp:145-183): 4 consecutive 16-bit words per sprite, base word address = sprite_index4, laid out Y/X/attr/code_lo -- matching sprite_record_decode's port names exactly so the two wire toge rtl/video/sprite_subtile_step.sv:1 Computes one 16x16 sub-tile's screen position and LUT-index code, from the get_sprites() sub-tile loop (psikyo_v.cpp, verified against the actual current source rather than re-derived by hand): rtl/video/sprite_zoom_lut.sv:1 Sprite zoom scaling lookup: raw 4-bit zoom field -> (dst_size, dx), the two quantities drawgfxzoom_core (src/emu/drawgfxt.ipp:738) needs to render one 16x16 source tile at the requested scale. rtl/video/sprite_zoom_src_index.sv:1 Per-destination-column source pixel index for the nearest-neighbor zoom-blit accumulator (gfx_element::drawgfxzoom_core, drawgfxt.ipp:738-805), collapsed to a closed form -- see docs/phase1_video_engine.md, "The actual per-tile scaling algo rtl/video/spriteram_dbuf.sv:1 Hardware-buffered sprite RAM (0x400000-0x401FFF), modelling MAME's buffered_spriteram32_device. rtl/video/spriteram_dbuf.sv:20 psikyo_v.cpp's screen_vblank does get_sprites() and THEN m_spriteram->copy() -- it builds the display list from the buffer as it stands and only then refreshes that buffer, so the list a frame renders is one buffer-generation old. rtl/video/spriteram_dbuf.sv:141 The global sprite ENABLE is deliberately LIVE (ctrl_shadow, the last CPU-written value), not the frame-latched copy -- per the author of MAME's Psikyo renderer: the bit takes effect immediately, so the caller gates the DISPLAY with it and s rtl/video/spriteram_dbuf.sv:148 The transparent-pen selects stay latched with the copy: they parameterize the RENDER pass, which consumes that snapshot -- a live pen change would tear the pass already in flight, and MAME likewise reads its sprite control word from the buf rtl/video/tile_cell_decode.sv:1 Decodes a raw 16-bit tilemap VRAM cell (named vram_cell -- "cell" is a reserved SystemVerilog keyword, part of the config/cell/liblist/use declaration syntax) into a gfx-ROM tile number and palette color-group index, per get_tile_info<Layer rtl/video/tile_row_decode.sv:1 Decodes one 16-pixel row of a 16x16x4bpp "packed_msb" tile (MAME's gfx_16x16x4_packed_msb layout, used for both the "sprites" and "tiles" gfx regions -- gfx_psikyo in psikyo.cpp) into 16 4-bit pixel/palette-nibble values. rtl/video/tile_row_decode.sv:17 - Each byte's HIGH nibble is the even (left) pixel, LOW nibble is the odd (right) pixel ("x order: hi nibble first" per generic.cpp). rtl/video/tilemap_addrgen.sv:5 See docs/phase1_video_engine.md ("Tilemap addressing") for the derivation: MAME's tile_scan<Layer> (psikyo_v.cpp) looks like a bit-interleave, but its result is always masked to the low 12 bits by the caller, and every extra term in each ca rtl/video/tilemap_line_engine.sv:198 One-PIXEL alignment bias, measured on real hardware against the MAME reference (reported by the author of MAME's Psikyo renderer): screen_x shows tilemap pixel (scroll + screen_x + 1), moving the image one pixel LEFT of the unbiased sum. rtl/video/video_timing.sv:1 Raw video timing generator for the Phase 1 screen configuration -- verified directly from psikyo.cpp's machine config, not assumed: m_screen->set_raw(14.318181_MHz_XTAL/2, 456, 0, 320, 262, 0, 224); i.e. pixel clock ~7.159MHz, htotal=456 (a rtl/video/video_timing.sv:8 MAME's set_raw() only specifies the blanking BOUNDARIES it needs for its own rasterizer -- it doesn't drive a real CRT, so it has no opinion on actual hsync/vsync PULSE width/position within those blanking windows. rtl/video/video_timing.sv:35 frame_start fires on vblank's RISING edge (vcnt going 223->224) -- matches psikyo_v.cpp's own sprite-buffer swap trigger (screen_vblank(), psikyo_v.cpp:667-675, already noted in docs/phase1_memory_map.md), so this is the natural place for a rtl/video/vreg_decode.sv:20 Board-specific tile gfx banking -- MAME psikyo_v.cpp's m_ka302c_banking. rtl/video/vreg_decode.sv:24 1 (gunbird/btlkroad, and s1945n in Phase 2): LIVE banking, each layer's bank taken from its own layer-control bit 10 (psikyo_v.cpp:477, `(layer_ctrl[layer] & 0x400) >> 10`). rtl/video/vreg_decode.sv:28 Fixed banks assigned once at video_start -- layer 0 = bank 0, layer 1 = bank 1 (psikyo_v.cpp:135-136, "sngkace / samuraia don't use banking" / "They share gfx2 to save memory on other boards"). rtl/video/vreg_decode.sv:90 SH404 banking (s1945/tengai, wins over ka302c_banking): the security MCU's bctrl register drives both banks, full 2-bit -- layer 0 from bctrl[5:4], layer 1 from bctrl[7:6] (psikyo.cpp s1945_mcu_bctrl_w: switch_bgbanks(1, data>>6&3); switch_ rtl/video/vreg_decode.sv:144 ENABLE IS ACTIVE LOW: psikyo_v.cpp does m_tilemap[layer]->enable(~layer_ctrl[layer] & 1); Reading it active-high held both layers off for every value the game writes, so the compositor painted backdrop on every pixel and only sprites appear rtl/video/vreg_decode.sv:153 Bit 2 is "?" in psikyo_v.cpp's own bit table, but the screen-clear rewrite in MAME PR 16050 ("psikyo.cpp: Fix background colour") gives it a job: bits 3 and 2 are a symmetric pair of "this pen is NOT the transparent one" flags, and whicheve rtl/video/vreg_decode.sv:164 Row-scroll is active when EITHER control bit is set -- psikyo_v.cpp gates on `layer_ctrl[layer] & 0x0300`, with bit 9 selecting per-tile granularity (`tile_rowscroll = (layer_ctrl & 0x0200) >> 7`, i.e. index >> 4) rather than acting as a se README.md:31 Refs: https://buffis.com/research/input-lag-in-psikyo-games-in-mame/ README.md:122 Put the MAME merged, or split roms in games/mame README.md:134 SH404 audio: from-scratch YMF278B (OPL4) core (`rtl/sound/opl4/`, built against MAME's ymfm reference - see `docs/phase2_ymf278b.md`): full bus protocol, ch README.md:151 Some improvements to priorities and background clear over MAME (which has regressed over the years) README.md:176 It's a platform I'm familiar with, as I collaborated with other members of the MAME team on the video system to add the later games circa ~2002, and the video s README.md:191 This has NOT been verified against a PCB other than the timing measurements back in the day and recorded in the MAME source. README.md:202 Development was heavily AI-assisted, combined with experience of the platform from the original MAME emulation that I assisted with many years ago. README.md:202 It has been validated against MAME, and it's various hardware tests including timings, MAMETesters reports etc. README.md:206 Manual testing on a real DE10-nano — every supported game is played and A/B-compared against MAME on real hardware before release; the debugging instrumenta README.md:219 The MAMEdev team (especially Olivier Galibert, R. Belmont and Luca Elia as well as my own work) for [MAME](https://github.com/mamedev/mame)'s `psikyo.cpp`/ Says it matches, follows or was checked against MAME — 14 Psikyo.sv:449 dsw_in[15:8] genuinely is unused and reads as 1s, matching MAME's IP_ACTIVE_LOW default. Psikyo.sv:525 See the coin_in comment: 0 = constant 0 (matches MAME), 1 = ~vblank. rtl/cpu/maincpu.sv:17 Main CPU subsystem for the SH201B/KA302C boards (68EC020 @16MHz, psikyo.cpp:254-266 base map + per-board overlay, re-verified against current MAME source): TG68K.C + address decode + BRAM-region ports + sound-latch write + held-autovectored rtl/cpu/maincpu.sv:534 Match MAME's irq4_line_hold: assert on the RISING edge, hold until acknowledged, and let the acknowledge win. rtl/cpu/s1945_mcu.sv:17 table_absent (tengai) is not the same as an all-zero table: MAME's command 0x013 leaves latch1 UNCHANGED when the table pointer is null, rather than loading a zero. rtl/memory/gfxrom_byte_reorder.sv:1 Reorders a 64-bit SDRAM read granule (native ascending-address -> ascending-bit-position packing, as produced by rtl/memory/sdram/ sdram.sv's burst-4 read capture -- see that module's own STATE_READ0..STATE_READ3 comments, and confirmed dir rtl/memory/psikyo_sdram_top.sv:55 samuraia/samuraiak/sngkace/sngkacea ONLY (not gunbird/btlkroad, despite identical sound hardware) -- MAME's init_sngkace() applies out[7]=in[6], out[6]=in[7] to the whole ymsnd:adpcma ROM region, a real ROM-mastering artifact that can't be rtl/video/sprite_display_list_walker.sv:1 Walks the sprite display list (psikyo_v.cpp get_sprites(), re-verified against current MAME source, see docs/phase1_memory_map.md): rtl/video/sprite_display_list_walker.sv:73 sram_data % 768, full 16-bit range (matches MAME's `sprite %= 0x300` applied directly to the raw 16-bit display-list word, no prior masking -- see this module's header). rtl/video/spriteram_dbuf.sv:23 WHEN copy_start fires is the pipeline's capture instant and is owned by psikyo_core's sequencing (it depends on the swap policy -- see the spr_copy_start comment there): under the FrameStart policy it fires at the frame boundary, matching M rtl/video/tile_row_decode.sv:6 Format, verified against MAME's actual decode algorithm (src/emu/drawgfx.cpp: gfx_element::decode()/readbit()), NOT just the gfx_layout struct's field values at face value -- a first pass at reading the struct alone (planeoffset={0,1,2,3}) rtl/video/vreg_decode.sv:148 Reset value 0 therefore means ENABLED, matching MAME, whose m_vregs also powers up zeroed. README.md:37 MRAs: `<rotation>vertical (ccw)</rotation>` for all vertical sets, matching MAME README.md:205 Behavior is checked against MAME's `psikyo.cpp`/`psikyo_v.cpp` as the reference, including regression tests written for every hardware-found bug. Keeps a MAME approximation — 1 rtl/cpu/s1945_mcu.sv:41 - rd_status_toggle: the word at 0xC00002 was read; the free- running status bit flips (MAME's own "hack" -- POST spins on it going both ways). Shares text with the MAME driver without saying so — 12 Psikyo.sv:530 memory map calls the sprites "buffered by two frames (list buffered + fb — shares text with psikyo/psikyo.cpp:257 rtl/video/compositor.sv:138 for (int layer = 0; layer < 2; layer++) — shares text with psikyo/psikyo_v.cpp:119 rtl/video/sprite_display_list_walker.sv:4 for (offs = 0; offs < (0x800-2)/2; offs++) { // 1023 entries max — shares text with psikyo/psikyo_v.cpp:201 rtl/video/sprite_subtile_step.sv:6 if (flipx) { xstart = nx-1; xend = -1; xinc = -1; } else { xstart = 0; xend = nx; xinc = +1; } — shares text with psikyo/psikyo_v.cpp:250 rtl/video/sprite_subtile_step.sv:8 if (flipy) { ystart = ny-1; yend = -1; yinc = -1; } else { ystart = 0; yend = ny; yinc = +1; } — shares text with psikyo/psikyo_v.cpp:254 rtl/video/sprite_subtile_step.sv:9 for (dy = ystart; dy != yend; dy += yinc) — shares text with psikyo/psikyo_v.cpp:257 rtl/video/sprite_subtile_step.sv:10 for (dx = xstart; dx != xend; dx += xinc) { — shares text with psikyo/psikyo_v.cpp:259 rtl/video/video_timing.sv:3 m_screen->set_raw(14.318181_MHz_XTAL/2, 456, 0, 320, 262, 0, 224); — shares text with psikyo/psikyo.cpp:1131 rtl/video/vreg_decode.sv:30 (psikyo_v.cpp:135-136, "sngkace / samuraia don't use banking" — shares text with psikyo/psikyo_v.cpp:135 rtl/video/vreg_decode.sv:31 "They share gfx2 to save memory on other boards"). get_tile_info — shares text with psikyo/psikyo_v.cpp:136 rtl/video/vreg_decode.sv:93 switch_bgbanks(1, data>>6&3); switch_bgbanks(0, data>>4&3)). Tengai's — shares text with psikyo/psikyo.cpp:157 rtl/video/vreg_decode.sv:145 m_tilemap[layer]->enable(~layer_ctrl[layer] & 1); — shares text with psikyo/psikyo_v.cpp:487
PsikyoSH2# The Fallen Angels / Daraku Tenshi: The Fallen Angels, Dragon Blaze, Gunbarich, Gunbird 2 … MiSTer-devel/Arcade-PsikyoSH2_MiSTer @ 35a135b0 MAME compared: psikyo/psikyo4.cpp, psikyo/psikyosh.cpp + 4 related file(s) Read: 34 HDL files, 15,961 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	27%
Statements: 1 toward hardware, 2 toward MAME Ships hardware documentation files — 1 hw/PS5 schematic .pdf Cites MAME source — 2 rtl/PSH2/YMF278B.sv:1 license:BSD-3-Clause (PCM engine derived from MAME's ymf278b) rtl/PSH2/YMF278B_pkg.sv:1 license:BSD-3-Clause (PCM engine derived from MAME's ymf278b)
Psychic5# Psychic 5 MiSTer-devel/Arcade-Psychic5_MiSTer @ 22dcd342 MAME compared: jaleco/psychic5.cpp + 2 related file(s) Read: 29 HDL files, 7,843 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	35%
Statements: 9 toward hardware, 4 toward MAME, 3 not counted Cites hardware documentation that MAME's driver does not — 9 rtl/Psychic5_cpuboard/Psychic5_obj.v:579 LS273 8N rtl/Psychic5_videoboard/Psychic5_video.v:289 LS74 7H rtl/Psychic5_videoboard/Psychic5_video.v:309 LS74 7H rtl/Psychic5_videoboard/Psychic5_video.v:330 LS74 8E rtl/Psychic5_videoboard/Psychic5_video.v:351 LS74 8E rtl/Psychic5_videoboard/Psychic5_video.v:372 LS74 7E rtl/Psychic5_videoboard/Psychic5_video.v:392 LS74 7E rtl/Psychic5_videoboard/Psychic5_video.v:422 LS175 8F rtl/Psychic5_videoboard/Psychic5_video.v:656 LS273 6B Cites hardware references or measurements that MAME's driver also gives — 3 rtl/Psychic5_cpuboard/Psychic5_obj.v:448 sequencer ROM MB7122E = 82S137 — also in MAME: 82S137 jaleco/psychic5.cpp:1352 rtl/Psychic5_emu.v:222 0x0007_0000 0x0000_0400 3t my09.3t 82S137 BRAM sprite engine sequencer(MB7122) — also in MAME: 3t jaleco/psychic5.cpp:1298, 82S137 jaleco/psychic5.cpp:1352 rtl/Psychic5_emu.v:223 0x0007_0400 0x0000_0200 7l my10.7l 82S131 BRAM grayscale LUT — also in MAME: 7l jaleco/psychic5.cpp:1297, 82S131 jaleco/psychic5.cpp:1421 Cites MAME source — 2 rtl/Psychic5_emu.v:211 start addr length comp num mame rom parts num location description rtl/Psychic5_emu.v:226 Note 1: MAME states JP uses a 256k ROM, but I verified that an original PCB that holds JP release also used a 512k ROM instead of the 256k one. Shares text with the MAME driver without saying so — 2 rtl/Psychic5_cpuboard/Psychic5_obj.v:258 (4) X7 X6 X5 X4 X3 X2 X1 X0 b 4T — shares text with jaleco/psychic5.cpp:300 rtl/Psychic5_videoboard/Psychic5_video.v:506 *Psychic 5 is a vertical screen game, so vertical scrolling effect that appears during play is actually horizontal scroll. -----------> CRT scanline d — shares text with jaleco/psychic5.cpp
QBert# Mad Planets, Qbert, Qbert's Qubes, Reactor … MiSTer-devel/Arcade-QBert_MiSTer @ 2a19606a MAME compared: gottlieb/gottlieb.cpp Read: 42 HDL files, 15,811 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	14%
Statements: 4 toward MAME Cites MAME source — 3 Arcade-QBert.sv:451 test button (active-high per MAME IN1 bit0 IP_ACTIVE_HIGH): fire/"Service Select" rtl/mylstar_board.v:214 Reactor: MAME documents mirror(0x0ff8) for all I/O ports, meaning addr[3] is a don't-care in the original hardware decoder. rtl/sc01a/sc01a.vhd:12 Key differences from MAME reference: - All arithmetic in s(2.15) fixed-point (no floating point) - Filter coefficients pre-computed as static ROM tables - IIR filters implemented as sequential state machines - Clock enables (sclock_en, cclo Says it was translated, ported or taken from MAME — 1 rtl/sc01a/sc01a.vhd:9 Based on the Votrax SC01-A simulation from MAME Copyright (c) Olivier Galibert
Qix# Complex X, The Electric Yo-Yo, Kram, Qix … MiSTer-devel/Arcade-Qix_MiSTer @ cd3ca552 MAME compared: taito/qix.cpp + 4 related file(s) Read: 27 HDL files, 20,684 lines (Quartus project)	MiSTer official	Mostly hardware	medium	36%
Statements: 12 toward hardware, 32 toward MAME Cites hardware documentation that MAME's driver does not — 5 rtl/Qix.sv:168 FIRQ cross-signals (from schematic Figure 13, U7 7474 dual flip-flop) rtl/Qix_CPU.sv:127 FIRQ access pulses (from schematic Figure 13, U7/U8): $8C00 (even): assert FIRQ on video CPU $8C01 (odd): ack data CPU's own FIRQ One 20MHz cycle pulse at E-fall. rtl/Qix_CPU.sv:226 Per schematic DSR 2/2, its port A is J17 = the player-2 / cocktail control panel, and the data CPU's input poll reads the player's buttons from HERE whenever $8400 != 0: E277: LDX #$9400 / E27A: TST $8400 / E27F: LDX #$9000 / E282: LDA ,X F rtl/Qix_Sound.sv:234 sndPIA2 ($2000-$3FFF) — TMS5200 speech PIA (Kram's "KRAM!" voice) Wiring per Kram schematic: port B ↔ D0-D7 rtl/Qix_Video.sv:135 FIRQ access pulses (from schematic Figure 13, U7/U8): $8C00 (even): assert FIRQ on data CPU $8C01 (odd): ack video CPU's own FIRQ One 20MHz cycle pulse at E-fall. Ships hardware documentation files — 7 Useful Information/schematics/Qix.pdf Useful Information/schematics/Qix_-_1981_-_Taito.pdf Useful Information/schematics/The_Electric_Yoyo.pdf Useful Information/schematics/ZooKeeper.pdf Useful Information/schematics/qix-schematic_text.pdf Useful Information/schematics/slither.pdf Useful Information/schematics/taito_kram.pdf Cites MAME source — 23 rtl/Qix.sv:180 FIRQ delay configuration MODE 0: No delay (direct latch, current behavior) MODE 1: Half E-cycle delay (~400ns at 1.25 MHz E clock) MODE 2: 1 E-cycle delay (~800ns) MODE 3: 2 E-cycle delay (~1600ns) MODE 4: Alternating execution (MAME-style rtl/Qix.sv:210 --- MODE 5: MAME-style end-of-phase FIRQs --- rtl/Qix.sv:244 --- MODE 4: Alternating execution (MAME-style) --- Use E clock phase to alternate: data CPU acts on E=1 half, video CPU acts on E=0 half. rtl/Qix.sv:315 PIA input assembly — per-game, sourced from MAME qix.cpp INPUT_PORTS rtl/Qix.sv:476 MAME fixes this with interleave=20. rtl/Qix_CPU.sv:90 Per qix.cpp: "Zookeeper is almost the same, just the top bit of the address is inverted most of the time to make space for more ROM." XOR cpu_A[15] with is_zookeep so the existing I/O decoders match unchanged. rtl/Qix_CPU.sv:266 MCU games: latched MCU PA output feeds PIA0 PB input, mirroring MAME's coin_r which returns m_68705_porta_out (captured by mcu_porta_w callback). rtl/Qix_CPU.sv:282 MCU PA input latch: mirrors MAME's coin_w (PIA0 writepb_handler) — fires ONLY on true PB port writes (CRB bit2=1), NOT on DDRB writes (CRB bit2=0). rtl/Qix_CPU.sv:354 Slither has no 6802 sound board (qix.cpp: "Slither uses 2 SN76489's for sound instead of the 6802+DAC; these are accessed via the PIAs"). rtl/Qix_CPU.sv:409 SLITHER_CLOCK_OSC is referenced at qix.cpp:737 but not defined in our (truncated) copy of the driver. rtl/Qix_CPU.sv:604 Interface per MAME qix_m.cpp: - Data CPU writes PIA0 PB → MCU PA input (coin_w) - MCU PA output → PIA0 PB input (coin_r — already wired via pia0_pb_i mux above) - MCU PB = (coin & 0x0F) \| ((coin & 0x80) >> 3) - MCU PC = (coinctrl rtl/Qix_CPU.sv:646 MAME (`qix_m.cpp:185-197` coinctrl_w) asserts/clears M68705_IRQ_LINE from `BIT(data,2)` — the value the data CPU WROTE. rtl/Qix_CPU.sv:656 Using the latch makes an undriven bit read 0 => IRQ deasserted => a real 0->1 write produces a real edge, as on hardware and in MAME. rtl/Qix_Sound.sv:64 MAME: SOUND_CLOCK_OSC 7.3728 MHz, M6802(OSC/2) => 3.6864 MHz xtal, E = 921.6 kHz. rtl/Qix_Sound.sv:68 hdl/6802.uc/.vh/_param.vh were generated with jtframe from a 6802 target whose per-opcode `cycles:` came from MAME's cycles_6800[]. rtl/Qix_Sound.sv:308 IRQ to audio CPU: OR of all PIA interrupt outputs (active-high) NOTE (2026-06-16): tried sndpia1-only (MAME-faithful) to fix ZK fast music — DISPROVEN on HW, music unchanged. rtl/Qix_Sound.sv:310 sndpia2-in-sint is a real MAME deviation but NOT the music-tempo cause; revisit only with speech. rtl/Qix_Sound.sv:363 Derived from the parallel resistor network in qix_a.cpp (MAME). rtl/Qix_Video.sv:157 Zoo Keeper ROM-bank latch (per qix_m.cpp zookeep_state::bankswitch_w) rtl/cpu/TMS5220/source/TMS5220.vhd:13 References: TMS5220 datasheet, US Patent US4335277 and TMS5220.cpp from MAME source code. rtl/custom/sn76489/sn76489_noise.vhd:199 Tapped bits according to MAME's sn76496.c, implemented in function lfsr_tapped_f. rtl/qix_display.sv:175 Display address Formula (from MAME qix.cpp): ((MA << 6) & 0xF800) \| ((RA << 8) & 0x0700) \| pix_cnt Expanded: bits [15:11] = MA[9:5] bits [10: 8] = RA[2:0] bits [ 7: 3] = 0 bits [ 2: 0] = pix_cnt rtl/qix_palette.sv:53 RRGGBBII → RGB conversion (from MAME qix.cpp) Index = {color_value[1:0], intensity[1:0]} Says it was translated, ported or taken from MAME — 2 Arcade-Qix.sv:359 Port byte = counter scaled by Trackball Speed: Normal = MAME's 50%, Fast = 1:1, Slow = 1:4 rtl/cpu/TMS5220/source/TMS5220.vhd:15 IMPORTANT NOTES: 1) This implementation does NOT implement the schematic in US4335277 2) It is based primarily on MAME source code and aims to be "functionally equivalent" to the "TMS5220" chip but not identical in terms of electrical circu Shares text with the MAME driver without saying so — 7 rtl/Qix_CPU.sv:91 "Zookeeper is almost the same, just the top bit of the address is inverted — shares text with taito/qix.cpp:68 rtl/Qix_CPU.sv:92 most of the time to make space for more ROM." — shares text with taito/qix.cpp:68 rtl/Qix_CPU.sv:354 Slither has no 6802 sound board (qix.cpp: "Slither uses 2 SN76489's for sound — shares text with taito/qix.cpp:726 rtl/Qix_CPU.sv:355 instead of the 6802+DAC; these are accessed via the PIAs"). The data CPU writes — shares text with taito/qix.cpp:726 rtl/Qix_CPU.sv:411 Slither data CPU at OSC/4/4 ~= 1.34 MHz; this assumes the PSGs share that rate. — shares text with taito/qix.cpp:737 rtl/Qix_Video.sv:221 "[2] Slither only. This hardware feature is NOT present in the — shares text with taito/qix.cpp:122 rtl/qix_display.sv:177 ((MA << 6) & 0xF800) \| ((RA << 8) & 0x0700) \| pix_cnt — shares text with taito/qix_v.cpp:271
Raiden# Raiden MiSTer-devel/Arcade-Raiden_MiSTer @ 027e28a1 MAME compared: seibu/raiden.cpp + 4 related file(s) Read: 37 HDL files, 11,693 lines (Quartus project)	MiSTer official	Both	medium	62%
Statements: 8 toward hardware, 104 toward MAME Says it was checked against the original PCB — 1 rtl/Raiden/Raiden_video_timing.sv:11 RAIDEN (2026-08-21, refresh 1:1): le evidenze sul PCB Raiden convergono su 262 linee ≈ 59.6 Hz, NON 263: MAME raiden.cpp `set_refresh_hz(59.60) "verified on PCB"` (entrambi i set) e i vregs del CRTC reale che raidenb scrive al boot (V total Reports a measurement taken on the original PCB — 1 rtl/Raiden/Raiden_video_timing.sv:8 PCB measurement Blood Bros: VSync 59.4094 Hz, HSync 15.6246 kHz, master XTAL 20 MHz (= 263 linee a 15.625 kHz). Says it was checked on “real hardware” — 2 Raiden.sv:522 Il ricevitore Main ha lo stesso latch-FSM del Sub (main_top:128-152 = sub_top:112-134): protocollo ready-pulse gia' provato con la cache su HW. Raiden.sv:1588 Verificato su HW il 2026-08-23. Notes where it differs from MAME — 4 Raiden.sv:516 (Storico: il vecchio bypass "pattern WonderSwan" era di un'era pre-latch-FSM; oggi il ricevitore Main latcha il ready-pulse come il Sub -> cache ok.) MAIN ROM via rom_cache (come il Sub): senza cache il Main fetcha DIRETTO da SDRAM in arbit rtl/Raiden/Raiden_main_top.sv:120 La coperta dichiarava 2 periodi dove ce n'e' 1: STA verde e SILICIO CHE SBAGLIA -- la stessa forma del bug punteggio storico (multicycle 9 falso, -11.03/-11.85) e di CE_HALF a +1 clk (-11.316, vedi cpu_v30_bridge). rtl/Raiden/Raiden_sub_top.sv:102 La coperta dichiarava 2 periodi dove ce n'e' 1: STA verde e SILICIO CHE SBAGLIA -- la stessa forma del bug punteggio storico (multicycle 9 falso, -11.03/-11.85) e di CE_HALF a +1 clk (-11.316, vedi cpu_v30_bridge). rtl/Raiden/v30_new/v30_bus.sv:644 Se in sim arrivano sbagliati (attivi bassi!), il gioco va in un'altra modalita' e tutto il confronto con MAME non vale niente. Cites MAME source — 96 Raiden.sv:342 raiden_decrypt — applica MAME init_decryption() al volo durante download. Raiden.sv:364 --- Joystick to Raiden input mapping --- MAME P1_P2 port ($E0002): active low. Raiden.sv:367 MiSTer joy bits: joy[0]=R, joy[1]=L, joy[2]=D, joy[3]=U, joy[4]=A, joy[5]=B. Raiden P1_P2 layout MAME (raiden.cpp:589-605): bit 0=UP, 1=DOWN, 2=LEFT, 3=RIGHT, 4=BTN1(Fire), 5=BTN2(Bomb), 6=unused, 7=START1 bit 8-15 = P2 (stesso layout) MiST Raiden.sv:631 MAME raiden.cpp:391-401 — scroll_ram è u16 array, indici 0xNN sono WORD index (non byte address). Raiden.sv:633 Formula (raiden.cpp:398): ((b_hi & 0xF0) << 4) \| ((b_lo & 0x7F) << 1) \| ((b_lo & 0x80) >> 7) scrollregs[0] = BG_X = scroll_ram[0x09].lo<<4 \| scroll_ram[0x0A].lo shifted scrollregs[1] = BG_Y = scroll_ram[0x01].lo<<4 \| scroll_ram[0x02].lo shi Raiden.sv:648 raidenb: gli scroll arrivano dal CRTC come word intere (raiden.cpp:407-410, nessuna ricomposizione byte) — mux sul board select. Raiden.sv:651 L'algebra MAME completa (tilemap.cpp: scroll trasformato + CONTENUTO mirrorato) dimostra che il contratto di rotazione 180° si soddisfa con lo scroll RAW: nessuna negazione. Raiden.sv:723 000 xBGR : R=[ 3:0] G=[ 7:4] B=[11:8] (MAME palette_device::xBGR_444) Raiden.sv:732 xBGR (MAME palette_device::xBGR_444) Raiden.sv:1052 ── Flip screen (CRTC reg 0x1A bit 0) ─────────────────────────────────────── MAME: BIT(reg_1a, 0) → flip_screen. Raiden.sv:1079 MAME raiden.cpp: tilemap set_flip_all su 256 colonne = 255-x. FIX flip 2px (2026-08-21): dal commit 5dee128 (M10K read-ahead, 31 lug, NON nella 1.0 del 29 lug) il read-side legge linebuf[hpos+1] REGISTRATO. Raiden.sv:1103 Raiden Text scroll fissi: 128 X (MAME), 16 Y (centratura HW reale) Raiden.sv:1128 ── BG/FG layer renderer (16x16, 4bpp, 32x32) — fetch SDRAM via arbiter ── Raiden plain: NO MG layer (MAME raiden.cpp:493-495 sub_map ha solo bgram+fgram+palette). Raiden.sv:1164 MAME gfx_raiden palette bases: bgtiles=0, fgtiles=256(0x100), sprites=512(0x200), text=768(0x300) Raiden.sv:1166 BG palette base 0 (raiden.cpp:698 GFXDECODE bgtiles 0,16) Raiden.sv:1187 FG palette base 256 (raiden.cpp:699 GFXDECODE fgtiles 256,16) Raiden.sv:1444 Pixel pipeline MAME RAIDEN (raiden.cpp:286-358 draw_sprites + 361-397 update): Render order MAME: BG (priority 1) → FG (priority 2) → Text (priority 4) Sprite con pri_mask: pri=0 → SKIP (gestito nel renderer, opaque=0) pri=1 → mask = GFX_PM Raiden.sv:1509 MAME: bitmap.fill(black_pen) prima di disegnare i layer → backdrop = NERO fisso, NON palette[0]. Raiden.sv:1525 is_backdrop_d forza nero (MAME bitmap.fill(black_pen)) → no scene-color dell'area "vuota" tra layer (es. rtl/Raiden/Raiden_audio_z80.sv:7 Spec da MAME (reference/mame_seibu/seibusound.cpp + dcon.cpp): - Z80A @ 14.31818 MHz / 4 = 3.579545 MHz - YM2151 (jt51) @ 14.31818 / 4 = 3.579545 MHz - OKI M6295 (jt6295) @ 20 MHz / 16 = 1.25 MHz, PIN7=LOW rtl/Raiden/Raiden_audio_z80.sv:57 OSD volume select (4-bit, pattern BoogieWings): 0=Default, 1=Mute, 2=MAME, 3..15 = percentuale del Default rtl/Raiden/Raiden_audio_z80.sv:113 ─── Clock enable: clk_sys (80 MHz) → Z80/YM 3.579545 MHz, OKI 1 MHz ───── MAME raiden.cpp:724 Z80 @ 14.318181/4 = 3.579 MHz :744 YM3812 @ 14.318181/4 = 3.579 MHz (shared con Z80) 80/3.579545 = 22.349, NON intero: la divisione per 22 dava 3. rtl/Raiden/Raiden_audio_z80.sv:141 OKI clock: MAME raiden.cpp:754 = 12 MHz / 12 = 1 MHz exact. rtl/Raiden/Raiden_audio_z80.sv:183 MAME audiocpu region layout (sdgndmps): rtl/Raiden/Raiden_audio_z80.sv:250 ─── sei80bu: opcode (M1) decrypt — Raiden Z80 ROM encryption ───────────── MAME raiden.cpp:768-769: opcodes via sei80bu_device::opcode_r, data via raw. rtl/Raiden/Raiden_audio_z80.sv:253 GATE z80_decrypt_en (porta, dal board select MRA index=1): 0 = ROM raw (raidenb newer hardware, rai6.u212 in chiaro) 1 = sei80bu attivo (set classici, raiden.zip MAME originale) rtl/Raiden/Raiden_audio_z80.sv:324 ─── ROM bank register (Z80 0x4007: bit0 → bank 0/1) ───────────────────── MAME seibu_sound_device::bank_w: m_rom_bank->set_entry(BIT(data,0)) rtl/Raiden/Raiden_audio_z80.sv:411 Main writes to 0xA0008 (MAME offset 4) → assert RST18 snd_addr = bus_addr[3:1], 0xA0008 → bit[3:1]=100 = 4 rtl/Raiden/Raiden_audio_z80.sv:437 ─── Soundlatch main_w/r logic ────────────────────────────────────────── snd_addr = bus_addr[3:1] = offset/2 (0=word 0, 1=word 1, 2=word 2, 3=word 3, 4=word 4, 5=word 5, 6=word 6) MAME usa byte access (umask16 0x00ff = byte basso). rtl/Raiden/Raiden_audio_z80.sv:439 Mappa offset MAME → snd_addr: offset 0 (0xA0000) → snd_addr 0 offset 1 (0xA0002) → snd_addr 1 offset 2 (0xA0004) → snd_addr 2 offset 3 (0xA0006) → snd_addr 3 offset 5 (0xA000A) → snd_addr 5 offset 6 (0xA000C) → snd_addr 6 rtl/Raiden/Raiden_audio_z80.sv:462 Main writes (MAME seibu_sound_device::main_w): case 0/1: m_main2sub[offset] = data case 4: update_irq_lines(RST18_ASSERT) — gestito sopra case 2/6: pending flags (sub2main=0, main2sub=1) rtl/Raiden/Raiden_audio_z80.sv:470 MAME case 2/6 rtl/Raiden/Raiden_audio_z80.sv:477 Z80 reads soundlatch (→ MAME implicit: nessun side effect) Z80 writes sub2main rtl/Raiden/Raiden_audio_z80.sv:491 MAME seibu_sound_device::main_r (seibusound.cpp:285): offset 2,3: sub2main[0/1] (Z80 → main latch bytes) offset 5: main2sub_pending (main chiede: Z80 ha letto il mio comando?) default: 0xFF NO sdgndmps override per Raiden (era bug copi rtl/Raiden/Raiden_audio_z80.sv:503 ─── YM3812 (jtopl2) mono ──────────────────────────────────────────────── MAME raiden.cpp:744 YM3812(config, "ymsnd", 14.318181_MHz_XTAL / 4) Mono → duplicato L/R nel mixer sotto. rtl/Raiden/Raiden_audio_z80.sv:703 PIN7 = HIGH (MAME raiden.cpp:754 verified) rtl/Raiden/Raiden_audio_z80.sv:811 I byte della ROM Z80 come li vede la CPU: in MAME 0010 = C3 76 10. rtl/Raiden/Raiden_audio_z80.sv:901 ─── Mixer audio: jtframe_mixer Toki pattern (Q4.4 gains) ──────────────── Volume OSD pattern BoogieWings: Default/Mute/MAME + percentuali che scalano il DEFAULT. rtl/Raiden/Raiden_audio_z80.sv:905 Default Raiden tarato HW (screenshot 2026-07-13): FM 500%, ADPCM 400% del gain MAME base (FM 0x10, OKI 0x0C). rtl/Raiden/Raiden_audio_z80.sv:907 FM : 0x10 × 5 = 0x50 (= era 100% MAME × 5.0) OKI : 0x0C × 4 = 0x30 (= era 75% MAME × 4.0) Le percentuali OSD scalano da QUESTI nuovi default. rtl/Raiden/Raiden_audio_z80.sv:909 MAME (sel 2) resta il valore MAME-esatto originale (0x10 / 0x0C) per chi vuole l'accurato. rtl/Raiden/Raiden_main_top.sv:350 Equivale a MAME tilemap render fine-frame. rtl/Raiden/Raiden_main_top.sv:371 Tutte le scritture nella text RAM, nello stesso formato del tap MAME. rtl/Raiden/Raiden_main_top.sv:527 ─── control_w $0E006 (8-bit) — raidenb: $0B006 ──────────────────────── base (raiden.cpp:242-259): bit 0: BG dis, bit 1: FG dis, bit 2: TX dis, bit 3: SPR dis, bit 6: flipscreen raidenb (raiden.cpp:261-271): bit 1: flipscreen, bit 3: TX rtl/Raiden/Raiden_main_top.sv:639 Confronto diretto con MAME sull'ATTRACT DEMO (stesso codice, nessun input, deterministico). rtl/Raiden/Raiden_main_top.sv:641 MAME misurato: +44 ogni 300 frame video. rtl/Raiden/Raiden_seibu_crtc.sv:12 Mappatura output sugli usi REALI di raidenb (raiden.cpp:273-282, 791-794), non sulla doc generica CRTC: reg 0x1C (layer_en): d0=BG disable, d1=FG disable, d4=SPR disable (in Raiden il layer FG e' lo "screen 2" del CRTC → bit 1). rtl/Raiden/Raiden_seibu_crtc.sv:21 reg 0x1A: flip NON viene da qui in raidenb (callback non collegata in MAME); il flip sta nel control 0x0B006 d1. rtl/Raiden/Raiden_seibu_crtc.sv:83 MAME raidenb layer_enable_w: bit=1 → layer DISABILITATO. rtl/Raiden/Raiden_sprite_renderer.sv:9 Format word (formato "comune", non alt_format) da MAME src/mame/seibu/sei021x_sei0220_spr.cpp: w0 bit 15 = enable (0=skip, 1=draw) w0 bit 14 = flip_x w0 bit 13 = flip_y w0 bit 12..10 = sizex (3-bit, +1) → 1..8 tile larghezza rtl/Raiden/Raiden_sprite_renderer.sv:24 Multi-tile: tile_code += 1 per sub-tile (TODO: ordine x-major o y-major da verificare con dump MAME — assunto x-major per ora). rtl/Raiden/Raiden_sprite_renderer.sv:27 Priority callback dcon.cpp::pri_cb: pri=0 → above FG pri=1 → above MG pri=2 → above BG pri=3 → above Text (= sotto Text) rtl/Raiden/Raiden_sprite_renderer.sv:81 ─── Line buffer ping-pong (320 × 10-bit: color[3:0] + pri[1:0] + pen[3:0]) ── Layout 10-bit: [9:6]=color (4-bit MAME Raiden), [5:4]=pri_code, [3:0]=pen Valid pixel = pen != 0xF (15 = trasparente in MAME) rtl/Raiden/Raiden_sprite_renderer.sv:114 Decoded fields - MAME RAIDEN layout (raiden.cpp:298-316): w0: [15]=active, [14]=flipy, [13]=flipx, [11:8]=color(4-bit), [7:0]=Y(8-bit unsigned) w1: [11:0]=code(12-bit) w2: [15:14]=priority(2-bit, 0=SKIP), [8:0]=X(signed 9-bit) w3: unused Sp rtl/Raiden/Raiden_sprite_renderer.sv:121 flip_screen (DIP) inverte flipx/flipy per-sprite (raiden.cpp:353-354). rtl/Raiden/Raiden_sprite_renderer.sv:131 flip_screen (DIP): x = 240 - x (raiden.cpp:351). rtl/Raiden/Raiden_sprite_renderer.sv:136 flip_screen: y = 240 - y (raiden.cpp:352). rtl/Raiden/Raiden_sprite_renderer.sv:195 Inverte la priorità tra sprite rispetto al default MAME. rtl/Raiden/Raiden_sprite_renderer.sv:435 priority=0 skip (MAME raiden.cpp:322-324). rtl/Raiden/Raiden_text_renderer.sv:7 Specifiche da MAME (src/mame/seibu/dcon.cpp): rtl/Raiden/Raiden_text_renderer.sv:51 (raiden.cpp:697 GFXDECODE text 768 16 → palette base 0x300) rtl/Raiden/Raiden_text_renderer.sv:59 raidenb (newer hardware): text tilemap TILEMAP_SCAN_COLS (raiden.cpp:463-471) → vram_addr = col32+row invece di row32+col. rtl/Raiden/Raiden_text_renderer.sv:133 --- Stage 0: tile coords --- MAME raiden.cpp:458 text_layer = TILEMAP_SCAN_ROWS, 8x8, 32x32 tiles. rtl/Raiden/Raiden_text_renderer.sv:180 vram_data è valido in stage 1 (BRAM read latency 1 ce_pix) MAME raiden.cpp get_text_tile_info: tile = (data & 0xff) \| ((data >> 6) & 0x300) = bit[7:0] \| bit[15:14] in [9:8] color = (data >> 8) & 0x0f = bit[11:8] rtl/Raiden/Raiden_tile_layer.sv:7 Differenze fra layer (da MAME dcon.cpp): rtl/Raiden/Raiden_tile_layer.sv:227 MAME raiden.cpp:443 BG e FG usano TILEMAP_SCAN_COLS: tile_index = col * height + row = col * 32 + row Quindi vram_addr = {col[4:0], row[4:0]} (col high, row low). rtl/Raiden/Raiden_tile_layer.sv:267 MAME raiden_tilelayout (raiden.cpp:685-694): planes = STEP4(12,-4) = {12, 8, 4, 0} rtl/Raiden/Raiden_tile_layer.sv:284 MAME readbit MSB-first → bit_in_byte = 7 - (bitnum mod 8). rtl/Raiden/Raiden_video_timing.sv:11 RAIDEN (2026-08-21, refresh 1:1): le evidenze sul PCB Raiden convergono su 262 linee ≈ 59.6 Hz, NON 263: MAME raiden.cpp `set_refresh_hz(59.60) "verified on PCB"` (entrambi i set) e i vregs del CRTC reale che raidenb scrive al boot (V total rtl/Raiden/Raiden_video_timing.sv:18 Il pixel clock effettivo per matchare HSync 15.625 kHz con HTotal=384 (320 attivi + 64 blank ≈ 80% duty) è: pix_clk = HTotal × HSync = 384 × 15625 = 6.0 MHz Frame rate: 6e6 / (384 × 262) = 59.63 Hz (Raiden PCB 59.60, MAME verified) rtl/Raiden/Raiden_video_timing.sv:23 Active area da MAME (sdgndmps_map): visarea 0..408-1, 28..30*8-1 quindi 320×224, V offset = 16 (top blank). rtl/Raiden/raiden_addr_main.sv:6 Memory map MAME raiden_state::main_map (riga 475-488): 0x00000-0x06FFF RAM (28KB) → ram_memrq 0x07000-0x07FFF spriteram (4KB) → sprite_memrq 0x08000-0x08FFF shared RAM (Sub) → shared_memrq 0x0A000-0x0A00D rtl/Raiden/raiden_addr_main.sv:19 board_raidenb=1: mappa raidenb_state::main_map (raiden.cpp:537-550) — shared 0x0A000, I/O+ctrl 0x0B00x, sound 0x0D000, Seibu CRTC 0x0D040-8F, niente scroll_ram. rtl/Raiden/raiden_addr_main.sv:67 raidenb_state::main_map (raiden.cpp:537-550) rtl/Raiden/raiden_addr_sub.sv:6 Memory map MAME raiden_state::sub_map (riga 490-501): 0x00000-0x01FFF RAM (8KB) → ram_memrq 0x02000-0x027FF bgram (R/W) → bgram_memrq 0x02800-0x02FFF fgram (R/W) → fgram_memrq 0x03000-0x03FFF pal rtl/Raiden/raiden_ce_gen.sv:6 V30 spec MAME = 10 MHz esatti. rtl/Raiden/raiden_ce_gen.sv:8 clk_sel[2:0] (da OSD P2O[22:20]): 0=10MHz → div 8 (10.0 MHz esatti) ← spec MAME 1=8MHz → div 10 (8.0 MHz) 2=12MHz → div 6 (13.3 MHz) 3=16MHz → div 5 (16.0 MHz) 4=24MHz → div 4 (20.0 MHz) 5=32MHz → div 2 (26.7 MHz) rtl/Raiden/raiden_ce_gen.sv:48 10 MHz spec MAME (80/8) rtl/Raiden/raiden_decrypt.sv:4 raiden_decrypt — passthrough ioctl_dout con decifrato MAME init_decryption() rtl/Raiden/raiden_decrypt.sv:9 Range crittato (riferimento raiden.cpp:1187): - Main ROM section 2: MRA byte 0x020000-0x05FFFF (CPU 0xC0000-0xFFFFF) - Sub ROM tutto: MRA byte 0x060000-0x09FFFF (CPU 0xC0000-0xFFFFF) rtl/Raiden/raiden_decrypt.sv:20 Bitswap16 da MAME bitswap<16>(d, b15..b0): out[15]=d[b15], ..., out[0]=d[b0]. rtl/Raiden/raiden_decrypt.sv:84 ── Output selection ──────────────────────────────────────────────── PRODUCTION MODE: decrypt runtime per usare raiden.zip originale MAME. rtl/Raiden/raiden_decrypt.sv:86 I range enc_main (0x020000-0x05FFFF) e enc_sub (0x060000-0x09FFFF) sono applicati on-the-fly via XOR + bitswap MAME init_decryption() (raiden.cpp:1187). rtl/Raiden/raiden_shared_ram.sv:19 MAME memory map: Main: $08000-$08FFF Sub : $04000-$04FFF rtl/Raiden/raiden_sprite_mainbus.sv:4 Raiden sprite RAM bus (pattern Irem M72 board_b_d-style + BUFFERED_SPRITERAM16) Gestisce spriteram (Main side, $07000-$07FFF, 4KB = 2K word) con: - Porta A: Main V30 R/W - Buffer: copia spriteram → buf su rising vblank (MAME BUFFERED_SPRITE rtl/Raiden/raiden_sprite_mainbus.sv:10 MAME memory map Main: $07000-$07FFF spriteram (4KB) — share "spriteram" (BUFFERED_SPRITERAM16) rtl/Raiden/raiden_video_subbus.sv:13 MAME memory map Sub: $02000-$027FF bgram $02800-$02FFF fgram $03000-$03FFF palette rtl/Raiden/sei80bu.v:4 sei80bu - SEI80BU Encrypted Z80 Interface Implementazione esatta da MAME mame/src/devices/machine/sei80bu.cpp: - data_r: 5 XOR + 2 bitswap (sempre) - opcode_r: 8 XOR + 4 bitswap (data + 3 XOR e 2 bitswap extra solo M1) Determinato runti rtl/Raiden/v30_new/v30_bus.sv:577 COSTO IN CICLI CPU del codice di boot (deterministico, identico a MAME). rtl/Raiden/v30_new/v30_bus.sv:578 Stampo il numero di CE (= clock CPU) alla n-esima scrittura nella finestra 00400-0040F: gli stessi eventi misurati in MAME con raiden_cycles.lua. rtl/Raiden/v30_new/v30_bus.sv:590 Ogni volta che cambia e' un'istruzione completata: stampo ciclo + IP nella stessa finestra tracciata in MAME, cosi' il costo istruzione per istruzione si confronta uno a uno. rtl/Raiden/v30_new/v30_bus.sv:601 Riferimento MAME da avvio: main ~4106/4186 per frame (con calo a ~3 ogni 6 frame), sub ~822/2992 alternati. rtl/Raiden/v30_new/v30_bus.sv:616 costo di UN giro del ciclo di attesa: in MAME e' 23 cicli esatti (cmp [410h],5 = 10, blt = 13). rtl/Raiden/v30_new/v30_bus.sv:634 In MAME viene messo a 1 una volta sola da EECE7 e da li' in poi la ISR lavora. rtl/Raiden/v30_new/v30_bus.sv:668 In MAME sono ~73.380 cicli (44% del frame): e' il lavoro vero del frame. README.md:11 This core reimplements the hardware in SystemVerilog/VHDL from MAME references and hardware observation. Says it matches, follows or was checked against MAME — 1 rtl/Raiden/v30_new/v30_bus.sv:653 Confrontato con la traccia di MAME dice l'istruzione esatta in cui i due si separano. Shares text with the MAME driver without saying so — 7 Raiden.sv:1448 pri=1 → mask = GFX_PMASK_4 \| GFX_PMASK_2 → sotto FG e Text → SOPRA SOLO BG — shares text with seibu/raiden.cpp:327 rtl/Raiden/Raiden_audio_z80.sv:504 MAME raiden.cpp:744 YM3812(config, "ymsnd", 14.318181_MHz_XTAL / 4) — shares text with seibu/raiden.cpp:758 rtl/Raiden/Raiden_text_renderer.sv:4 Raiden_MiSTer — Text layer renderer Seibu D-Con (8x8, 4bpp, 64x32). Author: Umberto Parisi (rmonic79) Specifiche da MAME (src/mame/seibu/dcon.cpp): — shares text with seibu/raiden.cpp rtl/Raiden/Raiden_tile_layer.sv:269 xoff = STEP4(0,1) \| STEP4(16,1) \| STEP4(512,1) \| STEP4(528,1) — shares text with seibu/raiden.cpp:681 rtl/Raiden/Raiden_video_timing.sv:4 Raiden_MiSTer — Video timing single-screen Seibu D-Con. Author: Umberto Parisi (rmonic79) Raiden Psycho Salamander gira su Seibu D-Con (PB91008), stess — shares text with seibu/raiden.cpp rtl/Raiden/raiden_decrypt.sv:63 Main: 15,14,10,12,11,13,9,8,3,2,5,4,7,1,6,0 — shares text with seibu/raiden.cpp:1205 rtl/Raiden/raiden_decrypt.sv:68 Sub: 15,14,13,9,11,10,12,8,2,0,5,4,7,3,1,6 — shares text with seibu/raiden.cpp:1216
Raiden2# Raiden II, Raiden DX MiSTer-devel/Arcade-Raiden2_MiSTer @ 534c84c5 MAME compared: seibu/raiden2.cpp + 12 related file(s) Read: 39 HDL files, 15,779 lines (Quartus project)	MiSTer official	Mostly MAME	medium	73%
Statements: 5 toward hardware, 236 toward MAME Says it was checked against the original PCB — 1 rtl/Raiden2/raiden2_ce_gen.sv:41 Il V30 della scheda gira a 16,000000 MHz (quarzo 32 MHz diviso 2, "verified on pcb"), quindi il rapporto esatto e' 16/96 = 20/120. Says it was checked on “real hardware” — 3 rtl/Raiden2/Raiden2_cop3.sv:660 0 : 1 (unsigned <320 provato su HW = REGRESSIONE; il signed [-160,320) dell'intento MAME e' il comportamento giusto sul core) rtl/Raiden2/Raiden2_sprite_renderer.sv:502 Scan INVERSO 511→0 (verificato su HW): lo fa la scan-ombra, e la FIFO conserva quell'ordine, quindi con last-write-wins l'entry 0 scrive per ultima e vince → entry 0 sopra. rtl/Raiden2/Raiden2_tile_layer.sv:350 Plane order verificato su HW: BG/MG = DCBA (PEN_ORDER=0), FG = BADC (PEN_ORDER=1). Notes where it differs from MAME — 1 rtl/Raiden2/Raiden2_cop3.sv:3702 La chiave e' la word CON SEGNO all'indirizzo ALLINEATO AL LONG: key = read_word( (sort_ram + val) & ~3 ) E' l'unica funzione che soddisfa i due testimoni del ROM: piani $00363E: $110004 + val (val ≡0 mod 4) = $1157EC, e la chiave e' la Y Cites MAME source — 220 Raiden2.sv:327 Raiden II: il programma main V30 e' IN CHIARO (raiden2.cpp non ha init_decryption). Raiden2.sv:337 --- Joystick to Raiden input mapping --- MAME P1_P2 port ($E0002): active low. Raiden2.sv:340 MiSTer joy bits: joy[0]=R, joy[1]=L, joy[2]=D, joy[3]=U, joy[4]=A, joy[5]=B. Raiden P1_P2 layout MAME (raiden.cpp:589-605): bit 0=UP, 1=DOWN, 2=LEFT, 3=RIGHT, 4=BTN1(Fire), 5=BTN2(Bomb), 6=unused, 7=START1 bit 8-15 = P2 (stesso layout) MiST Raiden2.sv:360 Seibu coin input: Raiden II usa SEIBU_COIN_INPUTS_INVERT (raiden2.cpp:768, tutti i bit ATTIVI BASSI, a riposo 0xFF — confermato dal ROM nella _old: il ramo che accredita e' quello con AND == 0). Raiden2.sv:611 MAME raiden.cpp:391-401 — scroll_ram è u16 array, indici 0xNN sono WORD index (non byte address). Raiden2.sv:613 Formula (raiden.cpp:398): ((b_hi & 0xF0) << 4) \| ((b_lo & 0x7F) << 1) \| ((b_lo & 0x80) >> 7) scrollregs[0] = BG_X = scroll_ram[0x09].lo<<4 \| scroll_ram[0x0A].lo shifted scrollregs[1] = BG_Y = scroll_ram[0x01].lo<<4 \| scroll_ram[0x02].lo shi Raiden2.sv:664 ── Palette → RGB888 — COPIATA dalla _old (Raiden2_palette.sv:85-96, video HW-perfetto): Raiden2 = xBGR_555 (legionna.cpp:1212), NON 444. Raiden2.sv:666 Layout word: bit[4:0]=R, bit[9:5]=G, bit[14:10]=B. Espansione 5→8 standard MAME palette_device: {val5, val5[4:2]}. Raiden2.sv:869 Pixel clock 8 MHz = clk_sys/12, HTotal 512, VTotal 282 (raiden2.cpp: set_raw(32MHz/4, 512,0,320, 282,0,240)). Raiden2.sv:898 ── Flip screen (CRTC reg 0x1A bit 0) ─────────────────────────────────────── MAME: BIT(reg_1a, 0) → flip_screen. Raiden2.sv:1007 Scroll CRTC (legionna_v.cpp tile_scroll_w): ram[0/1]→BG, [2/3]→MG, [4/5]→FG. Raiden2.sv:1104 La ROM e' CIFRATA (MAME init_raiden2 → raiden2_decrypt_sprites): l'algoritmo lavora su word da 32 bit, quindi si accumulano le due meta' a 16 bit da ioctl, si decifra, si scrivono entrambe. Raiden2.sv:1437 Pixel pipeline MAME RAIDEN (raiden.cpp:286-358 draw_sprites + 361-397 update): Render order MAME: BG (priority 1) → FG (priority 2) → Text (priority 4) Sprite con pri_mask: pri=0 → SKIP (gestito nel renderer, opaque=0) pri=1 → mask = GFX_PM Raiden2.sv:1465 ── Composizione raiden2_v (dalla _old): draw_raw + blend_layer con m_cur_spri = {0,1,2,3,-1} (raiden2.cpp:3165-3167). Raiden2.sv:1480 Implementa il modello MAME per intero: fondale nero, poi gli 8 livelli dal FONDO in avanti, e un indice in tabella si MESCOLA al 50% con l'accumulato invece di sostituirlo. rtl/Raiden2/Raiden2_audio_z80.sv:25 Spec da MAME (legionna.cpp godzilla machine config :1295-1355): - Z80 @ 14.318180/4 = 3.579545 MHz (seibu_sound_map + godzilla_sound_io_map) - YM2151/OPM (jt51) @ 28.63636/8 = 3.579545 MHz - OKI M6295 (jt6295) @ 20MHz/20 = 1.000 MHz, PIN7=H rtl/Raiden2/Raiden2_audio_z80.sv:58 Raiden2 pcm.922 = 512KB: bit 18 = bank (Z80 IO port 0, MAME godzilla_oki_bank_w: set_rom_bank(data&1)). rtl/Raiden2/Raiden2_audio_z80.sv:63 Secondo OKI (MAME raiden2.cpp:1151): ROM su DDR3, porta a priorita' bassa. rtl/Raiden2/Raiden2_audio_z80.sv:74 master OKI2 (MAME instrada 0.40 CIASCUNO) rtl/Raiden2/Raiden2_audio_z80.sv:192 MAME raiden2_sound_map: $6000 = oki1, $6002 = oki2 -> discrimina addr[1]. rtl/Raiden2/Raiden2_audio_z80.sv:265 raiden2_sound_map (raiden2.cpp:738) sposta bank_w a $401A: la mappa Seibu CONDIVISA lo ha a $4007, che qui NON e' mappato. rtl/Raiden2/Raiden2_audio_z80.sv:491 MAME seibu_sound_device::main_r (seibusound.cpp:279): case 2,3: return sub2main[offset-2] (soundlatch data: coin/input dal Z80) case 5: return main2sub_pending ? rtl/Raiden2/Raiden2_audio_z80.sv:574 ─── YM2151 (jt51) mono — Raiden II usa OPM, non OPL2 ─────────────────── MAME raiden2.cpp base_ym2151: ym2151_device @ XTAL(28'636'363)/8, route ALL_OUTPUTS 0.50 su mono. rtl/Raiden2/Raiden2_audio_z80.sv:779 ─── OKI M6295 (jt6295) — MAME raiden2.cpp: XTAL 28.63636/28 = 1.0227 MHz, PIN7_HIGH, DUE chip instradati 0.40 ciascuno. rtl/Raiden2/Raiden2_audio_z80.sv:957 Due OKI (MAME li instrada entrambi a 0.40 contro 0.50 dell'FM): si sommano a 17 bit PRIMA del guadagno, poi una sola moltiplicazione. rtl/Raiden2/Raiden2_audio_z80.sv:960 I due OKI hanno ORA il loro guadagno master indipendente: in MAME sono due device distinti instradati 0.40 ciascuno, e nell'OSD sono due voci. rtl/Raiden2/Raiden2_cop3.sv:4 MAME-faithful implementation of the Seibu SEI300 chip as used by the `legionna` driver (Raiden2 1992 — Banpresto/TAD). rtl/Raiden2/Raiden2_cop3.sv:7 Reference (in this repo): MAME seibucop.cpp MAME seibucop_cmd.ipp MAME seibucop_dma.ipp MAME legionna.cpp rtl/Raiden2/Raiden2_cop3.sv:57 MAME seibucop_cmd.ipp:471: execute_7e05: write_byte(0x470, read_byte(cop_regs[4])) Su DX $470 e' raidendx_cop_bank_2_w: bit 5-4 = banco FOREGROUND (bit 15-12 = banco programma, che una write a BYTE non tocca). rtl/Raiden2/Raiden2_cop3.sv:165 Z-sorting DMA: registri $100450-$100458 (MAME cop_sort_). rtl/Raiden2/Raiden2_cop3.sv:178 MAME cop_itoa_digits[10]: BCD digits of cop_itoa (low<<0 \| high<<16). rtl/Raiden2/Raiden2_cop3.sv:182 Il vecchio loop a sottrazioni ripetute era O(valore) (~valore/9 clk): con i long 32-bit di godzilla (score, writer $156E/$1F93E) il 68k restava congelato (dma_busy include bcd_pending) fino a MILLISECONDI per chiamata — su MAME/HW reale i d rtl/Raiden2/Raiden2_cop3.sv:195 MAME cop_program command table (seibucop.cpp lines 318-457) At boot, game code uploads 32 macro slots × 8 micro-op words via pgm_addr (0x100434) → slot8 + sub-index pgm_data (0x100432) → micro-op word pgm_value (0x100438) → cop_func_valu rtl/Raiden2/Raiden2_cop3.sv:202 MAME calls find_trigger_match(triggerval, 0xff00) to find the slot whose cop_func_trigger matches. rtl/Raiden2/Raiden2_cop3.sv:330 Triggers (write-only addresses) MAME legionna.cpp:172 maps cop_cmd_w to $100500-$100505 (3 words). rtl/Raiden2/Raiden2_cop3.sv:654 0x100410 sprite_dma_inc (MAME cop_sprite_dma_inc_w): if x_clip in [-160, 320): cop_regs[4] += 8. rtl/Raiden2/Raiden2_cop3.sv:655 MA in MAME sprite_x e' uint16_t assegnato a int -> MAI negativo -> il -160 e' codice morto: check EFFETTIVO = unsigned < 320 (X "negative" 0xFFxx NON avanzano il puntatore entry). rtl/Raiden2/Raiden2_cop3.sv:660 0 : 1 (unsigned <320 provato su HW = REGRESSIONE; il signed [-160,320) dell'intento MAME e' il comportamento giusto sul core) rtl/Raiden2/Raiden2_cop3.sv:667 A size==0 NON wrappare (il size-- uint di MAME wrapperebbe a $FFFF: il loop del builder su status[1] andrebbe in livelock — provato peggio). rtl/Raiden2/Raiden2_cop3.sv:718 Macro program upload — MAME seibucop.cpp lines 318-457 pgm_data writes one micro-op word to cop_program[latch_addr] AND latches the slot's trigger/value/mask from current latch regs. rtl/Raiden2/Raiden2_cop3.sv:821 itoa_digits (MAME 0x100590-99, 5 word). rtl/Raiden2/Raiden2_cop3.sv:833 Status / dist / angle (seibucop.cpp:916 cop_status_r → cop_status) rtl/Raiden2/Raiden2_cop3.sv:841 MAME open bus rtl/Raiden2/Raiden2_cop3.sv:915 commit write al dst ASSOLUTO (fill/mr), 1:1 MAME write_word(dst) rtl/Raiden2/Raiden2_cop3.sv:951 LEGACY sprite-DMA (seibucop_cmd.ipp): 6880 (carica rel_xy), c480 (single-step: compone l'entry sprite a cop_regs[4]+offs con X/Y = rel + (obj - abs)). rtl/Raiden2/Raiden2_cop3.sv:975 write angolo (word {0,angle} come MAME host_endian) rtl/Raiden2/Raiden2_cop3.sv:976 5105/f105 — moltiplicatore 16.16 (ricavato da ROM+disasm, non da MAME: li' gli handler sono vuoti). rtl/Raiden2/Raiden2_cop3.sv:988 dde5 — i PALLINI DEL RADAR (MAME LEGACY_execute_dde5). rtl/Raiden2/Raiden2_cop3.sv:1010 ── sprite_prot / sprcpt: costruttore della display list di Raiden II ── MAME raiden2.cpp:474-503 (sprite_prot_src_w). rtl/Raiden2/Raiden2_cop3.sv:1038 ── Registri sprite_prot ($6C0-$6DF), MAME raiden2.cpp:452-535 ────────── rtl/Raiden2/Raiden2_cop3.sv:1075 Trigger latches — MAME seibucop.cpp cop_cmd_w line 1069. rtl/Raiden2/Raiden2_cop3.sv:1076 MAME dispatches on raw data after clearing cop_status bit 15. rtl/Raiden2/Raiden2_cop3.sv:1130 DMA mode 0x80-0x87: MAME dma_palette_brightness() fa FADE solo con pal_brightness_mode 4/5; con qualsiasi altro valore fa una COPIA SEMPLICE src->dst (ramo else, seibucop_dma.ipp:119-123) verso QUALUNQUE dst — incl. rtl/Raiden2/Raiden2_cop3.sv:1138 DMA generici 0x09/0x0E: MAME write_word(dst) va nello spazio host = arriva a QUALSIASI RAM mappata, incluse le BRAM video ($101000-$105FFF: staging tilemap, palette-stage $104000, sprite $105000). rtl/Raiden2/Raiden2_cop3.sv:1146 Output del fade/blend 0x8x: MAME dma_palette_brightness fa write_word(dst) nello SPAZIO HOST = raggiunge QUALUNQUE RAM mappata (pal-stage $104000, sprite $105800, Main RAM...). rtl/Raiden2/Raiden2_cop3.sv:1149 Ora: pal_val registrato in D_FADE_WRITE e committato in D_FADE_COMMIT via canale fill (decode per dst assoluto in main_top: bg/fg/mg/txt/pal/spr) o mr (dst in Main RAM) — 1:1 MAME. rtl/Raiden2/Raiden2_cop3.sv:1152 (Il vecchio dma80_to_spr era INVERTITO: il blit pietre e' src=$105800 dst=$104000, non il contrario — MAME map: $100478=SRC, $10047C=DST.) rtl/Raiden2/Raiden2_cop3.sv:1155 LEGACY sprite-DMA state (MAME m_sprite_dma_rel_x/y, m_sprite_dma_x_clip) rtl/Raiden2/Raiden2_cop3.sv:1170 Raiden II (raiden2.cpp:635-644): blocco contiguo $0C000-$0F7FF (SPR 4K + BG 2K + FG 2K + MG 2K + TXT 4K) piu' la palette $1F000-$1FFFF. rtl/Raiden2/Raiden2_cop3.sv:1269 MAME cop_cmd_w (seibucop.cpp:1075): rtl/Raiden2/Raiden2_cop3.sv:1281 MAME cop_sort_dma_trig_w -> dma_zsorting(data): n = data + 1 rtl/Raiden2/Raiden2_cop3.sv:1311 find_trigger_match (seibucop.cpp:464) Cerca slot N tale che (trigger & 0xf800) == (cop_func_trigger[N] & 0xf800) && cop_func_trigger[N] != 0. rtl/Raiden2/Raiden2_cop3.sv:1313 Restituisce canonical trigger value del slot (NB: MAME LEGACY_cop_cmd_w usa il match slot per dispatchare; in pratica equivale a restituire cop_func_trigger[slot]). rtl/Raiden2/Raiden2_cop3.sv:1334 fade_table — MAME seibucop.cpp:733 (reverse engineered from Seibu Cup Soccer bootleg) v = pal_channel(5-bit) \| (brightness_val_xor_X) [10-bit input] low = v & 0x1F high = v & 0x3E0 return (low * (high \| (high>>5)) + 0x210) >> 10 [8-bit o rtl/Raiden2/Raiden2_cop3.sv:1373 ── Hitbox b100/b900 scratch (MAME cop_collision_update_hitbox) ────────────── dx[i] = int8 (signed) byte basso, size[i] = uint8 (unsigned) byte alto del word descrittore @ hitadr2+2i. 3 assi (Y,X,Z) per Raiden2. rtl/Raiden2/Raiden2_cop3.sv:1380 num_axis: MAME seibucop.cpp:1010 "if (data & 0x100) num_axis = 3" else 2. rtl/Raiden2/Raiden2_cop3.sv:1382 res init 7 vs 3 (seibucop.cpp:1038-39). rtl/Raiden2/Raiden2_cop3.sv:1388 Delta LATCHATI dall'ultimo comando d'angolo: il 3bb0 NON li ricalcola, li riusa (in MAME sono m_LEGACY_r0/r1, e il TODO sopra execute_3b30 dice esattamente questo). rtl/Raiden2/Raiden2_cop3.sv:1405 dde5: divisore CON SEGNO (in MAME e' una divisione C int, quindi troncamento verso zero). rtl/Raiden2/Raiden2_cop3.sv:1436 Con 16-bit frac + 24 iter + z>>16: 0 divergenze di decisione vs MAME int(atan(dx/dy)128/pi) su ~640k casi (dimostrato numericamente). rtl/Raiden2/Raiden2_cop3.sv:1709 MAME cop_dma_trigger_w: NON modifica cop_status (vedi seibucop.cpp:741). rtl/Raiden2/Raiden2_cop3.sv:1717 MAME dma_tilemap_buffer: copy staging RAM → renderer BRAM src = cop_dma_src[mode] << 6 (byte addr 0x101000+ = staging) dst = i (loop counter 0..0x13FF = renderer index) count = 0x2800/2 = 5120 words seibucop_dma.ipp:8 — correzione SPECIFICA rtl/Raiden2/Raiden2_cop3.sv:1733 MAME dma_palette_buffer: copy staging palette → renderer src = cop_dma_src[mode] << 6 (0x104000 = palette staging) dst = i (loop counter 0..0x7FF = renderer index) count = 0x1000/2 = 2048 words rtl/Raiden2/Raiden2_cop3.sv:1743 MAME write_word(dst) su spazio host: con dst nelle BRAM video ($101000-$105FFF: staging/pal/spr, es. rtl/Raiden2/Raiden2_cop3.sv:1759 simplified, MAME size>>1 rtl/Raiden2/Raiden2_cop3.sv:1764 MAME seibucop_dma.ipp dma_palette_brightness() mode 5/4. rtl/Raiden2/Raiden2_cop3.sv:1767 MAME formulas: src = cop_dma_src[mode] << 6 dst = cop_dma_dst[mode] << 6 size = ((cop_dma_size << 5) - (cop_dma_dst << 6) + $20)/2 Init: src=$106000, dst=$104000, size=($827F<<5 - $4100<<6 + $20)/2 = ($104FE0 - $104000 + $20)/2 = $1000 rtl/Raiden2/Raiden2_cop3.sv:1778 MAME size = (((size<<5) - (dst<<6) + 0x20)/2) rtl/Raiden2/Raiden2_cop3.sv:1784 MAME: mode 4/5 = fade palette; QUALSIASI ALTRO = copia semplice src->dst (seibucop_dma.ipp:119-123). rtl/Raiden2/Raiden2_cop3.sv:1794 MAME seibucop.cpp cop_dma_trigger_w case 0x116 — SEIBUCUP: fill come 0x118 ma SENZA guard dst!=0 e length bytes = (size+1)<<4 (metà). rtl/Raiden2/Raiden2_cop3.sv:1796 legionna.cpp:56-61: "The COP-MCU appears to write to the work ram area, otherwise it RESETS in mid-animation of the title screen" → senza questo fill il gioco torna al logo da solo. rtl/Raiden2/Raiden2_cop3.sv:1807 Skip if dst != 0 (MAME guard, dma.ipp:135) rtl/Raiden2/Raiden2_cop3.sv:1827 MAME sprite_prot_src_w (raiden2.cpp:474-503): src = (seg << 4) + data x = int16(read_dword(src+8) >> 16) - spr_x y = int16(read_dword(src+4) >> 16) - spr_y Su V30 (little-endian) la meta' ALTA di una dword sta a +2, quindi il >>16 significa rtl/Raiden2/Raiden2_cop3.sv:1842 MAME cop_cmd_w (seibucop.cpp:1073): cop_status &= 0x7fff (clear bit 15). rtl/Raiden2/Raiden2_cop3.sv:1844 MAME: cop_status &= 0x7fff (clear bit 15). rtl/Raiden2/Raiden2_cop3.sv:1859 MAME LEGACY_cop_cmd_w: find_trigger_match(data, 0xF800) → slot per GRUPPO f800, poi handler dal microcodice caricato. rtl/Raiden2/Raiden2_cop3.sv:1894 MAME execute_6200: cop_read_byte(cop_regs[0]+0x34); su V30 m_byte_endian_val=0 -> nessuno XOR -> byte host 0x34 (pari) = lane bassa della word a 0x34. rtl/Raiden2/Raiden2_cop3.sv:1912 MAME lo esegue come una somma, quindi raddoppia il passo invece di annullarlo. rtl/Raiden2/Raiden2_cop3.sv:1915 MAME execute_0205: read dword at cop_regs[0]+4+offset4 (ppos) rtl/Raiden2/Raiden2_cop3.sv:1936 0x138e / 0x338e — atan(dx/dy) MAME execute_338e. rtl/Raiden2/Raiden2_cop3.sv:1938 Parte da r1+4 hi (offset 0x0004), come 3BB0/MAME. rtl/Raiden2/Raiden2_cop3.sv:1969 0x2208 / 0x2288 - slot 04, MAME execute_2288 (seibucop_cmd.ipp:168) dx = read_word(cop_regs[0] + 0x12) dy = read_word(cop_regs[0] + 0x16) if(!dy){status\|=0x8000; angle=0} else angle=atan(dx/dy)128/pi, +0x80 se dy<0; if(data&0x80) write_byt rtl/Raiden2/Raiden2_cop3.sv:2001 MAME: div = cop_read_word(r0+0x36). rtl/Raiden2/Raiden2_cop3.sv:2049 MAME LEGACY_execute_dde5 (seibucop_cmd.ipp): offs = (offset & 3) * 4 div = read_word(cop_regs[4] + offs) dir_offset = read_word(cop_regs[4] + offs + 8) if (div == 0) div = 1 write_word(cop_regs[6] + offs + 4, (read_word(cop_reg rtl/Raiden2/Raiden2_cop3.sv:2088 MAME: angle = word @ r0+0x34, amp = word @ r0+0x36 (V30: nessuno xor). rtl/Raiden2/Raiden2_cop3.sv:2106 0x7E05 — SOLO Raiden DX (MAME: "raidendx only"). rtl/Raiden2/Raiden2_cop3.sv:2125 Raiden II triggera 0xa100, la famiglia legionna 0xa180: MAME (seibucop.cpp:1164-1167) dispatcha ENTRAMBI su execute_a100. rtl/Raiden2/Raiden2_cop3.sv:2127 allow_swap = data & 0x0080 (seibucop_cmd.ipp:537-540): 0 per a100, 1 per a180 — NON e' costante, va preso dal bit 7. rtl/Raiden2/Raiden2_cop3.sv:2129 MAME cop_collision_read_pos: cop_read_word(spradr+N) = host_read_word((spradr+N)^m_word_endian_val). rtl/Raiden2/Raiden2_cop3.sv:2130 Su V30 il valore e' 0 (seibucop.cpp:291-297): flags @ host+2, pos[i] @ host+6+4i. rtl/Raiden2/Raiden2_cop3.sv:2140 Raiden II triggera 0xa900 (seibucop.cpp:1169-1172 e :625); allow_swap = data & 0x0080 (seibucop_cmd.ipp:548-551). rtl/Raiden2/Raiden2_cop3.sv:2153 b000 NON e' un no-op: il dispatcher LEGACY di godzilla (seibucop.cpp:1365) matcha con mask 0xf800, quindi la patch init_godzilla (b100->b000) ESEGUE comunque l'update ma con num_axis=2 (bit8=0 = Z disattivata). rtl/Raiden2/Raiden2_cop3.sv:2175 MAME execute_2a05 (seibucop_cmd.ipp:193): delta = read_word (cop_regs[1] + 0x1e + offset4) (cop_regs[0] + 4 + 2 + offset4) += delta (cop_regs[0] + 0x1e + offset4) += delta Le write_dword di MAME su una somma a 16 bit sono una svista rtl/Raiden2/Raiden2_cop3.sv:2313 Mode 4 (SEIBUCUP/Denjin, seibucop_dma.ipp:87-117): indice = (val2)[4:0], val 0x0010/0xFFFF = TARGET PURO, NESSUN bypass bit15. rtl/Raiden2/Raiden2_cop3.sv:2360 MAME: m_host_space->write_word(dst, pal_val) — dst ASSOLUTO. rtl/Raiden2/Raiden2_cop3.sv:2402 MAME (0x118 e 0x116): write_dword(i, v1 \| v2<<16) su spazio LE V30 → word a i = v1, word a i+2 = v2 (alternati; su 68k BE era l'opposto). rtl/Raiden2/Raiden2_cop3.sv:2415 Macro 0x0205 — linear movement (MAME execute_0205) ppos = read_dword(cop_regs[0]+0x04) vel = read_dword(cop_regs[0]+0x10) npos = ppos + vel write_dword(cop_regs[0]+0x04, npos) delta = (npos>>16) - (ppos>>16) write_word(cop_regs[0]+0x1E, re rtl/Raiden2/Raiden2_cop3.sv:2473 MAME cop_read/write_word(cop_regs[0]+0x1e). rtl/Raiden2/Raiden2_cop3.sv:2493 Macro 0x0905/0x0904 — jump (MAME execute_0904) write_dword(cop_regs[0]+0x10, read_dword(cop_regs[0]+0x10) ± read_dword(cop_regs[0]+0x28)) 0x0905 (bit 0=1) = +, 0x0904 (bit 0=0) = - rtl/Raiden2/Raiden2_cop3.sv:2519 MAME execute_0904: bit 0 di data = 1 → add, =0 → sub. rtl/Raiden2/Raiden2_cop3.sv:2552 0x138E/0x338E atan(dx/dy) — MAME execute_338e (cmd.ipp:159) dx = read_dword(r1+4) - read_dword(r0+4) dy = read_dword(r1+8) - read_dword(r0+8) if(!dy){status\|=0x8000; angle=0} else angle=atan(dx/dy)128/pi; dy<0→+0x80 if(data&0x80) write_byt rtl/Raiden2/Raiden2_cop3.sv:2603 MAME: angle = atan(dx/dy)128/pi (+0x80 se dy<0). rtl/Raiden2/Raiden2_cop3.sv:2605 Cosi' z = atan(dx/dy) e il +0x80 (in WR) copre solo il quadrante, come MAME. rtl/Raiden2/Raiden2_cop3.sv:2607 NIENTE prescale: i dword diff sono FIXED-POINT coord<<16 (come il 3BB0 che usa dx32[31:16] e MAME dx>>16), NON interi piccoli. rtl/Raiden2/Raiden2_cop3.sv:2656 MAME (int)(...) tronca VERSO ZERO. rtl/Raiden2/Raiden2_cop3.sv:2658 BUG TROVATO (validato vs MAME su 29241 casi): il CORDIC SOTTO-CONVERGE di 1 LSB sulle DIAGONALI (es. rtl/Raiden2/Raiden2_cop3.sv:2663 Compenso l'epsilon di sotto-convergenza con +1 toward-zero PRIMA del troncamento: bias=1 azzera tutte le 133 divergenze (bias=0) -> 0/29241 vs MAME. rtl/Raiden2/Raiden2_cop3.sv:2672 MAME execute_338e (seibucop_cmd.ipp:175-188): la write dell'angolo in RAM (obj+0x34 host, gated da data&0x80) e' FUORI dall'if/else di dy -> avviene SEMPRE, anche a dy==0 (dove cop_angle=0 -> scrive 0^0x80 = 0x80). rtl/Raiden2/Raiden2_cop3.sv:2678 Ora calcolo ang_byte in entrambi i rami e scrivo SEMPRE, come MAME. rtl/Raiden2/Raiden2_cop3.sv:2685 Scrivere l'angolo anche a dy==0 ("1:1 MAME") REGREDISCE: il martello scivola/moonwalk. rtl/Raiden2/Raiden2_cop3.sv:2688 MAME: dy==0 -> cop_angle=0 rtl/Raiden2/Raiden2_cop3.sv:2695 Il chip lavora in PIXEL: le tabelle del bootleg mettono distanza e angolo nella STESSA word, indicizzata da (A<<9)\|B con A,B a 9 bit (la documentazione del progetto), e il nostro stesso 3bb0 tronca gia' i delta con dx32[31:16] (come MAME m_ rtl/Raiden2/Raiden2_cop3.sv:2706 Stesso difetto in MAME (if (!dx) sui 32 bit), da cui il sintomo identico nei due emulatori. rtl/Raiden2/Raiden2_cop3.sv:2714 118e/e18e len 4 -> caricano solo dx/dy: NON scrivono 130e/e30e len 7 -> calcolano l'angolo, non lo scrivono 138e/e38e len 8 -> scrivono Con la regola del bit 7 (quella di MAME) e18e sovrascrive obj+$37 su tutti gli oggetti ogni frame, fra i rtl/Raiden2/Raiden2_cop3.sv:2725 SEIBUCUP: write RAW — il ROM carica il microcode 138e variante cupsoc/SDGundam (tabella $498: ...b9a b9a A9A) = MAME LEGACY_execute_130e_cupsoc, SENZA ^0x80 (il ^0x80 e' della variante famiglia $B9A / is_yflip: legionna). rtl/Raiden2/Raiden2_cop3.sv:2729 PROVA sim 8 casi: col ^0x80 vettore sincos INVERTITO 180° vs MAME → boss 138e-driven marcia via (stage 4). rtl/Raiden2/Raiden2_cop3.sv:2731 ⛔ NON toccare il sincos (lookup diretto = sin MAME): toccarlo inverte i game-written = regressione build 13. rtl/Raiden2/Raiden2_cop3.sv:2744 0x2208 / 0x2288 (slot 04) - MAME execute_2288 (seibucop_cmd.ipp:168) Microcodice ROM: f8a b8a 388 b9a b9a a9a (valu 5, mask f5df). rtl/Raiden2/Raiden2_cop3.sv:2749 MAME li mette in un int partendo da read_word() che ritorna uint16 -> zero-esteso -> il suo stesso 'if (dy < 0)' e' codice MORTO e l'angolo cade sempre nel primo quadrante. rtl/Raiden2/Raiden2_cop3.sv:2837 MAME: !dy -> cop_status \|= 0x8000, cop_angle = 0. rtl/Raiden2/Raiden2_cop3.sv:2847 La write in RAM dipende dal bit 7 del trigger (MAME data&0x80), che qui coincide con la regola della LUNGHEZZA usata dal 138e: len = ((cmd>>7)&7)+1 -> 2288 len 6 = esegue anche l'ultima word 'a9a' (lo store), 2208 len 5 si ferma prima. rtl/Raiden2/Raiden2_cop3.sv:2865 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197) dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (aritmetico) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = sqrt(dxdx + dydy) if(data&0x80) write_word(r0 + (data&0x200?0x3a:0x38 rtl/Raiden2/Raiden2_cop3.sv:2932 E' il TODO dichiarato in MAME. rtl/Raiden2/Raiden2_cop3.sv:2984 MAME: macro completata → cop_status = 7 (gate-poll del gioco). rtl/Raiden2/Raiden2_cop3.sv:3050 MAME: if (div == 0) div = 1 rtl/Raiden2/Raiden2_cop3.sv:3061 In MAME read_word e' unsigned e dir_offset int16_t: la somma e' int, la divisione int/int -> troncamento VERSO ZERO. rtl/Raiden2/Raiden2_cop3.sv:3125 0x8100/0x8900 sin/cos (MAME execute_8100/8900) raw_angle = cop_read_word(cop_regs[0]+0x34) & 0xff amp = (65536>>5) * (cop_read_word(cop_regs[0]+0x36) & 0xff) = 2048 * amp_byte if (raw_angle == 0xC0 sin / 0x80 cos): amp = 2 res = int( rtl/Raiden2/Raiden2_cop3.sv:3175 MAME special-case: sin && raw==0xC0 OR cos && raw==0x80 → amp = 2 rtl/Raiden2/Raiden2_cop3.sv:3202 ── write_dword su V30 LITTLE-ENDIAN (2026-08-14) ────────────── MAME: write_dword(cop_regs[0]+0x10 sin / +0x14 cos, res). rtl/Raiden2/Raiden2_cop3.sv:3210 PROVA DAL ROM (non da MAME): dopo OGNI 8100 il gioco esegue `sar word [bp+0x12],1` + `rcr word [bp+0x10],1` ($0AB121, $0A6D0B) = shift aritmetico a 32 bit con la word ALTA a +0x12; idem `sar [bp+0x16]`/`rcr [bp+0x14]` dopo ogni 8900. rtl/Raiden2/Raiden2_cop3.sv:3237 0xa180/0xa980 — read pos (MAME cop_collision_read_pos) flags_swap = cop_read_word(spradr+2) → host_read_word(spradr+0) pos[0] = cop_read_word(spradr+6) → host_read_word(spradr+4) pos[1] = cop_read_word(spradr+10) → host_read_word( rtl/Raiden2/Raiden2_cop3.sv:3244 Però MAME cop_read_word(+2) = host_read_word(+2^2) = host_read_word(+0). rtl/Raiden2/Raiden2_cop3.sv:3255 rdata = word @ host+0 = flags (MAME cop_read_word(spradr+2) ^ 2). rtl/Raiden2/Raiden2_cop3.sv:3264 rdata = word @ host+4 = pos[0] (Y axis per MAME) rtl/Raiden2/Raiden2_cop3.sv:3284 0xb100/0xb900 — update hitbox & compute intersection (1:1 MAME cop_collision_update_hitbox, seibucop.cpp:1003-1065). rtl/Raiden2/Raiden2_cop3.sv:3293 V30: extraxor=0 (seibucop.cpp:1008) e read_byte(pari)=lane bassa → stesse lane del 68k (extraxor=1 + read_byte(pari)=lane alta): NON toccare. rtl/Raiden2/Raiden2_cop3.sv:3326 2 assi (b000/b800): terza word NON letta, dx/size azzerati (seibucop.cpp:1014-1022) rtl/Raiden2/Raiden2_cop3.sv:3359 2 assi: l'asse 2 (Z) NON viene aggiornato (loop MAME i<num_axis) rtl/Raiden2/Raiden2_cop3.sv:3378 res init: 3 assi = 111, 2 assi = 011 (seibucop.cpp:1038-39: bit Z gia' 0 = "collide banale" -> hit deciso solo da X/Y) rtl/Raiden2/Raiden2_cop3.sv:3402 LEGACY 6880 — carica rel_xy per il prossimo c480 (MAME LEGACY_execute_6980: rel_xy = read_word(spr_src+4+offs)) rtl/Raiden2/Raiden2_cop3.sv:3423 LEGACY c480 — single-step sprite DMA (MAME LEGACY_execute_c480): info = read(spr_src+offs) + (param & 0x3f) -> entry+0 abs = read(regs[0]+8/+4) - spr_dma_abs_x/y X(fx/dx/rel_x) -> entry+4 (+ x_clip per l'inc $410) Y(fy/rel_y) -> entry+6 rtl/Raiden2/Raiden2_cop3.sv:3538 E' la variante FAMIGLIA => MAME execute_6200 (seibucop_cmd.ipp:337), primary_reg=0 / primary_offset=0x34. rtl/Raiden2/Raiden2_cop3.sv:3567 wrap a signed 8-bit (MAME: +=/-=256 su int) rtl/Raiden2/Raiden2_cop3.sv:3592 MAME execute_6200: cop_write_byte(cop_regs[0]+0x34). rtl/Raiden2/Raiden2_cop3.sv:3603 5105 / f105 — MOLTIPLICATORE 16.16 (nessun handler in MAME: ricavato da ROM + disasm di cupsoc). rtl/Raiden2/Raiden2_cop3.sv:3689 Z-sorting DMA ($1006FE) — MAME dma_zsorting (seibucop_dma.ipp:164) n = data+1 val = read_word(lookup + 2i) (RAW, senza xor) key = (int16)cop_read_word(sort_ram + val) (host (addr)^2, CON SEGNO) param 1 = crescente, 2 = rtl/Raiden2/Raiden2_cop3.sv:3732 Bubble sort: swap SOLO se strettamente fuori ordine = stabile come lo std::stable_sort di MAME. rtl/Raiden2/Raiden2_cop3.sv:3749 (Difetto presente da sempre, anche nel core _old: li' la parte COP della lista cadeva in Main RAM e la sua assenza non si notava.) Ora ogni emissione e' spostata di uno stato in avanti, cosi' il latch allo stato N+2 riceve esattamente il ca rtl/Raiden2/Raiden2_main_top.sv:246 Raiden DX: il banco programma lo scrivono DUE registri e vale l'ULTIMO (MAME: raiden2_bank_w da $6CB fa set_entry(BIT(~data,7)), raidendx_cop_bank_2_w da $470 fa set_entry(cop_bank>>12); su DX restano mappati entrambi). rtl/Raiden2/Raiden2_main_top.sv:259 MAME riapplica anche set_entry(cop_bank>>12), che una write a byte non cambia: qui basta marcare che l'ultimo a scrivere il banco e' $470. rtl/Raiden2/Raiden2_main_top.sv:269 Packing banchi tile (raiden2_v.cpp, trascritto dalla _old maincpu_map): $6CC byte basso: bg = (d&1)<<1 → 0/2 ; mid = 1\|(d&2) → 1/3 $470 byte alto : fg = 4\|(d>>14) → 4..7 (aggiornato solo con be[1], qui ricomposto dal registro cop_bank già l rtl/Raiden2/Raiden2_main_top.sv:282 fg SOLO su write $470 be[1] (semantica commit/MAME: bank_reset tiene fg=6 finche' il gioco non scrive cbank; ricalcolarlo ogni clock lo forzava a 4 subito dopo il reset). rtl/Raiden2/Raiden2_main_top.sv:286 Raiden DX : fg = 4 \| ((cop_bank>>4)&3) -> bit 5-4, e MAME lo aggiorna a OGNI write di $470 (raiden2_v.cpp raidendx_cop_bank_2_w). rtl/Raiden2/Raiden2_main_top.sv:303 ─── Latch buffered spriteram: write CPU a $68E (raiden2.cpp:623) ─────── NON a vblank come Raiden 1: e' il GIOCO a decidere quando fotografare la lista sprite. rtl/Raiden2/Raiden2_main_top.sv:426 MAME raiden2.cpp:1126-1127: irq0_line_hold + vector_r 0xC0/4. rtl/Raiden2/Raiden2_main_top.sv:535 Raiden II: la copia nel buffer parte dalla write CPU a $68E, non dal vblank (BUFFERED_SPRITERAM16 comandata dal gioco, raiden2.cpp:623). rtl/Raiden2/Raiden2_main_top.sv:551 Equivale a MAME tilemap render fine-frame. rtl/Raiden2/Raiden2_main_top.sv:655 ── SPLIT STAGING/RENDER (semantica MAME 2-stadi, pattern _old) ──────── STAGING (array qui sotto) = host RAM: porta A = CPU (+fill COP), porta B = sorgente del DMA. rtl/Raiden2/Raiden2_main_top.sv:657 RENDERER (array _rend) = scritti SOLO dal DMA 0x14/0x15, letti dal video: coppia contenuto/scroll atomica come MAME. rtl/Raiden2/Raiden2_main_top.sv:1016 ─── control_w $0E006 (8-bit) ────────────────────────────────────────── MAME bit 0: BG dis, bit 1: FG dis, bit 2: TX dis, bit 3: SPR dis bit 6: flipscreen rtl/Raiden2/Raiden2_main_top.sv:1031 ─── Sound seibu ($00700-$0071F, 8-bit umask 00FF) ───────────────────── MAME main_r/main_w(offset>>1): registro seibu = (byte-$700)/4 = cpu_addr[4:2] (fix coin della _old: con [4:1] ogni registro tranne 0 era misaddressato e la coin non ven rtl/Raiden2/Raiden2_seibu_crtc.sv:23 Seibu CRTC fedele a MAME (seibu_crtc.cpp). rtl/Raiden2/Raiden2_seibu_crtc.sv:55 Raiden DX / Sky Smasher: registri [0x10] e [0x20] SCAMBIATI (MAME seibu_crtc.cpp read_alt/write_alt). rtl/Raiden2/Raiden2_seibu_crtc.sv:177 MAME mappa: bit0=screen0(BG), bit1=screen2(MG), bit2=screen1(FG), bit3=screen3(Text) (vedi seibu_crtc.cpp commento "screen 0=BG, screen 1=FG, screen 2=MG, screen 3=Text") In SD Gundam dcon.cpp layer_en_w gira la maschera così: ~layer_en bit rtl/Raiden2/Raiden2_seibu_crtc.sv:186 Il dispatcher MAME usa "if (BIT(~m_layer_en, n))" per saltare = layer disabilitato quando il bit è 1. rtl/Raiden2/Raiden2_seibu_crtc.sv:191 Raiden2 layer ordering (legionna_v.cpp:384-390 screen_update_SEIBUCUP): bit 0 = BG (background) bit 1 = MG (midground) bit 2 = FG (foreground) bit 3 = Text bit 4 = Sprites ATTENZIONE: e' l'OPPOSTO di legionna (screen_update_legionna :342-34 rtl/Raiden2/Raiden2_seibu_crtc.sv:212 Scroll-base 0x2C-0x3A (seibu_crtc.cpp:243 layer_scroll_base_w; screen0=BG, screen2=MG, screen1=FG, screen3=Text). rtl/Raiden2/Raiden2_seibu_crtc.sv:213 Raw esce qui; le formule (delta vs riferimento godzilla, Y invertita come il set_scrolldy(0x1ef-data) di MAME) stanno nel top. rtl/Raiden2/Raiden2_sprite_renderer.sv:25 Formato spriteram quasi identico (entrambi MAME sei021x_sei0220_spr.cpp) — differenze: - Spriteram @ 0x105000-0x105FFF (4KB, 1024 word, 256 entry × 4 word) - w3 bit 15 = tile bank extra bit (denjinmk usa, Raiden2 base = 0) rtl/Raiden2/Raiden2_sprite_renderer.sv:30 Format word (legionna_v.cpp:288-312): w0 bit 15 = enable (0=draw, 1=skip — TODO verify Raiden2) w0 bit 14 = flip_x w0 bit 13 = flip_y (??? rtl/Raiden2/Raiden2_sprite_renderer.sv:46 Priority callback legionna_v.cpp:314-317: pri_mask[0] = 0x0000 (sopra tutto) pri_mask[1] = 0xFFF0 pri_mask[2] = 0xFFFC pri_mask[3] = 0xFFFE rtl/Raiden2/Raiden2_sprite_renderer.sv:139 CUPSOC: spriteram 2KB → 256 entry (MAME size/2/4 = 2048/2/4 = 256). rtl/Raiden2/Raiden2_sprite_renderer.sv:145 Decoded fields — MAME sei0210_device::draw (non-alt format, riga 143): if (BIT(~spriteram[i], 15)) continue; → draw quando w0[15]==1. rtl/Raiden2/Raiden2_sprite_renderer.sv:147 ─── Formato SEI25X_RISE1X (MAME sei25x_rise1x_spr.cpp:88-101) ────────── Raiden II NON usa il formato SEI0211 della famiglia legionna: i campi stanno su bit diversi. rtl/Raiden2/Raiden2_sprite_renderer.sv:162 cupsoc_pri_cb (legionna_v.cpp:319): pri = (w1[15:14] & 2) \| (ext & 1) → livello = {w1[15], w0[6]}. rtl/Raiden2/Raiden2_sprite_renderer.sv:165 CUPSOC: pri_cb STANDARD (legionna_v.cpp pri_cb = mask[pri]) → livello = w1[15:14] pieno, NON il {w1[15],ext} di grainbow (che ha un pri_cb suo). rtl/Raiden2/Raiden2_sprite_renderer.sv:181 MAME SEI0211 default m_xoffset/m_yoffset = 0 (sei021x_sei0220_spr.cpp:40-41). rtl/Raiden2/Raiden2_sprite_renderer.sv:182 Raiden2 NON chiama set_offset (legionna.cpp:1214) → offset 0,0. rtl/Raiden2/Raiden2_sprite_renderer.sv:221 Tile code finale Y-MAJOR (MAME draw_internal: ax=outer, ay=inner, code++): sub_index = axsizey + ay → cur_tile = code + eff_tile_xsp_h + eff_tile_y Raiden II: NESSUN gfxbank_cb in raiden2.cpp -> il codice va usato tale e quale, ed e' a rtl/Raiden2/Raiden2_sprite_renderer.sv:237 byte_lo = pf_rom_data[31:24]/[15:8], byte_hi = [23:16]/[7:0] Raiden II NON usa il tilelayout planare della famiglia legionna: usa gfx_16x16x4_packed_lsb (raiden2.cpp:1058), cioe' 4bpp PACKED, un nibble per pixel, 8 byte per riga da 16 pixel rtl/Raiden2/Raiden2_sprite_renderer.sv:241 Con readbit() di MAME (0x80>>(bit%8)), planeoffset {0,1,2,3} e xoffset {14,04,34,24,...}: pixel PARI = nibble BASSO del byte, pixel DISPARI = nibble ALTO dello stesso byte, senza rimescolare bit. rtl/Raiden2/Raiden2_sprite_renderer.sv:705 MAME gfx_legionna_spr: color base = 6416 = 0x400 (64 colorset × 16 pen). rtl/Raiden2/Raiden2_text_renderer.sv:25 Specifiche da MAME (legionna.cpp:1117-1126, 1167): rtl/Raiden2/Raiden2_text_renderer.sv:47 Char ROM in MAME: "char" region 64KB = ROM_COPY user1[0x10000..0x1FFFF]. rtl/Raiden2/Raiden2_tile_layer.sv:25 Differenze fra layer (da MAME dcon.cpp): rtl/Raiden2/Raiden2_tile_layer.sv:58 BB FG hardcoded +0x1000 (MAME bloodbro fg_tile_info) rtl/Raiden2/Raiden2_tile_layer.sv:243 Tile index con eventuale gfx_bank (MG ha bit 12 = 13-bit totali, BG/FG = 12 bit) + TILE_CODE_OFS hardcoded (BB FG aggiunge 0x1000 secondo MAME bloodbro fg_tile_info). rtl/Raiden2/Raiden2_tile_layer.sv:310 rom_addr = tile_idx128 + banco0x80000 + side_off + row4 Raiden II: tile = (vram & 0xfff) \| (bank << 12) -> 15 bit (raiden2_v.cpp:162-190 get_back/mid/fore_tile_info; bank 0..7 = 32768 tile = la region "tiles" da 4MB, unica per i 3 layer) rtl/Raiden2/Raiden2_video_timing.sv:25 RAIDEN II — timing dal driver MAME (raiden2.cpp:1134): screen.set_raw(XTAL(32'000'000)/4, 512, 0, 408, 282, 0, 308) cioe' pixel clock 8.000 MHz, 512x282 totali, 320x240 visibili con blanking che parte da 0 su entrambi gli assi (nessuna fi rtl/Raiden2/Raiden2_video_timing.sv:67 ── Pixel clock enable: 96 MHz / 12 = 8.000 MHz ───────────────────────── Raiden II reale (raiden2.cpp:1134 set_raw): XTAL(32 MHz)/4 = 8 MHz. rtl/Raiden2/Raiden2_video_timing.sv:90 ── Constants timing ───────────────────────────────────────────────────── MAME raiden2.cpp:1134 screen.set_raw(XTAL(32'000'000)/4, 512, 0, 408, 282, 0, 308) = pixel clock 8.000 MHz, 512x282 totali, 320x240 visibili. rtl/Raiden2/crypt/raiden2_sprite_decrypt.sv:4 Trascritto da MAME src/mame/seibu/r2crypt.cpp (raiden2_decrypt_sprites + core_decrypt) e seibu_helper.cpp (seibu_partial_carry_sum). rtl/Raiden2/crypt/raiden2_sprite_decrypt.sv:29 ─── Tabelle (estratte da r2crypt.cpp) ────────────────────────────────── rtl/Raiden2/crypt/raiden2_sprite_decrypt.sv:116 ─── somma con riporto parziale (seibu_helper.cpp:12) ─────────────────── Il riporto propaga solo dove CARRY_MASK ha 1; il riporto finale rientra in XOR sul bit 0. rtl/Raiden2/ddram_sprite.sv:58 NIENTE swap per Raiden II: la region "sprites" e' ROM_REGION32_LE nativa e il download scrive gia' plain[15:0] a +0 e plain[31:16] a +2, quindi la dword in DDR3 e' identica a quella di MAME. rtl/Raiden2/raiden2_addr_main.sv:5 Mappa MAME raiden2_mem (raiden2.cpp:626-646), fine-decode del blocco $400-$7FF trascritto dalla maincpu_map della repo _old (quella che bootava): $00000-$003FF RAM (IVT) → ram_memrq $00400-$006FF COP SEI300 rtl/Raiden2/raiden2_addr_main.sv:45 Raiden DX: mappa programma DIVERSA (MAME raidendx_mem). rtl/Raiden2/raiden2_mixer.sv:11 MODELLO (MAME raiden2_v.cpp screen_update + blend_layer): si parte dal fondale NERO e si attraversano gli 8 livelli dal FONDO in avanti — spr0, BG, spr1, MG, spr2, FG, spr3, TEXT. rtl/Raiden2/raiden2_mixer.sv:48 ── tabella: quali indici si mescolano (127 su 2048, da MAME) ─────────── PERCORSO ESPLICITO IN SINTESI: col nome nudo Quartus non la troverebbe (nessun SEARCH_PATH copre rtl/Raiden2) e resterebbe TUTTA A ZERO, cioe' blending inerte sul sili rtl/Raiden2/raiden2_mixer.sv:79 palette xBGR_555 -> RGB888 (espansione MAME palette_device) rtl/Raiden2/raiden2_mixer.sv:135 Trovato dal test contro il modello MAME (sim/tb_mixer.cpp). rtl/Raiden2/raiden2_shared_ram.sv:19 MAME memory map: Main: $08000-$08FFF Sub : $04000-$04FFF rtl/Raiden2/raiden2_sprite_mainbus.sv:4 Raiden sprite RAM bus (pattern Irem M72 board_b_d-style + BUFFERED_SPRITERAM16) Gestisce spriteram (Main side, $07000-$07FFF, 4KB = 2K word) con: - Porta A: Main V30 R/W - Buffer: copia spriteram → buf su rising vblank (MAME BUFFERED_SPRITE rtl/Raiden2/raiden2_sprite_mainbus.sv:10 MAME memory map Main: $07000-$07FFF spriteram (4KB) — share "spriteram" (BUFFERED_SPRITERAM16) rtl/Raiden2/raiden2_sprite_mainbus.sv:110 Copy FSM: trigger = vblank_rising (nel top = sprbuf_trig, write CPU $68E, BUFFERED_SPRITERAM16 come MAME). rtl/Raiden2/sdram_bridge.sv:46 condivisa da BG, MG e FG (raiden2.cpp: i tre layer 16x16 indicizzano tutti gfx 1 con tile 15 bit) 0x290000-0x2AFFFF: OKI1 256KB (ioctl byte 0x520000) Totale 5.5MB sugli 8MB della finestra. rtl/Raiden2/sdram_bridge.sv:325 --- FG address descramble (legionna.cpp:1129 descramble_legionnaire_gfx) --- MAME applica un bitswap<24> agli indirizzi della ROM "fore" durante init: src_descrambled[i] = src_raw[bitswap<24>(i, ... rtl/Raiden2/sdram_bridge.sv:372 bitswap MAME del byte offset rtl/Raiden2/sei80bu.v:4 sei80bu - SEI80BU Encrypted Z80 Interface Implementazione esatta da MAME mame/src/devices/machine/sei80bu.cpp: - data_r: 5 XOR + 2 bitswap (sempre) - opcode_r: 8 XOR + 4 bitswap (data + 3 XOR e 2 bitswap extra solo M1) Determinato runti README.md:13 This core reimplements the hardware in SystemVerilog from MAME references, the ROM microcode tables and hardware observation. Says it matches, follows or was checked against MAME — 7 Raiden2.sv:192 Offset layer COPIATI dalla _old (video HW-perfetto, Raiden2.sv:446-463): TRIM0 = 0 per TUTTI i layer ("esattamente il valore con cui il core girava"), sprite xoff = -1 ("base famiglia, match MAME su HW"), txt xoff = -1. Raiden2.sv:1483 Provato contro un modello scritto dal codice MAME: sim/tb_mixer.cpp, 20000 pixel, ZERO differenze (1957 casi con piu' trasparenze sovrapposte). rtl/Raiden2/Raiden2_cop3.sv:1854 LEGACY sprite-DMA (match a maschera, MAME find_trigger_match): c480 mask $FF00 -> qualunque c4xx; 6880 mask $FFF3. rtl/Raiden2/Raiden2_cop3.sv:3190 res = prod >> 4 (= /16 per matchare formula MAME 2048/32768 = 1/16) rtl/Raiden2/Raiden2_cop3.sv:3713 Verificato in gioco su MAME il 2026-07-29. rtl/Raiden2/Raiden2_sprite_renderer.sv:183 +1 pixel a destra: offset verificato con pixel hunting su MAME (rmonic79). README.md:129 The implementation here (`Raiden2_cop3.sv`) was written from those tables and checked command by command against MAME, including the DMA modes, the sorting used Says it was translated, ported or taken from MAME — 2 rtl/Raiden2/Raiden2_cop3.sv:2873 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197): 1:1 dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (signed) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = floor(sqrt(dxdx + dydy)) if(data&0x80) write_word(r0+(data&0x200?0x3 rtl/Raiden2/Raiden2_cop3.sv:2993 0x42C2/0x4AA0 divide — MAME execute_42c2/4aa0 (cmd.ipp:219/247): 1:1 DIVIDEND = cop_dist << (5 - cop_scale) (cop_scale 0..3 → shift 5..2) 42c2: div=cop_read_word(r0+0x36)→host 0x36; if(!div){status\|=0x8000; write 0 a host 0x38} else write Keeps a MAME approximation — 1 rtl/Raiden2/Raiden2_cop3.sv:253 MAME usa total_cycles%256 (surrogato dell'RNG hw ignoto): l'LFSR e' un surrogato equivalente ma robusto alle letture regolari. Shares text with the MAME driver without saying so — 6 rtl/Raiden2/Raiden2_main_top.sv:273 Reset MAME bank_reset(0,6,1,0): bg=0 fg=6 mid=1. — shares text with seibu/raiden2.cpp:411 rtl/Raiden2/Raiden2_text_renderer.sv:23 Text layer renderer Seibu Raiden2 (8x8, 4bpp, 64x32). Specifiche da MAME (legionna.cpp:1117-1126, 1167): // charlayout 8x8, RGN_FRAC(1,1), 4 b — shares text with seibu/raiden2_v.cpp rtl/Raiden2/Raiden2_video_timing.sv:23 Video timing single-screen Seibu D-Con. RAIDEN II — timing dal driver MAME (raiden2.cpp:1134): screen.set_raw(XTAL(32'000'000)/4, 512, 0, 408, 282 — shares text with seibu/raiden2.cpp:1134 rtl/Raiden2/Raiden2_video_timing.sv:92 screen.set_raw(XTAL(32'000'000)/4, 512, 0, 408, 282, 0, 308) — shares text with seibu/raiden2.cpp:1134 rtl/Raiden2/crypt/raiden2_sprite_decrypt.sv:13 x1lo = (x5[i2] << 11) ^ x11[i3] ^ gm(i4) — shares text with seibu/r2crypt.cpp:211 rtl/Raiden2/sdram_bridge.sv:327 src_descrambled[i] = src_raw[bitswap<24>(i, ... 6,5,15,14,13,12, 11,10,9,8, 7,4, 3..0)] — shares text with seibu/seibu_crtc.cpp:338
RallyX# New Rally-X, Rally-X MiSTer-devel/Arcade-RallyX_MiSTer @ abd3c384 MAME compared: namco/rallyx.cpp + 4 related file(s) Read: 16 HDL files, 5,598 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	1%
Statements: 2 toward MAME Cites MAME source — 2 rtl/nrx_bang.v:4 Fixed-point approximation of the Rally-X discrete explosion circuit modeled in MAME PR 15424. README.md:27 copy ROM zip files to /media/fat/_Arcade/mame
Rampart# Rampart MiSTer-devel/Arcade-Rampart_MiSTer @ 01b708d0 MAME compared: atari/rampart.cpp + 4 related file(s) Read: 39 HDL files, 5,176 lines (Quartus project)	MiSTer official	Both	medium	55%
Statements: 19 toward hardware, 31 toward MAME, 14 not counted Cites hardware documentation that MAME's driver does not — 18 rtl/main/rampart_decode.sv:3 Main CPU address decode: GAL 12C and the two LS138s, 10C and 11C. rtl/main/rampart_decode.sv:67 10C 74LS138: enabled by /A22; C B A = pins 19 18 17. rtl/main/rampart_decode.sv:80 11C 74LS138: enabled by A22 and /IOSEL; C B A = A21 A20 A19. rtl/main/rampart_eeprom.sv:3 EEPROM at 13F (2K x 8, 2816 class) and its write-unlock flop. rtl/main/rampart_gal12c.sv:8 The board build decides which part is fitted: variant 0 = 136082-1006 (set rampart, trackballs: 2 x 64K + 2 x 512K ROMs) variant 1 = 136082-1056 (set rampart2p, joysticks: 2 x 128K + 2 x 512K ROMs) variant 2 = 136082-1005 (sets rampart2pa a rtl/main/rampart_inputs.sv:3 Switch inputs IN0/IN1: the 74LS257 pair at 10B/11B, read at 0x640000. rtl/main/rampart_latch.sv:3 Output latches at 0x640000: 7B 74LS273 (D15-8) and 6C 74LS174 (D5-0). rtl/main/rampart_main.sv:88 ---- latch 7B/6C ---- rtl/main/rampart_watchdog.sv:3 Reset counter and watchdog: the 74LS197 at 7D. rtl/video/rampart_gal4l.sv:7 Generated from the chip's fuse map (jedutil -view), one assign per output, terms in the fuse-map order. rtl/video/rampart_gal7k.sv:7 Generated from the chip's fuse map (jedutil -view), one assign per output, terms in the fuse-map order. rtl/video/rampart_gal8j.sv:7 Generated from the chip's fuse map (jedutil -view), one assign per output, terms in the fuse-map order. rtl/video/rampart_gal8m.sv:7 Generated from the chip's fuse map (jedutil -view), one assign per output, terms in the fuse-map order. rtl/video/rampart_lb.sv:3 Rampart motion-object line buffer: the Lb custom 137536-001 at 1F/H. rtl/video/rampart_mix.sv:7 The priority PAL socket at 2J is empty on production boards, so the mux takes the motion object whenever its pen is not 0. rtl/video/rampart_mob.sv:3 Rampart motion-object processor: the MOB 137593-001 at 2K/L. rtl/video/rampart_sos2.sv:3 Rampart raster counters: the H count that feeds the 7K GAL and the vertical side of the SOS-2 sync generator (Atari 137550-001, 11K/L). README.md:15 The address decoding and the video timing are transcribed from the board's own GAL chips, and the inputs, reset and watchdog, sync, colour output and sound circ Cites hardware references or measurements that MAME's driver also gives — 14 Arcade-Rampart.sv:150 0x460800 0x000002 12C GAL variant code, input panel code — also in MAME: 12C atari/rampart.cpp:531 rtl/main/rampart_gal12c.sv:3 GAL16V8 at 12C: the main CPU address decoder. — also in MAME: 12C atari/rampart.cpp:531 rtl/main/rampart_slapstic.sv:16 /CS = A18 & /A19 & A20 & /A21 (from the 12C GAL): 0x140000- 0x17FFFF and its mirrors. — also in MAME: 12C atari/rampart.cpp:531 rtl/mem/rampart_rom_loader.sv:24 Which CPU addresses select which pair is decided by the 12C GAL, which differs between board variants, so the config byte names the variant: 0x06 = 136082-1006, 0x56 = 136082-1056, 0x05 = 136082-1005. — also in MAME: 12C atari/rampart.cpp:531, 136082-1006 atari/rampart.cpp:531, 136082-1056 atari/rampart.cpp:558, 136082-1005 atari/rampart.cpp:589 rtl/mem/rampart_rom_loader.sv:57 12C GAL variant code — also in MAME: 12C atari/rampart.cpp:531 rtl/rampart_core.sv:200 12C part: 0x06 = 136082-1006, 0x56 = 1056, 0x05 = 1005 — also in MAME: 12C atari/rampart.cpp:531, 136082-1006 atari/rampart.cpp:531 rtl/video/rampart_bitmap.sv:20 WAIT_MODEL = 1 adds the board's slot timing: the 8J GAL (clocked at 14 MHz) holds the CPU until its one slot per group while the raster fetches (8J pin 11 = 7K pin 15 low), and releases it at once in the fetch-free window. — also in MAME: 8J atari/rampart.cpp:529, 8J atari/rampart.cpp:529, 7K atari/rampart.cpp:528 rtl/video/rampart_gal4l.sv:3 4L GAL 136082-1001: motion-object RAM arbiter (GAL16V8, registered). — also in MAME: 4L atari/rampart.cpp:527, 136082-1001 atari/rampart.cpp:527 rtl/video/rampart_gal7k.sv:3 7K GAL 136082-1002: horizontal timing decode (GAL16V8, registered). — also in MAME: 7K atari/rampart.cpp:528, 136082-1002 atari/rampart.cpp:528 rtl/video/rampart_gal8j.sv:3 8J GAL 136082-1003: bitmap DRAM sequencer (GAL20V8, registered). — also in MAME: 8J atari/rampart.cpp:529, 136082-1003 atari/rampart.cpp:529 rtl/video/rampart_gal8m.sv:3 8M GAL 136082-1004: motion-object RAM address mux (GAL20V8). — also in MAME: 8M atari/rampart.cpp:530, 136082-1004 atari/rampart.cpp:530 rtl/video/rampart_moram.sv:18 WAIT_MODEL = 1 uses the 4L GAL (14 MHz) for the CPU wait: its pin 18 releases a CPU access only while no next-line work is pending. — also in MAME: 4L atari/rampart.cpp:527 rtl/video/rampart_video.sv:150 graphics ROM 2N, 128K x 8, loaded as dumped — also in MAME: 2N atari/rampart.cpp:516 README.md:33 The sets differ in their control panel and program-ROM layout, and so in the address-decode GAL fitted at 12C. — also in MAME: 12C atari/rampart.cpp:531 Notes where it differs from MAME — 1 README.md:156 Attract-mode and demo timing can differ from MAME by a frame or two; the game plays the same. Cites MAME source — 29 Arcade-Rampart.sv:24 The MRA also carries MAME's factory EEPROM image, used when there is no save yet. Arcade-Rampart.sv:81 Colour DAC: the board's resistor network (default) or MAME's linear table. Arcade-Rampart.sv:257 IRQ_MODEL 0 is MAME's timing instead (see rtl/main/rampart_irq.sv). rtl/main/rampart_irq.sv:15 The default, -3, lines the interrupts up with MAME's emulation of this board, the only timing reference there is: fx68k needs the request about three clocks earlier than MAME's 68000 to take it at the same instruction. rtl/main/rampart_slapstic.sv:7 The state machine follows MAME's slapstic.cpp (BSD-3-Clause), class 111-118, used here as the functional reference. rtl/main/rampart_slapstic.sv:68 Set to 1 to reset them on every board reset instead, as MAME does. rtl/main/rampart_slapstic.sv:86 Current state in MAME's numbering (0 idle ... rtl/mem/rampart_nvram_io.sv:13 Two load paths: ioctl index 2 is the .nvm restore/save channel; index 0 (the ROM stream) carries MAME's factory EEPROM image at 0x460000 as a seed (seed_we). rtl/rampart_core.sv:25 The defaults follow MAME's timing; Arcade-Rampart.sv changes only IRQ_MODEL. rtl/rampart_core.sv:61 0 = board DAC levels, 1 = MAME's rtl/video/rampart_dac.sv:14 mame = 1 selects the plain linear scale instead, (code << 2) \| (code >> 4), with no clamp. README.md:17 Atari never published the pages for the CPU, the video RAMs and the custom chips, so MAME's Rampart driver filled those gaps. README.md:19 Where the board and MAME differ, the core follows the board; the differences you may notice are listed below. README.md:45 Put the ROM zips in `games/mame/` (see below). README.md:53 The factory EEPROM image that MAME keeps in the set is used the first time a set is run. README.md:98 \| Colour levels \| Board DAC, MAME \| Board DAC \| see below \| README.md:109 `Board DAC` reproduces the board's colour output circuit: each gun is a resistor ladder with a pull-up and a black clamp, so black is true black but every lit l README.md:113 `MAME` uses MAME's plain linear scale instead. README.md:134 Differences from MAME you may notice README.md:136 Colours. With `Board DAC`, colours follow the board's resistor network: dark colours are brighter and contrast is lower than with MAME's linear palette. README.md:141 The sound is therefore softer at the top end than MAME's unfiltered mix. README.md:142 When the game lowers the ADPCM level, the board attenuates it rather than muting it as MAME does. README.md:145 MAME draws the picture in four bands, so a change made mid-frame can appear a few lines lower, or a frame later, in MAME than on the board. README.md:150 MAME resets the SLAPSTIC on every reset. README.md:152 The core uses the one Atari drew for the closely related Klax board, which interrupts at lines 64, 128 and 192 and at the start of vertical blank (line 240); MA README.md:158 CPU timing. The 68000 is a cycle-exact model of the real chip, so instruction timing can differ slightly from MAME's 68000. README.md:167 whether the board adds CPU wait states for its slower chips (the core, like MAME, adds none); README.md:169 where two motion objects overlap, which one is drawn on top (the core follows MAME: the later one in the list); README.md:198 The MAME team: the Rampart driver served as a functional reference, and the MAME sets preserve the GAL fuse maps the core's address decoding and video timing ar Says it matches, follows or was checked against MAME — 2 rtl/video/rampart_lb.sv:20 Which one the chip does is not known; 0 matches MAME. README.md:138 Choose `MAME` to match MAME.
ReliefPitcher# Relief Pitcher MiSTer-devel/Arcade-ReliefPitcher_MiSTer @ f079a574 MAME compared: atari/relief.cpp + 4 related file(s) Read: 38 HDL files, 4,458 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	14%
Statements: 2 toward hardware, 2 toward MAME, 8 not counted Cites hardware documentation that MAME's driver does not — 2 rtl/main/relief_dtack.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Wait-state counter (a 74F163 on the board) that times DTACK for the CPU. README.md:9 The core was built from the schematic sheets in Atari's TM-376 manual and the logic read from the board's GAL chips, with MAME 0.289 as a reference where those Cites hardware references or measurements that MAME's driver also gives — 8 rtl/gal/relief_gal_0002.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Atari 136093-0002, a GAL16V8 at 15F: main address decoder. — also in MAME: 136093-0002 atari/relief.cpp:618, 15F atari/relief.cpp:618 rtl/gal/relief_gal_0003.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Atari 136093-0003, a GAL16V8 at 11R. — also in MAME: 136093-0003 atari/relief.cpp:619, 11R atari/relief.cpp:619 rtl/gal/relief_gal_0004.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Atari 136093-0004, a GAL16V8 at 5N. — also in MAME: 136093-0004 atari/relief.cpp:620, 5N atari/relief.cpp:620 rtl/gal/relief_gal_0005.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Atari 136093-0005, a GAL16V8 at 3F: colour select and upper pixel bits. — also in MAME: 136093-0005 atari/relief.cpp:621, 3F atari/relief.cpp:621 rtl/gal/relief_gal_0006.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Atari 136093-0006, a GAL16V8 at 5F: low pixel bits and transparent-pen detection. — also in MAME: 136093-0006 atari/relief.cpp:622, 5F atari/relief.cpp:622 rtl/gal/relief_gal_0008.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Atari 136093-0008, a GAL16V8 at 3E on the audio daughterboard. — also in MAME: 136093-0008 atari/relief.cpp:623, 3E atari/relief.cpp:623 rtl/gal/relief_gal_0009.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Atari 136093-0009, a GAL16V8 at 8A on the audio daughterboard. — also in MAME: 136093-0009 atari/relief.cpp:624, 8A atari/relief.cpp:624 rtl/gal/relief_gal_0010.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Atari 136093-0010, a GAL16V8 at 15A: daughterboard address decoder. — also in MAME: 136093-0010 atari/relief.cpp:625, 15A atari/relief.cpp:625 Cites MAME source — 2 Arcade-ReliefPitcher.sv:513 Keys follow MAME, plus F1 for a service credit and F2 for the self-test switch. README.md:9 The core was built from the schematic sheets in Atari's TM-376 manual and the logic read from the board's GAL chips, with MAME 0.289 as a reference where those
RingKing# King of Boxer MiSTer-devel/Arcade-RingKing_MiSTer @ 51cbc3c3 MAME compared: dataeast/kingofb.cpp Read: 22 HDL files, 7,825 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	0%
No statements found
RiverPatrol# River Patrol MiSTer-devel/Arcade-RiverPatrol_MiSTer @ 2319de92 MAME compared: nichibutsu/cclimber.cpp Read: 15 HDL files, 6,263 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	10%
Statements: 1 toward MAME Cites MAME source — 1 rtl/ym_2149_linmix.vhd:44 Clues from MAME sound driver and Kazuhiro TSUJIKAWA
Robotron# Alien Arena, Blaster, Bubbles, Joust … MiSTer-devel/Arcade-Robotron_MiSTer @ 562a5dac MAME compared: williams/williams.cpp + 5 related file(s) Read: 16 HDL files, 12,567 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	12%
Statements: 5 toward MAME Cites MAME source — 1 rtl/hc55564.vhd:4 This is a VHDL port of the MAME C++ CVSD emulator. Says it matches, follows or was checked against MAME — 1 rtl/sc1.vhd:127 test blits 20k 16x16 blit in normal and same with slow flag match mame timing now Shares text with the MAME driver without saying so — 3 rtl/williams_cpu.vhd:348 clock 0 1 2 3 4 5 6 7 8 9 10 11 — shares text with williams/williamsblitter.cpp:50 rtl/williams_cpu.vhd:349 Q 0 0 0 1 1 1 1 1 1 0 0 0 — shares text with williams/williams.cpp:448 rtl/williams_cpu.vhd:350 E 0 0 0 0 0 0 1 1 1 1 1 1 — shares text with williams/williams.cpp:448
RshnAtk# Green Beret, Mr. Goemon MiSTer-devel/Arcade-RushnAttack_MiSTer @ f6e6ab36 MAME compared: konami/gberet.cpp + 5 related file(s) Read: 16 HDL files, 5,789 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	0%
No statements found
Salamander# Salamander MiSTer-devel/Arcade-Salamander_MiSTer @ 99a6e3fd MAME compared: konami/nemesis.cpp + 3 related file(s) Read: 31 HDL files, 12,215 lines (Quartus project)	MiSTer official	Both	low	67%
Statements: 4 toward hardware, 10 toward MAME Cites hardware documentation that MAME's driver does not — 3 rtl/Salamander_sound.v:389 GX587 output filters, sheet 2/2 FM C44 33n sees R82 1K \|\| (R83 1K + R14 1K) = 667R -> 7.2kHz PCM C28 470p sees (ladder 100K + R51 20K) \|\| R39/R40 23K5 = 19K65 -> 17.2kHz rtl/ipcores/K007232.v:33 A fully synchronous model for Konami 007232 dual-channel PCM player based on the Furrtek's die shot based schematics: README.md:2 Current status: Fixable, custom chip known as K005295 will be decapped. Says it was checked on “real hardware” — 1 rtl/GX400_video/K005295.v:478 This has been confirmed by running test ROM on real hw. Cites MAME source — 4 rtl/GX400_video/K005293.v:180 The chip showed us a total of 26 results and suggested that the source of MAME was a very empirical result. rtl/Salamander_cpu.v:428 io0_cs C0001 : soundlatch C0002-3 : DSW0(MAME); DIPSW1(PCB) C0004-5 : watchdog rtl/Salamander_cpu.v:433 io1_cs C2000-1 : IN0(MAME); DIPSW3(PCB)[2:0], coin/start C2002-3 : IN1(MAME); DIPSW3(PCB)[3], p1 C2004-5 : IN2(MAME); p2 C2006-7 : DSW1(MAME); DIPSW2(PCB) rtl/Salamander_emu.v:54 start addr length comp num mame rom parts num location description Shares text with the MAME driver without saying so — 6 Salamander.sv:216 0 1 2 3 4 5 6 — shares text with konami/nemesis.cpp:2898 rtl/GX400_video/GX400_video.v:355 FETCHES HSCROLL(1 PIXEL ROW) VALUE WHEN VCLK = 1 MCLK 0 1 2 3 4 5 0 1 2 3 4 5 CLK18M _\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\| — shares text with konami/nemesis.cpp rtl/GX400_video/GX400_video.v:499 MCLK 0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5 CLK18M _\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯ — shares text with konami/nemesis.cpp rtl/GX400_video/GX400_video.v:742 MCLK 1 1 0 1 2 3 4 5 6 7 8 9 0 1 CLK18M _\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯ — shares text with konami/nemesis.cpp:2898 rtl/GX400_video/K005290.v:38 pixel 0 1 2 3 4 5 6 7 1H _\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\| 2H ___\|¯¯¯ — shares text with konami/nemesis.cpp:2898 rtl/ipcores/vlm5030_gl/vlm5030_gl.vhd:1343 9 8 7 6 5 4 3 2 1 0 — shares text with konami/nemesis.cpp:279
ScooterShooter# Scooter Shooter MiSTer-devel/Arcade-ScooterShooter_MiSTer @ 8d211dbf MAME compared: konami/scotrsht.cpp + 1 related file(s) Read: 9 HDL files, 6,674 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	8%
Statements: 1 toward hardware Cites hardware documentation that MAME's driver does not — 1 rtl/ScooterShooter.sv:526 Scooter Shooter also uses 3 switchable low-pass filters on the SSG side of its YM2203 with a cutoff frequency of 723.432Hz (actually closer to 492.130Hz due to internal resistance inside the 74HC4066 handling the filter switching).
Scramble# Amidar, Anteater, Armored Car, Battle of Atlantis … MiSTer-devel/Arcade-Scramble_MiSTer @ 3712a29c MAME compared: galaxian/galaxian.cpp, galaxian/scobra.cpp, galaxian/scramble.cpp + 12 related file(s) Read: 14 HDL files, 5,467 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	11%
Statements: 1 toward MAME Cites MAME source — 1 rtl/YM2149_linmix_sep.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA
SDGundamPS# SD Gundam Psycho Salamander no Kyoui MiSTer-devel/Arcade-GundamSD_MiSTer @ 957fc714 MAME compared: seibu/dcon.cpp + 4 related file(s) Read: 20 HDL files, 6,275 lines (Quartus project)	MiSTer official	Mostly MAME	medium	59%
Statements: 3 toward hardware, 50 toward MAME Cites hardware documentation that MAME's driver does not — 2 rtl/GundamSD/GundamSD_main_top.sv:31 Memory map SD Gundam (da MAME dcon.cpp + SD Gundam override): $000000-$07FFFF ROM 68K (512KB) $080000-$08BFFF Main RAM (48KB) $08C000-$08C7FF BG tile RAM (2KB) $08C800-$08CFFF FG tile RAM (2KB) $08D000-$08D7FF MG tile RAM rtl/GundamSD/GundamSD_maincpu_map.sv:29 Memory map SD Gundam (da MAME dcon.cpp + sdgndmps_map override): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $080000-$08BFFF Main RAM (48KB) → BRAM $08C000-$08C7FF BG tile RAM → BRAM dual-port $08C800-$ Reports a measurement taken on the original PCB — 1 rtl/GundamSD/GundamSD_video_timing.sv:26 PCB measurement Blood Bros: VSync 59.4094 Hz, HSync 15.6246 kHz, master XTAL 20 MHz. Cites MAME source — 45 GundamSD.sv:297 --- Joystick to SD Gundam input mapping --- MAME P1_P2 port ($E0002): active low. GundamSD.sv:625 ── Flip screen (CRTC reg 0x1A bit 0) ─────────────────────────────────────── MAME: BIT(reg_1a, 0) → flip_screen. GundamSD.sv:667 SD Gundam Text scroll fissi: 128 X (MAME), 16 Y (centratura HW reale) GundamSD.sv:707 MAME +128 X + offset HW Y +16 (centratura calibrata su PCB Seibu D-Con) GundamSD.sv:812 Pixel pipeline con sprite + priority callback (MAME pri_cb dcon.cpp). GundamSD.sv:813 pri_code semantics (MAME pri_mask 0xF0/0xFC/0xFE/0): pri=3 → sprite ABOVE ALL (mask=0, copre Text/FG/MG/BG, INSERT COIN, HUD) pri=0 → sprite ABOVE FG (copre FG, MG, BG; coperto solo da Text) pri=1 → sprite ABOVE MG (copre MG, BG; coperto rtl/GundamSD/GundamSD_audio_z80.sv:25 Spec da MAME (reference/mame_seibu/seibusound.cpp + dcon.cpp): - Z80A @ 14.31818 MHz / 4 = 3.579545 MHz - YM2151 (jt51) @ 14.31818 / 4 = 3.579545 MHz - OKI M6295 (jt6295) @ 20 MHz / 16 = 1.25 MHz, PIN7=LOW rtl/GundamSD/GundamSD_audio_z80.sv:173 MAME audiocpu region layout (sdgndmps): rtl/GundamSD/GundamSD_audio_z80.sv:257 ─── ROM bank register (Z80 0x4007: bit0 → bank 0/1) ───────────────────── MAME seibu_sound_device::bank_w: m_rom_bank->set_entry(BIT(data,0)) rtl/GundamSD/GundamSD_audio_z80.sv:328 Main writes to 0xA0008 (MAME offset 4) → assert RST18 snd_addr = bus_addr[3:1], 0xA0008 → bit[3:1]=100 = 4 rtl/GundamSD/GundamSD_audio_z80.sv:354 ─── Soundlatch main_w/r logic ────────────────────────────────────────── snd_addr = bus_addr[3:1] = offset/2 (0=word 0, 1=word 1, 2=word 2, 3=word 3, 4=word 4, 5=word 5, 6=word 6) MAME usa byte access (umask16 0x00ff = byte basso). rtl/GundamSD/GundamSD_audio_z80.sv:356 Mappa offset MAME → snd_addr: offset 0 (0xA0000) → snd_addr 0 offset 1 (0xA0002) → snd_addr 1 offset 2 (0xA0004) → snd_addr 2 offset 3 (0xA0006) → snd_addr 3 offset 5 (0xA000A) → snd_addr 5 offset 6 (0xA000C) → snd_addr 6 rtl/GundamSD/GundamSD_audio_z80.sv:372 Main writes (MAME seibu_sound_device::main_w): case 0/1: m_main2sub[offset] = data case 4: update_irq_lines(RST18_ASSERT) — gestito sopra case 2/6: pending flags (sub2main=0, main2sub=1) rtl/GundamSD/GundamSD_audio_z80.sv:380 MAME case 2/6 rtl/GundamSD/GundamSD_audio_z80.sv:387 Z80 reads soundlatch (→ MAME implicit: nessun side effect) Z80 writes sub2main rtl/GundamSD/GundamSD_audio_z80.sv:401 MAME sdgndmps_sound_comms_r override (dcon.cpp:288): offset 5 hardcoded 1. rtl/GundamSD/GundamSD_main_top.sv:31 Memory map SD Gundam (da MAME dcon.cpp + SD Gundam override): $000000-$07FFFF ROM 68K (512KB) $080000-$08BFFF Main RAM (48KB) $08C000-$08C7FF BG tile RAM (2KB) $08C800-$08CFFF FG tile RAM (2KB) $08D000-$08D7FF MG tile RAM rtl/GundamSD/GundamSD_main_top.sv:251 VBLANK IRQ4 — MAME dcon.cpp: m_maincpu->set_vblank_int(irq4_line_hold) Rising edge di vblank → assert IRQ4 pending; IACK CPU → clear. rtl/GundamSD/GundamSD_main_top.sv:399 XOR 0x400 lato CPU per allineare BRAM[N] = MAME text_vram[N] (renderer parte da addr 0). rtl/GundamSD/GundamSD_main_top.sv:407 Quindi MAME palette[N] sta in vram_addr = (N + 0x400) & 0x7FF. rtl/GundamSD/GundamSD_main_top.sv:408 Per allineare BRAM[N] = MAME palette[N] applichiamo XOR 0x400 SOLO al lato CPU (a_addr). rtl/GundamSD/GundamSD_main_top.sv:409 Il renderer passa pen_index MAME nativo (BG=0x400+, MG=0x500+, ecc) e la BRAM è già allineata. rtl/GundamSD/GundamSD_maincpu_map.sv:29 Memory map SD Gundam (da MAME dcon.cpp + sdgndmps_map override): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $080000-$08BFFF Main RAM (48KB) → BRAM $08C000-$08C7FF BG tile RAM → BRAM dual-port $08C800-$ rtl/GundamSD/GundamSD_maincpu_map.sv:160 ─── GFX bank register ─────────────────────────────────────────────────── MAME dcon.cpp gfxbank_w: SOLO bit0 → m_gfx_bank_select = 0x1000 oppure 0. rtl/GundamSD/GundamSD_palette.sv:25 MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 2048); Address space CPU: 0x08E800..0x08F7FF (4 KB = 2048 word). rtl/GundamSD/GundamSD_palette.sv:34 Espansione 5→8 bit con replica top-bits (standard MiSTer / MAME palette_device). rtl/GundamSD/GundamSD_palette.sv:86 xBGR_555 → RGB888 con replica bit alti (5→8 standard MiSTer/MAME) rtl/GundamSD/GundamSD_seibu_crtc.sv:23 Seibu CRTC fedele a MAME (src/mame/seibu/seibu_crtc.cpp). rtl/GundamSD/GundamSD_seibu_crtc.sv:117 MAME mappa: bit0=screen0(BG), bit1=screen2(MG), bit2=screen1(FG), bit3=screen3(Text) (vedi seibu_crtc.cpp commento "screen 0=BG, screen 1=FG, screen 2=MG, screen 3=Text") In SD Gundam dcon.cpp layer_en_w gira la maschera così: ~layer_en bit rtl/GundamSD/GundamSD_seibu_crtc.sv:126 Il dispatcher MAME usa "if (BIT(~m_layer_en, n))" per saltare = layer disabilitato quando il bit è 1. rtl/GundamSD/GundamSD_sprite_renderer.sv:27 Format word (formato "comune", non alt_format) da MAME src/mame/seibu/sei021x_sei0220_spr.cpp: w0 bit 15 = enable (0=skip, 1=draw) w0 bit 14 = flip_x w0 bit 13 = flip_y w0 bit 12..10 = sizex (3-bit, +1) → 1..8 tile larghezza rtl/GundamSD/GundamSD_sprite_renderer.sv:42 Multi-tile: tile_code += 1 per sub-tile (TODO: ordine x-major o y-major da verificare con dump MAME — assunto x-major per ora). rtl/GundamSD/GundamSD_sprite_renderer.sv:45 Priority callback dcon.cpp::pri_cb: pri=0 → above FG pri=1 → above MG pri=2 → above BG pri=3 → above Text (= sotto Text) rtl/GundamSD/GundamSD_sprite_renderer.sv:134 SEI0211 get_coordinate (MAME sei021x_sei0220_spr.h): coord &= 0x1ff; return (coord >= 0x180) ? rtl/GundamSD/GundamSD_sprite_renderer.sv:181 Tile code finale Y-MAJOR (MAME draw_internal: ax=outer, ay=inner, code++): sub_index = axsizey + ay → cur_tile = code + eff_tile_xsp_h + eff_tile_y rtl/GundamSD/GundamSD_text_renderer.sv:25 Specifiche da MAME (src/mame/seibu/dcon.cpp): rtl/GundamSD/GundamSD_text_renderer.sv:183 --- Stage 3: pen decode --- MAME readbit: bit MSB-first → src[bn/8] & (0x80 >> (bn%8)) In Verilog LSB-first, bit position = 7 - (bn%8). rtl/GundamSD/GundamSD_tile_layer.sv:25 Differenze fra layer (da MAME dcon.cpp): rtl/GundamSD/GundamSD_tile_layer.sv:277 MAME readbit: src[bitnum/8] & (0x80 >> (bitnum%8)) (MSB-first) Verilog è LSB-first: bit posizione = 7 - (bitnum%8). rtl/GundamSD/GundamSD_video_timing.sv:35 Active area da MAME (sdgndmps_map): visarea 0..408-1, 28..308-1 quindi 320×224, V offset = 16 (top blank). README.md:9 This core reimplements the hardware in SystemVerilog from MAME references (`seibu/dcon.cpp`, `seibu/seibu_crtc.cpp`), the Seibu CRTC documentation, the main 680 README.md:48 MAME-accurate Seibu CRTC (scroll, layer enable, flip screen) and SEI0211 sprite priority README.md:63 YM2151 FM (jt51) + OKI M6295 ADPCM (jt6295) with MAME-accurate mixer README.md:135 \| Custom video CRTC\| Seibu CRTC (legionna.cpp / seibu_crtc.cpp) \| README.md:216 The MAME* project for invaluable hardware reference (`seibu/dcon.cpp`, `seibu/seibu_crtc.cpp`). Says it matches, follows or was checked against MAME — 1 GundamSD.sv:305 SD Gundam SYSTEM port ($E0004) — verified MAME dcon.cpp:345-356 bit0 = START1 (active LOW) bit4 = START2 (active LOW) bit8 = SERVICE (active LOW) PORT_SERVICE_NO_TOGGLE altri = UNKNOWN/UNUSED → tied 1 Coin inputs NON sono qui Shares text with the MAME driver without saying so — 4 rtl/GundamSD/GundamSD_audio_z80.sv:174 ROM_LOAD "911-a05.010" 0x00000, 0x8000 → primi 32KB del file → region 0x00000-0x07FFF — shares text with seibu/dcon.cpp:678 rtl/GundamSD/GundamSD_palette.sv:23 Palette RAM Seibu D-Con (xBGR_555, 2048 entries). MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 2048); Address space CPU: 0x08E — shares text with seibu/dcon.cpp:559 rtl/GundamSD/GundamSD_text_renderer.sv:23 Text layer renderer Seibu D-Con (8x8, 4bpp, 64x32). Specifiche da MAME (src/mame/seibu/dcon.cpp): // get_text_tile_info tile = textram[tile_i — shares text with seibu/dcon.cpp rtl/GundamSD/GundamSD_video_timing.sv:23 Video timing single-screen Seibu D-Con. SD Gundam Psycho Salamander gira su Seibu D-Con (PB91008), stessa famiglia di Blood Bros (1990). PCB measuremen — shares text with seibu/dcon.cpp
SDGundamRainbow# SD Gundam Sangokushi Rainbow Tairiku Senki MiSTer-devel/Arcade-SDGundamRainbow_MiSTer @ 154ec6db MAME compared: seibu/legionna.cpp + 8 related file(s) Read: 24 HDL files, 10,821 lines (Quartus project)	MiSTer official	Mostly MAME	medium	71%
Statements: 5 toward hardware, 193 toward MAME, 1 not counted Cites hardware references or measurements that MAME's driver also gives — 1 rtl/SDGundamRainbow/SDGundamRainbow_maincpu_map.sv:23 Main CPU memory map SDGundamRainbow / SD Gundam (legionna.cpp grainbow_map): $000000-$0FFFFF ROM 68K (1MB) → SDRAM via bridge $100000-$1003FF RAM scratch (1KB) → BRAM (Main RAM low) $100400-$1006FF COP3 region — also in MAME: 68K seibu/legionna.cpp:46 Reports a measurement taken on the original PCB — 1 rtl/SDGundamRainbow/SDGundamRainbow_video_timing.sv:26 PCB measurement Blood Bros: VSync 59.4094 Hz, HSync 15.6246 kHz, master XTAL 20 MHz. Says it was checked on “real hardware” — 4 rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:343 0 : 1 (unsigned <320 provato su HW = REGRESSIONE; il signed [-160,320) dell'intento MAME e' il comportamento giusto sul core) rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:215 byte_lo = pf_rom_data[31:24]/[15:8], byte_hi = [23:16]/[7:0] Plane order DCBA (verificato su HW, come BG/MG/FG): pen[0] dal bit "D" (byte_hi[3-sub]), pen[3] dal bit "A" (byte_lo[7-sub]). rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:332 Scan INVERSO 511→0 (verificato su HW: ordine sprite-su-sprite opposto al loop MAME 0→511). rtl/SDGundamRainbow/SDGundamRainbow_tile_layer.sv:322 Plane order verificato su HW: BG/MG = DCBA (PEN_ORDER=0), FG = BADC (PEN_ORDER=1). Cites MAME source — 176 SDGundamRainbow.sv:307 --- Joystick to SD Gundam input mapping --- MAME P1_P2 port ($E0002): active low. SDGundamRainbow.sv:310 MiSTer joy bits: joy[0]=R, joy[1]=L, joy[2]=D, joy[3]=U, joy[4]=A, joy[5]=B. MAME PLAYERS12 (legionna.cpp:439-444): bit[0]=UP, [1]=DOWN, [2]=LEFT, [3]=RIGHT, [4]=BTN1, [5]=BTN2, [6]=BTN3, [7]=unused (active low). SDGundamRainbow.sv:320 SDGundamRainbow SYSTEM port ($10074C) — MAME legionna.cpp:427-436 bit0 = START1 (active LOW) bit1 = START2 (active LOW) bit2..7 = UNKNOWN → tied 1 bit8..15 = UNKNOWN → tied 1 Coin inputs NON sono qui: vanno via SEIBU_COIN_INPUTS → Z80 → sou SDGundamRainbow.sv:689 ── Flip screen (CRTC reg 0x1A bit 0) ─────────────────────────────────────── MAME: BIT(reg_1a, 0) → flip_screen. SDGundamRainbow.sv:735 ── Text layer renderer (8x8, 4bpp, 64x32 grid) ───────────────────────────── SDGundamRainbow MAME (ROM_START godzilla): "char" = REGIONE PROPRIA 128KB (11.620/10.615, ROM_LOAD16_BYTE), NON dentro user1 come Legionnaire. SDGundamRainbow.sv:748 SDGundamRainbow text scroll-base (CRTC reg 0x3A, hook godzilla-only legionna.cpp:1326). SDGundamRainbow.sv:749 Calibrazione HW di famiglia (dump vregs in seibu_crtc.cpp): Legionnaire reg=0x01FF, visarea da riga 16 → 0x1FF-0x1EF=+16 = ESATTAMENTE il vecchio yoff text +16 del core Legionnaire funzionante; D-Con reg=0xFFEF (low9=0x1EF), visarea da 0 → SDGundamRainbow.sv:753 La formula MAME set_scrolldy(0x1EF-data) è INVERTITA rispetto all'HW (convenzione dy del tilemap.cpp) — mai fidarsi del verso MAME. SDGundamRainbow.sv:791 SDGundamRainbow CRTC scroll passthrough (legionna_v.cpp:34-49 tile_scroll_w): scroll_ram[0/1] → BG (m_background_layer) scroll_ram[2/3] → MG (m_midground_layer) scroll_ram[4/5] → FG (m_foreground_layer) Nel nostro CRTC: xscroll_l0 = ram[0/1 SDGundamRainbow.sv:814 SDGundamRainbow BG: tilemap 32x32 (legionna_v.cpp:204). SDGundamRainbow.sv:815 MAME GFXDECODE "back" color base = 0 (gfx_legionna riga 1168), 32 colorset. SDGundamRainbow.sv:816 HAS_TRANSP=1 perché m_background_layer->set_transparent_pen(15) in legionna_v.cpp:216 (pen 15 = trasparente, NON opaco come Blood Bros). SDGundamRainbow.sv:838 SDGundamRainbow MG: 16x16, 4bpp, 32x32 tilemap (legionna_v.cpp:204). SDGundamRainbow.sv:839 get_mid_tile_info_share_bgrom (legionna_v.cpp:158): MG share BG ROM, tile = (vram & 0xfff) \| 0x1000 (= seconda metà della BG ROM) color = ((vram >> 12) & 0xf) \| 0x10 (= palette set superiore: bit 4 = 1) In palette MAME "back" base = 0, SDGundamRainbow.sv:866 SDGundamRainbow FG: tilemap 32x32 (legionna_v.cpp:213). SDGundamRainbow.sv:868 MAME GFXDECODE "fore" color base = 3216 = 0x200, 16 colorset. SDGundamRainbow.sv:878 GRAINBOW: fore = bg2.619 ROM_LOAD16_WORD_SWAP (legionna.cpp:1987) = IDENTICO alla back bg1.618 → stesso decode DCBA di BG/MG (riscontro HW utente: col BADC il FG era sbagliato). SDGundamRainbow.sv:886 SDGundamRainbow: bit 2 = FG (legionna_v.cpp:344) SDGundamRainbow.sv:973 Anticipando di 1 l'indirizzo e il DE, il dato campionato al tick e' quello del pixel CORRENTE: allineamento coi tile ripristinato (= calibrazione +1 pixel-hunting MAME, fatta prima del fix CRT) e colonna 0 coperta. SDGundamRainbow.sv:1007 MAME riferimenti (VIDEO_START grainbow, legionna_v.cpp:276-287): m_sprite_pri_mask per grainbow: pri=0 → 0xFFF0 (copre pri-value 0,1,2 → bg,mg,fg → SOTTO text) pri=1 → 0xFFFC (copre 0,1 → bg,mg → sotto fg,text) pri=2 → 0xFFFE (copre 0 → SDGundamRainbow.sv:1017 Ordine composite RTL (front→back), derivato dalle pri_mask sopra: Sprite pri=3 (sopra tutto, text incluso) Text (pri-value 4) Sprite pri=0 (sopra bg/mg/fg, sotto text) FG (pri-value 2) Sprite pri=1 (sopra bg/mg) MG rtl/SDGundamRainbow/SDGundamRainbow_audio_z80.sv:25 Spec da MAME (legionna.cpp godzilla machine config :1295-1355): - Z80 @ 14.318180/4 = 3.579545 MHz (seibu_sound_map + godzilla_sound_io_map) - YM2151/OPM (jt51) @ 3.579545 MHz, route ch0+ch1 0.50 su mono - OKI M6295 (jt6295) @ 20MHz/20 = 1. rtl/SDGundamRainbow/SDGundamRainbow_audio_z80.sv:57 SDGundamRainbow pcm.922 = 512KB: bit 18 = bank (Z80 IO port 0, MAME godzilla_oki_bank_w: set_rom_bank(data&1)). rtl/SDGundamRainbow/SDGundamRainbow_audio_z80.sv:364 MAME seibu_sound_device::main_r (seibusound.cpp:279): case 2,3: return sub2main[offset-2] (soundlatch data: coin/input dal Z80) case 5: return main2sub_pending ? rtl/SDGundamRainbow/SDGundamRainbow_audio_z80.sv:379 ─── YM2151 (jt51) — GRAINBOW usa OPM, non OPL2 (legionna.cpp:1340) ────── Il driver Z80 programma i timer OPM (reg 0x10-0x14): su jtopl2 non scattava mai l'IRQ → RST10 morto → sequencer musica fermo. rtl/SDGundamRainbow/SDGundamRainbow_audio_z80.sv:458 MAME: route 0.50+0.50 su mono (legionna.cpp:1342-1343) rtl/SDGundamRainbow/SDGundamRainbow_audio_z80.sv:466 ─── OKI M6295 (jt6295) — PIN7_HIGH (20MHz/20 = 1.0 MHz, legionna.cpp:1345) rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:4 MAME-faithful implementation of the Seibu SEI300 chip as used by the `legionna` driver (SDGundamRainbow 1992 — Banpresto/TAD). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:7 Reference (in this repo): MAME seibucop.cpp MAME seibucop_cmd.ipp MAME seibucop_dma.ipp MAME legionna.cpp rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:136 MAME cop_itoa_digits[10]: BCD digits of cop_itoa (low<<0 \| high<<16). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:140 Il vecchio loop a sottrazioni ripetute era O(valore) (~valore/9 clk): con i long 32-bit di godzilla (score, writer $156E/$1F93E) il 68k restava congelato (dma_busy include bcd_pending) fino a MILLISECONDI per chiamata — su MAME/HW reale i d rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:153 MAME cop_program command table (seibucop.cpp lines 318-457) At boot, game code uploads 32 macro slots × 8 micro-op words via pgm_addr (0x100434) → slot8 + sub-index pgm_data (0x100432) → micro-op word pgm_value (0x100438) → cop_func_valu rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:160 MAME calls find_trigger_match(triggerval, 0xff00) to find the slot whose cop_func_trigger matches. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:263 Triggers (write-only addresses) MAME legionna.cpp:172 maps cop_cmd_w to $100500-$100505 (3 words). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:337 0x100410 sprite_dma_inc (MAME cop_sprite_dma_inc_w): if x_clip in [-160, 320): cop_regs[4] += 8. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:338 MA in MAME sprite_x e' uint16_t assegnato a int -> MAI negativo -> il -160 e' codice morto: check EFFETTIVO = unsigned < 320 (X "negative" 0xFFxx NON avanzano il puntatore entry). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:343 0 : 1 (unsigned <320 provato su HW = REGRESSIONE; il signed [-160,320) dell'intento MAME e' il comportamento giusto sul core) rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:350 A size==0 NON wrappare (il size-- uint di MAME wrapperebbe a $FFFF: il loop del builder su status[1] andrebbe in livelock — provato peggio). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:385 Macro program upload — MAME seibucop.cpp lines 318-457 pgm_data writes one micro-op word to cop_program[latch_addr] AND latches the slot's trigger/value/mask from current latch regs. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:486 itoa_digits (MAME 0x100590-99, 5 word). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:498 Status / dist / angle (seibucop.cpp:916 cop_status_r → cop_status) rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:506 MAME open bus rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:573 commit write al dst ASSOLUTO (fill/mr), 1:1 MAME write_word(dst) rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:609 LEGACY sprite-DMA (seibucop_cmd.ipp): 6880 (carica rel_xy), c480 (single-step: compone l'entry sprite a cop_regs[4]+offs con X/Y = rel + (obj - abs)). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:633 write angolo (word {0,angle} come MAME host_endian) rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:645 Trigger latches — MAME seibucop.cpp cop_cmd_w line 1069. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:646 MAME dispatches on raw data after clearing cop_status bit 15. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:700 DMA mode 0x80-0x87: MAME dma_palette_brightness() fa FADE solo con pal_brightness_mode 4/5; con qualsiasi altro valore fa una COPIA SEMPLICE src->dst (ramo else, seibucop_dma.ipp:119-123) verso QUALUNQUE dst — incl. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:708 DMA generici 0x09/0x0E: MAME write_word(dst) va nello spazio host = arriva a QUALSIASI RAM mappata, incluse le BRAM video ($101000-$105FFF: staging tilemap, palette-stage $104000, sprite $105000). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:716 Output del fade/blend 0x8x: MAME dma_palette_brightness fa write_word(dst) nello SPAZIO HOST = raggiunge QUALUNQUE RAM mappata (pal-stage $104000, sprite $105800, Main RAM...). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:719 Ora: pal_val registrato in D_FADE_WRITE e committato in D_FADE_COMMIT via canale fill (decode per dst assoluto in main_top: bg/fg/mg/txt/pal/spr) o mr (dst in Main RAM) — 1:1 MAME. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:722 (Il vecchio dma80_to_spr era INVERTITO: il blit pietre e' src=$105800 dst=$104000, non il contrario — MAME map: $100478=SRC, $10047C=DST.) rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:725 LEGACY sprite-DMA state (MAME m_sprite_dma_rel_x/y, m_sprite_dma_x_clip) rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:835 MAME cop_cmd_w (seibucop.cpp:1075): rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:869 find_trigger_match (seibucop.cpp:464) Cerca slot N tale che (trigger & 0xf800) == (cop_func_trigger[N] & 0xf800) && cop_func_trigger[N] != 0. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:871 Restituisce canonical trigger value del slot (NB: MAME LEGACY_cop_cmd_w usa il match slot per dispatchare; in pratica equivale a restituire cop_func_trigger[slot]). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:892 fade_table — MAME seibucop.cpp:733 (reverse engineered from Seibu Cup Soccer bootleg) v = pal_channel(5-bit) \| (brightness_val_xor_X) [10-bit input] low = v & 0x1F high = v & 0x3E0 return (low * (high \| (high>>5)) + 0x210) >> 10 [8-bit o rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:931 ── Hitbox b100/b900 scratch (MAME cop_collision_update_hitbox) ────────────── dx[i] = int8 (signed) byte basso, size[i] = uint8 (unsigned) byte alto del word descrittore @ hitadr2+2i. 3 assi (Y,X,Z) per SDGundamRainbow. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:938 num_axis: MAME seibucop.cpp:1010 "if (data & 0x100) num_axis = 3" else 2. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:940 res init 7 vs 3 (seibucop.cpp:1038-39). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:967 Con 16-bit frac + 24 iter + z>>16: 0 divergenze di decisione vs MAME int(atan(dx/dy)128/pi) su ~640k casi (dimostrato numericamente). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1212 MAME cop_dma_trigger_w: NON modifica cop_status (vedi seibucop.cpp:741). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1220 MAME dma_tilemap_buffer: copy staging RAM → renderer BRAM src = cop_dma_src[mode] << 6 (byte addr 0x101000+ = staging) dst = i (loop counter 0..0x13FF = renderer index) count = 0x2800/2 = 5120 words rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1230 MAME dma_palette_buffer: copy staging palette → renderer src = cop_dma_src[mode] << 6 (0x104000 = palette staging) dst = i (loop counter 0..0x7FF = renderer index) count = 0x1000/2 = 2048 words rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1240 MAME write_word(dst) su spazio host: con dst nelle BRAM video ($101000-$105FFF: staging/pal/spr, es. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1255 simplified, MAME size>>1 rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1260 MAME seibucop_dma.ipp dma_palette_brightness() mode 5/4. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1263 MAME formulas: src = cop_dma_src[mode] << 6 dst = cop_dma_dst[mode] << 6 size = ((cop_dma_size << 5) - (cop_dma_dst << 6) + $20)/2 Init: src=$106000, dst=$104000, size=($827F<<5 - $4100<<6 + $20)/2 = ($104FE0 - $104000 + $20)/2 = $1000 rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1274 MAME size = (((size<<5) - (dst<<6) + 0x20)/2) rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1280 MAME: mode 4/5 = fade palette; QUALSIASI ALTRO = copia semplice src->dst (seibucop_dma.ipp:119-123). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1290 MAME seibucop.cpp cop_dma_trigger_w case 0x116 — GRAINBOW: fill come 0x118 ma SENZA guard dst!=0 e length bytes = (size+1)<<4 (metà). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1292 legionna.cpp:56-61: "The COP-MCU appears to write to the work ram area, otherwise it RESETS in mid-animation of the title screen" → senza questo fill il gioco torna al logo da solo. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1303 Skip if dst != 0 (MAME guard, dma.ipp:135) rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1316 MAME cop_cmd_w (seibucop.cpp:1073): cop_status &= 0x7fff (clear bit 15). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1318 MAME: cop_status &= 0x7fff (clear bit 15). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1333 MAME LEGACY_cop_cmd_w: find_trigger_match(data, 0xF800) → slot per GRUPPO f800, poi handler dal microcodice caricato. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1380 MAME execute_0205: read dword at cop_regs[0]+4+offset4 (ppos) rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1401 0x138e / 0x338e — atan(dx/dy) MAME execute_338e. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1403 Parte da r1+4 hi (offset 0x0004), come 3BB0/MAME. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1411 r1+4 hi (MAME read_dword(r1+4) primo) rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1426 MAME: raw_angle = cop_read_word(r0+0x34) = host_read_word(0x34^2 = 0x36); amp = cop_read_word(r0+0x36) = host_read_word(0x36^2 = 0x34). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1443 0xa180 — collision read pos for slot 0 MAME cop_collision_read_pos: cop_read_word(spradr+N) = host_read_word((spradr+N)^2) per host_endian=true. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1464 b000 NON e' un no-op: il dispatcher LEGACY di godzilla (seibucop.cpp:1365) matcha con mask 0xf800, quindi la patch init_godzilla (b100->b000) ESEGUE comunque l'update ma con num_axis=2 (bit8=0 = Z disattivata). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1572 Mode 4 (GRAINBOW/Denjin, seibucop_dma.ipp:87-117): indice = (val2)[4:0], val 0x0010/0xFFFF = TARGET PURO, NESSUN bypass bit15. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1619 MAME: m_host_space->write_word(dst, pal_val) — dst ASSOLUTO. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1653 MAME (0x118 e 0x116): write_dword(i, v1 \| v2<<16) su spazio BE 68k → word a i = v2, word a i+2 = v1 (alternati). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1666 Macro 0x0205 — linear movement (MAME execute_0205) ppos = read_dword(cop_regs[0]+0x04) vel = read_dword(cop_regs[0]+0x10) npos = ppos + vel write_dword(cop_regs[0]+0x04, npos) delta = (npos>>16) - (ppos>>16) write_word(cop_regs[0]+0x1E, re rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1709 MAME cop_read/write_word(cop_regs[0]+0x1e) = host word @ (0x1e^2)=0x1c (host endianness word^2; conferma doc 06 micro-op 'addmem16 0x1C(r0)'). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1727 Macro 0x0905/0x0904 — jump (MAME execute_0904) write_dword(cop_regs[0]+0x10, read_dword(cop_regs[0]+0x10) ± read_dword(cop_regs[0]+0x28)) 0x0905 (bit 0=1) = +, 0x0904 (bit 0=0) = - rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1753 MAME execute_0904: bit 0 di data = 1 → add, =0 → sub tmp32_a = vel ± grav. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1784 0x138E/0x338E atan(dx/dy) — MAME execute_338e (cmd.ipp:159) dx = read_dword(r1+4) - read_dword(r0+4) dy = read_dword(r1+8) - read_dword(r0+8) if(!dy){status\|=0x8000; angle=0} else angle=atan(dx/dy)128/pi; dy<0→+0x80 if(data&0x80) write_byt rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1832 MAME: angle = atan(dx/dy)128/pi (+0x80 se dy<0). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1834 Cosi' z = atan(dx/dy) e il +0x80 (in WR) copre solo il quadrante, come MAME. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1836 NIENTE prescale: i dword diff sono FIXED-POINT coord<<16 (come il 3BB0 che usa dx32[31:16] e MAME dx>>16), NON interi piccoli. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1877 MAME (int)(...) tronca VERSO ZERO. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1879 BUG TROVATO (validato vs MAME su 29241 casi): il CORDIC SOTTO-CONVERGE di 1 LSB sulle DIAGONALI (es. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1884 Compenso l'epsilon di sotto-convergenza con +1 toward-zero PRIMA del troncamento: bias=1 azzera tutte le 133 divergenze (bias=0) -> 0/29241 vs MAME. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1893 MAME execute_338e (seibucop_cmd.ipp:175-188): la write dell'angolo in RAM (obj+0x34 host, gated da data&0x80) e' FUORI dall'if/else di dy -> avviene SEMPRE, anche a dy==0 (dove cop_angle=0 -> scrive 0^0x80 = 0x80). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1899 Ora calcolo ang_byte in entrambi i rami e scrivo SEMPRE, come MAME. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1906 Scrivere l'angolo anche a dy==0 ("1:1 MAME") REGREDISCE: il martello scivola/moonwalk. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1909 MAME: dy==0 -> cop_angle=0 rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1920 GRAINBOW: write RAW — il ROM carica il microcode 138e variante cupsoc/SDGundam (tabella $498: ...b9a b9a A9A) = MAME LEGACY_execute_130e_cupsoc, SENZA ^0x80 (il ^0x80 e' della variante famiglia $B9A / is_yflip: legionna). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1924 PROVA sim 8 casi: col ^0x80 vettore sincos INVERTITO 180° vs MAME → boss 138e-driven marcia via (stage 4). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1926 ⛔ NON toccare il sincos (lookup diretto = sin MAME): toccarlo inverte i game-written = regressione build 13. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1940 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197) dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (aritmetico) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = sqrt(dxdx + dydy) if(data&0x80) write_word(r0 + (data&0x200?0x3a:0x38 rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2049 (Il fix MAME-aligned 0x3a:0x38 faceva fuggire i nemici -> MAME invertito vs HW. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2056 MAME: macro completata → cop_status = 7 (gate-poll del gioco). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2142 0x8100/0x8900 sin/cos (MAME execute_8100/8900) raw_angle = cop_read_word(cop_regs[0]+0x34) & 0xff amp = (65536>>5) * (cop_read_word(cop_regs[0]+0x36) & 0xff) = 2048 * amp_byte if (raw_angle == 0xC0 sin / 0x80 cos): amp = 2 res = int( rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2181 MAME special-case: sin && raw==0xC0 OR cos && raw==0x80 → amp = 2 rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2227 0xa180/0xa980 — read pos (MAME cop_collision_read_pos) flags_swap = cop_read_word(spradr+2) → host_read_word(spradr+0) pos[0] = cop_read_word(spradr+6) → host_read_word(spradr+4) pos[1] = cop_read_word(spradr+10) → host_read_word( rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2234 Però MAME cop_read_word(+2) = host_read_word(+2^2) = host_read_word(+0). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2245 rdata = word @ host+0 = flags (MAME cop_read_word(spradr+2) ^ 2). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2254 rdata = word @ host+4 = pos[0] (Y axis per MAME) rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2274 0xb100/0xb900 — update hitbox & compute intersection (1:1 MAME cop_collision_update_hitbox, seibucop.cpp:1003-1065). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2321 2 assi (b000/b800): terza word NON letta, dx/size azzerati (seibucop.cpp:1014-1022) rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2360 2 assi: l'asse 2 (Z) NON viene aggiornato (loop MAME i<num_axis) rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2379 res init: 3 assi = 111, 2 assi = 011 (seibucop.cpp:1038-39: bit Z gia' 0 = "collide banale" -> hit deciso solo da X/Y) rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2403 LEGACY 6880 — carica rel_xy per il prossimo c480 (MAME LEGACY_execute_6980: rel_xy = read_word(spr_src+4+offs)) rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2424 LEGACY c480 — single-step sprite DMA (MAME LEGACY_execute_c480): info = read(spr_src+offs) + (param & 0x3f) -> entry+0 abs = read(regs[0]+8/+4) - spr_dma_abs_x/y X(fx/dx/rel_x) -> entry+4 (+ x_clip per l'inc $410) Y(fy/rel_y) -> entry+6 rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2537 6200 — rotate-towards (MAME execute_6200, variante grainbow che godzilla CARICA nella tabella): angle(obj host+0x37) ruota verso cop_angle_target di cop_angle_step; flags(host+2) bit2=raggiunto. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2540 Dominio angolo: il nostro 138e scrive in RAM plain^0x80 (is_yflip) -> lavoro nel dominio stored con target^0x80: il DELTA e' rotazione-invariante => matematica IDENTICA a MAME. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2543 Write angolo = WORD {0,angle} (MAME host_endian write-word). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2564 wrap a signed 8-bit (MAME: +=/-=256 su int) rtl/SDGundamRainbow/SDGundamRainbow_main_top.sv:227 VBLANK IRQ4 — MAME legionna.cpp: m_maincpu->set_vblank_int(irq4_line_hold) MAME HOLD_LINE: IRQ asserted on edge, released ONLY at IACK (= when CPU fetches vector). rtl/SDGundamRainbow/SDGundamRainbow_main_top.sv:232 VBLANK IRQ4 — MAME legionna.cpp: m_maincpu->set_vblank_int(irq4_line_hold) MAME HOLD_LINE: IRQ asserted on edge, released ONLY at IACK (= when CPU fetches vector). rtl/SDGundamRainbow/SDGundamRainbow_main_top.sv:489 COP3 cmd 0x14 dma_tilemap_buffer (legionna_v.cpp:86 videowrite_cb_w): offset 0x000..0x3FF → BG (back_data) offset 0x400..0x7FF → FG (fore_data) offset 0x800..0xBFF → MG (mid_data) offset 0xC00..0x13FF → Text (textram, 0x800 word) SRC rtl/SDGundamRainbow/SDGundamRainbow_main_top.sv:513 Il fill scrive le BRAM STAGING (= la host RAM di MAME): il per-frame DMA 0x14/0x15 le propaga al renderer. rtl/SDGundamRainbow/SDGundamRainbow_main_top.sv:527 ── SPLIT STAGING vs RENDERER (semantica MAME 2-stadi, come la palette) ───── MAME godzilla: $101000-$103FFF e' .ram() PURO (handler background_w/… COMMENTATI nel map, legionna.cpp) — le scritture CPU NON toccano i tilemap. rtl/SDGundamRainbow/SDGundamRainbow_main_top.sv:530 I tilemap leggono m_back/fore/mid_data/m_textram = buffer SEPARATI (make_unique_clear, legionna_v.cpp) scritti SOLO da videowrite_cb_w = DMA 0x14. rtl/SDGundamRainbow/SDGundamRainbow_main_top.sv:535 u_XX_ram = STAGING: porta A = CPU (+fill 0x116/0x118, come MAME che filla la host RAM), porta B = sorgente del DMA 0x14. rtl/SDGundamRainbow/SDGundamRainbow_main_top.sv:538 Coppia contenuto/scroll = atomica a livello ISR, come MAME. rtl/SDGundamRainbow/SDGundamRainbow_main_top.sv:610 ── Palette: split STAGING ($104000) vs RENDERER (semantica MAME 2-stadi) ─── MAME: la CPU e il fade (cmd 0x80) scrivono la STAGING RAM a $104000. rtl/SDGundamRainbow/SDGundamRainbow_main_top.sv:650 MAME godzilla: $104000 e' RAM pura (legionna.cpp:262, handler palette commentato) — la palette VISIBILE si aggiorna SOLO via paletteramout_cb = dma_palette_buffer 0x15 (seibucop_dma.ipp:27); il fade DMA scrive lo STAGING (host RAM, dma.ipp: rtl/SDGundamRainbow/SDGundamRainbow_maincpu_map.sv:23 Main CPU memory map SDGundamRainbow / SD Gundam (legionna.cpp grainbow_map): $000000-$0FFFFF ROM 68K (1MB) → SDRAM via bridge $100000-$1003FF RAM scratch (1KB) → BRAM (Main RAM low) $100400-$1006FF COP3 region rtl/SDGundamRainbow/SDGundamRainbow_maincpu_map.sv:119 ─── Region detect (MAME grainbow_map, legionna.cpp:324) ───────────────── rtl/SDGundamRainbow/SDGundamRainbow_maincpu_map.sv:223 MAME legionna_map: main_r/main_w(offset>>1) con umask16(0x00ff). rtl/SDGundamRainbow/SDGundamRainbow_maincpu_map.sv:227 Vedi seibusound.cpp main_r/main_w. rtl/SDGundamRainbow/SDGundamRainbow_maincpu_map.sv:231 ─── GFX bank ──────────────────────────────────────────────────────────── grainbow non ha il tile bank register ($100470 assente dalla mappa MAME): gfx_bank resta 0. rtl/SDGundamRainbow/SDGundamRainbow_maincpu_map.sv:335 Replica la latenza-zero-osservabile di MAME (cop_cmd_w sincrono): il gioco legge cop_hit_val_stat/cop_angle ($188/$1b4) nell'istruzione dopo il trigger. rtl/SDGundamRainbow/SDGundamRainbow_palette.sv:25 MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 12816); (legionna.cpp:1212, 12816 = 2048 entry) Address space CPU: 0x104000..0x104FFF (4 KB = 2048 word). rtl/SDGundamRainbow/SDGundamRainbow_palette.sv:35 Espansione 5→8 standard MAME palette_device: {val5, val5[4:2]} (bit replication che riempie i 3 LSB con i 3 MSB del valore 5-bit). rtl/SDGundamRainbow/SDGundamRainbow_palette.sv:85 SDGundamRainbow: xBGR_555 → RGB888 (legionna.cpp:1212) Layout: bit[4:0]=R, bit[9:5]=G, bit[14:10]=B. 5 bit per canale. rtl/SDGundamRainbow/SDGundamRainbow_palette.sv:87 Espansione 5→8 standard MAME palette_device: {val5, val5[4:2]} (replica i 3 MSB nei 3 LSB → range 0..255 con monotonia preservata). rtl/SDGundamRainbow/SDGundamRainbow_seibu_crtc.sv:23 Seibu CRTC fedele a MAME (seibu_crtc.cpp). rtl/SDGundamRainbow/SDGundamRainbow_seibu_crtc.sv:130 MAME mappa: bit0=screen0(BG), bit1=screen2(MG), bit2=screen1(FG), bit3=screen3(Text) (vedi seibu_crtc.cpp commento "screen 0=BG, screen 1=FG, screen 2=MG, screen 3=Text") In SD Gundam dcon.cpp layer_en_w gira la maschera così: ~layer_en bit rtl/SDGundamRainbow/SDGundamRainbow_seibu_crtc.sv:139 Il dispatcher MAME usa "if (BIT(~m_layer_en, n))" per saltare = layer disabilitato quando il bit è 1. rtl/SDGundamRainbow/SDGundamRainbow_seibu_crtc.sv:144 SDGundamRainbow layer ordering (legionna_v.cpp:384-390 screen_update_GRAINBOW): bit 0 = BG (background) bit 1 = MG (midground) bit 2 = FG (foreground) bit 3 = Text bit 4 = Sprites ATTENZIONE: e' l'OPPOSTO di legionna (screen_update_legionna rtl/SDGundamRainbow/SDGundamRainbow_seibu_crtc.sv:165 Scroll-base 0x2C-0x3A (seibu_crtc.cpp:243 layer_scroll_base_w; screen0=BG, screen2=MG, screen1=FG, screen3=Text). rtl/SDGundamRainbow/SDGundamRainbow_seibu_crtc.sv:166 Raw esce qui; le formule (delta vs riferimento godzilla, Y invertita come il set_scrolldy(0x1ef-data) di MAME) stanno nel top. rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:25 Formato spriteram quasi identico (entrambi MAME sei021x_sei0220_spr.cpp) — differenze: - Spriteram @ 0x105000-0x105FFF (4KB, 1024 word, 256 entry × 4 word) - w3 bit 15 = tile bank extra bit (denjinmk usa, SDGundamRainbow base = 0) rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:30 Format word (legionna_v.cpp:288-312): w0 bit 15 = enable (0=draw, 1=skip — TODO verify SDGundamRainbow) w0 bit 14 = flip_x w0 bit 13 = flip_y (??? rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:46 Priority callback legionna_v.cpp:314-317: pri_mask[0] = 0x0000 (sopra tutto) pri_mask[1] = 0xFFF0 pri_mask[2] = 0xFFFC pri_mask[3] = 0xFFFE rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:140 0..511 (MAME size/2/4 = 4096/2/4 = 512) rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:145 Decoded fields — MAME sei0210_device::draw (non-alt format, riga 143): if (BIT(~spriteram[i], 15)) continue; → draw quando w0[15]==1. rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:154 grainbow_pri_cb (legionna_v.cpp:319): pri = (w1[15:14] & 2) \| (ext & 1) → livello = {w1[15], w0[6]}. rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:167 MAME SEI0211 default m_xoffset/m_yoffset = 0 (sei021x_sei0220_spr.cpp:40-41). rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:168 SDGundamRainbow NON chiama set_offset (legionna.cpp:1214) → offset 0,0. rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:200 Tile code finale Y-MAJOR (MAME draw_internal: ax=outer, ay=inner, code++): sub_index = axsizey + ay → cur_tile = code + eff_tile_xsp_h + eff_tile_y grainbow: NESSUN gfxbank_cb (legionna.cpp:1449, solo pri_cb) — code puro 14 bit. rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:537 MAME gfx_legionna_spr: color base = 6416 = 0x400 (64 colorset × 16 pen). rtl/SDGundamRainbow/SDGundamRainbow_text_renderer.sv:25 Specifiche da MAME (legionna.cpp:1117-1126, 1167): rtl/SDGundamRainbow/SDGundamRainbow_text_renderer.sv:47 Char ROM in MAME: "char" region 64KB = ROM_COPY user1[0x10000..0x1FFFF]. rtl/SDGundamRainbow/SDGundamRainbow_text_renderer.sv:140 MAME `legionna_v.cpp:214`: text tilemap = 64×32 (8x8 tiles, TILEMAP_SCAN_ROWS). rtl/SDGundamRainbow/SDGundamRainbow_text_renderer.sv:186 --- Stage 3: pen decode (charlayout planes packed in nibbles) --- Per col c (0..3 dentro la half-tile), bit position = 3 - c. pen[0] = word[bit_pos + 0] (plane 0) pen[1] = word[bit_pos + 4] (plane 1) pen[2] = word[bit_pos + 8] (plane rtl/SDGundamRainbow/SDGundamRainbow_text_renderer.sv:192 MAME readbit usa MSB-first: bit_offs N → byte[N/8] bit (7-N%8). rtl/SDGundamRainbow/SDGundamRainbow_text_renderer.sv:193 In Verilog word concat (lo=byte0[7:0], hi=byte1[7:0]) → MAME pos N = word[(7-N%8) + (N>=8?8:0)]. rtl/SDGundamRainbow/SDGundamRainbow_text_renderer.sv:210 MAME GFXDECODE char: color base = 4816 = 0x300 (16 colorset × 16 pen). rtl/SDGundamRainbow/SDGundamRainbow_tile_layer.sv:25 Differenze fra layer (da MAME dcon.cpp): rtl/SDGundamRainbow/SDGundamRainbow_tile_layer.sv:58 BB FG hardcoded +0x1000 (MAME bloodbro fg_tile_info) rtl/SDGundamRainbow/SDGundamRainbow_tile_layer.sv:221 Tile index con eventuale gfx_bank (MG ha bit 12 = 13-bit totali, BG/FG = 12 bit) + TILE_CODE_OFS hardcoded (BB FG aggiunge 0x1000 secondo MAME bloodbro fg_tile_info). rtl/SDGundamRainbow/SDGundamRainbow_video_timing.sv:35 Active area da MAME (sdgndmps_map): visarea 0..408-1, 28..308-1 quindi 320×224, V offset = 16 (top blank). rtl/SDGundamRainbow/SDGundamRainbow_video_timing.sv:60 ── Pixel clock enable: 96 MHz / 14 = 6.857 MHz ───────────────────────── SDGundamRainbow reale (legionna.cpp:1318 set_raw): pclk 14.318180/2 = 7.15909 MHz. rtl/SDGundamRainbow/SDGundamRainbow_video_timing.sv:78 ── Constants timing ───────────────────────────────────────────────────── SDGundamRainbow REALE (legionna.cpp:1318): set_raw(14318180/2, 455, 0, 320, 258, 0, 224) = 320x224, HTotal 455 @7.159MHz = 15.734 kHz, VTotal 258 → 60.985 Hz. rtl/SDGundamRainbow/sdram_bridge.sv:308 --- FG address descramble (legionna.cpp:1129 descramble_legionnaire_gfx) --- MAME applica un bitswap<24> agli indirizzi della ROM "fore" durante init: src_descrambled[i] = src_raw[bitswap<24>(i, ... rtl/SDGundamRainbow/sdram_bridge.sv:355 bitswap MAME del byte offset README.md:7 The game runs on the Seibu `legionna.cpp` hardware family* — an M68000 board with a Seibu CRTC, the SEI252 sprite chip and the SEI300 / COP3 coprocessor. README.md:12 This core reimplements the hardware in SystemVerilog from MAME references (`seibu/legionna.cpp`, `seibu/legionna_v.cpp`, `seibu/seibu_crtc.cpp`, `seibu/seibucop Says it matches, follows or was checked against MAME — 6 SDGundamRainbow.sv:199 -1 = base famiglia (match MAME su HW) SDGundamRainbow.sv:227 NB: gli offset per-layer (ex P5) sono HARDCODATI (osd__xoff/yoff costanti, match pixel-perfect MAME). rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1328 LEGACY sprite-DMA (match a maschera, MAME find_trigger_match): c480 mask $FF00 -> qualunque c4xx; 6880 mask $FFF3. rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2196 res = prod >> 4 (= /16 per matchare formula MAME 2048/32768 = 1/16) rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:169 +1 pixel a destra: offset verificato con pixel hunting su MAME (rmonic79). rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:332 Scan INVERSO 511→0 (verificato su HW: ordine sprite-su-sprite opposto al loop MAME 0→511). Says it was translated, ported or taken from MAME — 2 rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1948 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197): 1:1 dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (signed) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = floor(sqrt(dxdx + dydy)) if(data&0x80) write_word(r0+(data&0x200?0x3 rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2065 0x42C2/0x4AA0 divide — MAME execute_42c2/4aa0 (cmd.ipp:219/247): 1:1 DIVIDEND = cop_dist << (5 - cop_scale) (cop_scale 0..3 → shift 5..2) 42c2: div=cop_read_word(r0+0x36)→host 0x34; if(!div){status\|=0x8000; write 0 a host 0x3a} else write Keeps a MAME approximation — 1 rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:206 MAME usa total_cycles%256 (surrogato dell'RNG hw ignoto): l'LFSR e' un surrogato equivalente ma robusto alle letture regolari. Shares text with the MAME driver without saying so — 8 SDGundamRainbow.sv:816 HAS_TRANSP=1 perché m_background_layer->set_transparent_pen(15) in — shares text with seibu/legionna_v.cpp:216 SDGundamRainbow.sv:839 get_mid_tile_info_share_bgrom (legionna_v.cpp:158): MG share BG ROM, — shares text with seibu/legionna.h:80 rtl/SDGundamRainbow/SDGundamRainbow_palette.sv:23 Palette RAM Seibu SDGundamRainbow (xBGR_555, 2048 entries). MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 12816); (legio — shares text with seibu/legionna.cpp:1212 rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:146 if (BIT(~spriteram[i], 15)) continue; → draw quando w0[15]==1. — shares text with seibu/sei021x_sei0220_spr.cpp:128 rtl/SDGundamRainbow/SDGundamRainbow_text_renderer.sv:23 Text layer renderer Seibu SDGundamRainbow (8x8, 4bpp, 64x32). Specifiche da MAME (legionna.cpp:1117-1126, 1167): // charlayout 8x8, RGN_FRAC(1 — shares text with seibu/legionna.cpp rtl/SDGundamRainbow/SDGundamRainbow_video_timing.sv:23 Video timing single-screen Seibu D-Con. SD Gundam Psycho Salamander gira su Seibu D-Con (PB91008), stessa famiglia di Blood Bros (1990). PCB measuremen — shares text with seibu/legionna.cpp rtl/SDGundamRainbow/SDGundamRainbow_video_timing.sv:79 SDGundamRainbow REALE (legionna.cpp:1318): set_raw(14318180/2, 455, 0, — shares text with seibu/legionna.cpp:1318 rtl/SDGundamRainbow/sdram_bridge.sv:310 src_descrambled[i] = src_raw[bitswap<24>(i, ... 6,5,15,14,13,12, 11,10,9,8, 7,4, 3..0)] — shares text with seibu/legionna.cpp:1141
SegaG80V# Eliminator, Space Fury, Star Trek, Tac / Scan … MiSTer-devel/Arcade-SegaG80V_MiSTer @ 96b82aa2 MAME compared: sega/segag80v.cpp + 20 related file(s) Read: 67 HDL files, 36,169 lines (Quartus project)	MiSTer official	Both	low	6%
Statements: 6 toward hardware, 21 toward MAME, 1 not counted Cites hardware documentation that MAME's driver does not — 6 rtl/sega_game_pkg.sv:7 Cross-checked against MAME segag80v.cpp and the Sega schematics. rtl/sega_ports.sv:4 Input matrix: U1, U2, U5, and U9, four 74LS253 dual 4-to-1 muxes on the CPU board. rtl/xy/sega_xy.sv:8 Cross-checked against MAME segag80v_v.cpp and the Sega X-Y schematics. rtl/xy/sega_xy_top.sv:6 * 4K x 8 vector RAM at U24-U31 on X-Y Control drawing 800-0163 sheet 5. README.md:34 Videodr0me rebuilt the vector generator for high-resolution raster presentation, integrated the CRT-effects pipeline, added video modes and geometry controls, e README.md:37 He also rebuilt Zektor's discrete-audio implementation from its original schematics. Cites hardware references or measurements that MAME's driver also gives — 1 rtl/segag80v_cpu.sv:371 Interrupt chain (CPU board sheet 7/7) — also in MAME: sheet 7 sega/nl_astrob.cpp:637 Cites MAME source — 6 rtl/sega_inputs.sv:5 Bit positions follow MAME segag80v.cpp. rtl/segag80v_cpu.sv:14 MAME's segag80v.cpp uses 2 and notes the real figure "depends on how many rising clock edges MEMRQ is held for, plus 1 additional cycle", with 3 causing visible slowdown in Space Fury. rtl/segag80v_cpu.sv:134 MAME models this with adjust_icount(-2) on every program-space read and write and every opcode fetch, and does not apply it to I/O. rtl/segag80v_cpu.sv:377 MAME latches the IRQ line and only recomputes it on an event, and the SERVICE input has no flip-flop — it contributes to exactly one update. README.md:30 The original G80V machine core and speech implementation were created by alanswx from Sega hardware documentation and Aaron Giles' detailed G80 research in MAME README.md:300 Aaron Giles and MAME contributors: detailed G80 machine, vector, and sound research and executable reference. Says it matches, follows or was checked against MAME — 3 rtl/sega_game_pkg.sv:7 Cross-checked against MAME segag80v.cpp and the Sega schematics. rtl/sega_security.sv:7 Cross-checked against MAME segag80_m.cpp and the Sega hardware mappings. rtl/xy/sega_xy.sv:8 Cross-checked against MAME segag80v_v.cpp and the Sega X-Y schematics. Shares text with the MAME driver without saying so — 12 Arcade-SegaG80V.sv:4 Eliminator, Space Fury, Zektor, Tac/Scan, Star Trek. — shares text with sega/segag80v.cpp:32 rtl/sega_ports.sv:9 D7 COINA n/c n/c n/c — shares text with sega/segag80v.cpp:243 rtl/sega_ports.sv:10 D6 COINB P1.13 P1.14 n/c (P1.13 = DRAW) — shares text with sega/segag80v.cpp:244 rtl/sega_ports.sv:11 D5 SERVICE P1.15 P1.16 P1.17 — shares text with sega/segag80v.cpp:245 rtl/sega_ports.sv:12 D4 P1.18 P1.19 P1.20 P1.21 — shares text with sega/segag80v.cpp:246 rtl/sega_ports.sv:13 D3 SW1.8 SW1.7 SW1.6 SW1.5 — shares text with sega/segag80v.cpp:247 rtl/sega_ports.sv:14 D2 SW1.4 SW1.3 SW1.2 SW1.1 — shares text with sega/segag80v.cpp:248 rtl/sega_ports.sv:15 D1 SW2.8 SW2.7 SW2.6 SW2.5 — shares text with sega/segag80v.cpp:249 rtl/sega_ports.sv:16 D0 SW2.4 SW2.3 SW2.2 SW2.1 — shares text with sega/segag80v.cpp:250 rtl/segag80v_cpu.sv:15 and notes the real figure "depends on how many rising clock edges MEMRQ — shares text with sega/segag80v.cpp:147 rtl/segag80v_cpu.sv:16 is held for, plus 1 additional cycle", with 3 causing visible slowdown in — shares text with sega/segag80v.cpp:148 rtl/xy/sega_xy.sv:161 steps down and large steps up. The carry out of bit 8 clocks the up/down — shares text with sega/segag80v_v.cpp:245
SEGASYS1# 4-D Warriors, Block Gal, The Togyu, Flicky … MiSTer-devel/Arcade-SEGASYS1_MiSTer @ 83ea725f MAME compared: sega/system1.cpp + 2 related file(s) Read: 18 HDL files, 3,660 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	7%
Statements: 2 toward MAME Cites MAME source — 2 rtl/sn76489/sn76489_noise.vhd:199 Tapped bits according to MAME's sn76496.c, implemented in function lfsr_tapped_f. README.md:57 copy ROM zip files to /media/fat/_Arcade/mame
SegaVCO# Buck Rogers: Planet of Zoom, Turbo MiSTer-devel/Arcade-SegaVCO_MiSTer @ a7536fc3 MAME compared: sega/turbo.cpp + 3 related file(s) Read: 50 HDL files, 16,947 lines (Quartus project)	MiSTer official	Both	medium	49%
Statements: 36 toward hardware, 25 toward MAME, 5 not counted Cites hardware documentation that MAME's driver does not — 36 Arcade-SegaVCO.sv:170 SERVICE1 (IN1 bit 5) and TEST (IN1 bit 4) (sheet 4: I15=SERVICE, I14=TEST) are tied inactive; no button is mapped to them. Arcade-SegaVCO.sv:173 in0[5:4] are ACC.LO/ACC.HI (sheet 4: two opto-isolated lines on the control connector). rtl/audio/alarm_chan.sv:1 ALARM channel: IC15A 555 astable -> IC16 74LS393 ripple divider -> IC3/IC7 74123 retriggerable monostables (one per /ALARMn) -> IC11 74LS38 open-collector wire-OR node -> R154/C88 one-pole high-pass -> IC29/IC25 unity-follower + x(-2) gain rtl/audio/alarm_chan.sv:29 Stage 2: IC16 74LS393 ripple divider, falling-edge triggered, never reset after power-on (1CLR/2CLR grounded on the board). rtl/audio/alarm_chan.sv:67 Stage 4: IC11 74LS38 open-collector wire-OR node. rtl/audio/alarm_chan.sv:112 Idle level: with no alarm gated every 74LS38 output is off and R153 holds the node HIGH, so x settles at X_LOW + X_SPAN. rtl/audio/audio_top.sv:18 Turbo sound-board CN1 bundle, from the third 8255 (PPI2/IC123/CSFA) on the CPU board: raw port bytes in, named per the schematic below. rtl/audio/audio_top.sv:126 CN1 bundle, decoded and named per the schematic (bit map below). rtl/audio/audio_top.sv:469 CN2-pin-to-amp-channel mapping, from the cabinet wiring and power amp schematics (734-0048 Upright, 734-0049 Cockpit). rtl/audio/exp_chan.sv:1 EXP channel (crack + rumble), sheet 2. rtl/audio/hit_chan.sv:1 HIT channel, sheet 2 (same shape as exp_chan.sv). rtl/audio/hit_chan.sv:13 The 74123 timing resistor has no designator or value on sheet 2. rtl/audio/hit_chan.sv:78 Reset is the idle state (cap at 5V, silent), not 0V. rtl/audio/la4460.sv:2 Sheet 1, PDF page 45. rtl/audio/la4460.sv:20 Both come from a printed log graph (about +/-20 %); they are the only soft parameters here, sections 1 and 2 are computed from schematic values. rtl/audio/mute_ctl.sv:1 DC-mute control node -- LA4460 pin 6 (sheet 1). rtl/audio/rebound_chan.sv:1 REBOUND channel, sheet 2 (same shape as hit_chan.sv / exp_chan.sv). rtl/audio/rebound_chan.sv:76 Reset is the idle state (cap at 5V, silent), not 0V. rtl/audio/ship_chan.sv:1 SHIP engine channel (sheet 834-5122 sheet 1, "MY SHIP"): IC14 555 astable (R23/R24/C12); IC17 pins 1-3 buffer the C12 voltage, which feeds three relaxation oscillators (IC17 pins 5-7 and 12-14 with Tr2, IC26 pins 1-3 and 8-10 with Tr5, IC22 rtl/audio/turbo_alarm_chan.sv:1 Turbo ALARM channel (D-2/11): IC48 555 astable -> IC43 393 ripple divider -> IC46/IC53 74123 retriggerable monostables (one per /Trig1-4) -> IC47 74LS38 open-collector wire-OR node -> 5.1K/4.7uF one-pole high-pass -> IC33-A follower -> IC33 rtl/audio/turbo_alarm_chan.sv:92 Stage 4: IC47 74LS38 open-collector wire-OR node (gating per the header). rtl/audio/turbo_crash_chan.sv:16 The CRASH.S filter is a one-pole approximation of the second-order IC2 pins 5-7 stage (not derived from the schematic). rtl/audio/turbo_mixer.sv:46 MUTE: D-11/11 generates MUTE locally via IC42 (74LS123-family monostable, R286 = 220K / C137 = 33uF off a power-on 5V rail), a power-on delay mute. rtl/audio/turbo_mute_ctl.sv:9 \| timing \| comparator crossing an RC \| 74LS123 one-shot \| rtl/audio/turbo_mute_ctl.sv:13 Generator (D-11/11): IC42 = 74LS123 (dual monostable, one half used). rtl/audio/turbo_mute_ctl.sv:35 RESET MODELS POWER-ON (same deliberate deviation as mute_ctl.sv): a core reset re-arms the full 3.27s mute, whereas the real 74LS123 triggers only on the 5V rail rising. rtl/audio/turbo_othercars_chan.sv:55 Amplitudes (2686/5031/1660) and duties are the schematic nominals; the three N_UP/N_DOWN/STEP pairs sit inside the component tolerance band around the nominal frequencies (A 83 Hz -> 77.1 Hz, B 195 Hz -> 202.3 Hz, C 211 Hz -> 202.4 Hz); tha rtl/audio/turbo_playercar_chan.sv:10 D9 control/VCA: IC41 (74LS139) BSEL decoder selects exactly one of BCONT0/1/2. rtl/audio/turbo_playercar_chan.sv:632 BCONT0/1/2 gate targets (IC41 74LS139 decoder, one-hot). rtl/audio/turbo_playercar_mycarsource.sv:11 The tone rate comes from the STEP_LUT law; the sub rate is a named operating-point parameter (0.43 Hz/V) because TR5's in-circuit VCE is not recoverable from the schematic. rtl/segavco.v:1072 IC20 (PR-1116, TBP18S030 32x8 PROM; P-ROM board sheet 2/10) has address inputs PLB0-2 (A0-A2) and SLIPAR/ACCIAR (A3-A4), i.e. sprbits[26:24] and babit[4]/babit[5], matching turbo_v.cpp's ((sprbits>>24)&7) \| ((babit&0x30)>>1). rtl/segavco.v:1075 Its output feeds a 74LS376 latch (IC19) whose set/clear sequencing was not traced; the model OR-accumulates every visible pixel, is read at fe00 low nibble and cleared by any write to e800-efff. rtl/video/mixer_turbo.v:1 Turbo mixer (schematic sheet 144): a bit-serial 16:1 multiplexer, not an ordinal priority chain -- the layer ordering is data (the contents of PR-1122/PR-1123), not structure. rtl/video/mixer_turbo.v:146 16 bits wide: the three 74LS150s (IC38/39/40, P-ROM Board sheet 2/10) are 16:1 selectors with D15 grounded (0) and D14 pulled high (1). README.md:12 Both sound boards are rebuilt as discrete circuits in fixed-point DSP, working from the original schematics: oscillators, 555 timers, one-shots, noise source, v README.md:45 Known gaps. Some upper engine harmonics, the Other Cars second harmonic and the tunnel's room character do not yet match the cabinet recording, and the alar Cites hardware references or measurements that MAME's driver also gives — 5 rtl/audio/fire_chan.sv:1 FIRE channel (laser), sheet 3. — also in MAME: sheet 3 sega/turbo.cpp:324 rtl/audio/noise_mm5837.sv:1 MM5837 pseudo-random noise generator (sheet 3). — also in MAME: sheet 3 sega/turbo.cpp:324 rtl/io/i8255.v:16 On the CPU board (834-5120 sheet 5) IC90's PC7 drives the sub Z80's /INT and PC6 comes from its /IORQ with no gating, so the command write is the interrupt and the sub CPU's own /IORQ (acknowledge, then the ISR's IN) clears it; there is no — also in MAME: sheet 5 sega/turbo.cpp:261 rtl/segavco.v:360 PC7 goes straight to the sub CPU's /INT (834-5120 sheet 5: IC90 pin 10 -> IC50 pin 16), so the write is the interrupt. — also in MAME: sheet 5 sega/turbo.cpp:261 rtl/video/video_timing.v:26 The original board's H SYNC (82S141 IC78 pin 9, pr-5197) is high for native counts 264..303, i.e. 528..607 here (8.01 us), leaving only 3.2 us of back porch; composite encoders such as the AD723 then fail to insert colour burst. — also in MAME: 82S141 sega/turbo.cpp:1708 Cites MAME source — 22 Arcade-SegaVCO.sv:333 Not on the original board; like MAME's lever artwork it is only a display aid, off by default. rtl/io/steering_input.sv:6 The game reads a dial (MAME IPT_DIAL): only the change between two reads matters, not an absolute angle, which a free-running mod-256 accumulator models. rtl/segavco.v:367 MAME clears the handshake a machine cycle later through its own scheduling; that is an emulator artifact and is not reproduced. rtl/segavco.v:495 Turbo's proms blob has a different layout from Buck's (see turbo_v.cpp and the MRA) but uses the same shared proms_we/proms_wraddr slot as Buck's PROMs above. rtl/segavco.v:503 no consumer in MAME -- loaded, not wired rtl/segavco.v:969 LS148 priority encoder: index of the lowest-numbered set bit in plb (0-7), or 4'hf if plb==0 (MAME: countl_zero(bitswap<8>(plb,0,1,2,3,4,5,6,7)) with the mux==8 clamp folded in). rtl/segavco.v:1034 repack_bg's shifts overflow 8 bits on purpose: MAME's palbits is a plain int, and this is how the bgcolor branch reaches the upper 3/4 of the 1024-entry (10-bit) palette. rtl/segavco.v:1072 IC20 (PR-1116, TBP18S030 32x8 PROM; P-ROM board sheet 2/10) has address inputs PLB0-2 (A0-A2) and SLIPAR/ACCIAR (A3-A4), i.e. sprbits[26:24] and babit[4]/babit[5], matching turbo_v.cpp's ((sprbits>>24)&7) \| ((babit&0x30)>>1). rtl/video/fg_tilemap.v:4 Buck Rogers' column fetch is remapped through PR-5194 (an X-shift PROM): col = pr5194[((xx>>3)-1) & 0x1f] Output "foreraw" is MAME's `color4 + pixel`, an 8-bit raw pen for the mixer. rtl/video/fg_tilemap.v:21 It is a plain 8-native-pixel shift with the tilemap forced blank outside [8, 0x108) (MAME turbo_v.cpp: `foreraw = (xx<8\|\|xx>=0x108) ? rtl/video/fg_tilemap.v:47 Simulation-only combinational read port on the tilemap VRAM, for comparing the HUD cell-for-cell against MAME. rtl/video/fg_tilemap.v:113 Turbo's blanking window (MAME turbo_v.cpp). rtl/video/fg_tilemap.v:113 The ">=264" arm can never fire since xx is 8 bits; it is kept to mirror the MAME source. rtl/video/mixer_turbo.v:3 Follows MAME's turbo_state::screen_update. rtl/video/road_gen.v:3 Follows MAME's turbo_state::screen_update. rtl/video/sprite_engine.v:13 Register widths stay at Buck Rogers' (larger) sizes; Turbo's narrower values are computed in their native width and then zero-extended, which reproduces MAME's masked/uint16_t arithmetic (e.g. Turbo's ROM address is a true 14-bit mask, `(of rtl/video/sprite_engine.v:18 PR-5195 (the sprite state machine PROM) is intentionally not read: MAME's prepare_sprites() models that sequencer chip directly as boolean logic, as this module does. rtl/video/sprite_engine.v:302 Gate on the full 9-bit vpos so the FSM runs exactly once per visible scanline (y_target_next = 0..VDISP-1), as MAME's per-line loop does: at vpos = VTOTAL-1 (wrap, prepares y=0) and vpos = 0..VDISP-2. rtl/video/sprite_engine.v:449 ROM address from the 17-bit offset register: Buck Rogers uses offs[15:1]; Turbo masks to offs[14:1] (MAME's `(offs>>1)&0x3fff`), taken from the 16-bit slice so wraparound is confined to 16 bits. rtl/video/sprite_engine.v:473 Gates the fetch/advance path and the output path (latched_masked) like MAME's local `sprlive`, but not lst_active's own accumulation. README.md:70 Gear Overlay* (off by default) shows a small L or H beside the TIME readout for the gear lever position the game is reading, like the lever graphic in MAME's a README.md:90 [MAME](https://www.mamedev.org/) - reference driver source (`turbo.cpp`, `turbo_v.cpp`, `turbo_a.cpp`, `resnet.h`) for memory maps, table derivations and cr Says it matches, follows or was checked against MAME — 1 rtl/video/sprite_engine.v:45 visible scanlines, y=0..VDISP-1 (matches MAME cliprect.min_y/max_y) Shares text with the MAME driver without saying so — 2 rtl/segavco.v:970 or 4'hf if plb==0 (MAME: countl_zero(bitswap<8>(plb,0,1,2,3,4,5,6,7)) with — shares text with sega/turbo.cpp:1813 rtl/video/fg_tilemap.v:23 [8, 0x108) (MAME turbo_v.cpp: `foreraw = (xx<8\|\|xx>=0x108) ? 0 : — shares text with sega/turbo_v.cpp:459
SegaVICZ80# Carnival, Pulsar MiSTer-devel/Arcade-SegaVICZ80_MiSTer @ 275d0d7e MAME compared: sega/vicdual.cpp + 12 related file(s) Read: 31 HDL files, 18,130 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	5%
Statements: 2 toward hardware, 2 toward MAME Cites hardware documentation that MAME's driver does not — 2 rtl/system.v:432 Samurai protection circuit - taken from MAME as I can't find the schematics rtl/system.v:652 - The U44 PROM and surrounding circuitry for colour output is taken from the Head On 2 schematic Cites MAME source — 1 rtl/system.v:928 Wave sample player module - Used by Carnival, Invinco and Pulsar to emulate analog sound board by playing WAV samples sourced from MAME project Says it was translated, ported or taken from MAME — 1 rtl/system.v:432 Samurai protection circuit - taken from MAME as I can't find the schematics
SegaXBoard# A.B. Cop, After Burner, After Burner II, GP Rider … MiSTer-devel/Arcade-SegaXBoard_MiSTer @ 83bb1314 MAME compared: sega/segaxbd.cpp + 12 related file(s) Read: 31 HDL files, 5,748 lines (Quartus project)	MiSTer official	Mostly MAME	medium	67%
Statements: 8 toward hardware, 76 toward MAME Cites hardware documentation that MAME's driver does not — 1 rtl/io/xb_adc0804.sv:6 Channel select = I/O chip #1 port C bits 4:2 (MAME, from the schematic). Says it was checked on “real hardware” — 6 README.md:21 \| M7 \| After Burner and Thunder Blade \| done: aburner (1.32/1.31), thndrbld1, thndrbldd confirmed on hardware; Thunder Blade pixel-exact vs MAME; FD1094 parent README.md:22 \| M8 \| Super Monaco GP \| done: smgpd (decrypted bootleg) with the second sound board and driving inputs, pixel-exact vs MAME, confirmed on hardware; official FD README.md:24 \| M10 \| Racing Hero and A.B. Cop \| done: six sets (bootlegs pixel-exact vs MAME, FD1094 parents), confirmed on hardware \| README.md:25 \| M11 \| GP Rider \| done: three single-board FD1094 sets, confirmed on hardware \| README.md:26 \| M12 \| Last Survivor \| done: input multiplexer, two players, bootleg and FD1094 sets, confirmed on hardware \| README.md:27 \| M13 \| Line of Fire \| done: six sets, lightgun/gamepad gun control with cursor speed and crosshair, confirmed on hardware \| Notes where it differs from MAME — 1 README.md:165 `docs/DESIGN.md` records the results per milestone, and where the RTL deliberately differs from MAME. Cites MAME source — 63 rtl/audio/xb_segapcm_5218.sv:2 Sega 315-5218 PCM (SegaPCM), MAME segapcm.cpp with BANK_512 (bankshift 12, bankmask 0x70). rtl/audio/xb_segapcm_5218.sv:9 The sums are in MAME's 1/32768 units, i.e. directly 16-bit samples. rtl/audio/xb_segapcm_5218.sv:11 ROM bytes come from SDRAM port p6 (16-bit words, byte selected by A0); the stream pads the PCM slot with 0xFF like MAME's ERASEFF region. rtl/audio/xb_segapcm_5218.sv:42 MAME m_low: addr[7:0] per channel rtl/audio/xb_soundsys.sv:7 Mix: MAME routes PCM at 0.35 and the YM2151 at 0.15 of full scale. rtl/cpu/fd1094/jts16_fd1094_dec.v:146 decoding, pretty much copy-paste from MAME's fd1094.cpp I trust the synthesizer to simplify the equations rtl/cpu/xb_cmptimer_5250.sv:2 Sega 315-5250 compare / timer / 68000-Z80 interface Word offsets (address bits 4:1), reference MAME segaic16_m.cpp: 0,1 bounds (write executes compare) 3 flags: 0x8000 below min, rtl/cpu/xb_cmptimer_5250.sv:37 MAME's m_bit keeps counting; bits >= 16 fall off the u16 rtl/cpu/xb_math_5248.sv:4 Reference: MAME segaic16_m.cpp. rtl/cpu/xb_math_5249.sv:10 Reference: MAME segaic16_m.cpp sega_315_5249_divider_device::execute. rtl/cpu/xb_math_5249.sv:74 operands as they are after this same write (MAME updates the register first, then executes) rtl/cpu/xb_math_5249.sv:151 MAME: remainder = dividend - clamped_q * divisor rtl/io/xb_adc0804.sv:6 Channel select = I/O chip #1 port C bits 4:2 (MAME, from the schematic). rtl/io/xb_adc0804.sv:7 Reference MAME adc0804.cpp + segaxbd.cpp analog_r. rtl/io/xb_adc0804.sv:49 sampled at end of conversion (MAME) rtl/io/xb_cxd1095.sv:6 Reference MAME cxd1095.cpp. rtl/io/xb_cxd1095.sv:22 latch & ~dir (as MAME's dataout) rtl/io/xb_cxd1095.sv:28 1 = input, per MAME m_data_dir rtl/io/xb_stick.sv:5 Three opt-ins: ramp the D-pad drives a virtual stick 5 counts a frame (full lock in 26 frames, near MAME's PORT_KEYDELTA(4) over 0x20..0xE0) instead of snapping ~recenter releasing the D-pad leaves the virtual stick where it is; the op rtl/mem/xb_fb_if.sv:5 Empty framebuffer pixel = 0xFFFF (MAME's transparent value). rtl/mem/xb_fb_if.sv:6 Services (per DESIGN.md): - erase_line(y): fill line with 0xFFFF - write_run(...): pixel run writes from the sprite renderer; wr_shadow runs RMW dest &= 0x7fff instead (MAME shadow sprites clear framebuffer bit 15) - read_line(y): rtl/video/xb_palette_5242.sv:4 Palette word: bit 15 = effects select (1 hilight / 0 shadow), 14:12 = LSB of B/G/R, 11:8 B, 7:4 G, 3:0 R (MAME paletteram_w). rtl/video/xb_road_5275.sv:2 Sega 315-5275 road generator (X Board), MAME segaic16_road.cpp segaic16_road_outrun_draw with the X Board parameters (colorbase 0x1700 / 0x1720 / 0x1780, xoffs -166, control mask 7). rtl/video/xb_road_5275.sv:73 MAME priority_map rtl/video/xb_road_5275.sv:141 background colour for this line (MAME ROAD_BACKGROUND pass) rtl/video/xb_sprite_5211.sv:4 Algorithm: MAME sega16sp.cpp sega_outrun_sprite_device::draw (xboard): w0: e------- -------- end of list; -h-h---- hide; ----bbb- bank; -------t tttttttt top + 256 w1: ROM offset (16-bit words of 32-bit pixels) w2: ppppppp- pitch (signed, rtl/video/xb_sprite_5211.sv:20 At vblank the buffers swap only if a render ran since the previous swap, so a frame without a $110000 write keeps displaying the old image exactly like the real chip (MAME's every-frame redraw of the buffered list is an emulator artefact wi rtl/video/xb_sprite_5211.sv:115 data[7] in MAME: the row's working pointer rtl/video/xb_sprite_5211.sv:116 `addr` above is the row base, advanced by pitch at each row end (MAME's addr) rtl/video/xb_sprite_5211.sv:134 pixel reordering for non-flipped sprites (MAME): reverse the nibble order rtl/video/xb_sprite_5211.sv:140 MAME clips to the screen rtl/video/xb_sprite_5211.sv:141 framebuffer x window: MAME clips to screen x 0..319 = fb x 190..509 (2x: 380..1019) rtl/video/xb_sprite_5211.sv:291 MAME: data[7] = addr at row start rtl/video/xb_sprite_5211.sv:306 MAME: second-to-last pixel of the group rtl/video/xb_sprite_5211.sv:362 skip an off-screen row but advance the base address exactly like MAME (its own state so row_sum has settled since the last yacc write) rtl/video/xb_tilemap_5197.sv:2 Sega 315-5197 tilemap generator, "16B" register layout (MAME segaic16.cpp tilemap_16b_). rtl/video/xb_tilemap_5197.sv:7 Text RAM (word offsets): 0x740..0x743 page select set 0..3 (E80..E87) 0x748..0x74B y scroll set 0..3, bit 15 = column scroll on (E90..E97) 0x74C..0x74F x scroll set 0..3, bit 15 = row scroll on (E98..E9F) 0x7C0 + 0x20layer + (y>>3) rtl/video/xb_tilemap_5197.sv:16 Tile word: 15 priority, 12:6 colour, 12:0 code (they overlap, as in MAME). rtl/video/xb_tilerom.sv:5 Plane 2 (third ROM, epr-11113) is pen bit 2 (MAME gfx_8x8x3_planar: RGN_FRAC(2,3) is the MSB plane). rtl/video/xb_video_timing.sv:4 MAME: m_screen->set_raw(MASTER_CLOCK/8, 400, 0, 320, 262, 0, 224). rtl/video/xb_video_timing.sv:61 Sync widths follow the System 16-family convention used by MAME's screen layout: hsync from 336..367 (32 px), vsync lines 240..243 (4 lines). rtl/xb_core.sv:161 ---------------------------------------------------------------- watchdog MB3773: kicked by I/O chip #1 port C bit 6 and by every vblank (MAME update_main_irqs). rtl/xb_core.sv:195 main 68000 RESET instruction -> sub CPU reset (MAME m68k_reset_callback) rtl/xb_core.sv:306 MAME writes 0xFFFF to word 0 of the bank handed back to the CPU after the swap ("hack for thunderblade"); it is invisible on After Burner II, so it is enabled per game through the descriptor. rtl/xb_core.sv:350 MAME: active low unknown -> 1), D6 = ADC /INTR (active high), D7 n/c rtl/xb_core.sv:352 MAME aburner2_motor_r / smgp_motor_r rtl/xb_core.sv:357 Last Survivor: I/O chip 1 port B reads one of four input groups selected by I/O chip 0 port D bits 6:5 (MAME lastsurv_muxer_w / lastsurv_port_r): 0 = P2 stick + aim, 1 = P1 stick + aim, 2 = attack buttons (P1 bit 4, P2 bit 0), 3 = nothing. rtl/xb_core.sv:360 The aim rotary is an 8-position encoder read back as a 4-bit active-low direction pattern (MAME lastsurv_position_table); it follows the right stick and keeps its last direction when released. rtl/xb_core.sv:390 Positions are 0..255 like MAME's lightgun ports; the ADC reversal of the Y channels comes from the descriptor (MAME install_loffire). rtl/xb_core.sv:438 MAME: set_display_enable(data & 0x20) rtl/xb_core.sv:441 After Burner: MAME's ranges X 0x20..0xE0, Y 0x40..0xC0 with PORT_REVERSE (stick up reads high), throttle on channel 2. rtl/xb_core.sv:485 driving (Super Monaco GP): steering 0x38..0xC8 on ADC0, gas 0x38..0xB8 on ADC1, brake 0x28..0xA8 on ADC2 (MAME ranges). rtl/xb_core.sv:501 GP Rider: steering full range 0x01..0xFF on ADC0, pedals 0x10..0xEF read the other way up from the rest of the driving games (MAME PORT_REVERSE on both pedals): released is 0xEF, floored is 0x10. rtl/xb_core.sv:807 crosshair overlay for the gamepad gun mode (P1 white, P2 yellow): the 0..255 positions map to the 320x224 screen as MAME's crosshairs do rtl/xb_core.sv:842 Super Monaco GP's second sound board (deluxe cabinet rear speakers): the same Z80 + 315-5218 without the YM2151, fed by the same 315-5250 latch and NMI (MAME appends soundcpu2 to the zint line; either Z80's port 0x40 read clears it). rtl/xb_pkg.sv:14 ---- video timing (MAME: MASTER_CLOCK/8, 400, 0, 320, 262, 0, 224) ----- README.md:15 \| M1 \| Both 68000s boot, math/timer/IO chips pass unit tests, PC traces track MAME \| done in sim (self-test screen check moves to M2) \| README.md:20 \| M6 \| Hardware bring-up and timing closure \| done: DIPs, NVRAM, MAME analog ranges, pause; zero negative slack all corners, 49% ALMs; ROM cache fill defect fix README.md:45 \| Game \| MAME set \| ROM zips (MAME 0.289) \| Main CPU \| README.md:130 Needs Verilator, Icarus Verilog, Python 3.12 and MAME. README.md:232 MAME (mamedev.org) — the behavioural reference for the whole board: `segaxbd.cpp` and the 16-bit Sega device family (`segaic16`, `sega16sp`, `segaic16_road` README.md:236 Every custom chip model in `verif/models/` is a port of the MAME code, and MAME 0.289 produced the golden frames, traces and audio the RTL is checked against. README.md:239 Charles MacDonald — "Sega X-Board hardware notes" (2004), the real-hardware description of the sprite sequencing, memory map and I/O used where MAME simplif Says it matches, follows or was checked against MAME — 6 README.md:16 \| M2 \| Tilemap/text/palette pixel-exact against MAME \| done in sim \| README.md:21 \| M7 \| After Burner and Thunder Blade \| done: aburner (1.32/1.31), thndrbld1, thndrbldd confirmed on hardware; Thunder Blade pixel-exact vs MAME; FD1094 parent README.md:22 \| M8 \| Super Monaco GP \| done: smgpd (decrypted bootleg) with the second sound board and driving inputs, pixel-exact vs MAME, confirmed on hardware; official FD README.md:23 \| M9 \| FD1094 \| done: decryptor unit-verified against MAME; encrypted Thunder Blade and Super Monaco GP (World, Rev B) pixel-exact vs MAME and confirmed on hard README.md:24 \| M10 \| Racing Hero and A.B. Cop \| done: six sets (bootlegs pixel-exact vs MAME, FD1094 parents), confirmed on hardware \| README.md:157 What the tests show: the custom chips are checked against Python ports of MAME's C++ (the 315-5248/5249/5250 over 10^5 random operations, the FD1094 over 30,000 Says it was translated, ported or taken from MAME — 1 rtl/video/xb_mixer.sv:2 X Board video priority mixer (315-5279 PAL + 315-5197 pixel bus), a direct port of MAME segaxbd_state::screen_update: road background -> [road fg if road_priority == 0] -> bg pri0 (mark 1) -> bg pri1 (2) -> fg pri0 (2) -> fg pri1 (4) -> [ro Keeps a MAME approximation — 2 rtl/xb_core.sv:190 GP Rider (MAME m_gprider_hack): with the link board absent the game must not see level 6, so timer+vblank together present level 4 (the timer follows after) rtl/xb_pkg.sv:53 ---- per-game descriptor (first 64 bytes of the stream) ---------------- byte 0: game id (0 = aburner2, 1 = aburner, 2 = thndrbld, ...) byte 1: flags: bit0 road_priority (0: road fg under tiles, 1: over) bit1 thndrbld sprite-RAM wipe hack b Shares text with the MAME driver without saying so — 4 rtl/cpu/xb_math_5249.sv:10 Reference: MAME segaic16_m.cpp sega_315_5249_divider_device::execute. — shares text with sega/segaic16_m.cpp:180 rtl/video/xb_sprite_5211.sv:379 yacc += vzoom; addr += pitch * (yacc >> 9); yacc &= 0x1ff — shares text with sega/sega16sp.cpp:1208 rtl/video/xb_video_timing.sv:4 MAME: m_screen->set_raw(MASTER_CLOCK/8, 400, 0, 320, 262, 0, 224). — shares text with sega/segaxbd.cpp:1842 rtl/xb_pkg.sv:14 ---- video timing (MAME: MASTER_CLOCK/8, 400, 0, 320, 262, 0, 224) ----- — shares text with sega/segaxbd.cpp:1842
SeibuCupSoccer# Seibu Cup Soccer MiSTer-devel/Arcade-SeibuCupSoccer_MiSTer @ 52c9fa22 MAME compared: seibu/legionna.cpp + 8 related file(s) Read: 21 HDL files, 10,080 lines (Quartus project)	MiSTer official	Mostly MAME	medium	83%
Statements: 7 toward hardware, 234 toward MAME, 1 not counted Cites hardware references or measurements that MAME's driver also gives — 1 rtl/SeibuCup/SeibuCup_maincpu_map.sv:23 Main CPU memory map SeibuCup / SD Gundam (legionna.cpp cupsoc_map): $000000-$0FFFFF ROM 68K (1MB) → SDRAM via bridge $100000-$1003FF RAM scratch (1KB) → BRAM (Main RAM low) $100400-$1006FF COP3 region — also in MAME: 68K seibu/legionna.cpp:46 Says it was checked against the original PCB — 1 README.md:28 The core boots, plays and has been checked against the original PCB. Reports a measurement taken on the original PCB — 1 rtl/SeibuCup/SeibuCup_video_timing.sv:26 PCB measurement Blood Bros: VSync 59.4094 Hz, HSync 15.6246 kHz, master XTAL 20 MHz. Says it was checked on “real hardware” — 4 rtl/SeibuCup/SeibuCup_cop3.sv:387 0 : 1 (unsigned <320 provato su HW = REGRESSIONE; il signed [-160,320) dell'intento MAME e' il comportamento giusto sul core) rtl/SeibuCup/SeibuCup_sprite_renderer.sv:218 byte_lo = pf_rom_data[31:24]/[15:8], byte_hi = [23:16]/[7:0] Plane order DCBA (verificato su HW, come BG/MG/FG): pen[0] dal bit "D" (byte_hi[3-sub]), pen[3] dal bit "A" (byte_lo[7-sub]). rtl/SeibuCup/SeibuCup_sprite_renderer.sv:368 Scan INVERSO 511→0 (verificato su HW: ordine sprite-su-sprite opposto al loop MAME 0→511). rtl/SeibuCup/SeibuCup_tile_layer.sv:322 Plane order verificato su HW: BG/MG = DCBA (PEN_ORDER=0), FG = BADC (PEN_ORDER=1). Notes where it differs from MAME — 1 rtl/SeibuCup/SeibuCup_cop3.sv:3130 La chiave e' la word CON SEGNO all'indirizzo ALLINEATO AL LONG: key = read_word( (sort_ram + val) & ~3 ) E' l'unica funzione che soddisfa i due testimoni del ROM: piani $00363E: $110004 + val (val ≡0 mod 4) = $1157EC, e la chiave e' la Y Cites MAME source — 216 SeibuCup.sv:225 La finestra visibile e' set_visarea(0,319, 8,247): in MAME lo sprite a Y=8 finisce sulla riga 8 della bitmap, che la visarea mostra IN CIMA (m_xoffset/m_yoffset del SEI0211 sono 0, legionna.cpp non chiama set_offset). SeibuCup.sv:354 --- Joystick to SD Gundam input mapping --- MAME P1_P2 port ($E0002): active low. SeibuCup.sv:357 MiSTer joy bits: joy[0]=R, joy[1]=L, joy[2]=D, joy[3]=U, joy[4]=A, joy[5]=B. MAME PLAYERS12 (legionna.cpp:439-444): bit[0]=UP, [1]=DOWN, [2]=LEFT, [3]=RIGHT, [4]=BTN1, [5]=BTN2, [6]=BTN3, [7]=unused (active low). SeibuCup.sv:377 SeibuCup SYSTEM port ($10074C) — MAME legionna.cpp:427-436 bit0 = START1 (active LOW) bit1 = START2 (active LOW) bit2..7 = UNKNOWN → tied 1 bit8..15 = UNKNOWN → tied 1 Coin inputs NON sono qui: vanno via SEIBU_COIN_INPUTS → Z80 → soundlatch SeibuCup.sv:384 bit8 = START3, bit9 = START4 (MAME porta "SYSTEM" di cupsoc). SeibuCup.sv:421 00 = cupsoc / cupsoca nessuna modifica 01 = olysoc92 / a / b [$0FFFFE] = $3032 -> titolo Olympic Soccer '92 02 = cupsocb [$0FFFFA] = $00FF -> spegne il testo di debug Sono le stesse due scritture che MAME fa in ini SeibuCup.sv:773 ── Flip screen (CRTC reg 0x1A bit 0) ─────────────────────────────────────── MAME: BIT(reg_1a, 0) → flip_screen. SeibuCup.sv:819 ── Text layer renderer (8x8, 4bpp, 64x32 grid) ───────────────────────────── SeibuCup MAME (ROM_START godzilla): "char" = REGIONE PROPRIA 128KB (11.620/10.615, ROM_LOAD16_BYTE), NON dentro user1 come Legionnaire. SeibuCup.sv:832 SeibuCup text scroll-base (CRTC reg 0x3A, hook godzilla-only legionna.cpp:1326). SeibuCup.sv:833 Calibrazione HW di famiglia (dump vregs in seibu_crtc.cpp): Legionnaire reg=0x01FF, visarea da riga 16 → 0x1FF-0x1EF=+16 = ESATTAMENTE il vecchio yoff text +16 del core Legionnaire funzionante; D-Con reg=0xFFEF (low9=0x1EF), visarea da 0 → SeibuCup.sv:837 La formula MAME set_scrolldy(0x1EF-data) è INVERTITA rispetto all'HW (convenzione dy del tilemap.cpp) — mai fidarsi del verso MAME. SeibuCup.sv:875 SeibuCup CRTC scroll passthrough (legionna_v.cpp:34-49 tile_scroll_w): scroll_ram[0/1] → BG (m_background_layer) scroll_ram[2/3] → MG (m_midground_layer) scroll_ram[4/5] → FG (m_foreground_layer) Nel nostro CRTC: xscroll_l0 = ram[0/1], xscr SeibuCup.sv:880 Finestra visibile di CUPSOC: legionna.cpp fa screen.set_visarea(08, 408-1, 18, 318-1) = [0..319] x [8..247] quindi origine X = 0 e origine Y = 8. SeibuCup.sv:905 SeibuCup BG: tilemap 32x32 (legionna_v.cpp:204). SeibuCup.sv:906 MAME GFXDECODE "back" color base = 0 (gfx_legionna riga 1168), 32 colorset. SeibuCup.sv:907 HAS_TRANSP=1 perché m_background_layer->set_transparent_pen(15) in legionna_v.cpp:216 (pen 15 = trasparente, NON opaco come Blood Bros). SeibuCup.sv:929 SeibuCup MG: 16x16, 4bpp, 32x32 tilemap (legionna_v.cpp:204). SeibuCup.sv:930 get_mid_tile_info_share_bgrom (legionna_v.cpp:158): MG share BG ROM, tile = (vram & 0xfff) \| 0x1000 (= seconda metà della BG ROM) color = ((vram >> 12) & 0xf) \| 0x10 (= palette set superiore: bit 4 = 1) In palette MAME "back" base = 0, SeibuCup.sv:957 SeibuCup FG: tilemap 32x32 (legionna_v.cpp:213). SeibuCup.sv:959 MAME GFXDECODE "fore" color base = 3216 = 0x200, 16 colorset. SeibuCup.sv:969 SEIBUCUP: fore = bg2.619 ROM_LOAD16_WORD_SWAP (legionna.cpp:1987) = IDENTICO alla back bg1.618 → stesso decode DCBA di BG/MG (riscontro HW utente: col BADC il FG era sbagliato). SeibuCup.sv:977 SeibuCup: bit 2 = FG (legionna_v.cpp:344) SeibuCup.sv:1064 Anticipando di 1 l'indirizzo e il DE, il dato campionato al tick e' quello del pixel CORRENTE: allineamento coi tile ripristinato (= calibrazione +1 pixel-hunting MAME, fatta prima del fix CRT) e colonna 0 coperta. SeibuCup.sv:1098 MAME riferimenti (VIDEO_START cupsoc, legionna_v.cpp:276-287): m_sprite_pri_mask per cupsoc: pri=0 → 0xFFF0 (copre pri-value 0,1,2 → bg,mg,fg → SOTTO text) pri=1 → 0xFFFC (copre 0,1 → bg,mg → sotto fg,text) pri=2 → 0xFFFE (copre 0 → bg → SeibuCup.sv:1108 Ordine composite RTL (front→back), derivato dalle pri_mask sopra: Sprite pri=3 (sopra tutto, text incluso) Text (pri-value 4) Sprite pri=0 (sopra bg/mg/fg, sotto text) FG (pri-value 2) Sprite pri=1 (sopra bg/mg) MG rtl/SeibuCup/SeibuCup_audio_z80.sv:25 Spec da MAME (legionna.cpp godzilla machine config :1295-1355): - Z80 @ 14.318180/4 = 3.579545 MHz (seibu_sound_map + godzilla_sound_io_map) - YM3812/OPL2 (jtopl2) @ 3.579545 MHz - OKI M6295 (jt6295) @ 20MHz/20 = 1.000 MHz, PIN7=HIGH, ROM 5 rtl/SeibuCup/SeibuCup_audio_z80.sv:57 SeibuCup pcm.922 = 512KB: bit 18 = bank (Z80 IO port 0, MAME godzilla_oki_bank_w: set_rom_bank(data&1)). rtl/SeibuCup/SeibuCup_audio_z80.sv:385 MAME seibu_sound_device::main_r (seibusound.cpp:279): case 2,3: return sub2main[offset-2] (soundlatch data: coin/input dal Z80) case 5: return main2sub_pending ? rtl/SeibuCup/SeibuCup_audio_z80.sv:446 ─── YM3812 (jtopl2) mono — CUPSOC usa OPL2, non OPM ──────────────────── MAME cupsoc machine config: ym3812_device @ 14318180/4 (legionna.cpp). rtl/SeibuCup/SeibuCup_audio_z80.sv:491 ─── OKI M6295 (jt6295) — PIN7_HIGH (20MHz/20 = 1.0 MHz, legionna.cpp:1345) rtl/SeibuCup/SeibuCup_cop3.sv:4 MAME-faithful implementation of the Seibu SEI300 chip as used by the `legionna` driver (SeibuCup 1992 — Banpresto/TAD). rtl/SeibuCup/SeibuCup_cop3.sv:7 Reference (in this repo): MAME seibucop.cpp MAME seibucop_cmd.ipp MAME seibucop_dma.ipp MAME legionna.cpp rtl/SeibuCup/SeibuCup_cop3.sv:140 Z-sorting DMA: registri $100450-$100458 (MAME cop_sort_). rtl/SeibuCup/SeibuCup_cop3.sv:153 MAME cop_itoa_digits[10]: BCD digits of cop_itoa (low<<0 \| high<<16). rtl/SeibuCup/SeibuCup_cop3.sv:157 Il vecchio loop a sottrazioni ripetute era O(valore) (~valore/9 clk): con i long 32-bit di godzilla (score, writer $156E/$1F93E) il 68k restava congelato (dma_busy include bcd_pending) fino a MILLISECONDI per chiamata — su MAME/HW reale i d rtl/SeibuCup/SeibuCup_cop3.sv:170 MAME cop_program command table (seibucop.cpp lines 318-457) At boot, game code uploads 32 macro slots × 8 micro-op words via pgm_addr (0x100434) → slot8 + sub-index pgm_data (0x100432) → micro-op word pgm_value (0x100438) → cop_func_valu rtl/SeibuCup/SeibuCup_cop3.sv:177 MAME calls find_trigger_match(triggerval, 0xff00) to find the slot whose cop_func_trigger matches. rtl/SeibuCup/SeibuCup_cop3.sv:299 Triggers (write-only addresses) MAME legionna.cpp:172 maps cop_cmd_w to $100500-$100505 (3 words). rtl/SeibuCup/SeibuCup_cop3.sv:381 0x100410 sprite_dma_inc (MAME cop_sprite_dma_inc_w): if x_clip in [-160, 320): cop_regs[4] += 8. rtl/SeibuCup/SeibuCup_cop3.sv:382 MA in MAME sprite_x e' uint16_t assegnato a int -> MAI negativo -> il -160 e' codice morto: check EFFETTIVO = unsigned < 320 (X "negative" 0xFFxx NON avanzano il puntatore entry). rtl/SeibuCup/SeibuCup_cop3.sv:387 0 : 1 (unsigned <320 provato su HW = REGRESSIONE; il signed [-160,320) dell'intento MAME e' il comportamento giusto sul core) rtl/SeibuCup/SeibuCup_cop3.sv:394 A size==0 NON wrappare (il size-- uint di MAME wrapperebbe a $FFFF: il loop del builder su status[1] andrebbe in livelock — provato peggio). rtl/SeibuCup/SeibuCup_cop3.sv:437 Macro program upload — MAME seibucop.cpp lines 318-457 pgm_data writes one micro-op word to cop_program[latch_addr] AND latches the slot's trigger/value/mask from current latch regs. rtl/SeibuCup/SeibuCup_cop3.sv:538 itoa_digits (MAME 0x100590-99, 5 word). rtl/SeibuCup/SeibuCup_cop3.sv:550 Status / dist / angle (seibucop.cpp:916 cop_status_r → cop_status) rtl/SeibuCup/SeibuCup_cop3.sv:558 MAME open bus rtl/SeibuCup/SeibuCup_cop3.sv:625 commit write al dst ASSOLUTO (fill/mr), 1:1 MAME write_word(dst) rtl/SeibuCup/SeibuCup_cop3.sv:661 LEGACY sprite-DMA (seibucop_cmd.ipp): 6880 (carica rel_xy), c480 (single-step: compone l'entry sprite a cop_regs[4]+offs con X/Y = rel + (obj - abs)). rtl/SeibuCup/SeibuCup_cop3.sv:685 write angolo (word {0,angle} come MAME host_endian) rtl/SeibuCup/SeibuCup_cop3.sv:686 5105/f105 — moltiplicatore 16.16 (ricavato da ROM+disasm, non da MAME: li' gli handler sono vuoti). rtl/SeibuCup/SeibuCup_cop3.sv:698 dde5 — i PALLINI DEL RADAR (MAME LEGACY_execute_dde5). rtl/SeibuCup/SeibuCup_cop3.sv:752 Trigger latches — MAME seibucop.cpp cop_cmd_w line 1069. rtl/SeibuCup/SeibuCup_cop3.sv:753 MAME dispatches on raw data after clearing cop_status bit 15. rtl/SeibuCup/SeibuCup_cop3.sv:807 DMA mode 0x80-0x87: MAME dma_palette_brightness() fa FADE solo con pal_brightness_mode 4/5; con qualsiasi altro valore fa una COPIA SEMPLICE src->dst (ramo else, seibucop_dma.ipp:119-123) verso QUALUNQUE dst — incl. rtl/SeibuCup/SeibuCup_cop3.sv:815 DMA generici 0x09/0x0E: MAME write_word(dst) va nello spazio host = arriva a QUALSIASI RAM mappata, incluse le BRAM video ($101000-$105FFF: staging tilemap, palette-stage $104000, sprite $105000). rtl/SeibuCup/SeibuCup_cop3.sv:823 Output del fade/blend 0x8x: MAME dma_palette_brightness fa write_word(dst) nello SPAZIO HOST = raggiunge QUALUNQUE RAM mappata (pal-stage $104000, sprite $105800, Main RAM...). rtl/SeibuCup/SeibuCup_cop3.sv:826 Ora: pal_val registrato in D_FADE_WRITE e committato in D_FADE_COMMIT via canale fill (decode per dst assoluto in main_top: bg/fg/mg/txt/pal/spr) o mr (dst in Main RAM) — 1:1 MAME. rtl/SeibuCup/SeibuCup_cop3.sv:829 (Il vecchio dma80_to_spr era INVERTITO: il blit pietre e' src=$105800 dst=$104000, non il contrario — MAME map: $100478=SRC, $10047C=DST.) rtl/SeibuCup/SeibuCup_cop3.sv:838 LEGACY sprite-DMA state (MAME m_sprite_dma_rel_x/y, m_sprite_dma_x_clip) rtl/SeibuCup/SeibuCup_cop3.sv:966 MAME cop_cmd_w (seibucop.cpp:1075): rtl/SeibuCup/SeibuCup_cop3.sv:978 MAME cop_sort_dma_trig_w -> dma_zsorting(data): n = data + 1 rtl/SeibuCup/SeibuCup_cop3.sv:1006 find_trigger_match (seibucop.cpp:464) Cerca slot N tale che (trigger & 0xf800) == (cop_func_trigger[N] & 0xf800) && cop_func_trigger[N] != 0. rtl/SeibuCup/SeibuCup_cop3.sv:1008 Restituisce canonical trigger value del slot (NB: MAME LEGACY_cop_cmd_w usa il match slot per dispatchare; in pratica equivale a restituire cop_func_trigger[slot]). rtl/SeibuCup/SeibuCup_cop3.sv:1029 fade_table — MAME seibucop.cpp:733 (reverse engineered from Seibu Cup Soccer bootleg) v = pal_channel(5-bit) \| (brightness_val_xor_X) [10-bit input] low = v & 0x1F high = v & 0x3E0 return (low (high \| (high>>5)) + 0x210) >> 10 [8-bit o rtl/SeibuCup/SeibuCup_cop3.sv:1068 ── Hitbox b100/b900 scratch (MAME cop_collision_update_hitbox) ────────────── dx[i] = int8 (signed) byte basso, size[i] = uint8 (unsigned) byte alto del word descrittore @ hitadr2+2i. 3 assi (Y,X,Z) per SeibuCup. rtl/SeibuCup/SeibuCup_cop3.sv:1075 num_axis: MAME seibucop.cpp:1010 "if (data & 0x100) num_axis = 3" else 2. rtl/SeibuCup/SeibuCup_cop3.sv:1077 res init 7 vs 3 (seibucop.cpp:1038-39). rtl/SeibuCup/SeibuCup_cop3.sv:1083 Delta LATCHATI dall'ultimo comando d'angolo: il 3bb0 NON li ricalcola, li riusa (in MAME sono m_LEGACY_r0/r1, e il TODO sopra execute_3b30 dice esattamente questo). rtl/SeibuCup/SeibuCup_cop3.sv:1107 dde5: divisore CON SEGNO (in MAME e' una divisione C int, quindi troncamento verso zero). rtl/SeibuCup/SeibuCup_cop3.sv:1138 Con 16-bit frac + 24 iter + z>>16: 0 divergenze di decisione vs MAME int(atan(dx/dy)128/pi) su ~640k casi (dimostrato numericamente). rtl/SeibuCup/SeibuCup_cop3.sv:1391 MAME cop_dma_trigger_w: NON modifica cop_status (vedi seibucop.cpp:741). rtl/SeibuCup/SeibuCup_cop3.sv:1399 MAME dma_tilemap_buffer: copy staging RAM → renderer BRAM src = cop_dma_src[mode] << 6 (byte addr 0x101000+ = staging) dst = i (loop counter 0..0x13FF = renderer index) count = 0x2800/2 = 5120 words rtl/SeibuCup/SeibuCup_cop3.sv:1409 MAME dma_palette_buffer: copy staging palette → renderer src = cop_dma_src[mode] << 6 (0x104000 = palette staging) dst = i (loop counter 0..0x7FF = renderer index) count = 0x1000/2 = 2048 words rtl/SeibuCup/SeibuCup_cop3.sv:1419 MAME write_word(dst) su spazio host: con dst nelle BRAM video ($101000-$105FFF: staging/pal/spr, es. rtl/SeibuCup/SeibuCup_cop3.sv:1434 simplified, MAME size>>1 rtl/SeibuCup/SeibuCup_cop3.sv:1439 MAME seibucop_dma.ipp dma_palette_brightness() mode 5/4. rtl/SeibuCup/SeibuCup_cop3.sv:1442 MAME formulas: src = cop_dma_src[mode] << 6 dst = cop_dma_dst[mode] << 6 size = ((cop_dma_size << 5) - (cop_dma_dst << 6) + $20)/2 Init: src=$106000, dst=$104000, size=($827F<<5 - $4100<<6 + $20)/2 = ($104FE0 - $104000 + $20)/2 = $1000 rtl/SeibuCup/SeibuCup_cop3.sv:1453 MAME size = (((size<<5) - (dst<<6) + 0x20)/2) rtl/SeibuCup/SeibuCup_cop3.sv:1459 MAME: mode 4/5 = fade palette; QUALSIASI ALTRO = copia semplice src->dst (seibucop_dma.ipp:119-123). rtl/SeibuCup/SeibuCup_cop3.sv:1469 MAME seibucop.cpp cop_dma_trigger_w case 0x116 — SEIBUCUP: fill come 0x118 ma SENZA guard dst!=0 e length bytes = (size+1)<<4 (metà). rtl/SeibuCup/SeibuCup_cop3.sv:1471 legionna.cpp:56-61: "The COP-MCU appears to write to the work ram area, otherwise it RESETS in mid-animation of the title screen" → senza questo fill il gioco torna al logo da solo. rtl/SeibuCup/SeibuCup_cop3.sv:1482 Skip if dst != 0 (MAME guard, dma.ipp:135) rtl/SeibuCup/SeibuCup_cop3.sv:1502 MAME cop_cmd_w (seibucop.cpp:1073): cop_status &= 0x7fff (clear bit 15). rtl/SeibuCup/SeibuCup_cop3.sv:1504 MAME: cop_status &= 0x7fff (clear bit 15). rtl/SeibuCup/SeibuCup_cop3.sv:1519 MAME LEGACY_cop_cmd_w: find_trigger_match(data, 0xF800) → slot per GRUPPO f800, poi handler dal microcodice caricato. rtl/SeibuCup/SeibuCup_cop3.sv:1569 MAME lo esegue come una somma, quindi raddoppia il passo invece di annullarlo. rtl/SeibuCup/SeibuCup_cop3.sv:1572 MAME execute_0205: read dword at cop_regs[0]+4+offset4 (ppos) rtl/SeibuCup/SeibuCup_cop3.sv:1593 0x138e / 0x338e — atan(dx/dy) MAME execute_338e. rtl/SeibuCup/SeibuCup_cop3.sv:1595 Parte da r1+4 hi (offset 0x0004), come 3BB0/MAME. rtl/SeibuCup/SeibuCup_cop3.sv:1677 MAME LEGACY_execute_dde5 (seibucop_cmd.ipp): offs = (offset & 3) 4 div = read_word(cop_regs[4] + offs) dir_offset = read_word(cop_regs[4] + offs + 8) if (div == 0) div = 1 write_word(cop_regs[6] + offs + 4, (read_word(cop_reg rtl/SeibuCup/SeibuCup_cop3.sv:1716 MAME: raw_angle = cop_read_word(r0+0x34) = host_read_word(0x34^2 = 0x36); amp = cop_read_word(r0+0x36) = host_read_word(0x36^2 = 0x34). rtl/SeibuCup/SeibuCup_cop3.sv:1733 0xa180 — collision read pos for slot 0 MAME cop_collision_read_pos: cop_read_word(spradr+N) = host_read_word((spradr+N)^2) per host_endian=true. rtl/SeibuCup/SeibuCup_cop3.sv:1754 b000 NON e' un no-op: il dispatcher LEGACY di godzilla (seibucop.cpp:1365) matcha con mask 0xf800, quindi la patch init_godzilla (b100->b000) ESEGUE comunque l'update ma con num_axis=2 (bit8=0 = Z disattivata). rtl/SeibuCup/SeibuCup_cop3.sv:1885 Mode 4 (SEIBUCUP/Denjin, seibucop_dma.ipp:87-117): indice = (val2)[4:0], val 0x0010/0xFFFF = TARGET PURO, NESSUN bypass bit15. rtl/SeibuCup/SeibuCup_cop3.sv:1944 MAME: m_host_space->write_word(dst, pal_val) — dst ASSOLUTO. rtl/SeibuCup/SeibuCup_cop3.sv:1978 MAME (0x118 e 0x116): write_dword(i, v1 \| v2<<16) su spazio BE 68k → word a i = v2, word a i+2 = v1 (alternati). rtl/SeibuCup/SeibuCup_cop3.sv:1991 Macro 0x0205 — linear movement (MAME execute_0205) ppos = read_dword(cop_regs[0]+0x04) vel = read_dword(cop_regs[0]+0x10) npos = ppos + vel write_dword(cop_regs[0]+0x04, npos) delta = (npos>>16) - (ppos>>16) write_word(cop_regs[0]+0x1E, re rtl/SeibuCup/SeibuCup_cop3.sv:2042 MAME cop_read/write_word(cop_regs[0]+0x1e) = host word @ (0x1e^2)=0x1c (host endianness word^2; conferma doc 06 micro-op 'addmem16 0x1C(r0)'). rtl/SeibuCup/SeibuCup_cop3.sv:2061 Macro 0x0905/0x0904 — jump (MAME execute_0904) write_dword(cop_regs[0]+0x10, read_dword(cop_regs[0]+0x10) ± read_dword(cop_regs[0]+0x28)) 0x0905 (bit 0=1) = +, 0x0904 (bit 0=0) = - rtl/SeibuCup/SeibuCup_cop3.sv:2087 MAME execute_0904: bit 0 di data = 1 → add, =0 → sub tmp32_a = vel ± grav. rtl/SeibuCup/SeibuCup_cop3.sv:2121 0x138E/0x338E atan(dx/dy) — MAME execute_338e (cmd.ipp:159) dx = read_dword(r1+4) - read_dword(r0+4) dy = read_dword(r1+8) - read_dword(r0+8) if(!dy){status\|=0x8000; angle=0} else angle=atan(dx/dy)128/pi; dy<0→+0x80 if(data&0x80) write_byt rtl/SeibuCup/SeibuCup_cop3.sv:2169 MAME: angle = atan(dx/dy)128/pi (+0x80 se dy<0). rtl/SeibuCup/SeibuCup_cop3.sv:2171 Cosi' z = atan(dx/dy) e il +0x80 (in WR) copre solo il quadrante, come MAME. rtl/SeibuCup/SeibuCup_cop3.sv:2173 NIENTE prescale: i dword diff sono FIXED-POINT coord<<16 (come il 3BB0 che usa dx32[31:16] e MAME dx>>16), NON interi piccoli. rtl/SeibuCup/SeibuCup_cop3.sv:2225 MAME (int)(...) tronca VERSO ZERO. rtl/SeibuCup/SeibuCup_cop3.sv:2227 BUG TROVATO (validato vs MAME su 29241 casi): il CORDIC SOTTO-CONVERGE di 1 LSB sulle DIAGONALI (es. rtl/SeibuCup/SeibuCup_cop3.sv:2232 Compenso l'epsilon di sotto-convergenza con +1 toward-zero PRIMA del troncamento: bias=1 azzera tutte le 133 divergenze (bias=0) -> 0/29241 vs MAME. rtl/SeibuCup/SeibuCup_cop3.sv:2241 MAME execute_338e (seibucop_cmd.ipp:175-188): la write dell'angolo in RAM (obj+0x34 host, gated da data&0x80) e' FUORI dall'if/else di dy -> avviene SEMPRE, anche a dy==0 (dove cop_angle=0 -> scrive 0^0x80 = 0x80). rtl/SeibuCup/SeibuCup_cop3.sv:2247 Ora calcolo ang_byte in entrambi i rami e scrivo SEMPRE, come MAME. rtl/SeibuCup/SeibuCup_cop3.sv:2254 Scrivere l'angolo anche a dy==0 ("1:1 MAME") REGREDISCE: il martello scivola/moonwalk. rtl/SeibuCup/SeibuCup_cop3.sv:2257 MAME: dy==0 -> cop_angle=0 rtl/SeibuCup/SeibuCup_cop3.sv:2264 Il chip lavora in PIXEL: le tabelle del bootleg mettono distanza e angolo nella STESSA word, indicizzata da (A<<9)\|B con A,B a 9 bit (la documentazione del progetto), e il nostro stesso 3bb0 tronca gia' i delta con dx32[31:16] (come MAME m_ rtl/SeibuCup/SeibuCup_cop3.sv:2275 Stesso difetto in MAME (if (!dx) sui 32 bit), da cui il sintomo identico nei due emulatori. rtl/SeibuCup/SeibuCup_cop3.sv:2283 118e/e18e len 4 -> caricano solo dx/dy: NON scrivono 130e/e30e len 7 -> calcolano l'angolo, non lo scrivono 138e/e38e len 8 -> scrivono Con la regola del bit 7 (quella di MAME) e18e sovrascrive obj+$37 su tutti gli oggetti ogni frame, fra i rtl/SeibuCup/SeibuCup_cop3.sv:2294 SEIBUCUP: write RAW — il ROM carica il microcode 138e variante cupsoc/SDGundam (tabella $498: ...b9a b9a A9A) = MAME LEGACY_execute_130e_cupsoc, SENZA ^0x80 (il ^0x80 e' della variante famiglia $B9A / is_yflip: legionna). rtl/SeibuCup/SeibuCup_cop3.sv:2298 PROVA sim 8 casi: col ^0x80 vettore sincos INVERTITO 180° vs MAME → boss 138e-driven marcia via (stage 4). rtl/SeibuCup/SeibuCup_cop3.sv:2300 ⛔ NON toccare il sincos (lookup diretto = sin MAME): toccarlo inverte i game-written = regressione build 13. rtl/SeibuCup/SeibuCup_cop3.sv:2314 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197) dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (aritmetico) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = sqrt(dxdx + dydy) if(data&0x80) write_word(r0 + (data&0x200?0x3a:0x38 rtl/SeibuCup/SeibuCup_cop3.sv:2381 E' il TODO dichiarato in MAME. rtl/SeibuCup/SeibuCup_cop3.sv:2426 (Il fix MAME-aligned 0x3a:0x38 faceva fuggire i nemici -> MAME invertito vs HW. rtl/SeibuCup/SeibuCup_cop3.sv:2433 MAME: macro completata → cop_status = 7 (gate-poll del gioco). rtl/SeibuCup/SeibuCup_cop3.sv:2499 MAME: if (div == 0) div = 1 rtl/SeibuCup/SeibuCup_cop3.sv:2510 In MAME read_word e' unsigned e dir_offset int16_t: la somma e' int, la divisione int/int -> troncamento VERSO ZERO. rtl/SeibuCup/SeibuCup_cop3.sv:2574 0x8100/0x8900 sin/cos (MAME execute_8100/8900) raw_angle = cop_read_word(cop_regs[0]+0x34) & 0xff amp = (65536>>5) (cop_read_word(cop_regs[0]+0x36) & 0xff) = 2048 * amp_byte if (raw_angle == 0xC0 sin / 0x80 cos): amp = 2 res = int( rtl/SeibuCup/SeibuCup_cop3.sv:2613 MAME special-case: sin && raw==0xC0 OR cos && raw==0x80 → amp = 2 rtl/SeibuCup/SeibuCup_cop3.sv:2659 0xa180/0xa980 — read pos (MAME cop_collision_read_pos) flags_swap = cop_read_word(spradr+2) → host_read_word(spradr+0) pos[0] = cop_read_word(spradr+6) → host_read_word(spradr+4) pos[1] = cop_read_word(spradr+10) → host_read_word( rtl/SeibuCup/SeibuCup_cop3.sv:2666 Però MAME cop_read_word(+2) = host_read_word(+2^2) = host_read_word(+0). rtl/SeibuCup/SeibuCup_cop3.sv:2677 rdata = word @ host+0 = flags (MAME cop_read_word(spradr+2) ^ 2). rtl/SeibuCup/SeibuCup_cop3.sv:2686 rdata = word @ host+4 = pos[0] (Y axis per MAME) rtl/SeibuCup/SeibuCup_cop3.sv:2706 0xb100/0xb900 — update hitbox & compute intersection (1:1 MAME cop_collision_update_hitbox, seibucop.cpp:1003-1065). rtl/SeibuCup/SeibuCup_cop3.sv:2753 2 assi (b000/b800): terza word NON letta, dx/size azzerati (seibucop.cpp:1014-1022) rtl/SeibuCup/SeibuCup_cop3.sv:2792 2 assi: l'asse 2 (Z) NON viene aggiornato (loop MAME i<num_axis) rtl/SeibuCup/SeibuCup_cop3.sv:2811 res init: 3 assi = 111, 2 assi = 011 (seibucop.cpp:1038-39: bit Z gia' 0 = "collide banale" -> hit deciso solo da X/Y) rtl/SeibuCup/SeibuCup_cop3.sv:2835 LEGACY 6880 — carica rel_xy per il prossimo c480 (MAME LEGACY_execute_6980: rel_xy = read_word(spr_src+4+offs)) rtl/SeibuCup/SeibuCup_cop3.sv:2856 LEGACY c480 — single-step sprite DMA (MAME LEGACY_execute_c480): info = read(spr_src+offs) + (param & 0x3f) -> entry+0 abs = read(regs[0]+8/+4) - spr_dma_abs_x/y X(fx/dx/rel_x) -> entry+4 (+ x_clip per l'inc $410) Y(fy/rel_y) -> entry+6 rtl/SeibuCup/SeibuCup_cop3.sv:2969 cupsoc carica il microcodice 3a0 3a6 380 aa0 2a6 => MAME LEGACY_execute_6200 ("this is for cupsoc, different sequence, works on different registers"): regs[1]+0x0c, NON regs[0]+0x34 della variante famiglia. rtl/SeibuCup/SeibuCup_cop3.sv:2977 Write angolo = WORD {0,angle} (MAME host_endian write-word). rtl/SeibuCup/SeibuCup_cop3.sv:2998 wrap a signed 8-bit (MAME: +=/-=256 su int) rtl/SeibuCup/SeibuCup_cop3.sv:3023 MAME cop_write_byte(regs1+$0F): SOLO il byte basso (indirizzo dispari -> be[0], main_top.sv). rtl/SeibuCup/SeibuCup_cop3.sv:3034 5105 / f105 — MOLTIPLICATORE 16.16 (nessun handler in MAME: ricavato da ROM + disasm di cupsoc). rtl/SeibuCup/SeibuCup_cop3.sv:3117 Z-sorting DMA ($1006FE) — MAME dma_zsorting (seibucop_dma.ipp:164) n = data+1 val = read_word(lookup + 2i) (RAW, senza xor) key = (int16)cop_read_word(sort_ram + val) (host (addr)^2, CON SEGNO) param 1 = crescente, 2 = rtl/SeibuCup/SeibuCup_cop3.sv:3160 Bubble sort: swap SOLO se strettamente fuori ordine = stabile come lo std::stable_sort di MAME. rtl/SeibuCup/SeibuCup_main_top.sv:246 VBLANK IRQ4 — MAME legionna.cpp: m_maincpu->set_vblank_int(irq4_line_hold) MAME HOLD_LINE: IRQ asserted on edge, released ONLY at IACK (= when CPU fetches vector). rtl/SeibuCup/SeibuCup_main_top.sv:251 VBLANK IRQ4 — MAME legionna.cpp: m_maincpu->set_vblank_int(irq4_line_hold) MAME HOLD_LINE: IRQ asserted on edge, released ONLY at IACK (= when CPU fetches vector). rtl/SeibuCup/SeibuCup_main_top.sv:513 COP3 cmd 0x14 dma_tilemap_buffer (legionna_v.cpp:86 videowrite_cb_w): offset 0x000..0x3FF → BG (back_data) offset 0x400..0x7FF → FG (fore_data) offset 0x800..0xBFF → MG (mid_data) offset 0xC00..0x13FF → Text (textram, 0x800 word) SRC rtl/SeibuCup/SeibuCup_main_top.sv:537 Il fill scrive le BRAM STAGING (= la host RAM di MAME): il per-frame DMA 0x14/0x15 le propaga al renderer. rtl/SeibuCup/SeibuCup_main_top.sv:551 ── SPLIT STAGING vs RENDERER (semantica MAME 2-stadi, come la palette) ───── MAME godzilla: $101000-$103FFF e' .ram() PURO (handler background_w/… COMMENTATI nel map, legionna.cpp) — le scritture CPU NON toccano i tilemap. rtl/SeibuCup/SeibuCup_main_top.sv:554 I tilemap leggono m_back/fore/mid_data/m_textram = buffer SEPARATI (make_unique_clear, legionna_v.cpp) scritti SOLO da videowrite_cb_w = DMA 0x14. rtl/SeibuCup/SeibuCup_main_top.sv:559 u_XX_ram = STAGING: porta A = CPU (+fill 0x116/0x118, come MAME che filla la host RAM), porta B = sorgente del DMA 0x14. rtl/SeibuCup/SeibuCup_main_top.sv:562 Coppia contenuto/scroll = atomica a livello ISR, come MAME. rtl/SeibuCup/SeibuCup_main_top.sv:634 ── Palette: split STAGING ($104000) vs RENDERER (semantica MAME 2-stadi) ─── MAME: la CPU e il fade (cmd 0x80) scrivono la STAGING RAM a $104000. rtl/SeibuCup/SeibuCup_main_top.sv:674 MAME godzilla: $104000 e' RAM pura (legionna.cpp:262, handler palette commentato) — la palette VISIBILE si aggiorna SOLO via paletteramout_cb = dma_palette_buffer 0x15 (seibucop_dma.ipp:27); il fade DMA scrive lo STAGING (host RAM, dma.ipp: rtl/SeibuCup/SeibuCup_maincpu_map.sv:23 Main CPU memory map SeibuCup / SD Gundam (legionna.cpp cupsoc_map): $000000-$0FFFFF ROM 68K (1MB) → SDRAM via bridge $100000-$1003FF RAM scratch (1KB) → BRAM (Main RAM low) $100400-$1006FF COP3 region rtl/SeibuCup/SeibuCup_maincpu_map.sv:120 ─── Region detect (MAME cupsoc_map, legionna.cpp:324) ───────────────── rtl/SeibuCup/SeibuCup_maincpu_map.sv:147 CUPSOC: spriteram e' META' di grainbow — $107000-$1077FF (2KB = 256 entry) e sopra c'e' la "Ani Dsp(?) Ram" $107800-$107FFF (RAM normale, MAME cupsoc_map). rtl/SeibuCup/SeibuCup_maincpu_map.sv:228 MAME legionna_map: main_r/main_w(offset>>1) con umask16(0x00ff). rtl/SeibuCup/SeibuCup_maincpu_map.sv:232 Vedi MAME seibusound.cpp main_r/main_w. rtl/SeibuCup/SeibuCup_maincpu_map.sv:236 ─── GFX bank ──────────────────────────────────────────────────────────── cupsoc non ha il tile bank register ($100470 assente dalla mappa MAME): gfx_bank resta 0. rtl/SeibuCup/SeibuCup_maincpu_map.sv:347 Replica la latenza-zero-osservabile di MAME (cop_cmd_w sincrono): il gioco legge cop_hit_val_stat/cop_angle ($188/$1b4) nell'istruzione dopo il trigger. rtl/SeibuCup/SeibuCup_palette.sv:25 MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 12816); (legionna.cpp:1212, 12816 = 2048 entry) Address space CPU: 0x104000..0x104FFF (4 KB = 2048 word). rtl/SeibuCup/SeibuCup_palette.sv:35 Espansione 5→8 standard MAME palette_device: {val5, val5[4:2]} (bit replication che riempie i 3 LSB con i 3 MSB del valore 5-bit). rtl/SeibuCup/SeibuCup_palette.sv:85 SeibuCup: xBGR_555 → RGB888 (legionna.cpp:1212) Layout: bit[4:0]=R, bit[9:5]=G, bit[14:10]=B. 5 bit per canale. rtl/SeibuCup/SeibuCup_palette.sv:87 Espansione 5→8 standard MAME palette_device: {val5, val5[4:2]} (replica i 3 MSB nei 3 LSB → range 0..255 con monotonia preservata). rtl/SeibuCup/SeibuCup_seibu_crtc.sv:23 Seibu CRTC fedele a MAME (seibu_crtc.cpp). rtl/SeibuCup/SeibuCup_seibu_crtc.sv:130 MAME mappa: bit0=screen0(BG), bit1=screen2(MG), bit2=screen1(FG), bit3=screen3(Text) (vedi seibu_crtc.cpp commento "screen 0=BG, screen 1=FG, screen 2=MG, screen 3=Text") In SD Gundam dcon.cpp layer_en_w gira la maschera così: ~layer_en bit rtl/SeibuCup/SeibuCup_seibu_crtc.sv:139 Il dispatcher MAME usa "if (BIT(~m_layer_en, n))" per saltare = layer disabilitato quando il bit è 1. rtl/SeibuCup/SeibuCup_seibu_crtc.sv:144 SeibuCup layer ordering (legionna_v.cpp:384-390 screen_update_SEIBUCUP): bit 0 = BG (background) bit 1 = MG (midground) bit 2 = FG (foreground) bit 3 = Text bit 4 = Sprites ATTENZIONE: e' l'OPPOSTO di legionna (screen_update_legionna :342-3 rtl/SeibuCup/SeibuCup_seibu_crtc.sv:165 Scroll-base 0x2C-0x3A (seibu_crtc.cpp:243 layer_scroll_base_w; screen0=BG, screen2=MG, screen1=FG, screen3=Text). rtl/SeibuCup/SeibuCup_seibu_crtc.sv:166 Raw esce qui; le formule (delta vs riferimento godzilla, Y invertita come il set_scrolldy(0x1ef-data) di MAME) stanno nel top. rtl/SeibuCup/SeibuCup_sprite_renderer.sv:25 Formato spriteram quasi identico (entrambi MAME sei021x_sei0220_spr.cpp) — differenze: - Spriteram @ 0x105000-0x105FFF (4KB, 1024 word, 256 entry × 4 word) - w3 bit 15 = tile bank extra bit (denjinmk usa, SeibuCup base = 0) rtl/SeibuCup/SeibuCup_sprite_renderer.sv:30 Format word (legionna_v.cpp:288-312): w0 bit 15 = enable (0=draw, 1=skip — TODO verify SeibuCup) w0 bit 14 = flip_x w0 bit 13 = flip_y (??? rtl/SeibuCup/SeibuCup_sprite_renderer.sv:46 Priority callback legionna_v.cpp:314-317: pri_mask[0] = 0x0000 (sopra tutto) pri_mask[1] = 0xFFF0 pri_mask[2] = 0xFFFC pri_mask[3] = 0xFFFE rtl/SeibuCup/SeibuCup_sprite_renderer.sv:140 CUPSOC: spriteram 2KB → 256 entry (MAME size/2/4 = 2048/2/4 = 256). rtl/SeibuCup/SeibuCup_sprite_renderer.sv:146 Decoded fields — MAME sei0210_device::draw (non-alt format, riga 143): if (BIT(~spriteram[i], 15)) continue; → draw quando w0[15]==1. rtl/SeibuCup/SeibuCup_sprite_renderer.sv:155 cupsoc_pri_cb (legionna_v.cpp:319): pri = (w1[15:14] & 2) \| (ext & 1) → livello = {w1[15], w0[6]}. rtl/SeibuCup/SeibuCup_sprite_renderer.sv:158 CUPSOC: pri_cb STANDARD (legionna_v.cpp pri_cb = mask[pri]) → livello = w1[15:14] pieno, NON il {w1[15],ext} di grainbow (che ha un pri_cb suo). rtl/SeibuCup/SeibuCup_sprite_renderer.sv:170 MAME SEI0211 default m_xoffset/m_yoffset = 0 (sei021x_sei0220_spr.cpp:40-41). rtl/SeibuCup/SeibuCup_sprite_renderer.sv:171 SeibuCup NON chiama set_offset (legionna.cpp:1214) → offset 0,0. rtl/SeibuCup/SeibuCup_sprite_renderer.sv:203 Tile code finale Y-MAJOR (MAME draw_internal: ax=outer, ay=inner, code++): sub_index = axsizey + ay → cur_tile = code + eff_tile_xsp_h + eff_tile_y cupsoc: NESSUN gfxbank_cb (legionna.cpp:1449, solo pri_cb) — code puro 14 bit. rtl/SeibuCup/SeibuCup_sprite_renderer.sv:573 MAME gfx_legionna_spr: color base = 6416 = 0x400 (64 colorset × 16 pen). rtl/SeibuCup/SeibuCup_text_renderer.sv:25 Specifiche da MAME (legionna.cpp:1117-1126, 1167): rtl/SeibuCup/SeibuCup_text_renderer.sv:47 Char ROM in MAME: "char" region 64KB = ROM_COPY user1[0x10000..0x1FFFF]. rtl/SeibuCup/SeibuCup_text_renderer.sv:140 MAME `legionna_v.cpp:214`: text tilemap = 64×32 (8x8 tiles, TILEMAP_SCAN_ROWS). rtl/SeibuCup/SeibuCup_text_renderer.sv:186 --- Stage 3: pen decode (charlayout planes packed in nibbles) --- Per col c (0..3 dentro la half-tile), bit position = 3 - c. pen[0] = word[bit_pos + 0] (plane 0) pen[1] = word[bit_pos + 4] (plane 1) pen[2] = word[bit_pos + 8] (plane rtl/SeibuCup/SeibuCup_text_renderer.sv:192 MAME readbit usa MSB-first: bit_offs N → byte[N/8] bit (7-N%8). rtl/SeibuCup/SeibuCup_text_renderer.sv:193 In Verilog word concat (lo=byte0[7:0], hi=byte1[7:0]) → MAME pos N = word[(7-N%8) + (N>=8?8:0)]. rtl/SeibuCup/SeibuCup_text_renderer.sv:210 MAME GFXDECODE char: color base = 4816 = 0x300 (16 colorset × 16 pen). rtl/SeibuCup/SeibuCup_tile_layer.sv:25 Differenze fra layer (da MAME dcon.cpp): rtl/SeibuCup/SeibuCup_tile_layer.sv:58 BB FG hardcoded +0x1000 (MAME bloodbro fg_tile_info) rtl/SeibuCup/SeibuCup_tile_layer.sv:221 Tile index con eventuale gfx_bank (MG ha bit 12 = 13-bit totali, BG/FG = 12 bit) + TILE_CODE_OFS hardcoded (BB FG aggiunge 0x1000 secondo MAME bloodbro fg_tile_info). rtl/SeibuCup/SeibuCup_video_timing.sv:35 Active area da MAME (sdgndmps_map): visarea 0..408-1, 28..308-1 quindi 320×224, V offset = 16 (top blank). rtl/SeibuCup/SeibuCup_video_timing.sv:60 ── Pixel clock enable: 96 MHz / 14 = 6.857 MHz ───────────────────────── SeibuCup reale (legionna.cpp:1318 set_raw): pclk 14.318180/2 = 7.15909 MHz. rtl/SeibuCup/SeibuCup_video_timing.sv:78 ── Constants timing ───────────────────────────────────────────────────── SeibuCup REALE (legionna.cpp:1318): set_raw(14318180/2, 455, 0, 320, 258, 0, 224) = 320x224, HTotal 455 @7.159MHz = 15.734 kHz, VTotal 258 → 60.985 Hz. rtl/SeibuCup/SeibuCup_video_timing.sv:96 CUPSOC: 240 righe visibili (MAME visarea 8..247), 60 Hz. rtl/SeibuCup/SeibuCup_video_timing.sv:103 Raster unico 262: 6.857e6/(436262) = 60.03 Hz = i 60 Hz di MAME. rtl/SeibuCup/sdram_bridge.sv:308 --- FG address descramble (legionna.cpp:1129 descramble_legionnaire_gfx) --- MAME applica un bitswap<24> agli indirizzi della ROM "fore" durante init: src_descrambled[i] = src_raw[bitswap<24>(i, ... rtl/SeibuCup/sdram_bridge.sv:355 bitswap MAME del byte offset README.md:6 Seibu Cup Soccer runs on the Seibu `legionna.cpp` hardware family* — an M68000 board with a Seibu CRTC, the SEI252 sprite chip, and the SEI300 / COP3 copro README.md:8 It shares that board with Legionnaire, Heated Barrel, Denjin Makai, Godzilla and SD Gundam Sangokushi Rainbow, and it is the only one of them that MAME still README.md:13 This core reimplements the hardware in SystemVerilog from the program ROM, from MAME references (`legionna.cpp`, `legionna_v.cpp`, `seibu_crtc.cpp`, `seibucop.c README.md:34 The COP: how a game MAME calls "unemulated protection" was solved README.md:46 MAME marks Seibu Cup Soccer as unemulated protection, and the code that is there is partly guesswork — several of its comments turned out to be wrong, not m README.md:51 ROM > behaviour in game > MAME. README.md:54 MAME is a hint, and a good one, but never the last word. README.md:60 MAME dispatches many of these commands by game name. README.md:66 Command `6200` exists twice in MAME (`execute_6200` and `LEGACY_execute_6200`) with different registers and offsets. README.md:76 Who writes the resulting angle is decided by the length field of the trigger, not by bit 7 as MAME has it: commands of length 8 write it, those of lengt README.md:87 A probe on the real thing. A LUA tap on the COP window running under MAME showed which commands the game actually issues during a match. README.md:94 That probe had itself been lying for a while: MAME's `install_read_tap` returns an object whose destructor removes the tap, so a script that does not keep the r README.md:96 Every LUA measurement taken before that was found in the MAME source is untrustworthy — which explained a long run of inconsistent results. README.md:124 And it answered a question MAME had given up on. README.md:124 `seibucop.cpp` says "atan maths are nowhere to be found from the roms". README.md:133 — which also settled that the division truncates rather than rounding (MAME's comment says otherwise, and is right only 52% of the time), and that the ampli README.md:138 Things MAME says that are not true README.md:149 The correct version of command `3bb0` was already in MAME, but buried inside an `#ifdef UNUSED_COMMANDS` that is never defined. README.md:236 The sprite priority masks are inherited from MAME, where two of the four values carry the authors' own question marks (`legionna_v.cpp` gives cupsoc `0xfff0 Says it matches, follows or was checked against MAME — 6 SeibuCup.sv:224 -1 = base famiglia (match MAME su HW) rtl/SeibuCup/SeibuCup_cop3.sv:1514 LEGACY sprite-DMA (match a maschera, MAME find_trigger_match): c480 mask $FF00 -> qualunque c4xx; 6880 mask $FFF3. rtl/SeibuCup/SeibuCup_cop3.sv:2628 res = prod >> 4 (= /16 per matchare formula MAME 2048/32768 = 1/16) rtl/SeibuCup/SeibuCup_cop3.sv:3141 Verificato in gioco su MAME il 2026-07-29. rtl/SeibuCup/SeibuCup_sprite_renderer.sv:172 +1 pixel a destra: offset verificato con pixel hunting su MAME (rmonic79). rtl/SeibuCup/SeibuCup_sprite_renderer.sv:368 Scan INVERSO 511→0 (verificato su HW: ordine sprite-su-sprite opposto al loop MAME 0→511). Says it was translated, ported or taken from MAME — 2 rtl/SeibuCup/SeibuCup_cop3.sv:2322 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197): 1:1 dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (signed) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = floor(sqrt(dxdx + dydy)) if(data&0x80) write_word(r0+(data&0x200?0x3 rtl/SeibuCup/SeibuCup_cop3.sv:2442 0x42C2/0x4AA0 divide — MAME execute_42c2/4aa0 (cmd.ipp:219/247): 1:1 DIVIDEND = cop_dist << (5 - cop_scale) (cop_scale 0..3 → shift 5..2) 42c2: div=cop_read_word(r0+0x36)→host 0x34; if(!div){status\|=0x8000; write 0 a host 0x3a} else write Keeps a MAME approximation — 1 rtl/SeibuCup/SeibuCup_cop3.sv:223 MAME usa total_cycles%256 (surrogato dell'RNG hw ignoto): l'LFSR e' un surrogato equivalente ma robusto alle letture regolari. Shares text with the MAME driver without saying so — 9 SeibuCup.sv:881 screen.set_visarea(08, 408-1, 18, 318-1) = [0..319] x [8..247] — shares text with seibu/legionna.cpp:1317 SeibuCup.sv:907 HAS_TRANSP=1 perché m_background_layer->set_transparent_pen(15) in — shares text with seibu/legionna_v.cpp:216 SeibuCup.sv:930 get_mid_tile_info_share_bgrom (legionna_v.cpp:158): MG share BG ROM, — shares text with seibu/legionna.h:80 rtl/SeibuCup/SeibuCup_palette.sv:23 Palette RAM Seibu SeibuCup (xBGR_555, 2048 entries). MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 128*16); (legionna.cpp — shares text with seibu/legionna.cpp:1212 rtl/SeibuCup/SeibuCup_sprite_renderer.sv:147 if (BIT(~spriteram[i], 15)) continue; → draw quando w0[15]==1. — shares text with seibu/sei021x_sei0220_spr.cpp:128 rtl/SeibuCup/SeibuCup_text_renderer.sv:23 Text layer renderer Seibu SeibuCup (8x8, 4bpp, 64x32). Specifiche da MAME (legionna.cpp:1117-1126, 1167): // charlayout 8x8, RGN_FRAC(1,1), 4 — shares text with seibu/legionna.cpp rtl/SeibuCup/SeibuCup_video_timing.sv:23 Video timing single-screen Seibu D-Con. SD Gundam Psycho Salamander gira su Seibu D-Con (PB91008), stessa famiglia di Blood Bros (1990). PCB measuremen — shares text with seibu/legionna.cpp rtl/SeibuCup/SeibuCup_video_timing.sv:79 SeibuCup REALE (legionna.cpp:1318): set_raw(14318180/2, 455, 0, — shares text with seibu/legionna.cpp:1318 rtl/SeibuCup/sdram_bridge.sv:310 src_descrambled[i] = src_raw[bitswap<24>(i, ... 6,5,15,14,13,12, 11,10,9,8, 7,4, 3..0)] — shares text with seibu/legionna.cpp:1141
Shuuz# Shuuz MiSTer-devel/Arcade-Shuuz_MiSTer @ 4fb3ba9e MAME compared: atari/shuuz.cpp + 4 related file(s) Read: 36 HDL files, 4,230 lines (Quartus project)	MiSTer official	Both	low	43%
Statements: 24 toward hardware, 14 toward MAME, 9 not counted Cites hardware documentation that MAME's driver does not — 24 rtl/io/shuuz_inputs.sv:4 Reads go through one 74LS257 (28A), selected by address line 1: 105000: bit 11 /VIDBL, bit 0 left coin, bit 1 right coin 105002: bit 11 self-test switch, bit 0 left button, bit 1 right button Its fourth section carries two JAMMA pins the Sh rtl/io/shuuz_inputs.sv:11 Writes clock a 74LS174 (15A) from data lines 13-8 at the end of the write: 13 motor enable, 12 VCR power, 11 and 10 coin counters, 9 /AUDRES, 8 /PCMRES (0 holds the sound chip in reset). rtl/main/shuuz_cpu.sv:1 SPDX-License-Identifier: GPL-3.0-or-later 68000 at 30C: fx68k with its two clock-phase enables. rtl/main/shuuz_dtack.sv:1 SPDX-License-Identifier: GPL-3.0-or-later /DTACK: the 74LS163A wait counter at 50B. rtl/main/shuuz_eeprom_28c16.sv:1 SPDX-License-Identifier: GPL-3.0-or-later 28C16 EEPROM at 38F (2K x 8) and the flop at 10B that locks it. rtl/main/shuuz_eeprom_28c16.sv:137 ---- the unlock flop at 10B -------------------------------------------- /CLR = /SYSRES; /PRE (unlock) is a level and wins over its own /WL edge. rtl/main/shuuz_main.sv:101 ---- address decode: the GAL at 55C and the 74LS138 at 55B ---- rtl/main/shuuz_nvram_io.sv:1 SPDX-License-Identifier: GPL-3.0-or-later MiSTer load and save of the 28C16 EEPROM at 38F. rtl/main/shuuz_watchdog.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Power-on reset and watchdog: the 74LS197 counter at 30B. rtl/shuuz_clocks.sv:6 The board divides the crystal with a free-running 74LS163 (62D): QB is 3.58 MHz, QC 1.79 MHz and QD 894.9 kHz, the clock of the MSM6295 and the LETA. rtl/video/shuuz_cram.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Colour RAM at 3E0000 (the RAM at 54K; 1024 words are used): one copy read by the pixel scan and one by the processor, both written together. rtl/video/shuuz_lb.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Motion object line buffers (LB 137536-001 at 85S and its RAM): two banks, one written by the MOB for the next line while the other is displayed and erased behind the beam. rtl/video/shuuz_mob.sv:1 SPDX-License-Identifier: GPL-3.0-or-later MOB 137593-001 at 70S: for every line, read the first link from the SLIP table, walk the linked list of motion objects in video RAM and draw the stamp rows that cross the line into the line buffer. rtl/video/shuuz_vad_regs.sv:1 SPDX-License-Identifier: GPL-3.0-or-later VAD 137656-001 at 50S (modelled as the -002 of the sister boards): the 32-word register file, the end-of-frame reload and the parameter-word decoder. rtl/video/shuuz_vad_sync.sv:1 SPDX-License-Identifier: GPL-3.0-or-later VAD 137656-001 at 50S (modelled as the -002 of the sister boards): beam counters, sync, blanking and the scanline interrupt, programmed by registers 01-05. rtl/video/shuuz_vram.sv:1 SPDX-License-Identifier: GPL-3.0-or-later The 64 KB video RAM block at 3F0000 (RAMs at 41N and 70N) and the VAD's access schedule. README.md:9 It was built from the schematics in Atari's manual (TM-358) and the board's dumped GALs. README.md:103 These parts follow the schematics and the GAL fuse maps: README.md:106 Address decode. The GAL at 55C (136083-1050) and the 74LS138 at 55B, with the GAL's equations taken from its fuse map. README.md:109 Wait states. The 74LS163A counter at 50B ends every bus cycle: no wait state for the program ROM, one for the EEPROM, two for the LETA and the MSM6295. README.md:114 Watchdog. The 74LS197 at 30B holds the 68000 in reset for eight frames after power-on, and resets the board if the program stops writing to it for eight fra README.md:117 EEPROM. The 28C16 with the flop at 10B that locks it. README.md:174 \| Audio filter \| Response compared with the three stages computed from the schematic \| Within 0.05 dB up to 4 kHz \| README.md:221 Comments in the RTL name board parts by their location on the PCB (for example "the 74LS163A at 50B") and signals by their schematic names, so they can be check Cites hardware references or measurements that MAME's driver also gives — 9 rtl/gal/shuuz_gal_1050.sv:1 SPDX-License-Identifier: GPL-3.0-or-later GAL16V8 136083-1050 at 55C: main address decoder. — also in MAME: 136083-1050 atari/shuuz.cpp:466, 55C atari/shuuz.cpp:466 rtl/gal/shuuz_gal_1051.sv:1 SPDX-License-Identifier: GPL-3.0-or-later GAL16V8 136083-1051 at 45E. — also in MAME: 136083-1051 atari/shuuz.cpp:467, 45E atari/shuuz.cpp:467 rtl/gal/shuuz_gal_1053.sv:1 SPDX-License-Identifier: GPL-3.0-or-later GAL16V8 136083-1053 at 85N: motion object against playfield. — also in MAME: 136083-1053 atari/shuuz.cpp:469, 85N atari/shuuz.cpp:469 rtl/main/shuuz_main.sv:129 ---- the GAL at 45E: strobes for the video section, one clock late ---- — also in MAME: 45E atari/shuuz.cpp:467 rtl/mem/shuuz_prog_rom.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Program ROM, 256 KB (two 27C010 at 23P and 13P), held in block RAM so that every read takes the same time, as it does on the board. — also in MAME: 23P atari/shuuz.cpp:442, 13P atari/shuuz.cpp:443 rtl/shuuz_core.sv:183 Its sample ROMs 75B and 65B are one 256 KB block, 75B first. — also in MAME: 75B atari/shuuz.cpp:462, 65B atari/shuuz.cpp:463, 75B atari/shuuz.cpp:462 rtl/video/shuuz_mixer.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Colour RAM address from the playfield pixel and the line-buffer pixel, decided by the priority GAL at 85N (136083-1053). — also in MAME: 85N atari/shuuz.cpp:469, 136083-1053 atari/shuuz.cpp:469 README.md:119 Video bus strobes. The GAL at 45E (136083-1051) passes the bus strobes to the video section one clock late. — also in MAME: 45E atari/shuuz.cpp:467, 136083-1051 atari/shuuz.cpp:467 README.md:124 Priority and shadows. The GAL at 85N (136083-1053) decides whether a motion object pixel or the playfield shows. — also in MAME: 85N atari/shuuz.cpp:469, 136083-1053 atari/shuuz.cpp:469 Cites MAME source — 13 rtl/video/shuuz_mixer.sv:15 The wiring here follows the signal names MAME's source gives the equations. rtl/video/shuuz_vad_sync.sv:9 Register fields (the layout MAME uses; the VAD sheet was never published): 01 vsync start (11-3), vsync end (2-0) 02 last line (15-9), vblank start (8-0) 03 scanline interrupt line (8-0) 04 hsync end / 2 (15-10), hsync start (9-0) 05 h README.md:10 MAME 0.289 was used as a cross-check, and as the only source for the video chips, whose schematics were never published. README.md:112 MAME has no wait states, so the game program runs slightly slower here, as on the board. README.md:133 They cut off above about 900 Hz, so the core sounds duller than MAME, which plays the chip unfiltered. README.md:139 What follows MAME instead README.md:142 The VAD (timing, scroll registers, end-of-frame reload), the MOB (motion object list walk) and the line buffer therefore follow MAME's `atarivad` and `atarimo` README.md:153 MAME draws whole frames and shows it on the next frame. README.md:171 \| Main bus \| Boot of both program versions compared with MAME, bus access by bus access (polling loops merged) \| The same 46,911 accesses in the same order, thr README.md:172 \| Video \| 46 frames of each version (attract mode, a game, self-test) in which the program does not change the picture mid-frame, compared with MAME pixel by pi README.md:173 \| MSM6295 \| Compared with MAME's own MSM6295 device, built from MAME's source and driven by the real sample ROMs \| 17,811 samples equal \| README.md:175 \| Whole core \| Both versions run for 2,900 frames: attract mode, a coin, player selection and pitches with the trackball, then the game's own ROM and video RAM README.md:244 The MAME team: `shuuz.cpp` (Aaron Giles), `atarivad`, `atarimo` and `okim6295`, the reference for everything the schematics do not settle. Says it matches, follows or was checked against MAME — 1 rtl/video/shuuz_vad_regs.sv:8 The VAD sheet was never published; this follows MAME's atarivad and what the game program does.
SilverLand# River Patrol MiSTer-devel/Arcade-SilverLand_MiSTer @ 3ea85804 MAME compared: nichibutsu/cclimber.cpp Read: 15 HDL files, 6,196 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	10%
Statements: 1 toward MAME Cites MAME source — 1 rtl/ym_2149_linmix.vhd:44 Clues from MAME sound driver and Kazuhiro TSUJIKAWA
SkullXBones# Skull & Crossbones MiSTer-devel/Arcade-SkullXBones_MiSTer @ 73fdc240 MAME compared: atari/skullxbo.cpp + 8 related file(s) Read: 34 HDL files, 7,927 lines (Quartus project)	MiSTer official	Both	high	82%
Statements: 93 toward hardware, 70 toward MAME, 3 not counted Cites hardware documentation that MAME's driver does not — 86 rtl/main/skullxbo_addr_decode.sv:5 Schematic sheet 2: LS32 170E, LS139 140A (both halves), LS138 130A, LS139 170J, the LS00 120C MOBMSB latch and the gates that make /ROM, /SLAPSTIK and /VIDRAM; sheet 3: the LS139 220F program-ROM bank select. rtl/main/skullxbo_addr_decode.sv:67 LS139 220F-1 (sheet 3; G = /ROM, A = A17, B = A18, unbuffered) rtl/main/skullxbo_addr_decode.sv:136 ---- program ROM (sheet 3) ---- rtl/main/skullxbo_cpu.sv:3 Skull & Crossbones main CPU: fx68k (a cycle-exact 68000) wired as sheet 2 draws the 68000 at 245C. rtl/main/skullxbo_cpu.sv:16 SOS-2 pin 12 (/7M) -> 110F F04 -> `7M` (PAL 110E, PFHS, SOS-1 195N) SOS-2 pin 13 ( 7M) -> 110F F04 -> `/7M` (68000 CLK, LS163A 230F) rtl/main/skullxbo_cpu.sv:29 `ce_7m_cpu` is output because the LS163A 230F in skullxbo_dtack is clocked by the same /7M edge. rtl/main/skullxbo_cpu.sv:32 Pins as sheet 2 wires them: CLK = /7M HALT, RESET = tied together to the /RESET net AS -> 200E LS14 -> `AS` (active high on the board) UDS, LDS -> 170E LS32 (/WH, /WL) rtl/main/skullxbo_cpu.sv:76 the /7M rising tick, for skullxbo_dtack's LS163A 230F rtl/main/skullxbo_dtack.sv:3 Skull & Crossbones /DTACK generation (schematic sheet 2): the LS163A wait counter at 230F, the LS11 90E clear gate, the LS74 130C-B /WAITHBL flop, the LS74 110C-B VCYCDONE flop and the LS27 210F that combines the three DTACK sources. rtl/main/skullxbo_dtack.sv:14 The parts, as sheet 2 wires them: LS11 90E : /VIDRAM, /WAITHBL, AS -> 230F /CLR LS163A 230F : CK = /7M ; ENP = /DTACK ; ENT = /VPA ; /LOAD = QD ; D,C,B,A = 1, 1, /EEROM, 1 ; RCO -> LS27 210F LS08 200F : /VPA & VCYCDONE -> LS27 210F LS7 rtl/main/skullxbo_dtack.sv:69 /CLR dominates the clock on a 74LS74. rtl/main/skullxbo_dtack.sv:94 ---------------- LS163A 230F ----------------------------------------- rtl/main/skullxbo_dtack.sv:101 LS11 90E pin 6 -> /CLR (SYNCHRONOUS on an LS163A) rtl/main/skullxbo_eeprom_28c16.sv:3 28C16-45 (2 K x 8) EEPROM at 170A, plus the LS74 30H-A unlock flop and the LS08 60E gate that drives its /OE. rtl/main/skullxbo_eeprom_28c16.sv:4 Schematic sheet 3. rtl/main/skullxbo_eeprom_28c16.sv:12 Wiring: A10..A0 = BA11..BA1 D7..D0 = BD7:0 (the odd / low byte lane) /CE = /EEROM (0xFF6000-0xFF7FFF) /OE = LS08 60E /WE = /WL (every low-lane 68000 write) rtl/main/skullxbo_eeprom_28c16.sv:22 Unlock / lock: LS74 30H-A : D = GND, CK = /WL (rising = end of any low-lane write), /PRE = /UNLOCK (a write to FF0C00), /CLR = /RESET LS08 60E : /OE = Q AND /RESET rtl/main/skullxbo_eeprom_28c16.sv:74 LS08 60E pin 11 -> 170A pin 20 rtl/main/skullxbo_eeprom_28c16.sv:135 LS08 60E: /OE = Q AND /RESET. rtl/main/skullxbo_eeprom_28c16.sv:144 ---- LS74 30H-A ------------------------------------------------------ /CLR = /RESET is asynchronous on the part; /UNLOCK (/PRE) is level sensitive and beats the /WL edge of its own cycle. rtl/main/skullxbo_inputs.sv:3 Skull & Crossbones controls and status port: the two LS257 muxes 80B/100C (sheet 3) and the F244 150C status nibble (sheet 4). rtl/main/skullxbo_inputs.sv:72 LS257 80B/100C -> BD15:8, ACTIVE LOW rtl/main/skullxbo_irq.sv:3 Skull & Crossbones interrupts (schematic sheet 2): the LS11 90E band decoder, the LS10 90C gates, the LS74 130C-A scanline latch, the LS74 110C-A VBLANK latch and the LS00 120C / LS10 90C IPL encoder. rtl/main/skullxbo_irq.sv:14 LS11 90E : /1V & 2V & 4V (high when V mod 8 == 6) rtl/main/skullxbo_irq.sv:15 LS10 90C : NAND(90E, ANIRQ, /VBLANK) -> 130C-A D rtl/main/skullxbo_irq.sv:16 LS74 130C-A : CK = HBLANK (board net), /PRE = /IRQACK, /Q = IRQ1 pending LS74 110C-A : D = GND, CK = VBLANK (SOS-2 pin), /PRE = /VBLACK, /Q = IRQ2 pending /IPL2 = SCOM 120E FULL, direct /IPL1 = NAND(/IPL2, IRQ2 pending) ( rtl/main/skullxbo_irq.sv:59 /1V -- LS11 90E pin 11 rtl/main/skullxbo_irq.sv:82 ---------------- LS11 90E + LS10 90C (the D input) ------------------- rtl/main/skullxbo_irq.sv:84 LS10 90C pin 6 (a 3-input NAND) rtl/main/skullxbo_irq.sv:112 ---------------- LS00 120C + LS10 90C : the IPL encoder -------------- rtl/main/skullxbo_irq.sv:115 LS10 90C pin 12 rtl/main/skullxbo_main.sv:80 LS191 1VS..256VS rtl/main/skullxbo_main.sv:135 BA11:1 (PAL 10F inverts BA11 into the rtl/main/skullxbo_main.sv:138 BD15:0 (LS245 50B/50C are a WORD port) rtl/main/skullxbo_main.sv:140 LS74 70C-B Q -- the one-pixel steal rtl/main/skullxbo_main.sv:149 LS125 50H pin 3 = /4H, the link bit clock rtl/main/skullxbo_main.sv:371 the LS163A wait sequencer, VCYCDONE and the /WAITHBL stall rtl/main/skullxbo_main.sv:568 LS74 70C-A (an S-R latch, clock tied off) : /PRE = AS , /CLR = /CRAMD F32 60C pin 11 = OR( 70C-A /Q , /CRAM ) LS74 70C-B : D = 60C pin 11 , CP = /14MA , /PRE = AS , Q = /CRAMD => /CRAMD is a ONE-14MA-cycle low pulse, once per CPU colour-RAM rtl/main/skullxbo_main.sv:572 Then, on sheet 9, F398 40J delays it one 14MB into /CRAMOO, and /CRWR = OR( OR(/CRAMOO, /W) , /14MA ) -- a half-cycle write pulse VIDCLK = OR( CRAMOO , /14MA ) -- HELD HIGH for that cycle The CPU steals exactly one pixel: rtl/main/skullxbo_main.sv:601 LS245 50B/50C: a 16-bit WORD port rtl/main/skullxbo_main.sv:633 LS125 50H pin 3 = /4H rtl/main/skullxbo_main.sv:642 LS245 50B/50C, a WORD rtl/main/skullxbo_watchdog.sv:3 Skull & Crossbones power-on reset and watchdog (schematic sheet 1): the Q1 / R62 / C55 power-on node into 200E LS14, the LS90 70F divider, the LS00 10D reset gate with jumper JP1, and Q3 driving the /RESET net. rtl/main/skullxbo_watchdog.sv:23 LS90 70F, a BCD divide-by-ten: CKA = /VBLANK, QA -> CKB R0 (reset to 0) = LS00 10D output = NAND(/WDOG, JP1 node) R9 (set to 9) = the POR node, wins over R0 QD -> Q3 -> /RESET JP1 open (as shipped): a /WDOG write resets the count. rtl/main/skullxbo_watchdog.sv:82 ---------------- LS00 10D + JP1 -------------------------------------- R0 = NAND( /WDOG , JP1node ) with JP1node = ~jp1 rtl/main/skullxbo_watchdog.sv:87 ---------------- LS90 70F -------------------------------------------- R9 (set to nine) dominates R0 on a 74LS90; both are LEVEL sensitive and asynchronous. rtl/mem/skullxbo_prog_rom.sv:3 Skull & Crossbones 68000 program ROM: the eight 27512 sockets of sheet 3, served from SDRAM through a small direct-mapped cache with 4-word lines and a next-line prefetch. rtl/mem/skullxbo_vram.sv:3 Skull & Crossbones video RAM: the two 16-bit memories (208H/235H and 221H/250H), the seven F253/LS253 address multiplexers, the F174 address latches, PAL16R8 110E (136072-2143, implemented directly from its fuse dump), the byte-lane write p rtl/mem/skullxbo_vram.sv:135 LS191 1VS..256VS; only VS[8:3] are wired rtl/mem/skullxbo_vram.sv:197 PAL16R8 110E (136072-2143): the eight registered equations rtl/mem/skullxbo_vram.sv:199 From the 136072-2143 fuse dump, decoded with MAME's jedutil. rtl/mem/skullxbo_vram.sv:436 A 74LS373 is TRANSPARENT while G is high and freezes on its falling edge, so the CPU gets a stable word after its single slot even though VD immediately reverts to the video fetches. rtl/skullxbo_core.sv:220 ---- debug nets -------------------------------------------------------- `main_reset_n` is the LS90 70F /RESET net; `main_slip_n` / `main_slipup` / `main_pal_e` are PAL 110E's registered outputs; `main_cramd_n` / `main_cramoo_n` are the one rtl/video/skullxbo_alpha.sv:3 Skull & Crossbones alphanumerics (schematic sheet 5): LS374 190K/220K, the 27256 character ROM at 250K, LS194A 230K/230L and LS174 190F (ANPAL3:0, ANBO, ANIRQ). rtl/video/skullxbo_alpha.sv:26 Pipeline (why a cell is displayed one group late): mux slot (8k+3, b) -> the alpha word LS374 190K/220K clocked by 4HD14M, rising into (8k+4, b) LS194A S1 = NOR(1H,2H): parallel load once every four counts, shift th rtl/video/skullxbo_alpha.sv:40 The LS194A clock 7MD/14M rises a quarter count after the count boundary; the pens are modelled on the boundary, which is the same thing at the resolution of the doubled alpha pixels. rtl/video/skullxbo_alpha.sv:118 LS194A 230K / 230L rtl/video/skullxbo_cram.sv:3 Skull & Crossbones colour RAM 40E / 50E, the /CRAMD pixel steal and the HC273 40B/40C output registers (schematic sheet 10). rtl/video/skullxbo_cram.sv:9 The RAM: two 137534-001 2 K x 8 parts = 2048 x 16 at FF2000-FF2FFE, a 16-bit word port for the CPU (LS245 50B/50C), /CS = /OE = GND, /WE = /CRWR. rtl/video/skullxbo_cram.sv:11 The video side addresses it with CRAMA10:1 from the F153 muxes plus PAL 10F pin 14 as A10. rtl/video/skullxbo_cram.sv:17 The pixel steal: LS74 70C makes /CRAMD a one-14MA-cycle low pulse per CPU colour-RAM access; F398 40J delays it one 14MB into /CRAMOO; and VIDCLK = OR(CRAMOO, /14MA) is held high for that cycle, freezing the HC273 outputs. rtl/video/skullxbo_cram.sv:58 /CRAMD, back into PAL 10F pin 1 rtl/video/skullxbo_dac.sv:3 Skull & Crossbones: the R-2R DACs RN1/RN2/RN3 and the analogue stage (schematic sheet 10), reduced to 8 bits per channel for MiSTer. rtl/video/skullxbo_hstrobes.sv:3 Skull & Crossbones on-board horizontal strobes (schematic 046903-01 sheet 1: LS74 80E / 80F / 80C, LS02 70E, LS27 210F, LS08 200F, LS11 90E, LS10 90C, LS04 100E/40K, F174 160H). rtl/video/skullxbo_hstrobes.sv:16 The HBLANK chain: LS74 80E-A : D = HBLANK(sos2), /CLR = HBLANK(sos2), CK = 16H Q = HBDLY LS02 70E-4 : NOR(/1H2H, /4H) = 1H & 2H & 4H (h == 7) LS74 80F-A : D = 1, /CLR = HBDLY, CK = (h == 7) LS74 80F-B : D = 80F-A Q, CK = /4HD/14M, rtl/video/skullxbo_hstrobes.sv:84 7MD/14M rising: LS194A 230K/230L clock rtl/video/skullxbo_lb.sv:3 Skull & Crossbones motion-object line buffers (schematic sheet 9: 80J/70J and 80K/70K, the F163 counters 90J/100J/110J and 90K/100K/110K, the LS244/LS125 write drivers, F398 50J/40J + F174 60J). rtl/video/skullxbo_mo_fetch.sv:3 Skull & Crossbones motion-object stamp fetch and pixel shifters (schematic sheets 6-8: the five-plane 27512 banks, the LS373 60N/70N/50N/80N 32-bit row latch, the LS157 110M/100M plane-4 flip, and SOS-1 20N and 25L). rtl/video/skullxbo_mo_fetch.sv:74 The transparent pen is 0 (MAME transpen 0, and PAL 10F's (LBPIX == 0) test), so this model carries the true pen and the line buffer suppresses pen 0. rtl/video/skullxbo_mob.sv:3 Skull & Crossbones: the Atari MOB (137593-001) motion-object engine at 130K, schematic sheet 6. rtl/video/skullxbo_pfhs.sv:3 Skull & Crossbones: the Atari PFHS (137419-104) at 195M, schematic sheet 5. rtl/video/skullxbo_prio.sv:3 Skull & Crossbones: PAL16L8 10F (136072-1142, "PRI") and the F153 colour-RAM address multiplexers 10E / 20D / 30D / 30E / 20E (sheet 10). rtl/video/skullxbo_prio.sv:9 The PAL equations are the 136072-1142 fuse dump, decoded with MAME's `jedutil -view <jed> GAL16V8`: rtl/video/skullxbo_sos1.sv:3 One parameterised model, used three times: 195N (playfield, sheet 5), 20N (motion-object planes 3..0, sheet 8) and 25L (plane 4, sheet 8). rtl/video/skullxbo_sos2_sync.sv:3 Skull & Crossbones SOS-2 sync generator (Atari custom 137550-001 at 95F, schematic 046903-01 sheet 1). rtl/video/skullxbo_sos2_sync.sv:13 The board re-times the SOS-2's HBLANK and /HSYNC (LS74 80E / 80F / 80C) and gates RSTLB and LINKRES before anything uses them; those board nets are made in skullxbo_hstrobes.sv. rtl/video/skullxbo_video.sv:13 Video-RAM port: video -> memory (address sources into the F253/LS253 muxes, sheet 4) rtl/video/skullxbo_video.sv:412 The pen buses are combined by PAL 10F and the F153 muxes combinationally, registered by F174 50F/40F and again by the HC273s — two 14M stages. rtl/video/skullxbo_vscroll.sv:3 Skull & Crossbones playfield vertical-scroll counters (LS191 150H / 130H / 140H, schematic sheet 6; the /LOAD term from 170H F02, 60H LS32 and 70H F27). rtl/video/skullxbo_vscroll.sv:42 1 = 140H /CTEN is the VBLANK net (sheet 6, pin 4), so the chain holds through vertical blanking. README.md:128 \| Video RAM \| two 16-bit RAMs (playfield; alphanumerics + sprites + work RAM), CPU access arbitrated by PAL16R8 110E (`136072-2143`), implemented from its f README.md:133 \| Priority \| PAL16L8 10F (`136072-1142`), implemented from its fuse dump \| README.md:135 \| Sound board \| JSA Audio II: 6502 (T65) at 1.79 MHz, banked program ROM, PAL16L8 2D (`136056-2101`) from its fuse dump, periodic-interrupt divider \| README.md:165 All three programmable chips on the two boards — the video-RAM arbiter `136072-2143`, the priority PAL `136072-1142` and the sound address decoder `136056-2101` README.md:340 Every equation, strobe, timing slot and raster position in this core was taken from the A046903-01 / A047184-02 schematics and the three PAL dumps; `NOTICE.md` README.md:345 Thanks to the MAME team, whose `skullxbo.cpp`, `atarimo.cpp` and JSA sources served as the functional reference throughout, and to whoever preserved the Atari m Cites hardware references or measurements that MAME's driver also gives — 3 rtl/main/skullxbo_dtack.sv:9 Structure ported from `Arcade-Badlands_MiSTer/rtl/main/badlands_dtack.sv` (GPL-3.0, same author, a 28R LS163A doing the same job); the loads, the three-way DTACK and both flops are this board's. — also in MAME: 28R atari/skullxbo.cpp:665 rtl/main/skullxbo_main.sv:156 `jsa:cpu` -> the 6502 ROM at 1B — also in MAME: 1B atari/skullxbo.cpp:661 rtl/mem/skullxbo_rom_loader.sv:18 0x2B8000 0x010000 jsa:cpu block RAM: the 6502 ROM at 1B — also in MAME: 1B atari/skullxbo.cpp:661 Reports a measurement taken on the original PCB — 1 README.md:236 A measurement on a real board, or a dump of the SOS-2, would settle it. Says it was checked on “real hardware” — 2 Arcade-SkullXBones.sv:169 The read-capture phase can only be checked on hardware; see the README. rtl/video/skullxbo_sos2_sync.sv:47 The start is placed by the program's scanline-interrupt timing and confirmed on hardware (the HUD lands on the right line); skullxbo_hstrobes explains why the end cannot be at the wrap. Notes where it differs from MAME — 4 rtl/main/skullxbo_dtack.sv:28 EEPROM (FF6000) 13 2 (MAME does not model them) rtl/main/skullxbo_main.sv:577 MAME does not model this. rtl/video/skullxbo_cram.sv:20 MAME does not model this. README.md:12 Where a schematic and MAME disagree, the schematic wins. Cites MAME source — 64 Arcade-SkullXBones.sv:15 Skull & Crossbones runs on a horizontal monitor (MAME ROT0): no rotation. Arcade-SkullXBones.sv:202 Pad n's coin goes to D(n-1): D0 is MAME's COIN1 and D1 its COIN2, the two the default "separate mechs" setting credits. Arcade-SkullXBones.sv:203 (D3, which MAME marks unused, is debounced by the game but never gives a credit.) Arcade-SkullXBones.sv:205 D0 J1-36 MAME COIN1 Arcade-SkullXBones.sv:206 D1 J1-35 MAME COIN2 Arcade-SkullXBones.sv:207 D2 J1-31 MAME COIN3 Arcade-SkullXBones.sv:208 D3 J1-33 MAME unused rtl/main/skullxbo_addr_decode.sv:79 It selects which half of the motion-object list the MOB reads (MAME's `(offset >> 9) & 1`). rtl/main/skullxbo_inputs.sv:24 AUX #1 and AUX #2 are marked "development only" in the manual (MAME calls them unused); they are wired here as on the board. rtl/main/skullxbo_inputs.sv:36 The enable has no BA1 term, so the nibble appears on every /INPUTS read, at FF5800 as well as FF5802 (MAME shows it only at FF5802). rtl/main/skullxbo_main.sv:35 MAME returns 0x0000 instead. rtl/main/skullxbo_main.sv:47 What a floating data bus reads: 0xFFFF as on the board (MAME uses 0x0000). rtl/mem/skullxbo_rom_loader.sv:13 stream base size MAME region destination rtl/mem/skullxbo_rom_loader.sv:25 In MAME's region order the bytes of one hardware graphics fetch are 0x50000 apart (2 playfield columns, or 5 motion-object planes), so each byte would need its own SDRAM row activate, which is too slow. rtl/mem/skullxbo_rom_loader.sv:64 The playfield bytes are stored raw: MAME inverts that region after loading, but on the board the inversion happens in the SOS-1 shifter, and this core does the same. rtl/mem/skullxbo_vram.sv:104 This is MAME's `playfield_latched_w`, except that only the low byte of the 0xFFA000 word is rewritten (harmless: only D3:0 is used) and there is no "latch disabled" state; 140E always holds a value. rtl/mem/skullxbo_vram.sv:199 From the 136072-2143 fuse dump, decoded with MAME's jedutil. rtl/skullxbo_core.sv:81 UNDRIVEN_DATA what a floating data bus reads: 0xFFFF (no pull-ups); MAME's convention is 0x0000 POR_US the power-on reset length, 35-40 ms on the board rtl/skullxbo_core.sv:306 MAME marks them unused; they are wired here as on the board. rtl/video/skullxbo_alpha.sv:12 D14:11 = ANPAL3:0 D10:0 = the character code, with bit 10 inverted on its way to the ROM (200E LS14): MAME's `code = (data ^ 0x400)` rtl/video/skullxbo_cram.sv:12 The physical A10 is the complement of MAME's, but the CPU side is inverted by the same PAL output, so this module simply stores the software-visible map (bit for bit MAME's FF2000 image); skullxbo_prio outputs that A10 as `shadow`. rtl/video/skullxbo_dac.sv:11 D14..D10 = R5..R1 D9 ..D5 = G5..G1 D4 ..D0 = B5..B1 i.e. MAME's IRGB_1555. rtl/video/skullxbo_lb.sv:24 Hence bank 0 is written while 1V = 1 and read while 1V = 0, and vice versa: the bank written during line L is read during line L+1, and the MOB builds line N+1 during line N. (MAME has no line buffers; this one-line delay is real hardware rtl/video/skullxbo_lb.sv:35 MAME clears its motion-object bitmap every frame, which matches the first reading, so `LB_ERASE = 1` (the default) starts every write pass from an empty buffer. rtl/video/skullxbo_mo_fetch.sv:14 byte in device = code[11:0]16 + row2 + MOHALF full stamp index = MOROMA[17:3] (MAME's 0x7fff mask) rtl/video/skullxbo_mo_fetch.sv:34 MODp7 is the leftmost pixel of a byte (MAME molayout x offset 0), and plane 4 is the most significant pen bit. rtl/video/skullxbo_mo_fetch.sv:44 MAME instead takes `code % 20480`, mirroring banks 0-4 into bank 5. rtl/video/skullxbo_mo_fetch.sv:64 Under MHFLIP the three mechanisms together output the sixteen pens in the order 15, 14, ..., 0: MAME's mirrored tile. rtl/video/skullxbo_mo_fetch.sv:74 The transparent pen is 0 (MAME transpen 0, and PAL 10F's (LBPIX == 0) test), so this model carries the true pen and the line buffer suppresses pen 0. rtl/video/skullxbo_mob.sv:7 MAME's atarimo.cpp is the functional reference for the list semantics. rtl/video/skullxbo_mob.sv:28 The list (MAME s_mob_config): entry at 0xFFD000 + 0x800MOBMSB + 8link : word 0 : D7:0 = the next link (D15:8 unused) word 1 : D14:0 = stamp code , D15 = H-flip word 2 : D3:0 = colour , D5:4 = priority , D15:6 = X word 3 : D15:7 rtl/video/skullxbo_mob.sv:35 Geometry (from atarimo.cpp::render_object). rtl/video/skullxbo_mob.sv:35 MAME computes ypos = (-Y - yscroll - 8height) & 0x1ff and draws tile row ty at sy = ypos + 8ty. rtl/video/skullxbo_mob.sv:45 (The mask cannot alias: MAME's ypos is within [-272, 240) and y within [0, 240).) rtl/video/skullxbo_mob.sv:48 Horizontally MAME uses xpos = X - xscroll and, for H-flip, starts at xpos + (width-1)16 with a negative step, so the tile at xpos + 16k is width-1-k. The F163 line-buffer counters only count up, so the hardware walks k upward: rtl/video/skullxbo_mob.sv:66 (MAME's maxperline = 0 has no limit.) * The walk ends when a link repeats (MAME's `visited[]`, `MOB_END_VISITED`). rtl/video/skullxbo_mob.sv:79 The inferred choices and their defaults: `MOB_CODE_CARRY` 1: the per-tile stamp index is a full 15-bit add that carries into the bank bits MOROMA[17:15], as in MAME's flat code. rtl/video/skullxbo_mob.sv:91 MOTL = 1 reproduces MAME's shadow rule and MOMISC = 0 MAME's "alpha always wins". rtl/video/skullxbo_mob.sv:114 0 gives the literal "match against VS" reading, which puts the whole motion-object layer one scanline low against MAME. rtl/video/skullxbo_mob.sv:133 1 = that one walk matches against the MOB's own 0xD register (the frame's vertical scroll, written by /MOBWR during VBLANK), which is the line MAME draws there. rtl/video/skullxbo_mob.sv:380 MAME's loop is `while (!visited[link])` with `visited[link] = 1` before it follows the link, so an entry that links to itself is processed once. rtl/video/skullxbo_pf.sv:45 The MRA stores the raw ROM bytes, so MAME's ROMREGION_INVERT must not be applied as well. rtl/video/skullxbo_pfhs.sv:11 a nine-bit scroll register, D8:0 = BD15:7, latched on HS = /HSCRL (nine bits, which is what MAME's `2 * (xscroll >> 7)` needs); 2. rtl/video/skullxbo_pfhs.sv:19 MAME: screen dot x shows playfield dot x + 2scroll; in playfield pixels (one H count each) screen count m shows pixel m + scroll, i.e. column (m + scroll) >> 3 and pixel (m + scroll) & 7. rtl/video/skullxbo_prio.sv:9 The PAL equations are the 136072-1142 fuse dump, decoded with MAME's `jedutil -view <jed> GAL16V8`: rtl/video/skullxbo_prio.sv:43 Where MAME's comment and renderer differ from the fuses: MAME's (LBPIX == 1) is really LBTL AND (LBPIX == 1), so MOTL is a per-object enable for the shadow effect; * LBMISC is in MAME's comment but not its renderer: the PAL lets LBMISC pu rtl/video/skullxbo_prio.sv:50 Colour-RAM A10: pin 14 is inverting, so the physical A10 is the complement of MAME's. The CPU side goes through the same output, so software index n and video index n both land on physical row n XOR 0x400, and the palette map software sees rtl/video/skullxbo_prio.sv:82 = NOT a10_pin = MAME's CRAM.A10 rtl/video/skullxbo_sos1.sv:28 This is inferred (the part is undumped) and agrees with three independent facts: the playfield ROMs are stored complemented (MAME's ROMREGION_INVERT) and PFPAL3:0 come off an LS175's /Q pins; 20N needs no inverter; and 25L's empty plane-4 b rtl/video/skullxbo_sos2_sync.sv:70 MAME: 240 visible lines rtl/video/skullxbo_vscroll.sv:20 This is MAME's "scanline 0 should re-latch the previous raw scroll": a hardware read of alpha RAM. rtl/video/skullxbo_vscroll.sv:25 A core that decodes MAME's per-band command words would reload the scroll from ordinary character codes in alpha row 30 during gameplay. rtl/video/skullxbo_vscroll.sv:30 MAME's `(yscroll >> 7) - scanline` with a tilemap that adds the scroll is the same number. rtl/video/skullxbo_vscroll.sv:37 Net effect: VS over the visible part of line y is yscroll_raw + y, bit for bit MAME's tilemap row. README.md:11 MAME was used as a functional reference where the drawings are silent. README.md:42 \| ROMs \| Supplied by you from a MAME archive; none are included here \| README.md:89 Pad 1 is MAME's Coin 1 and pad 2 its Coin 2, the pair the default "separate mechs" coin setting credits; pads 3 and 4 drive the other two inputs. README.md:171 Main CPU — the 68000 bus is compared against MAME: 74,058 consecutive bus cycles agree (address, read/write, data, size) through reset, the ROM checksum README.md:175 Video — MAME was instrumented to capture the complete video state (playfield, alphanumerics, sprite and colour RAM) at chosen frames; those states are playe README.md:186 Sound — the sound board is compared against MAME the same way: the command and response traffic between the boards, and the YM2151 and MSM6295 register writ README.md:242 With that value the board's blanking signal clears the output on the same clock edge that would show screen x = 671, and the core treats that column as blanked; README.md:250 And the motion-object list is read one line ahead of the line it fills, which is the whole 576-dot difference from MAME on the MOTION OBJECT TEST screen (displa README.md:258 The core follows MAME's order (pad 1 = Coin 1), which credits correctly. README.md:345 Thanks to the MAME team, whose `skullxbo.cpp`, `atarimo.cpp` and JSA sources served as the functional reference throughout, and to whoever preserved the Atari m Says it matches, follows or was checked against MAME — 4 rtl/video/skullxbo_prio.sv:39 Pins 5, 16 and 18 are wired on the board but used by no equation; the equations match MAME's independently obtained comment, so the dump is taken as complete. rtl/video/skullxbo_sos1.sv:43 The part only guarantees that the two are equal; 0 (the load edge presents group 0) is what matches MAME's frames. README.md:193 Every program word lands correctly in SDRAM, the boot trace and the first sound round trip match MAME, and eight attract frames come out pixel-exact with all gr README.md:236 The core uses 262 lines / 59.92 Hz, the same as MAME. Shares text with the MAME driver without saying so — 2 rtl/video/skullxbo_sos2_sync.sv:23 ph: 0 1 2 3 4 5 6 7 — shares text with atari/skullxbo.cpp:581 rtl/video/skullxbo_vscroll.sv:21 re-latch the previous raw scroll": a hardware read of alpha RAM. — shares text with atari/skullxbo.cpp:275
SkySmasher# Sky Smasher MiSTer-devel/Arcade_SkySmasher_MiSTer @ 30caa1a2 MAME compared: seibu/bloodbro.cpp + 4 related file(s) Read: 20 HDL files, 5,953 lines (Quartus project)	MiSTer official	Mostly MAME	low	59%
Statements: 2 toward hardware, 46 toward MAME, 1 not counted Cites hardware documentation that MAME's driver does not — 2 rtl/SkySmasher/SkySmasher_main_top.sv:31 Memory map SD Gundam (da MAME dcon.cpp + SD Gundam override): $000000-$07FFFF ROM 68K (512KB) $080000-$08BFFF Main RAM (48KB) $08C000-$08C7FF BG tile RAM (2KB) $08C800-$08CFFF FG tile RAM (2KB) $08D000-$08D7FF MG tile RAM rtl/SkySmasher/SkySmasher_maincpu_map.sv:29 Memory map SD Gundam (da MAME dcon.cpp + sdgndmps_map override): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $080000-$08BFFF Main RAM (48KB) → BRAM $08C000-$08C7FF BG tile RAM → BRAM dual-port $08C800-$ Cites hardware references or measurements that MAME's driver also gives — 1 rtl/SkySmasher/SkySmasher_video_timing.sv:26 PCB measurement Blood Bros: VSync 59.4094 Hz, HSync 15.6246 kHz, master XTAL 20 MHz. — also in MAME: 59.4094 seibu/bloodbro.cpp:970, 15.6246 seibu/bloodbro.cpp:971 Cites MAME source — 42 SkySmasher.sv:222 I valori di calibrazione pixel-perfect MAME sono hardcodati nelle cablature (sotto) / dentro i renderer: - BG X+0 Y+16 : .yoff(10'sd16) - MG X+0 Y+0 : .yoff(10'sd0) - FG X+0 Y+16 : .yoff(10'sd16) - SPR X+0 Y-16 : sprite renderer SkySmasher.sv:302 --- Joystick to SD Gundam input mapping --- MAME P1_P2 port ($E0002): active low. SkySmasher.sv:305 MiSTer joy bits: joy[0]=R, joy[1]=L, joy[2]=D, joy[3]=U, joy[4]=A, joy[5]=B. MAME bloodbro IN0: bit0..3 = U/D/L/R, bit4=Btn1 Fire, bit5=Btn2 Roll, bit6=Btn3 Dynamite (active low) SkySmasher.sv:610 ── Flip screen (CRTC reg 0x1A bit 0) ─────────────────────────────────────── MAME: BIT(reg_1a, 0) → flip_screen. SkySmasher.sv:652 Blood Bros Text: no scroll (MAME bloodbro.cpp non chiama set_scroll su tx_tilemap) SkySmasher.sv:686 Blood Bros CRTC scroll passthrough — nessun offset (MAME bloodbro.cpp:427-430) Blood Bros usa scroll_ram[0/1] per BG e scroll_ram[2/3] per FG (MAME bloodbro.cpp:427-430). SkySmasher.sv:709 Blood Bros: tilemap 32x16 (MAME bloodbro.cpp:292) SkySmasher.sv:744 Blood Bros FG: palette base 0x500 (MAME bloodbro.cpp:808 = 0x5016) MAME bloodbro fg_tile_info: tile = (vram & 0xFFF) + 0x1000 hardcoded. SkySmasher.sv:751 Blood Bros: tilemap 32x16 (MAME bloodbro.cpp:293) SkySmasher.sv:756 Blood Bros: bit 1 = FG (MAME bloodbro.cpp layer_en_w) SkySmasher.sv:803 MAME bloodbro.cpp:379-382 pri_cb: pri=0 → mask 0 (above all), pri=1 → mask 0x02. SkySmasher.sv:804 MAME draw order (riga 434-441): BG → FG → sprites → Text. rtl/SkySmasher/SkySmasher_audio_z80.sv:25 Spec da MAME (reference/mame_seibu/seibusound.cpp + bloodbro.cpp): - Z80 @ 3.579545 MHz (XTAL 7.159090 / 2) - YM3812 (jtopl2) @ 3.579545 MHz - OKI M6295 (jt6295) @ 1.000 MHz (XTAL 12/12), PIN7=HIGH rtl/SkySmasher/SkySmasher_audio_z80.sv:31 Main↔sub comm @ 0xA0000-0xA000D: standard MAME seibu_sound_device. rtl/SkySmasher/SkySmasher_audio_z80.sv:315 ─── OKI M6295 (jt6295) — PIN7_HIGH (bloodbro.cpp:872) ────────────────── rtl/SkySmasher/SkySmasher_main_top.sv:31 Memory map SD Gundam (da MAME dcon.cpp + SD Gundam override): $000000-$07FFFF ROM 68K (512KB) $080000-$08BFFF Main RAM (48KB) $08C000-$08C7FF BG tile RAM (2KB) $08C800-$08CFFF FG tile RAM (2KB) $08D000-$08D7FF MG tile RAM rtl/SkySmasher/SkySmasher_main_top.sv:198 VBLANK IRQ2 — Sky Smasher: MAME bloodbro.cpp set_vblank_int(irq2_line_hold) Rising edge di vblank → assert IRQ2 pending; IACK CPU → clear. rtl/SkySmasher/SkySmasher_main_top.sv:342 XOR 0x400 lato CPU per allineare BRAM[N] = MAME text_vram[N] (renderer parte da addr 0). rtl/SkySmasher/SkySmasher_main_top.sv:350 Quindi MAME palette[N] sta in vram_addr = (N + 0x400) & 0x7FF. rtl/SkySmasher/SkySmasher_main_top.sv:351 Per allineare BRAM[N] = MAME palette[N] applichiamo XOR 0x400 SOLO al lato CPU (a_addr). rtl/SkySmasher/SkySmasher_main_top.sv:352 Il renderer passa pen_index MAME nativo (BG=0x400+, MG=0x500+, ecc) e la BRAM è già allineata. rtl/SkySmasher/SkySmasher_main_top.sv:362 Sprite RAM CPU-side (write/read) — Blood Bros: 4KB = 2048 word (AW=11) MAME bloodbro.cpp:467 map(0x08b000, 0x08bfff).ram().share(m_spriteram) → 4KB. rtl/SkySmasher/SkySmasher_maincpu_map.sv:29 Memory map SD Gundam (da MAME dcon.cpp + sdgndmps_map override): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $080000-$08BFFF Main RAM (48KB) → BRAM $08C000-$08C7FF BG tile RAM → BRAM dual-port $08C800-$ rtl/SkySmasher/SkySmasher_maincpu_map.sv:107 ─── Region detect (MAME bloodbro.cpp:465-483) ────────────────────────── rtl/SkySmasher/SkySmasher_maincpu_map.sv:161 ─── GFX bank register ─────────────────────────────────────────────────── MAME dcon.cpp gfxbank_w: SOLO bit0 → m_gfx_bank_select = 0x1000 oppure 0. rtl/SkySmasher/SkySmasher_palette.sv:25 MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_444, 2048); Address space CPU: 0x08E800..0x08F7FF (4 KB = 2048 word). rtl/SkySmasher/SkySmasher_palette.sv:34 Espansione 5→8 bit con replica top-bits (standard MiSTer / MAME palette_device). rtl/SkySmasher/SkySmasher_palette.sv:86 Blood Bros: xBGR_444 → RGB888 (MAME bloodbro.cpp:859 set_format xBGR_444) Layout: bit[11:8]=R, bit[7:4]=G, bit[3:0]=B. 4 bit per canale. rtl/SkySmasher/SkySmasher_palette.sv:88 Replica 4→8 standard: {nibble, nibble} (MAME palette_device standard expansion) rtl/SkySmasher/SkySmasher_seibu_crtc.sv:23 Seibu CRTC fedele a MAME (src/mame/seibu/seibu_crtc.cpp). rtl/SkySmasher/SkySmasher_seibu_crtc.sv:83 Sky Smasher / Raiden DX: il CRTC usa "read_alt/write_alt" che applicano un bitswap su bit 3 e bit 4 dell'offset word (MAME seibu_crtc.cpp:379-387). rtl/SkySmasher/SkySmasher_seibu_crtc.sv:123 MAME mappa: bit0=screen0(BG), bit1=screen2(MG), bit2=screen1(FG), bit3=screen3(Text) (vedi seibu_crtc.cpp commento "screen 0=BG, screen 1=FG, screen 2=MG, screen 3=Text") In SD Gundam dcon.cpp layer_en_w gira la maschera così: ~layer_en bit rtl/SkySmasher/SkySmasher_seibu_crtc.sv:132 Il dispatcher MAME usa "if (BIT(~m_layer_en, n))" per saltare = layer disabilitato quando il bit è 1. rtl/SkySmasher/SkySmasher_text_renderer.sv:25 Specifiche da MAME (src/mame/seibu/dcon.cpp): rtl/SkySmasher/SkySmasher_tile_layer.sv:25 Differenze fra layer (da MAME dcon.cpp): rtl/SkySmasher/SkySmasher_tile_layer.sv:58 BB FG hardcoded +0x1000 (MAME bloodbro fg_tile_info) rtl/SkySmasher/SkySmasher_tile_layer.sv:169 Tile index con eventuale gfx_bank (MG ha bit 12 = 13-bit totali, BG/FG = 12 bit) + TILE_CODE_OFS hardcoded (BB FG aggiunge 0x1000 secondo MAME bloodbro fg_tile_info). rtl/SkySmasher/SkySmasher_video_timing.sv:35 Active area da MAME (sdgndmps_map): visarea 0..408-1, 28..308-1 quindi 320×224, V offset = 16 (top blank). rtl/SkySmasher/SkySmasher_video_timing.sv:72 ── Constants timing ───────────────────────────────────────────────────── Blood Bros: 256x224 active (MAME bloodbro.cpp:846-851 set_visarea 0..255, 16..239). rtl/SkySmasher/sdram_bridge.sv:296 FG layer: Blood Bros shares ROM with BG (MAME bloodbro:807-808) README.md:18 YM3812 OPL2 FM (jtopl2) + OKI M6295 ADPCM (jt6295) with MAME-accurate mixer README.md:27 MAME-accurate DIP switches: Coin Mode (Mode 1 / Mode 2), Coinage, Starting Coin, Lives, Bonus Life, Difficulty, Allow Continue, Demo Sounds Says it matches, follows or was checked against MAME — 1 SkySmasher.sv:311 SkySmasher SYSTEM port ($0E0004) IN1 — verified MAME bloodbro.cpp:746-754 bit0 = START1 (active LOW) bit4 = START2 (active LOW) bit12 = SERVICE1 (0x1000, active LOW) IPT_SERVICE1 altri = UNKNOWN/UNUSED → tied 1 Coin inputs NON s Shares text with the MAME driver without saying so — 3 rtl/SkySmasher/SkySmasher_main_top.sv:363 MAME bloodbro.cpp:467 map(0x08b000, 0x08bfff).ram().share(m_spriteram) → 4KB. — shares text with seibu/bloodbro.cpp:467 rtl/SkySmasher/SkySmasher_palette.sv:23 Palette RAM Seibu Blood Bros (xBGR_444, 2048 entries). MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_444, 2048); Address space CPU: — shares text with seibu/bloodbro.cpp:859 rtl/SkySmasher/SkySmasher_video_timing.sv:23 Video timing single-screen Seibu D-Con. SD Gundam Psycho Salamander gira su Seibu D-Con (PB91008), stessa famiglia di Blood Bros (1990). PCB measuremen — shares text with seibu/bloodbro.cpp
SlapFight# Slap Fight, Tiger-Heli MiSTer-devel/Arcade-SlapFight_MiSTer @ 9ce05e39 MAME compared: toaplan/slapfght.cpp + 3 related file(s) Read: 14 HDL files, 3,877 lines (Quartus project)	MiSTer official	Mostly hardware	low	21%
Statements: 17 toward hardware, 1 not counted Cites hardware documentation that MAME's driver does not — 1 rtl/slapcore/slap_mcu.v:2 MCU Handshake Flip-Flops (directly from TTL 74LS74) Used for communication with external 68705 MCU (Slap Fight protection) This code does not function currently Cites hardware references or measurements that MAME's driver also gives — 1 rtl/slapcore/slap_sprites.v:271 Sprite 32K RAM Control Signals — also in MAME: 32K toaplan/slapfght.cpp:25 Ships hardware documentation files — 16 docs/KiCAD/SlapFight/CPUA.kicad_sch docs/KiCAD/SlapFight/Connectors.kicad_sch docs/KiCAD/SlapFight/SlapFight.kicad_sch docs/KiCAD/SlapFight/SpriteRAM.kicad_sch docs/KiCAD/SlapFight/SpriteROM.kicad_sch docs/KiCAD/SlapFight/aucpu.kicad_sch docs/KiCAD/SlapFight/background.kicad_sch docs/KiCAD/SlapFight/clock.kicad_sch docs/KiCAD/SlapFight/cpu_wait.kicad_sch docs/KiCAD/SlapFight/foreground.kicad_sch docs/KiCAD/SlapFight/pixels.kicad_sch docs/KiCAD/SlapFight/spLinebuff.kicad_sch docs/KiCAD/SlapFight/spradd.kicad_sch docs/KiCAD/SlapFight/untitled.kicad_sch docs/KiCAD/SlapFight/video_out.kicad_sch docs/KiCAD/SlapFight/vpixels.kicad_sch
SMS# Fantasy Zone II - The Tears of Opa-Opa, Hang-On Jr., Megumi Rescue, Opa Opa … MiSTer-devel/SMS_MiSTer @ 3ae7eec9 MAME compared: sega/segae.cpp + 1 related file(s) Read: 51 HDL files, 14,671 lines (Quartus project)	MiSTer official	Mostly MAME	low	29%
Statements: 13 toward MAME Cites MAME source — 10 rtl/cart_eeprom.vhd:7 Write $8000: bit 2=CS bit 1=CLK bit 0=DI (MAME & Genesis-Plus-GX convention) Read $8000: bit 0=DO rtl/system.vhd:344 4-PAK All Action mapper signals (HES 4 PAK All Action) References: MAME sega8_4pak_device (src/devices/bus/sega8/rom.cpp) rtl/system.vhd:350 Zemina/Nemesis mapper family (MAME: sega8_zemina_device / sega8_nemesis_device) Zemina: 8KB banking via writes to $0000-$0003; $0000-$1FFF starts from page 0. rtl/system.vhd:364 Static opcode-scan Zemina detection (computed during ROM download, ROMCL domain) Mirrors MAME's get_cart_type() logic: counts LD (nn),A opcodes targeting $0002/$0003/$0004 vs $FFFF in the first 32KB of the ROM. rtl/system.vhd:373 Static Codemasters header detection (mirrors MAME get_cart_type) Checks: ROM[0x7FE0] & 0x0F <= 9, ROM[0x7FE3] in {0x93, 0x94, 0x95}, ROM[0x7FEF] = 0x00 rtl/system.vhd:1428 4-PAK All Action mapper (per MAME sega8_4pak_device): $3FFE: reg0=D; bank0=D; bank2=(reg0[5:4]+reg2) $7FFF: bank1=D (independent) $BFFF: reg2=D; bank2=(reg0[5:4]+D) rtl/system.vhd:1560 MEKA mapper type 11: no mapper, linear ROM (MAME dahjee_typeb). rtl/system.vhd:1585 (MAME devices: sega8_dahjee_typea_device) Dahjee Type A heuristic + OSD force. rtl/system.vhd:1651 detect_zemina_static: MAME-equivalent static opcode scan result. rtl/system.vhd:1915 No opcode-boundary tracking needed: same approach as MAME. Says it matches, follows or was checked against MAME — 1 rtl/system.vhd:1912 Static Zemina opcode scan (MAME get_cart_type() port) Scans only the first 32KB (ROMAD < 0x8000), matching MAME exactly. Says it was translated, ported or taken from MAME — 1 rtl/MC8123.v:1 Copyright 2021 by blackwine decryption algorithm based on MAME sources Shares text with the MAME driver without saying so — 1 SMS.sv:181 0 1 2 3 4 5 6 — shares text with sega/segae.cpp:821
SNK6502# Fantasy, Nibbler, Pioneer Balloon, Sasuke vs. Commander … MiSTer-devel/Arcade-SNK6502_MiSTer @ 0e32dadc (matched by date) MAME compared: snk/snk6502.cpp + 4 related file(s) Read: 10 HDL files, 4,997 lines (Quartus project)	MiSTer official	Both	low	48%
Statements: 4 toward hardware, 28 toward MAME Ships hardware documentation files — 3 Useful Information/schematics/Nibbler Schematics.pdf Useful Information/schematics/Vanguard.pdf Useful Information/schematics/Vanguard_-_1981_-_SNK_Corporation.pdf Notes where it differs from MAME — 1 rtl/snk6502.v:462 MAME cannot arbitrate this: it ignores R12/R13 entirely and renders the tilemap from its own scan (TILEMAP_SCAN_ROWS, tile_index 0 at the origin, no scrolldx), so the whole question is invisible there. Cites MAME source — 21 Arcade-SNK6502.sv:233 ----- Sasuke / SatanSat free-running counter ----- MAME (snk6502.cpp): 8-bit counter += 0x10 at 1.4 MHz; sasuke_count_r() = counter >> 4. Arcade-SNK6502.sv:325 --- Fantasy (game_id=3) --- IN0 b7=L b6=R b5=U b4=D (8W); MAME has b3..0=UNKNOWN. Arcade-SNK6502.sv:342 MAME maps debug service inputs (slow-down, pause, end-game) onto those bits for testing, but the ROM treats any high level on those bits as debug activity. Arcade-SNK6502.sv:389 MAME custom bit — high when sound ch0 is muted rtl/snk6502.v:46 Sound channel 0 mute status (MAME music0_playing — active high when muted). rtl/snk6502.v:444 MEASURED (MAME debugger, user, 2026-08-04): Sasuke and Satan of Saturn program an IDENTICAL 6845 register table to Vanguard except for ONE register pair - the start address R12/R13. rtl/snk6502.v:491 MAME applies the full 8-bit value (snk6502_v.cpp:139 set_scrolly(0, data)), so [7:3]-only is wrong vs reference. rtl/snk6502.v:495 Vanguard writes $3300 (scroll_y) 2967 times vs 199 for $3200 in the MAME trace, so this is the axis that actually carries the scrolling. rtl/snk6502.v:541 MAME maps speech_w at $3400 EXACTLY (snk6502.cpp vanguard_map:409); a stray write anywhere else in the page would feed a spurious nibble into the HD38880 command FSM and desync it. rtl/snk6502.v:608 Mirror MAME's HOLD_LINE: assert on vblank rising edge, auto-clear when CPU starts fetching the IRQ vector ($FFFE). rtl/snk6502.v:787 The colour is likewise delayed one character (bg_color_prev) so it still belongs to tile T. So f=0 reproduces the previous design exactly; only nonzero fine bits change anything, and MAME applies the full 8-bit scroll value the same way. rtl/snk6502.v:849 MAME gfx_vanguard uses charlayout_memory for the FG with planes { 0, 25688 }, and MAME's FIRST plane entry is the pixel MSB => MSB = charram+0x000 (= our charram_p0), LSB = charram+0x800 (= our charram_p1). rtl/snk6502.v:990 MAME snk6502_v.cpp:26 (snk6502_palette; satansat_palette:189 is identical, so one formula covers all six games) uses resistor weights 0x21 / 0x47 / 0x97 per bit: r = 0x21bit0 + 0x47bit1 + 0x97bit2 (prom bits 2:0) g = 0x21bit3 + 0x4 rtl/snk6502.v:998 Bit-replication gave blue 0/85/170/255 - systematically ~15% too bright - which is why our cyan terrain measured (0,255,255) where MAME has (0,255,222). rtl/snk6502.v:1108 Sound port write strobes — game-aware (per MAME memory maps) Fantasy/Nibbler: $2100-$2103 (port 3 also written by fantasy_flipscreen_w) Vanguard: $3100-$3102 (no port 3; $3103 is flipscreen only) Pioneer Balloon: $B100-$B102 (n rtl/snk6502.v:1125 SASUKE-SATANSAT-SOUND-2026-08-03: Sasuke/SatanSat put their sound port at $B000/$B001 (MAME sasuke_map:347 / satansat_map:367), which was NOT DECODED ANYWHERE - so no sound command from either game ever reached snk6502_snd. rtl/snk6502.v:1150 VANGUARD-SOUND-2026-08-03: selects MAME's vanguard_sound_device semantics instead of fantasy_sound_device's. See Claude/vanguard_audio_audit_2026-08-03.md rtl/snk6502.v:1182 MAME vanguard_sound_device::sound_w port 0 (snk6502_a.cpp:577-617): bit 5 SHOT A -> sn76477.1 (was: NOT WIRED TO ANYTHING - silent gun) bit 6 SHOT B -> sn76477.2 (was: NOT WIRED TO ANYTHING) bit 7 BOMB -> "explsion" sample; left on the rtl/snk6502.v:1186 MAME fantasy_sound_device::sound_w port 0 (:762-795): bit 7 BOMB -> sn76477.1 -> discrete, driven as a LEVEL (m_discrete->write(FANTASY_BOMB_EN, data & 0x80)) rtl/snk6502.v:1212 MAME routes this at 0.25 vs SHOT A's 0.50, hence half the amplitude. rtl/snk6502.v:1255 MAME has the same imbalance - it routes Vanguard speech samples at 0.25 vs custom 0.50 / SHOT A 0.50 (snk6502_a.cpp:691-730) - and the user confirmed MAME Vanguard speech is inaudible without boosting the samples channel ~300% and reducing Says it matches, follows or was checked against MAME — 4 Arcade-SNK6502.sv:295 Per-game IN0 / IN1 / IN2 construction (active high — matches MAME) Bit ordering reminder: {b7, b6, b5, b4, b3, b2, b1, b0} rtl/snk6502.v:1002 Verified against screenshots: MAME's brightest blue really is 222. rtl/snk6502.v:1022 Matches MAME's PORT_IMPULSE(1) + coin_inserted() semantics: NMI is asserted on the FALLING edge of the coin bit (i.e., when the user releases the coin button, or when MAME's 1-frame impulse expires). rtl/snk6502.v:1199 ---- SN76477 leg A: 470k noise clock (3081.7 Hz) + 1.5M/220pF filter -------- Shared by Vanguard SHOT A and Fantasy BOMB: identical component values in MAME, and they belong to different games so the gates can never both be high. Shares text with the MAME driver without saying so — 3 rtl/snk6502.v:4 Supports: Sasuke vs. Commander, Satan of Saturn / Zarzon, Vanguard, — shares text with snk/snk6502.cpp:8 rtl/snk6502.v:993 r = 0x21bit0 + 0x47bit1 + 0x97*bit2 (prom bits 2:0) — shares text with snk/snk6502_v.cpp:37 rtl/snk6502.v:1188 (m_discrete->write(FANTASY_BOMB_EN, data & 0x80)) — shares text with snk/snk6502_a.cpp:790
SNK_TripleZ80# ASO - Armored Scrum Object MiSTer-devel/Arcade-SNK_TripleZ80_MiSTer @ 7181e418 MAME compared: snk/snk.cpp + 2 related file(s) Read: 79 HDL files, 9,067 lines (Quartus project)	MiSTer official	Mostly hardware	low	43%
Statements: 13 toward hardware, 3 toward MAME Cites hardware documentation that MAME's driver does not — 11 rtl/clocks/AlphaMissionCore_Clocks_Sync.sv:199 74LS30 8-input positive NAND gate rtl/clocks/pal16r6_15B_sync.v:1 Author: @RndMnkIII Date: 13/03/2022 Converted from ArmoredScrumObject_pal16r6a_3.jed using MAME's jedutil tool Many thanks to pldarchive.co.uk for the JED file. rtl/cpuA_B/pal16l6c_A1_nodly.v:1 Author: @RndMnkIII Date: 14/12/2021 Converted from AlphaMission_PAL16L6C_1A.jed using MAME's jedutil tool Many thanks to pldarchive.co.uk for the JED file. rtl/front/AlphaMissionCore_LineBuffer_sync.sv:155 74LS20 4-input NAND gate rtl/ttl/ttl_74107a_sync.v:1 74LS107A: Dual J-/K flip-flop with clear; negative-edge-triggered Inputs Outputs rtl/ttl/ttl_74163a_sync.v:1 4-bit modulo 16 binary counter with parallel load, * FOR SYNTHESIS * Synchronous Reset (SRn) -> LS163A <START_TEMPLATE> ttl_74161a #(.DELAY_RISE(20), .DELAY_FALL(25)) <NAME> (.Clear_bar(), .Load_bar(), .ENT(), .ENP(), .D(), .Clk(), .RCO rtl/ttl/ttl_74373.sv:1 ttl_74373.sv Octal D transparent latch function table, logic diagrams and switching characteristics extracted from TI 74LS373 Datasheet. rtl/ttl/ttl_74374_sync.sv:1 ttl_74374_sync.sv Octal D edge triggered FF function table, logic diagrams and switching characteristics extracted from TI 74LS374 Datasheet. rtl/ym3526/jtopl_exprom.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots. rtl/ym3526/jtopl_logsin.v:16 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots. rtl/ym3526/jtopl_op.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots. Says it was checked on “real hardware” — 1 rtl/final_video/pal16l8a_F9_nodly.v:5 This PLD was simplified, cleaned and tested on real hardware (GAL16V8-25LP device) Ships hardware documentation files — 1 docs/TNKIII_schematics.pdf Cites MAME source — 3 rtl/SNK_TripleZ80.sv:257 0XCE00 cpuA write registers (Unknown meaning in MAME) rtl/clocks/pal16r6_15B_sync.v:1 Author: @RndMnkIII Date: 13/03/2022 Converted from ArmoredScrumObject_pal16r6a_3.jed using MAME's jedutil tool Many thanks to pldarchive.co.uk for the JED file. rtl/cpuA_B/pal16l6c_A1_nodly.v:1 Author: @RndMnkIII Date: 14/12/2021 Converted from AlphaMission_PAL16L6C_1A.jed using MAME's jedutil tool Many thanks to pldarchive.co.uk for the JED file.
SolomonsKey# Solomon no Kagi MiSTer-devel/Arcade-SolomonsKey_MiSTer @ 57b099d9 MAME compared: tecmo/solomon.cpp Read: 17 HDL files, 6,424 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	9%
Statements: 1 toward MAME Cites MAME source — 1 rtl/YM2149_linmix_sep.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA
Sonson# Son Son MiSTer-devel/Arcade-Sonson_MiSTer @ d0ac4b40 MAME compared: capcom/sonson.cpp Read: 31 HDL files, 9,644 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	7%
Statements: 1 toward MAME Cites MAME source — 1 rtl/ym2149/YM2149.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA
SpaceFirebird# Space Firebird MiSTer-devel/Arcade-SpaceFirebird_MiSTer @ ea952fe3 MAME compared: nintendo/spacefb.cpp Read: 40 HDL files, 10,965 lines (Quartus project)	MiSTer official	Mostly MAME	low	13%
Statements: 2 toward hardware, 29 toward MAME, 1 not counted Cites hardware documentation that MAME's driver does not — 2 rtl/dkongjr_dac.sv:8 Components R20, C32 and Q4 on schematics. rtl/nintendo_sound.v:90 ---- DATA ROM 3H --------------------------- Cites hardware references or measurements that MAME's driver also gives — 1 rtl/SpaceFirebird.vhd:228 0000-3FFF ROM Code 8000-83FF RAM Sprite RAM C000-C7FF RAM Game RAM — also in MAME: 83FF nintendo/spacefb.cpp:28 Cites MAME source — 1 README.txt:20 The schematics show orange / yellow (but with one resistor mislabelled as 68 ohm) Mame uses red, because of this error on the schematics. Shares text with the MAME driver without saying so — 28 rtl/SpaceFirebird.vhd:425 bit 5 = Char/Sprite Bank switch (VREF) — shares text with nintendo/spacefb.cpp:86 rtl/SpaceFirebird.vhd:426 bit 6 = Turns on Bit 2 of the color PROM. Used to change the bird colors. (CREF) — shares text with nintendo/spacefb.cpp:87 rtl/SpaceFirebird.vhd:429 bit 0 = discrete sound (Enemy death) — shares text with nintendo/spacefb.cpp:91 rtl/SpaceFirebird.vhd:431 bit 2 = T1 input to 8035 — shares text with nintendo/spacefb.cpp:93 rtl/SpaceFirebird.vhd:432 bit 3 = PB4 input to 8035 — shares text with nintendo/spacefb.cpp:94 rtl/SpaceFirebird.vhd:433 bit 4 = PB5 input to 8035 — shares text with nintendo/spacefb.cpp:95 rtl/SpaceFirebird.vhd:434 bit 5 = T0 input to 8035 — shares text with nintendo/spacefb.cpp:96 rtl/SpaceFirebird.vhd:435 bit 6 = discrete sound (Ship fire) — shares text with nintendo/spacefb.cpp:97 rtl/SpaceFirebird.vhd:436 bit 7 = discrete sound (Explosion noise) — shares text with nintendo/spacefb.cpp:98 rtl/SpaceFirebird.vhd:440 These are passed to the sound board and are used to produce a — shares text with nintendo/spacefb.cpp:102 rtl/SpaceFirebird.vhd:441 red flash effect when you die. — shares text with nintendo/spacefb.cpp:103 rtl/SpaceFirebird.vhd:443 bit 0 = CONT R Changes contrast of the red/green/blue part of the stars. This is used to make the starfield flicker — shares text with nintendo/spacefb.cpp:105 rtl/SpaceFirebird.vhd:446 bit 3 = ALRD Turns background red on — shares text with nintendo/spacefb.cpp:108 rtl/SpaceFirebird.vhd:447 bit 4 = ALBU Turns background blue on — shares text with nintendo/spacefb.cpp:109 rtl/SpaceFirebird.vhd:448 bit 7 = ALBA Turns off star field (no star field) — shares text with nintendo/spacefb.cpp:112 rtl/SpaceFirebird.vhd:497 bit 4 = Player 1 Warp / Escape — shares text with nintendo/spacefb.cpp:40 rtl/SpaceFirebird.vhd:504 bit 4 = Player 2 Warp / Escape — shares text with nintendo/spacefb.cpp:51 rtl/SpaceFirebird.vhd:509 bit 2 = Start 1 Player game — shares text with nintendo/spacefb.cpp:60 rtl/SpaceFirebird.vhd:510 bit 3 = Start 2 Players game — shares text with nintendo/spacefb.cpp:61 rtl/SpaceFirebird.vhd:512 bit 7 = Coin and Service switch — shares text with nintendo/spacefb.cpp:65 rtl/SpaceFirebird.vhd:599 bit 0 = discrete sound (Enemy death) — shares text with nintendo/spacefb.cpp:91 rtl/SpaceFirebird.vhd:604 bit 7 = discrete sound (Explosion noise) — shares text with nintendo/spacefb.cpp:98 rtl/SpaceFirebird.vhd:610 bit 6 = discrete sound (Ship fire) — shares text with nintendo/spacefb.cpp:97 rtl/SpaceFirebird_video.vhd:513 CONT R Changes contrast of the red/green/blue part of the stars. This is used to make the starfield flicker — shares text with nintendo/spacefb.cpp:105 rtl/nintendo_sound.v:44 -- bit 2 = T1 input to 8035 — shares text with nintendo/spacefb.cpp:93 rtl/nintendo_sound.v:45 -- bit 3 = PB4 input to 8035 — shares text with nintendo/spacefb.cpp:94 rtl/nintendo_sound.v:46 -- bit 4 = PB5 input to 8035 — shares text with nintendo/spacefb.cpp:95 rtl/nintendo_sound.v:47 -- bit 5 = T0 input to 8035 — shares text with nintendo/spacefb.cpp:96
SpaceInvaders# 280-ZZZAP, Attack Force, Balloon Bomber, Blue Shark … MiSTer-devel/Arcade-SpaceInvaders_MiSTer @ 07386c17 MAME compared: midw8080/8080bw.cpp + 12 related file(s) Read: 23 HDL files, 6,555 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	33%
Statements: 5 toward MAME Cites MAME source — 2 Arcade-SpaceInvaders.sv:978 note because the CPU has the address line A9 (A1 for IO) inverted we have to be careful in looking at mame mapping Currently: GDB0-7 have A9 inverted, but PortWr doesn't we should probably not invert A9 in GDB0-7? README.md:23 Included is a python script that converts the MAME .lay files into Taito color overlay rom format. Shares text with the MAME driver without saying so — 3 Arcade-SpaceInvaders.sv:683 0x07, 0x06, 0x04, 0x05, 0x01, 0x00, 0x02 — shares text with midw8080/mw8080bw.cpp:432 Arcade-SpaceInvaders.sv:685 0x06, 0x02, 0x00, 0x04, 0x05, 0x01, 0x03 — shares text with midw8080/mw8080bw.cpp:539 Arcade-SpaceInvaders.sv:687 0x00, 0x04, 0x06, 0x07, 0x03, 0x01, 0x05 — shares text with midw8080/mw8080bw.cpp:1119
SpaceRace# Space Race [TTL] MiSTer-devel/Arcade-SpaceRace_MiSTer @ 93d68ce9 MAME driver: not found Read: 40 HDL files, 3,672 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	11%
Statements: 1 toward hardware Cites hardware documentation that MAME's driver does not — 1 Arcade-SpaceRace.sv:3 Based on Rev.F schematics
Sprint1# Sprint 1 MiSTer-devel/Arcade-Sprint1_MiSTer @ fc0e8180 MAME compared: atari/sprint2.cpp + 2 related file(s) Read: 20 HDL files, 5,306 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	6%
Statements: 3 toward hardware Cites hardware documentation that MAME's driver does not — 3 rtl/collision.vhd:63 74LS279 quad SR latch at H6, all inputs are active low Made synchronous here rtl/playfield.vhd:93 Some glue logic, may be re-written later to be cleaner and easier to follow without referring to schematic rtl/playfield.vhd:169 74LS166 video shift register
Sprint2# Sprint 1 MiSTer-devel/Arcade-Sprint2_MiSTer @ cd2b0025 MAME compared: atari/sprint2.cpp + 2 related file(s) Read: 20 HDL files, 5,563 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	6%
Statements: 3 toward hardware Cites hardware documentation that MAME's driver does not — 3 rtl/collision.vhd:69 74LS279 quad SR latch at H6, all inputs are active low These should probably be written as synchronous latches rtl/playfield.vhd:95 Some glue logic, may be re-written later to be cleaner and easier to follow without referring to schematic rtl/playfield.vhd:180 74LS166 video shift register
ST-V# Astra SuperStars, Baku Baku Animal, Batman Forever, Columns '97 … MiSTer-devel/Saturn_MiSTer @ db56bcec MAME compared: sega/stv.cpp + 23 related file(s) Read: 76 HDL files, 44,554 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	6%
Statements: 1 toward hardware, 5 toward MAME Cites hardware documentation that MAME's driver does not — 1 rtl/Saturn/CART.sv:5 0-none, 1-ROM 2M, 2-DRAM 1M, 3-DRAM 4M, 4-DRAM 6M, 5-BACKUP Shares text with the MAME driver without saying so — 5 Saturn.sv:276 0 1 2 3 4 5 6 7 8 9 — shares text with sega/315-5881_crypt.cpp:529 rtl/Saturn/STV/STVIO.sv:34 0x0007 PORT-D (OUTPUT) JAMMA (56P) + CN25 (JST NH 5P) RESERVED OUTPUT 4bit. (?) — shares text with sega/stv.cpp:134 rtl/Saturn/STV/STVIO.sv:35 0x0009 PORT-E (P3) CN32 (JST NH 9P) EXTENSION I/O 8bit. — shares text with sega/stv.cpp:135 rtl/Saturn/STV/STVIO.sv:36 0x000b PORT-F (P4 / Extra 6B layout) CN21 (JST NH 11P) EXTENSION I/O 8bit. — shares text with sega/stv.cpp:150 rtl/Saturn/STV/STVIO.sv:37 0x000d PORT-G CN20 (JST HN 10P) EXTENSION INPUT 8bit. (?) — shares text with sega/stv.cpp:137
Starforce# Baluba-louk no Densetsu, Star Force MiSTer-devel/Arcade-StarForce_MiSTer @ 9327e228 MAME compared: tecmo/senjyo.cpp Read: 23 HDL files, 6,696 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	11%
Statements: 2 toward MAME Cites MAME source — 2 Arcade-Starforce.sv:368 JPAC/IPAC/MAME Style Codes rtl/sn76489/sn76489_noise.vhd:199 Tapped bits according to MAME's sn76496.c, implemented in function lfsr_tapped_f.
StarWars# The Empire Strikes Back, Star Wars MiSTer-devel/Arcade-StarWars_MiSTer @ 64aaa04a MAME compared: atari/starwars.cpp + 4 related file(s) Read: 37 HDL files, 20,579 lines (Quartus project)	MiSTer official	Both	low	17%
Statements: 28 toward hardware, 7 toward MAME, 6 not counted Cites hardware documentation that MAME's driver does not — 28 rtl/avg/avg.vhd:104 On hardware, this is latched by the LS175 (6L, schematic p.25 Fig.1) from DVY10-DVY8, and drives the LS191 down-counter that gates additional fill-bit shifts into the timer at STROBE 1. rtl/avg/avg.vhd:113 GO flag (schematic p.24 Fig.3: 2E LS32 pin 8). rtl/avg/avg.vhd:123 Normalization at 12 MHz (schematic p.24 Fig.0: Normalization Flag circuit). rtl/avg/avg.vhd:124 STROBE 0 + OP0=0 sets NORM (LS74 5K). rtl/avg/avg.vhd:129 15-bit Vector Timer (schematic p.25 Fig.0: four cascaded LS161 counters 1D/1C/1B/2B, clocked at 12 MHz during draw, enabled by PR111 (+5V pull-up), loaded via fill-bit shifts during normalization and bin_scale). rtl/avg/avg.vhd:137 Bin_scale shift mechanism at STROBE 1 (schematic p.25 Fig.1: Vector Scaling). rtl/avg/avg.vhd:241 ===== VMEM bus arbitration: CPU accessing vector memory ===== On real hardware (schematic p.24 Fig.3), EVMEM from the main board gates the state machine clock via NOR gate 3E (LS02). rtl/avg/avg.vhd:275 /LATCH1 clears three chip groups (schematic p.23): 5F,5H (Fig.2): DVY0-7 async cleared to 0 5A,5B,5C (Fig.2): DVX0-11 async cleared to 0 3C (Fig.0): Z0-Z2 + DVX12 async cleared to 0 6H(DVY8-11) has /CLR=PR110 (not cleared here). rtl/avg/avg.vhd:312 STROBE0 + OP0=0 sets NORM (LS74 5K, p.24 Fig.0). rtl/avg/avg.vhd:323 STROBE 1 (state $D): SP adjust for JSR/RTS, or Vector Scaling (schematic p.25 Fig.1) for VCTR/SVEC. rtl/avg/avg.vhd:409 12 MHz Normalization Block (runs OUTSIDE clken gate) Schematic p.23 Fig.2: LS194 shift registers (3A-3D, 4A-4D) shift DVX/DVY left at 12 MHz, gated by ENORM. rtl/avg/avg.vhd:412 Schematic p.25 Fig.0: LS161 timer chain (1D/1C/1B/2B) shifts right simultaneously, filling from the top. rtl/avg/avg.vhd:414 Schematic p.24 Fig.0: NORM flag freezes PROM via SA. rtl/avg/avg.vhd:454 12 MHz Bin_Scale Block (runs OUTSIDE clken gate) Schematic p.25 Fig.1: Vector Scaling circuit. rtl/mathbox.sv:4 Hardware reference: - 4x 1Kx4 Microcode PROMs (136021-110 through 136021-113) - 74LS384 serial subtractor-multiplier-accumulator - 2Kx16 shared Math RAM ($5000-$5FFF as CPU sees it) - 15-bit unsigned fractional divider - 23-bit PRNG (LFSR) rtl/mathbox.sv:16 Based on SWMP.DOC, TCODE2.MAC, SWSIG.DOC, and original schematics: - SP-225 Sheet 5B & 6A: Divider, Matrix Processor, and Multiplier-Accumulator Block Diagrams - SP-225 Sheet 9A, 9B: 15-bit Restoring Divider - SP-225 Sheet 10A: Multiplier/A rtl/reticon_r5106.sv:4 Models the delay circuit on the original Atari Star Wars PCB (Sheet 16B): R5106 BBD: 512 stages, clocked at 37.8 kHz = 13.5 ms delay Recovery amp: TL084 (1/4 3C) with R45=470K, R46=12K Post-delay filter: TL084 (1/4 2B), R47=12K, C57/C58=270 rtl/reticon_r5106.sv:9 Schematic analysis (Sheet 16B, fig 2: "Output and Summing Amplifiers") shows the delayed signal feeds two TL084 stereo output amps alongside the dry "AUD" signal, creating what SWSIG.DOC calls "synthesized stereo." My interpretation: Left = rtl/reticon_r5106.sv:13 The exact polarity is difficult to confirm from the available schematic scans. rtl/slapstic101.vhd:1 Atari SLAPSTIC 137412-101 (Empire Strikes Back / Tetris) — faithful FPGA port of MAME's DECAPPED slapstic (src/mame/atari/slapstic.{cpp,h}, Aaron Giles & Frank Palazzolo). rtl/slapstic101.vhd:16 KEY DECAPPED FACTS (type 101, 13 address lines A0-A12, banked region $8000-$9FFF): * range_mask = 0xE000, input_mask = 0x1FFF, range_value = 0x8000 * test_in(mv) : inside ($8000-$9FFF) AND (a & mv.mask)=mv.value rtl/slapstic101.vhd:28 type-101 data (decapped): bankstart 3 ; bank = {0x0080,0x0090,0x00a0,0x00b0} alt1 {0x1f00,0x1e00} alt2 {0x1fff,0x1fff}(any/outside) alt3 {0x1ffc,0x1b5c} alt4 {0x1fcf,0x0080} altshift 0 bit1 {0x1ff0,0x1540} bit2 {0x1fcf,0x0080} bit3c0 { rtl/starwars.sv:251 --- ROM Download Address Decoding --- ----- SW-mode dn_addr decoders ----- MRA ROM layout (index 0), based on actual file sizes: 0x00000-0x03FFF: Banked ROM (16KB: 136021.214.1f, two 8K bank pages) 0x04000-0x0BFFF: Main ROM (32KB: 4x 8KB f rtl/starwars.sv:644 Bus arbitration: on real hardware, EVMEM gates the AVG state machine clock via NOR gate 3E (LS02) on the AVG board (schematic p.24 Fig.3). rtl/starwars.sv:828 AUDIO MIXING (Based on original Atari schematic SP-225 Sheet 16A/16B) rtl/starwars.sv:862 AUDIO PROCESSING (Sheet 16B: Filter + Reticon R5106 Delay/Stereo) rtl/starwars.sv:889 Reticon R5106 Delay (13.5 ms) - Pseudo-Stereo The original PCB routes the delayed signal to stereo summing amps (Sheet 16B, fig 2) alongside the dry signal. README.md:22 \| Vector Generator \| Atari Analog Vector Generator (AVG) with state machine PROM, 10-bit DACs, analog integrators \| Cycle-exact digital AVG in `avg.vhd` bas Cites hardware references or measurements that MAME's driver also gives — 6 rtl/avg/avg.vhd:63 Hardware: 136021-109.4b bipolar PROM — also in MAME: 136021-109 atari/starwars.cpp:391 rtl/avg/avg.vhd:109 PROM state machine signals (256x4 PROM 136021-109.4b, schematic p.24 Fig.3) — also in MAME: 136021-109 atari/starwars.cpp:391 rtl/mathbox.sv:220 Serial Multiplier State (74LS384 model) ACC += (A-B) * C * 4 (the <<2 models 74LS384 pipeline alignment) A-B is retained at 17 bits before the signed multiply. — also in MAME: 74LS384 atari/starwars_m.cpp:231, 74LS384 atari/starwars_m.cpp:231 rtl/mathbox.sv:367 Initialize serial multiplier (74LS384) A-B at 17-bit width (prevents wrapping), then sign-extended to 33 bits — also in MAME: 74LS384 atari/starwars_m.cpp:231 rtl/mathbox.sv:397 ----- MAC Stall: 33 cycles for serial multiply ----- Models the 74LS384 serial subtractor-multiplier-accumulator. — also in MAME: 74LS384 atari/starwars_m.cpp:231 README.md:21 \| Math Processor \| Custom TTL Mathbox (PROM-sequenced matrix processor, 74LS384 serial multiplier, 15-step restoring divider) \| Fully modeled in `mathbox.sv — also in MAME: 74LS384 atari/starwars_m.cpp:231 Cites MAME source — 5 rtl/A6532.vhd:19 Reference: MOS 6532 datasheet, mos6532_device, Stella M6532, MAME rtl/TMS5220.vhd:15 References: TMS5220 datasheet, US Patent US4335277 and TMS5220.cpp from MAME source code. rtl/slapstic101.vhd:5 WHY THIS EXISTS (supersedes rtl/slapstic.vhd for ESB): rtl/slapstic.vhd is a verbatim translation of an OLD, unconfirmed MAME slapstic. rtl/slapstic101.vhd:10 But ESB gameplay uses ALTERNATE ("devious") banking, confirmed via MAME (-log) over real play: 51 full alt-start/valid/select/commit sequences reaching banks 0/2. rtl/slapstic101.vhd:24 MAME taps the WHOLE space; so must we. Says it was translated, ported or taken from MAME — 2 rtl/TMS5220.vhd:17 IMPORTANT NOTES: 1) This implementation does NOT implement the schematic in US4335277 2) It is based primarily on MAME source code and aims to be "functionally equivalent" to the "TMS5220" chip but not identical in terms of electrical circu rtl/slapstic101.vhd:1 Atari SLAPSTIC 137412-101 (Empire Strikes Back / Tetris) — faithful FPGA port of MAME's DECAPPED slapstic (src/mame/atari/slapstic.{cpp,h}, Aaron Giles & Frank Palazzolo).
Subs# Subs MiSTer-devel/Arcade-Subs_MiSTer @ 2d7bc75a MAME compared: atari/subs.cpp + 2 related file(s) Read: 22 HDL files, 7,628 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	16%
Statements: 10 toward hardware Cites hardware documentation that MAME's driver does not — 10 rtl/cpu_mem.vhd:353 74LS42 at B9 decodes ROM and RAM enable signals rtl/cpu_mem.vhd:364 74LS42 at D9 decodes IO enable signals Write to outputs rtl/cpu_mem.vhd:379 74LS259 addressable latch at C9, this drives outputs rtl/input.vhd:95 74LS251 data selector/multiplexer at E10 rtl/input.vhd:112 74LS251 data selector/multiplexer at F10 rtl/input.vhd:129 74LS253 dual selector/multiplexer at E9 rtl/mixer.vhd:74 74LS174 latches video signals with rising edge of 6MHz clock rtl/playfield.vhd:119 74LS166 video shift register rtl/playfield.vhd:176 74LS163 counter at L6 CEP and CET tied to ground, counter is used only as a synchronous latch rtl/subs_core.vhd:16 Targeted to EP2C5T144C8 mini board but porting to nearly any FPGA should be fairly simple See Subs manual Figure 4-11 for video output details.
SuperBreakout# Super Breakout MiSTer-devel/Arcade-SuperBreakout_MiSTer @ 6d13f89b MAME compared: atari/sbrkout.cpp Read: 19 HDL files, 4,980 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	11%
Statements: 2 toward hardware, 1 toward MAME Cites hardware documentation that MAME's driver does not — 2 rtl/paddle_analog.vhd:47 Logic gates in IC at M10 These should be a 74LS132 with Schmitt trigger inputs, may not work reliably using FPGA pins directly rtl/playfield.vhd:114 74LS166 video shift register Cites MAME source — 1 rtl/super_breakout.vhd:182 r 3 g 3 b 3 https://github.com/mamedev/mame/blob/master/src/mame/layout/sbrkout.lay
SuprLoco# Super Locomotive MiSTer-devel/Arcade-SuprLoco_MiSTer @ 8a31d652 MAME compared: sega/suprloco.cpp Read: 16 HDL files, 3,290 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	58%
Statements: 7 toward hardware, 3 toward MAME Cites hardware documentation that MAME's driver does not — 7 rtl/SuprLoco_emu.v:148 Note 1: TBP24S41 = 82S137 TBP28S46 = 82S141 TBP18S030 = 82S123 rtl/SuprLoco_top.v:44 82S137(AW10) rtl/SuprLoco_top.v:45 82S141(AW9) rtl/SuprLoco_top.v:46 82S123(AW5) rtl/SuprLoco_top.v:56 74LS321 acts really weird - see the LS321 sigrok waveform rtl/SuprLoco_top.v:410 74LS377 rtl/SuprLoco_top.v:411 74LS273 Cites MAME source — 1 rtl/SuprLoco_emu.v:128 start addr length comp num mame rom parts num location description Shares text with the MAME driver without saying so — 2 SuprLoco.sv:214 0 1 2 3 4 5 6 — shares text with sega/suprloco.cpp:456 rtl/SuprLoco_top.v:55 74LS321 acts really weird - see the LS321 sigrok waveform CLK40M ¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\|¯\|_\| pres — shares text with sega/suprloco.cpp:456
TaitoAsuka# Asuka & Asuka, Jigoku Meguri, Cadash, U.N. Defense Force: Earth Joker … MiSTer-devel/Arcade-TaitoAsuka_MiSTer @ 747a777b MAME compared: taito/asuka.cpp + 11 related file(s) Read: 54 HDL files, 24,873 lines (Quartus project)	MiSTer official	Both	medium	40%
Statements: 6 toward hardware, 157 toward MAME, 2 not counted Cites hardware documentation that MAME's driver does not — 3 rtl/asuka/z180/cadash_link_z180.sv:20 $8000-$87FF RAM condivisa col 68000 (2 KB) I/O $00-$3F registri interni -> z180_io README.md:79 This core runs the real firmware on an HDL model of the MCU: [`jttc0030cmd`](https://github.com/jotego/jtcores) by Andrea Bogazzi wrapping Raki's `I README.md:272 Raki for IKA87AD, the uPD78C11 model reconstructed from the decapped die and the NEC datasheet, and Andrea Bogazzi ([@asturur](https://github.com/as Cites hardware references or measurements that MAME's driver also gives — 2 rtl/asuka/asuka_top.sv:249 work RAM 32K word — ci vive lo stack della CPU — also in MAME: 32K taito/asuka.cpp:107 rtl/asuka/asuka_top.sv:251 sprite RAM 8K word — also in MAME: 8K taito/asuka.cpp:108 Notes where it differs from MAME — 3 rtl/asuka/tc_mame/tc0100scn_mame.sv:217 Chip MAME non finisce la scansione dentro hblank window (2652 clk a 96/24). rtl/asuka/z180/cadash_link_rom.sv:15 Perche' BRAM e non SDRAM, visto che il canale `sub_rom_` esisterebbe gia': se il canale seriale sbaglia anche un solo byte, il gioco scrive a video COMMUNICATION CHECKSUM ERROR e BLOCCA il 68000 con ori #$700,sr e un loop infinito. README.md:127 That is not a bug, it was confirmed on a genuine PCB, and MAME does not reproduce it. Cites MAME source — 145 Template.sv:338 Le due famiglie del driver asuka.cpp hanno disposizioni COMPLETAMENTE diverse: sbagliarle non sposta solo un tasto. Template.sv:341 Misurato su MAME 0.286 con le porte a riposo: Template.sv:376 Disposizione dei bit dalle ioport di MAME (asuka.cpp:1106-1110): PA "800007": 5=START2 6=START1 7=SERVICE, attivi bassi PB "800009": 0=COIN1 1=COIN2, attivi ALTI e a impulso PC "80000B": 0=TILT 2=SU 3=GIU 4=SX 5=DX 6=TASTO1 7=TASTO2, att Template.sv:382 I coin sono l'unico punto delicato: in MAME hanno PORT_IMPULSE(1), cioe' valgono UN quadro e poi tornano a riposo anche se tieni premuto. Template.sv:448 Sceglie di quale set del driver asuka.cpp il core deve fare le veci. Template.sv:754 Hardcoded 16 MHz (Cadash MAME XTAL 32/2, asuka.cpp:1222). Template.sv:767 Sprite: sincroni come in MAME (default) o in ritardo come sulla scheda. Template.sv:868 1-bit OSD: 0=Polite (default), 1=MAME (100%) Template.sv:937 Video: quarzo 26.686 MHz (header di asuka.cpp, PCB), TC0100SCN → pixel clock = 26.686/4 = 6.6715 MHz, riga di 424 pixel = 15.735 kHz (riga NTSC), quadro di 262 righe = 60.06 Hz. Template.sv:940 Visibile 320x240 (MAME: set_size(320,256), visarea(0,319,16,255), 60 Hz). Template.sv:1015 MAME warning overlay: "DON'T BREAK YOUR WOOFER!" per ~3s su edge status[95] rtl/asuka/asuka_audio_top.sv:246 ROM bank register Cadash (mask 0x03 = 4 banchi, da YM2151 CT1/CT2) MAME asuka.cpp:1202 ymsnd.port_write_handler().set_membank(m_audiobank).mask(0x03) → quando jt51 emette CT1/CT2, bank = {ct2, ct1}. rtl/asuka/asuka_audio_top.sv:317 YM2151 a 0x9000-0x90FF (decode larga, MAME mappa solo 9000/9001). rtl/asuka/asuka_audio_top.sv:371 ADPCM-A: la scheda di Bonze NON monta la ROM del canale A (in MAME c'e' la sola regione ymsnd:adpcmb). rtl/asuka/asuka_audio_top.sv:437 PSG resta non panneggiato (in MAME va al subwoofer mono, qui lo sommo a entrambi i canali). rtl/asuka/asuka_audio_top.sv:463 osd_adpcmb e osd_psg restano inutilizzati: nessun set di asuka.cpp ha quei blocchi. rtl/asuka/asuka_audio_top.sv:478 In MAME lo YM2151 va sul bus a 0.25 e l'MSM a 0.5, cioe' l'ADPCM e' il doppio del FM; qui pero' il FM e' gia' a fondo scala, quindi raddoppiarlo significherebbe solo saturare. rtl/asuka/asuka_audio_top.sv:512 MAME msm_state (asuka.cpp), z80_map: $B000 w -> pos = (pos & 0x00FF) \| (data << 8) $C000 w -> reset_w(0): parte. rtl/asuka/asuka_maincpu_map.sv:24 MAME: cadash_state::main_map (asuka.cpp:638) rtl/asuka/asuka_maincpu_map.sv:43 Mappa di memoria del 68000 (MAME asuka.cpp): 0 = cadash_state::main_map (Cadash) 1 = msm_state::asuka_map (Asuka & Asuka, Galmedes, Earth Joker, Maze of Flott) Cambia dove stanno IOC, PCR, PC060HA, sprite RAM e sprite ctrl. rtl/asuka/asuka_maincpu_map.sv:144 --- Address decode --- Le due mappe, riga per riga (MAME asuka.cpp): cadash main_map asuka_map rtl/asuka/asuka_maincpu_map.sv:159 eto (base_state::eto_map, asuka.cpp:653): ROM 000000-0FFFFF TC0110PCR palette 100000-10000F work RAM 200000-203FFF (16K) rtl/asuka/asuka_maincpu_map.sv:169 a C04000-C0FFFF, sopra la sprite RAM TC0100SCN ctrl D20000-D2000F bonze (bonzeadv_state::main_map, asuka.cpp:597): ROM 000000-03FFFF e 080000-0FFFFF (il buco in mezzo non e' decodificato, come su asuka) TC0110PCR pale rtl/asuka/asuka_maincpu_map.sv:211 Su eto l'IOC risponde anche a 400000-40000F, ma in sola LETTURA: e' il mirror che il gioco usa per il service mode (asuka.cpp:657). rtl/asuka/asuka_maincpu_map.sv:217 La parola vale 00xx come in MAME, dove la porta e' a 8 bit e i bit alti restano a 0. rtl/asuka/asuka_maincpu_map.sv:358 --- CPUA ctrl --- MAME cpua_ctrl_w: if only high byte is written (UDS only), shift high→low so bit 0 of the low byte is correctly set. rtl/asuka/asuka_maincpu_map.sv:367 MAME-style high-byte-only normalization rtl/asuka/asuka_maincpu_map.sv:377 --- TC0140SYT sound comm (real, no stub) --- MAME: $220001=master_port_w, $220003=master_comm_r/w Pilotiamo cs/wr/rd/a1 al TC0140SYT vero in audio_top. rtl/asuka/asuka_sprite_renderer.sv:27 Sprite RAM format (MAME, 4 words per entry at $E00100): Darius 2 sprite format (ninjaw.cpp): word[0]: X position → sx = (data - 32) & 0x3FF word[1]: Y position → sy = data & 0x1FF word[2]: tile code[14:0] (0 = skip) word[3]: flipX[0], flipY rtl/asuka/asuka_sprite_renderer.sv:45 0 = MAME : fotografia al filo `snap` del top, lo stesso clock in cui parte l'IRQ di vblank e il chip dei tile ferma scroll e tabelle -> niente scivolamento. rtl/asuka/asuka_sprite_renderer.sv:51 Impulso di un clock dal top: in modo MAME fa partire la copia. rtl/asuka/asuka_sprite_renderer.sv:53 1 = il PC090OJ di questa scheda ha il buffer (MAME set_usebuffer(true): config cadash e asuka). rtl/asuka/asuka_sprite_renderer.sv:54 MAME disegna il quadro N con lo scroll di N e gli sprite copiati al vblank N-1: il renderer legge la copia del vblank precedente, la cascata di Raiden (raiden_sprite_mainbus.sv). rtl/asuka/asuka_sprite_renderer.sv:65 X offset (scroll-dependent, from MAME draw_sprites x_offs parameter) rtl/asuka/asuka_sprite_renderer.sv:95 PC090OJ sprite_colbank ($080000 write, MAME asuka.cpp:475): sprite_colbank = (sprite_ctrl & 0x3C) << 2 = top 4 bit di color 8-bit rtl/asuka/asuka_sprite_renderer.sv:99 Non e' il registro del TC0100SCN: il PC090OJ ha il suo, la parola 0xdff della sprite RAM, ed e' attivo quando il bit 0 vale ZERO (pc090oj.cpp:199). rtl/asuka/asuka_sprite_renderer.sv:126 y_offs = -8 from MAME + north adjust rtl/asuka/asuka_sprite_renderer.sv:141 frozen = fotografia di questo filo (scritta dalla copia) frozen2 = quello che legge SEMPRE il renderer: buffer acceso (MAME) -> il vecchio contenuto di frozen, cioe' la fotografia del filo precedente (cascata); altrimenti -> lo s rtl/asuka/asuka_sprite_renderer.sv:340 Priority mask MAME bit3 attr "unknown priority": pixel scritto da sprite con attr[3]=1 → prio_lb=1, vince anche su pixel gia' scritti da sprite con attr[3]=0. rtl/asuka/asuka_sprite_renderer.sv:438 scn_sc[T+2] = pixel render_x[T] = render_x[T+2] - 2 (chip MAME stessa pipeline). rtl/asuka/asuka_sprite_renderer.sv:461 Layout identico a TC0100SCN tile decoder (MAME gfx_8x8x4_packed_msb su half-row 4 byte). rtl/asuka/asuka_sprite_renderer.sv:520 I numeri: dritto y = grezzo + 8 - 16 + yoff = grezzo - 8 + yoff capovolto y = (256 - grezzo - 16 + 2) + 8 - 16 - yoff = 234 - grezzo - yoff dove il 256-16 e' pc090oj.cpp, il +2 e' la riga che si sta preparando (una avanti), e yoff cam rtl/asuka/asuka_sprite_renderer.sv:675 Cadash PC090OJ (pc090oj.cpp:193-208): y = m_ram_buffered[offs+1] & 0x1FF if (y > 0x140) y -= 0x200 // signed convert y += m_y_offset (=8 per Cadash, set_offsets(0,8)) cliprect.top = 16 (asuka.cpp:1248 visarea Y=16..255) → MAME render_y sc rtl/asuka/asuka_sprite_renderer.sv:687 [FLIP] pc090oj.cpp:201-204: capovolto, y = 256 - y - 16, prima degli offset del chip. rtl/asuka/asuka_sprite_renderer.sv:714 Cadash PC090OJ (pc090oj.cpp:192-207): x = m_ram_buffered[offs+3] & 0x1FF if (x > 0x140) x -= 0x200 // signed convert x += m_x_offset (=0 per Cadash) rtl/asuka/asuka_sprite_renderer.sv:721 [FLIP] pc090oj.cpp:201-204: capovolto, x = 320 - x - 16. rtl/asuka/asuka_sprite_renderer.sv:740 [FLIP] pc090oj.cpp:203-204: capovolto lo schermo, i flip del singolo sprite si rovesciano. rtl/asuka/asuka_sprite_renderer.sv:746 MAME color = (attr & 0x0F) \| sprite_colbank sprite_colbank = (ctrl & 0x3C) << 2 = bits[7:4] del color 8-bit fifo_color e' 7-bit → uso colbank[6:4] hi + attr[3:0] lo rtl/asuka/asuka_sprite_renderer.sv:770 [FLIP] pc090oj.cpp:203-204: capovolto lo schermo, i flip del singolo sprite si rovesciano. rtl/asuka/asuka_sprite_renderer.sv:776 MAME color = (attr & 0x0F) \| sprite_colbank sprite_colbank = (ctrl & 0x3C) << 2 = bits[7:4] del color 8-bit fifo_color e' 7-bit → uso colbank[6:4] hi + attr[3:0] lo rtl/asuka/asuka_sprite_renderer.sv:830 Lancia req ROM direttamente in RD_POP (mask 14-bit MAME drawgfx) rtl/asuka/asuka_sprite_renderer.sv:994 Cadash xBGR444 → RGB888 (MAME color_xbgr444 asuka.cpp:484) R = data[3:0], G = data[7:4], B = data[11:8] rtl/asuka/asuka_sprite_renderer.sv:1005 sprite_ob combinatorio da spr_disp_word (già registrato 1 clk da line buffer), allineato a scn_sc (anche registrato 1 clk dal chip MAME). rtl/asuka/asuka_top.sv:78 MAME SYSTEM port: {00,start2,start1,tilt,service,coin2,coin1} rtl/asuka/asuka_top.sv:80 Ingressi del C-Chip (solo Bonze): le tre porte GPIO del uPD78C11 piu' le linee AN, gia' composte in Template.sv come le vuole MAME. rtl/asuka/asuka_top.sv:86 0 = MAME (scroll fermato a ogni quadro), 1 = scheda vera (scroll dal vivo). rtl/asuka/asuka_top.sv:105 SCN rate selector rimosso — SCN ora usa ce_13m fisso (13.33 MHz, MAME-accurate). rtl/asuka/asuka_top.sv:359 Da QUESTO filo, e da nessun'altra formula, escono: - l'IRQ di vblank (gen_vblank_irq qui sotto); - in modo MAME: il fermo degli otto registri del TC0100SCN, la copia delle tabelle di rowscroll/colscroll, il fermo del registro sprite; - in m rtl/asuka/asuka_top.sv:364 E' Raiden (IRQ, copia sprite e latch dello scroll sullo stesso vblank_rising) ed e' MAME, che al vblank disegna tutto il quadro in un istante PRIMA che la CPU prenda l'IRQ. rtl/asuka/asuka_top.sv:396 In modo MAME anche questo registro (banco colore, priorita') e' fermo al filo: MAME lo legge nell'istante in cui disegna. rtl/asuka/asuka_top.sv:402 [FLIP] Il PC090OJ ha un SECONDO registro, che non sta sul bus ma dentro la sprite RAM: la parola 0xdff (pc090oj.cpp:154, "Bit 0 is flip control"). rtl/asuka/asuka_top.sv:405 Il bit e' attivo BASSO: sprite capovolti quando vale zero (pc090oj.cpp:199). rtl/asuka/asuka_top.sv:406 All'accensione MAME parte da zero e il gioco lo scrive subito, e qui si fa uguale per non inventare uno stato che sul chip non c'e'. rtl/asuka/asuka_top.sv:415 Fermo al filo come tutto il resto in modo MAME: il capovolgimento non puo' cambiare a meta' quadro mentre lo sfondo sta gia' disegnando col suo. rtl/asuka/asuka_top.sv:420 sprite_colbank = (sprite_ctrl & 0x3C) << 2 (MAME fixed_colpri_cb asuka.cpp:475) rtl/asuka/asuka_top.sv:496 --- VBlank IRQ4 + IRQ5 timer (Cadash: MAME asuka.cpp:522-532) --- IRQ4 = immediato a rising-edge VBlank. rtl/asuka/asuka_top.sv:502 Tabella dei set del driver (MAME asuka.cpp). rtl/asuka/asuka_top.sv:538 PC090OJ con buffer (MAME set_usebuffer(true)): config 'cadash' (asuka.cpp:1255) e config 'asuka' (asuka.cpp:1186), cioe' Cadash, Asuka, Galmedes, Earth Joker. rtl/asuka/asuka_top.sv:586 Sul 68000 il riconoscimento spegne solo la linea servita: l'altra resta pendente e viene presa dopo (MAME fa lo stesso con HOLD_LINE). rtl/asuka/asuka_top.sv:697 Main CPU clock divider (96MHz / den) clk_sel = 0 e' AUTOMATICO PER GIOCO: nel driver il 68000 non gira alla stessa velocita' su tutte le schede (MAME asuka.cpp). rtl/asuka/asuka_top.sv:700 Cadash XTAL 32 MHz / 2 = 16 MHz (asuka.cpp:1222) rtl/asuka/asuka_top.sv:701 tutte le altre XTAL 16 MHz / 2 = 8 MHz (asuka.cpp:1156) rtl/asuka/asuka_top.sv:765 Il 68000 lo vede a 800000-800FFF, un byte ogni parola (MAME: umask 0x00ff), quindi l'indirizzo del chip e' main_bus_addr[11:1]. rtl/asuka/asuka_top.sv:922 --- TC0220IOC (Cadash, asuka.cpp:647 — 8 byte direct address) --- rtl/asuka/asuka_top.sv:967 Il 68000 la vede dalla Port A a $800000-$800FFF, un byte per word (byte nella meta' bassa: MAME fa `m_shared_ram[offset] = data & 0xff`), quindi allo Z180 basta la corsia LO. rtl/asuka/asuka_top.sv:1038 PHI dello Z180 = 8 MHz (MAME: HD64180RP clock=8000000). rtl/asuka/asuka_top.sv:1499 --- CPU → TC0100SCN chip selects --- MAME cadash_state::main_map (asuka.cpp:638): $C00000-$C0FFFF → SCN RAM $C20000-$C2000F → SCN ctrl rtl/asuka/asuka_top.sv:1514 PC060HA sound comm (Cadash, asuka.cpp:643): $0C0001 = master_port_w $0C0003 = master_comm_r/w Già gestito da pc060ha_link a $C00000-$C00003 (vecchio Darius2 path C00000), ma su Cadash è $0C0000-$0C0003. rtl/asuka/asuka_top.sv:1642 MAME TC0100SCN wide mode: 0x00000-0x0FFFF = SCE0 (64KB = 32K word), 0x10000-0x13FFF = SCE1 (16KB = 8K word). rtl/asuka/asuka_top.sv:1751 Port B fetch: il chip MAME emette vram_b_addr[15:0] (bit 15 = main/ext). rtl/asuka/asuka_top.sv:1803 TC0100SCN bindings (chip MAME guida dout/dack/SC/rom; legacy wire tied-off) rtl/asuka/asuka_top.sv:1809 CPU path: redirigi dout/dack dal chip MAME rtl/asuka/asuka_top.sv:1820 Port B VRAM legacy tied-off (chip MAME guida via scn_m0_vram_b_addr) rtl/asuka/asuka_top.sv:1841 MAME-model TC0100SCN instances (3×) — PARALLEL with Donlon for now. rtl/asuka/asuka_top.sv:1843 In Step 3 Donlon will be disconnected and MAME will drive SC, rom_req, etc. rtl/asuka/asuka_top.sv:1854 MAME chip signals (single chip) rtl/asuka/asuka_top.sv:1920 Palette chip selects (from MAME darius2_master_map) TC0110PCR: $A00000-$A0000F su Cadash, $200000-$20000F su asuka_map rtl/asuka/asuka_top.sv:2019 Priorita' sprite/tile: nel driver e' GLOBALE, decisa una volta per frame dal callback che riceve sprite_ctrl (MAME asuka.cpp:467-477), non per sprite. rtl/asuka/asuka_top.sv:2078 Il TC0110PCR e' lo stesso, ma il driver lo legge in due modi diversi (MAME asuka.cpp:479-487): rtl/asuka/asuka_top.sv:2084 L'espansione a 8 bit replica i bit alti (4'hF -> 8'hFF, 5'h1F -> 8'hFF), che e' quello che fanno pal4bit/pal5bit di MAME. rtl/asuka/asuka_top.sv:2234 Gli sprite uscivano un pixel piu' a destra di MAME (visto su Bonze Adventure). rtl/asuka/mame_warning_overlay.sv:22 mame_warning_overlay.sv — testo statico "DON'T BREAK YOUR WOOFER!" che appare per ~3 secondi quando l'utente attiva PSG=MAME nell'OSD audio mixer. rtl/asuka/msm5205.sv:8 Fedele a MAME src/devices/sound/msm5205.cpp: rtl/asuka/msm5205.sv:62 --- ampiezza del passo, a troncamenti separati come MAME ----------------- rtl/asuka/pc060ha_link.sv:25 Single-clock rewrite ispirato a jtrastan_pc060 (JTCORES by Jose Tejada), implementato secondo la descrizione di pc060ha_device in MAME. rtl/asuka/tc0040ioc.sv:14 In MAME è un singolo chip con un solo m_port register. rtl/asuka/tc0110pr.sv:110 MAME chip behaviour: cpu_mode only closes on explicit VA=10. rtl/asuka/tc0110pr.sv:132 Priority MAME ninjaw (draw_sprites + primask): sprite prio 0 (OB[13]=0): sotto FG, sopra tutto il resto sprite prio 1 (OB[13]=1): sotto FG, sotto MID layer, sopra BOTTOM SC[14:13] dal chip MAME tc0100scn codifica il RUOLO del layer visibile rtl/asuka/tc0110pr.sv:154 layer BG "top" → MAME mid rtl/asuka/tc0140syt.sv:112 MAME ninjaw usa NMI per svegliare Z80 al ricevimento comando audio. rtl/asuka/tc0220ioc.sv:10 MAME (taitoio.cpp:14-29): $00 R IN00-07 (DSWA) $00 W watchdog reset $01 R IN08-15 (DSWB) $02 R 1P inputs $02 W init / unknown $03 R 2P inputs $04 RW coin counters/lockout $05 W unknown $06 W unknown $07 R coin inputs rtl/asuka/tc_mame/tc0100scn_cadash.sv:1 tc0100scn_cadash.sv — TC0100SCN Cadash dedicated, MAME-faithful. rtl/asuka/tc_mame/tc0100scn_cadash.sv:3 Reference: MAME tc0100scn.cpp (Nicola Salmoria) + asuka.cpp (Cadash setup). rtl/asuka/tc_mame/tc0100scn_cadash.sv:5 Cadash hardware: - Single-width tilemaps (no dual width) - 8x8x4 packed_msb BG tiles from external ROM - 2bpp FG text chars from internal VRAM word $3000-$37FF - VRAM layout (single): $0000-$1FFF BG0 tilemap (64×64 tile, 2 word/tile: attr+c rtl/asuka/tc_mame/tc0100scn_cadash.sv:22 MAME tile_info (tc0100scn.cpp:400-401): code = m_ram[(2tile_index) + 1 + Offset] ← word DISPARI attr = m_ram[(2tile_index) + Offset] ← word PARI rtl/asuka/tc_mame/tc0100scn_cadash.sv:79 Fotografia del quadro (modo MAME). rtl/asuka/tc_mame/tc0100scn_cadash.sv:88 1 = MAME (fotografia), 0 = PCB (vivo) rtl/asuka/tc_mame/tc0100scn_cadash.sv:141 MAME: Cadash fa set_offsets(1, 0) (asuka.cpp:1260); la famiglia asuka (Asuka & Asuka, Galmedes, Earth Joker, Maze of Flott) lascia il default (0, 0). rtl/asuka/tc_mame/tc0100scn_cadash.sv:146 asuka.cpp:1248 visarea(0,319,16,255) rtl/asuka/tc_mame/tc0100scn_cadash.sv:149 MAME tc0100scn.cpp:273-274: set_scrolldx(xd-16, ...), set_scrolldy(yd, ...) m_dx = xd-16 = -17. rtl/asuka/tc_mame/tc0100scn_cadash.sv:155 VRAM bases (single-width, MAME tc0100scn.cpp:249-256, 442-444, 306) rtl/asuka/tc_mame/tc0100scn_cadash.sv:165 Control registers (8 word, $C20000-$C2000F) MAME tc0100scn.cpp:454-472 (restore_scroll): ctrl[0] = BG0 scrollx, ctrl[1] = BG1 scrollx, ctrl[2] = FG0 scrollx ctrl[3] = BG0 scrolly, ctrl[4] = BG1 scrolly, ctrl[5] = FG0 scrolly ctrl[6] = layer rtl/asuka/tc_mame/tc0100scn_cadash.sv:174 Fermo degli otto registri al clock di snap (solo modo MAME). rtl/asuka/tc_mame/tc0100scn_cadash.sv:327 [FLIP] Schermo capovolto (ctrl[7] bit 0, tc0100scn.cpp:466). rtl/asuka/tc_mame/tc0100scn_cadash.sv:412 Richiesta di fotografia delle tabelle: si alza al clock di snap (modo MAME), si abbassa quando la macchina entra nella copia. rtl/asuka/tc_mame/tc0100scn_cadash.sv:460 MAME tilemap library standard (BG0): set_scrollx((j + bgscrolly) & 0x1ff, ...). rtl/asuka/tc_mame/tc0100scn_cadash.sv:554 MAME BG1 path = tilemap_draw_fg custom, rowscroll j = (y_abs + scrolly_delta) & 0x1ff = (render_y + cliprect.top - m_dy) = render_y + 16 - 8 = render_y + 8 = render_y + SCROLLDY. rtl/asuka/tc_mame/tc0100scn_cadash.sv:566 MAME tc0100scn.cpp:639-649: src_y_initial = fgscrolly + scrolly_delta + cliprect.top, scrolly_delta = -m_dy. rtl/asuka/tc_mame/tc0100scn_cadash.sv:579 Col scroll per-tile (MAME tc0100scn.cpp:656) rtl/asuka/tc_mame/tc0100scn_cadash.sv:718 SC output from line buffers MAME tilemap_draw: bottom layer opaque, then top BG, then FG. rtl/asuka/tc_mame/tc0100scn_cadash.sv:766 MAME default (ctrl[6][3]=0): BG0 is bottom (bottomlayer=0), BG1 is top rtl/asuka/tc_mame/tc0100scn_mame.sv:22 tc0100scn_mame.sv — TC0100SCN, MAME-accurate scanline renderer. rtl/asuka/tc_mame/tc0100scn_mame.sv:24 Reference: MAME tc0100scn.cpp + ninjaw.cpp (Darius 2). rtl/asuka/tc_mame/tc0100scn_mame.sv:25 Scroll math, tile lookup, pixel decode follow MAME exactly. rtl/asuka/tc_mame/tc0100scn_mame.sv:33 MAME VRAM layout (wide mode, word offsets): $0000-$3FFF BG0 attrib+code (128×64 tiles, 2 words/tile) $4000-$7FFF BG1 attrib+code (128×64 tiles, 2 words/tile) $8000-$81FF BG0 row scroll (256 words) $8200-$83FF BG1 row scroll (256 words) rtl/asuka/tc_mame/tc0100scn_mame.sv:53 0 = primo chip, 1 = chip successivi (flag MAME) rtl/asuka/tc_mame/tc0100scn_mame.sv:121 Cadash (asuka.cpp). rtl/asuka/tc_mame/tc0100scn_mame.sv:121 Formula MAME (tc0100scn.cpp:285-286): xd = -m_x_offset - m_multiscrn_xoffs; → Cadash: x_offset=1 → xd=-1 yd = 8 - m_y_offset; → Cadash: y_offset=0 → yd=8 MAME visarea Cadash (asuka.cpp:1248): visarea(0,319,16,255) clipre rtl/asuka/tc_mame/tc0100scn_mame.sv:136 Cadash sempre single-width (asuka.cpp non chiama set_dblwidth, m_dblwidth=0). rtl/asuka/tc_mame/tc0100scn_mame.sv:145 VRAM bases CADASH SINGLE-WIDTH (MAME tc0100scn.cpp:31-41). rtl/asuka/tc_mame/tc0100scn_mame.sv:146 Layout word offset (m_ram[] u16 array): $0000-$1FFF BG0 (64×64 tile, 2 word/tile = 8K word) $2000-$3FFF FG0 tilemap (64×64, 1 word/tile) $3000-$3FFF FG0 gfx (256 char × 8 row × 2 plane = 4K word) [overlap mapping MAME] $4000-$5FFF BG1 ( rtl/asuka/tc_mame/tc0100scn_mame.sv:358 BUG3 fix: Row scroll index MAME (tc0100scn.cpp:623). rtl/asuka/tc_mame/tc0100scn_mame.sv:359 MAME mappa j-esimo rowscroll_ram a tilemap row (j + bgscrolly). rtl/asuka/tc_mame/tc0100scn_mame.sv:409 MAME lo fa internamente nel gfx_element (drawgfx code % elements()). rtl/asuka/tc_mame/tc0100scn_mame.sv:439 BUG3 fix: BG1 rowscroll index = (rline - SCROLLDY) & 0x1ff (MAME). rtl/asuka/tc_mame/tc0100scn_mame.sv:457 Col scroll per-tile (MAME tc0100scn.cpp:656): column_offset = colscroll_ram[src_x/8]; src_y_tile = line_sy - column_offset. rtl/asuka/z180/cadash_link_z180.sv:18 Mappa dello Z180 (MAME asuka.cpp, cadash_state::sub_map): rtl/asuka/z180/cadash_link_z180.sv:23 La RAM condivisa vista dai due lati (MAME asuka.cpp:709-723): $8000 'M' (0x4D) = questa scheda e' MASTER, altro = SLAVE $8002 'T' se sta trasmettendo, 'R' se sta ricevendo $8080-$80FF dati SLAVE (= $800100 lato 68000) $8100-$817F dati rtl/asuka/z180/cadash_link_z180.sv:29 Il 68000 la vede a $800000-$800FFF, un byte per word (per questo MAME fa `data & 0xff`): word N del 68000 <-> byte N dello Z180. README.md:3 FPGA core for the Taito hardware behind Asuka & Asuka* — the family MAME collects in `asuka.cpp` — targeting the [MiSTer FPGA](https://github.com/MiSTer-deve README.md:16 The core reimplements the hardware in SystemVerilog from the MAME driver, read line by line — every non-obvious fact in the RTL carries its `asuka.cpp:<line>` c README.md:122 Volume controls for FM and ADPCM, and a MAME-compatible PSG mode. README.md:134 At the vblank MAME draws the whole frame in one instant, before the 68000 enters the interrupt handler. README.md:266 David Graves and Brian Troha, authors of MAME's `asuka.cpp`, with thanks to Richard Bush, and the MAMEDev team — memory maps, raster timing, gra README.md:270 Jonathan Gevaryahu and David Haywood for MAME's C-Chip device, the reference the chip's behaviour was checked against. Says it matches, follows or was checked against MAME — 3 Template.sv:348 Provato: forzando FF sull'IN2 di MAME si riproduce esatto lo schermo nero e muto, col programma che resta in $14xx come sulla MiSTer. rtl/asuka/asuka_sprite_renderer.sv:467 Formula uguale al chip tile MAME: lat_gfx32 con byte-pair swap, base con bit scramble. rtl/asuka/sdram_bridge.sv:266 Word-swap concat (SIM-verified MAME-compliant). Shares text with the MAME driver without saying so — 9 rtl/asuka/asuka_audio_top.sv:247 MAME asuka.cpp:1202 ymsnd.port_write_handler().set_membank(m_audiobank).mask(0x03) — shares text with taito/asuka.cpp:1202 rtl/asuka/asuka_sprite_renderer.sv:96 sprite_colbank = (sprite_ctrl & 0x3C) << 2 = top 4 bit di color 8-bit — shares text with taito/asuka.cpp:469 rtl/asuka/asuka_sprite_renderer.sv:676 y = m_ram_buffered[offs+1] & 0x1FF — shares text with taito/pc090oj.cpp:193 rtl/asuka/asuka_sprite_renderer.sv:715 x = m_ram_buffered[offs+3] & 0x1FF — shares text with taito/pc090oj.cpp:192 rtl/asuka/asuka_top.sv:420 sprite_colbank = (sprite_ctrl & 0x3C) << 2 (MAME fixed_colpri_cb asuka.cpp:475) — shares text with taito/asuka.cpp:469 rtl/asuka/asuka_top.sv:969 `m_shared_ram[offset] = data & 0xff`), quindi allo Z180 basta la corsia LO. — shares text with taito/asuka.cpp:584 rtl/asuka/tc_mame/tc0100scn_cadash.sv:23 code = m_ram[(2tile_index) + 1 + Offset] ← word DISPARI — shares text with taito/tc0100scn.cpp:402 rtl/asuka/tc_mame/tc0100scn_cadash.sv:24 attr = m_ram[(2tile_index) + Offset] ← word PARI — shares text with taito/tc0100scn.cpp:403 rtl/asuka/tc_mame/tc0100scn_mame.sv:122 xd = -m_x_offset - m_multiscrn_xoffs; → Cadash: x_offset=1 → xd=-1 — shares text with taito/tc0100scn.cpp:287
TaitoF2# Cameltry, Dead Connection, Dino Rex, Don Doko Don … MiSTer-devel/Arcade-TaitoF2_MiSTer @ 664dbb74 MAME compared: taito/taito_f2.cpp + 19 related file(s) Read: 43 HDL files, 29,921 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	36%
Statements: 1 toward MAME Cites MAME source — 1 rtl/jt10_auto_ss.sv:8094 same values as in MAME
TaitoSJ# Adventure Canoe, Alpine Ski, Bio Attack, Elevator Action … MiSTer-devel/Arcade-TaitoSystemSJ_MiSTer @ 121cf1d5 MAME compared: taito/taitosj.cpp + 5 related file(s) Read: 15 HDL files, 4,162 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	57%
Statements: 22 toward hardware, 4 not counted Cites hardware documentation that MAME's driver does not — 22 rtl/TaitoSJCore.v:573 $8000-$87FF RAM rtl/TaitoSJ_objbus.v:97 C0=1: 74LS83 carry-in unconnected, floats HIGH on hardware + 1 rtl/TaitoSJ_objbus.v:125 Hardware: ~OBJRQ connects to ~MR (pin 1) of U83 74LS273, acting as asynchronous master reset. rtl/mcu_glue.v:12 Schematic blocks: (1) UMCU_7A, UMCU_7B — 74LS74 Handshake flip-flops (2) UMCU_9, UMCU_13 — 74LS374 Data latches (3) UMCU_10, UMCU_11B/D — 74LS374 + 74LS191 Address latch/counter (4) UMCU_18A — 74LS74 Interrupt gating fli rtl/mcu_glue.v:119 --- UMCU_15C (74LS00 NAND) → 74LS04 inverter = AND --- NAND(~RESET, ~ZLREAD) → NOT → ~CLR for UMCU_7A Equivalent: ~CLR_7A = ~RESET & ~ZLREAD rtl/mcu_glue.v:161 --- UMCU_9 (74LS374) — MCU→Z80 data latch --- Captures PA on rising edge of ~68LWR rtl/mcu_glue.v:169 --- UMCU_13 (74LS374) — Z80→MCU data latch --- Captures Z80 data bus on rising edge of ~ZLWRITE (end of write cycle) ~OE = ~68LRD (output enabled when MCU reads) rtl/mcu_glue.v:183 --- UMCU_10 (74LS374) — upper address latch A[15:8] --- Captures PA on rising edge of ~UAL (PB7) — latches on deassert rtl/mcu_glue.v:191 --- UMCU_21D (74LS08 AND) — counter clock --- CNT_CLK = ~68WRITE & ~68READ rtl/mcu_glue.v:195 --- UMCU_11B + UMCU_11D (74LS191 x2) — lower address counter A[7:0] --- ~PL = ~LAL (PB6), CLK = cnt_clk, D/~U = GND (count UP) rtl/mcu_glue.v:208 (4) ~MCPUINT Interrupt Gating Circuit (from schematic image) rtl/mcu_glue.v:210 Signal flow: UMCU_23A (OR): ~CPUM1 \| ~CPUIORQ UMCU_23D (OR): ~68INTAK(~Q of 18A) \| UMCU_23A_out UMCU_23B (OR): ~68INTRQ(PB2) \| Q_18A ← Q feeds back from 18A UMCU_21B (AND): UMCU_23B_out & UMCU_23D_out = ~68IVR (clock for 18A) rtl/mcu_glue.v:222 UMCU_23A (74LS32 OR): ~CPUM1 \| ~CPUIORQ rtl/mcu_glue.v:225 UMCU_23D (74LS32 OR): ~68INTAK(~Q of U18A) \| UMCU_23A_out rtl/mcu_glue.v:228 UMCU_23B (74LS32 OR): ~68INTRQ(PB2) \| Q_18A rtl/mcu_glue.v:231 UMCU_21B (74LS08 AND): ~68IVR = UMCU_23B_out & UMCU_23D_out rtl/mcu_glue.v:254 UMCU_17D (74LS241 non-inverting buffer) on ~CPUINT: ~CPUINT → buffer → AND input (no polarity change) In FPGA: cpuint_n IS ~CPUINT, buffer is just a wire rtl/mcu_glue.v:259 UMCU_21A (74LS08 AND): ~Q_18A (pin 6) & buffered ~CPUINT (pin 1) Output = ~MCPUINT rtl/mcu_glue.v:266 (5) Status Buffer — UMCU_20B (74LS367) rtl/mcu_glue.v:276 UMCU_16 (74LS245) rtl/ttl_chips.v:57 74LS107 Chip pinout: rtl/ttl_chips.v:102 74LS139 Chip pinout: Cites hardware references or measurements that MAME's driver also gives — 4 rtl/mcu_glue.v:124 --- UMCU_7A (74LS74) — MCU→Z80 data available --- D = VCC, CLK = ~68LWR rising, ~CLR = clr_7a_n, ~PRE = VCC Q7A: 1 = MCU has written data for Z80 — also in MAME: 74LS74 taito/taitosj.h:104 rtl/mcu_glue.v:135 --- UMCU_7B (74LS74) — Z80→MCU data available --- D = GND, CLK = ~68LRD rising, ~CLR = ~RESET, ~PRE = ~ZLWRITE Q7B: 1 = Z80 has written data for MCU ~Q7B: 68ACCEPT (0 = data pending, interrupts MCU) — also in MAME: 74LS74 taito/taitosj.h:104 rtl/mcu_glue.v:234 --- UMCU_18A (74LS74) — interrupt gating toggle flip-flop --- D = ~Q (pin 2 tied to pin 6 on PCB), CLK = ~68IVR rising, ~PRE = VCC, ~CLR = ~RESET This makes it a toggle: each ~68IVR rising edge flips the state. — also in MAME: 74LS74 taito/taitosj.h:104 rtl/ttl_chips.v:6 74LS74 Chip pinout: — also in MAME: 74LS74 taito/taitosj.h:104
Tank# Tank / Tank Cocktail MiSTer-devel/Arcade-Tank_MiSTer @ 01b88927 MAME compared: atari/atarittl.cpp + 6 related file(s) Read: 19 HDL files, 4,404 lines (Quartus project)	MiSTer official	Both	low	60%
Statements: 25 toward hardware, 25 toward MAME Cites hardware documentation that MAME's driver does not — 25 rtl/game/tank_collision_hw.sv:17 The schematic shows two separate 6-bit counters; the netlist ties SCR1E and SCR2C to one D11 pin and swaps E11's CP0 / CP1. rtl/game/tank_controls_hw.sv:105 (MAME's 7492 model swaps QB and QD on the pins, which makes its TM1 come in bursts of three; the 7492A datasheet and the schematic's pin labels give the even 1-in-6.) rtl/game/tank_motion.sv:22 MAME's netlist takes HD1 / HD2 from 7474 pin 5 (Q) where the schematic uses pin 6 (Q-bar). rtl/game/tank_shells.sv:11 IC_C9, the white tank's shell (netlist SHELL1): FIRE: the FIRE1_ADJUST 50k pot and C11 47 uF. rtl/game/tank_shells.sv:36 The netlist's SHELL1 (IC_C9) is the white tank, which is the core's tank 2, so the pot sets core shell 2 and core shell 1 (black) gets the fixed 1.0784 s. rtl/tank_core.sv:8 IC names (IC_xx) follow the Board I / II schematics and MAME's netlist (nl_tank.cpp). rtl/tank_core.sv:12 The netlist numbers them the other way round (its TANK1 is the white tank); the screen matches the cabinet. rtl/tank_core.sv:335 Where a shell appears (measured on the netlist): its 16 x 16 window starts at the tank's window + 1 clock, and the visible 4 x 4 shell is at columns 4-7, rows 8-11 of it. rtl/tank_core.sv:493 (MAME's 7492 model maps pin 8 to QC, the 7490 / 7493 layout; the 7492A datasheet and the schematic put QD on pin 8.) tank_controls_hw keeps a twin of this counter for TM1, the chip's other output; both count the same frame_pulse. rtl/tank_core.sv:554 The machine boots with ~2 s of both tanks flashing and firing locked out (measured in the full MAME netlist). rtl/tank_core.sv:610 MAME's netlist leaves this switch out (it is wired as 25c). rtl/tank_core.sv:656 (MAME's netlist leaves Q2.C and Q3.B unconnected, so GNE never asserts there.) rtl/tank_core.sv:805 Outputs (the white tank is the core's tank 2, the netlist's TANK1): B10 (R5V 1k, sources on white-tank pixel) = is_tank2 rtl/video/blast_object.sv:23 MAME's netlist differs for BLAST1: it wires K3.5 to K3.3 (the tank-shape XOR) instead of K2.3, so its player 1 explosion carries the tank shape. rtl/video/blast_object.sv:25 The core follows the schematic for both. rtl/video/playfield.sv:5 The 2 KB ROM (90-2006, MK28000 at K10, drawn as IC_R10 in the netlist) is read through five 74153 muxes (IC_D9/E9/J9/H9/F9). rtl/video/shell_object.sv:11 This module draws that block at (x, y); tank_video.sv puts the explosion window at (x - 4, y - 8) to match (checked on the netlist at 128 positions per player). README.md:8 It was built from the Board I / Board II schematics and the Kee Games operator and service manuals, with MAME's Tank netlist as a cross-check. README.md:10 Where the netlist and the schematics disagree, the core follows the schematics. README.md:96 The parts below follow the schematics: README.md:128 Where MAME's netlist differs README.md:130 MAME's Tank netlist was the cross-check throughout. README.md:130 Where it disagreed with the schematics, the core follows the schematics; examples are the score counter wiring, an output pin of the HD1 / HD2 flip-flops, and t README.md:144 Each part was checked by simulation against the schematics and against measurements of the corrected MAME netlist before it counted as done. README.md:153 \| Analogue timings and levels \| Measured in `nltool` on the corrected netlist with MAME's device models; datasheet timing for the DM9602 \| Cites MAME source — 25 Arcade-Tank.sv:188 Only the first 2 KB are written: MAME's tankii set is the same image plus one trailing 0xFF byte, which would wrap onto ROM[0]. rtl/game/tank_collision_hw.sv:4 The board's collision network (nl_tank.cpp gate names), on clk_pix with synchronous strobes in place of the board's gated and asynchronous latch clocks: rtl/game/tank_controls_hw.sv:4 The board's control chain per tank: lever decode (IC_E15 / D15 NOR gates), rotation counter (74193 + 74107), speed counter (7493) and step divider (9316), with the gate equations of nl_tank.cpp. rtl/game/tank_controls_hw.sv:105 (MAME's 7492 model swaps QB and QD on the pins, which makes its TM1 come in bursts of three; the 7492A datasheet and the schematic's pin labels give the even 1-in-6.) rtl/game/tank_controls_hw.sv:158 tank_ctrl_chain_hw - one tank's rotation, speed and step divider, on clk_pix with frame_pulse / tm1 enables (gate names from nl_tank.cpp). rtl/game/tank_motion.sv:22 MAME's netlist takes HD1 / HD2 from 7474 pin 5 (Q) where the schematic uses pin 6 (Q-bar). rtl/game/tank_shells.sv:6 Pulse widths use the DM9602 datasheet equation Tw = 0.32 * R * C * (1 + 0.7 / R[kOhm]) (MAME's 9602 model uses the 74123's constant instead, which gives different widths.) rtl/tank_core.sv:8 IC names (IC_xx) follow the Board I / II schematics and MAME's netlist (nl_tank.cpp). rtl/tank_core.sv:295 The fire-arm clear is the other tank's BLO_UP (nl_tank.cpp): shell 1: CLR = NOR(BLO_UP2, SRS1) (IC_N7 -> IC_A15.1) shell 2: CLR = NOR(BLO_UP1, SRS2) (IC_N7 -> IC_A15.13) A tank CAN fire while it is itself exploding: its own BLO_UP has n rtl/tank_core.sv:493 (MAME's 7492 model maps pin 8 to QC, the 7490 / 7493 layout; the 7492A datasheet and the schematic put QD on pin 8.) tank_controls_hw keeps a twin of this counter for TM1, the chip's other output; both count the same frame_pulse. rtl/tank_core.sv:515 Each half is a monostable with TRIGGER and RESET both on the hit signal HTQ = NOR(HIT, MTK), and 1.8M / 1uF timing: Tw = RCln(3) = 1.9775 s (measured on MAME's NE555 model) = 120 fields at 60.797 Hz. rtl/tank_core.sv:554 The machine boots with ~2 s of both tanks flashing and firing locked out (measured in the full MAME netlist). rtl/tank_core.sv:596 GAME TIMER AND COINS (IC_H6 555 timer, IC_E6 74107, coin gates IC_B6 / D6 / J6 / N6), measured in nltool on MAME's device models. rtl/tank_core.sv:610 MAME's netlist leaves this switch out (it is wired as 25c). rtl/tank_core.sv:656 (MAME's netlist leaves Q2.C and Q3.B unconnected, so GNE never asserts there.) rtl/tank_core.sv:788 Levels measured in nltool with MAME's gate and 1N914 models, in volts: rtl/video/blast_object.sv:23 MAME's netlist differs for BLAST1: it wires K3.5 to K3.3 (the tank-shape XOR) instead of K2.3, so its player 1 explosion carries the tank shape. README.md:8 It was built from the Board I / Board II schematics and the Kee Games operator and service manuals, with MAME's Tank netlist as a cross-check. README.md:128 Where MAME's netlist differs README.md:130 MAME's Tank netlist was the cross-check throughout. README.md:130 Where it disagreed with the schematics, the core follows the schematics; examples are the score counter wiring, an output pin of the HD1 / HD2 flip-flops, and t README.md:134 Most circuit timings that depend on analogue parts were measured in MAME's netlist simulator, `nltool`, with the corrected netlist; the DM9602 one-shots that ti README.md:144 Each part was checked by simulation against the schematics and against measurements of the corrected MAME netlist before it counted as done. README.md:153 \| Analogue timings and levels \| Measured in `nltool` on the corrected netlist with MAME's device models; datasheet timing for the DM9602 \| README.md:219 The MAME team*: the Tank netlist (`nl_tank.cpp`) and the `netlist` library and `nltool` simulator, the cross-check for the whole core.
TankBattalion# Tank Battalion MiSTer-devel/Arcade-TankBattalion_MiSTer @ 6b84ddca (matched by date) MAME compared: namco/tankbatt.cpp + 2 related file(s) Read: 10 HDL files, 3,521 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	18%
Statements: 6 toward hardware, 1 not counted Cites hardware documentation that MAME's driver does not — 6 rtl/ttl_chips.v:1 74LS74 Chip pinout: rtl/ttl_chips.v:52 74LS107 Chip pinout: rtl/ttl_chips.v:141 74LS273 Chip pinout: rtl/ttl_chips.v:183 74LS166 Chip pinout: rtl/ttl_chips.v:225 74LS174 Chip pinout: rtl/ttl_chips.v:263 74LS139 Chip pinout: Cites hardware references or measurements that MAME's driver also gives — 1 rtl/ttl_chips.v:92 74LS161 Chip pinout: — also in MAME: 74LS161 namco/tankbatt.cpp:363
Tecmo# Back Fire, Gemini Wing, Argus no Senshi, Silk Worm MiSTer-devel/Arcade-Tecmo_MiSTer @ 9b62284b MAME compared: tecmo/tecmo.cpp Read: 30 HDL files, 6,442 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	20%
Statements: 1 toward hardware Ships hardware documentation files — 1 doc/rygar-schematic.pdf
Tempest# Tempest MiSTer-devel/Arcade-Tempest_MiSTer @ bcd5bf4d MAME compared: atari/tempest.cpp + 2 related file(s) Read: 38 HDL files, 16,447 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	5%
Statements: 13 toward hardware, 2 not counted Cites hardware documentation that MAME's driver does not — 13 rtl/avg/avg_prom_core.vhd:106 On hardware, this is latched by the LS175 (6L, schematic p.25 Fig.1) from DVY10-DVY8, and drives the LS191 down-counter that gates additional fill-bit shifts into the timer at STROBE 1. rtl/avg/avg_prom_core.vhd:115 GO flag (schematic p.24 Fig.3: 2E LS32 pin 8). rtl/avg/avg_prom_core.vhd:137 Bin_scale shift mechanism at STROBE 1 (schematic p.25 Fig.1: Vector Scaling). rtl/avg/avg_prom_core.vhd:261 /LATCH1 clears three chip groups (schematic p.23): 5F,5H (Fig.2): DVY0-7 async cleared to 0 5A,5B,5C (Fig.2): DVX0-11 async cleared to 0 3C (Fig.0): Z0-Z2 + DVX12 async cleared to 0 6H(DVY8-11) has /CLR=PR110 (not cleared here). rtl/avg/avg_prom_core.vhd:298 STROBE0 + OP0=0 sets NORM (LS74 5K, p.24 Fig.0). rtl/avg/avg_prom_core.vhd:309 STROBE 1 (action $D): SP adjust for JSR/RTS, or Vector Scaling (schematic p.25 Fig.1) for VCTR/SVEC. rtl/avg/avg_prom_core.vhd:339 Scale (0111_SSS LLLLLLLL) SSS = bin_scale -> LS175 latch (6L) -> LS191 counter (6M) LLLLLLLL = linear_scale -> LF13201 DAC (schematic p.26) rtl/avg/avg_prom_core.vhd:411 Schematic p.23 Fig.2: LS194 shift registers (3A-3D, 4A-4D) shift DVX/DVY left at 12 MHz, gated by ENORM. rtl/avg/avg_prom_core.vhd:413 Schematic p.25 Fig.0: LS161 timer chain (1D/1C/1B/2B) shifts right simultaneously, filling from the top. rtl/avg/avg_prom_core.vhd:454 Schematic p.25 Fig.1: Vector Scaling circuit. rtl/avg/vector_drawer.vhd:54 Linear scale velocity multiplier (schematic p.26: LF13201 multiplying DAC). rtl/tempest_mathbox.sv:6 Implements the microcoded processor shown on Tempest schematic Sheet 3B. README.md:9 This core reconstructs the original machine from Atari's schematics. Cites hardware references or measurements that MAME's driver also gives — 2 rtl/avg/avg_prom_core.vhd:62 Hardware: 136002-125 at D7. — also in MAME: 136002-125 atari/tempest.cpp:713 rtl/avg/avg_prom_core.vhd:111 PROM state machine signals (256x4 PROM 136002-125 at D7) — also in MAME: 136002-125 atari/tempest.cpp:713
TIAMC1# Billiard, Gorodki, Konek-Gorbunok, Snezhnaja Koroleva … MiSTer-devel/Arcade-TIAMC1_MiSTer @ 7d29fffd MAME compared: ussr/tiamc1.cpp + 4 related file(s) Read: 12 HDL files, 2,871 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	0%
Statements: 1 toward MAME Cites MAME source — 1 README.md:5 All information taken from [mame/tiamc1.cpp](https://github.com/mamedev/mame/blob/master/src/mame/drivers/tiamc1.cpp).
TimePilot# Time Pilot MiSTer-devel/Arcade-TimePilot_MiSTer @ 97033775 MAME compared: konami/timeplt.cpp + 1 related file(s) Read: 16 HDL files, 3,596 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	42%
Statements: 5 toward hardware Cites hardware documentation that MAME's driver does not — 5 rtl/TimePilot_CPU.sv:133 Address decoding for Z80 Most of the decoding is handled by the Konami 526 (82S153 PLA) - instantiate an instance of this IC here rtl/TimePilot_CPU.sv:332 Time Pilot has an additional 82S153 PLA labelled K528 that controls the vertical counter latch and is used to control the state of the Konami 082's vertical counter (active or high impedance as the vertical counter is directly connected to rtl/TimePilot_SND.sv:315 Time Pilot's AY-3-8910s contain selectable low-pass filters with the following cutoff frequencies: 3386.28Hz, 723.43Hz, 596.09Hz Model this here (the PCB handles this via 3 74HC4066 switching ICs located at A2, A3 and A4) rtl/custom/k526.sv:3 SystemVerilog implementation of the Konami 526, an 82S153 PLA used for address decoding on Time Pilot Converted from dump available at the PLD Archive http://wiki.pldarchive.co.uk/index.php?title=Time_Pilot Copyright (C) 2021 Ace rtl/custom/k528.sv:3 SystemVerilog implementation of the Konami 528, an 82S153 PLA used for controlling the vertical counter outputs on Time Pilot's Konami 082 Converted from dump available at the PLD Archive http://wiki.pldarchive.co.uk/index.php?title=Time_Pi
TimePilot84# Time Pilot '84 MiSTer-devel/Arcade-TimePilot84_MISTer @ 217aba83 MAME compared: konami/tp84.cpp + 1 related file(s) Read: 14 HDL files, 7,758 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	18%
Statements: 2 toward hardware Cites hardware documentation that MAME's driver does not — 2 rtl/TimePilot84_CPU.sv:198 Primary CPU ROMs (there is a 5th ROM socket on the original PCB at 6J, but is unpopulated) ROM 1/4 rtl/TimePilot84_SND.sv:287 Time Pilot '84's SN76489s contain selectable low-pass filters with the following cutoff frequencies: 3386.28Hz, 723.43Hz, 596.09Hz Model this here (the PCB handles this via a 74HC4066 switching IC located at C6)
TNKIII# T.A.N.K MiSTer-devel/Arcade-TNKIII_MiSTer @ bffd85ea MAME compared: snk/snk.cpp + 2 related file(s) Read: 80 HDL files, 9,424 lines (Quartus project)	MiSTer official	Mostly hardware	low	43%
Statements: 13 toward hardware, 2 toward MAME Cites hardware documentation that MAME's driver does not — 12 rtl/clocks/A5001_1.v:1 Author: @RndMnkIII Date: 13/03/2022 Converted from ArmoredScrumObject_pal16r6a_3.jed using MAME's jedutil tool Many thanks to pldarchive.co.uk for the JED file. rtl/clocks/TNKIIICore_Clocks_Sync.sv:199 74LS30 8-input positive NAND gate rtl/cpuA_B/A5001_2.v:1 Author: @RndMnkIII Date: 22/05/2022 Derived from TNKIII schematics and ASO PAL. rtl/final_video/A5001_3.v:1 A5001_3.v Author: @RndMnkIII Date: 23/05/2022 Derived from TNKIII schematics and ASO PAL. rtl/front/TNKIIICore_LineBuffer_sync.sv:156 74LS20 4-input NAND gate rtl/ttl/ttl_74107a_sync.v:1 74LS107A: Dual J-/K flip-flop with clear; negative-edge-triggered Inputs Outputs rtl/ttl/ttl_74163a_sync.v:1 4-bit modulo 16 binary counter with parallel load, * FOR SYNTHESIS * Synchronous Reset (SRn) -> LS163A <START_TEMPLATE> ttl_74161a #(.DELAY_RISE(20), .DELAY_FALL(25)) <NAME> (.Clear_bar(), .Load_bar(), .ENT(), .ENP(), .D(), .Clk(), .RCO rtl/ttl/ttl_74373.sv:1 ttl_74373.sv Octal D transparent latch function table, logic diagrams and switching characteristics extracted from TI 74LS373 Datasheet. rtl/ttl/ttl_74374_sync.sv:1 ttl_74374_sync.sv Octal D edge triggered FF function table, logic diagrams and switching characteristics extracted from TI 74LS374 Datasheet. rtl/ym3526/jtopl_exprom.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots. rtl/ym3526/jtopl_logsin.v:16 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots. rtl/ym3526/jtopl_op.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots. Ships hardware documentation files — 1 docs/TNKIII_schematics.pdf Cites MAME source — 2 rtl/clocks/A5001_1.v:1 Author: @RndMnkIII Date: 13/03/2022 Converted from ArmoredScrumObject_pal16r6a_3.jed using MAME's jedutil tool Many thanks to pldarchive.co.uk for the JED file. rtl/cpuA_B/TNKIIICore_CPU_A_B_sync.sv:521 ONLY WRITABLE VIDEO RELATED REGISTERS (TNKIII) 1 1 1 1 1 \| 1 \| Address: 5 4 3 2 1 \| 0 9 8 \| 7 6 5 4 3 2 1 0 16'hC800 1 1 0 0 1 \| 0 0 0 \| x x x x x x x x MSB 16'hC900 1 1 0 0 1 \| 0 0 1 \| x x x x x x x x FSX 16'hCA00
Toobin# Toobin' MiSTer-devel/Arcade-Toobin_MiSTer @ 0e9fe7b5 MAME compared: atari/toobin.cpp + 6 related file(s) Read: 33 HDL files, 4,254 lines (Quartus project)	MiSTer official	Both	medium	70%
Statements: 40 toward hardware, 49 toward MAME Cites hardware documentation that MAME's driver does not — 34 rtl/main/toobin_addr_decode.sv:17 Source: Atari SP-320 schematics (main CPU decode); MAME's toobin.cpp. rtl/main/toobin_eeprom_2804.sv:8 Board behavior (SP-320 sheet 3): /UNLOCK presets 14M (74LS74). rtl/main/toobin_inputs.sv:8 Toobin uses four independent paddle-direction pushbuttons per player plus a Throw Can button, which the game also uses as Start (SP-320 sheet 18 and the FF8800 switch word, all active-low): rtl/main/toobin_irq_wd.sv:13 Watchdog (SP-320 sheet 2, 8L LS90): /VSYNC clocks a decade counter. rtl/main/toobin_irq_wd.sv:17 Source: Atari SP-320 schematics; MAME's toobin.cpp; the System 1 core's TG68K IPL convention (rtl/lib/TG68K/TG68K.vhd). rtl/main/toobin_irq_wd.sv:53 74LS90 decade behavior: FF8000 clears to zero; /VSYNC advances 0..9. rtl/main/toobin_main_bus.sv:13 Source: Atari SP-320 schematics (main CPU decode). rtl/video/toobin_alpha_render.sv:9 SP-320 sheet 6 is the electrical authority: D11 drives ANHFLIP, D9:0 select one of the 1024 characters, and D10 reaches only the optional ANROMA14/VPP socket pin. rtl/video/toobin_mo_linebuf.sv:8 SP-320 sheet 13 selects the two physical line-buffer banks directly with 1V and /1V, so line_swap always changes banks; it is deliberately not completion-gated. rtl/video/toobin_mo_linebuf.sv:90 ---- unconditional 1V/inverse-1V bank parity (SP-320 sheet 13) ---- rtl/video/toobin_mo_list.sv:16 Word fields (schematic sheet 6 latch wiring + MAME atarimo config -- the link lives in w2, NOT w0; w0[7:0] is ypos-low/size bits): w0: abs[15], ypos[14:6], height[5:3], width[2:0] w1: vflip[15], hflip[14], code[13:0] w2: link[7:0] rtl/video/toobin_mo_list.sv:104 Link pointer comes from WORD 2 (schematic sheet 6: 17F link register is loaded from the C09804 word; MAME linkmask {{0,0,0x00ff,0}}). rtl/video/toobin_pf_render.sv:69 Sheet 14 clocks HSCROLL on the following scanline. rtl/video/toobin_priority.sv:6 This is the real PAL 7E equation, not a functional approximation. rtl/video/toobin_priority.sv:8 136061-1151 (PAL16L8A at 7E) was bruteforced by Caius and tested on a board by gamefixer; the JEDEC is on PLD Archive as `Toobin_136061-1151`, dated 07/10/2019. rtl/video/toobin_priority.sv:10 Decoded with MAME's jedutil as a gal16v8: simple mode, active-low outputs, only pins 13/14 driven. rtl/video/toobin_priority.sv:11 Those two pins are the shared SB/SA select rails of the five 74F153 muxes that build the colour-RAM address (pin14 -> F153 pin 2 = B/msb, pin13 -> F153 pin 14 = A/lsb), whose data inputs are C0=playfield, C1=motion object, C2=alpha, C3=CPU rtl/video/toobin_raster.sv:6 SP-320 sheets 5-6: 640x416 total, 512x384 visible, HSYNC 544-607, VSYNC 388-391. rtl/video/toobin_video.sv:134 SP-320 sheet 13 selects the two line-buffer banks directly from 1V//1V, and the displayed bank's chip select is gated only by 16MHZD and that parity -- there is no BLANK/active-display term, and R107-R114 pull the data bus to the transparen rtl/video/toobin_video.sv:138 (Corroborated by Atari SP-284's LINEBUF.vhd, whose address counter increments on every master clock with no active-display qualifier.) rtl/video/toobin_vscroll_ctrl.sv:6 SP-320 sheet 14 latches BD14:6 as VS8:0 and feeds two cascaded LS163 counters clocked by /HSYNC. README.md:7 The core reconstructs the original PCB — a 68010 main board plus an Atari JSA I sound board — from Atari's SP-320 schematic package, with MAME used as a functio README.md:169 It applies where the SP-320 schematics document something MAME's model does not, and in three of the seven cases MAME's own source flags the gap. README.md:175 \| Pixel priority merge \| `toobin.cpp` brackets it with `not verified: logic is all controlled in a PAL`: playfield pen bit 3 gates the merge, and the motion o README.md:178 \| Alpha character flip \| `(data >> 10) & 1` taken as the flip bit \| sheet 6 routes `ANHFLIP` to D11; D10 reaches only the optional `ANROMA14/VPP` socket pin README.md:181 \| JSA `/RDIO` D6 \| JSA I and II comments say active low, JSA III says active high \| resolved from the sheet 22 LS240 \| README.md:183 The output filter is the largest of these. Sheet 21 draws a unity-gain Sallen-Key 2nd-order low-pass around LM324 4A, and the core implements it with the va README.md:193 The priority merge is the one backed by a fuse dump. PAL 7E on sheet 16, Atari part 136061-1151, was brute-forced from a real part and tested on a board, so README.md:242 Video DAC — a 32-step voltage sweep per channel.** Sheet 16 shows an R/2R ladder and a 74F260 five-input NOR acting as an all-bits-zero detect, both feeding t README.md:251 End-to-end audio transfer. The `/MIX` Sallen-Key and the POKEY transimpedance pole are derived from sheet 21's component values, but the baseline response of README.md:262 JSA `/RDIO` D6. Resolved here from sheet 22's LS240, against MAME comments that contradict each other between JSA I/II and JSA III. README.md:263 The JSA I stand-alone audio PCB (Atari A-043713) is shared with Blasteroids, Vindicators, Xybots and Skull & Crossbones, so SP-316, SP-317 and *SP-313 README.md:295 Thanks to the MAME team, whose `toobin.cpp`, `atarijsa` and `atarimo` code served as the functional oracle throughout, and to whoever preserved the Atari SP-320 README.md:299 Thanks also to Caius, who brute-forced the priority PAL (136061-1151) off a real board, to gamefixer, who tested the result on hardware, and to the PL Says it was checked on “real hardware” — 1 README.md:299 Thanks also to Caius, who brute-forced the priority PAL (136061-1151) off a real board, to gamefixer, who tested the result on hardware, and to the PL Notes where it differs from MAME — 5 rtl/video/toobin_priority.sv:27 Two structural differences from MAME's model (toobin.cpp screen_update, which notes its own merge is unverified), each confirmed against all 1024 fuse vectors: (a) a layer's pen bit 3 SELECTS which of that layer's two priority bits is comp README.md:9 Where a schematic and MAME disagree, the schematic wins and the disagreement is recorded — see [Where this core differs from MAME](#where-this-core-differs-from README.md:166 Where this core differs from MAME README.md:169 It applies where the SP-320 schematics document something MAME's model does not, and in three of the seven cases MAME's own source flags the gap. README.md:195 The two differ structurally: MAME treats playfield pen bit 3 as a gate that must be set before the playfield may cover a motion object, where the hardware uses Cites MAME source — 39 Toobin.sv:91 MAME's INPUT_PORTS_START(toobin) has only the FF8800 controls and the FF9000 service/status word; every operator setting lives in the X2804 EEPROM and is changed from the game's own self-test. rtl/main/toobin_addr_decode.sv:6 Faithful reproduction of MAME toobin.cpp `main_map` semantics: 1. rtl/main/toobin_addr_decode.sv:17 Source: Atari SP-320 schematics (main CPU decode); MAME's toobin.cpp. rtl/main/toobin_addr_decode.sv:40 Per-entry hits (start, end, mirror straight from toobin.cpp). rtl/main/toobin_irq_wd.sv:6 Interrupts (MAME toobin.cpp, set_interrupt_mixer(false)): scanline compare -> IPL0 pin (weight 1); latched, set by the video `scanline_match` pulse, cleared by a write to FF83C0 (irqack). rtl/main/toobin_irq_wd.sv:17 Source: Atari SP-320 schematics; MAME's toobin.cpp; the System 1 core's TG68K IPL convention (rtl/lib/TG68K/TG68K.vhd). rtl/main/toobin_main_bus.sv:197 MAME's INPUT_PORTS (hblank=D13, ready=D15) has these two swapped; the old RTL shipped MAME's layout, so the send gate was actually polling raster timing. rtl/toobin_core.sv:217 A single latch is written by every decoded FF8380 alias and read back (MAME models it readable); the renderer consumes [7:0]. rtl/video/toobin_char_rom.sv:7 Decode per MAME `anlayout` (8x8, 2bpp, planes {0,4}, x-offsets {0,1,2,3,8,9,10,11}, y16), MSB-first bits: row y uses bytes A=tile16+y2 (pixels 0-3) and B=A+1 (pixels 4-7); pixel x in 0-3: {A[3-x], A[7-x]}; x in 4-7: {B[3-(x-4)], B[7-(x- rtl/video/toobin_char_rom.sv:42 {pix7,pix6,...,pix0}, each pixel = {MSB=plane[0]@off0, LSB=plane[1]@off4} (MAME: planeoffset[0] is the most-significant pixel bit). rtl/video/toobin_mo_gfx.sv:6 MAME `molayout`: 16x16, 4bpp, RGN_FRAC(1,2) (sprites region 2 MB => 1 MB halves). rtl/video/toobin_mo_list.sv:16 Word fields (schematic sheet 6 latch wiring + MAME atarimo config -- the link lives in w2, NOT w0; w0[7:0] is ypos-low/size bits): w0: abs[15], ypos[14:6], height[5:3], width[2:0] w1: vflip[15], hflip[14], code[13:0] w2: link[7:0] rtl/video/toobin_mo_list.sv:104 Link pointer comes from WORD 2 (schematic sheet 6: 17F link register is loaded from the C09804 word; MAME linkmask {{0,0,0x00ff,0}}). rtl/video/toobin_mo_pos.sv:6 Implements MAME atarimo render_object's coordinate math for ONE object against ONE render scanline Y (0..383), in closed form. rtl/video/toobin_mo_render.sv:9 Faithful to MAME atarimo render_object (swapxy, forward order, transpen 0, pen base 0x100). rtl/video/toobin_mo_render.sv:47 scroll (pixels; MAME feeds reg>>6) rtl/video/toobin_mo_render.sv:238 evaluate the current column (MAME swapxy clip: break right, skip left) rtl/video/toobin_palette.sv:6 Per MAME toobin.cpp paletteram_w / intensity_w: R5 = word[14:10], G5 = word[9:5], B5 = word[4:0] (5:5:5) base8 = (c5 224) >> 5 ; if (base8 != 0) base8 += 38 (per channel) bit15 (intensity-disable): 1 => pen at full brightness; 0 => pe rtl/video/toobin_palette.sv:49 MAME applies the global brightness as a floating-point pen contrast -- `m_brightness = (double)(~data & 0x1f) / 31.0` in toobin.cpp intensity_w, then set_pen_contrast() -- and the float-to-8-bit conversion truncates. rtl/video/toobin_priority.sv:10 Decoded with MAME's jedutil as a gal16v8: simple mode, active-low outputs, only pins 13/14 driven. rtl/video/toobin_tile_dec.sv:7 One 8x8 tile row = 4 bytes: A,B from the first ROM half (planes 2,3), C,D from the second half (planes 0,1), per MAME pflayout {RGN_FRAC(1,2)+0,+4,0,4}, plane0 = MSB. rtl/video/toobin_tile_reorg.sv:4 The tile ROM downloads in MAME pflayout order (first half 0..0x3FFFF = planes 2,3; second half 0x40000..0x7FFFF = planes 0,1). rtl/video/toobin_video.sv:10 Layer order/merge exactly per MAME screen_update. rtl/video/toobin_vram_cpu.sv:9 Per MAME get_playfield_tile_info the 32-bit word is {hi16, lo16} where hi16 (color/flip/cat, bits31:16) is the addr[1]=0 access and lo16 (code, bits15:0) is addr[1]=1 (big-endian). README.md:7 The core reconstructs the original PCB — a 68010 main board plus an Atari JSA I sound board — from Atari's SP-320 schematic package, with MAME used as a functio README.md:13 Toobin' is its own platform, not Atari System 1 or System 2 (MAME driver `toobin.cpp`); only the video sync chain resembles System 2. README.md:18 Six MAME sets run on identical RTL — they differ only in the main CPU ROMs. README.md:36 \| ROMs \| Supplied by you from a MAME archive; none are included here \| README.md:135 Those states are replayed through the real core RTL and the rendered frame is compared to MAME's own output pixel for pixel. README.md:136 Across attract, self-test and gameplay captures, 10 / 10 in-scope frames are bit-identical over all 196,608 pixels. One gameplay frame is a documented out-o README.md:152 Render-load oracle — the motion-object budget is sized against measured game load, not a guess: a MAME script sweeps 36,000 frames of attract and gameplay a README.md:168 MAME is this project's functional oracle, and every gate above measures the core against it — so this is a narrow claim, not a general one. README.md:173 \| Behaviour \| MAME \| This core \| README.md:175 \| Pixel priority merge \| `toobin.cpp` brackets it with `not verified: logic is all controlled in a PAL`: playfield pen bit 3 gates the merge, and the motion o README.md:176 \| JSA I `/MIX` low-pass bit \| `atarijsa.cpp` carries `TODO: emulate the low pass filter!` — the bit does nothing \| the real 2nd-order filter, component by compo README.md:177 \| POKEY stereo gating \| `atarijsa.cpp` notes it is "currently only mono, only looking at `ym2151_ct1`" \| CT1 gates the POKEY feed into the left path, CT2 into t README.md:204 Under those two constraints the hardware equation reduces to exactly MAME's condition, so the two agree on every frame Toobin' can produce. README.md:262 JSA `/RDIO` D6. Resolved here from sheet 22's LS240, against MAME comments that contradict each other between JSA I/II and JSA III. README.md:295 Thanks to the MAME team, whose `toobin.cpp`, `atarijsa` and `atarimo` code served as the functional oracle throughout, and to whoever preserved the Atari SP-320 Says it matches, follows or was checked against MAME — 6 rtl/main/toobin_addr_decode.sv:13 Read and write handlers are decoded SEPARATELY, matching MAME's independent .r()/.w() installs: a read of a write-only register (or vice-versa) yields REG_NONE (open bus). rtl/main/toobin_addr_decode.sv:28 match(a, start, end, mirror): MAME global-mask + mirror-collapse + range. rtl/mem/toobin_rom_loader.sv:19 Region sizes and order match MAME's ROM_START(toobin); the download itself arrives over the MiSTer ioctl interface (sys/hps_io.sv). rtl/video/toobin_mo_linebuf.sv:12 Pen 0xFFFF is transparent (matches MAME's MO sentinel). rtl/video/toobin_palette.sv:54 Every attract frame runs at intensity=00, where cn=31 and the divide is a pass-through, so the error is invisible there; a pixel-exact comparison against MAME on an intensity=01 self-test frame caught it (856 pixels, all exactly +1). README.md:133 Pixel-exact compositor gate** — MAME 0.288 is instrumented to capture complete video state (playfield, alpha, motion-object and palette RAM, plus the scroll/S Shares text with the MAME driver without saying so — 4 rtl/video/toobin_char_rom.sv:8 (8x8, 2bpp, planes {0,4}, x-offsets {0,1,2,3,8,9,10,11}, y16), MSB-first bits: — shares text with atari/toobin.cpp:472 rtl/video/toobin_mo_gfx.sv:7 planes {RGN_FRAC(1,2)+0, RGN_FRAC(1,2)+4, 0, 4} (plane0=MSB), y32, x-offsets — shares text with atari/toobin.cpp:483 rtl/video/toobin_mo_gfx.sv:8 {0,1,2,3, 8,9,10,11, 16,17,18,19, 24,25,26,27}. Each row = 32 bits = 4 bytes/half; — shares text with atari/toobin.cpp:472 rtl/video/toobin_palette.sv:51 `m_brightness = (double)(~data & 0x1f) / 31.0` in toobin.cpp intensity_w, — shares text with atari/toobin.cpp:217
TraverseUSA# Shot Rider, Traverse USA / Zippy Race MiSTer-devel/Arcade-TraverseUSA_MiSTer @ bfda0a5b MAME compared: irem/travrusa.cpp + 4 related file(s) Read: 8 HDL files, 7,083 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	26%
Statements: 3 toward hardware, 4 toward MAME, 6 not counted Cites hardware documentation that MAME's driver does not — 3 rtl/traverse_usa.vhd:365 vcnt <= '0'&x"E6"; -- from M52 schematics rtl/traverse_usa.vhd:1074 sprite palette ROM 2H spr_palette: entity work.travusa_spr_palette port map( clk => clock_36n, addr => spr_palette_addr, data => spr_palette_do rtl/traverse_usa.vhd:1095 sprite rgb lut ROM 1F spr_rgb_lut: entity work.travusa_spr_rgb_lut port map( clk => clock_36n, addr => spr_rgb_lut_addr, data => spr_rgb_lut_do Cites hardware references or measurements that MAME's driver also gives — 6 rtl/traverse_usa.vhd:902 char graphics ROM 3E char_graphics_1 : entity work.travusa_chr_bit1 port map( clk => clock_36n, addr => chr_code_line, data => chr_graphx1_do — also in MAME: 3E irem/travrusa.cpp:849 rtl/traverse_usa.vhd:910 char graphics ROM 3E char_graphics_2 : entity work.travusa_chr_bit2 port map( clk => clock_36n, addr => chr_code_line, data => chr_graphx2_do — also in MAME: 3E irem/travrusa.cpp:849 rtl/traverse_usa.vhd:918 char graphics ROM 3E char_graphics_3 : entity work.travusa_chr_bit3 port map( clk => clock_36n, addr => chr_code_line, data => chr_graphx3_do — also in MAME: 3E irem/travrusa.cpp:849 rtl/traverse_usa.vhd:1012 sprite graphics ROM 3N sprite_graphics_1 : entity work.travusa_spr_bit1 port map( clk => clock_36n, addr => spr_code_line, data => spr_graphx1_do — also in MAME: 3N irem/travrusa.cpp:854 rtl/traverse_usa.vhd:1020 sprite graphics ROM 3L or 3M sprite_graphics_2 : entity work.travusa_spr_bit2 port map( clk => clock_36n, addr => spr_code_line, data => spr_graphx2_do — also in MAME: 3L irem/travrusa.cpp:841, 3M irem/travrusa.cpp:855 rtl/traverse_usa.vhd:1028 sprite graphics ROM 3K sprite_graphics3 : entity work.travusa_spr_bit3 port map( clk => clock_36n, addr => spr_code_line, data => spr_graphx3_do — also in MAME: 3K irem/travrusa.cpp:842 Cites MAME source — 4 rtl/YM2149.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA rtl/traverse_usa.vhd:33 Use with MAME roms from travusa.zip rtl/traverse_usa.vhd:78 (Reducing line count will result in missing sprites) May be this can be achieved by increasing CPU clock speed (web site and MAME report 4Mhz) My M52-A schematic clearly shows 18.432/6. README.txt:175 (Reducing line count will result in missing sprites) May be this can be achieved by increasing CPU clock speed (web site and MAME report 4Mhz) My M52-A schemat
TrioThePunch# Trio The Punch - Never Forget Me... MiSTer-devel/Arcade-TrioThePunch_MiSTer @ 123d5db8 MAME compared: dataeast/actfancr.cpp + 4 related file(s) Read: 32 HDL files, 15,230 lines (Quartus project)	MiSTer official	Both	medium	28%
Statements: 2 toward hardware, 63 toward MAME Cites hardware documentation that MAME's driver does not — 1 rtl/actfancer/jtcop_bac06.v:41 The /NUDS and /NLDS inputs of all chips are gated via a 74LS32 chip by the /DSP chip select signal. Says it was checked against the original PCB — 1 README.md:21 YM2203 OPN + YM3812 OPL2 + OKI M6295 ADPCM, MAME-accurate clocks (OKI @ 1.056 MHz verified on PCB, MAME triothep) Cites MAME source — 49 TrioThePunch.sv:316 MAME actfancr.cpp port mapping: P1 bit 0=UP, 1=DOWN, 2=LEFT, 3=RIGHT, 4=BUTTON1, 5=BUTTON2, 7=START1 SYSTEM bit 0=COIN1, 1=COIN2 MiSTer hps_io with jn keywords (pattern BoogieWings/Darius DataEast): D-pad joy[0..3] = R,L,D,U J1 buttons base rtl/actfancer/actfancer_bac06_wrap.sv:3 ActFancer's H6280 main CPU is 8-bit; MAME accesses BAC06 via pf_data_8bit_swap_w(): A0 selects high/low byte of the 16-bit word. rtl/actfancer/actfancer_bac06_wrap.sv:6 We translate: cpu_8bit_addr[12:0] → cpu_dout[15:0] / cpu_dsn[1:0] / cpu_addr[12:1] such that for A0=0 → write hi byte, A0=1 → write lo byte (the "swap" variant in MAME swaps endianness vs the plain one). rtl/actfancer/actfancer_bac06_wrap.sv:65 MAME pf_data_8bit_swap_w (decbac06.cpp:625-660): A0=0 → byte BASSO del word A0=1 → byte ALTO del word (validato in sim/tb_bac06_swap.sv) rtl/actfancer/actfancer_chars.sv:3 Stessa architettura di actfancer_tiles ma con tile 8x8 + index VRAM da MAME tile_shape0_8x8_scan (cpp:173). rtl/actfancer/actfancer_chars.sv:92 MAME tile_shape0_8x8_scan: idx = (col & 0x1f) + ((row & 0x1f) << 5) + ((col & 0x60) << 5) rtl/actfancer/actfancer_main.sv:4 MAME reference: dataeast/actfancr.cpp::actfancr_state::prg_map (lines 154-173) rtl/actfancer/actfancer_main.sv:131 MAME: 0x110000-0x110001 (buffer_spriteram_w 2 byte). rtl/actfancer/actfancer_main.sv:161 SYSTEM port MAME (active-low except bit7=VBL active-high): bit 0 = COIN1, bit 1 = COIN2, bit 7 = VBL rtl/actfancer/actfancer_main.sv:185 PF bus fanout (BAC06 wrapper esterno gestisce 8-bit→16-bit) MAME maps tightly: pf0: 0x060000-0x060007 ctrl0, 0x060010-0x06001F ctrl1, 0x062000-0x063FFF VRAM pf1: 0x070000-0x070007 ctrl0, 0x070010-0x07001F ctrl1, 0x072000-0x0727FF VRAM mod rtl/actfancer/actfancer_main.sv:193 PF1 VRAM: MAME limita a 2KB (0x072000-0x0727FF) — restringo per evitare aliasing rtl/actfancer/actfancer_obj_wrap.sv:10 MAME spriteram ActFancer (actfancr.cpp:150 buffer_spriteram_w): m_spriteram16[i] = m_spriteram[i2] \| (m_spriteram[(i2)+1] << 8); LO byte HI byte Cioè LITTLE-ENDIAN dentro il word16: spriteram byte 2i = LO byte (= cpu A0=0) s rtl/actfancer/actfancer_obj_wrap.sv:76 little-endian (MAME buffer_spriteram_w): A0=0 -> LO byte -> dsn = 2'b10 (we[0]=1 enable LO) A0=1 -> HI byte -> dsn = 2'b01 (we[1]=1 enable HI) rtl/actfancer/actfancer_rom_bram32.sv:6 Layout MAME chars 8x8 4bpp = RGN_FRAC(1,4): 4 planes from {0/4, 1/4, 2/4, 3/4} of the region. rtl/actfancer/actfancer_rom_bram32.sv:7 So: plane 0 = bytes 0x00000..0x07FFF plane 1 = bytes 0x08000..0x0FFFF plane 2 = bytes 0x10000..0x17FFF plane 3 = bytes 0x18000..0x1FFFF (vedi gfx_layout layout_8x8x4 in actfancr.cpp riga 308-317) rtl/actfancer/actfancer_snd.sv:4 MAME reference: dataeast/actfancr.cpp::dec0_s_map (lines 196-204) rtl/actfancer/actfancer_snd.sv:151 PIN7_HIGH (MAME) rtl/actfancer/actfancer_sprites.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Act-Fancer DECO MXC06 sprite engine — 1:1 MAME decmxc06::draw_sprites. rtl/actfancer/actfancer_sprites.sv:4 Reference: reference/decmxc06.cpp rtl/actfancer/actfancer_sprites.sv:6 Sprite layout (4 word × 16 bit per sprite, big-endian sprite RAM 2KB = 256 sprite): word0 (byte0,1) = {byte0:[en, yflip, xflip, h[1:0], w[1:0], yh], byte1:[ylo[7:0]]} bit 15 : enable bit 14 : Y flip bit 13 : X flip bit 12:11 : height (1x, 2 rtl/actfancer/actfancer_sprites.sv:23 MAME conversion (cpp:80-85): sx = data2 & 0x01ff; if (sx >= 256) sx -= 512; sx = 240 - sx; sy = data0 & 0x01ff; if (sy >= 256) sy -= 512; sy = 240 - sy; rtl/actfancer/actfancer_sprites.sv:44 MRA sprites interleave (B0..B3): B0 = region 1/4 B1 = region 3/4 B2 = region 0 B3 = region 2/4 MAME planes = {0, 1/4, 2/4, 3/4} → pen[3]=B2, pen[2]=B0, pen[1]=B3, pen[0]=B1. rtl/actfancer/actfancer_sprites.sv:128 512 wide per gestire sx negativo (signed wrap MAME). rtl/actfancer/actfancer_sprites.sv:270 Y: 9-bit (byte0 bit0 = Y[8]) - MAME conversion rtl/actfancer/actfancer_sprites.sv:314 code per tile row in multi-h sprite: code = (code_base & ~(h-1)) if (parentFlipY) y_offset = -tile_yi else y_offset = (h-1) - tile_yi For multi-width (x_iter > 0): MAME consumes additional spriteram entries. rtl/actfancer/actfancer_sprites.sv:327 rom_addr = {code_y[11:0], row_in_tile[3:0], half} (code_y truncated to 12 bit per MAME tile region size 1536 ≈ 11 bit) word32-index shiftato di 1 (bridge fa [17:1]<<1, preserva [1:17]) rtl/actfancer/actfancer_tiles.sv:13 VRAM indexing MAME (decbac06.cpp): - shape0 col-major: idx = (row & 0xf) + ((0xFF - col[7:0]) << 4) - shape0 row-major: idx = (col & 0xf) + ((row & 0xf) << 4) + ((col & 0x1f0) << 4) - shape1: idx = (col & 0xf) + ((row & 0x1f) << 4) + ((col rtl/actfancer/actfancer_tiles.sv:97 scroll x invertito per col-major (MAME cpp:274-278) rtl/actfancer/actfancer_tiles.sv:124 VRAM index calculation (MAME tile_shape_scan) rtl/actfancer/actfancer_tiles.sv:255 hflip from MAME: column-major -> TILE_FLIPX rtl/actfancer/actfancer_top.sv:204 P1/P2 Trio: MAME P1 layout active-low bit 0=Up, 1=Down, 2=Left, 3=Right, 4=B1, 5=B2, 6=B3(Trio), 7=Start joy_w[7:0] è già rimappato dal top sv per matchare quest'ordine. rtl/actfancer/actfancer_video.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Act-Fancer — Video subsystem v5 (custom MAME-faithful modules) rtl/actfancer/actfancer_video.sv:4 Replaces previous jtcop_bac06/jtcop_obj with bespoke 1:1 MAME modules: actfancer_tiles → PF0 16x16 tiles (jtcop_bac06 ditched) rtl/actfancer/actfancer_video.sv:328 Compositing: PF1 (chars) > sprite > PF0 (tiles) Indici palette base Trio The Punch (MAME GFXDECODE triothep): chars → 0x000 tiles → 0x200 (vs ActFancer 0x100) sprite → 0x100 (vs ActFancer 0x200) rtl/actfancer/actfancer_video.sv:389 MAME pf_data_8bit_swap_w (decbac06.cpp:496+641): CPU A0=0 → MAME offset^1 → odd → mask 0x00ff → write LO byte CPU A0=1 → MAME offset^1 → even → mask 0xff00 → write HI byte rtl/actfancer/jtcop_bac06.v:205 MAME pf_control1_8bit_w (decbac06.cpp:551-566): offset >= 4 sono 8-bit mirror, scrivono LO byte indipendentemente da addr pari/dispari. rtl/actfancer/jtcop_bac06.v:286 hflip = TILE_FLIPX MAME: ON quando col-major (mode[0] bit1 = 0). rtl/actfancer/jtcop_bac06.v:296 MAME decbac06.cpp ActFancer m_wide=2: GEOM_4X1 16x16: 256 cols × 16 rows tile_shape0_scan column-major: idx = (row & 0xf) + ((0xFF - col[7:0]) << 4) row-major: idx = (col & 0xf) + ((row & 0xf) << 4) + ((col & 0x1f0) << 4 rtl/actfancer/jtcop_bac06.v:310 In jtcop convention, msbrow_en=0 means "MAME column-major" (TILE_FLIPX implicit). rtl/actfancer/jtcop_bac06.v:311 In jtcop convention, msbrow_en=1 means "MAME row-major". rtl/actfancer/jtcop_bac06.v:312 Trio The Punch: MAME m_wide=0 (tilemap 1024 px). rtl/actfancer/jtcop_bac06.v:314 8x8 cols = 128/64/32 (invariato MAME). rtl/actfancer/jtcop_bac06.v:337 shape1 16x16: 32 × 32 (1024 entries) ← Trio PF0 MAME: (col & 0xf) + ((row & 0x1f) << 4) + ((col & 0x10) << 5) rtl/actfancer/jtcop_bac06.v:487 MAME byte plane offset = 16+y (y=0..7) → DDR byte = T128 + 64 + y4 → rom_addr (word16-idx) = T32 + 16 + y rtl/actfancer/triothep_main.sv:4 MAME reference: dataeast/actfancr.cpp::triothep_state::prg_map (lines 175-192) rtl/actfancer/triothep_main.sv:6 0x000000-0x03FFFF ROM 256KB 0x040000-0x040007 PF1 BAC06 control0 0x040010-0x04001F PF1 BAC06 control1 (8bit_swap) 0x044000-0x045FFF PF1 VRAM (R/W, 8bit_swap) 8KB region 0x046400-0x0467FF PF1 rowscroll (R/W, 8bit_swap) 0 rtl/actfancer/triothep_main.sv:126 $140000 (nopr MAME) rtl/actfancer/triothep_main.sv:146 SYSTEM (VBL + coin) — MAME PORT_START("SYSTEM"): bit 0=COIN1, bit 1=COIN2, bit 2=SERVICE1 (tutti active-low), bits 3-6 = UNKNOWN active-low (default high), bit 7=VBL active-high. rtl/actfancer/triothep_main.sv:216 VBL → IRQ1 (HOLD_LINE equivalente) MAME: screen.screen_vblank().set_inputline(m_maincpu, 0, HOLD_LINE) Says it matches, follows or was checked against MAME — 1 README.md:21 YM2203 OPN + YM3812 OPL2 + OKI M6295 ADPCM, MAME-accurate clocks (OKI @ 1.056 MHz verified on PCB, MAME triothep) Shares text with the MAME driver without saying so — 13 rtl/actfancer/actfancer_chars.sv:92 MAME tile_shape0_8x8_scan: idx = (col & 0x1f) + ((row & 0x1f) << 5) + ((col & 0x60) << 5) — shares text with dataeast/decbac06.cpp:173 rtl/actfancer/actfancer_sprites.sv:24 sx = data2 & 0x01ff; if (sx >= 256) sx -= 512; sx = 240 - sx; — shares text with dataeast/decmxc06.cpp:81 rtl/actfancer/actfancer_sprites.sv:31 if (parentFlipY) incy = -1; else { code += h-1; incy = 1; } — shares text with dataeast/decmxc06.cpp:116 rtl/actfancer/actfancer_tiles.sv:15 - shape0 row-major: idx = (col & 0xf) + ((row & 0xf) << 4) + ((col & 0x1f0) << 4) — shares text with dataeast/decbac06.cpp:145 rtl/actfancer/actfancer_tiles.sv:16 - shape1: idx = (col & 0xf) + ((row & 0x1f) << 4) + ((col & 0xf0) << 5) — shares text with dataeast/decbac06.cpp:159 rtl/actfancer/actfancer_tiles.sv:17 - shape2: idx = (col & 0xf) + ((row & 0x3f) << 4) + ((col & 0x70) << 6) — shares text with dataeast/decbac06.cpp:166 rtl/actfancer/jtcop_bac06.v:299 row-major: idx = (col & 0xf) + ((row & 0xf) << 4) + ((col & 0x1f0) << 4) — shares text with dataeast/decbac06.cpp:145 rtl/actfancer/jtcop_bac06.v:301 tile_shape1_scan: idx = (col & 0xf) + ((row & 0x1f) << 4) + ((col & 0xf0) << 5) — shares text with dataeast/decbac06.cpp:159 rtl/actfancer/jtcop_bac06.v:303 tile_shape2_scan: idx = (col & 0xf) + ((row & 0x3f) << 4) + ((col & 0x70) << 6) — shares text with dataeast/decbac06.cpp:166 rtl/actfancer/jtcop_bac06.v:305 GEOM_4X1: 128×32 → idx = (col & 0x1f) + ((row & 0x1f) << 5) + ((col & 0x60) << 5) — shares text with dataeast/decbac06.cpp:173 rtl/actfancer/jtcop_bac06.v:306 GEOM_2X2: 64×64 → idx = (col & 0x1f) + ((row & 0x1f) << 5) + ((row & 0x20) << 5) + ((col & 0x20) << 6) — shares text with dataeast/decbac06.cpp:172 rtl/actfancer/jtcop_bac06.v:338 MAME: (col & 0xf) + ((row & 0x1f) << 4) + ((col & 0x10) << 5) — shares text with dataeast/decbac06.cpp:159 rtl/actfancer/triothep_main.sv:217 MAME: screen.screen_vblank().set_inputline(m_maincpu, 0, HOLD_LINE) — shares text with dataeast/actfancr.cpp:381
TropicalAngel# Tropical Angel MiSTer-devel/Arcade-TropicalAngel_MiSTer @ 3fe315d7 MAME compared: irem/m57.cpp + 5 related file(s) Read: 10 HDL files, 7,359 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	29%
Statements: 2 toward hardware, 3 toward MAME, 5 not counted Cites hardware documentation that MAME's driver does not — 1 rtl/TropicalAngel.vhd:310 from M52 schematics Cites hardware references or measurements that MAME's driver also gives — 5 rtl/TropicalAngel.vhd:843 char graphics ROM 3K — also in MAME: 3K irem/m57.cpp:564 rtl/TropicalAngel.vhd:857 char graphics ROM 3M — also in MAME: 3M irem/m57.cpp:565 rtl/TropicalAngel.vhd:871 char graphics ROM 3Q — also in MAME: 3Q irem/m57.cpp:567 rtl/TropicalAngel.vhd:913 sprite palette ROM 3D — also in MAME: 3D irem/m57.cpp:574 rtl/TropicalAngel.vhd:927 sprite rgb lut ROM 1B — also in MAME: 1B irem/m57.cpp:588 Reports a measurement taken on the original PCB — 1 Arcade-TropicalAngel.sv:413 oscillator for audio on pcb is 3.579545mhz divided by 4 according to measurements by Corrado (kold666) use clk_mem for in_clk because the snd rom vma is using clk_mem in the sensitivity list for it's CDC delay reg Cites MAME source — 3 rtl/TropicalAngel.vhd:34 Use with MAME roms from troangel.zip rtl/TropicalAngel.vhd:36 Tropical Angel (Irem M57) Hardware caracteristics : (No schematics available, video gen info is from MAME sources) rtl/ym2149/YM2149.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA
TurkeyShoot# Turkey Shoot MiSTer-devel/Arcade-TurkeyShoot_MiSTer @ 57be18e3 MAME compared: williams/williams.cpp + 5 related file(s) Read: 11 HDL files, 12,903 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	11%
Statements: 2 toward hardware, 2 toward MAME Cites hardware documentation that MAME's driver does not — 2 rtl/tshoot_cmos_ram.vhd:37 @0C-0F: pricing selection (XXYY XX=value YY=index [0000 custom, 0909 free play] default 0303) 0000/0101/.../0909 rtl/tshoot_cmos_ram.vhd:49 @2C-2F: ? Cites MAME source — 1 rtl/williams2.vhd:32 Use with MAME roms from tshoot.zip Shares text with the MAME driver without saying so — 1 rtl/williams2.vhd:325 pixels \|0\|1\|2\|3\|4\|5\|0\|1\|2\|3\|4\|5\| — shares text with williams/williamsblitter.cpp:50
Tutankham# Tutankham MiSTer-devel/Arcade-Tutankham_MiSTer @ 9cf75dc3 MAME compared: konami/tutankhm.cpp + 3 related file(s) Read: 21 HDL files, 7,712 lines (Quartus project)	MiSTer official	Mostly hardware	low	36%
Statements: 7 toward hardware, 14 toward MAME Cites hardware documentation that MAME's driver does not — 5 rtl/TimePilot_SND.sv:315 Time Pilot's AY-3-8910s contain selectable low-pass filters with the following cutoff frequencies: 3386.28Hz, 723.43Hz, 596.09Hz Model this here (the PCB handles this via 3 74HC4066 switching ICs located at A2, A3 and A4) rtl/custom/k084.sv:31 Chip pinout, confirmed against the Stern Tutankham service manual, C.R.T. Board schematic 34D-0126-S, where the part is labelled "084 / F3". rtl/custom/k084.sv:231 H8Q arrives inverted (MAME: h8q = BIT(~x, 3)) and, per sheet 34D-0126-S, already XORed with the buffered flip signal by the LS86 at F11. rtl/custom/k526.sv:3 SystemVerilog implementation of the Konami 526, an 82S153 PLA used for address decoding on Time Pilot Converted from dump available at the PLD Archive http://wiki.pldarchive.co.uk/index.php?title=Time_Pilot Copyright (C) 2021 Ace rtl/custom/k528.sv:3 SystemVerilog implementation of the Konami 528, an 82S153 PLA used for controlling the vertical counter outputs on Time Pilot's Konami 082 Converted from dump available at the PLD Archive http://wiki.pldarchive.co.uk/index.php?title=Time_Pi Ships hardware documentation files — 2 Useful Information/schematics/MemoryMap.txt Useful Information/schematics/Tutankham.pdf Cites MAME source — 10 rtl/Tutankham_CPU.sv:438 Generate VBlank IRQ for MC6809E MAME: IRQ fires every other vblank frame when irq_enable is set. rtl/Tutankham_CPU.sv:577 Against the ~130 ohm full-scale of the DAC those three star levels land at 194, 214 and 255 of 255 - the same figures galaxian.cpp derives - which is 24, 26 and 31 at 5 bits. rtl/custom/k084.sv:6 Reconstructed from the 084 pinout, the Galaxian/Scramble star circuit that MAME models in tutankhm_v.cpp, and the Konami bootleg daughter-board that replaced this chip. rtl/custom/k084.sv:32 That sheet also corrects two details of the pinout circulated with MAME: pin 12 is a second ground alongside pin 11, and pin 9 is not connected. rtl/custom/k084.sv:68 Two deliberate departures from MAME, both settled - do not re-derive: * No H64/H128 pin exists, so MAME's ((x & 0xc0) ^ flipxor) != 0xc0 quarter-line suppression is not modelled. rtl/custom/k084.sv:85 Set to 1 to reinstate MAME's galaxian-inherited x[7:6]==2'b11 suppression rtl/custom/k084.sv:134 Pin 3 gates the LFSR to the 256 visible pixels of a line - 512 steps per line, which is exactly MAME's stars_draw_row(..., star_offs = y * 512). rtl/custom/k084.sv:169 Bit numbering follows MAME's star palette: [5]/[4] red, [3]/[2] green, [1]/[0] blue, with the even index of each pair driving the 100 ohm (brighter) resistor. rtl/custom/k084.sv:231 H8Q arrives inverted (MAME: h8q = BIT(~x, 3)) and, per sheet 34D-0126-S, already XORed with the buffered flip signal by the LS86 at F11. rtl/custom/k084.sv:242 MAME's galaxian-inherited quarter-line suppression. Says it matches, follows or was checked against MAME — 2 rtl/Tutankham_CPU.sv:386 Apply flip and scroll to VRAM read coordinates (matching MAME screen_update) CRT Flip XORs into the game's own flip registers, rotating the image 180 degrees rtl/Tutankham_CPU.sv:453 Clear IRQ when irq_enable is turned off (matches MAME irq_enable_w) Shares text with the MAME driver without saying so — 2 rtl/custom/k084.sv:35 _____________ _\| \|_ NE555 ~1Hz \|_\|10 24\|_\| VCC _\| \|_ 18MHz (401) \|_\|1 19\|_\| Rese — shares text with konami/tutankhm.cpp:28 rtl/custom/k084.sv:212 NE555 astable on pin 10: Ra=100k, Rb=10k, C=10uF gives 0.693(Ra+2Rb)*C — shares text with konami/tutankhm.cpp:312
Ultratank# Ultra Tank MiSTer-devel/Arcade-Ultratank_MiSTer @ 54e8136f MAME compared: atari/ultratnk.cpp + 2 related file(s) Read: 18 HDL files, 5,080 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	7%
Statements: 4 toward hardware Cites hardware documentation that MAME's driver does not — 4 rtl/collision.vhd:52 74LS279 quad SR latch at L11, all inputs are active low rtl/playfield.vhd:108 Some glue logic, may be re-written later to be cleaner and easier to follow without referring to schematic rtl/playfield.vhd:142 74LS166 video shift register rtl/playfield.vhd:236 74LS273 octal flip-flop with asynchronous clear at H10
UPLFramebuffer# Ark Area, Mutant Night, Ninja-Kid II / NinjaKun Ashura no Shou, Omega Fighter … MiSTer-devel/Arcade-UPLFramebuffer_MiSTer @ e5a4f40d MAME compared: upl/ninjakd2.cpp Read: 13 HDL files, 3,491 lines (Quartus project)	MiSTer official	Both	low	74%
Statements: 2 toward hardware, 30 toward MAME Ships hardware documentation files — 2 Useful Information/schematics/Atomic RoboKid - Operators Manual.pdf Useful Information/schematics/Mutant Night - DIP Wiring Diagram.png Cites MAME source — 27 Arcade-UPLFramebuffer.sv:218 Every UPL set here is 2-button (ninjakd2.cpp INPUT_PORTS common / common_2p). Arcade-UPLFramebuffer.sv:259 MAME port assembly (ninjakd2.cpp:1156). rtl/UPLFramebuffer.sv:18 ---- controls, assembled into MAME port order by the wrapper (active low) rtl/UPLFramebuffer.sv:183 mnight/mnightj/arkarea use an 11-bit bg tile index (ninjakd2.cpp:1047 family). rtl/UPLFramebuffer.sv:268 Mono board - one SPEAKER (ninjakd2.cpp:1575) rtl/UPLFramebuffer_MAIN.sv:5 Map from ninjakd2.cpp:1010 (ninjakd2_main_cpu). rtl/UPLFramebuffer_MAIN.sv:18 ---- controls, assembled into MAME port order by the wrapper (active low) rtl/UPLFramebuffer_MAIN.sv:63 ninjakd2 (ninjakd2.cpp:1026) and mnight (:1047) relocate every region, but the control and input offsets match, so only the selects differ. rtl/UPLFramebuffer_MAIN.sv:136 only bit0 of MAME's tick counter is ever tested rtl/UPLFramebuffer_MAIN.sv:138 Bank mask from ROM region size (ninjakd2.cpp:1521 machine_start): robokid/omegaf 0x50000 = 16 banks, ninjakd2/mnight/arkarea 0x30000 = 8. rtl/UPLFramebuffer_MAIN.sv:157 bg_ctrl (ninjakd2.cpp:1285): +00/+01 scrollx, +02/+03 scrolly, +04 bit0 enable, +05 bank masked with (vram_alloc_size >> 10) - 1 — robokid 1 bit, omegaf 3. rtl/UPLFramebuffer_MAIN.sv:192 omegaf I/O protection read model (ninjakd2.cpp:866). rtl/UPLFramebuffer_MAIN.sv:219 MAME tests the POST-increment tick, so toggle on the leading edge and let the mux read it back the same cycle. rtl/UPLFramebuffer_MAIN.sv:331 vblank IRQ: HOLD_LINE on the rising edge, acknowledge returns 0xD7 = RST 10h (ninjakd2.cpp:775). rtl/ram_rom/upl_rom.sv:201 0x8000-0xBFFF is not encrypted (MAME decodes only the first 0x8000). rtl/ram_rom/upl_rom.sv:244 gfx_unscramble, in flight (ninjakd2.cpp:2249 lineswap_gfx_roms). rtl/ram_rom/upl_rom.sv:244 MAME rotates the low (bit+1) address bits left at load: da[bit:1] = sa[bit-1:0], da[0] = sa[bit]; bits above `bit` unchanged. rtl/video/UPLFramebuffer_BGLAYER.sv:5 Single layer on ninjakd2/mnight/arkarea, three identical ones on robokid and omegaf (ninjakd2.cpp robokid_get_bg_tile_info<Layer>). rtl/video/UPLFramebuffer_BGLAYER.sv:118 row_2x2 is 0 1 / 2 3, col_2x2 (robokid/omegaf) is 0 2 / 1 3: the sub-tile bits swap (emu/video/generic.cpp:145). rtl/video/UPLFramebuffer_SPRITE.sv:8 ninjakd2.cpp reference points: draw_sprites() — 96 16x16 sprites per frame, a big (32x32) one counting as 4, a disabled sprite still counting as 1 erase_sprites() — clear to 0xf, or with overdraw only where the stencil hits stencil_* rtl/video/UPLFramebuffer_SPRITE.sv:260 each 16x16 quadrant drawn counts against the 96 budget; MAME's quadrant order is x inner, y outer rtl/video/UPLFramebuffer_VIDEO.sv:4 Layer order and palette bases from ninjakd2.cpp screen_update_*. rtl/video/UPLFramebuffer_VIDEO.sv:61 Video timing (ninjakd2.cpp: 59.61 Hz). rtl/video/UPLFramebuffer_VIDEO.sv:70 MAME visarea min_y rtl/video/UPLFramebuffer_VIDEO.sv:104 ninjakd2.cpp get_fg_tile_info: tile = ((hi & 0xc0) << 2) \| lo flipyx = (hi >> 4) & 3 color = hi & 0x0f, palette base 0x200 rtl/video/UPLFramebuffer_VIDEO.sv:174 Three identical bg layers (ninjakd2.cpp robokid_get_bg_tile_info<Layer>). rtl/video/UPLFramebuffer_VIDEO.sv:234 fg transparent pen is 0xF, not 0 (ninjakd2.cpp:449 set_transparent_pen). Shares text with the MAME driver without saying so — 3 rtl/video/UPLFramebuffer_BGLAYER.sv:83 (col & 0x0f) \| ((row & 0x1f) << 4) \| ((col & mask) << 5) — shares text with upl/ninjakd2.cpp:416 rtl/video/UPLFramebuffer_BGLAYER.sv:110 robokid/omegaf: 12-bit tile = ((hi&0x10)<<7)\|((hi&0x20)<<5)\|((hi&0xc0)<<2)\|lo, — shares text with upl/ninjakd2.cpp:430 rtl/video/UPLFramebuffer_SPRITE.sv:99 code = sprptr[3] \| (bitswap<3>(sprptr[2],3,7,6) << 8) — shares text with upl/ninjakd2.cpp:626
Vastar# The Bounty, Dog Fight, Mogu Chan, The Percussor … MiSTer-devel/Arcade-Vastar_MiSTer @ 746bb363 (matched by date) MAME compared: orca/vastar.cpp, orca/zodiack.cpp + 4 related file(s) Read: 8 HDL files, 2,137 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	49%
Statements: 4 toward MAME Cites MAME source — 1 rtl/Vastar_CPU.sv:6 MAME reference: vastar.cpp, vastar_viddev.cpp Hardware: Z80 CPU1 + Z80 CPU2 @ 3.072 MHz (XTAL 18.432 / 6) AY-3-8910 @ 1.536 MHz (18.432 / 12) Screen: 288x264 total, visible 256x224 (lines 17-240), ~60.6 Hz (pixel clock 6.144 MHz = 18.432 XT Says it matches, follows or was checked against MAME — 2 rtl/Vastar_CPU.sv:152 The per-sprite flipX/flipY inversion (below, in the sprite decode) is gated on flip_screen, matching MAME vastar_viddev.cpp: if (m_flip_screen) { flipx = !flipx; flipy = !flipy; } Using rot_flip there instead looks like a harmless simplific rtl/Vastar_CPU.sv:305 BG tile ROMs — named by the layer they serve Note: bg0_tilerom loads from bgtiles1 ROM region (CS_DL=bgtile1_cs_i) bg1_tilerom loads from bgtiles0 ROM region (CS_DL=bgtile0_cs_i) This cross-mapping matches MAME's "4 - Which" gfx assignment. Shares text with the MAME driver without saying so — 1 rtl/Vastar_CPU.sv:154 if (m_flip_screen) { flipx = !flipx; flipy = !flipy; } — shares text with orca/vastar_viddev.cpp:161
VBall# U.S. Championship V'ball MiSTer-devel/Arcade-VBall_MiSTer @ eec44180 MAME compared: technos/vball.cpp Read: 13 HDL files, 3,106 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	0%
No statements found
Victory# Victory MiSTer-devel/Arcade-Victory_MiSTer @ 5fc39e93 MAME compared: exidy/victory.cpp + 2 related file(s) Read: 66 HDL files, 4,801 lines (Quartus project)	MiSTer official	Both	medium	42%
Statements: 48 toward hardware, 6 toward MAME, 1 not counted Cites hardware documentation that MAME's driver does not — 48 rtl/victory_board.sv:267 Sheet 4's 14K LS241 status driver is a live bus. rtl/victory_cpu_wait.sv:1 SPDX-License-Identifier: GPL-3.0-or-later CPU/audio drawing 77-0005-01 sheet 1: both H6 LS74 sections and N6 LS08. rtl/video/victory_graphics.sv:64 Sheet 15 detects occupied pixels across RGB colors. rtl/video/victory_graphics.sv:233 HSC sheet 15: 11H feeds SFCIRQ back into 10H. rtl/video/victory_graphics.sv:265 Sheet 10's downloaded 13E PROM supplies both movement enables and directions. rtl/video/victory_hsc_address.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 8: seven LS151 address selectors, MPXRC row/column selection. rtl/video/victory_hsc_alignment_control.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 9: 18C transfer NAND, 18B manual-increment NAND, 16D alignment NAND, and the first section of 15E with 17E's SRE NAND. rtl/video/victory_hsc_background_control.sv:30 Sheet 16 grounds CE15 and 16L selects +5 on WE13 when the access tag is high. rtl/video/victory_hsc_background_display.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 16: 9K/9L/9M LS299s, 10L NAND mode gates and 10K endpoint mux. rtl/video/victory_hsc_background_display.sv:3 Read bytes use logical RGB bit order, as sheet 6's RAM outputs. rtl/video/victory_hsc_background_ram.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 6 background RAM: one address/read/write port per 2114 bank. rtl/video/victory_hsc_blanking_control.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 4 pin network around 15J. rtl/video/victory_hsc_busy_filter.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Sheet 4 R7=22 ohms, C27=0.01 uF feeds 14K LS241 pin 2 only. rtl/video/victory_hsc_clock.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 2: 17A (74LS161), 16B (74LS74) and 15A (74S374). rtl/video/victory_hsc_clock.sv:3 ce_master represents each inverted-crystal rising edge; PROM 16A is asynchronous and must settle before the next enabled edge. rtl/video/victory_hsc_collision.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 15: 8E/8F/9E and 8D/9D/9F NOR each RGB triplet; 8C/9C OR the empty-pixel flags; 7C NANDs all eight results. rtl/video/victory_hsc_coordinate_control.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC 77-0004-01 sheet 9: 18B manual-X NAND, 16C vector gates, 17C Y AND and the second section of 15E. rtl/video/victory_hsc_coordinates.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 8: primary X (11B/13B LS169), sampled /LOAD (14A), Y-prime latch (10C), working X (12D/13D LS161) and Y (10B/8B LS169). rtl/video/victory_hsc_counters.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 8: I counters 12C/11C/12B/14B, PC counters 9B/7B, PC bit zero at 12E. rtl/video/victory_hsc_cpu_decode.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC 77-0004-01 sheet 1: 17L PROM, 19L/18L/19K/18K LS138s, 12H bus-selection OR and 12L address inverter. rtl/video/victory_hsc_cpu_wait.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 5: 5J request/feedback NANDs, 8J and both sections of 9J. rtl/video/victory_hsc_decode.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 9's next-address selection and raw PROM control outputs. rtl/video/victory_hsc_decode.sv:15 18E (74LS151): D0=GND, D1=HTC, D2=/LTC, D3=/SETRDY, D4=/CM7, D5=VFIN, D6/D7=+5. rtl/video/victory_hsc_dimensions.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 11: LS161 counters 3H/4H/5H, NAND 8H and inverters 9H. rtl/video/victory_hsc_display.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 14: 1F/1E/1D LS299 and XH LS157. rtl/video/victory_hsc_lookahead.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 16: 15M/16L address and /WE muxes, 15L LS174 address latch and 15K Signetics 82S09 (64x9). rtl/video/victory_hsc_lookahead.sv:24 Sheet 5 SEALOK = SLOKEA OR SEAADV. rtl/video/victory_hsc_lookahead.sv:33 82S09's open-collector outputs read the complemented stored word, and follow the complement of I0..8 during a write. rtl/video/victory_hsc_memory_control.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheets 9/14: address/write NANDs, foreground write latch 16B and serial-register direction gates. rtl/video/victory_hsc_memory_control.sv:23 Sheet 14 16B: D=S W VRAM, Q-bar pin 6 drives 6C and BIRWR. rtl/video/victory_hsc_memory_control.sv:24 SCLK11 is the same inverted-crystal edge that advances clock latch 15A; sample the established phase before that latch updates its outputs. rtl/video/victory_hsc_ram.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 14's three banks of 4116 DRAM, addressed through sheet 8. rtl/video/victory_hsc_ram.sv:35 Sheet 14's RP3/RP2 pull-ups make floating bits high; represent that bus value without inferring FPGA internal tristates. rtl/video/victory_hsc_raster_control.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 3: sync decoder, scroll loads and 13F blanking latches. rtl/video/victory_hsc_raster_control.sv:43 Sheet 3 exports the second section's /Q8, not Q9. rtl/video/victory_hsc_raster_counters.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 3 counter chain: 13H LS74, 17F LS161 and both 15F LS112 sections, with vertical 15H/16F LS161s. rtl/video/victory_hsc_raster_counters.sv:23 Sheet 3's INVERT is the complement of raw S INVERT. rtl/video/victory_hsc_register_decode.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 7: LS08 gates 19H/19J combine CPU and program-register strobes. rtl/video/victory_hsc_register_decode.sv:17 Sheet 7's +5 wire enters D6/pin 13; it crosses the CM-load return without a dot. rtl/video/victory_hsc_renderer.sv:23 Sheet 3 inverter 14H derives raster INVERT from raw S INVERT (CONTROL bit 3). rtl/video/victory_hsc_renderer.sv:24 Sheet 14 uses the raw wire for LS299 direction and endpoint. rtl/video/victory_hsc_renderer.sv:34 This is provisional glue, not a claim to reproduce missing PROM 15J. rtl/video/victory_hsc_rgb.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Sheet 16 Q1..Q6 current-steering RGB drivers, normalized nominal transfer. rtl/video/victory_hsc_rgb.sv:3 Low 82S09 pins sink emitter current through 3.9k/2k/1k branches. rtl/video/victory_hsc_scroll.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 5: 3J LS157 clocks cascaded 1J/XJ and XL/XK LS193s. rtl/video/victory_hsc_sequencer.sv:19 Sheet 8: 14E inverts the raw SEQ CLK to S SEQ CLK. rtl/video/victory_hsc_sequencer.sv:19 Sheet 9: 17E NANDs that signal with the non-inverted 18E condition output. rtl/video/victory_hsc_vector.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC 77-0004-01 sheet 10: PROM 13E's address and movement outputs. Cites hardware references or measurements that MAME's driver also gives — 1 rtl/video/victory_hsc_scroll.sv:21 Follow the continuous wires at 3J pins 10/11: normal scan increments both X and Y, not just X. — also in MAME: 3J exidy/victory.cpp:286 Cites MAME source — 6 rtl/io/trackball_input.sv:4 Like MAME's IPT_TRACKBALL with PORT_KEYDELTA(4) at 80% sensitivity, a held D-pad direction adds a small fixed step every frame (no ramp, stops when released); the stick adds a step proportional to its deflection beyond a dead zone. rtl/io/victory_inputs.sv:45 MAME declares PORT_REVERSE on Victory's dial. rtl/victory_board.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Main board memory/PIO decode from the pinned MAME Victory driver. rtl/video/victory_graphics.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Synthesizable command implementation based on Aaron Giles's BSD-licensed victory_v.cpp. rtl/video/victory_graphics.sv:84 MAME's busy model uses 11.289 MHz / 8. rtl/video/victory_timing.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Provisional raster from MAME victory.h; sync porches await PCB confirmation.
Vindicators# Vindicators MiSTer-devel/Arcade-Vindicators_MiSTer @ ad657d98 MAME compared: atari/vindictr.cpp + 6 related file(s) Read: 36 HDL files, 8,392 lines (Quartus project)	MiSTer official	Both	high	87%
Statements: 310 toward hardware, 88 toward MAME Cites hardware documentation that MAME's driver does not — 305 Arcade-Vindicators.sv:158 Per-player switch word, ACTIVE HIGH ("pressed"), in the order of the panel switches Pn-S1..Pn-S8 on SP-317 sheet 13 (= MAME 0x260000 D8..D15); see the port comment in vind_core.sv. rtl/main/vind_addr_decode.sv:3 Vindicators 68010 address decode — SP-317 sheet 4 (PAL 3C, LS139 4J) and sheet 3 (LS138 7/8B), gate for gate. rtl/main/vind_addr_decode.sv:7 Structure derives from the Xybots MiSTer core's `xybots_addr_decode.sv` (GPL-3.0); every equation below is Vindicators' own, read off SP-317 sheets 4 and 3. rtl/main/vind_addr_decode.sv:11 ---- PAL16L8 3C = 136059-1150 (sheet 4) -------------------------------- Pin map from the drawing: 1=BAS 2=A19 3=A18 4=A17 5=A16 6=A15 7=A14 8=A13 9=BS0 11=BS1 \| 12=MA14' 13=MA13' 14=/SLAPCS 15=/IOSEL 16=/COM 17=/ROM2 18=/ROM1 19=/ROM0. rtl/main/vind_addr_decode.sv:14 Fuse map decoded from the PAL dump with `jedutil`, re-checked against the sheet: rtl/main/vind_addr_decode.sv:30 The 2C slapstic socket is believed unpopulated (sheet 4). rtl/main/vind_addr_decode.sv:36 ---- LS139 4J (sheet 4) ------------------------------------------------ rtl/main/vind_addr_decode.sv:44 ---- LS138 7/8B (sheet 3) ---------------------------------------------- rtl/main/vind_addr_decode.sv:49 `CA20`, `CA16`, `CA5`, `CA4` are the buffered copies of the CPU's A20/A16/A5/A4 (the A1..A16 buffers are 7E/8E on sheet 4; CA20's buffer is on the video sheets, so it is taken here as a straight copy of A20). rtl/main/vind_addr_decode.sv:66 ---- derived control (sheet 4) ----------------------------------------- rtl/main/vind_addr_decode.sv:76 2C slapstic socket empty -> the PAL's BS inputs float HIGH (sheet 4). rtl/main/vind_addr_decode.sv:87 ---- common-bus qualifiers, from the video sheets (sheet 3) ---- rtl/main/vind_addr_decode.sv:91 ---- PAL 3C ---- rtl/main/vind_addr_decode.sv:101 ---- LS139 4J ---- rtl/main/vind_addr_decode.sv:137 ---- LS139 4J -------------------------------------------------------- rtl/main/vind_cpu.sv:3 Vindicators main CPU wrapper — MC68010 at 5D, SP-317 sheet 4. rtl/main/vind_cpu.sv:10 The part on the board is a 68010 (sheet 4, 64-pin DIP at 5D, CLK = RCLKA = 7.15909 MHz). rtl/main/vind_cpu.sv:18 This wrapper presents the sheet's own active-high `BAS` and an active-high `dtack` to the rest of the main board, and A23..A1 with no A0 — there is no A0 pin on a 68010 and none anywhere on this board; the byte lane is /UDS //LDS and no rtl/main/vind_cpu.sv:30 * `/AS`, `/UDS`, `/LDS` and `R//W` are driven from a `cpu_cen`-gated state machine, so every strobe edge lands on an RCLKA boundary — the same edges the 8D LS163A samples (`vind_dtack`, /CLR = BAS, CK = RCLKA). rtl/main/vind_cpu.sv:35 One extra RCLKA in the LS163A therefore becomes exactly one extra RCLKA of bus cycle, so the sheet's table maps one-for-one: 0 waits for ROM and the write strobes, 1 for /EEPROM, stall until PVCPU for /VRAM, stall until EWAI for rtl/main/vind_cpu.sv:43 Nothing on this board looks at that: every terminator is /DTACK off the LS163A, /BERR is tied high (no timeout), and the video side re-times its own accesses through PVCPU / EWAI. rtl/main/vind_cpu.sv:48 ---- /VPA and autovectors ---------------------------------------------- Sheet 4: `/VPA = ~(BAS & FC0 & FC1 & FC2)`, so every interrupt acknowledge is autovectored. rtl/main/vind_cpu.sv:140 CPU generic defaults to "01" (68010) in TG68K.vhd; the ghdl-generated netlist bakes it in, so it is not overridden here (works for both). rtl/main/vind_dtack.sv:3 Vindicators /DTACK and wait-state sequencer — SP-317 sheet 4, gate for gate (8D 74LS163A + 22F 74S74 + 23E/7D LS02 + 5F S32 + 22D LS10 + 24E LS86). rtl/main/vind_dtack.sv:7 Modelled on the Xybots core's `xybots_dtack.sv` (GPL-3.0); the counter, the load vector and the COM grant latch below are Vindicators' own, read off SP-317 sheet 4. rtl/main/vind_dtack.sv:35 ---- the sequencer ----------------------------------------------------- 22F 74S74 D = sd, CK = RCLKB, /PRE = /CLR = PR4 (inactive) Q -> 8D ENT 8D LS163A CK = RCLKA, /CLR = BAS (SYNCHRONOUS), /LD = QC (SYNCHRONOUS) ENT = 22F Q, ENP = rtl/main/vind_dtack.sv:87 PAL 3C /COM rtl/main/vind_dtack.sv:123 ---- 22F 74S74, clocked by RCLKB ------------------------------------ rtl/main/vind_dtack.sv:129 ---- 8D 74LS163A, clocked by RCLKA ---------------------------------- rtl/main/vind_eeprom_2804.sv:3 Vindicators X2804A (512 x 8) EEPROM at 1C + the 18E LS74 unlock latch — SP-317 sheet 4. rtl/main/vind_eeprom_2804.sv:6 Ported from the Xybots MiSTer core's `xybots_eeprom_2804.sv` (itself from Toobin's `toobin_eeprom_2804.sv`), GPL-3.0, and re-derived against the SP-317 sheet-4 wiring. rtl/main/vind_inputs.sv:3 Vindicators player / status input ports — SP-317 sheet 3 (1/2B, 3B, 6B LS244 and 9B LS367A). rtl/main/vind_inputs.sv:7 Shaped after the Xybots core's `xybots_inputs.sv` (GPL-3.0); the bit map is Vindicators' own, read off SP-317 sheet 3. rtl/main/vind_inputs.sv:10 ---- the three switch buffers ------------------------------------------ 1/2B LS244A (/PL1, 0x260000), 3B LS244B (/PL2, 0x260010) and 6B LS244C (/PL3, 0x260020) each drive the HIGH byte only, with BOTH enables tied to their strobe. rtl/main/vind_inputs.sv:22 Sheet 12's legend numbers the bits the other way round ("D15 (Switch 1) ... rtl/main/vind_inputs.sv:23 Sheet 3 is the wiring and wins; sheet 12 is just numbering bits top-down. rtl/main/vind_inputs.sv:27 ---- the status byte (9B LS367A, enabled by /PL2) ---------------------- CD0 = /VBLANK (video sheets) CD1 = S-TEST (self-test switch, pulled up by R68 -> 1 = not pressed) CD2 = /SINT (SCOM FULL, sheet 2 — sound -> main byte waiting rtl/main/vind_inputs.sv:37 ---- the unpopulated LETA / ADC0809 low byte (sheet 3) ---------------- 13B (LETA quadrature) would drive CD0-CD7 during /PL1 and 11B (ADC0809) during /PL3. rtl/main/vind_inputs.sv:39 Neither is populated on Vindicators (sheet 12 lists no analog entry, MAME declares the low bytes IPT_UNUSED, and the cabinet has only twin digital sticks), so those lanes read the floating/pulled-up bus = 0xFF. rtl/main/vind_inputs.sv:64 the 9B LS367A byte, for observation in simulation rtl/main/vind_inputs.sv:73 CD5 — LS367A pin 2 is a bare stub rtl/main/vind_irq.sv:3 Vindicators interrupt encoding — SP-317 sheet 4 (21E LS08, R79/R80, 9F LS11, 20E LS00). rtl/main/vind_irq.sv:7 Shaped after the Xybots core's `xybots_irq.sv` (GPL-3.0); the encoding is Vindicators' own, read off SP-317 sheet 4. rtl/main/vind_irq.sv:24 /SINT is the SCOM's `FULL` pin, a push-pull output (sheet 2), so that half is settled; /VINT comes from the VIRQ latch on the video sheets, so the asymmetry is (inferred). rtl/main/vind_irq.sv:45 ---- acknowledge -------------------------------------------------------- /VACK (sheet 3 LS138 Y0, write 0x360000) clears the VIRQ latch, which lives on the VIDEO sheets — so this module takes /VINT as an input and exports the /VACK strobe rtl/main/vind_irq.sv:57 /SINT — SCOM FULL, sheet 2 rtl/main/vind_main_bus.sv:3 Vindicators main board — SP-317 sheets 2, 3 and 4 as one block. rtl/main/vind_main_bus.sv:10 Composes: vind_cpu (TG68K in 68010 mode) + vind_addr_decode (PAL 3C, LS139 4J, LS138 7/8B) + vind_dtack (8D LS163A sequencer + the EWAI latch) + vind_irq + vind_watchdog (22M/N LS197 + the sheet-2 one-shot) + vind_eeprom_2804 (1C + the 18E rtl/main/vind_main_bus.sv:16 The memory map, the wait-state table and the schematic-vs-MAME decisions are documented in the submodule headers; this one records the composition. rtl/main/vind_main_bus.sv:30 The SCOM mailbox toward the JSA I board — the SCOM device itself (14/15B on sheet 2, both halves of the 4-wire serial link) is `rtl/sound/vind_scom.sv`. rtl/main/vind_main_bus.sv:36 ---- two buses, not one ------------------------------------------------ Sheet 4 gives the 7E/8E LS244 and 8C/7C LS245 enables as `/EWAI`, and EWAI = ~(ENOWAI + /COM), asserted only for /COM cycles. rtl/main/vind_main_bus.sv:42 * sheet 6 — VRAM 1M/2M/2N/1N is addressed by MA1..MA16 (the always-enabled 3D/3E LS244s) and sits on the raw 68010 D0-D15, through 3L/3K LS373 (read, G = VCPU, /OC = /VRAMRD = /VRAM + W//R) and 4L/4K LS244 (write, /G = VR//W). rtl/main/vind_main_bus.sv:45 `/CLRAM = MA16` splits CRAM off, and sheet 10 puts the CRAM CPU port on the same raw D bus, direction `VW//R`. rtl/main/vind_main_bus.sv:48 * so `/EWAI` gates only the I/O block on sheet 3 — the three LS244 switch ports, the 9B LS367A status byte, the SCOM and the 10B LS174. rtl/main/vind_main_bus.sv:54 ---- CDS, /CIO and CW//R ----------------------------------------------- All three are generated on sheet 5 (the unpopulated ECPU sheet), not on the video sheets: 23D LS158A muxes the two CPUs (`SEL = EWAI`, B = the main CPU), 20D LS32 rtl/main/vind_main_bus.sv:63 `/CIO` is the one thing the schematic does not settle: PAL 21D is undumped, but R78 470R ties `/CIO` to `/COM`, so `/CIO = /COM` (inferred). rtl/main/vind_main_bus.sv:92 3D/3E LS244, ALWAYS driven (sheet 4) rtl/main/vind_main_bus.sv:97 23D LS158A on sheet 5 (= A20 here) rtl/main/vind_main_bus.sv:102 synthesised from sheet 5, see header rtl/main/vind_main_bus.sv:103 synthesised from sheet 5, see header rtl/main/vind_main_bus.sv:176 Decode (PAL 3C + LS139 4J + LS138 7/8B) rtl/main/vind_main_bus.sv:193 The slapstic socket 2C is empty (sheet 4): /SLAPCS reaches nothing. rtl/main/vind_main_bus.sv:234 Program ROM address (sheet 4: the six EPROMs in three 128 KB banks) rtl/main/vind_main_bus.sv:244 This is the bus the program EPROMs, the EEPROM, the PAL, the VRAM (sheet 6) and the CRAM (sheet 10) all hang off. rtl/main/vind_main_bus.sv:255 Sheet 5: 23D LS158A (SEL = EWAI) then 20D LS32 (9,10->8). rtl/main/vind_main_bus.sv:258 PAL 21D, undumped; R78 rtl/main/vind_main_bus.sv:329 Inputs (1/2B, 3B, 6B LS244 + 9B LS367A) and the 10B LS174 rtl/main/vind_main_bus.sv:373 VRAM (3L/3K LS373, /OC = /VRAMRD) and CRAM (sheet 10) drive the RAW D bus — no /EWAI, no PVCPU: the LS373 holds the word the CPU slot fetched until /VRAMRD releases at the end of the cycle. rtl/main/vind_main_bus.sv:407 DTACK / wait states (8D LS163A + 22F 74S74 + the EWAI latch) rtl/main/vind_out_latch.sv:3 Vindicators output latch 10B 74LS174B — SP-317 sheet 3. rtl/main/vind_out_latch.sv:30 Two of the six outputs (`/ERESET`, `PRBK`) leave sheet 3 for the video sheets and are exported here; `LTEST`/`LRESL` reach only the unpopulated LETA and are therefore genuinely inert on this board. rtl/main/vind_watchdog.sv:3 Vindicators watchdog / reset counter — SP-317 sheet 4 (22M/N 74LS197, 18L LS08, the WDIS jumper) plus the sheet-2 power-on one-shot. rtl/main/vind_watchdog.sv:15 22M/N 74LS197 (dual counter: CK1 -> QA divide-by-2; CK2 -> QB,QC,QD /8) pin 13 /CLR = POWER-ON (sheet 2) rtl/main/vind_watchdog.sv:28 Sheet 12 says "128 msec. rtl/main/vind_watchdog.sv:34 ---- one departure from the sheet -------------------------------------- Sheet 4 calls the C/L load "synchronous". rtl/main/vind_watchdog.sv:50 sheet 2: R152 100 k x C60 0.1 uF ~ 10 ms (plus the Darlington Vbe) rtl/main/vind_watchdog.sv:67 ---- sheet 2: the power-on one-shot --------------------------------- rtl/main/vind_watchdog.sv:79 ---- 22M/N 74LS197 --------------------------------------------------- CK1 and CK2 are NEGATIVE-edge triggered; /VBLANK falls at the START of vertical blank, and QA's own falling edge clocks the divide-by-8 half. rtl/mem/vind_char_rom.sv:3 Vindicators alphanumeric character ROM — the 27128 at 15/16N (SP-317 sheet 7), 16 K x 8 in one M10K-backed BRAM. rtl/mem/vind_char_rom.sv:9 ---- the board (sheet 7) ------------------------------------------------- A13..A4 = AP9..AP0 the character code, alpha word D9:0 A3..A1 = 4V, 2V, 1V the pixel row inside the 8x8 cell rtl/mem/vind_char_rom.sv:21 Unlike the graphics ROMs this data is NOT inverted anywhere: MAME applies ROMREGION_INVERT to `sprites_pf` only, and sheet 7's shifters take the ROM bits straight. rtl/mem/vind_cpurom_sdram.sv:3 Vindicators 68010 program ROM out of SDRAM — the six 27512s at 1D/2D, 1F/2F, 1K/2K (SP-317 sheet 4) behind a prefetching set-associative cache. rtl/mem/vind_cpurom_sdram.sv:14 But sheet 4 gives ROM cycles zero wait states: the 8D LS163A loads 15 the moment BAS rises and RCO asserts /DTACK immediately, with no term that depends on the ROM at all. rtl/mem/vind_gfx_mem.sv:13 ---- what one request IS on the board (SP-317 sheet 9) ------------------- The sixteen graphics ROM sockets are wired as four quadrants, one per pixel bit-plane, all sharing ONE address bus: rtl/mem/vind_gfx_mem.sv:36 GA15 exists on the board but is not decoded by the fitted ROMs (sheet 8), so the caller drops it. rtl/mem/vind_gfx_mem.sv:44 (MAME's ROMREGION_INVERT is the same fact applied at load time; this core keeps the board's polarity so sheet 10's PAL equations can be written verbatim.) then drop _req; the arbiter waits for the drop, so one request = exactly on rtl/mem/vind_gfx_mem.sv:54 ---- budget --------------------------------------------------------------- Sheet 6 alternates the graphics ROM between the playfield and the motion object every 4 pixel clocks (MO//PF = 4HDL), and each layer's SLAGS pair is reloaded once p rtl/mem/vind_mem.sv:41 PAL 3C decodes /ROM0..2 from the address alone, so `prog_rd` is asserted throughout the download even though the CPU is in reset, and a cache that fills from a not-yet-written SDRAM would hold zeros for ever. rtl/mem/vind_mem.sv:59 WARNING: sheet 4 gives ROM cycles zero wait states and `vind_main_bus` implements that literally, so on a cache miss the CPU would latch stale data. rtl/mem/vind_mem.sv:255 PAL 3C decodes /ROM0..2 from the address alone (sheet 4: there is no BAS term on those outputs), so `prog_rd` is HIGH at prog_a = 0 for the whole download, while the 68010 is still held in reset — and without this term the cache fills line rtl/mem/vind_rom_loader.sv:28 maincpu is emitted as BIG-ENDIAN INTERLEAVED WORDS — the MAME even-offset ROM (the `1x` sockets 1D/1F/1K, sheet 4, D15:8) is `map="01"`, the FIRST byte of each output word. rtl/mem/vind_rom_loader.sv:36 * sprites_pf is emitted as a FOUR-WAY BYTE INTERLEAVE of the four bit planes, plane 0 (MSD0/PSD0) first, so the four plane bytes of one graphics address are consecutive and one 32-bit read returns the whole 8-pixel row the sheet 9 SLAGS pai rtl/mem/vind_sdram_loader.sv:18 prog : the MRA interleaves the six 27512s into BIG-ENDIAN 68010 words, so the EVEN download byte is D15:8 (the `1x` sockets at 1D/1F/1K, sheet 4) and the ODD byte is D7:0. rtl/video/vind_alpha.sv:3 Vindicators — SP-317 sheet 7 (`ALPHA`): the AP pipeline latch, the alpha control-word decoder, the VIRQ latch, the character ROM and its shifters, the playfield vertical counter and the motion-object X-scroll latch. rtl/video/vind_alpha.sv:13 14M LS273K (CK = 4H) : MATCH->MATCHD, VRD14->AP14, VRD13->AP13, VRD11..VRD8 -> AP11..AP8, VRD15 -> BARE STUB 14L LS273A (CK = 4H) : VRD7..VRD0 -> AP7..AP0 VRD12 is latched NOWHERE on sheet 7 and there is no AP12 net. rtl/video/vind_alpha.sv:16 That is not a missing bit: the alpha attribute bits D15, D12, D11 and D10 are latched INSIDE the GPC custom (15J/K pins 22..25, sheet 10) straight off the raw VRD bus, and D14/D13 come back as APAL4/APAL3 from 13M here. rtl/video/vind_alpha.sv:46 One byte is four pixels of two bit planes; 19N/18N LS194A parallel-load on H03 and shift right for the other three FCLOCKs, so QD emits O7,O6,O5,O4 (APIX1, the pen MSB) and O3,O2,O1,O0 (APIX0). rtl/video/vind_alpha.sv:56 19K/11L/13L LS163A, CK = 4H, /LD = /PFVS (AP8..AP0), ENT = PFHST (one pulse per line), ENP = /VBLANK (FROZEN during vertical blanking), /CLR = PR2. rtl/video/vind_alpha.sv:65 19M/N LS74 + 10L/10M LS175, CK = /MOHS, /CLR = /SYSRES, taking the /Q outputs, so `/PF256L../PF1L` is the ONE'S COMPLEMENT of the 9-bit MO X scroll -- which is what sheet 8's LS283 chain wants (subtract by add of complement). rtl/video/vind_alpha.sv:78 sheet 4 22M/N LS197, active high here rtl/video/vind_alpha.sv:89 6F Q2 -- the LS194A parallel-load window rtl/video/vind_alpha.sv:99 21E LS08 on sheet 8 rtl/video/vind_alpha.sv:100 14M LS273K Q12 rtl/video/vind_alpha.sv:114 sheet 3, write 0x360000 rtl/video/vind_alpha.sv:115 18E LS74 /Q -> sheet 4's IPL network rtl/video/vind_alpha.sv:148 ap[12] has NO board net (VRD12 is latched nowhere on sheet 7) and is held at 0 so nothing can accidentally consume it. rtl/video/vind_alpha.sv:175 13M LS174A -- CK = /4HDF [inferred] rtl/video/vind_alpha.sv:177 Sheet 7 gives 13M's clock as `/4HDF`, a name that appears nowhere else in SP-317; the obvious reading is a drawing typo for `/4HDD` (SYNGEN pin 36). rtl/video/vind_alpha.sv:222 Character ROM and the 19N / 18N LS194A shifters rtl/video/vind_alpha.sv:246 v[7:3]: the alpha ROW index is formed on sheet 6, not here. rtl/video/vind_alpha.sv:247 vrd[15]/vrd[12]: latched inside the GPC (sheet 10), never on this sheet. rtl/video/vind_alpha.sv:253 19K / 11L / 13L LS163A -- the playfield vertical counter rtl/video/vind_cram.sv:3 Vindicators — SP-317 sheet 10: the 2048 x 16 colour RAM (16K + 18K, 2K8-45A) and its CPU port. rtl/video/vind_cram.sv:79 ---- the CPU's own read port ------------------------------------------ Clocked at clk_sys, NOT at ce_7m, for exactly the reason `vind_vram`'s read is: the board's 16K/18K are ASYNCHRONOUS 2K8-45A static RAMs, so during the CPU's one RCLKA rtl/video/vind_cram.sv:95 3L/3K LS373 (sheet 6): transparent while the CPU owns the array, latched on the falling edge of that slot, driven onto D15:0 while /VRAMRD is low. rtl/video/vind_gfx_hold.sv:10 ---- what the board does -------------------------------------------------- SP-317 sheet 9: the sixteen graphics EPROMs are asynchronous and permanently enabled. rtl/video/vind_intensity_dac.sv:3 Vindicators — SP-317 sheet 10 (the 18M LS283 intensity adder, the 18D / 18F registers and the 17M/17L output registers) and sheet 11 (the RGBI current DACs, the ZREF reference and the all-zero clamps). rtl/video/vind_intensity_dac.sv:10 THE INTENSITY ADDER (sheet 10) rtl/video/vind_intensity_dac.sv:21 BLANKING (sheet 10, sheet 11) rtl/video/vind_intensity_dac.sv:30 THE LADDER (sheet 11) rtl/video/vind_intensity_dac.sv:119 The blanking level is still colour code 0 -- there is no separate pedestal (sheet 11), which is the only thing the clear was there to say. rtl/video/vind_mo.sv:3 Vindicators — the motion-object engine: SP-317 sheet 8 (`MO-CTRL`) plus the two line-buffer customs on sheet 10. rtl/video/vind_mo.sv:8 This module is only the wiring between `vind_mo_fetch` (the PAL 7N sequencer, the word latches, the adders, the two undumped PROMs and the MO half of the SLAGS shifters) and `vind_mo_linebuf` (14D/14E and the PAL 17E write sequencer). rtl/video/vind_mo.sv:13 ---- the list walk, in one paragraph ------------------------------------ Sheet 6's NXLDL cycle reads the SLIP word for band PFV >> 3 out of alpha row 31 and 7L/7J latch its D9:0 into LNK9..LNK0. rtl/video/vind_mo.sv:55 ---- back to sheet 6 / 7 ---- rtl/video/vind_mo.sv:62 ---- to the priority / GPC block (sheet 10) ---- rtl/video/vind_mo.sv:77 PAL 7N pin 13 (see vind_mo_fetch.sv) rtl/video/vind_mo_fetch.sv:3 Vindicators — SP-317 sheet 8 (`MO-CTRL`): the PAL16R6A 7N slot sequencer, the 4J LS139 word strobes, the four motion-object word latches, the X adders, the two undumped bipolar PROMs, the graphics-address counters, the MATCH flip-flops and rtl/video/vind_mo_fetch.sv:11 PAL16R6A 7N = 136059-1153 -- a dumped PAL, implemented VERBATIM rtl/video/vind_mo_fetch.sv:14 jedutil prints the sum-of-products that drives each pin LOW, so `pin = ~SOP` and, for the registered pins, `Q = SOP` with the pin showing `~Q`. rtl/video/vind_mo_fetch.sv:54 Sheet 6's 6F LS174C registers PVAS into VAS, so the RAM cycle happens one RCLKA later than the code above names it. rtl/video/vind_mo_fetch.sv:58 THE TWO UNDUMPED PROMs (sheet 8, [inferred]) rtl/video/vind_mo_fetch.sv:60 11N 82S147 (512x8) and 9J 82S129 (256x4) are NOT in the MAME ROM set and cannot be read off the drawing. rtl/video/vind_mo_fetch.sv:96 Sheet 8 routes PICTD/HORZD/VERTD through 7F LS175D first, so on the board the word latches clock on the RCLKA edge that ENDS the LS139 strobe cell (7F /Q = the active-high strobe, whose RISING edge is that boundary) and the 21F MATCH flip-f rtl/video/vind_mo_fetch.sv:106 phase 0 : /GLD with MO//PF high -> the SLAGS load the MO column phase 2 : /LD01 -> 8K/8J take MAT, 9K takes the width, and the 14D/14E write pointers take HPOS (they present it from phase 3) phase 3 : 4H's RISING edge -- 12M LS378C and the rtl/video/vind_mo_fetch.sv:144 14M LS273K Q12 rtl/video/vind_mo_fetch.sv:151 ---- to sheet 6 ---- rtl/video/vind_mo_fetch.sv:157 ---- to sheet 7 ---- rtl/video/vind_mo_fetch.sv:160 ---- to sheet 10 ---- rtl/video/vind_mo_fetch.sv:169 PAL 7N pin 13 IS the board's /BUFCLR (see section 3 below) rtl/video/vind_mo_fetch.sv:178 PAL 7N -- state rtl/video/vind_mo_fetch.sv:237 4J LS139 -- the four MO word strobes (sheet 8) rtl/video/vind_mo_fetch.sv:250 7F LS175D -- the strobe pipeline and the line-buffer bank (sheet 8) rtl/video/vind_mo_fetch.sv:257 Not settled by the schematic: sheet 8 also shows /BUFCLR on 7F's /CLR, and that cannot be taken literally -- an asynchronous clear on THIS register would pin the bank at 0 and there would be no ping-pong at all. rtl/video/vind_mo_fetch.sv:279 The four word latches (sheet 8) rtl/video/vind_mo_fetch.sv:298 GA15 (mo_tile[15]) is not decoded by the graphics ROM (sheet 9). rtl/video/vind_mo_fetch.sv:311 10J / 10K / 4N -- HPOS = MO_X - MO_XSCROLL (sheet 8) rtl/video/vind_mo_fetch.sv:315 ---- 12M LS378C -- the snapshot register (sheet 8) --------------------- 12M : CK = 4H , /G = /NEWMO D4 = MFLP -> Q5 ; D13/D3/D6 = 12N S3/S2/S1 (= diff[2:0]) -> the GP4V/GP2V/GP1V side of 12L ; D14 = MATCH -> Q15 -> 20F = GPEN. rtl/video/vind_mo_fetch.sv:376 Vertical match (sheet 8) rtl/video/vind_mo_fetch.sv:385 9J 82S129 + 9K LS169 -- the width counter and /END (sheet 8) rtl/video/vind_mo_fetch.sv:387 The preset is HSIZ -- the object's width minus one -- which is exactly the three bits sheet 8's "9K D (pin 6) = GND" leaves room for, and it is the only value that draws HSIZ + 1 columns: rtl/video/vind_mo_fetch.sv:417 Not settled by the schematic: sheet 8 reads 9K's CK as 4HD3 and its /LD as /LD01, but /LD01 is low only in phase 2 while 4HD3 rises in phase 7, so a LITERAL LS169 -- synchronous load -- would never take the preset at all. rtl/video/vind_mo_fetch.sv:423 That is the only reconstruction in which the SAME three-bit 82S129 output produces both required behaviours: rtl/video/vind_mo_fetch.sv:448 21F LS74 + 21E LS08 -- MATCH (sheet 8) rtl/video/vind_mo_fetch.sv:467 11N 82S147 + 10N/9N LS169 + 8N/7M LS283 -- the graphics address rtl/video/vind_mo_fetch.sv:469 Sheet 8 wires the 82S147's address from the LIVE nets -- A8 = /VMATCH, A7 = MFLP (9L), A6/A4/A3 = HSIZ (9L), A2:A0 = 14N S4:S2 -- not from 12M, and 10N/9N reload from it on EVERY 4H while /NEWMO is asserted. rtl/video/vind_mo_fetch.sv:480 10N / 9N LS169: CK = 4H (sheet 8), /LD = /NEWMO, U//D = 6D LS04 from the snapshotted MFLP (12M Q5) -- the direction has to survive the whole locked-on fetch, so it cannot be the live 9L bit. rtl/video/vind_mo_fetch.sv:556 12M LS378C / 12L LS257C / 20F LS32 (sheet 8) and the MO SLAGS half rtl/video/vind_mo_fetch.sv:602 Every consumer -- the 17D/17E PAL equations, the 14D/14E line buffers and the GPC's M bus -- wants exactly that sense. rtl/video/vind_mo_linebuf.sv:3 Vindicators — SP-317 sheet 10: the two Atari "LB" line-buffer customs 14D (pixel/colour plane) and 14E (attribute plane), the 14F LS32 bank strobes, the 16F LS32 intensity-kludge gates and the PAL16L8A at 17E (136059-1152) that sequences th rtl/video/vind_mo_linebuf.sv:12 17E = 136059-1152 -- a dumped PAL, implemented VERBATIM rtl/video/vind_mo_linebuf.sv:41 Sheet 10 records 17E pin 1 as `21E LS08 (9,10 -> 8) = MCKR & FCLOCK`. rtl/video/vind_mo_linebuf.sv:87 ---- the LB custom's own output stage -------------------------------- The 40-pin Atari LB does not present the addressed cell straight on DO7..DO0: Gauntlet builds the same buffer out of discrete counters and '189s and still ends it in the rtl/video/vind_mo_linebuf.sv:121 ---- 14E read side, latched by 18D LS373 on sheet 10 ---- rtl/video/vind_mo_vmatch.sv:3 Vindicators — SP-317 sheet 8: the motion-object VERTICAL MATCH. rtl/video/vind_mo_vmatch.sv:33 14N S4:S2 is `(diff[5:3] + VSIZ + 1) mod 8` = the TILE ROW within the object counted from the top; it addresses the 82S147 at 11N. rtl/video/vind_pf.sv:3 Vindicators — the playfield layer: the PFHS custom (15L/M, Atari 137419-104, SP-317 sheet 7), the playfield word decode and bank latch (sheet 8), the graphics-ROM fetch and the PF half of the SLAGS shifters (sheet 9). rtl/video/vind_pf.sv:8 The PFHS and SLAGS behaviour is derived from `Arcade-Gauntlet_MiSTer/rtl/gauntlet/PFHS.vhd` and `SLAGS.vhd` (c) 2020 d18c7db, GPL-3.0 -- the SAME two Atari customs, whose internals SP-317 does not draw. rtl/video/vind_pf.sv:14 THE PLAYFIELD WORD (sheet 8) rtl/video/vind_pf.sv:16 5M LS374A (CK = /4H, /OC = MO//PF) : VRD15..VRD8 Q19 = PFHF (= VRD15, the tile's HORIZONTAL FLIP) and -> 5N D13 Q16,Q15,Q12 -> 5N (VRD14..VRD12) Q9..Q2 = GA11..GA8 3M LS374B (same clocks) : VRD7..VRD0 -> GA7..GA0 5N LS175B rtl/video/vind_pf.sv:27 PFHS (sheet 7) rtl/video/vind_pf.sv:29 * a 9-bit latch on HS (/PFHSLD) -- the playfield X scroll; * a 9-bit latch on SPC (/PFSPC) -- the "special" register; * a 6-bit counter loaded with scroll[8:3] at every ST (/PFHST, once per line) and incremented on 4H -> PF8H..PF256H, th rtl/video/vind_pf.sv:44 PFX AND THE COLOUR ADDRESS (sheet 10, and the ambiguity it raises) rtl/video/vind_pf.sv:47 Sheet 10 then holds GPC pin 32 (`P4`) at logic 0 through R87 1K / R86 10R, so ONE of the eight PFX bits never reaches the colour address. rtl/video/vind_pf.sv:117 PF256H..PF8H -> sheet 6's VRAM mux rtl/video/vind_pf.sv:120 5M Q19 -> 12L LS257C 4B rtl/video/vind_pf.sv:157 5M / 3M LS374 and 5N LS175B / 6N LS174 rtl/video/vind_pf.sv:173 Either 5N's clock is not the same edge as the 5M/3M word latch (sheet 8 draws it as "[4HD3]", in brackets, i.e. uncertain), or 6N's stage is in the PS0..PS3 path rather than PS4..PS7. rtl/video/vind_pf.sv:188 Graphics fetch (sheet 9) and the PF half of the SLAGS rtl/video/vind_pf.sv:191 Row = PF4V/PF2V/PF1V through 12L LS257C's B side. rtl/video/vind_pf.sv:208 latch 8B in SLAGS.vhd rtl/video/vind_pf.sv:265 PFHS pins 25..17 take PS7..PS4 from 6N and PSD3..PSD0 STRAIGHT from the SLAGS (sheet 7), so the low nibble enters the delay RAM in the board's active-low sense and the RAM's inverting outputs turn it back into the active-high pen on PFX3..P rtl/video/vind_pf.sv:280 4D latch, inverted data rtl/video/vind_prio_gpc.sv:3 Vindicators — SP-317 sheet 10: the PAL16L8A at 17D (136059-1151, MO-pen-1 / SHADE / PF-M priority), the seven 13F/15F LS32 OR gates, the GPC custom 15J/K (Atari 137419-101), the 13J LS253C alpha/MO substitution, the 12F LS174D one-pixel pip rtl/video/vind_prio_gpc.sv:10 The GPC's internals are derived from `Arcade-Gauntlet_MiSTer/rtl/gauntlet/GPC.vhd` (c) 2020 d18c7db, GPL-3.0 -- the SAME Atari custom (137419-101), whose internals SP-317 draws as a black box. rtl/video/vind_prio_gpc.sv:13 Every wire around it is Vindicators' own and cited to sheet 10. rtl/video/vind_prio_gpc.sv:17 17D = 136059-1151 -- a dumped PAL, implemented VERBATIM rtl/video/vind_prio_gpc.sv:35 `PF/M` on pin 13 is the NET from sheet 7's PFHS custom (the per-playfield- colour "playfield in front of the MO" bit selected out of the /PFSPC register by PFX[2:0]); `PF/M` on GPC pin 18 is a PIN NAME inside the custom's box. rtl/video/vind_prio_gpc.sv:41 13F / 15F -- the MO bus into the GPC (sheet 10) rtl/video/vind_prio_gpc.sv:48 THE GPC (sheet 10, internals from the Gauntlet model) rtl/video/vind_prio_gpc.sv:50 3H latch (H03 & /4H) : D3..D0 = VRD15, VRD10, VRD11, VRD12 3F latch : 3F2 = D3 (alpha OPAQUE), ALC2..ALC0 = D2..D0 rtl/video/vind_prio_gpc.sv:69 Sheet 7 leaves the latched VRD15 as a bare stub and never latches VRD12 at all, and asks where APAL2..APAL0 come from. rtl/video/vind_prio_gpc.sv:73 APAL4 = D14 and APAL3 = D13 arrive separately from 13M on sheet 7 and are substituted onto CRA8/CRA6 by 13J. rtl/video/vind_prio_gpc.sv:77 THE COLOUR-RAM ADDRESS (sheet 10) rtl/video/vind_prio_gpc.sv:86 A8 = CA8 + (SHADE_delayed & CA9) -- 18L LS08 + 13F LS32 A9 = CA9 A10 = STAIN -- 19M/N LS74 through 12F Q7 CPU (via 14K LS257B and 19K LS244N): A10 = MA11, A9 = MA10 (the GPC's MA1/MA0 pins are BOTH tied to M rtl/video/vind_prio_gpc.sv:108 Sheet 10 records the GPC's alpha attribute pins as D3 = VRD15, D2 = VRD10, D1 = VRD11, D0 = VRD12 -- a scrambled order (Xybots' GPC is scrambled too, differently). rtl/video/vind_prio_gpc.sv:141 ---- CPU / colour-RAM select (sheet 6) ---- rtl/video/vind_prio_gpc.sv:184 The GPC's own 3H latch takes the raw alpha attribute nibble off VRD on the same edge as sheet 7's 14M/14L: the ce_7m edge that ENDS the alpha slot (phase 3), which is 4H's rising edge. rtl/video/vind_prio_gpc.sv:196 3F latch rtl/video/vind_prio_gpc.sv:204 only VRD15, VRD12..VRD10 reach the GPC's D pins (sheet 10). rtl/video/vind_prio_gpc.sv:232 12F LS174D -- the one-pixel pipeline (CK = FCLOCK) rtl/video/vind_prio_gpc.sv:267 13J LS253C and the 11-bit CRAM address rtl/video/vind_prio_gpc.sv:275 /PRAM = ~/CLRAM, so /PRAM is low (13J driving) in every video slot and high (13J tri-stated) in a CPU colour-RAM cycle -- where 19K LS244N drives CRA8..CRA1 from MA8..MA1 instead. rtl/video/vind_syngen.sv:4 Carried over from the Xybots core (SP-313 sheet 4, the same Atari part on the same crystal) and re-verified against SP-317 sheet 6. rtl/video/vind_syngen.sv:15 SP-317 draws only its pinout, so its internal behaviour is reconstructed from the same part as implemented discretely on Atari System 1 (SP-277) and modelled in `Arcade-Gauntlet_MiSTer/rtl/gauntlet/SYNGEN.vhd` (d18c7db, GPL-3.0) + its `RO rtl/video/vind_syngen.sv:22 * a 9-bit horizontal counter cleared by NXL, * an 82S153 PLA (Atari 136032-103) decoding H into NXL/HSYNC/HBLANK/LMPD/PFHST/BUFCLR/C0/C1/C2, all of them taken through one register (the "7E" 74S174), * an 8-bit vertical counter plus one extr rtl/video/vind_syngen.sv:41 PIN DIRECTIONS, AS READ OFF SP-317 SHEET 6 rtl/video/vind_syngen.sv:43 This module started as the Xybots core's SYNGEN (SP-313 sheet 4, the same Atari custom on the same 14.318181 MHz crystal), so it carries the UNION of the two boards' pin sets and vind_video ties off what Vindicators leaves bare. rtl/video/vind_syngen.sv:46 SP-317 sheet 6 is the authority for this board: rtl/video/vind_syngen.sv:57 Three differences from the Xybots reading, all from sheet 6: * NXL (pin 21) IS wired here -- it starts the SLIP fetch once per line, and PAL 7N's own product terms fix its phase (see section 2 below); * /PFHST (pin 28) IS wired here -- Vind rtl/video/vind_syngen.sv:66 The vertical counter is inside the custom -- there is no 256V net anywhere in the package, which is why the line total can only come from its own dumped PROM (see above). rtl/video/vind_syngen.sv:97 Designators are SP-313 sheet 4's; on SP-317 sheet 6 the same squarers are 23F ---- rtl/video/vind_syngen.sv:99 14M (8B 74S04 1->2) rtl/video/vind_syngen.sv:100 /14MP (8B 74S04 13->12) rtl/video/vind_syngen.sv:101 7M (7B 74S74 Q) rtl/video/vind_syngen.sv:102 /7M (7B 74S74 /Q) rtl/video/vind_syngen.sv:103 DCLK (9B 74S74 Q) rtl/video/vind_syngen.sv:104 RCLK (1C 74S74 Q, /PRE = DCLK) rtl/video/vind_syngen.sv:105 VIDCLK (11J 74S04 3->4 from /CKO) rtl/video/vind_syngen.sv:106 /VIDCLK (8B 74S04 9->8 from CKO) rtl/video/vind_syngen.sv:129 10E 74S00 (1,2->3) rtl/video/vind_syngen.sv:130 11J 74S04 (9->8) rtl/video/vind_syngen.sv:132 11J 74S04 (11->10) rtl/video/vind_syngen.sv:134 11J 74S04 (1->2) rtl/video/vind_syngen.sv:142 ---- video-RAM access phase (sheet 5 LS253 select) ---- rtl/video/vind_syngen.sv:143 8M 74S32 (4 = /2HD1H, 5 = 4HD2H -> 6) rtl/video/vind_syngen.sv:155 ---- interrupt ---- Sheet 2: 1B LS02 (11 = VBLANK, 12 = /HBLANK -> 13) then 10A LS20 with 4V,2V,1V then 4A LS04 (9->8). rtl/video/vind_syngen.sv:157 The IRQ1 latch is set by `virq_gate & VIRQ`, where VIRQ is alpha-RAM bit 10 latched by 6D LS174E on sheet 7 (see vind_alpha.sv). rtl/video/vind_syngen.sv:162 ---- SP-317 sheet 6 pin usage ------------------------------------------- Vindicators wires SIX SYNGEN pins that Xybots leaves as stubs, and leaves six that Xybots uses. rtl/video/vind_syngen.sv:164 The Vindicators pin map, from sheet 6: rtl/video/vind_syngen.sv:167 pin 22 C2 -> H03 source (via 6F LS174C) -> vrac2 rtl/video/vind_syngen.sv:168 pin 25 LMPD -> /LMPD -> mohr_n pin 35 4HDL -> PF//MO -> h_4hd1h_n pin 36 4HDD -> /4HDD -> h_4hd2h_n and pins 23 (C1), 24 (C0), 34 (4H), 18 (VSCK), 33 (2HDL), 17 (VRES rtl/video/vind_syngen.sv:175 The Vindicators SYNGEN symbol has no BUFCLR pin (all 40 pins are accounted for on sheet 6), and Gauntlet -- the same custom set -- makes the net in discrete logic as /BUFCLR = /LMPD + /4H + 2H + /1H (`Arcade-Gauntlet_MiSTer/rtl/gauntlet/VID rtl/video/vind_syngen.sv:187 SYNGEN pin 21 -- /PNXL (wired on SP-317) rtl/video/vind_syngen.sv:194 clk_sys phase, and the 14M / MCKR chain (SP-317 sheet 6) rtl/video/vind_syngen.sv:212 7B 74S74: D = /7M, CK = 14M -> divide by two, rising with ce_7m. rtl/video/vind_syngen.sv:216 9B 74S74: D = /7M, CK = /14MP. rtl/video/vind_syngen.sv:223 1C 74S74: D = 7M, CK = 14M, /PRE = DCLK (asynchronous), /CLR = PR1 = 1. rtl/video/vind_syngen.sv:233 SYNGEN CKO (pin 29) = CK, /CKO (pin 4) = ~CK; both are re-inverted on the board, so VIDCLK is in phase with 7M and is the 68000 clock (sheet 2). rtl/video/vind_syngen.sv:239 SYNGEN horizontal PLA (Atari 136032-103 / 82S153), inside the SYNGEN black box on SP-317 sheet 6 rtl/video/vind_syngen.sv:248 SP-317 PHASE CORRECTION FOR PIN 21 (/PNXL). rtl/video/vind_syngen.sv:249 On SP-313 pin 21 is a bare stub, so nothing there could observe where the NXL pulse sits relative to 1H/2H/4H, and the System-1 model simply reuses the counter-clear term. rtl/video/vind_syngen.sv:251 On SP-317 the pin is wired, and PAL 7N is hard evidence for its phase: every NXL product term in 7N's equations is qualified by `1H & 2H & 4H`, i.e. PHASE 7, and only with NXL there do the three consumers agree -- * PVAS1:PVAS0 = 10 at phas rtl/video/vind_syngen.sv:284 o16 (C0) and o11 stay unimplemented: pin 24 is a bare stub on SP-317 sheet 6 as well as on SP-313 sheet 4, and the System-1 PLA's /o11 (/BUFCLR) has no pin in the Vindicators symbol -- see the port comment. rtl/video/vind_syngen.sv:287 o12 (/PFHST) IS wired on SP-317 (pin 28 -> sheet 7's PF vertical counter and PFHS `ST`), so its System-1 PLA term is implemented here: /o12 = i4 & i5 & i6 & /i7 & i8 & i9 (h[8:3] == 6'b110111) with i1..i9 = h[0]..h[8]. rtl/video/vind_syngen.sv:297 SYNGEN vertical PROM (Atari 136032-102, 256 x 4), inside the SYNGEN black box on SP-317 sheet 6 rtl/video/vind_syngen.sv:331 The counters and the SYNGEN output register (74S174 "7E" / "7D") rtl/video/vind_syngen.sv:392 Glue around SYNGEN (IC designators are SP-313 sheet 4's; the same circuit sits on SP-317 sheet 6) rtl/video/vind_syngen.sv:402 8B 74S04 rtl/video/vind_syngen.sv:406 10E 74S00 rtl/video/vind_syngen.sv:408 11J 74S04 rtl/video/vind_syngen.sv:414 8M 74S32: VRAC0 = /2HD1H \| 4HD2H. rtl/video/vind_syngen.sv:419 g3b/g6b are the two unnamed intermediate nets on SP-313 sheet 4; /MOHR itself comes out of SYNGEN pin 25. rtl/video/vind_testpat.sv:7 4 bits per channel, matching the CRAM's I:R:G:B 4:4:4:4 word (SP-317 sheet 10); full intensity only. rtl/video/vind_video.sv:3 Vindicators video top — SP-317 sheets 6 (VRAM/SYNGEN), 7 (ALPHA), 8 (MO-CTRL), 9 (GR-MEM), 10 (line buffers / priority / GPC / CRAM) and 11 (RGBI DAC), plus the sheet-5 common-bus signals that terminate here. rtl/video/vind_video.sv:11 ---- the sheet-5 question this module answers --------------------------- Sheet 5's ECPU half is not populated, so /ECOM is never asserted, the 23D LS158A mux is held permanently on the main CPU's side and the main CPU is granted the common rtl/video/vind_video.sv:104 The SYNGEN model is shared with the Xybots core, so it carries the union of the two boards' pin sets; the six pins Vindicators leaves as bare stubs on SP-317 sheet 6 are tied off here. rtl/video/vind_video.sv:141 Sheet 6 -- VRAM, the address multiplexers and the CPU slot rtl/video/vind_video.sv:177 Sheet 7 -- alphanumerics, control words, PF vertical counter rtl/video/vind_video.sv:264 Priority, GPC and the colour-RAM address (sheet 10) rtl/video/vind_video.sv:290 Colour RAM (sheet 10) rtl/video/vind_video.sv:306 /CLRAM is decoded from MA16 alone (sheet 6) and MA16 holds for the whole cycle, so it is what the mux takes. rtl/video/vind_video.sv:342 The DAC's blanking is not a decoration: on sheet 10 /VIDBL ASYNCHRONOUSLY CLEARS the 17M/17L output registers, i.e. it acts on the pixel that is in those registers at that instant. rtl/video/vind_vram.sv:3 Vindicators — SP-317 sheet 6 (`VRAM`): the four 8Kx8 static RAMs, the six 74LS253 + 3J LS257A address multiplexers, the CPU read/write path, the 6F LS174C / 11F LS175A pipeline registers and the 7L/7J LS378 MO link register. rtl/video/vind_vram.sv:9 Structure follows the Xybots MiSTer core's video blocks (GPL-3.0); every equation here is Vindicators' own and cited to sheet 6. rtl/video/vind_vram.sv:15 1M/2M carry VRD15..VRD8, 2N/1N carry VRD7..VRD0; `VRA14` and `/VRA14` are the two banks' CS2 and `VRA13..VRA1` are A12..A0, so the store is 16384 x 16 addressed by VRA14:VRA1 and VRAn == 68010 byte-address bit n. `VRA15` lands on pin 1, a N rtl/video/vind_vram.sv:32 The video side drives VRA14:VRA13 = VAS1B:VAS0 (3J LS257A section 3/4), so each client lands in its own 8 KB quadrant, and the six LS253s pick VRA12..VRA1: rtl/video/vind_vram.sv:53 7D LS02 : n = ~(DTACK + /VRAM) 9F LS11 : PVCPU = PVAS0 & PVAS1 & n -> sheet 4's wait counter 6F : VCPU = registered PVCPU 20F LS32: /VRAMRD = /VRAM + W//R 20E LS00: VR//W = ~(W//R & VCPU) 17F LS04: VW//R = ~VR//W 5F rtl/video/vind_vram.sv:81 ---- SYNGEN taps (sheet 6) ---- rtl/video/vind_vram.sv:88 ---- slot selector from the sheet-8 PAL 7N (one RCLKA ahead) ---- rtl/video/vind_vram.sv:98 ---- CPU side (the raw 68010 bus, NOT the common bus -- sheet 6) ---- rtl/video/vind_vram.sv:101 sheet 4 4J LS139 Y3 (0x3E0000-0x3FFFFF) rtl/video/vind_vram.sv:102 sheet 4 24D LS04 pin 4 (1 = write) rtl/video/vind_vram.sv:106 -> sheet 4's DTACK wait term rtl/video/vind_vram.sv:110 ---- colour-RAM select, exported to sheet 10 ---- rtl/video/vind_vram.sv:136 11F 74LS175A -- CK = RCLKA, /CLR = PR3 (never cleared) rtl/video/vind_vram.sv:167 6F 74LS174C -- CK = RCLKA, /CLR = PR3 rtl/video/vind_vram.sv:208 6L LS253F's /2G is tied to GND, so VRA12 is never tri-stated by NXLDL; VRA11..VRA7 are, and RP2 then pulls them to 1 (alpha row 31). rtl/video/vind_vram.sv:213 3J LS257A -- SEL = VCPU selects the B (CPU) inputs rtl/video/vind_vram.sv:234 A CPU VRAM write lands only when /PRAM is low (A16 == 1); with A16 == 0 the same strobes drive the colour RAM on sheet 10. rtl/video/vind_vram.sv:279 Transparent is the operative word: `q` is clk_sys-registered (section 6) so it already carries the CPU slot's word within that slot, and the sheet-4 LS163A asserts /DTACK inside the slot -- a latch that only captured after it would deli rtl/video/vind_vram.sv:293 7L / 7J 74LS378 -- the MO link register rtl/vind_core.sv:5 The four blocks below together model the SP-317 game board and the JSA I audio board: rtl/vind_core.sv:8 vind_mem program EPROMs (sheet 4) and graphics ROMs (sheet 9), both held in SDRAM; the 15/16N character ROM; the MiSTer ROM download path and the sound-ROM write stream vind_main_bus sheets 2/3/4 — 68010 (TG68K), PAL 3C decode, LS163 rtl/vind_core.sv:21 ONE clock domain, clk_sys = 57.272727 MHz = 4 x the 14.318181 MHz crystal (sheet 6), with integer clock enables and no fractional enables anywhere. rtl/vind_core.sv:29 ce_6502 = clk_sys / 32 = 1.789772 MHz JSA I 6502 ce_b4h = /B4H, the SCOM shift clock = 4H inverted (sheet 3, 17F), one pulse per rising edge of /B4H = falling edge of the SYNGEN 4H tap, 894.886 kHz rtl/vind_core.sv:39 ---- the one deliberate departure from the sheets: `prog_stall` ------------ Sheet 4 gives program-ROM cycles ZERO wait states and vind_main_bus implements that literally. rtl/vind_core.sv:93 [7] = Pn-S8, which sheet 13 wires as Left Trigger, Right Trigger, Left Thumb, Right Thumb, Left Forward, Right Forward, Left Back, Right Back (= MAME 0x260000 D8..D15). rtl/vind_core.sv:311 /B4H (sheet 3, 17F LS04 = ~4H): the SCOM/LETA/ADC clock. README.md:112 Every operator setting — difficulty, lives, coinage, tank damage, bookkeeping — lives in the on-board Atari 2804A EEPROM at 1C and is edited from the game's own README.md:146 \| Program ROM \| 384 KB (six 27512s at 1D/2D, 1F/2F, 1K/2K), streamed from SDRAM behind a 32-word line cache \| README.md:147 \| Sound board \| Atari JSA I (A043713): 6502 @ 1.7897725 MHz + YM2151 @ 3.579545 MHz + POKEY @ 1.7897725 MHz. The TMS5220C at 3D is not populated and is README.md:153 \| Priority \| PAL16L8 17D (`136059-1151`, the dumped fuse map, used verbatim) + the GPC custom at 13J \| README.md:187 Schematic provenance — every sheet of SP-317 that carries logic (2–11 for the game board, 14–17 for the audio board) was transcribed before any RTL was writ README.md:232 It is where the SP-317 schematics document something MAME's model does not — and in one case MAME's own source flags the gap. README.md:238 \| Playfield / motion-object priority \| "the MO wins unless `mopriority & 4`"; `/PFSPC` is a no-op \| the decision the board actually makes, in PAL 17D (` README.md:241 \| Lines per frame \| `set_raw(..., 262, ...)`, 59.923 Hz, above a comment saying these are "from published specs, not derived" \| 263 lines, 59.696 Hz. README.md:245 \| Self-test switch source \| read from `0x260010` bit 12 — which is a P2 stick switch, not a service switch \| the cabinet service switch, routed to the a README.md:248 \| Colour-RAM write during the picture \| the new colour simply takes effect; nothing else on the line changes \| the CPU and the video share the colour RAM's README.md:252 Priority and SHADE. These are the two divergences with a real chance of changing a pixel, and they are also the two where the hardware evidence is strongest … 5 more Notes where it differs from MAME — 5 rtl/video/vind_cram.sv:25 MAME does not model any of this. rtl/video/vind_intensity_dac.sv:88 MAME does NOT compute this sum. README.md:12 Where a schematic and MAME disagree, the schematic wins and the disagreement is recorded: see [Where this core differs from MAME](#where-this-core-differs-from- README.md:229 Where this core differs from MAME README.md:232 It is where the SP-317 schematics document something MAME's model does not — and in one case MAME's own source flags the gap. Cites MAME source — 68 Arcade-Vindicators.sv:10 Vindicators runs on a HORIZONTAL monitor (MAME ROT0), so there is no rotation; the Orientation option only offers a 180-degree flip. Arcade-Vindicators.sv:158 Per-player switch word, ACTIVE HIGH ("pressed"), in the order of the panel switches Pn-S1..Pn-S8 on SP-317 sheet 13 (= MAME 0x260000 D8..D15); see the port comment in vind_core.sv. rtl/main/vind_eeprom_2804.sv:32 Exactly one write per unlock: this is the hardware behind MAME's `EEPROM_2804 ... rtl/main/vind_eeprom_2804.sv:128 Nothing pulls D0-D7 down, so the modelled float value is 0xFF — also MAME's unmapped read. rtl/main/vind_inputs.sv:24 MAME's `0x0100 = Left Stick Fire` therefore corresponds to Pn-S1, which is the mapping used here. rtl/main/vind_inputs.sv:39 Neither is populated on Vindicators (sheet 12 lists no analog entry, MAME declares the low bytes IPT_UNUSED, and the cabinet has only twin digital sticks), so those lanes read the floating/pulled-up bus = 0xFF. rtl/main/vind_main_bus.sv:16 The memory map, the wait-state table and the schematic-vs-MAME decisions are documented in the submodule headers; this one records the composition. rtl/main/vind_main_bus.sv:356 There is no bus-error timeout (BERR is tied to PR3), so such a cycle still gets DTACK with 0 waits and reads the pulled-up/floating value, modelled as 0xFFFF — which is also MAME's `unmap_value_high()`. rtl/main/vind_out_latch.sv:30 MAME `nopw()`s this address. rtl/mem/vind_char_rom.sv:17 That is MAME's `anlayout` exactly: 2 planes at bit offsets {0, 4}, xoffsets {0,1,2,3, 8,9,10,11}, 816 bits per character. rtl/mem/vind_char_rom.sv:21 Unlike the graphics ROMs this data is NOT inverted anywhere: MAME applies ROMREGION_INVERT to `sprites_pf` only, and sheet 7's shifters take the ROM bits straight. rtl/mem/vind_gfx_mem.sv:27 The MRA emits MAME's `sprites_pf` region as a four-way byte interleave of the planes, plane 0 first, so those four bytes are consecutive in SDRAM and the fetch is one 2-word burst: rtl/mem/vind_gfx_mem.sv:44 (MAME's ROMREGION_INVERT is the same fact applied at load time; this core keeps the board's polarity so sheet 10's PAL equations can be written verbatim.) then drop _req; the arbiter waits for the drop, so one request = exactly on rtl/mem/vind_rom_loader.sv:17 stream base size MAME region destination rtl/mem/vind_rom_loader.sv:28 * maincpu is emitted as BIG-ENDIAN INTERLEAVED WORDS — the MAME even-offset ROM (the `1x` sockets 1D/1F/1K, sheet 4, D15:8) is `map="01"`, the FIRST byte of each output word. rtl/video/vind_alpha.sv:25 11M LS138 : G1 = 256H, /G2A = /HBLANK, /G2B = ~(MO//PF & 1V & 2V & 4V) SELC:SELB:SELA = AP11:AP10:AP9 Y2 /PFB playfield bank latch (AP3..AP0 -> GA15..GA12) Y3 /PFHSLD PFHS HS -- playfield X scroll, AP8..AP0 Y4 /MOHS MO X-scroll latch rtl/video/vind_alpha.sv:36 MAME's `configure_scanline(..., 0, 8)` with `offset = ((scanline - 8) / 8) * 64 + 42` is the same thing said one line later. rtl/video/vind_alpha.sv:49 That is exactly MAME's `anlayout` (planeoffset {0,4}, xoffset {0,1,2,3,8,9,10,11}) with planeoffset[0] the pen MSB. rtl/video/vind_alpha.sv:58 Its outputs are the playfield tilemap row, the SLIP band index (PFV >> 3) and the MO vertical-match operand -- so the motion objects share the playfield's vertical scroll, exactly as MAME's `set_yscroll()` does. rtl/video/vind_intensity_dac.sv:15 The kludge only fires when MAT6 and MSD3 are both set, where 16F LS32 lets MAT3..MAT1 through (the ACTIVE-LOW nets, i.e. the complement of the logical colour bits) -- exactly MAME's `if (mo[x] & 8) pf[x] \|= (~mo[x] & 0xe0) << 6;`. rtl/video/vind_intensity_dac.sv:47 MAME uses an exact `15` multiply and the 17-step table ztable[] = { 0, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e, f, 10, 11 } whose shape (0 at code 0, n+2 for n >= 1) reproduces R121's threshold and R120's pedestal but not the ladder's curvature rtl/video/vind_intensity_dac.sv:91 Hardware's idle MOG is 111, so `INT + 27 + 2 = INT + 16 = INT` and the two agree for ordinary pixels -- but on a kludge pixel hardware gives `INT + 2MOG + 2` where MAME gives `INT + 2MOG`, i.e. the hardware is TWO ztable steps higher. rtl/video/vind_intensity_dac.sv:94 That is a real difference between the two, so DAC_MAME_COMPAT reproduces MAME's arithmetic as well as its table. rtl/video/vind_intensity_dac.sv:139 MAME's ztable, and the resistor-derived intensity curve. rtl/video/vind_intensity_dac.sv:180 MAME multiplies exactly; the hardware weights are 1.000 / 1.958 / 3.917 / 7.581, summing to 14.456, scaled by 15/14.456. rtl/video/vind_intensity_dac.sv:203 The divisor puts the full-scale product (colour 15 x intensity 15) at 255 on both paths: MAME 240272/256 = 255, hardware 240282/265 = 255. rtl/video/vind_intensity_dac.sv:214 Every entry is the integer result of that arithmetic (DIV = 256 for MAME's ztable, 265 for the resistor ladder) applied to the c16/z16 functions above. rtl/video/vind_mo_fetch.sv:60 11N 82S147 (512x8) and 9J 82S129 (256x4) are NOT in the MAME ROM set and cannot be read off the drawing. rtl/video/vind_mo_fetch.sv:61 Their FUNCTION is fixed by their wiring plus `atarimo.cpp`, and both are reconstructed here: rtl/video/vind_mo_fetch.sv:81 MAME wraps X with `xpos & 0x1ff` and never clips, so no HPOS-dependent shortening is modelled; the HPOS inputs exist on the board to stop an object that would run off the end of the 512-entry line buffer, which cannot happen with a wrapping rtl/video/vind_mo_fetch.sv:403 The columns start at phase 3 of the lock cell, one per cell, so the object is P + 1 = HSIZ + 1 columns wide -- MAME's `width`. rtl/video/vind_mo_fetch.sv:406 A preset of `HSIZ + 1` instead draws ONE EXTRA column of the tile past the object's right edge on every object wider than one tile, as a pixel comparison against MAME shows. rtl/video/vind_mo_fetch.sv:493 4M drives GA15..GA8 from the code word's high byte; 8N/7M add the offset into the LOW byte only, so the sum wraps at 256 -- a real hardware limit MAME does not have, and a deliberate difference from it. rtl/video/vind_mo_fetch.sv:599 MSD3..MSD0 leave the SLAGS in the board's ACTIVE-LOW pixel sense: the ROM bytes arrive raw (the data lines carry 4.7K pull-ups, and MAME models the same fact with ROMREGION_INVERT at load time), so no inversion is needed here. rtl/video/vind_mo_linebuf.sv:62 -- so a "special" object (priority bit 6) leaves the PIXEL plane untouched ("no draw", MAME's `if (mopriority & 4) continue;`) but still deposits its stain markers in the ATTRIBUTE plane. rtl/video/vind_mo_linebuf.sv:64 /STON is exactly MAME's `START_MARKER = (4 << PRIORITY_SHIFT) \| 2` and /STOFF its `END_MARKER = (4 << PRIORITY_SHIFT) \| 4`. rtl/video/vind_mo_linebuf.sv:96 It is measured the same way `vind_pf.sv`'s PFX_ALIGN is: at 1 the motion objects land on MAME's `xpos = X - xscroll` in every frame capture, at 0 they are one pixel to the left. rtl/video/vind_mo_vmatch.sv:21 so /VMATCH is asserted exactly for -8(VSIZ+1) <= diff <= -1: the object covers the 8(VSIZ+1) scanlines ABOVE the row where PFV == ~Y. That is the same "negate Y, subtract the height" rule MAME uses (`ypos = -ypos; ypos -= yscroll; ypos rtl/video/vind_mo_vmatch.sv:30 MAME simply does not render outside the visible area -- a different mechanism, same result. rtl/video/vind_pf.sv:16 5M LS374A (CK = /4H, /OC = MO//PF) : VRD15..VRD8 Q19 = PFHF (= VRD15, the tile's HORIZONTAL FLIP) and -> 5N D13 Q16,Q15,Q12 -> 5N (VRD14..VRD12) Q9..Q2 = GA11..GA8 3M LS374B (same clocks) : VRD7..VRD0 -> GA7..GA0 5N LS175B rtl/video/vind_pf.sv:39 MAME treats /PFSPC as a no-op (`case 5: break;`), so this whole input to the priority decision is absent from MAME; the core implements it. rtl/video/vind_pf.sv:54 MAME (whose picture is known good) computes 0x200 + 32((data>>12)&7) + pen, i.e. colour = VRD14:VRD12 in bits 7:5 with bit 4 always zero. rtl/video/vind_pf.sv:58 The two readings differ by exactly one position, and only the MAME one is physically sensible (a flip bit is not a palette bit). rtl/video/vind_pf.sv:109 MAME's ROMREGION_INVERT is the same fact applied at load time; this core keeps the board's polarity so sheets 7/10's PAL equations can be written verbatim. rtl/video/vind_prio_gpc.sv:110 Taken literally the alpha colour address puts D10 in bit 4 and D12 in bit 2, while MAME's `color = ((data >> 10) & 0x0f) \| ((data >> 9) & 0x20)` puts D12 in bit 4 and D10 in bit 2. rtl/video/vind_prio_gpc.sv:113 ALPHA_D_MAME = 1 selects the descending order D3..D0 = VRD15, VRD12, VRD11, VRD10 that reproduces MAME. rtl/video/vind_syngen.sv:32 The one place it does NOT agree with MAME is the total line count: this model gives 263 lines, MAME's `set_raw` says 262. rtl/video/vind_syngen.sv:34 MAME's own comment at that line notes that its parameters are taken from published specs rather than derived, and that the board uses a SYNGEN chip to generate video signals, so the derived value is used here. rtl/video/vind_syngen.sv:37 Frame rate 7 159 090 / (456263) = 59.696 Hz instead of MAME's 59.923 Hz. rtl/video/vind_syngen.sv:112 visible pixel index = h - 9 (MAME hpos) rtl/video/vind_video.sv:26 With PIPE_DLY = 2 the rendered frame sits at offset (0, 0) against MAME frame captures. rtl/video/vind_vram.sv:15 1M/2M carry VRD15..VRD8, 2N/1N carry VRD7..VRD0; `VRA14` and `/VRA14` are the two banks' CS2 and `VRA13..VRA1` are A12..A0, so the store is 16384 x 16 addressed by VRA14:VRA1 and VRAn == 68010 byte-address bit n. `VRA15` lands on pin 1, a N rtl/vind_core.sv:93 [7] = Pn-S8, which sheet 13 wires as Left Trigger, Right Trigger, Left Thumb, Right Thumb, Left Forward, Right Forward, Left Back, Right Back (= MAME 0x260000 D8..D15). README.md:24 All eight MAME sets run on identical RTL. README.md:51 \| ROMs \| Supplied by you from a MAME archive; none are included here \| README.md:107 (The sibling Xybots board does swap them; this one does not, and MAME agrees.) README.md:133 It acts on the output side only (`rtl/video/vind_analog_adjust.sv`): the native 456 × 263 raster, the 7.159 MHz dot clock and the 59.696 Hz refresh are untouche README.md:199 Main CPU boot — the 68010 bus is co-simulated against MAME 0.289 through reset, the RAM and ROM tests, the EEPROM unlock protocol and the scanline interrupt README.md:204 Video — MAME is instrumented to capture complete video state (alpha, playfield and motion-object RAM plus the palette) at chosen frames; those states are re README.md:212 Sound — the JSA I board is compared to MAME: the 6502's I/O accesses and the YM2151 register stream in order and in value, the SCOM command / response hands README.md:231 MAME is this project's functional oracle and every check above measures the core against it, so this is a narrow list, not a general claim. README.md:236 \| Behaviour \| MAME \| This core \| README.md:254 The frame comparisons run against MAME's own rendered output and pass, so on the captured frames the two models agree; the difference is in what happens on fram README.md:259 The 57-object limit. MAME draws every entry a list contains. README.md:267 A `DAC_MAME_COMPAT` parameter selects MAME's curve so the frame comparisons can match bit for bit; the shipping build uses the schematic's. README.md:271 The colour-RAM write. Vindicators writes its palette only outside the visible picture once it has booted — a MAME trace of 10,740 attract frames logged no c README.md:323 The YM2151 : POKEY mix balance** is 2.98 : 1, computed from the sheet-16 resistor network, against MAME's 1.5 : 1. README.md:390 Thanks to the MAME team, whose `vindictr.cpp`, `atarijsa.cpp` and `atarimo.cpp` served as the functional oracle throughout, and to whoever preserved the Atari S Says it matches, follows or was checked against MAME — 12 rtl/mem/vind_rom_loader.sv:32 Getting this backwards byte-swaps every opcode and the CPU fetches a garbage reset vector with no error anywhere, so the assembled region is checked by CRC against MAME's own :maincpu region, 04f2ff51. rtl/video/vind_cram.sv:13 So the CRAM word is INT3-0 : RED3-0 : GRN3-0 : BLU3-0 = D15..D0, matching MAME's `paletteram_w`, and the two byte lanes are written INDEPENDENTLY through their own /WE terms (which is how /UDS and /LDS are honoured). rtl/video/vind_intensity_dac.sv:51 `DAC_MAME_COMPAT = 1` selects MAME's table and its exact multiply, for bit-exact comparison against MAME's rendering; the release build uses the resistor-ladder transfer, which is the default. rtl/video/vind_intensity_dac.sv:60 1 = MAME's ztable and its exact multiply, for bit-exact comparison against MAME's rendering. rtl/video/vind_intensity_dac.sv:113 Written literally as a synchronous clear in a pixel-quantised core it costs a WHOLE pixel -- the register is still holding zero throughout the first pixel after /VIDBL releases -- and the picture loses its leftmost column: one mismatching p rtl/video/vind_mo_fetch.sv:619 Without it every motion object lands two pixels left of MAME's `xpos = X - xscroll`; with it the layer is pixel-exact against MAME frame captures. rtl/video/vind_pf.sv:169 Sheets 7 and 8 draw two (5N then 6N), but the pen bits reach PFHS straight off the SLAGS, and the two paths only line up if the colour is one stage shorter than the drawing reads; with one stage the playfield is pixel-exact against MAME fra rtl/video/vind_pf.sv:291 With PFX_ALIGN = 2 the playfield and the alphanumerics land on the same raster phase and the picture is pixel-exact against MAME frame captures. rtl/video/vind_prio_gpc.sv:94 (that is the ALPHA_D_MAME = 1 order, the default, and it is IDENTICAL to MAME's; ALPHA_D_MAME = 0 reverses the D12/D10 run to the literal sheet-10 pin order) MO 0x100 \| colour<<4 \| pen rtl/video/vind_prio_gpc.sv:100 All three rows agree with MAME exactly once ALPHA_D_MAME is set -- which is the default, and which is verified pixel-exact against MAME frame captures. rtl/video/vind_video.sv:350 Delayed, the picture is pixel-exact against MAME frame captures. rtl/vind_core.sv:62 1 selects MAME's ztable transfer instead of the sheet-11 resistor ladder, for bit-exact comparison against MAME; the release build uses the ladder. Shares text with the MAME driver without saying so — 8 rtl/mem/vind_char_rom.sv:19 {0,1,2,3, 8,9,10,11}, 816 bits per character. — shares text with atari/vindictr.cpp:492 rtl/video/vind_alpha.sv:37 `offset = ((scanline - 8) / 8) 64 + 42` is the same thing said one line — shares text with atari/vindictr.cpp:207 rtl/video/vind_alpha.sv:50 (planeoffset {0,4}, xoffset {0,1,2,3,8,9,10,11}) with planeoffset[0] the — shares text with atari/vindictr.cpp:492 rtl/video/vind_intensity_dac.sv:18 `if (mo[x] & 8) pf[x] \|= (~mo[x] & 0xe0) << 6;`. — shares text with atari/vindictr.cpp:359 rtl/video/vind_intensity_dac.sv:91 pass, `pf[x] \|= (~mo[x] & 0xe0) << 6`). Hardware's idle MOG is 111, so — shares text with atari/vindictr.cpp:360 rtl/video/vind_mo_linebuf.sv:65 `START_MARKER = (4 << PRIORITY_SHIFT) \| 2` and /STOFF its `END_MARKER — shares text with atari/atarimo.cpp:241 rtl/video/vind_prio_gpc.sv:112 while MAME's `color = ((data >> 10) & 0x0f) \| ((data >> 9) & 0x20)` puts — shares text with atari/vindictr.cpp:102 rtl/video/vind_syngen.sv:36 and that the board uses a SYNGEN chip to generate video signals, so the — shares text with atari/vindictr.cpp:548
Xevious# Super Xevious, Xevious MiSTer-devel/Arcade-Xevious_MiSTer @ 2b9e12df MAME compared: namco/xevious.cpp + 12 related file(s) Read: 24 HDL files, 7,767 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	22%
Statements: 1 toward MAME Cites MAME source — 1 rtl/xevious.vhd:39 Use with MAME roms from xevious.zip
XSleena# Xain'd Sleena MiSTer-devel/Arcade-XSleena_MiSTer @ aee6831a (matched by date) MAME compared: technos/xain.cpp + 2 related file(s) Read: 49 HDL files, 16,034 lines (Quartus project)	MiSTer official	Mostly hardware	low	33%
Statements: 10 toward hardware, 3 toward MAME Cites hardware documentation that MAME's driver does not — 9 rtl/XSleenaCore.sv:215 SHARED SIGNALS BETWEEN TOP AND BOTTOM BOARDS See schematics pages 10A and 10B rtl/XSleenaCore_RGB4bitLUT.sv:5 LUT data calculated from LT Spice simulation recreating ASO schematics normalized and hex converted using the following python script: from matplotlib import pyplot as plt import numpy rtl/XSleenaCore_SoundCPU.sv:46 * Sound Cpu (Schematics page 7B,8B) * rtl/XSleenaCore_cpuA_B.sv:131 * Main CPU (Schematics page 1B) * rtl/XSleenaCore_cpuA_B.sv:500 * Sub Cpu (Schematics page 2B) * rtl/XSleenaCore_cpuA_B.sv:845 * Shared SRAM (Schematics page 2B) * rtl/ttl_sync/ttl_74161_sync.v:1 4-bit modulo 16 binary counter with parallel load, * FOR SYNTHESIS * Asynchronous Reset (MRn) -> LS163A <START_TEMPLATE> ttl_74161a #(.DELAY_RISE(20), .DELAY_FALL(25)) <NAME> (.Clear_bar(), .Load_bar(), .ENT(), .ENP(), .D(), .Clk(), .RC rtl/ttl_sync/ttl_74163a_sync.v:1 4-bit modulo 16 binary counter with parallel load, * FOR SYNTHESIS * Synchronous Reset (SRn) -> LS163A <START_TEMPLATE> ttl_74161a #(.DELAY_RISE(20), .DELAY_FALL(25)) <NAME> (.Clear_bar(), .Load_bar(), .ENT(), .ENP(), .D(), .Clk(), .RCO rtl/ttl_sync/ttl_74374_sync_noHiZout.sv:1 ttl_74374.sv Octal D edge triggered FF function table, logic diagrams and switching characteristics extracted from TI 74LS374 Datasheet. Ships hardware documentation files — 1 doc/Arkanoid_schema.pdf Shares text with the MAME driver without saying so — 3 rtl/XSleenaCore_CLK.sv:339 NMI fires on scanline 248 (VBL) and is latched — shares text with technos/xain.cpp:215 rtl/XSleenaCore_CLK.sv:340 VBLK input bit is held high from scanlines 248-255: — shares text with technos/xain.cpp:219 rtl/XSleenaCore_CLK.sv:355 FIRQ (IMS) fires every on every 8th scanline (except 0) — shares text with technos/xain.cpp:211
Xybots# Xybots MiSTer-devel/Arcade-Xybots_MiSTer @ 3a3139ae MAME compared: atari/xybots.cpp + 8 related file(s) Read: 34 HDL files, 6,582 lines (Quartus project)	MiSTer official	Both	high	78%
Statements: 185 toward hardware, 98 toward MAME, 1 not counted Cites hardware documentation that MAME's driver does not — 182 Arcade-Xybots.sv:5 This is the MiSTer `emu` wrapper around rtl/xybots_core.sv, which holds the whole game: the SP-313 main board, the SYNGEN raster and video pipeline, the motion-object engine and the JSA I audio PCB. Arcade-Xybots.sv:17 Clocking: clk_sys = 57.272727 MHz = 4 x the SP-313 sheet-4 14.318181 MHz crystal. Arcade-Xybots.sv:306 WIDTH = 336 = the visible width of the SP-313 raster (456 x 263 total). rtl/main/xybots_addr_decode.sv:3 Xybots 68000 address decode — SP-313 sheet 2, gate for gate. rtl/main/xybots_addr_decode.sv:8 Every select below is read off the drawn decoders on sheet 2, not off MAME's `main_map`. rtl/main/xybots_addr_decode.sv:154 A22..A18 and A7..A1 reach no decoder on sheet 2 at all. rtl/main/xybots_cpu.sv:3 Xybots main CPU — fx68k (cycle-exact 68000), wired as SP-313 sheet 2 draws it. rtl/main/xybots_cpu.sv:24 fx68k's flops are `always_ff @(posedge clk) if (enPhiN)`, so `enPhi1 = ce_7m` puts the fx68k CPU clock edge on the `ce_7m` cycle itself and the rest of sheet 2 — the 5A LS163A /DTACK counter, the 7B 74S74 VRAC arbitration and the E-clock/VP rtl/main/xybots_cpu.sv:37 BERRn = 1 (16A pin 22 = PR2): sheet 2 has no bus-error source. rtl/main/xybots_cpu.sv:55 `oHALTEDn` (fx68k's double-bus-fault output) has no load on sheet 2 and is left unconnected. rtl/main/xybots_cpu.sv:62 ---- /VPA, autovectoring and the RESET instruction ----------------------- Sheet 2 makes `/VPA = ~(FC0 & FC1 & FC2 & AS)` (10A LS20) and wires it to BOTH the 68000's VPA pin (21) and the 5A LS163A's ENT input. rtl/main/xybots_cpu.sv:135 double bus fault; no load on sheet 2 rtl/main/xybots_dpram_be.sv:8 Used twice on the main board: * the 16 KB video RAM at 14J/14E (`AW = 13`, 8 K words), where the two 8464D70 SRAMs take independent /WE strobes so byte writes on either lane are honoured; * the 2 KB colour RAM at 17J/17K (`AW = 10`, 1 K wor rtl/main/xybots_dtack.sv:3 Xybots /DTACK generator — SP-313 sheet 2 (5A LS163A + 7B 74S74 + 1B LS02). rtl/main/xybots_dtack.sv:10 Non-video path — 5A LS163A, a SYNCHRONOUS-clear 4-bit binary counter: CK (2) = VIDCLK (= the 68000 clock, 7.15909 MHz) /CLR (1) = 2A LS08 (1 = /VRAM, 2 = AS -> 3) = /VRAM & AS -> the counter is held at 0 whenever there is no bus cycle rtl/main/xybots_dtack.sv:27 Video path — 7B 74S74: D (12) = /VRAM CK (11) = VRAC2 /PRE (10) = AS -> with no bus cycle Q is preset to 1 /CLR (13) = PR3 (tied inactive) /Q (8) = VDTACK With AS inactive the preset holds Q = 1 so VDTACK = 0. rtl/main/xybots_dtack.sv:67 ---- 5A LS163A ------------------------------------------------------- rtl/main/xybots_dtack.sv:86 ---- 7B 74S74 -------------------------------------------------------- /PRE = AS is asynchronous on the real part. rtl/main/xybots_eeprom_2804.sv:3 Xicor X2804A (512 x 8) EEPROM at 20C/D — SP-313 sheet 3. rtl/main/xybots_inputs.sv:3 Xybots control-panel and status ports — SP-313 sheet 4 (18F, 21E, 18J). rtl/main/xybots_inputs.sv:8 ---- /SW, 0x806100 ------------------------------------------------------- 18F LS244B drives the HIGH byte and 21E LS244B the LOW byte; both /1G and /2G on both parts are `/SW`, so the port is a full 16-bit read and the game reads it as a w rtl/main/xybots_inputs.sv:25 The `CLK0/DIR0/...` net names on the DC connector are vestigial; sheet 10 labels the same pins START, FIRE, TWIST RT, TWIST LT, RIGHT, LEFT, DOWN, UP. rtl/main/xybots_inputs.sv:31 ---- /SYSIN, 0x806200 ---------------------------------------------------- 18J LS244A, both enables = `/SYSIN`, drives the HIGH byte only: D8 /SELFTEST D9 /AUDBUSY (SCOM 20E BUSY) D10 256H D11 VBLANK D12 SW8 D13 SW9 D14 SW1 rtl/main/xybots_irq.sv:3 Xybots interrupt encoder — SP-313 sheet 2 (1B LS02, 10A LS20, 4A LS04, 3B LS00, 1C 74S74, 10C LS00). rtl/main/xybots_irq.sv:15 1C 74S74 as an S/R latch: D = CK = PR1 (it never clocks), /PRE = 3B/11, /CLR = /VIDACK, Q -> 10C LS00 pin 2 5. rtl/main/xybots_irq.sv:19 ---- VIRQ is programmable, and that is the biggest schematic-vs-MAME difference in the whole core ---------------------------------------- `VIRQ` is not a raster signal. rtl/main/xybots_irq.sv:21 SP-313 sheet 7, 6D LS174E (CK = 4H) latches SCRAMD10 -> VIRQ, i.e. bit 10 of the ALPHA tile word being fetched. rtl/main/xybots_irq.sv:31 `virq` is the latched alpha bit 10 from the video timing block; the gating with V[2:0]/HBLANK/VBLANK is here because sheet 2 is where it is drawn. rtl/main/xybots_irq.sv:57 The 1C 74S74 has no reset input on the board: its /CLR is `/VIDACK` and nothing else, so a watchdog timeout or a 68000 RESET instruction leaves a pending IRQ1 pending (the CPU comes out of reset with the SR mask at 7 anyway, and the handler rtl/main/xybots_irq.sv:65 6D LS174E pin 2: latched alpha word bit 10 rtl/main/xybots_irq.sv:75 1C 74S74 Q; diagnostic output, no consumer in the core. rtl/main/xybots_irq.sv:83 The latch is level-set: while VIRQ and the window are both true the preset holds Q at 1, so a /VIDACK write that lands in the same window cannot clear it (both /PRE and /CLR low on a 74S74 forces Q = /Q = 1; on release the preset wins here rtl/main/xybots_main_bus.sv:3 Xybots main board — SP-313 sheet 2 as one block. rtl/main/xybots_main_bus.sv:21 The CPU side is arbitrated: the CPU owns VRAC phase 3 of the four-phase video-RAM multiplex, and the 7B 74S74 in xybots_dtack is what makes the CPU wait for that slot. rtl/main/xybots_main_bus.sv:26 `virq` is the 6D LS174E output, i.e. bit 10 of the ALPHA word being fetched — see xybots_irq's header. rtl/main/xybots_main_bus.sv:29 ---- the /RESET net ------------------------------------------------------ The watchdog's /RESET resets the 68000 AND (leaving sheet 2 for sheet 3 only) clears the EEPROM unlock flip-flop and forces the EEPROM /OE gate. rtl/main/xybots_main_bus.sv:57 7B 74S74 clock rtl/main/xybots_main_bus.sv:62 6D LS174E pin 2: latched alpha bit 10 rtl/main/xybots_main_bus.sv:131 Declared here because sheet 2 wires it to the 68000's VPA pin as well as to the 5A's ENT input, so the CPU instance needs it. rtl/main/xybots_main_bus.sv:136 It regenerates the second clock phase fx68k needs from `ce_7m` itself, so sheet 2 hands it nothing but the enable that everything else here runs on. rtl/main/xybots_main_bus.sv:149 Decode (sheet 2) rtl/main/xybots_main_bus.sv:260 Sheet 9 draws exactly ONE /WE path for both 17J and 17K, and it is /WL-qualified — 15C LS32 (9 = /WL, 10 = /CRAMD) then 15C LS32 (13 = that, 12 = /7M). rtl/main/xybots_main_bus.sv:322 Interrupts (sheet 2) rtl/main/xybots_main_bus.sv:327 `reset` here is POWER-UP ONLY: the 1C 74S74's only clear is /VIDACK, so a watchdog timeout must not drop a pending IRQ1 (see xybots_irq's header). rtl/main/xybots_main_bus.sv:379 Inputs (18F/21E/18J on sheet 4) rtl/main/xybots_main_bus.sv:421 DTACK (5A LS163A + 7B 74S74 + 1B LS02) rtl/main/xybots_slapstic.sv:3 Atari SLAPSTIC 137412-107 — SP-313 sheet 2, location 14B ("SLAPSTK7"). rtl/main/xybots_slapstic.sv:7 The state machine below was written from SP-313 sheet 2 and checked against MAME's `slapstic.cpp` (BSD-3-Clause); see NOTICE.md. rtl/main/xybots_slapstic.sv:14 ---- pinout as wired on sheet 2 ---------------------------------------- rtl/main/xybots_slapstic.sv:42 Sheet 2 puts no R/W term on /CS or CK, so `we` does not reach the state machine. rtl/main/xybots_slapstic.sv:90 One pulse per 68000 bus cycle = one CK (/AS) edge at 14B pin 7. rtl/main/xybots_slapstic.sv:99 Present so the caller keeps the write cycles; the state machine ignores it, exactly as MAME and sheet 2 do. rtl/main/xybots_watchdog.sv:3 Xybots watchdog — SP-313 sheet 2 (1A LS00, 3A LS90, 4A LS04). rtl/main/xybots_watchdog.sv:46 power-on reset, active high (sheet 1, 11A LS14) rtl/mem/xybots_prog_rom.sv:11 ---- what the four sockets are (SP-313 sheet 3) ------------------------- 17C/D + 19C/D PROM0 /CE = A17 -> 68000 0x000000-0x01FFFF (2 x 64 KB) rtl/mem/xybots_prog_rom.sv:30 SLAPSTIC (sheet 2, 14B + 13C LS157): `slap_sel` = /SLAPSTIC asserted, i.e. A23=0 & A17=0 & A16=0 & A15=1. rtl/video/xybots_alpha.sv:3 Xybots alphanumerics layer — SP-313 sheet 7 (6D/7D LS174E, 5C 2764, 2C/3C LS194A) and the VIRQ tap that sheet 2 turns into IRQ1. rtl/video/xybots_alpha.sv:12 h = 8k+3 ALPHA VRAC phase: the word is on the SCRAM data bus -> 8k+4 6D/7D LS174E clock on 4H rising: code[9:0] and VIRQ latched; the attribute nibble (D15, D14:12) is NOT latched here on the board -- it runs straight to the GPC -- so rtl/video/xybots_alpha.sv:30 ---- the character ROM is an 8 KB part in a 16 KB socket ----------------- Sheet 7 draws a U27128 at 5C with A13 wired to code bit 9, but the dumped part 136054-1101.5c is a 2764. rtl/video/xybots_alpha.sv:39 ---- VIRQ --------------------------------------------------------------- 6D LS174E pin 3 -> pin 2 is SCRAMD10 of the alpha word, i.e. a per-tile-row programmable scanline interrupt. rtl/video/xybots_alpha.sv:41 It leaves here as the RAW 6D output: the gate with V[2:0]==7 & HBLANK & ~VBLANK and the 1C 74S74 latch are on sheet 2 and live in rtl/main/xybots_irq.sv, which xybots_main_bus feeds from this port. rtl/video/xybots_alpha.sv:54 ---- SYNGEN counters (SP-313 sheet 4) ---- rtl/video/xybots_alpha.sv:71 6D LS174E pin 2 = alpha word bit 10 rtl/video/xybots_alpha.sv:75 6D / 7D LS174E — clocked by 4H, which rises entering count h ≡ 4. rtl/video/xybots_alpha.sv:96 5C character ROM address, straight off sheet 7 A13..A4 = code (A13 unconnected on the fitted 2764 -> code[9] dropped) A3..A1 = 4V, 2V, 1V A0 = /4H rtl/video/xybots_alpha.sv:111 2C / 3C LS194A — S1 = 1H2H (load), CK = /VIDCLK. rtl/video/xybots_cram.sv:3 Xybots colour-RAM read path and video output registers — SP-313 sheet 9 (17J/17K 2K8-100A used as 1K x 16, 18L and 19L LS273H). rtl/video/xybots_cram.sv:14 18L / 19L are clocked by 8M 74S32 (12 = CRAMD, 13 = /7M -> 11). rtl/video/xybots_cram.sv:38 ---- 18L / 19L LS273H ---- rtl/video/xybots_dac.sv:3 Xybots video DACs — SP-313 sheet 9: three identical 4-bit binary-weighted current DACs whose shared reference current is set by a fourth, 4-bit intensity ladder. rtl/video/xybots_dac.sv:10 ---- the circuit --------------------------------------------------------- Each colour: open-collector U7406 inverters switching R = 620, 1.2K, 2.4K, 4.7K (bit 3..bit 0) into a summing node, plus a 74LS260 "all four bits zero" detect. rtl/video/xybots_gpc.sv:3 Xybots GPC 14K — the Atari custom on SP-313 sheet 8 that turns the alpha attribute nibble, the P bus, the M bus and PF/MO into the 10-bit colour-RAM address. rtl/video/xybots_gpc.sv:10 ---- this is the one place MAME is the oracle --------------------------- The GPC is an Atari custom and a black box: sheet 8 gives every pin connection and nothing about the inside. rtl/video/xybots_gpc.sv:23 and that is a DEDUCTION FROM MAME, not from the schematic. rtl/video/xybots_gpc.sv:34 The third row is MAME's `pf[x] = (mo[x] ^ 0x2f0)`, the case its comment calls "doesn't make sense from the schematics". rtl/video/xybots_mo.sv:3 Xybots — the motion-object engine: SP-313 sheets 5, 6 and 8 tied together. rtl/video/xybots_mo.sv:8 xybots_mo_fetch sheets 5 + 6 — the table walk, the object word latches, the vertical match (xybots_mo_vmatch), the sprite-ROM client and the pixel path xybots_mo_linebuf sheet 8 — the two LB customs (9K, 8K) as ping-pong line buffers wi rtl/video/xybots_mo.sv:51 ---- SYNGEN (sheet 4) ---- rtl/video/xybots_mo.sv:106 The LB customs take their address inputs A8..A0 straight off SCRAMD15..7 (sheet 8): the object's X is loaded by /MOHLD during the word-3 fetch, from the video data bus, not from a latch. rtl/video/xybots_mo_fetch.sv:3 Xybots — SP-313 sheets 5 and 6: the motion-object table walk, the object word latches, the vertical match pipeline, the sprite-ROM address and the pixel path (LS158 swap + LS194 shifters). rtl/video/xybots_mo_fetch.sv:15 0 \| MO word 2 \| (fetch) entry n = H[8:3] 1 \| MO word 0 \| word 2 latched (10F/9E LS174A rises at h%8 == 1) 2 \| CPU \| word 0 latched (6F/6E LS273B on /4HD2H, rises at 2) 3 \| ALPHA \| 4 \| PLAYFIELD \| 5 rtl/video/xybots_mo_fetch.sv:32 455 (sheet 8, /DIE gated by 1VD8H), so entries 0..55 are drawn, entry 56 is fetched and thrown away, and entries 57..63 are never addressed at all. rtl/video/xybots_mo_fetch.sv:67 ---- SYNGEN (sheet 4) ---- rtl/video/xybots_mo_fetch.sv:71 11J 74S04 (9->8) rtl/video/xybots_mo_fetch.sv:74 ---- video-side VRAM port (sheet 5 LS253 mux, MO phase) ---- rtl/video/xybots_mo_fetch.sv:84 ---- to the line buffers (sheet 8), all in the INVERTED sense ---- rtl/video/xybots_mo_fetch.sv:107 10F/9E LS174A — word 2 [15:7] rtl/video/xybots_mo_fetch.sv:108 10F/9E LS174A — word 2 [2:0] rtl/video/xybots_mo_fetch.sv:109 6F/6E LS273B — word 0 [13:0] rtl/video/xybots_mo_fetch.sv:111 8E LS174B — word 1 [3:0], true sense rtl/video/xybots_mo_fetch.sv:146 Vertical match and the ROM address (sheet 5, combinational) rtl/video/xybots_mo_fetch.sv:221 The draw-side pipeline (1D LS174C + 5F/5E LS273F, sheet 5/6) rtl/video/xybots_mo_fetch.sv:250 7F LS86 + 6J/5J LS158 + 6K/5K LS194 (sheet 6) rtl/video/xybots_mo_fetch.sv:261 The LS158s are INVERTING and their /G is /MOVMATCHD: with no vertical match every output is forced high, i.e. MOPIX = 4'hF = the transparent pen, which is what stops 8D LS20 (sheet 8) from writing anything. rtl/video/xybots_mo_linebuf.sv:3 Xybots — SP-313 sheet 8: the two Atari "LB" line-buffer customs (9K and 8K) and the discrete logic that drives them. rtl/video/xybots_mo_linebuf.sv:33 That is the only reading under which sheet 4's crossed pairing makes sense — /MOHLD1 (even lines) belongs to the buffer being written and /MOHR0 (even lines) to the buffer being read — and it is the only one in which the pointers do not c rtl/video/xybots_mo_linebuf.sv:37 There is no BUFCLR pin on the Xybots LB symbol and no other clear anywhere on sheet 8, yet a buffer written on line N and read on line N+1 has to be empty again for line N+2. rtl/video/xybots_mo_linebuf.sv:101 /DIE and /LBWR (sheet 8) rtl/video/xybots_mo_vmatch.sv:3 Xybots — SP-313 sheet 5: the motion-object vertical match (9D, 10D, 3D, 8D) and the picture-code adder (4D, 5D). rtl/video/xybots_mo_vmatch.sv:10 `xybots_mo_fetch` supplies the latched object words and clocks the result into the 1D LS174C / 5F-5E LS273F pipeline the sheet draws around it. rtl/video/xybots_mo_vmatch.sv:16 The LS283 symbols on sheet 5 carry high-side pin numbers that do not match a real 74LS283, so their A/B/C0/S/C4 ROLE labels are authoritative and the pin numbers are not. rtl/video/xybots_mo_vmatch.sv:23 `MOV0 \| 1V` is exactly carry(MOV0 + 1V + 1), so 9D+10D compute the 9-bit U = MOV[8:0] + V[8:0] + 1 where V[8] is VBLANK (there is no 256V net anywhere in SP-313). rtl/video/xybots_mo_vmatch.sv:25 The bit-0 sum, MOA2, is the matching XNOR — and sheet 5 builds MOA2 out of 2A LS08 + 1A LS00 + 4A LS04 + 1B LS02, which is an XNOR. rtl/video/xybots_mo_vmatch.sv:30 The +1 is the line-buffer pipeline: a column computed while the beam is on line V is written into the off-screen buffer and read out on line V+1 (sheet 8, RSEL = 1V). rtl/video/xybots_mo_vmatch.sv:66 5D's C4 goes NOWHERE, and MOPIC13..8 reach the ROM sockets unmodified through 5F/5E LS273F. rtl/video/xybots_mo_vmatch.sv:76 object word 2, as latched by 10F/9E LS174A rtl/video/xybots_mo_vmatch.sv:79 object word 0, as latched by 6F/6E LS273B rtl/video/xybots_pf.sv:3 Xybots playfield layer — SP-313 sheet 7 (13F/13E LS273D, 13J LS174D, PFROM0-3, 6M/5M LS157A, 6L/5L LS194A, 13K LS273). rtl/video/xybots_pf.sv:12 h = 8k+4 PLAYFIELD VRAC phase: the word is on the SCRAM data bus -> 8k+5 13F/13E LS273D clock on 4HD1H rising: PFHFLIP (bit 15), colour (bits 14:11) and the 13-bit code (bits 12:0) latched. rtl/video/xybots_pf.sv:19 -> 8k+13 the prefetched row moves into the display slot h = 8k+14 ROM byte index {~4HD1H, 2HD1H} ^ {flip,flip} = 0 -> 8k+15 6L/5L LS194A parallel load (S1 = /1H), 13J-style colour move ... rtl/video/xybots_pf.sv:43 ---- ROM address, straight off sheet 7 ---------------------------------- A15..A5 = PFPIC10..PFPIC0 A4..A2 = 4V, 2V, 1V A1 = /4HD1H XOR PFHFLIP A0 = 2HD1H XOR PFHFLIP socket = {PFPIC12, PFPIC11} -> MAME "tiles" region offse rtl/video/xybots_pf.sv:91 13F / 13E LS273D — clocked by 4HD1H, which rises entering count h ≡ 5, so the PRE-edge condition is h[2:0] == 4. rtl/video/xybots_pf.sv:129 13F/13E latch the new word and the fetch starts immediately rtl/video/xybots_pf.sv:142 ROM byte index and the 6M/5M LS157A nibble swap A1 = /4HD1H XOR PFHFLIP, A0 = 2HD1H XOR PFHFLIP 4HD1H(h) = 4H(h-1) is high for h ≡ 5,6,7,0; 2HD1H(h) = 2H(h-1) is high for h ≡ 3,4,7,0. rtl/video/xybots_pf.sv:174 6L / 5L LS194A — S1 = /1H, CK = VIDCLK: parallel load on the edge whose PRE-edge count is even, one shift per count. rtl/video/xybots_pf.sv:195 13J LS174D — CK = 2HD1H, which rises entering counts h ≡ 3 and h ≡ 7, i.e. on the edges whose PRE-edge count has h[1:0] == 2. rtl/video/xybots_prio.sv:3 Xybots priority network — SP-313 sheet 8: 9C LS10 (PRIEN), 12J 74S85 with its cascade trick, 11K 74S157 (the P bus) and the 12K + 14M LS32 gates (the M bus). rtl/video/xybots_prio.sv:15 ---- 12J is a 74S85, not a PAL ------------------------------------------ A = LBPRI, B = PFCOL, A<BI = A>BI = GND and A=BI = PRIEN; the only output used is A>BO = PF/MO. rtl/video/xybots_prio.sv:17 A 74S85 whose three cascade inputs are all low drives BOTH A>BO and A<BO high on A == B, so: rtl/video/xybots_prio.sv:40 12J 74S85 pin 5 (A>BO): 1 = playfield wins rtl/video/xybots_prio.sv:48 ---- 12J 74S85 --------------------------------------------------------- The structural device, so that the cascade state is modelled and not assumed. rtl/video/xybots_prio.sv:58 With A>BI = 0 and A<BI = 0 the 74S85 gives {1,1,0} when A=BI is also 0, and {0,0,1} when A=BI is high. rtl/video/xybots_prio.sv:70 ---- 11K 74S157 -------------------------------------------------------- SEL = 8M 74S32 ( PF/MO , 10E 74S00(PRIEN, 11J 74S04(LBCOL3)) ) = PF/MO \| ~(PRIEN & ~LBCOL3) SEL = 1 selects the B inputs, i.e. PFPIX. rtl/video/xybots_syngen.sv:3 Xybots — SP-313 sheet 4: master clock tree, SYNGEN custom (11E/F) and the discrete glue that surrounds it. rtl/video/xybots_syngen.sv:11 This module is the whole of sheet 4 except the LS244 switch-input buffers (18F/18J/21E) — i.e. the oscillator/divider chain, the SYNGEN custom itself, and every gate that shapes SYNGEN's outputs into the nets the other eight sheets consume. rtl/video/xybots_syngen.sv:19 SP-313 draws only its pinout, so its internal behaviour is reconstructed from the same part as implemented discretely on Atari System 1 (SP-277) and modelled in the Arcade-Gauntlet_MiSTer core's `rtl/gauntlet/SYNGEN.vhd` (d18c7db, GPL-3.0 rtl/video/xybots_syngen.sv:26 * a 9-bit horizontal counter cleared by NXL, * an 82S153 PLA (Atari 136032-103) decoding H into NXL/HSYNC/HBLANK/LMPD/PFHST/BUFCLR/C0/C1/C2, all of them taken through one register (the "7E" 74S174), * an 8-bit vertical counter plus one extr rtl/video/xybots_syngen.sv:44 PIN DIRECTIONS ON SP-313 SHEET 4 rtl/video/xybots_syngen.sv:56 VSCK (vertical scroll clock) and /PFHST (playfield horizontal start) are the System-1 scrolling hooks: Xybots has no scrolling playfield, so both are bare stubs, as is C0 (Xybots makes its own VRAC0 with 8M 74S32 instead). rtl/video/xybots_syngen.sv:87 14M (8B 74S04 1->2) rtl/video/xybots_syngen.sv:88 /14MP (8B 74S04 13->12) rtl/video/xybots_syngen.sv:89 7M (7B 74S74 Q) rtl/video/xybots_syngen.sv:90 /7M (7B 74S74 /Q) rtl/video/xybots_syngen.sv:91 DCLK (9B 74S74 Q) rtl/video/xybots_syngen.sv:92 RCLK (1C 74S74 Q, /PRE = DCLK) rtl/video/xybots_syngen.sv:93 VIDCLK (11J 74S04 3->4 from /CKO) rtl/video/xybots_syngen.sv:94 /VIDCLK (8B 74S04 9->8 from CKO) rtl/video/xybots_syngen.sv:117 10E 74S00 (1,2->3) rtl/video/xybots_syngen.sv:118 11J 74S04 (9->8) rtl/video/xybots_syngen.sv:120 11J 74S04 (11->10) rtl/video/xybots_syngen.sv:122 11J 74S04 (1->2) rtl/video/xybots_syngen.sv:130 ---- video-RAM access phase (sheet 5 LS253 select) ---- rtl/video/xybots_syngen.sv:131 8M 74S32 (4 = /2HD1H, 5 = 4HD2H -> 6) rtl/video/xybots_syngen.sv:143 ---- interrupt ---- Sheet 2: 1B LS02 (11 = VBLANK, 12 = /HBLANK -> 13) then 10A LS20 with 4V,2V,1V then 4A LS04 (9->8). rtl/video/xybots_syngen.sv:145 The IRQ1 latch is set by `virq_gate & VIRQ`, where VIRQ is alpha-RAM bit 10 latched by 6D LS174E on sheet 7; that half comes out of xybots_alpha. rtl/video/xybots_syngen.sv:158 clk_sys phase, and the 14M / 7M chain (SP-313 sheet 4) rtl/video/xybots_syngen.sv:175 7B 74S74: D = /7M, CK = 14M -> divide by two, rising with ce_7m. rtl/video/xybots_syngen.sv:179 9B 74S74: D = /7M, CK = /14MP. rtl/video/xybots_syngen.sv:186 1C 74S74: D = 7M, CK = 14M, /PRE = DCLK (asynchronous), /CLR = PR1 = 1. rtl/video/xybots_syngen.sv:196 SYNGEN CKO (pin 29) = CK, /CKO (pin 4) = ~CK; both are re-inverted on the board, so VIDCLK is in phase with 7M and is the 68000 clock (sheet 2). rtl/video/xybots_syngen.sv:202 SYNGEN horizontal PLA (Atari 136032-103 / 82S153), sheet-4 black box rtl/video/xybots_syngen.sv:226 o16 (C0), o12 (/PFHST) and o11 (BUFCLR) are deliberately not implemented: pins 24 and 28 are bare stubs on sheet 4 and BUFCLR has no pin at all in the Xybots symbol, so nothing in this game can observe them. rtl/video/xybots_syngen.sv:231 SYNGEN vertical PROM (Atari 136032-102, 256 x 4), sheet-4 black box rtl/video/xybots_syngen.sv:264 The counters and the SYNGEN output register (74S174 "7E" / "7D") rtl/video/xybots_syngen.sv:332 8B 74S04 rtl/video/xybots_syngen.sv:336 10E 74S00 rtl/video/xybots_syngen.sv:338 11J 74S04 rtl/video/xybots_syngen.sv:344 8M 74S32: VRAC0 = /2HD1H \| 4HD2H. rtl/video/xybots_syngen.sv:350 g3b/g6b are the two unnamed intermediate nets on sheet 4; /MOHR itself comes out of SYNGEN pin 25. rtl/video/xybots_testpat.sv:22 4 bits per channel, which is the natural width for this game: Xybots' CRAM is 1024 x 16 in I:R:G:B 4:4:4:4 (SP-313 sheet 9), so the real palette output lands on the same bus. rtl/video/xybots_video.sv:74 6D LS174E: raw alpha bit 10, UNDELAYED rtl/video/xybots_video.sv:242 Compositor stage 1 — the GPC's 7M input register (sheet 8). rtl/xybots_core.sv:7 The five blocks, and the SP-313 schematic sheets each one models: rtl/xybots_core.sv:9 xybots_mem sheet 3 ROMs + the MiSTer download path + SDRAM xybots_main_bus sheet 2 — 68000, decode, DTACK, IRQ, watchdog, SLAPSTIC, EEPROM + NVRAM, inputs, video RAM, colour RAM xybots_video sheets 4/5/7/8/9 — SYNGEN, the VRAM ad rtl/xybots_core.sv:23 ONE clock domain, clk_sys = 57.272727 MHz = 4 x the SP-313 sheet-4 crystal (14.318181 MHz), with integer clock enables and no fractional enables anywhere. rtl/xybots_core.sv:28 ce_14m = clk_sys / 4 = 14.318181 MHz SYNGEN master (sheet 4) rtl/xybots_core.sv:80 cpu_reset sys_reset \| watchdog_reset — formed INSIDE xybots_main_bus, because the sheet-2 /RESET net reaches only the 68000's RESET/HALT pins and (on sheet 3) the EEPROM unlock latch and its /OE gate. rtl/xybots_core.sv:141 ---- video out (single clk_sys domain, qualified by ce_pix) ---- 8 bits per channel: CRAM is I:R:G:B 4:4:4:4 (sheet 9), but the INTENSITY bit means the sheet-9 resistor-ladder DAC produces more than 16 levels per channel, so the core's outp rtl/xybots_core.sv:403 Main board — SP-313 sheet 2 rtl/xybots_core.sv:459 JSA I audio PCB — SP-313 sheets 11-14 README.md:7 The core reconstructs the original PCB set — the game board (68000 + SLAPSTIC 137412-107) and the Atari JSA I stand-alone audio board (6502 + YM2151) — from README.md:114 \| Protection \| Atari SLAPSTIC 137412-107 at 14B, banking ROM `0x8000-0x9FFF` in 4 × 8 KB pages \| README.md:121 \| Priority \| The 74S85 magnitude comparator at 12J (not a PAL — sheet 8 is unambiguous) + the GPC custom at 14K form the colour-RAM address \| README.md:156 Programmed logic — the one PAL the core depends on, the JSA sound board's address decoder (Atari 136056-2101), is implemented from its fuse map rather than README.md:163 Video timing — the SYNGEN raster is reconstructed from the real Atari System 1 sync PROM 136032-102 and checked by an exhaustive one-frame bench that rebuil README.md:214 It is where the SP-313 schematics or the sound board's decoder PAL document something MAME's model does not — and in two of the seven cases MAME's own source fl README.md:220 \| Lines per frame \| `set_raw(..., 262, ...)`, 59.923 Hz, above a comment saying these are "from published specs, not derived" and that the board uses a SYNGEN README.md:225 \| Sound CPU: YM2151 select \| `0x2000-0x2001` \| `0x2000-0x27FF` — the decoder PAL 136056-2101 sees neither SA10..SA1 nor anything the YM2151 (which has only README.md:242 The decoder output exists on sheet 2 and goes nowhere, so the writes terminate like any other decoded-but-unconnected access and have no effect. README.md:264 A SYNGEN dump would settle the 263-line count directly.** The vertical total is derived from the System 1 sync PROM and the discrete System 1 circuit that the S README.md:313 The SLAPSTIC is not derived from those cores: it was written from SP-313 sheet 2 and verified against MAME's state machine. README.md:317 Thanks to the MAME team, whose `xybots.cpp`, `atarijsa.cpp`, `atarimo.cpp` and `slapstic.cpp` served as the functional oracle throughout, and to whoever preserv Cites hardware references or measurements that MAME's driver also gives — 1 rtl/mem/xybots_prog_rom.sv:77 27256 at 17B/19B: pin 1 is VPP, A16 undecoded -> 0x30000 folds onto 0x20000 — also in MAME: 17B atari/xybots.cpp:416, 19B atari/xybots.cpp:417 Notes where it differs from MAME — 3 rtl/main/xybots_irq.sv:27 In attract and in play the game keeps exactly ONE armed word — row 29, column 42 — so the two models coincide at ~line 239; in SELF TEST the character-set and RAM-test screens set bit 10 in thousands of visible words and real hardware takes README.md:11 Where a schematic and MAME disagree, the schematic wins and the disagreement is recorded: see [Where this core differs from MAME](#where-this-core-differs-from- README.md:211 Where this core differs from MAME Cites MAME source — 84 Arcade-Xybots.sv:12 Xybots runs on a HORIZONTAL monitor (MAME ROT0), so there is no rotation: the raster goes straight through arcade_video. Arcade-Xybots.sv:86 Xybots has NO dip switches: MAME's INPUT_PORTS_START(xybots) has only the 0x806100 control word and the 0x806200 service/status word, and every operator setting lives in the X2804 EEPROM at 0x805000, changed from the game's own self-test. Arcade-Xybots.sv:197 Coins are read on the JSA audio board and are SWAPPED on Xybots (MAME set_swapped_coins(true)); the swap is inside rtl/sound/xybots_jsa_io.sv, so coin1 here is the LEFT chute / player 1 exactly as the harness labels it. rtl/main/xybots_addr_decode.sv:8 Every select below is read off the drawn decoders on sheet 2, not off MAME's `main_map`. rtl/main/xybots_addr_decode.sv:9 The mirrors MAME documents fall OUT of the address bits those decoders never look at, so the two descriptions agree over the whole 24-bit space (see the mirror note at the end). rtl/main/xybots_addr_decode.sv:46 ---- mirrors, i.e. which bits nobody looks at ---------------------------- A23 = 1 half: A22..A15 are not decoded at all -> everything repeats every 0x8000, which is MAME's `.mirror(0x7f8000)`. rtl/main/xybots_addr_decode.sv:49 /CRAM covers 0x804000-0x804FFF but only A10..A1 reach the RAM -> MAME's 0x800 palette mirror. rtl/main/xybots_addr_decode.sv:50 /EEROM covers 0x805000-0x805FFF but the X2804A only has A0..A8 -> MAME's 0xc00. rtl/main/xybots_addr_decode.sv:52 A23 = 0 half: only A17 (ROM /CE) and A16/A15 (slapstic) are decoded, so the ROM repeats every 0x40000, which is MAME's `.mirror(0x7c0000)`. rtl/main/xybots_addr_decode.sv:154 That omission is the WHOLE source of MAME's `.mirror(0x7c0000)` on the ROM half and `.mirror(0x7f8000)` plus the 0x100-byte I/O pages on the board half, so it is deliberate; sink the bits so the tools agree. rtl/main/xybots_eeprom_2804.sv:18 The socket is wired for a 2 K x 8 part but the fitted X2804A is 512 x 8 (A0..A8 only), so the device repeats four times inside 0x805000-0x805FFF — which is exactly MAME's `.mirror(0x7f8c00)`. rtl/main/xybots_eeprom_2804.sv:31 Exactly one write is permitted per unlock, which is MAME's `lock_after_write(true)`. rtl/main/xybots_eeprom_2804.sv:225 The board has no bus pull-ups on D0B-D7B, so the modelled float value is the 0xFF that MAME's unmapped read gives. rtl/main/xybots_inputs.sv:28 MAME says FFE100 bit 0 = START2 ... rtl/main/xybots_inputs.sv:40 Two schematic-vs-MAME points: * D12-D15 are four real switch inputs on connector SWB that MAME declares `IPT_UNUSED`. rtl/main/xybots_irq.sv:19 ---- VIRQ is programmable, and that is the biggest schematic-vs-MAME difference in the whole core ---------------------------------------- `VIRQ` is not a raster signal. rtl/main/xybots_irq.sv:26 MAME instead does `screen_vblank() -> ASSERT_LINE M68K_IRQ_1`, one IRQ per frame. rtl/main/xybots_irq.sv:45 MAME drives two independent input lines. rtl/main/xybots_main_bus.sv:88 SWB-3..6 -> /SYSIN D12..D15 (MAME: unused) rtl/main/xybots_main_bus.sv:194 So the access that selects a bank still reads the OLD bank and the new one applies from the next cycle — which is exactly what MAME's read TAP does (the tap runs after the underlying `bankr` read) and what the boot trace shows at pc 0x13F32 rtl/main/xybots_main_bus.sv:265 The game never notices: it touches CRAM with WORD accesses only, so this and MAME's per-lane `palette_device::write16` are indistinguishable here. rtl/main/xybots_main_bus.sv:396 Everything else — reads of the write-only strobes (the `clr` read-modify-writes at pc 0x52A and the five `clr.w $ea00.w` sites), the three unconnected LS138 outputs, the undecoded 0x806300/0x806700/0x807000 pages — leaves the bus floating, rtl/main/xybots_slapstic.sv:30 The transition structure MAME's `slapstic.cpp` gives for chip class 103-110, which is what 137412-107 belongs to. rtl/main/xybots_slapstic.sv:31 MAME qualifies each match with a 32-bit range test as well as the chip's own address mask; on this board that range test reduces to exactly "A23=0 and A17=0 and A16=0 and A15=1", which IS /SLAPSTIC, so the two forms below are all that is ne rtl/main/xybots_slapstic.sv:56 slapstic_data for 137412-107, verbatim from slapstic.cpp. rtl/main/xybots_slapstic.sv:56 All values are CHIP word addresses (= 68000 A14..A1), which is what MAME's tables hold. rtl/main/xybots_slapstic.sv:99 Present so the caller keeps the write cycles; the state machine ignores it, exactly as MAME and sheet 2 do. rtl/main/xybots_slapstic.sv:107 MAME's S_* encoding; diagnostic output, no consumer in the core. rtl/main/xybots_slapstic.sv:111 MAME slapstic.h `enum { S_IDLE, S_ACTIVE, S_ALT_VALID, S_ALT_SELECT, S_ALT_COMMIT, S_BIT_LOAD, S_BIT_SET_ODD, S_BIT_SET_EVEN, ... rtl/main/xybots_slapstic.sv:125 68000 A0 does not exist on the bus, and MAME masks bit 0 out of every test, so nothing here depends on byte lane. rtl/main/xybots_watchdog.sv:30 MAME says `WATCHDOG_TIMER(config, "watchdog")` with default timing: the 8-frame period, the 2-frame pulse and the park-at-9 power-up are not modelled there. rtl/mem/xybots_prog_rom.sv:36 Result: an 8 KB page at 0x008000-0x009FFF repeated four times over 0x8000-0xFFFF, exactly MAME's `configure_entries(0, 4, base + 0x8000, 0x2000)`. rtl/mem/xybots_rom_loader.sv:13 stream base size MAME region destination rtl/mem/xybots_rom_loader.sv:25 * maincpu is emitted as BIG-ENDIAN INTERLEAVED WORDS — the even-offset MAME ROM (17cd/17b) is `map="01"`, the FIRST byte of each output word, i.e. D15:8. rtl/video/xybots_alpha.sv:23 Two more pipeline stages downstream (GPC, then CRAM + 18L/19L) put that pixel on the DAC during count 8k+9+p, i.e. at hpos = 8k+p — where MAME's alpha tilemap puts it. rtl/video/xybots_alpha.sv:119 Byte / plane order (MAME's `anlayout`): char_data[7:4] = ANPIX1 of pixels 0..3 (plane 0 = the MSB pen bit) char_data[3:0] = ANPIX0 of pixels 0..3 and A0 = /4H already selected pixels 0..3 vs 4..7. rtl/video/xybots_dac.sv:34 Neither ladder is exactly binary: 4700/620 = 7.58 rather than 8, and 1000/120 = 8.33 rather than 8, so the colour curve sits slightly above MAME's straight n/15 in the low half and slightly below it in the high half, and the intensity curve rtl/video/xybots_dac.sv:39 ---- MAME ---------------------------------------------------------------- MAME's `IRGB_4444` is, measured against two pixel-exact captured frames covering 25 distinct palette words: rtl/video/xybots_dac.sv:46 `DAC_MAME_COMPAT = 1` reproduces it bit for bit, which is what a simulation comparing this core against MAME's rendered bitmap wants. rtl/video/xybots_dac.sv:73 round(2^15 * fc(n)) for the 620 / 1.2K / 2.4K / 4.7K colour ladder, and MAME's 17n when DAC_MAME_COMPAT is set. rtl/video/xybots_dac.sv:117 The shifted product is 8-bit by construction — 255 2^30 >> 30 in schematic mode, 255255 >> 8 in MAME mode — so the cast is exact. rtl/video/xybots_gpc.sv:10 ---- this is the one place MAME is the oracle --------------------------- The GPC is an Atari custom and a black box: sheet 8 gives every pin connection and nothing about the inside. rtl/video/xybots_gpc.sv:17 and MAME's alpha tile info is `color = (data >> 12) & 7`, `opaque = data & 0x8000`, with the "chars" gfx entry at palette base 0 and 4 pens per colour. rtl/video/xybots_gpc.sv:23 and that is a DEDUCTION FROM MAME, not from the schematic. rtl/video/xybots_gpc.sv:23 Likewise the palette bases 0 / 256 / 512 (and the otherwise unused 768) come from MAME's GFXDECODE entries. rtl/video/xybots_gpc.sv:34 The third row is MAME's `pf[x] = (mo[x] ^ 0x2f0)`, the case its comment calls "doesn't make sense from the schematics". rtl/video/xybots_gpc.sv:62 The alpha layer is on top; pen 0 is transparent unless the tile's opaque bit (word bit 15) is set -- MAME's TILE_FORCE_LAYER0. rtl/video/xybots_gpc.sv:66 M is the line buffer's byte, inverted sense; ~M is MAME's {colour, pen}. rtl/video/xybots_mo_fetch.sv:149 On a visible line that is simply MAME's vpos; on the last line of the frame (v256 phase, v = 255, VBLANK = 1) it is 511, and 511 + 1 = 0 mod 512 — which is exactly the display line the buffer written there feeds. rtl/video/xybots_mo_linebuf.sv:129 The counters are nine bits, so a column that starts near 511 wraps into the left edge of the screen — which is exactly MAME's `xpos & 0x1ff` followed by the `xpos >= width ? rtl/video/xybots_mo_vmatch.sv:32 So U = MOV + D for the DISPLAYED line D, which is MAME's coordinate directly. rtl/video/xybots_mo_vmatch.sv:35 MAME (`atarimo.cpp::render_object`) puts the object at ypos = (-(Y + 8height)) & 0x1FF and draws 8height lines from there, i.e. D is covered iff (Y + D) mod 512 >= 512 - 8height and the row inside the object is (Y + D) mod 512 - (512 - 8 rtl/video/xybots_mo_vmatch.sv:50 Two connections are ambiguous on the drawing and are read here as 3D B3 = 10D.S1 4D B1 = 3D.S1 4D's B1 is the load-bearing one: tied to GND the picture code would advance two tiles per row and only four rows could be addressed, whereas 3D rtl/video/xybots_mo_vmatch.sv:67 So the add is EIGHT bits wide and a carry out of MOPIC7 is lost: tile index = {MOPIC[13:8], (MOPIC[7:0] + tile_row)[7:0]} MAME adds `code + row` in full 14-bit precision. rtl/video/xybots_mo_vmatch.sv:70 That is a real difference between this core and MAME, kept because it is what the board does. rtl/video/xybots_pf.sv:43 ---- ROM address, straight off sheet 7 ---------------------------------- A15..A5 = PFPIC10..PFPIC0 A4..A2 = 4V, 2V, 1V A1 = /4HD1H XOR PFHFLIP A0 = 2HD1H XOR PFHFLIP socket = {PFPIC12, PFPIC11} -> MAME "tiles" region offse rtl/video/xybots_pf.sv:50 The empty 9L socket ({PFPIC12,PFPIC11} = 2, region 0x20000-0x2FFFF) floats and reads as 0xFF on the board; the MRA materialises 0xFF there while MAME leaves 0x00. rtl/video/xybots_pf.sv:168 MAME's gfx_8x8x4_packed_msb: the HIGH nibble is the left pixel of the pair. rtl/video/xybots_prio.sv:10 ---- everything from the line buffer is INVERTED sense ------------------- LBPIX = ~pen, LBCOL = ~colour, LBPRI = ~priority (= MAME's `mopriority`). rtl/video/xybots_prio.sv:23 which is the pair of equations MAME uses. rtl/video/xybots_syngen.sv:36 The one place it does NOT agree with MAME is the total line count: this model gives 263 lines, MAME's `set_raw` says 262. rtl/video/xybots_syngen.sv:38 MAME's own comment at that line says those parameters come from published specs rather than from the board, so the derived value is used here. rtl/video/xybots_syngen.sv:40 Frame rate is therefore 7 159 090 / (456263) = 59.696 Hz instead of MAME's 59.923 Hz. rtl/video/xybots_syngen.sv:100 visible pixel index = h - 9 (MAME hpos) rtl/video/xybots_video.sv:22 That is exactly where the board puts it and exactly where MAME puts tile column k: at x = 8k. rtl/video/xybots_video.sv:34 1 = MAME's IRGB_4444 transfer rtl/xybots_core.sv:92 1 selects MAME's IRGB_4444 transfer instead of the sheet-9 resistor ladder, bit-exactly. rtl/xybots_core.sv:93 It exists so a simulation can be compared against MAME's rendered bitmap; the core itself uses the schematic curve and there is deliberately no OSD option for it. rtl/xybots_core.sv:134 Coins live on the JSA board and are SWAPPED on Xybots (MAME set_swapped_coins(true)); the swap is inside xybots_jsa_io. README.md:7 The core reconstructs the original PCB set — the game board (68000 + SLAPSTIC 137412-107) and the Atari JSA I* stand-alone audio board (6502 + YM2151) — from README.md:21 All five MAME sets run on identical RTL — they differ only in the main CPU ROMs (and, for `xybots0`, in three tile ROMs and the sound ROM's filename). README.md:39 \| ROMs \| Supplied by you from a MAME archive; none are included here \| README.md:82 The operator manual's Switch Test page calls the knob switches Turn Left / Turn Right; MAME names the same two inputs Twist Left / Twist Right. README.md:144 Like the other MiSTer arcade repositories, this one ships the core and its release files only; the simulation benches, MAME capture scripts and design notes are README.md:168 Main CPU boot — the 68000 bus is co-simulated against MAME 0.288 through reset, the RAM and ROM tests, the SLAPSTIC checksum walk, 143 EEPROM writes and the README.md:174 The SLAPSTIC 107 is proved equivalent to MAME's state machine over the full alt / bit / add sequences. README.md:191 Those states are replayed through the real core RTL and compared to MAME's own rendered bitmap pixel for pixel. README.md:213 MAME is this project's functional oracle and every gate above measures the core against it, so this is a narrow list, not a general claim. README.md:214 It is where the SP-313 schematics or the sound board's decoder PAL document something MAME's model does not — and in two of the seven cases MAME's own source fl README.md:218 \| Behaviour \| MAME \| This core \| README.md:237 A `DAC_MAME_COMPAT` parameter selects MAME's curve so the frame-CRC gates can compare bit for bit; the shipping build uses the schematic's. README.md:244 MAME does not map the address at all, and reaches the same outcome by a different route. README.md:250 Neither row is observable in this game: the sound program addresses the YM2151 at `0x2000`/`0x2001` only and only ever reads `0x2806`, and MAME taps over attr README.md:317 Thanks to the MAME team, whose `xybots.cpp`, `atarijsa.cpp`, `atarimo.cpp` and `slapstic.cpp` served as the functional oracle throughout, and to whoever preserv Says it matches, follows or was checked against MAME — 9 Arcade-Xybots.sv:174 The /SW word at 0x806100 in its SCHEMATIC bit order, but ACTIVE HIGH ("pressed") — the 18F/21E LS244 inversion lives in rtl/main/xybots_inputs.sv, which is where the sheet-4 wiring is transcribed and verified (MAME's FFE100 agrees bit for b rtl/main/xybots_inputs.sv:42 They are exposed here as inputs and default to inactive (reading 1), so the core matches MAME unless a user wires them. rtl/main/xybots_inputs.sv:44 * 256H (D10) is never tested by the program. MAME approximates it by XORing 0x0400 on every read of the port; this core drives the real 256H from the video counter, because nothing observable depends on it and the hardware signal is fre rtl/main/xybots_slapstic.sv:7 The state machine below was written from SP-313 sheet 2 and checked against MAME's `slapstic.cpp` (BSD-3-Clause); see NOTICE.md. rtl/main/xybots_slapstic.sv:90 It must pulse for EVERY cycle the chip can see, reads and writes alike, not only for cycles inside the banked window: alt1 is matched with MAME's `test_any`, and an out-of-window cycle breaks an alt sequence in progress. rtl/video/xybots_cram.sv:16 Layout, straight off the wiring and identical to MAME's IRGB_4444: README.md:189 Pixel-exact video gates — MAME is instrumented to capture complete video state (alpha, playfield and motion-object RAM plus the palette) at chosen frames. README.md:192 The alpha layer, the playfield layer, the motion-object engine and the full compositor each have their own gate; the compositor is *bit-identical to MAME's `go README.md:313 The SLAPSTIC is not* derived from those cores: it was written from SP-313 sheet 2 and verified against MAME's state machine. Says it was translated, ported or taken from MAME — 1 Arcade-Xybots.sv:174 The /SW word at 0x806100 in its SCHEMATIC bit order, but ACTIVE HIGH ("pressed") — the 18F/21E LS244 inversion lives in rtl/main/xybots_inputs.sv, which is where the sheet-4 wiring is transcribed and verified (MAME's FFE100 agrees bit for b Keeps a MAME approximation — 1 rtl/main/xybots_inputs.sv:44 * 256H (D10) is never tested by the program. MAME approximates it by XORing 0x0400 on every read of the port; this core drives the real 256H from the video counter, because nothing observable depends on it and the hardware signal is fre Shares text with the MAME driver without saying so — 3 rtl/main/xybots_slapstic.sv:111 MAME slapstic.h `enum { S_IDLE, S_ACTIVE, S_ALT_VALID, S_ALT_SELECT, — shares text with atari/slapstic.h:283 rtl/main/xybots_slapstic.sv:112 S_ALT_COMMIT, S_BIT_LOAD, S_BIT_SET_ODD, S_BIT_SET_EVEN, ... }`. — shares text with atari/slapstic.h:283 rtl/video/xybots_gpc.sv:35 calls "doesn't make sense from the schematics". It does: 0x2f0 flips bit 9 — shares text with atari/xybots.cpp:205
Zaxxon# Future Spy, Super Zaxxon, Zaxxon MiSTer-devel/Arcade-Zaxxon_MiSTer @ 0bc93064 MAME compared: sega/zaxxon.cpp + 7 related file(s) Read: 9 HDL files, 2,626 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	57%
Statements: 1 toward hardware, 1 toward MAME, 1 not counted Cites hardware documentation that MAME's driver does not — 1 rtl/zaxxon.vhd:74 Schematics remarks : IC board 834-0214 and 834-0257 or 834-0211 some details are missing or seems to be wrong: - sprite buffer addresses flip control seems to be incomplete (fliping adresses both at read and write is useless !) - diagonal s Cites hardware references or measurements that MAME's driver also gives — 1 rtl/zaxxon.vhd:80 - 834-0211 sheet 7 of 9 : /128H, 128H and 256H dont agree with U21 Qc/Qd output ! — also in MAME: sheet 7 sega/nl_segausb.cpp:352 Cites MAME source — 1 rtl/zaxxon.vhd:36 Use with MAME roms from zaxxon.zip
ZigZag# Zig Zag MiSTer-devel/Arcade-ZigZag_MiSTer @ 5753cfd4 MAME compared: galaxian/galaxian.cpp + 7 related file(s) Read: 21 HDL files, 7,034 lines (Quartus project)	MiSTer official	Not enough evidence in the code	insufficient	1%
Statements: 1 toward MAME Shares text with the MAME driver without saying so — 1 rtl/mc_inport.vhd:17 DIP SW 0 1 2 3 4 5 — shares text with galaxian/galaxian.cpp:2796
jt1942# 1942, Pirate Ship Higemaru, Vulgus jotego/jtcores @ b672aca5 MAME compared: capcom/1942.cpp, capcom/higemaru.cpp, capcom/vulgus.cpp + 4 related file(s) Read: 21 HDL files, 3,858 lines (files.yaml)	JTCORES	Both	low	15%
Statements: 8 toward hardware, 2 toward MAME Cites hardware documentation that MAME's driver does not — 7 hdl/jt1942_colmix.v:5 1942 Colour Mixer Schematics page 4 hdl/jt1942_objtiming.v:79 But this should take the flip bit into account to work correctly and that isn't in the schematics. hdl/jt1942_objtiming.v:101 objcnt[2:0] = H[6:4]; `else // 1942 scan sequence from schematics objcnt[4] = H[8]^~H[7]; objcnt[3] = (V[7] & objcnt[4]) ^ ~H[7]; objcnt[2:0] = H[6:4]; `endif end hdl/jt1942_sound.v:5 1942 Sound Schematics page 3/8 cores/gng/hdl/jtgng_objdma.v:33 Ghosts'n Goblins copies only 'h180 objects as per schematics 1943 copy more, but it is not clear what the limit is. README.md:14 This occurs because that logo is printed using two sprites right at the limit of the vertical split line (schematics 5/8). README.md:21 The conversion was done based on 1942 schematics and MAME driver for Higemaru. Notes where it differs from MAME — 1 hdl/jt1942_sound.v:23 MAME ignores one of them. Cites MAME source — 2 README.md:21 The conversion was done based on 1942 schematics and MAME driver for Higemaru. README.md:25 Interrupts are generated directly from the PROM and they do not occur at the same time as in MAME.
jt1943# 1943: Midway Kaisen, 1943 Kai: Midway Kaisen, 1943: The Battle of Midway Mark II jotego/jtcores @ b672aca5 MAME compared: capcom/1943.cpp + 2 related file(s) Read: 17 HDL files, 3,019 lines (files.yaml)	JTCORES	Not enough evidence in the code	insufficient	18%
Statements: 3 toward hardware, 1 toward MAME Cites hardware documentation that MAME's driver does not — 3 cores/gng/hdl/jtgng_objdma.v:33 Ghosts'n Goblins copies only 'h180 objects as per schematics 1943 copy more, but it is not clear what the limit is. cores/trojan/hdl/jttrojan_mcu.v:5 Following Trojan schematics, although it is not used in Trojan but Avengers README.md:59 Changed object to 8MHz as per schematics. Cites MAME source — 1 cores/gng/hdl/jtgng_sound.v:9 watch points for MAME: wpset e000,1,w,1,{printf "reg = %X", wpdata;g} wpset e001,1,w,1,{printf "val = %X", wpdata;g}
jtajax# Ajax jotego/jtcores @ b672aca5 MAME compared: konami/ajax.cpp + 7 related file(s) Read: 15 HDL files, 3,247 lines (files.yaml)	JTCORES	Both	low	42%
Statements: 5 toward hardware, 8 toward MAME Cites hardware documentation that MAME's driver does not — 5 hdl/jtajax_sub.v:79 OR'ed with blank output of 051316 (see J5 on sheet 2/3) cores/aliens/hdl/jt051960.v:5 Based on Furrtek's RE work on die shots and MAME documentation cores/aliens/hdl/jt051962.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi cores/aliens/hdl/jt052109.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi cores/aliens/hdl/jt052591.v:70 The die schematic gates external reads with BK (CPU_ERAM, sheet 3). Cites MAME source — 4 cores/aliens/hdl/jt051960.v:5 Based on Furrtek's RE work on die shots and MAME documentation cores/aliens/hdl/jt051960.v:104 original hardware outputs ram_dout[7:1], leaving 7'd0 for compatibility with MAME traces and it also simplifies logic cores/aliens/hdl/jt051962.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi cores/aliens/hdl/jt052109.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi Shares text with the MAME driver without saying so — 4 cores/aliens/hdl/jt052109.v:90 00 A~B 6~7 8~9 Reset state — shares text with konami/k052109.cpp:84 cores/aliens/hdl/jt052109.v:91 01 8~9 4~5 6~7 — shares text with konami/k052109.cpp:85 cores/aliens/hdl/jt052109.v:92 10 6~7 2~3 4~5 — shares text with konami/k052109.cpp:86 cores/aliens/hdl/jt052109.v:93 11 4~5 0~1 2~3 — shares text with konami/k052109.cpp:87
jtaliens# Aliens, Crazy Cop, Crime Fighters, Super Contra: Alien no Gyakushuu … jotego/jtcores @ b672aca5 MAME compared: konami/aliens.cpp, konami/crimfght.cpp, konami/thunderx.cpp + 7 related file(s) Read: 11 HDL files, 2,931 lines (files.yaml)	JTCORES	Mostly hardware	low	54%
Statements: 22 toward hardware, 8 toward MAME Cites hardware documentation that MAME's driver does not — 7 hdl/jt051960.v:5 Based on Furrtek's RE work on die shots and MAME documentation hdl/jt051962.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi hdl/jt052109.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi hdl/jt052591.v:70 The die schematic gates external reads with BK (CPU_ERAM, sheet 3). README.md:5 The PALs were dumped by Caius and are published [here](https://wiki.pldarchive.co.uk/index.php?title=Aliens). README.md:38 /NAS & /A15 & /A14; /ROM1CS =/NAS & A15 README.md:40 /NAS & /NINITSET & A14 & A13 & /BK3; /ROM2CS = /NAS & /NINITSET & /A15 & A14 & A13 & BK3; /CHAIN = NRMRD & /A15 & /A14 & A13 & A12; /INCS = NINITSET & /A15 Ships hardware documentation files — 15 cores/aliens/doc/051937_schematics.pdf cores/aliens/doc/051960_schematics.pdf cores/aliens/doc/052591/k052591_schematics.pdf cores/aliens/doc/Konami-052124.H13.pld cores/aliens/doc/Konami-052124.H13_GAL18V10.jed cores/aliens/doc/Konami-052124_H13_CK2605.jed cores/aliens/doc/Konami-052125.H15.pld cores/aliens/doc/Konami-052125.H15_GAL22V10.jed cores/aliens/doc/Konami-052125.H15_PLS173.jed cores/aliens/doc/Konami-053022_e19.jed cores/aliens/doc/Konami-053023_e18.jed cores/aliens/doc/Konami_053326_D21.jed cores/aliens/doc/Konami_053327_D20.jed cores/aliens/doc/k051962_schematics.pdf cores/aliens/doc/k052109_schematics.pdf Cites MAME source — 4 hdl/jt051960.v:5 Based on Furrtek's RE work on die shots and MAME documentation hdl/jt051960.v:104 original hardware outputs ram_dout[7:1], leaving 7'd0 for compatibility with MAME traces and it also simplifies logic hdl/jt051962.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi hdl/jt052109.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi Shares text with the MAME driver without saying so — 4 hdl/jt052109.v:90 00 A~B 6~7 8~9 Reset state — shares text with konami/k052109.cpp:84 hdl/jt052109.v:91 01 8~9 4~5 6~7 — shares text with konami/k052109.cpp:85 hdl/jt052109.v:92 10 6~7 2~3 4~5 — shares text with konami/k052109.cpp:86 hdl/jt052109.v:93 11 4~5 0~1 2~3 — shares text with konami/k052109.cpp:87
jtbiocom# Top Secret jotego/jtcores @ b672aca5 MAME compared: capcom/bionicc.cpp + 2 related file(s) Read: 21 HDL files, 3,945 lines (files.yaml)	JTCORES	Mostly hardware	low	24%
Statements: 3 toward hardware, 1 toward MAME Cites hardware documentation that MAME's driver does not — 1 cores/gng/hdl/jtgng_objdma.v:33 Ghosts'n Goblins copies only 'h180 objects as per schematics 1943 copy more, but it is not clear what the limit is. Reports a measurement taken on the original PCB — 2 hdl/jtbiocom_colmix.v:5 Resistor values measured on PCB by Caius (Twitter @Caius63417737) hdl/jtbiocom_main.v:397 Matches measurement of F1-Dream PCB, although the Bionic Commando schematics point to V256, that must be a typo or an old version using V256 prevents the game from registering coin inputs Cites MAME source — 1 hdl/jtbiocom_mcu.v:86 Current MAME models the MCU-to-sound transfer on the 1-to-0 transition of P3.6.
jtblkout# Block Out jotego/jtcores @ b672aca5 MAME compared: technos/blockout.cpp Read: 6 HDL files, 935 lines (files.yaml)	JTCORES	Not enough evidence in the code	insufficient	11%
Statements: 2 toward MAME Cites MAME source — 2 hdl/jtblkout_fb.v:62 shift image up 10px (MAME visarea V=10) README.md:3 FPGA core for the Technos Block Out board (MAME `technos/blockout.cpp`, 1989, Technos Japan / California Dreams), plus the `agress` variant on the same PCB
jtbtiger# Black Dragon jotego/jtcores @ b672aca5 MAME compared: capcom/blktiger.cpp Read: 22 HDL files, 4,109 lines (files.yaml)	JTCORES	Not enough evidence in the code	insufficient	13%
Statements: 2 toward hardware, 2 toward MAME Cites hardware documentation that MAME's driver does not — 2 hdl/jtbtiger_mcu.v:6 based on 1943 schematics cores/gng/hdl/jtgng_objdma.v:33 Ghosts'n Goblins copies only 'h180 objects as per schematics 1943 copy more, but it is not clear what the limit is. Cites MAME source — 2 hdl/jtbtiger_mcu.v:38 All bits active low 4 output enable of from-CPU latch 5 clock pin of to-CPU latch 1 clear interrupt only bit 1 is needed in FPGA implementation Note that MAME clears the interrupt in a different way as it does it when the main CPU reads fro cores/gng/hdl/jtgng_sound.v:9 watch points for MAME: wpset e000,1,w,1,{printf "reg = %X", wpdata;g} wpset e001,1,w,1,{printf "val = %X", wpdata;g}
jtbubl# Bubble Bobble, Tokio / Scramble Formation jotego/jtcores @ b672aca5 MAME compared: taito/bublbobl.cpp + 3 related file(s) Read: 7 HDL files, 1,564 lines (files.yaml)	JTCORES	Not enough evidence in the code	insufficient	42%
Statements: 2 toward hardware, 2 toward MAME Cites hardware documentation that MAME's driver does not — 2 hdl/jtbubl_main.v:412 This is a jumper on the schematics it can come from P1[6] or from VBL README.md:26 The cores have been developed by combining information in the MAME drivers with PLD dumps from the PLD archive and with full schematic extraction from the PCBs. Cites MAME source — 2 cores/kunio/hdl/jtkunio_mcu.v:42 MCU semaphore in MAME jargon README.md:26 The cores have been developed by combining information in the MAME drivers with PLD dumps from the PLD archive and with full schematic extraction from the PCBs.
jtcal50# Caliber 50 jotego/jtcores @ b672aca5 MAME compared: seta/downtown.cpp + 2 related file(s) Read: 10 HDL files, 1,866 lines (files.yaml)	JTCORES	Both	low	67%
Statements: 11 toward hardware, 6 toward MAME Cites hardware documentation that MAME's driver does not — 1 cores/kiwi/hdl/jtkiwi_gfx.v:9 SETAX1-001, the die shot available shows what it seems to be an internal dual-line buffer and another larger memory Reports a measurement taken on the original PCB — 1 hdl/jtcal50_video.v:98 Measured on PCB 64us per line, 8us blanking 17.45ms per frame, 2.05ms blanking, 512.5us sync (centered) Ships hardware documentation files — 9 cores/cal50/sch/cal50.kicad_sch cores/cal50/sch/color_mixer.kicad_sch cores/cal50/sch/cpu.kicad_sch cores/cal50/sch/graphics_1.kicad_sch cores/cal50/sch/graphics_2.kicad_sch cores/cal50/sch/io.kicad_sch cores/cal50/sch/misc.kicad_sch cores/cal50/sch/sound.kicad_sch cores/cal50/sch/sound_output.kicad_sch Cites MAME source — 5 cores/kiwi/hdl/jtkiwi_gfx.v:18 12 = 8kB sprite RAM, page selects the 0x800 half (tnzs/calibr50) 13 = 16kB, page selects the 0x1000 buffer (metafox/arbalest, MAME seta001 setac) cores/kiwi/hdl/jtkiwi_gfx.v:125 16kB sprite RAM: cfg[1] carries the buffer bank (MAME seta001 setac_eof) cores/kiwi/hdl/jtkiwi_gfx.v:290 Changed to 16-bit access to ease the drawing logic the upper byte refers to the upper half of the memory for the CPU In MAME the lower half is called spritecodelow and the upper spritecodehigh cores/kiwi/hdl/jtkiwi_obj.v:12 12 = 8kB sprite RAM, page selects the 0x800 half (tnzs/calibr50) 13 = 16kB, page selects the 0x1000 buffer (metafox/arbalest, MAME seta001 setac) cores/kiwi/hdl/jtkiwi_tilemap.v:107 This is probably some config setting unexplored by MAME Says it was translated, ported or taken from MAME — 1 hdl/jtx1012.v:5 X1-012, tilemap currently based on MAME information 64 columns, 32 rows, 16x16 tiles 1024x512 pixels
jtcastle# Akuma-Jou Dracula jotego/jtcores @ b672aca5 MAME compared: konami/hcastle.cpp + 5 related file(s) Read: 10 HDL files, 2,234 lines (files.yaml)	JTCORES	Not enough evidence in the code	insufficient	20%
Statements: 1 toward hardware Ships hardware documentation files — 1 cores/castle/doc/Konami_052127.jed
jtcircus# Circus Charlie jotego/jtcores @ b672aca5 MAME compared: konami/circusc.cpp + 2 related file(s) Read: 9 HDL files, 1,405 lines (files.yaml)	JTCORES	Not enough evidence in the code	insufficient	13%
Statements: 1 toward hardware Cites hardware documentation that MAME's driver does not — 1 hdl/jtcircus_main.v:127 74LS259 @ 1D
jtcommnd# Senjou no Ookami jotego/jtcores @ b672aca5 MAME compared: capcom/commando.cpp Read: 18 HDL files, 3,676 lines (files.yaml)	JTCORES	Both	low	41%
Statements: 5 toward hardware, 2 toward MAME, 2 not counted Cites hardware documentation that MAME's driver does not — 2 hdl/jtcommnd_main.v:430 Schematic 7L - sound interrupter cores/gng/hdl/jtgng_objdma.v:33 Ghosts'n Goblins copies only 'h180 objects as per schematics 1943 copy more, but it is not clear what the limit is. Cites hardware references or measurements that MAME's driver also gives — 2 hdl/jtcommnd_game.v:117 PROM 6L (interrupts) — also in MAME: 6L capcom/commando.cpp:103 hdl/jtcommnd_main.v:68 PROM 6L (interrupts) — also in MAME: 6L capcom/commando.cpp:103 Ships hardware documentation files — 3 cores/commnd/model/CHAR_RAM.sch cores/commnd/model/commando.sch cores/commnd/model/scrollh.sch Cites MAME source — 2 cores/gng/hdl/jtgng_sound.v:9 watch points for MAME: wpset e000,1,w,1,{printf "reg = %X", wpdata;g} wpset e001,1,w,1,{printf "val = %X", wpdata;g} README.md:24 The ROM Master, aka Bruno Silva, has provided us with a .bat file to generate the necessary ROM file using MAME ROM files.
jtcomsc# Combat School jotego/jtcores @ b672aca5 MAME compared: konami/combatsc.cpp + 8 related file(s) Read: 10 HDL files, 2,241 lines (files.yaml)	JTCORES	Not enough evidence in the code	insufficient	0%
No statements found
jtcontra# Contra jotego/jtcores @ b672aca5 MAME compared: konami/contra.cpp + 7 related file(s) Read: 11 HDL files, 2,192 lines (files.yaml)	JTCORES	Not enough evidence in the code	insufficient	0%
No statements found
jtcop# Fighting Fantasy, Robocop jotego/jtcores @ b672aca5 MAME compared: dataeast/dec0.cpp + 7 related file(s) Read: 13 HDL files, 3,429 lines (files.yaml)	JTCORES	Not enough evidence in the code	insufficient	13%
Statements: 1 toward hardware Cites hardware documentation that MAME's driver does not — 1 hdl/jtcop_bac06.v:27 The /NUDS and /NLDS inputs of all chips are gated via a 74LS32 chip by the /DSP chip select signal.
jtcps1# 1941: Counter Attack, Wonder 3, Area 88, Captain Commando … jotego/jtcores @ b672aca5 MAME compared: capcom/cps1.cpp + 4 related file(s) Read: 23 HDL files, 5,611 lines (files.yaml)	JTCORES	Both	low	11%
Statements: 2 toward hardware, 7 toward MAME, 1 not counted Cites hardware documentation that MAME's driver does not — 2 README.md:100 Use the tool jedutil in order to extract the equations from them. README.md:103 jedutil -view wl24b.1a gal16v8 Cites hardware references or measurements that MAME's driver also gives — 1 hdl/jtcps1_main.v:168 PAL IOA1 (16P8B @ 12F) — also in MAME: 12F capcom/cps1.cpp:35 Cites MAME source — 6 hdl/jtcps1_mmr.v:176 MAME uses the same values for layers 3 and 4 so I just skip layer 4 from the configuration. README.md:262 Video only simulations can be done using mame dumps. README.md:262 Use the tool cfg2mame in the ver/video folder to create two .mame files that can invoked from mame to dump the simulation data. README.md:263 Run the game in debug mode but source from MAME the register file that cfg2mame creates. README.md:264 Then at the point of interest souce vram.mame. README.md:264 Copy that file to a directory with the mame name of the game. Says it was translated, ported or taken from MAME — 1 hdl/jtcps1_prom_we.v:99 The decryption is literally copied from MAME, it is up to the synthesizer to optimize the code.
jtcps15# Cadillacs: Kyouryuu Shin Seiki, Muscle Bomber: The Body Explosion, Muscle Bomber Duo: Heat Up Warriors, The Punisher … jotego/jtcores @ b672aca5 MAME compared: capcom/cps1.cpp + 4 related file(s) Read: 23 HDL files, 5,880 lines (files.yaml)	JTCORES	Both	low	11%
Statements: 2 toward hardware, 7 toward MAME, 1 not counted Cites hardware documentation that MAME's driver does not — 2 README.md:92 Use the tool jedutil in order to extract the equations from them. README.md:95 jedutil -view wl24b.1a gal16v8 Cites hardware references or measurements that MAME's driver also gives — 1 cores/cps1/hdl/jtcps1_main.v:168 PAL IOA1 (16P8B @ 12F) — also in MAME: 12F capcom/cps1.cpp:35 Cites MAME source — 6 cores/cps1/hdl/jtcps1_mmr.v:176 MAME uses the same values for layers 3 and 4 so I just skip layer 4 from the configuration. README.md:254 Video only simulations can be done using mame dumps. README.md:254 Use the tool cfg2mame in the ver/video folder to create two .mame files that can invoked from mame to dump the simulation data. README.md:255 Run the game in debug mode but source from MAME the register file that cfg2mame creates. README.md:256 Then at the point of interest souce vram.mame. README.md:256 Copy that file to a directory with the mame name of the game. Says it was translated, ported or taken from MAME — 1 cores/cps1/hdl/jtcps1_prom_we.v:99 The decryption is literally copied from MAME, it is up to the synthesizer to optimize the code.
jtcps2# 1944: The Loop Master, 19XX: The War Against Destiny, Powered Gear: Strategic Variant Armor Equipment, Alien vs. Predator … jotego/jtcores @ b672aca5 MAME compared: capcom/cps2.cpp + 8 related file(s) Read: 36 HDL files, 7,819 lines (files.yaml)	JTCORES	Both	low	15%
Statements: 3 toward hardware, 7 toward MAME Cites hardware documentation that MAME's driver does not — 3 hdl/jtcps2_main.v:415 according to Loic's DL-1827 schematic README.md:92 Use the tool jedutil in order to extract the equations from them. README.md:95 jedutil -view wl24b.1a gal16v8 Cites MAME source — 6 cores/cps1/hdl/jtcps1_mmr.v:176 MAME uses the same values for layers 3 and 4 so I just skip layer 4 from the configuration. README.md:253 Video only simulations can be done using mame dumps. README.md:253 Use the tool cfg2mame in the ver/video folder to create two .mame files that can invoked from mame to dump the simulation data. README.md:254 Run the game in debug mode but source from MAME the register file that cfg2mame creates. README.md:255 Then at the point of interest souce vram.mame. README.md:255 Copy that file to a directory with the mame name of the game. Says it was translated, ported or taken from MAME — 1 cores/cps1/hdl/jtcps1_prom_we.v:99 The decryption is literally copied from MAME, it is up to the synthesizer to optimize the code.
jtcps3# JoJo no Kimyou na Bouken: Mirai e no Isan, JoJo no Kimyou na Bouken, Warzard, Street Fighter III 2nd Impact: Giant Attack … jotego/jtcores @ b672aca5 MAME compared: capcom/cps3.cpp + 3 related file(s) Read: 25 HDL files, 6,271 lines (files.yaml)	JTCORES	Mostly hardware	low	27%
Statements: 47 toward hardware, 1 toward MAME Ships hardware documentation files — 47 cores/cps3/sch/bic.kicad_sch cores/cps3/sch/blanking.kicad_sch cores/cps3/sch/buffer_line_driver.kicad_sch cores/cps3/sch/capacitors_uu.kicad_sch cores/cps3/sch/cassette.kicad_sch cores/cps3/sch/cbi.kicad_sch cores/cps3/sch/ccu.kicad_sch cores/cps3/sch/colmix.kicad_sch cores/cps3/sch/cps3.kicad_sch cores/cps3/sch/gfx.kicad_sch cores/cps3/sch/gll1.kicad_sch cores/cps3/sch/gll2.kicad_sch cores/cps3/sch/h_description.kicad_sch cores/cps3/sch/iou.kicad_sch cores/cps3/sch/main.kicad_sch cores/cps3/sch/memories.kicad_sch cores/cps3/sch/memories_fb.kicad_sch cores/cps3/sch/memories_gfx.kicad_sch cores/cps3/sch/memories_main.kicad_sch cores/cps3/sch/memories_scu.kicad_sch cores/cps3/sch/objects.kicad_sch cores/cps3/sch/plane_color.kicad_sch cores/cps3/sch/ppu.kicad_sch cores/cps3/sch/ram_cassette.kicad_sch cores/cps3/sch/report.txt cores/cps3/sch/scroll.kicad_sch cores/cps3/sch/simm.kicad_sch cores/cps3/sch/simm3.kicad_sch cores/cps3/sch/simm4.kicad_sch cores/cps3/sch/simm5.kicad_sch cores/cps3/sch/simm6.kicad_sch cores/cps3/sch/simm_connector.kicad_sch cores/cps3/sch/simm_gfx.kicad_sch cores/cps3/sch/simm_main.kicad_sch cores/cps3/sch/simms.kicad_sch cores/cps3/sch/simms_1-2.kicad_sch cores/cps3/sch/simms_2~1.kicad_sch cores/cps3/sch/simms_2~1_snd.kicad_sch cores/cps3/sch/simms_6~3.kicad_sch cores/cps3/sch/slot_male.kicad_sch cores/cps3/sch/slots_females.kicad_sch cores/cps3/sch/slots_sch.kicad_sch cores/cps3/sch/sound.kicad_sch cores/cps3/sch/ssu.kicad_sch cores/cps3/sch/trans.kicad_sch cores/cps3/sch/untitled.kicad_sch cores/cps3/sch/video_dac.kicad_sch Cites MAME source — 1 hdl/jtcps3_chardma.v:78 Command list pointer: word index inside 8 MiB char RAM (MAME-style)
jtdd# Double Dragon jotego/jtcores @ b672aca5 MAME compared: technos/ddragon.cpp + 2 related file(s) Read: 9 HDL files, 1,527 lines (files.yaml)	JTCORES	Not enough evidence in the code	insufficient	40%
Statements: 4 toward hardware, 2 toward MAME Cites hardware documentation that MAME's driver does not — 4 hdl/jtdd_main.v:74 sheet 8/10 hdl/jtdd_main.v:155 Schematic sheet 3/9 hdl/jtdd_obj.v:5 Schematics 3-7/10 OBJ Object layer Max 32 sprites per line hdl/jtdd_scroll.v:5 Schematics 8/10 and 9/10 BACK Scroll layer Cites MAME source — 2 README.md:23 ADPCM sounds with less treble than in MAME. README.md:106 The rom folder contains the batch files for both linux and windows to generate the ROM file starting from a MAME set.
jtdd2# Double Dragon II: The Revenge jotego/jtcores @ b672aca5 MAME compared: technos/ddragon.cpp + 2 related file(s) Read: 8 HDL files, 1,477 lines (files.yaml)	JTCORES	Not enough evidence in the code	insufficient	42%
Statements: 4 toward hardware, 2 toward MAME Cites hardware documentation that MAME's driver does not — 4 cores/dd/hdl/jtdd_main.v:74 sheet 8/10 cores/dd/hdl/jtdd_main.v:155 Schematic sheet 3/9 cores/dd/hdl/jtdd_obj.v:5 Schematics 3-7/10 OBJ Object layer Max 32 sprites per line cores/dd/hdl/jtdd_scroll.v:5 Schematics 8/10 and 9/10 BACK Scroll layer Cites MAME source — 2 README.md:23 ADPCM sounds with less treble than in MAME. README.md:107 The rom folder contains the batch files for both linux and windows to generate the ROM file starting from a MAME set.
jtddrbl# Double Dribble jotego/jtcores @ b672aca5 MAME compared: konami/ddribble.cpp + 1 related file(s) Read: 9 HDL files, 1,787 lines (files.yaml)	JTCORES	Both	low	51%
Statements: 10 toward hardware, 8 toward MAME Cites hardware documentation that MAME's driver does not — 10 hdl/jtddrbl_main.v:4 Hardware on the same SCHEMATIC page that holds the MAIN MC6809E: - MC6809E main CPU (drawn as "6809E" — pin-compatible footprint) visible pins: HALT, NMI, IRQ, FIRQ, RESET, BS, BA, R/W, E, Q, AVMA, BUSY, LIC, TSC, A0..A15, D0..D7 - 27512 ma hdl/jtddrbl_main.v:60 CPU A0..A15 bus (visible on SCHEMATIC page 1 main CPU pins) hdl/jtddrbl_main.v:71 ROM address composition — physical chip is one 27512 (64 KB) on SCHEMATIC page 1. hdl/jtddrbl_main.v:143 chip 1 NFIR (swap per schematic) hdl/jtddrbl_main.v:144 chip 1 NIRQ (swap per schematic) hdl/jtddrbl_sound.v:4 Hardware on SCHEMATIC page 1 top-right (tile_p1_topR.png): - MC6809E sound CPU - 27256 sound program EPROM (32 KB) — adjacent to the CPU - 2128SL sound work RAM (2 KB) — but MAME's map uses it as the SUB↔SOUND shared RAM (0x0000-0x07FF), so hdl/jtddrbl_sound.v:18 YM2203 + VLM5030 both run on the 3.58 MHz xtal — SCHEMATIC page 1. hdl/jtddrbl_sound.v:163 YM2203 runs on the 3.58 MHz xtal (SCHEMATIC page 1). hdl/jtddrbl_sound.v:205 VLM5030 runs on the 3.58 MHz xtal (SCHEMATIC page 1), gated by vlm_cen. hdl/jtddrbl_sub.v:4 Hardware on schematic page 1 (sub CPU + sound CPU + I/O): - MC6809E at designator A12 (top-left area of page 1), full 6809E pinout visible pins: HALT, NMI, IRQ, FIRQ, RESET, BS, BA, R/W, CLKE (pin 34), CLKQ (pin 35), AVMA, BUSY, TSC, A0..A1 Cites MAME source — 7 hdl/jtddrbl_main.v:115 MAME ref: konami/ddribble.cpp:331-334 void bankswitch_w(uint8_t data) { m_mainbank->set_entry(data & 0x07); } → 3-bit bank field, latched on write to 0x8000. hdl/jtddrbl_obj.v:81 MAME masks the base number per size (ddribble.cpp draw_sprites): hdl/jtddrbl_scroll.v:43 SDRAM is byteswap16(MAME) and the converter wants MAME packed_msb, so byteswap each 16-bit half before the transpose. hdl/jtddrbl_sound.v:4 Hardware on SCHEMATIC page 1 top-right (tile_p1_topR.png): - MC6809E sound CPU - 27256 sound program EPROM (32 KB) — adjacent to the CPU - 2128SL sound work RAM (2 KB) — but MAME's map uses it as the SUB↔SOUND shared RAM (0x0000-0x07FF), so hdl/jtddrbl_sound.v:19 MAME ref (pinned 347fd2c) for things not directly readable from the sheets: - konami/ddribble.cpp:413-419 sound CPU memory map (exact ranges) hdl/jtddrbl_sound.v:89 Y1 (0x1000-0x1FFF) OPN → YM2203 /CS [MAME ddribble.cpp:416 = 0x1000-0x1001] hdl/jtddrbl_sound.v:90 Y3 (0x3000-0x3FFF) VDATA → VLM5030 data latch [MAME ddribble.cpp:417 = 0x3000] Y6 (0x6000-0x6FFF) IRQEN → sound-IRQ ACKNOWLEDGE. Shares text with the MAME driver without saying so — 1 hdl/jtddrbl_main.v:116 void bankswitch_w(uint8_t data) { m_mainbank->set_entry(data & 0x07); } — shares text with konami/ddribble.cpp:87
jtexed# Exed Exes jotego/jtcores @ b672aca5 MAME compared: capcom/exedexes.cpp Read: 21 HDL files, 4,012 lines (files.yaml)	JTCORES	Mostly hardware	low	41%
Statements: 43 toward hardware Cites hardware documentation that MAME's driver does not — 6 cores/commnd/hdl/jtcommnd_main.v:68 PROM 6L (interrupts) cores/commnd/hdl/jtcommnd_main.v:430 Schematic 7L - sound interrupter hdl/jtexed_game.v:153 PROM 6L (interrupts) hdl/jtexed_sound.v:5 based on 1942 Schematics page 3/8 cores/gng/hdl/jtgng_objdma.v:33 Ghosts'n Goblins copies only 'h180 objects as per schematics 1943 copy more, but it is not clear what the limit is. README.md:34 The core is made based on the actual schematics, not emulators. Ships hardware documentation files — 37 cores/exed/sch/bus_control_dma.kicad_sch cores/exed/sch/capacitors.kicad_sch cores/exed/sch/char.kicad_sch cores/exed/sch/coin_l.kicad_sch cores/exed/sch/colmix.kicad_sch cores/exed/sch/ds_cabinete.kicad_sch cores/exed/sch/ds_gabinete.kicad_sch cores/exed/sch/exed.kicad_sch cores/exed/sch/h_counter.kicad_sch cores/exed/sch/h_scroll.kicad_sch cores/exed/sch/h_scroll1.kicad_sch cores/exed/sch/h_scroll1_2.kicad_sch cores/exed/sch/interruption.kicad_sch cores/exed/sch/last_u.kicad_sch cores/exed/sch/logics_gates.kicad_sch cores/exed/sch/main.kicad_sch cores/exed/sch/mux.kicad_sch cores/exed/sch/mux_ot.kicad_sch cores/exed/sch/obj_counters.kicad_sch cores/exed/sch/obj_lut.kicad_sch cores/exed/sch/obj_mx.kicad_sch cores/exed/sch/obj_ram.kicad_sch cores/exed/sch/obj_rom.kicad_sch cores/exed/sch/object_table.kicad_sch cores/exed/sch/psg.kicad_sch cores/exed/sch/ram_rom.kicad_sch cores/exed/sch/ram_rom_main.kicad_sch cores/exed/sch/rom_olut.kicad_sch cores/exed/sch/scroll1.kicad_sch cores/exed/sch/scroll2.kicad_sch cores/exed/sch/snd_c_latch.kicad_sch cores/exed/sch/sound.kicad_sch cores/exed/sch/v_counter.kicad_sch cores/exed/sch/v_scroll.kicad_sch cores/exed/sch/v_scroll1.kicad_sch cores/exed/sch/video.kicad_sch cores/exed/sch/video_timings.kicad_sch
jtflane# Fast Lane jotego/jtcores @ b672aca5 MAME compared: konami/fastlane.cpp + 7 related file(s) Read: 9 HDL files, 1,919 lines (files.yaml)	JTCORES	Not enough evidence in the code	insufficient	0%
No statements found
jtflstory# Cycle Shooting, N.Y. Captor, The FairyLand Story, Onna Sanshirou - Typhoon Gal … jotego/jtcores @ b672aca5 MAME compared: taito/flstory.cpp, taito/nycaptor.cpp + 1 related file(s) Read: 17 HDL files, 2,212 lines (files.yaml)	JTCORES	Mostly hardware	low	24%
Statements: 28 toward hardware Cites hardware documentation that MAME's driver does not — 3 hdl/jtflstory_mcu.v:69 74LS74 set input has priority over clock hdl/jtflstory_mcu.v:75 74LS74 set input has priority over clock README.md:3 This work is based on the schematic work we did on an original FairyLand arcade PCB. Ships hardware documentation files — 25 cores/flstory/sch/adapter/adapter.kicad_sch cores/flstory/sch/flstory/amplifiers.kicad_sch cores/flstory/sch/flstory/capacitors_lu.kicad_sch cores/flstory/sch/flstory/colmix.kicad_sch cores/flstory/sch/flstory/fairyland.kicad_sch cores/flstory/sch/flstory/io_cabinet.kicad_sch cores/flstory/sch/flstory/latches.kicad_sch cores/flstory/sch/flstory/linebuf.kicad_sch cores/flstory/sch/flstory/main.kicad_sch cores/flstory/sch/flstory/mcu.kicad_sch cores/flstory/sch/flstory/obj_ram.kicad_sch cores/flstory/sch/flstory/ongen.kicad_sch cores/flstory/sch/flstory/palette.kicad_sch cores/flstory/sch/flstory/secondary.kicad_sch cores/flstory/sch/flstory/shared.kicad_sch cores/flstory/sch/flstory/snd_clocks.kicad_sch cores/flstory/sch/flstory/sound.kicad_sch cores/flstory/sch/flstory/sub_main.kicad_sch cores/flstory/sch/flstory/tilerom.kicad_sch cores/flstory/sch/flstory/timing.kicad_sch cores/flstory/sch/flstory/video.kicad_sch cores/flstory/sch/flstory/vram.kicad_sch cores/flstory/sch/flstory/watchdog.kicad_sch cores/flstory/sch/msm5232/msm5232.kicad_sch cores/flstory/sch/sound_connector/sound_connector.kicad_sch
jtfround# Hard Puncher jotego/jtcores @ b672aca5 MAME compared: konami/twin16.cpp + 3 related file(s) Read: 13 HDL files, 2,375 lines (files.yaml)	JTCORES	Mostly hardware	low	37%
Statements: 17 toward hardware, 2 toward MAME Cites hardware documentation that MAME's driver does not — 3 hdl/jt00778x.v:5 Based on Skutis' RE work on die shots and MAME documentation hdl/jt00778x.v:80 original equation from schematics, it is the same as the start of vblank README.md:20 This core is based on the official schematics for this system and the reverse engineering work done by Skutis on them. Ships hardware documentation files — 14 cores/fround/sch/GFX-Fixed layer.kicad_sch cores/fround/sch/GFX-Tiles.kicad_sch cores/fround/sch/color_mixer.kicad_sch cores/fround/sch/cpu.kicad_sch cores/fround/sch/fround.kicad_sch cores/fround/sch/io.kicad_sch cores/fround/sch/pixel_mixer.kicad_sch cores/fround/sch/sound.kicad_sch cores/fround/sch/sprite_timing_diagrams.kicad_sch cores/fround/sch/sprites1.kicad_sch cores/fround/sch/sprites2.kicad_sch cores/fround/sch/timing.kicad_sch cores/fround/sch/timing_diagrams.kicad_sch cores/fround/sch/timing_signals.kicad_sch Cites MAME source — 2 hdl/jt00778x.v:5 Based on Skutis' RE work on die shots and MAME documentation hdl/jtfround_video.v:154 60.6 Hz according to MAME
jtgae1# Big Karnak, Biomechanical Toy, Squash, Thunder Hoop jotego/jtcores @ b672aca5 MAME compared: gaelco/gaelco.cpp + 4 related file(s) Read: 9 HDL files, 1,473 lines (files.yaml)	JTCORES	Not enough evidence in the code	insufficient	0%
Statements: 1 toward MAME Says it was translated, ported or taken from MAME — 1 README.md:4 This core is based on the MAME driver for Gaelco GAE1 hardware and some PCB measurements to validate clock, video frequencies and discard DMA behavior.
jtgaiden# Ninja Ryukenden, Raiga - Strato Fighter, Wild Fang jotego/jtcores @ b672aca5 MAME compared: tecmo/gaiden.cpp + 2 related file(s) Read: 17 HDL files, 1,814 lines (files.yaml)	JTCORES	Not enough evidence in the code	insufficient	0%
Statements: 3 toward MAME Cites MAME source — 3 README.md:7 The core mostly follows MAME, with deviations natural from a digital logic implementation point of view. README.md:9 Blending is implemented by blinking the two elements to blend, this is different from MAME's implementation. README.md:14 Some items may not be accurate on MAME driver and should be double checked:
jtgals# Gals Panic jotego/jtcores @ b672aca5 MAME compared: kaneko/galpanic.cpp + 5 related file(s) Read: 7 HDL files, 1,087 lines (files.yaml)	JTCORES	Not enough evidence in the code	insufficient	0%
No statements found
jtgng# Makaimura jotego/jtcores @ b672aca5 MAME compared: capcom/gng.cpp Read: 18 HDL files, 3,370 lines (files.yaml)	JTCORES	Not enough evidence in the code	insufficient	13%
Statements: 2 toward hardware, 1 toward MAME Cites hardware documentation that MAME's driver does not — 2 hdl/jtgng_objdma.v:33 Ghosts'n Goblins copies only 'h180 objects as per schematics 1943 copy more, but it is not clear what the limit is. README.md:37 A verilog model of the original hardware, replicated from original schematics. Cites MAME source — 1 hdl/jtgng_sound.v:9 watch points for MAME: wpset e000,1,w,1,{printf "reg = %X", wpdata;g} wpset e001,1,w,1,{printf "val = %X", wpdata;g}
jtgrad3# Gradius III: Densetsu kara Shinwa e, Gradius III (NEW Ver.) jotego/jtcores @ b672aca5 MAME compared: konami/gradius3.cpp + 7 related file(s) Read: 14 HDL files, 2,851 lines (files.yaml)	JTCORES	Both	low	51%
Statements: 18 toward hardware, 8 toward MAME Cites hardware documentation that MAME's driver does not — 5 cores/aliens/hdl/jt051960.v:5 Based on Furrtek's RE work on die shots and MAME documentation cores/aliens/hdl/jt051962.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi cores/aliens/hdl/jt052109.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi hdl/jtgrad3_arbiter.v:5 F22, the video bus mutex: one 74LS74 with its halves clocked on opposite phases of the 24 MHz clock, each Q asynchronously presetting the other. hdl/jtgrad3_colmix.v:5 Based on the work in Gradius III schematics by Skutis Ships hardware documentation files — 13 cores/grad3/sch/052535/052535.kicad_sch cores/grad3/sch/grad3/color_mixer.kicad_sch cores/grad3/sch/grad3/cpu_master.kicad_sch cores/grad3/sch/grad3/cpu_slave.kicad_sch cores/grad3/sch/grad3/grad3.kicad_sch cores/grad3/sch/grad3/io.kicad_sch cores/grad3/sch/grad3/misc.kicad_sch cores/grad3/sch/grad3/object_layer.kicad_sch cores/grad3/sch/grad3/pcm.kicad_sch cores/grad3/sch/grad3/shram.kicad_sch cores/grad3/sch/grad3/sound.kicad_sch cores/grad3/sch/grad3/tile_layers.kicad_sch cores/grad3/sch/grad3/tile_logic.kicad_sch Cites MAME source — 4 cores/aliens/hdl/jt051960.v:5 Based on Furrtek's RE work on die shots and MAME documentation cores/aliens/hdl/jt051960.v:104 original hardware outputs ram_dout[7:1], leaving 7'd0 for compatibility with MAME traces and it also simplifies logic cores/aliens/hdl/jt051962.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi cores/aliens/hdl/jt052109.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi Shares text with the MAME driver without saying so — 4 cores/aliens/hdl/jt052109.v:90 00 A~B 6~7 8~9 Reset state — shares text with konami/k052109.cpp:84 cores/aliens/hdl/jt052109.v:91 01 8~9 4~5 6~7 — shares text with konami/k052109.cpp:85 cores/aliens/hdl/jt052109.v:92 10 6~7 2~3 4~5 — shares text with konami/k052109.cpp:86 cores/aliens/hdl/jt052109.v:93 11 4~5 0~1 2~3 — shares text with konami/k052109.cpp:87
jtgunsmk# Gun.Smoke jotego/jtcores @ b672aca5 MAME compared: capcom/gunsmoke.cpp Read: 16 HDL files, 2,977 lines (files.yaml)	JTCORES	Not enough evidence in the code	insufficient	32%
Statements: 3 toward hardware, 1 toward MAME Cites hardware documentation that MAME's driver does not — 2 cores/gng/hdl/jtgng_objdma.v:33 Ghosts'n Goblins copies only 'h180 objects as per schematics 1943 copy more, but it is not clear what the limit is. hdl/jtgunsmk_main.v:200 1943 Schematics page 5/9, parts 12J and 14K Reports a measurement taken on the original PCB — 1 hdl/jtgunsmk_game.v:123 Objects DMA timing measured on real PCB was roughly 130us which correspons to these parameters: Cites MAME source — 1 cores/gng/hdl/jtgng_sound.v:9 watch points for MAME: wpset e000,1,w,1,{printf "reg = %X", wpdata;g} wpset e001,1,w,1,{printf "val = %X", wpdata;g}
jtharier# Enduro Racer, Hang-On, Space Harrier jotego/jtcores @ b672aca5 MAME compared: sega/segahang.cpp + 13 related file(s) Read: 20 HDL files, 4,130 lines (files.yaml)	JTCORES	Both	medium	70%
Statements: 18 toward hardware, 30 toward MAME, 1 not counted Cites hardware documentation that MAME's driver does not — 16 hdl/jtharier_cab.v:5 Flight-stick conditioning to ADC0/ADC1, CPU sheet 2/6 (IC126/IC125). hdl/jtharier_colmix.v:65 SHADE from 315-5171, sheet 6/7. hdl/jtharier_main.v:22 Address decode, CK-2605 315-5166 on CPU sheet 1/6 hdl/jtharier_main.v:38 Work RAM, IC96/IC83 on CPU sheet 1/6 hdl/jtharier_main.v:79 Sub PPI port A, CPU sheet 2/6 hdl/jtharier_main.v:83 i8751, CPU sheet 1/6 hdl/jtharier_main.v:174 IC106 (CK-2605 315-5168, control sheet 1/7) decides it from /VRAM, AD1, AD15, H3, HA3, HB3 and /HSYNC -- no vertical input, so it applies to every VRAM access all frame long. hdl/jtharier_main.v:293 Flight-stick ADC at 140030, sheet 2/6: IC126 ADC0804 behind the IC125 CD4051 mux, channel select from PPI1 port A[3:2], /INTR returned on PPI1 port C bit 6. hdl/jtharier_main.v:399 The board does this with the BREQ/BACK handshake at IC23/IC8/IC9 (sheet 1/6); jts16_main models the S16A equivalent, its IC69 82S153. hdl/jtharier_road.v:5 Space Harrier road generator: the 315-5025 custom (sheet 4/6), road control RAM 2016 x2 (IC50/IC63), road data ROM EPR-7181 (IC2), LS669 x3 counters (IC14/15/16). hdl/jtharier_road.v:7 The 315-5025 has no decap, so its per-pixel behaviour comes from MAME's model -- the last-resort source for a custom the schematic and the siblings cannot describe. hdl/jtharier_roadarb.v:5 Road RAM CPU-port arbiter, CPU sheet 3/6. hdl/jtharier_sound.v:15 Main CPU interface via PPI0, CPU sheet 2/6 hdl/jtharier_sub.v:14 Shared RAM and road RAM, dual ported through the LS157 mux IC80-IC83, CPU sheet 3/6 hdl/jtharier_sub.v:26 Program ROM EPR-7182/7183, CPU sheet 3/6 README.md:5 This core is based on the schematics for Space Harrier, the JTS16 and JTOUTRUN cores for parts of the graphics and sound system, and on the documentation of spr Cites hardware references or measurements that MAME's driver also gives — 1 hdl/jtharier_road.v:95 4-bit counter at 9M, low 3 bits count bits in a byte — also in MAME: 9M sega/segaic16_road.cpp:111 Reports a measurement taken on the original PCB — 1 cores/s16/hdl/jts16_tilemap.v:135 Measured on PCB vint lasts 64us, starts one line before blanking vsync occurs 16 lines later Ships hardware documentation files — 1 cores/harier/pal/315-5171.txt Cites MAME source — 24 hdl/jtharier_main.v:158 Block the MCU's write to the main/MCU sync byte at 0x040385, as MAME does unconditionally (segahang.cpp i8751_w: "the cpu is too fast or the mcu too slow ... hdl/jtharier_main.v:295 ADC0 is stick X and ADC1 stick Y, both centred at 0x80 (segahang.cpp:915). hdl/jtharier_obj.v:111 The sharrier device origin is (189,-1) (sega16sp.cpp), so HOBJ_START = 189 reads device x 189 out on column 0, and HOBJ_FLIP = 508 is the same column flipped -- the buffer's own flip pivots on 511, the wrong point for a 189..508 window. hdl/jtharier_obj_draw.v:7 ATTRIBUTION -- the draw algorithm is derived from MAME `sega_sharrier_sprite_device::draw` in sega16sp.cpp (Aaron Giles, BSD-3-Clause). hdl/jtharier_obj_draw.v:12 Horizontal zoom is shrink-only, sega16sp.cpp:398: xacc = (xacc & 0xff) + hzoom; if(xacc < 0x100){ draw; screen x++ } The source pixel always advances; the screen pixel only when xacc did not carry. hdl/jtharier_obj_draw.v:15 Flip reads words and nibbles in reverse (sega16sp.cpp:420). hdl/jtharier_obj_draw.v:21 pal==6'h3f is shadow (segahang.cpp:282). hdl/jtharier_obj_draw.v:39 MAME value: (field & 0x3f) << 1 hdl/jtharier_obj_draw.v:74 per-pixel shadow: shadow-enabled AND pix==0xA (segahang.cpp:282, (pix&0x80f)==0x00a) hdl/jtharier_obj_scan.v:7 ATTRIBUTION -- derived from MAME `sega_sharrier_sprite_device::draw` in sega16sp.cpp (Aaron Giles, BSD-3-Clause). hdl/jtharier_obj_scan.v:11 Descriptor (8 words, sega16sp.cpp:291); words +0..+8 only: +0 bbbbbbbb tttttttt bottom=[15:8], top=[7:0] (DEVICE scanlines) +2 -bbb---- -------- bank +2 -------x xxxxxxxx xpos (xpos $BD = screen X 0, applied in _obj.v) +4 s------ hdl/jtharier_obj_scan.v:26 Vertical zoom is stateful down the sprite, sega16sp.cpp:367: for y = top..bottom-1: addr += pitch; if(zoom[zaddr++] & zmask) addr += pitch zaddr = (vzoom & 0x38) << 5 == { vzoom[5:3], 8'd0 } zmask = 1 << (vzoom & 7) == zoom_data[ v hdl/jtharier_obj_scan.v:195 MAME: (field & 0x3f) << 1 hdl/jtharier_road.v:7 The 315-5025 has no decap, so its per-pixel behaviour comes from MAME's model -- the last-resort source for a custom the schematic and the siblings cannot describe. hdl/jtharier_road.v:9 The state names are MAME's and map onto the sheet-4/6 parts -- 9M/9N/9P = LS669, 8J = LS164, 9J = LS174 -- so the transcription can be checked against segaic16_road.cpp line for line. hdl/jtharier_road.v:19 Road control RAM word map (roadram, 0x400 words used of 0x800), MAME offsets /2: 0x000-0x0FF per scanline: control [11:10] plycont road priority vs tilemaps/sprites [9] /CE of the road ROM (Space Harrier: 1 disables ROM data) [8] hdl/jtharier_road.v:58 Colour bases, segahang.cpp:190 segaic16_road_init(0, ROAD_SHARRIER). hdl/jtharier_road.v:63 The pipeline runs from x=-24 to warm ss8j and the counters but must not be drawn (segaic16_road.cpp:199). hdl/jtharier_road.v:69 PROVISIONAL: this value agrees with MAME, and MAME is not the authority here. hdl/jtharier_road.v:94 Per-pixel engine state, MAME node names retained hdl/jtharier_road.v:122 ff9j1 with the forcing applied (MAME 137-142), combinational so the forced value feeds this cycle's 6M updates rather than the next. hdl/jtharier_video.v:103 The fault is in the mask ROM, confirmed on the cabinet and in MAME. hdl/jtharier_video.v:164 Text/HUD is at the very front: segahang.cpp inflates the text priority so sprites never cover the high scores. README.md:5 This core is based on the schematics for Space Harrier, the JTS16 and JTOUTRUN cores for parts of the graphics and sound system, and on the documentation of spr Says it matches, follows or was checked against MAME — 1 hdl/jtharier_cab.v:33 matches MAME PORT_KEYDELTA(4) Says it was translated, ported or taken from MAME — 1 hdl/jtharier_road.v:14 license:BSD-3-Clause copyright-holders:Aaron Giles Transcribed from MAME segaic16_road.cpp, segaic16_road_hangon_draw (ROAD_SHARRIER path). Shares text with the MAME driver without saying so — 4 hdl/jtharier_main.v:159 unconditionally (segahang.cpp i8751_w: "the cpu is too fast or the mcu too — shares text with sega/segahang.cpp:523 hdl/jtharier_main.v:160 slow ... the mcu clears this value after the cpu sets it"). If the clear lands, — shares text with sega/segahang.cpp:524 hdl/jtharier_obj_draw.v:5 Sprite row renderer for the Space Harrier custom (315-5011/5012). ATTRIBUTION -- the draw algorithm is derived from MAME `sega_sharrier_sprite_device:: — shares text with sega/sega16sp.cpp hdl/jtharier_obj_scan.v:5 Sprite table scanner for the Space Harrier custom (315-5011/5012). ATTRIBUTION -- derived from MAME `sega_sharrier_sprite_device::draw` in sega16sp.cpp — shares text with sega/sega16sp.cpp
jtkarnov# Atomic Runner Chelnov, Karnov, Wonder Planet jotego/jtcores @ b672aca5 MAME compared: dataeast/karnov.cpp + 4 related file(s) Read: 6 HDL files, 1,285 lines (files.yaml)	JTCORES	Not enough evidence in the code	insufficient	23%
Statements: 1 toward hardware Cites hardware documentation that MAME's driver does not — 1 hdl/jtkarnov_main.v:103 page 7/16)
jtkchamp# Karate Dou, Taisen Karate Dou jotego/jtcores @ b672aca5 MAME compared: dataeast/kchamp.cpp + 2 related file(s) Read: 7 HDL files, 1,139 lines (files.yaml)	JTCORES	Not enough evidence in the code	insufficient	0%
Statements: 1 toward MAME Cites MAME source — 1 README.md:15 The single player version was derived from the MAME driver and the 2P version.
jtkicker# Kicker jotego/jtcores @ b672aca5 MAME compared: konami/shaolins.cpp Read: 8 HDL files, 1,393 lines (files.yaml)	JTCORES	Not enough evidence in the code	insufficient	20%
Statements: 2 toward hardware, 1 toward MAME Cites hardware documentation that MAME's driver does not — 1 README.md:4 We have analysed the PCB and extracted full schematics from it. Ships hardware documentation files — 1 cores/kicker/sch/kicker.kicad_sch Cites MAME source — 1 README.md:4 The discoveries found during this process have been reported to the MAME team.
jtkiwi# Arkanoid - Revenge of DOH, Chuka Taisen, Dr. Toppel's Tankentai, Extermination … jotego/jtcores @ b672aca5 MAME compared: taito/tnzs.cpp + 3 related file(s) Read: 9 HDL files, 2,131 lines (files.yaml)	JTCORES	Both	low	46%
Statements: 38 toward hardware, 6 toward MAME Cites hardware documentation that MAME's driver does not — 2 hdl/jtkiwi_gfx.v:9 SETAX1-001, the die shot available shows what it seems to be an internal dual-line buffer and another larger memory README.md:31 The cores have been developed by combining information in the MAME drivers with PLD dumps from the PLD archive and with full schematic extraction from the PCBs. Ships hardware documentation files — 36 cores/kiwi/sch/arknoid2/arknoid2.kicad_sch cores/kiwi/sch/arknoid2/cpu.kicad_sch cores/kiwi/sch/arknoid2/gfx.kicad_sch cores/kiwi/sch/arknoid2/io.kicad_sch cores/kiwi/sch/arknoid2/misc.kicad_sch cores/kiwi/sch/arknoid2/sound.kicad_sch cores/kiwi/sch/extrmatn/capacitors.kicad_sch cores/kiwi/sch/extrmatn/colmix.kicad_sch cores/kiwi/sch/extrmatn/exterm.kicad_sch cores/kiwi/sch/extrmatn/gfx.kicad_sch cores/kiwi/sch/extrmatn/gfx_ram.kicad_sch cores/kiwi/sch/extrmatn/gfx_rom.kicad_sch cores/kiwi/sch/extrmatn/main.kicad_sch cores/kiwi/sch/extrmatn/mcu.kicad_sch cores/kiwi/sch/extrmatn/sound.kicad_sch cores/kiwi/sch/extrmatn/watchdog.kicad_sch cores/kiwi/sch/insectx/colmix.kicad_sch cores/kiwi/sch/insectx/cpu.kicad_sch cores/kiwi/sch/insectx/gfx.kicad_sch cores/kiwi/sch/insectx/graphics.kicad_sch cores/kiwi/sch/insectx/insectx.kicad_sch cores/kiwi/sch/insectx/io.kicad_sch cores/kiwi/sch/insectx/main.kicad_sch cores/kiwi/sch/insectx/mcu.kicad_sch cores/kiwi/sch/insectx/misc.kicad_sch cores/kiwi/sch/insectx/sound.kicad_sch cores/kiwi/sch/insectx/untitled.kicad_sch cores/kiwi/sch/insectx/watchdog.kicad_sch cores/kiwi/sch/tnzs/cpu.kicad_sch cores/kiwi/sch/tnzs/graphics.kicad_sch cores/kiwi/sch/tnzs/io.kicad_sch cores/kiwi/sch/tnzs/misc.kicad_sch cores/kiwi/sch/tnzs/sound.kicad_sch cores/kiwi/sch/tnzs/sub_pcb.kicad_sch cores/kiwi/sch/tnzs/tnzs.kicad_sch cores/kiwi/sch/tnzs/top_board.kicad_sch Cites MAME source — 6 hdl/jtkiwi_gfx.v:18 12 = 8kB sprite RAM, page selects the 0x800 half (tnzs/calibr50) 13 = 16kB, page selects the 0x1000 buffer (metafox/arbalest, MAME seta001 setac) hdl/jtkiwi_gfx.v:125 16kB sprite RAM: cfg[1] carries the buffer bank (MAME seta001 setac_eof) hdl/jtkiwi_gfx.v:290 Changed to 16-bit access to ease the drawing logic the upper byte refers to the upper half of the memory for the CPU In MAME the lower half is called spritecodelow and the upper spritecodehigh hdl/jtkiwi_obj.v:12 12 = 8kB sprite RAM, page selects the 0x800 half (tnzs/calibr50) 13 = 16kB, page selects the 0x1000 buffer (metafox/arbalest, MAME seta001 setac) hdl/jtkiwi_tilemap.v:107 This is probably some config setting unexplored by MAME README.md:31 The cores have been developed by combining information in the MAME drivers with PLD dumps from the PLD archive and with full schematic extraction from the PCBs.
jtkunio# Nekketsu Kouha Kunio-kun jotego/jtcores @ b672aca5 MAME compared: technos/renegade.cpp Read: 9 HDL files, 1,302 lines (files.yaml)	JTCORES	Mostly hardware	low	25%
Statements: 16 toward hardware, 3 toward MAME Ships hardware documentation files — 16 cores/kunio/sch/capacitors.kicad_sch cores/kunio/sch/characters.kicad_sch cores/kunio/sch/colmix.kicad_sch cores/kunio/sch/counters.kicad_sch cores/kunio/sch/double_line_buffer.kicad_sch cores/kunio/sch/io.kicad_sch cores/kunio/sch/kunio.kicad_sch cores/kunio/sch/last unit.kicad_sch cores/kunio/sch/main.kicad_sch cores/kunio/sch/memories_sprite.kicad_sch cores/kunio/sch/obj_draw.kicad_sch cores/kunio/sch/obj_lut_buf.kicad_sch cores/kunio/sch/objects.kicad_sch cores/kunio/sch/scroll.kicad_sch cores/kunio/sch/scrom_memories.kicad_sch cores/kunio/sch/sound.kicad_sch Cites MAME source — 3 hdl/jtkunio_mcu.v:42 MCU semaphore in MAME jargon README.md:23 ADPCM sounds with less treble than in MAME. README.md:107 The rom folder contains the batch files for both linux and windows to generate the ROM file starting from a MAME set.
jtlabrun# Labyrinth Runner jotego/jtcores @ b672aca5 MAME compared: konami/labyrunr.cpp + 7 related file(s) Read: 13 HDL files, 2,564 lines (files.yaml)	JTCORES	Not enough evidence in the code	insufficient	0%
No statements found
jtmidres# Midnight Resistance jotego/jtcores @ b672aca5 MAME compared: dataeast/dec0.cpp + 7 related file(s) Read: 12 HDL files, 3,164 lines (files.yaml)	JTCORES	Mostly hardware	low	35%
Statements: 7 toward hardware, 1 toward MAME Cites hardware documentation that MAME's driver does not — 1 cores/cop/hdl/jtcop_bac06.v:27 The /NUDS and /NLDS inputs of all chips are gated via a 74LS32 chip by the /DSP chip select signal. Ships hardware documentation files — 6 cores/midres/doc/jedec/MidRes-TB-1-1-(PAL1-19H).jed cores/midres/doc/jedec/MidRes-TB-2-(PAL2-10H).jed cores/midres/doc/jedec/MidRes-TB-3-(PAL3-9H).jed cores/midres/doc/jedec/MidRes-TB-4-(PAL4-8H).jed cores/midres/doc/jedec/MidRes-TB-5-(PAL5-14H).jed cores/midres/doc/jedec/MidRes-TB-6-(PAL6-20H).jed Cites MAME source — 1 hdl/jtmidres_colmix.v:5 The layer priority is solved as in MAME I hope to get access to a Midnight Resistance board at some point and derive the original circuit
jtmikie# Shinnyuu Shain Tooru-kun jotego/jtcores @ b672aca5 MAME compared: konami/mikie.cpp + 1 related file(s) Read: 9 HDL files, 1,548 lines (files.yaml)	JTCORES	Not enough evidence in the code	insufficient	12%
Statements: 2 toward hardware, 1 toward MAME Cites hardware documentation that MAME's driver does not — 2 hdl/jtmikie_main.v:126 74LS259 README.md:4 We have analysed the PCB and extracted full schematics from it. Cites MAME source — 1 README.md:4 The discoveries found during this process have been reported to the MAME team.
jtmx5k# Flak Attack jotego/jtcores @ b672aca5 MAME compared: konami/flkatck.cpp + 7 related file(s) Read: 12 HDL files, 2,416 lines (files.yaml)	JTCORES	Not enough evidence in the code	insufficient	8%
Statements: 1 toward hardware Cites hardware documentation that MAME's driver does not — 1 hdl/jtmx5k_video.v:149 Note that the logic gates 13F and 14F in the schematics use the object and tile blank information so the second K007121 selects between object and sprite correctly This second K007121 has been removed from the FPGA core and instead the pale
jtninja# Dragonninja, Heavy Barrel jotego/jtcores @ b672aca5 MAME compared: dataeast/dec0.cpp + 7 related file(s) Read: 12 HDL files, 3,185 lines (files.yaml)	JTCORES	Mostly hardware	low	31%
Statements: 7 toward hardware, 1 toward MAME Cites hardware documentation that MAME's driver does not — 1 cores/cop/hdl/jtcop_bac06.v:27 The /NUDS and /NLDS inputs of all chips are gated via a 74LS32 chip by the /DSP chip select signal. Ships hardware documentation files — 6 cores/ninja/doc/MidRes-TB-1-1-(PAL1-19H).jed cores/ninja/doc/MidRes-TB-2-(PAL2-10H).jed cores/ninja/doc/MidRes-TB-3-(PAL3-9H).jed cores/ninja/doc/MidRes-TB-4-(PAL4-8H).jed cores/ninja/doc/MidRes-TB-5-(PAL5-14H).jed cores/ninja/doc/MidRes-TB-6-(PAL6-20H).jed Cites MAME source — 1 README.md:63 BAC06 chip \| Region \| Total Size \| MSFT \| MAME gfx
jtoutrun# Out Run, Turbo Out Run jotego/jtcores @ b672aca5 MAME compared: sega/segaorun.cpp + 15 related file(s) Read: 24 HDL files, 5,534 lines (files.yaml)	JTCORES	Mostly hardware	low	60%
Statements: 7 toward hardware, 4 toward MAME Cites hardware documentation that MAME's driver does not — 4 hdl/jtoutrun_colmix.v:5 Video board, schematic sheet 5 of 7 hdl/jtoutrun_main.v:28 SG bus on page 6/7 hdl/jtoutrun_video.v:149 first 8kB of pal RAM dumped cores/s16b/hdl/jts16b_mapper.v:232 see schematics page 10 Reports a measurement taken on the original PCB — 1 cores/s16/hdl/jts16_tilemap.v:135 Measured on PCB vint lasts 64us, starts one line before blanking vsync occurs 16 lines later Ships hardware documentation files — 1 cores/outrun/pal/315-5228.txt Notes where it differs from MAME — 1 hdl/jtoutrun_snd.v:86 The schematics have it, MAME doesn't Cites MAME source — 2 hdl/jtoutrun_motor.v:5 dummy motor, follows MAME's implementation cores/s16/hdl/jts16_fd1094_dec.v:146 decoding, pretty much copy-paste from MAME's fd1094.cpp I trust the synthesizer to simplify the equations Shares text with the MAME driver without saying so — 2 hdl/jtoutrun_pcm.v:6 Clock input 16.000MHz on pin 80 — shares text with sega/segaorun.cpp:100 hdl/jtoutrun_pcm.v:7 Clock outputs: pin 2 - 4.000MHz, pin 80 - 500.000kHz, pin 89 - 62.500KHz — shares text with sega/segaorun.cpp:101
jtpaclan# Pac-Land jotego/jtcores @ b672aca5 MAME compared: namco/pacland.cpp Read: 15 HDL files, 1,613 lines (files.yaml)	JTCORES	Both	low	26%
Statements: 2 toward hardware, 3 toward MAME Cites hardware documentation that MAME's driver does not — 1 cores/shouse/hdl/jtcus30.sv:5 Implementation of Namco's CUS30 - 8-channel stereo DAC Based on MAME's namco_snd.cpp information and Atari's schematics Says it was checked against the original PCB — 1 hdl/jtpaclan_main.v:137 verified on PCB Cites MAME source — 2 cores/shouse/hdl/jtcus30.sv:8 The frequency number is the step added to the channel counter each waveform is 32-byte long MAME reports 12kHz as sampling frequency 15 kHz * 8 = 120 kHz 1536 kHz / 120 kHz = 12 cores/shouse/hdl/jtshouse_vtimer.v:27 60.6 Hz according to MAME Says it was translated, ported or taken from MAME — 1 cores/shouse/hdl/jtcus30.sv:5 Implementation of Namco's CUS30 - 8-channel stereo DAC Based on MAME's namco_snd.cpp information and Atari's schematics

Core

Database

MAMEHardware

Reading

Confidence

Coverage

ActFancer#
Act-Fancer Cybernetick Hyper Weapon
MiSTer-devel/Arcade-ActFancer_MISTer @ 267b81a4
MAME compared: dataeast/actfancr.cpp + 4 related file(s)
Read: 31 HDL files, 14,912 lines (Quartus project)

MiSTer official

Mostly MAME

medium

27%

Statements: 1 toward hardware, 53 toward MAME

Cites hardware documentation that MAME's driver does not — 1

rtl/actfancer/jtcop_bac06.v:41 The /NUDS and /NLDS inputs of all chips are gated via a 74LS32 chip by the /DSP chip select signal.

Cites MAME source — 42

ActFancer.sv:316 MAME actfancr.cpp port mapping: P1 bit 0=UP, 1=DOWN, 2=LEFT, 3=RIGHT, 4=BUTTON1, 5=BUTTON2, 7=START1 SYSTEM bit 0=COIN1, 1=COIN2 MiSTer hps_io with jn keywords (pattern BoogieWings/Darius DataEast): D-pad joy[0..3] = R,L,D,U J1 buttons base
rtl/actfancer/actfancer_bac06_wrap.sv:3 ActFancer's H6280 main CPU is 8-bit; MAME accesses BAC06 via pf_data_8bit_swap_w(): A0 selects high/low byte of the 16-bit word.
rtl/actfancer/actfancer_bac06_wrap.sv:6 We translate: cpu_8bit_addr[12:0] → cpu_dout[15:0] / cpu_dsn[1:0] / cpu_addr[12:1] such that for A0=0 → write hi byte, A0=1 → write lo byte (the "swap" variant in MAME swaps endianness vs the plain one).
rtl/actfancer/actfancer_bac06_wrap.sv:65 MAME pf_data_8bit_swap_w (decbac06.cpp:625-660): A0=0 → byte BASSO del word A0=1 → byte ALTO del word (validato in sim/tb_bac06_swap.sv)
rtl/actfancer/actfancer_chars.sv:3 Stessa architettura di actfancer_tiles ma con tile 8x8 + index VRAM da MAME tile_shape0_8x8_scan (cpp:173).
rtl/actfancer/actfancer_chars.sv:92 MAME tile_shape0_8x8_scan: idx = (col & 0x1f) + ((row & 0x1f) << 5) + ((col & 0x60) << 5)
rtl/actfancer/actfancer_main.sv:4 MAME reference: dataeast/actfancr.cpp::actfancr_state::prg_map (lines 154-173)
rtl/actfancer/actfancer_main.sv:132 MAME: 0x110000-0x110001 (buffer_spriteram_w 2 byte).
rtl/actfancer/actfancer_main.sv:162 SYSTEM port MAME (active-low except bit7=VBL active-high): bit 0 = COIN1, bit 1 = COIN2, bit 7 = VBL
rtl/actfancer/actfancer_main.sv:186 PF bus fanout (BAC06 wrapper esterno gestisce 8-bit→16-bit) MAME maps tightly: pf0: 0x060000-0x060007 ctrl0, 0x060010-0x06001F ctrl1, 0x062000-0x063FFF VRAM pf1: 0x070000-0x070007 ctrl0, 0x070010-0x07001F ctrl1, 0x072000-0x0727FF VRAM mod
rtl/actfancer/actfancer_main.sv:194 PF1 VRAM: MAME limita a 2KB (0x072000-0x0727FF) — restringo per evitare aliasing
rtl/actfancer/actfancer_obj_wrap.sv:10 MAME spriteram ActFancer (actfancr.cpp:150 buffer_spriteram_w): m_spriteram16[i] = m_spriteram[i*2] | (m_spriteram[(i*2)+1] << 8); LO byte HI byte Cioè LITTLE-ENDIAN dentro il word16: spriteram byte 2i = LO byte (= cpu A0=0) s
rtl/actfancer/actfancer_obj_wrap.sv:76 little-endian (MAME buffer_spriteram_w): A0=0 -> LO byte -> dsn = 2'b10 (we[0]=1 enable LO) A0=1 -> HI byte -> dsn = 2'b01 (we[1]=1 enable HI)
rtl/actfancer/actfancer_rom_bram32.sv:6 Layout MAME chars 8x8 4bpp = RGN_FRAC(1,4): 4 planes from {0/4, 1/4, 2/4, 3/4} of the region.
rtl/actfancer/actfancer_rom_bram32.sv:7 So: plane 0 = bytes 0x00000..0x07FFF plane 1 = bytes 0x08000..0x0FFFF plane 2 = bytes 0x10000..0x17FFF plane 3 = bytes 0x18000..0x1FFFF (vedi gfx_layout layout_8x8x4 in actfancr.cpp riga 308-317)
rtl/actfancer/actfancer_snd.sv:4 MAME reference: dataeast/actfancr.cpp::dec0_s_map (lines 196-204)
rtl/actfancer/actfancer_snd.sv:149 PIN7_HIGH (MAME)
rtl/actfancer/actfancer_sprites.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Act-Fancer DECO MXC06 sprite engine — 1:1 MAME decmxc06::draw_sprites.
rtl/actfancer/actfancer_sprites.sv:4 Reference: reference/decmxc06.cpp
rtl/actfancer/actfancer_sprites.sv:6 Sprite layout (4 word × 16 bit per sprite, big-endian sprite RAM 2KB = 256 sprite): word0 (byte0,1) = {byte0:[en, yflip, xflip, h[1:0], w[1:0], yh], byte1:[ylo[7:0]]} bit 15 : enable bit 14 : Y flip bit 13 : X flip bit 12:11 : height (1x, 2
rtl/actfancer/actfancer_sprites.sv:23 MAME conversion (cpp:80-85): sx = data2 & 0x01ff; if (sx >= 256) sx -= 512; sx = 240 - sx; sy = data0 & 0x01ff; if (sy >= 256) sy -= 512; sy = 240 - sy;
rtl/actfancer/actfancer_sprites.sv:44 MRA sprites interleave (B0..B3): B0 = region 1/4 B1 = region 3/4 B2 = region 0 B3 = region 2/4 MAME planes = {0, 1/4, 2/4, 3/4} → pen[3]=B2, pen[2]=B0, pen[1]=B3, pen[0]=B1.
rtl/actfancer/actfancer_sprites.sv:128 512 wide per gestire sx negativo (signed wrap MAME).
rtl/actfancer/actfancer_sprites.sv:270 Y: 9-bit (byte0 bit0 = Y[8]) - MAME conversion
rtl/actfancer/actfancer_sprites.sv:314 code per tile row in multi-h sprite: code = (code_base & ~(h-1)) if (parentFlipY) y_offset = -tile_yi else y_offset = (h-1) - tile_yi For multi-width (x_iter > 0): MAME consumes additional spriteram entries.
rtl/actfancer/actfancer_sprites.sv:327 rom_addr = {code_y[11:0], row_in_tile[3:0], half} (code_y truncated to 12 bit per MAME tile region size 1536 ≈ 11 bit) word32-index shiftato di 1 (bridge fa [17:1]<<1, preserva [1:17])
rtl/actfancer/actfancer_tiles.sv:13 VRAM indexing MAME (decbac06.cpp): - shape0 col-major: idx = (row & 0xf) + ((0xFF - col[7:0]) << 4) - shape0 row-major: idx = (col & 0xf) + ((row & 0xf) << 4) + ((col & 0x1f0) << 4) - shape1: idx = (col & 0xf) + ((row & 0x1f) << 4) + ((col
rtl/actfancer/actfancer_tiles.sv:97 scroll x invertito per col-major (MAME cpp:274-278)
rtl/actfancer/actfancer_tiles.sv:124 VRAM index calculation (MAME tile_shape*_scan)
rtl/actfancer/actfancer_tiles.sv:255 hflip from MAME: column-major -> TILE_FLIPX
rtl/actfancer/actfancer_top.sv:396 MAME ROM_REGION 256KB ma file "18" e` solo 64KB (vedi actfancr.cpp:471).
rtl/actfancer/actfancer_video.sv:4 Two tile layers via Jotego's jtcop_bac06 (wrapped for 8-bit CPU bus): PF0 = MASTER (16x16 background), provides H/V timing reference PF1 = SLAVE (8x8 chars overlay) DECO MXC06 sprite engine (bespoke MAME-faithful actfancer_sprites).
rtl/actfancer/actfancer_video.sv:10 Video timing: jtframe_vtimer internal to PF0 (384x272 total @ 6 MHz pixel clock -> 256x240 active @ 57.45 Hz, hardware-accurate to MAME).
rtl/actfancer/actfancer_video.sv:285 Compositing: PF1 (chars) > sprite > PF0 (tiles) Indici palette base (MAME GFXDECODE): chars → 0x000 tiles → 0x100 sprite → 0x200
rtl/actfancer/actfancer_video.sv:347 MAME pf_data_8bit_swap_w (decbac06.cpp:496+641): CPU A0=0 → MAME offset^1 → odd → mask 0x00ff → write LO byte CPU A0=1 → MAME offset^1 → even → mask 0xff00 → write HI byte
rtl/actfancer/jtcop_bac06.v:282 hflip = TILE_FLIPX MAME: ON quando col-major (mode[0] bit1 = 0).
rtl/actfancer/jtcop_bac06.v:292 MAME decbac06.cpp ActFancer m_wide=2: GEOM_4X1 16x16: 256 cols × 16 rows tile_shape0_scan column-major: idx = (row & 0xf) + ((0xFF - col[7:0]) << 4) row-major: idx = (col & 0xf) + ((row & 0xf) << 4) + ((col & 0x1f0) << 4
rtl/actfancer/jtcop_bac06.v:306 In jtcop convention, msbrow_en=0 means "MAME column-major" (TILE_FLIPX implicit).
rtl/actfancer/jtcop_bac06.v:307 In jtcop convention, msbrow_en=1 means "MAME row-major".
rtl/actfancer/jtcop_bac06.v:321 column-major MAME: (row[3:0]) + ((0xFF - col[7:0]) << 4)
rtl/actfancer/jtcop_bac06.v:481 MAME byte plane offset = 16+y (y=0..7) → DDR byte = T*128 + 64 + y*4 → rom_addr (word16-idx) = T*32 + 16 + y
README.md:30 YM2203 OPN + YM3812 OPL2 + OKI M6295 ADPCM, MAME-accurate clocks

Shares text with the MAME driver without saying so — 11

rtl/actfancer/actfancer_chars.sv:92 MAME tile_shape0_8x8_scan: idx = (col & 0x1f) + ((row & 0x1f) << 5) + ((col & 0x60) << 5) — shares text with dataeast/decbac06.cpp:173
rtl/actfancer/actfancer_sprites.sv:24 sx = data2 & 0x01ff; if (sx >= 256) sx -= 512; sx = 240 - sx; — shares text with dataeast/decmxc06.cpp:81
rtl/actfancer/actfancer_sprites.sv:31 if (parentFlipY) incy = -1; else { code += h-1; incy = 1; } — shares text with dataeast/decmxc06.cpp:116
rtl/actfancer/actfancer_tiles.sv:15 - shape0 row-major: idx = (col & 0xf) + ((row & 0xf) << 4) + ((col & 0x1f0) << 4) — shares text with dataeast/decbac06.cpp:145
rtl/actfancer/actfancer_tiles.sv:16 - shape1: idx = (col & 0xf) + ((row & 0x1f) << 4) + ((col & 0xf0) << 5) — shares text with dataeast/decbac06.cpp:159
rtl/actfancer/actfancer_tiles.sv:17 - shape2: idx = (col & 0xf) + ((row & 0x3f) << 4) + ((col & 0x70) << 6) — shares text with dataeast/decbac06.cpp:166
rtl/actfancer/jtcop_bac06.v:295 row-major: idx = (col & 0xf) + ((row & 0xf) << 4) + ((col & 0x1f0) << 4) — shares text with dataeast/decbac06.cpp:145
rtl/actfancer/jtcop_bac06.v:297 tile_shape1_scan: idx = (col & 0xf) + ((row & 0x1f) << 4) + ((col & 0xf0) << 5) — shares text with dataeast/decbac06.cpp:159
rtl/actfancer/jtcop_bac06.v:299 tile_shape2_scan: idx = (col & 0xf) + ((row & 0x3f) << 4) + ((col & 0x70) << 6) — shares text with dataeast/decbac06.cpp:166
rtl/actfancer/jtcop_bac06.v:301 GEOM_4X1: 128×32 → idx = (col & 0x1f) + ((row & 0x1f) << 5) + ((col & 0x60) << 5) — shares text with dataeast/decbac06.cpp:173
rtl/actfancer/jtcop_bac06.v:302 GEOM_2X2: 64×64 → idx = (col & 0x1f) + ((row & 0x1f) << 5) + ((row & 0x20) << 5) + ((col & 0x20) << 6) — shares text with dataeast/decbac06.cpp:172

Aleck64#
Eleven Beat, Hanabi de Doon! - Don-chan Puzzle, Hi Pai Paradise, Hi Pai Paradise 2 …
MiSTer-devel/N64_MiSTer @ 399e6594
MAME compared: nintendo/aleck64.cpp + 11 related file(s)
Read: 84 HDL files, 42,940 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 10 toward MAME

Cites MAME source — 10

N64.sv:628 MAME keyboard controls /////////////////////////
N64.sv:662 MAME's default mahjong panel bindings.
N64.sv:759 MAME buttons 3/4 correspond to the MRA's logical C/D controls at R/C-Right.
N64.sv:780 Aleck64 PIF titles use the N64 analog stick for their MAME directions.
rtl/Aleck64.vhd:9 The E90 renderer below follows the currently documented MAME behaviour: each enabled list entry draws one 8x8, palette-shaded puzzle block over the N64 video output.
README.md:28 | MAME set | Game | Input/hardware status |
README.md:51 The E90 puzzle-piece overlay extends the reference MAME implementation with the tile `0x0400` playfield-background mode.
README.md:56 Magical Tetris's separate 128-byte S2D board memory is initialized from the MAME `at24c01.u34` dump and appended to the same persistent NVRAM file.
README.md:72 Mahjong games use MAME's panel defaults: A-N, left Ctrl for Kan, left Alt for Pon, Space for Chi, left Shift for Reach, and Z for Ron.
README.md:75 Games with physical DIP banks expose their MAME-defined settings through the standard MiSTer **DIP Switches** OSD entry.

Arabian#
Arabian
MiSTer-devel/Arcade-Arabian_MiSTer @ 42fef5ac
MAME compared: sunelectronics/arabian.cpp
Read: 11 HDL files, 2,679 lines (Quartus project)

MiSTer official

Mostly MAME

medium

75%

Statements: 4 toward hardware, 52 toward MAME

Cites hardware documentation that MAME's driver does not — 2

rtl/Arabian_CPU.sv:366 12 MHz master (XTAL, SP-237 sheet 8B), 6 MHz dot clock.
rtl/Arabian_CPU.sv:783 Confirmed against SP-237 sheet 11B: plane B reaches red (BZ/BR via IC118) and green (BG via IC118, BB via IC120) but never blue -- the blue driver TR6 is fed only from the plane-A path.

Ships hardware documentation files — 1

Useful Information/Arabian (1983) - Schematics (1st Printing).pdf

Notes where it differs from MAME — 1

rtl/cpu/mb88_sv/mb88_core.sv:31 NOT MODELLED — NONE are gaps (MAME doesn't model them for the default part, or no target device uses them): * STANDBY (stby_n pin): MAME has no standby/STOP state for mb88.

Cites MAME source — 43

Arcade-Arabian.sv:222 Service inputs — MAME keeps these separate
rtl/Arabian.sv:14 Player inputs (active HIGH, per MAME port definitions)
rtl/Arabian_CPU.sv:5 The video timing, VRAM and blitter blocks are still the kangaroo.cpp implementation by Ville Laitinen and Aaron Giles, pending their port.
rtl/Arabian_CPU.sv:63 Generate clock enables from the 12 MHz master (MAIN_OSC, arabian.cpp) cen_6m = 12/2 = 6 MHz (pixel clock — provisional, see Video Timing)
rtl/Arabian_CPU.sv:82 Holds the Z80 while the blitter owns the bitmap: arabian.cpp blits inside the $E006 write and the board's DMA holds the bus for the same span, so the blit must be atomic.
rtl/Arabian_CPU.sv:189 arabian.cpp blitter_w: $E000-$E006, mirror $0FF8
rtl/Arabian_CPU.sv:214 NMI is not connected on this board (arabian.cpp memory map header).
rtl/Arabian_CPU.sv:220 Wiring mirrors arabian.cpp:
rtl/Arabian_CPU.sv:230 MAME converts pin clocks at (clocks+5)/6, so the 2 MHz pin rate is divided by 6.
rtl/Arabian_CPU.sv:291 --- flip screen --- MAME latches this only when the MCU writes R0.
rtl/Arabian_CPU.sv:313 MAME's read_r returns the output latch; R0 additionally reads bit2 high ("RAM mode enabled")
rtl/Arabian_CPU.sv:344 MAME: standard IM1 interrupt, RST 38h every vblank IRQ fires on vblank rising edge
rtl/Arabian_CPU.sv:462 arabian.cpp blit_area(): a source byte pair (offs, offs+0x4000) carries four pixels; pixel m takes bit m and bit m+4 from each plane byte.
rtl/Arabian_CPU.sv:487 arabian.cpp videoram_w(): the CPU writes four pixels of two bits each, pixel m taking data[m] and data[m+4].
rtl/Arabian_CPU.sv:490 MAME's comments on that function do not match the palette bit order; the code does.
rtl/Arabian_CPU.sv:536 MAME's loop is X outer, Y inner, source advancing per step.
rtl/Arabian_CPU.sv:737 arabian.cpp screen_update is a straight bitmap scanout: the pen IS the pixel byte, with the five AY port-A control bits forming the upper half of a 13-bit colour-table index: pen = ((video_control >> 3) << 8) | pixel_byte There is no scroll
rtl/Arabian_CPU.sv:746 MAME's screen_update does dest_x = 255-x, dest_y = 255-y on a 256x256 bitmap (arabian.cpp:475-484), which is this XOR.
rtl/Arabian_CPU.sv:783 Colour derivation, arabian.cpp palette().
rtl/Arabian_CPU.sv:793 MAME's weights match the sheet-11B network: red 1.2K/1.8K = 1.5 (153/102), green 750R/1.2K = 1.6 (156/99), 510R pull-ups.
rtl/cpu/mb88_sv/mb88.sv:56 Generate it here: one ena_timer pulse per 32 `ena` machine-cycle enables — MAME mb88 burn_cycles /32 (full timer overflow = ÷8192 of `ena`).
rtl/cpu/mb88_sv/mb88_core.sv:6 Oracle: MAME cpu/mb88xx/mb88xx.cpp (opcode-for-opcode).
rtl/cpu/mb88_sv/mb88_core.sv:14 STATUS (2026-07-18): COMPLETE vs MAME mb88xx.cpp — opcode AND non-opcode.
rtl/cpu/mb88_sv/mb88_core.sv:16 OPCODES: all 256 bytes, verified byte-for-byte vs mb88xx.cpp execute_run() (0x00-2f individual; 0x30-3f sbit/rbit/tbit/rti/jpa/en/dis; 0x40-7f setD/ rstD/tstD/tba/xd/xyd/lxi/call/jpl/ai; 0x80-bf lyi/li/cyi/ci; 0xc0-ff jmp).
rtl/cpu/mb88_sv/mb88_core.sv:23 * Timer: internal (pio7, ÷32 prescale) OR external TC pin (pio6) per MAME increment_timer() (2026-07-11 + 2026-07-17 fixes).
rtl/cpu/mb88_sv/mb88_core.sv:29 * O-port PLA: 8-bit cf-nibble-select outO = MAME write_pla with pla_bits==8 (the device default; what the Namco 5xxx use).
rtl/cpu/mb88_sv/mb88_core.sv:34 * External-clock serial (pio 0x10/0x30): MAME fatalerror's it (unsupported).
rtl/cpu/mb88_sv/mb88_core.sv:58 interrupt injection (harness drives from the MAME trace during bug hunt)
rtl/cpu/mb88_sv/mb88_core.sv:88 ---- SERIAL (2026-07-18; faithful to MAME mb88xx.cpp serial_timer()/pio_enable()) ---- 4-bit RECEIVE shift register clocked at clock()/SERIAL_PRESCALE(=6), armed when pio[5:4]==2'b10 (MAME's (m_pio & 0x30)==0x20 = internal serial clock).
rtl/cpu/mb88_sv/mb88_core.sv:92 sf blocks further shifting until tsts clears it; SBcount runaway-disables at THRESH (MAME anti-hang).
rtl/cpu/mb88_sv/mb88_core.sv:93 External-clock serial (pio 0x10/0x30) is unsupported by MAME (fatalerror) so we just don't tick.
rtl/cpu/mb88_sv/mb88_core.sv:94 SO/transmit is not modeled in MAME's mb88 either.
rtl/cpu/mb88_sv/mb88_core.sv:98 MAME SERIAL_DISABLE_THRESH
rtl/cpu/mb88_sv/mb88_core.sv:154 SP[] and ram[] intentionally NOT reset (MAME device_reset doesn't clear data RAM/stack; ROM inits RAM; Verilator zero-inits arrays).
rtl/cpu/mb88_sv/mb88_core.sv:160 MAME mb88xx.cpp: `if (m_ctr && !state && (m_pio & 0x40)) increment_timer(); m_ctr = state;` i.e. on a FALLING edge of the TC pin, if external-counter mode (pio bit6/0x40) is enabled, tick the SAME timer.
rtl/cpu/mb88_sv/mb88_core.sv:163 This drives the 51xx's per-frame timer, which MAME clocks from screen vblank (namco51.cpp vblank() -> MB88XX_TC_LINE).
rtl/cpu/mb88_sv/mb88_core.sv:168 Two mutually-exclusive sources feed the ONE counter (a chip uses internal OR external mode, never both): internal clock (ena_timer & pio7 = MAME 0x80), OR external TC falling edge (pio6 = MAME 0x40).
rtl/cpu/mb88_sv/mb88_core.sv:172 MCU-TIMER-FIX-2026-07-11: pio7 gate (MAME 0x80); TC-TIMER-FIX-2026-07-17: + external TC path (pio6/MAME 0x40)
rtl/cpu/mb88_sv/mb88_core.sv:179 ---- SERIAL receive engine (MAME serial_timer).
rtl/cpu/mb88_sv/mb88_core.sv:188 MAME: SB = (SB>>1) | (si?8:0)
rtl/cpu/mb88_sv/mb88_core.sv:201 MAME executes the instruction first, pushes the POST-instruction PC, then burn_cycles(3).
rtl/cpu/mb88_sv/mb88_core.sv:217 outO: cf=1->oh, cf=0->ol (MAME write_pla 8-bit / VHDL)
rtl/cpu/mb88_sv/mb88_core.sv:324 {PA,PC} here is already the POST-instruction PC = MAME's GETPC().

Says it matches, follows or was checked against MAME — 7

rtl/Arabian_CPU.sv:372 Visible window matches MAME's visarea (0,255, 11,244): 256 across, 234 down.
rtl/cpu/mb88_sv/mb88_core.sv:64 PC of the executing instruction (matches MAME)
rtl/cpu/mb88_sv/mb88_core.sv:105 IRQ-CYCLES-FIX-2026-08-21: interrupt entry costs 3 ce, matching MAME's burn_cycles(3) (mb88xx.cpp:481).
rtl/cpu/mb88_sv/mb88_core.sv:211 executing instruction's own PC (matches MAME)
rtl/cpu/mb88_sv/mb88_core.sv:294 jmp within page (INCPC-then-override, matches MAME)
rtl/cpu/mb88_sv/mb88_core.sv:322 IRQ-CYCLES-FIX-2026-08-21: entry work + 2 idle ce = 3 ce total, so an instruction plus an interrupt costs 4 ce, matching MAME's 1 + 3.
rtl/ram_rom/rom_loader.sv:3 Arabian ROM loader ROM layout matched to MAME arabian.cpp

Says it was translated, ported or taken from MAME — 2

rtl/Arabian.sv:3 Arabian top-level module Copyright (C) 2026 Rodimus Based on MAME arabian.cpp by Dan Boris
rtl/Arabian_CPU.sv:3 Arabian Main CPU Board Based on MAME arabian.cpp by Dan Boris.

Arkanoid#
Arkanoid
MiSTer-devel/Arcade-Arkanoid_MISTer @ bea1771c
MAME compared: taito/arkanoid.cpp + 3 related file(s)
Read: 8 HDL files, 2,222 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

34%

Statements: 2 toward MAME

Cites MAME source — 1

Arcade-Arkanoid.sv:583 DIP switches are in reverse order when compared to this table (sourced from MAME Arkanoid driver):

Shares text with the MAME driver without saying so — 1

Arcade-Arkanoid.sv:583 DIP switches are in reverse order when compared to this table (sourced from MAME Arkanoid driver): +-----------------------------+------------------------------ — shares text with taito/arkanoid.cpp

Asteroids#
Asteroids Deluxe, Asteroids, Lunar Lander
MiSTer-devel/Arcade-Asteroids_MiSTer @ 0f1369fa
MAME compared: atari/asteroid.cpp + 3 related file(s)
Read: 46 HDL files, 22,126 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 3 toward hardware

Cites hardware documentation that MAME's driver does not — 3

rtl/asteroids_audio_board.sv:144 Nominal 555/DAC frequencies from the Asteroids board schematic.
rtl/asteroids_core.sv:7 The address map and RAM arbitration follow the Asteroids main-board schematics.
README.md:13 This core reconstructs all three machines from Atari's schematics and pairs them with a high-resolution vector renderer and CRT-effects pipeline.

Astrocade#
Extra Bases, Gorf, The Adventures of Robby Roto!, Sea Wolf II …
MiSTer-devel/Arcade-Astrocade_MiSTer @ ea231f0f
MAME compared: bally/astrocde.cpp + 2 related file(s)
Read: 40 HDL files, 17,784 lines (Quartus project)

MiSTer official

Mostly MAME

low

Statements: 16 toward MAME

Cites MAME source — 4

rtl/bally_io.vhd:312 2+4, 6 bit up counter as per patent and Mame = 7 bit counter = x3F or max 63
rtl/sc01a/sc01a.vhd:12 Key differences from MAME reference: - All arithmetic in s(2.15) fixed-point (no floating point) - Filter coefficients pre-computed as static ROM tables - IIR filters implemented as sequential state machines - Clock enables (sclock_en, cclo
README.txt:62 Sound uses samples, originally from mame but modified to closer match the hardware
README.txt:76 (as per Mame) analogue should work the same as the real game.

Says it was translated, ported or taken from MAME — 3

rtl/sc01a/sc01a.vhd:9 Based on the Votrax SC01-A simulation from MAME Copyright (c) Olivier Galibert
README.txt:79 SC-01 speech implemented using a fixed-point VHDL port of MAME’s Votrax SC-01 core.
README.txt:90 SC-01 speech implemented using a fixed-point VHDL port of MAME’s Votrax SC-01 core.

Shares text with the MAME driver without saying so — 9

rtl/bally_pattern.vhd:136 address is selected between source/dest based on mode.d0 — shares text with bally/astrocde_v.cpp:769
rtl/bally_pattern.vhd:149 if mode.d3 is set, then the last byte fetched per row is forced to 0 (address = gorf hack for the moment) — shares text with bally/astrocde_v.cpp:772
rtl/bally_pattern.vhd:185 if the flip-flop at U13 is high and mode.d2 is 1 we can increment source — shares text with bally/astrocde_v.cpp:693
rtl/bally_pattern.vhd:186 however, if mode.d3 is set and we're on the last byte of a row, the increment is suppressed — shares text with bally/astrocde_v.cpp:694
rtl/bally_pattern.vhd:193 if mode.d1 is 1, toggle the flip-flop; otherwise leave it preset — shares text with bally/astrocde_v.cpp:698
rtl/bally_pattern.vhd:198 destination increment is suppressed for the last byte in a row — shares text with bally/astrocde_v.cpp:706
rtl/bally_pattern.vhd:200 at the end of each row, the skip value is added to the dest value — shares text with bally/astrocde_v.cpp:801
rtl/bally_pattern.vhd:203 carry behavior into the top byte is controlled by mode.d4 — shares text with bally/astrocde_v.cpp:805
rtl/bally_pattern.vhd:214 if mode.d5 is 1, we increment — shares text with bally/astrocde_v.cpp:709

atarisys1#
Indiana Jones and the Temple of Doom, Marble Madness, Peter Pack Rat, Road Blasters …
MiSTer-devel/Arcade-Atari-system1_MiSTer @ 475e26f7
MAME compared: atari/atarisy1.cpp + 6 related file(s)
Read: 20 HDL files, 6,271 lines (Quartus project)

MiSTer official

Both

medium

89%

Statements: 44 toward hardware, 8 toward MAME, 25 not counted

Cites hardware documentation that MAME's driver does not — 44

Arcade-atarisys1.sv:645 SP-276 SP-277 SP-282 SP-286 SP-298 #########################################
rtl/atarisys1/AUDIO.vhd:160 sheet 5 --
rtl/atarisys1/AUDIO.vhd:287 sheet 6 --
rtl/atarisys1/CART.vhd:13 Indiana Jones and the Temple of Doom cartridge for Atari System 1 From SP-282 schematic (identical to SP-280 just different page order)
rtl/atarisys1/CART.vhd:184 sheet 11 SP-299 INT3 schema --
rtl/atarisys1/CART.vhd:188 counter 4/5F is kept in "hold" mode (pins ENT, ENP grounded) so just (ab)used as a 1 bit latch deviation from schematic, it was determined that INT3 was occuring too early and causing video problems with roadblasters due to V offset being l
rtl/atarisys1/CART.vhd:225 sheet 2 SP-282 -- (sheet 8 SP-280) -- sheet 3 SP-282 -- (sheet 7 SP-280) --
rtl/atarisys1/CART.vhd:243 sheet 4 SP-282 -- (sheet 2 SP-280) --
rtl/atarisys1/CART.vhd:349 schematic variation between games sheet 4 SP-282 vs sheet 12 SP-299
rtl/atarisys1/CART.vhd:353 common address for PROMs 4/5A, 7A on SP-282 or 2D, 1/2D on SP-299
rtl/atarisys1/CART.vhd:386 -- PROM 1/2D , decoder 1D, buffers 2H, 3H, 4H on SP-299 slv_GBA <= I_PD7A & slv_MGRA(11 downto 1);
rtl/atarisys1/CART.vhd:429 else if others default to SP-282
rtl/atarisys1/CART.vhd:431 PROM 4/5A on SP-282
rtl/atarisys1/CART.vhd:443 PROM 7A on SP-282 convert ROM selects back into an address vector
rtl/atarisys1/CART.vhd:486 sheet 5 SP-282 -- (sheet 4 SP-280) --
rtl/atarisys1/CART.vhd:508 sheet 6 SP-282 -- (sheet 5 SP-280) --
rtl/atarisys1/CART.vhd:530 sheet 7 SP-282 -- (sheet 6 SP-280) --
rtl/atarisys1/CART.vhd:551 sheet 8 SP-282 -- (sheet 3 SP-280) --
rtl/atarisys1/GPC.vhd:70 These equations describe the PROM 3E contents, top 2 data bits are the same as bottom 2 data bits as can be seen in PROM dump
rtl/atarisys1/GPC.vhd:98 3H latch
rtl/atarisys1/GPC.vhd:117 1B, 5B latch
rtl/atarisys1/LINECTR.vhd:72 4J, 3D on SP-277 schema sheet 8
rtl/atarisys1/LINECTR.vhd:93 latch 3J
rtl/atarisys1/LS299.vhd:17 simplified 74LS299 shifter as used in SLAGS
rtl/atarisys1/MAIN.vhd:260 sheet 2 --
rtl/atarisys1/MAIN.vhd:451 sheet 3 --
rtl/atarisys1/MAIN.vhd:465 sheet 4 --
rtl/atarisys1/MOHLB_LSI.vhd:13 Motion Object Horizontal Line Buffer based on SP-286 schematic sheet 7
rtl/atarisys1/MOHLB_LSI.vhd:67 sheet 7 --
rtl/atarisys1/PFHS.vhd:67 11E latch
rtl/atarisys1/PFHS.vhd:80 two 74LS189 16x4 bit RAMs, arranged as one 16x8 RAM but only 3 address lines used, so really one 8x8 RAM IMPORTANT: data out is the COMPLEMENT of data in!!!
rtl/atarisys1/SLAGS.vhd:73 In schema SP-276 when /NOROM signals are asserted they cause the shifters to hold their state and also they cause /CPAL signals to pull low the D0/D7 lines of the ROMS (which are not fitted to PCB, hence the /NOROM signal) the final effect
rtl/atarisys1/SYNGEN.vhd:124 From SP-313 this is /HBLANK
rtl/atarisys1/VIDEO.vhd:248 sheet 7 --
rtl/atarisys1/VIDEO.vhd:345 sheet 8 --
rtl/atarisys1/VIDEO.vhd:390 9C latch
rtl/atarisys1/VIDEO.vhd:416 2C latch
rtl/atarisys1/VIDEO.vhd:427 5F latch
rtl/atarisys1/VIDEO.vhd:458 sheet 9 --
rtl/atarisys1/VIDEO.vhd:541 1/2A, 3C latch on SP-299 addr bit 13 is taken from VRD9 but on SP-286 it is connected to ALBNK selector the only games that uses a 16K ALPHA ROM are indytempc and roadblstcg
rtl/atarisys1/VIDEO.vhd:552 2/3B ROM (same as 5F)
rtl/atarisys1/VIDEO.vhd:570 sheet 10 --
rtl/atarisys1/VIDEO.vhd:612 6A, 6B latch color palette output
README.md:5 Based primarily on the SP-280, SP-286 schematics with additional support from SP-277, SP-298

Cites hardware references or measurements that MAME's driver also gives — 25

rtl/atarisys1/AUDIO.vhd:164 Location J16 and J17 implements a halt to 6502 for 8 video frames after a /RST or /IRQ A 74LS164 shit register is configured as: 74LS164 inputs A,B tied High, CLK tied to /VBLANK, /RST tied to output of AND gate with inputs /6502IRQ 6502 pi — also in MAME: 74LS164 atari/atarisy1.cpp:36, 74LS164 atari/atarisy1.cpp:36, 74LS164 atari/atarisy1.cpp:36
rtl/atarisys1/CART.vhd:359 if Roadrunner or Roadblasters use variation SP-298 / SP-299 !!! — also in MAME: SP-298 atari/atarisy1.cpp:1763, SP-299 atari/atarisy1.cpp:1765
rtl/atarisys1/CART.vhd:361 PROM 2D on SP-299 if I_MATCHn = '0' then sl_NOROM7n <= '0'; sl_NOROM6n <= '0'; sl_NOROM5n <= I_PD4A(5); sl_NOROM4n <= I_PD4A(4); sl_NOROM3n <= I_PD4A(7); sl_GD7P7 <= I_PD4A(3); sl_GD7P6 <= I_PD4A(2); sl_GD7P5 <= I_PD4A(1); sl_GD7P4 — also in MAME: 2D atari/atarisy1.cpp:1614, SP-299 atari/atarisy1.cpp:1765
rtl/atarisys1/CART.vhd:389 if Roadrunner or Roadblasters use this variation derived from MAME source code since schema SP-299 doesn't work — also in MAME: SP-299 atari/atarisy1.cpp:1765
rtl/atarisys1/GPC.vhd:13 Graphic Priority Control (Atari custom chip 137419-101) This GPC was derived from System I SP-277 schematic — also in MAME: SP-277 atari/atarisy1.cpp:941
rtl/atarisys1/GPC.vhd:82 9D latch — also in MAME: 9D atari/atarisy1.cpp:1613
rtl/atarisys1/GPC.vhd:107 3F latch — also in MAME: 3F atari/atarisy1.cpp:1599
rtl/atarisys1/MAIN.vhd:11 For full details, see the GNU General Public License at www.gnu.org/licenses Based on SP-286 schematic — also in MAME: SP-286 atari/atarisy1.cpp:942
rtl/atarisys1/MAIN.vhd:518 14E latch sound data out — also in MAME: 14E atari/atarisy1.cpp:1785
rtl/atarisys1/MAIN.vhd:528 15E latch sound data in — also in MAME: 15E atari/atarisy1.cpp:1585
rtl/atarisys1/PFHS.vhd:13 Play Field Horizontal Scroll (Atari custom chip 137419-104) This PFHS was derived from System I SP-277 schematic — also in MAME: SP-277 atari/atarisy1.cpp:941
rtl/atarisys1/PFHS.vhd:93 4D latch — also in MAME: 4D atari/atarisy1.cpp:1612
rtl/atarisys1/SLAGS.vhd:13 Storage/Logic Array Graphics Shifter (Atari custom chip 137415-101) This SLAGS was derived from Marble Madness SP-276 schematic — also in MAME: SP-276 atari/atarisy1.cpp:1000
rtl/atarisys1/SLAGS.vhd:81 latch 8B — also in MAME: 8B atari/atarisy1.cpp:1598
rtl/atarisys1/SLAGS.vhd:92 latch 11A — also in MAME: 11A atari/atarisy1.cpp:1572
rtl/atarisys1/SYNGEN.vhd:13 System Clock and Sync Generator (Atari custom chip 137419-103) This SYNGEN was derived from System I SP-277 schematic — also in MAME: SP-277 atari/atarisy1.cpp:941
rtl/atarisys1/SYNGEN.vhd:152 82S129 256x4 TTL BIPOLAR PROM (Atari chip 136032.102) — also in MAME: 82S129 atari/atarisy1.cpp:807, 136032.102 atari/atarisy1.cpp:969
rtl/atarisys1/SYNGEN.vhd:179 Equations for PLA chip 7F Signetics 82S153 aka PLS153A (Atari custom chip 136032.103) /o19 = /i1 & i2 & i3 & i7 & i8 & i9 o18 = i1 & /i2 o17 = i1 & /i2 & /i3 + /i1 & i2 & /i3 + i1 & /i2 & i3 o16 = /i2 + i1 & i2 & /i3 + /i1 & i2 & i3 — also in MAME: 7F atari/atarisy1.cpp:1605, 82S153 atari/atarisy1.cpp:970, 136032.103 atari/atarisy1.cpp:970
rtl/atarisys1/VIDEO.vhd:11 For full details, see the GNU General Public License at www.gnu.org/licenses From SP-286 schematic — also in MAME: SP-286 atari/atarisy1.cpp:942
rtl/atarisys1/VIDEO.vhd:446 ALBNK is CTF in SP-299 — also in MAME: SP-299 atari/atarisy1.cpp:1765
rtl/atarisys1/VIDEO.vhd:497 as per SP-299 — also in MAME: SP-299 atari/atarisy1.cpp:1765
rtl/atarisys1/VIDEO.vhd:516 as per SP-299 — also in MAME: SP-299 atari/atarisy1.cpp:1765
rtl/atarisys1/VIDEO.vhd:521 as per SP-299 — also in MAME: SP-299 atari/atarisy1.cpp:1765
rtl/atarisys1/VIDEO.vhd:524 latch 4F — also in MAME: 4F atari/atarisy1.cpp:1594
rtl/atarisys1/VIDEO.vhd:550 slv_ROM_2B_addr(13) <= sl_ALBNK_CTF; -- not used because 2/3B ROM is only 8K — also in MAME: 3B atari/atarisy1.cpp:1597, 8K atari/atarisy1.cpp:1782

Cites MAME source — 5

Arcade-atarisys1.sv:304 Default MAME Controls Assignment
rtl/atarisys1/AUDIO.vhd:162 Atari System 1 TTL motherboard PCB factory modification according to atarisy1.cpp from MAME Location A2 simply fixes a PCB layout pin swap issue with /COMPSYNC to match the schematic.
rtl/atarisys1/CART.vhd:389 if Roadrunner or Roadblasters use this variation derived from MAME source code since schema SP-299 doesn't work
rtl/atarisys1/TMS5220.vhd:13 References: TMS5220 datasheet, US Patent US4335277 and TMS5220.cpp from MAME source code.
README.md:7 System-1 supported game cartridges according to MAME

Says it was translated, ported or taken from MAME — 2

rtl/atarisys1/SLAPSTIC.vhd:13 SLAPSTIC 137412-104 GAUNTLET This SLAPSTIC was translated from MAME "slapstic.cpp" source code pretty much verbatim :) The original MAME C++ code is left in as comments
rtl/atarisys1/TMS5220.vhd:15 IMPORTANT NOTES: 1) This implementation does NOT implement the schematic in US4335277 2) It is based primarily on MAME source code and aims to be "functionally equivalent" to the "TMS5220" chip but not identical in terms of electrical circu

Shares text with the MAME driver without saying so — 1

rtl/atarisys1/SYNGEN.vhd:16 H 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 — shares text with atari/atarisy1_v.cpp:50

atarisys2#
720 Degrees, APB - All Points Bulletin, Championship Sprint, Paperboy …
MiSTer-devel/Arcade-AtariSystem2_MiSTer @ 7ad07997
MAME compared: atari/atarisy2.cpp + 6 related file(s)
Read: 34 HDL files, 9,303 lines (Quartus project)

MiSTer official

Mostly MAME

high

82%

Statements: 35 toward hardware, 106 toward MAME

Cites hardware documentation that MAME's driver does not — 28

atarisys2.sv:124 paperboy TM-275 Table 1-3 (unchanged, and its labels predate this work) 720 TM-294 Table 1-3 + Figure 3-22, the game's own game options screen ssprint TM-290 Table 3-2 + Figure 3-20, the game's own switch settings screen TM-290 kee
atarisys2.sv:1012 Loaded into the sound-bus eeprom[] so the game has valid coinage -- otherwise it powers up blank and "INSERT COIN" never credits (the coin input path itself is correct; verified vs SP-275 sheet 9A).
atarisys2.sv:1436 SP-275 sheet 9A has it as the third/aux coin-door input; MAME called it IPT_COIN3 until commit 76f3936 reclassified it as IPT_SERVICE1, which is what the cabinet actually wires there.
atarisys2.sv:1453 Physical option DIP switches (SP-275 sheet 9B, TM-275 tables 1-2/1-3), exposed in the OSD "Game Options" page and fed to the two POKEYs' pot lines (ALLPOT).
atarisys2.sv:1659 SP-308 is the authority, and it is unambiguous: sheet 1B "Control Panel" S5A/S5B = FIRE (J24 pin 7, orange) S3A/S3B = SIREN (J24 pin 8, yellow) sheet 6A "Control Panel Inputs" SW5 -> LS244 5P in 11 -> out 9 = DAL1 (IN0 bit 1) SW3 -> LS
atarisys2.sv:2028 LEVELS (schematic-derived rebalance): SP-275 sheet 9B "Audio Output Drivers" sums each chip into the TDA2002 through its own input resistor -- YM (YAM) R141/R144=47K, POKEY (PAUD) R139/R142=47K, TMS (TIAUD) R140/R143=68K -- so the board's i
atarisys2.sv:2044 TMS5220 speech (tms_snd, signed 14-bit) is mono on real hardware (a single "TIAUD" net feeding the shared resistor mixer, sheet 9A) -- summed into BOTH channels equally.
atarisys2.sv:2050 Two consequences: (1) The TMS `<<2` becomes the *unity* (loudest) speech level; the game runs speech at TMS bits 5-7 = 000 (gain 0.5, verified in MAME: 0x187a only ever = 0x1f/0x1e), so typical speech now plays at <<2 * 0.5 = <<1 -- i.e. 6
atarisys2.sv:2063 Base per-chip terms (schematic-derived, see LEVELS above): YM at 1/2 FS and POKEY <<9 (~1/2 FS) => ~1:1 (SP-275 sheet 9B equal 47K sums); TMS <<2 (mono -> summed into both channels equally; real speech is well under its 8191 FS, so <<2 is a
atarisys2.sv:2066 Schematic-accurate chain (derived from SP-275 sheets 9A/9B).
atarisys2.sv:2075 Analog audio chain -- SP-275 sheets 9A/9B.
atarisys2.sv:2148 See the SP-308 note above.
rtl/adc/adc0809.sv:19 The conversion time is settled: the default 64 clocks on the exact 625 kHz enable = 102.4 us sits inside the data-sheet 90-116 us window, and the handlebar, calibration and TM-275 control diagnostics all behave correctly on hardware at this
rtl/main/sys2_analog_map.sv:40 SP-290 sheet 8B shows the pedal pot going into the ADC0809 through a 100 R series resistor with NO divider, i.e. the converter sees the full rail.
rtl/main/sys2_main_bus.sv:616 See SP-275 sheet 6B.
rtl/mem/sys2_sdram.sv:293 Measured on the fitted netlist, that slot was open at BOTH ends of the PVT range: the data reaches this flop at 35.003..42.192 ns while the 31.250 edge reaches it at 39.217..40.679 -- the unwanted edge sits INSIDE the arrival window, so whi
rtl/sys2_video_timing.sv:5 Sources: SP-275 sheet 11A and MAME atarisy2.cpp commit d066f16.
rtl/video/sys2_mob_decode.sv:8 The field masks are the MAME `atari_motion_objects_config` s_mob_config for atarisy2 (atarisy2_v.cpp @ d066f16), cross-checked against the schematics.
rtl/video/sys2_mob_walker.sv:11 This follows the SCHEMATIC, not MAME.
rtl/video/sys2_mob_walker.sv:43 This is the real hardware budget, not MAME's. The linked-list address advances on a strobe generated once every 16 of the 640 horizontal clocks and the pointer resets to the head each line, so the board visits exactly 640/16 = 40 entries pe
rtl/video/sys2_mob_walker.sv:239 The 82S131 at 5P (confirmed from schematic sheet 12A) takes only MOPIC[2:0] as input and its three outputs supply MO graphics ROM address [8:6]; the higher MOPIC bits bypass the PROM entirely into the ROM address latches.
rtl/video/sys2_palette.sv:7 Each channel is (colormap[nibble] * intensity[I]) >> 4, using the resistor/intensity ladders from schematic sheets SP16A-SP17A (integer reference values from MAME's atarisy2_v.cpp).
rtl/video/sys2_priority.sv:6 Paperboy per-pixel layer priority (SP-275 sheet 15B; confirmed against MAME's atarisy2_v.cpp).
rtl/video/sys2_priority.sv:11 The hardware rule (SP-275 sheet 15B): 1.
rtl/video/sys2_video_render.sv:26 Scroll value fields per SP-275 sheet 15A: X = xscroll[15:6] (pixels, 0-1023) + bank0 = xscroll[3:0], effective on the following scanline after the CPU write.
rtl/video/sys2_video_render.sv:344 Final per-pixel priority (SP-275 sheet 15B): the motion object competes with the playfield using the carried category, then the alpha layer is placed on top.
README.md:171 **Native raster.** 640 × 416 total, 512 × 384 visible, 16 MHz pixel clock, ~60.096 Hz, with the blanking, sync, 32V and VBLANK edges transcribed off SP-275 shee
README.md:175 **Analog audio chain.** The board filters **per chip, not on the sum** — SP-275 sheets 9A/9B give each of the YM, POKEY and TMS paths its own preamp pole, inter

Says it was checked on “real hardware” — 6

atarisys2.sv:1617 positive Y is DOWN on the pad -- confirmed on hardware
rtl/clocks/sys2_clocks.sv:32 T-11 headroom caveat: pinning the T-11 to EXACTLY 10 MHz drops it below the prior +6.7 % (10.67 MHz) rate, which had "masked a new-objects-arrive- late symptom." That symptom (graphic pop-in of houses/objects) was later root-caused to the s
rtl/main/sys2_analog_map.sv:26 This block used to be a two-part VERIFY; both parts were answered by research and the whole path was then confirmed on hardware.
rtl/main/sys2_analog_map.sv:43 Confirmed on hardware via APB's Pedal Test, which prints lo/hi/range/raw/ normalized rather than the Sprints' bare lo/value/hi: raw moves 00 -> 3F and normalized 00 -> FF as the pedal travels.
rtl/main/sys2_main_bus.sv:598 Left in the mailbox, a stale byte becomes data-byte-1 of the next readout (cmd 0x0B high-score table) and shifts the whole 180-byte transfer by one -> the T-11's terminator check reads a data byte ('E'=0x45) instead of 0x55 -> $01C0=04 -> $
rtl/mem/sys2_sprite_byte_fifo.sv:45 DEPTH=16 / margin 4 is silicon-validated: on hardware the full inverted sum of the original 256 KiB sprite image matched, so the FIFO delivered every byte to the writer with no overflow.

Notes where it differs from MAME — 1

atarisys2.sv:1784 Rate conversion (deflection -> turn rate) lives in sys2_analog_spin; see its header for why a springing thumbstick cannot map one-to-one onto a continuous-rotation encoder, and for the deliberate divergence from MAME's angle mapping on 720.

Cites MAME source — 86

atarisys2.sv:112 MAME only fills in csprint's 0x80 bit and leaves bits 5:0 inheriting Paperboy's Lives/Bonus Life -- impossible for a racing game.
atarisys2.sv:120 MAME uses generic `DEF_STR` stand-ins where a game has no matching enum -- 720's "Bonus Life" is really first bonus ticket at and its "Difficulty" is timer for STREET; APB's "Max Continues" is Add-A-Coin Control.
atarisys2.sv:135 ssprint has NO switch-1 option; csprint's Auto High Score Reset is the one place the two Sprints genuinely differ, and MAME has that right.
atarisys2.sv:138 However, refer to the Report Options screen in self-test to be sure" -- the manual hedges, so MAME's "Attract Lights" is kept rather than dropping the option.
atarisys2.sv:140 APB's Add-A-Coin maximum reads "Unlimited" on the manual's top setting; MAME calls it 199, which is presumably the internal counter cap.
atarisys2.sv:491 The raster is the same 512x384 as every other game; it is the MONITOR that is turned, which is why MAME renders APB 384x512 and why its self-test screen only matches ours after a rotation.
atarisys2.sv:493 **The direction is measured, not assumed: rotated CCW our frame is 0 px against MAME's, rotated CW it is 2432 px.**
atarisys2.sv:544 CCW, measured against MAME rather than guessed (see above).
atarisys2.sv:1247 The board's tile ROM decodes only as many address lines as it has, so an over-range code wraps -- MAME writes that as `rawcode % gfx->elements()`.
atarisys2.sv:1251 elements = HALF/16, i.e. MAME's tiles region / 32.
atarisys2.sv:1392 joystick_0[4]=Throw R [5]=Throw L [6]=Coin [7]=Service Credit (J1 order in CONF_STR; the release MRA <buttons> MUST list them in the SAME order -- an MRA name list overrides the OSD labels, and a mismatch silently drives the wrong core b
atarisys2.sv:1436 SP-275 sheet 9A has it as the third/aux coin-door input; MAME called it IPT_COIN3 until commit 76f3936 reclassified it as IPT_SERVICE1, which is what the cabinet actually wires there.
atarisys2.sv:1479 MAME's ioport `defvalue` is NOT a transcription of those arrows -- it says 00 for paperboy DSW0 and 0x55 for 720 DSW1, and BOTH disagree with the manuals.
atarisys2.sv:1480 Do not re-derive this from MAME.
atarisys2.sv:1508 DSW1 is NOT game-independent -- see PB_DIP_MENU for the sourcing and the csprint deviation from MAME.
atarisys2.sv:1659 SP-308 is the authority, and it is unambiguous: sheet 1B "Control Panel" S5A/S5B = FIRE (J24 pin 7, orange) S3A/S3B = SIREN (J24 pin 8, yellow) sheet 6A "Control Panel Inputs" SW5 -> LS244 5P in 11 -> out 9 = DAL1 (IN0 bit 1) SW3 -> LS
atarisys2.sv:1667 Neither MAME nor the TM can tell you this.
atarisys2.sv:1737 Rather than writing spinner deltas into the counter -- which is what MAME does, and which would bypass the 156 kHz sample rate, the 2x decode and the resolution bit -- each channel gets a `sys2_quad_gen` that emits REAL quadrature edges for
atarisys2.sv:1743 Channel map, from each game's MAME PORT_MODIFY("LETAn"):
atarisys2.sv:1757 What is OPEN is the DISTRIBUTION of those four counts, NOT a phase offset: MAME emits all four within +/-3 of the top, we emit one every 36.
atarisys2.sv:2048 sys2_sound_bus decodes 0x187a into three Q0.8 gains (mix_gain_ym/pk/tms, 256 = unity) via the MAME atarisy2 mixer_w resistor model; each chip's base term below is scaled by its gain.
rtl/adc/adc0809.sv:18 Source: National ADC0808/ADC0809 data sheet (8 clocks/bit, 64-clock nominal conversion at f_CLK); MAME d066f16 adc0808_device functional model.
rtl/main/sys2_analog_map.sv:14 Channel assignment, from each game's MAME PORT_MODIFY("ADCn"):
rtl/main/sys2_analog_map.sv:31 MAME declares the Sprint/APB pedals `PORT_MINMAX(0x00,0x3f) ...
rtl/main/sys2_analog_map.sv:35 PORT_INVERT IS a bitwise `~` of the accumulated value -- `src/emu/ioport.h` comments it "positional control bits are active low" and `ioport.cpp` applies a plain `value = ~value`.
rtl/main/sys2_analog_map.sv:54 TM-290 Fig 3-9 prints a REAL Super Sprint cabinet's Pedal Test: rest ~0x67, pressed ~0x96 -- mid-scale, ~0x2F of travel, and INCREASING with press, i.e. opposite in direction and offset to the MAME-derived 0xff -> 0xc0 here.
rtl/main/sys2_main_bus.sv:105 IN0 is not the only such port -- MAME's ssprint also does PORT_MODIFY("IN1"), which ROTATES the coin bits (paperboy 0x20/0x40/0x80 = COIN3/COIN1/COIN2; ssprint = COIN1/COIN2/COIN3).
rtl/main/sys2_main_bus.sv:149 MAME 0.288 bankselect_w, exactly: bank = bitswap(page ^ 3, 5,4,1,0,3,2) -- the XOR comes FIRST, then the low bit-pairs swap.
rtl/main/sys2_main_bus.sv:160 ssprint's region mirrors only pairwise (2=4, 3=5, ...), and bank^0xC crosses the pair: without the XOR its map-source read (bankselect 0x1000, MAME bank 13, region 0x2A000 = track data) served region 0x12000 = a sea of 0x0F0F -- which the d
rtl/main/sys2_main_bus.sv:395 Derived from MAME 0.288 atarisy2.cpp INPUT_PORTS_START(paperboy) plus each game's PORT_MODIFY("IN0"):
rtl/main/sys2_main_bus.sv:533 Per MAME d066f16 and the SP6A transcription, each latch samples its own enable bit at the set event; delivery to the T-11 is ungated, so clearing an enable bit never clears an already-pending latch.
rtl/main/sys2_main_bus.sv:578 ssprint's boot checks fast: it found nothing, touched sound_reset (0x15A0 -- the failure branch MAME's IO-read trace never takes), and never started attract.
rtl/rom/sys2_char_rom.sv:35 16 KiB: Paperboy populates only the first 8 KiB (512 chars) and the rest is 0xff fill, but 720/ssprint/csprint/apb all ship 0x4000 and MAME masks the alpha code to 10 bits (`code = data & 0x3ff`) for every game in the driver.
rtl/rom/sys2_maincpu_rom.sv:9 The MAME maincpu region is a sparse 0x90000-byte logical image populated only in 0x8000-byte windows selected by the 0x8000-granular index addr[19:15] -- Paperboy uses {1, 2, 6, 10, 14}, the family union is {1, 2, 3, 6, 10, 11, 14, 15}.
rtl/rom/sys2_maincpu_rom.sv:121 MAME's ASSEMBLED region replicates each banked ROM across the region (ROM_RELOAD): paperboy's units mirror 4-way (2=3=4=5, 6=7=8=9, 10=11=12=13, 14=15=16=17), the Sprints' pairwise (2=4, 3=5, 10=12, 11=13, 14=16, 15=17).
rtl/rom/sys2_rom_loader.sv:6 The MiSTer MRA emits the six MAME logical regions as one ordered index-0 byte stream (see rtl/rom/sys2_rom_layout.vh); index 1 carries the four-byte game descriptor.
rtl/rom/sys2_sprite_rom_arb.sv:16 The MO parameter field is 14 bits ((word0&7)<<11 | (word1&0x7ff)) but NO region here can be indexed by 14 -- masking to 11 or 13 is MAME's `tile_data::set()` wrap (rawcode % gfx->elements()), the same rule the playfield already follows.
rtl/rom/sys2_sprite_rom_arb.sv:159 MAME's code % elements, expressed as the mask it actually is.
rtl/slapstic/sys2_slapstic.sv:20 Reference cores are weighed rather than trusted, and that is a second copy of MAME rather than independent evidence: the type-105 column is the one with hardware behind it, and simulation proves this module reproduces the proven 105 impleme
rtl/slapstic/sys2_slapstic.sv:23 The other four columns rest on MAME alone.
rtl/slapstic/sys2_slapstic.sv:129 On System 2 the slapstic is configured at 0x8000-0x81FF -- MAME gives all five games `set_range(m_maincpu, AS_PROGRAM, 0100000, 0100777, 0)`, octal.
rtl/slapstic/sys2_slapstic.sv:138 For chips 103-110 -- which is all five of ours -- `active_103_110` builds alt1 with test_any, and MAME says why in its own section header: "Active state, 103-110, has direct, alt and bitwise, and alt can be done ANYWHERE".
rtl/slapstic/sys2_slapstic.sv:144 Verified exhaustively over all 65536 addresses for all five types: this pairing reproduces MAME's matcher set exactly, matcher for matcher.
rtl/slapstic/sys2_slapstic.sv:148 Reading MAME's `checker::test_in` and generalising it to every matcher is the natural mistake, but the call sites are four lines of C++ that say `test_any` in plain sight, under a comment that states the rule in English.
rtl/slapstic/sys2_slapstic.sv:154 MAME's `checker::test_any`: the matcher's own mask and value ONLY, with no window folded in, so it fires anywhere in the 64K space.
rtl/sys2_video_timing.sv:5 Sources: SP-275 sheet 11A and MAME atarisy2.cpp commit d066f16.
rtl/t11/t11_core.sv:5 Behavioral sources: DEC DCT11-AA User's Guide and MAME t11 at d066f16.
rtl/video/sys2_mob_decode.sv:8 The field masks are the MAME `atari_motion_objects_config` s_mob_config for atarisy2 (atarisy2_v.cpp @ d066f16), cross-checked against the schematics.
rtl/video/sys2_mob_vscan.sv:8 This is the subtle, MAME-derived coordinate math, locked into a tested module so the sprite layer cannot repeat the playfield colour bug's "shapes fine, placement wrong" class of error.
rtl/video/sys2_mob_vscan.sv:12 From MAME atarimo.cpp render_object (atarisy2: m_xoffset=m_xscroll=m_yscroll=0, no vflip, no width; motion objects are screen-absolute): ypos = -Y_field; ypos -= height << 4; // height in 16px tiles ypos &= 0x1ff; // bi
rtl/video/sys2_mob_walker.sv:6 Paperboy motion-object linked-list walker (MAME atarimo.cpp build_active_list / render_object @ d066f16).
rtl/video/sys2_mob_walker.sv:15 MAME does two things the PCB does not: it sets maxperline = 0 (effectively unlimited) and it keeps a visited[] bitmap and stops the moment a link repeats.
rtl/video/sys2_mob_walker.sv:17 Consequences of the real behaviour: a terminal self-linked object is re-processed until the 40 slots expire (harmless when it re-renders identical pixels), and a short CYCLIC list of overlapping visible objects can end with a different fina
rtl/video/sys2_mob_walker.sv:24 Objects are composited in walk order with later writes overwriting earlier opaque pixels -- MAME draws the active list front-to-back into one bitmap, so the last list entry covering a pixel wins.
rtl/video/sys2_mob_walker.sv:28 render_object coordinate order (verbatim from MAME, atarisy2 xoffset/scroll/ nextneighbor all 0): xpos = X_field; (next_xpos hold inert); if neighbor xpos = last_xpos + 16; last_xpos = xpos (pre-fold); then xpos &= 0x3ff and if xpos >= 512
rtl/video/sys2_mob_walker.sv:32 last_xpos is an 11-bit register here (MAME uses an unbounded int); they differ only for a neighbour chain whose raw xpos exceeds 2047, which does not occur in Paperboy.
rtl/video/sys2_mob_walker.sv:55 MAME uses maxperline = 0 (unlimited) and we previously followed it at 256, so this is a DELIBERATE divergence from our own oracle.
rtl/video/sys2_mob_walker.sv:56 Override to 256 to reproduce MAME when comparing against MAME rather than against the board.
rtl/video/sys2_mob_walker.sv:136 rawx is 11-bit; the neighbor add wraps mod 2048 (the documented finite-width deviation from MAME's unbounded int, immaterial for Paperboy's lists).
rtl/video/sys2_mob_walker.sv:230 last_xpos updates for every object (MAME: unconditional, pre-fold).
rtl/video/sys2_mob_walker.sv:244 MAME increments the combined integer code and DOES carry, so this is a deliberate divergence from our own oracle -- and one no MAME-comparison can detect, because MAME shares the error.
rtl/video/sys2_palette.sv:7 Each channel is (colormap[nibble] * intensity[I]) >> 4, using the resistor/intensity ladders from schematic sheets SP16A-SP17A (integer reference values from MAME's atarisy2_v.cpp).
rtl/video/sys2_palette.sv:44 Colour steps -- the one palette value still resting on MAME rather than the schematic.
rtl/video/sys2_palette.sv:46 MAME's `color_table` is a bare hand-written array with no derivation comment, unlike its `intensity_table` which is built from named conductances (round 4 proved those ARE the branch conductances normalised to 256).
rtl/video/sys2_palette.sv:53 We ship MAME's table anyway, deliberately.
rtl/video/sys2_palette.sv:53 MAME is the only oracle we can actually validate against -- the frame comparison is pixel-exact against it on three scenes -- so swapping in a table validated by nothing would break that comparison and trade a known-good approximation for a
rtl/video/sys2_palette.sv:61 Expect the MAME frame comparison to fail when it is defined -- that is correct and expected, because that check measures agreement with MAME, which is exactly what this option changes.
rtl/video/sys2_palette.sv:63 Default (undefined) = MAME: 0,3,4,5,6,7,8,9,10,11,12,13,14,14,15,15 PALETTE_SPICE_COLORMAP 0,6,7,7,8,9,9,10,10,11,12,12,13,14,14,15
rtl/video/sys2_pen4.sv:6 Shared 4-pixel 4bpp pen kernel for the Atari System II planar packing (MAME RGN_FRAC(1,2): planeoffset { 0, 4, RGN_FRAC(1,2)+0, RGN_FRAC(1,2)+4 }, MSB-first within each byte).
rtl/video/sys2_pf_linebuf.sv:251 The real board's tile ROM only decodes as many address lines as it has, so an over-range code wraps; MAME reproduces that as `rawcode % gfx->elements()`.
rtl/video/sys2_priority.sv:6 Paperboy per-pixel layer priority (SP-275 sheet 15B; confirmed against MAME's atarisy2_v.cpp).
rtl/video/sys2_priority.sv:17 This is exactly MAME's `!((mopri + pfpri) & 2) || !(pf & 8)`.
rtl/video/sys2_video_render.sv:15 Tile word: code[9:0], bank-select[10], colour group[13:11], category[15:14] inverted (MAME (~data>>14)&3, fed to the priority mixer).
rtl/video/sys2_video_render.sv:18 4bpp pen via the MAME pflayout planar packing: the first ROM half (rom_lo) holds pen bits 3,2 and the second half (rom_hi) pen bits 1,0, MSB-first within each nibble.
rtl/video/sys2_video_render.sv:149 MAME's yscroll_w updates m_playfield_tile_bank[1] OUTSIDE its `if (!(newscroll & 0x10))` conditional (src/mame/atari/atarisy2_v.cpp) -- bit 4 schedules the scroll load, the bank takes effect on the write in both modes, followed by mark_all_
rtl/video/sys2_video_render.sv:162 bank0/xscroll is NOT the same case and is deliberately left alone: it is applied at the next line_start, and MAME's segment granularity (update_partial on scroll writes) makes that the same scanline boundary.
rtl/video/sys2_video_render.sv:263 MAME: code = (bank[(data>>10)&1] << 10) | (data & 0x3ff), with a FOUR-bit bank (xscroll&0x0f / yscroll&0x0f) -- 14 bits, up to 16384 tiles for APB.
rtl/video/sys2_video_render.sv:272 Dropping them is exactly `code % 4096`, and 4096 is Paperboy's decoded tile-element count, so this reproduces MAME's own wrap: tile_data::set() does `rawcode % gfx->elements()` before the fetch.
rtl/video/sys2_video_render.sv:292 4bpp playfield pen via the shared sys2_pen4 kernel (MAME `pflayout` planar packing: FIRST region half rom_lo = pf_rom_data[7:0] -> pen bits 3,2; SECOND half rom_hi = pf_rom_data[15:8] -> pen bits 1,0).
rtl/video/sys2_video_render.sv:417 MAME (~data >> 14) & 3
README.md:24 All 29 remaining MAME clone sets — other revisions and the German, French and Spanish releases — ship under `releases/_alternatives/`.
README.md:27 `Paperboy (prototype)` is `MACHINE_NOT_WORKING` in MAME with every ROM a `BAD_DUMP`.
README.md:189 MAME differs on all three, and following MAME instead breaks Championship Sprint and 720.
README.md:190 720's "MO Height Test" produces a ragged staircase 44 pixels taller than MAME's — that staircase is what the hardware draws.
README.md:302 **The MAME team** — `atarisy2.cpp` and `atarisy2_v.cpp` were the functional cross-reference for everything the schematics do not settle.
README.md:303 References in the RTL comments of the form `mame/atarisy2.cpp` point at MAME's own sources.

Says it matches, follows or was checked against MAME — 14

atarisys2.sv:109 sw7 is the HIGH bit of each pair and sw8 the low one (verified: MAME's ssprint values reproduce TM-292's switch table exactly under that mapping).
atarisys2.sv:118 Every field below was checked against its operator manual; every encoding MAME had was correct, and what the manuals changed was the NAMES.
atarisys2.sv:1655 The bus's bit numbers were always right -- sys2_main_bus puts btn2 on IN0 bit1 and btn3 on bit3, matching MAME's 0x02/0x08 -- but the joystick bits feeding them were inverted, so the button the MRA labels "Siren" sounded nothing and fired i
atarisys2.sv:2050 Two consequences: (1) The TMS `<<2` becomes the *unity* (loudest) speech level; the game runs speech at TMS bits 5-7 = 000 (gain 0.5, verified in MAME: 0x187a only ever = 0x1f/0x1e), so typical speech now plays at <<2 * 0.5 = <<1 -- i.e. 6
rtl/main/sys2_analog_map.sv:49 All four hops were traced: this module emits `PEDAL_RELEASED - travel` (0xFF idle / 0xC0 floored, matching MAME) -> `adc_in` -> `adc0809` straight capture -> {8'hff, data}.
rtl/main/sys2_main_bus.sv:119 Playfield scroll/bank registers, the raw 16-bit values latched on the CPU write (matching MAME's shared m_xscroll/m_yscroll).
rtl/main/sys2_main_bus.sv:164 Verified against MAME bank writes: 0x1000->13, 0xE000->62, 0xF000->63 (bankoffset[] table in atarisy2.cpp agrees).
rtl/main/sys2_main_bus.sv:586 The command is the low byte, so only a low-byte write strobes the latch and its pending flag (matching MAME's even-byte soundlatch handler).
rtl/slapstic/sys2_slapstic.sv:127 Two matchers, because MAME has two, and the difference is not an oversight.
rtl/slapstic/sys2_slapstic.sv:130 But it taps the WHOLE address space and decides per matcher whether the window applies (MAME slapstic.cpp):
rtl/slapstic/sys2_slapstic.sv:155 Used by exactly one matcher -- alt1 -- and only because MAME uses it there for chips 103-110.
rtl/video/sys2_pen4.sv:16 The four pens are spelled out with constant bit-selects (the verified form from the MAME reference) -- pure combinational.
rtl/video/sys2_video_render.sv:409 10 code bits, matching MAME's `code = data & 0x3ff` for every System 2 game.
README.md:201 The video path is pixel-exact against MAME frame captures on four of the five games, and service-mode video RAM is byte-identical to MAME on every game that kee

Says it was translated, ported or taken from MAME — 2

rtl/main/sys2_main_bus.sv:406 That is MAME's mapping verbatim, not an omission here -- APB's remaining controls are the LETA wheel and the ADC pedal, which do not pass through this word.
rtl/slapstic/sys2_slapstic.sv:18 Transcribed from the tables in the Arcade-Atari-system1 core's `SLAPSTIC.vhd`, which carries MAME's `slapstic_data` structs verbatim as comments.

Shares text with the MAME driver without saying so — 4

rtl/video/sys2_palette.sv:21 Intensity ladder: ZB=115, Z3=78, Z2=37, Z1=17, Z0=9. — shares text with atari/atarisy2_v.cpp:160
rtl/video/sys2_pen4.sv:7 (MAME RGN_FRAC(1,2): planeoffset { 0, 4, RGN_FRAC(1,2)+0, RGN_FRAC(1,2)+4 }, — shares text with atari/atarisy2.cpp:1144
rtl/video/sys2_pf_linebuf.sv:89 code = (bank[(data>>10)&1] << 10) | (data & 0x3ff) — shares text with atari/atarisy2_v.cpp:31
rtl/video/sys2_video_render.sv:263 MAME: code = (bank[(data>>10)&1] << 10) | (data & 0x3ff), with a FOUR-bit bank — shares text with atari/atarisy2_v.cpp:31

AtariTetris#
Tetris (Atari)
MiSTer-devel/Arcade-ATetris_MiSTer @ adde7f86
MAME compared: atari/atetris.cpp + 2 related file(s)
Read: 20 HDL files, 5,715 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 2 toward hardware

Cites hardware documentation that MAME's driver does not — 2

rtl/Pokey/pokey_poly_17_9.vhdl:53 next state (as pokey decap)
rtl/Pokey/pokey_poly_17_9.vhdl:74 from pokey schematics

Athena#
Athena, Country Club, Lee Trevino's Fighting Golf
MiSTer-devel/Arcade-Athena_MiSTer @ c475eba6
MAME compared: snk/snk.cpp + 2 related file(s)
Read: 82 HDL files, 9,729 lines (Quartus project)

MiSTer official

Both

low

29%

Statements: 13 toward hardware, 4 toward MAME

Cites hardware documentation that MAME's driver does not — 13

rtl/clocks/A5001_1.v:1 Author: @RndMnkIII Date: 13/03/2022 Converted from ArmoredScrumObject_pal16r6a_3.jed using MAME's jedutil tool Many thanks to pldarchive.co.uk for the JED file.
rtl/clocks/A6001_1.v:1 Athena A6001-1 PAL16R6 Author: @RndMnkIII Date: 03/06/2022 Converted from SNK_A6001-1_PAL16R6.jed using MAME's jedutil tool Many thanks to @Porchy and pldarchive.co.uk for the JED files.
rtl/clocks/TNKIIICore_Clocks_Sync.sv:203 74LS30 8-input positive NAND gate
rtl/final_video/A5001_3.v:1 A5001_3.v Author: @RndMnkIII Date: 23/05/2022 Derived from TNKIII schematics and ASO PAL.
rtl/front/TNKIIICore_LineBuffer_sync.sv:120 74LS20 4-input NAND gate
rtl/ttl/ttl_74107a_AsyncClr.v:1 74LS107A: Dual J-/K flip-flop with clear; negative-edge-triggered Inputs Outputs
rtl/ttl/ttl_74107a_sync.v:1 74LS107A: Dual J-/K flip-flop with clear; negative-edge-triggered Inputs Outputs
rtl/ttl/ttl_74163a_sync.v:1 4-bit modulo 16 binary counter with parallel load, *** FOR SYNTHESIS *** Synchronous Reset (SRn) -> LS163A <START_TEMPLATE> ttl_74161a #(.DELAY_RISE(20), .DELAY_FALL(25)) <NAME> (.Clear_bar(), .Load_bar(), .ENT(), .ENP(), .D(), .Clk(), .RCO
rtl/ttl/ttl_74373.sv:1 ttl_74373.sv Octal D transparent latch function table, logic diagrams and switching characteristics extracted from TI 74LS373 Datasheet.
rtl/ttl/ttl_74374_sync.sv:1 ttl_74374_sync.sv Octal D edge triggered FF function table, logic diagrams and switching characteristics extracted from TI 74LS374 Datasheet.
rtl/ym3526/jtopl_exprom.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.
rtl/ym3526/jtopl_logsin.v:16 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.
rtl/ym3526/jtopl_op.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.

Cites MAME source — 2

rtl/clocks/A5001_1.v:1 Author: @RndMnkIII Date: 13/03/2022 Converted from ArmoredScrumObject_pal16r6a_3.jed using MAME's jedutil tool Many thanks to pldarchive.co.uk for the JED file.
rtl/cpuA_B/AthenaCore_CPU_A_B_sync.sv:582 ONLY WRITABLE VIDEO RELATED REGISTERS (TNKIII) 1 1 1 1 1 | 1 | Address: 5 4 3 2 1 | 0 9 8 | 7 6 5 4 3 2 1 0 16'hC800 1 1 0 0 1 | 0 0 0 | x x x x x x x x MSB 16'hC900 1 1 0 0 1 | 0 0 1 | x x x x x x x x FSX 16'hCA00

Says it was translated, ported or taken from MAME — 1

rtl/clocks/A6001_1.v:1 Athena A6001-1 PAL16R6 Author: @RndMnkIII Date: 03/06/2022 Converted from SNK_A6001-1_PAL16R6.jed using MAME's jedutil tool Many thanks to @Porchy and pldarchive.co.uk for the JED files.

Shares text with the MAME driver without saying so — 1

rtl/cpuA_B/AthenaCore_CPU_A_B_sync.sv:227 void snk_state::countryc_trackball_w(uint8_t data) — shares text with snk/snk.cpp:1196

Badlands#
Bad Lands
MiSTer-devel/Arcade-Badlands_MiSTer @ f1589516
MAME compared: atari/badlands.cpp + 4 related file(s)
Read: 33 HDL files, 7,410 lines (Quartus project)

MiSTer official

Both

medium

78%

Statements: 113 toward hardware, 46 toward MAME, 35 not counted

Cites hardware documentation that MAME's driver does not — 109

rtl/badlands_core.sv:11 badlands_main sheets 1 and 2 plus the whole memory path: fx68k 22E, the GAL 26C / LS138 24C decode, the 28R LS163A wait sequencer, the 8 K x 8 22V video/work RAM and its GAL 21R slot schedule, the 22J VBLANK latch and 13J IPL encoder, the
rtl/badlands_core.sv:38 ce_14m = clk_sys / 4 = 14.318181 MHz 14M: CRAM byte rate, GAL 21R clock ce_7m = clk_sys / 8 = 7.159091 MHz 7M: pixel, H counter, 68000 ce_1h = clk_sys / 16 = 3.579545 MHz 1H: YM2151 phiM, LETA CK ce_2h = clk_sys / 32 = 1.78
rtl/badlands_core.sv:80 The 2816A's self-timed byte write, in clk_sys cycles: the data-sheet 10 ms at 57.272724 MHz.
rtl/badlands_core.sv:335 GAL 9N pin 12: /MISC2 and R/W come from the main board, AUDFULL from the 15J flag on sheet 5, and the D8 pair goes back into badlands_main's read mux.
rtl/badlands_core.sv:350 SOUND — sheet 5 (there is no separate audio PCB)
rtl/main/badlands_addr_decode.sv:3 Bad Lands address decode -- the GAL 26C (136074-1001), the LS138 24C it enables, and the program-ROM chip/output enables, from schematic sheet 2.
rtl/main/badlands_addr_decode.sv:11 ---- GAL 26C, a GAL16V8 in 16L8 mode, all outputs combinatorial ---------- pins 1..8 = /AS, R/W, A13, A14, A15, A16, A17, A23 pins 9, 11 = BS0, BS1 from the empty SLAPSTIC socket 28C: in no product term, so there is no SLAPSTIC to implem
rtl/main/badlands_addr_decode.sv:40 ---- LS138 24C ---------------------------------------------------------- G1 (6) = +5 V, /G2A (4) = GND, /G2B (5) = /MISC, C,B,A (3,2,1) = A15,A14,A13
rtl/main/badlands_addr_decode.sv:84 ---- LS138 24C outputs, active low -----------------------------------
rtl/main/badlands_addr_decode.sv:128 ---------------- LS138 24C ------------------------------------------- /G2A = GND, G1 = +5 V, /G2B = /MISC ; C,B,A = A15,A14,A13
rtl/main/badlands_cpu.sv:3 Bad Lands main CPU -- fx68k (cycle-exact 68000) wired as schematic sheet 2 draws the 22E MC68000.
rtl/main/badlands_cpu.sv:13 ---- the clock phase, and why it matters -------------------------------- The SOS-2's 7M pin drives one load: 23R 74F74 half 2's D input, clocked by 14M rising.
rtl/main/badlands_cpu.sv:17 7M -> GAL 26R CLK, GAL 21R input, GAL 9N, LB ACLK, the H counter /7M -> 68000 22E CLK (pin 15), 28R LS163A CLK (pin 2), 7N, 10K
rtl/main/badlands_cpu.sv:20 The CPU and the /DTACK sequencer run on /7M while GAL 26R and the video side run on 7M; that half-cycle stagger is deliberate.
rtl/main/badlands_cpu.sv:35 badlands_dtack takes the same (pcnt == 4) tick, which is what sheet 2 wires to its LS163A.
rtl/main/badlands_cpu.sv:38 ---- pins as sheet 2 wires them -----------------------------------------
rtl/main/badlands_cpu.sv:55 The same net drives the 28R LS163A's ENT, so an IACK gets no /DTACK and can only end through the CPU's own VPA path -- badlands_dtack's business, not this module's. Here we just publish `fc` and take `vpa_n`.
rtl/main/badlands_cpu.sv:97 the /7M rising tick, so badlands_dtack's LS163A can use the very same edge sheet 2 wires to its pin 2
rtl/main/badlands_cpu.sv:137 double bus fault; no load on sheet 2
rtl/main/badlands_dtack.sv:3 Bad Lands /DTACK -- the 28R 74LS163A wait-state sequencer of schematic sheet 2, plus the 19J LS08 that ORs in the video RAM's /RTIME.
rtl/main/badlands_dtack.sv:7 Structure ported from `Arcade-Blasteroids_MiSTer/rtl/main/blstroid_dtack.sv` (GPL-3.0, same author, a 12C LS163A doing the same job).
rtl/main/badlands_dtack.sv:11 ---- the part, as sheet 2 wires it -------------------------------------- 6,5,4,3 D,C,B,A = /RAM , /AUDRESD , /EEROM , /AUDRESD
rtl/main/badlands_dtack.sv:20 19J LS08: pin 2 = /RTIME (GAL 21R pin 14), pin 1 = /RCO, pin 3 = /DTACK => /DTACK = /RTIME AND /RCO, i.e. asserted when RCO = 1 or /RTIME = 0.
rtl/main/badlands_dtack.sv:65 GAL 21R pin 14 -> 19J LS08 pin 2
rtl/main/badlands_dtack.sv:75 On the LS163A the ripple carry is RCO = QA.QB.QC.QD.ENT, so /VPA kills RCO as well as the count.
rtl/main/badlands_eeprom_2816.sv:3 Xicor 2816A (2 K x 8) EEPROM at 27J plus the 22J F74 unlock flop and the 19J LS08 that gates its /OE -- schematic sheet 2.
rtl/main/badlands_eeprom_2816.sv:14 ---- wiring ------------------------------------------------------------- 19,22,23,1 A10..A7 = 68000 A11, A10, A9, A8 2-8 A6..A0 = 68000 A7, A6, A5, A4, A3, A2, A1 17..9 D7..D0 = the 68000's D7:0 -- the odd / low byte lane
rtl/main/badlands_eeprom_2816.sv:27 ---- the unlock / lock protocol ----------------------------------------- 22J F74 half 1: D(2) = GND CLK(3) = /WRL (rising = the end of any 68000 write) /PRE(4)= /UNLOCK (a write to 0xFEE001, LS138 24C Y7) /CLR(1)= /RES Q(5) -> 1
rtl/main/badlands_inputs.sv:3 Bad Lands inputs -- /SWITCHES (18C LS244), the LETA 20C, the two steering quadrature generators and the LM556 pedal timers of schematic sheet 1.
rtl/main/badlands_inputs.sv:65 ============ pedals ==================================================== One LM556 at 26A, both halves used.
rtl/main/badlands_inputs.sv:171 badlands_pedal_556 -- one half of the LM556 at 26A plus its two RC networks.
rtl/main/badlands_irq.sv:3 Bad Lands interrupts -- the 22J 74F74 VBLANK latch and the 13J 74F00 that encodes /IPL0, from schematic sheet 2.
rtl/main/badlands_irq.sv:44 LS138 24C Y1, level, active low (write 0xFE2001)
rtl/main/badlands_irq.sv:45 15J sheet 5, active low -> /IPL1 directly
rtl/main/badlands_irq.sv:51 ---------------- 22J 74F74 half 2 ----------------------------------- Set by the rising edge of VBLANK, cleared while /VIRQACK is low.
rtl/main/badlands_irq.sv:53 /CLR dominates the clock on a 74F74, so the clear is tested first.
rtl/main/badlands_irq.sv:64 ---------------- 13J 74F00 pin 8 and the two direct nets -------------
rtl/main/badlands_main.sv:28 Several reads drive only part of it: /MISC2 read -- GAL 9N drives D8 only /SWITCHES -- 18C LS244 drives D7:0 only /LETA -- the LETA drives D7:0 only /AUDRD -- 13F LS374 drives D15:8 only /CRAM -- 8F LS245 drives D15:
rtl/main/badlands_main.sv:44 A23 = 0 there, so /RAM, /EEROM and /AUDRESD are all inactive and the 28R LS163A loads V = 15, where RCO asserts /DTACK at once: zero wait states, the cycle completes, the 68000 does not hang and the watchdog is not invoked.
rtl/main/badlands_main.sv:99 GAL 9N pin 12 sits in the video block on the real board (sheet 4), so the D8 = AUDFULL read at 0xFC0000 comes in here rather than being formed locally; `misc2_n` and `cpu_rw` go out to that same GAL.
rtl/main/badlands_main.sv:198 /MISC only enables the LS138 24C, whose eight Y outputs are the strobes this module actually uses; a13s/a14s are the empty SLAPSTIC socket's pass-throughs and are already folded into `rom_a`, and rom_oe_lo/hi pick which 27512 pair answers,
rtl/main/badlands_main.sv:298 the 28R LS163A wait sequencer
rtl/main/badlands_watchdog.sv:3 Bad Lands power-on reset and watchdog -- the Q1 2N5306 / R30 / C33 POR node and the 28A 74LS197 of schematic sheet 1.
rtl/main/badlands_watchdog.sv:21 ---- 28A 74LS197 -------------------------------------------------------- D (11) = +5 V ; C (3) = B (10) = A (4) = GND => the preset is 8 CLK1 (8) = VBLANK ; CLK2 (6) = QA (5) (the two stages cascade) /CLR (13) = the POR node
rtl/main/badlands_watchdog.sv:55 It does not reach the SOS-2, the LETA, the PF bank flop 18S, the MO/priority flops 15V/18R, the PIXCLK flop 14E, the sound IRQ latch 14E or either mailbox flag in 15J; the sound section is reset only by /AUDRES.
rtl/main/badlands_watchdog.sv:74 LS138 24C Y0, level, active low (write 0xFE0001)
rtl/main/badlands_watchdog.sv:111 ---------------- 28A 74LS197 ---------------------------------------- Counts on the falling edge of CLK1 = VBLANK, i.e. at the start of vertical blank.
rtl/mem/badlands_prog_rom.sv:21 SLAPSTIC socket 28C is empty and GAL 26C passes A13/A14 straight through (`o18 = i3`, `o19 = i4`), so 0x008000-0x00FFFF is plain ROM with nothing to bank.
rtl/mem/badlands_vram.sv:3 Bad Lands video / work RAM -- the one 8 K x 8 SRAM at 22V, its four address multiplexers, GAL 21R (136074-1002), the 1H byte-lane scheme and the 19N / 22K / 28N / 28L / 22N data path.
rtl/mem/badlands_vram.sv:13 ---- the part ------------------------------------------------------------ One 8 K x 8 100 ns SRAM (137535-004) at 22V.
rtl/mem/badlands_vram.sv:60 ---- the sampling phase, which is forced --------------------------------- 23R (which makes 7M) and GAL 21R are both clocked by 14M rising, so the GAL samples 7M, 1H, 2H, 4H pre-edge.
rtl/mem/badlands_vram.sv:83 /RAMWP = 17J F32 OR( GAL 21R pin 15 , MODCLK ) -> 22V /WE and MODCLK (= 7M delayed a quarter period, 50 % duty) is low over pcnt 2..5, so /RAMWP is one clean ~70 ns pulse inside each H count.
rtl/mem/badlands_vram.sv:240 26T 74F153 -> A12, A6
rtl/mem/badlands_vram.sv:247 28T 74F153 -> A8, A7
rtl/mem/badlands_vram.sv:254 23T 74F157 (SEL = 2H, /E = 4H) -> A11, A10, A9, A1
rtl/mem/badlands_vram.sv:259 21T 74F157 (SEL = /UTIME, /E = GND) -> A5, A4, A3, A2
rtl/mem/badlands_vram.sv:322 28N is a 74F373 transparent latch, not a register: LE = /2H, so D7:0 follows the RAM bus for the whole of h = 0 and h = 1 and only closes at the start of h = 2.
rtl/video/badlands_cram.sv:3 Bad Lands — the colour-RAM port: the 2 K x 8 SRAM at 8K, the 10K F374 address latch, the 8J A0 mux, the 19K/8F CPU path, the 3K byte-0 holding register, the 1K/5K HC273 output registers and the 14E/4J PIXCLK gate.
rtl/video/badlands_cram.sv:6 Schematic sheet 4 grids 8K, 10K, 19K, 8F, 8J, 3K, 1K, 5K, 14E, 4J.
rtl/video/badlands_cram.sv:23 10K latches at 7M falling; then 7M = 0 gives A0 = 0 (byte 0 = colour word D15:8, held by 3K at the next 7M rising edge) and 7M = 1 gives A0 = 1 (byte 1 = D7:0, taken by 5K directly).
rtl/video/badlands_cram.sv:33 That is the only blanking mechanism on the board; sheet 6 has no /BLANK input.
rtl/video/badlands_cram.sv:94 10K 74F374 — the video address latch (CK = /7M rising = 7M falling)
rtl/video/badlands_dac.sv:5 Schematic sheet 6.
rtl/video/badlands_dac.sv:50 the raw gun codes, for anyone reproducing sheet 6
rtl/video/badlands_hstrobes.sv:3 Bad Lands — GAL 26R (136074-2000) at 26R, the horizontal strobe generator, plus the 13J F00 inverter that makes `8HD6H` and the 13V LS175 `/HSYNC` delay network (R98/R99/R100).
rtl/video/badlands_hstrobes.sv:43 The /HSYNC delay: 13V 74LS175 is clocked by PVCLK rising (once per 16 counts, at the n = 5 -> 6 boundary).
rtl/video/badlands_hstrobes.sv:79 ---- GAL 26R pins (all registered on 7M rising) ----------------------
rtl/video/badlands_hstrobes.sv:214 13J 74F00 pins 1 = /8HD6H, 2 = +5 V, 3 = 8HD6H (a NAND as an inverter).
rtl/video/badlands_hstrobes.sv:229 13V 74LS175 — the /HSYNC delay line, clocked by PVCLK rising
rtl/video/badlands_hstrobes.sv:232 A 74LS175 clocked by PVCLK therefore captures the value /HSYNCDO held during that n = 5 count, i.e. `hsyncdo_n` before this cycle's update.
rtl/video/badlands_lb.sv:3 Bad Lands — the motion-object LINE BUFFER, Fujitsu MB87316 at 15N.
rtl/video/badlands_lb.sv:4 Schematic sheet 4 grid 15N.
rtl/video/badlands_lb.sv:11 WE1/WE0 = /MOW1 //MOW0 DIE1/DIE0 = /MOD1 //MOD0 MOR1/MOL1 = /MOR1 //MOL1 MOR0/MOL0 = /MOR0 //MOL0 DI7:DI4 = 17K /Q = NOT {RAMD3,RAMD2,RAMD1,RAMD0} = /priority, /palette DI3:DI0 = /MO3:0 (7T/7R high nibble) DOE = /MO (the tri-state
rtl/video/badlands_lb.sv:55 in which GAL 9N evaluates the priority (during the 7M = 0 half of count k) and 10K latches the winner's index (at the next 7M falling edge).
rtl/video/badlands_lb_ctrl.sv:3 Bad Lands — GAL 16S (136074-1003) at 16S, plus the two 16P F00 gates that turn its o14/o15 into /MOW0 and /MOW1.
rtl/video/badlands_lb_ctrl.sv:4 Schematic sheet 4 grid 16S / 16P.
rtl/video/badlands_lb_ctrl.sv:64 ---- GAL 16S / 16P outputs -------------------------------------------
rtl/video/badlands_mo.sv:3 Bad Lands — the MOTION-OBJECT engine: VMATCH 17U, the 13V/15V chip selects and the three stamp ROMs, 17K's palette/priority latch, 18S/2's VMD flop, 24J's pen-zero test, GAL 16S + 16P, and the MB87316 line buffer at 15N.
rtl/video/badlands_mo.sv:6 Schematic sheet 4.
rtl/video/badlands_mo.sv:39 8H, 8HD6H and H mod 16 do not divide 456, so the group beginning at H = 448 is only 8 counts long, and: * /8H produces no rising edge between H = 448 and H = 16, so 17K (palette + priority) and 18S/2 (VMD) hold entry 27's values across the
rtl/video/badlands_mo.sv:72 1V -> RSEL and GAL 16S pin 9
rtl/video/badlands_mo.sv:178 GAL 16S + 16P F00
rtl/video/badlands_mo.sv:198 The MB87316 line buffer at 15N
rtl/video/badlands_mo_fetch.sv:5 Schematic sheet 4 grids 13V, 15V, 14R/10R/14T.
rtl/video/badlands_pf.sv:5 Schematic sheet 3.
rtl/video/badlands_pf.sv:29 The pipeline, inside a group of eight counts c: the PF word is complete on RAMD15:0 at 8c+3, where 9V/7V latch it (4H rising) and PFA17/16 and A15:A5 settle; ROM byte 0 ({/4H,2H} = 00) is read over 8c+4 and 8c+5; at 8c+5 11V latches the pal
rtl/video/badlands_pf.sv:45 18S 74F74 half 1 has /PRE and /CLR both tied to +5 V, so the bank bit's power-on value is indeterminate; `BANK_POR` parameterises it and 0 matches MAME.
rtl/video/badlands_pf.sv:59 Only the low three H and V bits reach sheet 3: the stamp arrives through the VRAM word, the row is {4V,2V,1V} and the byte index is {/4H,2H}.
rtl/video/badlands_pf.sv:87 18S 74F74 half 1 — the playfield bank bit
rtl/video/badlands_pf.sv:110 Only the ROM-address and chip-select fields are needed here; the palette (D15:13) is taken from the 9V latch by 11V two counts later.
rtl/video/badlands_prio.sv:3 Bad Lands — GAL 9N (136074-1004) at 9N and the 18R F74 half 2 that registers its decision.
rtl/video/badlands_prio.sv:4 Schematic sheet 4 grids 9N, 18R.
rtl/video/badlands_prio.sv:109 ---- 18R 74F74 half 2: D = pin 19, CK = 14M rising, no reset ---------
rtl/video/badlands_sos2_sync.sv:3 Bad Lands — the SOS-2 sync generator (Atari 137550-001 at 25M, schematic 047194-01 sheet 1 grid 25M).
rtl/video/badlands_sos2_sync.sv:12 The SOS-2's own HBLANK (pin 21) and /HSYNC (pin 23) outputs are unconnected on this board: horizontal blanking and sync are regenerated in GAL 26R (136074-2000) and the sync is delayed through 13V, so they live in badlands_hstrobes.sv, and
rtl/video/badlands_sos2_sync.sv:19 ---- horizontal --------------------------------------------------------- H_TOTAL = 456 counts of 7M follows from GAL 26R alone: its /FIRSTH product-term set {453,454,455,0,1,2,3,4} is contiguous only if 455 wraps to 0.
rtl/video/badlands_sos2_sync.sv:49 Two independent facts fix this: GAL 26R is clocked by 7M rising and its registered /FIRSTH, /BLANK and /8HD6H sets are the solved sums shifted late by exactly one 7M period, which only holds if the SOS-2's H counter also advances on 7M risi
rtl/video/badlands_sos2_sync.sv:58 Everything downstream — GAL 26R's registers, GAL 21R, 18R's two decisions per pixel, 7N/10K on /7M, 3K on 7M, PIXCLK = NOR(14E./Q, 7M) — is written against this convention.
rtl/video/badlands_sos2_sync.sv:269 /VRES — the frame reset the SOS-2 shares with the VMATCH custom at 17U, low over the last line of the frame.
rtl/video/badlands_video.sv:19 count k 7T/7R present /PF3:0 and /MO3:0 for count k; the LB presents DO for count k from ph 4 ph 4..7 of k GAL 9N evaluates the rule (7M = 0) on those pens ph 0..3 of k+1 18R publishes the winner; 7N (latched at ph 4 of k) or the L
rtl/video/badlands_video.sv:42 It clears 1K/5K, which is the only blanking mechanism — sheet 6 has no /BLANK input of its own.
rtl/video/badlands_video.sv:164 GAL 26R (26R) + the 13J inverter + the 13V /HSYNC delay
rtl/video/badlands_video.sv:185 The playfield (sheet 3)
rtl/video/badlands_video.sv:207 The motion objects (sheet 4)
rtl/video/badlands_video.sv:242 The shared /CRAMA7:1 bus and GAL 9N (sheet 4)
rtl/video/badlands_vmatch.sv:4 Schematic sheet 4 grid 17U.
README.md:155 | GALs | All six GAL16V8s — address decode, video-RAM timing, line-buffer control, priority, sound decode, horizontal strobes — implemented **verbatim** from th
README.md:182 The six GALs were decoded with MAME's `jedutil` and their equations are implemented verbatim.
README.md:337 Thanks to the MAME team, whose `badlands.cpp`, `badlands_v.cpp` and `atarimo.cpp` served as the functional oracle throughout — and whose PCB notes record the re

Cites hardware references or measurements that MAME's driver also gives — 35

rtl/badlands_core.sv:216 GAL 9N pin 12: the D8 = AUDFULL read at 0xFC0000 lives in the VIDEO block on the real board — also in MAME: 9N atari/badlands.cpp:505
rtl/main/badlands_addr_decode.sv:7 Structure ported from `Arcade-Blasteroids_MiSTer/rtl/main/blstroid_addr_decode.sv` (GPL-3.0, same author); the equations are out of the 136074-1001 fuse map. — also in MAME: 136074-1001 atari/badlands.cpp:152
rtl/main/badlands_addr_decode.sv:31 /RAM has no /AS qualifier, so it can be asserted while the bus is idle; GAL 21R takes /AS separately on its pin 3, so do not AND the two here. — also in MAME: 21R atari/badlands.cpp:503
rtl/main/badlands_addr_decode.sv:75 ---- GAL 26C outputs, active low exactly as the pins are named ------- — also in MAME: 26C atari/badlands.cpp:502
rtl/main/badlands_addr_decode.sv:109 ---------------- GAL 26C (136074-1001) ------------------------------- Written as the active-low pin: pin = ~(sum of products). — also in MAME: 26C atari/badlands.cpp:502, 136074-1001 atari/badlands.cpp:152
rtl/main/badlands_main.sv:289 /RAM arrives with no /AS term, exactly as GAL 26C emits it — also in MAME: 26C atari/badlands.cpp:502
rtl/main/badlands_main.sv:490 Nothing in GAL 26C or the LS138 looks at the lanes, which is why the qualification has to be here: the program loads the palette as pairs of byte writes, an even byte carrying the colour and an odd byte carrying a constant the board throws — also in MAME: 26C atari/badlands.cpp:502
rtl/main/badlands_main.sv:536 D8 comes from GAL 9N pin 12, which is in the video block; its own enable term is /MISC2 & R/W, i.e. exactly this branch's condition. — also in MAME: 9N atari/badlands.cpp:505
rtl/mem/badlands_prog_rom.sv:12 20F 136074-1008 /OE = A17 D15:8 0x000000-0x01FFFF even bytes — also in MAME: 20F atari/badlands.cpp:114, 136074-1008 atari/badlands.cpp:137
rtl/mem/badlands_prog_rom.sv:13 27F 136074-1006 /OE = A17 D7:0 0x000000-0x01FFFF odd bytes — also in MAME: 27F atari/badlands.cpp:116, 136074-1006 atari/badlands.cpp:139
rtl/mem/badlands_prog_rom.sv:14 17F 136074-1009 /OE = /A17 D15:8 0x020000-0x03FFFF even 24F 136074-1007 /OE = /A17 D7:0 0x020000-0x03FFFF odd /CE = A23 on all four; ROM address = {A16,A15,A14S,A13S,A12..A1}. — also in MAME: 17F atari/badlands.cpp:113, 136074-1009 atari/badlands.cpp:136, 24F atari/badlands.cpp:115, 136074-1007 atari/badlands.cpp:138
rtl/mem/badlands_sdram_loader.sv:12 Bad Lands' MO stamps come from three ordinary 27512s at 14R / 10R / 14T selected by {MOA17,MOA16}, so the socket index is just the top two bits of a flat byte address and one stamp row is eight consecutive bytes. — also in MAME: 14R atari/badlands.cpp:109, 10R atari/badlands.cpp:108, 14T atari/badlands.cpp:109
rtl/mem/badlands_vram.sv:32 ---- GAL 21R (136074-1002), verbatim ------------------------------------- GAL16V8 registered. — also in MAME: 21R atari/badlands.cpp:503, 136074-1002 atari/badlands.cpp:156
rtl/mem/badlands_vram.sv:177 ------------------------------------------------ GAL 21R, registered — also in MAME: 21R atari/badlands.cpp:503
rtl/mem/badlands_vram.sv:216 ------------------------------------------ GAL 21R, combinatorial pins — also in MAME: 21R atari/badlands.cpp:503
rtl/video/badlands_cram.sv:71 GAL 9N pin 17 — also in MAME: 9N atari/badlands.cpp:505
rtl/video/badlands_hstrobes.sv:75 ---- GAL 26R inputs (pins 2-9, 12, 19) ------------------------------- — also in MAME: 26R atari/badlands.cpp:507
rtl/video/badlands_hstrobes.sv:102 GAL 26R — the equations verbatim in net names. — also in MAME: 26R atari/badlands.cpp:507
rtl/video/badlands_lb_ctrl.sv:55 ---- GAL 16S inputs --------------------------------------------------- — also in MAME: 16S atari/badlands.cpp:504
rtl/video/badlands_mo.sv:73 GAL 26R pin 17 — also in MAME: 26R atari/badlands.cpp:507
rtl/video/badlands_mo.sv:74 GAL 26R pin 18 (wired to 16S, unused) — also in MAME: 26R atari/badlands.cpp:507, 16S atari/badlands.cpp:504
rtl/video/badlands_mo.sv:78 ---- GAL 26R strobes used as clocks ---------------------------------- — also in MAME: 26R atari/badlands.cpp:507
rtl/video/badlands_mo.sv:96 DO7:0 -> /CRAMA7:1 and GAL 9N — also in MAME: 9N atari/badlands.cpp:505
rtl/video/badlands_pf.sv:41 A playfield pen of 0 is a normal opaque colour on this board — GAL 9N tests /PF3 only, so the playfield has no transparency. — also in MAME: 9N atari/badlands.cpp:505
rtl/video/badlands_prio.sv:64 ---- GAL 9N inputs ---------------------------------------------------- — also in MAME: 9N atari/badlands.cpp:505
rtl/video/badlands_sos2_sync.sv:39 * VBLANK (pin 22) is an active-high output, taken raw to /SWITCHES D6, the watchdog clock, GAL 26R pin 12 and the sound IRQ. — also in MAME: 26R atari/badlands.cpp:507
rtl/video/badlands_sos2_sync.sv:145 GAL 26R pin 12, watchdog CLK) — also in MAME: 26R atari/badlands.cpp:507
rtl/video/badlands_video.sv:3 Bad Lands — the whole raster-time video block: sheets 1 (SOS-2, GAL 26R), 3 (playfield), 4 (motion objects, priority, colour RAM) and 6 (the DACs and composite sync). — also in MAME: 26R atari/badlands.cpp:507
rtl/video/badlands_video.sv:13 DO7 does not reach the bus: it is the stored priority bit and goes only to GAL 9N pin 11. — also in MAME: 9N atari/badlands.cpp:505
rtl/video/badlands_video.sv:41 The board has one blanking net, /BLANK (GAL 26R pin 13), and it already contains VBLANK. — also in MAME: 26R atari/badlands.cpp:507
rtl/video/badlands_video.sv:43 MiSTer's `arcade_video` wants separate hblank and vblank, so this module exports GAL 26R's own sum with the VBLANK term removed as `hblank`, and the SOS-2's VBLANK as `vblank`. — also in MAME: 26R atari/badlands.cpp:507
rtl/video/badlands_video.sv:90 ---- GAL 9N pin 12: AUDFULL on D8 at 0xFC0000 ------------------------ — also in MAME: 9N atari/badlands.cpp:505
rtl/video/badlands_video.sv:299 The DACs settle at PIXCLK (ph 4) and the blanking / sync nets are per-count values out of GAL 26R, so one common ce_7m register keeps them aligned to the count and hands `arcade_video` a clean one-pixel-per-ce_pix stream. — also in MAME: 26R atari/badlands.cpp:507
README.md:149 | Priority | GAL16V8 9N (`136074-1004`), from the dumped fuse map | — also in MAME: 9N atari/badlands.cpp:505, 136074-1004 atari/badlands.cpp:154
README.md:270 Two of the six GAL dumps have no second read.** `136074-1004` (priority, 9N) and `136074-2000` (horizontal strobes, 26R) have a single dump each; the other four — also in MAME: 136074-1004 atari/badlands.cpp:154, 9N atari/badlands.cpp:505, 136074-2000 atari/badlands.cpp:157, 26R atari/badlands.cpp:507

Notes where it differs from MAME — 4

README.md:11 Where a schematic and MAME disagree, the schematic wins and the disagreement is recorded — see [Where this core differs from MAME](#where-this-core-differs-from
README.md:219 Where this core differs from MAME
README.md:222 It is where the A047193-01 schematics document something MAME's model does not.
README.md:250 **The pedal model and the self-test bit** are cases where MAME's model is not a model of this circuit.

Cites MAME source — 40

Arcade-Badlands.sv:13 Bad Lands runs on a horizontal monitor (MAME ROT0), so there is no rotation.
rtl/main/badlands_eeprom_2816.sv:58 ---- programming time --------------------------------------------------- The 2816A data sheet gives a self-timed byte write of typically 5 ms and at most 10 ms, with the I/O pins high-Z throughout; MAME models no write time at all.
rtl/main/badlands_inputs.sv:85 PEDAL_IDLE_SILENT stops the idle oscillator so the LETA reads a flat 0x00, as MAME's does, for simulation only.
rtl/main/badlands_inputs.sv:95 Why a generator and not "add the delta into the counter", which is what MAME does: making real edges keeps the 3.58 MHz sample rate, the decode factor and the direction logic in the path, so a player who spins faster than /1H can sample los
rtl/main/badlands_inputs.sv:327 Simulation only: 1 stops the idle oscillator so the LETA reads the flat 0x00 MAME's does.
rtl/main/badlands_main.sv:38 `UNDRIVEN_DATA = 0xFFFF` is the default because that is what MAME returns; `UNDRIVEN_LAST_VALUE = 1` models the board instead.
rtl/main/badlands_watchdog.sv:61 MAME uses a generic WATCHDOG_TIMER with library-default seconds-scale timing, about 20x too long; this module is the schematic's.
rtl/mem/badlands_rom_loader.sv:13 stream base size MAME region destination
rtl/video/badlands_cram.sv:43 Touching colour RAM during active display therefore shows on screen; MAME has no equivalent artefact.
rtl/video/badlands_dac.sv:11 MAME uses `palette_device::IRGB_1555`, in which colour-word bit 15 adds an LSB to all three guns — the board wires that bit to the green ladder alone, so do not implement IRGB_1555.
rtl/video/badlands_dac.sv:14 Expect a small systematic colour difference from MAME on any entry with bit 15 set.
rtl/video/badlands_gfx_client.sv:46 MAME's `ROMREGION_INVERT` is MAME's, not the board's: the pen buses `/PF3:0` and `/MO3:0` are active low, which is the polarity the 27512 already holds.
rtl/video/badlands_lb.sv:19 512 locations per bank (A8:A0 = 9 bits) = MAME's `xposmask = 0xff80`.
rtl/video/badlands_lb.sv:60 With this phase the MOH X field maps straight to the screen column with no offset, exactly as MAME's atarimo does.
rtl/video/badlands_mo.sv:29 Objects per line — a hard limit with no MAME counterpart: entries 0..26 fetched at H = 0..431, drawn at H = 16..447, fully drawn
rtl/video/badlands_mo_fetch.sv:56 0 = the schematic (code[11:10] bypasses the row adder through 13V/15V), 1 = MAME (the whole 12-bit code is incremented).
rtl/video/badlands_pf.sv:17 D12 bank D11 | device | tiles offset MAME code
rtl/video/badlands_pf.sv:25 MAME's `code = (data & 0x1fff) + (BIT(data,12) ?
rtl/video/badlands_prio.sv:51 The rule this produces: the motion object wins when mo_pen != 0 AND ( priority OR NOT pf_pen[3] ), which is what MAME's `screen_update_badlands` does.
rtl/video/badlands_video.sv:32 8c+7 — the visible window is columns 0..41 exactly, with no scroll and no offset, which is what MAME's un-scrolled 64 x 32 TILEMAP_SCAN_ROWS produces; * the LB read pointer is reset at H = 5 and location L is read during count L+6, so LB lo
rtl/video/badlands_video.sv:54 0 = schematic, 1 = MAME's row carry
rtl/video/badlands_vmatch.sv:21 The internals are inferred: this is the only algorithm consistent with the pin widths, the MO RAM layout, the ROM geometry and MAME.
rtl/video/badlands_vmatch.sv:40 This reproduces MAME's atarimo arithmetic exactly: MAME draws the sprite from `ypos = (-Y - 8*height) mod 512` downwards, and solving `sy = ypos + 8*t + line` for the scanline gives the same D.
rtl/video/badlands_vmatch.sv:47 MAME increments the full 12-bit code instead; `code_hi_carry` exports MAME's version of the top two bits so `badlands_mo`'s `MO_CODE_CARRY` parameter can select either behaviour.
rtl/video/badlands_vmatch.sv:73 (code + row)[11:10] — the MAME leg
rtl/video/badlands_vmatch.sv:130 ...and this is what MAME would produce instead.
README.md:39 | ROMs | Supplied by you from a MAME archive; none are included here |
README.md:182 The six GALs were decoded with MAME's `jedutil` and their equations are implemented verbatim.
README.md:185 **Main CPU boot** — the 68000 bus is co-simulated against MAME: **912,548 consecutive bus cycles agree** (address, R/W, data, size) through reset, the ROM check
README.md:191 **Video** — MAME is instrumented to capture complete video state (playfield, motion-object and colour RAM) at chosen frames; those states are replayed through t
README.md:194 **21 frames — 8 attract, 12 gameplay, 1 power-on — are pixel-exact over the 1,122,902 compared pixels.** The pixels left out are the scanlines where the CPU wri
README.md:199 **Sound** — the sound section is compared to MAME over **12 seconds / 719 frames**: 586 mailbox commands and 584 responses order-exact, the YM2151 register writ
README.md:201 The one divergence is the inverted self-test bit described below; flipping that single bit reproduces MAME's streams exactly, which shows it is the *only* diffe
README.md:221 MAME is this project's functional oracle and every gate above measures the core *against* it, so this is a narrow list, not a general claim.
README.md:226 | Behaviour | MAME | This core |
README.md:228 | **Motion-object entries** | 64 entries at a 2-byte stride | The video-side address bit `A1` is forced low, so entries are **4 bytes apart and there are 32**.
README.md:233 | **Sound self-test bit polarity** | D7 = 1 when self-test is *off* | The inverting LS240 and the game ROM both give D7 = 1 when the switch is *on*. MAME's pola
README.md:240 **The 27-object limit and the 32-entry list** are the two places where a crowded screen could in principle look different from MAME.
README.md:247 On a colour word with bit 15 set, MAME brightens all three guns and the board brightens only green.
README.md:337 Thanks to the MAME team, whose `badlands.cpp`, `badlands_v.cpp` and `atarimo.cpp` served as the functional oracle throughout — and whose PCB notes record the re

Says it matches, follows or was checked against MAME — 4

rtl/video/badlands_lb.sv:35 The idle value is 8'hFF: DI3:0 are the active-low pens /MO3:0, so all-ones decodes to pen 0 = transparent, matching MAME's transparent pen 0.
rtl/video/badlands_pf.sv:45 18S 74F74 half 1 has /PRE and /CLR both tied to +5 V, so the bank bit's power-on value is indeterminate; `BANK_POR` parameterises it and 0 matches MAME.
rtl/video/badlands_vmatch.sv:14 OE = GND (always enabled) VFLIPEN = GND HFLD = no connect -> Bad Lands motion objects cannot flip, matching MAME's hflipmask = 0 / vflipmask = 0.
README.md:266 Its alignment is proved pixel-exact against MAME over 21 frames; its idle output value, read latency and strobe widths as silicon facts are not.

Says it was translated, ported or taken from MAME — 1

rtl/video/badlands_mo_fetch.sv:75 MAME's carried code[11:10]

Shares text with the MAME driver without saying so — 1

rtl/video/badlands_pf.sv:25 MAME's `code = (data & 0x1fff) + (BIT(data,12) ? (bank << 12) : 0)` is the — shares text with atari/badlands_v.cpp:24

Bagman#
Bagman, Botanic, Pickin', Super Bagman …
MiSTer-devel/Arcade-Bagman_MiSTer @ ee2393eb
MAME compared: valadon/bagman.cpp + 3 related file(s)
Read: 9 HDL files, 2,527 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

44%

Statements: 5 toward MAME

Cites MAME source — 4

rtl/bagman_pal16r6.vhd:6 MAME show a complete pal16r6 simulation from fusemap.
rtl/bagman_pal16r6.vhd:45 Clock scheme within MAME seems to be missing.
rtl/plc10_speech_synthetizer.vhd:4 Main part of the TMS5110 simulation - algorithm is from MAME source Job here includes parsing the bit stream from PROM data and computes speech samples
rtl/ym_2149_linmix.vhd:44 Clues from MAME sound driver and Kazuhiro TSUJIKAWA

Says it was translated, ported or taken from MAME — 1

rtl/bagman_pal16r6.vhd:4 Pal contents comes from MAME src/machine/bagman.c fusemap.

BankPanic#
Bank Panic, Combat Hawk
MiSTer-devel/Arcade-BankPanic_MiSTer @ 6f30da47
MAME compared: sanritsu/bankp.cpp
Read: 15 HDL files, 7,485 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

23%

Statements: 2 toward hardware

Cites hardware documentation that MAME's driver does not — 2

rtl/core.v:529 shift & select high or low bits of ROM data translated to verilog to avoid a lot of 74LS194 instances
rtl/sn76489_audio.vhd:52 * The SN76489 datasheet * Insight gained from the AY-3-8910/YM-2149 die-shot and reverse-engineered schematics (similar audio chips from the same era).

Batman#
Batman
MiSTer-devel/Arcade-Batman_MiSTer @ 34783858
MAME compared: atari/batman.cpp + 8 related file(s)
Read: 37 HDL files, 7,334 lines (Quartus project)

MiSTer official

Both

high

79%

Statements: 78 toward hardware, 69 toward MAME, 8 not counted

Cites hardware documentation that MAME's driver does not — 72

Arcade-Batman.sv:127 (index 2) 0x000800 eeprom 28C16 at 12R, NVRAM save/restore BRAM
rtl/batman_core.sv:34 The 6502's /RESET from the game board's LS273 1S latch (sndres_n) is a separate net.
rtl/batman_core.sv:43 R80 * C115 = 10 ms of power-on reset (from the schematic).
rtl/batman_core.sv:205 Driven by batman_main, used by batman_sound: /SNDRES from the LS273 1S, the two /SCOM strobes with the 68000's odd byte, and /AUDIRQ, /AUDFULL and the mailbox byte coming back.
rtl/batman_core.sv:214 the LS273 1S output latch bits that leave the main board
rtl/batman_core.sv:300 the rest of the LS273 1S
rtl/main/batman_cpu.sv:4 Batman main CPU: fx68k (cycle-exact 68000) wired as the MC68000 at 6L/M.
rtl/main/batman_decode.sv:3 Batman main-board address decode: GAL 136085-1002 at 9L, the 74F138 device decoder at 5/6K and the 74LS138 I/O-strobe decoder at 1P/R (from the schematic, pages 42 and 44).
rtl/main/batman_decode.sv:26 ---- GAL 9L outputs (not qualified by /AS) ----
rtl/main/batman_decode.sv:38 Y1 28C16 at 12R +0x20000
rtl/main/batman_decode.sv:46 ---- LS138 1P/R, the I/O strobes (MA6:MA4 inside /CIO) ----
rtl/main/batman_decode.sv:52 Y5 +0x50 LS273 1S clock
rtl/main/batman_decode.sv:58 9L: GAL16V8A 136085-1002, in its own pin numbers
rtl/main/batman_decode.sv:83 5/6K: 74F138, the device block
rtl/main/batman_decode.sv:105 1P/R: 74LS138, the I/O strobes
rtl/main/batman_dtack.sv:3 Batman /DTACK: the 74F163 wait counter at 8K and the LS04 at 12M that inverts its RCO into the 68000's /DTACK (from the schematic, page 44).
rtl/main/batman_dtack.sv:45 ---------------- 74F163 8K -------------------------------------------
rtl/main/batman_eeprom_28c16.sv:4 Batman 28C16 (2K x 8) EEPROM at 12R and the 74LS74 unlock flop at 11N/P that drives its /OE (from the schematic, page 44).
rtl/main/batman_eeprom_28c16.sv:148 ---- LS74 11N/P half A ----------------------------------------------- /CLR = /SYSRES; /PRE (unlock) is a level and wins over its own /WL edge.
rtl/main/batman_gal_9l.sv:3 Batman GAL16V8A 136085-1002 at 9L (label B_MAIN): the 68000 address decoder.
rtl/main/batman_gal_9l.sv:4 Equations from the GAL fuse map; pin names from the schematic, page 44.
rtl/main/batman_gal_9l.sv:16 It uses both BAS and /AS, which stretches the enable slightly past /AS rising and gives the LS273 at 1S its clock edge inside the data-hold window.
rtl/main/batman_inputs.sv:3 Batman controls, status word and output latch: the 74LS257 muxes at 1P, 2P and 2S, the empty 1R/S expansion socket and the 74LS273 output latch at 1S (from the schematic, page 42).
rtl/main/batman_inputs.sv:17 LS273 at 1S: clocked on the rising (releasing) edge of /LATCH, cleared by /SYSRES.
rtl/main/batman_inputs.sv:54 ---- the LS273 1S ----
rtl/main/batman_inputs.sv:93 1S: the 74LS273 output latch
rtl/main/batman_irq.sv:3 Batman interrupts: the LS08 IPL encoder at 10K and the LS20 /VPA gate at 7D (from the schematic, page 44).
rtl/main/batman_main.sv:3 Batman game PCB A048987-01, 68000 side: the CPU at 6L/M, the address decode, the wait counter, 64 KB work RAM, the 28C16 EEPROM, the watchdog, the input muxes, the LS273 output latch and the interrupt encoder, plus the MiSTer ROM loader and
rtl/main/batman_main.sv:61 -> GAL 9L pin 9
rtl/main/batman_main.sv:69 pin 1, latch 3Q, a level
rtl/main/batman_main.sv:79 ================= the rest of the LS273 1S ==========================
rtl/main/batman_main.sv:161 the whole LS273 1S
rtl/main/batman_main.sv:173 the 68000 at 6L/M
rtl/main/batman_main.sv:211 the decode: GAL 9L + F138 5/6K + LS138 1P/R
rtl/main/batman_main.sv:311 inputs, the status word and the LS273 1S output latch
rtl/main/batman_main.sv:405 the EEPROM at 12R and the 11N/P unlock flop
rtl/main/batman_nvram_io.sv:4 MiSTer load/save controller for the Batman 28C16 EEPROM at 12R.
rtl/main/batman_watchdog.sv:3 Batman power-on reset and watchdog: the R80/C115/Q7 POWER-ON node (schematic page 41) and the 74LS197 counter at 12N/P (page 44).
rtl/main/batman_watchdog.sv:14 /SYSRES reaches the 68000, the EEPROM unlock flop and the LS273 at 1S; it does not reset the VAD.
rtl/main/batman_watchdog.sv:60 ---------------- 74LS197 12N/P --------------------------------------- /VBLANK falls at the start of blanking = rising edge of active-high vblank.
rtl/video/batman_alpha.sv:11 Cell word (as MAME decodes it; the video sheets are not in the manual): bits 9-0 character code bit 10 bank enable: 1 -> code + ALBK * 0x400 bits 14-11 colour (ALC3:0) bit 15 opaque (ALBG): pen 0 is drawn too ALBK2:0 is LS273 outp
rtl/video/batman_alpha.sv:41 LS273 1S bits 14:12
rtl/video/batman_cram.sv:3 Batman colour RAM at 6A/6B: 2048 x 16 at 0x2E0000-0x2E0FFF, shared by the video scan and the 68000.
rtl/video/batman_dac.sv:3 Batman video DAC: the three R2R 1K/2K ladders R11/R12/R13, the 74LS260 pen-zero NORs at 3A/B and 3B/C and the 7406 black clamp at 3C/D (schematic page 43).
rtl/video/batman_dac.sv:14 A 74LS260 NOR over the five upper bits of each gun drives a 7406 that pulls the gun to black when they are all zero; I is not in the NOR, so {0, I=1} is black on the board.
rtl/video/batman_gal_11d.sv:3 Batman GAL16V8A 136085-1005 at 11D: motion-object line-buffer phase control and the "stain" (shadow run) latch.
rtl/video/batman_gal_9b.sv:3 Batman GAL20V8A 136085-1004 at 9B: colour-RAM address bits CRA1..CRA4 and the layer-select pair CS0 / CS1.
rtl/video/batman_gal_9b.sv:19 The MO pixel bits arrive active low (the stamp ROM is stored inverted), unlike the MO colour bits at 9C; this is the board's wiring, not an error.
rtl/video/batman_gal_9c.sv:3 Batman GAL20V8A 136085-1003 at 9C: colour-RAM address bits CRA5..CRA10.
rtl/video/batman_gal_9d.sv:3 Batman GAL16V8A 136085-1006 at 9D: PF/M (playfield-over-motion-object priority), its complement, and an "MO byte == 0x01" decode.
rtl/video/batman_lb.sv:3 Batman motion-object line buffers: the two 137536-001 customs at 11B and 11C.
rtl/video/batman_mixer.sv:3 Batman colour-RAM address generator: GALs 136085-1006 (9D), 1004 (9B), 1003 (9C) and 1005 (11D) wired together, plus the stain run latch.
rtl/video/batman_mixer.sv:82 9D (136085-1006): PF/M
rtl/video/batman_mixer.sv:108 9B (136085-1004): CS0, CS1 and CRA4:1
rtl/video/batman_mixer.sv:126 9C (136085-1003): CRA10:5
rtl/video/batman_mixer.sv:146 11D (136085-1005): line-buffer phase and the stain markers
rtl/video/batman_mob.sv:3 Batman motion-object engine: the MOB 137593-001 custom at 10F.
rtl/video/batman_pf.sv:26 MAME stores the region inverted, and the MRA ships raw bytes, so ROM_INVERT applies the board's inversion here (the playfield pen reaches GAL 9B active high).
rtl/video/batman_vad_regs.sv:3 Batman VAD 137656-002 at 6F: the 32-word register file at 0x2EFFC0, the end-of-frame (EOF) reload and the parameter-word (scroll) decoder.
rtl/video/batman_vad_sync.sv:3 Batman VAD 137656-002 at 6F: the raster counters, sync, blanking and the scanline interrupt, all generated from the register file (no timing constants in the data path).
rtl/video/batman_vad_sync.sv:29 The counters free-run from power-up whatever reg 00 says: the main board's LS197 at 12N/P holds the 68000 in reset until it has counted eight /VBLANK edges, so the raster must run before the CPU can program the VAD.
rtl/video/batman_video.sv:3 Batman video block: the Atari VAD 137656-002 at 6F, the MOB 137593-001 at 10F, the two 137536-001 line buffers, the four priority GALs, the colour RAM and the DACs, all behind the board's single /VRAM strobe.
rtl/video/batman_video.sv:21 The 0x2Exxxx and 0x3Exxxx aliases reach the same hardware (GAL 9L decides whether the 68000 waits).
rtl/video/batman_video.sv:70 -> GAL 9L pin 9
rtl/video/batman_video.sv:73 ---- the LS273 1S output latch ----------------------------------------
README.md:9 The address decoding, the sound board and the video mixer come from Atari's schematics and from the dumped GAL chips.
README.md:11 Where the schematics and MAME disagree, the core follows the schematics, so a few things deliberately differ from MAME.
README.md:107 **Address decoding from the actual chips.** The 68000's memory map is the dumped GAL 136085-1002 at 9L, together with the 74-series decoders drawn on the schema
README.md:112 **Bus timing.** Wait states come from the board's F163 counter, and interrupts use the schematic's priority encoding: level 4 for the video scanline interrupt,
README.md:120 **Analog audio.** The board's filter and mixer stages are modelled from the component values on the schematics, which were cross-checked against Atari's parts l
README.md:150 **FM : ADPCM balance.** The filter shapes come from the schematic, but the overall level ratio between the two sound chips depends on their output levels, which
README.md:225 **Reading the source.** Comments name chips by their position on the Atari board, such as "GAL at 9L" or "LS273 at 1S", and the GAL modules name their ports by

Cites hardware references or measurements that MAME's driver also gives — 8

Arcade-Batman.sv:120 0x000000 0x0C0000 maincpu 6 x 27C010 at 10R 7R 9/10R 6R 9R 5R SDRAM — also in MAME: 10R atari/batman.cpp:502, 7R atari/batman.cpp:503, 10R atari/batman.cpp:502, 6R atari/batman.cpp:505, 9R atari/batman.cpp:506, 5R atari/batman.cpp:507
Arcade-Batman.sv:121 0x0C0000 0x020000 chars 1 x 1 Mbit at 10M BRAM — also in MAME: 10M atari/batman.cpp:513
Arcade-Batman.sv:124 0x2E0000 0x010000 jsa:cpu 1 x 27C512 at 12C BRAM — also in MAME: 12C atari/batman.cpp:510
Arcade-Batman.sv:125 0x2F0000 0x080000 jsa:oki1 4 x 1 Mbit at 19E 17E 15E 12E SDRAM — also in MAME: 19E atari/batman.cpp:536, 17E atari/batman.cpp:537, 15E atari/batman.cpp:538, 12E atari/batman.cpp:539
rtl/mem/batman_prog_rom.sv:4 Batman 68000 program ROM: the six 27C010s at 10R/7R, 9-10R/6R and 9R/5R (schematic page 45), served from SDRAM through a direct-mapped cache with 4-word lines and next-line prefetch. — also in MAME: 10R atari/batman.cpp:502, 7R atari/batman.cpp:503, 10R atari/batman.cpp:502, 6R atari/batman.cpp:505, 9R atari/batman.cpp:506, 5R atari/batman.cpp:507
rtl/mem/batman_rom_loader.sv:45 ---- JSA 6502 program (64 KB ROM at 12C) -> block RAM ---- — also in MAME: 12C atari/batman.cpp:510
README.md:116 **The whole JSA III sound board.** Its two GALs (136085-1038 and -1039) come from their fuse maps. — also in MAME: 136085-1038 atari/batman.cpp:551
README.md:131 **Video mixing and colour.** The four priority GALs (136085-1003, -1004, -1005 and -1006) come from their fuse maps. — also in MAME: 136085-1003 atari/batman.cpp:547

Notes where it differs from MAME — 6

rtl/main/batman_dtack.sv:18 then /DTACK two CPU clocks later interrupt acknowledge P = 2 frozen: /DTACK never asserts (autovector) Wait states come from the GAL fuse map; MAME models none.
rtl/main/batman_inputs.sv:16 MAME ignores A1 on the status read.
rtl/video/batman_vad_dma.sv:11 The game sets bit 14 around every edit of these tables; MAME ignores reg 00, but those critical sections only make sense if bit 14 suspends the DMA.
rtl/video/batman_vad_regs.sv:9 The manual lacks the VAD sheet; this follows MAME's atarivad, corrected where the game's own behaviour shows MAME is incomplete: * Reg 00: bit 15 master enable, bit 14 suspends the VAD's DMA channel (the game sets it around every edit of th
README.md:11 Where the schematics and MAME disagree, the core follows the schematics, so a few things deliberately differ from MAME.
README.md:132 The colour DACs follow the resistor ladder on the schematic, including the black-level clamp, which MAME does not model.

Cites MAME source — 58

Arcade-Batman.sv:24 The MRA also carries MAME's batman-eeprom.bin as a seed so a first boot without a save file gets the factory settings.
Arcade-Batman.sv:129 MAME inverts `tiles` and `sprites` after loading; this core applies the board's own active-low sense in the video RTL.
rtl/batman_core.sv:40 1 = 14.318181 MHz (as MAME), 0 = 7.159 MHz.
rtl/main/batman_cpu.sv:11 MAME runs the CPU at 14.318 MHz; sibling Atari boards use 7.16 MHz.
rtl/main/batman_cpu.sv:11 This core follows MAME (CPU_14M = 1); batman_dtack must get the same value because its wait counter is clocked from the same node.
rtl/main/batman_cpu.sv:25 1 = 14.318 MHz (ce_14m, as MAME), 0 = 7.159 MHz (ce_7m).
rtl/main/batman_eeprom_28c16.sv:17 WRITE_CYCLES models the byte programming time (MAME treats writes as instant).
rtl/main/batman_inputs.sv:36 JAMMA 17 STRT1 ("JAMMA START 1"; MAME calls it unused)
rtl/main/batman_main.sv:13 The data bus has no buffers or pull-ups, so any lane nothing drives reads as UNDRIVEN_DATA (0xFFFF, as MAME).
rtl/main/batman_main.sv:23 1 = 68000 at 14.318 MHz (as MAME), 0 = 7.159 MHz.
rtl/main/batman_main.sv:395 Block RAM powers up at 0x00, as MAME's work RAM does.
rtl/main/batman_watchdog.sv:12 MAME uses its 3-frame default instead.
rtl/mem/batman_rom_loader.sv:77 In MAME's order the four bit planes of one stamp row are 0x40000 bytes apart, i.e. in four SDRAM rows.
rtl/video/batman_alpha.sv:11 Cell word (as MAME decodes it; the video sheets are not in the manual): bits 9-0 character code bit 10 bank enable: 1 -> code + ALBK * 0x400 bits 14-11 colour (ALC3:0) bit 15 opaque (ALBG): pen 0 is drawn too ALBK2:0 is LS273 outp
rtl/video/batman_dac.sv:12 Each gun is a 6-bit ladder whose LSB is the shared intensity bit I (colour-RAM bit 15): gun = {channel[4:0], I}, expanded to 8 bits the way MAME does.
rtl/video/batman_dac.sv:16 MAME has no clamp and shows that code as 4/255; BLACK_CLAMP = 0 reproduces MAME.
rtl/video/batman_dac.sv:41 MAME's pal6bit: (v << 2) | (v >> 4), equal to round(255 * v / 63).
rtl/video/batman_gal_11d.sv:14 The manual lacks the video sheets, so the pin names below are inferred from sibling boards and MAME.
rtl/video/batman_gal_9d.sv:13 The manual lacks the video sheets, so pin names are inferred from ThunderJaws' GAL and MAME.
rtl/video/batman_gal_9d.sv:14 PF/M reproduces MAME's rule for the selected playfield's priority PFX9:8 against MO priority MPR1:0: 3: playfield always wins 2: wins if MPR < 2 and not upper pen 1: wins if MPR == 0 and not upper pen 0: never Pins 15/16 are tak
rtl/video/batman_gal_9d.sv:20 ThunderJaws ORs it into PF/M; Batman does not, and MAME has no such rule, so the mixer leaves pin 19 unconnected.
rtl/video/batman_lb.sv:21 FIRST_WINS: MAME draws Batman's object list in reverse, so the first entry ends up on top.
rtl/video/batman_mixer.sv:17 Stain (MAME's name for it): a motion object with priority bit MPR2 set is not drawn.
rtl/video/batman_mixer.sv:34 ---- what 9D pins 15 and 16 are wired to (the sheet is missing) ------ 0 = PFX3 of the selected playfield and PFXS; reproduces MAME.
rtl/video/batman_mixer.sv:51 An MPR2 object draws no visible pixel (as in MAME), but 11D still needs its pen to run the stain.
rtl/video/batman_mixer.sv:171 Behaviour follows MAME's atarimo apply_stain: * a start pixel stains itself and opens the run; * every pixel inside the run is stained; * an end pixel arms `offnext`, and the run closes after the next pixel unless that pixel is itself a sta
rtl/video/batman_mixer.sv:176 MAME runs it to the bitmap edge instead; that makes no visible difference.
rtl/video/batman_mob.sv:9 The manual lacks the video sheets, so Batman's settings follow MAME's atarimo configuration: 10-bit links, 4-word entries at MOBASE + 4 * link, 8 x 8 stamps, a 64-word SLIP table of 8-line bands, no vertical flip.
rtl/video/batman_mob.sv:25 X offset; MAME uses -1.
rtl/video/batman_mob.sv:31 MAME's bitmap geometry, used by the coordinate folds.
rtl/video/batman_mob.sv:98 MAME masks 0x0007
rtl/video/batman_pf.sv:3 Batman playfield layer, instantiated twice: PF1 (P1BASE 0x2F0000, the transparent foreground, MAME's `playfield2`) and PF2 (P2BASE 0x2F2000, the opaque background, MAME's `playfield`).
rtl/video/batman_pf.sv:26 MAME stores the region inverted, and the MRA ships raw bytes, so ROM_INVERT applies the board's inversion here (the playfield pen reaches GAL 9B active high).
rtl/video/batman_vad_dma.sv:17 It runs during vertical blanking, the only time the video RAM has DMA slots (MAME does it at line 0).
rtl/video/batman_vad_dma.sv:31 1 = take the autostore byte when the write reaches the RAM; 0 = at the CPU write, as MAME does.
rtl/video/batman_vad_regs.sv:28 last EOF index replayed (as MAME)
rtl/video/batman_vad_regs.sv:29 skip zero words (as MAME)
rtl/video/batman_vad_regs.sv:30 Regs 01-1F read back their last value, as in MAME; the game never reads them, so this is unobservable.
rtl/video/batman_vad_regs.sv:84 tag A (MAME m_pf1_xscroll_raw)
rtl/video/batman_vad_regs.sv:85 tag B (MAME m_pf0_xscroll_raw),
rtl/video/batman_vad_regs.sv:224 The two playfields share one horizontal fetch pipeline, so PF2's scroll includes the low three bits of PF1's (confirmed against MAME's frames).
rtl/video/batman_vad_sync.sv:12 Register fields (register layout as in MAME; the VAD sheet is not in the manual) and Batman's values: reg 01 V_SY_S [11:3] V_SY_E [2:0] 0795
rtl/video/batman_vad_sync.sv:43 ---- scanline interrupt ------------------------------------------------- 0 = a comparator on the V counter (fires every frame); 1 = MAME's one-shot timer, re-armed by each reg 03 write.
rtl/video/batman_video.sv:459 An MPR2 object is hidden from 9B/9C/9D (as in MAME) but still seen by 11D.
rtl/video/batman_vram.sv:14 (The VAD sheet is not in the manual; this schedule is inferred from MAME, the VAD registers and frame matching.) clk_sys gives eight clocks per pixel, so here each pixel is split into eight phases: ph 0-4 the layers, ph 5 MO, ph 6 CPU, ph 7
README.md:10 MAME is used as a cross-reference for what the schematics do not cover.
README.md:25 MAME has one Batman set, with no clones.
README.md:50 **First boot.** Before a save file exists, the core fills the EEPROM from the factory image in the MAME set (`batman-eeprom.bin`).
README.md:117 The 6502's 4 ms interrupt timer only restarts after the 6502 acknowledges it, as on the board; MAME runs it freely.
README.md:122 MAME applies no filtering, so this core sounds darker than MAME, as the real board does.
README.md:123 The ADPCM and FM chips are mixed 33 : 15, as the mixer resistors set it; MAME uses 0.75 : 0.60.
README.md:126 MAME uses a flat ×2.
README.md:128 **ADPCM ROM banking from the GAL.** In one bank, the GAL on the sound board selects a different sample ROM than MAME's hard-coded mapping.
README.md:147 The core uses 14.318 MHz, as MAME does.
README.md:171 | Boot | 338,939 bus cycles of the 68000 from power-on (every write, and every access outside the program ROM), compared one by one with MAME | Same cycles in t
README.md:172 | Video | 44 frames (attract, gameplay, the staircase scene, all four self-test screens, synthetic states) compared pixel by pixel with MAME, with graphics fetc
README.md:176 The test benches, MAME captures and development notes behind these results are not part of this repository.
README.md:265 **The MAME team**: `batman.cpp`, `atarivad`, `atarimo` and `atarijsa` (Aaron Giles and contributors) were the cross-reference for everything the schematics do n

Says it matches, follows or was checked against MAME — 11

rtl/video/batman_lb.sv:12 The manual lacks the video sheets, so this follows MAME's atarimo.
rtl/video/batman_mixer.sv:30 1 = joined after the 9B/9C mux, so alpha pixels are stained too; the core uses this, and it matched MAME's frames.
rtl/video/batman_mob.sv:94 Vertical match, in MAME's arithmetic so the wrap-around folds agree
rtl/video/batman_pf.sv:30 XOFF defaults to 0; batman_video sets the offsets that match MAME's frames.
rtl/video/batman_vad_dma.sv:9 The manual lacks the VAD sheets; this follows MAME's atarivad plus what the game program does.
rtl/video/batman_vad_regs.sv:9 The manual lacks the VAD sheet; this follows MAME's atarivad, corrected where the game's own behaviour shows MAME is incomplete: * Reg 00: bit 15 master enable, bit 14 suspends the VAD's DMA channel (the game sets it around every edit of th
rtl/video/batman_video.sv:12 The kit manual does not include the video schematic sheets (VAD, MOB, video RAM, line buffers), so this block follows MAME's atarivad / atarimo, the GAL fuse maps and sibling Atari cores, checked against MAME's frames.
rtl/video/batman_video.sv:34 ---- tuning; the defaults match MAME's frames pixel for pixel --------
README.md:143 That part of the core follows MAME's behaviour, the fuse maps of the GALs around it and sibling Atari cores, and it was checked frame by frame against MAME and
README.md:173 | Sound | 3 s of attract and 22 s of gameplay replayed against MAME recordings | Every sound-chip write made in answer to a game command matches MAME in order a
README.md:174 | Whole core | Built with Quartus 17.0.2 and run on DE10-Nano boards by the author and by other testers | Boots and plays with no problems reported. Screenshots

BattleZone#
Bradley Trainer, Battlezone, Red Baron
MiSTer-devel/Arcade-BattleZone_MiSTer @ 14207b4f
MAME compared: atari/bzone.cpp + 6 related file(s)
Read: 32 HDL files, 5,795 lines (Quartus project)

MiSTer official

Mostly hardware

low

27%

Statements: 5 toward hardware

Cites hardware documentation that MAME's driver does not — 1

rtl/POKEY.sv:495 This instance name made sense at 4AM when I typed it

Ships hardware documentation files — 4

Berzerk#
Berzerk
MiSTer-devel/Arcade-Berzerk_MiSTer @ 737c3995
MAME compared: stern/berzerk.cpp
Read: 9 HDL files, 2,612 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

45%

Statements: 3 toward MAME

Cites MAME source — 2

rtl/berzerk.vhd:62 Mame command reminder wpiset 40,1,w,1,{printf "a:%08x d:%02X",wpaddr,wpdata; g} wpiset 40,1,w,(wpdata!=0) && (wpdata!=90) && (wpdata!=92),{printf "a:%08x d:%02X",wpaddr,wpdata; g}
rtl/berzerk_speech.vhd:6 By Jonathan Gevaryahu ("Lord Nightmare") with help from Kevin Horton ("kevtris") MAME conversion and integration by R. Belmont Clock Frequency control updated by Zsolt Vasvari Other fixes by AtariAce

Says it was translated, ported or taken from MAME — 1

rtl/berzerk_speech.vhd:4 s14001a speech synthesis based on Mame source code : TSI S14001A emulator v1.32

BlackWidow#
Black Widow, Gravitar
MiSTer-devel/Arcade-BlackWidow_MiSTer @ e560fd8b
MAME compared: atari/bwidow.cpp + 2 related file(s)
Read: 40 HDL files, 16,352 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

11%

Statements: 12 toward hardware, 1 toward MAME, 4 not counted

Cites hardware documentation that MAME's driver does not — 12

Arcade-BlackWidow.sv:484 The numbers in parentheses will appear on the BONUS ADDER line in the Operator Information Display (Figure 2-1) for these settings.
rtl/avg/avg_prom_core.vhd:105 On hardware, this is latched by the LS175 (6L, schematic p.25 Fig.1) from DVY10-DVY8, and drives the LS191 down-counter that gates additional fill-bit shifts into the timer at STROBE 1.
rtl/avg/avg_prom_core.vhd:114 GO flag (schematic p.24 Fig.3: 2E LS32 pin 8).
rtl/avg/avg_prom_core.vhd:136 Bin_scale shift mechanism at STROBE 1 (schematic p.25 Fig.1: Vector Scaling).
rtl/avg/avg_prom_core.vhd:251 /LATCH1 clears three chip groups (schematic p.23): 5F,5H (Fig.2): DVY0-7 async cleared to 0 5A,5B,5C (Fig.2): DVX0-11 async cleared to 0 3C (Fig.0): Z0-Z2 + DVX12 async cleared to 0 6H(DVY8-11) has /CLR=PR110 (not cleared here).
rtl/avg/avg_prom_core.vhd:288 STROBE0 + OP0=0 sets NORM (LS74 5K, p.24 Fig.0).
rtl/avg/avg_prom_core.vhd:299 STROBE 1 (action $D): SP adjust for JSR/RTS, or Vector Scaling (schematic p.25 Fig.1) for VCTR/SVEC.
rtl/avg/avg_prom_core.vhd:326 Scale (0111_SSS LLLLLLLL) SSS = bin_scale -> LS175 latch (6L) -> LS191 counter (6M) LLLLLLLL = linear_scale -> LF13201 DAC (schematic p.26)
rtl/avg/avg_prom_core.vhd:393 Schematic p.23 Fig.2: LS194 shift registers (3A-3D, 4A-4D) shift DVX/DVY left at 12 MHz, gated by ENORM.
rtl/avg/avg_prom_core.vhd:395 Schematic p.25 Fig.0: LS161 timer chain (1D/1C/1B/2B) shifts right simultaneously, filling from the top.
rtl/avg/avg_prom_core.vhd:436 Schematic p.25 Fig.1: Vector Scaling circuit.
rtl/avg/vector_drawer.vhd:59 Linear scale velocity multiplier (schematic p.26: LF13201 multiplying DAC).

Cites hardware references or measurements that MAME's driver also gives — 4

rtl/avg/avg_prom_core.vhd:63 Hardware: 136002-125.n4 bipolar PROM — also in MAME: 136002-125 atari/bwidow.cpp:865
rtl/avg/avg_prom_core.vhd:110 PROM state machine signals (256x4 PROM 136002-125.n4) — also in MAME: 136002-125 atari/bwidow.cpp:865
rtl/pgmrom.vhd:57 136017-101.d1 4096 0 0000 000000000000 136017-102.ef1 4096 4096 0001 000000000000 136017-103.h1 4096 8192 0010 000000000000 136017-104.j1 4096 12288 0011 000000000000 136017-105.kl1 4096 16384 0100 000000000000 136017-106.m1 4096 2048 — also in MAME: 136017-101 atari/bwidow.cpp:855, 136017-102 atari/bwidow.cpp:856, 136017-103 atari/bwidow.cpp:857, 136017-104 atari/bwidow.cpp:858, 136017-105 atari/bwidow.cpp:859, 136017-106 atari/bwidow.cpp:860
rtl/vecrom.vhd:50 136017-107.l7 2048 24576 0110 000000000000 blank 2048 26624 0110 100000000000 136017-108.mn7 4096 28672 0111 000000000000 136017-109.np7 4096 32768 1000 000000000000 136017-110.r7 4096 36864 1001 000000000000 — also in MAME: 136017-107 atari/bwidow.cpp:850, 136017-108 atari/bwidow.cpp:851, 136017-109 atari/bwidow.cpp:852, 136017-110 atari/bwidow.cpp:853

Shares text with the MAME driver without saying so — 1

Arcade-BlackWidow.sv:449 ------------------------------------------------------------------------------- Settings of 8-Toggle Switch on Black Widow CPU PCB (at D4) 8 7 6 5 4 — shares text with atari/bwidow.cpp:30

Blasteroids#
Blasteroids
MiSTer-devel/Arcade-Blasteroids_MiSTer @ f8ceffb0
MAME compared: atari/blstroid.cpp + 8 related file(s)
Read: 32 HDL files, 7,475 lines (Quartus project)

MiSTer official

Both

high

82%

Statements: 165 toward hardware, 64 toward MAME, 1 not counted

Cites hardware documentation that MAME's driver does not — 160

Arcade-Blasteroids.sv:46 The Whirly-Gig counter is the Atari LETA custom at 8A, inside blstroid_main.
Arcade-Blasteroids.sv:153 Button 4 is sheet 12's D3 "spare", which is unwired in a cabinet but IS displayed by the self test, so it is mapped rather than tied off - that is what lets a user confirm the whole input path from the Switch Test.
Arcade-Blasteroids.sv:281 The counter itself is the Atari LETA custom at 8A, inside blstroid_main where sheet 4 puts it; this module only synthesises the CLK/DIR pin pair that reaches it.
Arcade-Blasteroids.sv:426 DW = 24: the colour RAM is xRGB 5:5:5 (SP-316 sheet 12) and the core expands it through the R/2R DAC transfer, so it hands over 8 bits per channel.
rtl/blstroid_core.sv:12 blstroid_rom_loader / _prog_rom / _ram8 / _sdram_loader / _gfx_mem / _sdram the ioctl download, the 256 KB program ROM and the 64 KB sound ROM in BRAM, and the graphics SDRAM blstroid_main SP-316 sheets 2-5 and 12: fx68k, the addre
rtl/blstroid_core.sv:45 `blstroid_vram` still drives `vram_a` and still latches VD15 into the 4K LS174B on 4H, so `PFM2` — the row-interrupt condition — still comes from the sheet-6 latch regardless of who owns the array.
rtl/blstroid_core.sv:104 The SOS-2 counts V internally and the schematics do not settle 262 against the 263 the same Atari sync-generator family produces, so this is a build-time parameter; rebuild with 263 to try it.
rtl/blstroid_core.sv:143 `blstroid_whirly` in Arcade-Blasteroids.sv synthesises them from the MiSTer spinner / paddle / mouse / d-pad; the COUNTER is the LETA custom at 8A, inside blstroid_main where sheet 4 puts it.
rtl/blstroid_core.sv:153 D3 is sheet 12's "spare" and it is not a Start button.
rtl/blstroid_core.sv:167 ---- video out (single clk_sys domain, qualified by ce_pix) ---- 8 bits per channel: colour RAM is xRGB 5:5:5 (sheet 12) and the DAC transfer widens it to 8, so the core's output bus is 8-bit and arcade_video is instantiated with DW = 24.
rtl/blstroid_core.sv:376 Video board — SP-316 sheets 4 to 11
rtl/blstroid_core.sv:473 Main board — SP-316 sheets 2, 3, 4, 5 and 12
rtl/blstroid_core.sv:536 JSA I audio PCB — SP-316 sheets 14 to 17
rtl/blstroid_core.sv:561 The board's own self-clearing periodic divider (sheet 17), not MAME's free-running model of it; the sheet-16 low-pass is real hardware and stays in circuit.
rtl/main/blstroid_addr_decode.sv:3 Blasteroids 68000 address decode — SP-316 sheet 3, gate for gate.
rtl/main/blstroid_addr_decode.sv:6 Structure from the Xybots MiSTer core's rtl/main/xybots_addr_decode.sv (GPL-3.0, same author); every equation below is read off SP-316 sheet 3 rather than taken from MAME's main_map.
rtl/main/blstroid_addr_decode.sv:61 ---- the SLAPSTIC socket ------------------------------------------------- Decoded and exported because sheet 3 draws it; it reaches nothing.
rtl/main/blstroid_addr_decode.sv:62 The 2A socket is empty ("The SLAPSTIC chip is not installed", sheet 3) and the 4A LS157 that would substitute its bank bits is strapped to its B inputs by R77, so 038000-03FFFF is plain program ROM.
rtl/main/blstroid_addr_decode.sv:160 A22..A18, A17 (the ROM-pair /CE, consumed inside blstroid_prog_rom) and A8..A1 (consumed by the RAMs, the priority RAM, the LETA's A2 and the button mux's A1) reach no decoder on sheet 3.
rtl/main/blstroid_cpu.sv:3 Blasteroids main CPU — fx68k (cycle-exact 68000) wired as SP-316 sheet 2 draws the 2C U68000.
rtl/main/blstroid_cpu.sv:19 ---- clock enables ------------------------------------------------------ fx68k is fully synchronous on `clk` (= clk_sys, 57.272724 MHz) and takes TWO enables per CPU clock, one per phase of the nominal 7.15909 MHz /7M: enPhi1 -> the CPU cl
rtl/main/blstroid_cpu.sv:29 ---- pins as sheet 2 wires them ----------------------------------------
rtl/main/blstroid_cpu.sv:52 `oHALTEDn` (fx68k's double-bus-fault output) has no load on sheet 2 and is left open.
rtl/main/blstroid_cpu.sv:57 BERRn is tied inactive: sheet 2 has no bus-error source at all.
rtl/main/blstroid_cpu.sv:59 ---- /VPA and autovectoring -------------------------------------------- Sheet 2 makes /VPA = ~(AS & FC0 & FC1 & FC2) (1D LS20) and wires it both to the 68000's VPA pin and to the 12C LS163A's ENT, so an FC = 7 cycle deliberately gets no /D
rtl/main/blstroid_cpu.sv:128 double bus fault; no load on sheet 2
rtl/main/blstroid_dpram_be.sv:13 Byte writes on either lane must be honoured independently (SP-316 sheet 12); * the colour RAM at FFA000-FFA3FE, 512 x 16 (AW = 9): 0x000-0x0FF are the motion-object palettes, 0x100-0x1FF the playfield palettes, xRGB 5:5:5.
rtl/main/blstroid_dtack.sv:3 Blasteroids /DTACK generator — SP-316 sheet 2 (12C LS163A + 11C LS11 + 11D LS74 + 14/15B LS74 upper + 16A LS260).
rtl/main/blstroid_dtack.sv:7 Derived from the Xybots MiSTer core's rtl/main/xybots_dtack.sv (GPL-3.0, same author), re-done gate for gate off SP-316 sheet 2.
rtl/main/blstroid_dtack.sv:15 ---- 12C LS163A, the wait-state counter -------------------------------- CK (2) = /7M (the 68000 clock) CLR (1) = 11C LS11 pin 12 = /WAITHBL & /VIDRAM & AS (sync clear) LD (9) = QD (11) (self-load fee
rtl/main/blstroid_dtack.sv:37 and the clock chain, all sheet 2: g12B = 12B LS32 (9,10->8) = /1H | 2H g13D = 13D LS10 (1,2,13->12) = ~( /1H & 2H & 4H )
rtl/main/blstroid_dtack.sv:61 A write to FF8E00 asserts /WAITHBL, which also holds the LS163A cleared (11C LS11), so no acknowledge is produced until the rising edge of HBLANK — the CPU stalls inside the bus cycle for up to a whole scan line (~63.7 us).
rtl/main/blstroid_dtack.sv:108 ---- 12C LS163A ------------------------------------------------------
rtl/main/blstroid_eeprom_2804.sv:3 Xicor X2804A (512 x 8) EEPROM at 2A/B, plus the 14/15B LS74 unlock latch — SP-316 sheet 3.
rtl/main/blstroid_eeprom_2804.sv:18 The socket is wired for a 2816 (2 K x 8) but the fitted X2804A is 512 x 8 (A0..A8 only), so the device repeats four times over FFB001-FFBFFF — which is what sheet 12's "a = ADDRESS BITS ON 2816 ONLY" note means and what MAME's `.mirror(0x03
rtl/main/blstroid_inputs.sv:3 Blasteroids status and button ports, FF9C01 / FF9C03 — SP-316 sheet 4 (12L F244, 10A LS257).
rtl/main/blstroid_inputs.sv:14 BD7 A17 -> Y3 SELFTEST active LOW (R1 1 K pull-up on sheet 3; the
rtl/main/blstroid_inputs.sv:20 Sheet 12 prints "XXXX XX01" on the HBLANK row and "XXXX XXX1" on the three above it; the hardware makes all four A1-independent, so that is a drafting slip — D7:D4 read identically at both addresses.
rtl/main/blstroid_inputs.sv:29 An LS257 selects its A inputs when SELECT is low, so FF9C01 (A1 = 0) is player 1 and FF9C03 (A1 = 1) is player 2, matching sheet 12.
rtl/main/blstroid_inputs.sv:33 SPARE1/SPARE2 land on CTRA-9/CTRA-10, which sheet 13's cabinet harness leaves unconnected — they read 1 on a real machine.
rtl/main/blstroid_irq.sv:3 Blasteroids interrupt latches and priority encoder — SP-316 sheet 2 (11C LS11, 1D LS20, 13C LS74, 13D LS10, 11B F00).
rtl/main/blstroid_irq.sv:7 Structure from the Xybots MiSTer core's rtl/main/xybots_irq.sv (GPL-3.0, same author); the equations are read off SP-316 sheets 2 and 6.
rtl/main/blstroid_irq.sv:19 and PFM2 is SP-316 sheet 6, 4K LS174B: D (3) = VD15, Q (2) = PFM2, CK = 4H — bit 15 of the last playfield word the video side fetched, which for the non-displayed column-40 word of a row is sheet 12's ROW PROGRAMMABLE INTERRUPT flag.
rtl/main/blstroid_irq.sv:31 /IRQACK is still implemented, because sheet 3 decodes it.
rtl/main/blstroid_irq.sv:75 sheet 6, 4K LS174B pin 2 (latched VD15)
rtl/main/blstroid_leta.sv:3 Atari LETA at 8A — the Whirly-Gig counters, FF9801 / FF9805.
rtl/main/blstroid_leta.sv:4 SP-316 sheet 4.
rtl/main/blstroid_leta.sv:11 ---- wiring, off sheet 4 ------------------------------------------------ 24 VCC 12 GND
rtl/main/blstroid_leta.sv:40 The decode here follows the Atari System 2 core's, which is calibrated against a game whose service mode counts encoder pulses (720's 72-tooth disc = 144 counts/rev, i.e. 2x decoding): * the pin pair is treated as quadrature, CLK = phase A,
rtl/main/blstroid_main.sv:3 Blasteroids main board — SP-316 sheets 2, 3, 4, 5 and 12 as one block.
rtl/main/blstroid_main.sv:6 Structure from the Xybots MiSTer core's rtl/main/xybots_main_bus.sv (GPL-3.0, same author); the board-specific parts are read off SP-316.
rtl/main/blstroid_main.sv:20 * The video RAM, the colour RAM and the priority RAM live inside this module, because their CPU-side arbitration is sheet 2/5 logic.
rtl/main/blstroid_main.sv:24 `pfm2` is sheet 6's 4K LS174B pin 2 — bit 15 of the last playfield word fetched, latched at 4H — and it is what arms the row interrupt; see blstroid_irq.
rtl/main/blstroid_main.sv:47 ---- the /RESET net ----------------------------------------------------- The watchdog's /RESET drives the 68000's RESET+HALT pins (one net) and, leaving sheet 2 for sheet 3 only, the EEPROM unlock flip-flop's /CLR and the 14B LS08 that gat
rtl/main/blstroid_main.sv:79 sheet 6, 4K LS174B pin 2 (latched VD15)
rtl/main/blstroid_main.sv:160 Decode (sheet 3)
rtl/main/blstroid_main.sv:182 /SLAPSTIK is decoded because sheet 3 draws it and reaches nothing (the 2A socket is empty); FF9000 is an unused LS139 output.
rtl/main/blstroid_main.sv:281 Sheet 12: XX0P PPPC CCC0 = 256 motion-object entries (16 palettes x 16) at FFA000-FFA1FE, XX10 PPPC CCC0 = 128 playfield entries (8 x 16) at FFA200-FFA2FE, and FFA300-FFA3FE is addressable RAM nothing uses.
rtl/main/blstroid_main.sv:283 The colour RAM is arbitrated by the 14C F74 pair on sheet 10 and does not gate /DTACK: it takes the normal one-/7M-edge acknowledgement.
rtl/main/blstroid_main.sv:298 Priority RAM — 256 x 1, write only (sheet 10, 17E 27LS00A)
rtl/main/blstroid_main.sv:300 Sheet 12: FF8800-FF89FE, address `H PPP MMMM` = BA8..BA1 (H = playfield pen bit 3, P = playfield palette, M = motion-object palette), data D0, 1 = motion object on top.
rtl/main/blstroid_main.sv:338 Interrupts (sheet 2)
rtl/main/blstroid_main.sv:439 DTACK (12C LS163A + 11D LS74 pair + 16A LS260)
rtl/main/blstroid_watchdog.sv:3 Blasteroids watchdog — SP-316 sheet 2 (14D LS00, 1B LS90, Q4 2N3904).
rtl/main/blstroid_watchdog.sv:53 power-on reset, active high (sheet 2, 8C LS14)
rtl/main/blstroid_whirly.sv:3 Blasteroids Whirly-Gig encoder — a MiSTer spinner, paddle, mouse or d-pad turned into the CLK+DIR pin pair the LETA at 8A actually sees.
rtl/main/blstroid_whirly.sv:11 ---- what this stands in for ------------------------------------------- SP-316 sheet 13: LET-5/6 = P1-CLK / P1-DIR, LET-7/8 = P2-CLK / P2-DIR, each with a 3.3 K pull-down, a 0.01 uF cap and a 1 K series resistor into the LETA (sheet 4).
rtl/mem/blstroid_prog_rom.sv:12 ---- the four sockets ---------------------------------------------------- SP-316 sheet 12 labels the region "256K BYTES PROGRAM ROM": four 27512s in two even/odd pairs,
rtl/mem/blstroid_prog_rom.sv:21 Sheet 12 reserves 0x038000-0x03FFFF as "32K BYTES SLAPSTIC PROGRAM ROM SPACE", but no slapstic is fitted on a Blasteroids board and MAME's driver has none either, so this is a plain ROM.
rtl/mem/blstroid_rom_loader.sv:26 ---- the sprite region is TWO 512 KB halves ------------------------------ `sprites` is 1 MB: bytes 0x00000-0x7FFFF are the board's M row MO stamp ROMs (sheet 8) and 0x80000-0xFFFFF the N row (sheet 7).
rtl/video/blstroid_cram.sv:3 Blasteroids — SP-316 sheet 10: the PF/MO decision register (14C F74), the two colour-address drivers (17D F374 for the motion object, 16D F374A for the playfield), the CRA8 multiplexer, the 512 x 16 colour RAM (15/16B + 15/16C) with its 680
rtl/video/blstroid_cram.sv:21 which is sheet 12's `XX0P PPPC CCC0` (MO) and `XX10 PPPC CCC0` (PF).
rtl/video/blstroid_cram.sv:157 The colour word is xRGB 5:5:5 (sheet 12; MAME's xRGB_555):
rtl/video/blstroid_dac.sv:3 Blasteroids video DACs — SP-316 sheet 11: three identical packaged R/2R ladders (RN3 red, RN2 green, RN1 blue) driven from the HC273 output registers, plus the LS260 + 15A U06 code-0 pedestal sink.
rtl/video/blstroid_dac.sv:22 ---- the one non-linearity, and why it is not emulated ------------------- A 74LS260 5-input NOR per channel detects "all five bits zero" and drives a 15A U06 open-collector inverter that sinks the ladder node through 1 K, cancelling the pu
rtl/video/blstroid_mo.sv:3 Blasteroids — the motion-object engine: SP-316 sheets 7, 8 and 9 tied together.
rtl/video/blstroid_mo.sv:11 This module carries three of the four blocks that are one pipeline on the board — the fourth, the LINK WALK (13E LS74 + 7D LS273A + 7E LS374, sheet 5), lives in `blstroid_vram.sv` with the address multiplexers it drives:
rtl/video/blstroid_mo.sv:15 VMATCH 8K the vertical match / size compare and the stamp ROM address (sheet 7, Atari 137552-001) the ROM read sixteen 27512s (sheets 7 + 8) as ONE burst-8-byte read through the blstroid_gfx_mem MO client SOS-1 10K
rtl/video/blstroid_mo.sv:21 `blstroid_mo_linebuf` (sheet 9) is instantiated at the bottom.
rtl/video/blstroid_mo.sv:51 Link 56 (the 57th) is fetched over 448..455 and drawn over 454..461, i.e. counts 454, 455 of this line and 0..5 of the next — finishing EXACTLY at the 5->6 boundary where `1VD6H` (4E LS174C, clocked by 4HD2H) flips the buffers over.
rtl/video/blstroid_mo.sv:142 ---- SOS-2 3F (sheet 4), via blstroid_sos2_sync ----
rtl/video/blstroid_mo.sv:148 4E LS174C Q10 — 1V retimed on 4HD2H
rtl/video/blstroid_mo.sv:369 The two line buffers (sheet 9)
rtl/video/blstroid_mo.sv:371 The F163 chains on sheet 9 are clocked at 14M with a synchronous /LD, so a strobe two 14M periods wide would load the counter twice — and the second load would land on the 16th pixel of the object being drawn, writing it at the next object'
rtl/video/blstroid_mo_linebuf.sv:3 Blasteroids — SP-316 sheet 9: the two motion-object line buffers (14K and 14F, 2K x 8 35 ns), their F163 address counter chains (14L/15L/13L and 14J/15J/13J), the transparency write gate and the read-and-clear cycle.
rtl/video/blstroid_mo_linebuf.sv:18 | free-runs at 14M = the | X by /MOHLD1 = the WRITE | DISPLAY address | address pixel bus D3:0 | undriven -> R65/66/69/70 | MOPIX3:0 from SOS-1 | pull-ups -> 0xF | /OE | enabled while 14M is high | dis
rtl/video/blstroid_mo_linebuf.sv:66 The /OE and pixel-bus selection uses 1VD6H, which is 1V retimed by 4E LS174C on 4HD2H — it flips at the h%8 5->6 boundary, exactly where the 57th link's sixteen pixels finish.
rtl/video/blstroid_mo_linebuf.sv:87 ---- SOS-2 strobes (sheet 4 pins 26/27) and the retimed 1V ----
rtl/video/blstroid_mo_linebuf.sv:91 4E LS174C Q10
rtl/video/blstroid_pf.sv:3 Blasteroids — SP-316 sheet 6: the playfield picture latches (4K LS174B, 4L LS374C, 6F F174A), the four PF graphics ROMs (1L, 1M, 3L, 3M), the 2J/1J LS194A shifters and the 4E LS174C re-timing latch.
rtl/video/blstroid_pf.sv:8 Structurally derived from the Xybots MiSTer core's rtl/video/xybots_pf.sv (GPL-3.0, same author); every number below is re-derived for Blasteroids from sheet 6.
rtl/video/blstroid_pf.sv:29 Sheet 5's slot schedule gives the playfield exactly one video-RAM slot per 8 counts, at `H[2:0]` = 3, and sheet 6 latches the word on the `4H` rising edge at the 3->4 boundary.
rtl/video/blstroid_pf.sv:34 4K/4L/6F latch it on the board; here the 13-bit code goes straight out as ONE `blstroid_gfx_mem` PF request for the whole 4-byte stamp row, and the previously completed row moves down the prefetch pipe (`row_new` -> `row_mid`).
rtl/video/blstroid_pf.sv:66 The 2J / 1J LS194A shifters and the horizontal doubling
rtl/video/blstroid_pf.sv:79 The board recovers the same alignment downstream (sheet 10's 14C F74 on `/14M` and the two F374s on `14M`); doing it here keeps `pf_pix` exactly on the `hpos` grid the compositor uses:
rtl/video/blstroid_pf.sv:90 `4E LS174C` (CK = `4HD2H`, rising at the 5->6 boundary) re-times three unrelated signals two counts after the map latch: D3 = PFM2 -> Q2 = PFPAL2 D13 = PMLNK8 -> Q12 = MOLNK8
rtl/video/blstroid_pf.sv:94 D6 = PFM0 -> Q7 = PFPAL0 `MOLNK8` goes back to sheet 5 as `VRAM10` in the four motion-object slots (`blstroid_vram.molnk8`) and `1VD6H` is the sheet-9 line-buffer ping-pong select, so this module exports both even though neither is a pixel.
rtl/video/blstroid_pf.sv:98 `PFM2:0` themselves are the 4K LS174B latch, modelled in `blstroid_vram` so that the IRQ1 path does not have to depend on the playfield module.
rtl/video/blstroid_pf.sv:120 4K LS174B Q2/Q5/Q7 = PFM2, PFM1, PFM0
rtl/video/blstroid_pf.sv:133 ---- 4E LS174C, the two non-playfield signals it re-times ------------
rtl/video/blstroid_pf.sv:135 Q10 -> sheet 9 line-buffer ping-pong
rtl/video/blstroid_pf.sv:146 4HD2H rising — 4E LS174C
rtl/video/blstroid_pf.sv:152 4E LS174C — PFPAL2:0, MOLNK8, 1VD6H (CK = 4HD2H)
rtl/video/blstroid_pf.sv:212 4K / 4L / 6F latch the new map word; the fetch starts here
rtl/video/blstroid_pf.sv:227 2J / 1J LS194A — parallel load, then one shift, per ROM byte
rtl/video/blstroid_prio.sv:3 Blasteroids — SP-316 sheet 10: the priority RAM 17E (27LS00A, 256 x 1), its two inverting 74F158 address multiplexers (15E, 16E) and the /CS3 gate that makes a transparent motion-object pixel mean "playfield".
rtl/video/blstroid_prio.sv:8 Module shape from the Xybots MiSTer core's rtl/video/xybots_prio.sv (GPL-3.0, same author); Blasteroids' network is a one-bit lookup rather than Xybots' 74S85 comparator, so nothing else is shared.
rtl/video/blstroid_prio.sv:13 ---- the address ------------------------------------------------------- 15E/16E F158 are inverting 2:1 muxes, but they invert the CPU write address and the video lookup address identically, so the inversion cancels and software sees sheet
rtl/video/blstroid_prio.sv:33 i.e. a stored 1 means "MO on top", which is what sheet 12 says and what MAME's `if (mo[x] != 0xffff)` guard does.
rtl/video/blstroid_prio.sv:65 sheet 12's address uses PFPIX3
rtl/video/blstroid_sos2_sync.sv:3 Blasteroids — SP-316 sheet 4: the SOS-2 sync generator (3F, Atari 137550-001) and every discrete gate on that sheet that shapes its outputs into the nets the other video sheets consume.
rtl/video/blstroid_sos2_sync.sv:13 ---- what the sheet gives, and what it does not ------------------------- 3F is a 40-pin Atari custom and SP-316 draws only its pinout, so the counters are derived rather than read:
rtl/video/blstroid_sos2_sync.sv:19 It cannot be clocked at 14M (912 does not fit in 9 bits), so it runs at 7M, and the only value in 257..512 that yields a standard 15.7 kHz line is 456: 7 159 090 / 456 = 15 700.6 Hz, 63.709 us.
rtl/video/blstroid_sos2_sync.sv:93 263 is what the Atari System 1 / Xybots sync-generator family produces from its dumped sync PROM (240 visible + 22 blanked + one extra line made by /VRES loading 0xFF), and the SOS-2 exposes the same /VRES net.
rtl/video/blstroid_sos2_sync.sv:96 The SOS-2 counts V internally and the schematics do not settle it, so this stays a build-time parameter: 59.9227 Hz at 262, 59.6949 Hz at 263.
rtl/video/blstroid_sos2_sync.sv:165 pin 25 -> 13E LS74 /CLR, 7D LS273A /CLR
rtl/video/blstroid_sos2_sync.sv:169 ---- the video-RAM slot schedule (sheet 5) --------------------------
rtl/video/blstroid_sos2_sync.sv:191 ---- the two HBLANK edges, one clk_sys cycle wide, aligned to ce_7m -- `hblank_rise` is the edge sheet 2 uses twice: it clocks 13C LS74 (the row-programmable IRQ1) and 11D LS74 upper (halt-until-HBLANK).
rtl/video/blstroid_sos2_sync.sv:280 That is unobservable: every one of those lines is inside VBLANK, the playfield row address only matters while `vde`, and the IRQ1 gate is qualified by /VBLANK (sheet 2).
rtl/video/blstroid_sos2_sync.sv:357 SELCPU = ~(/4H & 1H) = 4H | /1H (14D LS00, sheet 5); RAMFREE = ~((1H & /4H) | /2H) = 2H & SELCPU (11J LS02 + 14B LS08, sheet 2):
rtl/video/blstroid_testpat.sv:40 The blanking split below (front porch, sync width, back porch, and the VSYNC line) is this module's own and is not taken from the SP-316 sheets: it is Xybots' measured SP-313 split (456 total: 32 front, 32 sync, 56 back) scaled x2 to this l
rtl/video/blstroid_video.sv:3 Blasteroids — the whole video board (SP-316 sheets 4 to 11) as one module: the SOS-2 sync generator, the video/work RAM and its 8-count slot schedule, the playfield pipeline, the motion-object engine, the priority RAM, the colour RAM and th
rtl/video/blstroid_video.sv:56 Sheet 2 clocks the IRQ1 latch on the rising edge of HBLANK and samples `PFM2`, and `PFM2` is the 4K LS174B's latched VD15 of the last playfield word fetched — a value that changes once every 8 H counts all the way across the line, because t
rtl/video/blstroid_video.sv:60 Sheet 12 puts the row-interrupt flag in column 40 only.
rtl/video/blstroid_video.sv:89 /MOL loads the line-buffer write counter from VD15:6 while MOHPOS is on the video bus, and sheet 5 puts MOHPOS at H[2:0] = 5.
rtl/video/blstroid_video.sv:186 4K LS174B Q2 — the IRQ1 row condition
rtl/video/blstroid_video.sv:226 SOS-2 at 3F — sheet 4
rtl/video/blstroid_video.sv:240 /MOL must land on the count that carries MOHPOS (sheet 5, H[2:0] = 5) — see the header.
rtl/video/blstroid_video.sv:276 Video / work RAM — sheet 5
rtl/video/blstroid_video.sv:298 ---- 4K LS174B (sheet 6): PFM2:0 = the map word's D15:13, on 4H ------- The latch itself lives in blstroid_vram, so the IRQ1 path does not depend on whether the playfield module is drawing; both consumers read it here.
rtl/video/blstroid_video.sv:304 Playfield — sheet 6
rtl/video/blstroid_video.sv:334 Priority RAM — sheet 10
rtl/video/blstroid_video.sv:348 Colour RAM and the output registers — sheet 10
rtl/video/blstroid_video.sv:368 The DACs — sheet 11
rtl/video/blstroid_vram.sv:3 Blasteroids — SP-316 sheet 5: the 16 KB video / work RAM (5L, 6/7L), its address multiplexers, the eight-count slot arbiter, the CPU data path and the motion-object link registers.
rtl/video/blstroid_vram.sv:8 Structurally derived from the Xybots MiSTer core's video-RAM arbiter (GPL-3.0, same author), with every gate re-derived from sheet 5.
rtl/video/blstroid_vram.sv:12 The crux of sheet 5: /OE is tied low
rtl/video/blstroid_vram.sv:17 This module reproduces that: `vd` is the registered read of whatever address the multiplexers select, valid from the second clk_sys cycle of each `1H` count and therefore stable at that count's `ce_7m` — the edge on which sheet 6's 4K/4L/6F
rtl/video/blstroid_vram.sv:58 cpu_we_hi LEVEL = ~/WH -> writes vd[15:8] (6/7L, the high byte lane) cpu_we_lo LEVEL = ~/WL -> writes vd[7:0] (5L, the low byte lane) A write reaches the RAM only when RAMFREE & cpu_sel & the lane & 7M is high (sheet 2: /VWRH = /VM
rtl/video/blstroid_vram.sv:93 The 4K LS174B / 4L LS374C / 6F F174A map-word latches and the 4E LS174C re-timing latch (PFPAL2:0, MOLNK8, 1VD6H) are on sheet 6 and live in `blstroid_pf.sv`, with the rest of the playfield pipeline they belong to.
rtl/video/blstroid_vram.sv:96 This module therefore EXPORTS `pmlnk8` (13E LS74 Q, sheet 5) and IMPORTS `molnk8` (4E LS174C Q12, sheet 6) — exactly the two wires that cross between the sheets.
rtl/video/blstroid_vram.sv:117 ---- from blstroid_pf (sheet 6, 4E LS174C Q12) ----------------------
rtl/video/blstroid_vram.sv:134 ---- 4K LS174B, the playfield map word's palette field --------------- Q2, Q5, Q7 = PFM2, PFM1, PFM0 = the latched VD15, VD14, VD13, captured on the `4H` rising edge once per stamp column.
rtl/video/blstroid_vram.sv:136 `pfm[2]` (PFM2) is BOTH the playfield palette MSB and the row-programmable-interrupt condition that sheet 2's 11C LS11 / 1D LS20 / 13C LS74 chain turns into IRQ1, which is why it leaves this module rather than `blstroid_pf`: the interrupt p
rtl/video/blstroid_vram.sv:144 ---- motion-object link walk (13E LS74 / 7D LS273A / 7E LS374) ------
rtl/video/blstroid_vram.sv:145 13E LS74 Q5 -> sheet 6 4E LS174C D13
rtl/video/blstroid_vram.sv:161 The motion-object link registers — 13E LS74, 7D LS273A, 7E LS374
rtl/video/blstroid_vram.sv:172 7D LS273A — the link just latched off VD
rtl/video/blstroid_vram.sv:192 4K LS174B — CK 9 = `4H`, /C 1 = PR2.
rtl/video/blstroid_vram.sv:208 Address multiplexers — 5F LS253, 4F LS253A, 6E/5E LS257, 11C LS11
rtl/video/blstroid_vram.sv:234 Write strobes — sheet 2, 11E LS32 chain
rtl/video/blstroid_vram.sv:296 `v[2:0]` is the line inside the stamp — sheet 6's PF ROM address, formed in blstroid_pf, not part of the map address.
README.md:7 The core reconstructs the original PCB set — the 68000 game board plus an Atari JSA I sound board — from Atari's SP-316 schematic package, with MAME used as a f
README.md:162 | Protection | None — SP-316 sheet 3 notes *"The SLAPSTIC chip is not installed"* |
README.md:221 It applies where the SP-316 schematics document something MAME's model does not.
README.md:226 | Row-programmable interrupt (IRQ1) | Stubbed out; MAME takes zero level-1 interrupts | Real and fully wired: sheet 6 latches VD15 as PFM2 and sheet 2's LS74 is
README.md:228 | Video DAC | Linear `xRGB_555` | The three R/2R ladders on sheet 11, including their code-0 pedestal |
README.md:231 | Watchdog | Generic timer with default timing | Sheet 2's LS90: reset after 8 frames without a write, held for two frames, parked at 9 on power-up |
README.md:254 **Which YM2151 channel is left.** SP-316 does not label them, so the core follows MAME.
README.md:302 Thanks to the MAME team, whose `blstroid.cpp`, `atarijsa` and `atarimo` code served as the functional oracle throughout, and to whoever preserved the Atari SP-3

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/video/blstroid_mo_linebuf.sv:57 Between strobes both free-run at 14M, which is why one object's sixteen pixels land at X, X+1 ... — also in MAME: 14M atari/blstroid.cpp:451

Notes where it differs from MAME — 5

rtl/main/blstroid_irq.sv:10 ---- IRQ1, the row-programmable playfield interrupt -------------------- Real hardware, fully wired, and the one thing MAME stubs out:
README.md:10 Where a schematic and MAME disagree, the schematic wins and the disagreement is recorded — see [Where this core differs from MAME](#where-this-core-differs-from
README.md:200 All three interrupt levels are taken, including the row-programmable playfield interrupt that MAME does not implement, and the sound mailbox closes between the
README.md:218 Where this core differs from MAME
README.md:221 It applies where the SP-316 schematics document something MAME's model does not.

Cites MAME source — 58

Arcade-Blasteroids.sv:15 Blasteroids runs on a horizontal monitor (MAME ROT0), so there is no rotation: the raster goes straight through arcade_video.
Arcade-Blasteroids.sv:120 MAME's INPUT_PORTS_START(blstroid) has only the two dial ports and the two button/status words, and every operator setting lives in the X2804 EEPROM at 0xFFB000, changed from the game's own self test.
Arcade-Blasteroids.sv:150 TM-316's Switch Test lists exactly four inputs per player (Spare, Xform, Thrust, Fire), the control-panel figure and the CTRA connector carry three buttons per player, and MAME's blstroid.cpp defines no IPT_START1/2.
rtl/blstroid_core.sv:104 The SOS-2's vertical total: 262 lines, MAME's figure.
rtl/blstroid_core.sv:111 1 = MAME's xRGB_555 transfer, 0 = the sheet-11 R/2R ladder value.
rtl/blstroid_core.sv:153 The operator manual lists exactly four inputs per player in the Switch Test (Spare, Xform, Thrust, Fire), the control-panel figure and the CTRA connector carry three buttons per player, and MAME defines no IPT_START1/2 either.
rtl/main/blstroid_addr_decode.sv:8 The two descriptions agree over the whole 24-bit space: the mirrors MAME documents are simply the address bits the drawn decoders never look at.
rtl/main/blstroid_addr_decode.sv:47 ---- what the mirrors are ------------------------------------------------ A22-A15 reach no decoder at all, so the whole FF8000-FFFFFF register/RAM map repeats every 32 KB over 800000-FFFFFF (MAME: `global_mask(0x83ffff)` plus per-entry `.m
rtl/main/blstroid_addr_decode.sv:50 Inside FF8000-FF8FFF only A11-A9 are decoded, so each write strobe answers over a whole 512-byte page (MAME: `.mirror(0x0381fe)`) — except /PRIRAM, whose A8-A1 are the priority RAM's own address.
rtl/main/blstroid_dtack.sv:64 MAME spins the CPU instead, which is observationally equivalent but is not what the board does.
rtl/main/blstroid_eeprom_2804.sv:18 The socket is wired for a 2816 (2 K x 8) but the fitted X2804A is 512 x 8 (A0..A8 only), so the device repeats four times over FFB001-FFBFFF — which is what sheet 12's "a = ADDRESS BITS ON 2816 ONLY" note means and what MAME's `.mirror(0x03
rtl/main/blstroid_eeprom_2804.sv:36 * the first following low-byte write clocks D = 0 on the /WL rising edge, so the part re-locks after exactly one write — MAME's `lock_after_write(true)`.
rtl/main/blstroid_eeprom_2804.sv:56 ---- programming time --------------------------------------------------- The X2804A data sheet gives a self-timed byte write of typically 5 ms and at most 10 ms with the I/O pins high-Z throughout; MAME models no write time at all.
rtl/main/blstroid_eeprom_2804.sv:207 There are no pull-ups on BD0-BD7, so the modelled float value is the 0xFF an unmapped MAME read gives.
rtl/main/blstroid_inputs.sv:35 MAME maps them as BUTTON4 and the self test displays them, so they are exposed here.
rtl/main/blstroid_leta.sv:38 ---- how the CLK/DIR pair is decoded ------------------------------------ No LETA data sheet is public and MAME has no LETA device at all (it reads these addresses as plain IPT_DIAL ports, sensitivity 60).
rtl/main/blstroid_main.sv:55 ---- reads of write-only strobes --------------------------------------- Nothing drives the board bus for them, so they read 0xFFFF, which is also MAME's `unmap_value_high()`.
rtl/main/blstroid_main.sv:304 A CPU read returns the undriven bus (0xFFFF); MAME keeps a readable shadow instead, so the two disagree there.
rtl/main/blstroid_watchdog.sv:36 MAME instantiates `WATCHDOG_TIMER(config, "watchdog")` with default timing: neither the 8-frame period, nor the 2-frame pulse, nor the park-at-9 power-up is modelled there.
rtl/main/blstroid_whirly.sv:71 d-pad Left/Right stepped at a fixed rate, the same idea as MAME's PORT_KEYDELTA, so a gamepad or keyboard can play at all.
rtl/main/blstroid_whirly.sv:79 MAME uses PORT_SENSITIVITY(60) PORT_KEYDELTA(10).
rtl/mem/blstroid_prog_rom.sv:21 Sheet 12 reserves 0x038000-0x03FFFF as "32K BYTES SLAPSTIC PROGRAM ROM SPACE", but no slapstic is fitted on a Blasteroids board and MAME's driver has none either, so this is a plain ROM.
rtl/mem/blstroid_rom_loader.sv:11 ---- the index-0 stream map ---------------------------------------------- The MRA concatenates MAME's ROM regions in this order, and the offsets below must match it byte for byte:
rtl/mem/blstroid_rom_loader.sv:15 stream base size MAME region destination
rtl/mem/blstroid_rom_loader.sv:36 ---- byte order (the one thing that must not be guessed) ----------------- maincpu is emitted as BIG-ENDIAN INTERLEAVED WORDS — the even-offset MAME ROM (6C / 4C) is `map="01"`, the FIRST byte of each output word, i.e. D15:8.
rtl/mem/blstroid_sdram_loader.sv:16 tiles (MAME gfx_8x8x4_packed_msb): 32 bytes per 8x8 stamp, byte = code[12:0]*32 + row[2:0]*4 + (A1,A0); one PF stamp row = 4 CONSECUTIVE bytes = 2 words = ONE burst-2.
rtl/mem/blstroid_sdram_loader.sv:20 A Blasteroids MO stamp is 16 x 8 and its pixels come alternately from the two 512 KB halves of the `sprites` region — the board's M row and N row banks of MO stamp ROMs (sheets 8 and 7), addressed with the SAME within-half address (MAME `mo
rtl/mem/blstroid_sdram_loader.sv:25 sprites (MAME molayout): 32 bytes per 16x8 stamp PER HALF, within-half byte = code[13:0]*32 + row[2:0]*4 + (A1,A0); one MO stamp row = 4 bytes from M AND 4 bytes from N, both at the SAME within-half offset -> 8 bytes, 4 words.
rtl/video/blstroid_cram.sv:23 MAME's `GFXDECODE_SCALE("tiles", 0, ..., 256, 16, 2, 1)` uses the same base 256 with 8 of the 16 groups.
rtl/video/blstroid_cram.sv:55 MAME behaves the same way.
rtl/video/blstroid_cram.sv:157 The colour word is xRGB 5:5:5 (sheet 12; MAME's xRGB_555):
rtl/video/blstroid_dac.sv:30 ---- the two transfers --------------------------------------------------- DAC_MAME_COMPAT = 1 (default) MAME's `pal5bit(x) = (x << 3) | (x >> 2)` — bit replication, what `xRGB_555` does.
rtl/video/blstroid_dac.sv:36 The default is the MAME curve so that a frame captured from this core can be compared bit for bit with one captured from MAME; the ladder's own answer is 0.
rtl/video/blstroid_mo.sv:82 That is MAME's `molayout` x-offset list {RGN_FRAC(1,2)+0, RGN_FRAC(1,2)+4, 0, 4, ...} read back out.
rtl/video/blstroid_mo.sv:109 and the first VISIBLE pixel is (h, pix) = (HB_END, 0), so making the line-buffer address equal the screen column — which is MAME's `xpos` exactly, atarimo.cpp folding xpos >= 640 by -1024 where the 10-bit counter wraps — needs
rtl/video/blstroid_mo.sv:123 1 = walk the full 14-bit code when a tall object crosses a 1024-stamp boundary (MAME's `code++`).
rtl/video/blstroid_mo.sv:226 which is atarimo.cpp's `ypos = -(Y + 8*height)` covering 8*height lines, re-derived: the object covers D iff U >= 512 - 8*height.
rtl/video/blstroid_mo.sv:238 MAME draws the stamp rows bottom-up and flips inside the stamp; the shipping ROM never sets the bit, so this path is unexercised by the game and is here only because the sheet wires the pin.
rtl/video/blstroid_mo.sv:247 MO_CODE_CARRY = 1 restores MAME's full 14-bit add for comparison.
rtl/video/blstroid_mo_linebuf.sv:38 So an untouched location reads pen 0, and pen 0 is transparent — MAME's "transparent pen index = 0" exactly.
rtl/video/blstroid_mo_linebuf.sv:61 The counters are TEN bits and the RAMs' A10 is grounded, so a column starting near 1023 wraps into the left edge — which is exactly atarimo.cpp's `xpos &= 0x3ff` followed by its `xpos >= width ?
rtl/video/blstroid_pf.sv:58 chip = {PFPIC12, PFPIC11} -> MAME `tiles` offset * 0x10000 so the linear byte address is `code * 32 + line * 4 + byte_in_row` and the `blstroid_gfx_mem` request address (bits 17:2 of it) is simply `{code[12:0], line[2:0]}` — no multiply
rtl/video/blstroid_prio.sv:23 which is byte-for-byte MAME's `priaddr = ((pf & 8) << 4) | (pf & 0x70) | ((mo & 0xf0) >> 4)`.
rtl/video/blstroid_prio.sv:33 i.e. a stored 1 means "MO on top", which is what sheet 12 says and what MAME's `if (mo[x] != 0xffff)` guard does.
rtl/video/blstroid_prio.sv:41 The sheet has no CPU read path to 17E: the 68000's `clr.w` over this region is a read-modify-write whose read only has to terminate, and MAME maps the region write-only as well.
rtl/video/blstroid_sos2_sync.sv:22 That is MAME's 456*2, arrived at independently.
rtl/video/blstroid_sos2_sync.sv:27 * The visible window is 40 stamps x 16 px = 640 = 320 counts, and 30 stamp rows x 8 lines = 240 — MAME's 640 x 240 exactly.
rtl/video/blstroid_sos2_sync.sv:91 ---- vertical ------------------------------------------------------- 262 is MAME's figure, whose own comment says it comes from published specs rather than measurement.
README.md:7 The core reconstructs the original PCB set — the 68000 game board plus an Atari JSA I sound board — from Atari's SP-316 schematic package, with MAME used as a f
README.md:20 Five MAME sets run on identical RTL — they differ only in the main CPU ROMs.
README.md:43 | ROMs | Supplied by you from a MAME archive; none are included here |
README.md:82 The operator manual lists exactly four switches per player, and the MAME driver defines no Start input.
README.md:220 MAME 0.288 was this project's functional oracle and every gate above measures the core *against* it, so this is a narrow claim.
README.md:224 | Behaviour | MAME | This core |
README.md:226 | Row-programmable interrupt (IRQ1) | Stubbed out; MAME takes zero level-1 interrupts | Real and fully wired: sheet 6 latches VD15 as PFM2 and sheet 2's LS74 is
README.md:247 The core uses 262 (MAME's published figure) as a compile-time parameter; rebuild with `V_TOTAL = 263` to try the other.
README.md:254 **Which YM2151 channel is left.** SP-316 does not label them, so the core follows MAME.
README.md:302 Thanks to the MAME team, whose `blstroid.cpp`, `atarijsa` and `atarimo` code served as the functional oracle throughout, and to whoever preserved the Atari SP-3

Says it matches, follows or was checked against MAME — 2

README.md:204 **Pixel-exact compositor gate** — MAME is instrumented to capture complete video state at chosen frames; that state is replayed through the real core RTL and th
README.md:233 On every captured frame they are observationally identical to MAME, because the per-band chains the game installs are short and no captured scanline exceeds 57

Keeps a MAME approximation — 1

rtl/video/blstroid_mo.sv:130 /VRES's phase is inside the SOS-2 and cannot be probed, but this is the only reading under which line 0 of the picture is correct, and it is what MAME's `ypos` arithmetic assumes.

Shares text with the MAME driver without saying so — 3

rtl/main/blstroid_whirly.sv:22 counting up (0,0) -> (0,1) -> (1,1) -> (1,0) -> (0,0) — shares text with atari/atarimo.cpp:14
rtl/main/blstroid_whirly.sv:80 uses PORT_SENSITIVITY(60) PORT_KEYDELTA(10). — shares text with atari/blstroid.cpp:313
rtl/video/blstroid_mo.sv:83 MAME's `molayout` x-offset list {RGN_FRAC(1,2)+0, RGN_FRAC(1,2)+4, 0, 4, — shares text with atari/blstroid.cpp:357

Blockade#
Blasto, Blockade, CoMotion, Hustle
MiSTer-devel/Arcade-Blockade_MiSTer @ dba47dc9
MAME compared: sega/blockade.cpp
Read: 9 HDL files, 2,628 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

24%

Statements: 1 toward MAME

Cites MAME source — 1

rtl/blockade.v:326 This is an analog noise generator which I can't replicate, so we have wave playback of a MAME-source sample

BloodBros#
Blood Bros.
MiSTer-devel/Arcade-BloodBros_MiSTer @ 2abeab3f
MAME compared: seibu/bloodbro.cpp + 4 related file(s)
Read: 19 HDL files, 5,778 lines (Quartus project)

MiSTer official

Mostly MAME

medium

70%

Statements: 2 toward hardware, 50 toward MAME, 1 not counted

Cites hardware documentation that MAME's driver does not — 2

rtl/BloodBros/BloodBros_main_top.sv:31 Memory map SD Gundam (da MAME dcon.cpp + SD Gundam override): $000000-$07FFFF ROM 68K (512KB) $080000-$08BFFF Main RAM (48KB) $08C000-$08C7FF BG tile RAM (2KB) $08C800-$08CFFF FG tile RAM (2KB) $08D000-$08D7FF MG tile RAM
rtl/BloodBros/BloodBros_maincpu_map.sv:29 Memory map SD Gundam (da MAME dcon.cpp + sdgndmps_map override): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $080000-$08BFFF Main RAM (48KB) → BRAM $08C000-$08C7FF BG tile RAM → BRAM dual-port $08C800-$

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/BloodBros/BloodBros_video_timing.sv:26 PCB measurement Blood Bros: VSync 59.4094 Hz, HSync 15.6246 kHz, master XTAL 20 MHz. — also in MAME: 59.4094 seibu/bloodbro.cpp:970, 15.6246 seibu/bloodbro.cpp:971

Cites MAME source — 44

BloodBros.sv:215 I valori di calibrazione pixel-perfect MAME sono hardcodati DENTRO i rispettivi renderer / cablature: - BG X+0 Y+16 : .yoff(10'sd16) sotto - MG X+0 Y+0 : .yoff(10'sd0) - FG X+0 Y+16 : .yoff(10'sd16) - SPR X+0 Y-16 : sprite rende
BloodBros.sv:293 --- Joystick to SD Gundam input mapping --- MAME P1_P2 port ($E0002): active low.
BloodBros.sv:296 MiSTer joy bits: joy[0]=R, joy[1]=L, joy[2]=D, joy[3]=U, joy[4]=A, joy[5]=B. MAME bloodbro IN0: bit0..3 = U/D/L/R, bit4=Btn1 Fire, bit5=Btn2 Roll, bit6=Btn3 Dynamite (active low)
BloodBros.sv:597 ── Flip screen (CRTC reg 0x1A bit 0) ─────────────────────────────────────── MAME: BIT(reg_1a, 0) → flip_screen.
BloodBros.sv:639 Blood Bros Text: no scroll (MAME bloodbro.cpp non chiama set_scroll su tx_tilemap)
BloodBros.sv:673 Blood Bros CRTC scroll passthrough — nessun offset (MAME bloodbro.cpp:427-430) Blood Bros usa scroll_ram[0/1] per BG e scroll_ram[2/3] per FG (MAME bloodbro.cpp:427-430).
BloodBros.sv:696 Blood Bros: tilemap 32x16 (MAME bloodbro.cpp:292)
BloodBros.sv:731 Blood Bros FG: palette base 0x500 (MAME bloodbro.cpp:808 = 0x50*16) MAME bloodbro fg_tile_info: tile = (vram & 0xFFF) + 0x1000 hardcoded.
BloodBros.sv:738 Blood Bros: tilemap 32x16 (MAME bloodbro.cpp:293)
BloodBros.sv:743 Blood Bros: bit 1 = FG (MAME bloodbro.cpp layer_en_w)
BloodBros.sv:790 MAME bloodbro.cpp:379-382 pri_cb: pri=0 → mask 0 (above all), pri=1 → mask 0x02.
BloodBros.sv:791 MAME draw order (riga 434-441): BG → FG → sprites → Text.
rtl/BloodBros/BloodBros_audio_z80.sv:25 Spec da MAME (reference/mame_seibu/seibusound.cpp + bloodbro.cpp): - Z80 @ 3.579545 MHz (XTAL 7.159090 / 2) - YM3812 (jtopl2) @ 3.579545 MHz - OKI M6295 (jt6295) @ 1.000 MHz (XTAL 12/12), PIN7=HIGH
rtl/BloodBros/BloodBros_audio_z80.sv:31 Main↔sub comm @ 0xA0000-0xA000D: standard MAME seibu_sound_device.
rtl/BloodBros/BloodBros_audio_z80.sv:315 ─── OKI M6295 (jt6295) — PIN7_HIGH (bloodbro.cpp:872) ──────────────────
rtl/BloodBros/BloodBros_main_top.sv:31 Memory map SD Gundam (da MAME dcon.cpp + SD Gundam override): $000000-$07FFFF ROM 68K (512KB) $080000-$08BFFF Main RAM (48KB) $08C000-$08C7FF BG tile RAM (2KB) $08C800-$08CFFF FG tile RAM (2KB) $08D000-$08D7FF MG tile RAM
rtl/BloodBros/BloodBros_main_top.sv:198 VBLANK IRQ4 — MAME dcon.cpp: m_maincpu->set_vblank_int(irq4_line_hold) Rising edge di vblank → assert IRQ4 pending; IACK CPU → clear.
rtl/BloodBros/BloodBros_main_top.sv:342 XOR 0x400 lato CPU per allineare BRAM[N] = MAME text_vram[N] (renderer parte da addr 0).
rtl/BloodBros/BloodBros_main_top.sv:350 Quindi MAME palette[N] sta in vram_addr = (N + 0x400) & 0x7FF.
rtl/BloodBros/BloodBros_main_top.sv:351 Per allineare BRAM[N] = MAME palette[N] applichiamo XOR 0x400 SOLO al lato CPU (a_addr).
rtl/BloodBros/BloodBros_main_top.sv:352 Il renderer passa pen_index MAME nativo (BG=0x400+, MG=0x500+, ecc) e la BRAM è già allineata.
rtl/BloodBros/BloodBros_main_top.sv:362 Sprite RAM CPU-side (write/read) — Blood Bros: 4KB = 2048 word (AW=11) MAME bloodbro.cpp:467 map(0x08b000, 0x08bfff).ram().share(m_spriteram) → 4KB.
rtl/BloodBros/BloodBros_maincpu_map.sv:29 Memory map SD Gundam (da MAME dcon.cpp + sdgndmps_map override): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $080000-$08BFFF Main RAM (48KB) → BRAM $08C000-$08C7FF BG tile RAM → BRAM dual-port $08C800-$
rtl/BloodBros/BloodBros_maincpu_map.sv:107 ─── Region detect (MAME bloodbro.cpp:465-483) ──────────────────────────
rtl/BloodBros/BloodBros_maincpu_map.sv:161 ─── GFX bank register ─────────────────────────────────────────────────── MAME dcon.cpp gfxbank_w: SOLO bit0 → m_gfx_bank_select = 0x1000 oppure 0.
rtl/BloodBros/BloodBros_palette.sv:25 MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_444, 2048); Address space CPU: 0x08E800..0x08F7FF (4 KB = 2048 word).
rtl/BloodBros/BloodBros_palette.sv:34 Espansione 5→8 bit con replica top-bits (standard MiSTer / MAME palette_device).
rtl/BloodBros/BloodBros_palette.sv:86 Blood Bros: xBGR_444 → RGB888 (MAME bloodbro.cpp:859 set_format xBGR_444) Layout: bit[11:8]=R, bit[7:4]=G, bit[3:0]=B. 4 bit per canale.
rtl/BloodBros/BloodBros_palette.sv:88 Replica 4→8 standard: {nibble, nibble} (MAME palette_device standard expansion)
rtl/BloodBros/BloodBros_seibu_crtc.sv:23 Seibu CRTC fedele a MAME (src/mame/seibu/seibu_crtc.cpp).
rtl/BloodBros/BloodBros_seibu_crtc.sv:117 MAME mappa: bit0=screen0(BG), bit1=screen2(MG), bit2=screen1(FG), bit3=screen3(Text) (vedi seibu_crtc.cpp commento "screen 0=BG, screen 1=FG, screen 2=MG, screen 3=Text") In SD Gundam dcon.cpp layer_en_w gira la maschera così: ~layer_en bit
rtl/BloodBros/BloodBros_seibu_crtc.sv:126 Il dispatcher MAME usa "if (BIT(~m_layer_en, n))" per saltare = layer disabilitato quando il bit è 1.
rtl/BloodBros/BloodBros_sprite_renderer.sv:26 Formato "alt" (vedi MAME sei021x_sei0220_spr.cpp).
rtl/BloodBros/BloodBros_sprite_renderer.sv:126 Decoded fields — Blood Bros ALT FORMAT (MAME sei021x_sei0220_spr.cpp:124-140) W0: bit 15 Disable (1=skip!) - INVERSO vs std (era enable)
rtl/BloodBros/BloodBros_sprite_renderer.sv:145 SEI0211 get_coordinate (MAME sei021x_sei0220_spr.h): coord &= 0x1ff; return (coord >= 0x180) ?
rtl/BloodBros/BloodBros_sprite_renderer.sv:178 Tile code finale Y-MAJOR (MAME draw_internal: ax=outer, ay=inner, code++): sub_index = ax*sizey + ay → cur_tile = code + eff_tile_x*sp_h + eff_tile_y
rtl/BloodBros/BloodBros_text_renderer.sv:25 Specifiche da MAME (src/mame/seibu/dcon.cpp):
rtl/BloodBros/BloodBros_tile_layer.sv:25 Differenze fra layer (da MAME dcon.cpp):
rtl/BloodBros/BloodBros_tile_layer.sv:58 BB FG hardcoded +0x1000 (MAME bloodbro fg_tile_info)
rtl/BloodBros/BloodBros_tile_layer.sv:176 Tile index con eventuale gfx_bank (MG ha bit 12 = 13-bit totali, BG/FG = 12 bit) + TILE_CODE_OFS hardcoded (BB FG aggiunge 0x1000 secondo MAME bloodbro fg_tile_info).
rtl/BloodBros/BloodBros_video_timing.sv:35 Active area da MAME (sdgndmps_map): visarea 0..40*8-1, 2*8..30*8-1 quindi 320×224, V offset = 16 (top blank).
rtl/BloodBros/BloodBros_video_timing.sv:72 ── Constants timing ───────────────────────────────────────────────────── Blood Bros: 256x224 active (MAME bloodbro.cpp:846-851 set_visarea 0..255, 16..239).
rtl/BloodBros/sdram_bridge.sv:296 FG layer: Blood Bros shares ROM with BG (MAME bloodbro:807-808)
README.md:18 YM3812 OPL2 FM (jtopl2) + OKI M6295 ADPCM (jt6295) with MAME-accurate mixer

Says it matches, follows or was checked against MAME — 2

BloodBros.sv:208 Shift fisso aggiunto per match MAME 1:1 (misurato HW 2026-05-14): BG X+0 Y+16 FG X+0 Y+16 SPR X+0 Y+0 TXT X-1 Y+16 L'OSD resta editabile ±32 attorno al valore corretto.
BloodBros.sv:302 Blood Bros SYSTEM port ($0E0004) IN1 — verified MAME bloodbro.cpp:688 bit0 = START1 (active LOW) bit4 = START2 (active LOW) bit12 = SERVICE1 (0x1000, active LOW) IPT_SERVICE1 altri = UNKNOWN/UNUSED → tied 1 Coin inputs NON sono

Says it was translated, ported or taken from MAME — 1

BloodBros.sv:208 Shift fisso aggiunto per match MAME 1:1 (misurato HW 2026-05-14): BG X+0 Y+16 FG X+0 Y+16 SPR X+0 Y+0 TXT X-1 Y+16 L'OSD resta editabile ±32 attorno al valore corretto.

Shares text with the MAME driver without saying so — 3

rtl/BloodBros/BloodBros_main_top.sv:363 MAME bloodbro.cpp:467 map(0x08b000, 0x08bfff).ram().share(m_spriteram) → 4KB. — shares text with seibu/bloodbro.cpp:467
rtl/BloodBros/BloodBros_palette.sv:23 Palette RAM Seibu Blood Bros (xBGR_444, 2048 entries). MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_444, 2048); Address space CPU: — shares text with seibu/bloodbro.cpp:859
rtl/BloodBros/BloodBros_video_timing.sv:23 Video timing single-screen Seibu D-Con. SD Gundam Psycho Salamander gira su Seibu D-Con (PB91008), stessa famiglia di Blood Bros (1990). PCB measuremen — shares text with seibu/bloodbro.cpp

BluePrint#
Blue Print, Grasspin, Saturn
MiSTer-devel/Arcade-BluePrint_MiSTer @ aff7508d
MAME compared: jaleco/blueprnt.cpp
Read: 7 HDL files, 1,626 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

54%

Statements: 1 toward hardware, 2 toward MAME

Ships hardware documentation files — 1

Useful Information/Blueprint Schematics & Manual.pdf

Cites MAME source — 1

rtl/BluePrint_CPU.sv:96 H counter 0-319, V counter 0-263 From MAME: set_raw(5MHz, 320, 0, 256, 264, 16, 240)

Shares text with the MAME driver without saying so — 1

rtl/BluePrint_CPU.sv:97 From MAME: set_raw(5MHz, 320, 0, 256, 264, 16, 240) — shares text with jaleco/blueprnt.cpp:600

BombJack#
Bomb Jack
MiSTer-devel/Arcade-BombJack_MiSTer @ 14f52332
MAME compared: tecmo/bombjack.cpp
Read: 26 HDL files, 5,827 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

50%

Statements: 7 toward hardware, 2 toward MAME

Cites hardware documentation that MAME's driver does not — 7

rtl/bombjack/bombjack.vhd:14 This is a VHDL implementation of the arcade game "Bomb Jack" (c) 1984 Tehkan Translated from schematic to VHDL Q1 2012, d18c7db
rtl/bombjack/bombjack.vhd:353 chip 6P10 page 1 (deviation from schematic to cleanup the wait pulse by taking s_7P5 into account as well) added user/hiscore system controlled pause
rtl/bombjack/p3_timing.vhd:236 chip 5P9 page 3 - original as per schematic U5P9 : process begin wait until rising_edge(I_CLK_12M); s_16V_t1 <= s_16V; -- detect rising edge of s_16V if (s_16V = '1' and s_16V_t1 = '0') then -- chip 4N8 page 3 s_vblank_n <= not (s_32V and s
rtl/bombjack/p3_timing.vhd:248 chip 5P9 page 3 - deviation from schematic to extend the blanking signal
rtl/bombjack/p4_sprites.vhd:180 ROMs 8K, 8H, 8E in separate file
rtl/bombjack/p6_char_gen.vhd:140 ROMs 8K, 8H, 8E in separate file
rtl/bombjack/p7_bgnd_tiles.vhd:105 ROMs 4P, 8R, 8N, 8L in separate file

Cites MAME source — 2

rtl/bombjack_top.vhd:1 -----------------------------------------------------------------[07.09.2015] MAME Bomb Jack implementation in FPGA
rtl/ym2149/YM2149_linmix.vhd:47 Clues from MAME sound driver and Kazuhiro TSUJIKAWA

BoogieWings#
The Great Ragtime Show
MiSTer-devel/Arcade-BoogieWings_MiSTer @ 84085e3d
MAME compared: dataeast/boogwing.cpp + 12 related file(s)
Read: 20 HDL files, 18,347 lines (Quartus project)

MiSTer official

Mostly MAME

medium

44%

Statements: 180 toward MAME

Cites MAME source — 164

Template.sv:253 w-mode: posizione 1°/2° blocco come MAME
Template.sv:255 w-mode: code nell'ordine MAME
Template.sv:256 0 = MAME -16
Template.sv:446 --- BoogieWings INPUT mapping (MAME boogwing.cpp:561-633 INPUT_PORTS_START) --- MiSTer joy bit layout (MiSTer convention): [0]=Right, [1]=Left, [2]=Down, [3]=Up [4]=A (FIRE/BTN1), [5]=B (BOMB/BTN2), [6]=X (SPECIAL/BTN3) [10]=Start, [11]=Coi
Template.sv:452 INPUTS port (MAME "INPUTS", 16-bit, tutto active LOW):
Template.sv:475 SYSTEM port (MAME "SYSTEM", 16-bit): bit 0: COIN1 (active LOW) bit 1: COIN2 (active LOW) bit 2: SERVICE1 (active LOW) bit 3: VBLANK (active HIGH — da screen device) bit 4..15: unused (idle HIGH)
Template.sv:483 bit 3 VBLANK (active HIGH MAME → 1 quando in vblank)
Template.sv:946 OSD audio gain decoder: 4 bit → gain 4.4 fixed point 0=Default 1=Mute 2=MAME 3=25% 4=50% 5=75% 6=100% 7=125% 8=150% 9=200% 10=250% 11=300% 12=400% 13=500% 14=700% 15=1000% % indicato è scaling rispetto al Default (= valore base per ogni chi
Template.sv:971 Default HW-tested (= valori RTL applicati con foto utente OSD 200%/300%/400%): FM=0x08 (0.5), OKI0=0xFF (15.94, =sat max), OKI1=0x80 (8.0) MAME esatti: FM=0x05 (0.32), OKI0=0x09 (0.56), OKI1=0x02 (0.12)
Template.sv:992 OSD sel passati direttamente al chip audio (Default/MAME hardcoded dentro).
Template.sv:1169 BoogieWings video timing: 320×240 60Hz (boogwing.cpp:731: htot=442, hact=320, vtot=274, vact=240) Pixel clock: 96/14 = 6.857 MHz (divisore intero).
rtl/boogwings/boogwings_audio.sv:5 MAME boogwing.cpp: - HuC6280A (audio CPU) @ SOUND_XTAL/4 ≈ 8.055 MHz - YM2151 @ SOUND_XTAL/9 ≈ 3.580 MHz - OKI M6295 #0 @ SOUND_XTAL/32 ≈ 1.007 MHz (PIN7_HIGH) - OKI M6295 #1 @ SOUND_XTAL/16 ≈ 2.014 MHz (PIN7_HIGH)
rtl/boogwings/boogwings_audio.sv:11 Memory map H6280 (audio_map boogwing.cpp:547): 0x000000-0x00FFFF: ROM (64 KB, audiocpu.bin) 0x100000-0x100001: NOP (read/write) 0x110000-0x110001: YM2151 r/w 0x120000-0x120001: OKI #0 r/w 0x130000-0x130001: OKI #1 r/w 0x140000: sou
rtl/boogwings/boogwings_audio.sv:83 OSD audio sel (4 bit each: 0=Default, 1=Mute, 2=MAME, 3-15 = percentual scale)
rtl/boogwings/boogwings_audio.sv:107 Default = bilanciamento del mix di MAME, misurato sull'attract: le scritture ai chip registrate in MAME suonate sui chip del core (banco AudioTrack_Compare), e i tre guadagni adattati perche' il mix coincida con l'uscita di MAME banda per b
rtl/boogwings/boogwings_audio.sv:364 Bank switch OKI: MAME port_write_handler riceve {CT2, CT1} (= bit 7:6 del dato scritto al YM2151 register 0x1B).
rtl/boogwings/boogwings_audio.sv:365 MAME boogwing.cpp:694-695: oki[1].bank = (data & 2) >> 1 = CT2 bit oki[0].bank = data & 1 = CT1 bit Quindi devo prendere data[7:6] = {CT2,CT1} e mapparli ai bank.
rtl/boogwings/boogwings_audio.sv:448 MAME oki bank: 0x40000 (256 KB) finestra dentro 512 KB ROM.
rtl/boogwings/boogwings_audio.sv:461 MAME oki bank: 0x40000 (256 KB) finestra dentro 512 KB ROM.
rtl/boogwings/boogwings_audio.sv:751 soundlatch IRQ (MAME IRQ0 → H6280 IRQ1)
rtl/boogwings/boogwings_audio.sv:752 YM2151 timer IRQ → H6280 IRQ2 (MAME IRQ2)
rtl/boogwings/boogwings_audio.sv:780 MAME pesi BoogieWings: ym=0.32, oki0=0.56, oki1=0.12.
rtl/boogwings/boogwings_audio.sv:780 In 4.4 fixed: ym = 0.32 × 16 = 5.12 → 0x05 oki0 = 0.56 × 16 = 8.96 → 0x09 oki1 = 0.12 × 16 = 1.92 → 0x02 MA jtcps1 amplifica più di MAME float-equivalent perché jt6295 14-bit ≠ MAME peak.
rtl/boogwings/boogwings_audio.sv:851 Correzione verso MAME (low-shelf 498 Hz +1.8 dB, peaking 5773 Hz -3.0 dB) a 192 kHz, ricavata da registrazioni allineate MAME/core dell'attract.
rtl/boogwings/boogwings_top.sv:5 Hardware MAME (boogwing.cpp):
rtl/boogwings/boogwings_top.sv:14 Memory map main (boogwing.cpp:504): 0x000000-0x0FFFFF ROM (1MB, encrypted) 0x200000-0x20FFFF work RAM (64KB) 0x220000 priority_w 0x240000/0x244000 spriteram DMA trigger 0x242000/0x246000 spriteram1/2 (2KB ciascuno) 0x24E000-0x
rtl/boogwings/boogwings_top.sv:29 Memory map audio H6280 (boogwing.cpp:547): 0x000000-0x00FFFF ROM (64KB) 0x110000 YM2151 r/w 0x120000 OKI1 r/w 0x130000 OKI2 r/w 0x140000 sound latch read 0x1F0000-0x1F1FFF work RAM (8KB)
rtl/boogwings/boogwings_top.sv:54 Inputs MAME-mapping BoogieWings (vedi docs/99_discovery_log.md): inputs_port = INPUTS (16-bit, P1+P2 joy+button+start, active LOW) system_port = SYSTEM (16-bit, coin+service+vblank, active LOW eccetto vblank)
rtl/boogwings/boogwings_top.sv:137 OSD audio sel (4 bit each) — Default/MAME hardcoded dentro boogwings_audio
rtl/boogwings/boogwings_top.sv:224 MAIN CPU M68000 @ 14 MHz (target, MAME = 28MHz/2) Pattern: jtframe_68kdtack_cen genera cpu_cen/cpu_cenb con cycle recovery quando bus è busy (es.
rtl/boogwings/boogwings_top.sv:229 Clock divider: clk_sys 96 MHz × 7/48 = 14.000 MHz esatti MAME M68K main = 28 MHz / 2 = 14.000 MHz (boogwing.cpp:715,719) Prima era 1/7 ≈ 13.71 MHz = -2% troppo lento
rtl/boogwings/boogwings_top.sv:254 Noprw range MAME (boogwing.cpp:510, 534, 535) — devono produrre DTACK ma scrittura/lettura senza effetti (read=FFFF, write=ignorata).
rtl/boogwings/boogwings_top.sv:368 MAME: irq6_line_hold = mantieni IRQ6 alto, MAME lo abbassa quando CPU fa IACK.
rtl/boogwings/boogwings_top.sv:416 DE102 decryption (DECO102 chip) — selettore via `BYPASS_DECRYPT` address scramble: i_logical → i_physical (ROM offset) data decrypt: din × addr × select_xor → plain Parametri boogwing.cpp:1027: address_xor=0x42BA, data_select_xor=0x00,
rtl/boogwings/boogwings_top.sv:450 MAIN address decoder (boogwing.cpp:504)
rtl/boogwings/boogwings_top.sv:465 MAME: 0x242000-0x2427FF (2 KB = 0x800 byte).
rtl/boogwings/boogwings_top.sv:484 Noprw ranges (MAME boogwing.cpp:510, 534, 535): 0x220002-0x22FFFF : after priority_w 0x280000-0x28000F : palette setup (eccetto 0x282008 = paldma) 0x282000-0x282001 : palette setup
rtl/boogwings/boogwings_top.sv:604 MAME boogwing.cpp:529-530: chip1 pf1/pf2 mappati con `.ram().w(deco16ic)`.
rtl/boogwings/boogwings_top.sv:893 chip0 ctrl[0] bit 7 (MAME boogwing.cpp:419)
rtl/boogwings/boogwings_top.sv:894 Render x/y flippati quando flip_screen=1 (MAME flip_screen_set).
rtl/boogwings/boogwings_top.sv:896 Schermo BoogieWings: hcnt 0..441 attivo 0..319 → x flip = 319-x. Template.sv: render_x=hcnt (= x di MAME), render_y=vcnt+1 (tutta l'immagine alzata di 1 px).
rtl/boogwings/boogwings_top.sv:898 In MAME l'asse dello specchio verticale e' 255; nello spazio alzato di 1 diventa 255+2*1 = 257, non 255.
rtl/boogwings/boogwings_top.sv:899 Misurato: col flip gli sprite, che dentro usano le costanti di MAME (240-y, 304-x), cadono esattamente sull'asse 257 (banco NsSprites_Flip_Bench, 0 differenze su 76160 confronti).
rtl/boogwings/boogwings_top.sv:923 BoogieWings bank callbacks (boogwing.cpp:749, 761): tilegen[0]: bank1=none, bank2=bank_callback (mode 1) tilegen[1]: bank1=bank_callback2, bank2=bank_callback2 (mode 2) GFX base address SDRAM (tile_byte_addr relativo a TILE_BASE): tiles1 (t
rtl/boogwings/boogwings_top.sv:1075 Buffer side (DMA write dest + renderer read source) — buffered_spriteram MAME-style
rtl/boogwings/boogwings_top.sv:1168 MAME buffered_spriteram16: copy LIVE -> BUFFER a VBlank rise (bufsprite.h).
rtl/boogwings/boogwings_top.sv:1234 CPU readback NON serve (write-only dal punto di vista di MAME boogwing: il chip è palette device, leggere è debug).
rtl/boogwings/boogwings_top.sv:1240 Palette DECO_ACE 24-bit RGB888 (MAME deco_ace.cpp): m_paletteram[2048] è uint32: bits 23:16 = B byte, 15:8 = G byte, 7:0 = R byte.
rtl/boogwings/boogwings_top.sv:1433 Palette index base (boogwing.cpp:gfx_boogwing entries): tiles1 (text 8×8) = palette base 0x800 tiles2 (deco16_0) = palette base 0x100 tiles3 (deco16_1) = palette base 0x300
rtl/boogwings/boogwings_top.sv:1446 Palette index per layer (MAME gfx_boogwing boogwing.cpp:671): tiles1 (text) → base 0x800, 16 set × 16 col (4bpp) tiles2 (BG1) → base 0x100, 16 set × 32 col (5bpp → ora 4bpp, upper half vuota finché plane 4 non impl) tiles3 (BG2) → base
rtl/boogwings/boogwings_top.sv:1462 La logica MAME ha 5 modi diversi via priority_reg[2:0] (vedi screen_update); per ora implemento solo l'ordine default.
rtl/boogwings/boogwings_top.sv:1464 (col_bank di chip1 pf2 è già dentro d16_1_pf2_col → non sommato qui) Palette base per layer — MAME GFXDECODE (boogwing.cpp:672-674): tiles1 text = 0x800, tiles2 BG1 = 0x100, tiles3 BG2 = 0x300.
rtl/boogwings/boogwings_top.sv:1474 Layer mixer con priority register MAME-compliant (5 modi).
rtl/boogwings/boogwings_top.sv:1475 Riferimento: boogwing.cpp:417-477 screen_update.
rtl/boogwings/boogwings_top.sv:1509 MAME formula: pal_idx = base + col_5b * 16 + pen[3:0].
rtl/boogwings/boogwings_top.sv:1529 Sprite chip0 (sprites1): MAME GFXDECODE 0x500, 32 banks x 16 colors.
rtl/boogwings/boogwings_top.sv:1530 MAME mixer: pal_idx = 0x500 + (pix1 & 0x1ff) dove pix1 = {color[7:0], pen[3:0]} → pal_idx = 0x500 + {color[4:0], pen[3:0]} (= 5 bit color = 32 banks) Bug fix: era color[3:0] (= solo 16 banks), ora color[4:0] (= 32 banks MAME-corretto).
rtl/boogwings/boogwings_top.sv:1541 Sprite chip1 (sprites2): MAME 0x700, 16 banks x 16 colors.
rtl/boogwings/boogwings_top.sv:1549 MAME boogwing.cpp mix() priorità sprite vs sprite dinamica (pixel-by-pixel).
rtl/boogwings/boogwings_top.sv:1551 MAME (priority_reg & 0x7) default case → spri1 = 2/8/32, spri2 = 4/16/64.
rtl/boogwings/boogwings_top.sv:1552 pri_bits = {color[6], color[5]} = {x_bit15, x_bit14} MAME spri1: 0x600=0b11 → 2 ; 0x400=0b10 → 8 ; else → 32 MAME spri2: 0x600=0b11 → 4 ; (0x400 OR 0x200)=non-zero → 16 ; else → 64
rtl/boogwings/boogwings_top.sv:1558 MAME spri1 (boogwing.cpp:240-262) ha un CASE su priority: case 0x00: (pix1&0x600)==0x600 -> 2 ; ==0x400 -> 8 ; else -> 32 default (priority!=0): (pix1&0x400) -> 8 ; else -> 32 (MAI 2!) Il core usava SEMPRE lo schema 0x00 (2/8/32).
rtl/boogwings/boogwings_top.sv:1561 In priority 4 (cutscene pre-boss, il testo e' uno sprite chip0) questo dava spri1=2 quando spr_pri=2'b11, mentre MAME da' spri1=8.
rtl/boogwings/boogwings_top.sv:1564 Fix: rispettare il case priority come MAME.
rtl/boogwings/boogwings_top.sv:1574 MAME default: (pix1 & 0x400) ?
rtl/boogwings/boogwings_top.sv:1583 chip1 sopra chip0 se spri2 > spri1 (MAME default).
rtl/boogwings/boogwings_top.sv:1590 MAME invece calcola spri1 = 32 (perche' p1 in {0,1} finisce nel ramo else) e spri2 = 16 (perche' p2 = 1 entra in "else if (pix2 & 0x600)"): con bit9 = 1 su entrambi la condizione spri2 > spri1 e' falsa e il pixel del chip 1 viene buttato vi
rtl/boogwings/boogwings_top.sv:1599 === MAME priority bitmap (bg_pri) per sprite vs playfield === MAME boogwing.cpp:437-471: dopo screen.priority().fill(0), ogni tilemap_draw passa un priority_value che viene scritto nella priority bitmap per i pixel opachi disegnati.
rtl/boogwings/boogwings_top.sv:1604 MAME draw sequence (pri_reg & 0x7): case 0x5: PF2[0] OPAQUE=0, combine[1] pri=32 case 0x4: combine[1] OPAQUE=0, PF2[0] pri=32 case 0x1/0x2: PF2[1] OPAQUE=0, PF2[0] pri=8, PF1[1] pri=32 case 0x3: PF2[1] OPAQUE=0, PF2[0] pri=8, PF1[1] alpha (
rtl/boogwings/boogwings_top.sv:1649 pri1 = sprite chip0 priority vs playfield (MAME boogwing.cpp:264-295) pri2 = sprite chip1 priority vs playfield (MAME boogwing.cpp:316-338) IMPORTANTE: MAME checks tipo "(pix & 0x400) == 0x400" testano SOLO il bit 10 (= spr_pri[1]), NON l'e
rtl/boogwings/boogwings_top.sv:1677 Sprite-vs-playfield: visible solo se pri > bg_pri (MAME mix() linee 359/371)
rtl/boogwings/boogwings_top.sv:1681 drawnpixe1 flags MAME (mix() line 357-387): pixel sprite EFFETTIVAMENTE disegnato
rtl/boogwings/boogwings_top.sv:1686 MODE 3 shadow apply (MAME line 396-411): pri3 = 32.
rtl/boogwings/boogwings_top.sv:1704 MAME mix() linea 369: dstline[x] = paldata[tmappix] (= ultimo tilemap drawn).
rtl/boogwings/boogwings_top.sv:1706 BACKDROP: dove tutti i layer sono trasparenti, MAME mostra pen 0x400 (boogwing.cpp:435 bitmap.fill(pen(0x400))), NON pen 0 (nero).
rtl/boogwings/boogwings_top.sv:1743 === Sprite chip1 alpha-blend (MAME boogwing.cpp:305-314) === pix2 = (colour << 4) | pen → mapping al mio sistema: pix2[3:0] = spr2_pen[3:0] pix2[7:4] = spr2_color[3:0] (= 4 bit colour LSB visibili nel pal_idx)
rtl/boogwings/boogwings_top.sv:1752 MAME alpha2 logic: default: alpha2 = get_alpha((pix2 >> 4) & 0xf) = get_alpha(spr2_color[3:0]) if pix2[8]: if pix2[11]: alpha2 = (pix2&8) ?
rtl/boogwings/boogwings_top.sv:1759 MAME get_alpha(N): regval = ace_regs[N][7:0]; if regval > 0x20: return 0x80 (special) else: return clamp_unsigned(255 - (regval << 3))
rtl/boogwings/boogwings_top.sv:1788 PROVATO A TOGLIERLA E RIMESSA (2026-09-23): boogwing.cpp:309 dichiara opaco il pixel col bit 3 del pen acceso senza leggere la LUT dell'ACE.
rtl/boogwings/boogwings_top.sv:1790 Sembrava una semplificazione dell'emulatore da scavalcare, ma il confronto a schermo con MAME dice il contrario: senza, le esplosioni diventano brunastre e trasparenti dove in MAME sono piene e brillanti.
rtl/boogwings/boogwings_top.sv:1815 DECO_ACE alpha-blend (MAME deco_ace.cpp + boogwing.cpp mix()): Quando priority_reg[2:0]==3 e FG0 (chip1.pf1) ha pen != 0 → blend FG0 con strato sotto (di solito BG1 o FG1).
rtl/boogwings/boogwings_top.sv:1834 Text TOP sempre (drawn dopo mix sprite in MAME).
rtl/boogwings/boogwings_top.sv:1837 Sprite priority DINAMICA pixel-by-pixel (MAME mix() spri1 vs spri2 + pri vs bg).
rtl/boogwings/boogwings_top.sv:1886 MAME: bg2_drawed = (bgpri==8) → BG1 disegnato + ombra cade su BG1.
rtl/boogwings/boogwings_top.sv:1923 === DECO_ACE FADE (deco_ace.cpp:165-199) — ESATTO, identico a MAME bit-per-bit.
rtl/boogwings/boogwings_top.sv:1939 Palette RAW vs FADED (deco_ace.cpp:175-198): la palette deco_ace ha 4096 pen: 0x000-0x7FF = palette CON fade (set_pen_color(i)).
rtl/boogwings/boogwings_top.sv:1942 MAME indicizza con paldata[pal_idx]: se pal_idx >= 0x800 -> RAW (no fade).
rtl/boogwings/boogwings_top.sv:1943 Gli sprite/BG (base <0x800) vanno raw solo col calculated_coloffs (priority bit3 -> +0x800, boogwing.cpp:355).
rtl/boogwings/boogwings_top.sv:1946 Il bit 11 dell'indice (0x800) marca "raw" = bypass del fade, PER-PIXEL su top e bot separati (come MAME: l'offset 0x800 e' per-sorgente, NON globale).
rtl/boogwings/boogwings_top.sv:1952 Alpha factor — MAME deco_ace.cpp get_alpha(): alpha = m_ace_ram[val] & 0xff; if (alpha > 0x20) return 0x80; // special blending command else alpha = 255 - (alpha << 3); clamp 0; Boogwing usa val=0x1f per tilemap alpha (chip1.pf1).
rtl/boogwings/boogwings_top.sv:1985 Formule MAME invariate, bit per bit: fade mult (0x1100): c = clamp(0,255, c + ((fadept - c) * fadeps) / 255) /255 esatto = (|prod| * 32897) >> 23, quoziente troncato verso zero fade add (0x1000): c = min(c + fadeps, 255) alpha_blend_r32: (
rtl/boogwings/boogwings_top.sv:1992 Mapping: dst = bot_color (BG1), src = top_color (FG0 ombra) - MAME line 408.
rtl/boogwings/boogwings_top.sv:2339 sprite_romaddr e' in spazio MAME (= source 4MB).
rtl/boogwings/boogwings_top.sv:2459 Sprite download interleave: layout MAME tile_16x16_layout richiede plane 0,1 da LO region, plane 2,3 da HI region.
rtl/boogwings/boogwings_top.sv:3009 Coordinate GREZZE: il flip degli sprite lo fa bw_sprites (flipscreen_spr = ~flip_screen -> x=304-x, y=240-y, mult=-16), nello stesso spazio della bitmap MAME.
rtl/boogwings/boogwings_top.sv:3060 Coordinate GREZZE: il flip degli sprite lo fa bw_sprites (flipscreen_spr = ~flip_screen -> x=304-x, y=240-y, mult=-16), nello stesso spazio della bitmap MAME.
rtl/boogwings/bw_sprites.sv:11 MAME equivalente: m_sprite_bitmap full-frame 320×256 + draw_sprites_common.
rtl/boogwings/bw_sprites.sv:25 Output identico al MAME m_sprite_bitmap se scan ordinata correttamente.
rtl/boogwings/bw_sprites.sv:28 MAME standard format (offs +0/+1/+2): +0: efFbSssyyyyyyyyy e=priority, f=flipy, F=flipx, b=flash, S=w, ss=h +1: tttttttttttttttt tile code +2: ppcccccxxxxxxxxx pp=priority, ccccc=color (5b), x=xpos
rtl/boogwings/bw_sprites.sv:112 flipscreen sprite — MAME boogwing.cpp:424 set_flip_screen(!BIT(flip,7)) → SEMPRE invertito rispetto a flip_screen input (= tilemap flip).
rtl/boogwings/bw_sprites.sv:135 Frame parity per il FLASH sprite (MAME decospr.cpp:227: flag y_word[12], lo sprite e' nascosto sui frame DISPARI -> if(!(flash && (frame_number & 1))) draw).
rtl/boogwings/bw_sprites.sv:146 ~pause_in: in pausa il vblank continua (display vivo) ma la parita' frame resta ferma -> il FLASH si congela come su PCB/MAME (niente flicker in pausa).
rtl/boogwings/bw_sprites.sv:317 MAME decospr.cpp:267-282 + 297-314 — formula completa boogwing con flipscreen=ON:
rtl/boogwings/bw_sprites.sv:326 MAME boogwing.cpp:424 set_flip_screen(!BIT(flip,7)) → default ON (flip[7]=0).
rtl/boogwings/bw_sprites.sv:338 Solo "sign-ext" con soglia 320 (MAME decospr.cpp:267-269): x = x & 0x1ff; (9-bit 0..511) if (x >= 320) x -= 512; (0..319 unsigned, 320..511 → -192..-1) Risultato: signed -192..319 (10-bit signed sufficiente).
rtl/boogwings/bw_sprites.sv:444 Col flip MAME mette il blocco a 240-sy e i blocchi successivi vanno verso l'alto (mult=-16), quindi la cima e' 240 - sy - 16*multi = 256 - sy - height: simmetrica, non 0.
rtl/boogwings/bw_sprites.sv:548 fx_eff = flipx ^ flipscreen_spr (MAME riga 306-313: flipscreen invertito m_flipallx=0) NB: fx_eff (dai reg FSM) serve SOLO all'address-gen (half_use in S_ROM_REQ); la catena pen del DRAW usa lo snapshot d_flipx/d_pix (il draw gira in parall
rtl/boogwings/bw_sprites.sv:574 MAME planeoffset = {hi+8, hi+0, lo+8, lo+0} → plane 0 = byte 3 (mbd-05 alto), plane 1 = byte 2, plane 2 = byte 1, plane 3 = byte 0 (mbd-06 basso).
rtl/boogwings/bw_sprites.sv:587 MAME order: pen={p4,planes1..4}.
rtl/boogwings/bw_sprites.sv:746 Se OFF, doppia inversione MAME (240-y, 304-x).
rtl/boogwings/bw_sprites.sv:776 MAME decospr.cpp:297-304: flipscreen OFF: mult = -16, tile cresce verso l'alto da sy → bounding box [sy - 16*multi, sy + 16) → dy_top = scan_y - (sy - 16*multi) = (scan_y - sy) + 16*multi flipscreen ON: mult = +16, tile cresce verso il bas
rtl/boogwings/bw_sprites.sv:814 MAME: non-intersecante = nulla.
rtl/boogwings/bw_sprites.sv:841 FIX flipx half-swap: quando fx_eff=1 (sprite specchiato), MAME inverte anche l'ordine dei 2 half del tile (oltre al flip pixel-in-byte già fatto da bit_x).
rtl/boogwings/bw_sprites.sv:908 FIX BUG #2: MAME decospr.cpp:351 → 2° blocco a (x+16) per flipscreen_spr=1, (x-16) per flipscreen_spr=0.
rtl/boogwings/deco16ic.sv:5 Riferimento C++: reference/mame/deco16ic.cpp (Bryan McPhail / David Haywood) Riferimento BoogieWings: reference/mame/boogwing.cpp
rtl/boogwings/deco16ic.sv:30 Bank callback mode (boogwing.cpp:699-711): 0 = identity (no callback, bank=0) 1 = boogwing bank_callback: offset = ((bank >> 4) & 7) << 12 2 = boogwing bank_callback2: offset = bank_callback + (bank & 0xF == 0xA ?
rtl/boogwings/deco16ic.sv:39 Colour bank + mask (MAME boogwing.cpp:744-760): output_colour = (raw_colour & COL_MASK) + COL_BANK BoogieWings: chip 0 pf1/pf2: COL_BANK=0, COL_MASK=0x0F chip 1 pf1 : COL_BANK=0, COL_MASK=0x0F chip 1 pf2 : COL_BANK=16, COL_MASK=0x0F
rtl/boogwings/deco16ic.sv:146 Control registers (8 word @ 0x00-0x0F) Layout (deco16ic.cpp:94-134): [0] bit 7 = flip screen, bit 6:0 = ?
rtl/boogwings/deco16ic.sv:149 [1] = pf2 scroll X [2] = pf2 scroll Y [3] = pf1 scroll X [4] = pf1 scroll Y [5] = enables + rowscroll/colscroll style [6] = mode bits (8x8 vs 16x16, rowscroll en, colscroll en, flip behavior) [7] = bank hi: [15:8] = pf1 gfx bank, [7:0] = pf
rtl/boogwings/deco16ic.sv:176 Bank callback (deco16ic.cpp:903-931) bank1_cb input = pf12_control[7] & 0xff (byte basso) bank2_cb input = pf12_control[7] >> 8 (byte alto) Output = m_pf1_bank / m_pf2_bank, sommato a tile_code in rendering
rtl/boogwings/deco16ic.sv:181 BoogieWings (boogwing.cpp:699-711): bank_callback: offset = ((bank >> 4) & 7) * 0x1000 → max 0x7000 bank_callback2: bank_callback + ((bank & 0xF) == 0xA ?
rtl/boogwings/deco16ic.sv:208 VRAM CPU readback ritorna 0 (MAME raramente rilegge VRAM tile; sopprimere il read port libera la 2a porta del M10K).
rtl/boogwings/deco16ic.sv:233 VRAM layout 64x32 (deco16ic.cpp:291): tile_index = (col & 0x1F) + ((row & 0x1F) << 5) + ((col & 0x20) << 5) + ((row & 0x20) << 6) Cioè blocchi 32x32 disposti in 2x1 (col[5] e row[5] selezionano blocco).
rtl/boogwings/deco16ic.sv:238 Layout 16x16 4bpp (boogwing.cpp tile_16x16_layout): 32 byte per riga (16 px × 2 byte plane = 32 byte = 8 word ROM) No, ricalcolo: 16x16 4bpp = 16*16*4 / 8 = 128 byte per tile = 32 word 32-bit (4 byte) In gfx_layout: plane_offset = { 1/2+8,
rtl/boogwings/deco16ic.sv:282 VRAM swizzle layout DECO_64x32 (deco16ic.cpp:291) tile_index = (col & 0x1F) + ((row & 0x1F) << 5) + ((col & 0x20) << 5) + ((row & 0x20) << 6) Per 64×32: row 5-bit (max 0x1F), col 6-bit (max 0x3F) → bit [11] = row[5] (= 0 sempre per 32 ro
rtl/boogwings/deco16ic.sv:297 Tile decode (deco16ic.cpp:294-352, pf1 usa control[6] byte basso)
rtl/boogwings/deco16ic.sv:317 ROM addressing 16x16 4bpp PLANAR (MAME gfx tile_16x16_layout): Per metà-riga (8 pixel) servono 2 fetch 16-bit del bridge: fetch 1: planeLo region → word con plane0+plane1 (8 pixel × 2 plane) fetch 2: planeHi region → word con plane2+plane3
rtl/boogwings/deco16ic.sv:337 formula MAME: 16x16 4bpp planar 2 region: tile=64 byte/region * 2 region = 128 byte Region = 64 byte/tile (2 plane * 16x16 / 8 = 64 byte).
rtl/boogwings/deco16ic.sv:346 16x16: byte_per_region = tile_code*64 + xhalf*32 + 2*y → {tile_code, xhalf, pix_y[3:0], 1'b0} 8x8 : byte_per_region = tile_code*16 + 2*y → {tile_code, pix_y[2:0], 1'b0} MAME tile_16x16_layout x_offsets: STEP8(16*8*2,1) per pixel 0.
rtl/boogwings/deco16ic.sv:380 rom_data 32-bit PLANAR (MAME gfx tile_16x16_layout): tile_data[15:0] = plane_lo_word = {plane1_byte, plane0_byte} (8 pixel × 2 plane) tile_data[31:16] = plane_hi_word = {plane3_byte, plane2_byte} pixel i (0..7) bit_pos = 7 - i (MSB first)
rtl/boogwings/deco16ic.sv:392 MAME convention: pixel 0 (leftmost) = MSB del byte plane (bit 7), pixel 7 (rightmost) = LSB (bit 0).
rtl/boogwings/deco16ic.sv:405 MAME: output_colour = (raw & col_mask) + col_bank
rtl/boogwings/deco16ic_jt.sv:77 Flip screen globale (MAME boogwing.cpp:419-425: pf_control_r(0) bit 7).
rtl/boogwings/deco16ic_jt.sv:78 Sponta solo da chip 0 (chip1 ha il suo ma MAME usa solo chip0).
rtl/boogwings/deco16ic_jt.sv:117 Combine 8bpp (MAME tilemap_12_combine_draw, priority 4/5): pf1 e pf2 sono lo STESSO pixel (nibble basso/alto).
rtl/boogwings/deco16ic_jt.sv:277 Flip screen globale (MAME boogwing.cpp:419-425): flip = m_deco_tilegen[0]->pf_control_r(0); flip_screen = BIT(flip,7);
rtl/boogwings/deco16ic_jt.sv:281 MAME deco16ic.cpp:899-900 (codice, NON il commento header che è invertito): PF1 scroll = ctrl[1] (X), ctrl[2] (Y) PF2 scroll = ctrl[3] (X), ctrl[4] (Y)
rtl/boogwings/deco16ic_jt.sv:289 Rowscroll enable + style (MAME deco16ic.cpp header riga 94-130) pf12_control[5] (word 0xa): bit 15 = pf1 enable bit 14:11 = pf1 rowscroll style bit 10:8 = pf1 colscroll style bit 7 = pf2 enable bit 6:3 = pf2 rowscroll style bit 2:
rtl/boogwings/deco16ic_jt.sv:306 dissolvenza logo Data East) MAME passa al renderer custom (:847-850) che applica bit6 e bit5 INDIPENDENTI, insieme.
rtl/boogwings/deco16ic_jt.sv:311 MAME riga 761: (control0 >> 3) & 0xf -> bit 6:3 per pf1 row style.
rtl/boogwings/deco16ic_jt.sv:318 COLSCROLL Y-per-column (MAME deco16ic.cpp:492-497, 812): col_type = 8 << (control0 & 7) ∈ {8,16,32,64,128,256,512,1024} col_idx = (src_x & 0x1ff) / col_type col_offset = rowscroll_ptr[0x200 + col_idx] // 16-bit Y offset veff_eff = veff +
rtl/boogwings/deco16ic_jt.sv:334 PLAYFIELD DISABLE (MAME deco16ic.cpp:465: if(!BIT(control0,7)) return;).
rtl/boogwings/deco16ic_jt.sv:356 MAME riga 482: src_x = scrollx + rowscroll_ptr[src_y / row_type] rows = total scanlines / row_type.
rtl/boogwings/deco16ic_jt.sv:377 Per text 8x8 MAME dimezza numrows (riga 798); equivalente a >> 1 sull'idx.
rtl/boogwings/deco16ic_jt.sv:389 16x16: veff MASCHERATO a [8:0] (= & height_mask 511, MAME deco16ic.cpp:477/:534) PRIMA dello shift.
rtl/boogwings/deco16ic_jt.sv:405 FIX colonne durante scroll (MAME deco16ic.cpp:493 col_idx da src_x = pixel REALE): src_x deve azzerare il sub-tile offset scroll_x[3:0] (16x16) o [2:0] (8x8).
rtl/boogwings/deco16ic_jt.sv:568 VRAM swizzle hardcoded: 8x8 (text) = Linear idx = {row[4:0], col[5:0]} 16x16 (BG) = DECO_64x32 idx = {col[5], row[4:0], col[4:0]} MAME deco16ic.cpp:245 — TILEMAP_SCAN_ROWS per 8x8, deco16_scan_rows per 16x16.
rtl/boogwings/deco16ic_jt.sv:596 Flip per-tile (MAME deco16ic.cpp:330-341 get_pf1_tile_info): if (vram[15] && ctrl[6][0]) → FLIPX, colour &= 7 if (vram[15] && ctrl[6][1]) → FLIPY, colour &= 7 Per pf2 (16x16): ctrl[6][8] e ctrl[6][9].
rtl/boogwings/deco16ic_jt.sv:644 Sub-tile X offset: scan parte da tile-aligned, buf_waddr inizia negativo (wrap 9-bit) per scartare i primi N pixel del primo tile (= MAME src_x = scroll_x + render_x).
rtl/boogwings/deco16ic_jt.sv:692 MAME: colour = tile[15:12], if tile[15] && flipctrl colour &= 7
rtl/boogwings/deco16ic_jt.sv:912 Colscroll attivo: veff_eff = render_y + scroll + cs (MAME esatto).
rtl/boogwings/deco16ic_jt.sv:914 Il -1 vale SOLO per colscroll-ONLY (0x20 = path tilemap STANDARD MAME, dove e' stato tarato e validato: camini, commit 36a9671 — NON TOCCARE quel caso).
rtl/boogwings/deco16ic_jt.sv:915 Con row+col SIMULTANEI (0x60 = path custom MAME, dissolvenza logo Data East) MAME fa y=src_y+coloff SENZA -1: applicarlo li' spostava il layer di 1 riga rispetto allo stato statico -> SALTO del logo alla fine dell'effetto (riprodotto in SIM
rtl/boogwings/deco16ic_jt.sv:938 Flip per-tile pf2 (MAME deco16ic.cpp:300-311): ctrl[6][8] = FLIPX, ctrl[6][9] = FLIPY (per pf2)
rtl/boogwings/deco16ic_jt.sv:981 Sub-tile X offset: waddr inizia negativo (= 9-bit wrap) per scartare primi N pixel del primo tile = MAME src_x pixel-by-pixel.
rtl/boogwings/deco16ic_jt.sv:1048 Bit position MAME-natural: sc2_pen_p4 = p4_byte[bit_pos].
rtl/boogwings/mix_eq.sv:3 mix_eq — correzione del mix audio verso MAME, 4 biquad in cascata per canale a 192 kHz: S0 low-shelf 461 Hz +1.80 dB S1 peaking 1525 Hz -0.72 dB Q 6.00 S2 peaking 6107 Hz -3.33 dB Q 1.39 S3 high-shelf 6019 Hz +1.26 dB
rtl/boogwings/mix_eq.sv:9 I parametri vengono da due registrazioni allineate dello stesso attract, MAME e core (MiSTer_Utility/AudioTrack_Compare: match_eq4.py, adattamento pesato sull'incertezza di misura); coefficienti e modello intero bit-esatto da eq_rtl_gen.py.
rtl/boogwings/mix_eq.sv:11 Dopo la correzione nessuna banda (50 Hz - 12.5 kHz) resta fuori dall'incertezza e l'rms coincide con MAME entro 0.07 dB.
README.md:12 This core reimplements the hardware in SystemVerilog from MAME references and hardware observation.
README.md:55 **Documentation**: the board's priority PROM (`kj-00.15n`, the one MAME loads and marks *"not used"*) is decoded in [docs/](docs/) — input mapping proved with z
README.md:64 DECO104 protection (I/O + data scramble) reproduced from MAME
README.md:65 MAME-accurate DECO16IC tilemaps (per-row / per-column scroll) and the DECO ACE alpha-blend + fade mixer, including the simultaneous row+column scroll used by th
README.md:84 Two DECO16IC tilemap chips: BG0/BG1 (chip 0) + FG0/FG1 (chip 1), 16×16 and 8×8 tiles, per-row and per-column scroll — MAME-accurate

Says it was translated, ported or taken from MAME — 7

rtl/boogwings/deco16ic_jt.sv:143 State allargato a 5 bit per supportare colscroll lookup per-half (MAME 1:1).
rtl/boogwings/deco16ic_jt.sv:402 COLSCROLL idx (per-half lookup, MAME 1:1 per pixel collassato a per-half perché cs_off è costante nei 8 px consecutivi per col_type≥8).
rtl/boogwings/deco16ic_jt.sv:500 MAME 1:1: colscroll lookup PER PIXEL (in pratica per HALF di 8 px quando col_type≥8).
rtl/boogwings/deco16ic_jt.sv:560 MAME 1:1.
rtl/boogwings/deco16ic_jt.sv:742 MAME 1:1 per-pixel collapsed per HALF perché cs_off è costante negli 8 px consecutivi con col_type≥8.
rtl/boogwings/deco16ic_jt.sv:906 COLSCROLL Y latched pf2 per-half (MAME 1:1).
README.md:47 **Audio**: 4× OKI interpolation with a flat-band FIR, mix EQ, inter-chip balance taken from MAME, and a 10-bit mixer.

Keeps a MAME approximation — 1

Template.sv:955 MAME (placeholder, gestito sotto)

Shares text with the MAME driver without saying so — 8

rtl/boogwings/boogwings_top.sv:1689 E poi filtro: ((pix2 & 0x900) != 0x900) || ((spri2 <= spri1) && sprite1_drawed) — shares text with dataeast/boogwing.cpp:403
rtl/boogwings/boogwings_top.sv:1755 if pix2[11]: alpha2 = (pix2&8) ? 0xff : get_alpha(0x14 + ((pix2-1) & 0x7)) — shares text with dataeast/boogwing.cpp:309
rtl/boogwings/boogwings_top.sv:1953 alpha = m_ace_ram[val] & 0xff; — shares text with dataeast/deco_ace.cpp:211
rtl/boogwings/bw_sprites.sv:112 flipscreen sprite — MAME boogwing.cpp:424 set_flip_screen(!BIT(flip,7)) — shares text with dataeast/boogwing.cpp:424
rtl/boogwings/bw_sprites.sv:326 MAME boogwing.cpp:424 set_flip_screen(!BIT(flip,7)) → default ON (flip[7]=0). — shares text with dataeast/boogwing.cpp:424
rtl/boogwings/deco16ic.sv:235 + ((col & 0x20) << 5) + ((row & 0x20) << 6) — shares text with dataeast/deco16ic.cpp:277
rtl/boogwings/deco16ic.sv:244 x_offset = STEP8(16*8*2,1), STEP8(0,1) → 16 pixel x usando 2 byte — shares text with dataeast/boogwing.cpp:654
rtl/boogwings/deco16ic.sv:283 tile_index = (col & 0x1F) + ((row & 0x1F) << 5) + ((col & 0x20) << 5) + ((row & 0x20) << 6) — shares text with dataeast/deco16ic.cpp:277

Bosconian#
Bosconian - Star Destroyer
MiSTer-devel/Arcade-Bosconian_MiSTer @ 439b554c
MAME compared: namco/bosco.cpp + 14 related file(s)
Read: 28 HDL files, 9,261 lines (Quartus project)

MiSTer official

Mostly MAME

low

30%

Statements: 32 toward hardware, 41 toward MAME, 5 not counted

Cites hardware documentation that MAME's driver does not — 32

rtl/bosco_video_render.vhd:44 (inverted) outputs from RAM 2E, small-object registers
rtl/bosco_video_render.vhd:364 7J: 74LS175 DFF Produces delayed hblank signals.
rtl/bosco_video_render.vhd:393 6L: 74LS08 AND 7J 2Q seems to be a slightly "tweaked" version of the hblank_n signal.
rtl/bosco_video_render.vhd:456 1J, 1K: 74LS374 DFF playfield_posix and playfield_posiy represent the internal state of registers 1J and 1K; posix and posiy are those registers' outputs, which are pulled up when not in the playfield
rtl/bosco_video_render.vhd:470 2K, 2J: 2x 74LS283 4-bit adder, combined to make an 8-bit adder When outside the playfield, since posiy is pulled up to 11111111 and PF_n is the lower carry in, this will just be vcount.
rtl/bosco_video_render.vhd:475 3M, 2L: 2x 74LS283 4-bit adder, combined to make a 6-bit adder The playfield flag is used as the low carry input.
rtl/bosco_video_render.vhd:485 2N: 74LS244 Line Driver Applies the upper bits of the playfield-adjusted x/y positions to the address bus.
rtl/bosco_video_render.vhd:497 2P: 74LS257 MUX
rtl/bosco_video_render.vhd:517 6K: 74LS175 DFF with Clear Strangely, on the schematic, PF_n is input at 2D, but there is neither a 2Q nor a /2Q.
rtl/bosco_video_render.vhd:533 4C: 74LS243 8-Bit Register with Clear This latches the upper bits of the graphics ROM address (used for fetching both sprite and tile data), along with the flip flags for sprites.
rtl/bosco_video_render.vhd:551 5F: 74LS174 DFF with Clear
rtl/bosco_video_render.vhd:569 6H, 6F: 74LS157 MUX Always enabled.
rtl/bosco_video_render.vhd:668 7F: 74LS08 AND - outpin 8; mislabeled on schematic as outpin 11 Determine if the screen is flipped AND we're not in hblank.
rtl/bosco_video_render.vhd:675 6J: 74LS86 XOR - outpin 11 Determine whether the next batch of pixels should be flipped while being shifted out.
rtl/bosco_video_render.vhd:680 4L: 74LS377 D-Register with Common Enable and Clock Original has 6MHZ as the clock and /COLSET as the enable
rtl/bosco_video_render.vhd:696 6D, 6C: 74LS194 Bidirectional Universal Shift Register Original hardware clocked by 6MHZ.
rtl/bosco_video_render.vhd:721 7C: 74LS157 MUX Always enabled; selector is output 5Q from 4L NOTE: The schematic here appears to have some errors; if implemented exactly as diagrammed, the pixel shifter doesn't work properly.
rtl/bosco_video_render.vhd:785 3H, 3K: 74LS283 4-bit adders, paired to make an 8-bit adder.
rtl/bosco_video_render.vhd:787 3J: 74LS20 4-input NAND, outpin 6
rtl/bosco_video_render.vhd:792 3J: 74LS20 4-input NAND, outpin 8
rtl/bosco_video_render.vhd:795 6J: 74LS86 XOR (but one operand is P, so this is functionally an inverter)
rtl/bosco_video_render.vhd:798 5H: 74LS174 DFF with Clear Original hardware clocked by /VPSET.
rtl/bosco_video_render.vhd:816 3D, 3E: 74LS163 Binary Counters, Fully Synchronous Note: On the 74LS163, the reset is also synchronous.
rtl/bosco_video_render.vhd:836 3N: 74LS20 dual 4-input NAND
rtl/bosco_video_render.vhd:843 7F: 74LS08 AND, outpin 3
rtl/bosco_video_render.vhd:845 4B: 74LS365 Buffer Original hardware enables (active low) are 6MHZ and /HBLANK**.
rtl/bosco_video_render.vhd:879 2C, 3F, 3C: 74LS163 Binary Counters, Fully Synchronous Note: On the 74LS163, the reset is also synchronous.
rtl/bosco_video_render.vhd:898 1D: 74LS377 D-Register with Common Enable and Clock Original hardware: 6MHZ clock, LD_n as active-low enable Sets up the address for reading the Small Object ROM.
rtl/bosco_video_render.vhd:950 4B: 74LS365 Hex Buffer - Just used as a simple buffer, so not implemented.
rtl/bosco_video_render.vhd:951 74LS365 has output enables, but they're not used according to the schematic.
rtl/bosco_video_render.vhd:953 7F: 74LS08 AND, outpin6
rtl/bosco_video_render.vhd:991 7D: 74LS174 DFF with Clear The clock for this flip-flop is /6MHZ.

Cites hardware references or measurements that MAME's driver also gives — 5

rtl/bosco_video_render.vhd:106 PROM 2R timing signals — also in MAME: 2R namco/bosco.cpp:862
rtl/bosco_video_render.vhd:110 PROM 7H timing signals — also in MAME: 7H namco/bosco.cpp:868
rtl/bosco_video_render.vhd:302 The 07xx and the 2R PROM produce the following sync timings: HSync: the 07xx HSync output is ignored; timing comes from PROM 2R. — also in MAME: 07xx namco/bosco.cpp:21, 2R namco/bosco.cpp:862, 07xx namco/bosco.cpp:21, 2R namco/bosco.cpp:862
rtl/bosco_video_render.vhd:840 The CS (active low) for RAM 4J is low when either: * hblank_xx is low (we are displaying a line) * or nand_3N_outpin8 is low (we are writing a sprite to RAM) — also in MAME: 4J namco/galaga.cpp:1245
rtl/bosco_video_render.vhd:1006 5A: PAL (BS-8) 5A has not been dumped as far as I'm aware, so its function here is inferred from the inputs it is given and the output it is supposed to produce (based on comparisons to MAME.) — also in MAME: 5A namco/bosco.cpp:504, 5A namco/bosco.cpp:504

Cites MAME source — 12

rtl/bosco_video_render.vhd:1006 5A: PAL (BS-8) 5A has not been dumped as far as I'm aware, so its function here is inferred from the inputs it is given and the output it is supposed to produce (based on comparisons to MAME.)
rtl/bosconian.vhd:1 TODO - MAME runs the 50xx, 51xx, and 54xx at MASTER_CLOCK/12, or 1.536 MHz.
rtl/bosconian.vhd:6 TODO - The 06xx in MAME runs at MASTER_CLOCK/6/64, which is very slow compared to what I have?
rtl/bosconian.vhd:30 Features : TV 15KHz mode only (atm) Coctail mode ok Sound ok Starfield from MAME information
rtl/bosconian.vhd:50 Namco 05XX Starfield 4 sets, 63 stars/set, 2 set displayed at one time for blinking 6bits colors: 2red/2green/2blue full emulation in vhdl (from MAME information)
rtl/bosconian.vhd:429 Not sure why yet - may be related to the shot sound regression they saw in MAME (and fixed by manually extending the 54xx IRQ duration.)
rtl/bosconian.vhd:964 cs50xx #0 - part of the main board MAME sources says that Bosconian is the only game to use the 50xx "to its full potential".
rtl/bosconian.vhd:1132 The division by 32 for the timer is a guess, originally made by MAME
rtl/bosconian.vhd:1417 shared work RAM 1 - 0x7800-0x7FFF - called "share1" in MAME implementation
rtl/namco_06xx.vhd:5 From MAME documentation:
rtl/namco_06xx.vhd:136 NOTE: MAME checks for the individual bits, without caring whether or not the last four bits are one-hot.
rtl/namco_06xx.vhd:227 NOTE: I'm not seeing yet how this is implemented in MAME.

Shares text with the MAME driver without saying so — 29

rtl/bosconian.vhd:328 reset sub and sound CPU, and 5Xxx chips on main board — shares text with namco/bosco.cpp:84
rtl/bosconian.vhd:329 reset 5Xxx chips on video board — shares text with namco/bosco.cpp:117
rtl/bosconian.vhd:596 10011----000xxxx W ----xxxx SOWR bullets shape and X pos msb — shares text with namco/bosco.cpp:102
rtl/bosconian.vhd:599 10011----001---- W xxxxxxxx POSI X playfield X scroll — shares text with namco/bosco.cpp:103
rtl/bosconian.vhd:603 10011----010---- W xxxxxxxx POSI Y playfield Y scroll — shares text with namco/bosco.cpp:104
rtl/bosconian.vhd:607 10011----011---- W -----xxx STAR to 05XX: starfield X scroll speed — shares text with namco/bosco.cpp:105
rtl/bosconian.vhd:608 10011----011---- W --xxx--- STAR to 05XX: starfield Y scroll speed — shares text with namco/bosco.cpp:105
rtl/bosconian.vhd:613 10011----100---- W -------- STARCLR to 05XX: starfield enable(?) — shares text with namco/bosco.cpp:107
rtl/bosconian.vhd:618 10011----111-000 W -------x FLIP flip screen — shares text with namco/bosco.cpp:110
rtl/bosconian.vhd:622 10011----111-100 W -------x BLK 0 \ to 05XX: starfield blink — shares text with namco/bosco.cpp:114
rtl/bosconian.vhd:623 10011----111-101 W -------x BLK 1 / (select active subset) — shares text with namco/bosco.cpp:115
rtl/bosconian.vhd:629 10011----111-111 W -------x RESET reset 5xXX chips on video board — shares text with namco/bosco.cpp:117
rtl/bosconian.vhd:1246 In Bosconian, address lines 15-12 (52xx pins 17-20) are direct active-low chip enables. — shares text with namco/namco52.cpp:42
rtl/bosconian.vhd:1374 Tilemap RAM 1: tile code (1st half is radar + sprite registers; 2nd half is scrolling playfield) — shares text with namco/bosco.cpp:123
rtl/bosconian.vhd:1385 Tilemap RAM 2: tile attribute (1st half is radar + sprite registers; 2nd half is scrolling playfield) — shares text with namco/bosco.cpp:123
rtl/namco_06xx.vhd:7 This chip is used as an interface to up to 4 other custom chips. — shares text with namco/namco06.cpp:7
rtl/namco_06xx.vhd:8 It signals IRQs to the custom MCUs when writes happen, and generates — shares text with namco/namco06.cpp:8
rtl/namco_06xx.vhd:9 NMIs to the controlling CPU to drive reads based on a clock. — shares text with namco/namco06.cpp:9
rtl/namco_06xx.vhd:11 It uses a clock divider that's used to pulse the NMI and custom chip select — shares text with namco/namco06.cpp:11
rtl/namco_06xx.vhd:14 The control register controls chip as such: the low 4 bits are chip selects — shares text with namco/namco06.cpp:14
rtl/namco_06xx.vhd:15 (active high), the 5th bit is read/!write, and the upper 3 bits are the — shares text with namco/namco06.cpp:15
rtl/namco_06xx.vhd:18 SD0-SD7 are data I/O lines connecting to the controlling CPU — shares text with namco/namco06.cpp:18
rtl/namco_06xx.vhd:19 SEL selects either control (1) or data (0), usually connected to — shares text with namco/namco06.cpp:19
rtl/namco_06xx.vhd:20 an address line of the controlling CPU — shares text with namco/namco06.cpp:20
rtl/namco_06xx.vhd:21 /NMI is an NMI signal line for the controlling CPU — shares text with namco/namco06.cpp:21
rtl/namco_06xx.vhd:23 ID0-ID7 are data I/O lines connecting to the other custom chips — shares text with namco/namco06.cpp:23
rtl/namco_06xx.vhd:24 /IO1-/IO4 are IRQ signal lines for each custom chip — shares text with namco/namco06.cpp:24
rtl/namco_06xx.vhd:43 [1] on polepos, galaga, xevious, and bosco: connected to K3 of the 51xx — shares text with namco/namco06.cpp:43
rtl/namco_06xx.vhd:44 on bosco and xevious, connected to R8 of the 50xx — shares text with namco/namco06.cpp:44

Breakout#
Breakout
MiSTer-devel/Arcade-Breakout_MiSTer @ e0132557
MAME compared: atari/pong.cpp + 8 related file(s)
Read: 40 HDL files, 3,137 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

15%

Statements: 1 toward hardware

Cites hardware documentation that MAME's driver does not — 1

Arcade-Breakout.sv:3 Based on Rev.F schematics

BubSys#
TwinBee (Bubble System)
MiSTer-devel/Arcade-BubSys_MiSTer @ 3959a820
MAME driver: not found
Read: 38 HDL files, 15,595 lines (Quartus project)

MiSTer official

Mostly hardware

low

38%

Statements: 6 toward hardware, 5 toward MAME

Cites hardware documentation that MAME's driver does not — 5

rtl/BubSys_emu.v:64 0x0004_3200 0x0000_0100 2a 400-a01 82S129 BRAM wavetable
rtl/BubSys_emu.v:65 0x0004_3300 0x0000_0100 1a 400-a02 82S129 BRAM wavetable
rtl/ipcores/K005297/K005297.v:74 Konami 005296/005297 Bubble Memory Controller(BMC) cell level implementation based on the die shot below:
rtl/ipcores/K005297/K005297.v:76 Die shot: https://www.siliconpr0n.org/archive/doku.php?id=caps0ff:konami:005297
README.md:2 Current status: Fixable, custom chip known as K005295 will be decapped.

Ships hardware documentation files — 1

resources/BubbleSystem_schematics.pdf

Cites MAME source — 5

BubSys.sv:378 Bubble System resistor network gamma LUT, caculated by MAME's resnet.cpp
rtl/BubSys_emu.v:60 start addr length comp num mame rom parts num location description
rtl/BubSys_sound.v:321 MAME PSG1(4F on the board)
rtl/BubSys_sound.v:347 MAME PSG2(4H on the board)
rtl/GX400_video/K005293.v:180 The chip showed us a total of 26 results and suggested that the source of MAME was a very empirical result.

BubSysROM#
Gradius (ROM version), Galactic Warriors, TwinBee
MiSTer-devel/Arcade-BubSysROM_MiSTer @ eb372c15
MAME compared: konami/nemesis.cpp + 3 related file(s)
Read: 36 HDL files, 12,455 lines (Quartus project)

MiSTer official

Both

low

56%

Statements: 4 toward hardware, 11 toward MAME

Cites hardware documentation that MAME's driver does not — 3

rtl/BubSysROM_emu.v:62 0x0005_2000 0x0000_0100 2j 400-a01 82S129 BRAM wavetable
rtl/BubSysROM_emu.v:63 0x0005_2100 0x0000_0100 3j 400-a02 82S129 BRAM wavetable
README.md:2 Current status: Fixable, custom chip known as K005295 will be decapped.

Ships hardware documentation files — 1

resources/BubbleSystemROM_schematics.pdf

Cites MAME source — 5

BubSysROM.sv:361 Bubble System resistor network gamma LUT, caculated by MAME's resnet.cpp
rtl/BubSysROM_emu.v:56 start addr length comp num mame rom parts num location description
rtl/BubSysROM_sound.v:326 MAME PSG1(4F on the board)
rtl/BubSysROM_sound.v:352 MAME PSG2(4H on the board)
rtl/GX400_video/K005293.v:180 The chip showed us a total of 26 results and suggested that the source of MAME was a very empirical result.

Shares text with the MAME driver without saying so — 6

BubSysROM.sv:213 0 1 2 3 4 5 6 — shares text with konami/nemesis.cpp:2898
rtl/GX400_video/GX400_video.v:294 FETCHES HSCROLL(1 PIXEL ROW) VALUE WHEN VCLK = 1 MCLK 0 1 2 3 4 5 0 1 2 3 4 5 CLK18M _|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_| — shares text with konami/nemesis.cpp
rtl/GX400_video/GX400_video.v:438 MCLK 0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5 CLK18M _|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯ — shares text with konami/nemesis.cpp
rtl/GX400_video/GX400_video.v:681 MCLK 1 1 0 1 2 3 4 5 6 7 8 9 0 1 CLK18M _|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯ — shares text with konami/nemesis.cpp:2898
rtl/GX400_video/K005290.v:38 pixel 0 1 2 3 4 5 6 7 1H _|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯| 2H ___|¯¯¯ — shares text with konami/nemesis.cpp:2898
rtl/ipcores/vlm5030_gl/vlm5030_gl.vhd:1343 9 8 7 6 5 4 3 2 1 0 — shares text with konami/nemesis.cpp:279

BurgerTime#
Burger Time
MiSTer-devel/Arcade-BurgerTime_MiSTer @ d7cdb626
MAME compared: dataeast/btime.cpp + 4 related file(s)
Read: 11 HDL files, 4,610 lines (Quartus project)

MiSTer official

Mostly MAME

low

32%

Statements: 1 toward hardware, 17 toward MAME

Cites hardware documentation that MAME's driver does not — 1

rtl/burger_time.vhd:241 make hcnt and vcnt video scanner (from schematics !)

Cites MAME source — 1

rtl/YM2149_linmix_sep.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA

Shares text with the MAME driver without saying so — 16

rtl/burger_time.vhd:273 ROM_LOAD( "aa04.9b", 0xc000, 0x1000, CRC(368a25b5) SHA1(ed3f3712423979dcb351941fa85dce6a0a7bb16b) ) — shares text with dataeast/btime.cpp:2548
rtl/burger_time.vhd:274 ROM_LOAD( "aa06.13b", 0xd000, 0x1000, CRC(b4ba400d) SHA1(8c77397e934907bc47a739f263196a0f2f81ba3d) ) — shares text with dataeast/btime.cpp:2549
rtl/burger_time.vhd:275 ROM_LOAD( "aa05.10b", 0xe000, 0x1000, CRC(8005bffa) SHA1(d0da4e360039f6a8d8142a4e8e05c1f90c0af68a) ) — shares text with dataeast/btime.cpp:2550
rtl/burger_time.vhd:276 ROM_LOAD( "aa07.15b", 0xf000, 0x1000, CRC(086440ad) SHA1(4a32bc92f8ff5fbe112f56e62d2c03da8851a7b9) ) — shares text with dataeast/btime.cpp:2551
rtl/burger_time.vhd:279 ROM_LOAD( "ab14.12h", 0xe000, 0x1000, CRC(f55e5211) SHA1(27940026d0c6212d1138d2fd88880df697218627) ) — shares text with dataeast/btime.cpp:2554
rtl/burger_time.vhd:282 ROM_LOAD( "aa12.7k", 0x0000, 0x1000, CRC(c4617243) SHA1(24204d591aa2c264a852ee9ba8c4be63efd97728) ) /* charset #1 */ — shares text with dataeast/btime.cpp:2557
rtl/burger_time.vhd:283 ROM_LOAD( "ab13.9k", 0x1000, 0x1000, CRC(ac01042f) SHA1(e64b6381a9298eaf74e79fa5f1ea8e9596c58a49) ) — shares text with dataeast/btime.cpp:2558
rtl/burger_time.vhd:284 ROM_LOAD( "ab10.10k", 0x2000, 0x1000, CRC(854a872a) SHA1(3d2ecfd54a5a9d68b53cf4b4ee1f2daa6aef2123) ) — shares text with dataeast/btime.cpp:2559
rtl/burger_time.vhd:285 ROM_LOAD( "ab11.12k", 0x3000, 0x1000, CRC(d4848014) SHA1(0a55b091cd4e7f317c35defe13d5051b26042eee) ) — shares text with dataeast/btime.cpp:2560
rtl/burger_time.vhd:286 ROM_LOAD( "aa8.13k", 0x4000, 0x1000, CRC(8650c788) SHA1(d9b1ee2d1f2fd66705d497c80252861b49aa9254) ) — shares text with dataeast/btime.cpp:2561
rtl/burger_time.vhd:287 ROM_LOAD( "ab9.15k", 0x5000, 0x1000, CRC(8dec15e6) SHA1(b72633de6268ce16742bba4dcba835df860d6c2f) ) — shares text with dataeast/btime.cpp:2562
rtl/burger_time.vhd:290 ROM_LOAD( "ab00.1b", 0x0000, 0x0800, CRC(c7a14485) SHA1(6a0a8e6b7860859f22daa33634e34fbf91387659) ) /* charset #2 */ — shares text with dataeast/btime.cpp:2565
rtl/burger_time.vhd:291 ROM_LOAD( "ab01.3b", 0x0800, 0x0800, CRC(25b49078) SHA1(4abdcbd4f3362c3e4463a1274731289f1a72d2e6) ) — shares text with dataeast/btime.cpp:2566
rtl/burger_time.vhd:292 ROM_LOAD( "ab02.4b", 0x1000, 0x0800, CRC(b8ef56c3) SHA1(4a03bf011dc1fb2902f42587b1174b880cf06df1) ) — shares text with dataeast/btime.cpp:2567
rtl/burger_time.vhd:294 ROM_REGION( 0x0800, "bg_map", 0 ) /* background tilemaps */ — shares text with dataeast/btime.cpp:2569
rtl/burger_time.vhd:295 ROM_LOAD( "ab03.6b", 0x0000, 0x0800, CRC(d26bc1f3) SHA1(737af6e264183a1f151f277a07cf250d6abb3fd8) ) — shares text with dataeast/btime.cpp:2570

BurningRubber#
Burnin' Rubber
MiSTer-devel/Arcade-BurningRubber_MiSTer @ 55212a97
MAME compared: dataeast/btime.cpp + 4 related file(s)
Read: 11 HDL files, 4,488 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

33%

Statements: 1 toward hardware, 10 toward MAME

Cites hardware documentation that MAME's driver does not — 1

rtl/burnin_rubber.vhd:248 make hcnt and vcnt video scanner (from schematics !)

Cites MAME source — 1

rtl/YM2149_linmix_sep.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA

Shares text with the MAME driver without saying so — 9

rtl/burnin_rubber.vhd:291 /* a000-bfff space for the service ROM */ — shares text with dataeast/btime.cpp:2862
rtl/burnin_rubber.vhd:292 ROM_LOAD( "brubber.12c", 0xc000, 0x2000, CRC(b5279c70) SHA1(5fb1c50040dc4e9444aed440e2c3cf4c79b72311) ) — shares text with dataeast/btime.cpp:2863
rtl/burnin_rubber.vhd:293 ROM_LOAD( "brubber.12d", 0xe000, 0x2000, CRC(b2ce51f5) SHA1(5e38ea24bcafef1faba023def96532abd6f97d38) ) — shares text with dataeast/btime.cpp:2864
rtl/burnin_rubber.vhd:296 ROM_LOAD( "bnj6c.bin", 0xe000, 0x1000, CRC(8c02f662) SHA1(1279d564e65fd3ccac25b1f9fbb40d910de2b544) ) — shares text with dataeast/btime.cpp:2867
rtl/burnin_rubber.vhd:299 ROM_LOAD( "bnj4e.bin", 0x0000, 0x2000, CRC(b864d082) SHA1(cacf71fa6c0f7121d077381a0ff6222f534295ab) ) — shares text with dataeast/btime.cpp:2870
rtl/burnin_rubber.vhd:300 ROM_LOAD( "bnj4f.bin", 0x2000, 0x2000, CRC(6c31d77a) SHA1(5e52554f594f569527af4768d244cc40a7b4460a) ) — shares text with dataeast/btime.cpp:2871
rtl/burnin_rubber.vhd:301 ROM_LOAD( "bnj4h.bin", 0x4000, 0x2000, CRC(5824e6fb) SHA1(e98f0eb476b8f033f5cc70a6e503afc4e651fd45) ) — shares text with dataeast/btime.cpp:2872
rtl/burnin_rubber.vhd:304 ROM_LOAD( "bnj10e.bin", 0x0000, 0x1000, CRC(f4e9eb49) SHA1(b356512d2ebd4e2005e76496b434e5ecebadb251) ) — shares text with dataeast/btime.cpp:2875
rtl/burnin_rubber.vhd:305 ROM_LOAD( "bnj10f.bin", 0x1000, 0x1000, CRC(a9ffacb4) SHA1(49d5f9c0b695f474197fbb761bacc065b6b5808a) ) — shares text with dataeast/btime.cpp:2876

CanyonBomber#
Canyon Bomber
MiSTer-devel/Arcade-CanyonBomber_MiSTer @ 0e83812f
MAME compared: atari/canyon.cpp + 2 related file(s)
Read: 18 HDL files, 4,890 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

13%

Statements: 4 toward hardware

Cites hardware documentation that MAME's driver does not — 4

rtl/cpu_mem.vhd:424 74LS153 dual selector/multiplexer at H7 reads configuration DIP switches
rtl/cpu_mem.vhd:436 74LS153 dual selector/multiplexer at K8 reads Fire buttons
rtl/cpu_mem.vhd:447 Steer and Thrust inputs are shown on schematic connected to this selector but not used by Canyon Bomber.
rtl/playfield.vhd:123 74LS195 video shift register

Cave#
DoDonPachi, DonPachi, ESP Ra.De., Dangun Feveron …
MiSTer-devel/Arcade-Cave_MiSTer @ 375d1843
MAME compared: atlus/cave.cpp + 4 related file(s)
Read: 75 HDL files, 47,400 lines (Quartus project)

MiSTer official

Mostly MAME

low

31%

Statements: 1 toward hardware, 4 toward MAME

Cites hardware documentation that MAME's driver does not — 1

rtl/cave/savestate/CavePwrInst2JT03.sv:2154 Trying to synthesize this memory as M-9K RAM in Altera devices

Cites MAME source — 2

rtl/cave/AudioMixer.sv:144 MAME's routing is PSG A/B/C at 0.40, FM at 0.80, OKI0 at 0.80, and OKI1 at 1.00; these anchors account for the implementations' differing raw scales.
rtl/cave/savestate/CavePwrInst2JT03.sv:10900 same values as in MAME

Says it was translated, ported or taken from MAME — 2

README.md:22 | [**Power Instinct 2**](http://adb.arcadeitalia.net/dettaglio_mame.php?game_name=pwrinst2&arcade_only=0&autosearch=1) | WIP | Based on Mame - No hardware-accu
README.md:23 | [**Gogetsuji Legends**](http://adb.arcadeitalia.net/dettaglio_mame.php?game_name=plegends&arcade_only=0&autosearch=1) | WIP | Based on Mame - No hardware-accu

CaveBanpresto#
Akuu Gallet, Hotdog Storm, Mazinger Z, Oni - The Ninja Master …
MiSTer-devel/Arcade-CaveBanpresto_MiSTer @ 26ecac93
MAME compared: atlus/cave.cpp + 4 related file(s)
Read: 109 HDL files, 74,290 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

22%

Statements: 1 toward hardware, 4 toward MAME

Cites hardware documentation that MAME's driver does not — 1

rtl/cave/savestate/CaveBanprestoJT03Exact.sv:2163 Trying to synthesize this memory as M-9K RAM in Altera devices

Cites MAME source — 4

rtl/cave/Sound.sv:374 The 32 MHz master-clock accumulator steps are fixed by the MAME 0.288 board profiles: 0x0873 ~= 1.056 MHz, 0x1000 = 2.000 MHz, and 0x10E5 ~= 2.112 MHz.
rtl/cave/savestate/CaveBanprestoJT03Exact.sv:10920 same values as in MAME
README.md:10 | Hotdog Storm | WIP | MAME-based. No hardware-accurate comparison made |
README.md:12 | Metamoqester | WIP | MAME-based. No hardware-accurate comparison made |

Centipede#
Centipede
MiSTer-devel/Arcade-Centipede_MiSTer @ 7f5d1636
MAME compared: atari/centiped.cpp + 2 related file(s)
Read: 25 HDL files, 6,579 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

18%

Statements: 2 toward hardware, 1 not counted

Cites hardware documentation that MAME's driver does not — 2

rtl/centipede.v:2 Atari Centipede, from the schematics
rtl/centipede.v:757 a guess, based on millipede schematics

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/centipede.v:336 136001-407.d1 2048 0 0000 0000 00000000 prog_rom_1 136001-408.e1 2048 2048 0000 1000 00000000 prog_rom_1 136001-409.fh1 2048 4096 0001 0000 00000000 prog_rom_1 136001-410.j1 2048 6144 0001 1000 00000000 prog_rom_1 136001-211.f7 2048 819 — also in MAME: 136001-407 atari/centiped.cpp:2031, 136001-408 atari/centiped.cpp:2032, 136001-409 atari/centiped.cpp:2033, 136001-410 atari/centiped.cpp:2034, 136001-211 atari/centiped.cpp:2037, 136001-212 atari/centiped.cpp:2038, 136001-213 atari/centiped.cpp:2041

Chameleon#
Chameleon
MiSTer-devel/Arcade-Chameleon_MiSTer @ 1a8da936
MAME compared: snk/lasso.cpp
Read: 13 HDL files, 5,470 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

25%

Statements: 1 toward hardware, 1 toward MAME

Cites hardware documentation that MAME's driver does not — 1

rtl/sn76489_audio.vhd:52 * The SN76489 datasheet * Insight gained from the AY-3-8910/YM-2149 die-shot and reverse-engineered schematics (similar audio chips from the same era).

Cites MAME source — 1

rtl/core.v:33 AUDIO CPU: 0.6MHz from MAME, too slow comparing to the original game MAIN CPU: 0.7MHz, good SN89: 3.5MHz, not sure!

ChampionBaseball#
Champion Base Ball, Champion Base Ball Part-2, Exciting Soccer II, Exciting Soccer …
MiSTer-devel/Arcade-ChampionBaseball_MiSTer @ 117c4a4a (matched by date)
MAME compared: alpha/champbas.cpp + 2 related file(s)
Read: 16 HDL files, 4,374 lines (Quartus project)

MiSTer official

Mostly MAME

medium

81%

Statements: 2 toward hardware, 95 toward MAME, 1 not counted

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/ChampionBaseball_MAIN.sv:173 LS259 mainlatch @ 9D (champbas.cpp:970-978), written with D0. — also in MAME: 9D alpha/champbas.cpp:970

Ships hardware documentation files — 2

Cites MAME source — 88

Arcade-ChampionBaseball.sv:208 champbas has THREE buttons (INPUT_PORTS champbas, champbas.cpp:761-771):
Arcade-ChampionBaseball.sv:254 MAME port assembly.
rtl/ChampionBaseball.sv:16 ---- controls, already assembled into MAME port order by the wrapper
rtl/ChampionBaseball.sv:233 Both boards are mono — one SPEAKER each (champbas.cpp:998, :1115)
rtl/ChampionBaseball_MAIN.sv:5 The AY lives at 0x7000-0x7001 on THIS board, not the sound board (champbas.cpp:579).
rtl/ChampionBaseball_MAIN.sv:18 ---- controls (active LOW at the port, as MAME reads them)
rtl/ChampionBaseball_MAIN.sv:78 Address decode — champbas_map (champbas.cpp:576)
rtl/ChampionBaseball_MAIN.sv:122 The MRA is already correct — it pads 0x1800 to place the ROM 0x7800-0x7FFF must also win over cs_ay: in MAME the later `.rom()` entry
rtl/ChampionBaseball_MAIN.sv:148 exctsccr adds a SECOND sprite position RAM at A040-A04F (champbas.cpp:645)
rtl/ChampionBaseball_MAIN.sv:173 LS259 mainlatch @ 9D (champbas.cpp:970-978), written with D0.
rtl/ChampionBaseball_MAIN.sv:222 wdog_cnt counts UP from a kick, so it is ALREADY MAME's (0x10 - counter): MAME's m_counter loads 0x10 and counts DOWN (watchdog.cpp:112 / :165).
rtl/ChampionBaseball_MAIN.sv:361 LS259 bit 6 -> mcu_start_w, bit 7 -> bus_dir_w (champbas.cpp:935-936).
rtl/ChampionBaseball_MAIN.sv:390 champbasja fake protection (champbas.cpp:532-563).
rtl/ChampionBaseball_SND.sv:4 The AY is on the MAIN board (champbas.cpp:579); this CPU never sees it.
rtl/ChampionBaseball_SND.sv:31 Address decode — champbas_sound_map (champbas.cpp:659) decodes it.
rtl/ChampionBaseball_SND.sv:52 Sound latch (MAME GENERIC_LATCH_8).
rtl/ChampionBaseball_SND.sv:152 MAME routes the AY at 0.3 and the DAC at 0.7 (:1002, :1004), so the
rtl/ChampionBaseball_VIDEO.sv:22 ---- control bits from the LS259 mainlatch (champbas.cpp:970-978)
rtl/ChampionBaseball_VIDEO.sv:46 champbas splits them across TWO memories: code/colour/flip in MAIN RAM 0x8FF0-0x8FFF (champbas.cpp:395-403)
rtl/ChampionBaseball_VIDEO.sv:87 first visible line (MAME visarea min_y)
rtl/ChampionBaseball_VIDEO.sv:88 one past last (MAME visarea max_y = 239)
rtl/ChampionBaseball_VIDEO.sv:296 champbas : colour = (attr & 0x1f) | 0x20 (champbas.cpp:348) exctsccr : colour = (attr & 0x0f) (champbas.cpp:356) Low 5 bits are stored either way; champbas's |0x20 is a constant
rtl/ChampionBaseball_VIDEO.sv:351 SPRITE ENGINE (champbas.cpp:387-418) 8 sprites, 16x16, 2bpp.
rtl/ChampionBaseball_VIDEO.sv:352 MAME iterates offs = 0x0E down to 0 step -2, code = (attr[offs] >> 2 & 0x3f) | (gfx_bank << 6) color = (attr[offs+1] & 0x1f) | (palette_bank << 6)
rtl/ChampionBaseball_VIDEO.sv:383 MAME draws 3bpp first then 4bpp, each offs 0x0E->0, so later writes win.
rtl/ChampionBaseball_VIDEO.sv:396 MAME draws the 4bpp bank with transpen_mask(gfx, colour, 0x10) ctabentry = (color_prom[0x100 + i] & 0x0f) | 0x10 that MAME drops were drawn in colour-index 0x10 — the black masks
rtl/ChampionBaseball_VIDEO.sv:414 MAME order: 7 first, 0 last
rtl/ChampionBaseball_VIDEO.sv:434 MEASURED, not derived: comparing "FPGA - Soccer 2.png" against height where MAME has them at 0.60-0.65 — a MIRROR (0.60->0.40), not a shift — and the trophy sign moves left->right.
rtl/ChampionBaseball_VIDEO.sv:467 Talbot's gfx1/gfx2 are 0x1000 each (champbas: 0x2000 each), so the MRA's sprite code is 6 bits -- MAME masks 0x3f and talbot nops gfxbank
rtl/ChampionBaseball_VIDEO.sv:583 exctsccr indexes its LUT through a bitswap (champbas.cpp:324):
rtl/ChampionBaseball_VIDEO.sv:589 exctsccr_palette (champbas.cpp:329-334) splits the pen space in two: pens 0x000-0x0FF (chars + 3bpp sprites): ctabentry = (color_prom[bitswap(i)] & 0x0f) | ((i & 0x80) >> 3) pens 0x100-0x1FF (4bpp sprites, :330): ctabentry = (color_prom[0x1
rtl/ChampionBaseball_VIDEO.sv:619 Resistor-network DAC (champbas.cpp:243-251) 0x21 / 0x47 / 0x97 triple (the same constants exctsccr_palette :301 0x51 / 0xAE.
rtl/ChampionBaseball_VIDEO.sv:640 champbas normalises its (champbas.cpp:310-313), so its blue tops out at 0xDE rather than 0xFF.
rtl/ExcitingSoccer_SND.sv:226 MAME (:1120-1129): each AY 0.08, each DAC 0.3
rtl/cpu/hmcs40/alpha8201.sv:8 mcu_start / bus_dir <- LS259 mainlatch Q6/Q7 (champbas.cpp:935-936) ext_* <- champbas_map 0x6000-0x63FF shared RAM mcu_addr / mcu_data -> champbas_rom's 13-bit MCU ROM port CEN_DIV generates the machine-cycle enable; pause
rtl/cpu/hmcs40/alpha8201.sv:21 Z80-side control (LS259 mainlatch, champbas.cpp:935-936)
rtl/cpu/hmcs40/alpha8201.sv:119 mcu_update_address() (alpha8201.cpp:357-361): m_mcu_address = (m_mcu_d<<8 & 0x300) | m_mcu_r[2]<<4 | m_mcu_r[3];
rtl/cpu/hmcs40/alpha8201.sv:124 mcu_data_r gate, alpha8201.cpp:368
rtl/cpu/hmcs40/alpha8201.sv:125 mcu_writeram gate, alpha8201.cpp:353
rtl/cpu/hmcs40/alpha8201.sv:133 Z80 side — unconditional (alpha8201.cpp:418-428 comment: "going by
rtl/cpu/hmcs40/alpha8201.sv:136 MCU side — read (mcu_data_r, alpha8201.cpp:364-376): R0 gets the
rtl/cpu/hmcs40/alpha8201.sv:138 R-PORT-READBACK-FIX-2026-08-07 (part 2): MAME read_r() (hmcs40.cpp:387-396) IS_CMOS (hmcs40.cpp:123), so m_polarity is truthy -> the AND branch.
rtl/cpu/hmcs40/alpha8201.sv:144 MCU side — write (mcu_writeram, alpha8201.cpp:350-355).
rtl/cpu/hmcs40/alpha8201.sv:149 MAME, not two.
rtl/cpu/hmcs40/alpha8201.sv:149 Both port writers funnel through mcu_update_address(): mcu_data_w() (write_r<0..3>, alpha8201.cpp:378-384) -> update_address -> writeram
rtl/cpu/hmcs40/alpha8201.sv:174 pin 19 !HLT tied to Vcc — never halted (alpha8201.cpp:52)
rtl/cpu/hmcs40/alpha8201.sv:181 R2-R7 have NO read_r<> bind in device_add_mconfig, so they take MAME's on at $0ECF -> "TESTING 6" hangs forever.
rtl/cpu/hmcs40/alpha8201.sv:189 (alpha8201.cpp:329 binds write_d only), and the core already applies
rtl/cpu/hmcs40/alpha8201.sv:196 pin 30 INT0 = GO (alpha8201.cpp:57)
rtl/cpu/hmcs40/alpha8201.sv:197 pin 31 INT1 = n.c. (alpha8201.cpp:58)
rtl/cpu/hmcs40/hmcs40.sv:11 HD44801 = HMCS44 family (hmcs40.cpp:46, :113-128): stack_levels = 4, pcwidth = 11, prgwidth = 12 (program_2k, 4096 words), datawidth = 8, data_160x4 (160 x 4-bit RAM), polarity = CMOS.
rtl/cpu/hmcs40/hmcs40.sv:16 cen : one clk-wide pulse per machine cycle, generated by the WRAPPER, not here — one cen per MAME cycle() call (hmcs40.cpp:647-651).
rtl/cpu/hmcs40/hmcs40.sv:21 Approximation: an INT1-edge counter bump (hmcs40.cpp:598-599) landing on an FSM commit edge is dropped.
rtl/cpu/hmcs40/hmcs40.sv:30 HMCS40_INPUT_LINE_HLT (hmcs40.cpp:578) — active high halts the core
rtl/cpu/hmcs40/hmcs40.sv:42 D0-D15 discrete i/o (hmcs40.cpp:406-424).
rtl/cpu/hmcs40/hmcs40.sv:47 This is MAME's `m_write_d(...)` callback -> alpha_8201_device::mcu_d_w(),
rtl/cpu/hmcs40/hmcs40.sv:50 MAME binds write_r<0..3> to alpha_8201_device::mcu_data_w(), which calls mcu_update_address() -> mcu_writeram().
rtl/cpu/hmcs40/hmcs40.sv:55 INT0/INT1 pins (HMCS40_INPUT_LINE_INT0/1, hmcs40.cpp:573-603)
rtl/cpu/hmcs40/hmcs40.sv:59 debug/observability (not part of the MAME model — added for the
rtl/cpu/hmcs40/hmcs40.sv:96 LPU-latched upper bits (hmcs40op.cpp:462-476)
rtl/cpu/hmcs40/hmcs40.sv:99 hardware call stack (hmcs40op.cpp:24-36)
rtl/cpu/hmcs40/hmcs40.sv:163 Step1(LPU fixup)+Step2(shift regs)+Step3(int check) — hmcs40.cpp:663-676
rtl/cpu/hmcs40/hmcs40.sv:164 wait for cen: push_stack + redirect to vector (take_interrupt, hmcs40.cpp:551-571)
rtl/cpu/hmcs40/hmcs40.sv:171 reversed 4-bit immediate (hmcs40.cpp:681, m_i)
rtl/cpu/hmcs40/hmcs40.sv:180 LFSR PC increment — bit-exact transcription of hmcs40.cpp:632-645
rtl/cpu/hmcs40/hmcs40.sv:241 -- register-to-register (hmcs40op.cpp:49-99) ----------
rtl/cpu/hmcs40/hmcs40.sv:252 -- RAM address instructions (hmcs40op.cpp:104-173) ----
rtl/cpu/hmcs40/hmcs40.sv:266 -- RAM register instructions (hmcs40op.cpp:178-224),
rtl/cpu/hmcs40/hmcs40.sv:300 -- immediate instructions (hmcs40op.cpp:229-246) ------
rtl/cpu/hmcs40/hmcs40.sv:308 -- arithmetic (hmcs40op.cpp:251-369) -------------------
rtl/cpu/hmcs40/hmcs40.sv:334 -- compare (hmcs40op.cpp:374-414), all set S only ------
rtl/cpu/hmcs40/hmcs40.sv:343 -- RAM bit manipulation (hmcs40op.cpp:419-435) ---------
rtl/cpu/hmcs40/hmcs40.sv:348 -- ROM address instructions (hmcs40op.cpp:440-489) -----
rtl/cpu/hmcs40/hmcs40.sv:375 -- interrupt instructions (hmcs40op.cpp:494-609) -------
rtl/cpu/hmcs40/hmcs40.sv:396 -- input/output (hmcs40op.cpp:614-690) -----------------
rtl/cpu/hmcs40/hmcs40.sv:412 I_ILL — hmcs40op.cpp:41-44, no state change beyond pc advance
rtl/cpu/hmcs40/hmcs40.sv:447 P write-back (hmcs40op.cpp:673-689), applied once the pattern word
rtl/cpu/hmcs40/hmcs40.sv:475 hmcs40.cpp:273-290 device_reset(): cf/ie/iri/irt=0, if0/if1/tf=1
rtl/cpu/hmcs40/hmcs40.sv:495 hmcs40.cpp:656-661: internal clock stopped, nothing advances
rtl/cpu/hmcs40/hmcs40.sv:517 consumed unconditionally, hmcs40.cpp:676
rtl/cpu/hmcs40/hmcs40.sv:520 take_interrupt() (hmcs40.cpp:551-571): push return addr,
rtl/cpu/hmcs40/hmcs40.sv:613 cycle()->clock_prescaler() (hmcs40.cpp:618-625): normal
rtl/ram_rom/champbas_rom.sv:63 Index 0 — maincpu: MAME ROM_REGION "maincpu", main Z80 program.
rtl/ram_rom/champbas_rom.sv:80 Index 1 — audiocpu: MAME ROM_REGION "audiocpu", audio Z80 program.
rtl/ram_rom/champbas_rom.sv:97 Index 2 — gfx_p01: MAME ROM_REGION "gfx1"/"gfx2", planes 0/1 of an address bit downstream (0x2000 for champbas family, 0x1000 for
rtl/ram_rom/champbas_rom.sv:114 Index 6 — mcu: MAME ROM_REGION "alpha_8201:mcu", ALPHA-8201/8302/8303
rtl/ram_rom/champbas_rom.sv:130 Index 7 — prom: MAME ROM_REGION "proms", colour PROMs (palette + pen->color LUT, one or two PROMs depending on set).
rtl/ram_rom/champbas_rom.sv:165 Index 9 — gfx3: MAME ROM_REGION "gfx3", 4bpp sprites.

Says it matches, follows or was checked against MAME — 2

rtl/ChampionBaseball_MAIN.sv:140 A[7:6] picks the quadrant, matching MAME's A000/A040/A080/A0C0.
rtl/ChampionBaseball_MAIN.sv:209 16 vblanks without an $A0C0 kick resets the CPU side (MAME: Without it the boot spin at $003F ("jr c,$003F", a jump to itself) never ends, and wdog_cnt runs past 0x10 so the bit-2 readback stops matching MAME -- which is the bit Talbot's MC

Says it was translated, ported or taken from MAME — 2

rtl/cpu/hmcs40/alpha8201.sv:6 Ported from MAME's alpha8201.cpp (license BSD-3-Clause, copyright hap).
rtl/cpu/hmcs40/hmcs40.sv:6 Ported from MAME's cpu/hmcs40/{hmcs40.cpp,hmcs40op.cpp,hmcs40.h} (license BSD-3-Clause, copyright hap), staged under Useful Information/mame/cpu/hmcs40/.

Shares text with the MAME driver without saying so — 3

rtl/ChampionBaseball_VIDEO.sv:397 ctabentry = (color_prom[0x100 + i] & 0x0f) | 0x10 — shares text with alpha/champbas.cpp:332
rtl/ChampionBaseball_VIDEO.sv:576 ctabentry = (lut[i & 0xff] & 0x0f) | ((i & 0x100) >> 4) — shares text with alpha/champbas.cpp:282
rtl/ChampionBaseball_VIDEO.sv:593 ctabentry = (color_prom[0x100 + i] & 0x0f) | 0x10 — shares text with alpha/champbas.cpp:332

ChinaGate#
Sai Yu Gou Ma Roku
MiSTer-devel/Arcade-ChinaGate_MiSTer @ d6d7cb31
MAME compared: technos/chinagat.cpp + 2 related file(s)
Read: 20 HDL files, 5,384 lines (Quartus project)

MiSTer official

Mostly MAME

low

50%

Statements: 2 toward hardware, 36 toward MAME

Cites hardware documentation that MAME's driver does not — 2

rtl/chinagate/jtcg_main.sv:28 It exposes chip-select strobes and write data to the surrounding modules: - shared 8K RAM (with sub CPU) - FG vram, BG vram, sprite RAM, palette - banked + fixed program ROM and consumes: - cabinet inputs (P1, P2, SYSTEM) - DSW - read-back
rtl/chinagate/jtcg_shared_ram.sv:23 China Gate FPGA core Shared RAM 8K, dual-port, between main and sub CPU.

Cites MAME source — 29

ChinaGate.sv:560 Coin Gong (FM CH7) mode: Polite (25%, default) o MAME (100%) Polite: ch_tl_offset[7] = 16 (~-12 dB, attenua effetti CH7 troppo forti) MAME: ch_tl_offset[7] = 0 (passa TL del game invariato, come MAME) CH0..CH6 sempre invariati (offset 0).
ChinaGate.sv:801 OSD label "MAME,Polite" → 0=MAME (default), 1=Polite
ChinaGate.sv:828 In quella zona MAME mostra cornice nera del FG; mio FG ha pen=0 lì e mostra sprite/BG sotto.
rtl/chinagate/chinagate_audio.sv:76 Quando 0, comportamento MAME esatto.
rtl/chinagate/chinagate_audio.sv:295 Mixer: replica MAME chinagat (mono, gain 0.8 entrambi) + OSD vol
rtl/chinagate/chinagate_audio.sv:297 MAME normalization (verificato chinagat.cpp + ymfm_mame.h + okim6295.cpp): YM2151: output / 32768 → ±1.0 (16-bit a unità) OKI M6295: output / 2048 → ±1.0 per voce (acc 4 voci 14-bit) Per allineare OKI a YM: oki << 4 (×16 = 32768/2048).
rtl/chinagate/jtcg_colmix.sv:25 References: - chinagat.cpp:709-713 (gfx decode regions: chars=0,16; sprites=128,8; tiles=256,8) - ddragon_v.cpp:220-232 (drawing order: BG, sprites, FG) - crossref §6 (palette is xBGR_444, split lo/hi at $3000/$3400)
rtl/chinagate/jtcg_colmix.sv:35 Priority (hardcoded, MAME-correct): FG (pen != 0) > sprite (pen != 0) > BG
rtl/chinagate/jtcg_draw.sv:25 Disegna 16 pixel di una riga di tile 16x16 4bpp applicando il MAME chinagat tilelayout direttamente: per ogni X-quad q (0..3): fetch 1 word 16-bit da SDRAM @ word_addr = T*64 + q*16 + y byte_lo = SDRAM[2*word_addr] (j7/j8: planes 2,3)
rtl/chinagate/jtcg_draw.sv:123 perm 0123 (verificato tool tile_viewer su sprite reale code 0x08b6 color 1 vs MAME ground truth): p0 = byte_lo[bit_pos] p1 = byte_lo[bit_pos + 4] p2 = byte_hi[bit_pos] p3 = byte_hi[bit_pos + 4]
rtl/chinagate/jtcg_obj.sv:31 References: - ddragon_v.cpp::draw_sprites() in mame_ref/ - jtdd_obj.v in jtdd_ref/ - crossref_chinagate.md §6
rtl/chinagate/jtcg_obj.sv:39 - China Gate "sprite clip" wrap-around for negative coords [-15,-8] is not implemented yet; jtframe_objdraw's natural wrap handles -15..0 and 256..271 differently from MAME.
rtl/chinagate/jtcg_obj.sv:129 MAME draw_sprites: flipx = attr & 8 (= bit 3), flipy = attr & 4 (= bit 2).
rtl/chinagate/jtcg_obj.sv:138 mask del code in funzione di size (MAME draw_sprites: which &= ~size).
rtl/chinagate/jtcg_obj.sv:147 selector tile interno al metatile: bit 0 = top/bottom (sumy[4] inverso, top=0 bottom=1) MAME: size=1: top=which+0, bottom=which+1 → tile_y = ~ypos[4] in nostre coord RTL ChinaGate aveva: id[0] <= id[0] ^ ypos[4] → equivalente bit 1 = left/r
rtl/chinagate/jtcg_obj.sv:158 xpos: il tile sinistro è a xpos+dx (= xpos-16 con dx=-16, MAME), il tile destro a xpos.
rtl/chinagate/jtcg_obj.sv:159 Cioè: half_x=0 (left): xpos_draw = xpos - 16 (MAME: sx + dx) half_x=1 (right): xpos_draw = xpos (MAME: sx) Per size_x=0 c'è solo half_x=0 ma con xpos_draw = xpos (non shift).
rtl/chinagate/jtcg_obj.sv:238 MAME chinagat (ddragon_v.cpp:152-153): sx = 240 - byte4 + (X_MSB << 8) if (sx in [-15,-8]) sx += 256; // wrap MAME chinagat-specific Sottrazione 9-bit completa con borrow corretto.
rtl/chinagate/jtcg_obj.sv:242 Range wrap MAME: -15..-8 = 9'd497..9'd504 unsigned.
rtl/chinagate/jtcg_obj.sv:247 wrap a destra (MAME chinagat clip fix)
rtl/chinagate/jtcg_scroll.sv:25 Decodifica MAME chinagat tilelayout (16x16 4bpp, 64 byte/tile): - planes 2,3 nei primi 0x20000 byte SDRAM region (a-13 + a-12) - planes 0,1 negli 0x20000 byte successivi (a-15 + a-14) - byte_idx (within half) = T*64 + 16*qf + pyf - byte SDR
rtl/chinagate/jtcg_scroll.sv:158 Tiles ROM in BRAM locale (256KB = 2 x 128KB) tiles_dl_addr[17] = 0 → lo half (planes 2,3 according to MAME, ma con v32 confermato che è byte_HI nel decoder) tiles_dl_addr[17] = 1 → hi half (byte_LO nel decoder)
rtl/chinagate/jtcg_scroll.sv:163 hi half MAME = byte_lo
rtl/chinagate/jtcg_scroll.sv:164 lo half MAME = byte_hi
rtl/chinagate/jtcg_scroll.sv:168 dl_addr[17]=0 → MAME prima half → byte_hi nel decoder dl_addr[17]=1 → MAME seconda half → byte_lo nel decoder
rtl/chinagate/jtcg_video.sv:25 Decodifica MAME chinagat charlayout (8x8 4bpp, 32 byte/char): - 4 byte per row, byte_idx = T*32 + 8*qx + y (qx in 0..3, 2 pixel/byte) - 1 byte SDRAM = 2 pixel x 4 plane (planes interleavati) - pixel pari (left, subx=0): pen = {b[7], b[5]
README.md:10 The core reimplements the hardware in SystemVerilog from the MAME driver, the PCB schematics and pixel-accurate validation against MAME and original PCB footage
README.md:25 YM2151 FM (jt51) + OKI M6295 ADPCM (jt6295) with MAME-accurate mixer
README.md:122 The **MAME** project for invaluable hardware reference (chinagat.cpp, ddragon.cpp, ddragon_v.cpp).

Says it matches, follows or was checked against MAME — 1

rtl/chinagate/jtcg_draw.sv:39 Verificato 100% match MAME via _dev/scripts/tile_viewer.py (decoder xrev_perm_3210 + MRA US).

Shares text with the MAME driver without saying so — 6

ChinaGate.sv:198 "P3O[43:38],BG X Offset,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,-32,-31,-30,-29,-28,-27,-26,-25,-24,-23,-22,-21,-2 — shares text with technos/ddragon.cpp:230
ChinaGate.sv:199 "P3O[49:44],BG Y Offset,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,-32,-31,-30,-29,-28,-27,-26,-25,-24,-23,-22,-21,-2 — shares text with technos/ddragon.cpp:230
ChinaGate.sv:200 "P3O[55:50],FG X Offset,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,-32,-31,-30,-29,-28,-27,-26,-25,-24,-23,-22,-21,-2 — shares text with technos/ddragon.cpp:230
ChinaGate.sv:201 "P3O[61:56],FG Y Offset,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,-32,-31,-30,-29,-28,-27,-26,-25,-24,-23,-22,-21,-2 — shares text with technos/ddragon.cpp:230
ChinaGate.sv:202 "P3O[67:62],Sprite X Offset,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,-32,-31,-30,-29,-28,-27,-26,-25,-24,-23,-22,-2 — shares text with technos/ddragon.cpp:230
ChinaGate.sv:203 "P3O[73:68],Sprite Y Offset,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,-32,-31,-30,-29,-28,-27,-26,-25,-24,-23,-22,-2 — shares text with technos/ddragon.cpp:230

CityConnection#
City Connection
MiSTer-devel/Arcade-CityConnection_MiSTer @ 57407191
MAME compared: jaleco/citycon.cpp
Read: 22 HDL files, 9,262 lines (Quartus project)

MiSTer official

Mostly MAME

medium

42%

Statements: 8 toward hardware, 79 toward MAME, 3 not counted

Cites hardware documentation that MAME's driver does not — 8

rtl/citycon/pld/pal_h7.v:23 PAL H7 (CCP-1) — sprite line buffer sequencer (City Connection) Decompilazione JEDEC via jedutil → reference/pld_decoded/pal_h7_eqn.txt
rtl/citycon/pld/pal_l5.v:23 PAL L5 — funzione non ancora identificata (City Connection) Decompilazione JEDEC via jedutil → reference/pld_decoded/pal_l5_eqn.txt
rtl/citycon/pld/pal_l5.v:44 - i1, i2, i3 selezionano quale output attivare → 8 combinazioni = 1 per ognuno degli 8 output (decoder 3→8, simile a 74LS138).
rtl/citycon/pld/pal_u7.v:23 PAL U7 (CCP-2) — sync/timing generator (City Connection) Decompilazione JEDEC via jedutil → reference/pld_decoded/pal_u7_eqn.txt
rtl/citycon/pld/ttl_74ls157.v:2 74LS157 — Quad 2-to-1 multiplexer con select e enable 16-pin DIP.
rtl/citycon/pld/ttl_74ls161.v:2 74LS161 — Synchronous 4-bit binary counter with parallel load 16-pin DIP.
rtl/citycon/pld/ttl_74ls283.v:2 74LS283 — 4-bit binary full adder con carry-in/out 16-pin DIP.
rtl/citycon/pld/ttl_74ls86.v:2 74LS86 — Quad XOR gate 14-pin DIP.

Cites hardware references or measurements that MAME's driver also gives — 3

rtl/citycon/pld/prom_82s123.v:2 82S123 — Bipolar PROM 32 word × 8 bit (Signetics/TI/AMD) 16-pin DIP, 5 address (A0..A4), 8 output tri-state Sul PCB City Connection: N5 (address decoder CPU) e R4 (funzione ignota). — also in MAME: 82S123 jaleco/citycon.cpp:496
rtl/citycon/pld/prom_82s129.v:2 82S129 — Bipolar PROM 256 word × 4 bit (Signetics/TI/AMD) 16-pin DIP, 8 address (A0..A7), 4 output tri-state Sul PCB City Connection: L6 (funzione ignota). — also in MAME: 82S129 jaleco/citycon.cpp:498
rtl/citycon/pld/prom_82s129.v:6 Implementazione FPGA: simile a 82S123 ma 256×4. — also in MAME: 82S123 jaleco/citycon.cpp:496

Cites MAME source — 65

Template.sv:29 Sprite stage gate-level (PCB Jaleco): commentare per usare il renderer "MAME-style" originale del core.
Template.sv:201 Audio volume boost: 0=100% (default 1.5x MAME), 1=125%, 2=150%, 3=175%, 4=200%
Template.sv:280 Joystick → City Connection input mapping MAME P1 port (active-low): b7=START2, b6=START1, b5=FIRE2, b4=FIRE1, b3=LEFT, b2=RIGHT, b1=DOWN, b0=UP MiSTer joy: [0]=R [1]=L [2]=D [3]=U [4]=A(Fire) [5]=B(Jump) [10]=Start [11]=Coin
Template.sv:355 CHAR ROM BRAM (4KB source) ///////////// Region "chars" c4: MRA offset 0x14000-0x14FFF (usiamo solo primi 4KB, come fa init_citycon MAME).
Template.sv:359 Noi leggiamo src[i] e componiamo il byte espanso come MAME fa in init_citycon.
rtl/citycon/citycon_audio.sv:22 City Connection — Audio subsystem Reference MAME citycon.cpp:384-431, sound_map 244-251
rtl/citycon/citycon_audio.sv:37 soundlatch1 ($3001 main → audio) → YM2203 port A (read by audio CPU via YM2203) soundlatch2 ($3002 main → audio) → YM2203 port B AY8910 ports A/B: not connected (MAME default)
rtl/citycon/citycon_audio.sv:41 IRQ audio CPU = vblank rising edge (MAME: irq0_line_hold "actually unused")
rtl/citycon/citycon_audio.sv:49 edge for IRQ (MAME irq0_line_hold)
rtl/citycon/citycon_audio.sv:53 0=100% (1.5x MAME) ...
rtl/citycon/citycon_audio.sv:146 AY8910 (jt49) — address latch + jt49 instance MAME address_data_w: offs=0 latch addr (regnum), offs=1 write data
rtl/citycon/citycon_audio.sv:221 IRQ vblank (MAME irq0_line_hold "actually unused" ma cablato)
rtl/citycon/citycon_audio.sv:228 Quando audio CPU non lo serve (= MAME "actually unused"), nessuno legge IRQ ack register, quindi rilascio dopo 1 ck per evitare hang.
rtl/citycon/citycon_audio.sv:234 MIXER — MAME volumi: AY8910 mono = (A+B+C) × 0.40 YM2203 FM = fm_snd × 0.40 YM2203 PSG = psg_snd × 0.20 AY8910 outputs 8-bit (0..255), psg_snd 10-bit (0..1023), fm_snd signed 16-bit
rtl/citycon/citycon_audio.sv:240 Calcolo precisione: AY8910 sum 8+8+8 = 10-bit unsigned (0..765) ×0.40 ≈ ×102/256 (= 0.3984, errore 0.4%) — uso shift: ×102 / 256 con ×26 shift 6 = ×0.40625 Per restare nei valori MAME senza approssimazione bisogna usare moltiplicatori.
rtl/citycon/citycon_audio.sv:256 step | total scale vs MAME | AY/FM mul (0.40 base) | PSG mul (0.20 base)
rtl/citycon/citycon_top.sv:99 Clock enables (clk_sys = 40 MHz — MAME MASTER_CLOCK / 2) ce_pix = clk/8 = 5 MHz (MAME PIXEL_CLOCK esatto)
rtl/citycon/citycon_top.sv:101 ce_E = clk/32 = 1.25 MHz (MAME CPU_CLOCK esatto)
rtl/citycon/citycon_top.sv:115 ogni 20 clk → 2 MHz (MAME)
rtl/citycon/citycon_top.sv:156 Memory map (da citycon.cpp main_map): $0000-$0FFF WRAM (4KB) $1000-$1FFF FG VRAM (4KB) $2000-$27FF linecolor RAM (256B + mirror 0x700) $2800-$2FFF sprite RAM (256B + mirror 0x700) $3000 IN / background_w $3001 DSW1 r / sou
rtl/citycon/citycon_top.sv:263 Il +4 X era per compensare cliprect MAME 240 px; con area 256 px PCB non serve più.
rtl/citycon/citycon_video.sv:22 City Connection — video renderer (MAME-accurate, versione "step finale")
rtl/citycon/citycon_video.sv:24 Implementazione fedele a citycon.cpp: - FG 5bpp via expansion on-the-fly (crom_i/crom_k interface) - FG palette: virtual palette @ 640 + 4*scanline + pen[1:0] (MAME update loop) - BG 4bpp via two-half tilelayout (c6..c9 + planes 2/3 @ +0xC0
rtl/citycon/citycon_video.sv:145 CONVENZIONE COORDINATE UNIFICATA (Codex audit fix): screen_x = coord X in bitmap MAME (visibile 8..247) screen_y = coord Y in bitmap MAME (visibile 16..239) Tutti i layer usano queste coord.
rtl/citycon/citycon_video.sv:151 = bitmap_y MAME
rtl/citycon/citycon_video.sv:154 SCROLL per-row FG (MAME: rows 0..5 → 0, rows 6..31 → scroll_x)
rtl/citycon/citycon_video.sv:156 MAME: bitmap_y
rtl/citycon/citycon_video.sv:164 FG TILEMAP (MAME mapper) scan(col,row) = {col[6:5], row[4:0], col[4:0]} (12-bit) Pixel ROM (5bpp expansion): i_low = code*8 + r i_high = code*8 + r + 0x800 Per ogni mezzo-tile servono 3 byte (planes 0/1 in byte0, 2/3 in byte1, 4 in byte2)
rtl/citycon/citycon_video.sv:174 MAME: fg_col = bitmap_x + scroll.
rtl/citycon/citycon_video.sv:292 MAME drawgfx.cpp readbit: MSB-first.
rtl/citycon/citycon_video.sv:306 MAME char 5bpp pen = row_sub*4 + pen_visibile.
rtl/citycon/citycon_video.sv:316 BG TILEMAP (MAME) scan(col,row) = {col[6:5], row[4:0], col[4:0]} (stesso del FG) code_addr = 0x1000*bg_image + tile_index pal_addr = 0xC000 + 0x100*bg_image + code pix_addr: gfxset (3+bg_image) entry base = 0x2000*bg_image + code*8 + r (c
rtl/citycon/citycon_video.sv:325 MAME: bg_col = bitmap_x + scroll>>1
rtl/citycon/citycon_video.sv:328 MAME: bitmap_y
rtl/citycon/citycon_video.sv:383 BG pixel ROM layout (MAME tilelayout, 4bpp 8x8): base = (3 + bg_image) * 0x1000 + code*8 + row + (col<4 ?
rtl/citycon/citycon_video.sv:477 Extract BG 4bpp pen — MAME tilelayout planes = {4, 0, 0xC000*8+4, 0xC000*8+0} Convenzione MAME (src/emu/drawgfx.cpp): bit offset 0 = bit 7 del byte (MSB).
rtl/citycon/citycon_video.sv:487 MAME drawgfx.cpp readbit: src[n/8] & (0x80 >> (n%8)) → MSB-first bit order.
rtl/citycon/citycon_video.sv:501 SPRITE RENDERER (line buffer ping-pong, scanner FSM fedele MAME)
rtl/citycon/citycon_video.sv:515 Draw order MAME: dall'ultimo sprite al primo → il primo è "on top" (sovrascrive).
rtl/citycon/citycon_video.sv:538 MAME: sy = 239 - sy_raw.
rtl/citycon/citycon_video.sv:552 sprite_addr/sprrom_addr — mux MAME-style vs PCB-gate-level vedi blocco `ifdef SPRITE_GATE_LEVEL più sotto.
rtl/citycon/citycon_video.sv:628 MAME letterale: yscan_next = screen_y (= bitmap_y).
rtl/citycon/citycon_video.sv:633 MAME: scan da 63 -> 0 (ultimo scritto = on-top = idx 0)
rtl/citycon/citycon_video.sv:852 Lo scanner MAME-style (citycon_video.sv:571-749) continua a girare in parallelo ma le sue uscite vengono ignorate dal mux finale.
rtl/citycon/citycon_video.sv:905 Palette mapping: sprite: base 0 + spr_pal*16 + spr_pen (16 banks × 16 pen) FG: MAME scrive ogni frame palram[640+4y+i] copiando da palram[512+4*linecolor[y]+i].
rtl/citycon/citycon_video.sv:908 Invece di replicare il writeback in HW, leggo DIRETTAMENTE da palram[512 + 4*linecolor[y] + pen[1:0]] (sorgente MAME).
rtl/citycon/citycon_video.sv:912 MAME fa palram[640+4*y+i]=palram[512+4*linecolor[y]+i] per i=0..3.
rtl/citycon/citycon_video.sv:914 linecolor indicizzato da y_fg (non y_active) perché MAME fa changecolor(640+4*offs+...) dove offs = char_color*8 + row_sub = y_fg.
rtl/citycon/citycon_video.sv:1065 Output mixing (MAME order: BG base → FG trans 0 → sprite trans 0)
rtl/citycon/pld/hv_counter.v:33 Numeri PCB confermati MAME/decompilazione: HTOTAL=320, HBEND=8, HBSTART=248 VTOTAL=262, VBEND=16, VBSTART=240
rtl/citycon/pld/sprite_pcb.v:119 HREV sul PCB = attr2[4] raw (NON invertito come nel MAME-style flipx).
rtl/citycon/pld/sprite_pcb.v:120 MAME: flipx = ~attr2[4]; PCB: HREV = attr2[4].
rtl/citycon/pld/sprite_pcb.v:263 SEMPLIFICAZIONE FPGA: il PCB usa pulse periodico ogni 8 ck con LS166 shift register, ma FSM-MAME-style serializza in 2 metà 4-pixel ognuna.
rtl/citycon/pld/sprite_pcb.v:464 Su FPGA con il modello FSM-MAME-style del scanner, il counter scrive solo durante draw_active e fermerebbe a fine HBLANK, quindi serve un read addr basato su hcnt come nel legacy.
rtl/citycon/pld/sprite_stage.v:39 SCANNER (pagina 10) NON è ancora gate-level — resta MAME-style sopra di noi (citycon_video.sv:571-749).
rtl/citycon/pld/sprite_stage.v:58 Input dal scanner sprite (MAME-style upstream per ora)
rtl/citycon/pld/sprite_stage.v:140 NOTA: per ora HREV upstream è già applicato dallo scanner MAME-style che invia in_pen_col post-flipx.
rtl/citycon/pld/sprite_stage.v:216 Cablaggio input (ipotesi consolidata da pin_mapping.md): i1..i4 = S0..S3 (sprite pen, da B11) i5..i8 = V counter primati (qui sostituito con vcnt[3:0] come prossimità, nota: il PCB usa V primati post-flip; scanner upstream è MAME-style, l'e
README.md:10 This core reimplements the hardware in SystemVerilog from MAME references and pixel-accurate validation against original PCB footage.
README.md:24 AY-3-8910 (jt49) and YM2203 (jt03) sound chips with MAME-accurate mixer
README.md:25 247×224 active video area (PCB-accurate, **not** MAME's 240×224 clip)
README.md:39 Two weeks of pixel hunt: sprites and the platform "trail" effect were all consistently a few pixels off vs MAME.
README.md:46 One frame revealed it: the PCB outputs **247 pixels wide**, not 240 as MAME's clipping suggests.
README.md:48 MAME crops 7 pixels and adjusts everything internally to fit.
README.md:148 The **MAME** project for invaluable hardware reference.

Says it matches, follows or was checked against MAME — 7

rtl/citycon/citycon_audio.sv:245 Uso volumi MAME 1:1 con calcolo intero: AY8910 = sum * 26 / 64 = sum * 0.40625 (errore 1.5%) YM2203 FM = fm_snd * 26 / 64 YM2203 PSG = psg_snd * 13 / 64 (= 0.203) Per match esatto MAME servirebbero divisioni reali — accettiamo 1-2% di error
rtl/citycon/citycon_top.sv:107 ce_pix = clk/8 = 5 MHz (match MAME PIXEL_CLOCK).
rtl/citycon/citycon_top.sv:112 CPU MC6809 E clock = 2 MHz (match MAME CPU_CLOCK/4 = 8/4).
rtl/citycon/citycon_video.sv:148 Match MAME 1:1.
rtl/citycon/citycon_video.sv:197 Match MAME (tile pipeline=X+3 ↔ vram[X+3]).
rtl/citycon/citycon_video.sv:312 fg_opaque = (fg_pen != 0) — match MAME drawer transparent pen check.
rtl/citycon/pld/sprite_pcb.v:121 Il NAND A3 produce NSM = NAND(match, HREV), quindi: attr2[4]=1 (sprite "naturale" MAME) → HREV=1 → NSM=0 in match → A0=Q0 (lineare) attr2[4]=0 (sprite flipx MAME) → HREV=0 → NSM=1 in match → A0=~Q0 (flip)

Says it was translated, ported or taken from MAME — 7

rtl/citycon/citycon_audio.sv:245 Uso volumi MAME 1:1 con calcolo intero: AY8910 = sum * 26 / 64 = sum * 0.40625 (errore 1.5%) YM2203 FM = fm_snd * 26 / 64 YM2203 PSG = psg_snd * 13 / 64 (= 0.203) Per match esatto MAME servirebbero divisioni reali — accettiamo 1-2% di error
rtl/citycon/citycon_video.sv:148 Match MAME 1:1.
rtl/citycon/citycon_video.sv:311 MAME 1:1: set_transparent_pen(0) è sul pen 5bpp completo (0..31), non solo pen visibile.
rtl/citycon/citycon_video.sv:313 MAME 1:1: trasparente sse pen 5bpp = 0
rtl/citycon/citycon_video.sv:641 MAME 1:1: sy = 239 - sy_raw (no flip), sy = 238 - sy in flip mode.
rtl/citycon/citycon_video.sv:917 MAME 1:1: FG legge dalla VIRTUAL palette palram[640+4*y+pen[1:0]].
rtl/citycon/citycon_video.sv:949 VIRTUAL PALETTE WRITEBACK FSM (MAME 1:1 implementation) Ogni frame in vblank esegue il loop: for offs=0..255: indx=linecolor[offs]; for i=0..3: palette[640+4*offs+i] = palette[512+4*indx+i] 1024 entries × 2 byte = 2048 byte trasferiti per f

ComputerSpace#
Computer Space
MiSTer-devel/Arcade-ComputerSpace_MiSTer @ c9912443
MAME driver: not found
Read: 13 HDL files, 7,046 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

77%

Statements: 14 toward hardware

Cites hardware documentation that MAME's driver does not — 14

rtl/computer_space_logic.vhd:11 Naming convention: -- Sync Star Board inputs/outputs are labelled SB_<nn>, where <nn> is -- according to original schematics input/output labels.
rtl/computer_space_logic.vhd:13 -- Motion Board inputs/outputs are labelled MB_<nn>, where <nn> is -- according to original schematics input/output labels.
rtl/computer_space_logic.vhd:15 -- Memory Board inputs/outputs are labelled MemBrd_<nn>, where <nn> is -- according to original schematics input/output labels.
rtl/computer_space_top.vhd:33 -- * Computerspacefan.com - who has provided sound samples and -- original schematics -- * Chris (http://www.pyroelectro.com/) whose code for interlaced -- ntsc signalling I have kindly used as a basis for creating an --
rtl/computer_space_top.vhd:54 Turn and both missiles sounds are produced exactly in the same way as in the original desing (based on schematics analysis) : gated frequency from saucer and missile counters on motion board.
rtl/computer_space_top.vhd:61 From schematics one gets that these sounds come from a single noise generator.
rtl/memory_board.vhd:3 -- Implementation of Computer Space's Memory Board -- "wire by wire" and "component by component"/"gate by gate" -- according to original schematics.
rtl/memory_board.vhd:41 -- Memory Board inputs/outputs are labelled MemBrd_<nn>, where <nn> is -- according to original schematics input/output labels.
rtl/memory_board.vhd:962 otherwise include logic as per schematics to get sound frequency input via e6_13.
rtl/motion_board.vhd:3 -- Implementation of Computer Space's Motion Board -- "wire by wire" and "component by component"/"gate by gate" based on -- original schematics.
rtl/motion_board.vhd:29 -- Motion Board inputs/outputs are labelled MB_<nn>, where <nn> is -- according to original schematics input/output labels.
rtl/sync_star_board.vhd:2 SYNC STAR BOARD -- For use with Computer Space FPGA emulator -- Implementation of Computer Space's Sync Star Board -- "wire by wire" and "component by component"/"gate by gate" based on -- original schema
rtl/sync_star_board.vhd:32 -- Sync Star Board inputs/outputs are labelled SB_<nn>, where <nn> is -- according to original schematics input/output labels.
rtl/sync_star_board.vhd:302 As it is not according to original schematics it is -- placed in a separate entity to isolate from rest of original -- schematics.

CongoBongo#
Congo Bongo
MiSTer-devel/Arcade-CongoBongo_MiSTer @ 22dbeae5
MAME compared: sega/zaxxon.cpp + 7 related file(s)
Read: 14 HDL files, 4,286 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

35%

Statements: 2 toward MAME

Cites MAME source — 2

rtl/congo_bongo.vhd:34 Use with MAME roms from congo.zip
rtl/sn76489/sn76489_noise.vhd:199 Tapped bits according to MAME's sn76496.c, implemented in function lfsr_tapped_f.

Cosmic#
Cosmic Alien, Devil Zone, Magical Spot, Sengoku no Jieitai …
MiSTer-devel/Arcade-Cosmic_MiSTer @ 33b7ede2
MAME compared: universal/cosmic.cpp + 2 related file(s)
Read: 13 HDL files, 7,124 lines (Quartus project)

MiSTer official

Mostly MAME

low

31%

Statements: 20 toward MAME

Cites MAME source — 2

Arcade-Cosmic.sv:367 JPAC/IPAC/MAME Style Codes
rtl/Cosmic_video.vhd:626 _N zero = no sprite to be drawn bit 7 : 0 = 32x32,1 = 16x16 bit 6 : 0 = left to right, 1 = right to left rest : inverse of sprite number (see C) _X horizontal position inverted _Y vertical position inverted - 1 (from Mame) _C bit

Shares text with the MAME driver without saying so — 18

rtl/Cosmic.vhd:311 map(0x4000, 0x5fff).ram().share("videoram"); — shares text with universal/cosmic.cpp:286
rtl/Cosmic.vhd:312 map(0x6000, 0x601f).writeonly().share("spriteram"); — shares text with universal/cosmic.cpp:287
rtl/Cosmic.vhd:317 map(0x7000, 0x700b).w(FUNC(cosmic_state::panic_sound_output_w)); — shares text with universal/cosmic.cpp:292
rtl/Cosmic.vhd:318 map(0x700c, 0x700e).w(FUNC(cosmic_state::cosmic_color_register_w)); — shares text with universal/cosmic.cpp:293
rtl/Cosmic.vhd:319 map(0x700f, 0x700f).w(FUNC(cosmic_state::flip_screen_w)); — shares text with universal/cosmic.cpp:294
rtl/Cosmic.vhd:320 map(0x7800, 0x7801).w(FUNC(cosmic_state::panic_sound_output2_w)); — shares text with universal/cosmic.cpp:295
rtl/Cosmic.vhd:324 map(0x3800, 0x3807).r(FUNC(cosmic_state::magspot_coinage_dip_r)); — shares text with universal/cosmic.cpp:317
rtl/Cosmic.vhd:325 map(0x4000, 0x401f).writeonly().share("spriteram"); — shares text with universal/cosmic.cpp:318
rtl/Cosmic.vhd:326 map(0x4800, 0x4800).w(FUNC(cosmic_state::dac_w)); — shares text with universal/cosmic.cpp:319
rtl/Cosmic.vhd:327 map(0x480c, 0x480d).w(FUNC(cosmic_state::cosmic_color_register_w)); — shares text with universal/cosmic.cpp:320
rtl/Cosmic.vhd:328 map(0x480f, 0x480f).w(FUNC(cosmic_state::flip_screen_w)); — shares text with universal/cosmic.cpp:321
rtl/Cosmic.vhd:333 map(0x6000, 0x7fff).ram().share("videoram"); — shares text with universal/cosmic.cpp:326
rtl/Cosmic.vhd:337 map(0x4000, 0x5fff).ram().share("videoram"); — shares text with universal/cosmic.cpp:286
rtl/Cosmic.vhd:338 map(0x6000, 0x601f).writeonly().share("spriteram"); — shares text with universal/cosmic.cpp:287
rtl/Cosmic.vhd:342 map(0x6803, 0x6803).r(FUNC(cosmic_state::cosmica_pixel_clock_r)); — shares text with universal/cosmic.cpp:307
rtl/Cosmic.vhd:343 map(0x7000, 0x700b).w(FUNC(cosmic_state::cosmica_sound_output_w)); — shares text with universal/cosmic.cpp:292
rtl/Cosmic.vhd:344 map(0x700c, 0x700d).w(FUNC(cosmic_state::cosmic_color_register_w)); — shares text with universal/cosmic.cpp:309
rtl/Cosmic.vhd:345 map(0x700f, 0x700f).w(FUNC(cosmic_state::flip_screen_w)); — shares text with universal/cosmic.cpp:294

CosmicGuerilla#
Cosmic Guerilla
MiSTer-devel/Arcade-CosmicGuerilla_MiSTer @ 3d39320a
MAME compared: universal/cosmicg.cpp
Read: 11 HDL files, 4,588 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

31%

Statements: 3 toward MAME

Cites MAME source — 2

Arcade-CosmicGuerilla.sv:373 JPAC/IPAC/MAME Style Codes
README.md:25 It also does this in Mame.

Shares text with the MAME driver without saying so — 1

rtl/CosmicGuerilla.vhd:435 map(0x2000, 0x3fff).ram().share("videoram"); — shares text with universal/cosmicg.cpp:232

CrazyBalloon#
Crazy Balloon
MiSTer-devel/Arcade-CrazyBalloon_MiSTer @ 7ea1d452
MAME compared: taito/crbaloon.cpp + 3 related file(s)
Read: 13 HDL files, 7,935 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 1 toward hardware

Cites hardware documentation that MAME's driver does not — 1

rtl/CrazyBalloon_audio.vhd:90 Music circuit (74LS273, 2 x 74LS161 & 74LS93) similar to one in galaxian, different divider chip

CrazyClimber#
Crazy Climber
MiSTer-devel/Arcade-CrazyClimber_MiSTer @ c52b6e8b
MAME compared: nichibutsu/cclimber.cpp
Read: 15 HDL files, 6,106 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

11%

Statements: 1 toward MAME

Cites MAME source — 1

rtl/ym_2149_linmix.vhd:44 Clues from MAME sound driver and Kazuhiro TSUJIKAWA

CrazyKong#
Crazy Kong, Crazy Kong Part II
MiSTer-devel/Arcade-CrazyKong_MiSTer @ ee03d1cb
MAME compared: nichibutsu/cclimber.cpp
Read: 14 HDL files, 5,940 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

11%

Statements: 1 toward MAME

Cites MAME source — 1

rtl/ym_2149_linmix.vhd:44 Clues from MAME sound driver and Kazuhiro TSUJIKAWA

CrystalCastles#
Crystal Castles
MiSTer-devel/Arcade-CrystalCastles_MiSTer @ 8df9caf3
MAME compared: atari/ccastles.cpp
Read: 25 HDL files, 3,774 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 2 toward hardware, 1 not counted

Cites hardware documentation that MAME's driver does not — 2

rtl/SupportChips.v:186 82S09 64 X 9 RAM Color RAM
README.md:46 Created using original schematics, and insight from own tools and tests with a custom diagnostic rom.

Cites hardware references or measurements that MAME's driver also gives — 1

README.md:48 82S129 PROMs were replaced by their equivalent logic expressions. — also in MAME: 82S129 atari/ccastles.cpp:913

Darius#
Darius
MiSTer-devel/Arcade-Darius_MiSTer @ a85cac5e
MAME compared: taito/darius.cpp + 4 related file(s)
Read: 42 HDL files, 17,074 lines (Quartus project)

MiSTer official

Mostly MAME

medium

34%

Statements: 1 toward hardware, 41 toward MAME

Cites hardware documentation that MAME's driver does not — 1

Template.sv:746 Base periodo Darius = 16 quarti (4 clk @96M = 24MHz pixel): clamp minimo 8 quarti (2 clk) — hsize molto negativo non puo' azzerare il periodo.

Cites MAME source — 33

Template.sv:293 --- Joystick to Darius input mapping --- MiSTer joy bits: 0=R, 1=L, 2=D, 3=U, 4=Fire(A), 5=Bomb(B), 6=Start1P, 7=Start2P, 8=Coin Darius P1 ($C00008): active low, bits: 7=unused,6=unused,5=Fire2,4=Fire1,3=U,2=D,1=L,0=R Darius P2 ($C0000A): s
Template.sv:304 MAME SYSTEM port ($C0000C) bit layout: bit 7:6 = unused (idle=0, IP_ACTIVE_HIGH) bit 5 = start2 (active LOW, idle=1) bit 4 = start1 (active LOW, idle=1)
Template.sv:309 bit 2 = service(active LOW, idle=1) — not mapped, hardcode idle bit 1 = coin2 (active HIGH, idle=0) bit 0 = coin1 (active HIGH, idle=0) MiSTer joy bits: [3:0]=R,L,D,U [4]=A [5]=B [10]=Start [11]=Coin [12]=Pause MAME SYSTEM port
rtl/darius/audio_mixer_gain.sv:45 DEFAULT PER CANALE — UNICO PUNTO DA MODIFICARE Valori iniziali = coefficienti MAME-ratio attuali del mixer (FM:PSG:MSM = 0.60:0.08:1.00).
rtl/darius/audio_mixer_gain.sv:50 Default x4 vs coeff MAME originali (154/5284/4071): base forte (oltre il 200% della taratura precedente).
rtl/darius/darius_audio_z80.sv:27 MAME memory maps: Z80 #1: 0000-3FFF ROM (fixed), 4000-7FFF ROM (banked, 4×16KB), 8000-8FFF RAM (4KB), 9000-9001 YM2203#1, A000-A001 YM2203#2, B000 PC060HA port_w, B001 PC060HA comm R/W, C000/C400/C800/CC00/D000 pan regs, D400 ADPCM cmd, DC0
rtl/darius/darius_audio_z80.sv:248 Z80 #1 reset: global reset OR PC060HA sub-reset (MAME: only main audio CPU)
rtl/darius/darius_audio_z80.sv:468 Volume registers from YM2203 I/O ports (MAME: write_portA0/B0/A1/B1)
rtl/darius/darius_audio_z80.sv:494 Volume directly from YM2203 I/O port outputs (combinatorial, no extra registers) MAME: write_portA0 = YM1 IOA, write_portB0 = YM1 IOB, etc.
rtl/darius/darius_audio_z80.sv:540 NMI enable gate + data write (MAME: port 0x00=nmi_disable, 0x01=nmi_enable, 0x02=adpcm_data)
rtl/darius/darius_audio_z80.sv:562 MSM5205 data + reset (MAME: m_msm->data_w(data), m_msm->reset_w(!(data & 0x20)))
rtl/darius/darius_audio_z80.sv:642 --- Z80 #2 I/O read: port 0x00=cmd, 0x02/0x03=0 (MAME), else 0xFF ---
rtl/darius/darius_audio_z80.sv:696 Audio mixer — MAME-ratio-matched, 3-stage pipeline
rtl/darius/darius_audio_z80.sv:698 Coefficients scaled for jt03 integer output ranges (not MAME floats).
rtl/darius/darius_audio_z80.sv:703 --- Stage 0: pv quantization (MAME-exact: (pan * vol) >> 8) — REGISTERED ---
rtl/darius/darius_dual68k_top.sv:75 MAME SYSTEM port: {00,start2,start1,tilt,service,coin2,coin1}
rtl/darius/darius_maincpu_map.sv:63 MAME SYSTEM port: {00,start2,start1,tilt,service,coin2,coin1}
rtl/darius/darius_maincpu_map.sv:238 Coin lockout/counter register (MAME: m_coin_word, written at $C00060, read back at $C0000E)
rtl/darius/darius_maincpu_map.sv:747 Coin lockout: MAME coin_lockout_w(0, ~data & 0x02) → bit1=0 locks COIN1 MAME coin_lockout_w(1, ~data & 0x04) → bit2=0 locks COIN2
rtl/darius/darius_panel_renderer.sv:256 Source pixel coordinates with scroll + panel offset (selects by current layer) MAME set_offsets(-16, 8): L0 xoff=-16, L1 xoff=+8 MAME Y: L0 +8, L1 0
rtl/darius/darius_sprite_renderer.sv:27 Sprite RAM format (MAME, 4 words per entry at $E00100): word[0]: Y position → sy = (256 - data) & 0x1FF word[1]: X position → sx = data & 0x3FF word[2]: tile code[12:0], flipX[14], flipY[15] word[3]: priority[7], color[6:0]
rtl/darius/darius_sprite_renderer.sv:48 X offset (scroll-dependent, from MAME draw_sprites x_offs parameter)
rtl/darius/darius_sprite_renderer.sv:93 y_offs = -8 from MAME + north adjust
rtl/darius/darius_sprite_renderer.sv:314 Pixel extraction: bit-per-plane (MAME method)
rtl/darius/darius_sprite_renderer.sv:322 This was confirmed by: - Debug overlay showing PA=646 (pixel 6) where MAME expects pixel 5 - Systematic HW testing of 8+ permutations - PA lookup live showing correct bank 0x64x entries with this mapping The effective byte layout observed o
rtl/darius/darius_sprite_renderer.sv:333 MAME pixel = {plane3_bit, plane2_bit, plane1_bit, plane0_bit}
rtl/darius/darius_sprite_renderer.sv:610 Draw 8 pixels from current ROM word (bit-per-plane, MAME method)
rtl/darius/pc060ha_link.sv:25 Single-clock rewrite ispirato a jtrastan_pc060 (JTCORES by Jose Tejada), implementato secondo la descrizione di pc060ha_device in MAME.
rtl/darius/triple_screen_test.sv:127 Sprite overlay (MAME priority: prio_transpen + primask) sprite_prio=1 (primask=0): covers everything sprite_prio=0 (GFX_PMASK_2): covers L0 (tile_prio=01) but NOT L1 (tile_prio=10)
README.md:9 This core reimplements the hardware in SystemVerilog from MAME references and hardware observation on original PCBs.
README.md:76 **Dual 68000** main/sub with shared RAM (FX68K core), PC060HA master/slave communication reproduced from MAME
README.md:82 Palette with MAME-verified byte order
README.md:105 Palette with MAME-verified byte order

Says it matches, follows or was checked against MAME — 5

rtl/darius/darius_audio_z80.sv:586 S1=1, S0=0 → divide by 48 → 384K/48 = 8KHz (matches MAME)
rtl/darius/darius_audio_z80.sv:699 FM:PSG:MSM ratios match MAME route gains (0.60 : 0.08 : 1.00).
rtl/darius/darius_audio_z80.sv:730 --- Stage 0b: coefficients (coeff × pv) — REGISTERED --- Ratios FM:PSG:MSM match MAME route gains (0.60 : 0.08 : 1.00).
rtl/darius/darius_panel_renderer.sv:420 prio: L0=01, L2=10 (matches MAME priority bitmap values)
rtl/darius/darius_sprite_renderer.sv:227 Verificato: MAME attract (slot 7 = code $3E6 128/128 frame demo) + Darius-Native main_annotated.md ("La nave è a $E00138, code $3E6").

Shares text with the MAME driver without saying so — 3

rtl/darius/darius_audio_z80.sv:562 MSM5205 data + reset (MAME: m_msm->data_w(data), m_msm->reset_w(!(data & 0x20))) — shares text with taito/darius.cpp:701
rtl/darius/darius_maincpu_map.sv:747 Coin lockout: MAME coin_lockout_w(0, ~data & 0x02) → bit1=0 locks COIN1 — shares text with taito/darius.cpp:400
rtl/darius/darius_maincpu_map.sv:748 MAME coin_lockout_w(1, ~data & 0x04) → bit2=0 locks COIN2 — shares text with taito/darius.cpp:401

Darius2NinjaWarriors#
Darius II, The Ninja Warriors
MiSTer-devel/Arcade-Darius2NinjaWarriors_MiSTer @ 03224c45
MAME compared: taito/ninjaw.cpp + 7 related file(s)
Read: 31 HDL files, 11,243 lines (Quartus project)

MiSTer official

Mostly MAME

medium

69%

Statements: 2 toward hardware, 106 toward MAME

Notes where it differs from MAME — 2

rtl/darius2/darius2_dual68k_top.sv:1418 Port B VRAM addr/we/din: chip MAME non usa SA/SDout/WE legacy; l'arbiter Port B è guidato da scn_m*_vram_b_addr (vedi mux scn_pb_addr più sotto).
rtl/darius2/tc_mame/tc0100scn_mame.sv:207 Chip MAME non finisce la scansione dentro hblank window (2652 clk a 96/24).

Cites MAME source — 86

Template.sv:253 --- Joystick to Darius 2 / Ninja Warriors input mapping --- MAME ninjaw.cpp IN0 (= p1_input, TC0040IOC port $02): bit 0: UNKNOWN ACTIVE_HIGH ("Stops working if this is high") — MUST be 0 bit 1: UNKNOWN ACTIVE_LOW — idle=1 bit 2: COIN1
Template.sv:266 MAME ninjaw.cpp IN2 (= system_input, TC0040IOC port $07): bit 0: SERVICE1 ACTIVE_LOW — idle=1 bit 1: TILT ACTIVE_LOW — idle=1 bit 2: START1 ACTIVE_LOW — idle=1 (pressed=0) bit 3: START2 ACTIVE_LOW — idle=1 bit 4: P1 BTN1 ACTIVE
Template.sv:276 Layout MAME: [3:0] P1 U D R L, [7:4] P2 U D R L (Right prima di Left).
Template.sv:282 MAME ninjaw IN2 (= system_input, TC0040IOC port $07): bit 0: SERVICE1 ACTIVE_LOW — idle=1 bit 1: TILT ACTIVE_LOW — idle=1 bit 2: START1 ACTIVE_LOW — idle=1 (pressed=0) bit 3: START2 ACTIVE_LOW — idle=1 bit 4: P1 BTN1 ACTIVE_LOW
Template.sv:507 Hardcoded 12 MHz (Darius 2 original MAME rate).
Template.sv:589 1-bit OSD: 0=Polite (default), 1=MAME (100%)
Template.sv:751 MAME warning overlay: "DON'T BREAK YOUR WOOFER!" per ~3s su edge status[95]
rtl/darius2/darius2_audio_top.sv:150 Sound RAM 8 KB (0xC000-0xDFFF MAME)
rtl/darius2/darius2_audio_top.sv:165 MAME ninjaw_state::sound_bankswitch_w mappa 0xF200 (memory write, non I/O).
rtl/darius2/darius2_audio_top.sv:273 Routing MAME ninjaw.cpp:633-652: pan_data[0] = FM L gain ($E401 dopo XOR^1) pan_data[1] = FM R gain ($E400 dopo XOR^1) pan_data[2] = ADPCM L gain ($E403 dopo XOR^1) pan_data[3] = ADPCM R gain ($E402 dopo XOR^1) (offset ^= 1 prima
rtl/darius2/darius2_audio_top.sv:285 MAME: offset ^= 1
rtl/darius2/darius2_audio_top.sv:303 PSG resta non panneggiato (in MAME va al subwoofer mono, qui lo sommo a entrambi i canali).
rtl/darius2/darius2_audio_top.sv:341 PSG: solo 2 valori OSD (Polite=12% default, MAME=100%).
rtl/darius2/darius2_audio_top.sv:342 0=Polite (1/8), 1=MAME (8/8)
rtl/darius2/darius2_audio_top.sv:345 MIXER NUOVO — interpretazione MAME-fedele basata su audit ymfm + ninjaw.cpp
rtl/darius2/darius2_audio_top.sv:353 MAME ninjaw routing (ninjaw.cpp:992-1003): add_route(0, "subwoofer", 0.75) → PSG mono * 0.75 add_route(1, "2610.1.l", 1.0) → FM_L → flt[0] (m_2610_l[0]) add_route(1, "2610.1.r", 1.0) → FM_L → flt[1] (m_2610_r[0]) ← stesso input!
rtl/darius2/darius2_audio_top.sv:360 pancontrol_w (ninjaw.cpp:633-652) decode con offset XOR^1: $E400 → flt[1] (FM_L verso speaker R) = pan_data[1] mio $E401 → flt[0] (FM_L verso speaker L) = pan_data[0] mio $E402 → flt[3] (FM_R verso speaker R) = pan_data[3] mio $E403 → flt[2
rtl/darius2/darius2_audio_top.sv:370 PSG va al subwoofer mono (in MAME) — qui sommato a entrambi audio_l/r.
rtl/darius2/darius2_dual68k_top.sv:75 MAME SYSTEM port: {00,start2,start1,tilt,service,coin2,coin1}
rtl/darius2/darius2_dual68k_top.sv:90 SCN rate selector rimosso — SCN ora usa ce_13m fisso (13.33 MHz, MAME-accurate).
rtl/darius2/darius2_dual68k_top.sv:426 Main CPU clock divider (96MHz / den) Default 0 = 12 MHz (Darius 2 originale MAME: XTAL 24MHz/2).
rtl/darius2/darius2_dual68k_top.sv:430 96/8 = 12MHz (original MAME default)
rtl/darius2/darius2_dual68k_top.sv:439 Sub CPU clock divider (96MHz / den) Default 0 = 12 MHz (Darius 2 originale MAME).
rtl/darius2/darius2_dual68k_top.sv:443 96/8 = 12MHz (original MAME default)
rtl/darius2/darius2_dual68k_top.sv:779 --- CPU → TC0100SCN chip selects --- From MAME darius2_master_map: $280000-$293FFF → SCN[0] RAM (read + write-through to all 3) $2A0000-$2A000F → SCN[0] ctrl $2C0000-$2D3FFF → SCN[1] RAM $2E0000-$2E000F → SCN[1] ctrl $300000-$313FFF → SCN[2
rtl/darius2/darius2_dual68k_top.sv:807 TC0140SYT sound comm (MAME ninjaw_master_map): 0x220000-0x220001 = master_port_w (MA1=0) 0x220002-0x220003 = master_comm_r/w (MA1=1)
rtl/darius2/darius2_dual68k_top.sv:868 TC0100SCN ce_pixel: fisso a 13.33 MHz (MAME-accurate Darius 2 XTAL 26.686/2).
rtl/darius2/darius2_dual68k_top.sv:943 Fix #36: triple_screen_w writethrough (MAME ninjaw_state::tc0100scn_triple_screen_w).
rtl/darius2/darius2_dual68k_top.sv:944 Per MAME ninjaw.cpp:655-660, scritture CPU a $280000-$293FFF (range SCN0) sono replicate SIMULTANEAMENTE su tutti e 3 i TC0100SCN.
rtl/darius2/darius2_dual68k_top.sv:1028 MAME TC0100SCN wide mode: 0x00000-0x0FFFF = SCE0 (64KB = 32K word), 0x10000-0x13FFF = SCE1 (16KB = 8K word).
rtl/darius2/darius2_dual68k_top.sv:1224 Il chip MAME ha cen=1 solo quando scn_arb_phase == suo indice → FSM renderer avanza 1/3 dei clk, ma quando avanza il dato Port B è già il suo (nessuna collisione su mirror VRAM, nessuna latenza arbiter da gestire).
rtl/darius2/darius2_dual68k_top.sv:1247 Seleziona addr corrente in base a phase MAME chip emette vram_b_addr[15:0] direttamente (bit 15 = main/ext selector, stesso encoding di scn{N}_ram_full_addr del Donlon).
rtl/darius2/darius2_dual68k_top.sv:1310 --- TC0100SCN instances (Donlon reference RTL) --- MAME Darius 2: set_offsets(22,0), multiscr_xoffs 0/2/4 per chip 0/1/2.
rtl/darius2/darius2_dual68k_top.sv:1386 DONLON TIE-OFFS — wire ex-Donlon ora guidati dai chip MAME o costanti.
rtl/darius2/darius2_dual68k_top.sv:1390 render_x per pannello (moved up da sotto: servono ai chip MAME e agli assign hcnt qui sotto.
rtl/darius2/darius2_dual68k_top.sv:1397 CPU path: redirigi dout/dack dai chip MAME (CRITICO per CPU reads/DTACK)
rtl/darius2/darius2_dual68k_top.sv:1405 SC → palette (MAME chip emette SC diretto a render_x)
rtl/darius2/darius2_dual68k_top.sv:1410 Tile ROM interface → MAME chip
rtl/darius2/darius2_dual68k_top.sv:1433 main selector (unused with chip MAME)
rtl/darius2/darius2_dual68k_top.sv:1459 MAME-model TC0100SCN instances (3×) — PARALLEL with Donlon for now.
rtl/darius2/darius2_dual68k_top.sv:1461 In Step 3 Donlon will be disconnected and MAME will drive SC, rom_req, etc.
rtl/darius2/darius2_dual68k_top.sv:1480 MAME chip signals (parallel to Donlon, not connected to system yet)
rtl/darius2/darius2_dual68k_top.sv:1584 Palette chip selects (from MAME darius2_master_map)
rtl/darius2/darius2_dual68k_top.sv:1758 --- Palette lookup: BYPASS scn_line_buffer esterno (Donlon-legacy) --- Il chip MAME emette SC sincrono a render_x, NON serve ping-pong 13→24.
rtl/darius2/darius2_dual68k_top.sv:1760 Replica la logica sprite_wins del TC0110PR per blending corretto: FG vince sempre Sprite prio 0 vince su BG top (mid in MAME primask) e BG bottom Sprite prio 1 vince solo su BG bottom (sotto BG top/mid) SC[14:13] encoding (da tc0100scn_mame
rtl/darius2/darius2_maincpu_map_new.sv:24 MAME: darius2_master_map (ninjaw.cpp)
rtl/darius2/darius2_maincpu_map_new.sv:266 --- CPUA ctrl --- MAME cpua_ctrl_w: if only high byte is written (UDS only), shift high→low so bit 0 of the low byte is correctly set.
rtl/darius2/darius2_maincpu_map_new.sv:275 MAME-style high-byte-only normalization
rtl/darius2/darius2_maincpu_map_new.sv:285 --- TC0140SYT sound comm (real, no stub) --- MAME: $220001=master_port_w, $220003=master_comm_r/w Pilotiamo cs/wr/rd/a1 al TC0140SYT vero in audio_top.
rtl/darius2/darius2_sprite_renderer.sv:27 Sprite RAM format (MAME, 4 words per entry at $E00100): Darius 2 sprite format (ninjaw.cpp): word[0]: X position → sx = (data - 32) & 0x3FF word[1]: Y position → sy = data & 0x1FF word[2]: tile code[14:0] (0 = skip) word[3]: flipX[0], flipY
rtl/darius2/darius2_sprite_renderer.sv:45 X offset (scroll-dependent, from MAME draw_sprites x_offs parameter)
rtl/darius2/darius2_sprite_renderer.sv:87 y_offs = -8 from MAME + north adjust
rtl/darius2/darius2_sprite_renderer.sv:236 Priority mask MAME bit3 attr "unknown priority": pixel scritto da sprite con attr[3]=1 → prio_lb=1, vince anche su pixel gia' scritti da sprite con attr[3]=0.
rtl/darius2/darius2_sprite_renderer.sv:332 scn_sc[T+2] = pixel render_x[T] = render_x[T+2] - 2 (chip MAME stessa pipeline).
rtl/darius2/darius2_sprite_renderer.sv:351 Pixel extraction — formula derivata da MAME drawgfx.cpp readbit: src[bitnum/8] & (0x80 >> (bitnum%8)) → bit 0 del char = MSB del byte.
rtl/darius2/darius2_sprite_renderer.sv:581 bit3 MAME
rtl/darius2/darius2_sprite_renderer.sv:604 bit3 MAME
rtl/darius2/darius2_sprite_renderer.sv:655 Lancia req ROM direttamente in RD_POP (mask 14-bit MAME drawgfx)
rtl/darius2/darius2_sprite_renderer.sv:817 sprite_ob combinatorio da spr_disp_word (già registrato 1 clk da line buffer), allineato a scn_sc (anche registrato 1 clk dal chip MAME).
rtl/darius2/darius2_subcpu_map_new.sv:24 MAME: darius2_slave_map (ninjaw.cpp)
rtl/darius2/darius2_subcpu_map_new.sv:109 MAME ninjaw_slave_map (ninjaw.cpp:699-701): sub scrive palette dei 3 schermi.
rtl/darius2/mame_warning_overlay.sv:22 mame_warning_overlay.sv — testo statico "DON'T BREAK YOUR WOOFER!" che appare per ~3 secondi quando l'utente attiva PSG=MAME nell'OSD audio mixer.
rtl/darius2/pc060ha_link.sv:25 Single-clock rewrite ispirato a jtrastan_pc060 (JTCORES by Jose Tejada), implementato secondo la descrizione di pc060ha_device in MAME.
rtl/darius2/tc0040ioc.sv:14 In MAME è un singolo chip con un solo m_port register.
rtl/darius2/tc0110pr.sv:110 MAME chip behaviour: cpu_mode only closes on explicit VA=10.
rtl/darius2/tc0110pr.sv:132 Priority MAME ninjaw (draw_sprites + primask): sprite prio 0 (OB[13]=0): sotto FG, sopra tutto il resto sprite prio 1 (OB[13]=1): sotto FG, sotto MID layer, sopra BOTTOM SC[14:13] dal chip MAME tc0100scn codifica il RUOLO del layer visibile
rtl/darius2/tc0110pr.sv:154 layer BG "top" → MAME mid
rtl/darius2/tc0140syt.sv:101 MAME ninjaw usa NMI per svegliare Z80 al ricevimento comando audio.
rtl/darius2/tc_mame/tc0100scn_mame.sv:22 tc0100scn_mame.sv — TC0100SCN, MAME-accurate scanline renderer.
rtl/darius2/tc_mame/tc0100scn_mame.sv:24 Reference: MAME tc0100scn.cpp + ninjaw.cpp (Darius 2).
rtl/darius2/tc_mame/tc0100scn_mame.sv:25 Scroll math, tile lookup, pixel decode follow MAME exactly.
rtl/darius2/tc_mame/tc0100scn_mame.sv:33 MAME VRAM layout (wide mode, word offsets): $0000-$3FFF BG0 attrib+code (128×64 tiles, 2 words/tile) $4000-$7FFF BG1 attrib+code (128×64 tiles, 2 words/tile) $8000-$81FF BG0 row scroll (256 words) $8200-$83FF BG1 row scroll (256 words)
rtl/darius2/tc_mame/tc0100scn_mame.sv:53 0 = primo chip, 1 = chip successivi (flag MAME)
rtl/darius2/tc_mame/tc0100scn_mame.sv:118 Formula MAME (tc0100scn.cpp:285-286): xd = -m_x_offset - m_multiscrn_xoffs; yd = 8 - m_y_offset; → Chip 0: xd=-22, chip 1: xd=-24, chip 2: xd=-26; yd uguale per tutti (8).
rtl/darius2/tc_mame/tc0100scn_mame.sv:122 cliprect.top di ninjaw.cpp:938 = 3*8 = 24.
rtl/darius2/tc_mame/tc0100scn_mame.sv:122 MAME fa src_y += cliprect.top, equivale a usare effettivo scrolldy = yd - cliprect.top = 8 - 24 = -16.
rtl/darius2/tc_mame/tc0100scn_mame.sv:141 VRAM bases CONDIZIONATI su wide/single (MAME spec).
rtl/darius2/tc_mame/tc0100scn_mame.sv:344 BUG3 fix: Row scroll index MAME (tc0100scn.cpp:623).
rtl/darius2/tc_mame/tc0100scn_mame.sv:345 MAME mappa j-esimo rowscroll_ram a tilemap row (j + bgscrolly).
rtl/darius2/tc_mame/tc0100scn_mame.sv:395 MAME lo fa internamente nel gfx_element (drawgfx code % elements()).
rtl/darius2/tc_mame/tc0100scn_mame.sv:424 BUG3 fix: BG1 rowscroll index = (rline - SCROLLDY) & 0x1ff (MAME).
rtl/darius2/tc_mame/tc0100scn_mame.sv:442 Col scroll per-tile (MAME tc0100scn.cpp:656): column_offset = colscroll_ram[src_x/8]; src_y_tile = line_sy - column_offset.
rtl/darius2/triple_screen_test.sv:166 Sprite overlay (MAME ninjaw.cpp priority: "1 = low") prio=0 (primask GFX_PMASK_4): sprite sopra tutto tranne FG prio=1 (primask GFX_PMASK_4|GFX_PMASK_2): sprite sotto L1 (tile_prio=10) Draw se: no tile opaco, OR prio=0, OR tile NON è L1.
README.md:13 This core reimplements the hardware in SystemVerilog from MAME references and hardware observation.
README.md:26 Three TC0100SCN tilemap chips (BG0 + BG1 + FG0 per panel) — MAME-accurate
README.md:177 The **MAME** project — invaluable hardware reference (TC0100SCN, memory maps, timing)

Says it matches, follows or was checked against MAME — 1

rtl/darius2/sdram_bridge.sv:266 Word-swap concat (SIM-verified MAME-compliant).

Says it was translated, ported or taken from MAME — 1

README.md:28 Sprite renderer with priority, flip, 16×16 4bpp tiles, MAME 1:1 wrap math

Shares text with the MAME driver without saying so — 18

Template.sv:193 "P2O[43:38],BG0 X offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29,-2 — shares text with taito/tc0100scn.cpp:240
Template.sv:194 "P2O[49:44],BG0 Y offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29,-2 — shares text with taito/tc0100scn.cpp:240
Template.sv:195 "P2O[55:50],BG1 X offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29,-2 — shares text with taito/tc0100scn.cpp:240
Template.sv:196 "P2O[61:56],BG1 Y offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29,-2 — shares text with taito/tc0100scn.cpp:240
Template.sv:197 "P2O[67:62],Sprite X offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29 — shares text with taito/tc0100scn.cpp:240
Template.sv:198 "P2O[73:68],Sprite Y offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29 — shares text with taito/tc0100scn.cpp:240
Template.sv:199 "P2O[79:74],FG X offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29,-28 — shares text with taito/tc0100scn.cpp:240
Template.sv:200 "P2O[85:80],FG Y offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29,-28 — shares text with taito/tc0100scn.cpp:240
Template.sv:255 bit 0: UNKNOWN ACTIVE_HIGH ("Stops working if this is high") — MUST be 0 — shares text with taito/ninjaw.cpp:780
rtl/darius2/darius2_audio_top.sv:354 add_route(0, "subwoofer", 0.75) → PSG mono * 0.75 — shares text with taito/ninjaw.cpp:995
rtl/darius2/darius2_audio_top.sv:355 add_route(1, "2610.1.l", 1.0) → FM_L → flt[0] (m_2610_l[0]) — shares text with taito/ninjaw.cpp:996
rtl/darius2/darius2_audio_top.sv:356 add_route(1, "2610.1.r", 1.0) → FM_L → flt[1] (m_2610_r[0]) ← stesso input! — shares text with taito/ninjaw.cpp:997
rtl/darius2/darius2_audio_top.sv:357 add_route(2, "2610.2.l", 1.0) → FM_R → flt[2] (m_2610_l[1]) — shares text with taito/ninjaw.cpp:998
rtl/darius2/darius2_audio_top.sv:358 add_route(2, "2610.2.r", 1.0) → FM_R → flt[3] (m_2610_r[1]) — shares text with taito/ninjaw.cpp:999
rtl/darius2/darius2_dual68k_top.sv:943 Fix #36: triple_screen_w writethrough (MAME ninjaw_state::tc0100scn_triple_screen_w). — shares text with taito/ninjaw.cpp:656
rtl/darius2/darius2_maincpu_map_new.sv:269 if ((data & 0xff00) && ((data & 0xff) == 0)) data = data >> 8; — shares text with taito/ninjaw.cpp:606
rtl/darius2/tc_mame/tc0100scn_mame.sv:119 xd = -m_x_offset - m_multiscrn_xoffs; — shares text with taito/tc0100scn.cpp:287
rtl/darius2/triple_screen_test.sv:168 prio=1 (primask GFX_PMASK_4|GFX_PMASK_2): sprite sotto L1 (tile_prio=10) — shares text with taito/ninjaw.cpp:480

Darius2WarriorBlade#
Warrior Blade - Rastan Saga Episode III
MiSTer-devel/Arcade-Darius2WarriorBlade_MiSTer @ 613c2453
MAME compared: taito/warriorb.cpp + 7 related file(s)
Read: 29 HDL files, 10,674 lines (Quartus project)

MiSTer official

Mostly MAME

medium

68%

Statements: 3 toward hardware, 110 toward MAME

Notes where it differs from MAME — 3

rtl/darius2/darius2_dual68k_top.sv:1156 MAME chip TC0100SCN (2× warriorb.cpp) — wire driver per Port A BRAM e segnali ausiliari ex-Donlon (tied 0/1'b1 dato che MAME non li espone).
rtl/darius2/darius2_dual68k_top.sv:1188 Port B VRAM addr/we/din: chip MAME non usa SA/SDout/WE legacy; l'arbiter Port B è guidato da scn_m*_vram_b_addr (vedi mux scn_pb_addr più sotto).
rtl/darius2/tc_mame/tc0100scn_mame.sv:255 Chip MAME non finisce la scansione dentro hblank window (2652 clk a 96/24).

Cites MAME source — 103

Template.sv:244 --- Joystick to game inputs --- IN0/IN1/IN2 per warriorb.cpp (TC0220IOC/TC0510NIO direct-mapped): IN0 (offset $02): bit0=SERVICE1, bit1=TILT, bit2=COIN1, bit3=COIN2, bit4=START1, bit5=START2, bit6-7=unknown (active_low).
Template.sv:493 CPU clock parametrizzato per board (MAME-accurate), niente OSD: darius2d/sagaia : 68000 @ 12 MHz (XTAL 24MHz/2) → clk_sel code 0 warriorb : 68000 @ 16 MHz (warriorb.cpp) → clk_sel code 2 clk_sel code (divisore in darius2_dual68k_to
Template.sv:498 Sub-CPU non esiste in warriorb.cpp (single 68000): allineato per coerenza.
Template.sv:578 1-bit OSD: 0=Polite (default), 1=MAME (100%)
Template.sv:741 MAME warning overlay: "DON'T BREAK YOUR WOOFER!" per ~3s su edge status[95]
rtl/darius2/darius2_audio_top.sv:153 Sound RAM 8 KB (0xC000-0xDFFF MAME)
rtl/darius2/darius2_audio_top.sv:168 MAME ninjaw_state::sound_bankswitch_w mappa 0xF200 (memory write, non I/O).
rtl/darius2/darius2_audio_top.sv:276 Routing MAME ninjaw.cpp:633-652: pan_data[0] = FM L gain ($E401 dopo XOR^1) pan_data[1] = FM R gain ($E400 dopo XOR^1) pan_data[2] = ADPCM L gain ($E403 dopo XOR^1) pan_data[3] = ADPCM R gain ($E402 dopo XOR^1) (offset ^= 1 prima
rtl/darius2/darius2_audio_top.sv:288 MAME: offset ^= 1
rtl/darius2/darius2_audio_top.sv:306 PSG resta non panneggiato (in MAME va al subwoofer mono, qui lo sommo a entrambi i canali).
rtl/darius2/darius2_audio_top.sv:344 PSG: solo 2 valori OSD (Polite=12% default, MAME=100%).
rtl/darius2/darius2_audio_top.sv:345 0=Polite (1/8), 1=MAME (8/8)
rtl/darius2/darius2_audio_top.sv:348 MIXER NUOVO — interpretazione MAME-fedele basata su audit ymfm + ninjaw.cpp
rtl/darius2/darius2_audio_top.sv:356 MAME ninjaw routing (ninjaw.cpp:992-1003): add_route(0, "subwoofer", 0.75) → PSG mono * 0.75 add_route(1, "2610.1.l", 1.0) → FM_L → flt[0] (m_2610_l[0]) add_route(1, "2610.1.r", 1.0) → FM_L → flt[1] (m_2610_r[0]) ← stesso input!
rtl/darius2/darius2_audio_top.sv:363 pancontrol_w (ninjaw.cpp:633-652) decode con offset XOR^1: $E400 → flt[1] (FM_L verso speaker R) = pan_data[1] mio $E401 → flt[0] (FM_L verso speaker L) = pan_data[0] mio $E402 → flt[3] (FM_R verso speaker R) = pan_data[3] mio $E403 → flt[2
rtl/darius2/darius2_audio_top.sv:373 PSG va al subwoofer mono (in MAME) — qui sommato a entrambi audio_l/r.
rtl/darius2/darius2_audio_top.sv:384 MAME pancontrol_w (warriorb.cpp:378): gain = data*3/100; ninjaw.cpp:649: data/255.
rtl/darius2/darius2_audio_top.sv:440 Il PSG resta com'era (Polite=1/8, MAME=8/8 — non si tocca).
rtl/darius2/darius2_audio_top.sv:561 Base offset per variant warriorb.cpp (selettore: board_warriorb): darius2d: main 1MB + (no sub) → Z80 0x100000 warriorb: main 2MB + (no sub) → Z80 0x200000 Layout: main → Z80 128KB → sprite → tile → ADPCM-A → [ADPCM-B solo d2d]
rtl/darius2/darius2_dual68k_top.sv:70 Board variant: warriorb.cpp hardware (sempre 2-screen, single 68000).
rtl/darius2/darius2_dual68k_top.sv:85 MAME SYSTEM port: {00,start2,start1,tilt,service,coin2,coin1}
rtl/darius2/darius2_dual68k_top.sv:100 SCN rate selector rimosso — SCN ora usa ce_13m fisso (13.33 MHz, MAME-accurate).
rtl/darius2/darius2_dual68k_top.sv:204 Forward decl per VRAM read data (Port A read-back chip MAME).
rtl/darius2/darius2_dual68k_top.sv:218 Sub-CPU rimosso (warriorb.cpp = single 68000).
rtl/darius2/darius2_dual68k_top.sv:393 Main CPU clock divider (96MHz / den) Default 0 = 12 MHz (Darius 2 originale MAME: XTAL 24MHz/2).
rtl/darius2/darius2_dual68k_top.sv:397 96/8 = 12MHz (original MAME default)
rtl/darius2/darius2_dual68k_top.sv:406 Sub CPU clock divider (96MHz / den) Default 0 = 12 MHz (Darius 2 originale MAME).
rtl/darius2/darius2_dual68k_top.sv:410 96/8 = 12MHz (original MAME default)
rtl/darius2/darius2_dual68k_top.sv:431 SCN/PAL range — warriorb.cpp: d2d : 0x200000-0x26FFFF SCN, 0x400000-0x42000F PAL wb : 0x300000-0x36FFFF SCN, 0x400000-0x42000F PAL
rtl/darius2/darius2_dual68k_top.sv:518 Sub-CPU rimossa: warriorb.cpp = single 68000 (no shared RAM, no sub).
rtl/darius2/darius2_dual68k_top.sv:555 darius2_subcpu_map rimosso (sub-CPU non esiste in warriorb.cpp).
rtl/darius2/darius2_dual68k_top.sv:571 darius_shared_ram (shared main↔sub) rimossa: warriorb.cpp non ha sub-CPU, la mappa CPU non decoda quel range.
rtl/darius2/darius2_dual68k_top.sv:649 --- CPU → TC0100SCN chip selects --- From MAME darius2_master_map: $280000-$293FFF → SCN[0] RAM (read + write-through to all 3) $2A0000-$2A000F → SCN[0] ctrl $2C0000-$2D3FFF → SCN[1] RAM $2E0000-$2E000F → SCN[1] ctrl $300000-$313FFF → SCN[2
rtl/darius2/darius2_dual68k_top.sv:665 SCN chip selects — warriorb.cpp: darius2d : SCN0 0x200000+ ctrl 0x220000 ; SCN1 0x240000+ ctrl 0x260000 warriorb : SCN0 0x300000+ ctrl 0x320000 ; SCN1 0x340000+ ctrl 0x360000 Niente SCN2 (esiste solo nel chip 3 di ninjaw).
rtl/darius2/darius2_dual68k_top.sv:690 TC0140SYT sound comm (MAME ninjaw_master_map): 0x220000-0x220001 = master_port_w (MA1=0) 0x220002-0x220003 = master_comm_r/w (MA1=1)
rtl/darius2/darius2_dual68k_top.sv:748 TC0100SCN ce_pixel: fisso a 13.33 MHz (MAME-accurate Darius 2 XTAL 26.686/2).
rtl/darius2/darius2_dual68k_top.sv:817 Fix #36: triple_screen_w writethrough (MAME ninjaw_state::tc0100scn_triple_screen_w).
rtl/darius2/darius2_dual68k_top.sv:818 Per MAME ninjaw.cpp:655-660, scritture CPU a $280000-$293FFF (range SCN0) sono replicate SIMULTANEAMENTE sui TC0100SCN.
rtl/darius2/darius2_dual68k_top.sv:880 MAME TC0100SCN wide mode: 0x00000-0x0FFFF = SCE0 (64KB = 32K word), 0x10000-0x13FFF = SCE1 (16KB = 8K word).
rtl/darius2/darius2_dual68k_top.sv:1110 MAME chip emette vram_b_addr[15:0] (bit 15 = main/ext selector).
rtl/darius2/darius2_dual68k_top.sv:1160 render_x per pannello (moved up da sotto: servono ai chip MAME e agli assign hcnt qui sotto.
rtl/darius2/darius2_dual68k_top.sv:1163 warriorb.cpp: 2 panel × 320 = 640 totali.
rtl/darius2/darius2_dual68k_top.sv:1169 CPU path: redirigi dout/dack dai chip MAME (CRITICO per CPU reads/DTACK).
rtl/darius2/darius2_dual68k_top.sv:1175 SC → palette (MAME chip emette SC diretto a render_x).
rtl/darius2/darius2_dual68k_top.sv:1182 Tile ROM interface → MAME chip
rtl/darius2/darius2_dual68k_top.sv:1199 main selector (unused with chip MAME)
rtl/darius2/darius2_dual68k_top.sv:1210 MAME-model TC0100SCN instances (3×) — PARALLEL with Donlon for now.
rtl/darius2/darius2_dual68k_top.sv:1212 In Step 3 Donlon will be disconnected and MAME will drive SC, rom_req, etc.
rtl/darius2/darius2_dual68k_top.sv:1230 MAME chip signals
rtl/darius2/darius2_dual68k_top.sv:1322 u_scn_mame_2 (chip 3 ninjaw) rimosso: warriorb.cpp = 2 chip SCN.
rtl/darius2/darius2_dual68k_top.sv:1426 pal2 (TC0110PR chip 3) rimossa: warriorb.cpp = 2 palette chip.
rtl/darius2/darius2_dual68k_top.sv:1431 scn0_sc/scn1_sc emessi sincroni dai chip MAME → consumati direttamente dal compositor sotto.
rtl/darius2/darius2_dual68k_top.sv:1434 --- Palette lookup: BYPASS scn_line_buffer esterno (Donlon-legacy) --- Il chip MAME emette SC sincrono a render_x, NON serve ping-pong 13→24.
rtl/darius2/darius2_dual68k_top.sv:1436 Replica la logica sprite_wins del TC0110PR per blending corretto: FG vince sempre Sprite prio 0 vince su BG top (mid in MAME primask) e BG bottom Sprite prio 1 vince solo su BG bottom (sotto BG top/mid) SC[14:13] encoding (da tc0100scn_mame
rtl/darius2/darius2_dual68k_top.sv:1582 Range MRA per variant (warriorb.cpp): darius2d: main 1MB + Z80 128KB → sprite a 0x120000-0x31FFFF (2MB) warriorb: main 2MB + Z80 128KB → sprite a 0x220000-0x61FFFF (4MB)
rtl/darius2/darius2_dual68k_top.sv:1604 Output mux: select panel based on render_x Tile-RGB mux per warriorb.cpp: 2 panel a 320 px (threshold 320).
rtl/darius2/darius2_maincpu_map_new.sv:24 MAME: darius2_master_map (ninjaw.cpp)
rtl/darius2/darius2_maincpu_map_new.sv:142 --- Decode tables for warriorb.cpp variants (single 68000, 2-screen) --- darius2d: ROM 0x000000-0x0FFFFF (1MB: 512KB code + 512KB data) RAM 0x100000-0x10FFFF SCN0 0x200000-0x213FFF / ctrl 0x220000 SCN1 0x240000-0x253FFF / ctrl 0x26000
rtl/darius2/darius2_maincpu_map_new.sv:160 ROM mirror non usato: warriorb.cpp ha main 1MB (d2d) o 2MB (wb), niente mirror.
rtl/darius2/darius2_maincpu_map_new.sv:308 --- CPUA ctrl --- MAME cpua_ctrl_w: if only high byte is written (UDS only), shift high→low so bit 0 of the low byte is correctly set.
rtl/darius2/darius2_maincpu_map_new.sv:317 MAME-style high-byte-only normalization
rtl/darius2/darius2_maincpu_map_new.sv:327 --- TC0140SYT sound comm (real, no stub) --- MAME: $220001=master_port_w, $220003=master_comm_r/w Pilotiamo cs/wr/rd/a1 al TC0140SYT vero in audio_top.
rtl/darius2/darius2_sprite_renderer.sv:27 Sprite RAM format (MAME, 4 words per entry at $E00100): Darius 2 sprite format (ninjaw.cpp): word[0]: X position → sx = (data - 32) & 0x3FF word[1]: Y position → sy = data & 0x1FF word[2]: tile code[14:0] (0 = skip) word[3]: flipX[0], flipY
rtl/darius2/darius2_sprite_renderer.sv:48 X offset (scroll-dependent, from MAME draw_sprites x_offs parameter)
rtl/darius2/darius2_sprite_renderer.sv:88 warriorb.cpp: 2 panel × 320 = 640 px wide.
rtl/darius2/darius2_sprite_renderer.sv:89 V_ACTIVE varia per variant (MAME visarea Y): darius2d : 232 (riga 3*8..32*8-1) warriorb : 240 (riga 2*8..32*8-1)
rtl/darius2/darius2_sprite_renderer.sv:94 Sprite Y baseline (sub-component "y_offs = -8 MAME + north adjust").
rtl/darius2/darius2_sprite_renderer.sv:100 Sprite Y baseline 2 (formula MAME warriorb-family: `- sy - 24`).
rtl/darius2/darius2_sprite_renderer.sv:262 Priority mask MAME bit3 attr "unknown priority": pixel scritto da sprite con attr[3]=1 → prio_lb=1, vince anche su pixel gia' scritti da sprite con attr[3]=0.
rtl/darius2/darius2_sprite_renderer.sv:361 scn_sc[T+2] = pixel render_x[T] = render_x[T+2] - 2 (chip MAME stessa pipeline).
rtl/darius2/darius2_sprite_renderer.sv:383 Pixel extraction — formula derivata da MAME drawgfx.cpp readbit: src[bitnum/8] & (0x80 >> (bitnum%8)) → bit 0 del char = MSB del byte.
rtl/darius2/darius2_sprite_renderer.sv:388 16 : 0 bp = pix_idx[1:0] p0 = row_data[half_off + 12 + bp] p1 = row_data[half_off + 8 + bp] p2 = row_data[half_off + 4 + bp] p3 = row_data[half_off + 0 + bp] pixel = {p3, p2, p1, p0} gfx_16x16x4_packed_lsb (warriorb.cpp): row_data
rtl/darius2/darius2_sprite_renderer.sv:706 Lancia req ROM direttamente in RD_POP (mask 14-bit MAME drawgfx)
rtl/darius2/darius2_sprite_renderer.sv:718 Layout ROM addressing per variant: warriorb.cpp packed_lsb 16x16x4: d2d : {code[13:0], row[3:0], half_lr, 2'b00} — 2MB ROM wb : {code[14:0], row[3:0], half_lr, 2'b00} — 4MB ROM
rtl/darius2/darius2_sprite_renderer.sv:875 sprite_ob combinatorio da spr_disp_word (già registrato 1 clk da line buffer), allineato a scn_sc (anche registrato 1 clk dal chip MAME).
rtl/darius2/mame_warning_overlay.sv:22 mame_warning_overlay.sv — testo statico "DON'T BREAK YOUR WOOFER!" che appare per ~3 secondi quando l'utente attiva PSG=MAME nell'OSD audio mixer.
rtl/darius2/pc060ha_link.sv:25 Single-clock rewrite ispirato a jtrastan_pc060 (JTCORES by Jose Tejada), implementato secondo la descrizione di pc060ha_device in MAME.
rtl/darius2/sdram_bridge.sv:395 sub-CPU non esiste in warriorb.cpp (port unused)
rtl/darius2/tc0040ioc.sv:4 Author: Umberto Parisi (rmonic79) Version: 2.0 (warriorb.cpp only — TC0220IOC / TC0510NIO direct-mapped)
rtl/darius2/tc0040ioc.sv:8 tc0040ioc — I/O controller per warriorb.cpp.
rtl/darius2/tc0040ioc.sv:12 Read map (warriorb.cpp): 0x00: DSWA 0x01: DSWB 0x02: IN0 (player1 + coin/start) 0x03: IN1 (player2 joystick) 0x04: coin counters (regs[4]) 0x07: IN2 (buttons + freeze) Write a 0x00 = watchdog reset (ignorato), 0x04 = coin counters.
rtl/darius2/tc0110pr.sv:110 MAME chip behaviour: cpu_mode only closes on explicit VA=10.
rtl/darius2/tc0110pr.sv:132 Priority MAME ninjaw (draw_sprites + primask): sprite prio 0 (OB[13]=0): sotto FG, sopra tutto il resto sprite prio 1 (OB[13]=1): sotto FG, sotto MID layer, sopra BOTTOM SC[14:13] dal chip MAME tc0100scn codifica il RUOLO del layer visibile
rtl/darius2/tc0110pr.sv:154 layer BG "top" → MAME mid
rtl/darius2/tc0140syt.sv:101 MAME ninjaw usa NMI per svegliare Z80 al ricevimento comando audio.
rtl/darius2/tc_mame/tc0100scn_mame.sv:22 tc0100scn_mame.sv — TC0100SCN, MAME-accurate scanline renderer.
rtl/darius2/tc_mame/tc0100scn_mame.sv:24 Reference: MAME tc0100scn.cpp + ninjaw.cpp (Darius 2).
rtl/darius2/tc_mame/tc0100scn_mame.sv:25 Scroll math, tile lookup, pixel decode follow MAME exactly.
rtl/darius2/tc_mame/tc0100scn_mame.sv:33 MAME VRAM layout (wide mode, word offsets): $0000-$3FFF BG0 attrib+code (128×64 tiles, 2 words/tile) $4000-$7FFF BG1 attrib+code (128×64 tiles, 2 words/tile) $8000-$81FF BG0 row scroll (256 words) $8200-$83FF BG1 row scroll (256 words)
rtl/darius2/tc_mame/tc0100scn_mame.sv:53 0 = primo chip, 1 = chip successivi (flag MAME)
rtl/darius2/tc_mame/tc0100scn_mame.sv:145 Formula MAME (tc0100scn.cpp:285-286): xd = -m_x_offset - m_multiscrn_xoffs; yd = 8 - m_y_offset; → Chip 0: xd=-22, chip 1: xd=-24, chip 2: xd=-26; yd uguale per tutti (8).
rtl/darius2/tc_mame/tc0100scn_mame.sv:149 cliprect.top di ninjaw.cpp:938 = 3*8 = 24.
rtl/darius2/tc_mame/tc0100scn_mame.sv:149 MAME fa src_y += cliprect.top, equivale a usare effettivo scrolldy = yd - cliprect.top = 8 - 24 = -16.
rtl/darius2/tc_mame/tc0100scn_mame.sv:162 SCROLLDY = 8 (MAME yd) - P_Y_OFFSET - cliprect.top (24).
rtl/darius2/tc_mame/tc0100scn_mame.sv:189 VRAM bases CONDIZIONATI su wide/single (MAME spec).
rtl/darius2/tc_mame/tc0100scn_mame.sv:394 Row scroll index MAME (tc0100scn.cpp:649): indice = (y_cliprect - 8) & 0x1FF.
rtl/darius2/tc_mame/tc0100scn_mame.sv:443 MAME lo fa internamente nel gfx_element (drawgfx code % elements()).
rtl/darius2/tc_mame/tc0100scn_mame.sv:495 Col scroll per-tile (MAME tc0100scn.cpp:656): column_offset = colscroll_ram[src_x/8]; src_y_tile = line_sy - column_offset.
rtl/darius2/tc_mame/tc0100scn_mame.sv:562 FG text Y: warriorb mostra 1 scanline del tile adiacente (puntini sopra E sotto i glifi, assenti in MAME) → off-by-one sul FG.
rtl/darius2/triple_screen_test.sv:90 warriorb.cpp 2-screen: 640 px active (2 × 320), V variabile per variant: darius2d : 232 (MAME set_visarea(0, 319, 3*8, 32*8-1) = righe 24..255) warriorb : 240 (MAME set_visarea(0, 319, 2*8, 32*8-1) = righe 16..255)
rtl/darius2/triple_screen_test.sv:171 Sprite overlay (MAME ninjaw.cpp priority: "1 = low") prio=0 (primask GFX_PMASK_4): sprite sopra tutto tranne FG prio=1 (primask GFX_PMASK_4|GFX_PMASK_2): sprite sotto L1 (tile_prio=10) Draw se: no tile opaco, OR prio=0, OR tile NON è L1.
README.md:12 This core reimplements the hardware in SystemVerilog from MAME references and hardware observation.
README.md:60 Two TC0100SCN tilemap chips (MAME-accurate): BG0, BG1 with per-row scroll and per-column scroll, plus the FG0 text layer

Says it matches, follows or was checked against MAME — 1

rtl/darius2/sdram_bridge.sv:280 Word-swap concat (SIM-verified MAME-compliant).

Shares text with the MAME driver without saying so — 6

rtl/darius2/darius2_audio_top.sv:357 add_route(0, "subwoofer", 0.75) → PSG mono * 0.75 — shares text with taito/warriorb.cpp:648
rtl/darius2/darius2_audio_top.sv:358 add_route(1, "2610.1.l", 1.0) → FM_L → flt[0] (m_2610_l[0]) — shares text with taito/warriorb.cpp:649
rtl/darius2/darius2_audio_top.sv:359 add_route(1, "2610.1.r", 1.0) → FM_L → flt[1] (m_2610_r[0]) ← stesso input! — shares text with taito/warriorb.cpp:650
rtl/darius2/darius2_audio_top.sv:360 add_route(2, "2610.2.l", 1.0) → FM_R → flt[2] (m_2610_l[1]) — shares text with taito/warriorb.cpp:651
rtl/darius2/darius2_audio_top.sv:361 add_route(2, "2610.2.r", 1.0) → FM_R → flt[3] (m_2610_r[1]) — shares text with taito/warriorb.cpp:652
rtl/darius2/tc_mame/tc0100scn_mame.sv:146 xd = -m_x_offset - m_multiscrn_xoffs; — shares text with taito/tc0100scn.cpp:287

DCon#
D-Con
MiSTer-devel/Arcade-Dcon_MiSTer @ 3ad65361
MAME compared: seibu/dcon.cpp + 4 related file(s)
Read: 19 HDL files, 5,847 lines (Quartus project)

MiSTer official

Mostly MAME

medium

63%

Statements: 3 toward hardware, 43 toward MAME

Cites hardware documentation that MAME's driver does not — 2

rtl/DCon/DCon_main_top.sv:31 Memory map SD Gundam (da MAME dcon.cpp + SD Gundam override): $000000-$07FFFF ROM 68K (512KB) $080000-$08BFFF Main RAM (48KB) $08C000-$08C7FF BG tile RAM (2KB) $08C800-$08CFFF FG tile RAM (2KB) $08D000-$08D7FF MG tile RAM
rtl/DCon/DCon_maincpu_map.sv:29 Memory map SD Gundam (da MAME dcon.cpp + sdgndmps_map override): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $080000-$08BFFF Main RAM (48KB) → BRAM $08C000-$08C7FF BG tile RAM → BRAM dual-port $08C800-$

Reports a measurement taken on the original PCB — 1

rtl/DCon/DCon_video_timing.sv:26 PCB measurement Blood Bros: VSync 59.4094 Hz, HSync 15.6246 kHz, master XTAL 20 MHz.

Cites MAME source — 39

DCon.sv:208 I valori di calibrazione pixel-perfect MAME sono hardcodati DENTRO i rispettivi renderer: - Sprite X+1, Y+0 (rimosso -16 + +16 OSD): DCon_sprite_renderer.sv:178-179 - Text X+2, Y+0: DCon_text_renderer.sv (vedi sotto) - BG/MG/FG: nessun of
DCon.sv:282 --- Joystick to SD Gundam input mapping --- MAME P1_P2 port ($E0002): active low.
DCon.sv:586 ── Flip screen (CRTC reg 0x1A bit 0) ─────────────────────────────────────── MAME: BIT(reg_1a, 0) → flip_screen.
DCon.sv:628 D-Con Text: niente scroll (MAME screen_update_dcon non chiama set_scroll su text layer)
DCon.sv:662 D-Con CRTC scroll passthrough — nessun offset HW (MAME screen_update_dcon:214-219).
DCon.sv:771 Pixel pipeline con sprite + priority callback (MAME pri_cb dcon.cpp).
DCon.sv:772 pri_code semantics (MAME pri_mask 0xF0/0xFC/0xFE/0): pri=3 → sprite ABOVE ALL (mask=0, copre Text/FG/MG/BG, INSERT COIN, HUD) pri=0 → sprite ABOVE FG (copre FG, MG, BG; coperto solo da Text) pri=1 → sprite ABOVE MG (copre MG, BG; coperto
rtl/DCon/DCon_audio_z80.sv:25 Spec da MAME (reference/mame_seibu/seibusound.cpp + dcon.cpp:dcon): - Z80 @ 4.000000 MHz - YM3812 (jtopl2) @ 4.000000 MHz - OKI M6295 (jt6295) @ 1.320000 MHz, PIN7=LOW
rtl/DCon/DCon_audio_z80.sv:98 ─── Clock enable: clk_sys (96 MHz) → Z80/YM 4 MHz, OKI 1.32 MHz ───────── Z80/YM: 96/4 = 24 esatto → div 24, target 4.000 MHz (MAME dcon.cpp:541) OKI: 96/1.32 = 72.73 → div 73, target 1.315 MHz (errore 0.4%, accettabile)
rtl/DCon/DCon_audio_z80.sv:153 MAME audiocpu region layout (dcon):
rtl/DCon/DCon_audio_z80.sv:334 snd_rdata: D-Con usa main_r standard (MAME seibusound.cpp:287).
rtl/DCon/DCon_main_top.sv:31 Memory map SD Gundam (da MAME dcon.cpp + SD Gundam override): $000000-$07FFFF ROM 68K (512KB) $080000-$08BFFF Main RAM (48KB) $08C000-$08C7FF BG tile RAM (2KB) $08C800-$08CFFF FG tile RAM (2KB) $08D000-$08D7FF MG tile RAM
rtl/DCon/DCon_main_top.sv:197 VBLANK IRQ4 — MAME dcon.cpp: m_maincpu->set_vblank_int(irq4_line_hold) Rising edge di vblank → assert IRQ4 pending; IACK CPU → clear.
rtl/DCon/DCon_main_top.sv:340 XOR 0x400 lato CPU per allineare BRAM[N] = MAME text_vram[N] (renderer parte da addr 0).
rtl/DCon/DCon_main_top.sv:348 Quindi MAME palette[N] sta in vram_addr = (N + 0x400) & 0x7FF.
rtl/DCon/DCon_main_top.sv:349 Per allineare BRAM[N] = MAME palette[N] applichiamo XOR 0x400 SOLO al lato CPU (a_addr).
rtl/DCon/DCon_main_top.sv:350 Il renderer passa pen_index MAME nativo (BG=0x400+, MG=0x500+, ecc) e la BRAM è già allineata.
rtl/DCon/DCon_maincpu_map.sv:29 Memory map SD Gundam (da MAME dcon.cpp + sdgndmps_map override): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $080000-$08BFFF Main RAM (48KB) → BRAM $08C000-$08C7FF BG tile RAM → BRAM dual-port $08C800-$
rtl/DCon/DCon_maincpu_map.sv:160 ─── GFX bank register ─────────────────────────────────────────────────── MAME dcon.cpp gfxbank_w: SOLO bit0 → m_gfx_bank_select = 0x1000 oppure 0.
rtl/DCon/DCon_palette.sv:25 MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 2048); Address space CPU: 0x08E800..0x08F7FF (4 KB = 2048 word).
rtl/DCon/DCon_palette.sv:34 Espansione 5→8 bit con replica top-bits (standard MiSTer / MAME palette_device).
rtl/DCon/DCon_palette.sv:86 xBGR_555 → RGB888 con replica bit alti (5→8 standard MiSTer/MAME)
rtl/DCon/DCon_seibu_crtc.sv:23 Seibu CRTC fedele a MAME (src/mame/seibu/seibu_crtc.cpp).
rtl/DCon/DCon_seibu_crtc.sv:117 MAME mappa: bit0=screen0(BG), bit1=screen2(MG), bit2=screen1(FG), bit3=screen3(Text) (vedi seibu_crtc.cpp commento "screen 0=BG, screen 1=FG, screen 2=MG, screen 3=Text") In SD Gundam dcon.cpp layer_en_w gira la maschera così: ~layer_en bit
rtl/DCon/DCon_seibu_crtc.sv:126 Il dispatcher MAME usa "if (BIT(~m_layer_en, n))" per saltare = layer disabilitato quando il bit è 1.
rtl/DCon/DCon_sprite_renderer.sv:27 Format word (formato "comune", non alt_format) da MAME src/mame/seibu/sei021x_sei0220_spr.cpp: w0 bit 15 = enable (0=skip, 1=draw) w0 bit 14 = flip_x w0 bit 13 = flip_y w0 bit 12..10 = sizex (3-bit, +1) → 1..8 tile larghezza
rtl/DCon/DCon_sprite_renderer.sv:42 Multi-tile: tile_code += 1 per sub-tile (TODO: ordine x-major o y-major da verificare con dump MAME — assunto x-major per ora).
rtl/DCon/DCon_sprite_renderer.sv:45 Priority callback dcon.cpp::pri_cb: pri=0 → above FG pri=1 → above MG pri=2 → above BG pri=3 → above Text (= sotto Text)
rtl/DCon/DCon_sprite_renderer.sv:164 SEI0211 get_coordinate (MAME sei021x_sei0220_spr.h): coord &= 0x1ff; return (coord >= 0x180) ?
rtl/DCon/DCon_sprite_renderer.sv:173 Hardcode pixel-perfect MAME (valori netti commit 28adc3a, OSD a 0): X = sp_x_raw + 1 Y = sp_y_raw + 0 (era +16 OSD - 16 HW = 0 netto) xoff/yoff porte conservate per compat ma non più cablate al top.
rtl/DCon/DCon_sprite_renderer.sv:200 Tile code finale Y-MAJOR (MAME draw_internal: ax=outer, ay=inner, code++): sub_index = ax*sizey + ay → cur_tile = code + eff_tile_x*sp_h + eff_tile_y
rtl/DCon/DCon_text_renderer.sv:25 Specifiche da MAME (src/mame/seibu/dcon.cpp):
rtl/DCon/DCon_text_renderer.sv:126 --- Stage 0: tile coords --- Hardcode +2 X per pixel-perfect MAME (commit 28adc3a).
rtl/DCon/DCon_text_renderer.sv:184 --- Stage 3: pen decode --- MAME readbit: bit MSB-first → src[bn/8] & (0x80 >> (bn%8)) In Verilog LSB-first, bit position = 7 - (bn%8).
rtl/DCon/DCon_tile_layer.sv:25 Differenze fra layer (da MAME dcon.cpp):
rtl/DCon/DCon_video_timing.sv:35 Active area da MAME (sdgndmps_map): visarea 0..40*8-1, 2*8..30*8-1 quindi 320×224, V offset = 16 (top blank).
README.md:18 YM3812 OPL2 FM (jtopl2) + OKI M6295 ADPCM (jt6295) with MAME-accurate mixer
README.md:59 | Custom video CRTC| Seibu CRTC (legionna.cpp / seibu_crtc.cpp) |
README.md:130 The **MAME** project for invaluable hardware reference (`seibu/dcon.cpp`, `seibu/seibu_crtc.cpp`).

Says it matches, follows or was checked against MAME — 1

DCon.sv:290 SD Gundam SYSTEM port ($E0004) — verified MAME dcon.cpp:345-356 bit0 = START1 (active LOW) bit4 = START2 (active LOW) bit8 = SERVICE (active LOW) PORT_SERVICE_NO_TOGGLE altri = UNKNOWN/UNUSED → tied 1 Coin inputs NON sono qui

Shares text with the MAME driver without saying so — 3

rtl/DCon/DCon_palette.sv:23 Palette RAM Seibu D-Con (xBGR_555, 2048 entries). MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 2048); Address space CPU: 0x08E — shares text with seibu/dcon.cpp:559
rtl/DCon/DCon_text_renderer.sv:23 Text layer renderer Seibu D-Con (8x8, 4bpp, 64x32). Specifiche da MAME (src/mame/seibu/dcon.cpp): // get_text_tile_info tile = textram[tile_i — shares text with seibu/dcon.cpp
rtl/DCon/DCon_video_timing.sv:23 Video timing single-screen Seibu D-Con. SD Gundam Psycho Salamander gira su Seibu D-Con (PB91008), stessa famiglia di Blood Bros (1990). PCB measuremen — shares text with seibu/dcon.cpp

Deco16#
Crude Buster, Tatakae Genshizin Joe & Mac, The Cliffhanger - Edward Randy, Kuhga - Operation Code 'Vapor Trail'
MiSTer-devel/Arcade-Deco16_Mister @ 5e1ca62f
MAME compared: dataeast/cbuster.cpp, dataeast/cninja.cpp, dataeast/vaportra.cpp + 14 related file(s)
Read: 48 HDL files, 20,333 lines (Quartus project)

MiSTer official

Mostly MAME

medium

19%

Statements: 43 toward MAME

Cites MAME source — 35

rtl/cninja/jtcbuster_decoder.v:3 Crude Buster / Two Crude board decoder (doc/cbuster.cpp ::main_map).
rtl/cninja/jtcbuster_decoder.v:54 TC-4 registered-PAL protection HLE (doc/cbuster.cpp ::prot_w)
rtl/cninja/jtcbuster_decoder.v:58 MAME masks the write by mem_mask before matching, so mask cpu_dout by the active byte lanes: otherwise a byte write arrives with a stale high byte and never matches.
rtl/cninja/jtcninja_colmix.v:6 Each board has its own layer order, taken from its screen_update in MAME.
rtl/cninja/jtcninja_deco104.v:3 DECO 104 protection / I/O mux for Data East cninja.cpp (Joe & Mac).
rtl/cninja/jtcninja_deco104.v:11 Behaviour (see doc/deco146.cpp read_protport / write_protport): real_address = addr*2 & 0x7ff (addr = word offset) WRITE: store din to rambank[(ra&0xff)>>1]; special ports: 0x42 -> XOR reg, 0xee -> NAND reg, 0xa8 -> sound latch (+
rtl/cninja/jtcninja_deco104.v:32 The 146 (edrandy) is the SAME engine with its own port table and constants and NO magic read-address xor (deco146.cpp: m_magic_read_address_xor_enabled = false), so it is a second instantiation with the parameters below rather than a second
rtl/cninja/jtcninja_deco104.v:88 ---- I/O ports (MAME cninja PORT_START) ---- INPUTS (port A): P1 low byte, P2 high byte (active low).
rtl/cninja/jtcninja_deco104.v:89 Per MAME cninja PORT_START("INPUTS"): bits0-3 joyUDLR, b4 B1, b5 B2, b6 unused, b7 START1; bits8-11 joyUDLR(P2), b12 B1, b13 B2, b14 unused, b15 START2.
rtl/cninja/jtcninja_deco104.v:251 Log every completed protection READ so the values can be diffed against MAME.
rtl/cninja/jtcninja_deco16.v:7 Scroll modes (control1[6:5], per deco16ic.cpp deco16_pf_update / custom_tilemap_draw):
rtl/cninja/jtcninja_deco16ic.v:5 Per MAME (deco16ic.cpp device_start) the chip owns its own state, so it is modelled here: m_pf1_data 0x2000 bytes -> u_pf1 (AW=12) m_pf2_data 0x2000 bytes -> u_pf2 m_pf12_control 0x10 bytes -> u_mmr (jtdeco16ic_mmr, cfg/mmr.yaml)
rtl/cninja/jtcninja_decoder.v:3 Caveman Ninja / Joe & Mac board decoder (doc/cninja.cpp ::cninja_map).
rtl/cninja/jtcninja_decospr.v:4 MAME ref: decospr.cpp (mirrored in cores/cninja/doc).
rtl/cninja/jtcninja_game.v:19 SCAFFOLD -- Data East DECO 16-bit (cninja.cpp), Caveman Ninja / Joe & Mac.
rtl/cninja/jtcninja_game.v:103 The deco16ic register dump has no consumer: JTFRAME_IOCTL_RD is not set, so the core has no ioctl_din output and scenes are captured from MAME, not from hardware.
rtl/cninja/jtcninja_game.v:124 tiles2 also needs the MAME ROM_CONTINUE de-interleave (mame2mra emits mag-00|mag-01 naive; the real region swaps the middle 256kB blocks = word bits 17<->18), folded into the rotate.
rtl/cninja/jtcninja_game.v:305 xor (deco146.cpp disables it)
rtl/cninja/jtcninja_main.v:3 Main 68000 subsystem for the Data East cninja.cpp family.
rtl/cninja/jtcninja_main.v:220 A superset of MAME's PCs because of prefetch, so diff it as an in-order subsequence against the MAME trace.
rtl/cninja/jtcninja_main.v:236 Heartbeat: per-frame liveness + cumulative palette/tilegen/sprite write counts (compare to MAME: full boot writes 4096 palette + ~50k tilegen).
rtl/cninja/jtcninja_obj.v:59 cninja and cbuster both use MAME's tilelayout (dp straight) - cbuster verified at 98% vs screen.png.
rtl/cninja/jtcninja_snd.v:3 Sound subsystem for Data East cninja.cpp (Joe & Mac).
rtl/cninja/jtcninja_snd.v:13 HuC6280 physical sound_map (doc/cninja.cpp ::sound_map): 000000-00ffff program ROM A[20:16]==0 100000-100001 YM2203 A[20] & A[19:16]==0 110000-110001 YM2151 A[20] & A[19:16]==1 120000-120001
rtl/cninja/jtcninja_snd.v:227 The cninja attract is silent (only the YM2151 tempo timer) until the main CPU sends a play command (~frame 1106 in MAME, cmd 0x14) which drives the YM2203 music.
rtl/cninja/jtcninja_video.v:3 Video subsystem for the Data East 16-bit family (cninja.cpp and friends).
rtl/cninja/jtcninja_video.v:243 deco16ic bank callback (driver-provided in MAME).
rtl/cninja/jtcninja_video.v:383 vaportra uses the MXC-06 instead (vaportra.cpp: "same as Bad Dudes") - a different chip with a different sprite word format, vendored from cores/cop as jtcninja_mxc06 with the dec0 seallayout plane order.
rtl/cninja/jtdarkseal_decoder.v:3 Dark Seal / Gate of Doom board decoder (doc/darkseal.cpp ::main_map).
rtl/cninja/jtdarkseal_decoder.v:51 MAME does it once over the whole ROM in driver_init; the ROM is stored RAW in SDRAM and undone here, the only place it CAN live - it permutes bits inside a byte, which neither the MRA (byte/file level) nor the byte-serial download can expre
rtl/cninja/jtdeco_irq.v:3 Data East deco_irq (doc/deco_irq.cpp): vblank plus two programmable raster interrupts.
rtl/cninja/jtedrandy_decoder.v:3 The Cliffhanger - Edward Randy board decoder (doc/cninja.cpp ::edrandy_map).
rtl/cninja/jtedrandy_decoder.v:66 MAME runs edrandy with empty_init: the 68k ROM is not scrambled.
rtl/cninja/jtvaportra_decoder.v:3 Vapor Trail / Kuhga board decoder (doc/vaportra.cpp ::main_map).
rtl/cninja/jtvaportra_decoder.v:6 000000-07ffff program ROM ffc000-ffffff work RAM 100000 PLAYERS r / priority[0] w 100002 COINS r / priority[1] w 100004 DSW r 100007 soundlatch w (byte) 200000/202000 tilegen[1] data 240000-24000f

Says it matches, follows or was checked against MAME — 6

rtl/cninja/jtcbuster_decoder.v:94 H out={in4,in6,in7,in5,in3:0} L out={in7,in1,in5,in4,in6,in2,in3,in0} verified vs MAME: SSP=0x084000, PC=0x600, 0x606 = 46 FC 27 00
rtl/cninja/jtcninja_deco104.v:210 bankswitch side effect, deferred one cycle so the registered tw (e_port/e_off) matches the current access (MAME: off==0x66 on a non-latch read toggles the rambank).
rtl/cninja/jtcninja_decospr.v:25 The whole table is always covered, matching MAME's decospr, which has no per-line cap.
rtl/cninja/jtcninja_decospr.v:194 cninja AND cbuster both use MAME's `tilelayout` (same planeoffset), so they take dp straight - verified: cbuster sprite render matches MAME screen.png at 98% with dp, vs 21-29% for any swap.
rtl/cninja/jtcninja_game.v:126 Verified end-to-end against the MAME gfxdecode (0 px mismatch).
rtl/cninja/jtcninja_snd.v:229 Verified vs MAME.

Says it was translated, ported or taken from MAME — 1

rtl/cninja/jtcninja_deco104.v:5 Ported from MAME deco146.cpp / deco104.cpp (deco_146_base_device + deco104 specialisation).

Shares text with the MAME driver without saying so — 1

rtl/ikaopm/IKAOPM_lfo.v:431 TAP MSB 6 5 4 3 2 1 0 LSB Base value shift register 0 1 1 0 1 0 1 Volume register(AMD/PM — shares text with dataeast/cninja.cpp:70

DECOCassette#
Fishing, Astro Fantasia, Boulder Dash, Hamburger …
MiSTer-devel/Arcade-DECOCassette_MiSTer @ afc8122f
MAME compared: dataeast/decocass.cpp + 7 related file(s)
Read: 61 HDL files, 16,512 lines (Quartus project)

MiSTer official

Both

high

51%

Statements: 2 toward hardware, 285 toward MAME

Ships hardware documentation files — 1

Useful Information/schematics/decocassette.pdf

Notes where it differs from MAME — 1

rtl/mcu/mcu_tape_iface.v:142 The ORIGINAL forward decode drives the tape INTO the data region (RCLK@read lit, $05 delivered), so forward is empirically correct for THIS streamer's layout, even though it diverges from MAME's bit5-sign.

Cites MAME source — 237

Arcade-DECOCassette.sv:231 Keyboard coin/start (MAME defaults): 1 = 1P Start, 2 = 2P Start, 5 = Coin 1, 6 = Coin 2.
Arcade-DECOCassette.sv:281 MAME factory defaults (decocass.cpp DSW1/DSW2): sw[2]=DSW1=0x3F : Coin 1C/1C, "Type of Tape"=MD(Small)=0x30 (SW1:5,6, "Used by the bios"), Upright sw[3]=DSW2=0xFF : option bits all-default + "Country Code"=A=0xe0 (SW2:6,7,8, "DON'T CHANGE")
Arcade-DECOCassette.sv:418 2026-05-17 — Render-side charram lives in video_fg.v as 3 separate planes (per MAME `charlayout` 3bpp).
Arcade-DECOCassette.sv:444 MEMORY: decocrom overlay-PCB ROM (MAME "user3" region) — ctisland/ctisland2/ ctisland3/cexplore only.
Arcade-DECOCassette.sv:445 Banked over charram $6000-$AFFF via $E900 (decocass_e900_w -> m_rombank, decocass.cpp:2095-2105/130-135).
Arcade-DECOCassette.sv:579 MAIN CPU: DECO-222 @ 750 kHz (ce_hclk4 = HCLK4, per MAME decocass.cpp:1018)
Arcade-DECOCassette.sv:600 750 kHz CPU clock (HCLK4 per MAME decocass.cpp:1018)
Arcade-DECOCassette.sv:647 If the loader regresses on this build, flip back to the commented line below (joy[14]) to isolate — no rebuild-from-memory needed: .coin_in (joystick_0[14] | joystick_1[14]), // P1 or P2 coin → main-CPU NMI (MAME decocass_m.cpp:1
Arcade-DECOCassette.sv:756 2026-05-18 — full 8-bit dongle output (per MAME)
Arcade-DECOCassette.sv:908 2026-05-18: 8-bit per MAME
Arcade-DECOCassette.sv:911 2026-05-18 — dongle reads MCU host-bus registers per MAME `upi41_master_r(0)/(1)`.
Arcade-DECOCassette.sv:926 MAME decocass_e5xx_r: (offset & E5XX_MASK)==2 -> composite STATUS byte; else -> m_dongle_r(offset).
Arcade-DECOCassette.sv:933 MAME reads 0 there.
Arcade-DECOCassette.sv:942 e5xx_dongle : dongle_din_full); E5XX-STATUS-ROUTING-FIX-2026-06-10: MAME decocass_e5xx_r returns the 8041/tape STATUS for $E5x2/3 on ALL dongle types incl.
Arcade-DECOCassette.sv:944 Darksoft (darksoft_r is the ELSE branch = offset 0/1 only; decocass_m.cpp:1200,1229).
Arcade-DECOCassette.sv:951 dongle_din_full : 8'h00); DONGLE-DATA-UNGATE-2026-06-27: MAME decocass_e5xx_r (decocass_m.cpp:1227-1232) returns m_dongle_r(offset) for $E5x0/1 on ALL dongle types — NO OBF / 8041-status gate.
Arcade-DECOCassette.sv:953 The OBF gate below forced $E5x0/1 to 0x00 whenever OBF=0, which holds throughout type3 PROM-mode reads (data = m_donglerom[ctr], decocass_m.cpp:630, independent of the 8041) → BurgerTime's decrypt stream read back as 0x00 = garbage.
Arcade-DECOCassette.sv:959 e5xx_dongle // $E5x2/3 = STATUS byte, ALL types (MAME) : (dongle_type == 4'd7) ?
Arcade-DECOCassette.sv:962 $E5x2/3 = STATUS byte, ALL types (MAME)
Arcade-DECOCassette.sv:963 $E5x0/1 = dongle data, ALL types UNGATED (MAME m_dongle_r)
Arcade-DECOCassette.sv:1103 Prepare input signals from joysticks/buttons (inverted per MAME)
Arcade-DECOCassette.sv:1105 CONTROLS-ACTIVEHIGH-FIX-2026-06-10: MAME decocass IN0/IN1 are ACTIVE-HIGH (decocass.cpp:154-159, IP_ACTIVE_HIGH; bit0=R 1=L 2=U 3=D 4=B1 5=B2, bits6-7 UNUSED).
Arcade-DECOCassette.sv:1109 ORIGINAL (active-low = stuck-on), uncomment to restore: assign in0 = {2'b11, ~joystick_0[5:0]}; assign in1 = {2'b11, ~joystick_1[5:0]}; CONTROLS-UD-SWAP-2026-06-10: MiSTer joystick [3]=Up/[2]=Down, MAME IN0 bit2=Up/bit3=Down (decocass.cpp:1
Arcade-DECOCassette.sv:1220 Per MAME decocass.cpp, audio NMI enable is set by main CPU writes to $E416.
Arcade-DECOCassette.sv:1330 Sprites (task 10) SPRITE-DESC-SWIZZLE-FIX-2026-06-11: the sprite descriptor mirror must be a TRUE copy of fgvideoram, which applies the $C800-$CBFF mirror-swizzle (video_fg.v:71-74 / MAME mirrorvideoram_w: swap upper-5/lower-5 bits).
Arcade-DECOCassette.sv:1387 Per MAME decocass_v.cpp:323-333 (`decocass_paletteram_w`): offset = (offset & 31) ^ 16; m_palette->set_indirect_color(offset, ...); The hardware XORs bit 4 (and mod-32s) the CPU's write offset before committing it to the indirect-color tabl
rtl/clock_div.v:4 Single 96 MHz PLL output -> six CEs that match the DECO Cassette divider tree (decocass.cpp lines 59-63 + decocass_tape.cpp TAPE_CLOCKRATE).
rtl/cpu/T48/upi41_db_bus.vhd:220 MAME mcs48.cpp in_a_dbb: "acknowledge the IBF IRQ and clear the bit in STS"; the IBF interrupt is LEVEL-sensitive on STS_IBF (mcs48.cpp:1299).
rtl/cpu/deco222.v:5 Reference: MAME src/devices/cpu/m6502/deco222.cpp bswap = ((byte & 0x9F) | ((byte & 0x40) >> 1) | ((byte & 0x20) << 1)) i.e. swap bits D5 and D6 (corrected 2026-05-30 — was wrongly D1<->D6)
rtl/cpu/deco222.v:32 MAME formula: (b & 0x9F) | ((b&0x40)>>1) | ((b&0x20)<<1).
rtl/decocass.v:36 750 kHz CPU clock enable (HCLK4 = MASTER/16, per MAME decocass.cpp:1018)
rtl/decocass.v:75 MAME's
rtl/decocass.v:108 decocrom (MAME decocrom_map/init_decocrom): $6000-$AFFF banked read source, selected by $E900 (decocass_e900_w -> m_rombank->set_entry).
rtl/decocass.v:109 Writes are UNAFFECTED by the bank (always land in charram — decocass_de0091_w always calls decocass_charram_w regardless of bank, per MAME's own comment "cexplore requires us to allow them").
rtl/decocass.v:184 Main CPU NMI generation — MAME-faithful (decocass_m.cpp:150-159).
rtl/decocass.v:186 The previous implementation asserted NMI on every VBLANK rising edge, citing "per the hardware." But MAME asserts main-CPU NMI EXCLUSIVELY on coin insert (`INPUT_CHANGED_MEMBER(coin_inserted)` at decocass_m.cpp:155-159 → `set_input_line(NMI
rtl/decocass.v:191 No screen_vblank_callback / set_periodic_int / vblank-NMI binding exists anywhere in MAME's decocass machine config.
rtl/decocass.v:202 MAME treats coin as active-low and triggers on falling edge; translated here as rising edge of active-high coin_in = coin press.
rtl/decocass.v:223 MAME proof: DECO main CPU NMI is coin-ONLY (decocass_m.cpp:158), has NO IRQ, and NO vblank interrupt — the BIOS POLLS vblank via DSW1[7]/$E300 (decocass.cpp:214, already wired in cpu_din_mux ~line 454).
rtl/decocass.v:244 Address decode (lines 88-127 of decocass.cpp)
rtl/decocass.v:286 Per MAME `decocass.cpp:939-948` `charlayout`, the FG character set is 3 planes × 1024 tiles × 8 bytes = 24 KB, and each plane occupies a distinct 8 KB CPU window: Plane 0: $6000-$7FFF cpu_addr[15:13] == 3'b011 Plane 1: $8000-$9FFF cpu
rtl/decocass.v:335 paletteram: $E000-$E0FF (CPU readback dpram, no XOR — MAME stores the raw byte at `m_paletteram[offset]` so CPU readback returns the last-written value at the same offset.
rtl/decocass.v:378 Reference: decocass.cpp lines 105-118 for register semantics.
rtl/decocass.v:412 MAME: m_color_missiles = data & 0x77
rtl/decocass.v:424 decocass_e900_w: m_de0091_enable = data&3; set_entry SKIPPED (register unchanged) when data&3==3 (MAME's "invalid" guard) -> only actually load 0/1/2.
rtl/decocass.v:451 Reference: decocass.cpp lines 88-127 for read sources.
rtl/decocass.v:458 RAM: $0000-$5FFF (lines 94-97 of spec) NOTE: first arm narrowed to 00xx (was 0xxx) so $6000-$7FFF correctly routes to charram_q below, per decocass.cpp memory map.
rtl/decocass.v:474 Charram: $B000-$BFFF — NEVER banked (decocrom_map only overrides $6000-$AFFF; MAME's base decocass_map .ram() still owns this range even under init_decocrom).
rtl/decocass.v:499 DSW1: $E300 (line 110 of spec) Per MAME decocass.cpp PORT_START("DSW1"): bit[7] is VBLANK custom port, bits[6:0] are DIP switches.
rtl/dongle/dongle_darksoft.v:2 Darksoft multigame dongle (MAME: decocass_darksoft_state, decocass_m.cpp:1157-1187)
rtl/dongle/dongle_darksoft.v:28 low address byte (the MAME "offset")
rtl/dongle/dongle_darksoft.v:43 MAME offsets are exact 0 / 1 within the $E5xx window
rtl/dongle/dongle_mux.v:9 - Data input is `mcu_dbb_dout` (host DBBOUT, 8-bit) and `mcu_dbb_sts` (host DBBSTS, 8-bit), per MAME `upi41_master_r(0)/(1)`.
rtl/dongle/dongle_mux.v:39 MCU host-bus registers (DBBOUT/DBBSTS) per MAME `upi41_master_r(0/1)`
rtl/dongle/dongle_mux.v:111 Darksoft multigame dongle — 20-bit counter into a 1 MB ROM (MAME decocass_darksoft_state)
rtl/dongle/dongle_mux.v:123 Widel multigame dongle — 20-bit counter/latch into a 1 MB ROM (MAME decocass_widel_state)
rtl/dongle/dongle_mux.v:154 DONGLE-TYPE4-ADDR-FIX-2026-06-27: type4 (Scrum Try/Oozumou) PROM is 32 KB and the counter is 15-bit (decocass_m.cpp:887/891).
rtl/dongle/dongle_nodong.v:4 Per MAME `decocass_nodong_r` (decocass_m.cpp:1026-1058): offset & 1 == 0 → upi41_master_r(0) = MCU DBBOUT offset & 1 == 1 → upi41_master_r(1) = MCU DBBSTS
rtl/dongle/dongle_nodong.v:8 2026-05-18: takes MCU host-bus registers (NOT P2 outputs — the old `mcu_status_low` wiring was incorrect per MAME).
rtl/dongle/dongle_type1.v:4 Faithful to MAME decocass_type1_r (decocass_m.cpp:266-339), the per-game machine_resets (1457-1561), and the flags tables (357-460).
rtl/dongle/dongle_type1.v:10 Map VALUES from MAME via /tmp/gen_type1.py.
rtl/dongle/dongle_type1.v:38 Swap source = the 8041 host DATA byte (DBBOUT), per MAME decocass_type1_r.
rtl/dongle/dongle_type1.v:47 Regenerated from MAME (see header).
rtl/dongle/dongle_type1.v:113 ctisland3 (handcrafted dongle PROM; MAME comment: "correct for
rtl/dongle/dongle_type1.v:114 handcrafted prom" -> identity in/out maps, decocass_m.cpp:1563-1570)
rtl/dongle/dongle_type1.v:130 Latched MCU data byte (previous A0==0 read), per decocass_m.cpp:336.
rtl/dongle/dongle_type1.v:133 T1MAP(i,map) = (map >> i*3) & 7 (decocass_m.cpp:32-35)
rtl/dongle/dongle_type2.v:12 Reference: decocass_m.cpp lines 541-602
rtl/dongle/dongle_type2.v:14 State variables (from decocass_m.cpp): - m_type2_promaddr : PROM address (8 bits) from cpu_addr_lo on even-address write - m_type2_d2_latch : D2 status latch (bit 2 of initialization write) - m_type2_xx_latch : Enable latch (set when cpu
rtl/dongle/dongle_type2.v:19 Write behavior (decocass_m.cpp:569-602): - Odd address ($E5x1): Write initialization/D2 latch If xx_latch == 1: (no-op) If cpu_dout[7:4] == 0xC0: Set xx_latch = 1, D2 latch = (cpu_dout[2]) Otherwise: Forward to MCU - Even address ($E5x0): W
rtl/dongle/dongle_type2.v:28 Read behavior (decocass_m.cpp:541-567): - Odd address ($E5x1): Return PROM byte if xx_latch == 1, else MCU status - Even address ($E5x0): Return 0xFF (floating) if xx_latch == 1, else MCU data - PROM address: {D2_latch, promaddr[7:0]}
rtl/dongle/dongle_type2.v:46 2026-05-18: 8-bit per MAME
rtl/dongle/dongle_type2.v:64 Synchronous state updates (decocass_m.cpp:569-602, decocass_type2_w)
rtl/dongle/dongle_type2.v:74 Write handler (decocass_m.cpp:569-602)
rtl/dongle/dongle_type2.v:78 Activate PROM latch and capture D2 status bit (decocass_m.cpp:590-594)
rtl/dongle/dongle_type2.v:95 PROM address generation: {D2_latch, promaddr[7:0]} (decocass_m.cpp:549)
rtl/dongle/dongle_type2.v:101 Output data mux: PROM vs. MCU passthrough (decocass_m.cpp:541-567)
rtl/dongle/dongle_type3.v:14 Reference: decocass_m.cpp lines 622–851
rtl/dongle/dongle_type3.v:22 Counter behavior (decocass_m.cpp line 633): - Increments on cpu_re when offset & 1 == 1 and m_type3_pal_19 == 1 - Wraps to 0 at 4096
rtl/dongle/dongle_type3.v:31 Swap modes (TYPE3_SWAP_* enum, decocass_m.cpp lines 39–51): 0: TYPE3_SWAP_01 — swap bits 0 (d0_latch) and 1 (save[1]) 1: TYPE3_SWAP_12 — swap bits 1 (save[2]) and 2 (save[1]) 2: TYPE3_SWAP_13 — swap bits 1 (save[3]), 2 (save[2]), 3 (s
rtl/dongle/dongle_type3.v:44 Burger Time (cbtime) uses TYPE3_SWAP_12 (mode 1) — decocass_m.cpp line 1590.
rtl/dongle/dongle_type3.v:58 2026-05-18: 8-bit per MAME
rtl/dongle/dongle_type3.v:86 Write handler: cpu_we and cpu_addr_lo[0] == 1 (decocass_m.cpp lines 827–851)
rtl/dongle/dongle_type3.v:101 Read handler: cpu_re and cpu_addr_lo[0] == 1 (decocass_m.cpp lines 626–634)
rtl/dongle/dongle_type3.v:116 FIX 2026-05-30: MAME line 798 latches `save & 1` = the 8041 DATA byte's bit 0 (DBBOUT[0]), and only in the pal_19==0 path.
rtl/dongle/dongle_type3.v:126 PROM address generation: full 12-bit counter when pal_19 is active (decocass_m.cpp line 630: `data = m_donglerom[m_type3_ctrs];`) Counter wraps at 4096 — full 4 KB PROM is addressable.
rtl/dongle/dongle_type3.v:145 NOTE: For even address reads in PROM mode, return 0xFF (open bus) This is handled at line 654 in MAME and returns 0xFF.
rtl/dongle/dongle_type3.v:151 8041 status mode: apply bit-swap transformation Bit 0 is always D0 latch in most modes (except SWAP_34_7) FIX 2026-05-30: MAME swaps `save = upi41_master_r(0)` = the 8041 DATA byte (DBBOUT), NOT prom_q.
rtl/dongle/dongle_type3.v:157 Decode the swap mode and apply bit permutation (decocass_m.cpp lines 662–795)
rtl/dongle/dongle_type3.v:305 2026-05-18 — 8-bit per MAME decocass_type3_r.
rtl/dongle/dongle_type3.v:307 Output mux — MAME decocass_type3_r (dispatcher already gated offset&2==0): A0==1: pal_19 ?
rtl/dongle/dongle_type4.v:13 Reference: decocass_m.cpp lines 866-939
rtl/dongle/dongle_type4.v:15 State variables (from decocass_m.cpp): - m_type4_ctrs : 15-bit counter (0–0x7FFF, wraps at 0x8000) - m_type4_latch : Enable latch (set when cpu_dout[7:4] == 0xC on odd-address write)
rtl/dongle/dongle_type4.v:19 Write behavior (decocass_m.cpp:912-939): - Odd address ($E5x1): Load MSB of counter If latch == 1: Set m_type4_ctrs[14:8] = {cpu_dout[6:0], 1'b0} (7 bits) If cpu_dout[7:4] == 0xC0: Set latch = 1 Otherwise: Forward to MCU - Even address ($E5
rtl/dongle/dongle_type4.v:28 Read behavior (decocass_m.cpp:866-910): - Odd address ($E5x1): Return MCU status if latch == 1, else 0xFF - Even address ($E5x0): Return PROM byte if latch == 1 (auto-increment after) Counter increments after read: (m_type4_ctrs + 1) & 0x7F
rtl/dongle/dongle_type4.v:47 2026-05-18: 8-bit per MAME
rtl/dongle/dongle_type4.v:63 Synchronous state updates (decocass_m.cpp:912-939, decocass_type4_w)
rtl/dongle/dongle_type4.v:72 Write handler (decocass_m.cpp:912-939)
rtl/dongle/dongle_type4.v:76 Load MSB: counter[14:8] = {cpu_dout[6:0], 1'b0} (decocass_m.cpp:918, note the mask is 0x7f)
rtl/dongle/dongle_type4.v:87 Load LSB: counter[7:0] = cpu_dout (decocass_m.cpp:932)
rtl/dongle/dongle_type4.v:94 Read handler: auto-increment counter on even-address read (decocass_m.cpp:884-892)
rtl/dongle/dongle_type4.v:109 PROM address generation: 15-bit counter (decocass_m.cpp:887)
rtl/dongle/dongle_type4.v:115 Output data mux: PROM vs. MCU passthrough (decocass_m.cpp:866-910)
rtl/dongle/dongle_type5.v:11 Reference: decocass_m.cpp lines 950-1016
rtl/dongle/dongle_type5.v:13 State variables (from decocass_m.cpp): - m_type5_latch : Enable latch (set when cpu_dout[7:4] == 0xC on odd-address write)
rtl/dongle/dongle_type5.v:16 Write behavior (decocass_m.cpp:992-1016): - Odd address ($E5x1): Set latch If latch == 1: No-op (line 998) If cpu_dout[7:4] == 0xC0: Set latch = 1 (line 1002) Otherwise: Forward to MCU (line 1015) - Even address ($E5x0): Handled by MCU pass
rtl/dongle/dongle_type5.v:23 Read behavior (decocass_m.cpp:950-990): - Odd address ($E5x1): Return MCU status (line 958) - Even address ($E5x0): Return 0x55 if latch == 1 (line 971) Otherwise: Return MCU data or open-bus (lines 978-985)
rtl/dongle/dongle_type5.v:43 2026-05-18: 8-bit per MAME
rtl/dongle/dongle_type5.v:52 Synchronous state updates (decocass_m.cpp:992-1016, decocass_type5_w)
rtl/dongle/dongle_type5.v:60 Write handler (decocass_m.cpp:992-1016)
rtl/dongle/dongle_type5.v:75 Output data mux: Fixed 0x55 vs. MCU passthrough (decocass_m.cpp:950-990)
rtl/dongle/dongle_widel.v:8 Reference: decocass_m.cpp:1068-1146 (decocass_widel_r/_w), decocass.h:445-464.
rtl/dongle/dongle_widel.v:10 MAME semantics (offset bit1 already resolved upstream — the wrapper only routes here when cpu_addr[1]==0, i.e. $E5x0/$E5x1; $E5x2/$E5x3 go to the shared STATUS byte path outside this module, same convention as type1-5):
rtl/dongle/dongle_widel.v:18 Read $E501 (odd): - data = mcu_dbb_sts ALWAYS (latched or not) - latched ONLY: ctrs += 0x100 as a READ side effect (wraps mod 0x100000) (the counter still advances even though the returned byte is MCU status, not PROM data — this is genuine
rtl/dongle/dongle_widel.v:24 Write $E501 (odd): - latched: ctrs <= 0 (BOTH halves cleared; the written value is ignored — comment in MAME source: Treasure Island depends on this clearing the lower bits too) - not latched, (data[7:4]==0xC): latch <= 1 (activation
rtl/io/inputs.v:30 Raw input bus (from MiSTer hps_io via Arcade-DECOCassette.sv, task 26) Active-low for joysticks, buttons, coins per MAME INPUT_PORTS_START
rtl/io/inputs.v:40 TODO(verify-with-mame): MCU controls input mux for cdsteljn mahjong
rtl/io/inputs.v:47 Address decode for $E6xx (combinational read mux) Reference: decocass_m.cpp line 182-199, decocass_input_r(offset)
rtl/io/inputs.v:64 TODO(verify-with-mame): handled by separate module
rtl/io/inputs.v:73 Note: decocass.cpp line 214 defines DSW1[7] as: PORT_BIT( 0x80, IP_ACTIVE_HIGH, IPT_CUSTOM) PORT_READ_LINE_DEVICE_MEMBER("screen", FUNC(screen_device::vblank))
rtl/io/mahjong_panel.v:4 MAME init_cdsteljn: $E413 bits 3:2 select one of 4 rows; $E600/$E601 read the selected row for P1/P2, active-high: row 0: unused (0x00) row 1: A B C D E F G (bits 0-6) row 2: H I J K L M N (bits 0-6) row 3: Chi Pon Kan Reach Ron (bi
rtl/io/quadrature_adc.v:5 Cycle-accurate relative to MAME decocass_m.cpp: - decocass_quadrature_decoder_reset_w (line 161-166): latches all 4 axes - decocass_adc_w (line 168-170): no-op (ADC not actually used in cfishing) - decocass_input_r (line 182-199): reads qua
rtl/io/quadrature_adc.v:11 MAME simply latches analog[4] at reset and reads back.
rtl/io/quadrature_adc.v:43 Per MAME decocass_m.cpp line 161-166: void decocass_quadrature_decoder_reset_w(uint8_t data) { for (int i = 0; i < 4; i++) m_quadrature_decoder[i] = m_analog[i]->read(); // 0x10..0xf0
rtl/io/quadrature_adc.v:57 Center position (matches default 0x80 from decocass.cpp)
rtl/io/quadrature_adc.v:70 cpu_we_adc at $E420-$E42F is a no-op in MAME (line 168-170) No action needed.
rtl/io/quadrature_adc.v:83 For now, MAME cfishing emulation does NOT require true quadrature simulation—it only latches and reads back raw ADC values.
rtl/io/watchdog.v:16 Screen update at line 741 of decocass_v.cpp computes: flip_screen_set(m_watchdog_flip & BIT(m_dsw[0]->read(), 6)) where m_dsw[0] is DSW1 and bit 6 is the Cabinet (cocktail) bit.
rtl/io/watchdog.v:44 Watchdog counter logic Reference: decocass_v.cpp lines 388-393
rtl/io/watchdog.v:61 CPU writes to $E300: reload counter and clear reset Reference: decocass.cpp line 391-392
rtl/io/watchdog.v:78 Flip register and screen-flip output Reference: decocass_v.cpp lines 395-400, screen_update_decocass line 741
rtl/io/watchdog.v:95 CPU writes to $E301: store data Reference: decocass_v.cpp line 399
rtl/io/watchdog.v:101 Compute flip_screen: XOR of the flip register with cocktail DSW bit Reference: decocass_v.cpp line 741 (slightly reinterpreted for Verilog) flip_screen_set(m_watchdog_flip & BIT(m_dsw[0]->read(), 6))
rtl/io/watchdog.v:105 In MAME, this appears to AND the register with the DSW bit, but the task description says "XOR with DSW1[6]".
rtl/io/watchdog.v:106 Let's verify: - MAME line 741: flip_screen_set(m_watchdog_flip & BIT(m_dsw[0]->read(), 6)) - This is an AND, not XOR.
rtl/io/watchdog.v:110 TODO(verify-with-mame): Confirm flip_screen polarity.
rtl/io/watchdog.v:111 Currently implementing the MAME version (AND).
rtl/io/watchdog.v:116 AND as per MAME line 741
rtl/io/watchdog.v:123 Unused inputs (for reference): - cpu_dout[7:4] during $E300 write: ignored by watchdog (used for other purposes) - cpu_dout[7:4] during $E301 write: TODO(verify-with-mame) — not documented - BIT(cpu_dout, 3) on $E301 write: enables/disables
rtl/mcu/i8041_top.v:134 DMEM-RAM-128-2026-06-04: the DECO MCU is an I8041A (decocass.cpp:1025) = 128 bytes of internal RAM, NOT 64.
rtl/mcu/mcu_tape_iface.v:9 Pin mappings per decocass_m.cpp (lines 1734-1835):
rtl/mcu/mcu_tape_iface.v:11 P1 (tape data/status in; motor/direction/speed out): P1.0 ← tape_data (MAME: ~data bit if set, see decocass_m.cpp line 1778) P1.1 ← tape_clock (MAME: ~clk bit if set, line 1779) P1.2 ← tape_bot (MAME: ~BOT# if set, line 17
rtl/mcu/mcu_tape_iface.v:24 T0/T1 (timer inputs): T0 ← tape direction sensor (TODO: verify mapping in MAME) T1 ← tape status bit (TODO: verify mapping in MAME)
rtl/mcu/mcu_tape_iface.v:96 P1 Wiring (decocass_m.cpp lines 1734-1789)
rtl/mcu/mcu_tape_iface.v:99 That was WRONG: per MAME's i8041_p1_r (decocass_m.cpp:1768-1789), P1 reads return `m_i8041_p1` unchanged — i.e. whatever the MCU LAST WROTE.
rtl/mcu/mcu_tape_iface.v:115 For OUR tape_streamer, we need to derive motor/direction/speed from P1.4/5/2 according to the MAME-decoded LOG semantics: FAST = ~P1.2 (bit 2 = 0 means fast) REW = ~P1.4 (bit 4 = 0 means rewind active) FWD = ~P1.5 (bit 5 = 0 means forward
rtl/mcu/mcu_tape_iface.v:124 No external drives on P1 (per MAME)
rtl/mcu/mcu_tape_iface.v:129 TAPE-DIR-2026-06-04: a MAME-LITERAL swap (rew=~P1.5, fwd=P1.5&~P1.4, from i8041_p1_w where bit5=0 => NEGATIVE speed) was TRIED and REVERTED — it REGRESSED on FPGA: with the ORIGINAL decode the tape reads blocks (counter 999->998, then ERROR
rtl/mcu/mcu_tape_iface.v:135 MAME's bit5=0=>negative is a DIFFERENT physical convention (reads while rewinding) that does NOT map onto this streamer's clockpos layout.
rtl/mcu/mcu_tape_iface.v:144 (Why MAME's negative-speed read works in MAME but not ported = unresolved; not the bug to chase — the $05 garbage on a FORWARD read is.) MAME-literal kept for reference (do NOT re-enable — proven worse): wire rew_active = ~mcu_p1_out[5]; w
rtl/mcu/mcu_tape_iface.v:162 P2 Wiring (decocass_m.cpp lines 1791-1835)
rtl/mcu/mcu_tape_iface.v:165 Per MAME's i8041_p2_r (line 1816): data = (m_i8041_p2 & ~0xe0) | m_cassette->get_status_bits(); So P2[7:5] are OR'd with the cassette status bits, while P2[4:0] come from the MCU's own latched writes.
rtl/mcu/mcu_tape_iface.v:171 From decocass_tape.cpp:288-338 (get_status_bits): bit 0x20 = BOT/EOT (set in LEADER, BOT, EOT, TRAILER regions) bit 0x40 = RCLK (read clock — active in data region) bit 0x80 = RDATA (read data bit)
rtl/mcu/mcu_tape_iface.v:192 T0/T1 Wiring — MAME does NOT register callbacks for T0/T1 on the MCU (decocass.cpp:1026-1029 only wires P1/P2).
rtl/mcu/mcu_tape_iface.v:291 MAME-PARITY 2026-05-30: route the host strobe to the i8041 ONLY for $E5x0/$E5x1 (offset bit1 == 0).
rtl/mcu/mcu_tape_iface.v:292 MAME `decocass_e5xx_w` sends a 6502 write to `upi41_master_w` only when (offset & E5XX_MASK[0x02]) == 0; $E5x2/$E5x3 are STATUS/dongle space and must NOT reach the MCU.
rtl/mcu/mcu_tape_iface.v:312 MAME-PARITY 2026-05-30: gated e5_we_mcu/e5_re_mcu (was cpu_e5_we/cpu_e5_re) so only $E5x0/$E5x1 reach the MCU; $E5x2/$E5x3 no longer strobe it.
rtl/mcu/mcu_tape_iface.v:378 DONGLE-E5XXMASK-GATE-2026-06-27: MAME routes ONLY $E5x0/$E5x1 (offset & E5XX_MASK[0x02])==0 to the dongle (decocass_e5xx_r:1200/1227, decocass_e5xx_w); $E5x2/$E5x3 are STATUS and NEVER reach m_dongle_r/_w.
rtl/mcu/mcu_tape_iface.v:392 Return result to main CPU — MAME splits behavior on (offset & E5XX_MASK) where E5XX_MASK = 0x02 (decocass_m.cpp:212):
rtl/mcu/mcu_tape_iface.v:395 (offset & 2) == 2 → STATUS byte composed from MCU/cassette state (decocass_m.cpp:1199-1213) (offset & 2) == 0 → dongle data path (decocass_m.cpp:1227-1233)
rtl/mcu/mcu_tape_iface.v:406 Status byte mapping (MAME decocass_m.cpp:1204-1212): D7 = !cassette_present (active-low; 0 = present) D6 = 1 (floating input) D5 = 1 (floating input) D4 = bot_eot (BOT/EOT direct from drive
rtl/mcu/mcu_tape_iface.v:446 MAME `decocass_e5xx_r` returns DBBOUT LIVE (m_dongle_r, no latch).
rtl/mcu/mcu_tape_iface.v:461 TODO(verify-with-mame): P2[7:4] status bit sources (tape BOT/EOT, etc.) TODO(verify-with-mame): T0/T1 timer input mapping in decocass_m.cpp TODO(new-signal-decocass.v): Add cpu_re_e5xx strobe (currently only cpu_we_e5xx exists) TODO(new-sig
rtl/mcu/tape_streamer.v:1 DECO Cassette System — Tape Streamer Synthesized implementation of decocass_tape.cpp
rtl/mcu/tape_streamer.v:7 Mirroring MAME decocass_tape.cpp: maintains clockpos (tape position), computes region/byte/bit from clockpos, reads image bytes, applies CRC16, and outputs serial stream with framing.
rtl/mcu/tape_streamer.v:39 Constants from decocass_tape.cpp
rtl/mcu/tape_streamer.v:59 Data block structure (MAME decocass_tape.h BYTE_BLOCK_TOTAL = 331): PRE_GAP(34) + LEADIN(1) + HEADER(1) + DATA(256) + CRC_MSB(1) + CRC_LSB(1) + TRAILER(1) + LEADOUT(1) + LONGCLOCK(1) + POSTGAP(34) = 331 bytes FIX 2026-05-30: was 297 — the p
rtl/mcu/tape_streamer.v:132 MAME |speed| is 7 (fast) or 1 (normal); speed_select==2'b10 = fast.
rtl/mcu/tape_streamer.v:207 Region detection (mirrors MAME lines 232-275)
rtl/mcu/tape_streamer.v:242 TAPE-EOT-FIX-2026-06-04: mirror of the leader side, measured down from total_clocks (MAME decocass_tape.cpp:251-258).
rtl/mcu/tape_streamer.v:266 Current byte value selection Mirrors MAME get_status_bits() logic
rtl/mcu/tape_streamer.v:293 MAME never sees this (lockstep functional model, no async sampling).
rtl/mcu/tape_streamer.v:296 RCLK unchanged (still MAME-faithful).
rtl/mcu/tape_streamer.v:311 Output: tape_clock (active high during clocked regions, MAME line 304-315)
rtl/mcu/tape_streamer.v:318 MAME decocass_tape.cpp:305 — read clock (bit 0x40) is HIGH when (clockpos-offset) is EVEN.
rtl/mcu/tape_streamer.v:319 even -> 1, odd -> 0 (== MAME 0x40)
rtl/mcu/tape_streamer.v:321 FIX 2026-05-30: was `~clk_bit`, which inverted the read clock vs MAME -> MCU sampled tape data on the wrong edge -> no valid bytes -> "deck not responding".
rtl/mcu/tape_streamer.v:324 alternating read clock (MAME polarity)
rtl/mcu/tape_streamer.v:328 Output: tape_bot and tape_eot (hole sense signals) Mirrors MAME get_status_bits() lines 292-294
rtl/mcu/tape_streamer.v:332 TAPE-EOT-FIX-2026-06-04: MAME sets the 0x20 hole-sense in LEADER|BOT|EOT|TRAILER
rtl/mcu/tape_streamer.v:333 (get_status_bits, decocass_tape.cpp:293).
rtl/mcu/tape_streamer.v:339 end-side holes (combined = MAME 0x20)
rtl/ram_rom/cassette_loader.v:8 CRC16 implementation per MAME `decocass_tape.cpp:136-145` (`tape_crc16_byte`): for (i = 0; i < 8; i++) { crc = (crc >> 1) | (crc << 15); // rotate right crc ^= (data << 7) & 0x80; // current data bit -> bit 7 if (crc & 0x80) crc ^=
rtl/ram_rom/cassette_loader.v:20 MAME brute-forces `testval` (decocass_tape.cpp:109-112) but always lands on the running CRC, so storing the running CRC directly is exactly correct — no brute-force needed.
rtl/ram_rom/cassette_loader.v:71 FIX 2026-05-30: the original omitted MAME's `data >>= 1;` (line 144), so it XORed bit 0 of `d` on all 8 iterations instead of bits 0..7 — i.e. it dropped 7 of every 8 data bits.
rtl/ram_rom/cassette_loader.v:91 MAME line 144 — advance to next data bit
rtl/ram_rom/cassette_loader.v:111 NUMBLOCKS-FIX-2026-06-07: track the LAST NON-ZERO byte (MAME: numblocks = ((last_nonzero|0xFF)+1)/256), NOT the full file size.
rtl/video/video_bg.v:8 This is the MAME-faithful structure (decocass_v.cpp draw_edge:625, get_bg_l/r:199-219, video_start:700-704, tile_offset[32*32]:130-163).
rtl/video/video_bg.v:16 If BurgerTime/LnC shift by ~256px on the first build, that pins the hcnt/vcnt-vs-MAME origin delta (read it via MAME's screen_update popmessage: key 'I' → mode/h/vl/vr) and we add a constant origin offset.
rtl/video/video_bg.v:24 MAME reference (decocass.cpp:961-970 tilelayout, decocass_v.cpp:130-163 tile_offset, decocass_v.cpp:199-228 get_bg_*_tile_info): - 32×32 tilemap of 16×16-pixel tiles - 16 unique tile bitmaps (4-bit tile_code), 3 bits per pixel - tilemap cod
rtl/video/video_bg.v:34 Pixel-byte mapping (per MAME tilelayout): tile N, row y, pixel x (16 pixels per row):
rtl/video/video_bg.v:57 FG color register — also drives BG color (decocass_v.cpp:201-204)
rtl/video/video_bg.v:109 tile_offset LUT — full 32×32 (decocass_v.cpp:130-163).
rtl/video/video_bg.v:152 BG-SKEWFIX-2026-06-28: the tile-code BRAM (bg_tilecodes) has 1-cycle read latency, so `tilecode_byte` reflects the tile from hcnt N-1 while pix_x/eff_pix_y/blank_comb are from hcnt N. Latching them together (original s1 below) drew tile N-1
rtl/video/video_bg.v:227 Extract pixel bits from the bytes: plane 0: byte[4 + pix_x[1:0]] — upper nibble of $D0xx byte plane 1: byte[0 + pix_x[1:0]] — lower nibble of $D4xx byte plane 2: byte[4 + pix_x[1:0]] — upper nibble of $D4xx byte BG-BITMAP-FIX-2026-06-10: MS
rtl/video/video_bg.v:242 Output: palette index per MAME get_bg_l_tile_info (decocass_v.cpp:199-208): color = (m_color_center_bot >> 7) & 1 (1 bit) tileinfo.set(2, tile_code, color * 4 + 1, 0) Use {1'b0, color, pen[2:0]} (5-bit).
rtl/video/video_bg.v:249 PALETTE-BG-COLORSET-2026-06-28: emit the FULL 6-bit pen per MAME gfx(2) color = `color*4+1`.
rtl/video/video_fg.v:5 Geometry: 32 cols × 32 rows × 8×8 pixels = 256×256 px tilemap Scan order: column-major per MAME decocass_v.cpp:187-192 fgvideoram_scan_cols
rtl/video/video_fg.v:21 Previous version was 2 planes × 4 KB = 8 KB total (vs. MAME's 3 planes × 8 KB = 24 KB), used 8-bit tile codes (vs. 10-bit), and built fg_pen as `{attr[2:0], pen[1:0]}` (vs. MAME's `{0, color_center_bot[0], pen[2:0]}`).
rtl/video/video_fg.v:28 See `Common-Pitfalls/MAME palette address transforms are load-bearing` and [[decocass_white_screen_audit_2026-05-16]] for the full investigation.
rtl/video/video_fg.v:48 FG color register (decocass.cpp E410 — get_fg_tile_info uses BIT(.,0))
rtl/video/video_fg.v:85 fgvram & colorram have a SWIZZED MIRROR at $C800-$CFFF per MAME `mirrorvideoram_w` (decocass_m.cpp:72-73): swap upper 5 bits and lower 5 bits of the 10-bit offset.
rtl/video/video_fg.v:112 10-bit tile code per MAME get_fg_tile_info: tile_index = 256 * (attr & 3) + code = {attr[1:0], code[7:0]}
rtl/video/video_fg.v:155 FLIP-FIX 2026-05-30: MAME's gfx decode is MSB-FIRST — pixel x reads bit (7-x) via the `(src >> (7 - (bit&7)))` extraction, NOT "bit x".
rtl/video/video_fg.v:184 FG palette index — MAME get_fg_tile_info: tileinfo.set(0, // gfx 0 (charlayout) 256 * (attr & 3) + code, // tile index BIT(m_color_center_bot, 0), // color = 0 or 1 0); g
rtl/video/video_missiles.v:7 MAME decocass_v.cpp:572-617 draw_missiles.
rtl/video/video_missiles.v:99 upper drawn after lower in MAME → upper wins on overlap
rtl/video/video_mixer.v:1 DECO Cassette — Final pixel mixer + LS148 priority encoder (task 11) Implements the priority order from MAME screen_update_decocass (decocass_v.cpp:719-784) and draw_special_priority / draw_edge / draw_center effects.
rtl/video/video_mixer.v:5 Priority order (from decocass_v.cpp 743-780): 1.
rtl/video/video_mixer.v:7 If mode_set & 0x08: draw_edge ×2 (opaque, decocass_v.cpp:747-751) 3.
rtl/video/video_mixer.v:8 If mode_set & 0x20: draw_center (opaque, decocass_v.cpp:753-755) Else: draw_center, then draw_edge ×2 (transparent, decocass_v.cpp:757-764) 4.
rtl/video/video_mixer.v:10 FG tilemap (transparent on pen 0, decocass_v.cpp:771) 5.
rtl/video/video_mixer.v:11 Sprites (transparent on pen 0, decocass_v.cpp:774) 6.
rtl/video/video_mixer.v:12 Missiles (transparent on pen 0, decocass_v.cpp:777) 7.
rtl/video/video_mixer.v:13 draw_special_priority (headlight/tunnel pen-bit-4 modulation, decocass_v.cpp:780)
rtl/video/video_mixer.v:60 Priority multiplexer following decocass_v.cpp 719-784
rtl/video/video_mixer.v:63 Base fill color (pen 8, from decocass_v.cpp:744)
rtl/video/video_mixer.v:72 TODO(verify-with-mame): draw_special_priority headlight/tunnel detection decocass_v.cpp:235-290 checks: - crossing = mode_set[1:0] (0=outside, 1=exiting, 2=inside, 3=entering) - pri2 condition depends on crossing and back_h_shift (tunnel en
rtl/video/video_mixer.v:95 Step 2: Draw edge opaque if bkg_ena and edge_valid From decocass_v.cpp:747-751
rtl/video/video_mixer.v:104 Step 3: Draw center or edge transparent From decocass_v.cpp:753-765
rtl/video/video_mixer.v:107 Center color from decocass_v.cpp:292-304 Bits [4:2] of color_center_bot -> pen color [2:0] But decocass_paletteram_w uses bits [2:0] of written byte as color index For center: use color_center_bot bits as direct pen value TODO(verify-with-m
rtl/video/video_mixer.v:122 Step 4: FG tilemap (transparent on pen 0, decocass_v.cpp:771)
rtl/video/video_mixer.v:128 Step 5: Sprites (transparent on pen 0, decocass_v.cpp:774)
rtl/video/video_mixer.v:134 Step 6: Missiles (transparent on pen 0, decocass_v.cpp:777)
rtl/video/video_mixer.v:140 Step 7: draw_special_priority (decocass_v.cpp:780) TODO(verify-with-mame): full headlight/tunnel logic From decocass_v.cpp:235-290: - crossing = mode_set[1:0] - if (crossing == 0 && !tunnel_active) return - if (!cross_on) return - color = b
rtl/video/video_palette.v:4 Architecture (from decocass_v.cpp and decocass.cpp): - 64 logical pens (0-63) - Pens 0-31 map directly to CLUT entries 0-31 - Pens 32-63 map to CLUT entries with bitswap applied (bit flip for headlight mode) - Palette RAM ($E000-$E0FF, 256
rtl/video/video_palette.v:12 From decocass_v.cpp:323-333 (decocass_paletteram_w): - offset = (offset & 31) ^ 16 // XOR A4 (bit 4) into the CLUT index - RGB output is inverted: ~data[2:0] for R, ~data[5:3] for G, ~data[7:6] for B - pal3bit(x) = (x<<5)|(x<<2)|(x>>1) //
rtl/video/video_palette.v:18 From decocass.cpp:1004-1012 (decocass_palette): - Pens 0-31: set_pen_indirect(i, i) - Pens 32-63: set_pen_indirect(32+i, bitswap(i, 7,6,5,4,3,1,2,0))
rtl/video/video_palette.v:42 Palette RAM: 256-byte dual-port BRAM Stores PROM color indices (5 bits per entry) CPU writes at $E000-$E0FF; read indexed by pen[4:0] Note: pen[5] selects between two alternate palettes (direct vs. bitswapped) which is handled by the indire
rtl/video/video_palette.v:50 INVERT-AT-WRITE 2026-05-16: real hardware has inverters on the palette ROM output (the `~data` in MAME's decocass_paletteram_w).
rtl/video/video_palette.v:59 Any actual BIOS-written byte gets its bits inverted on storage; the downstream decode then takes the bits directly, producing the same final RGB as MAME's `~data` formula.
rtl/video/video_palette.v:64 PALETTE-BG-COLORSET-2026-06-28: pens 32-63 use MAME's BITSWAPPED indirect half (decocass_palette: set_pen_indirect(32+i, bitswap<8>(i,7,6,5,4,3,1,2,0)) = swap pen bits 1↔2).
rtl/video/video_palette.v:80 Direct RGB decode from the palette byte (MAME decocass_paletteram_w).
rtl/video/video_palette.v:83 The byte stored in the palette encodes RGB directly per decocass_v.cpp:323-333: m_palette->set_indirect_color(offset, rgb_t(pal3bit(~data >> 0), // R pal3bit(~data >> 3), // G pal2bit(~data >> 6))); // B
rtl/video/video_sprites.v:5 References: MAME decocass_v.cpp:524-569 draw_sprites MAME decocass.cpp:950-959 spritelayout (16,16, 256, planes=3, the offsets below)
rtl/video/video_sprites.v:10 Per slot, interleave 0x20: [offs+0x00] flags : bit0 = enable, bit1 = flipy, bit2 = flipx [offs+0x20] code : 0..255 (index into the 16×16 sprite set in charram) [offs+0x40] Y : sy = 240 - Y [offs+0x60] X : sx = 240 - X Draw order s
rtl/video/video_timing.v:1 DECO Cassette — Video timing generator (task 07) Raster counters + HSYNC/VSYNC/HBLANK/VBLANK generation Derived from MAME's set_raw(HCLK, 384, 0*8, 256, 272, 1*8, 248)

Says it matches, follows or was checked against MAME — 19

Arcade-DECOCassette.sv:936 This drops the rt_seen05E2 game-PC dependency and matches MAME's idle $E500=0.
Arcade-DECOCassette.sv:955 Ungated now, matching the darksoft path and MAME.
Arcade-DECOCassette.sv:1485 The hblank/vblank windows themselves already match MAME set_raw(384,0,256,272,8,248), so ONLY this alignment delay is needed -- nothing in vcnt/vblank.
rtl/decocass.v:12 This matches MAME's DECO_222(config, m_maincpu, HCLK4) at decocass.cpp:1018.
rtl/dongle/dongle_darksoft.v:11 The read returns the byte at the CURRENT address; the increment lands on the next ce_hclk4 edge, so the 6502 (which samples cpu_din_full combinationally during its slow ce_main read) always sees the pre-increment byte — matching MAME order.
rtl/dongle/dongle_mux.v:7 2026-05-18 — REWORKED interface to match MAME: - Each dongle returns 8-bit `cpu_din_full` (was 4-bit `cpu_din_low4`).
rtl/dongle/dongle_type1.v:9 2026-05-30 RE-KEY: game_id is now the DECO RELEASE NUMBER (8-bit), matching MAME's numbering (decocass.cpp per-game release-number comments).
rtl/io/quadrature_adc.v:63 Latch the four analog inputs at reset time This matches MAME's behavior exactly:
rtl/mcu/mcu_tape_iface.v:139 DIRECTION: tested MAME-literal (rew=~P1.5/fwd=P1.5&~P1.4) WITH the probe 2026-06-04 → MEASURABLY WORSE: tape ran to the clockpos-0 wall, read_block never dispatched ($2E8 dark), nothing delivered (ROW2/3 = $00), BOT-now lit.
rtl/mcu/mcu_tape_iface.v:154 FIX 2026-05-30: speed_select now encodes MAGNITUDE only (direction is tape_direction above); 00=stop, 01=normal(1x), 10=fast(7x) — matches MAME |speed| 0/1/7.
rtl/mcu/mcu_tape_iface.v:384 Gate the strobes to $E5x0/1 to match MAME's E5XX_MASK.
rtl/mcu/tape_streamer.v:322 Now matches MAME line 305.
rtl/ram_rom/cassette_loader.v:70 CRC16 step matching MAME `tape_crc16_byte` (decocass_tape.cpp:136-145) exactly.
rtl/ram_rom/cassette_loader.v:73 (The predecessor's "only bit 0 contributes" comment was them missing line 144.) With the shift, the CRC is correct, and since testval == running-CRC for this polynomial (verified), storing the running CRC below is exactly MAME's brute-force
rtl/video/video_fg.v:8 CHARACTER FORMAT — VERIFIED FROM MAME decocass.cpp:939-948 `charlayout`: - 8×8 pixel characters - 1024 characters total (10-bit tile code) - 3 bits per pixel — THREE planes - Plane offsets: 0, 8192, 16384 bytes (in CPU $6000-$BFFF region) -
rtl/video/video_palette.v:93 pal3bit (3-bit → 4-bit) closed-form: out = {x, x[2]} verifies: 0→0, 1→2, 2→4, 3→6, 4→9, 5→11, 6→13, 7→15 (matches MAME) pal2bit (2-bit → 4-bit) closed-form: out = {x, x} verifies: 0→0, 1→5, 2→10, 3→15 (matches MAME)
rtl/video/video_palette.v:105 That makes default-0 BRAM decode to BLACK (matching MAME's default state) and BIOS-written bytes decode to the same final RGB as MAME's `~data`.
rtl/video/video_sprites.v:106 Per-pixel priority select: highest slot index covering (hcnt,vcnt) wins (matches MAME draw order).
rtl/video/video_timing.v:67 TOP-EXPAND-2026-06-29: high edge 255->257 = +2 rows at the display-TOP (high hcnt) to restore the 2 truncated BG rows / match MAME.

Says it was translated, ported or taken from MAME — 5

rtl/cpu/deco222.v:28 The old D1<->D6 swap was WRONG (predecessor mis-transcribed MAME): it turned the BIOS reset entry $F053 (raw 38 B8 C2 FF 9A) into SEC/CLV/illegal garbage, and $F615 raw $DD into illegal $9F (CPU jammed there = the black-screen hang).
rtl/decocass.v:7 Based on MAME src/mame/deco/decocass.cpp: - decocass_map (lines 88-127): address map decode - decocrom_map (lines 130-134): extended banking (not yet implemented)
rtl/io/inputs.v:8 Based on MAME src/mame/deco/decocass_m.cpp: - decocass_input_r (lines 182-199): dispatches by offset[2:0]
rtl/io/watchdog.v:9 Based on MAME src/mame/deco/decocass_v.cpp: - decocass_watchdog_count_w (lines 388-393): loads counter with (data & 0x0f) + 1, calls watchdog_reset() to clear overflow.
rtl/mcu/tape_streamer.v:213 Ported MAME's symmetric end-of-tape boundaries (decocass_tape.cpp:251-258), measured DOWN from total_clocks (mirror of the leader side).

Shares text with the MAME driver without saying so — 24

Arcade-DECOCassette.sv:282 sw[2]=DSW1=0x3F : Coin 1C/1C, "Type of Tape"=MD(Small)=0x30 (SW1:5,6, "Used by the bios"), Upright — shares text with dataeast/decocass.cpp:206
Arcade-DECOCassette.sv:1389 m_palette->set_indirect_color(offset, ...); — shares text with dataeast/decocass_v.cpp:332
rtl/dongle/dongle_type1.v:57 chwy (DECO release 1) -latch_27_pass_3_inv_2 — shares text with dataeast/decocass_m.cpp:413
rtl/dongle/dongle_type1.v:65 cterrani (DECO release 4) -latch_26_pass_3_inv_2 — shares text with dataeast/decocass_m.cpp:357
rtl/dongle/dongle_type1.v:73 castfant (DECO release 7) -latch_16_pass_3_inv_1 — shares text with dataeast/decocass_m.cpp:439
rtl/dongle/dongle_type1.v:81 csuperas (DECO release 9) -latch_26_pass_3_inv_2 flip4-5 — shares text with dataeast/decocass_m.cpp:357
rtl/dongle/dongle_type1.v:89 clocknch (DECO release 11) -latch_26_pass_3_inv_2 flip2-3 — shares text with dataeast/decocass_m.cpp:357
rtl/dongle/dongle_type1.v:97 cprogolf (DECO release 13) -latch_26_pass_3_inv_2 flip0-1 — shares text with dataeast/decocass_m.cpp:357
rtl/dongle/dongle_type1.v:101 cdsteljn (DECO release 14) -latch_27_pass_3_inv_2 — shares text with dataeast/decocass_m.cpp:413
rtl/dongle/dongle_type1.v:105 cluckypo (DECO release 15) -latch_26_pass_3_inv_2 flip1-3 — shares text with dataeast/decocass_m.cpp:357
rtl/dongle/dongle_type1.v:109 ctisland (DECO release 16) -latch_26_pass_3_inv_2 flip0-2 — shares text with dataeast/decocass_m.cpp:357
rtl/dongle/dongle_type1.v:118 cexplore (DECO release 18) -latch_26_pass_5_inv_2 — shares text with dataeast/decocass_m.cpp:426
rtl/dongle/dongle_type3.v:127 (decocass_m.cpp line 630: `data = m_donglerom[m_type3_ctrs];`) — shares text with dataeast/decocass_m.cpp:630
rtl/dongle/dongle_widel.v:1 ============================================================================ Widel Dongle — 20-bit Counter + 1 MB ROM (David Widel multigame kit) Implement — shares text with dataeast/decocass_m.cpp
rtl/io/quadrature_adc.v:44 void decocass_quadrature_decoder_reset_w(uint8_t data) { — shares text with dataeast/decocass.h:182
rtl/io/quadrature_adc.v:45 for (int i = 0; i < 4; i++) — shares text with dataeast/decocass_m.cpp:164
rtl/io/quadrature_adc.v:46 m_quadrature_decoder[i] = m_analog[i]->read(); // 0x10..0xf0 — shares text with dataeast/decocass_m.cpp:165
rtl/mcu/mcu_tape_iface.v:167 data = (m_i8041_p2 & ~0xe0) | m_cassette->get_status_bits(); — shares text with dataeast/decocass_m.cpp:1816
rtl/video/video_bg.v:243 color = (m_color_center_bot >> 7) & 1 (1 bit) — shares text with dataeast/decocass_v.cpp:201
rtl/video/video_fg.v:187 BIT(m_color_center_bot, 0), // color = 0 or 1 — shares text with dataeast/decocass_v.cpp:227
rtl/video/video_palette.v:20 - Pens 32-63: set_pen_indirect(32+i, bitswap(i, 7,6,5,4,3,1,2,0)) — shares text with dataeast/decocass.cpp:1010
rtl/video/video_palette.v:65 (decocass_palette: set_pen_indirect(32+i, bitswap<8>(i,7,6,5,4,3,1,2,0)) = swap pen bits 1↔2). — shares text with dataeast/decocass.cpp:1010
rtl/video/video_palette.v:85 m_palette->set_indirect_color(offset, — shares text with dataeast/decocass_v.cpp:332
rtl/video/video_timing.v:3 Derived from MAME's set_raw(HCLK, 384, 0*8, 256, 272, 1*8, 248) — shares text with dataeast/decocass.cpp:1039

Defender#
Colony 7, Defender, Jin, Mayday
MiSTer-devel/Arcade-Defender_MiSTer @ 041e62c7
MAME compared: williams/williams.cpp + 5 related file(s)
Read: 11 HDL files, 12,720 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 2 toward MAME

Cites MAME source — 1

rtl/defender.vhd:30 Use with MAME roms from defender.zip

Shares text with the MAME driver without saying so — 1

rtl/defender.vhd:323 pixels |0|1|2|3|4|5|0|1|2|3|4|5| — shares text with williams/williamsblitter.cpp:50

DenjinMakai#
Denjin Makai
MiSTer-devel/Arcade-DenjinMakai_MiSTer @ eb980034
MAME compared: seibu/legionna.cpp + 8 related file(s)
Read: 24 HDL files, 10,836 lines (Quartus project)

MiSTer official

Mostly MAME

medium

71%

Statements: 5 toward hardware, 212 toward MAME, 1 not counted

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:23 Main CPU memory map Denjin Makai (MAME legionna.cpp denjinmk_map:296-322): $000000-$0FFFFF ROM 68K (1MB) → SDRAM via bridge $100000-$1003FF RAM scratch (1KB) → BRAM (Main RAM low) $100400-$1006FF COP3 region — also in MAME: 68K seibu/legionna.cpp:46

Reports a measurement taken on the original PCB — 1

rtl/DenjinMakai/DenjinMakai_video_timing.sv:26 PCB measurement Blood Bros: VSync 59.4094 Hz, HSync 15.6246 kHz, master XTAL 20 MHz.

Says it was checked on “real hardware” — 4

rtl/DenjinMakai/DenjinMakai_cop3.sv:336 0 : 1 (unsigned <320 provato su HW = REGRESSIONE; il signed [-160,320) dell'intento MAME e' il comportamento giusto sul core)
rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:216 byte_lo = pf_rom_data[31:24]/[15:8], byte_hi = [23:16]/[7:0] Plane order DCBA (verificato su HW, come BG/MG/FG): pen[0] dal bit "D" (byte_hi[3-sub]), pen[3] dal bit "A" (byte_lo[7-sub]).
rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:333 Scan INVERSO 511→0 (verificato su HW: ordine sprite-su-sprite opposto al loop MAME 0→511).
rtl/DenjinMakai/DenjinMakai_tile_layer.sv:322 Plane order verificato su HW: BG/MG = DCBA (PEN_ORDER=0), FG = BADC (PEN_ORDER=1).

Cites MAME source — 188

DenjinMakai.sv:186 Offset per-layer DenjinMakai: MAME visarea parte da (0,0) (set_raw vbend=0, legionna.cpp:1318) e denjinmk NON definisce scrolldx/dy per BG/MG/FG ne' sprite offset (nessun set_offset, legionna.cpp:1331) → tutti 0.
DenjinMakai.sv:191 NB: denjinmk ha anche tile_scroll_base_w (legionna_v.cpp:58-65): reg base 7 → text set_scrolldy(0x1ef - data).
DenjinMakai.sv:304 --- Joystick to SD Gundam input mapping --- MAME P1_P2 port ($E0002): active low.
DenjinMakai.sv:307 MiSTer joy bits: joy[0]=R, joy[1]=L, joy[2]=D, joy[3]=U, joy[4]=A, joy[5]=B. MAME PLAYERS12 (legionna.cpp:439-444): bit[0]=UP, [1]=DOWN, [2]=LEFT, [3]=RIGHT, [4]=BTN1, [5]=BTN2, [6]=BTN3, [7]=unused (active low).
DenjinMakai.sv:317 DenjinMakai SYSTEM port ($10074C) — MAME legionna.cpp:427-436 bit0 = START1 (active LOW) bit1 = START2 (active LOW) bit2..7 = UNKNOWN → tied 1 bit8..15 = UNKNOWN → tied 1 Coin inputs NON sono qui: vanno via SEIBU_COIN_INPUTS → Z80 → soundla
DenjinMakai.sv:678 ── Flip screen (CRTC reg 0x1A bit 0) ─────────────────────────────────────── MAME: BIT(reg_1a, 0) → flip_screen.
DenjinMakai.sv:724 ── Text layer renderer (8x8, 4bpp, 64x32 grid) ───────────────────────────── DenjinMakai MAME (ROM_START denjinmk): "char" = REGIONE PROPRIA 128KB (11.620/10.615, ROM_LOAD16_BYTE), NON dentro user1 come Legionnaire.
DenjinMakai.sv:737 DenjinMakai text scroll-base (CRTC reg 0x3A, hook denjinmk-only legionna.cpp:1326).
DenjinMakai.sv:738 Calibrazione HW di famiglia (dump vregs in seibu_crtc.cpp): Legionnaire reg=0x01FF, visarea da riga 16 → 0x1FF-0x1EF=+16 = ESATTAMENTE il vecchio yoff text +16 del core Legionnaire funzionante; D-Con reg=0xFFEF (low9=0x1EF), visarea da 0 →
DenjinMakai.sv:742 La formula MAME set_scrolldy(0x1EF-data) è INVERTITA rispetto all'HW (convenzione dy del tilemap.cpp) — mai fidarsi del verso MAME.
DenjinMakai.sv:745 DENJIN MAKAI: la scrolldy dinamica del text dal CRTC reg $3A NON si applica — in MAME layer_scroll_base_callback e' collegata SOLO a godzilla (legionna.cpp:1326, commento in tile_scroll_base_w: "specific for Godzilla").
DenjinMakai.sv:784 DenjinMakai CRTC scroll passthrough (MAME legionna_v.cpp:34-49 tile_scroll_w): scroll_ram[0/1] → BG (m_background_layer) scroll_ram[2/3] → MG (m_midground_layer) scroll_ram[4/5] → FG (m_foreground_layer) Nel nostro CRTC: xscroll_l0 = ram[0/
DenjinMakai.sv:802 DenjinMakai BG: tilemap 32x32 (legionna_v.cpp:204).
DenjinMakai.sv:803 MAME GFXDECODE "back" color base = 0 (gfx_legionna riga 1168), 32 colorset.
DenjinMakai.sv:804 HAS_TRANSP=1 perché m_background_layer->set_transparent_pen(15) in legionna_v.cpp:216 (pen 15 = trasparente, NON opaco come Blood Bros).
DenjinMakai.sv:826 DenjinMakai MG: 16x16, 4bpp, 32x32 tilemap (MAME legionna_v.cpp:204).
DenjinMakai.sv:827 get_mid_tile_info_share_bgrom (legionna_v.cpp:158): MG share BG ROM, tile = (vram & 0xfff) | 0x1000 (= seconda metà della BG ROM) color = ((vram >> 12) & 0xf) | 0x10 (= palette set superiore: bit 4 = 1) In palette MAME "back" base = 0,
DenjinMakai.sv:854 DenjinMakai FG: tilemap 32x32 (legionna_v.cpp:213).
DenjinMakai.sv:856 MAME GFXDECODE "fore" color base = 32*16 = 0x200, 16 colorset.
DenjinMakai.sv:866 DENJINMAKAI: fore = bg2.619 ROM_LOAD16_WORD_SWAP (legionna.cpp:1987) = IDENTICO alla back bg1.618 → stesso decode DCBA di BG/MG (riscontro HW utente: col BADC il FG era sbagliato).
DenjinMakai.sv:874 DenjinMakai: bit 2 = FG (MAME legionna_v.cpp:344)
DenjinMakai.sv:962 Anticipando di 1 l'indirizzo e il DE, il dato campionato al tick e' quello del pixel CORRENTE: allineamento coi tile ripristinato (= calibrazione +1 pixel-hunting MAME, fatta prima del fix CRT) e colonna 0 coperta.
DenjinMakai.sv:996 MAME riferimenti (DENJINMAKAI — diverso da legionna!): legionna_v.cpp:247-251 m_sprite_pri_mask[0..3] per denjinmk: pri=0 → 0xFFF0 (copre pri-value 0,1,2 → bg,mg,fg → SOTTO text) pri=1 → 0xFFFC (copre 0,1 → bg,mg → sotto fg,text) pri=2 →
DenjinMakai.sv:1016 MAME denjinmk legionna_v.cpp:382 bitmap.fill(0xff) "matches PCB recording"
DenjinMakai.sv:1020 DENJIN MAKAI: pri 3 → mask 0x0000 = copre TUTTO, text incluso (MAME VIDEO_START denjinmk: "briefing guy in pre-stage and portraits before a boss fight").
DenjinMakai.sv:1041 Backdrop = palette[0x0FF] reale (MAME denjinmk: bitmap.fill(0xff), match PCB).
rtl/DenjinMakai/DenjinMakai_audio_z80.sv:25 Spec da MAME (legionna.cpp denjinmk machine config :1295-1355): - Z80 @ 14.318180/4 = 3.579545 MHz (seibu_sound_map + denjinmk_sound_io_map) - YM2151/OPM (jt51) @ 3.579545 MHz, route ch0+ch1 0.50 su mono - OKI M6295 (jt6295) @ 20MHz/20 = 1.
rtl/DenjinMakai/DenjinMakai_audio_z80.sv:364 MAME seibu_sound_device::main_r (seibusound.cpp:279): case 2,3: return sub2main[offset-2] (soundlatch data: coin/input dal Z80) case 5: return main2sub_pending ?
rtl/DenjinMakai/DenjinMakai_audio_z80.sv:379 ─── YM2151 (jt51) — DENJINMAKAI usa OPM, non OPL2 (legionna.cpp:1340) ────── Il driver Z80 programma i timer OPM (reg 0x10-0x14): su jtopl2 non scattava mai l'IRQ → RST10 morto → sequencer musica fermo.
rtl/DenjinMakai/DenjinMakai_audio_z80.sv:458 MAME: route 0.50+0.50 su mono (legionna.cpp:1342-1343)
rtl/DenjinMakai/DenjinMakai_audio_z80.sv:461 ─── OKI bank — DENJINMAKAI: Z80 "OUT (0),A" → banco ROM OKI (512KB = 2×256KB) MAME denjinmk_sound_io_map (legionna.cpp:282-286) port 0 → denjinmk_oki_bank_w: m_oki->set_rom_bank(data & 1) (write tipica 0x02/0x03).
rtl/DenjinMakai/DenjinMakai_audio_z80.sv:470 ─── OKI M6295 (jt6295) — PIN7_HIGH (20MHz/20 = 1.0 MHz, legionna.cpp:1345)
rtl/DenjinMakai/DenjinMakai_cop3.sv:4 MAME-faithful implementation of the Seibu SEI300 chip as used by the `legionna` driver (DenjinMakai 1992 — Banpresto/TAD).
rtl/DenjinMakai/DenjinMakai_cop3.sv:7 Reference (in this repo): MAME seibucop.cpp MAME seibucop_cmd.ipp MAME seibucop_dma.ipp MAME legionna.cpp
rtl/DenjinMakai/DenjinMakai_cop3.sv:136 MAME cop_itoa_digits[10]: BCD digits of cop_itoa (low<<0 | high<<16).
rtl/DenjinMakai/DenjinMakai_cop3.sv:140 Il vecchio loop a sottrazioni ripetute era O(valore) (~valore/9 clk): con i long 32-bit di denjinmk (score, writer $156E/$1F93E) il 68k restava congelato (dma_busy include bcd_pending) fino a MILLISECONDI per chiamata — su MAME/HW reale i d
rtl/DenjinMakai/DenjinMakai_cop3.sv:153 MAME cop_program command table (seibucop.cpp lines 318-457) At boot, game code uploads 32 macro slots × 8 micro-op words via pgm_addr (0x100434) → slot*8 + sub-index pgm_data (0x100432) → micro-op word pgm_value (0x100438) → cop_func_valu
rtl/DenjinMakai/DenjinMakai_cop3.sv:160 MAME calls find_trigger_match(triggerval, 0xff00) to find the slot whose cop_func_trigger matches.
rtl/DenjinMakai/DenjinMakai_cop3.sv:256 Triggers (write-only addresses) MAME legionna.cpp:172 maps cop_cmd_w to $100500-$100505 (3 words).
rtl/DenjinMakai/DenjinMakai_cop3.sv:330 0x100410 sprite_dma_inc (MAME cop_sprite_dma_inc_w): if x_clip in [-160, 320): cop_regs[4] += 8.
rtl/DenjinMakai/DenjinMakai_cop3.sv:331 MA in MAME sprite_x e' uint16_t assegnato a int -> MAI negativo -> il -160 e' codice morto: check EFFETTIVO = unsigned < 320 (X "negative" 0xFFxx NON avanzano il puntatore entry).
rtl/DenjinMakai/DenjinMakai_cop3.sv:336 0 : 1 (unsigned <320 provato su HW = REGRESSIONE; il signed [-160,320) dell'intento MAME e' il comportamento giusto sul core)
rtl/DenjinMakai/DenjinMakai_cop3.sv:343 A size==0 NON wrappare (il size-- uint di MAME wrapperebbe a $FFFF: il loop del builder su status[1] andrebbe in livelock — provato peggio).
rtl/DenjinMakai/DenjinMakai_cop3.sv:378 Macro program upload — MAME seibucop.cpp lines 318-457 pgm_data writes one micro-op word to cop_program[latch_addr] AND latches the slot's trigger/value/mask from current latch regs.
rtl/DenjinMakai/DenjinMakai_cop3.sv:479 itoa_digits (MAME 0x100590-99, 5 word).
rtl/DenjinMakai/DenjinMakai_cop3.sv:491 Status / dist / angle (MAME seibucop.cpp:916 cop_status_r → cop_status)
rtl/DenjinMakai/DenjinMakai_cop3.sv:502 MAME open bus
rtl/DenjinMakai/DenjinMakai_cop3.sv:569 commit write al dst ASSOLUTO (fill/mr), 1:1 MAME write_word(dst)
rtl/DenjinMakai/DenjinMakai_cop3.sv:605 LEGACY sprite-DMA (MAME seibucop_cmd.ipp): 6880 (carica rel_xy), c480 (single-step: compone l'entry sprite a cop_regs[4]+offs con X/Y = rel + (obj - abs)).
rtl/DenjinMakai/DenjinMakai_cop3.sv:629 write angolo (word {0,angle} come MAME host_endian)
rtl/DenjinMakai/DenjinMakai_cop3.sv:641 Trigger latches — MAME seibucop.cpp cop_cmd_w line 1069.
rtl/DenjinMakai/DenjinMakai_cop3.sv:642 MAME dispatches on raw data after clearing cop_status bit 15.
rtl/DenjinMakai/DenjinMakai_cop3.sv:696 DMA mode 0x80-0x87: MAME dma_palette_brightness() fa FADE solo con pal_brightness_mode 4/5; con qualsiasi altro valore fa una COPIA SEMPLICE src->dst (ramo else, seibucop_dma.ipp:119-123) verso QUALUNQUE dst — incl.
rtl/DenjinMakai/DenjinMakai_cop3.sv:704 DMA generici 0x09/0x0E: MAME write_word(dst) va nello spazio host = arriva a QUALSIASI RAM mappata, incluse le BRAM video ($101000-$105FFF: staging tilemap, palette-stage $104000, sprite $105000).
rtl/DenjinMakai/DenjinMakai_cop3.sv:712 Output del fade/blend 0x8x: MAME dma_palette_brightness fa write_word(dst) nello SPAZIO HOST = raggiunge QUALUNQUE RAM mappata (pal-stage $104000, sprite $105800, Main RAM...).
rtl/DenjinMakai/DenjinMakai_cop3.sv:715 Ora: pal_val registrato in D_FADE_WRITE e committato in D_FADE_COMMIT via canale fill (decode per dst assoluto in main_top: bg/fg/mg/txt/pal/spr) o mr (dst in Main RAM) — 1:1 MAME.
rtl/DenjinMakai/DenjinMakai_cop3.sv:718 (Il vecchio dma80_to_spr era INVERTITO: il blit pietre e' src=$105800 dst=$104000, non il contrario — MAME map: $100478=SRC, $10047C=DST.)
rtl/DenjinMakai/DenjinMakai_cop3.sv:721 LEGACY sprite-DMA state (MAME m_sprite_dma_rel_x/y, m_sprite_dma_x_clip)
rtl/DenjinMakai/DenjinMakai_cop3.sv:824 MAME cop_cmd_w (seibucop.cpp:1075):
rtl/DenjinMakai/DenjinMakai_cop3.sv:860 Restituisce canonical trigger value del slot (NB: MAME LEGACY_cop_cmd_w usa il match slot per dispatchare; in pratica equivale a restituire cop_func_trigger[slot]).
rtl/DenjinMakai/DenjinMakai_cop3.sv:881 fade_table — MAME seibucop.cpp:733 (reverse engineered from Seibu Cup Soccer bootleg) v = pal_channel(5-bit) | (brightness_val_xor_X) [10-bit input] low = v & 0x1F high = v & 0x3E0 return (low * (high | (high>>5)) + 0x210) >> 10 [8-bit o
rtl/DenjinMakai/DenjinMakai_cop3.sv:920 ── Hitbox b100/b900 scratch (MAME cop_collision_update_hitbox) ────────────── dx[i] = int8 (signed) byte basso, size[i] = uint8 (unsigned) byte alto del word descrittore @ hitadr2+2*i. 3 assi (Y,X,Z) per DenjinMakai.
rtl/DenjinMakai/DenjinMakai_cop3.sv:927 num_axis: MAME seibucop.cpp:1010 "if (data & 0x100) num_axis = 3" else 2.
rtl/DenjinMakai/DenjinMakai_cop3.sv:929 res init 7 vs 3 (seibucop.cpp:1038-39).
rtl/DenjinMakai/DenjinMakai_cop3.sv:956 Con 16-bit frac + 24 iter + z>>16: 0 divergenze di decisione vs MAME int(atan(dx/dy)*128/pi) su ~640k casi (dimostrato numericamente).
rtl/DenjinMakai/DenjinMakai_cop3.sv:1199 MAME cop_dma_trigger_w: NON modifica cop_status (vedi seibucop.cpp:741).
rtl/DenjinMakai/DenjinMakai_cop3.sv:1207 MAME dma_tilemap_buffer: copy staging RAM → renderer BRAM src = cop_dma_src[mode] << 6 (byte addr 0x101000+ = staging) dst = i (loop counter 0..0x13FF = renderer index) count = 0x2800/2 = 5120 words
rtl/DenjinMakai/DenjinMakai_cop3.sv:1217 MAME dma_palette_buffer: copy staging palette → renderer src = cop_dma_src[mode] << 6 (0x104000 = palette staging) dst = i (loop counter 0..0x7FF = renderer index) count = 0x1000/2 = 2048 words
rtl/DenjinMakai/DenjinMakai_cop3.sv:1227 MAME write_word(dst) su spazio host: con dst nelle BRAM video ($101000-$105FFF: staging/pal/spr, es.
rtl/DenjinMakai/DenjinMakai_cop3.sv:1240 simplified, MAME size>>1
rtl/DenjinMakai/DenjinMakai_cop3.sv:1245 MAME seibucop_dma.ipp dma_palette_brightness() mode 5/4.
rtl/DenjinMakai/DenjinMakai_cop3.sv:1248 MAME formulas: src = cop_dma_src[mode] << 6 dst = cop_dma_dst[mode] << 6 size = ((cop_dma_size << 5) - (cop_dma_dst << 6) + $20)/2 Init: src=$106000, dst=$104000, size=($827F<<5 - $4100<<6 + $20)/2 = ($104FE0 - $104000 + $20)/2 = $1000
rtl/DenjinMakai/DenjinMakai_cop3.sv:1259 MAME size = (((size<<5) - (dst<<6) + 0x20)/2)
rtl/DenjinMakai/DenjinMakai_cop3.sv:1265 MAME: mode 4/5 = fade palette; QUALSIASI ALTRO = copia semplice src->dst (seibucop_dma.ipp:119-123).
rtl/DenjinMakai/DenjinMakai_cop3.sv:1275 MAME seibucop.cpp cop_dma_trigger_w case 0x116 — DENJINMAKAI: fill come 0x118 ma SENZA guard dst!=0 e length bytes = (size+1)<<4 (metà).
rtl/DenjinMakai/DenjinMakai_cop3.sv:1277 legionna.cpp:56-61: "The COP-MCU appears to write to the work ram area, otherwise it RESETS in mid-animation of the title screen" → senza questo fill il gioco torna al logo da solo.
rtl/DenjinMakai/DenjinMakai_cop3.sv:1288 Skip if dst != 0 (MAME guard, dma.ipp:135)
rtl/DenjinMakai/DenjinMakai_cop3.sv:1301 MAME cop_cmd_w (seibucop.cpp:1073): cop_status &= 0x7fff (clear bit 15).
rtl/DenjinMakai/DenjinMakai_cop3.sv:1303 MAME: cop_status &= 0x7fff (clear bit 15).
rtl/DenjinMakai/DenjinMakai_cop3.sv:1318 MAME LEGACY_cop_cmd_w: find_trigger_match(data, 0xF800) → slot per GRUPPO f800, poi handler dal microcodice caricato.
rtl/DenjinMakai/DenjinMakai_cop3.sv:1344 MAME execute_0205: read dword at cop_regs[0]+4+offset*4 (ppos)
rtl/DenjinMakai/DenjinMakai_cop3.sv:1365 0x138e / 0x338e — atan(dx/dy) MAME execute_338e.
rtl/DenjinMakai/DenjinMakai_cop3.sv:1367 Parte da r1+4 hi (offset 0x0004), come 3BB0/MAME.
rtl/DenjinMakai/DenjinMakai_cop3.sv:1375 r1+4 hi (MAME read_dword(r1+4) primo)
rtl/DenjinMakai/DenjinMakai_cop3.sv:1390 MAME: raw_angle = cop_read_word(r0+0x34) = host_read_word(0x34^2 = 0x36); amp = cop_read_word(r0+0x36) = host_read_word(0x36^2 = 0x34).
rtl/DenjinMakai/DenjinMakai_cop3.sv:1407 0xa180 — collision read pos for slot 0 MAME cop_collision_read_pos: cop_read_word(spradr+N) = host_read_word((spradr+N)^2) per host_endian=true.
rtl/DenjinMakai/DenjinMakai_cop3.sv:1428 b000 NON e' un no-op: il dispatcher LEGACY di denjinmk (seibucop.cpp:1365) matcha con mask 0xf800, quindi la patch init_denjinmk (b100->b000) ESEGUE comunque l'update ma con num_axis=2 (bit8=0 = Z disattivata).
rtl/DenjinMakai/DenjinMakai_cop3.sv:1536 Mode 4 (DENJINMAKAI/Denjin, seibucop_dma.ipp:87-117): indice = (val*2)[4:0], val 0x0010/0xFFFF = TARGET PURO, NESSUN bypass bit15.
rtl/DenjinMakai/DenjinMakai_cop3.sv:1583 MAME: m_host_space->write_word(dst, pal_val) — dst ASSOLUTO.
rtl/DenjinMakai/DenjinMakai_cop3.sv:1617 MAME (0x118 e 0x116): write_dword(i, v1 | v2<<16) su spazio BE 68k → word a i = v2, word a i+2 = v1 (alternati).
rtl/DenjinMakai/DenjinMakai_cop3.sv:1630 Macro 0x0205 — linear movement (MAME execute_0205) ppos = read_dword(cop_regs[0]+0x04) vel = read_dword(cop_regs[0]+0x10) npos = ppos + vel write_dword(cop_regs[0]+0x04, npos) delta = (npos>>16) - (ppos>>16) write_word(cop_regs[0]+0x1E, re
rtl/DenjinMakai/DenjinMakai_cop3.sv:1673 MAME cop_read/write_word(cop_regs[0]+0x1e) = host word @ (0x1e^2)=0x1c (host endianness word^2; conferma doc 06 micro-op 'addmem16 0x1C(r0)').
rtl/DenjinMakai/DenjinMakai_cop3.sv:1691 Macro 0x0905/0x0904 — jump (MAME execute_0904) write_dword(cop_regs[0]+0x10, read_dword(cop_regs[0]+0x10) ± read_dword(cop_regs[0]+0x28)) 0x0905 (bit 0=1) = +, 0x0904 (bit 0=0) = -
rtl/DenjinMakai/DenjinMakai_cop3.sv:1717 MAME execute_0904: bit 0 di data = 1 → add, =0 → sub tmp32_a = vel ± grav.
rtl/DenjinMakai/DenjinMakai_cop3.sv:1748 0x138E/0x338E atan(dx/dy) — MAME execute_338e (cmd.ipp:159) dx = read_dword(r1+4) - read_dword(r0+4) dy = read_dword(r1+8) - read_dword(r0+8) if(!dy){status|=0x8000; angle=0} else angle=atan(dx/dy)*128/pi; dy<0→+0x80 if(data&0x80) write_byt
rtl/DenjinMakai/DenjinMakai_cop3.sv:1796 MAME: angle = atan(dx/dy)*128/pi (+0x80 se dy<0).
rtl/DenjinMakai/DenjinMakai_cop3.sv:1798 Cosi' z = atan(dx/dy) e il +0x80 (in WR) copre solo il quadrante, come MAME.
rtl/DenjinMakai/DenjinMakai_cop3.sv:1800 NIENTE prescale: i dword diff sono FIXED-POINT coord<<16 (come il 3BB0 che usa dx32[31:16] e MAME dx>>16), NON interi piccoli.
rtl/DenjinMakai/DenjinMakai_cop3.sv:1841 MAME (int)(...) tronca VERSO ZERO.
rtl/DenjinMakai/DenjinMakai_cop3.sv:1843 BUG TROVATO (validato vs MAME su 29241 casi): il CORDIC SOTTO-CONVERGE di 1 LSB sulle DIAGONALI (es.
rtl/DenjinMakai/DenjinMakai_cop3.sv:1848 Compenso l'epsilon di sotto-convergenza con +1 toward-zero PRIMA del troncamento: bias=1 azzera tutte le 133 divergenze (bias=0) -> 0/29241 vs MAME.
rtl/DenjinMakai/DenjinMakai_cop3.sv:1857 MAME execute_338e (seibucop_cmd.ipp:175-188): la write dell'angolo in RAM (obj+0x34 host, gated da data&0x80) e' FUORI dall'if/else di dy -> avviene SEMPRE, anche a dy==0 (dove cop_angle=0 -> scrive 0^0x80 = 0x80).
rtl/DenjinMakai/DenjinMakai_cop3.sv:1863 Ora calcolo ang_byte in entrambi i rami e scrivo SEMPRE, come MAME.
rtl/DenjinMakai/DenjinMakai_cop3.sv:1870 Scrivere l'angolo anche a dy==0 ("1:1 MAME") REGREDISCE: il martello scivola/moonwalk.
rtl/DenjinMakai/DenjinMakai_cop3.sv:1873 MAME: dy==0 -> cop_angle=0
rtl/DenjinMakai/DenjinMakai_cop3.sv:1896 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197) dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (aritmetico) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = sqrt(dx*dx + dy*dy) if(data&0x80) write_word(r0 + (data&0x200?0x3a:0x38
rtl/DenjinMakai/DenjinMakai_cop3.sv:2005 (Il fix MAME-aligned 0x3a:0x38 faceva fuggire i nemici -> MAME invertito vs HW.
rtl/DenjinMakai/DenjinMakai_cop3.sv:2012 MAME: macro completata → cop_status = 7 (gate-poll del gioco).
rtl/DenjinMakai/DenjinMakai_cop3.sv:2098 0x8100/0x8900 sin/cos (MAME execute_8100/8900) raw_angle = cop_read_word(cop_regs[0]+0x34) & 0xff amp = (65536>>5) * (cop_read_word(cop_regs[0]+0x36) & 0xff) = 2048 * amp_byte if (raw_angle == 0xC0 sin / 0x80 cos): amp *= 2 res = int(
rtl/DenjinMakai/DenjinMakai_cop3.sv:2137 MAME special-case: sin && raw==0xC0 OR cos && raw==0x80 → amp *= 2
rtl/DenjinMakai/DenjinMakai_cop3.sv:2183 0xa180/0xa980 — read pos (MAME cop_collision_read_pos) flags_swap = cop_read_word(spradr+2) → host_read_word(spradr+0) pos[0] = cop_read_word(spradr+6) → host_read_word(spradr+4) pos[1] = cop_read_word(spradr+10) → host_read_word(
rtl/DenjinMakai/DenjinMakai_cop3.sv:2190 Però MAME cop_read_word(+2) = host_read_word(+2^2) = host_read_word(+0).
rtl/DenjinMakai/DenjinMakai_cop3.sv:2201 rdata = word @ host+0 = flags (MAME cop_read_word(spradr+2) ^ 2).
rtl/DenjinMakai/DenjinMakai_cop3.sv:2210 rdata = word @ host+4 = pos[0] (Y axis per MAME)
rtl/DenjinMakai/DenjinMakai_cop3.sv:2230 0xb100/0xb900 — update hitbox & compute intersection (1:1 MAME cop_collision_update_hitbox, seibucop.cpp:1003-1065).
rtl/DenjinMakai/DenjinMakai_cop3.sv:2277 2 assi (b000/b800): terza word NON letta, dx/size azzerati (MAME seibucop.cpp:1014-1022)
rtl/DenjinMakai/DenjinMakai_cop3.sv:2316 2 assi: l'asse 2 (Z) NON viene aggiornato (loop MAME i<num_axis)
rtl/DenjinMakai/DenjinMakai_cop3.sv:2335 res init: 3 assi = 111, 2 assi = 011 (MAME seibucop.cpp:1038-39: bit Z gia' 0 = "collide banale" -> hit deciso solo da X/Y)
rtl/DenjinMakai/DenjinMakai_cop3.sv:2359 LEGACY 6880 — carica rel_xy per il prossimo c480 (MAME LEGACY_execute_6980: rel_xy = read_word(spr_src+4+offs))
rtl/DenjinMakai/DenjinMakai_cop3.sv:2372 LEGACY c480 — single-step sprite DMA (MAME LEGACY_execute_c480): info = read(spr_src+offs) + (param & 0x3f) -> entry+0 abs = read(regs[0]+8/+4) - spr_dma_abs_x/y X(fx/dx/rel_x) -> entry+4 (+ x_clip per l'inc $410) Y(fy/rel_y) -> entry+6
rtl/DenjinMakai/DenjinMakai_cop3.sv:2478 6200 — rotate-towards (MAME execute_6200, variante grainbow che denjinmk CARICA nella tabella): angle(obj host+0x37) ruota verso cop_angle_target di cop_angle_step; flags(host+2) bit2=raggiunto.
rtl/DenjinMakai/DenjinMakai_cop3.sv:2481 Dominio angolo: il nostro 138e scrive in RAM plain^0x80 (is_yflip) -> lavoro nel dominio stored con target^0x80: il DELTA e' rotazione-invariante => matematica IDENTICA a MAME.
rtl/DenjinMakai/DenjinMakai_cop3.sv:2484 Write angolo = WORD {0,angle} (MAME host_endian write-word).
rtl/DenjinMakai/DenjinMakai_cop3.sv:2505 wrap a signed 8-bit (MAME: +=/-=256 su int)
rtl/DenjinMakai/DenjinMakai_main_top.sv:216 VBLANK IRQ4 — MAME legionna.cpp: m_maincpu->set_vblank_int(irq4_line_hold) MAME HOLD_LINE: IRQ asserted on edge, released ONLY at IACK (= when CPU fetches vector).
rtl/DenjinMakai/DenjinMakai_main_top.sv:221 VBLANK IRQ4 — MAME legionna.cpp: m_maincpu->set_vblank_int(irq4_line_hold) MAME HOLD_LINE: IRQ asserted on edge, released ONLY at IACK (= when CPU fetches vector).
rtl/DenjinMakai/DenjinMakai_main_top.sv:479 COP3 cmd 0x14 dma_tilemap_buffer (MAME legionna_v.cpp:86 videowrite_cb_w): offset 0x000..0x3FF → BG (back_data) offset 0x400..0x7FF → FG (fore_data) offset 0x800..0xBFF → MG (mid_data) offset 0xC00..0x13FF → Text (textram, 0x800 word)
rtl/DenjinMakai/DenjinMakai_main_top.sv:503 Il fill scrive le BRAM STAGING (= la host RAM di MAME): il per-frame DMA 0x14/0x15 le propaga al renderer.
rtl/DenjinMakai/DenjinMakai_main_top.sv:516 ── SPLIT STAGING vs RENDERER (semantica MAME 2-stadi, come la palette) ───── MAME denjinmk: $101000-$103FFF e' .ram() PURO (handler background_w/… COMMENTATI nel map, legionna.cpp) — le scritture CPU NON toccano i tilemap.
rtl/DenjinMakai/DenjinMakai_main_top.sv:519 I tilemap leggono m_back/fore/mid_data/m_textram = buffer SEPARATI (make_unique_clear, legionna_v.cpp) scritti SOLO da videowrite_cb_w = DMA 0x14.
rtl/DenjinMakai/DenjinMakai_main_top.sv:524 u_XX_ram = STAGING: porta A = CPU (+fill 0x116/0x118, come MAME che filla la host RAM), porta B = sorgente del DMA 0x14.
rtl/DenjinMakai/DenjinMakai_main_top.sv:527 Coppia contenuto/scroll = atomica a livello ISR, come MAME.
rtl/DenjinMakai/DenjinMakai_main_top.sv:599 ── Palette: split STAGING ($104000) vs RENDERER (semantica MAME 2-stadi) ─── MAME: la CPU e il fade (cmd 0x80) scrivono la STAGING RAM a $104000.
rtl/DenjinMakai/DenjinMakai_main_top.sv:609 In MAME il fade DMA (mode 0x8x) fa m_host_space->write_word(dst): con dst in $104000-$104FFF quella write ATTRAVERSA la map, quindi passa per palette_swap_w (offset^=1) esattamente come le write della CPU.
rtl/DenjinMakai/DenjinMakai_main_top.sv:615 Le LETTURE (porta B, sorgente del cmd 0x15) restano LINEARI come in MAME.
rtl/DenjinMakai/DenjinMakai_main_top.sv:631 MAME denjinmk: $104000 e' RAM pura (legionna.cpp:262, handler palette commentato) — la palette VISIBILE si aggiorna SOLO via paletteramout_cb = dma_palette_buffer 0x15 (seibucop_dma.ipp:27); il fade DMA scrive lo STAGING (host RAM, dma.ipp:
rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:23 Main CPU memory map Denjin Makai (MAME legionna.cpp denjinmk_map:296-322): $000000-$0FFFFF ROM 68K (1MB) → SDRAM via bridge $100000-$1003FF RAM scratch (1KB) → BRAM (Main RAM low) $100400-$1006FF COP3 region
rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:139 Text VRAM: $102800-$1037FF = 4KB = 2048 word (MAME common_video_allocate_ptr alloca textram a 0x1000/2 word, videowrite_cb_w smista offset < 0x2800/2).
rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:149 denjinmk_map (legionna.cpp:311): 0x100800-0x100FFF .ram()
rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:183 MAME palette_swap_w (legionna.cpp:288-294): "Looks like they specifically swapped address line A1 in this range" — offset^=1 poi COMBINE_DATA.
rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:229 MAME legionna_map: main_r/main_w(offset>>1) con umask16(0x00ff).
rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:233 Vedi seibusound.cpp main_r/main_w.
rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:237 ─── GFX bank — denjinmk_setgfxbank (MAME legionna_v.cpp:...) ──────────── "this is either 0x0000 or 0xe000, except in two endings (MT #07416)" back = (data & 0x2000) >> 1 → bit13 → +0x1000 mid = (data & 0x4000) >> 2 → bit14 → +0x1000 for
rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:282 denjinmk: MAME empty_init, nessuna patch ROM.
rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:309 MAME denjinmk_sound_comms_r (legionna.cpp:99-106): "Routine at 5FDC spins indefinitely until the lowest bit becomes 1" → l'offset 10 (= word index 10 = $100714) ritorna SEMPRE 1, non passa dal seibu_sound.
rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:344 Replica la latenza-zero-osservabile di MAME (cop_cmd_w sincrono): il gioco legge cop_hit_val_stat/cop_angle ($188/$1b4) nell'istruzione dopo il trigger.
rtl/DenjinMakai/DenjinMakai_palette.sv:25 MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 128*16); (legionna.cpp:1212, 128*16 = 2048 entry) Address space CPU: 0x104000..0x104FFF (4 KB = 2048 word).
rtl/DenjinMakai/DenjinMakai_palette.sv:35 Espansione 5→8 standard MAME palette_device: {val5, val5[4:2]} (bit replication che riempie i 3 LSB con i 3 MSB del valore 5-bit).
rtl/DenjinMakai/DenjinMakai_palette.sv:85 DenjinMakai: xBGR_555 → RGB888 (MAME legionna.cpp:1212) Layout: bit[4:0]=R, bit[9:5]=G, bit[14:10]=B. 5 bit per canale.
rtl/DenjinMakai/DenjinMakai_palette.sv:87 Espansione 5→8 standard MAME palette_device: {val5, val5[4:2]} (replica i 3 MSB nei 3 LSB → range 0..255 con monotonia preservata).
rtl/DenjinMakai/DenjinMakai_seibu_crtc.sv:23 Seibu CRTC fedele a MAME (seibu_crtc.cpp).
rtl/DenjinMakai/DenjinMakai_seibu_crtc.sv:120 MAME mappa: bit0=screen0(BG), bit1=screen2(MG), bit2=screen1(FG), bit3=screen3(Text) (vedi seibu_crtc.cpp commento "screen 0=BG, screen 1=FG, screen 2=MG, screen 3=Text") In SD Gundam dcon.cpp layer_en_w gira la maschera così: ~layer_en bit
rtl/DenjinMakai/DenjinMakai_seibu_crtc.sv:129 Il dispatcher MAME usa "if (BIT(~m_layer_en, n))" per saltare = layer disabilitato quando il bit è 1.
rtl/DenjinMakai/DenjinMakai_seibu_crtc.sv:134 DenjinMakai layer ordering (MAME legionna_v.cpp:384-390 screen_update_DENJINMAKAI): bit 0 = BG (background) bit 1 = MG (midground) bit 2 = FG (foreground) bit 3 = Text bit 4 = Sprites ATTENZIONE: e' l'OPPOSTO di legionna (screen_update_legi
rtl/DenjinMakai/DenjinMakai_seibu_crtc.sv:155 Scroll-base Screen3(text) Y = reg 0x3A (blocco layer_scroll_base 0x2C-0x3B, offset word 7 — MAME seibu_crtc.cpp:243 + legionna_v.cpp:58-65 denjinmk-only: text set_scrolldy(0x1ef - data).
rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:25 Formato spriteram quasi identico (entrambi MAME sei021x_sei0220_spr.cpp) — differenze: - Spriteram @ 0x105000-0x105FFF (4KB, 1024 word, 256 entry × 4 word) - w3 bit 15 = tile bank extra bit (denjinmk usa, DenjinMakai base = 0)
rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:30 Format word (MAME legionna_v.cpp:288-312): w0 bit 15 = enable (0=draw, 1=skip — TODO verify DenjinMakai) w0 bit 14 = flip_x w0 bit 13 = flip_y (???
rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:46 Priority callback legionna_v.cpp:314-317: pri_mask[0] = 0x0000 (sopra tutto) pri_mask[1] = 0xFFF0 pri_mask[2] = 0xFFFC pri_mask[3] = 0xFFFE
rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:140 0..511 (MAME size/2/4 = 4096/2/4 = 512)
rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:145 Decoded fields — MAME sei0210_device::draw (non-alt format, riga 143): if (BIT(~spriteram[i], 15)) continue; → draw quando w0[15]==1.
rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:157 SEI0211 get_coordinate (MAME sei021x_sei0220_spr.h): coord &= 0x1ff; return (coord >= 0x180) ?
rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:165 MAME SEI0211 default m_xoffset/m_yoffset = 0 (sei021x_sei0220_spr.cpp:40-41).
rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:166 DenjinMakai NON chiama set_offset (legionna.cpp:1214) → offset 0,0.
rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:198 Tile code finale Y-MAJOR (MAME draw_internal: ax=outer, ay=inner, code++): sub_index = ax*sizey + ay → cur_tile = code + eff_tile_x*sp_h + eff_tile_y Banking denjinmk_tile_cb (legionna_v.cpp:327-334): ext→|0x4000, y→|0x8000, applicato PRI
rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:538 MAME gfx_legionna_spr: color base = 64*16 = 0x400 (64 colorset × 16 pen).
rtl/DenjinMakai/DenjinMakai_text_renderer.sv:25 Specifiche da MAME (legionna.cpp:1117-1126, 1167):
rtl/DenjinMakai/DenjinMakai_text_renderer.sv:47 Char ROM in MAME: "char" region 64KB = ROM_COPY user1[0x10000..0x1FFFF].
rtl/DenjinMakai/DenjinMakai_text_renderer.sv:140 MAME `legionna_v.cpp:214`: text tilemap = 64×32 (8x8 tiles, TILEMAP_SCAN_ROWS).
rtl/DenjinMakai/DenjinMakai_text_renderer.sv:186 --- Stage 3: pen decode (charlayout planes packed in nibbles) --- Per col c (0..3 dentro la half-tile), bit position = 3 - c. pen[0] = word[bit_pos + 0] (plane 0) pen[1] = word[bit_pos + 4] (plane 1) pen[2] = word[bit_pos + 8] (plane
rtl/DenjinMakai/DenjinMakai_text_renderer.sv:192 MAME readbit usa MSB-first: bit_offs N → byte[N/8] bit (7-N%8).
rtl/DenjinMakai/DenjinMakai_text_renderer.sv:193 In Verilog word concat (lo=byte0[7:0], hi=byte1[7:0]) → MAME pos N = word[(7-N%8) + (N>=8?8:0)].
rtl/DenjinMakai/DenjinMakai_text_renderer.sv:210 MAME GFXDECODE char: color base = 48*16 = 0x300 (16 colorset × 16 pen).
rtl/DenjinMakai/DenjinMakai_text_renderer.sv:211 DENJIN MAKAI: trasparente pen 7 (MAME VIDEO_START_MEMBER(denjinmk): m_text_layer->set_transparent_pen(7) — famiglia usa 15).
rtl/DenjinMakai/DenjinMakai_tile_layer.sv:25 Differenze fra layer (da MAME dcon.cpp):
rtl/DenjinMakai/DenjinMakai_tile_layer.sv:58 BB FG hardcoded +0x1000 (MAME bloodbro fg_tile_info)
rtl/DenjinMakai/DenjinMakai_tile_layer.sv:175 denjinmk 320x256 (MAME visarea 0..255)
rtl/DenjinMakai/DenjinMakai_tile_layer.sv:221 Tile index con eventuale gfx_bank (MG ha bit 12 = 13-bit totali, BG/FG = 12 bit) + TILE_CODE_OFS hardcoded (BB FG aggiunge 0x1000 secondo MAME bloodbro fg_tile_info).
rtl/DenjinMakai/DenjinMakai_video_timing.sv:35 Active area da MAME (sdgndmps_map): visarea 0..40*8-1, 2*8..30*8-1 quindi 320×224, V offset = 16 (top blank).
rtl/DenjinMakai/DenjinMakai_video_timing.sv:60 ── Pixel clock enable: 96 MHz / 14 = 6.857 MHz ───────────────────────── DenjinMakai reale (MAME legionna.cpp:1318 set_raw): pclk 14.318180/2 = 7.15909 MHz.
rtl/DenjinMakai/DenjinMakai_video_timing.sv:64 DENJIN MAKAI: 56 Hz nominali (MAME set_refresh_hz(56), "Value from doc") con la riga Seibu standard ~15.73 kHz → 281 righe totali.
rtl/DenjinMakai/DenjinMakai_video_timing.sv:87 ── Constants timing ───────────────────────────────────────────────────── DenjinMakai REALE (MAME legionna.cpp:1318): set_raw(14318180/2, 455, 0, 320, 258, 0, 224) = 320x224, HTotal 455 @7.159MHz = 15.734 kHz, VTotal 258 → 60.985 Hz.
rtl/DenjinMakai/DenjinMakai_video_timing.sv:122 DENJIN MAKAI: 256 righe visibili (MAME visarea 0..255), CONFERMATE dal riscontro visivo sull'hardware — a 240 si taglierebbero 16 righe di contenuto in basso.
rtl/DenjinMakai/sdram_bridge.sv:151 Differenza chiave vs Godzilla: il MG ha la SUA ROM (bg-2-ab.617, MAME gfx_heatbrl + get_mid_tile_info_split) invece di condividere la back con offset +0x1000 → MG_BASE propria e TILE_CODE_OFS=0 nel tile layer.
rtl/DenjinMakai/sdram_bridge.sv:315 --- FG address descramble (MAME legionna.cpp:1129 descramble_legionnaire_gfx) --- MAME applica un bitswap<24> agli indirizzi della ROM "fore" durante init: src_descrambled[i] = src_raw[bitswap<24>(i, ...
rtl/DenjinMakai/sdram_bridge.sv:362 bitswap MAME del byte offset
README.md:6 Denjin Makai is a beat-'em-up running on the **Seibu `legionna.cpp` hardware family** — an M68000 board with a Seibu CRTC, the SEI252 sprite chip and the SEI300
README.md:12 This core reimplements the hardware in SystemVerilog from MAME references (`seibu/legionna.cpp`, `seibu/legionna_v.cpp`, `seibu/seibu_crtc.cpp`, `seibu/seibucop
README.md:34 **The game runs at 56 Hz.** That is the board's own rate — MAME reads it from the documentation (`set_refresh_hz(56)`) — and the core reproduces it exactly: 436

Says it matches, follows or was checked against MAME — 7

DenjinMakai.sv:200 -1 = sprite 1px a OVEST (sinistra), match MAME su HW
DenjinMakai.sv:228 NB: gli offset per-layer (ex P5) sono HARDCODATI (osd_*_xoff/yoff costanti, match pixel-perfect MAME).
rtl/DenjinMakai/DenjinMakai_cop3.sv:858 find_trigger_match (MAME seibucop.cpp:464) Cerca slot N tale che (trigger & 0xf800) == (cop_func_trigger[N] & 0xf800) && cop_func_trigger[N] != 0.
rtl/DenjinMakai/DenjinMakai_cop3.sv:1313 LEGACY sprite-DMA (match a maschera, MAME find_trigger_match): c480 mask $FF00 -> qualunque c4xx; 6880 mask $FFF3.
rtl/DenjinMakai/DenjinMakai_cop3.sv:2152 res = prod >> 4 (= /16 per matchare formula MAME 2048/32768 = 1/16)
rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:167 +1 pixel a destra: offset verificato con pixel hunting su MAME (rmonic79).
rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:333 Scan INVERSO 511→0 (verificato su HW: ordine sprite-su-sprite opposto al loop MAME 0→511).

Says it was translated, ported or taken from MAME — 2

rtl/DenjinMakai/DenjinMakai_cop3.sv:1904 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197): 1:1 dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (signed) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = floor(sqrt(dx*dx + dy*dy)) if(data&0x80) write_word(r0+(data&0x200?0x3
rtl/DenjinMakai/DenjinMakai_cop3.sv:2021 0x42C2/0x4AA0 divide — MAME execute_42c2/4aa0 (cmd.ipp:219/247): 1:1 DIVIDEND = cop_dist << (5 - cop_scale) (cop_scale 0..3 → shift 5..2) 42c2: div=cop_read_word(r0+0x36)→host 0x34; if(!div){status|=0x8000; write 0 a host 0x3a} else write

Shares text with the MAME driver without saying so — 15

DenjinMakai.sv:804 HAS_TRANSP=1 perché m_background_layer->set_transparent_pen(15) in — shares text with seibu/legionna_v.cpp:216
DenjinMakai.sv:827 get_mid_tile_info_share_bgrom (legionna_v.cpp:158): MG share BG ROM, — shares text with seibu/legionna.h:80
DenjinMakai.sv:1021 VIDEO_START denjinmk: "briefing guy in pre-stage and portraits before a — shares text with seibu/legionna_v.cpp:261
rtl/DenjinMakai/DenjinMakai_audio_z80.sv:463 denjinmk_oki_bank_w: m_oki->set_rom_bank(data & 1) (write tipica 0x02/0x03). — shares text with seibu/legionna.cpp:277
rtl/DenjinMakai/DenjinMakai_main_top.sv:609 In MAME il fade DMA (mode 0x8x) fa m_host_space->write_word(dst): con dst — shares text with seibu/seibucop.cpp:810
rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:184 swapped address line A1 in this range" — offset^=1 poi COMBINE_DATA. — shares text with seibu/legionna.cpp:288
rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:238 "this is either 0x0000 or 0xe000, except in two endings (MT #07416)" — shares text with seibu/legionna_v.cpp:76
rtl/DenjinMakai/DenjinMakai_maincpu_map.sv:310 spins indefinitely until the lowest bit becomes 1" → l'offset 10 — shares text with seibu/legionna.cpp:101
rtl/DenjinMakai/DenjinMakai_palette.sv:23 Palette RAM Seibu DenjinMakai (xBGR_555, 2048 entries). MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 128*16); (legionna. — shares text with seibu/legionna.cpp:1212
rtl/DenjinMakai/DenjinMakai_sprite_renderer.sv:146 if (BIT(~spriteram[i], 15)) continue; → draw quando w0[15]==1. — shares text with seibu/sei021x_sei0220_spr.cpp:128
rtl/DenjinMakai/DenjinMakai_text_renderer.sv:23 Text layer renderer Seibu DenjinMakai (8x8, 4bpp, 64x32). Specifiche da MAME (legionna.cpp:1117-1126, 1167): // charlayout 8x8, RGN_FRAC(1,1), — shares text with seibu/legionna.cpp
rtl/DenjinMakai/DenjinMakai_text_renderer.sv:212 m_text_layer->set_transparent_pen(7) — famiglia usa 15). — shares text with seibu/legionna_v.cpp:219
rtl/DenjinMakai/DenjinMakai_video_timing.sv:23 Video timing single-screen Seibu D-Con. SD Gundam Psycho Salamander gira su Seibu D-Con (PB91008), stessa famiglia di Blood Bros (1990). PCB measuremen — shares text with seibu/legionna.cpp
rtl/DenjinMakai/DenjinMakai_video_timing.sv:88 DenjinMakai REALE (MAME legionna.cpp:1318): set_raw(14318180/2, 455, 0, — shares text with seibu/legionna.cpp:1318
rtl/DenjinMakai/sdram_bridge.sv:317 src_descrambled[i] = src_raw[bitswap<24>(i, ... 6,5,15,14,13,12, 11,10,9,8, 7,4, 3..0)] — shares text with seibu/legionna.cpp:1141

DigDug#
Dig Dug
MiSTer-devel/Arcade-DigDug_MiSTer @ 57956d0d
MAME compared: namco/digdug.cpp + 12 related file(s)
Read: 18 HDL files, 6,982 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

No statements found

Dominos#
Dominos
MiSTer-devel/Arcade-Dominos_MiSTer @ faa35f90
MAME compared: atari/sprint2.cpp + 2 related file(s)
Read: 16 HDL files, 4,422 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 2 toward hardware

Cites hardware documentation that MAME's driver does not — 2

rtl/playfield.vhd:91 Some glue logic, may be re-written later to be cleaner and easier to follow without referring to schematic
rtl/playfield.vhd:148 74LS166 video shift register

DonkeyKong#
Donkey Kong, Radar Scope
MiSTer-devel/Arcade-DonkeyKong_MiSTer @ 53971b3c
MAME compared: nintendo/dkong.cpp + 3 related file(s)
Read: 54 HDL files, 12,045 lines (Quartus project)

MiSTer official

Both

low

Statements: 3 toward hardware, 2 toward MAME, 1 not counted

Cites hardware documentation that MAME's driver does not — 3

rtl/dkong_top.v:24 This description is largely based on the TKG4 schematics, with some extensions to support Radarscope and Donkey Kong Jr (although MiSter currently has a separate DKJR core).
rtl/dkong_top.v:27 In the schematics, ICs are denoted by their position on the board, i.e. IC 6M is the IC in column 6, row M. Unfortunataly, this makes reverse lookup from Verilog to schematic hard, but at least ICs with similar coordinates are often cloase
rtl/dkongjr_dac.sv:8 Components R20, C32 and Q4 on schematics.

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/dkong_sound.v:83 ---- DATA ROM 3H --------------------------- — also in MAME: 3H nintendo/dkong.cpp:2554

Says it was translated, ported or taken from MAME — 2

rtl/mister-discrete/astable_555_vco.sv:40 Drawing based on a drawing from MAME discrete
rtl/mister-discrete/invertor_square_wave_oscilator.sv:33 Drawing based on a drawing from MAME discrete

DonkeyKong3#
Donkey Kong 3
MiSTer-devel/Arcade-DonkeyKong3_MiSTer @ 52aff38b
MAME compared: nintendo/dkong.cpp + 3 related file(s)
Read: 29 HDL files, 11,167 lines (Quartus project)

MiSTer official

Mostly hardware

low

22%

Statements: 18 toward hardware, 19 not counted

Cites hardware documentation that MAME's driver does not — 18

rtl/apu.sv:441 Values read directly from the netlist
rtl/apu.sv:718 This is implemented from the original LSFR frame counter logic taken from the 2A03 netlists.
rtl/dkong3_adec.v:74 CPU can clear the NMI via register @ 3E.
rtl/dkong3_adec.v:102 74LS139 @ 3B
rtl/dkong3_adec.v:126 74LS138 @ 2A
rtl/dkong3_adec.v:145 74LS138 @ 3A
rtl/dkong3_adec.v:163 74LS138 @ 4E Same as 4F except used for writes.
rtl/dkong3_adec.v:183 74LS138 @ 4F Enable signals for reading inputs and and DIP switches
rtl/dkong3_adec.v:206 74LS259 @ 3E Misc control signals (7E80H - 7E87H)
rtl/dkong3_adec.v:236 74LS174 @ 5H Reset signal to sub CPU's
rtl/dkong3_col_pal.v:34 Parts 3M, 3L (74LS157) Selects sprites or backgound pixels Sprites take priority
rtl/dkong3_obj.v:94 Object RAM 6P, 6R
rtl/dkong3_roms.v:11 0x00000 - 0x01FFF 7B PROGRAM ROM (8KB) 0x02000 - 0x03FFF 7C PROGRAM ROM (8KB) 0x04000 - 0x05FFF 7D PROGRAM ROM (8KB) 0x06000 - 0x06FFF 3P GFX ROM (4KB) 0x07000 - 0x07FFF 3N GFX ROM (4KB) 0x08000 - 0x09FFF 7E PROGRAM ROM (8KB) 0x0A000 - 0x0A
rtl/dkong3_sound.v:125 74LS374 @ 4J Input port 0 for Sub CPU 1
rtl/dkong3_sound.v:150 74LS374 @ 4H Input port 1 for sub CPU 1
rtl/dkong3_sound.v:206 ROM 6M for Sub CPU 2
rtl/dkong3_sound.v:217 RAM @ 6F for Sub CPU 2
rtl/dkong3_sound.v:240 74LS374 @ 5F Input port for Sub CPU 2

Cites hardware references or measurements that MAME's driver also gives — 19

rtl/dkong3_adec.v:90 Address Decoder PROM @ 5E — also in MAME: 5E nintendo/dkong.cpp:292
rtl/dkong3_main.v:174 Main CPU RAM 7F (2KB) — also in MAME: 7F nintendo/dkong.cpp:2564
rtl/dkong3_main.v:196 Main CPU RAMs 7H (2KB) This is also read by the DMA controller. — also in MAME: 7H nintendo/dkong.cpp:2913
rtl/dkong3_roms.v:119 Object/Sprite ROMs 7C,7D,7E,7F. — also in MAME: 7C nintendo/dkong.cpp:2561, 7D nintendo/dkong.cpp:2562, 7E nintendo/dkong.cpp:2563, 7F nintendo/dkong.cpp:2564
rtl/dkong3_roms.v:193 CLUT PROM 1D (512x8) Only 256 entries are used. — also in MAME: 1D nintendo/dkong.cpp:2148
rtl/dkong3_roms.v:221 CLUT PROM 1C (512x4) Only 256 entries are used. — also in MAME: 1C nintendo/dkong.cpp:1058
rtl/dkong3_roms.v:249 Colour palette PROM 2N (256x4) 4-bit output. — also in MAME: 2N nintendo/dkong.cpp:2569
rtl/dkong3_roms.v:276 Address decoder PROM 5E (32x8) — also in MAME: 5E nintendo/dkong.cpp:292
rtl/dkong3_roms.v:302 Sub CPU 1 (Sound) ROM 5L. — also in MAME: 5L nintendo/dkong.cpp:2050
rtl/dkong3_roms.v:330 Sub CPU 2 (Sound) ROM 6H. — also in MAME: 6H nintendo/dkong.cpp:804
rtl/dkong3_sound.v:59 Sub CPU 1 @ 4M (Ricoh 2A03) — also in MAME: 4M nintendo/dkong.cpp:2172
rtl/dkong3_sound.v:91 ROM 5L for Sub CPU 1 — also in MAME: 5L nintendo/dkong.cpp:2050
rtl/dkong3_sound.v:102 RAM @ 5K — also in MAME: 5K nintendo/dkong.cpp:333
rtl/dkong3_sound.v:174 Sub CPU 2 @ 5J (Ricoh 2A03) — also in MAME: 5J nintendo/dkong_a.cpp:865
rtl/dkong3_vram.v:47 VRAM 2 x 2114 @ 2P, 2R (1KB) — also in MAME: 2P nintendo/dkong.cpp:2932, 2R nintendo/dkong.cpp:2931
rtl/dkong3_vram.v:74 Colour PROM 2N — also in MAME: 2N nintendo/dkong.cpp:2569
rtl/dkong3_vram.v:106 Video ROMs 3N, 3P — also in MAME: 3N nintendo/dkong.cpp:2557, 3P nintendo/dkong.cpp:2558
rtl/dkong3_vram.v:178 VRAM BUSY signal @ 2K — also in MAME: 2K nintendo/dkong.cpp:2178
rtl/dkong3_vram.v:194 ESBLK signal @ 2K This signal doesn't go anywhere on the schematic. — also in MAME: 2K nintendo/dkong.cpp:2178

DonkeyKongJunior#
Donkey Kong Junior
MiSTer-devel/Arcade-DonkeyKongJunior_MiSTer @ 8d576e70
MAME compared: nintendo/dkong.cpp + 3 related file(s)
Read: 51 HDL files, 15,067 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 1 toward hardware, 4 not counted

Cites hardware documentation that MAME's driver does not — 1

rtl/dkongjr_dac.sv:8 Components R20, C32 and Q4 on schematics.

Cites hardware references or measurements that MAME's driver also gives — 4

rtl/dkongjr_rom.v:11 0x00000 - 0x01FFF 5B PROGRAM ROM (8KB) 0x02000 - 0x03FFF 5C PROGRAM ROM (8KB) 0x04000 - 0x05FFF 5E PROGRAM ROM (8KB) 0x06000 - 0x06FFF 3P GFX ROM (4KB) 0x07000 - 0x07FFF 3N GFX ROM (4KB) 0x08000 - 0x09FFF 5B PROGRAM ROM REPEAT (8KB) 0x0A000 — also in MAME: 5B nintendo/dkong.cpp:290, 5C nintendo/dkong.cpp:291, 5E nintendo/dkong.cpp:292, 3P nintendo/dkong.cpp:2558, 3N nintendo/dkong.cpp:2557, 5B nintendo/dkong.cpp:290, 7C nintendo/dkong.cpp:2561, 7C nintendo/dkong.cpp:2561, 7D nintendo/dkong.cpp:2562, 7D nintendo/dkong.cpp:2562, 7E nintendo/dkong.cpp:2563, 7E nintendo/dkong.cpp:2563, 7F nintendo/dkong.cpp:2564, 7F nintendo/dkong.cpp:2564, 3H nintendo/dkong.cpp:2554, 2E nintendo/dkong.cpp:2567, 2F nintendo/dkong.cpp:2568, 2N nintendo/dkong.cpp:2569
rtl/dkongjr_rom.v:56 Program ROMs are addressed as follows: 0x0000 - 0x0FFF ROM 5B [0x0000 - 0x0FFF] (4KB) 0x1000 - 0x17FF ROM 5C [0x1000 - 0x17FF] (2KB) 0x1800 - 0x1FFF ROM 5E [0x1800 - 0x1FFF] (2KB) 0x2000 - 0x27FF ROM 5C [0x0000 - 0x07FF] (2KB) 0x280 — also in MAME: 5B nintendo/dkong.cpp:290, 5C nintendo/dkong.cpp:291, 5E nintendo/dkong.cpp:292, 5C nintendo/dkong.cpp:291, 5E nintendo/dkong.cpp:292, 5B nintendo/dkong.cpp:290, 5E nintendo/dkong.cpp:292, 5C nintendo/dkong.cpp:291, 5E nintendo/dkong.cpp:292, 5C nintendo/dkong.cpp:291
rtl/dkongjr_sound.v:105 ---- PROG ROM 3H --------------------------- — also in MAME: 3H nintendo/dkong.cpp:2554
rtl/dkongjr_vram.v:99 ----- ROM 2N ----- — also in MAME: 2N nintendo/dkong.cpp:2569

DottoriKun#
Dottori Kun
MiSTer-devel/Arcade-DottoriKun_MiSTer @ 96993eda
MAME compared: sega/dotrikun.cpp
Read: 9 HDL files, 5,323 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 1 toward MAME

Shares text with the MAME driver without saying so — 1

Arcade-DottoriKun.sv:6 Which was based on information from Chris Covell: http://www.chrismcovell.com/dottorikun.html — shares text with sega/dotrikun.cpp:54

Druaga#
Dig Dug II, Grobda, Mappy, Motos …
MiSTer-devel/Arcade-Druaga_MiSTer @ 67d5bb18
MAME compared: namco/mappy.cpp + 4 related file(s)
Read: 11 HDL files, 6,445 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 1 toward MAME

Cites MAME source — 1

Arcade-Druaga.sv:307 JPAC/IPAC/MAME Style Codes

Escape#
Escape from the Planet of the Robot Monsters
MiSTer-devel/Arcade-Escape_MiSTer @ 13642d85
MAME compared: atari/eprom.cpp + 6 related file(s)
Read: 24 HDL files, 16,347 lines (Quartus project)

MiSTer official

Both

medium

44%

Statements: 17 toward hardware, 64 toward MAME

Cites hardware documentation that MAME's driver does not — 14

rtl/core/escape_core.vhd:106 Escape shipped in two cabinet variants with different CPUs and both are confirmed from photographs: the dedicated board carries MC68010P8 (Motorola, date code A71R8813, matching SP-332's "U68010" at 45J/20P - SP-332 IS the dedicated-cabinet
rtl/core/escape_core.vhd:698 SP-332 - which IS the dedicated-cabinet package - draws both CPUs "U68010" (sheet 4 designator 45J "VCPU"; sheet 5 designator 20P "ECPU").
rtl/core/escape_core.vhd:704 (The old comment here claimed "real boards carry 68000s" as against the schematic.
rtl/core/escape_core.vhd:723 Same part as the video CPU on both variants (schematic 20P "ECPU"), and run in the same mode - see the video CPU comment above.
rtl/core/escape_core.vhd:751 autovector: assert VPA during interrupt acknowledge (FC=111), per schematic 60L/55L
rtl/core/escape_core.vhd:1071 On the real part that works because /AS stays asserted across the whole read-modify-write - M68000UM Rev 9 section 5.1.3 p.53, "The address strobe (AS) remains asserted throughout the entire cycle, making the cycle indivisible" - and the bo
rtl/core/escape_decode.vhd:2 Original RTL derived from the authoritative memory map (schematic SP-332, sheet 16; see docs/ARCHITECTURE.md).
rtl/core/escape_jsa.vhd:343 v63: WRIO (bank/YAMRES/squeak/TMS strobes) and MIX live in LS273s cleared only by /POR on the real board (SP-332 sheets 12/13) - they survive a 68k sound reset
rtl/core/escape_jsa.vhd:517 LANE4b: 2A00 write latches the byte onto the chip's data bus (the 74LS374 on the real board); the firmware's WRIO writes strobe WS.
rtl/core/escape_mob.v:116 MOPAIR-131: each line buffer is TWO banks, even and odd screen columns, written in the same clock - which is what the REAL BOARD does: sheet 9 of SP-332 shows the line buffer as a PAIR of LB customs (92U/85U) handling MOL0/1 and MOR0/1 with
rtl/core/escape_mob.v:322 This is the structure the real board has: Escape's PAL16L8 at 70J drives a dedicated /LINK memory slot (SP-332 sheet 7), so list walking never competes with the pixel pipeline.
README.md:15 The dual-CPU program boots and runs on two genuinely concurrent 68010s with shared RAM and the mailbox handshake, as the board does (68000 selectable — the dedi
README.md:45 **Authentic (schematic-verified):** clock frequencies (7.159 MHz CPUs, true pixel clock, all clocks derived from the board's 14.318 MHz colorburst family); rast
README.md:55 **Approximate:** per-instruction CPU cycle counts (TG68K is instruction-accurate, not cycle-exact); bus-cycle timing off-ROM (the original gave every subsystem

Says it was checked against the original PCB — 2

README.md:12 This LLM-assisted build has been refined extensively through testing and benchmarking against an original dedicated cabinet and PCB, with architecture decisions
README.md:42 Performance references are against actual machine gameplay, with MAME as the secondary reference.

Says it was checked on “real hardware” — 1

README.md:68 **Animation cadence**: the walk cycle advances every **8 frames**, locked against real-cabinet captures.

Cites MAME source — 58

rtl/core/TMS5220.vhd:14 This copy is vendored from third_party/Arcade-Atari-system1_MiSTer (GPL-3, (c) 2020 d18c7db) with the LANE3z lattice-filter fix: MAME-faithful matrix_multiply wrap semantics (see MM function), widened u/x accumulators, and output saturation
rtl/core/TMS5220.vhd:19 References: TMS5220 datasheet, US Patent US4335277 and TMS5220.cpp from MAME source code.
rtl/core/TMS5220.vhd:81 MAME's lattice keeps u/x in int32 and wraps them to 15 bits only at the multiplier input (matrix_multiply: a wraps to 10 bits, b to 15 bits); the 13-bit ranges overflowed on loud speech (Escape announcer, energy 14-15) - GHDL bound crash in
rtl/core/TMS5220.vhd:241 LANE3z: MAME tms5220.cpp matrix_multiply, faithful wrap semantics: coefficient wraps to 10-bit two's complement, sample to 15-bit, then signed product >> 9.
rtl/core/escape_core.vhd:106 Escape shipped in two cabinet variants with different CPUs and both are confirmed from photographs: the dedicated board carries MC68010P8 (Motorola, date code A71R8813, matching SP-332's "U68010" at 45J/20P - SP-332 IS the dedicated-cabinet
rtl/core/escape_core.vhd:178 Fetches in range are served zero-wait through the proven BRAM dtack path - restoring the real board's ~4-cycle fetch budget the game's frame architecture assumes (MAME fetches in zero time; SDRAM cost 15-25 cycles and starved the main loop
rtl/core/escape_core.vhd:191 Byte-wide because the real part is: MAME maps it umask16(0x00ff), so only the LOW byte of each word is EEPROM.
rtl/core/escape_core.vhd:209 Channel order per MAME eprom: IN0 = P1 Y, IN1 = P1 X, IN2 = P2 Y, IN3 = P2 X. X axes arrive pre-reversed (0x00 = full right), Y normal (0x00 = full up) — the harness wiring, not something we invert here.
rtl/core/escape_core.vhd:221 260000 D0: factory step/continue switch (unpopulated on production cabs, MAME marks it unused, but the self-test error loop reads it: 0x776 btst #0,$260000 — held low = step past a failed region)
rtl/core/escape_core.vhd:321 Direct speed meter against the MAME reference - answers "are the processors actually at speed?"
rtl/core/escape_core.vhd:328 docs/investigations/PERF_CADENCE.md measures the original in the units that matter - LOGIC UPDATES PER VIDEO FRAME, 0.9977 video / 0.9999 world in MAME - by tapping the two re-entrancy flags each ISR writes: $50 to $16CCD4 (main/video) and
rtl/core/escape_core.vhd:332 These count the $50 writes over 256 video frames, so 0100 hex IS 1.0000 updates/frame and the number is directly comparable to MAME's without assuming anything about clocks, bus cycles or wait states.
rtl/core/escape_core.vhd:348 The attract wipe covers the old scene with alpha tiles (~380 wr/frame in MAME); the stalled red panel on device is either those writes missing (game-logic divergence) or written-but-not-rendered.
rtl/core/escape_core.vhd:419 watchdog: game strobes 2E0000 (MAME eprom.cpp truth); if no strobe for 64 vblanks (~1.07s, authentic recover-by-reboot) this pulses high once
rtl/core/escape_core.vhd:456 v83: pending scroll (written any time) vs applied scroll (latched at frame start) - MAME eprom scanline_update applies alpha 780/781 only at scanline 0; instant application tore animated-scroll screens
rtl/core/escape_core.vhd:568 LANE4n gameplay shadows: MAME PC profile of demo gameplay showed 85% of MAIN-CPU time at 0x40000-0x57FFF (page 0x4E000 alone = 51%) and 21% of EXTRA time at 0xF000 - all outside the v58 shadows = the gameplay slowdown (audio at 100% proved
rtl/core/escape_core.vhd:701 This is what MAME's eprom driver models with M68000.
rtl/core/escape_core.vhd:703 So the schematic and MAME never actually contradicted each other; they describe different machines.
rtl/core/escape_core.vhd:1268 The watch arms on each video-CPU 5A5A command post-boot and clears on the extra's 4321 ack; ~4.7s unanswered (MAME warm ack: instant; 10x margin) latches mbox_dead.
rtl/core/escape_core.vhd:1311 Compare against MAME's cycles/frame for ground truth.
rtl/core/escape_core.vhd:1528 MOSDRAM-72: MAME miss-profiles (attract incl.
rtl/core/escape_core.vhd:1994 MAME's extra_map has video_int_ack_w at 360000 and clearing is shared: EITHER CPU's write drops IRQ4 for both.
rtl/core/escape_core.vhd:2040 LANE4j: EXACT register widths (MAME eprom.cpp truth).
rtl/core/escape_core.vhd:2041 The old 16-byte-wide windows were THE mid-game restart bug: MAME maps the run latch at the single byte 360011; our whole-window decode let game writes to unmapped 360012-1F stop the extra CPU (restart count 16 by mid-game on '58' vs MAME's
rtl/core/escape_core.vhd:2091 A read of 260020+2n returns the last completed conversion in the low byte, then latches channel n (A2..A1) and starts a new one (the read strobe doubles as ALE/START; behavioral reference: MAME eprom adc_r = data_r + address_offset_start_w)
rtl/core/escape_core.vhd:2143 -------------------------------------------------------------- JSA-I sound board link strobes: level-per-bus-cycle is safe (data stable across the cycle; escape_jsa's full/NMI logic is edge-derived internally) LANE4j: exact widths here too
rtl/core/escape_core.vhd:2222 v61 coin-chain probes: count 68k response reads (frozen while resp_full is up = the game stopped listening to the JSA), latch the last response byte, count raw coin-line edges, and snoop the game's own credit counter (work-RAM byte $3F7F55,
rtl/core/escape_core.vhd:2250 LANE3r engine-state probes (MAME attract study): the actor table head word 3F5000 is 0x12xx-patterned when the demo/game engine has spawned actors, 0000 on art pages; mode bytes 3F7F16 (60 art / 54 demo) and 3F7F23 (18 art / 2a demo).
rtl/core/escape_core.vhd:2330 LANE3q: the EXTRA CPU's IO reads were never decoded - every read of 260000/260010/ADC/SCOM returned 0x0000 (MAME's extra_map maps them all).
rtl/core/escape_jsa.vhd:2 Re-implemented from the behavior documented in reference/atarijsa.cpp (MAME, BSD-3-Clause) — no code copied.
rtl/core/escape_jsa.vhd:142 TMS5220 (LANE3u: the real chip - d18c7db's MAME-faithful core from the System 1 tree; Speak External mode is exactly what JSA firmware uses).
rtl/core/escape_jsa.vhd:153 MAME 6502-bus trace (mix_trace.lua) proved the firmware strobes WS through the WRIO latch on EVERY byte (2A04=07 -> 2A00=data -> 2A04=05), exactly the real board's LS273 wiring and the donor CART.vhd hookup.
rtl/core/escape_jsa.vhd:222 -------------------------------------------------------------- 6502 + reset snd_res (68k 360020) pulses a short internal reset, MAME sound_reset_w
rtl/core/escape_jsa.vhd:379 LANE3v: a 2A00 write IS a complete TMS byte transfer (MAME data_w semantics).
rtl/core/escape_jsa.vhd:437 D7 self-test (MAME nets 0 in normal play)
rtl/core/escape_jsa.vhd:444 The schematic doc calls these "+5V", but the JSA harness wires 0x04 as a third coin input (MAME JSAI port: Coin 3, IP_ACTIVE_HIGH; measured idle 2804 = 0x50/0x40, D3:2 = 00).
rtl/core/escape_jsa.vhd:451 D1:0 coins ACTIVE HIGH (MAME JSAI: IP_ACTIVE_HIGH; measured: idle 0, held coin reads 1)
rtl/core/escape_mob.v:3 During each scanline, builds the NEXT line into a line buffer: SLIP[band] -> linked list of 4-word entries (link*4 layout) -> per-tile chunky gfx fetches via the shared video SDRAM channel -> first-write-wins pixels (equivalent to MAME's re
rtl/core/escape_mob.v:431 That is checked, not argued: sim/tools/mob_order_check.py diffs the per-line sprite load sequence against the depth-1 engine's (the shorter run must be an exact prefix of the longer) and sim/tools/mob_vs_mame.py scores the rendered layer ag
rtl/core/escape_mob.v:615 v80: MAME atarimo ground truth - the entry Y field is NEGATED and offset by the sprite height: top = -yfield - (height+1)*8.
rtl/core/escape_mob.v:896 The old "+2" made every sprite land one scanline too high; cross-correlating the engine's output against MAME's showed a clean (dx=0, dy=+1) peak covering 88% of the matched pixels.
rtl/core/escape_mob.v:1113 MOPRI-1: eprom MO config, "mask for the priority" = 0x0070 in word 2 (reference/eprom.cpp s_mob_config).
rtl/core/escape_mob.v:1194 eprom's MO config sets "render in reverse order" (reference/eprom.cpp s_mob_config), so atarimo draws the linked list from its TAIL back to its HEAD - the head entry is painted last and therefore wins every pixel it touches.
rtl/core/escape_prio.v:4 Purely combinational; replaces the old fixed "MO always in front of PF" ladder in core_top.v. Transcribed from the GAL equations verified off the real PCB and quoted in reference/eprom.cpp (screen_update_eprom):
rtl/core/escape_prio.v:21 Signal mapping into this core's pixel pipeline (derived from MAME's tile-info + pen construction for eprom - see docs/investigations/mo_priority.md):
rtl/core/escape_prio.v:24 MPR2:MPR0 motion-object entry word 2 bits [6:4] (config mask 0x0070) MPX7:MPX4 motion-object colour = mo_pen[7:4] MPX3:MPX0 motion-object pixel = mo_pen[3:0] PFX5:PFX4 playfield priority = low two bits of the playfield tile colo
rtl/core/escape_stain.v:15 The reference (reference/atarimo.cpp, apply_stain) is:
rtl/core/escape_stain.v:24 restarted at every marker pixel by eprom.cpp's second iterate_dirty_rects pass.
rtl/core/hall_stick.v:7 X axes are reversed on the real harness (full right = 0x00, per MAME's PORT_REVERSE on ADC1/ADC3), so targets are pre-reversed here; escape_core's ADC model digitizes exactly what it is handed.
rtl/escape_mister.v:265 MAME declares this region ROMREGION_INVERT, so every byte is complemented first; then plane bits are gathered into 4-bit pixels, two per output byte, plane0 = MSB.
rtl/escape_mister.v:700 PF has the only hard realtime deadline in the system, and its demand is bounded (two fetches per 8-px cell), so the CPUs wait at most ~two reads - the attract-cycle benchmark has the game running slightly FASTER than MAME, so that headroom
rtl/escape_mister.v:937 column-major map scan (MAME SCAN_COLS semantics)
README.md:10 A MiSTer (DE10-Nano) port of the [Atari Dual 68k](https://github.com/spoonelli/Atari-Dual-68k) core, implementing Atari Games' 1989 arcade release (MAME set `ep
README.md:45 **Authentic (schematic-verified):** clock frequencies (7.159 MHz CPUs, true pixel clock, all clocks derived from the board's 14.318 MHz colorburst family); rast
README.md:65 **Frame-level pacing**: attract-loop period accuracy exceeding **99.6%** against MAME, story-panel timers in exact lockstep — and the residual is MAME slowing *
README.md:70 **Slowdown character**: in heavy crowds the game software slows on every platform; a MAME longplay spends ~1.5x more of its crowd time slowed than this core — c
README.md:74 **This port specifically**: crowd-scene scroll-velocity distributions measured identical to the Analogue Pocket release, with zero sub-half-speed dips where MAM
README.md:77 **Pixels**: motion-object output replays MAME scene dumps at **100.0000% agreement and coverage** on crowd, door, spawn-flash and factory-map fixtures.

Says it matches, follows or was checked against MAME — 1

README.md:33 | Video: alpha / playfield / motion objects, IRGB palette + intensity | ✅ pixel-verified vs MAME scene replay |

Says it was translated, ported or taken from MAME — 1

rtl/core/TMS5220.vhd:21 IMPORTANT NOTES: 1) This implementation does NOT implement the schematic in US4335277 2) It is based primarily on MAME source code and aims to be "functionally equivalent" to the "TMS5220" chip but not identical in terms of electrical circu

Shares text with the MAME driver without saying so — 4

rtl/core/escape_prio.v:12 !SHADE = !MPX0 + MPX1 + MPX2 + MPX3 + !MPX4*!MPX5*!MPX6*!MPX7 + FORCEMC0 — shares text with atari/eprom.cpp:328
rtl/core/escape_prio.v:14 !PF/M = MPR0*MPR1 + PFX3 + !PFX4*MPR1 + !PFX5*MPR1 + !PFX5*MPR0 — shares text with atari/eprom.cpp:336
rtl/core/escape_stain.v:32 START_MARKER = (4 << PRIORITY_SHIFT) | 2 — shares text with atari/atarimo.cpp:241
rtl/core/escape_stain.v:33 END_MARKER = (4 << PRIORITY_SHIFT) | 4 — shares text with atari/atarimo.cpp:242

Exerion#
Exerion
MiSTer-devel/Arcade-Exerion_MiSTer @ e4c3ef79
MAME compared: jaleco/exerion.cpp
Read: 12 HDL files, 3,291 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

16%

Statements: 3 toward hardware

Cites hardware documentation that MAME's driver does not — 3

rtl/ttl_chips.v:6 74LS74 Chip pinout:
rtl/ttl_chips.v:57 74LS107 Chip pinout:
rtl/ttl_chips.v:102 74LS139 Chip pinout:

Exidy2#
Hard Hat, Mouse Trap, Pepper II, Spectar …
MiSTer-devel/Arcade-Exidy2_MiSTer @ 91864236
MAME compared: exidy/exidy.cpp
Read: 7 HDL files, 2,922 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

36%

Statements: 4 toward hardware

Cites hardware documentation that MAME's driver does not — 4

rtl/audio_board.v:95 The PIAs @9B & 8B of the audio expansion board provide a handshake between the main CPU and the audio CPU
rtl/ttl_chips.v:6 74LS74 Chip pinout:
rtl/ttl_chips.v:57 74LS107 Chip pinout:
rtl/ttl_chips.v:102 74LS139 Chip pinout:

ExpressRaider#
Western Express
MiSTer-devel/Arcade-ExpressRaider_MiSTer @ 970e8f54
MAME compared: dataeast/exprraid.cpp
Read: 94 HDL files, 18,311 lines (Quartus project)

MiSTer official

Mostly hardware

low

30%

Statements: 8 toward hardware, 1 toward MAME

Cites hardware documentation that MAME's driver does not — 7

rtl/audio/ym2203/jt12_exprom.v:19 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.
rtl/audio/ym2203/jt12_logsin.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.
rtl/audio/ym2203/jt12_op.v:19 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.
rtl/audio/ym2203/jt12_reg.v:329 memory for CH registers Block/fnum data is latched until fnum low byte is written to Trying to synthesize this memory as M-9K RAM in Altera devices turns out worse in terms of resource utilization.
rtl/audio/ym3526/jtopl_exprom.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.
rtl/audio/ym3526/jtopl_logsin.v:16 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.
rtl/audio/ym3526/jtopl_op.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.

Ships hardware documentation files — 1

_schematics/Express Raider Schematics.pdf

Cites MAME source — 1

rtl/audio/ym2203/jt12_lfo.v:78 same values as in MAME

Finalizer#
Finalizer: Super Transformation
MiSTer-devel/Arcade-Finalizer_MiSTer @ d4828f09
MAME compared: konami/finalizr.cpp + 3 related file(s)
Read: 10 HDL files, 7,227 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

15%

Statements: 1 toward MAME

Cites MAME source — 1

rtl/custom/k005885.sv:388 The 005885 has five 8-bit registers set up as follows according to information in konamiic.txt found in MAME's source code:

FoodFight#
Food Fight
MiSTer-devel/Arcade-FoodFight_MiSTer @ 0e055157
MAME compared: atari/foodf.cpp
Read: 25 HDL files, 7,857 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 2 toward hardware

Cites hardware documentation that MAME's driver does not — 2

rtl/Pokey/pokey_poly_17_9.vhdl:53 next state (as pokey decap)
rtl/Pokey/pokey_poly_17_9.vhdl:74 from pokey schematics

freeze#
Freeze, Jack the Giantkiller, Super Casino, Tri-Pool: 3-In-One …
MiSTer-devel/Arcade-Freeze_MiSTer @ c68025bd
MAME compared: cinematronics/jack.cpp
Read: 35 HDL files, 7,820 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

No statements found

Frenzy#
Frenzy
MiSTer-devel/Arcade-Frenzy_MiSTer @ 94841c8a
MAME compared: stern/berzerk.cpp
Read: 9 HDL files, 2,598 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

45%

Statements: 3 toward MAME

Cites MAME source — 2

rtl/berzerk.vhd:62 Mame command reminder wpiset 40,1,w,1,{printf "a:%08x d:%02X",wpaddr,wpdata; g} wpiset 40,1,w,(wpdata!=0) && (wpdata!=90) && (wpdata!=92),{printf "a:%08x d:%02X",wpaddr,wpdata; g}
rtl/berzerk_speech.vhd:6 By Jonathan Gevaryahu ("Lord Nightmare") with help from Kevin Horton ("kevtris") MAME conversion and integration by R. Belmont Clock Frequency control updated by Zsolt Vasvari Other fixes by AtariAce

Says it was translated, ported or taken from MAME — 1

rtl/berzerk_speech.vhd:4 s14001a speech synthesis based on Mame source code : TSI S14001A emulator v1.32

Fuuki#
Asura Blade - Sword of Dynasty, Asura Buster - Eternal Warriors, Susume! Mile Smile / Go Go! Mile Smile, Gyakuten!! Puzzle Bancho
MiSTer-devel/Arcade-Fuuki_MiSTer @ 2964ff4b
MAME compared: fuuki/fuukifg2.cpp, fuuki/fuukifg3.cpp + 4 related file(s)
Read: 27 HDL files, 6,817 lines (Quartus project)

MiSTer official

Mostly MAME

medium

61%

Statements: 1 toward hardware, 65 toward MAME

Notes where it differs from MAME — 1

Fuuki.sv:669 The DIP "Flip Screen" (which both MAME drivers get wrong) stays commented out of the .mra files.

Cites MAME source — 52

Fuuki.sv:164 Both boards drive one speaker (fuukifg2.cpp / fuukifg3.cpp), so the default, status value 0, is mono.
Fuuki.sv:335 Every port is IP_ACTIVE_LOW in MAME; hps_io's joysticks are active high, hence the `~`.
Fuuki.sv:340 P1_P2 ($810000), from fuukifg2.cpp / fuukifg3.cpp INPUT_PORTS_START.
rtl/cpu/maincpu.sv:95 Interrupt sources: levels held by the video timing, MAME's HOLD_LINE.
rtl/cpu/maincpu.sv:192 FG-2 mirrors sprite RAM at +0x8000 (MAME: .mirror(0x008000)).
rtl/cpu/maincpu.sv:203 FG-2 sound latch: MAME maps the one byte at 0x8a0001.
rtl/cpu/maincpu.sv:213 FG-3's 0x508000-0x517FFF: MAME calls it "more tilemap, or linescroll?
rtl/fuuki_core.sv:648 Reference: gogomile's clouds (MAME capture: bands at 2, 1, 1/2, 0, 0 px/frame from lines 0, 30, 64, 89, 119) and pbancho's per-line scroll.
rtl/fuuki_core.sv:893 xRGB-555 as MAME decodes it (palette_device::xRGB_555 is standard_rgb_decoder<5,5,5, 10,5,0>): bits 14:10 red, 9:5 green, 4:0 blue.
rtl/memory/fuuki_sdram_top.sv:109 ---- address map, FG-3 ---- Sizes are the ROM_REGION declarations in fuukifg3.cpp, not the ROMs loaded: asurabld leaves the first 4 MB of its 32 MB sprite region empty and the sprite tile bank can address it, so the hole is part of the map.
rtl/memory/fuuki_sdram_top.sv:118 2 MB (MAME "tiles_bg")
rtl/memory/fuuki_sdram_top.sv:120 4 MB (MAME "ymf", OPL4 samples)
rtl/video/compositor.sv:5 MAME draws back, middle, front with priority codes 1, 2, 4, ORing each into a priority bitmap where the layer is opaque, so a pixel carries a 3-bit value saying which layers covered it.
rtl/video/compositor.sv:23 The backdrop is the last palette pen, 0x1fff, not pen 0: MAME fills with (0x800*4)-1 and the game writes black there at boot.
rtl/video/sprite_line_engine.sv:104 Separate non-zoomed path, as MAME: the zoom path draws 17 pixels at full size (sprite_zoom_lut.sv).
rtl/video/sprite_line_engine.sv:118 ---- code index ---- MAME increments the tile code in loop order and positions by the loop variable, so with flip the code is counted from the far end: iteration number, not position.
rtl/video/sprite_line_list.sv:10 This is the order measured on MiSTer (asurabld high-score table, in-game sprites, character-name flashes) and the opposite of what fuukispr.cpp's backwards walk for pdrawgfx suggests.
rtl/video/sprite_line_list.sv:62 ---- geometry, from the four latched words ---- Signed 10-bit positions, MAME's (v & 0x1ff) - (v & 0x200).
rtl/video/sprite_line_list.sv:74 MAME's separate non-zoomed path when both fields are zero; the zoom path draws 17 pixels at full size (sprite_zoom_lut.sv).
rtl/video/sprite_zoom_lut.sv:3 MAME hands zoom_transpen a 16.16 scale of 512 * (zoom + 8), zoom = 128 - 4*field, so a 16-pixel tile draws (zoom + 8) / 8 wide and destination pixel d samples source pixel (d << 16) / scale.
rtl/video/sprite_zoom_lut.sv:13 That is why the engine keeps MAME's separate non-zoomed path.
rtl/video/sprite_zoom_lut.sv:26 step = (128 << 16) / (zoom_t + 8), truncated as MAME's integer division.
rtl/video/spriteram_dbuf.sv:5 A frame is therefore drawn from the sprite RAM as it was at one instant, as MAME's single-pass screen_update does.
rtl/video/spriteram_dbuf.sv:13 FG-3 (fuukifg3.cpp screen_vblank) appears to hold sprites two generations back.
rtl/video/tilemap_line_engine.sv:49 MAME does not flip by rotating the output: fuukitmap.cpp substitutes offset constants and fuukispr.cpp recomputes sprite positions, so it has to be done here.
rtl/video/video_timing.sv:3 Neither driver calls set_raw(); fuukifg2.cpp and fuukifg3.cpp give only set_refresh_hz(60) and a visible area, so htotal, vtotal and sync positions are derived (docs/ROADMAP.md, "Screen timing"):
rtl/video/video_timing.sv:52 maincpu.sv edge-detects them into a held pending flag cleared only by acknowledge (MAME's HOLD_LINE).
rtl/video/video_timing.sv:54 Positions from fuukitmap.cpp's timers: level 1 screen().time_until_pos(248) -> line 248, x=0 level 3 screen().time_until_vblank_start() -> line 240, x=0 level 5 screen().time_until_pos(vregs[0x1c], max_x +
rtl/video/video_timing.sv:83 losing the effect's first five lines and adding five spurious interrupts a frame (checked against MAME traces in debug/).
rtl/video/video_timing.sv:123 raster_line arrives from vregs.sv already reduced as MAME's time_until_pos() reduces it, so every register value fires once a frame.
rtl/video/video_timing.sv:126 Level 5 fires at the hblank one line before the programmed line, not at that line's own hblank as MAME's timer does: the engines render two lines ahead of the display and a raster ISR's write is caught at the hblank after the interrupt.
rtl/video/video_timing.sv:132 lead 2 : bands start at 29, 63, 88, 118 (MAME: 30, 64, 89, 119) lead 1 : bands start at 30, 64, 89, 119 exact
rtl/video/vregs.sv:1 Fuuki video registers (FI-003K), from fuukitmap.cpp.
rtl/video/vregs.sv:7 sel 1 0x8D0000 "unknown, flipscreen related" (MAME's words)
rtl/video/vregs.sv:10 Register map (fuukitmap.cpp's own comment block):
rtl/video/vregs.sv:95 ---- raster line: the low 8 bits of regs[0x1c], as MAME ---- fuukitmap.cpp hands the value to screen::time_until_pos(), which reduces it modulo the screen height, 256 on both boards (fuukifg2.cpp set_size(320, 256); fuukifg3.cpp set_size(51
rtl/video/vregs.sv:111 ---- scroll offsets ---- From fuukitmap.cpp::prepare(), operators included:
rtl/video/vregs.sv:143 16-bit wrapping arithmetic, as MAME's u16.
rtl/video/vregs.sv:154 ---- layer order ---- The low 4 bits of the priority register index a table of orderings (fuukitmap.cpp: "not independent bits causing layers to switch").
rtl/video/vregs.sv:156 MAME indexes a six-entry table with `& 0x0f`, so 6-15 read out of bounds there; here they fall through to entry 0 (docs/ROADMAP.md open item 5).
README.md:109 Put the MAME merged or split ROMs in `games/mame`
README.md:141 The MAME drivers being ported here, `fuukifg2.cpp` and `fuukifg3.cpp` are based on my and others, work.
README.md:147 Hardware facts come from the MAME driver.
README.md:149 The graphics layouts were rendered to PNG from real ROM data before any RTL used them; the CPU is diffed against a real MAME trace; the video pipeline is diffed
README.md:152 Where the reference and the hardware disagree, or where MAME's own comments disclaim accuracy, that is recorded as an open question rather than silently resolve
README.md:159 MAME is the accuracy reference, with its own acknowledged uncertainties noted where they matter (both Fuuki drivers flag raster effects and flipped-screen scrol
README.md:167 **Ground truth captured from MAME automatically.** `scripts/mame_capture.py` drives MAME headlessly over its Lua interface and dumps every region the video hard
README.md:171 That makes "compare against MAME" a single command rather than a hand-driven debugger session.
README.md:172 **Offline proofs before building.** ROM interleaves are scored against MAME's disassembly, and graphics layouts rendered to PNG, before any RTL depends on them.
README.md:191 The **MAMEdev team** — in particular **Luca Elia**, **David Haywood** and my own earlier work — for [MAME](https://github.com/mamedev/mame)'s `fuukifg2.cpp`, `f
README.md:227 | `debug` | reference captures from MAME used as ground truth (gitignored) |
README.md:228 | `roms` | your own MAME sets (gitignored, never committed) |

Says it matches, follows or was checked against MAME — 1

README.md:116 Same as MAME, but would love to see real hardware

Shares text with the MAME driver without saying so — 12

rtl/cpu/maincpu.sv:214 Seems to be empty all of the time". Decoded so accesses terminate, not — shares text with fuuki/fuukifg3.cpp:396
rtl/fuuki_core.sv:371 layer 0 layer 1 layer 2 — shares text with fuuki/fuukifg2.cpp:127
rtl/video/tilemap_line_engine.sv:170 exceed the granularity there ("256 colour tiles with palette selectable — shares text with fuuki/fuukifg2.cpp:157
rtl/video/vregs.sv:12 00.w Layer 0 Scroll Y 0c.w Layers Y Offset — shares text with fuuki/fuukitmap.cpp:194
rtl/video/vregs.sv:13 02.w Layer 0 Scroll X 0e.w Layers X Offset — shares text with fuuki/fuukitmap.cpp:195
rtl/video/vregs.sv:14 04.w Layer 1 Scroll Y 1c.w Trigger a level 5 irq on this raster line — shares text with fuuki/fuukitmap.cpp:196
rtl/video/vregs.sv:15 06.w Layer 1 Scroll X 1e.w bit 0 Flip screen — shares text with fuuki/fuukitmap.cpp:197
rtl/video/vregs.sv:16 08.w Layer 2 Scroll Y bit 6 Layer 2 VRAM buffer select — shares text with fuuki/fuukitmap.cpp:198
rtl/video/vregs.sv:17 0a.w Layer 2 Scroll X — shares text with fuuki/fuukitmap.cpp:199
rtl/video/vregs.sv:114 scrolly_offs = m_vregs[0xc/2] - (m_flip ? m_xoffs_flip : m_xoffs); — shares text with fuuki/fuukitmap.cpp:245
rtl/video/vregs.sv:115 scrollx_offs = m_vregs[0xe/2] - (m_flip ? m_yoffs_flip : m_yoffs); — shares text with fuuki/fuukitmap.cpp:246
rtl/video/vregs.sv:156 (fuukitmap.cpp: "not independent bits causing layers to switch"). MAME — shares text with fuuki/fuukitmap.cpp:229

Galaga#
Galaga
MiSTer-devel/Arcade-Galaga_MiSTer @ c84be1c7
MAME compared: namco/galaga.cpp + 12 related file(s)
Read: 23 HDL files, 8,015 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

26%

Statements: 9 toward MAME

Cites MAME source — 9

rtl/galaga.vhd:34 Features : TV 15KHz mode only (atm) Coctail mode ok Sound ok Starfield from MAME information
rtl/galaga.vhd:40 Use with MAME roms from galagamw.zip
rtl/galaga.vhd:69 Namco 05XX Starfield 4 sets, 63 stars/set, 2 set displayed at one time for blinking 6bits colors: 2red/2green/2blue full emulation in vhdl (from MAME information)
rtl/stars.vhd:6 Done from only available MAME information
rtl/stars.vhd:24 Scan line number are 1 less than MAME list because of way of realisation Scan line number are ordered from lower to higher.
rtl/stars_machine.vhd:6 Done from only available MAME information
rtl/stars_machine.vhd:24 Scan line number are 1 less than MAME list because of way of realisation Scan line number are ordered from lower to higher.
README.md:65 /quote from [MAME sources](https://github.com/mamedev/mame/blob/a32810d97465ae077ece35984a98a92abbf3462f/src/mame/drivers/galaga.cpp#L584-L587)/: There is a bug
README.md:78 [Source](https://github.com/mamedev/mame/blob/a32810d97465ae077ece35984a98a92abbf3462f/src/mame/drivers/galaga.cpp#L555-L559)

Galaxian#
Azurian Attack, Black Hole, Catacomb, Galaxian …
MiSTer-devel/Arcade-Galaxian_MiSTer @ 9fecadef
MAME compared: galaxian/galaxian.cpp + 7 related file(s)
Read: 22 HDL files, 4,906 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

12%

Statements: 2 toward MAME

Cites MAME source — 1

Arcade-Galaxian.sv:452 NOTE: mame order matches order in mc_inport, mc_inport reorders these

Shares text with the MAME driver without saying so — 1

rtl/mc_inport.vhd:17 DIP SW 0 1 2 3 4 5 — shares text with galaxian/galaxian.cpp:2796

Galivan#
Ufo Robo Dangar, Cosmo Police Galivan
MiSTer-devel/Arcade-Galivan_MiSTer @ 08c16a1d
MAME compared: nichibutsu/galivan.cpp + 4 related file(s)
Read: 42 HDL files, 10,306 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 3 toward hardware

Cites hardware documentation that MAME's driver does not — 3

rtl/ym3526/jtopl_exprom.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.
rtl/ym3526/jtopl_logsin.v:16 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.
rtl/ym3526/jtopl_op.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.

Gaplus#
Gaplus
MiSTer-devel/Arcade-Gaplus_MiSTer @ 718b413d
MAME compared: namco/gaplus.cpp + 7 related file(s)
Read: 16 HDL files, 7,148 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

No statements found

Gauntlet#
Gauntlet II, Gauntlet, Vindicators Part II
MiSTer-devel/Arcade-Gauntlet_MiSTer @ a27c3f1a
MAME compared: atari/gauntlet.cpp + 4 related file(s)
Read: 26 HDL files, 6,302 lines (Quartus project)

MiSTer official

Both

medium

92%

Statements: 64 toward hardware, 5 toward MAME, 12 not counted

Cites hardware documentation that MAME's driver does not — 63

rtl/gauntlet/AUDIO.vhd:212 sheet 5 --
rtl/gauntlet/AUDIO.vhd:345 sheet 6 --
rtl/gauntlet/AUDIO.vhd:376 15S latch - 3 bit volume control
rtl/gauntlet/AUDIO.vhd:485 sheet 7 --
rtl/gauntlet/CRAMS.vhd:51 sheet 15 Color RAM --
rtl/gauntlet/CRAMS.vhd:61 10L, 10M RAM
rtl/gauntlet/GPC.vhd:13 Graphic Priority Control (Atari custom chip 137419-101) This GPC was derived from System I SP-277 schematic
rtl/gauntlet/GPC.vhd:73 These equations describe the PROM 3E contents, top 2 data bits are the same as bottom 2 data bits as can be seen in PROM dump
rtl/gauntlet/GPC.vhd:85 9D latch
rtl/gauntlet/GPC.vhd:101 3H latch
rtl/gauntlet/GPC.vhd:124 3F latch
rtl/gauntlet/LINEBUF.vhd:74 1X, 1W, 2X, 2W RAM
rtl/gauntlet/LS299.vhd:17 simplified 74LS299 shifter as used in SLAGS
rtl/gauntlet/MAIN.vhd:221 sheet 2
rtl/gauntlet/MAIN.vhd:407 sheet 3
rtl/gauntlet/MAIN.vhd:506 sheet 4
rtl/gauntlet/MAIN.vhd:538 sheet 7
rtl/gauntlet/MAIN.vhd:566 RAMs 11A/B
rtl/gauntlet/MAIN.vhd:567 RAMs 12A/B
rtl/gauntlet/MOHLB.vhd:44 sheet 13 Motion Object Line Buffer --
rtl/gauntlet/MOHLB.vhd:47 5S latch
rtl/gauntlet/PFHS.vhd:13 Play Field Horizontal Scroll (Atari custom chip 137419-104) This PFHS was derived from System I SP-277 schematic
rtl/gauntlet/PFHS.vhd:76 11E latch
rtl/gauntlet/PFHS.vhd:89 two 74LS189 16x4 bit RAMs, arranged as one 16x8 RAM but only 3 address lines used, so really one 8x8 RAM IMPORTANT: data out is the COMPLEMENT of data in!!!
rtl/gauntlet/PFHS.vhd:102 4D latch
rtl/gauntlet/SLAGS.vhd:13 Storage/Logic Array Graphics Shifter (Atari custom chip 137415-101) This SLAGS was derived from Marble Madness SP-276 schematic
rtl/gauntlet/SLAGS.vhd:73 latch 8B
rtl/gauntlet/SLAGS.vhd:84 latch 11A
rtl/gauntlet/SYNGEN.vhd:13 System Clock and Sync Generator (Atari custom chip 137419-103) This SYNGEN was derived from System I SP-277 schematic
rtl/gauntlet/SYNGEN.vhd:106 From SP-313 this is /HBLANK
rtl/gauntlet/SYNGEN.vhd:161 Equations for PLA chip 7F Signetics 82S153 aka PLS153A (Atari custom chip 136032.103) /o19 = /i1 & i2 & i3 & i7 & i8 & i9 o18 = i1 & /i2 o17 = i1 & /i2 & /i3 + /i1 & i2 & /i3 + i1 & /i2 & i3 o16 = /i2 + i1 & i2 & /i3 + /i1 & i2 & i3
rtl/gauntlet/VIDEO.vhd:255 sheet 2 control signals --
rtl/gauntlet/VIDEO.vhd:270 sheet 8 RAM banks --
rtl/gauntlet/VIDEO.vhd:287 sheet 9 VRAM addr and data bus muxes --
rtl/gauntlet/VIDEO.vhd:291 8F, 8J latches sheet 9 D transfered to Q on the rising edge of clock if enable /G is low
rtl/gauntlet/VIDEO.vhd:311 7S latch
rtl/gauntlet/VIDEO.vhd:346 sheet 10
rtl/gauntlet/VIDEO.vhd:350 3C, 3K latch sheet 10
rtl/gauntlet/VIDEO.vhd:363 5C, 5K latches sheet 10
rtl/gauntlet/VIDEO.vhd:378 4E latch
rtl/gauntlet/VIDEO.vhd:413 PROM 5L is 82S147 512x8 TTL BIPOLAR PROM (Atari chip 136037.102) Top 2 address bits tied low so only 128x8 used
rtl/gauntlet/VIDEO.vhd:459 4C, 4K latch
rtl/gauntlet/VIDEO.vhd:470 4D latch
rtl/gauntlet/VIDEO.vhd:484 sheet 11 - plane 0 and plane 1 ROMs and SLAG -- sheet 12 - plane 2 and plane 3 ROMs and SLAG -- ROMs total 256KB and are stored outside the FPGA
rtl/gauntlet/VIDEO.vhd:529 sheet 13 Play Field Scroll --
rtl/gauntlet/VIDEO.vhd:564 sheet 14
rtl/gauntlet/VIDEO.vhd:569 4N, 3N latches sheet 14
rtl/gauntlet/VIDEO.vhd:592 3P latch
rtl/gauntlet/VIDEO.vhd:658 6U latch with 7U PROM equations
rtl/gauntlet/VIDEO.vhd:662 82S147 512x8 TTL BIPOLAR PROM (Atari chip 136037.101) These equations replace the 7U PROM
rtl/gauntlet/VIDEO.vhd:797 sheet 15
rtl/gauntlet/VIDEO.vhd:854 9N, 10N latch color palette output
rtl/gauntlet/VIDEO.vhd:918 4P latch
rtl/gauntlet/VIDEO.vhd:923 7R latch
rtl/gauntlet/VRAMS.vhd:76 sheet 9 RAM decoder --
rtl/gauntlet/VRAMS.vhd:93 sheet 8 RAM banks --
rtl/gauntlet/VRAMS.vhd:103 PF video RAMs 6J, 7J
rtl/gauntlet/VRAMS.vhd:116 PF video RAMs 6D, 7D
rtl/gauntlet/VRAMS.vhd:129 MO video RAMs 6F, 7F
rtl/gauntlet/VRAMS.vhd:142 MO video RAMs 6C, 7C
rtl/gauntlet/VRAMS.vhd:155 AL video RAMs 6K, 7K
rtl/gauntlet/VRAMS.vhd:168 AL video RAMs 6E, 7E
readme.md:5 This is an FPGA implementation of Atari's arcade game "Gauntlet" from 1985, based on the SP-284 schematic circuit diagram.

Cites hardware references or measurements that MAME's driver also gives — 12

Arcade-Gauntlet.sv:523 ioctl_addr 000000..01FFFF = video ROMs 2L 2A 1L 1A (4*32KB) ioctl_addr 020000..03FFFF = video ROMs 2MN 2B 1MN 1B (4*32KB) ioctl_addr 040000..05FFFF = video ROMs 2P 2C 1P 1C (4*32KB) ioctl_addr 060000..07FFFF = video ROMs 2R 2D 1 — also in MAME: 2L atari/gauntlet.cpp:887, 2A atari/gauntlet.cpp:885, 1L atari/gauntlet.cpp:883, 1A atari/gauntlet.cpp:881, 2MN atari/gauntlet.cpp:888, 2B atari/gauntlet.cpp:886, 1MN atari/gauntlet.cpp:884, 1B atari/gauntlet.cpp:882, 2P atari/gauntlet.cpp:1639, 2C atari/gauntlet.cpp:1635, 1P atari/gauntlet.cpp:1631, 1C atari/gauntlet.cpp:1627, 2R atari/gauntlet.cpp:1902, 2D atari/gauntlet.cpp:1895, 1R atari/gauntlet.cpp:1888, 1D atari/gauntlet.cpp:1881, 2ST atari/gauntlet.cpp:1903, 2EF atari/gauntlet.cpp:1896, 1ST atari/gauntlet.cpp:1889, 1EF atari/gauntlet.cpp:1882, 2U atari/gauntlet.cpp:1904, 2J atari/gauntlet.cpp:1897, 1U atari/gauntlet.cpp:1890, 1J atari/gauntlet.cpp:1883
Arcade-Gauntlet.sv:545 ioctl_addr 140000..147FFF = AUDIO ROM 16S (32KB) — also in MAME: 16S atari/gauntlet.cpp:875
Arcade-Gauntlet.sv:547 ioctl_addr 148000..14BFFF = AUDIO ROM 16R (16KB) — also in MAME: 16R atari/gauntlet.cpp:874
Arcade-Gauntlet.sv:549 ioctl_addr 14C000..14FFFF = CHAR ROM 6P (16KB) — also in MAME: 6P atari/gauntlet.cpp:878
rtl/gauntlet/GPC.vhd:134 1B, 5B latch — also in MAME: 1B atari/gauntlet.cpp:882, 5B atari/gauntlet.cpp:1863
rtl/gauntlet/MAIN.vhd:564 ROMs 10A/B, 9A/B, 7A/B — also in MAME: 10A atari/gauntlet.cpp:866, 9A atari/gauntlet.cpp:862, 7A atari/gauntlet.cpp:868
rtl/gauntlet/SYNGEN.vhd:134 82S129 256x4 TTL BIPOLAR PROM (Atari chip 136032.102) — also in MAME: 82S129 atari/gauntlet.cpp:1645
rtl/gauntlet/VIDEO.vhd:244 Vindicators II uses ROM 2J which is the only ROM with a scrambled address -- FIXME — also in MAME: 2J atari/gauntlet.cpp:1897
rtl/gauntlet/VIDEO.vhd:602 PROM 4R is 74S287 (256x4) TTL PROM "136037-103" — also in MAME: 4R atari/gauntlet.cpp:893, 74S287 atari/gauntlet.cpp:893, 136037-103 atari/gauntlet.cpp:893
rtl/gauntlet/VIDEO.vhd:654 Vindicators has tweaked equations in PROM 7U for signal /NEWMON Select between Vindicators or Gauntlet equations — also in MAME: 7U atari/gauntlet.cpp:891
rtl/gauntlet/VIDEO.vhd:771 UNUSED this /BUFCLR replaced by signal from PROM 7U — also in MAME: 7U atari/gauntlet.cpp:891
readme.md:32 *WARNING:* In order to play Vindicators part 2, you must run the python script "descramble_2J.py 136059-1184.2j 136059-1184.des.2j" then copy the binary output — also in MAME: 136059-1184 atari/gauntlet.cpp:1897, 136059-1184 atari/gauntlet.cpp:1897, 136059-1184 atari/gauntlet.cpp:1897

Ships hardware documentation files — 1

doc/SP-284 Gauntlet schematic.pdf

Cites MAME source — 3

Arcade-Gauntlet.sv:336 Gauntlet I and II - Default MAME Controls Assignment
rtl/gauntlet/ROMS.G1/EEP_14A.vhd:20 signal RAM : RAM_ARRAY:=(others=>(others=>'0')); initialized EEPROM contents dumped from MAME
rtl/gauntlet/TMS5220.vhd:13 References: TMS5220 datasheet, US Patent US4335277 and TMS5220.cpp from MAME source code.

Says it was translated, ported or taken from MAME — 2

rtl/gauntlet/SLAPSTIC.vhd:13 SLAPSTIC 137412-104 GAUNTLET This SLAPSTIC was translated from MAME "slapstic.cpp" source code pretty much verbatim :) The original MAME C++ code is left in as comments
rtl/gauntlet/TMS5220.vhd:15 IMPORTANT NOTES: 1) This implementation does NOT implement the schematic in US4335277 2) It is based primarily on MAME source code and aims to be "functionally equivalent" to the "TMS5220" chip but not identical in terms of electrical circu

Godzilla#
Godzilla
MiSTer-devel/Arcade-Godzilla_MiSTer @ 3cbc8514
MAME compared: seibu/legionna.cpp + 8 related file(s)
Read: 24 HDL files, 10,625 lines (Quartus project)

MiSTer official

Mostly MAME

medium

71%

Statements: 5 toward hardware, 195 toward MAME, 1 not counted

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/Godzilla/Godzilla_maincpu_map.sv:23 Main CPU memory map Godzilla (legionna.cpp legionna_map): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $100000-$1003FF RAM scratch (1KB) → BRAM (Main RAM low) $100400-$1006FF COP3 region → m — also in MAME: 68K seibu/legionna.cpp:46

Reports a measurement taken on the original PCB — 1

rtl/Godzilla/Godzilla_video_timing.sv:26 PCB measurement Blood Bros: VSync 59.4094 Hz, HSync 15.6246 kHz, master XTAL 20 MHz.

Says it was checked on “real hardware” — 4

rtl/Godzilla/Godzilla_cop3.sv:336 0 : 1 (unsigned <320 provato su HW = REGRESSIONE; il signed [-160,320) dell'intento MAME e' il comportamento giusto sul core)
rtl/Godzilla/Godzilla_sprite_renderer.sv:216 byte_lo = pf_rom_data[31:24]/[15:8], byte_hi = [23:16]/[7:0] Plane order DCBA (verificato su HW, come BG/MG/FG): pen[0] dal bit "D" (byte_hi[3-sub]), pen[3] dal bit "A" (byte_lo[7-sub]).
rtl/Godzilla/Godzilla_sprite_renderer.sv:333 Scan INVERSO 511→0 (verificato su HW: ordine sprite-su-sprite opposto al loop MAME 0→511).
rtl/Godzilla/Godzilla_tile_layer.sv:322 Plane order verificato su HW: BG/MG = DCBA (PEN_ORDER=0), FG = BADC (PEN_ORDER=1).

Cites MAME source — 177

Godzilla.sv:208 Offset per-layer Godzilla: MAME visarea parte da (0,0) (set_raw vbend=0, legionna.cpp:1318) e godzilla NON definisce scrolldx/dy per BG/MG/FG ne' sprite offset (nessun set_offset, legionna.cpp:1331) → tutti 0.
Godzilla.sv:213 NB: godzilla ha anche tile_scroll_base_w (legionna_v.cpp:58-65): reg base 7 → text set_scrolldy(0x1ef - data).
Godzilla.sv:328 --- Joystick to SD Gundam input mapping --- MAME P1_P2 port ($E0002): active low.
Godzilla.sv:331 MiSTer joy bits: joy[0]=R, joy[1]=L, joy[2]=D, joy[3]=U, joy[4]=A, joy[5]=B. MAME PLAYERS12 (legionna.cpp:439-444): bit[0]=UP, [1]=DOWN, [2]=LEFT, [3]=RIGHT, [4]=BTN1, [5]=BTN2, [6]=BTN3, [7]=unused (active low).
Godzilla.sv:341 Godzilla SYSTEM port ($10074C) — MAME legionna.cpp:427-436 bit0 = START1 (active LOW) bit1 = START2 (active LOW) bit2..7 = UNKNOWN → tied 1 bit8..15 = UNKNOWN → tied 1 Coin inputs NON sono qui: vanno via SEIBU_COIN_INPUTS → Z80 → soundlatch
Godzilla.sv:695 ── Flip screen (CRTC reg 0x1A bit 0) ─────────────────────────────────────── MAME: BIT(reg_1a, 0) → flip_screen.
Godzilla.sv:741 ── Text layer renderer (8x8, 4bpp, 64x32 grid) ───────────────────────────── Godzilla MAME (ROM_START godzilla): "char" = REGIONE PROPRIA 128KB (11.620/10.615, ROM_LOAD16_BYTE), NON dentro user1 come Legionnaire.
Godzilla.sv:754 Godzilla text scroll-base (CRTC reg 0x3A, hook godzilla-only legionna.cpp:1326).
Godzilla.sv:755 Calibrazione HW di famiglia (dump vregs in seibu_crtc.cpp): Legionnaire reg=0x01FF, visarea da riga 16 → 0x1FF-0x1EF=+16 = ESATTAMENTE il vecchio yoff text +16 del core Legionnaire funzionante; D-Con reg=0xFFEF (low9=0x1EF), visarea da 0 →
Godzilla.sv:759 La formula MAME set_scrolldy(0x1EF-data) è INVERTITA rispetto all'HW (convenzione dy del tilemap.cpp) — mai fidarsi del verso MAME.
Godzilla.sv:797 Godzilla CRTC scroll passthrough (legionna_v.cpp:34-49 tile_scroll_w): scroll_ram[0/1] → BG (m_background_layer) scroll_ram[2/3] → MG (m_midground_layer) scroll_ram[4/5] → FG (m_foreground_layer) Nel nostro CRTC: xscroll_l0 = ram[0/1], xscr
Godzilla.sv:815 Godzilla BG: tilemap 32x32 (legionna_v.cpp:204).
Godzilla.sv:816 MAME GFXDECODE "back" color base = 0 (gfx_legionna riga 1168), 32 colorset.
Godzilla.sv:817 HAS_TRANSP=1 perché m_background_layer->set_transparent_pen(15) in legionna_v.cpp:216 (pen 15 = trasparente, NON opaco come Blood Bros).
Godzilla.sv:839 Godzilla MG: 16x16, 4bpp, 32x32 tilemap (legionna_v.cpp:204).
Godzilla.sv:840 get_mid_tile_info_share_bgrom (legionna_v.cpp:158): MG share BG ROM, tile = (vram & 0xfff) | 0x1000 (= seconda metà della BG ROM) color = ((vram >> 12) & 0xf) | 0x10 (= palette set superiore: bit 4 = 1) In palette MAME "back" base = 0,
Godzilla.sv:867 Godzilla FG: tilemap 32x32 (legionna_v.cpp:213).
Godzilla.sv:869 MAME GFXDECODE "fore" color base = 32*16 = 0x200, 16 colorset.
Godzilla.sv:879 GODZILLA: fore = bg2.619 ROM_LOAD16_WORD_SWAP (legionna.cpp:1987) = IDENTICO alla back bg1.618 → stesso decode DCBA di BG/MG (riscontro HW utente: col BADC il FG era sbagliato).
Godzilla.sv:887 Godzilla: bit 2 = FG (legionna_v.cpp:344)
Godzilla.sv:974 Anticipando di 1 l'indirizzo e il DE, il dato campionato al tick e' quello del pixel CORRENTE: allineamento coi tile ripristinato (= calibrazione +1 pixel-hunting MAME, fatta prima del fix CRT) e colonna 0 coperta.
Godzilla.sv:1008 MAME riferimenti (GODZILLA — diverso da legionna!): legionna_v.cpp:247-251 m_sprite_pri_mask[0..3] per godzilla: pri=0 → 0xFFF0 (copre pri-value 0,1,2 → bg,mg,fg → SOTTO text) pri=1 → 0xFFFC (copre 0,1 → bg,mg → sotto fg,text) pri=2 → 0x
Godzilla.sv:1028 MAME godzilla legionna_v.cpp:382 bitmap.fill(0xff) "matches PCB recording"
Godzilla.sv:1049 Backdrop = palette[0x0FF] reale (MAME godzilla: bitmap.fill(0xff), match PCB).
rtl/Godzilla/Godzilla_audio_z80.sv:25 Spec da MAME (legionna.cpp godzilla machine config :1295-1355): - Z80 @ 14.318180/4 = 3.579545 MHz (seibu_sound_map + godzilla_sound_io_map) - YM2151/OPM (jt51) @ 3.579545 MHz, route ch0+ch1 0.50 su mono - OKI M6295 (jt6295) @ 20MHz/20 = 1.
rtl/Godzilla/Godzilla_audio_z80.sv:57 Godzilla pcm.922 = 512KB: bit 18 = bank (Z80 IO port 0, MAME godzilla_oki_bank_w: set_rom_bank(data&1)).
rtl/Godzilla/Godzilla_audio_z80.sv:364 MAME seibu_sound_device::main_r (seibusound.cpp:279): case 2,3: return sub2main[offset-2] (soundlatch data: coin/input dal Z80) case 5: return main2sub_pending ?
rtl/Godzilla/Godzilla_audio_z80.sv:379 ─── YM2151 (jt51) — GODZILLA usa OPM, non OPL2 (legionna.cpp:1340) ────── Il driver Z80 programma i timer OPM (reg 0x10-0x14): su jtopl2 non scattava mai l'IRQ → RST10 morto → sequencer musica fermo.
rtl/Godzilla/Godzilla_audio_z80.sv:419 MAME: route 0.50+0.50 su mono (legionna.cpp:1342-1343)
rtl/Godzilla/Godzilla_audio_z80.sv:422 ─── OKI bank — GODZILLA: Z80 "OUT (0),A" → banco ROM OKI (512KB = 2×256KB) MAME godzilla_sound_io_map (legionna.cpp:282-286) port 0 → godzilla_oki_bank_w: m_oki->set_rom_bank(data & 1) (write tipica 0x02/0x03).
rtl/Godzilla/Godzilla_audio_z80.sv:434 ─── OKI M6295 (jt6295) — PIN7_HIGH (20MHz/20 = 1.0 MHz, legionna.cpp:1345)
rtl/Godzilla/Godzilla_cop3.sv:4 MAME-faithful implementation of the Seibu SEI300 chip as used by the `legionna` driver (Godzilla 1992 — Banpresto/TAD).
rtl/Godzilla/Godzilla_cop3.sv:7 Reference (in this repo): MAME seibucop.cpp MAME seibucop_cmd.ipp MAME seibucop_dma.ipp MAME legionna.cpp
rtl/Godzilla/Godzilla_cop3.sv:136 MAME cop_itoa_digits[10]: BCD digits of cop_itoa (low<<0 | high<<16).
rtl/Godzilla/Godzilla_cop3.sv:140 Il vecchio loop a sottrazioni ripetute era O(valore) (~valore/9 clk): con i long 32-bit di godzilla (score, writer $156E/$1F93E) il 68k restava congelato (dma_busy include bcd_pending) fino a MILLISECONDI per chiamata — su MAME/HW reale i d
rtl/Godzilla/Godzilla_cop3.sv:153 MAME cop_program command table (seibucop.cpp lines 318-457) At boot, game code uploads 32 macro slots × 8 micro-op words via pgm_addr (0x100434) → slot*8 + sub-index pgm_data (0x100432) → micro-op word pgm_value (0x100438) → cop_func_valu
rtl/Godzilla/Godzilla_cop3.sv:160 MAME calls find_trigger_match(triggerval, 0xff00) to find the slot whose cop_func_trigger matches.
rtl/Godzilla/Godzilla_cop3.sv:256 Triggers (write-only addresses) MAME legionna.cpp:172 maps cop_cmd_w to $100500-$100505 (3 words).
rtl/Godzilla/Godzilla_cop3.sv:330 0x100410 sprite_dma_inc (MAME cop_sprite_dma_inc_w): if x_clip in [-160, 320): cop_regs[4] += 8.
rtl/Godzilla/Godzilla_cop3.sv:331 MA in MAME sprite_x e' uint16_t assegnato a int -> MAI negativo -> il -160 e' codice morto: check EFFETTIVO = unsigned < 320 (X "negative" 0xFFxx NON avanzano il puntatore entry).
rtl/Godzilla/Godzilla_cop3.sv:336 0 : 1 (unsigned <320 provato su HW = REGRESSIONE; il signed [-160,320) dell'intento MAME e' il comportamento giusto sul core)
rtl/Godzilla/Godzilla_cop3.sv:343 A size==0 NON wrappare (il size-- uint di MAME wrapperebbe a $FFFF: il loop del builder su status[1] andrebbe in livelock — provato peggio).
rtl/Godzilla/Godzilla_cop3.sv:378 Macro program upload — MAME seibucop.cpp lines 318-457 pgm_data writes one micro-op word to cop_program[latch_addr] AND latches the slot's trigger/value/mask from current latch regs.
rtl/Godzilla/Godzilla_cop3.sv:479 itoa_digits (MAME 0x100590-99, 5 word).
rtl/Godzilla/Godzilla_cop3.sv:491 Status / dist / angle (seibucop.cpp:916 cop_status_r → cop_status)
rtl/Godzilla/Godzilla_cop3.sv:502 MAME open bus
rtl/Godzilla/Godzilla_cop3.sv:569 commit write al dst ASSOLUTO (fill/mr), 1:1 MAME write_word(dst)
rtl/Godzilla/Godzilla_cop3.sv:605 LEGACY sprite-DMA (seibucop_cmd.ipp): 6880 (carica rel_xy), c480 (single-step: compone l'entry sprite a cop_regs[4]+offs con X/Y = rel + (obj - abs)).
rtl/Godzilla/Godzilla_cop3.sv:629 write angolo (word {0,angle} come MAME host_endian)
rtl/Godzilla/Godzilla_cop3.sv:641 Trigger latches — MAME seibucop.cpp cop_cmd_w line 1069.
rtl/Godzilla/Godzilla_cop3.sv:642 MAME dispatches on raw data after clearing cop_status bit 15.
rtl/Godzilla/Godzilla_cop3.sv:696 DMA mode 0x80-0x87: MAME dma_palette_brightness() fa FADE solo con pal_brightness_mode 4/5; con qualsiasi altro valore fa una COPIA SEMPLICE src->dst (ramo else, seibucop_dma.ipp:119-123) verso QUALUNQUE dst — incl.
rtl/Godzilla/Godzilla_cop3.sv:704 DMA generici 0x09/0x0E: MAME write_word(dst) va nello spazio host = arriva a QUALSIASI RAM mappata, incluse le BRAM video ($101000-$105FFF: staging tilemap, palette-stage $104000, sprite $105000).
rtl/Godzilla/Godzilla_cop3.sv:712 Output del fade/blend 0x8x: MAME dma_palette_brightness fa write_word(dst) nello SPAZIO HOST = raggiunge QUALUNQUE RAM mappata (pal-stage $104000, sprite $105800, Main RAM...).
rtl/Godzilla/Godzilla_cop3.sv:715 Ora: pal_val registrato in D_FADE_WRITE e committato in D_FADE_COMMIT via canale fill (decode per dst assoluto in main_top: bg/fg/mg/txt/pal/spr) o mr (dst in Main RAM) — 1:1 MAME.
rtl/Godzilla/Godzilla_cop3.sv:718 (Il vecchio dma80_to_spr era INVERTITO: il blit pietre e' src=$105800 dst=$104000, non il contrario — MAME map: $100478=SRC, $10047C=DST.)
rtl/Godzilla/Godzilla_cop3.sv:721 LEGACY sprite-DMA state (MAME m_sprite_dma_rel_x/y, m_sprite_dma_x_clip)
rtl/Godzilla/Godzilla_cop3.sv:824 MAME cop_cmd_w (seibucop.cpp:1075):
rtl/Godzilla/Godzilla_cop3.sv:858 find_trigger_match (seibucop.cpp:464) Cerca slot N tale che (trigger & 0xf800) == (cop_func_trigger[N] & 0xf800) && cop_func_trigger[N] != 0.
rtl/Godzilla/Godzilla_cop3.sv:860 Restituisce canonical trigger value del slot (NB: MAME LEGACY_cop_cmd_w usa il match slot per dispatchare; in pratica equivale a restituire cop_func_trigger[slot]).
rtl/Godzilla/Godzilla_cop3.sv:881 fade_table — MAME seibucop.cpp:733 (reverse engineered from Seibu Cup Soccer bootleg) v = pal_channel(5-bit) | (brightness_val_xor_X) [10-bit input] low = v & 0x1F high = v & 0x3E0 return (low * (high | (high>>5)) + 0x210) >> 10 [8-bit o
rtl/Godzilla/Godzilla_cop3.sv:920 ── Hitbox b100/b900 scratch (MAME cop_collision_update_hitbox) ────────────── dx[i] = int8 (signed) byte basso, size[i] = uint8 (unsigned) byte alto del word descrittore @ hitadr2+2*i. 3 assi (Y,X,Z) per Godzilla.
rtl/Godzilla/Godzilla_cop3.sv:927 num_axis: MAME seibucop.cpp:1010 "if (data & 0x100) num_axis = 3" else 2.
rtl/Godzilla/Godzilla_cop3.sv:929 res init 7 vs 3 (seibucop.cpp:1038-39).
rtl/Godzilla/Godzilla_cop3.sv:956 Con 16-bit frac + 24 iter + z>>16: 0 divergenze di decisione vs MAME int(atan(dx/dy)*128/pi) su ~640k casi (dimostrato numericamente).
rtl/Godzilla/Godzilla_cop3.sv:1199 MAME cop_dma_trigger_w: NON modifica cop_status (vedi seibucop.cpp:741).
rtl/Godzilla/Godzilla_cop3.sv:1207 MAME dma_tilemap_buffer: copy staging RAM → renderer BRAM src = cop_dma_src[mode] << 6 (byte addr 0x101000+ = staging) dst = i (loop counter 0..0x13FF = renderer index) count = 0x2800/2 = 5120 words
rtl/Godzilla/Godzilla_cop3.sv:1217 MAME dma_palette_buffer: copy staging palette → renderer src = cop_dma_src[mode] << 6 (0x104000 = palette staging) dst = i (loop counter 0..0x7FF = renderer index) count = 0x1000/2 = 2048 words
rtl/Godzilla/Godzilla_cop3.sv:1227 MAME write_word(dst) su spazio host: con dst nelle BRAM video ($101000-$105FFF: staging/pal/spr, es.
rtl/Godzilla/Godzilla_cop3.sv:1240 simplified, MAME size>>1
rtl/Godzilla/Godzilla_cop3.sv:1245 MAME seibucop_dma.ipp dma_palette_brightness() mode 5/4.
rtl/Godzilla/Godzilla_cop3.sv:1248 MAME formulas: src = cop_dma_src[mode] << 6 dst = cop_dma_dst[mode] << 6 size = ((cop_dma_size << 5) - (cop_dma_dst << 6) + $20)/2 Init: src=$106000, dst=$104000, size=($827F<<5 - $4100<<6 + $20)/2 = ($104FE0 - $104000 + $20)/2 = $1000
rtl/Godzilla/Godzilla_cop3.sv:1259 MAME size = (((size<<5) - (dst<<6) + 0x20)/2)
rtl/Godzilla/Godzilla_cop3.sv:1265 MAME: mode 4/5 = fade palette; QUALSIASI ALTRO = copia semplice src->dst (seibucop_dma.ipp:119-123).
rtl/Godzilla/Godzilla_cop3.sv:1275 MAME seibucop.cpp cop_dma_trigger_w case 0x116 — GODZILLA: fill come 0x118 ma SENZA guard dst!=0 e length bytes = (size+1)<<4 (metà).
rtl/Godzilla/Godzilla_cop3.sv:1277 legionna.cpp:56-61: "The COP-MCU appears to write to the work ram area, otherwise it RESETS in mid-animation of the title screen" → senza questo fill il gioco torna al logo da solo.
rtl/Godzilla/Godzilla_cop3.sv:1288 Skip if dst != 0 (MAME guard, dma.ipp:135)
rtl/Godzilla/Godzilla_cop3.sv:1301 MAME cop_cmd_w (seibucop.cpp:1073): cop_status &= 0x7fff (clear bit 15).
rtl/Godzilla/Godzilla_cop3.sv:1303 MAME: cop_status &= 0x7fff (clear bit 15).
rtl/Godzilla/Godzilla_cop3.sv:1318 MAME LEGACY_cop_cmd_w: find_trigger_match(data, 0xF800) → slot per GRUPPO f800, poi handler dal microcodice caricato.
rtl/Godzilla/Godzilla_cop3.sv:1344 MAME execute_0205: read dword at cop_regs[0]+4+offset*4 (ppos)
rtl/Godzilla/Godzilla_cop3.sv:1365 0x138e / 0x338e — atan(dx/dy) MAME execute_338e.
rtl/Godzilla/Godzilla_cop3.sv:1367 Parte da r1+4 hi (offset 0x0004), come 3BB0/MAME.
rtl/Godzilla/Godzilla_cop3.sv:1375 r1+4 hi (MAME read_dword(r1+4) primo)
rtl/Godzilla/Godzilla_cop3.sv:1390 MAME: raw_angle = cop_read_word(r0+0x34) = host_read_word(0x34^2 = 0x36); amp = cop_read_word(r0+0x36) = host_read_word(0x36^2 = 0x34).
rtl/Godzilla/Godzilla_cop3.sv:1407 0xa180 — collision read pos for slot 0 MAME cop_collision_read_pos: cop_read_word(spradr+N) = host_read_word((spradr+N)^2) per host_endian=true.
rtl/Godzilla/Godzilla_cop3.sv:1428 b000 NON e' un no-op: il dispatcher LEGACY di godzilla (seibucop.cpp:1365) matcha con mask 0xf800, quindi la patch init_godzilla (b100->b000) ESEGUE comunque l'update ma con num_axis=2 (bit8=0 = Z disattivata).
rtl/Godzilla/Godzilla_cop3.sv:1536 Mode 4 (GODZILLA/Denjin, seibucop_dma.ipp:87-117): indice = (val*2)[4:0], val 0x0010/0xFFFF = TARGET PURO, NESSUN bypass bit15.
rtl/Godzilla/Godzilla_cop3.sv:1583 MAME: m_host_space->write_word(dst, pal_val) — dst ASSOLUTO.
rtl/Godzilla/Godzilla_cop3.sv:1617 MAME (0x118 e 0x116): write_dword(i, v1 | v2<<16) su spazio BE 68k → word a i = v2, word a i+2 = v1 (alternati).
rtl/Godzilla/Godzilla_cop3.sv:1630 Macro 0x0205 — linear movement (MAME execute_0205) ppos = read_dword(cop_regs[0]+0x04) vel = read_dword(cop_regs[0]+0x10) npos = ppos + vel write_dword(cop_regs[0]+0x04, npos) delta = (npos>>16) - (ppos>>16) write_word(cop_regs[0]+0x1E, re
rtl/Godzilla/Godzilla_cop3.sv:1673 MAME cop_read/write_word(cop_regs[0]+0x1e) = host word @ (0x1e^2)=0x1c (host endianness word^2; conferma doc 06 micro-op 'addmem16 0x1C(r0)').
rtl/Godzilla/Godzilla_cop3.sv:1691 Macro 0x0905/0x0904 — jump (MAME execute_0904) write_dword(cop_regs[0]+0x10, read_dword(cop_regs[0]+0x10) ± read_dword(cop_regs[0]+0x28)) 0x0905 (bit 0=1) = +, 0x0904 (bit 0=0) = -
rtl/Godzilla/Godzilla_cop3.sv:1717 MAME execute_0904: bit 0 di data = 1 → add, =0 → sub tmp32_a = vel ± grav.
rtl/Godzilla/Godzilla_cop3.sv:1748 0x138E/0x338E atan(dx/dy) — MAME execute_338e (cmd.ipp:159) dx = read_dword(r1+4) - read_dword(r0+4) dy = read_dword(r1+8) - read_dword(r0+8) if(!dy){status|=0x8000; angle=0} else angle=atan(dx/dy)*128/pi; dy<0→+0x80 if(data&0x80) write_byt
rtl/Godzilla/Godzilla_cop3.sv:1796 MAME: angle = atan(dx/dy)*128/pi (+0x80 se dy<0).
rtl/Godzilla/Godzilla_cop3.sv:1798 Cosi' z = atan(dx/dy) e il +0x80 (in WR) copre solo il quadrante, come MAME.
rtl/Godzilla/Godzilla_cop3.sv:1800 NIENTE prescale: i dword diff sono FIXED-POINT coord<<16 (come il 3BB0 che usa dx32[31:16] e MAME dx>>16), NON interi piccoli.
rtl/Godzilla/Godzilla_cop3.sv:1841 MAME (int)(...) tronca VERSO ZERO.
rtl/Godzilla/Godzilla_cop3.sv:1843 BUG TROVATO (validato vs MAME su 29241 casi): il CORDIC SOTTO-CONVERGE di 1 LSB sulle DIAGONALI (es.
rtl/Godzilla/Godzilla_cop3.sv:1848 Compenso l'epsilon di sotto-convergenza con +1 toward-zero PRIMA del troncamento: bias=1 azzera tutte le 133 divergenze (bias=0) -> 0/29241 vs MAME.
rtl/Godzilla/Godzilla_cop3.sv:1857 MAME execute_338e (seibucop_cmd.ipp:175-188): la write dell'angolo in RAM (obj+0x34 host, gated da data&0x80) e' FUORI dall'if/else di dy -> avviene SEMPRE, anche a dy==0 (dove cop_angle=0 -> scrive 0^0x80 = 0x80).
rtl/Godzilla/Godzilla_cop3.sv:1863 Ora calcolo ang_byte in entrambi i rami e scrivo SEMPRE, come MAME.
rtl/Godzilla/Godzilla_cop3.sv:1870 Scrivere l'angolo anche a dy==0 ("1:1 MAME") REGREDISCE: il martello scivola/moonwalk.
rtl/Godzilla/Godzilla_cop3.sv:1873 MAME: dy==0 -> cop_angle=0
rtl/Godzilla/Godzilla_cop3.sv:1896 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197) dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (aritmetico) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = sqrt(dx*dx + dy*dy) if(data&0x80) write_word(r0 + (data&0x200?0x3a:0x38
rtl/Godzilla/Godzilla_cop3.sv:2005 (Il fix MAME-aligned 0x3a:0x38 faceva fuggire i nemici -> MAME invertito vs HW.
rtl/Godzilla/Godzilla_cop3.sv:2012 MAME: macro completata → cop_status = 7 (gate-poll del gioco).
rtl/Godzilla/Godzilla_cop3.sv:2098 0x8100/0x8900 sin/cos (MAME execute_8100/8900) raw_angle = cop_read_word(cop_regs[0]+0x34) & 0xff amp = (65536>>5) * (cop_read_word(cop_regs[0]+0x36) & 0xff) = 2048 * amp_byte if (raw_angle == 0xC0 sin / 0x80 cos): amp *= 2 res = int(
rtl/Godzilla/Godzilla_cop3.sv:2137 MAME special-case: sin && raw==0xC0 OR cos && raw==0x80 → amp *= 2
rtl/Godzilla/Godzilla_cop3.sv:2183 0xa180/0xa980 — read pos (MAME cop_collision_read_pos) flags_swap = cop_read_word(spradr+2) → host_read_word(spradr+0) pos[0] = cop_read_word(spradr+6) → host_read_word(spradr+4) pos[1] = cop_read_word(spradr+10) → host_read_word(
rtl/Godzilla/Godzilla_cop3.sv:2190 Però MAME cop_read_word(+2) = host_read_word(+2^2) = host_read_word(+0).
rtl/Godzilla/Godzilla_cop3.sv:2201 rdata = word @ host+0 = flags (MAME cop_read_word(spradr+2) ^ 2).
rtl/Godzilla/Godzilla_cop3.sv:2210 rdata = word @ host+4 = pos[0] (Y axis per MAME)
rtl/Godzilla/Godzilla_cop3.sv:2230 0xb100/0xb900 — update hitbox & compute intersection (1:1 MAME cop_collision_update_hitbox, seibucop.cpp:1003-1065).
rtl/Godzilla/Godzilla_cop3.sv:2277 2 assi (b000/b800): terza word NON letta, dx/size azzerati (seibucop.cpp:1014-1022)
rtl/Godzilla/Godzilla_cop3.sv:2316 2 assi: l'asse 2 (Z) NON viene aggiornato (loop MAME i<num_axis)
rtl/Godzilla/Godzilla_cop3.sv:2335 res init: 3 assi = 111, 2 assi = 011 (seibucop.cpp:1038-39: bit Z gia' 0 = "collide banale" -> hit deciso solo da X/Y)
rtl/Godzilla/Godzilla_cop3.sv:2359 LEGACY 6880 — carica rel_xy per il prossimo c480 (MAME LEGACY_execute_6980: rel_xy = read_word(spr_src+4+offs))
rtl/Godzilla/Godzilla_cop3.sv:2372 LEGACY c480 — single-step sprite DMA (MAME LEGACY_execute_c480): info = read(spr_src+offs) + (param & 0x3f) -> entry+0 abs = read(regs[0]+8/+4) - spr_dma_abs_x/y X(fx/dx/rel_x) -> entry+4 (+ x_clip per l'inc $410) Y(fy/rel_y) -> entry+6
rtl/Godzilla/Godzilla_cop3.sv:2478 6200 — rotate-towards (MAME execute_6200, variante grainbow che godzilla CARICA nella tabella): angle(obj host+0x37) ruota verso cop_angle_target di cop_angle_step; flags(host+2) bit2=raggiunto.
rtl/Godzilla/Godzilla_cop3.sv:2481 Dominio angolo: il nostro 138e scrive in RAM plain^0x80 (is_yflip) -> lavoro nel dominio stored con target^0x80: il DELTA e' rotazione-invariante => matematica IDENTICA a MAME.
rtl/Godzilla/Godzilla_cop3.sv:2484 Write angolo = WORD {0,angle} (MAME host_endian write-word).
rtl/Godzilla/Godzilla_cop3.sv:2505 wrap a signed 8-bit (MAME: +=/-=256 su int)
rtl/Godzilla/Godzilla_main_top.sv:213 VBLANK IRQ4 — MAME legionna.cpp: m_maincpu->set_vblank_int(irq4_line_hold) MAME HOLD_LINE: IRQ asserted on edge, released ONLY at IACK (= when CPU fetches vector).
rtl/Godzilla/Godzilla_main_top.sv:218 VBLANK IRQ4 — MAME legionna.cpp: m_maincpu->set_vblank_int(irq4_line_hold) MAME HOLD_LINE: IRQ asserted on edge, released ONLY at IACK (= when CPU fetches vector).
rtl/Godzilla/Godzilla_main_top.sv:473 COP3 cmd 0x14 dma_tilemap_buffer (legionna_v.cpp:86 videowrite_cb_w): offset 0x000..0x3FF → BG (back_data) offset 0x400..0x7FF → FG (fore_data) offset 0x800..0xBFF → MG (mid_data) offset 0xC00..0x13FF → Text (textram, 0x800 word) SRC
rtl/Godzilla/Godzilla_main_top.sv:497 Il fill scrive le BRAM STAGING (= la host RAM di MAME): il per-frame DMA 0x14/0x15 le propaga al renderer.
rtl/Godzilla/Godzilla_main_top.sv:510 ── SPLIT STAGING vs RENDERER (semantica MAME 2-stadi, come la palette) ───── MAME godzilla: $101000-$103FFF e' .ram() PURO (handler background_w/… COMMENTATI nel map, legionna.cpp) — le scritture CPU NON toccano i tilemap.
rtl/Godzilla/Godzilla_main_top.sv:513 I tilemap leggono m_back/fore/mid_data/m_textram = buffer SEPARATI (make_unique_clear, legionna_v.cpp) scritti SOLO da videowrite_cb_w = DMA 0x14.
rtl/Godzilla/Godzilla_main_top.sv:518 u_XX_ram = STAGING: porta A = CPU (+fill 0x116/0x118, come MAME che filla la host RAM), porta B = sorgente del DMA 0x14.
rtl/Godzilla/Godzilla_main_top.sv:521 Coppia contenuto/scroll = atomica a livello ISR, come MAME.
rtl/Godzilla/Godzilla_main_top.sv:593 ── Palette: split STAGING ($104000) vs RENDERER (semantica MAME 2-stadi) ─── MAME: la CPU e il fade (cmd 0x80) scrivono la STAGING RAM a $104000.
rtl/Godzilla/Godzilla_main_top.sv:617 MAME godzilla: $104000 e' RAM pura (legionna.cpp:262, handler palette commentato) — la palette VISIBILE si aggiorna SOLO via paletteramout_cb = dma_palette_buffer 0x15 (seibucop_dma.ipp:27); il fade DMA scrive lo STAGING (host RAM, dma.ipp:
rtl/Godzilla/Godzilla_maincpu_map.sv:23 Main CPU memory map Godzilla (legionna.cpp legionna_map): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $100000-$1003FF RAM scratch (1KB) → BRAM (Main RAM low) $100400-$1006FF COP3 region → m
rtl/Godzilla/Godzilla_maincpu_map.sv:129 Text VRAM: $102800-$1037FF = 4KB = 2048 word (MAME common_video_allocate_ptr alloca textram a 0x1000/2 word, videowrite_cb_w smista offset < 0x2800/2).
rtl/Godzilla/Godzilla_maincpu_map.sv:139 godzilla_map (legionna.cpp:257): 0x100800-0x100FFF .ram() — SOLO godzilla, legionna non ce l'ha (buco ereditato dal porting).
rtl/Godzilla/Godzilla_maincpu_map.sv:215 MAME legionna_map: main_r/main_w(offset>>1) con umask16(0x00ff).
rtl/Godzilla/Godzilla_maincpu_map.sv:219 Vedi seibusound.cpp main_r/main_w.
rtl/Godzilla/Godzilla_maincpu_map.sv:226 MAME godzilla_setgfxbank: (data&0x4000)>>2
rtl/Godzilla/Godzilla_maincpu_map.sv:267 ─── init_godzilla (legionna.cpp:2624-2634) ───────────────── Kludge Z-axis collisioni (seibucop.cpp:52-54: "Super X missiles, Tokyo's tower ...
rtl/Godzilla/Godzilla_maincpu_map.sv:322 Replica la latenza-zero-osservabile di MAME (cop_cmd_w sincrono): il gioco legge cop_hit_val_stat/cop_angle ($188/$1b4) nell'istruzione dopo il trigger.
rtl/Godzilla/Godzilla_palette.sv:25 MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 128*16); (legionna.cpp:1212, 128*16 = 2048 entry) Address space CPU: 0x104000..0x104FFF (4 KB = 2048 word).
rtl/Godzilla/Godzilla_palette.sv:35 Espansione 5→8 standard MAME palette_device: {val5, val5[4:2]} (bit replication che riempie i 3 LSB con i 3 MSB del valore 5-bit).
rtl/Godzilla/Godzilla_palette.sv:85 Godzilla: xBGR_555 → RGB888 (legionna.cpp:1212) Layout: bit[4:0]=R, bit[9:5]=G, bit[14:10]=B. 5 bit per canale.
rtl/Godzilla/Godzilla_palette.sv:87 Espansione 5→8 standard MAME palette_device: {val5, val5[4:2]} (replica i 3 MSB nei 3 LSB → range 0..255 con monotonia preservata).
rtl/Godzilla/Godzilla_seibu_crtc.sv:23 Seibu CRTC fedele a MAME (seibu_crtc.cpp).
rtl/Godzilla/Godzilla_seibu_crtc.sv:120 MAME mappa: bit0=screen0(BG), bit1=screen2(MG), bit2=screen1(FG), bit3=screen3(Text) (vedi seibu_crtc.cpp commento "screen 0=BG, screen 1=FG, screen 2=MG, screen 3=Text") In SD Gundam dcon.cpp layer_en_w gira la maschera così: ~layer_en bit
rtl/Godzilla/Godzilla_seibu_crtc.sv:129 Il dispatcher MAME usa "if (BIT(~m_layer_en, n))" per saltare = layer disabilitato quando il bit è 1.
rtl/Godzilla/Godzilla_seibu_crtc.sv:134 Godzilla layer ordering (legionna_v.cpp:384-390 screen_update_GODZILLA): bit 0 = BG (background) bit 1 = MG (midground) bit 2 = FG (foreground) bit 3 = Text bit 4 = Sprites ATTENZIONE: e' l'OPPOSTO di legionna (screen_update_legionna :342-3
rtl/Godzilla/Godzilla_seibu_crtc.sv:155 Scroll-base Screen3(text) Y = reg 0x3A (blocco layer_scroll_base 0x2C-0x3B, offset word 7 — MAME seibu_crtc.cpp:243 + legionna_v.cpp:58-65 godzilla-only: text set_scrolldy(0x1ef - data).
rtl/Godzilla/Godzilla_sprite_renderer.sv:25 Formato spriteram quasi identico (entrambi MAME sei021x_sei0220_spr.cpp) — differenze: - Spriteram @ 0x105000-0x105FFF (4KB, 1024 word, 256 entry × 4 word) - w3 bit 15 = tile bank extra bit (denjinmk usa, Godzilla base = 0)
rtl/Godzilla/Godzilla_sprite_renderer.sv:30 Format word (legionna_v.cpp:288-312): w0 bit 15 = enable (0=draw, 1=skip — TODO verify Godzilla) w0 bit 14 = flip_x w0 bit 13 = flip_y (???
rtl/Godzilla/Godzilla_sprite_renderer.sv:46 Priority callback legionna_v.cpp:314-317: pri_mask[0] = 0x0000 (sopra tutto) pri_mask[1] = 0xFFF0 pri_mask[2] = 0xFFFC pri_mask[3] = 0xFFFE
rtl/Godzilla/Godzilla_sprite_renderer.sv:140 0..511 (MAME size/2/4 = 4096/2/4 = 512)
rtl/Godzilla/Godzilla_sprite_renderer.sv:145 Decoded fields — MAME sei0210_device::draw (non-alt format, riga 143): if (BIT(~spriteram[i], 15)) continue; → draw quando w0[15]==1.
rtl/Godzilla/Godzilla_sprite_renderer.sv:165 MAME SEI0211 default m_xoffset/m_yoffset = 0 (sei021x_sei0220_spr.cpp:40-41).
rtl/Godzilla/Godzilla_sprite_renderer.sv:166 Godzilla NON chiama set_offset (legionna.cpp:1214) → offset 0,0.
rtl/Godzilla/Godzilla_sprite_renderer.sv:198 Tile code finale Y-MAJOR (MAME draw_internal: ax=outer, ay=inner, code++): sub_index = ax*sizey + ay → cur_tile = code + eff_tile_x*sp_h + eff_tile_y Banking godzilla_tile_cb (legionna_v.cpp:327-334): ext→|0x4000, y→|0x8000, applicato PRI
rtl/Godzilla/Godzilla_sprite_renderer.sv:538 MAME gfx_legionna_spr: color base = 64*16 = 0x400 (64 colorset × 16 pen).
rtl/Godzilla/Godzilla_text_renderer.sv:25 Specifiche da MAME (legionna.cpp:1117-1126, 1167):
rtl/Godzilla/Godzilla_text_renderer.sv:47 Char ROM in MAME: "char" region 64KB = ROM_COPY user1[0x10000..0x1FFFF].
rtl/Godzilla/Godzilla_text_renderer.sv:140 MAME `legionna_v.cpp:214`: text tilemap = 64×32 (8x8 tiles, TILEMAP_SCAN_ROWS).
rtl/Godzilla/Godzilla_text_renderer.sv:186 --- Stage 3: pen decode (charlayout planes packed in nibbles) --- Per col c (0..3 dentro la half-tile), bit position = 3 - c. pen[0] = word[bit_pos + 0] (plane 0) pen[1] = word[bit_pos + 4] (plane 1) pen[2] = word[bit_pos + 8] (plane
rtl/Godzilla/Godzilla_text_renderer.sv:192 MAME readbit usa MSB-first: bit_offs N → byte[N/8] bit (7-N%8).
rtl/Godzilla/Godzilla_text_renderer.sv:193 In Verilog word concat (lo=byte0[7:0], hi=byte1[7:0]) → MAME pos N = word[(7-N%8) + (N>=8?8:0)].
rtl/Godzilla/Godzilla_text_renderer.sv:210 MAME GFXDECODE char: color base = 48*16 = 0x300 (16 colorset × 16 pen).
rtl/Godzilla/Godzilla_tile_layer.sv:25 Differenze fra layer (da MAME dcon.cpp):
rtl/Godzilla/Godzilla_tile_layer.sv:58 BB FG hardcoded +0x1000 (MAME bloodbro fg_tile_info)
rtl/Godzilla/Godzilla_tile_layer.sv:221 Tile index con eventuale gfx_bank (MG ha bit 12 = 13-bit totali, BG/FG = 12 bit) + TILE_CODE_OFS hardcoded (BB FG aggiunge 0x1000 secondo MAME bloodbro fg_tile_info).
rtl/Godzilla/Godzilla_video_timing.sv:35 Active area da MAME (sdgndmps_map): visarea 0..40*8-1, 2*8..30*8-1 quindi 320×224, V offset = 16 (top blank).
rtl/Godzilla/Godzilla_video_timing.sv:60 ── Pixel clock enable: 96 MHz / 14 = 6.857 MHz ───────────────────────── Godzilla reale (legionna.cpp:1318 set_raw): pclk 14.318180/2 = 7.15909 MHz.
rtl/Godzilla/Godzilla_video_timing.sv:78 ── Constants timing ───────────────────────────────────────────────────── Godzilla REALE (legionna.cpp:1318): set_raw(14318180/2, 455, 0, 320, 258, 0, 224) = 320x224, HTotal 455 @7.159MHz = 15.734 kHz, VTotal 258 → 60.985 Hz.
rtl/Godzilla/sdram_bridge.sv:308 --- FG address descramble (legionna.cpp:1129 descramble_legionnaire_gfx) --- MAME applica un bitswap<24> agli indirizzi della ROM "fore" durante init: src_descrambled[i] = src_raw[bitswap<24>(i, ...
rtl/Godzilla/sdram_bridge.sv:355 bitswap MAME del byte offset
README.md:6 Godzilla is a licensed Toho kaiju action game running on the **Seibu `legionna.cpp` hardware family** — an M68000 board with a Seibu CRTC, the SEI252 sprite chi
README.md:12 This core reimplements the hardware in SystemVerilog from MAME references (`seibu/legionna.cpp`, `seibu/legionna_v.cpp`, `seibu/seibu_crtc.cpp`, `seibu/seibucop

Says it matches, follows or was checked against MAME — 6

Godzilla.sv:222 -1 = sprite 1px a OVEST (sinistra), match MAME su HW
Godzilla.sv:252 NB: gli offset per-layer (ex P5) sono HARDCODATI (osd_*_xoff/yoff costanti, match pixel-perfect MAME).
rtl/Godzilla/Godzilla_cop3.sv:1313 LEGACY sprite-DMA (match a maschera, MAME find_trigger_match): c480 mask $FF00 -> qualunque c4xx; 6880 mask $FFF3.
rtl/Godzilla/Godzilla_cop3.sv:2152 res = prod >> 4 (= /16 per matchare formula MAME 2048/32768 = 1/16)
rtl/Godzilla/Godzilla_sprite_renderer.sv:167 +1 pixel a destra: offset verificato con pixel hunting su MAME (rmonic79).
rtl/Godzilla/Godzilla_sprite_renderer.sv:333 Scan INVERSO 511→0 (verificato su HW: ordine sprite-su-sprite opposto al loop MAME 0→511).

Says it was translated, ported or taken from MAME — 2

rtl/Godzilla/Godzilla_cop3.sv:1904 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197): 1:1 dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (signed) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = floor(sqrt(dx*dx + dy*dy)) if(data&0x80) write_word(r0+(data&0x200?0x3
rtl/Godzilla/Godzilla_cop3.sv:2021 0x42C2/0x4AA0 divide — MAME execute_42c2/4aa0 (cmd.ipp:219/247): 1:1 DIVIDEND = cop_dist << (5 - cop_scale) (cop_scale 0..3 → shift 5..2) 42c2: div=cop_read_word(r0+0x36)→host 0x34; if(!div){status|=0x8000; write 0 a host 0x3a} else write

Shares text with the MAME driver without saying so — 10

Godzilla.sv:817 HAS_TRANSP=1 perché m_background_layer->set_transparent_pen(15) in — shares text with seibu/legionna_v.cpp:216
Godzilla.sv:840 get_mid_tile_info_share_bgrom (legionna_v.cpp:158): MG share BG ROM, — shares text with seibu/legionna.h:80
rtl/Godzilla/Godzilla_audio_z80.sv:424 godzilla_oki_bank_w: m_oki->set_rom_bank(data & 1) (write tipica 0x02/0x03). — shares text with seibu/legionna.cpp:277
rtl/Godzilla/Godzilla_maincpu_map.sv:269 Tokyo's tower ... Z axis check makes no sense"): le 2 call-site — shares text with seibu/seibucop.cpp:54
rtl/Godzilla/Godzilla_palette.sv:23 Palette RAM Seibu Godzilla (xBGR_555, 2048 entries). MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 128*16); (legionna.cpp — shares text with seibu/legionna.cpp:1212
rtl/Godzilla/Godzilla_sprite_renderer.sv:146 if (BIT(~spriteram[i], 15)) continue; → draw quando w0[15]==1. — shares text with seibu/sei021x_sei0220_spr.cpp:128
rtl/Godzilla/Godzilla_text_renderer.sv:23 Text layer renderer Seibu Godzilla (8x8, 4bpp, 64x32). Specifiche da MAME (legionna.cpp:1117-1126, 1167): // charlayout 8x8, RGN_FRAC(1,1), 4 — shares text with seibu/legionna.cpp
rtl/Godzilla/Godzilla_video_timing.sv:23 Video timing single-screen Seibu D-Con. SD Gundam Psycho Salamander gira su Seibu D-Con (PB91008), stessa famiglia di Blood Bros (1990). PCB measuremen — shares text with seibu/legionna.cpp
rtl/Godzilla/Godzilla_video_timing.sv:79 Godzilla REALE (legionna.cpp:1318): set_raw(14318180/2, 455, 0, — shares text with seibu/legionna.cpp:1318
rtl/Godzilla/sdram_bridge.sv:310 src_descrambled[i] = src_raw[bitswap<24>(i, ... 6,5,15,14,13,12, 11,10,9,8, 7,4, 3..0)] — shares text with seibu/legionna.cpp:1141

Guardians#
Guardians / Denjin Makai II
MiSTer-devel/Arcade-Guardians_MiSTer @ 68eaafee (matched by date)
MAME compared: seta/seta2.cpp
Read: 23 HDL files, 6,682 lines (Quartus project)

MiSTer official

Mostly MAME

low

39%

Statements: 9 toward MAME

Cites MAME source — 7

rtl/gd_cpu_subsystem.sv:351 MAME bit order: left, right, up, down, B1, B2, B3, start.
rtl/gd_dx101_video.sv:7 Format and drawing rules are derived from MAME's BSD-licensed device model by Luca Elia and David Haywood.
rtl/gd_dx101_video.sv:709 MAME's STEP8(0,1) plane offsets and STEP8(7*8,-8) X offsets mean that source byte 7 supplies pen bit 7, byte 6 supplies bit 6, ...
rtl/gd_tmp68301.sv:2 Behaviour follows MAME's BSD-licensed TMP68301 device model.
rtl/gd_tmp68301.sv:165 The MAME device treats an asserted input as the active state for level mode and its rising transition as the event for edge mode.
rtl/gd_video_timing.sv:22 MAME deliberately substitutes 512x256 at exactly 60 Hz; use the programmed board timing here for correct native analog RGB: approximately 15.244 kHz horizontal and 59.085 Hz vertical.
rtl/gd_x1_010.sv:2 Register layout, rate and phase arithmetic follow MAME's BSD-licensed x1_010 device model.

Says it matches, follows or was checked against MAME — 2

rtl/gd_sprite_ram.sv:117 Bound the private table and synthesize one in its last slot, matching the finite hardware/MAME scan.
rtl/gd_x1_010.sv:87 A factor of two gives the hardware mix headroom and matches MAME closely without a large divider.

GulfWarII#
Gulf War II
MiSTer-devel/Arcade-GulfWarII_MiSTer @ 5b12749a
MAME compared: toaplan/twincobr.cpp + 8 related file(s)
Read: 20 HDL files, 5,167 lines (Quartus project)

MiSTer official

Mostly MAME

low

54%

Statements: 1 toward hardware, 12 toward MAME

Cites hardware documentation that MAME's driver does not — 1

Arcade-GulfWarII.sv:694 from outzone schematic

Cites MAME source — 8

Arcade-GulfWarII.sv:442 total 446, ~54.9 Hz native/MAME raster
Arcade-GulfWarII.sv:501 MAME only inverts Gulf War II's readable VBLANK input bit.
Arcade-GulfWarII.sv:1439 MAME flips only the tilemaps from the main latch.
Arcade-GulfWarII.sv:1528 SCU sprite RAM writes use the MAME 0x040000-0x040fff map.
Arcade-GulfWarII.sv:1683 MAME's tilemap core positions maps at dx-scroll/dy-scroll, so sampling
Arcade-GulfWarII.sv:1724 MAME's Toaplan SCU consumes sprite RAM as native 16-bit words.
rtl/gulfwar2/gulfwar2_palette_ram.sv:59 MAME models this RAM as xBGR_555: bit 15 unused, then B/G/R.
README.md:26 Behavioral reference: MAME's Toaplan driver behavior for Gulf War II, `toaplan_dsp.cpp`, and shared Toaplan video devices.

Says it matches, follows or was checked against MAME — 2

Arcade-GulfWarII.sv:1457 Match MAME's toaplan_dsp_device: DSP INT enable unhalts the DSP and halts the 68K; disable halts the DSP but does not itself release the 68K.
README.md:6 IT HAS BEEN EXTENSIVELY TESTED AND MATCHED TO MAME BEHAVIOR (TO THE BEST OF MY ABILITY)**

Says it was translated, ported or taken from MAME — 2

README.md:5 **THIS IS A VIBE CODED CORE BASED ON MAME AND ERIN OLAFSON'S [EXCELLENT TOAPLAN MiSTer FRAMEWORK](https://github.com/va7deo/).
README.md:28 ROM definitions and MRAs: based on MAME 0.287 set definitions.

Gyruss#
Gyruss
MiSTer-devel/Arcade-Gyruss_MiSTer @ 50646883
MAME compared: konami/gyruss.cpp + 3 related file(s)
Read: 16 HDL files, 8,213 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 1 toward hardware

Cites hardware documentation that MAME's driver does not — 1

rtl/Gyruss_SND.sv:563 Two of Gyruss's AY-3-8910s contain selectable low-pass filters with the following cutoff frequencies: 3386.28Hz, 723.43Hz, 596.09Hz Model this here (the PCB handles this via 3 74HC4066 switching ICs located at 9E, 9F and 10F)

HeatedBarrel#
Heated Barrel
MiSTer-devel/Arcade-HeatedBarrel_MiSTer @ 6a878e4f
MAME compared: seibu/legionna.cpp + 8 related file(s)
Read: 23 HDL files, 9,301 lines (Quartus project)

MiSTer official

Mostly MAME

medium

74%

Statements: 4 toward hardware, 153 toward MAME, 1 not counted

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/HeatedBarrel/HeatedBarrel_maincpu_map.sv:23 Main CPU memory map HeatedBarrel (MAME legionna.cpp legionna_map): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $100000-$1003FF RAM scratch (1KB) → BRAM (Main RAM low) $100400-$1006FF COP3 region — also in MAME: 68K seibu/legionna.cpp:46

Reports a measurement taken on the original PCB — 1

rtl/HeatedBarrel/HeatedBarrel_video_timing.sv:25 PCB measurement: VSync 59.4094 Hz, HSync 15.6246 kHz.

Says it was checked on “real hardware” — 3

rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:208 byte_lo = pf_rom_data[31:24]/[15:8], byte_hi = [23:16]/[7:0] Plane order DCBA (verificato su HW, come BG/MG/FG): pen[0] dal bit "D" (byte_hi[3-sub]), pen[3] dal bit "A" (byte_lo[7-sub]).
rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:325 Scan INVERSO 511→0 (verificato su HW: ordine sprite-su-sprite opposto al loop MAME 0→511).
rtl/HeatedBarrel/HeatedBarrel_tile_layer.sv:297 Plane order verificato su HW: BG/MG = DCBA (PEN_ORDER=0), FG = BADC (PEN_ORDER=1).

Cites MAME source — 138

HeatedBarrel.sv:218 SPR X=0 Y=-16 TXT X=-1 Y=+16 ── OFFSET PER-LAYER esposti nell'OSD (calibrazione 1:1 con MAME) ────────────── Azzerati gli hardcoded di Legionnaire/224.
HeatedBarrel.sv:221 Calibrare uno a uno confrontando con MAME, Offset per-layer HARDCODATI (calibrati su HW confronto MAME, pagina OSD Calibration rimossa).
HeatedBarrel.sv:337 --- Joystick input mapping --- MAME P1_P2 port ($E0002): active low.
HeatedBarrel.sv:340 MiSTer joy bits: joy[0]=R, joy[1]=L, joy[2]=D, joy[3]=U, joy[4]=A, joy[5]=B. MAME PLAYERS12 (legionna.cpp:439-444): bit[0]=UP, [1]=DOWN, [2]=LEFT, [3]=RIGHT, [4]=BTN1, [5]=BTN2, [6]=BTN3, [7]=unused (active low).
HeatedBarrel.sv:345 Corretto invertendo i 4 bit.) bit6/7 = UNKNOWN in MAME PLAYERS12 heatbrl -> tied 1 (no input fantasma; joy[6] attivo metterebbe bit6=0 = "premuto" -> trigger display DIP al power-on).
HeatedBarrel.sv:357 Heated Barrel SYSTEM port ($10074C) — MAME heatbrl (4 player): bit0=START1, bit1=START2, bit3=COIN3, bit4=START3, bit5=START4, bit7=COIN4 (active LOW)
HeatedBarrel.sv:702 ── Flip screen (CRTC reg 0x1A bit 0) ─────────────────────────────────────── MAME: BIT(reg_1a, 0) → flip_screen.
HeatedBarrel.sv:747 Blood Bros Text: no scroll (MAME bloodbro.cpp non chiama set_scroll su tx_tilemap)
HeatedBarrel.sv:781 HeatedBarrel CRTC scroll passthrough (MAME legionna_v.cpp:34-49 tile_scroll_w): scroll_ram[0/1] → BG (m_background_layer) scroll_ram[2/3] → MG (m_midground_layer) scroll_ram[4/5] → FG (m_foreground_layer) Nel nostro CRTC: xscroll_l0 = ram[0
HeatedBarrel.sv:799 HeatedBarrel BG: tilemap 32x32 (legionna_v.cpp:204).
HeatedBarrel.sv:800 MAME GFXDECODE "back" color base = 0 (gfx_legionna riga 1168), 32 colorset.
HeatedBarrel.sv:801 HAS_TRANSP=1 perché m_background_layer->set_transparent_pen(15) in legionna_v.cpp:216 (pen 15 = trasparente, NON opaco come Blood Bros).
HeatedBarrel.sv:824 MAME gfx_heatbrl: "mid" ha ROM INDIPENDENTE (get_mid_tile_info_split): tile = (vram & 0xfff) [offset 0, NO +0x1000], color = (vram >> 12) & 0xf.
HeatedBarrel.sv:848 HeatedBarrel FG: tilemap 32x32 (legionna_v.cpp:213).
HeatedBarrel.sv:850 MAME GFXDECODE "fore" color base = 32*16 = 0x200, 16 colorset.
HeatedBarrel.sv:864 HeatedBarrel: bit 2 = FG (MAME legionna_v.cpp:344)
HeatedBarrel.sv:973 MAME riferimenti: legionna_v.cpp:226-229 m_sprite_pri_mask[0..3] per HeatedBarrel: pri=0 → 0x0000 (cover bit 0,1,2,4 → mg,bg,fg,text → SOPRA TUTTO) pri=1 → 0xFFF0 (cover bit 0,1,2 → mg,bg,fg → sotto text) pri=2 → 0xFFFC (cover bit 0,1 →
HeatedBarrel.sv:994 pen 0 (= nero su palette MAME BLACK init)
HeatedBarrel.sv:1000 MAME legionna_v.cpp:340 fills bitmap with m_palette->black_pen() before drawing layers.
HeatedBarrel.sv:1022 MAME legionna_v.cpp:340 fa bitmap.fill(black_pen()) prima dei layer.
rtl/HeatedBarrel/HeatedBarrel_audio_z80.sv:25 Spec da MAME (reference/mame_seibu/seibusound.cpp + bloodbro.cpp): - Z80 @ 3.579545 MHz (XTAL 7.159090 / 2) - YM3812 (jtopl2) @ 3.579545 MHz - OKI M6295 (jt6295) @ 1.000 MHz (XTAL 12/12), PIN7=HIGH
rtl/HeatedBarrel/HeatedBarrel_audio_z80.sv:31 Main↔sub comm @ 0xA0000-0xA000D: standard MAME seibu_sound_device.
rtl/HeatedBarrel/HeatedBarrel_audio_z80.sv:359 MAME seibu_sound_device::main_r (reference/mame_seibu/seibusound.cpp:279): case 2,3: return sub2main[offset-2] (soundlatch data: coin/input dal Z80) case 5: return main2sub_pending ?
rtl/HeatedBarrel/HeatedBarrel_audio_z80.sv:392 ─── OKI M6295 (jt6295) — PIN7_HIGH (bloodbro.cpp:872) ──────────────────
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:4 MAME-faithful implementation of the Seibu SEI300 chip as used by the `legionna` driver (HeatedBarrel 1992 — Banpresto/TAD).
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:7 Reference (in this repo): reference/mame_seibu/seibucop.cpp reference/mame_seibu/seibucop_cmd.ipp reference/mame_seibu/seibucop_dma.ipp reference/mame_seibu/legionna.cpp
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:134 MAME cop_itoa_digits[10]: BCD digits of cop_itoa (low<<0 | high<<16).
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:144 MAME cop_program command table (seibucop.cpp lines 318-457) At boot, game code uploads 32 macro slots × 8 micro-op words via pgm_addr (0x100434) → slot*8 + sub-index pgm_data (0x100432) → micro-op word pgm_value (0x100438) → cop_func_valu
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:151 MAME calls find_trigger_match(triggerval, 0xff00) to find the slot whose cop_func_trigger matches.
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:215 Triggers (write-only addresses) MAME legionna.cpp:172 maps cop_cmd_w to $100500-$100505 (3 words).
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:289 0x100410 sprite_dma_inc (MAME seibucop.cpp:1279): if x_clip in [-160, 320): cop_regs[4] += 8 cop_sprite_dma_src += 6; cop_sprite_dma_size--; cop_status bit 1 = (size > 0) ?
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:292 0 : 1 (Sprite DMA x_clip non implementato: assumiamo in-range come MAME default per HeatedBarrel — il game non usa sprite DMA via COP comunque)
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:330 Macro program upload — MAME seibucop.cpp lines 318-457 pgm_data writes one micro-op word to cop_program[latch_addr] AND latches the slot's trigger/value/mask from current latch regs.
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:429 itoa_digits (MAME 0x100590-99, 5 word).
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:441 Status / dist / angle (MAME seibucop.cpp:916 cop_status_r → cop_status)
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:452 MAME open bus
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:565 Trigger latches — MAME seibucop.cpp cop_cmd_w line 1069.
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:566 MAME dispatches on raw data after clearing cop_status bit 15.
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:605 MAME converte itoa ISTANTANEO (seibucop.cpp:858).
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:713 MAME cop_cmd_w (seibucop.cpp:1075):
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:749 Restituisce canonical trigger value del slot (NB: MAME LEGACY_cop_cmd_w usa il match slot per dispatchare; in pratica equivale a restituire cop_func_trigger[slot]).
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:770 fade_table — MAME seibucop.cpp:733 (reverse engineered from Seibu Cup Soccer bootleg) v = pal_channel(5-bit) | (brightness_val_xor_X) [10-bit input] low = v & 0x1F high = v & 0x3E0 return (low * (high | (high>>5)) + 0x210) >> 10 [8-bit o
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:807 ── Hitbox b100/b900 scratch (MAME cop_collision_update_hitbox) ────────────── dx[i] = int8 (signed) byte basso, size[i] = uint8 (unsigned) byte alto del word descrittore @ hitadr2+2*i. 3 assi (Y,X,Z) per HeatedBarrel.
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:815 MAME: res init = (3axis ?
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:842 Con 16-bit frac + 24 iter + z>>16: 0 divergenze di decisione vs MAME int(atan(dx/dy)*128/pi) su ~640k casi (dimostrato numericamente).
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1074 MAME cop_dma_trigger_w: NON modifica cop_status (vedi seibucop.cpp:741).
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1080 MAME dma_tilemap_buffer: copy staging RAM → renderer BRAM src = cop_dma_src[mode] << 6 (byte addr 0x101000+ = staging) dst = i (loop counter 0..0x13FF = renderer index) count = 0x2800/2 = 5120 words
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1090 MAME dma_palette_buffer: copy staging palette → renderer src = cop_dma_src[mode] << 6 (0x104000 = palette staging) dst = i (loop counter 0..0x7FF = renderer index) count = 0x1000/2 = 2048 words
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1106 simplified, MAME size>>1
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1111 MAME seibucop_dma.ipp dma_palette_brightness() mode 5/4.
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1114 MAME formulas: src = cop_dma_src[mode] << 6 dst = cop_dma_dst[mode] << 6 size = ((cop_dma_size << 5) - (cop_dma_dst << 6) + $20)/2 Init: src=$106000, dst=$104000, size=($827F<<5 - $4100<<6 + $20)/2 = ($104FE0 - $104000 + $20)/2 = $1000
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1125 MAME size = (((size<<5) - (dst<<6) + 0x20)/2)
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1135 Skip if dst != 0 (MAME guard, dma.ipp:135)
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1149 MAME cop_cmd_w (seibucop.cpp:1073): cop_status &= 0x7fff (clear bit 15).
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1151 MAME: cop_status &= 0x7fff (clear bit 15).
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1170 MAME execute_0205: read dword at cop_regs[0]+4+offset*4 (ppos)
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1191 0x138e / 0x338e — atan(dx/dy) MAME execute_338e.
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1193 Parte da r1+4 hi (offset 0x0004), come 3BB0/MAME.
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1201 r1+4 hi (MAME read_dword(r1+4) primo)
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1216 MAME: raw_angle = cop_read_word(r0+0x34) = host_read_word(0x34^2 = 0x36); amp = cop_read_word(r0+0x36) = host_read_word(0x36^2 = 0x34).
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1404 Macro 0x0205 — linear movement (MAME execute_0205) ppos = read_dword(cop_regs[0]+0x04) vel = read_dword(cop_regs[0]+0x10) npos = ppos + vel write_dword(cop_regs[0]+0x04, npos) delta = (npos>>16) - (ppos>>16) write_word(cop_regs[0]+0x1E, re
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1447 MAME cop_read/write_word(cop_regs[0]+0x1e) = host word @ (0x1e^2)=0x1c (host endianness word^2; conferma doc 06 micro-op 'addmem16 0x1C(r0)').
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1465 Macro 0x0905/0x0904 — jump (MAME execute_0904) write_dword(cop_regs[0]+0x10, read_dword(cop_regs[0]+0x10) ± read_dword(cop_regs[0]+0x28)) 0x0905 (bit 0=1) = +, 0x0904 (bit 0=0) = -
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1491 MAME execute_0904: bit 0 di data = 1 → add, =0 → sub tmp32_a = vel ± grav.
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1522 0x138E/0x338E atan(dx/dy) — MAME execute_338e (cmd.ipp:159) dx = read_dword(r1+4) - read_dword(r0+4) dy = read_dword(r1+8) - read_dword(r0+8) if(!dy){status|=0x8000; angle=0} else angle=atan(dx/dy)*128/pi; dy<0→+0x80 if(data&0x80) write_byt
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1570 MAME: angle = atan(dx/dy)*128/pi (+0x80 se dy<0).
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1572 Cosi' z = atan(dx/dy) e il +0x80 (in WR) copre solo il quadrante, come MAME.
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1574 NIENTE prescale: i dword diff sono FIXED-POINT coord<<16 (come il 3BB0 che usa dx32[31:16] e MAME dx>>16), NON interi piccoli.
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1615 MAME (int)(...) tronca VERSO ZERO.
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1617 BUG TROVATO (validato vs MAME su 29241 casi): il CORDIC SOTTO-CONVERGE di 1 LSB sulle DIAGONALI (es.
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1622 Compenso l'epsilon di sotto-convergenza con +1 toward-zero PRIMA del troncamento: bias=1 azzera tutte le 133 divergenze (bias=0) -> 0/29241 vs MAME.
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1631 MAME execute_338e (seibucop_cmd.ipp:175-188): la write dell'angolo in RAM (obj+0x34 host, gated da data&0x80) e' FUORI dall'if/else di dy -> avviene SEMPRE, anche a dy==0 (dove cop_angle=0 -> scrive 0^0x80 = 0x80).
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1637 Ora calcolo ang_byte in entrambi i rami e scrivo SEMPRE, come MAME.
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1644 Scrivere l'angolo anche a dy==0 ("1:1 MAME") REGREDISCE: il martello scivola/moonwalk.
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1647 MAME: dy==0 -> cop_angle=0
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1670 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197) dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (aritmetico) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = sqrt(dx*dx + dy*dy) if(data&0x80) write_word(r0 + (data&0x200?0x3a:0x38
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1779 (Il fix MAME-aligned 0x3a:0x38 faceva fuggire i nemici -> MAME invertito vs HW.
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1786 MAME: macro completata → cop_status = 7 (gate-poll del gioco).
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1872 0x8100/0x8900 sin/cos (MAME execute_8100/8900) raw_angle = cop_read_word(cop_regs[0]+0x34) & 0xff amp = (65536>>5) * (cop_read_word(cop_regs[0]+0x36) & 0xff) = 2048 * amp_byte if (raw_angle == 0xC0 sin / 0x80 cos): amp *= 2 res = int(
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1911 MAME special-case: sin && raw==0xC0 OR cos && raw==0x80 → amp *= 2
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1957 0xa180/0xa980 — read pos (MAME cop_collision_read_pos) flags_swap = cop_read_word(spradr+2) → host_read_word(spradr+0) pos[0] = cop_read_word(spradr+6) → host_read_word(spradr+4) pos[1] = cop_read_word(spradr+10) → host_read_word(
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1964 Però MAME cop_read_word(+2) = host_read_word(+2^2) = host_read_word(+0).
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1975 rdata = word @ host+0 = flags (MAME cop_read_word(spradr+2) ^ 2).
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1984 rdata = word @ host+4 = pos[0] (Y axis per MAME)
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:2004 0xb100/0xb900 — update hitbox & compute intersection (1:1 MAME cop_collision_update_hitbox, seibucop.cpp:1003-1065).
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:2049 MAME seibucop.cpp:1010 (data & 0x0100).
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:2106 MAME seibucop.cpp:1038: res init = (num_axis==3 ?
rtl/HeatedBarrel/HeatedBarrel_main_top.sv:213 VBLANK IRQ4 — MAME legionna.cpp: m_maincpu->set_vblank_int(irq4_line_hold) MAME HOLD_LINE: IRQ asserted on edge, released ONLY at IACK (= when CPU fetches vector).
rtl/HeatedBarrel/HeatedBarrel_main_top.sv:218 VBLANK IRQ4 — MAME legionna.cpp: m_maincpu->set_vblank_int(irq4_line_hold) MAME HOLD_LINE: IRQ asserted on edge, released ONLY at IACK (= when CPU fetches vector).
rtl/HeatedBarrel/HeatedBarrel_main_top.sv:473 COP3 cmd 0x14 dma_tilemap_buffer (MAME legionna_v.cpp:86 videowrite_cb_w): offset 0x000..0x3FF → BG (back_data) offset 0x400..0x7FF → FG (fore_data) offset 0x800..0xBFF → MG (mid_data) offset 0xC00..0x13FF → Text (textram, 0x800 word)
rtl/HeatedBarrel/HeatedBarrel_main_top.sv:485 DMA tilemap (cmd 0x14): dma_vram_addr = INDICE renderer 0-based del chip SEI300 (MAME videowrite_cb_w: i=0..0x3FF BG, 0x400-0x7FF FG, 0x800-0xBFF MG, 0xC00-0x13FF TEXT).
rtl/HeatedBarrel/HeatedBarrel_main_top.sv:518 SCRATCH BG: CPU-write + DMA-src-read + FILL-write (= MAME .ram() $100800).
rtl/HeatedBarrel/HeatedBarrel_main_top.sv:531 RENDER BG: scritto SOLO dal DMA cmd 0x14 (= MAME m_back_data), letto dal renderer.
rtl/HeatedBarrel/HeatedBarrel_main_top.sv:596 ── Palette: split STAGING ($104000) vs RENDERER (semantica MAME 2-stadi) ─── MAME: la CPU e il fade (cmd 0x80) scrivono la STAGING RAM a $104000.
rtl/HeatedBarrel/HeatedBarrel_main_top.sv:618 Il mirror serve al FADE-SOFTWARE della CPU (presentazione, routine $263E) che fa read-modify-write sulla palette assumendo palette UNICA (come MAME/HW): senza mirror la CPU scrive solo lo staging e il risultato non e' visibile fino al pross
rtl/HeatedBarrel/HeatedBarrel_main_top.sv:639 In MAME m_spriteram=make_unique_clear (tutte 0 -> bit15=0 -> skip).
rtl/HeatedBarrel/HeatedBarrel_maincpu_map.sv:23 Main CPU memory map HeatedBarrel (MAME legionna.cpp legionna_map): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $100000-$1003FF RAM scratch (1KB) → BRAM (Main RAM low) $100400-$1006FF COP3 region
rtl/HeatedBarrel/HeatedBarrel_maincpu_map.sv:119 Heated Barrel memory map (MAME heatbrl_map): VRAM shiftata -0x800 vs legionna, CRTC +0x40, sound @1007c0, irqack @100600, spriteram @103000.
rtl/HeatedBarrel/HeatedBarrel_maincpu_map.sv:215 MAME legionna_map: main_r/main_w(offset>>1) con umask16(0x00ff).
rtl/HeatedBarrel/HeatedBarrel_maincpu_map.sv:219 Vedi reference/mame_seibu/seibusound.cpp main_r/main_w.
rtl/HeatedBarrel/HeatedBarrel_maincpu_map.sv:311 Replica la latenza-zero-osservabile di MAME (cop_cmd_w sincrono): il gioco legge cop_hit_val_stat/cop_angle ($188/$1b4) nell'istruzione dopo il trigger.
rtl/HeatedBarrel/HeatedBarrel_palette.sv:25 MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 128*16); (legionna.cpp:1212, 128*16 = 2048 entry) Address space CPU: 0x104000..0x104FFF (4 KB = 2048 word).
rtl/HeatedBarrel/HeatedBarrel_palette.sv:35 Espansione 5→8 standard MAME palette_device: {val5, val5[4:2]} (bit replication che riempie i 3 LSB con i 3 MSB del valore 5-bit).
rtl/HeatedBarrel/HeatedBarrel_palette.sv:85 HeatedBarrel: xBGR_555 → RGB888 (MAME legionna.cpp:1212) Layout: bit[4:0]=R, bit[9:5]=G, bit[14:10]=B. 5 bit per canale.
rtl/HeatedBarrel/HeatedBarrel_palette.sv:87 Espansione 5→8 standard MAME palette_device: {val5, val5[4:2]} (replica i 3 MSB nei 3 LSB → range 0..255 con monotonia preservata).
rtl/HeatedBarrel/HeatedBarrel_seibu_crtc.sv:23 Seibu CRTC fedele a MAME (src/mame/seibu/seibu_crtc.cpp).
rtl/HeatedBarrel/HeatedBarrel_seibu_crtc.sv:119 MAME mappa: bit0=screen0(BG), bit1=screen2(MG), bit2=screen1(FG), bit3=screen3(Text) (vedi seibu_crtc.cpp commento "screen 0=BG, screen 1=FG, screen 2=MG, screen 3=Text") MAME (legionna_v.cpp) layer_en_w gira la maschera così: ~layer_en bit
rtl/HeatedBarrel/HeatedBarrel_seibu_crtc.sv:128 Il dispatcher MAME usa "if (BIT(~m_layer_en, n))" per saltare = layer disabilitato quando il bit è 1.
rtl/HeatedBarrel/HeatedBarrel_seibu_crtc.sv:133 HeatedBarrel layer ordering (MAME legionna_v.cpp:342-345): bit 0 = MG (midground) bit 1 = BG (background) bit 2 = FG (foreground) bit 3 = Text bit 4 = Sprites (Diverso da BB/DCon/Gundam dove bit 0=BG, bit 1=MG.)
rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:25 Formato spriteram quasi identico (entrambi MAME sei021x_sei0220_spr.cpp) — differenze: - Spriteram @ 0x105000-0x105FFF (4KB, 1024 word, 256 entry × 4 word) - w3 bit 15 = tile bank extra bit (denjinmk usa, HeatedBarrel base = 0)
rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:30 Format word (MAME legionna_v.cpp:288-312): w0 bit 15 = enable (0=draw, 1=skip — TODO verify HeatedBarrel) w0 bit 14 = flip_x w0 bit 13 = flip_y (???
rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:46 Priority callback legionna_v.cpp:314-317: pri_mask[0] = 0x0000 (sopra tutto) pri_mask[1] = 0xFFF0 pri_mask[2] = 0xFFFC pri_mask[3] = 0xFFFE
rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:140 0..511 (MAME size/2/4 = 4096/2/4 = 512)
rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:145 Decoded fields — MAME sei0210_device::draw (non-alt format, riga 143): if (BIT(~spriteram[i], 15)) continue; → draw quando w0[15]==1.
rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:155 SEI0211 get_coordinate (MAME sei021x_sei0220_spr.h): coord &= 0x1ff; return (coord >= 0x180) ?
rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:163 MAME SEI0211 default m_xoffset/m_yoffset = 0 (sei021x_sei0220_spr.cpp:40-41).
rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:164 HeatedBarrel NON chiama set_offset (legionna.cpp:1214) → offset 0,0.
rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:196 Tile code finale Y-MAJOR (MAME draw_internal: ax=outer, ay=inner, code++): sub_index = ax*sizey + ay → cur_tile = code + eff_tile_x*sp_h + eff_tile_y
rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:530 MAME gfx_legionna_spr: color base = 64*16 = 0x400 (64 colorset × 16 pen).
rtl/HeatedBarrel/HeatedBarrel_text_renderer.sv:25 Specifiche da MAME (legionna.cpp:1117-1126, 1167):
rtl/HeatedBarrel/HeatedBarrel_text_renderer.sv:47 Char ROM in MAME: "char" region 64KB = ROM_COPY user1[0x10000..0x1FFFF].
rtl/HeatedBarrel/HeatedBarrel_text_renderer.sv:142 MAME `legionna_v.cpp:214`: text tilemap = 64×32 (8x8 tiles, TILEMAP_SCAN_ROWS).
rtl/HeatedBarrel/HeatedBarrel_text_renderer.sv:188 --- Stage 3: pen decode (charlayout planes packed in nibbles) --- Per col c (0..3 dentro la half-tile), bit position = 3 - c. pen[0] = word[bit_pos + 0] (plane 0) pen[1] = word[bit_pos + 4] (plane 1) pen[2] = word[bit_pos + 8] (plane
rtl/HeatedBarrel/HeatedBarrel_text_renderer.sv:194 MAME readbit usa MSB-first: bit_offs N → byte[N/8] bit (7-N%8).
rtl/HeatedBarrel/HeatedBarrel_text_renderer.sv:195 In Verilog word concat (lo=byte0[7:0], hi=byte1[7:0]) → MAME pos N = word[(7-N%8) + (N>=8?8:0)].
rtl/HeatedBarrel/HeatedBarrel_text_renderer.sv:212 MAME GFXDECODE char: color base = 48*16 = 0x300 (16 colorset × 16 pen).
rtl/HeatedBarrel/HeatedBarrel_tile_layer.sv:25 Differenze fra layer (da MAME legionna_v.cpp):
rtl/HeatedBarrel/HeatedBarrel_tile_layer.sv:58 BB FG hardcoded +0x1000 (MAME bloodbro fg_tile_info)
rtl/HeatedBarrel/HeatedBarrel_tile_layer.sv:176 heatbrl 256x256 (MAME visarea 0..255)
rtl/HeatedBarrel/HeatedBarrel_tile_layer.sv:196 Tile index con eventuale gfx_bank (MG ha bit 12 = 13-bit totali, BG/FG = 12 bit) + TILE_CODE_OFS hardcoded (BB FG aggiunge 0x1000 secondo MAME bloodbro fg_tile_info).
rtl/HeatedBarrel/HeatedBarrel_video_timing.sv:33 Active area Heated Barrel (MAME heatbrl): visarea 0..32*8-1, 0..32*8-1 quindi 256×256.
rtl/HeatedBarrel/HeatedBarrel_video_timing.sv:70 ── Constants timing ───────────────────────────────────────────────────── Blood Bros: 256x224 active (MAME bloodbro.cpp:846-851 set_visarea 0..255, 16..239).
rtl/HeatedBarrel/HeatedBarrel_video_timing.sv:86 MAME heatbrl (legionna.cpp:1258-1259): set_size(36*8,36*8), set_visarea(0,255,0,255) = 256x256 visibile @ 60Hz.
rtl/HeatedBarrel/sdram_bridge.sv:295 heatbrl: nessun de-scramble gfx (empty_init in MAME) — fetch lineare per tutte le region (back/mid/fore/sprite caricate gia' nel formato corretto, WORD_SWAP via MRA).
README.md:12 This core reimplements the hardware in SystemVerilog from MAME references and hardware observation.
README.md:41 **Seibu SEI300 / COP coprocessor** reproduced from the MAME `raiden2cop` reference: sincos / atan (CORDIC) math, distance / divide, object DMA, collision detect
README.md:45 MAME-accurate Seibu CRTC tilemaps with per-layer scroll and graphics banking
README.md:49 xBGR-555 palette, MAME-accurate layer priority and sprite/tilemap mixing

Says it matches, follows or was checked against MAME — 8

HeatedBarrel.sv:209 Shift fisso aggiunto per match MAME 1:1 (misurato HW 2026-05-14): BG X+0 Y+16 FG X+0 Y+16 SPR X+0 Y+0 TXT X-1 Y+16 L'OSD resta editabile ±32 attorno al valore corretto.
HeatedBarrel.sv:215 Offset per-layer HARDCODATI = match pixel-perfect MAME (trovati via OSD, ora fissi; menu P5 rimosso).
HeatedBarrel.sv:257 NB: gli offset per-layer (ex P5) sono HARDCODATI (osd_*_xoff/yoff costanti, match pixel-perfect MAME).
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:747 find_trigger_match (MAME seibucop.cpp:464) Cerca slot N tale che (trigger & 0xf800) == (cop_func_trigger[N] & 0xf800) && cop_func_trigger[N] != 0.
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1926 res = prod >> 4 (= /16 per matchare formula MAME 2048/32768 = 1/16)
rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:165 +1 pixel a destra: offset verificato con pixel hunting su MAME (rmonic79).
rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:325 Scan INVERSO 511→0 (verificato su HW: ordine sprite-su-sprite opposto al loop MAME 0→511).
rtl/HeatedBarrel/HeatedBarrel_video_timing.sv:87 V_VISIBLE portato 224->256 per matchare MAME.

Says it was translated, ported or taken from MAME — 3

HeatedBarrel.sv:209 Shift fisso aggiunto per match MAME 1:1 (misurato HW 2026-05-14): BG X+0 Y+16 FG X+0 Y+16 SPR X+0 Y+0 TXT X-1 Y+16 L'OSD resta editabile ±32 attorno al valore corretto.
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1678 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197): 1:1 dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (signed) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = floor(sqrt(dx*dx + dy*dy)) if(data&0x80) write_word(r0+(data&0x200?0x3
rtl/HeatedBarrel/HeatedBarrel_cop3.sv:1795 0x42C2/0x4AA0 divide — MAME execute_42c2/4aa0 (cmd.ipp:219/247): 1:1 DIVIDEND = cop_dist << (5 - cop_scale) (cop_scale 0..3 → shift 5..2) 42c2: div=cop_read_word(r0+0x36)→host 0x34; if(!div){status|=0x8000; write 0 a host 0x3a} else write

Shares text with the MAME driver without saying so — 4

rtl/HeatedBarrel/HeatedBarrel_palette.sv:23 Palette RAM Seibu HeatedBarrel (xBGR_555, 2048 entries). MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 128*16); (legionna — shares text with seibu/legionna.cpp:1212
rtl/HeatedBarrel/HeatedBarrel_sprite_renderer.sv:146 if (BIT(~spriteram[i], 15)) continue; → draw quando w0[15]==1. — shares text with seibu/sei021x_sei0220_spr.cpp:128
rtl/HeatedBarrel/HeatedBarrel_text_renderer.sv:23 Text layer renderer Seibu HeatedBarrel (8x8, 4bpp, 64x32). Specifiche da MAME (legionna.cpp:1117-1126, 1167): // charlayout 8x8, RGN_FRAC(1,1) — shares text with seibu/legionna.cpp
rtl/HeatedBarrel/HeatedBarrel_video_timing.sv:86 MAME heatbrl (legionna.cpp:1258-1259): set_size(36*8,36*8), set_visarea(0,255,0,255) — shares text with seibu/legionna.cpp:1201

Hyprduel#
Hyper Duel, Magical Error wo Sagase
MiSTer-devel/Arcade-HyperDuel_MiSTer @ 7f154f1e
MAME compared: metro/hyprduel.cpp
Read: 18 HDL files, 8,144 lines (Quartus project)

MiSTer official

Both

medium

49%

Statements: 6 toward hardware, 29 toward MAME

Reports a measurement taken on the original PCB — 4

rtl/hyprduel_sys.sv:400 Real-board OKI clock = 4 MHz OSC / 2 = 2.000 MHz, measured from the PCB 1cc video: announcer-voice pitch ratio 1.0532 against our previous 2.105 MHz divider => 1.999 MHz on hardware.
rtl/hyprduel_sys.sv:423 YM level keeps the 2026-07-05 MAME stream calibration (x1.20); the OKI level is calibrated against REAL HARDWARE (PCB 1cc video line capture, 2026-07-11): title-voice peak vs title-music RMS measured 2.20 on the PCB against 5.13 with the ol
rtl/i4220_vdp.sv:318 Frame total: MEASURED at 261 lines (60.2408 Hz with the 424-dot line at 6.6665 MHz) from two PCB recordings by three agreeing methods (docs/plan_refresh_measurement.md, ACCURACY.md 3.6); the game itself only ever programs 261 raster lines.
rtl/i4220_vdp.sv:504 v14: the game runs TWO write disciplines (measured in sim and with the silicon write-landing histogram, 2026-07-19).

Notes where it differs from MAME — 2

README.md:55 Where the core differs from MAME, and why.
README.md:58 **Visible area.** The CRTC registers MAME ignores set the monitor's visible window.

Cites MAME source — 21

Arcade-Hyprduel.sv:130 DIPs arrive as raw DSW port bytes on ioctl index 254 (MRA switches, default bf,ff = 0xFFBF = MAME defaults, demo sounds ON)
Arcade-Hyprduel.sv:223 inputs (board ports are active low; MAME hyprduel.cpp:348-372) P1/P2: bit0 U, 1 D, 2 L, 3 R, 4 shot, 5 change, 6 bomb MiSTer joystick: bit0 R, 1 L, 2 D, 3 U, then J1 order from bit 4
rtl/hyprduel_sys.sv:41 audio (signed mono mix, MAME weights: YM 0.80, OKI 0.57)
rtl/hyprduel_sys.sv:295 The sound program never writes the YM2151 twice within 0.5 us (MAME: 6.6 us minimum), so one pending write is enough.
rtl/hyprduel_sys.sv:333 It samples IC_n only on its phiM enable (IKAOPLL_timinggen), and opll_cen is held at 0 while crst_n is low, so the chip never saw the reset: from power-on it put out a 0.18 s decaying offset before the game's first write (MAME silent), and
rtl/hyprduel_sys.sv:402 MAME's 2.0625 MHz is ~3% sharp and flagged unverified in their own source.
rtl/hyprduel_sys.sv:423 YM level keeps the 2026-07-05 MAME stream calibration (x1.20); the OKI level is calibrated against REAL HARDWARE (PCB 1cc video line capture, 2026-07-11): title-voice peak vs title-music RMS measured 2.20 on the PCB against 5.13 with the ol
rtl/hyprduel_sys.sv:427 MAME's 0.57 route gain is ~3x hot vs the real board.
rtl/hyprduel_sys.sv:438 NOT PCB-verified: if MAME's OKI route is as far off here as on Hyper Duel (~3.5x), the board value is ~x2.8.
rtl/hyprduel_sys.sv:462 MAME's 0.57/0.80 routing (~a=0.71) is ~11 dB quieter than the real board.
rtl/i4220_blitter.sv:109 invalid tilemap: stay idle, no done (MAME: return, no IRQ)
rtl/i4220_render.sv:7 Per line: three sequential tilemap passes (layer 2 -> 1 -> 0, keep the lowest priority value, later pass wins ties => lowest layer wins), then one sprite pass in list order keeping the smallest priority group per pixel (first writer wins wi
rtl/i4220_vdp.sv:29 (MAME encodes the same fact by forcing the enable register OR 0xFD.)
rtl/i4220_vdp.sv:331 Measured on silicon (ladder probe, 2026-07-18): the game parks a scratch accumulator in the scroll registers across vblank and its frame-top write flurry lands during line 1, by (1,h160) - later than any simulation shows, because the SDRAM-
rtl/i4220_vdp.sv:345 A real monitor therefore shows chip lines 2..225; lines 0/1 are a hidden work area (the scratch accumulator and the boss-zone outlier live there), which is why a PCB's top of screen is clean while MAME - which latches these registers but ig
README.md:11 There is no datasheet for the chip, so it was built against MAME and then checked against photos and recordings of real boards.
README.md:29 Shows the same 224 lines as a real cabinet, so the top-of-screen glitch seen in MAME is gone
README.md:61 Reported to MAME in [mamedev/mame#15732](https://github.com/mamedev/mame/issues/15732).
README.md:66 **OKI sample clock.** 2.000 MHz (the 4 MHz crystal halved), about 3% lower than MAME's unverified value.
README.md:69 MAME misses around 14%, which shows as stepped parallax.
README.md:108 The I4220 work relies on MAME's Imagetek driver by Luca Elia, David Haywood, Angelo Salese and others.

Says it matches, follows or was checked against MAME — 6

Arcade-Hyprduel.sv:239 SERVICE port: bit15 service mode (low = on), bit14 Show Warning off SERVICE port: bit15 = Service Mode (1 = off), bit14 = Show Warning (0 = show, matching MAME's default and the unmodified PCB line; our old constant FFFF silently skipped th
rtl/hyprduel_sys.sv:433 magerror: x9.90 = MAME 0.288 PARITY, measured 2026-09-27 (docs/magerror_audio_fix.md): over 6.9 s of attract music with an identical 2930-write YM stream, MAME's YM2413 stream is 7.03x the IKAOPLL ACC and MAME's OKI stream is 2.13x our pre-
rtl/i4220_blitter.sv:4 Semantics verified against the MAME-port oracle (sim/oracle/i4220_blitter_oracle.py) by sim/tb/tb_blitter.sv.
rtl/i4220_blitter.sv:17 A start with an invalid destination tilemap returns to idle without o_done, matching MAME.
rtl/i4220_render.sv:5 Semantics as verified against the M1 oracle and real MAME frame dumps.
rtl/i4220_vdp.sv:76 Video timing: 0 = measured 261-line frame (60.2408 Hz, hardware -verified), 1 = legacy MAME 262-line frame (60.011 Hz) for displays that reject 60.24 Hz in sync-locked HDMI modes.

Keeps a MAME approximation — 2

rtl/hyprduel_sys.sv:8 MAME's inter-CPU spin hacks are deliberately NOT modelled; shared RAM is true dual-port.
rtl/i4220_vdp.sv:321 i_compat60 selects the legacy MAME-assumed 262-line frame (60.011 Hz) for displays that reject 60.24 Hz in sync-locked HDMI modes.

IGSPGM#
DoDonPachi II, DoDonPachi Dai-Ou-Jou, Demon Front / Moyu Zhanxian, Chuugokuryuu 3 Special …
MiSTer-devel/Arcade-IGSPGM_MiSTer @ 899c0a3e
MAME compared: igs/pgm.cpp + 27 related file(s)
Read: 56 HDL files, 30,661 lines (Quartus project)

MiSTer official

Mostly MAME

medium

29%

Statements: 2 toward hardware, 30 toward MAME

Cites hardware documentation that MAME's driver does not — 2

rtl/joy_db15.sv:9 The two pads are read out of a 74HC165 chain: JOY_LOAD is pulsed low to latch the switches, then each JOY_CLK rising edge shifts the next bit out on JOY_DATA.
README.md:62 [GUS GF1 Decap](https://github.com/nukeykt/LPC-GUS) - Coming from the same hardware lineage, the GF1 source was a useful reference for how things might be done

Cites MAME source — 20

rtl/exrom_decrypt.sv:20 IGS027A external ARM ROM address-bit XOR ("svg" / MAME pgm_<game>_decrypt).
rtl/exrom_decrypt.sv:33 IGS27_CRYPT* primitives (MAME pgmcrypt.cpp): each returns 1 when the corresponding output bit must be XORed for word index i.
rtl/exrom_decrypt.sv:53 type3 (55857G) high-byte tables (MAME pgmcrypt.cpp dfront_tab/theglad_tab), indexed by (word_idx >> 1) & 0xff = i[8:1].
rtl/ics2115/ics2115.sv:862 Port 0: IRQ status — MAME read() case 0
rtl/ics2115/ics2115_osc.sv:21 Processing order per spec §8.4 and MAME fill_output(): 1.
rtl/ics2115/ics2115_osc.sv:427 MAME/reference: (s8(sample_byte) << 8).
rtl/ics2115/ics2115_osc.sv:493 OSC_UPDATE: Advance oscillator accumulator (spec §6.1) fc bit 0 is unused; MAME uses fc<<2 on 32-bit acc, equivalent to fc>>1 in 29-bit space.
rtl/igs025.sv:63 Region/game-id values latched at reset (MACHINE_RESET in MAME).
rtl/igs025_src_tables.sv:3 Do not edit by hand; regenerate if the MAME tables change.
rtl/igs027a.sv:592 MAME inits counter to 1
rtl/pgm_asic3.sv:13 MAME "Region" port value: 0,1 = World variants 2 = Korea 3 = China 4 = Taiwan / orlegend111t protection sequence
rtl/pgm_asic3.sv:23 command : data) in MAME.
rtl/pgm_asic3.sv:145 Signature / self-test constants from MAME.
rtl/pgm_asic3.sv:234 0x03, 0x04, 0x05 are intentionally ignored by MAME.
rtl/pgm_asic3.sv:240 0x41-0x47 are intentionally ignored by MAME.
rtl/pgm_asic3.sv:255 0x50 is intentionally ignored by MAME.
rtl/rom_decrypt.sv:103 CAVE type1 (recreated internal ROM) 68k decrypt tables (MAME pgmcrypt.cpp).
rtl/rom_decrypt.sv:207 rom_size 0x100000 bytes -> 0x80000 words (MAME pgm_puzzli2_decrypt)
rtl/rom_decrypt.sv:220 rom_size 0x100000 bytes -> 0x80000 words (MAME pgm_pstar_decrypt)
README.md:56 [MAME](https://www.mamedev.org/) - Tons of information about the PGM system and especially its protection mechanisms.

Says it matches, follows or was checked against MAME — 3

rtl/ics2115/ics2115.sv:612 recalc_irq — combinational IRQ state computation Matches MAME recalc_irq(): scans all 32 voices for pending IRQs
rtl/ics2115/ics2115.sv:666 Register read mux — matches MAME reg_read() layout
rtl/ics2115/ics2115.sv:813 Host bus read output mux — matches MAME read() at offsets 0-3

Says it was translated, ported or taken from MAME — 4

rtl/igs022.sv:2 Converted from MAME src/mame/igs/igs022.cpp.
rtl/igs025.sv:2 Converted from MAME src/mame/igs/igs025.cpp + pgmprot_igs025_igs022.cpp.
rtl/igs025_src_tables.sv:1 AUTO-GENERATED from MAME src/mame/igs/pgmprot_igs025_igs022.cpp killbld_source_data[0x0c][0xec] and dw3_source_data[0x08][0xec].
rtl/pgm_asic3.sv:4 Converted from MAME src/mame/igs/pgmprot_orlegend.cpp copyright-holders: Olivier Galibert, iq_132

Shares text with the MAME driver without saying so — 3

rtl/PGM.sv:986 IGS022 + IGS025 protection (The Killing Blade / Dragon World 3). — shares text with igs/pgmprot_igs025_igs022.cpp:11
rtl/PGM.sv:1091 type2/3 games have an external ARM ROM served from DDR; type1 (kovsh/photoy2k) — shares text with igs/pgmprot_igs027a_type1.cpp:46
rtl/address_translator.sv:96 IGS022/IGS025 protection (The Killing Blade / Dragon World 3). — shares text with igs/pgmprot_igs025_igs022.cpp:11

IkariWarriors#
Ikari, Dogou Souken
MiSTer-devel/Arcade-IkariWarriors_MiSTer @ 3e5f3457
MAME compared: snk/snk.cpp + 2 related file(s)
Read: 86 HDL files, 10,589 lines (Quartus project)

MiSTer official

Mostly hardware

low

36%

Statements: 13 toward hardware, 1 toward MAME

Cites hardware documentation that MAME's driver does not — 12

rtl/clocks/A5004_1.v:1 Ikari Warriors A5004-1 PAL16R6 (same as Athena A6001-1 PAL16R6) Author: @RndMnkIII Date: 15/06/2022 Converted from Ikari-A5004-1-GAL.jed using MAME's jedutil tool Many thanks to @Porchy and pldarchive.co.uk for the JED files.
rtl/clocks/IkariWarriorsCore_Clocks.sv:205 74LS30 8-input positive NAND gate
rtl/front/IkariWarriorsCore_LineBuffer.sv:102 74LS20 4-input NAND gate
rtl/front_turbo/IkariWarriorsCore_FrontTurbo.sv:95 Register file: in hardware implemented using four 74LS670 4bitx4 Latch registers dual ported Implemented using 8bit registersx4
rtl/ttl/ttl_74107a_AsyncClr.v:1 74LS107A: Dual J-/K flip-flop with clear; negative-edge-triggered Inputs Outputs
rtl/ttl/ttl_74107a_sync.v:1 74LS107A: Dual J-/K flip-flop with clear; negative-edge-triggered Inputs Outputs
rtl/ttl/ttl_74163a_sync.v:1 4-bit modulo 16 binary counter with parallel load, *** FOR SYNTHESIS *** Synchronous Reset (SRn) -> LS163A <START_TEMPLATE> ttl_74161a #(.DELAY_RISE(20), .DELAY_FALL(25)) <NAME> (.Clear_bar(), .Load_bar(), .ENT(), .ENP(), .D(), .Clk(), .RCO
rtl/ttl/ttl_74373.sv:1 ttl_74373.sv Octal D transparent latch function table, logic diagrams and switching characteristics extracted from TI 74LS373 Datasheet.
rtl/ttl/ttl_74374_sync.sv:1 ttl_74374_sync.sv Octal D edge triggered FF function table, logic diagrams and switching characteristics extracted from TI 74LS374 Datasheet.
rtl/ym3526/jtopl_exprom.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.
rtl/ym3526/jtopl_logsin.v:16 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.
rtl/ym3526/jtopl_op.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.

Ships hardware documentation files — 1

docs/IkariWarriorsSchematic_RndMnkIII_edited.pdf

Says it was translated, ported or taken from MAME — 1

rtl/clocks/A5004_1.v:1 Ikari Warriors A5004-1 PAL16R6 (same as Athena A6001-1 PAL16R6) Author: @RndMnkIII Date: 15/06/2022 Converted from Ikari-A5004-1-GAL.jed using MAME's jedutil tool Many thanks to @Porchy and pldarchive.co.uk for the JED files.

Inferno#
Inferno
MiSTer-devel/Arcade-Inferno_MiSTer @ 7b85212b
MAME compared: williams/williams.cpp + 5 related file(s)
Read: 12 HDL files, 13,196 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

28%

Statements: 3 toward hardware, 2 toward MAME

Cites hardware documentation that MAME's driver does not — 2

rtl/inferno_cmos_ram.vhd:26 @00-01: Extra life - BCD 00 to 99 @02-03: Men for for 1 credit - BCD 01 to 99 @04-05: High score to date - BCD 00 to 01 - No / Yes @06-07: Pricing selection - BCD 00 to 09 - Custom / free play @08-09: Left coi
rtl/inferno_cmos_ram.vhd:47 @8A-8B: Position line 1 - HEX x08 to x46 @8C-8D: Position line 2 - HEX x08 to x46 @8E-8F: control sum of settings @90-91: ?

Ships hardware documentation files — 1

doc/Inferno Manual and Schematics.pdf

Cites MAME source — 1

rtl/williams2.vhd:32 Use with MAME roms from inferno.zip

Shares text with the MAME driver without saying so — 1

rtl/williams2.vhd:356 pixels |0|1|2|3|4|5|0|1|2|3|4|5| — shares text with williams/williamsblitter.cpp:50

IremM107#
Fire Barrel, Dream Soccer '94
MiSTer-devel/Arcade-IremM107_MiSTer @ bfdfd292
MAME compared: irem/m107.cpp + 3 related file(s)
Read: 38 HDL files, 15,273 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 2 toward hardware

Cites hardware documentation that MAME's driver does not — 1

rtl/m107.sv:166 Global signals from schematics

Notes where it differs from MAME — 1

rtl/nec_core/alu.sv:128 TODO - MAME doesn't update these flags, but documentation says it should flags.AC = ta[3:0] > 4'd0 ?

IremM62#
The Battle-Road, Horizon, Kaiketsu Yanchamaru, Spartan X …
MiSTer-devel/Arcade-IremM62_MiSTer @ 5ee82326
MAME compared: irem/m62.cpp + 8 related file(s)
Read: 30 HDL files, 9,979 lines (Quartus project)

MiSTer official

Mostly MAME

low

16%

Statements: 1 toward hardware, 9 toward MAME

Cites hardware documentation that MAME's driver does not — 1

rtl/iremm62_video_controller.vhd:72 from M52 schematics

Shares text with the MAME driver without saying so — 9

rtl/input_mapper.vhd:89 /* Bits 4,5,6 are different in each game, see below */ — shares text with irem/m62.cpp:412
rtl/platform.vhd:965 J1: selects whether bit 4 of obj color code selects or not high priority over tiles — shares text with irem/m62.cpp:41
rtl/platform.vhd:966 J2: selects whether bit 4 of obj color code goes to A7 of obj color PROMS — shares text with irem/m62.cpp:42
rtl/platform.vhd:968 JP1-4 - Tiles with color code >= the value set here have priority over sprites — shares text with irem/m62.cpp:54
rtl/platform.vhd:969 J1: selects whether bit 4 of obj color code selects or not high priority over tiles — shares text with irem/m62.cpp:41
rtl/tilemapctl.vhd:184 J1: selects whether bit 4 of obj color code selects or not high priority over tiles — shares text with irem/m62.cpp:41
rtl/tilemapctl.vhd:185 J2: selects whether bit 4 of obj color code goes to A7 of obj color PROMS — shares text with irem/m62.cpp:42
rtl/tilemapctl.vhd:187 JP1-4 - Tiles with color code >= the value set here have priority over sprites — shares text with irem/m62.cpp:54
rtl/tilemapctl.vhd:188 J1: selects whether bit 4 of obj color code selects or not high priority over tiles — shares text with irem/m62.cpp:41

IremM72#
Air Duel, Dragon Breed, Armed Police Unit Gallop, Daiku no Gensan …
MiSTer-devel/Arcade-IremM72_MiSTer @ b8ba3fae
MAME compared: irem/m72.cpp + 7 related file(s)
Read: 52 HDL files, 37,954 lines (Quartus project)

MiSTer official

Mostly hardware

medium

48%

Statements: 13 toward hardware, 11 toward MAME

Cites hardware documentation that MAME's driver does not — 5

rtl/joy_db15.sv:9 The two pads are read out of a 74HC165 chain: JOY_LOAD is pulsed low to latch the switches, then each JOY_CLK rising edge shifts the next bit out on JOY_DATA.
rtl/m72.v:244 Global signals from schematics.
rtl/v30/v30u_eu.sv:58 The behaviour is identical either way and the full ladder was re-scored to say so; the NETLIST is not.
rtl/v30/v30u_eu.sv:969 Both are booked UNLANDABLE-AS-DESIGNED with the block characterised, not the mechanism condemned: `docs/notes/ghost8f_results_2026-08-09.md` §9 measured the FULL family at **15.3 MHz on two draws** with every worst setup path launching from
rtl/v30/v30u_eu.sv:3050 *Falsifier*: a `v30u_eu` state register with no `ena` in the post-fit netlist, or a ladder cell that moves.

Reports a measurement taken on the original PCB — 5

rtl/v30/v30u_biu.sv:2249 MEASURED: silicon's second acknowledge is `display + 7` at every delay and the model's/ucore's was `T1 + 6`; they part only where a T1 WAITED, which in this whole corpus is the acknowledge after a woken HALT.
rtl/v30/v30u_biu.sv:2884 MEASURED on silicon, 1,189 HALT pseudo-cycles over the 725 retained fz2 captures, chip leg only: the HALT publishes the value the AD output latch ALREADY HOLDS, on both lanes, 1,189 of 1,189 with no exception.
rtl/v30/v30u_eu.sv:332 MEASURED against silicon on a directed board cell built for it (§85.2b): the floor is **3 clocks**, 121,890 rows at 0 row-diffs, with no other value in [1,7] within four orders of magnitude.
rtl/v30/v30u_eu.sv:2226 MEASURED, silicon, FLASH #17, `docs/notes/tf0f_cell_results_2026-08-11.md`: 512 directed cells x 4 waits x 4 alignments, 2,880 scored traps per engine, derivation 16/16 and a DISJOINT validation 14/14.
rtl/v30/v30u_eu.sv:3670 F` is exactly two ROM rows, 007A (POP PSW) and 01EA (RETI) -- which is the same pair E1 measured on silicon ("mu01EA's flag commit obeys the SAME race table as POP PSW's mu007A", 108/108 H-IDENTICAL).

Ships hardware documentation files — 2

Notes where it differs from MAME — 1

rtl/nu8051/nu8051_uart.sv:13 MAME is NOT the oracle for anything bit-timing here (PQ12): its mode-0 output is "highly simplified and incorrect" by its own comment, its mode-0 input is not emulated at all, and its receiver samples once per bit with no 2-of-3 majority.

Cites MAME source — 10

rtl/kna70h015.sv:77 From MAME Legend of Hero TONMA (c)1989 Irem
rtl/m72.v:199 Tie the MCU CE to the V30 CE phase: the MCU advances (and stalls) in lockstep with the bursty catch-up V30, holding the shared-RAM protection handshake at a constant V30<->MCU phase relationship (the effect MAME gets from synchronize() on e
rtl/nu8051/nu8051_alu.sv:234 B == 0 (IQ2, mirror-MAME): A/B echoed back unchanged, OV = 1
rtl/nu8051/nu8051_irq.sv:125 The level cleared is the CURRENT one - high if a high-priority routine is in progress, otherwise low (periph §6.2: MAME's `clear_current_irq`, and the manual's "the interrupt in progress is done").
rtl/nu8051/nu8051_ports.sv:179 The sampled PIN is the resolved node, not the external driver alone: a latch bit of 0 turns the output nFET on and pulls the pin low whatever the outside world drives (periph §3.2 quasi-bidirectional, §3.3 P0 open-drain), which is exactly t
rtl/nu8051/nu8051_seq.sv:1541 That is the cheap implementation, it is MAME's (`manage_idle_on_interrupt` runs on any taken interrupt), and it is the only one that settles the corner the manual does not mention - a write of IDL on the very edge that vectors - without the
rtl/nu8051/nu8051_timer.sv:244 Tx 1->0 : 1) GATE consumes the S5P2-SAMPLED INTx# pin level (PQ1 - the manual; MAME gates on the latched IEx flag and carries a TODO saying so).
rtl/nu8051/nu8051_uart.sv:199 QUESTION-P54-4: this puts the modes-2/3 RI one bit time EARLIER than periph §5.2/§5.7 say - the figures are unambiguous (no bit-detector sample and no shift pulse anywhere in the modes-2/3 stop bit) and MAME sets it a bit time late.
rtl/v30/v30u_eu.sv:304 --- the interrupt recognition (U2 pass 5; docs/facts/interrupt_model.md) --- The pins reach the decision through flops, and THAT is the whole mechanism: the ucore does NOT render `timed_runner.cpp`'s `D = max(B, A + pipe)`, which the third
rtl/v30/v30u_eu.sv:2561 `timed_runner.cpp` states the geometry and it falls straight out of `B = D + 1`, `entry = B + 2`:

Shares text with the MAME driver without saying so — 1

rtl/kna70h015.sv:77 From MAME Legend of Hero TONMA (c)1989 Irem M72 System Horizontal Freq. = 15.625KHz H.Period = 64.0us (512) H.Blank = 16.0us (128) H.Sync Puls — shares text with irem/m72.cpp:2743

IremM90#
Bomber Man World, Bomber Man, Gussun Oyoyo
MiSTer-devel/Arcade-IremM90_MiSTer @ 06d05255
MAME compared: irem/m90.cpp + 7 related file(s)
Read: 27 HDL files, 7,347 lines (Quartus project)

MiSTer official

Both

low

13%

Statements: 3 toward hardware, 1 toward MAME

Cites hardware documentation that MAME's driver does not — 2

rtl/m90.sv:151 Global signals from schematics
rtl/sound.sv:189 NMI frequency is 7812.5Khz On original hardware this is derived from the 32Mhz CPU clock, divided by 4096 4Mhz signal is divided by the 74LS161 counters IC71 and IC72 Here since we have a 40Mhz sys_clk, we divide by 5120

Notes where it differs from MAME — 1

rtl/V35/alu.sv:128 TODO - MAME doesn't update these flags, but documentation says it should flags.AC = ta[3:0] > 4'd0 ?

Shares text with the MAME driver without saying so — 1

rtl/sound.sv:22 void m90_state::m90_sound_cpu_map(address_map &map) { map(0x0000, 0xefff).rom(); map(0xf000, 0xffff).ram(); } void m90_state::m90_sound_cpu_io_map(address_ma — shares text with irem/m90.cpp:127

IremM92#
Cross Blades!, Geo Storm, Gunforce: Battle Fire Engulfed Terror Island, Hook …
MiSTer-devel/Arcade-IremM92_MiSTer @ 492cc21c (matched by date)
MAME compared: irem/m92.cpp + 5 related file(s)
Read: 40 HDL files, 15,247 lines (Quartus project)

MiSTer official

Mostly hardware

low

25%

Statements: 26 toward hardware

Cites hardware documentation that MAME's driver does not — 1

rtl/m92.sv:166 Global signals from schematics

Ships hardware documentation files — 24

Notes where it differs from MAME — 1

rtl/nec_core/alu.sv:128 TODO - MAME doesn't update these flags, but documentation says it should flags.AC = ta[3:0] > 4'd0 ?

IronHorse#
Dai Ressya Goutou
MiSTer-devel/Arcade-IronHorse_MiSTer @ 98ee94aa
MAME compared: konami/ironhors.cpp + 1 related file(s)
Read: 9 HDL files, 7,127 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

23%

Statements: 1 toward hardware, 1 toward MAME

Cites hardware documentation that MAME's driver does not — 1

rtl/IronHorse.sv:536 Iron Horse also uses 3 switchable low-pass filters on the SSG side of its YM2203 with a cutoff frequency of 723.432Hz (actually closer to 492.130Hz due to internal resistance inside the 74HC4066 handling the filter switching).

Cites MAME source — 1

rtl/custom/k005885.sv:388 The 005885 has five 8-bit registers set up as follows according to information in konamiic.txt found in MAME's source code:

Jackal#
Tokushu Butai Jackal
MiSTer-devel/Arcade-Jackal_MiSTer @ 1bc48c37
MAME compared: konami/jackal.cpp + 1 related file(s)
Read: 12 HDL files, 7,789 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

14%

Statements: 1 toward MAME

Cites MAME source — 1

rtl/custom/k005885.sv:388 The 005885 has five 8-bit registers set up as follows according to information in konamiic.txt found in MAME's source code:

Jailbreak#
Manhattan 24 Bunsyo
MiSTer-devel/Arcade-Jailbreak_MiSTer @ d564ee0b
MAME compared: konami/jailbrek.cpp + 7 related file(s)
Read: 10 HDL files, 6,780 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

No statements found

Joust2#
Joust 2 - Survival of the Fittest
MiSTer-devel/Arcade-Joust2_MiSTer @ dd09dfa5
MAME compared: williams/williams.cpp + 5 related file(s)
Read: 15 HDL files, 18,090 lines (Quartus project)

MiSTer official

Both

low

32%

Statements: 3 toward hardware, 5 toward MAME

Cites hardware documentation that MAME's driver does not — 2

rtl/joust2_cmos_ram.vhd:26 @00-01: Extra man every - BCD 00 to 99 @02-03: Men for for 1 credit - BCD 01 to 99 @04-05: High score to date allwd - BCD 00 to 01 - No / Yes @06-07: Sound in attract mode - BCD 00 to 01 - No / Yes @08-09: Pricing selection
rtl/joust2_cmos_ram.vhd:47 @8A-8B: Position line 1 - HEX x08 to x46 @8C-8D: Position line 2 - HEX x08 to x46 @8E-8F: control sum of settings @90-91: ?

Ships hardware documentation files — 1

doc/inferno-schematics.pdf

Cites MAME source — 2

rtl/williams2.vhd:32 Use with MAME roms from joust2.zip
rtl/williams_cvsd_board.vhd:30 Use with MAME roms from joust2.zip

Shares text with the MAME driver without saying so — 3

Arcade-Joust2.sv:209 0 1 2 3 4 5 6 — shares text with williams/williamsblitter.cpp:50
rtl/joust2_sound_board.vhd:163 cpu_2764_ic8_rom1_rev1.0f (84517c3c) — shares text with williams/williams.cpp:3852
rtl/williams2.vhd:363 pixels |0|1|2|3|4|5|0|1|2|3|4|5| — shares text with williams/williamsblitter.cpp:50

JunoFirst#
Juno First
MiSTer-devel/Arcade-JunoFirst_MiSTer @ efeb8e46
MAME compared: konami/junofrst.cpp + 5 related file(s)
Read: 23 HDL files, 11,760 lines (Quartus project)

MiSTer official

Both

low

29%

Statements: 5 toward hardware, 13 toward MAME

Cites hardware documentation that MAME's driver does not — 4

rtl/JunoFirst_CPU.sv:222 Juno First I/O decoding (memory-mapped in 0x8000-0x80FF region) Reference: MAME junofrst.cpp main_map and Juno First schematics
rtl/JunoFirst_SND.sv:274 Real arcade hardware doesn't need this delay; the 8039's pins on the JF schematic are wired identically to our setup (T0/T1 are floating NC, /EA pulled to VCC, /RESET from the system reset network, /INT from a 74LS74 we faithfully model).
rtl/custom/k526.sv:3 SystemVerilog implementation of the Konami 526, an 82S153 PLA used for address decoding on Time Pilot Converted from dump available at the PLD Archive http://wiki.pldarchive.co.uk/index.php?title=Time_Pilot Copyright (C) 2021 Ace
rtl/custom/k528.sv:3 SystemVerilog implementation of the Konami 528, an 82S153 PLA used for controlling the vertical counter outputs on Time Pilot's Konami 082 Converted from dump available at the PLD Archive http://wiki.pldarchive.co.uk/index.php?title=Time_Pi

Ships hardware documentation files — 1

Useful Information/juno_schem_text.pdf

Cites MAME source — 10

rtl/JunoFirst_CPU.sv:222 Juno First I/O decoding (memory-mapped in 0x8000-0x80FF region) Reference: MAME junofrst.cpp main_map and Juno First schematics
rtl/JunoFirst_CPU.sv:248 Juno First hardware blitter — 16x16 nibble-addressed sprite copy/clear Reference: MAME junofrst.cpp blitter_w()
rtl/JunoFirst_CPU.sv:576 Generate VBlank IRQ for MC6809E MAME: IRQ fires every other vblank frame when irq_enable is set.
rtl/JunoFirst_SND.sv:133 Z80 address decoding (MAME audio_map): 0x0000-0x0FFF = ROM (4KB) 0x2000-0x23FF = RAM (1KB) 0x3000 = soundlatch read 0x4000 = AY-8910 address write 0x4001 = AY-8910 data read 0x4002 = AY-8910 data write 0x5000
rtl/JunoFirst_SND.sv:158 Z80 IRQ — edge detect on irq_trigger (MAME sh_irqtrigger_w: fires on 0->1)
rtl/JunoFirst_SND.sv:220 IRQ latch — exactly as real hardware / MAME does it Z80 write → assert INT (active low) MCU writes P2.7 low → clear latch
rtl/JunoFirst_SND.sv:333 Multiplexed bus input to the 8039: /PSEN asserted → program ROM byte (instruction fetch) /RD asserted → soundlatch2 (8039 MOVX read of Z80-side command) else → 8'hFF (idle pull-ups) MAME's mcu_io_map maps 0x00-0xFF all to soundl
rtl/JunoFirst_SND.sv:386 Port A read: timer[3:0] in bits 7:4, i8039_status in bits 2:0 Timer = Z80 cycle count / 512 (MAME: total_cycles / (1024/2))
rtl/JunoFirst_SND.sv:423 MAME portB_w: bits [1:0]=ch.A filter, [3:2]=ch.B, [5:4]=ch.C Each pair selects capacitance: bit0=47nF, bit1=220nF (additive) For initial implementation, no dynamic filter switching — just DC removal.
rtl/JunoFirst_SND.sv:454 MAME reference: AY=0.30 per voice (x3 = 0.90), DAC=0.25 — i.e. DAC quieter than the AY total.

Says it matches, follows or was checked against MAME — 2

rtl/JunoFirst_CPU.sv:591 Clear IRQ when irq_enable is turned off (matches MAME irq_enable_w)
rtl/JunoFirst_SND.sv:351 T0/T1 are pin-1 / pin-39 on the real 8039 — NC on the JF schematic, but we tie to 0 to match the working Gyruss reference; MAME's junofrst.cpp does not bind T0/T1 callbacks either.

Says it was translated, ported or taken from MAME — 1

rtl/JunoFirst_SND.sv:3 Juno First sound board Based on MAME junofrst.cpp audio implementation

Kangaroo#
Funky Fish, Kangaroo
MiSTer-devel/Arcade-Kangaroo_MiSTer @ 5fd65cd5
MAME compared: sunelectronics/kangaroo.cpp
Read: 12 HDL files, 3,037 lines (Quartus project)

MiSTer official

Mostly MAME

medium

78%

Statements: 5 toward hardware, 57 toward MAME

Ships hardware documentation files — 4

Notes where it differs from MAME — 1

rtl/cpu/mb88_sv/mb88_core.sv:31 NOT MODELLED — NONE are gaps (MAME doesn't model them for the default part, or no target device uses them): * STANDBY (stby_n pin): MAME has no standby/STOP state for mb88.

Cites MAME source — 49

Arcade-Kangaroo.sv:259 2x pixel clock: arcade_video renders 512 px/line (each of the 256 source columns doubled) for the MAME-style dimmed-copy interleave, and the scaler shrinks it back.
rtl/Kangaroo.sv:14 Player inputs (active HIGH, per MAME port definitions)
rtl/Kangaroo_CPU.sv:21 h_center is in PIXELS and scaled x2 below because h_cnt runs at the double-rate 10 MHz clock (MAME: 320*2 / 256*2), so one displayed pixel is two h_cnt counts.
rtl/Kangaroo_CPU.sv:193 Blitter has 4 x 4KB ROMs, banked into 0xC000-0xDFFF via bank select (video_control[8]) MAME banks one contiguous 8K window over the 16K image (kangaroo.cpp:427, :532), and the image loads v0,v2,v1,v3 (kangaroo.cpp:772-775), so blit0=v0 blit
rtl/Kangaroo_CPU.sv:200 MAME: (data & 0x05) ?
rtl/Kangaroo_CPU.sv:239 MAME: m_video_control[0..10], written at 0xE800-0xE80A Only bits [3:0] of the address select the register (mirrored with 0x03F0)
rtl/Kangaroo_CPU.sv:278 MAME: m_maincpu->pulse_input_line(INPUT_LINE_NMI, attotime::zero); On original HW (mcu_present) the MB8841 drives NMI instead (see MCU block below) — this pulse is unused.
rtl/Kangaroo_CPU.sv:300 Per MAME kangaroo.cpp:153 — besides the boot NMI it "acts like a timer to determine the intervals of the big ape enemy appearing." Wiring mirrors kangaroo_mcu_state (kangaroo.cpp:455-504): CPU wr 0xEF00 -> main_data
rtl/Kangaroo_CPU.sv:305 protrom[addr] : F) (mcu_port_k_r) O port (oh:ol) -> protrom addr A0-A7 ; R3.1 -> A8 (A9,A10=GND) (mcu_port_o_w / mcu_port_r_w) R3.3 -> main-CPU NMI (mcu_port_r_w) MCU clock = 10MHz/4
rtl/Kangaroo_CPU.sv:309 darfpga mb88 has separate R in/out ports and no external drive on kangaroo's R pins, so tie in<-out (MAME's read_r returns the output latch).
rtl/Kangaroo_CPU.sv:312 MAME converts pin clocks at (clocks+5)/6, so the 2.5 MHz pin rate is divided by 6.
rtl/Kangaroo_CPU.sv:384 MAME: standard IM1 interrupt, RST 38h every vblank IRQ fires on vblank rising edge
rtl/Kangaroo_CPU.sv:406 Kangaroo video timing from MAME: screen.set_raw(10_MHz_XTAL, 320*2, 0*2, 256*2, 260, 8, 248); Total: 640 pixel clocks horizontal (at 5 MHz that's 320 positions at 10 MHz) But the screen uses 10 MHz as raw pixel clock with 640 total, 512 vis
rtl/Kangaroo_CPU.sv:436 Sync and blank generation MAME visible: x = 0*2 to 256*2-1 = 0 to 511, y = 8 to 247 The scanout pipeline is 2 clk_10m cycles deep, so hblank/hsync are delayed to match.
rtl/Kangaroo_CPU.sv:561 MAME videoram_write expand logic — pure combinational functions Expand 8-bit CPU data to 32-bit (DCBADCBA → 4 bytes)
rtl/Kangaroo_CPU.sv:661 MAME's blitter_execute() is synchronous inside the $E805 write, so software can issue the next trigger a few instructions later.
rtl/Kangaroo_CPU.sv:751 Adjust mask per MAME: OR top/bottom 2-bit pairs during DMA
rtl/Kangaroo_CPU.sv:794 Apply low-half blit: LOW-half ROM pairs with mask & 0x05 (kangaroo.cpp:344)
rtl/Kangaroo_CPU.sv:798 Now apply high-half blit: HIGH-half ROM pairs with mask & 0x0a (kangaroo.cpp:345)
rtl/Kangaroo_CPU.sv:846 MAME screen_update variables derived from video_control registers
rtl/Kangaroo_CPU.sv:849 MAME exact
rtl/Kangaroo_CPU.sv:851 FLIP A / FLIP B (video_control[9] bits 5/4, kangaroo.cpp:364-365), XORed with the OSD CRT Flip so it reuses the game's own mirror rather than adding a second one.
rtl/Kangaroo_CPU.sv:910 Priority compositing (MAME logic) Even pixels (first of pair): full brightness, no KOS1 masking Odd pixels (second of pair): apply KOS1 color mask for Z=0 pixels arcade_video samples the core's RGB once per h_cnt at ce_pix_2x, so consecutiv
rtl/Kangaroo_CPU.sv:932 Output — BGR 3-bit palette (MAME: PALETTE(config, m_palette, palette_device::BGR_3BIT))
rtl/Kangaroo_SND.sv:175 Simple mix: sum three unsigned 8-bit channels, apply 50% gain, output as signed 16-bit MAME: AY8910 route ALL_OUTPUTS to mono at 0.50
rtl/cpu/mb88_sv/mb88.sv:57 Generate it here: one ena_timer pulse per 32 `ena` machine-cycle enables — MAME mb88 burn_cycles /32 (full timer overflow = ÷8192 of `ena`).
rtl/cpu/mb88_sv/mb88_core.sv:6 Oracle: MAME cpu/mb88xx/mb88xx.cpp (opcode-for-opcode).
rtl/cpu/mb88_sv/mb88_core.sv:14 COMPLETE vs MAME mb88xx.cpp — opcode AND non-opcode.
rtl/cpu/mb88_sv/mb88_core.sv:16 OPCODES: all 256 bytes, verified byte-for-byte vs mb88xx.cpp execute_run() (0x00-2f individual; 0x30-3f sbit/rbit/tbit/rti/jpa/en/dis; 0x40-7f setD/ rstD/tstD/tba/xd/xyd/lxi/call/jpl/ai; 0x80-bf lyi/li/cyi/ci; 0xc0-ff jmp).
rtl/cpu/mb88_sv/mb88_core.sv:23 * Timer: internal (pio7, ÷32 prescale) OR external TC pin (pio6) per MAME increment_timer() (2026-07-11 + 2026-07-17 fixes).
rtl/cpu/mb88_sv/mb88_core.sv:29 * O-port PLA: 8-bit cf-nibble-select outO = MAME write_pla with pla_bits==8 (the device default; what the Namco 5xxx use).
rtl/cpu/mb88_sv/mb88_core.sv:34 * External-clock serial (pio 0x10/0x30): MAME fatalerror's it (unsupported).
rtl/cpu/mb88_sv/mb88_core.sv:55 MAME's write_pla() ends with an unconditional `m_write_o(0, m_o_output, mask)` (mb88xx.cpp:373), so consumers that latch the O port (e.g. namco_51xx's shared mailbox = MAME m_portO) must re-latch on every write, not on a value change.
rtl/cpu/mb88_sv/mb88_core.sv:65 interrupt injection (harness drives from the MAME trace during bug hunt)
rtl/cpu/mb88_sv/mb88_core.sv:95 ---- SERIAL (2026-07-18; faithful to MAME mb88xx.cpp serial_timer()/pio_enable()) ---- 4-bit RECEIVE shift register clocked at clock()/SERIAL_PRESCALE(=6), armed when pio[5:4]==2'b10 (MAME's (m_pio & 0x30)==0x20 = internal serial clock).
rtl/cpu/mb88_sv/mb88_core.sv:99 sf blocks further shifting until tsts clears it; SBcount runaway-disables at THRESH (MAME anti-hang).
rtl/cpu/mb88_sv/mb88_core.sv:100 External-clock serial (pio 0x10/0x30) is unsupported by MAME (fatalerror) so we just don't tick.
rtl/cpu/mb88_sv/mb88_core.sv:101 SO/transmit is not modeled in MAME's mb88 either.
rtl/cpu/mb88_sv/mb88_core.sv:105 MAME SERIAL_DISABLE_THRESH
rtl/cpu/mb88_sv/mb88_core.sv:155 SP[] and ram[] intentionally NOT reset (MAME device_reset doesn't clear data RAM/stack; ROM inits RAM; Verilator zero-inits arrays).
rtl/cpu/mb88_sv/mb88_core.sv:161 MAME mb88xx.cpp: `if (m_ctr && !state && (m_pio & 0x40)) increment_timer(); m_ctr = state;` i.e. on a FALLING edge of the TC pin, if external-counter mode (pio bit6/0x40) is enabled, tick the SAME timer.
rtl/cpu/mb88_sv/mb88_core.sv:164 This drives the 51xx's per-frame timer, which MAME clocks from screen vblank (namco51.cpp vblank() -> MB88XX_TC_LINE).
rtl/cpu/mb88_sv/mb88_core.sv:169 Two mutually-exclusive sources feed the ONE counter (a chip uses internal OR external mode, never both): internal clock (ena_timer & pio7 = MAME 0x80), OR external TC falling edge (pio6 = MAME 0x40).
rtl/cpu/mb88_sv/mb88_core.sv:173 MCU-TIMER-FIX-2026-07-11: pio7 gate (MAME 0x80); TC-TIMER-FIX-2026-07-17: + external TC path (pio6/MAME 0x40)
rtl/cpu/mb88_sv/mb88_core.sv:180 ---- SERIAL receive engine (MAME serial_timer).
rtl/cpu/mb88_sv/mb88_core.sv:184 MAME SERIAL_PRESCALE=6 divides the MB88 PIN clock; `ce` is already pin/6 (MCU_CEN_DIV), so the /6 must not be applied twice.
rtl/cpu/mb88_sv/mb88_core.sv:192 MAME: SB = (SB>>1) | (si?8:0)
rtl/cpu/mb88_sv/mb88_core.sv:211 MAME clears all pending on take
rtl/cpu/mb88_sv/mb88_core.sv:218 outO: cf=1->oh, cf=0->ol (MAME write_pla 8-bit / VHDL).

Says it matches, follows or was checked against MAME — 4

rtl/cpu/mb88_sv/mb88_core.sv:71 PC of the executing instruction (matches MAME)
rtl/cpu/mb88_sv/mb88_core.sv:213 executing instruction's own PC (matches MAME)
rtl/cpu/mb88_sv/mb88_core.sv:297 jmp within page (INCPC-then-override, matches MAME)
rtl/ram_rom/rom_loader.sv:3 Kangaroo ROM loader ROM layout matched to MAME kangaroo.cpp

Says it was translated, ported or taken from MAME — 4

rtl/Kangaroo.sv:3 Kangaroo top-level module Copyright (C) 2026 Rodimus Based on MAME kangaroo.cpp
rtl/Kangaroo_CPU.sv:3 Kangaroo Main CPU Board (TVG-1-CPU-B) Based on MAME kangaroo.cpp by Ville Laitinen, Aaron Giles
rtl/Kangaroo_CPU.sv:445 The horizontal BLANKING BUDGET here is correct and copied from MAME (kangaroo.cpp: set_raw(10_MHz_XTAL, 320*2, 0*2, 256*2, 260, 8, 248) -> htotal 640, active 512, so 128 clocks / 12.8 us of blanking).
rtl/Kangaroo_SND.sv:3 Kangaroo Sound Board (TVG-1-CPU-B, sound section) Based on MAME kangaroo.cpp

KickAndRun#
Kick and Run
MiSTer-devel/Arcade-KickAndRun_MiSTer @ 4224a5dd
MAME compared: taito/kikikai.cpp
Read: 111 HDL files, 22,035 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 6 toward hardware, 1 toward MAME

Cites hardware documentation that MAME's driver does not — 6

rtl/core.v:128 bit 2 is ROM1/0 switch, pin14 is connected to the bank register through PAL16G
rtl/ym2203/deprecated/jt12_opram.v:20 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.
rtl/ym2203/jt12_exprom.v:19 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.
rtl/ym2203/jt12_logsin.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.
rtl/ym2203/jt12_op.v:19 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.
rtl/ym2203/jt12_reg.v:329 memory for CH registers Block/fnum data is latched until fnum low byte is written to Trying to synthesize this memory as M-9K RAM in Altera devices turns out worse in terms of resource utilization.

Cites MAME source — 1

rtl/ym2203/jt12_lfo.v:78 same values as in MAME

Klax#
Klax
MiSTer-devel/Arcade-Klax_MiSTer @ c071c8da
MAME compared: atari/klax.cpp + 2 related file(s)
Read: 24 HDL files, 6,027 lines (Quartus project)

MiSTer official

Both

medium

76%

Statements: 49 toward hardware, 57 toward MAME, 7 not counted

Cites hardware documentation that MAME's driver does not — 43

Klax.sv:238 Leaving self-test resetting the game is authentic, not a defect: the test code stops petting the watchdog, the LS197 @5B bites and reboots the board.
rtl/klax_addr_decode.v:4 Transcribed from the DUMPED production decode PAL: GAL16V8 136075-1000 at 11C (136075-1000.11c.bin, jedutil) feeding the 74F138 at 11B (schematic Sheet 3).
rtl/klax_addr_decode.v:6 The schematic draws a 24-pin PAL20L10 at 11C, but Sheet 3 notes "USE 16L8 IF SLAPSTIK IS NOT USED" — production Klax has no slapstic, and the 16L8-class GAL at 11C is exactly what MAME dumped.
rtl/klax_addr_decode.v:21 MA16 sub-selects color RAM (0x3E pages, /CTIME path, F257 @5N) vs the single 8Kx16 video RAM (2X/2Y).
rtl/klax_addr_decode.v:86 74F138 @11B: Y = {SELC,SELB,SELA} pin levels.
rtl/klax_addr_decode.v:105 /VRAM sub-decode (video side, Sheets 4/5/8): MA16=0 -> color RAM (/CTIME = MA16 during the CPU slot, F257 @5N) MA16=1 -> 8Kx16 video RAM; chip select VRA14=MA14, MA15 unused.
rtl/klax_audio_filter.v:2 Klax Analog Audio Output Filter (board-level, Sheet 4)
rtl/klax_audio_filter.v:4 The MSM6295 @14D drives a 6779.44 Hz zero-order-hold DAC.
rtl/klax_audio_filter.v:11 SILICON REFERENCE - Klax schematic package, Figure 5-1 Sheet 4 of 9 (the sheet spans two pages: MSM6295 + first stage, then the rest):
rtl/klax_cpu_bus.v:9 DTACK (schematic Sheet 2): every bus cycle COMPLETES on real hardware — there is no such thing as a stalling unmapped access.
rtl/klax_cpu_bus.v:10 The LS163A at 10B (clock RCLOCK = the 7.16 MHz pixel/CPU clock, sync-cleared while BAS is idle) loads {D,C,B,A} = {+5V, PVCPU|/VRAM, /PCM, /EEPROM} once per cycle (LD/ENP self-sequenced from QD) and counts to 15; RCO -> DTACK -> /DTACK.
rtl/klax_cpu_bus.v:20 PVCPU comes from the VRAM arbitration state machine: the dumped 9W GAL (136075-1003 "MOBL2", registered at 14.318 MHz) generates the pre-VAS slot code from the H-counter phase; PVCPU = PVAS0 & PVAS1 & VREQ (LS11 @10U), VREQ = NOR(DTACK, /VR
rtl/klax_cpu_bus.v:28 Interrupt acknowledge: VPA = NAND(BAS,FC2,FC1,FC0) (F20 @9B) asserts combinationally during an IACK cycle, while DTACK needs at least one RCLOCK edge — VPA always wins the race and the 68000 autovectors.
rtl/klax_cpu_bus.v:121 Input mapping (schematic Sheet 5 + the 6W dump for the markers): i2=VREQ i3/i4/i5=1H/2H/4H (SOS hcnt bits = (hc+12) mod 8) i6=RCLOCKB i7=HBLANK (hc>=336) i8=NXL^NXLDL line-boundary marker i9=/PFHST (low hc 430..445, from the dumped 6W /P
rtl/klax_cpu_bus.v:201 Combinational PVAS outputs (o13/o18) at the RCLOCK sample point (tick0 inputs: i6=0, i8=nxlmark_t0) and PVCPU (LS11 @10U).
rtl/klax_cpu_bus.v:214 LS163A @10B wait-state counter (RCLOCK cadence).
rtl/klax_irq.v:4 Schematic Sheets 5 and 2: an LS74 at 5K with D = P = +5V, clocked by CK = VBLANK | ~32V (LS32 @10N + LS04 @9N), cleared by /VACK (the 0x360000 write).
rtl/klax_irq.v:6 /Q = /VINT drives IPL2 through the LS08 @7B (the other input is the pulled-up /SINT from the unstuffed AUX connector); IPL1/IPL0 are tied high, so /VINT is IRQ level 4.
rtl/klax_palette.v:4 Silicon (schematic Sheet 8): one 2Kx8/35 SRAM at 11J holds TWO banks of 512 IRGB_1555 entries.
rtl/klax_playfield.v:187 Silicon DAC truth (schematic Sheet 9): each channel is a 6-bit R/2R ladder whose LSB is the shared intensity bit — channel = {color5, I}.
rtl/klax_sys.v:298 === Output Latch (0x260000 write) === Documented in the Klax manual memory map (Figure 5-2, "LATCH").
rtl/klax_sys.v:316 Silicon notes (schematic Sheet 2): the latch is an LS174 at 2A clocked by /LATCH = R//W | /PAR — i.e. ANY write anywhere in the 0x26 page (P1 and P2 word addresses alike) clocks it, so the strobe below covers cs_input_p1 and cs_input_p2.
rtl/klax_sys.v:323 D13 = CBANK, the color-RAM bank select (color RAM A9, Sheet 8) — routed to the palette below; the game never sets it.
rtl/klax_sys.v:342 === OKI MSM6295 ADPCM Sound === u_oki is the chip (bit-exact vs MAME); u_audio_filter is the board's analog output stage around it (Sheet 4).
rtl/klax_sys.v:368 === Analog output filter (LM324 18C sections, Sheet 4) === 5-pole low-pass between the DAC pin and the speaker: -3 dB at 790 Hz, -49.6 dB at the 6779.4 Hz first image.
rtl/klax_sys.v:380 === EEPROM === sys_reset: the write-unlock latch (LS74 @5K) is cleared by /SYSRES on the PCB, so a watchdog bite re-locks it.
rtl/klax_top_mister.v:134 The SOS-2 custom chip (9Y) emits the 1H..256H counter taps; the 6W PAL decodes /PHSYNC = hc 352..379 (28 px) and HBLANK (336 visible).
rtl/klax_top_mister.v:138 VSYNC/VBLANK are generated inside the SOS-2 custom chip (not in any dumped PAL), so exact placement needs a scope capture.
rtl/klax_top_mister.v:142 The PCB delays it through the LS174 @17K (2H clock, R102 tap = stage 3 stuffed, Sheet 8) before the monitor: +10 px.
rtl/klax_top_mister.v:651 Silicon DAC truth (schematic Sheet 9): 6-bit R/2R ladder per channel, LSB = the shared intensity bit ({color5, I}); MAME's IRGB_1555 decoder is identical (pal6bit((c << 1) | i)).
rtl/klax_watchdog.v:4 Schematic Sheet 2: an LS197 4-bit counter at 5B clocked by VBLANK (QA ripples into CK2), with data inputs {D,C,B,A} = {+5V,GND,GND,GND}, count/load pin driven by /WDOG (the 0x2E0000 write, gated by the WDIS service jumper), async /CLR = POW
README.md:8 It was built from the PCB schematics and the dumped on-board PALs, with MAME as a cross-reference rather than as the specification.
README.md:118 What makes this core worth having is how much of it came off the schematics and the dumped PALs rather than out of an emulator:
README.md:130 **Every bus cycle completes.** DTACK comes from the LS163A at 10B, loaded from the decode: 0 wait states by default, +1 for EEPROM, +2 for the OKI, and 0-or-4 f
README.md:133 IACK is handled too — `VPA` from the F20 at 9B always beats DTACK.
README.md:135 **IRQ from the LS74 at 5K**, clocked by `VBLANK | ~32V` and cleared by `/VACK`, giving IRQ4 at scanlines 64, 128, 192 and 240 only.
README.md:139 **LS197 watchdog at 5B**, fully modelled including its power-on state: it clears to 0, which holds the board in reset for 8 frames before the game starts.
README.md:146 **DAC-exact colour.** Sheet 9 is a 6-bit R/2R ladder per channel whose LSB is a shared intensity bit, so the output follows the ladder rather than a naive bit e
README.md:151 **JAMMA-accurate HSync.** `/PHSYNC` from the dumped 6W PAL is delayed through the LS174 at 17K — only the stage-3 tap is stuffed — for +10 pixels, putting monit
README.md:154 **OKI MSM6295 ADPCM** decoding that is bit-exact against a MAME-0.288 golden model, plus — unlike MAME, which models none — the PCB's **analog audio output filt
README.md:180 It appears in no dumped PAL, so it needs a scope capture on the 9Y VSync pin.
README.md:201 | Address decode, DTACK, IACK | Dumped GAL equations transcribed and replicated, then exercised by the real TG68K in a mixed-language simulation | Reset-vector
README.md:207 | Analog audio filter | Against a golden model re-derived from the Sheet 4 component values. The generator also asserts that the coefficient literals in the RTL

Cites hardware references or measurements that MAME's driver also gives — 7

rtl/klax_addr_decode.v:65 --- 11C GAL dedicated outputs (single product terms) --- — also in MAME: 11C atari/klax.cpp:526
rtl/klax_addr_decode.v:73 --- 11C GAL F138 select encoder (o12=SELA, o13=SELB, o14=SELC) --- Active-low sums straight from the dump; pin low when a term matches. — also in MAME: 11C atari/klax.cpp:526
rtl/klax_cpu_bus.v:4 Owns the 68000 address decode boundary: - chip selects from the dumped 11C decode GAL (klax_addr_decode) - DTACK generation modeled on the real wait-state hardware - CPU read-data mux (open bus = 0xFFFF, data-bus pull-ups) — also in MAME: 11C atari/klax.cpp:526
rtl/klax_cpu_bus.v:113 VRAM arbitration replica: 9W GAL (MOBL2) + LS11 PVCPU — also in MAME: 9W atari/klax.cpp:529
rtl/klax_cpu_bus.v:158 Equations verbatim from jedutil on 136075-1003.9w.bin. — also in MAME: 136075-1003 atari/klax.cpp:529
rtl/klax_top_mister.v:133 H SYNC: GROUND TRUTH reverse-engineered from the dumped sync PAL16R6 at 6W (Atari 136075-1004; 136075-1004.6w.bin) via jedutil. — also in MAME: 6W atari/klax.cpp:530, 136075-1004 atari/klax.cpp:530, 136075-1004 atari/klax.cpp:530
rtl/klax_top_mister.v:142 /PHSYNC from the dumped 6W PAL = hc 352..379. — also in MAME: 6W atari/klax.cpp:530

Says it was checked on “real hardware” — 1

README.md:213 The logic in this release is the same logic that was validated on hardware on 2026-07-27.

Notes where it differs from MAME — 5

Klax.sv:240 MAME cannot reproduce that at all - its Klax watchdog is instantiated but never enabled, so MAME gets stuck in self-test forever (verified: frames 699-1900 byte-identical).
rtl/klax_addr_decode.v:12 Headline hardware facts modeled here (all differ from MAME's klax_map): - MA22/MA23 reach no decoder: the whole map MIRRORS x4 across the 24-bit space (only cpu_addr[21:0] participates below).
README.md:10 Where the two disagree, the silicon wins — so a few behaviours here deliberately differ from MAME.
README.md:96 MAME cannot reproduce this, because its Klax watchdog is never enabled.
README.md:154 **OKI MSM6295 ADPCM** decoding that is bit-exact against a MAME-0.288 golden model, plus — unlike MAME, which models none — the PCB's **analog audio output filt

Cites MAME source — 49

Klax.sv:4 Debuted 1989; MAME dates every set 1990 from the ROMs' own internal build stamps (parent set: 13FEB1990 11:10:09), and the MRAs follow.
Klax.sv:211 JAMMA "Button 2" is an alternative pin, not a second function, which is why MAME declares only BUTTON1 per player.
rtl/klax_addr_decode.v:6 The schematic draws a 24-pin PAL20L10 at 11C, but Sheet 3 notes "USE 16L8 IF SLAPSTIK IS NOT USED" — production Klax has no slapstic, and the 16L8-class GAL at 11C is exactly what MAME dumped.
rtl/klax_cpu_bus.v:36 MAME differs on both counts (no wait states, unmapped reads return 0) — silicon over MAME.
rtl/klax_eeprom.v:5 MAME map: 0x0E0000-0x0E0FFF, .umask16(0x00ff) 0x1F0000-0x1FFFFF write unlock
rtl/klax_inputs.v:5 P1 bit 11 is the active-high screen vblank status line from MAME's P1 port definition.
rtl/klax_inputs.v:8 MAME reference: klax.cpp input_ports, P1/P2 definitions.
rtl/klax_irq.v:19 MAME divergence (intentional, silicon over MAME): MAME's scanline timer (klax.cpp scanline_update, every 32 lines, "(scanline & 32) == 0 && !vblank") fires an EXTRA IRQ4 at scanline 0 that the real circuit cannot generate.
rtl/klax_mob_ram.v:4 CPU-visible storage from the MAME Klax map: 0x3F0F80-0x3F0FFF: Motion object SLIP RAM, 128 bytes / 64 words 0x3F2000-0x3F27FF: Motion object RAM, 2 KB / 1024 words
rtl/klax_motion_objects.v:20 mame/sprite.h draw_async() — sprite bitmap sized to the
rtl/klax_motion_objects.v:22 mame/klax.cpp s_mob_config — all field masks; gfx layout
rtl/klax_motion_objects.v:25 Coordinate model (equivalent to MAME's clipping; proved in simulation against the atarimo.cpp reference quoted above): top9 = (0 - (yfield + height*8)) & 511 delta9 = (line - top9) & 511, covers iff delta9 < height*8 X writes wrap mod 51
rtl/klax_motion_objects.v:39 Measured over the attract-mode gameplay demo (MAME, frames 2400-3600): Klax peaks at only 4 motion objects on any scanline (<=14 distinct/frame), vs the 1024-link iteration cap (MAME's MAX_PER_BANK, implemented below) and the time budget (p
rtl/klax_motion_objects.v:142 Decoded object (atarimo.cpp render_object field extraction)
rtl/klax_motion_objects.v:152 Y coverage (verified atarimo.cpp math, 9-bit domain)
rtl/klax_motion_objects.v:177 Tile column draw position: with hflip the first code is drawn at the rightmost column (atarimo.cpp:479-484)
rtl/klax_oki6295.v:4 MAME reference (0.288): okim6295.cpp / okiadpcm.cpp; klax.cpp configures OKIM6295(config, "oki", 14.318181 MHz / 4 / 4, PIN7_HIGH) and maps byte read/write at 0x270001 on the 68000 lower data lane.
rtl/klax_oki6295.v:22 - The MAME region is 0x40000 bytes with only 0x00000-0x1FFFF loaded from ROM; the rest is zero-filled, so byte reads above 128KB return 0x00 (phrases reaching there decode silence-ish ramps, busy stays set for the programmed length).
rtl/klax_oki6295.v:29 This is the integer-exact equivalent of MAME's float stream (add_int scale 2048, stream unit mapped to 32768).
rtl/klax_oki6295.v:39 - The busy bit rises a few hundred ns after the second command byte (phrase table fetch); MAME models it as instant.
rtl/klax_oki6295.v:77 Phrase addresses are 18 bits (masked to 0x3FFFF like MAME); nibble addresses carry one extra LSB.
rtl/klax_oki6295.v:200 Byte feeding the decoder: addresses above the 128KB ROM load read as 0x00 (MAME zero-fills the unloaded top half of the 0x40000 region).
rtl/klax_oki6295.v:403 Any byte is consumed here, even one with bit 7 set (MAME: the voice mask is simply bits 7:4).
rtl/klax_oki6295.v:459 signal * volume_fraction with MAME's truncate-toward-zero rounding then a >>>5 scale.
rtl/klax_oki6295.v:472 clamp(16 * sum, -32768, +32767): one full-volume voice spans the full output range; concurrent loud voices saturate, exactly like MAME's stream conversion.
rtl/klax_oki6295.v:608 MAME okim6295 volume table: ~3dB steps, indexes >= 9 are silent.
rtl/klax_palette.v:12 The game never sets CBANK, so bank 0 is the only one it ever uses — MAME models exactly that slice (1KB byte palette at 0x3E0000-0x3E07FF on the upper data lane, klax.cpp .umask16(0xff00)).
rtl/klax_playfield.v:12 Tile entry format (from MAME klax.cpp:125-132): data1 = pf_ram[tile_index]: [12:0] = tile code (0..8191, indexes into tile ROM) [15] = flip_x (horizontal flip) data2 = pfx_ram[tile_index]: [11:8] = color bank (0..15)
rtl/klax_playfield.v:32 MAME references: klax.cpp:125-132 get_playfield_tile_info klax.cpp:405 TILEMAP config: TILEMAP_SCAN_COLS, 60, 32 klax.cpp:403 PALETTE: IRGB_1555, 512 entries, 8-bit membits klax.cpp:366 GFXDECODE: tiles at palette base 2
rtl/klax_playfield.v:119 Klax hardware has NO playfield scroll registers: the tilemap is drawn at a fixed origin (MAME agrees - klax.cpp instantiates TILEMAP_SCAN_COLS 60x32 and never calls set_scrollx/set_scrolly), and all three klax_playfield instantiations tie s
rtl/klax_playfield.v:189 MAME is identical: IRGB_1555 -> pal6bit((c << 1) | i).
rtl/klax_prog_rom.v:43 Convert the flat MRA stream to the MAME/68000 byte layout in hardware.
rtl/klax_sys.v:152 See klax_watchdog.v for the silicon reference and the note on MAME leaving its watchdog disabled.
rtl/klax_sys.v:302 D10 coin counter 2 (right) D11 coin counter 1 (left) D12 spare D13 color-RAM bank select MAME models the write as a no-op (klax.cpp latch_w() is empty).
rtl/klax_sys.v:304 A MAME trace of a full boot+attract+demo run shows the game only ever drives D8 -- written 0 then 1 once at boot (pc 0x005c7c/94, ~frame 6) and never touched again; D13 is never set and the coin counters only click an external mechanical me
rtl/klax_sys.v:344 Keeping them separate keeps the chip model pure and independently verifiable against MAME.
rtl/klax_top_mister.v:651 Silicon DAC truth (schematic Sheet 9): 6-bit R/2R ladder per channel, LSB = the shared intensity bit ({color5, I}); MAME's IRGB_1555 decoder is identical (pal6bit((c << 1) | i)).
README.md:8 It was built from the PCB schematics and the dumped on-board PALs, with MAME as a cross-reference rather than as the specification.
README.md:132 MAME models no wait states at all.
README.md:136 **MAME fires an extra IRQ4 at scanline 0 that the silicon cannot produce**; this core follows the silicon.
README.md:141 MAME leaves its Klax watchdog disabled, so it never fires at all.
README.md:177 These cannot be settled from dumps, schematics or MAME, and would need measurement on a real PCB.
README.md:202 | Playfield renderer | MAME-dumped tilemap and palette RAM rendered through the RTL pipeline, compared against MAME's own frame | Pixel-exact |
README.md:203 | Motion objects | MAME-dumped MOB, SLIP, tilemap and palette RAM rendered through the full MiSTer top, compared against MAME at 336 × 240 | 98.50 % match at of
README.md:205 | Tile pixel decode | Compared pixel-by-pixel against the MAME tile formula | Exact |
README.md:206 | OKI MSM6295 | Sample-for-sample against a MAME-0.288-equivalent golden model, driven by the real sample ROMs | Bit-exact in audio and status, zero mismatches
README.md:311 Klax debuted in 1989; the ROMs' own internal build stamps read 1990, which is why MAME dates every set 1990 and the MRAs follow.
README.md:319 **The MAME team** — `klax.cpp` (Aaron Giles), `atarimo.cpp`, `okim6295.cpp` and `okiadpcm.cpp` were the cross-reference for everything the schematics do not set
README.md:321 References in the RTL comments of the form `mame/klax.cpp` point at MAME's own sources.

Says it matches, follows or was checked against MAME — 7

rtl/klax_motion_objects.v:10 Behavior is implemented from verified MAME 0.288 sources: mame/atarimo.cpp build_active_list() — SLIP[line>>3] start link, linked walk on word0[7:0], visited-array stop, MAX_PER_BANK=1024 iteration cap (maxperline=0) mame/atarimo.cpp ren
rtl/klax_motion_objects.v:43 The line abort is therefore unreachable by Klax content (~250x margin); MAME models no time-based dropout (maxperline=0 -> the 1024 cap only), so the RTL matches MAME in every case the game produces.
rtl/klax_oki6295.v:9 Verified bit-exact against a MAME-0.288-equivalent golden model by a sample-for-sample parity testbench driven by the real Klax sample ROMs.
rtl/klax_oki6295.v:13 Behavioral contract (matches MAME exactly): - Command protocol: a byte with bit 7 latches a pending sample number; the next byte (any value, even with bit 7 set) is the second half: voice mask in bits 7:4, volume index in bits 3:0.
rtl/klax_sys.v:342 === OKI MSM6295 ADPCM Sound === u_oki is the chip (bit-exact vs MAME); u_audio_filter is the board's analog output stage around it (Sheet 4).
rtl/klax_top_mister.v:132 Totals/visible: verified from MAME klax.cpp set_raw.
README.md:154 **OKI MSM6295 ADPCM** decoding that is bit-exact against a MAME-0.288 golden model, plus — unlike MAME, which models none — the PCB's **analog audio output filt

Shares text with the MAME driver without saying so — 1

rtl/klax_oki6295.v:6 OKIM6295(config, "oki", 14.318181 MHz / 4 / 4, PIN7_HIGH) and maps byte — shares text with atari/klax.cpp:432

Kyugo#
Airwolf, Flashgal, Gyrodine, Legend …
MiSTer-devel/Arcade-Kyugo_MiSTer @ 2243bbd8
MAME compared: orca/kyugo.cpp
Read: 8 HDL files, 2,319 lines (Quartus project)

MiSTer official

Mostly MAME

low

68%

Statements: 1 toward hardware, 41 toward MAME

Says it was checked on “real hardware” — 1

rtl/Kyugo_CPU.sv:1068 The flip_req branch (sy_calc - 16) is a MEASURED offset against a matched MAME reference frame, confirmed on hardware.

Cites MAME source — 31

Arcade-Kyugo.sv:66 Kyugo is MIXED-orientation per MAME ROT (vertical: Gyrodine/Repulse/99/SonOfPhoenix/SRD; horizontal: Flashgal/Legend/Airwolf).
rtl/Kyugo_CPU.sv:6 MAME reference: kyugo.cpp Hardware: Z80 CPU1 + Z80 CPU2 @ 3.072 MHz (XTAL 18.432 / 6) 2x AY-3-8910 @ 1.536 MHz (18.432 / 12) Screen: 396x260 total, visible 288x224 (lines 16-239), 59.66 Hz
rtl/Kyugo_CPU.sv:201 ------------------------------------------------------- Watchdog (Gyrodine) -------------------------------------------------// Watchdog (the cold-boot SUB-CHECK recovery mechanism — see wdog_arm above): MAME gyrodine() adds WATCHDOG_TIMER;
rtl/Kyugo_CPU.sv:273 Sub CPU memory decode — variant-aware (kyugo.cpp 484-532)
rtl/Kyugo_CPU.sv:313 I/O port decode — variant-aware (kyugo.cpp 547-583) AY1 base port: Gyro/Repulse = 0x00, Flashgal = 0x40, SRD/Legend = 0x80 AY2 base port: Gyro = 0xC0, Repulse = 0x40, Flashgal = 0x80, SRD/Legend = 0x84 Coin counter: Repulse/Flashgal = 0xC0/
rtl/Kyugo_CPU.sv:338 Coin counter (bit 0 of data per MAME coin_counter_w)
rtl/Kyugo_CPU.sv:423 CPU1 data bus mux — spram1 reads return value | 0xF0 (lower nibble only per MAME spriteram_2_r)
rtl/Kyugo_CPU.sv:550 MAME negates BG scroll_x whenever the game requests flip (kyugo.cpp:409-412: set_scrollx(0, -(lo+hi*256)) if flip_screen() else positive; scroll_y is never negated, :414).
rtl/Kyugo_CPU.sv:557 World offset when not flipped is +32 (MAME set_scrolldx(-32, ...), kyugo.cpp:271; world offset = -dx).
rtl/Kyugo_CPU.sv:573 base_h_cnt's total period (396, kyugo.cpp:946 screen.set_raw(...,396,0,288,260, 16,240)) is not a multiple of 8, and v_cnt only increments on the same tick base_h_cnt wraps 395->0 -- too late for column 0 of the new row to be ready via the
rtl/Kyugo_CPU.sv:663 Per-tile attr flips (bit2=flipX, bit3=flipY, MAME get_bg_tile_info) still apply as normal.
rtl/Kyugo_CPU.sv:715 MAME get_bg_tile_info: TILE_FLIPYX((attr&0x0c)>>2) -> flipX = attr bit 2, flipY = attr bit 3.
rtl/Kyugo_CPU.sv:719 flipX = attr bit 2 (MAME)
rtl/Kyugo_CPU.sv:720 flipY = attr bit 3 (MAME)
rtl/Kyugo_CPU.sv:750 Pen = {plane0, plane1, plane2}: MAME planeoffset[0] (= first ROM third, bg0) is the MSB.
rtl/Kyugo_CPU.sv:780 6-bit colour code: MAME color = color_codes[4:0]<<1 | fgcolor
rtl/Kyugo_CPU.sv:855 Pen = {plane0, plane1}: plane0 (fg_p0_bit, high nibble) is the MSB per MAME planeoffset[0].
rtl/Kyugo_CPU.sv:860 {color_codes[4:0], fgcolor, pen[1:0]} per MAME
rtl/Kyugo_CPU.sv:937 MAME sy/sx wrap (sy = (257 - y_raw); if > 240 then -256)
rtl/Kyugo_CPU.sv:941 MAME computes this sx wrap in a wide int (kyugo.cpp:369-370: sx = (x>320) ?
rtl/Kyugo_CPU.sv:950 Row hit (in SS_FR0): diff = eval_y - sy_full (9-bit two's complement); hit if diff[8:8]=0 (positive) Sprite row-stacking direction: MAME draws cell row y at `sx, flip ?
rtl/Kyugo_CPU.sv:951 sy - 16*y : sy + 16*y` (kyugo.cpp:401) -- when flipped, the 16 cells of a sprite stack UPWARD from sy instead of downward.
rtl/Kyugo_CPU.sv:974 Per-sprite flip attributes must invert when the game requests flip (MAME kyugo.cpp:391-395: if (flip) { flipx = !flipx; flipy = !flipy; }).
rtl/Kyugo_CPU.sv:978 flipx is XORed with flip_req: the screen_x pre-mirror below (screen_x_signed) cancels the rotation's position mirror on this axis but not MAME's per-cell mirror, so flipx must supply that mirror itself.
rtl/Kyugo_CPU.sv:980 flipy needs no XOR: the rotation's Y mirror already supplies MAME's flipy inversion, sy mirror, and stacking reversal together.
rtl/Kyugo_CPU.sv:997 Pen = {plane0, plane1, plane2}: MAME planeoffset[0] (= first ROM third, spr0) is the MSB.
rtl/Kyugo_CPU.sv:1003 MAME's sprite flip is asymmetric: it mirrors sy (240-sy), inverts flipx/flipy and reverses stacking, but passes sx through UNCHANGED (kyugo.cpp:401).
rtl/Kyugo_CPU.sv:1004 screen_rotate mirrors both render axes, which is correct for BG (MAME's tilemap flip also does both) but over-mirrors sprites on X -- render X is the displayed vertical on the ROT90 sets.
rtl/Kyugo_CPU.sv:1062 Sprite Y mirror: MAME applies `if (flip) sy = 240 - sy;` AFTER the 257-raw wrap (kyugo.cpp:376-377), so it applies to sy_calc here, not to sy_y_raw.
rtl/Kyugo_CPU.sv:1063 MAME does NOT mirror sprite X when flipped -- sx is passed through unchanged at kyugo.cpp:401 -- so sx_full stays as-is; that asymmetry is intentional on the reference hardware, not a bug here.
rtl/Kyugo_CPU.sv:1069 The algebra from MAME's `240 - raw` predicts -17; the measured, HW-confirmed value is -16.

Says it matches, follows or was checked against MAME — 6

rtl/Kyugo_CPU.sv:47 Pixel clock: 49.152 MHz * 4/32 = 6.144 MHz = XTAL/3 (matches MAME set_raw(XTAL/3, 396, 0, 288, 260, 16, 240) → 59.6575 Hz).
rtl/Kyugo_CPU.sv:945 Computed in an 11-bit signed field instead so 256..320 stays positive and only 321..511 goes negative, matching MAME exactly.
rtl/Kyugo_CPU.sv:1006 Pre-mirroring here cancels the rotation's X mirror, leaving sprites unmirrored in display space to match MAME; mirroring preserves the in-range test since out-of-range values stay out on both sides.
rtl/Kyugo_CPU.sv:1009 Cell-internal orientation and stacking direction need no separate correction: the rotation's both-axis mirror already matches MAME inverting both flipx and flipy, and the +16y stacking used here plus the rotation lands the same as MAME's -1
rtl/Kyugo_CPU.sv:1068 The flip_req branch (sy_calc - 16) is a MEASURED offset against a matched MAME reference frame, confirmed on hardware.
rtl/Kyugo_CPU.sv:1142 Matches MAME screen_update, which draws BG → sprites → FG, so FG is always on top.

Shares text with the MAME driver without saying so — 4

rtl/Kyugo_CPU.sv:47 Pixel clock: 49.152 MHz * 4/32 = 6.144 MHz = XTAL/3 (matches MAME set_raw(XTAL/3, 396, 0, 288, 260, 16, 240) → 59.6575 Hz). — shares text with orca/kyugo.cpp:946
rtl/Kyugo_CPU.sv:928 Slot offset: offs = 2*(n%12) + 64*(n/12), then base 0x28 — shares text with orca/kyugo.cpp:366
rtl/Kyugo_CPU.sv:951 Sprite row-stacking direction: MAME draws cell row y at `sx, flip ? sy - 16*y : sy + 16*y` — shares text with orca/kyugo.cpp:401
rtl/Kyugo_CPU.sv:975 if (flip) { flipx = !flipx; flipy = !flipy; }). Unlike the BG, which gets its mirror for free — shares text with orca/kyugo.cpp:391

LadyBug#
Cosmic Avenger, Dorodon, Lady Bug, Snap Jack
MiSTer-devel/Arcade-LadyBug_MiSTer @ c91b6267
MAME compared: universal/ladybug.cpp + 2 related file(s)
Read: 30 HDL files, 10,443 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 2 toward hardware

Cites hardware documentation that MAME's driver does not — 2

rtl/ladybug_video_timing.vhd:353 From the schematics, it is the same as /VBL (just buffered).
rtl/ttl_393.vhd:3 TTL 74LS393 - Dual 4-Bit Binary Counter

LaserdiscGames#
Cliff Hanger, Dragon's Lair, Space Ace
MiSTer-devel/Arcade-LaserdiscGames_MiSTer @ d0ba4d41
MAME driver: not found
Read: 38 HDL files, 11,677 lines (Quartus project)

MiSTer official

Both

medium

67%

Statements: 25 toward hardware, 53 toward MAME

Cites hardware documentation that MAME's driver does not — 3

Arcade-LaserdiscGames.sv:137 Program bytes occupy a different slice of ioctl index 0 per game, so the write MUST be gated per board -- ungated, Super Don's char and PROM data would land on top of program space, and Mach 3's tile and sprite data would wrap round the 64K
rtl/DragonsLair_CPU.sv:162 Bank select = A15:A13, device select = A5:A3 (A3/A4/A5 per the schematics)
rtl/superdon/SuperDon.sv:4 Memory: 0x0000-0x3FFF ROM (16K) 0x4000-0x47FF RAM (2K) 0x5C00-0x5FFF video RAM (1K, 32x32 tile codes) Ports: IN 00 joystick 01 buttons/coins 02 DSW1 03 DSW2 04 LD status OUT 00 LD command 04 SN76496 08 latch 0C/0D HD46505 (fixe

Ships hardware documentation files — 21

Notes where it differs from MAME — 1

rtl/superdon/SuperDon.sv:17 Read off the Main PCB (1) schematic -- MAME's MASTER_CLOCK/8 is wrong, Daphne's 5 MHz is right.

Cites MAME source — 43

Arcade-LaserdiscGames.sv:106 One Gottlieb/Mylstar rev-2 board runs all three; MAME's cobram3 config differs from g2laser only in sound-board mods.
Arcade-LaserdiscGames.sv:148 Dragon's Lair II has NO scoreboard: the original scored nothing, Daphne's lair2.cpp contains no scoreboard code at all (unlike lair.cpp) and MAME's dlair2.cpp instantiates no such device.
Arcade-LaserdiscGames.sv:780 4-way stick + one action button; MAME superdq IN0/IN1
rtl/DragonsLair_CPU.sv:208 SSI-263 speech chip, ports 0x00-0x07 (MAME thayers.cpp maps all eight; the chip ignores the register address on reads).
rtl/DragonsLair_CPU.sv:369 XCK is 860 kHz (MAME thayers.cpp: SSI263HLE(config, m_ssi, 860000)).
rtl/DragonsLair_CPU.sv:517 ------------------------------------------------- Thayer's COP421 + interrupts -----------------------------------------------// The COP is Thayer's only MCU: its D port drives the timer tick (D0) and keyboard data-ready (D1), both active l
rtl/DragonsLair_CPU.sv:534 The periodic source is a board one-shot: T = 1.1 * R30 * C53 = 8.25 ms (MAME thayers.cpp).
rtl/DragonsLair_CPU.sv:555 IN (0x40): b7 and b1:0 read 0, b3 is tied to +5V (MAME irqstate_r).
rtl/DragonsLair_CPU.sv:588 Z80 writes a 4-bit digit code: 0xE038-0xE03F (led_den1) -> digits[0..7] (MAME led_den1_w: m_digits[0|off]) 0xE030-0xE037 (led_den2) -> digits[8..15] (MAME led_den2_w: m_digits[8|off]) The 7-seg lookup (led_map in MAME) is applied at rend
rtl/DragonsLair_CPU.sv:598 den1 (E038) -> digits 0..7 (MAME dlair.cpp:332)
rtl/DragonsLair_CPU.sv:599 den2 (E030) -> digits 8..15 (MAME dlair.cpp:338)
rtl/Thayers_COP.sv:135 The COP free-runs SK; on each FALLING edge the panel shifts out one bit of a 10-bit frame (Daphne/MAME thayers.cpp kbclk_w):
rtl/cliff/CliffHanger.sv:11 Memory map (MAME mainmem): 0x0000-0x9FFF program ROM (5 x 8KB; the map extends to 0xBFFF, unpopulated) 0xE000-0xE7FF battery-backed NVRAM (5126) -- volatile here, see note 0xE800-0xEFFF RAM (2128)
rtl/cliff/CliffHanger.sv:117 --------------------------------------------------------- I/O decode ----- MAME mainport (global mask 0xFF).
rtl/cliff/CliffHanger.sv:133 --------------------------------------------------------- input banks ---- MAME port_r: banks 0..6 are mapped, anything above reads pulled-up 0xFF.
rtl/cliff/CliffHanger.sv:145 Bit assignments are MAME's (INPUT_PORTS_START(cliffhgr) BANK5/BANK6); Daphne only labels these "button data" / "joystick data".
rtl/cliff/CliffHanger.sv:233 ---- Philips VBI picture code (MAME philips_code_r) ---- 24 bits: 0xF in the top nibble marks a valid picture number, so bit 23 is set and the IRQ fires; the low 20 bits are the frame as 5 BCD digits.
rtl/cliff/CliffHanger.sv:395 --------------------------------------------------------- interrupts ----- IRQ: asserted when a valid Philips code arrives each field, cleared by reading port 0x53 (MAME irq_ack_r).
rtl/cliff/CliffHanger.sv:407 --------------------------------------------------------- sound ---------- Discrete: two gated 555 astables mixed (MAME cliffhgr_a.cpp).
rtl/cliff/CliffHanger.sv:457 MAME stern/cliffhgr.cpp: `m_led = offset ^ 1`, offset 0 = 0x6E = lit.
rtl/cliff/CliffHanger.sv:477 MAME returns 0
rtl/cliff/tms9928a_render.sv:29 Measured against MAME on the title screen: 453 wrong pixels, 86% of them at cell pixel 0 or 7.
rtl/cliff/tms9928a_render.sv:129 ---- Graphics II tables ------------------------------------------------ Bases and masks per MAME tms9928a.cpp (update_table_masks + the mode-2 draw loop).
rtl/cliff/tms9928a_render.sv:181 A zero nibble means "use the backdrop", as MAME's mode-2 loop does.
rtl/cliff/tms9928a_render.sv:230 MAME makes that conditional on EXTVID (reg0[0]) and otherwise paints colour 0 as a real pen; we do not, deliberately.
rtl/cliff/tms9928a_render.sv:236 It resolves to the backdrop, and a non-zero backdrop really does cover the picture on a real TMS -- MAME only makes pen 0 transparent, never the backdrop as such.
rtl/dlair2/DragonsLair2.sv:4 I8088 in MAX mode at 10 MHz (MAME cinematronics/dlair2.cpp: XTAL(30MHz)/3, "Schematics show I8088 'max' CPU"), Sony LDP-1450 on a serial port.
rtl/dlair2/DragonsLair2.sv:11 Memory map (MAME mainmem): 0x00000-0xEFFFF RAM -- external port, backed by DDR (ddram_cpu_ram); it cannot live on-chip, the core is at 75% of its M10K blocks.
rtl/dlair2/DragonsLair2.sv:17 IO map (MAME, commented there; corroborated by Daphne lair2.cpp's header "IO_PORT = 0x201, COIN_PORT = 0x202, CNTL_PORT = 0x202"): 0x020 interrupt controller 0x042/0x043, 0x061 sound 0x200-0x203 io / coin / eeprom 0x2F8-0x2FF COM
rtl/dlair2/DragonsLair2.sv:45 ---- controls ---- DL2 has NO DIP switches: its settings live in an EEPROM (port 0x202 b0), which is why MAME's dlair2 DIPs are explicit dummies and the OSD shows no DIP page.
rtl/dlair2/DragonsLair2.sv:287 MAME is no reference here: dlair2.cpp attaches SPEAKER with no sound device, so it emulates none of this.
rtl/dlair2/DragonsLair2.sv:427 --------------------------------------------------- 8259 + timer -------- MAME models two interrupts: a 60 Hz periodic one whose vector_r returns 0x20/4 = 8, and a serial one at 0x2c/4 = 11.
rtl/gpworld/GPWorld.sv:4 Memory: 0x0000-0xBFFF ROM (48K) 0xC000-0xC7FF sprite RAM (64 x 8) 0xC800-0xCFFF colour RAM 0xD000-0xD7FF tile RAM (64x32 codes) 0xD800 LD-V1000 latch 0xDA00-0xDA03 8255 (sound board) 0xDA20 pedal ADC 0xE000-0xFF
rtl/gpworld/GPWorld.sv:203 IN0 b4 SHIFT; IN1 b0 COIN1, b1 COIN2, b2 TEST, b3 SERVICE, b4 START (MAME).
rtl/gpworld/gpw_spr_mem.sv:13 Download: ioctl index 0, 0x10000-0x3FFFF = MAME's gfx2 region (0x8000 bytes of plane 0 then 0x8000 of plane 1, per 64K bank).
rtl/ldp/ldp_ldp1450.sv:72 ACK latencies from the LDP-1000A programming manual (ldp1000.cpp:99-102).
rtl/ldp/ldp_transport.sv:67 MAME update_audio_enable(): unmute only at mode==PLAY && speed==1x && both channels on.
rtl/mach3/Mach3.sv:5 MAME gottlieb/gottlieb.cpp `g2laser`; schematics in Useful Information/schematics/mach3_s.pdf (Logic Board A1, Interface A2).
rtl/mach3/Mach3.sv:23 A write to 5805 latches a byte and the board clocks 12 bits out to the player as pulse INTERVALS: 998us = 0, 1996us = 1 (555 at 40083Hz /10, then /4 or /8 — gottlieb.cpp:876).
rtl/mach3/Mach3.sv:364 MAME reads these ports straight through; the top level assembles them with the right polarity (SERVICE b0 and TILT b5 of IN1 are active LOW, everything else active HIGH).
rtl/mach3/mach3_video.sv:4 Shared by M.A.C.H. 3, Cobra Command and Us vs Them: MAME's cobram3 machine config differs from g2laser only in sound-board mods, so the video hardware is identical across all three.
rtl/mach3/mach3_video.sv:23 Values below are that ladder normalised to full scale; they come from MAME's documented resistances (gottlieb.cpp video_start) — sweep these first if colours look wrong on hardware, since the Logic Board A1 sheet was not available to confir
rtl/superdon/SuperDon.sv:162 Active-LOW banks (MAME superdq INPUT_PORTS).

Says it matches, follows or was checked against MAME — 4

rtl/DragonsLair_CPU.sv:581 The COP asserts on the falling edge of its D pins, matching MAME's cop_d_w.
rtl/ldp/ldp_ldv1000.sv:67 known-inert group (matches MAME's own unimplemented stubs)
rtl/ram_rom/rom_loader.sv:3 Kangaroo ROM loader ROM layout matched to MAME kangaroo.cpp
rtl/video/led_band.v:11 (matches MAME dlair.lay / DragonsLair_CPU)

Says it was translated, ported or taken from MAME — 5

Arcade-LaserdiscGames.sv:2 Dragon's Lair / Space Ace (US set) for MiSTer Copyright (C) 2026 Rodimus Based on MAME dlair.cpp; converted in place from the Kangaroo core copy Permission is hereby granted, free of charge, to any person obtaining a copy of this software a
rtl/DragonsLair.sv:2 Dragon's Lair / Space Ace (US set) top-level game module Copyright (C) 2026 Rodimus Based on MAME dlair.cpp Thin wrapper around DragonsLair_CPU (which now contains the Z80, AY-3-8910, work RAM, program ROM, the LaserDisc HLE, the LED latche
rtl/DragonsLair_CPU.sv:2 Dragon's Lair / Space Ace (US set) Main CPU Board Based on MAME dlair.cpp (dlus_map / dlair_ldv1000) by Aaron Giles Single Z80 @ (real 4 MHz) + AY-3-8910 (real 2 MHz) + Pioneer LD-V1000 laserdisc.
rtl/cliff/CliffHanger.sv:3 Based on MAME stern/cliffhgr.cpp (authoritative for the I/O map and the discrete sound) and Daphne game/cliff.cpp (authoritative for PR-8210 use).
rtl/ldp/ldp_ldv1000.sv:4 Ported from MAME pioneer_ldv1000hle_device.

Keeps a MAME approximation — 1

rtl/gpworld/GPWorld.sv:413 MAME swaps R and B; both are guesses -- flip PAL_RB_SWAP to try MAME's.

Legionnaire#
Legionnaire
MiSTer-devel/Arcade-Legionnaire_MiSTer @ 39c3eb79
MAME compared: seibu/legionna.cpp + 8 related file(s)
Read: 23 HDL files, 9,221 lines (Quartus project)

MiSTer official

Mostly MAME

medium

74%

Statements: 4 toward hardware, 145 toward MAME, 1 not counted

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/Legionnaire/Legionnaire_maincpu_map.sv:23 Main CPU memory map Legionnaire (MAME legionna.cpp legionna_map): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $100000-$1003FF RAM scratch (1KB) → BRAM (Main RAM low) $100400-$1006FF COP3 region — also in MAME: 68K seibu/legionna.cpp:46

Reports a measurement taken on the original PCB — 1

rtl/Legionnaire/Legionnaire_video_timing.sv:26 PCB measurement Blood Bros: VSync 59.4094 Hz, HSync 15.6246 kHz, master XTAL 20 MHz.

Says it was checked on “real hardware” — 3

rtl/Legionnaire/Legionnaire_sprite_renderer.sv:208 byte_lo = pf_rom_data[31:24]/[15:8], byte_hi = [23:16]/[7:0] Plane order DCBA (verificato su HW, come BG/MG/FG): pen[0] dal bit "D" (byte_hi[3-sub]), pen[3] dal bit "A" (byte_lo[7-sub]).
rtl/Legionnaire/Legionnaire_sprite_renderer.sv:325 Scan INVERSO 511→0 (verificato su HW: ordine sprite-su-sprite opposto al loop MAME 0→511).
rtl/Legionnaire/Legionnaire_tile_layer.sv:296 Plane order verificato su HW: BG/MG = DCBA (PEN_ORDER=0), FG = BADC (PEN_ORDER=1).

Cites MAME source — 130

Legionnaire.sv:330 --- Joystick to SD Gundam input mapping --- MAME P1_P2 port ($E0002): active low.
Legionnaire.sv:333 MiSTer joy bits: joy[0]=R, joy[1]=L, joy[2]=D, joy[3]=U, joy[4]=A, joy[5]=B. MAME PLAYERS12 (legionna.cpp:439-444): bit[0]=UP, [1]=DOWN, [2]=LEFT, [3]=RIGHT, [4]=BTN1, [5]=BTN2, [6]=BTN3, [7]=unused (active low).
Legionnaire.sv:343 Legionnaire SYSTEM port ($10074C) — MAME legionna.cpp:427-436 bit0 = START1 (active LOW) bit1 = START2 (active LOW) bit2..7 = UNKNOWN → tied 1 bit8..15 = UNKNOWN → tied 1 Coin inputs NON sono qui: vanno via SEIBU_COIN_INPUTS → Z80 → soundla
Legionnaire.sv:686 ── Flip screen (CRTC reg 0x1A bit 0) ─────────────────────────────────────── MAME: BIT(reg_1a, 0) → flip_screen.
Legionnaire.sv:719 ── Text layer renderer (8x8, 4bpp, 64x32 grid) ───────────────────────────── Legionnaire MAME (legionna.cpp:1563-1571): "user1" region 128KB caricato da 7.u077 + 8.u072 interleaved a 16-bit.
Legionnaire.sv:740 Blood Bros Text: no scroll (MAME bloodbro.cpp non chiama set_scroll su tx_tilemap)
Legionnaire.sv:774 Legionnaire CRTC scroll passthrough (MAME legionna_v.cpp:34-49 tile_scroll_w): scroll_ram[0/1] → BG (m_background_layer) scroll_ram[2/3] → MG (m_midground_layer) scroll_ram[4/5] → FG (m_foreground_layer) Nel nostro CRTC: xscroll_l0 = ram[0/
Legionnaire.sv:792 Legionnaire BG: tilemap 32x32 (legionna_v.cpp:204).
Legionnaire.sv:793 MAME GFXDECODE "back" color base = 0 (gfx_legionna riga 1168), 32 colorset.
Legionnaire.sv:794 HAS_TRANSP=1 perché m_background_layer->set_transparent_pen(15) in legionna_v.cpp:216 (pen 15 = trasparente, NON opaco come Blood Bros).
Legionnaire.sv:816 Legionnaire MG: 16x16, 4bpp, 32x32 tilemap (MAME legionna_v.cpp:204).
Legionnaire.sv:817 get_mid_tile_info_share_bgrom (legionna_v.cpp:158): MG share BG ROM, tile = (vram & 0xfff) | 0x1000 (= seconda metà della BG ROM) color = ((vram >> 12) & 0xf) | 0x10 (= palette set superiore: bit 4 = 1) In palette MAME "back" base = 0,
Legionnaire.sv:844 Legionnaire FG: tilemap 32x32 (legionna_v.cpp:213).
Legionnaire.sv:846 MAME GFXDECODE "fore" color base = 32*16 = 0x200, 16 colorset.
Legionnaire.sv:860 Legionnaire: bit 2 = FG (MAME legionna_v.cpp:344)
Legionnaire.sv:968 MAME riferimenti: legionna_v.cpp:226-229 m_sprite_pri_mask[0..3] per Legionnaire: pri=0 → 0x0000 (cover bit 0,1,2,4 → mg,bg,fg,text → SOPRA TUTTO) pri=1 → 0xFFF0 (cover bit 0,1,2 → mg,bg,fg → sotto text) pri=2 → 0xFFFC (cover bit 0,1 →
Legionnaire.sv:989 pen 0 (= nero su palette MAME BLACK init)
Legionnaire.sv:995 MAME legionna_v.cpp:340 fills bitmap with m_palette->black_pen() before drawing layers.
Legionnaire.sv:999 MAME screen_update_legionna (legionna_v.cpp:342-348): MG draw pri 0 → buffer bit 0 BG draw pri 1 → buffer bit 1 FG draw pri 2 → buffer bit 2 TXT draw pri 4 → buffer bit 4 sprite con pri_mask[N]: [0]=0x0000 (sopra tutti), [1]=0xFFF0 (sotto T
Legionnaire.sv:1046 MAME legionna_v.cpp:340 fa bitmap.fill(black_pen()) prima dei layer.
rtl/Legionnaire/Legionnaire_audio_z80.sv:25 Spec da MAME (reference/mame_seibu/seibusound.cpp + bloodbro.cpp): - Z80 @ 3.579545 MHz (XTAL 7.159090 / 2) - YM3812 (jtopl2) @ 3.579545 MHz - OKI M6295 (jt6295) @ 1.000 MHz (XTAL 12/12), PIN7=HIGH
rtl/Legionnaire/Legionnaire_audio_z80.sv:31 Main↔sub comm @ 0xA0000-0xA000D: standard MAME seibu_sound_device.
rtl/Legionnaire/Legionnaire_audio_z80.sv:359 MAME seibu_sound_device::main_r (reference/mame_seibu/seibusound.cpp:279): case 2,3: return sub2main[offset-2] (soundlatch data: coin/input dal Z80) case 5: return main2sub_pending ?
rtl/Legionnaire/Legionnaire_audio_z80.sv:392 ─── OKI M6295 (jt6295) — PIN7_HIGH (bloodbro.cpp:872) ──────────────────
rtl/Legionnaire/Legionnaire_cop3.sv:4 MAME-faithful implementation of the Seibu SEI300 chip as used by the `legionna` driver (Legionnaire 1992 — Banpresto/TAD).
rtl/Legionnaire/Legionnaire_cop3.sv:7 Reference (in this repo): reference/mame_seibu/seibucop.cpp reference/mame_seibu/seibucop_cmd.ipp reference/mame_seibu/seibucop_dma.ipp reference/mame_seibu/legionna.cpp
rtl/Legionnaire/Legionnaire_cop3.sv:128 MAME cop_itoa_digits[10]: BCD digits of cop_itoa (low<<0 | high<<16).
rtl/Legionnaire/Legionnaire_cop3.sv:138 MAME cop_program command table (seibucop.cpp lines 318-457) At boot, game code uploads 32 macro slots × 8 micro-op words via pgm_addr (0x100434) → slot*8 + sub-index pgm_data (0x100432) → micro-op word pgm_value (0x100438) → cop_func_valu
rtl/Legionnaire/Legionnaire_cop3.sv:145 MAME calls find_trigger_match(triggerval, 0xff00) to find the slot whose cop_func_trigger matches.
rtl/Legionnaire/Legionnaire_cop3.sv:209 Triggers (write-only addresses) MAME legionna.cpp:172 maps cop_cmd_w to $100500-$100505 (3 words).
rtl/Legionnaire/Legionnaire_cop3.sv:283 0x100410 sprite_dma_inc (MAME seibucop.cpp:1279): if x_clip in [-160, 320): cop_regs[4] += 8 cop_sprite_dma_src += 6; cop_sprite_dma_size--; cop_status bit 1 = (size > 0) ?
rtl/Legionnaire/Legionnaire_cop3.sv:286 0 : 1 (Sprite DMA x_clip non implementato: assumiamo in-range come MAME default per Legionnaire — il game non usa sprite DMA via COP comunque)
rtl/Legionnaire/Legionnaire_cop3.sv:324 Macro program upload — MAME seibucop.cpp lines 318-457 pgm_data writes one micro-op word to cop_program[latch_addr] AND latches the slot's trigger/value/mask from current latch regs.
rtl/Legionnaire/Legionnaire_cop3.sv:423 itoa_digits (MAME 0x100590-99, 5 word).
rtl/Legionnaire/Legionnaire_cop3.sv:435 Status / dist / angle (MAME seibucop.cpp:916 cop_status_r → cop_status)
rtl/Legionnaire/Legionnaire_cop3.sv:446 MAME open bus
rtl/Legionnaire/Legionnaire_cop3.sv:559 Trigger latches — MAME seibucop.cpp cop_cmd_w line 1069.
rtl/Legionnaire/Legionnaire_cop3.sv:560 MAME dispatches on raw data after clearing cop_status bit 15.
rtl/Legionnaire/Legionnaire_cop3.sv:687 MAME cop_cmd_w (seibucop.cpp:1075):
rtl/Legionnaire/Legionnaire_cop3.sv:723 Restituisce canonical trigger value del slot (NB: MAME LEGACY_cop_cmd_w usa il match slot per dispatchare; in pratica equivale a restituire cop_func_trigger[slot]).
rtl/Legionnaire/Legionnaire_cop3.sv:744 fade_table — MAME seibucop.cpp:733 (reverse engineered from Seibu Cup Soccer bootleg) v = pal_channel(5-bit) | (brightness_val_xor_X) [10-bit input] low = v & 0x1F high = v & 0x3E0 return (low * (high | (high>>5)) + 0x210) >> 10 [8-bit o
rtl/Legionnaire/Legionnaire_cop3.sv:781 ── Hitbox b100/b900 scratch (MAME cop_collision_update_hitbox) ────────────── dx[i] = int8 (signed) byte basso, size[i] = uint8 (unsigned) byte alto del word descrittore @ hitadr2+2*i. 3 assi (Y,X,Z) per Legionnaire.
rtl/Legionnaire/Legionnaire_cop3.sv:813 Con 16-bit frac + 24 iter + z>>16: 0 divergenze di decisione vs MAME int(atan(dx/dy)*128/pi) su ~640k casi (dimostrato numericamente).
rtl/Legionnaire/Legionnaire_cop3.sv:1045 MAME cop_dma_trigger_w: NON modifica cop_status (vedi seibucop.cpp:741).
rtl/Legionnaire/Legionnaire_cop3.sv:1051 MAME dma_tilemap_buffer: copy staging RAM → renderer BRAM src = cop_dma_src[mode] << 6 (byte addr 0x101000+ = staging) dst = i (loop counter 0..0x13FF = renderer index) count = 0x2800/2 = 5120 words
rtl/Legionnaire/Legionnaire_cop3.sv:1061 MAME dma_palette_buffer: copy staging palette → renderer src = cop_dma_src[mode] << 6 (0x104000 = palette staging) dst = i (loop counter 0..0x7FF = renderer index) count = 0x1000/2 = 2048 words
rtl/Legionnaire/Legionnaire_cop3.sv:1077 simplified, MAME size>>1
rtl/Legionnaire/Legionnaire_cop3.sv:1082 MAME seibucop_dma.ipp dma_palette_brightness() mode 5/4.
rtl/Legionnaire/Legionnaire_cop3.sv:1085 MAME formulas: src = cop_dma_src[mode] << 6 dst = cop_dma_dst[mode] << 6 size = ((cop_dma_size << 5) - (cop_dma_dst << 6) + $20)/2 Init: src=$106000, dst=$104000, size=($827F<<5 - $4100<<6 + $20)/2 = ($104FE0 - $104000 + $20)/2 = $1000
rtl/Legionnaire/Legionnaire_cop3.sv:1096 MAME size = (((size<<5) - (dst<<6) + 0x20)/2)
rtl/Legionnaire/Legionnaire_cop3.sv:1106 Skip if dst != 0 (MAME guard, dma.ipp:135)
rtl/Legionnaire/Legionnaire_cop3.sv:1119 MAME cop_cmd_w (seibucop.cpp:1073): cop_status &= 0x7fff (clear bit 15).
rtl/Legionnaire/Legionnaire_cop3.sv:1121 MAME: cop_status &= 0x7fff (clear bit 15).
rtl/Legionnaire/Legionnaire_cop3.sv:1140 MAME execute_0205: read dword at cop_regs[0]+4+offset*4 (ppos)
rtl/Legionnaire/Legionnaire_cop3.sv:1161 0x138e / 0x338e — atan(dx/dy) MAME execute_338e.
rtl/Legionnaire/Legionnaire_cop3.sv:1163 Parte da r1+4 hi (offset 0x0004), come 3BB0/MAME.
rtl/Legionnaire/Legionnaire_cop3.sv:1171 r1+4 hi (MAME read_dword(r1+4) primo)
rtl/Legionnaire/Legionnaire_cop3.sv:1186 MAME: raw_angle = cop_read_word(r0+0x34) = host_read_word(0x34^2 = 0x36); amp = cop_read_word(r0+0x36) = host_read_word(0x36^2 = 0x34).
rtl/Legionnaire/Legionnaire_cop3.sv:1203 0xa180 — collision read pos for slot 0 MAME cop_collision_read_pos: cop_read_word(spradr+N) = host_read_word((spradr+N)^2) per host_endian=true.
rtl/Legionnaire/Legionnaire_cop3.sv:1376 Macro 0x0205 — linear movement (MAME execute_0205) ppos = read_dword(cop_regs[0]+0x04) vel = read_dword(cop_regs[0]+0x10) npos = ppos + vel write_dword(cop_regs[0]+0x04, npos) delta = (npos>>16) - (ppos>>16) write_word(cop_regs[0]+0x1E, re
rtl/Legionnaire/Legionnaire_cop3.sv:1419 MAME cop_read/write_word(cop_regs[0]+0x1e) = host word @ (0x1e^2)=0x1c (host endianness word^2; conferma doc 06 micro-op 'addmem16 0x1C(r0)').
rtl/Legionnaire/Legionnaire_cop3.sv:1437 Macro 0x0905/0x0904 — jump (MAME execute_0904) write_dword(cop_regs[0]+0x10, read_dword(cop_regs[0]+0x10) ± read_dword(cop_regs[0]+0x28)) 0x0905 (bit 0=1) = +, 0x0904 (bit 0=0) = -
rtl/Legionnaire/Legionnaire_cop3.sv:1463 MAME execute_0904: bit 0 di data = 1 → add, =0 → sub tmp32_a = vel ± grav.
rtl/Legionnaire/Legionnaire_cop3.sv:1494 0x138E/0x338E atan(dx/dy) — MAME execute_338e (cmd.ipp:159) dx = read_dword(r1+4) - read_dword(r0+4) dy = read_dword(r1+8) - read_dword(r0+8) if(!dy){status|=0x8000; angle=0} else angle=atan(dx/dy)*128/pi; dy<0→+0x80 if(data&0x80) write_byt
rtl/Legionnaire/Legionnaire_cop3.sv:1542 MAME: angle = atan(dx/dy)*128/pi (+0x80 se dy<0).
rtl/Legionnaire/Legionnaire_cop3.sv:1544 Cosi' z = atan(dx/dy) e il +0x80 (in WR) copre solo il quadrante, come MAME.
rtl/Legionnaire/Legionnaire_cop3.sv:1546 NIENTE prescale: i dword diff sono FIXED-POINT coord<<16 (come il 3BB0 che usa dx32[31:16] e MAME dx>>16), NON interi piccoli.
rtl/Legionnaire/Legionnaire_cop3.sv:1587 MAME (int)(...) tronca VERSO ZERO.
rtl/Legionnaire/Legionnaire_cop3.sv:1589 BUG TROVATO (validato vs MAME su 29241 casi): il CORDIC SOTTO-CONVERGE di 1 LSB sulle DIAGONALI (es.
rtl/Legionnaire/Legionnaire_cop3.sv:1594 Compenso l'epsilon di sotto-convergenza con +1 toward-zero PRIMA del troncamento: bias=1 azzera tutte le 133 divergenze (bias=0) -> 0/29241 vs MAME.
rtl/Legionnaire/Legionnaire_cop3.sv:1603 MAME execute_338e (seibucop_cmd.ipp:175-188): la write dell'angolo in RAM (obj+0x34 host, gated da data&0x80) e' FUORI dall'if/else di dy -> avviene SEMPRE, anche a dy==0 (dove cop_angle=0 -> scrive 0^0x80 = 0x80).
rtl/Legionnaire/Legionnaire_cop3.sv:1609 Ora calcolo ang_byte in entrambi i rami e scrivo SEMPRE, come MAME.
rtl/Legionnaire/Legionnaire_cop3.sv:1616 Scrivere l'angolo anche a dy==0 ("1:1 MAME") REGREDISCE: il martello scivola/moonwalk.
rtl/Legionnaire/Legionnaire_cop3.sv:1619 MAME: dy==0 -> cop_angle=0
rtl/Legionnaire/Legionnaire_cop3.sv:1642 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197) dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (aritmetico) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = sqrt(dx*dx + dy*dy) if(data&0x80) write_word(r0 + (data&0x200?0x3a:0x38
rtl/Legionnaire/Legionnaire_cop3.sv:1751 (Il fix MAME-aligned 0x3a:0x38 faceva fuggire i nemici -> MAME invertito vs HW.
rtl/Legionnaire/Legionnaire_cop3.sv:1758 MAME: macro completata → cop_status = 7 (gate-poll del gioco).
rtl/Legionnaire/Legionnaire_cop3.sv:1844 0x8100/0x8900 sin/cos (MAME execute_8100/8900) raw_angle = cop_read_word(cop_regs[0]+0x34) & 0xff amp = (65536>>5) * (cop_read_word(cop_regs[0]+0x36) & 0xff) = 2048 * amp_byte if (raw_angle == 0xC0 sin / 0x80 cos): amp *= 2 res = int(
rtl/Legionnaire/Legionnaire_cop3.sv:1883 MAME special-case: sin && raw==0xC0 OR cos && raw==0x80 → amp *= 2
rtl/Legionnaire/Legionnaire_cop3.sv:1929 0xa180/0xa980 — read pos (MAME cop_collision_read_pos) flags_swap = cop_read_word(spradr+2) → host_read_word(spradr+0) pos[0] = cop_read_word(spradr+6) → host_read_word(spradr+4) pos[1] = cop_read_word(spradr+10) → host_read_word(
rtl/Legionnaire/Legionnaire_cop3.sv:1936 Però MAME cop_read_word(+2) = host_read_word(+2^2) = host_read_word(+0).
rtl/Legionnaire/Legionnaire_cop3.sv:1947 rdata = word @ host+0 = flags (MAME cop_read_word(spradr+2) ^ 2).
rtl/Legionnaire/Legionnaire_cop3.sv:1956 rdata = word @ host+4 = pos[0] (Y axis per MAME)
rtl/Legionnaire/Legionnaire_cop3.sv:1976 0xb100/0xb900 — update hitbox & compute intersection (1:1 MAME cop_collision_update_hitbox, seibucop.cpp:1003-1065).
rtl/Legionnaire/Legionnaire_main_top.sv:212 VBLANK IRQ4 — MAME legionna.cpp: m_maincpu->set_vblank_int(irq4_line_hold) MAME HOLD_LINE: IRQ asserted on edge, released ONLY at IACK (= when CPU fetches vector).
rtl/Legionnaire/Legionnaire_main_top.sv:217 VBLANK IRQ4 — MAME legionna.cpp: m_maincpu->set_vblank_int(irq4_line_hold) MAME HOLD_LINE: IRQ asserted on edge, released ONLY at IACK (= when CPU fetches vector).
rtl/Legionnaire/Legionnaire_main_top.sv:462 COP3 cmd 0x14 dma_tilemap_buffer (MAME legionna_v.cpp:86 videowrite_cb_w): offset 0x000..0x3FF → BG (back_data) offset 0x400..0x7FF → FG (fore_data) offset 0x800..0xBFF → MG (mid_data) offset 0xC00..0x13FF → Text (textram, 0x800 word)
rtl/Legionnaire/Legionnaire_main_top.sv:532 ── Palette: split STAGING ($104000) vs RENDERER (semantica MAME 2-stadi) ─── MAME: la CPU e il fade (cmd 0x80) scrivono la STAGING RAM a $104000.
rtl/Legionnaire/Legionnaire_main_top.sv:554 Il mirror serve al FADE-SOFTWARE della CPU (presentazione, routine $263E) che fa read-modify-write sulla palette assumendo palette UNICA (come MAME/HW): senza mirror la CPU scrive solo lo staging e il risultato non e' visibile fino al pross
rtl/Legionnaire/Legionnaire_maincpu_map.sv:23 Main CPU memory map Legionnaire (MAME legionna.cpp legionna_map): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $100000-$1003FF RAM scratch (1KB) → BRAM (Main RAM low) $100400-$1006FF COP3 region
rtl/Legionnaire/Legionnaire_maincpu_map.sv:130 Text VRAM: $102800-$1037FF = 4KB = 2048 word (MAME common_video_allocate_ptr alloca textram a 0x1000/2 word, videowrite_cb_w smista offset < 0x2800/2).
rtl/Legionnaire/Legionnaire_maincpu_map.sv:212 MAME legionna_map: main_r/main_w(offset>>1) con umask16(0x00ff).
rtl/Legionnaire/Legionnaire_maincpu_map.sv:216 Vedi reference/mame_seibu/seibusound.cpp main_r/main_w.
rtl/Legionnaire/Legionnaire_maincpu_map.sv:308 Replica la latenza-zero-osservabile di MAME (cop_cmd_w sincrono): il gioco legge cop_hit_val_stat/cop_angle ($188/$1b4) nell'istruzione dopo il trigger.
rtl/Legionnaire/Legionnaire_palette.sv:25 MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 128*16); (legionna.cpp:1212, 128*16 = 2048 entry) Address space CPU: 0x104000..0x104FFF (4 KB = 2048 word).
rtl/Legionnaire/Legionnaire_palette.sv:35 Espansione 5→8 standard MAME palette_device: {val5, val5[4:2]} (bit replication che riempie i 3 LSB con i 3 MSB del valore 5-bit).
rtl/Legionnaire/Legionnaire_palette.sv:85 Legionnaire: xBGR_555 → RGB888 (MAME legionna.cpp:1212) Layout: bit[4:0]=R, bit[9:5]=G, bit[14:10]=B. 5 bit per canale.
rtl/Legionnaire/Legionnaire_palette.sv:87 Espansione 5→8 standard MAME palette_device: {val5, val5[4:2]} (replica i 3 MSB nei 3 LSB → range 0..255 con monotonia preservata).
rtl/Legionnaire/Legionnaire_seibu_crtc.sv:23 Seibu CRTC fedele a MAME (src/mame/seibu/seibu_crtc.cpp).
rtl/Legionnaire/Legionnaire_seibu_crtc.sv:119 MAME mappa: bit0=screen0(BG), bit1=screen2(MG), bit2=screen1(FG), bit3=screen3(Text) (vedi seibu_crtc.cpp commento "screen 0=BG, screen 1=FG, screen 2=MG, screen 3=Text") In SD Gundam dcon.cpp layer_en_w gira la maschera così: ~layer_en bit
rtl/Legionnaire/Legionnaire_seibu_crtc.sv:128 Il dispatcher MAME usa "if (BIT(~m_layer_en, n))" per saltare = layer disabilitato quando il bit è 1.
rtl/Legionnaire/Legionnaire_seibu_crtc.sv:133 Legionnaire layer ordering (MAME legionna_v.cpp:342-345): bit 0 = MG (midground) bit 1 = BG (background) bit 2 = FG (foreground) bit 3 = Text bit 4 = Sprites (Diverso da BB/DCon/Gundam dove bit 0=BG, bit 1=MG.)
rtl/Legionnaire/Legionnaire_sprite_renderer.sv:25 Formato spriteram quasi identico (entrambi MAME sei021x_sei0220_spr.cpp) — differenze: - Spriteram @ 0x105000-0x105FFF (4KB, 1024 word, 256 entry × 4 word) - w3 bit 15 = tile bank extra bit (denjinmk usa, Legionnaire base = 0)
rtl/Legionnaire/Legionnaire_sprite_renderer.sv:30 Format word (MAME legionna_v.cpp:288-312): w0 bit 15 = enable (0=draw, 1=skip — TODO verify Legionnaire) w0 bit 14 = flip_x w0 bit 13 = flip_y (???
rtl/Legionnaire/Legionnaire_sprite_renderer.sv:46 Priority callback legionna_v.cpp:314-317: pri_mask[0] = 0x0000 (sopra tutto) pri_mask[1] = 0xFFF0 pri_mask[2] = 0xFFFC pri_mask[3] = 0xFFFE
rtl/Legionnaire/Legionnaire_sprite_renderer.sv:140 0..511 (MAME size/2/4 = 4096/2/4 = 512)
rtl/Legionnaire/Legionnaire_sprite_renderer.sv:145 Decoded fields — MAME sei0210_device::draw (non-alt format, riga 143): if (BIT(~spriteram[i], 15)) continue; → draw quando w0[15]==1.
rtl/Legionnaire/Legionnaire_sprite_renderer.sv:155 SEI0211 get_coordinate (MAME sei021x_sei0220_spr.h): coord &= 0x1ff; return (coord >= 0x180) ?
rtl/Legionnaire/Legionnaire_sprite_renderer.sv:163 MAME SEI0211 default m_xoffset/m_yoffset = 0 (sei021x_sei0220_spr.cpp:40-41).
rtl/Legionnaire/Legionnaire_sprite_renderer.sv:164 Legionnaire NON chiama set_offset (legionna.cpp:1214) → offset 0,0.
rtl/Legionnaire/Legionnaire_sprite_renderer.sv:196 Tile code finale Y-MAJOR (MAME draw_internal: ax=outer, ay=inner, code++): sub_index = ax*sizey + ay → cur_tile = code + eff_tile_x*sp_h + eff_tile_y
rtl/Legionnaire/Legionnaire_sprite_renderer.sv:535 MAME gfx_legionna_spr: color base = 64*16 = 0x400 (64 colorset × 16 pen).
rtl/Legionnaire/Legionnaire_text_renderer.sv:25 Specifiche da MAME (legionna.cpp:1117-1126, 1167):
rtl/Legionnaire/Legionnaire_text_renderer.sv:47 Char ROM in MAME: "char" region 64KB = ROM_COPY user1[0x10000..0x1FFFF].
rtl/Legionnaire/Legionnaire_text_renderer.sv:142 MAME `legionna_v.cpp:214`: text tilemap = 64×32 (8x8 tiles, TILEMAP_SCAN_ROWS).
rtl/Legionnaire/Legionnaire_text_renderer.sv:188 --- Stage 3: pen decode (charlayout planes packed in nibbles) --- Per col c (0..3 dentro la half-tile), bit position = 3 - c. pen[0] = word[bit_pos + 0] (plane 0) pen[1] = word[bit_pos + 4] (plane 1) pen[2] = word[bit_pos + 8] (plane
rtl/Legionnaire/Legionnaire_text_renderer.sv:194 MAME readbit usa MSB-first: bit_offs N → byte[N/8] bit (7-N%8).
rtl/Legionnaire/Legionnaire_text_renderer.sv:195 In Verilog word concat (lo=byte0[7:0], hi=byte1[7:0]) → MAME pos N = word[(7-N%8) + (N>=8?8:0)].
rtl/Legionnaire/Legionnaire_text_renderer.sv:212 MAME GFXDECODE char: color base = 48*16 = 0x300 (16 colorset × 16 pen).
rtl/Legionnaire/Legionnaire_tile_layer.sv:25 Differenze fra layer (da MAME dcon.cpp):
rtl/Legionnaire/Legionnaire_tile_layer.sv:58 BB FG hardcoded +0x1000 (MAME bloodbro fg_tile_info)
rtl/Legionnaire/Legionnaire_tile_layer.sv:195 Tile index con eventuale gfx_bank (MG ha bit 12 = 13-bit totali, BG/FG = 12 bit) + TILE_CODE_OFS hardcoded (BB FG aggiunge 0x1000 secondo MAME bloodbro fg_tile_info).
rtl/Legionnaire/Legionnaire_video_timing.sv:35 Active area da MAME (sdgndmps_map): visarea 0..40*8-1, 2*8..30*8-1 quindi 320×224, V offset = 16 (top blank).
rtl/Legionnaire/Legionnaire_video_timing.sv:72 ── Constants timing ───────────────────────────────────────────────────── Blood Bros: 256x224 active (MAME bloodbro.cpp:846-851 set_visarea 0..255, 16..239).
rtl/Legionnaire/sdram_bridge.sv:287 --- FG address descramble (MAME legionna.cpp:1129 descramble_legionnaire_gfx) --- MAME applica un bitswap<24> agli indirizzi della ROM "fore" durante init: src_descrambled[i] = src_raw[bitswap<24>(i, ...
rtl/Legionnaire/sdram_bridge.sv:334 bitswap MAME del byte offset
README.md:11 This core reimplements the hardware in SystemVerilog from MAME references and hardware observation.
README.md:32 **Seibu SEI300 / COP coprocessor** reproduced from the MAME `raiden2cop` reference: sincos / atan (CORDIC) math, distance / divide, object DMA, collision detect
README.md:36 MAME-accurate Seibu CRTC tilemaps: BG / MG / FG / TEXT with per-layer scroll
README.md:38 xBGR-555 palette, MAME-accurate layer priority and sprite/tilemap mixing

Says it matches, follows or was checked against MAME — 7

Legionnaire.sv:209 Shift fisso aggiunto per match MAME 1:1 (misurato HW 2026-05-14): BG X+0 Y+16 FG X+0 Y+16 SPR X+0 Y+0 TXT X-1 Y+16 L'OSD resta editabile ±32 attorno al valore corretto.
Legionnaire.sv:215 Offset per-layer HARDCODATI = match pixel-perfect MAME (trovati via OSD, ora fissi; menu P5 rimosso).
Legionnaire.sv:253 NB: gli offset per-layer (ex P5) sono HARDCODATI (osd_*_xoff/yoff costanti, match pixel-perfect MAME).
rtl/Legionnaire/Legionnaire_cop3.sv:721 find_trigger_match (MAME seibucop.cpp:464) Cerca slot N tale che (trigger & 0xf800) == (cop_func_trigger[N] & 0xf800) && cop_func_trigger[N] != 0.
rtl/Legionnaire/Legionnaire_cop3.sv:1898 res = prod >> 4 (= /16 per matchare formula MAME 2048/32768 = 1/16)
rtl/Legionnaire/Legionnaire_sprite_renderer.sv:165 +1 pixel a destra: offset verificato con pixel hunting su MAME (rmonic79).
rtl/Legionnaire/Legionnaire_sprite_renderer.sv:325 Scan INVERSO 511→0 (verificato su HW: ordine sprite-su-sprite opposto al loop MAME 0→511).

Says it was translated, ported or taken from MAME — 3

Legionnaire.sv:209 Shift fisso aggiunto per match MAME 1:1 (misurato HW 2026-05-14): BG X+0 Y+16 FG X+0 Y+16 SPR X+0 Y+0 TXT X-1 Y+16 L'OSD resta editabile ±32 attorno al valore corretto.
rtl/Legionnaire/Legionnaire_cop3.sv:1650 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197): 1:1 dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (signed) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = floor(sqrt(dx*dx + dy*dy)) if(data&0x80) write_word(r0+(data&0x200?0x3
rtl/Legionnaire/Legionnaire_cop3.sv:1767 0x42C2/0x4AA0 divide — MAME execute_42c2/4aa0 (cmd.ipp:219/247): 1:1 DIVIDEND = cop_dist << (5 - cop_scale) (cop_scale 0..3 → shift 5..2) 42c2: div=cop_read_word(r0+0x36)→host 0x34; if(!div){status|=0x8000; write 0 a host 0x3a} else write

Shares text with the MAME driver without saying so — 5

rtl/Legionnaire/Legionnaire_palette.sv:23 Palette RAM Seibu Legionnaire (xBGR_555, 2048 entries). MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 128*16); (legionna. — shares text with seibu/legionna.cpp:1212
rtl/Legionnaire/Legionnaire_sprite_renderer.sv:146 if (BIT(~spriteram[i], 15)) continue; → draw quando w0[15]==1. — shares text with seibu/sei021x_sei0220_spr.cpp:128
rtl/Legionnaire/Legionnaire_text_renderer.sv:23 Text layer renderer Seibu Legionnaire (8x8, 4bpp, 64x32). Specifiche da MAME (legionna.cpp:1117-1126, 1167): // charlayout 8x8, RGN_FRAC(1,1), — shares text with seibu/legionna.cpp
rtl/Legionnaire/Legionnaire_video_timing.sv:23 Video timing single-screen Seibu D-Con. SD Gundam Psycho Salamander gira su Seibu D-Con (PB91008), stessa famiglia di Blood Bros (1990). PCB measuremen — shares text with seibu/legionna.cpp
rtl/Legionnaire/sdram_bridge.sv:289 src_descrambled[i] = src_raw[bitswap<24>(i, ... 6,5,15,14,13,12, 11,10,9,8, 7,4, 3..0)] — shares text with seibu/legionna.cpp:1141

Leland#
Ataxx, Brute Force, Danny Sullivan's Indy Heat, Ironman Ivan Stewart's Super Off-Road …
MiSTer-devel/Arcade-Leland_MiSTer @ 2dc128ae
MAME compared: cinematronics/leland.cpp + 5 related file(s)
Read: 83 HDL files, 15,476 lines (Quartus project)

MiSTer official

Mostly MAME

medium

49%

Statements: 130 toward MAME

Cites MAME source — 118

rtl/KF8253/kf8253_leland_bus.sv:6 Scope boundary: this module does NOT decode a real system address into "is this access for me" -- that is the PCS-window job (MAME's leland_a.cpp peripheral_r/w, `select = offset >> 6`, PCS2/PCS3 sub-windows).
rtl/audio/leland_dac_mixer.sv:6 Takes the sound board's digital DAC register outputs (six 8-bit sample+volume pairs and one 10-bit sample) and produces one mono signed 16-bit PCM stream; the top level duplicates it to both channels (leland_a.cpp has a single front_center
rtl/audio/leland_dac_mixer.sv:15 Gains: leland_a.cpp routes each 8-bit channel at 0.2 and dac9 at 1.0.
rtl/audio/leland_dac_mixer.sv:15 MAME's volume DAC (DAC_8BIT_BINARY_WEIGHTED) has a gain of 2.0, which doubles every 8-bit channel (measured against a MAME capture of Indy Heat).
rtl/audio/leland_sound.sv:16 Reference: MAME leland_a.cpp leland_80186_map_program (RAM 0x00000-0x1FFFF mirrored, ROM 0x20000-0xFFFFF identity-mapped into the audiocpu region).
rtl/audio/leland_sound.sv:55 Core interrupt/debug ports: INT0/INT1 are decoded by leland_sound_board straight from control_data; NMI is unused per leland_a.cpp.
rtl/audio/leland_sound.sv:228 leland_sound_board -- PIT clock enable: the two discrete PIT8254s run at 4 MHz (leland_a.cpp `set_clk<N>(4000000)`); clk_sys/12 is exactly 4 MHz at 48 MHz.
rtl/audio/leland_sound_board.sv:6 Sits downstream of i186_periph's system-side data bus (everything i186_periph did not claim as an internal register): decodes the external PCS peripheral window (command/response latch, PIT0/PIT1, dac9, clock-active status; leland_a.cpp per
rtl/audio/leland_sound_board.sv:16 MAME's peripheral_r/w and dac_w are 16-bit handlers whose `offset` is a word offset in the same units (PIT0 programming at byte address 0x20100 is word offset 0x80, `>>6` = select 2), so the constants below come straight from leland_a.cpp.
rtl/audio/leland_sound_board.sv:21 clock_active[6:2] (leland_a.cpp m_clock_active, the PCS select-0 status read) is an edge-triggered latch, not a level follower: MAME calls set_clock_line() only on a pin transition event, and bit 6 (TMROUT0) only ever transitions high in th
rtl/audio/leland_sound_board.sv:63 Ataxx sound board variant (leland_a.cpp ATAXX_80186): peripherals sit in an I/O-space window (not memory), there is no whole-I/O-space DAC port and no second PIT, and the three DACs plus their volumes are written through PCS select 5.
rtl/audio/leland_sound_board.sv:159 Outside Ataxx mode select 5 falls through to the "unimplemented read returns 0xFFFF, write ignored" default below, like leland_a.cpp's `m_type <= TYPE_REDLINE` guard.
rtl/audio/leland_sound_board.sv:269 --- clock_active status (select-0 read; bits [1:0] unused -- DMA-fed dac 0/1 never SET a clock_active bit in leland_a.cpp, only dac_w's unconditional set_clock_line(dac,0) clear ever touches them, which is a permanent no-op since they start
rtl/audio/leland_sound_board.sv:290 A byte write merges into the 16-bit register like MAME's COMBINE_DATA.
rtl/audio/leland_sound_board.sv:439 --- local read mux (pcs0/1; pcs4/5 and io-space are write-only, read as 0xFFFF matching leland_a.cpp's fallthrough-to-default warn+0xffff) ---
rtl/cpu/i186_periph.sv:5 Written from MAME's i186.cpp as a behavioural reference (no code reuse).
rtl/cpu/i186_periph.sv:8 It sits inline on the s80x86 core's data bus only (MAME also intercepts only data accesses): an access to the relocation-selected internal page is serviced here, everything else passes through to the system bus.
rtl/cpu/i186_periph.sv:17 count/maxA/maxB are live registers compared every tick, which is equivalent to MAME's event-scheduled model.
rtl/cpu/i186_periph.sv:23 The s80x86 core requires irq[7:0] to stay stable from the moment `intr` asserts until the `inta` pulse, which MAME's model does not guarantee.
rtl/cpu/i186_periph.sv:76 every timer-0 terminal count, regardless of the interrupt-enable bit (i186.cpp drives tmrout0 on every TC).
rtl/cpu/i186_periph.sv:120 --- Relocation register --- Reset default 0x20FF: I/O mode (bit12=0), page 0xFF -> window 0xFF00-0xFFFF (i186.cpp device_reset: m_reloc = 0x20ff), before the ROM reprograms it.
rtl/cpu/i186_periph.sv:134 External PCS window, recomputed continuously from PACS/MPCS (matches leland_a.cpp peripheral_ctrl: temp = (PACS & 0xffc0) << 4, space chosen by MPCS bit 6 of the *stored* (forced-bits-included) value).
rtl/cpu/i186_periph.sv:242 Byte-swap quirk: bytesel==10 (high lane only) is the odd-byte-address case in i186.cpp and targets the register word's high byte; bytesel==01 is the low byte.
rtl/cpu/i186_periph.sv:273 write-only (EOI); i186.cpp reads log an error and return nothing
rtl/cpu/i186_periph.sv:291 Hi-address (source/dest upper 4 bits) registers read back with the unused upper 12 bits as 0, matching i186.cpp's `source >> 16` (source stored as a plain integer wider than the real 20-bit bus).
rtl/cpu/i186_periph.sv:401 Selection is by RIU, not by "ALT enabled" (i186.cpp: `(control & 0x1000) ?
rtl/cpu/i186_periph.sv:424 Control-register write masking: bits in `resbits` are hardware-owned (preserved from the old value, never settable by a CPU write); INH (bit14) gates whether EN (bit15) actually updates from this write, and always reads back 0 (i186.cpp int
rtl/cpu/i186_periph.sv:445 Post-elapse control mutation (i186.cpp timer_elapsed): MC (bit5) always sets; CONT (bit0) or mid-ALT-cycle (ALT && !RIU) reprimes (toggling RIU on the ALT case) and keeps EN running, otherwise the timer stops (EN and RIU both clear).
rtl/cpu/i186_periph.sv:454 i186.cpp: RIU sets only when (ALT && !RIU) [starting the B half]; every other reprime case (not ALT, or ALT&&RIU finishing the B half under CONT) unconditionally clears it back to 0 -- NOT "leave unchanged".
rtl/cpu/i186_periph.sv:554 --- Priority resolver (i186.cpp update_interrupt_state, non-iRMX scan order: for each priority 0..7 check timer, then dma0, dma1, ext0..ext3; masked sources never match because a stored field with MSK=1 cannot equal 0-7).
rtl/cpu/i186_periph.sv:556 A source at the current priority that is already in service aborts the whole scan, as MAME's `return;`.
rtl/cpu/i186_periph.sv:605 EXT0 (0x10 -> in_service[4]); an in-service source with SFNM (bit 6) set also ends the scan in i186.cpp, so no nested request is ever granted here (cascade/SFNM support is omitted).
rtl/cpu/i186_periph.sv:690 Reading POLL (0x12) while a request is pending is treated identically to a real `inta` pulse (i186.cpp internal_port_r case 0x12: `if (poll_status & 0x8000) inta_callback(...)`); poll-mode firmware relies on it.
rtl/cpu/i186_periph.sv:699 Rescan trigger: every event that calls update_interrupt_state() in i186.cpp (register writes, EOI, an INT0/1 edge, a timer_irq pulse, a DMA interrupt pulse, or the inta/poll-read ack).
rtl/cpu/i186_periph.sv:714 EOI (i186.cpp handle_eoi, non-iRMX): the specific form clears one in_service bit by explicit vector; the nonspecific form (bit 15 set) scans priority 0..7 and clears the first in-service source whose priority field's low 3 bits match (the m
rtl/cpu/i186_periph.sv:780 --- Timer status latch (per-timer strobe -> sticky status bits, i186.cpp timer_elapsed: `m_intr.status |= 0x01 << which`) ---
rtl/cpu/i186_periph.sv:787 Unlike a literal port of i186.cpp external_int(), edge-triggered mode (LTM=0, the reset default and what this board uses) latches a rising edge as a sticky request that only a genuine ack clears.
rtl/cpu/i186_periph.sv:793 Level-triggered mode (LTM=1) tracks the live pin level as in MAME.
rtl/cpu/i186_periph.sv:796 LTM=1: MAME's literal level-tracking behavior
rtl/cpu/i186_periph.sv:824 --- Register writes (plain field stores; every one of these triggers a rescan in i186.cpp, folded into the shared rescan block below via `intc_reg_write`/`wr_eoi`) ---
rtl/cpu/i186_periph.sv:849 Ack processing (a real `inta` pulse from the core, or a POLL register read), as i186.cpp int_callback.
rtl/cpu/i186_periph.sv:862 Clear the request bit(s) this ack covers, UNLESS it's an LTM-mode external source (0xf0 of ack_mask) -- a level-triggered request stays sticky until the pin itself deasserts, matching i186.cpp's LTM check exactly.
rtl/cpu/i186_periph.sv:992 M/IO bit semantics per i186.cpp (SRC_MIO/DEST_MIO set == memory space): this bus's d_io is the opposite sense (1 == I/O).
rtl/cpu/i186_periph.sv:1053 update_dma_control (i186.cpp): CHG_NOCHG (bit2) clear -> preserve the old ST_STOP (bit1) instead of taking the write's; CHG_NOCHG itself always reads back 0 afterward.
rtl/cpu/i186_periph.sv:1107 Pointer increment/decrement, count decrement, TC stop/interrupt -- as i186.cpp drq_callback.
rtl/cpu/i186_periph.sv:1132 Terminate: explicit TERMINATE_ON_ZERO, or unsync mode (which always self-stops on TC regardless of that bit -- i186.cpp: `(control&TERMINATE_ON_ZERO) || !(control&SYNC_MASK)`).
rtl/cpu/leland_master.sv:7 Leland Master Z80 memory map (validated against MAME leland.cpp): 0x0000-0x1FFF ROM fixed bank (always master_rom[0x00000..0x01FFF]) 0x2000-0x9FFF Banked ROM window (32 KB, bank register selects offset) 0xA000-0xDFFF Fixed ROM (region of
rtl/cpu/leland_master.sv:19 I/O port map (validated against MAME leland.cpp master_map_io and redline_state::init_offroad): 0xF0 ROM bank register (write, bits [2:0] used) 0xF8 Player 3 wheel read (offroad_wheel_3_r, dial-encoded) 0xF9 Player 1 wh
rtl/cpu/leland_master.sv:29 Banking (validated against MAME leland_m.cpp offroad_bankswitch): bank_reg [2:0] indexes a fixed lookup table of ROM base offsets.
rtl/cpu/leland_master.sv:32 bank_list (MAME):
rtl/cpu/leland_master.sv:55 Battery-backed RAM (0xA000-0xDFFF, 16 KB), master-private: normally fixed ROM (region offset 0xA000), overlaid by MAME's battery_ram_view only when bank_reg == 1.
rtl/cpu/leland_master.sv:68 VRAM I/O port op stream (to leland_board's VRAM sequencer) -- leland_mvram_port_r/w, installed by init_master_ports at mvram_base=0x00 and 0x40 (see leland.cpp init_offroad()).
rtl/cpu/leland_master.sv:79 /MCONT control outputs (I/O port 0x09, validated MAME leland_master_output_w) bit0: slave_reset_n (0=hold Slave in reset, 1=run) bit2: slave_nmi_n (0=assert NMI) bit3: slave_int_req (0=assert Slave INT)
rtl/cpu/leland_master.sv:87 80186 sound-board control latch: port 0xF0 is both the graphics bank register (bank_reg) and the sound board's control register (/RESET, ZNMI, INT0, /TEST, INT1 in bits [7:3]); MAME's redline_master_alt_bankswitch_w forwards the same byte t
rtl/cpu/leland_master.sv:94 Sound command latch writes (ports 0xF2/0xF4, leland_a.cpp command_lo_w/command_hi_w).
rtl/cpu/leland_master.sv:109 Background scroll registers (MAME scroll_w at io_base+0x0C-0x0F: ports 0xCC-0xCF and 0x8C-0x8F for Off-Road).
rtl/cpu/leland_master.sv:114 Graphics bank (MAME m_gfxbank / leland_video gfxbank), set through the AY-3-8910 port A write callback: the ROM writes a register select (I/O 0x0A, /OGIA) then data (0x0B, /OGID), relocated like /MCONT.
rtl/cpu/leland_master.sv:133 Raster line counter (from leland_video), used to generate the periodic "VA10" interrupt every 16 scanlines starting at line 8 (validated against MAME leland_m.cpp leland_interrupt_callback).
rtl/cpu/leland_master.sv:138 Pedal (MAME AN0-AN2, IPT_PEDAL): raw value, read directly at ports 0xFD/0xFE/0xFF.
rtl/cpu/leland_master.sv:143 Wheel (MAME AN3-AN5, IPT_DIAL): a free-spinning encoder, so only the direction and magnitude of motion since the last read is reported (dial_compute_value).
rtl/cpu/leland_master.sv:214 Periodic "VA10" interrupt — validated against MAME leland_m.cpp leland_interrupt_callback(): fires every 16 scanlines starting at line 8.
rtl/cpu/leland_master.sv:216 This is the only Master INT source in MAME.
rtl/cpu/leland_master.sv:231 The periodic VA10 raster interrupt is the only master INT source in MAME; the CPUs otherwise communicate through the shared VRAM mailbox and the SLAVEHALT/GIN1 poll (see leland_slave.sv).
rtl/cpu/leland_master.sv:237 ROM banking — validated against MAME offroad_bankswitch()
rtl/cpu/leland_master.sv:248 bank_list from MAME offroad_bankswitch (offsets into master_rom region)
rtl/cpu/leland_master.sv:342 leland_mvram_port_r/w range, parameterised by mvram_base (MAME init_master_ports).
rtl/cpu/leland_master.sv:351 TRANS_EN=0: the Master is num=0 in MAME's vram_port_w, so its bit-4 transparency bit is ignored (transparency is Slave-only).
rtl/cpu/leland_master.sv:383 MAME redline_state::init_offroad installs the shared leland_master_input_r/output_w handlers (GIN, mcont, ay, scroll) at io_base+offset, aliased at both io_base=0xC0 and 0x80, so the physical /MCONT port is 0xC9 (mirrored at 0x89), not the
rtl/cpu/leland_master.sv:388 P1 pedal, raw (MAME port 0xFD)
rtl/cpu/leland_master.sv:391 Wheel ports (MAME init_offroad/init_offroadt): fixed dial-encoded reads at 0xF9 (P1), 0xFB (P2) and 0xF8 (P3), separate from the pedal ports; unused by Pig Out.
rtl/cpu/leland_master.sv:397 The relocated leland_master_input_r/output_w window (GIN0/1/3, mcont, ay, scroll) is parameterised by io_base (MAME init_master_ports(mvram_base, io_base)); dual_io_window reproduces Off-Road's double install (base and base^0x40).
rtl/cpu/leland_master.sv:399 Offsets inside the window are fixed by MAME: 0x00/0x01 GIN0/1, 0x09 mcont, 0x0A/0x0B ay, 0x0C-0x0F scroll, 0x11 GIN3.
rtl/cpu/leland_master.sv:413 MAME master_redline_map_io: 0xF2 = 80186 response_r / command_lo_w, 0xF4 = command_hi_w (write-only).
rtl/cpu/leland_master.sv:419 Background scroll registers (MAME scroll_w, offset 0x0C-0x0F relative to io_base -- see leland.cpp init_offroad()/init_offroadt()/init_pigout()).
rtl/cpu/leland_master.sv:426 Wheel dial encoder (MAME leland_m.cpp dial_compute_value): each read reports the direction (bit 7) and magnitude (bits 4:0, clamped to 0x1F, accumulated mod 32) of wheel motion since the last read of the same port, never an absolute angle.
rtl/cpu/leland_master.sv:472 GIN input ports — validated against MAME INPUT_PORTS and leland_master_input_r (leland_m.cpp), parameterized by io_base (see io_win() above).
rtl/cpu/leland_master.sv:488 bit1=COIN3, bit2=COIN2, bit3=COIN1 (MAME offroad INPUT_PORTS IN1 order is NOT P1/P2/P3).
rtl/cpu/leland_master.sv:496 JOY4_DIGITAL (pigout) GIN0 (leland.cpp INPUT_PORTS_START(pigout), IN0 @ io_base+0): bit1=P3BTN2, bit2=P3right, bit3=P3down, bit5=P2BTN2, bit6=P2left, bit7=P2up.
rtl/cpu/leland_master.sv:548 Pig Out: fixed IN4 at raw 0x7F (MAME init_pigout install_read_port, outside the io_base window): P1 joystick, two buttons and start.
rtl/cpu/leland_master.sv:560 I/O writes The sound command latch (leland_a.cpp command_lo_w/command_hi_w) lives in the sound board; ports 0xF2/0xF4 are forwarded to it through cmd_wr_data/cmd_wr_lo/cmd_wr_hi.
rtl/cpu/leland_master.sv:574 MAME's diff==0 early-out is a software optimisation, not bus behaviour, and control_wr is idempotent.
rtl/cpu/leland_master.sv:636 MAME: set_input_line(NMI, BIT(data,2) ?
rtl/cpu/leland_master.sv:640 /MCONT bit 3 is a held level (MAME: set_input_line(IRQ0, BIT(data,3) ?
rtl/cpu/leland_master.sv:648 MAME leland_master_output_w: /MCONT bit 1 selects the palette view.
rtl/cpu/leland_master.sv:662 Palette RAM is readable while /MCONT bit 1 selects the palette view (MAME: ram().w(palette write8)).
rtl/cpu/leland_master_ataxx.sv:4 Ataxx master Z80 (MAME leland.cpp master_map_program_2 / master_map_io_2).
rtl/cpu/leland_slave.sv:7 Memory map (MAME leland.cpp slave_large_map_program, used by the `lelandi` machine config): 0x0000-0x1FFF ROM bank 0 (fixed) 0x2000-0x3FFF unmapped (reads 0xFF) 0x4000-0xBFFF banked ROM window, 32 KB 0xC000 ROM bank register (wri
rtl/cpu/leland_slave.sv:51 Master asserted /MCONT bit3 → assert Slave INT (the only Slave INT source in MAME; there is no Master->Slave command port)
rtl/cpu/leland_slave.sv:78 Slave INT: /MCONT bit3 (leland_master_output_w case 0x09) is the only Slave INT source in MAME.
rtl/cpu/leland_slave.sv:133 ROM banking (MAME slave_large_map_program / slave_large_banksw_w): the bank register at 0xC000 (bits [3:0]) selects a 32 KB window at 0x4000-0xBFFF: bankaddress = 0x10000 + 0x8000 * bank_reg, and bank_reg >= 14 falls back to 0x10000.
rtl/cpu/leland_slave.sv:136 Offsets are within the slave ROM region (leland_board adds ADDR_SLAVE_BASE): 0x00000 u3 (8 KB, fixed bank) 0x02000-0x2FFFF zero fill 0x30000 u4t bank_reg 4/5 0x40000 u5t bank_reg 6/7 0x50000 u6t bank_reg 8/9 0x6000
rtl/cpu/leland_slave.sv:154 MAME's init_offroad() calls rotate_memory("slave") twice, which left-rotates every 32 KB block from 0x10000 by 8 KB per call: a net rotation of half a block.
rtl/cpu/leland_slave.sv:175 MAME slave_map_io installs this handler at 0x00-0x1F with .mirror(0x40), i.e. bit 6 is a don't-care -- the same port also answers at 0x40-0x5F.
rtl/cpu/leland_slave.sv:211 Bank register write: exactly 0xC000 (MAME slave_large_banksw_w).
rtl/cpu/leland_slave_ataxx.sv:4 Ataxx slave Z80 (MAME leland.cpp ataxx_state::slave_map_program / slave_map_io_2).
rtl/io/steering_input.sv:9 The cabinet's wheel is a free-spinning rotary encoder (MAME IPT_DIAL): only the change between two reads matters.
rtl/io/trackball_input.sv:4 Like MAME's IPT_TRACKBALL with PORT_KEYDELTA(4) at 80% sensitivity, a held D-pad direction adds a small fixed step every frame (no ramp, stops when released); the stick adds a step proportional to its deflection beyond a dead zone.
rtl/leland_board.sv:79 Wheel: free-running mod-256 virtual dial (stick + d-pad + spinner combined by steering_input.sv); leland_master turns it into MAME's dial_compute_value() encoding.
rtl/leland_board.sv:82 Pedal: raw 8-bit value (0 = released, 255 = full), read directly as MAME's IPT_PEDAL AN0/AN1/AN2 do.
rtl/leland_board.sv:955 Transparent writes (vp_trans, Slave-only in MAME) implement the exact leland_v.cpp vram_port_w merge: if (!(data & 0xf0)) data |= old & 0xf0; if (!(data & 0x0f)) data |= old & 0x0f; by inserting a read phase before the write phase.
rtl/leland_board.sv:1063 Work RAM: 4 KB per CPU, private (MAME: the master's 0xE000-0xEFFF is 'mainram', the slave's is a separate RAM).
rtl/leland_board_pkg.sv:143 The Leland games share the same master/slave bank tables (MAME's offroad_bankswitch is shared); only the I/O bases, input scheme and flags differ per row.
rtl/mem/leland_eeprom_93c46.sv:7 Standard Microwire protocol, as in MAME leland.cpp/leland_m.cpp (64 words x 16 bits).
rtl/mem/leland_eeprom_93c56.sv:4 Start bit, 2-bit opcode, 8-bit address (MAME EEPROM_93C56_16BIT with streaming reads: CS held high keeps shifting out the next word).
rtl/video/leland_video.sv:7 Leland hardware timing (MAME leland_v.cpp): pixel clock 7.159090 MHz (14.318181 MHz / 2) 424 x 256 total, 320 x 240 active -> 16.88 kHz / 65.95 Hz
rtl/video/leland_video.sv:55 Graphics bank (MAME m_gfxbank), written by the master through the AY-3-8910 port A: [5:4] character bank, [3] PROM bank
rtl/video/leland_video.sv:115 The scroll registers are used live, not latched per frame: MAME's scroll_w() calls update_partial() first, so the game relies on mid-frame scroll changes (HUD/status split).
rtl/video/leland_video.sv:139 Stride is 256 bytes per line (MAME: y << 8).
rtl/video/leland_video.sv:157 Background tilemap (MAME leland_get_tile_info / leland_scan)
rtl/video/leland_video.sv:396 Low tile byte at index, high byte at index | 0x4000 (MAME ataxx_get_tile_info)
rtl/video/leland_video.sv:578 Bit order: MAME's leland_layout uses xoffset STEP8(0,1), which its decoder reads MSB-first, so pixel column 0 is bit 7 of the plane byte.
rtl/video/leland_video.sv:588 Plane weights are reversed relative to bg_gfx ROM order: MAME's leland_layout lists its plane offsets ascending, and the decoder gives plane offset 0 the most significant bit.
rtl/video/leland_vram_port.sv:7 Implements MAME leland_v.cpp exactly: - video_addr_w (memory-mapped address latch, 0xF800/0xF801) - vram_port_w (I/O ports 0x00-0x1F, mirrored at 0x40-0x5F) - vram_port_r (same range)
rtl/video/leland_vram_port.sv:27 Address latch (video_addr_w): low (0xF800): addr = (addr & 0xFE00) | ((data << 1) & 0x01FE) high (0xF801): addr = ((data << 9) & 0xFE00) | (addr & 0x01FE), buffer = data[7] The buffer bit is tracked but unused, exactly like MAME (VRAM's up
rtl/video/leland_vram_port.sv:77 tracked like MAME's m_buffer, never used (see header)
rtl/video/leland_vram_port.sv:119 MAME op 3: addr += inc & (addr << 1); addr ^= 1 (increment only lands when inc is set AND the address is odd)
rtl/video/leland_vram_port.sv:188 MAME: warning only -- no write, no addr change
rtl/video/leland_vram_port.sv:210 MAME: unknown read op returns 0

Says it matches, follows or was checked against MAME — 5

Leland.sv:428 Nitro and Coin are J1 buttons 1-2 (joystick bits 4-5): p1_btn[1] is nitro and p1_btn[3] is coin, matching MAME's GIN0/GIN1 bit layout.
rtl/cpu/leland_master.sv:283 Banked-low (0x2000-0x9FFF), verified against MAME's live execution: bank_reg 0/1 (bank_offset 0x2000): rom_addr == cpu_addr bank_reg >= 2: rom_addr == bank_offset + cpu_addr[14:0].
rtl/cpu/leland_master.sv:595 matches MAME machine_reset()'s sound_port_w(0)
rtl/cpu/leland_slave.sv:156 For a 15-bit offset "+0x4000 mod 0x8000" is the same as inverting bit 14, so one XOR reproduces it (verified byte-exact against MAME's region dump).
rtl/cpu/leland_slave.sv:211 The reset value 0 matches MAME machine_reset().

Shares text with the MAME driver without saying so — 7

rtl/cpu/leland_master.sv:636 MAME: set_input_line(NMI, BIT(data,2) ? CLEAR_LINE : ASSERT_LINE), so with the — shares text with cinematronics/leland_m.cpp:1062
rtl/cpu/leland_master.sv:644 leland_master_output_w: m_eeprom->di_write(BIT(data,4)); clk_write(BIT(data,5)); cs_write(BIT(data,6)); — shares text with cinematronics/leland_m.cpp:775
rtl/mem/leland_eeprom_93c46.sv:11 via PORT_READ_LINE_DEVICE_MEMBER("eeprom", ...::do_read). — shares text with cinematronics/leland.cpp:417
rtl/video/leland_video.sv:166 leland_scan: idx = (col&0xff) | ((row&0x1f)<<8) | ((row&0xe0)<<9) — shares text with cinematronics/leland_v.cpp:62
rtl/video/leland_vram_port.sv:22 op 3: write data -> addr; addr += inc & (addr<<1); addr ^= 1 — shares text with cinematronics/leland_v.cpp:233
rtl/video/leland_vram_port.sv:32 64 KB is a TODO there: "accessing upper half of video RAM is not — shares text with cinematronics/leland.cpp:39
rtl/video/leland_vram_port.sv:119 MAME op 3: addr += inc & (addr << 1); addr ^= 1 — shares text with cinematronics/leland_v.cpp:234

MajorHavoc#
Major Havoc
MiSTer-devel/Arcade-MajorHavoc_MiSTer @ 6933b852
MAME compared: atari/mhavoc.cpp
Read: 43 HDL files, 18,808 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

11%

Statements: 7 toward hardware

Cites hardware documentation that MAME's driver does not — 7

rtl/avg/major_havoc_avg_core.vhd:58 State PROM 136002-125 at 6C (SP-252 sheet 6B).
rtl/major_havoc_core.sv:6 Implements the production dual-6502 main board from Atari drawing package SP-252 with its independent 10.000 MHz CPU/audio and 12.096 MHz AVG clocks.
rtl/major_havoc_core.sv:222 SP-252 sheet 4B stretches Alpha's 400 ns cycle while /VMEM is active.
rtl/major_havoc_core.sv:242 SP-252 sheet 4B clocks the watchdog at 10 MHz / 4096.
rtl/major_havoc_watchdog.sv:6 Models the cascaded counter and Alpha reset flip-flop on SP-252 sheet 4B.
rtl/videodr0me_fb/vfb_readout.sv:579 SP-252 sheet 9A uses 5.6K main-color branches and a 22K fine-red branch.
README.md:7 This core reconstructs the original dual-processor arcade hardware from Atari's schematics and pairs it with a high-resolution vector renderer and CRT-effects p

MarbleMadness2#

MiSTer-devel/Arcade-MarbleMadness2_MiSTer @ 25265baf
MAME driver: not found
Read: 23 HDL files, 6,229 lines (Quartus project)

MiSTer official

Mostly MAME

low

37%

Statements: 10 toward MAME

Cites MAME source — 9

rtl/mm2_address_decode.sv:1 Motorola 68000 byte-address decoder derived from MAME marblmd2_map().
rtl/mm2_core.sv:351 MAME's IRGB1555 decoder treats the intensity bit as the least significant bit of each six-bit color component.
rtl/mm2_cpu_subsystem.sv:130 Infer it for an odd-byte cycle so the byte-granular MAME-derived decoder can retain its documented addresses.
rtl/mm2_jsa_iii.sv:3 Clock ratios, address decode, banking, command polarity, and mixer controls follow MAME's atarijsa implementation.
rtl/mm2_playfield.sv:3 Each tile row is decoded from four SDRAM words using the split-half eight-bit MAME layout, then written into the line buffer for the following scanline.
rtl/mm2_vad.sv:3 This implements the scanline register/IRQ behavior, indexed playfield scroll parameters, and the end-of-frame register shadow described by MAME's atarivad device.
rtl/mm2_video_timing.sv:1 Raster timing documented by MAME's marblmd2 driver: 14.318181 MHz CPU/master reference, 7.1590905 MHz pixels, 456 clocks/line, 262 lines/frame, 336x240 visible.
rtl/mm2_video_timing.sv:5 The sync positions are provisional because the MAME driver explicitly lists the crystals/timing as unverified.
README.md:72 MAME documents that the prototype itself can report service RAM-test issues, so a reported RAM failure is not necessarily an FPGA fault.

Says it matches, follows or was checked against MAME — 1

rtl/mm2_motion_objects.sv:6 Later objects in the list overwrite earlier objects, matching the non-reversed MAME configuration.

MarioBros#
Mario Bros.
MiSTer-devel/Arcade-MarioBros_MiSTer @ a934eecf
MAME compared: nintendo/mario.cpp + 2 related file(s)
Read: 48 HDL files, 12,019 lines (Quartus project)

MiSTer official

Both

low

21%

Statements: 20 toward hardware, 3 toward MAME, 7 not counted

Cites hardware documentation that MAME's driver does not — 20

rtl/mario_adec.v:111 74LS139 @ 4A
rtl/mario_adec.v:123 This output goes to a LS245 @ 7H enable which is not used in the FPGA implementation.
rtl/mario_adec.v:136 74LS138 @ 3A Address decoding 7000H - 7FFFH (R)
rtl/mario_adec.v:152 7400H - 77FFH - VRAM (R)
rtl/mario_adec.v:155 74LS138 @ 3B Address decoding 7000H - 7FFFH (W)
rtl/mario_adec.v:172 7400H - 77FFH - VRAM (W)
rtl/mario_adec.v:175 74LS138 @ 3C Address decoding 6000H - 6FFFH (R/W) RAM0 @ 7B - 6000H - 67FFH RAM1 @ 7A - 6800H - 6FFFH
rtl/mario_adec.v:195 74LS138 @ 4B Address decoding 7C00H - 7FFFH (R) Enable signals for reading inputs and and DIP switches
rtl/mario_adec.v:217 74LS138 @ 4C Address decoding 7C00H - 7FFFH (W) Miscellaneous addressing.
rtl/mario_adec.v:243 74LS259 @ 2L Misc control signals (7E80H - 7E87H)
rtl/mario_adec.v:273 74LS259 @ 7M Sound Port (7F00H - 7F07H) Tiggers sound effects.
rtl/mario_adec.v:305 74LS374 @ 7J Sound data (7E00H) Data latch for sound CPU
rtl/mario_col_pal.v:35 Parts 4U, 5T (74LS157) Selects sprites or backgound pixels Sprites take priority
rtl/mario_main.v:184 Main CPU RAM 7A, 7B 2 x 2KB (6116)
rtl/mario_obj.v:132 Object RAM 8B, 8C 2 x 2148 (1KB) Sprite data is written to these RAM's via DMA.
rtl/mario_obj.v:279 RAM 8E 64 x 9 bits bipolar RAM with inverted O/C outputs.
rtl/mario_roms.v:11 0x00000 - 0x01FFF 7F PROGRAM ROM (8KB) 0x02000 - 0x03FFF 7E PROGRAM ROM (8KB) 0x04000 - 0x05FFF 7D PROGRAM ROM (8KB) 0x06000 - 0x06FFF 3F GFX ROM (4KB) 0x07000 - 0x07FFF 3J GFX ROM (4KB) 0x08000 - 0x08FFF 7C PROGRAM ROM (4KB) 0x09000 - 0x09
rtl/mario_roms.v:258 Sub CPU (Sound) External ROM 5K.
rtl/mario_roms.v:296 It is not known if the internal ROM has been dumped.
rtl/mario_vram.v:78 VRAM 2 x 2114 @ 3D, 3E (1KB)

Cites hardware references or measurements that MAME's driver also gives — 7

rtl/mario_adec.v:77 CPU can clear the NMI via register @ 2L. — also in MAME: 2L nintendo/mario.cpp:845
rtl/mario_adec.v:100 Address Decoder PROM @ 5B — also in MAME: 5B nintendo/mario.cpp:954
rtl/mario_col_pal.v:61 Colour PROM 4P (512 x 8bit) The PROM actually contains 2 versions of the colour palette: 0 - 255 = Inverted palette 256 - 512 = Standard palette Link CL2 on the PCB is used for selecting the palette. — also in MAME: 4P nintendo/mario.cpp:951
rtl/mario_roms.v:123 Object/Sprite ROMs 7M,7N,7P,7S,7T,7U. — also in MAME: 7M nintendo/mario.cpp:943, 7N nintendo/mario.cpp:944, 7P nintendo/mario.cpp:945, 7S nintendo/mario.cpp:946, 7T nintendo/mario.cpp:947, 7U nintendo/mario.cpp:948
rtl/mario_roms.v:204 CLUT PROM 4P (512x8) Only 256 entries are used. — also in MAME: 4P nintendo/mario.cpp:951
rtl/mario_roms.v:232 Address decoder PROM 5B (32x8) — also in MAME: 5B nintendo/mario.cpp:954
rtl/mario_vram.v:126 Video ROMs 3F, 3J — also in MAME: 3F nintendo/mario.cpp:939, 3J nintendo/mario.cpp:940

Cites MAME source — 1

Arcade-MarioBros.sv:301 JPAC/IPAC/MAME Style Codes

Says it was translated, ported or taken from MAME — 1

rtl/mario_roms.v:296 The solution below was taken from MAME.

Shares text with the MAME driver without saying so — 1

rtl/mario_input.v:12 BIT 0 1 2 3 4 5 6 7 — shares text with nintendo/mario.cpp:800

MCR1#
Kick, Solar Fox
MiSTer-devel/Arcade-MCR1_MiSTer @ 7cc5f869
MAME compared: bally/mcr.cpp + 7 related file(s)
Read: 13 HDL files, 3,748 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

41%

Statements: 1 toward hardware, 1 toward MAME, 1 not counted

Cites hardware documentation that MAME's driver does not — 1

rtl/mcr1.vhd:73 Sprite are 32x32 pixels with 1x1 pixel definition, 16 lines for odd 1/2 frame and 16 lines for even 2/2 frame thanks to V8 on sprite rom ROMAD2 (look at 74ls86 G1 pin 9 on video genration board schematics)

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/mcr1.vhd:841 sprite graphics ROM 1E/1D/1B/1A — also in MAME: 1E bally/mcr.cpp:1991, 1D bally/mcr.cpp:1990, 1B bally/mcr.cpp:1989, 1A bally/mcr.cpp:572

Cites MAME source — 1

rtl/YM2149_linmix_sep.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA

MCR2#
Domino Man, Kozmik Kroozr, Satan's Hollow, Tron …
MiSTer-devel/Arcade-MCR2_MiSTer @ 756fb64d
MAME compared: bally/mcr.cpp + 7 related file(s)
Read: 13 HDL files, 3,887 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

37%

Statements: 1 toward hardware, 1 toward MAME, 1 not counted

Cites hardware documentation that MAME's driver does not — 1

rtl/mcr2.vhd:74 Sprite are 32x32 pixels with 1x1 pixel definition, 16 lines for odd 1/2 frame and 16 lines for even 2/2 frame thanks to V8 on sprite rom ROMAD2 (look at 74ls86 G1 pin 9 on video genration board schematics)

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/mcr2.vhd:793 sprite graphics ROM 1E/1D/1B/1A — also in MAME: 1E bally/mcr.cpp:1991, 1D bally/mcr.cpp:1990, 1B bally/mcr.cpp:1989, 1A bally/mcr.cpp:572

Cites MAME source — 1

rtl/YM2149_linmix_sep.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA

MCR3#
Discs of Tron, Journey, Tapper, Timber
MiSTer-devel/Arcade-MCR3_MiSTer @ f74cb762
MAME compared: bally/mcr.cpp + 7 related file(s)
Read: 15 HDL files, 4,460 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

33%

Statements: 1 toward hardware, 2 toward MAME, 2 not counted

Cites hardware documentation that MAME's driver does not — 1

rtl/mcr3.vhd:74 Sprite are 32x32 pixels with 1x1 pixel definition, 16 lines for odd 1/2 frame and 16 lines for even 2/2 frame thanks to V8 on sprite rom ROMAD2 (look at 74ls86 G1 pin 9 on video genration board schematics)

Cites hardware references or measurements that MAME's driver also gives — 2

rtl/mcr3.vhd:838 background graphics ROM 6F — also in MAME: 6F bally/mcr.cpp:2578
rtl/mcr3.vhd:856 background graphics ROM 5F — also in MAME: 5F bally/mcr.cpp:2579

Cites MAME source — 2

rtl/YM2149_linmix_sep.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA
rtl/mcr3.vhd:34 Use with MAME roms from timber.zip

MCR3Mono#
Demolition Derby, Max RPM, Power Drive, Rampage …
MiSTer-devel/Arcade-MCR3Mono_MiSTer @ 780d31bc
MAME compared: bally/mcr3.cpp + 8 related file(s)
Read: 15 HDL files, 10,239 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

11%

Statements: 1 toward hardware, 2 toward MAME

Cites hardware documentation that MAME's driver does not — 1

rtl/mcr3mono.vhd:74 Sprite are 32x32 pixels with 1x1 pixel definition, 16 lines for odd 1/2 frame and 16 lines for even 2/2 frame thanks to V8 on sprite rom ROMAD2 (look at 74ls86 G1 pin 9 on video genration board schematics)

Cites MAME source — 1

rtl/mcr3mono.vhd:34 Use with MAME roms from timber.zip

Shares text with the MAME driver without saying so — 1

rtl/turbo_cheap_squeak.vhd:1 Midway Turbo Cheap Squeak sound board — shares text with bally/midway_sound.cpp:34

MCR3Scroll#
Crater Raider, Spy Hunter, Turbo Tag
MiSTer-devel/Arcade-MCR3Scroll_MiSTer @ 120a1612
MAME compared: bally/mcr3.cpp + 8 related file(s)
Read: 16 HDL files, 5,245 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

32%

Statements: 1 toward hardware, 1 toward MAME, 3 not counted

Cites hardware documentation that MAME's driver does not — 1

rtl/mcr3scroll.vhd:73 Sprite are 32x32 pixels with 1x1 pixel definition, 16 lines for odd 1/2 frame and 16 lines for even 2/2 frame thanks to V8 on sprite rom ROMAD2 (look at 74ls86 G1 pin 9 on video genration board schematics)

Cites hardware references or measurements that MAME's driver also gives — 3

rtl/mcr3scroll.vhd:1017 char graphics ROM 10G — also in MAME: 10G bally/mcr3.cpp:1528
rtl/mcr3scroll.vhd:1034 background graphics ROM 3A/4A — also in MAME: 3A bally/mcr3.cpp:1434, 4A bally/mcr3.cpp:1435
rtl/mcr3scroll.vhd:1051 background graphics ROM 5A/6A — also in MAME: 5A bally/mcr3.cpp:1436, 6A bally/mcr3.cpp:1437

Cites MAME source — 1

rtl/YM2149_linmix_sep.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA

MissileCommand#
Missile Command
MiSTer-devel/Arcade-MissileCommand_MiSTer @ a0bea970
MAME compared: atari/missile.cpp
Read: 24 HDL files, 5,367 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

15%

Statements: 4 toward hardware

Cites hardware documentation that MAME's driver does not — 4

rtl/ls42.v:2 74LS42 - BCD to decimal decoder
rtl/micro.v:49 L3 - 74S86 - XOR
rtl/micro.v:51 C4 - 74S32 - OR
rtl/missile.v:473 This part diverges from the original schematics quite a bit.

MoonPatrol#
Moon Patrol
MiSTer-devel/Arcade-MoonPatrol_MiSTer @ ff2845ca
MAME compared: irem/m52.cpp + 5 related file(s)
Read: 41 HDL files, 14,453 lines (Quartus project)

MiSTer official

Both

low

12%

Statements: 1 toward hardware, 6 toward MAME

Cites hardware documentation that MAME's driver does not — 1

rtl/iremm52_video_controller.vhd:68 from M52 schematics

Cites MAME source — 3

rtl/moon_patrol_sound_board.vhd:42 MAME claims that reading 8800 should return Z80's DE register value but PACE do something that seems to be (very) different.
rtl/tilemapctl.vhd:85 extract R,G,B from colour palette MAME says there are 512 palette entries although the code uses 6 bits of colour only the highest colour in the PROM is 83 so we're going with 128 (5+2 bits)
rtl/ym_2149_linmix.vhd:44 Clues from MAME sound driver and Kazuhiro TSUJIKAWA

Shares text with the MAME driver without saying so — 3

rtl/bitmap1_ctl.vhd:87 /* the colors to pick is as follows: */ — shares text with irem/m52.cpp:202
rtl/bitmap2_ctl.vhd:87 /* the colors to pick is as follows: */ — shares text with irem/m52.cpp:202
rtl/bitmap3_ctl.vhd:87 /* the colors to pick is as follows: */ — shares text with irem/m52.cpp:202

MrDo#
Mr. Do!
MiSTer-devel/Arcade-MrDo_MiSTer @ 9a4aed0c
MAME compared: universal/mrdo.cpp + 2 related file(s)
Read: 12 HDL files, 3,281 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

48%

Statements: 1 toward hardware

Cites hardware documentation that MAME's driver does not — 1

Arcade-MrDo.sv:776 address clock on the streaming buffer is at 5M.

MrJong#
Mr. Jong
MiSTer-devel/Arcade-MrJong_MiSTer @ f78655f6
MAME compared: sanritsu/mrjong.cpp
Read: 24 HDL files, 7,608 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

12%

Statements: 1 toward hardware

Cites hardware documentation that MAME's driver does not — 1

rtl/audio/sn76489_audio.vhd:52 * The SN76489 datasheet * Insight gained from the AY-3-8910/YM-2149 die-shot and reverse-engineered schematics (similar audio chips from the same era).

MysticMarathon#
Mystic Marathon
MiSTer-devel/Arcade-MysticMarathon_MiSTer @ adf358ef
MAME compared: williams/williams.cpp + 5 related file(s)
Read: 10 HDL files, 12,747 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

11%

Statements: 1 toward hardware, 2 toward MAME, 2 not counted

Cites hardware documentation that MAME's driver does not — 1

rtl/mystic_marathon_cmos_ram.vhd:29 @04-05: High score to date - BCD 00 to 01 - No / Yes @06-07: Pricing selection - BCD 00 to 09 - Custom / free play @08-09: Left coin slot units - BCD 00 to 99 @0A-0B: Center coin slot units - BCD 00 to 99 @0C-0D: Right co

Cites hardware references or measurements that MAME's driver also gives — 2

rtl/mystic_marathon_cmos_ram.vhd:47 @88-89: Position line 1 - HEX x08 to x44 @8A-8B: Position line 2 - HEX x08 to x44 — also in MAME: 8A williams/williams.cpp:2552, 8B williams/williams.cpp:2552
rtl/williams2.vhd:418 ic79 74LS85 controls low background color bank bit w.r.t ligne number (vcnt) — also in MAME: 74LS85 williams/williams_v.cpp:542

Cites MAME source — 1

rtl/williams2.vhd:36 Use with MAME roms from mysticm.zip

Shares text with the MAME driver without saying so — 1

rtl/williams2.vhd:329 pixels |0|1|2|3|4|5|0|1|2|3|4|5| — shares text with williams/williamsblitter.cpp:50

NaughtyBoy#
Naughty Boy
MiSTer-devel/Arcade-NaughtyBoy_MiSTer @ 519a5a6e
MAME compared: phoenix/naughtyb.cpp + 4 related file(s)
Read: 12 HDL files, 4,957 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

No statements found

NightSlashers#
Night Slashers
MiSTer-devel/Arcade-NightSlashers_MiSTer @ 52b0d5b3
MAME compared: dataeast/fghthist.cpp + 14 related file(s)
Read: 33 HDL files, 27,713 lines (Quartus project)

MiSTer official

Mostly MAME

medium

43%

Statements: 1 toward hardware, 193 toward MAME, 3 not counted

Cites hardware documentation that MAME's driver does not — 1

rtl/nightslashers/ns_audio_z80.sv:10 MAME deco32.cpp (autorevole): Z80 @ 32.22/9 = 3.58 MHz (qui cen 96/27 = 3.556, -0.68%) z80_sound_map: 0000-7FFF ROM, 8000-87FF RAM, A000-A001 YM2151, B000 OKI0, C000 OKI1, D000 soundlatch_r (DECO104) IRQ0 = merger(soundlatch | ym_irq) (:23

Cites hardware references or measurements that MAME's driver also gives — 3

rtl/nightslashers/nightslashers_top.sv:2595 Quindi la HuC salva: RAM 8K (M10K, porta di lettura UNICA muxata = zero logica), stato CPU (298 bit) e stato bus (32 bit). — also in MAME: 8K dataeast/fghthist.cpp:83
rtl/nightslashers/ns_audio_huc.sv:76 0..8191 = RAM 8K, 8192..8447 = shadow YM — also in MAME: 8K dataeast/fghthist.cpp:83
rtl/nightslashers/ns_audio_huc.sv:366 Lo stato FM/ADPCM del set USA non entra nel savestate; CPU HuC, RAM 8K (M10K) e stato bus si'. — also in MAME: 8K dataeast/fghthist.cpp:83

Cites MAME source — 171

Template.sv:192 FIX 2026-07-03: brev8 text=0 — combo PROVATA DIFF=0 su 262144 pen vs golden MAME (work/tile_text_chain_verify.py); con brev8=1 ogni riga del text era specchiata in X. 2026-07-09 HARDCODED DEFINITIVI — convalidati A SCHERMO dall'utente via O
Template.sv:244 Default 0 = MAME -16.
Template.sv:288 ATTENZIONE 2026-08-28: il "~70-75% di MAME" che stava scritto qui era una IPOTESI (quantizzazione tick), MAI misurata, e da qui si e' propagata nei documenti come se fosse un dato.
Template.sv:291 Ho provato a misurarla con sim/tb/tb_ns_runtime.sv, ma anche quei numeri sono INVALIDI: confrontando la traccia col golden di arm.cpp, quel banco consegna alla CPU una istruzione su due sbagliata (0xFFFFFFFF), quindi misurava un processore
Template.sv:295 Quello che resta vero e' solo: la CPU gira a 7,065 MHz contro i 7,000 di MAME (ARM(config, m_maincpu, 28_MHz_XTAL/4)), e Night Slashers rallenta di suo anche in sala — quindi alzare il clock porta il gioco OLTRE la PCB e nasconde anche i ra
Template.sv:432 I tile NS SONO criptati (deco32.cpp init_nslasher: deco56 tiles1 + deco74 tiles2, + bitplane reorder).
Template.sv:559 --- BoogieWings INPUT mapping (MAME boogwing.cpp:561-633 INPUT_PORTS_START) --- MiSTer joy bit layout (MiSTer convention): [0]=Right, [1]=Left, [2]=Down, [3]=Up [4]=A (FIRE/BTN1), [5]=B (BOMB/BTN2), [6]=X (SPECIAL/BTN3) [10]=Start, [11]=Coi
Template.sv:565 INPUTS port (MAME "INPUTS", 16-bit, tutto active LOW):
Template.sv:588 SYSTEM port (MAME "SYSTEM", 16-bit): bit 0: COIN1 (active LOW) bit 1: COIN2 (active LOW) bit 2: SERVICE1 (active LOW) bit 3: VBLANK (active HIGH — da screen device) bit 4..15: unused (idle HIGH)
Template.sv:595 bit 15..8 = P3 (MAME IN1).
Template.sv:607 bit 3 VBLANK (active HIGH MAME → 1 quando in vblank)
Template.sv:1016 Il core divide /6 (CPU_CLK_CNT 0..5) -> ciclo macchina = 24/6 = 4.0 MHz = clock HuC MAME (4.0275 MHz, 32.22/8).
Template.sv:1119 OSD audio gain decoder: 4 bit → gain 4.4 fixed point 0=Default 1=Mute 2=MAME 3=25% 4=50% 5=75% 6=100% 7=125% 8=150% 9=200% 10=250% 11=300% 12=400% 13=500% 14=700% 15=1000% % indicato è scaling rispetto al Default (= valore base per ogni chi
Template.sv:1144 Default HW-tested (= valori RTL applicati con foto utente OSD 200%/300%/400%): FM=0x08 (0.5), OKI0=0xFF (15.94, =sat max), OKI1=0x80 (8.0) MAME esatti: FM=0x05 (0.32), OKI0=0x09 (0.56), OKI1=0x02 (0.12)
Template.sv:1165 OSD sel passati direttamente al chip audio (Default/MAME hardcoded dentro).
Template.sv:1348 BoogieWings video timing: 320×240 60Hz (boogwing.cpp:731: htot=442, hact=320, vtot=274, vact=240) Pixel clock: 96/14 = 6.857 MHz (divisore intero).
Template.sv:1371 2026-07-10 FIX pixel 319 (confronto screenshot MAME dell'utente: a noi mancava l'ultima colonna): rgb_out_q campiona su ce_pix = immagine in ritardo di 1 px vs DE -> la colonna 319 usciva a DE gia' caduto.
rtl/cpu_arm/a23_copro_deco156.v:30 bcd<->dec use 8 nibbles (32-bit), base-10, exactly as MAME.
rtl/cpu_arm/a23_copro_deco156.v:40 Reproduces public-domain documented behaviour from MAME.
rtl/cpu_arm/a23_core.v:358 L'assunzione "zero copro ops" era SBAGLIATA: 2860 istruzioni coproc nel codice, e MAME HandleCoPro implementa il BCD (crn==2 -> add/mul/sub in cr[5]).
rtl/cpu_arm/a23_core.v:360 FIX: istanzio a23_copro_deco156 (gia' scritto, fedele a MAME) + disabilito und_request sulle coproc in a23_decode.
rtl/cpu_arm/a23_decode.v:79 reset = IRQ MASCHERATO (MAME arm.cpp:319 R15=SVC|I_MASK|F_MASK).
rtl/cpu_arm/a23_decode.v:79 PROVATO co-sim: con irq_mask=0 l'Amber prende un IRQ nel bit-bang EEPROM (n=41054, 0x3e7a0) dove MAME tiene I=1 -> boot interrotto -> NERO
rtl/cpu_arm/a23_decode.v:477 BUG BOOT-FATAL (nero): per un data-processing con operando IMMEDIATO ruotato (instruction[25]=1 && rotate instruction[11:8]!=0) e S-bit, MAME/golden pongono C = bit31 dell'immediato RUOTATO (arm.cpp:788 sc=op2&SIGN_BIT).
rtl/cpu_arm/a23_decode.v:571 DECO156 (Night Slashers): MAME arm.cpp:405-410 instrada CDP/MRC/MCR (encoding 0x0e000000) a HandleCoPro SENZA eccezione; solo cio' che NON e' coproc va a Undefined (arm.cpp:422).
rtl/cpu_arm/a23_decode.v:580 NB verificato col disassembler: il codice eseguibile NS non contiene coproc reali (tutte nei blocchi dati) -> questa regola e' per fedelta' a MAME, non e' la causa nero.
rtl/cpu_arm/a23_execute.v:177 reset = IRQ MASCHERATO (MAME arm.cpp:319).
rtl/cpu_arm/a23_execute.v:499 reset = IRQ MASCHERATO (MAME arm.cpp:319).
rtl/cpu_arm/a23_execute.v:545 BUG BOOT-FATAL fix: per immediato ruotato il C ai logici = bit31 dell'immediato (gia' ruotato in barrel_shift_in = i_imm32), come MAME arm.cpp:788 (sc=op2&SIGN_BIT).
rtl/nightslashers/deco16ic_jt.sv:81 Flip screen globale (MAME boogwing.cpp:419-425: pf_control_r(0) bit 7).
rtl/nightslashers/deco16ic_jt.sv:82 Sponta solo da chip 0 (chip1 ha il suo ma MAME usa solo chip0).
rtl/nightslashers/deco16ic_jt.sv:125 Combine 8bpp (MAME tilemap_12_combine_draw, priority 4/5): pf1 e pf2 sono lo STESSO pixel (nibble basso/alto).
rtl/nightslashers/deco16ic_jt.sv:288 Flip screen globale (MAME boogwing.cpp:419-425): flip = m_deco_tilegen[0]->pf_control_r(0); flip_screen = BIT(flip,7);
rtl/nightslashers/deco16ic_jt.sv:292 MAME deco16ic.cpp:899-900 (codice, NON il commento header che è invertito): PF1 scroll = ctrl[1] (X), ctrl[2] (Y) PF2 scroll = ctrl[3] (X), ctrl[4] (Y)
rtl/nightslashers/deco16ic_jt.sv:300 Rowscroll enable + style (MAME deco16ic.cpp header riga 94-130) pf12_control[5] (word 0xa): bit 15 = pf1 enable bit 14:11 = pf1 rowscroll style bit 10:8 = pf1 colscroll style bit 7 = pf2 enable bit 6:3 = pf2 rowscroll style bit 2:
rtl/nightslashers/deco16ic_jt.sv:319 MAME riga 761: (control0 >> 3) & 0xf -> bit 6:3 per pf1 row style.
rtl/nightslashers/deco16ic_jt.sv:326 COLSCROLL Y-per-column (MAME deco16ic.cpp:492-497, 812): col_type = 8 << (control0 & 7) ∈ {8,16,32,64,128,256,512,1024} col_idx = (src_x & 0x1ff) / col_type col_offset = rowscroll_ptr[0x200 + col_idx] // 16-bit Y offset veff_eff = veff +
rtl/nightslashers/deco16ic_jt.sv:342 PLAYFIELD DISABLE (MAME deco16ic.cpp:465: if(!BIT(control0,7)) return;).
rtl/nightslashers/deco16ic_jt.sv:365 Per text 8x8 MAME dimezza numrows (riga 798); equivalente a >> 1 sull'idx.
rtl/nightslashers/deco16ic_jt.sv:388 FIX colonne durante scroll (MAME deco16ic.cpp:493 col_idx da src_x = pixel REALE): src_x deve azzerare il sub-tile offset scroll_x[3:0] (16x16) o [2:0] (8x8).
rtl/nightslashers/deco16ic_jt.sv:435 MAME deco32.cpp:918 bank_callback = (bank & ~0xf) << 8 = bank[7:4]<<12, UNIFORME, indipendente dal nibble basso.
rtl/nightslashers/deco16ic_jt.sv:436 Il vecchio mode 2 aggiungeva un +0x800 inventato su nibble==0xA (non in MAME) -> mis-bank scenografia chip1 in scene con control[7] nibble 0xA -> tile trasparenti -> sfondo blu.
rtl/nightslashers/deco16ic_jt.sv:554 VRAM swizzle hardcoded: 8x8 (text) = Linear idx = {row[4:0], col[5:0]} 16x16 (BG) = DECO_64x32 idx = {col[5], row[4:0], col[4:0]} MAME deco16ic.cpp:245 — TILEMAP_SCAN_ROWS per 8x8, deco16_scan_rows per 16x16.
rtl/nightslashers/deco16ic_jt.sv:582 Flip per-tile (MAME deco16ic.cpp:330-341 get_pf1_tile_info): if (vram[15] && ctrl[6][0]) → FLIPX, colour &= 7 if (vram[15] && ctrl[6][1]) → FLIPY, colour &= 7 Per pf2 (16x16): ctrl[6][8] e ctrl[6][9].
rtl/nightslashers/deco16ic_jt.sv:630 Sub-tile X offset: scan parte da tile-aligned, buf_waddr inizia negativo (wrap 9-bit) per scartare i primi N pixel del primo tile (= MAME src_x = scroll_x + render_x).
rtl/nightslashers/deco16ic_jt.sv:677 MAME: colour = tile[15:12], if tile[15] && flipctrl colour &= 7
rtl/nightslashers/deco16ic_jt.sv:896 Colscroll attivo: veff_eff = render_y + scroll + cs (MAME esatto).
rtl/nightslashers/deco16ic_jt.sv:915 Flip per-tile pf2 (MAME deco16ic.cpp:300-311): ctrl[6][8] = FLIPX, ctrl[6][9] = FLIPY (per pf2)
rtl/nightslashers/deco16ic_jt.sv:957 Sub-tile X offset: waddr inizia negativo (= 9-bit wrap) per scartare primi N pixel del primo tile = MAME src_x pixel-by-pixel.
rtl/nightslashers/deco16ic_jt.sv:1022 Bit position MAME-natural: sc2_pen_p4 = p4_byte[bit_pos].
rtl/nightslashers/nightslashers_top.sv:11 Hardware MAME (deco32.cpp; boogwing.cpp per l'ossatura condivisa):
rtl/nightslashers/nightslashers_top.sv:20 Memory map main (boogwing.cpp:504): 0x000000-0x0FFFFF ROM (1MB, encrypted) 0x200000-0x20FFFF work RAM (64KB) 0x220000 priority_w 0x240000/0x244000 spriteram DMA trigger 0x242000/0x246000 spriteram1/2 (2KB ciascuno) 0x24E000-0x
rtl/nightslashers/nightslashers_top.sv:35 Memory map audio H6280 (boogwing.cpp:547): 0x000000-0x00FFFF ROM (64KB) 0x110000 YM2151 r/w 0x120000 OKI1 r/w 0x130000 OKI2 r/w 0x140000 sound latch read 0x1F0000-0x1F1FFF work RAM (8KB)
rtl/nightslashers/nightslashers_top.sv:60 Inputs MAME-mapping BoogieWings (vedi docs/99_discovery_log.md): inputs_port = INPUTS (16-bit, P1+P2 joy+button+start, active LOW) system_port = SYSTEM (16-bit, coin+service+vblank, active LOW eccetto vblank)
rtl/nightslashers/nightslashers_top.sv:134 24 MHz -> CE_IN HuC (core /6 = 4.0 MHz = MAME)
rtl/nightslashers/nightslashers_top.sv:151 OSD audio sel (4 bit each) — Default/MAME hardcoded dentro boogwings_audio
rtl/nightslashers/nightslashers_top.sv:284 Noprw range MAME (boogwing.cpp:510, 534, 535) — devono produrre DTACK ma scrittura/lettura senza effetti (read=FFFF, write=ignorata).
rtl/nightslashers/nightslashers_top.sv:291 2026-07-10 CPU SPEED OSD: la quantizzazione dei tick (LDR/STR=2 tick, branch=3-4) porta l'effettivo a ~70-75% di MAME -> sforamenti frame nelle scene piene = rallentoni dove l'originale non li ha.
rtl/nightslashers/nightslashers_top.sv:456 NS ARM memory map (bytes), from MAME deco32.cpp nslasher_map: 0x000000-0x0FFFFF ROM (SDRAM) 32-bit 0x100000-0x11FFFF work RAM 128KB 32-bit 0x140000-0x140003 vblank ack (write) 0x150000 EEPROM (CS/CLK/DI=6/5/4
rtl/nightslashers/nightslashers_top.sv:485 nslasher_debug_r (0x200000 lower 16) = 0xFFFF fisso (come MAME nslasher_debug_r()).
rtl/nightslashers/nightslashers_top.sv:488 NS priority register m_pri: deco32_v.cpp eeprom_w (the 0x150000 write) calls pri_w(data & 0x07).
rtl/nightslashers/nightslashers_top.sv:500 ── EEPROM 93C46 seriale (NS) ─────────────────────────────────────────────── MAME deco32.cpp eeprom_w (0x150000 byte): bit6=CS, bit5=CLK, bit4=DI.
rtl/nightslashers/nightslashers_top.sv:523 (NS: MAME port_b = eeprom do_read lshift 0.
rtl/nightslashers/nightslashers_top.sv:523 I coin NS NON sono in port_b.) FIX STALLO 2026-07-03: system_port[3] dal Template e' VBlank (layout SYSTEM BoogieWings) ma per il firmware NS bit3 = tasto SERVICE active-LOW (MAME IN1, deco32.cpp): col VBlank il gioco vede SERVICE premuto p
rtl/nightslashers/nightslashers_top.sv:530 bit 15..4 IDLE fissi: da quando system_port[15:8] porta il P3 (Template 2026-07-11), il port_b NON deve vederlo — MAME port_b = solo EEPROM DO.
rtl/nightslashers/nightslashers_top.sv:552 port_c verso il DECO146 = IN1 (MAME deco32.cpp:2021 port_c_cb=IN1, def riga 1554): bit0=COIN1, bit1=COIN2, bit2=SERVICE1, bit3=SERVICE(no-toggle), bit4 (0x0010) = VBLANK **active-HIGH** (PORT_READ_LINE screen vblank), bit8-10/12-14 = BUTTON
rtl/nightslashers/nightslashers_top.sv:572 2026-08-29 — DIMOSTRATO DALLA ROM (non da MAME: il difetto del boss c'e' anche li', quindi come oracolo non vale).
rtl/nightslashers/nightslashers_top.sv:750 MAME deco32.cpp ioprot_r/w: deco146_addr = (BIT(real,14,4)<<11) | BIT(real,0,11), real = in-region byte addr.
rtl/nightslashers/nightslashers_top.sv:752 Verified numerically (work/arm_decrypt/deco146_map.py): the 11 LOW bits used by MAME ioprot_r (deco32.cpp:711-714): offset = byte_addr>>2 (umask32 0xffff0000, one 16-bit prot word per 32-bit dword); real_address = offset*2 = byte_addr>>1; d
rtl/nightslashers/nightslashers_top.sv:777 Tilegen1 (DECO16IC #1): pf1 0x1c2000, pf2 0x1c4000, rowscroll 0x1d2000/0x1d4000, control 0x1e0000 (deco32.cpp nslasher_map).
rtl/nightslashers/nightslashers_top.sv:788 The actual buffer copy is done at vblank (MAME buffered_spriteram), the trigger write is a NOP here.
rtl/nightslashers/nightslashers_top.sv:797 NS palette/ACE (deco32.cpp nslasher_map): ACE 'Ace' RAM 0x163000-0x16309F (ace_r/ace_w, 40 words) color banks 0x164000 / 0x164004 / 0x164008 (tilemap / spr1 / spr2) buffered palette 0x168000-0x169FFF (8KB = 4096 words = 2048 RGB entri
rtl/nightslashers/nightslashers_top.sv:838 ── Read data assembly back to the 32-bit ARM bus ── 16-bit chips return data in the lower half with a 0xFFFF0000 endianness XOR (MAME deco16ic/deco32 dword readers).
rtl/nightslashers/nightslashers_top.sv:843 16-bit video chips return their word in the LOWER half with upper=0xFFFF (this IS the MAME 0xFFFF0000 dword XOR, same as the ROM line).
rtl/nightslashers/nightslashers_top.sv:1031 MAME boogwing.cpp:529-530: chip1 pf1/pf2 mappati con `.ram().w(deco16ic)`.
rtl/nightslashers/nightslashers_top.sv:1197 DECO104 magic xor value (deco104.cpp ctor)
rtl/nightslashers/nightslashers_top.sv:1212 NS: IN1 = coin/service + bit4 VBLANK (MAME), NON i DIP
rtl/nightslashers/nightslashers_top.sv:1279 NS colour bank registers (0x164000/4/8) — deco32_v.cpp tilemap/sprite_color_bank_w 0x164000 tilemap_color_bank_w: tilegen1 pf1 bank = ((d>>0)&7)<<4, tilegen1 pf2 bank = ((d>>3)&7)<<4 0x164004 sprite1_color_bank_w: sprgen0 colorbase = (d&7)<
rtl/nightslashers/nightslashers_top.sv:1308 Decoded fields (raw, consumed by the NS mixer in the palette-index step): tilegen1 pf1 bank field = data[2:0], pf2 bank field = data[5:3] (MAME <<4) sprite0/1 colorbase field = data[2:0] (MAME <<8) Step 1 only CAPTURES these registers; the
rtl/nightslashers/nightslashers_top.sv:1341 chip0 ctrl[0] bit 7 (MAME boogwing.cpp:419)
rtl/nightslashers/nightslashers_top.sv:1342 Render x/y flippati quando flip_screen=1 (MAME flip_screen_set).
rtl/nightslashers/nightslashers_top.sv:1346 Mantengo formula MAME-coerente.
rtl/nightslashers/nightslashers_top.sv:1368 BoogieWings bank callbacks (boogwing.cpp:749, 761): tilegen[0]: bank1=none, bank2=bank_callback (mode 1) tilegen[1]: bank1=bank_callback2, bank2=bank_callback2 (mode 2) GFX base address SDRAM (tile_byte_addr relativo a TILE_BASE): tiles1 (t
rtl/nightslashers/nightslashers_top.sv:1389 NS: chip0.pf2 (BG) e' 4bpp (deco32.cpp tilelayout, verificato max pen 0xF), NON 5bpp come il BG1 di BoogieWings.
rtl/nightslashers/nightslashers_top.sv:1523 Buffer side (DMA write dest + renderer read source) — buffered_spriteram MAME-style
rtl/nightslashers/nightslashers_top.sv:1543 MAME (buffer_spriteram_w = memcpy istantanea) non perde MAI una write.
rtl/nightslashers/nightslashers_top.sv:1543 Con la CPU al ~70-75% di MAME le scene piene sforano il frame -> la build della lista nuova parte mentre la copia gira -> prime entry (boss) droppate = pezzi col frame vecchio = movimenti nervosi.
rtl/nightslashers/nightslashers_top.sv:1546 Write-through sempre: la copia prende vecchio-o-nuovo per word (jitter +/-77us, MAME-legale).
rtl/nightslashers/nightslashers_top.sv:1610 ── FIX STIRAMENTO 2026-07-19 (correla con rallentamenti CPU) ── MAME (deco32.cpp:842 buffer_spriteram_w): il copy live->buffer avviene SOLO quando la CPU scrive 0x174010/0x17c010 (= lista sprite COMPLETA).
rtl/nightslashers/nightslashers_top.sv:1643 copy LIVE -> BUFFER a VBlank rise, SOLO se la CPU ha triggerato (0x174010/ 0x17c010 = lista completa, MAME buffer_spriteram_w).
rtl/nightslashers/nightslashers_top.sv:1711 CPU readback NON serve (write-only dal punto di vista di MAME boogwing: il chip è palette device, leggere è debug).
rtl/nightslashers/nightslashers_top.sv:1717 Palette DECO_ACE 24-bit RGB888 (MAME deco_ace.cpp): m_paletteram[2048] è uint32: bits 23:16 = B byte, 15:8 = G byte, 7:0 = R byte.
rtl/nightslashers/nightslashers_top.sv:1728 MAME deco_ace.cpp:131/177: m_paletteram[entry]=data; b=d[23:16] g=d[15:8] r=d[7:0].
rtl/nightslashers/nightslashers_top.sv:1779 CPU READBACK VERO (MAME buffered_palette_r) — copia dedicata: le 2 porte di pal_cpu_ent sono gia' occupate (write CPU/SS + read DMA).
rtl/nightslashers/nightslashers_top.sv:1835 FIX: trigger = pulse di 1 ck (rising edge), come MAME.
rtl/nightslashers/nightslashers_top.sv:1873 FIX 2026-07-03 stride ACE: MAME umask32 (deco32.cpp:630) = 1 reg per DWORD -> idx = aa[7:2].
rtl/nightslashers/nightslashers_top.sv:1961 Palette index base (boogwing.cpp:gfx_boogwing entries): tiles1 (text 8×8) = palette base 0x800 tiles2 (deco16_0) = palette base 0x100 tiles3 (deco16_1) = palette base 0x300
rtl/nightslashers/nightslashers_top.sv:1974 Palette index per layer (MAME gfx_boogwing boogwing.cpp:671): tiles1 (text) → base 0x800, 16 set × 16 col (4bpp) tiles2 (BG1) → base 0x100, 16 set × 32 col (5bpp → ora 4bpp, upper half vuota finché plane 4 non impl) tiles3 (BG2) → base
rtl/nightslashers/nightslashers_top.sv:1990 La logica MAME ha 5 modi diversi via priority_reg[2:0] (vedi screen_update); per ora implemento solo l'ordine default.
rtl/nightslashers/nightslashers_top.sv:1992 (col_bank di chip1 pf2 è già dentro d16_1_pf2_col → non sommato qui) Palette base per layer — MAME GFXDECODE (boogwing.cpp:672-674): MAME gfx_nslasher (deco32.cpp:1870): text(tiles1 charlayout)=0x800, BG1(tiles1 tilelayout)=0x000, BG2/3(til
rtl/nightslashers/nightslashers_top.sv:1998 Base NS = 0x000 + color bank runtime (0x164000) sommato sopra, come MAME deco16_tilemap_colour_bank.
rtl/nightslashers/nightslashers_top.sv:2001 BG1 (MAME tiles1 tilelayout base 0)
rtl/nightslashers/nightslashers_top.sv:2002 BG2 (MAME tiles2 tilelayout base 0)
rtl/nightslashers/nightslashers_top.sv:2006 Layer mixer con priority register MAME-compliant (5 modi).
rtl/nightslashers/nightslashers_top.sv:2007 Riferimento: boogwing.cpp:417-477 screen_update.
rtl/nightslashers/nightslashers_top.sv:2026 FIX 2026-07-03 (MAME deco32.cpp:1152 + deco32_v.cpp:492): i modi sono BIT, non valori: bit0=ordine layer, bit1=BG2/3 joint 8bpp, bit2=fade.
rtl/nightslashers/nightslashers_top.sv:2027 Il vecchio decode (pri==4||pri==5) teneva il mixer in combine-mode con pri=4 runtime, dove MAME (m_pri&2=0) disegna i layer SEPARATI.
rtl/nightslashers/nightslashers_top.sv:2035 FIX 2026-07-03 COLOR BANK (MAME deco32.cpp:2326 pf2_col_bank=0x10 statico su chip0; deco32_v.cpp:56-59 cbank runtime <<4 colori = <<8 entry su chip1): il fix di giugno "basi a 0x000" era incompleto — i BG indicizzano a +0x100/+0x200/+0x300
rtl/nightslashers/nightslashers_top.sv:2046 Pal_idx singoli (per modi separati) BG1 (chip0.pf2): bank statico MAME 0x10 (=+0x100 entry) + stride 4bpp col*16 (il vecchio col<<5 era eredita' 5bpp BoogieWings).
rtl/nightslashers/nightslashers_top.sv:2052 MAME formula: pal_idx = base + bank + col_5b * 16 + pen[3:0].
rtl/nightslashers/nightslashers_top.sv:2061 NS sprite palette (mix_nslasher, ns_video.cpp:346/395): chip0 (5bpp, gfx0): col0 = (color[4:0] % 16) * granularity(32); base = colorbase = sprite1_color_bank_w (data&7)<<8.
rtl/nightslashers/nightslashers_top.sv:2083 NS MIX — FEDELE a mix_nslasher (reference/ns_video.cpp:322-462) + screen_update_nslasher (:464-522).
rtl/nightslashers/nightslashers_top.sv:2089 get_alpha (deco_ace.cpp): regval>0x20 -> 0x80; else clamp(255 - reg<<3).
rtl/nightslashers/nightslashers_top.sv:2100 Attributi sprite (bit del temp-word MAME priColAlphaPal0/1):
rtl/nightslashers/nightslashers_top.sv:2115 else: FG1 (primask 1) sotto; m_pri&1: BG1 (2), FG0 (4 -> alpha bitmap se ns_at_en, NIENTE priority) else: FG0 (2), BG1 (4 -> alpha bitmap se ns_at_en) BACKDROP = pen 0x300 (deco32_v.cpp:476).
rtl/nightslashers/nightslashers_top.sv:2118 ns_tm_pri = tilemapPri MAME (4/2/1/0).
rtl/nightslashers/nightslashers_top.sv:2188 coloffs del ramo sprite1 e alpha-tilemap (mix :387): 0x800 SOLO se (m_pri&4)==0 E sprite0 ha disegnato (il nome MAME 'sprite1_drawn' = s0 drew, fuorviante).
rtl/nightslashers/nightslashers_top.sv:2227 TEXT: MAME lo disegna ULTIMO, sopra tutto (screen_update :65)
rtl/nightslashers/nightslashers_top.sv:2262 === DECO_ACE FADE (deco_ace.cpp:165-199) — ESATTO, identico a MAME bit-per-bit.
rtl/nightslashers/nightslashers_top.sv:2304 Palette RAW vs FADED (deco_ace.cpp:175-198): la palette deco_ace ha 4096 pen: 0x000-0x7FF = palette CON fade (set_pen_color(i)).
rtl/nightslashers/nightslashers_top.sv:2307 MAME indicizza con paldata[pal_idx]: se pal_idx >= 0x800 -> RAW (no fade).
rtl/nightslashers/nightslashers_top.sv:2308 Gli sprite/BG (base <0x800) vanno raw solo col calculated_coloffs (priority bit3 -> +0x800, boogwing.cpp:355).
rtl/nightslashers/nightslashers_top.sv:2311 Il bit 11 dell'indice (0x800) marca "raw" = bypass del fade, PER-PIXEL su top e bot separati (come MAME: l'offset 0x800 e' per-sorgente, NON globale).
rtl/nightslashers/nightslashers_top.sv:2344 MAME alpha_blend_r32 convention: result = (src * alpha + dst * (256 - alpha)) >> 8.
rtl/nightslashers/nightslashers_top.sv:2360 MAME sub_blend_r32 (boogwing.cpp:180-188): INVERTE la source (s ^= 0xffffff), poi blend tra src_invertita e dst con shift >>9: result = (inv_src * level + dst * (256 - level)) >> 9 (level = alpha) Output SEMPRE in range, mai sotto zero (
rtl/nightslashers/nightslashers_top.sv:2379 In MAME line 408: alpha_blend_r32(dstline[x] = BG, pix3 = FG0).
rtl/nightslashers/nightslashers_top.sv:2399 Fade sul colore at (stessa formula, raw-exempt su idx bit11) — il fade e' affine: commuta col blend convesso, quindi l'ordine fade->blend qui equivale al MAME (pen gia' fadate).
rtl/nightslashers/nightslashers_top.sv:2496 2026-07-10 AUDIO VERO (set World/Korea/Japan): Z80 (T80pa) + YM2151 (jt51) + 2x OKI (jt6295) secondo MAME deco32.cpp z80_sound_map/nslasher config.
rtl/nightslashers/nightslashers_top.sv:2668 24 MHz -> CE_IN HuC (core /6 = 4.0 MHz = MAME)
rtl/nightslashers/nightslashers_top.sv:2825 sprite_romaddr e' in spazio MAME (= source 4MB).
rtl/nightslashers/nightslashers_top.sv:2934 NS tile layout (deco32.cpp): only 2 regions, both 2MB, both 4bpp.
rtl/nightslashers/nightslashers_top.sv:2977 Sprite download interleave: layout MAME tile_16x16_layout richiede plane 0,1 da LO region, plane 2,3 da HI region.
rtl/nightslashers/ns_audio_huc.sv:15 MAME deco32.cpp nslasheru: the US release uses HuC6280 instead of the Z80.
rtl/nightslashers/ns_audio_huc.sv:19 HuC clock: CE_IN = frac_cen 16.11 MHz; firmware CSH -> /6 = 2.685 MHz MAME-exact.
rtl/nightslashers/ns_audio_huc.sv:20 HuC internal PSG NOT used (MAME: internal sound unused).
rtl/nightslashers/ns_audio_huc.sv:30 24 MHz pulse -> CE_IN HuC (core /6 = 4.0 MHz = MAME)
rtl/nightslashers/ns_audio_huc.sv:141 Il core divide /6 (CPU_CLK_CNT 0..5) -> ciclo macchina = 24/6 = 4.0 MHz = clock HuC MAME (4.0275 MHz = 32.22/8).
rtl/nightslashers/ns_audio_huc.sv:143 VALIDATO coi numeri MAME (screenshot): YM/OKI corretti (<1%), solo l'HuC era fuori.
rtl/nightslashers/ns_audio_huc.sv:195 -- Decode h6280_sound_map — STRETTO, identico alla build che suonava (brjbx8300 ricostruita): periferiche su finestre 16 byte come la mappa MAME (110000-110001 ecc.), NON pagine intere 64K (pattern BW).
rtl/nightslashers/ns_audio_huc.sv:245 Il firmware HuC ASSUME RAM=0 (come MAME .ram() power-on clear): il suo TAI init la azzera, ma sul ferro il timing puo' far saltare la sincronizzazione -> RAM indefinita -> avvio a caso a ogni reset (dimostrato sul ferro).
rtl/nightslashers/ns_audio_huc.sv:281 -- Soundlatch MAME-exact — LATCH SINGOLO, non FIFO (2026-07-14) ------------- La build che SUONAVA sul ferro (brjbx8300, ricostruita bit-exact dagli archivi di sessione) usava QUESTO schema: un byte (ultima write vince) + flag IRQ level, CL
rtl/nightslashers/ns_audio_z80.sv:10 MAME deco32.cpp (autorevole): Z80 @ 32.22/9 = 3.58 MHz (qui cen 96/27 = 3.556, -0.68%) z80_sound_map: 0000-7FFF ROM, 8000-87FF RAM, A000-A001 YM2151, B000 OKI0, C000 OKI1, D000 soundlatch_r (DECO104) IRQ0 = merger(soundlatch | ym_irq) (:23
rtl/nightslashers/ns_audio_z80.sv:93 La voce OSD "MAME" resta ai pesi route MAME fedeli (ym 0.40, oki0 0.80, oki1 0.10 in Q4.4) per confronto.
rtl/nightslashers/ns_audio_z80.sv:193 ── Decode (mappa MAME z80_sound_map) ───────────────────────────────────────
rtl/nightslashers/ns_audio_z80.sv:224 ── Soundlatch MAME-exact (deco146 soundlatch_r / write_soundlatch) ───────── FIX 2026-07-10: il latch REALE e' UN byte + flag IRQ level: ogni write SOVRASCRIVE (l'ultima vince), la read Z80 di D000 CLEARA l'IRQ e restituisce il byte corrent
rtl/nightslashers/ns_audio_z80.sv:233 Semantica MAME = per makeup.
rtl/nightslashers/ns_audio_z80.sv:312 ── IRQ merger (MAME :2380): soundlatch | YM -> IRQ0 ────────────────────────
rtl/nightslashers/ns_audio_z80.sv:510 ── DIN mux Z80 ────────────────────────────────────────────────────────────── FIX 2026-07-10 — LA CAUSA DEL "motore muto": MAME z80_sound_io (deco32.cpp:688) mappa TUTTI i 64KB della ROM nello spazio I/O: map(0x0000, 0xffff).rom().region("a
rtl/nightslashers/ns_sprites.sv:9 MAME equivalente: m_sprite_bitmap full-frame 320×256 + draw_sprites_common.
rtl/nightslashers/ns_sprites.sv:23 Output identico al MAME m_sprite_bitmap se scan ordinata correttamente.
rtl/nightslashers/ns_sprites.sv:26 MAME standard format (offs +0/+1/+2): +0: efFbSssyyyyyyyyy e=priority, f=flipy, F=flipx, b=flash, S=w, ss=h +1: tttttttttttttttt tile code +2: ppcccccxxxxxxxxx pp=priority, ccccc=color (5b), x=xpos
rtl/nightslashers/ns_sprites.sv:106 flipscreen sprite — MAME boogwing.cpp:424 set_flip_screen(!BIT(flip,7)) → SEMPRE invertito rispetto a flip_screen input (= tilemap flip).
rtl/nightslashers/ns_sprites.sv:129 Frame parity per il FLASH sprite (MAME decospr.cpp:227: flag y_word[12], lo sprite e' nascosto sui frame DISPARI -> if(!(flash && (frame_number & 1))) draw).
rtl/nightslashers/ns_sprites.sv:140 ~pause_in: in pausa il vblank continua (display vivo) ma la parita' frame resta ferma -> il FLASH si congela come su PCB/MAME (niente flicker in pausa).
rtl/nightslashers/ns_sprites.sv:348 MAME decospr.cpp:267-282 + 297-314 — formula completa boogwing con flipscreen=ON:
rtl/nightslashers/ns_sprites.sv:357 MAME boogwing.cpp:424 set_flip_screen(!BIT(flip,7)) → default ON (flip[7]=0).
rtl/nightslashers/ns_sprites.sv:369 Solo "sign-ext" con soglia 320 (MAME decospr.cpp:267-269): x = x & 0x1ff; (9-bit 0..511) if (x >= 320) x -= 512; (0..319 unsigned, 320..511 → -192..-1) Risultato: signed -192..319 (10-bit signed sufficiente).
rtl/nightslashers/ns_sprites.sv:572 fx_eff = flipx ^ flipscreen_spr (MAME riga 306-313: flipscreen invertito m_flipallx=0) NB: fx_eff (dai reg FSM) serve SOLO all'address-gen (half_use in S_ROM_REQ); la catena pen del DRAW usa lo snapshot d_flipx/d_pix (il draw gira in parall
rtl/nightslashers/ns_sprites.sv:598 MAME planeoffset = {hi+8, hi+0, lo+8, lo+0} → plane 0 = byte 3 (mbd-05 alto), plane 1 = byte 2, plane 2 = byte 1, plane 3 = byte 0 (mbd-06 basso).
rtl/nightslashers/ns_sprites.sv:611 MAME order: pen={p4,planes1..4}.
rtl/nightslashers/ns_sprites.sv:739 Se OFF, doppia inversione MAME (240-y, 304-x).
rtl/nightslashers/ns_sprites.sv:769 MAME decospr.cpp:297-304: flipscreen OFF: mult = -16, tile cresce verso l'alto da sy → bounding box [sy - 16*multi, sy + 16) → dy_top = scan_y - (sy - 16*multi) = (scan_y - sy) + 16*multi flipscreen ON: mult = +16, tile cresce verso il bas
rtl/nightslashers/ns_sprites.sv:807 MAME: non-intersecante = nulla.
rtl/nightslashers/ns_sprites.sv:834 FIX flipx half-swap: quando fx_eff=1 (sprite specchiato), MAME inverte anche l'ordine dei 2 half del tile (oltre al flip pixel-in-byte già fatto da bit_x).
rtl/nightslashers/ns_sprites.sv:901 FIX BUG #2: MAME decospr.cpp:351 → 2° blocco a (x+16) per flipscreen_spr=1, (x-16) per flipscreen_spr=0.
README.md:12 This core reimplements the hardware in SystemVerilog from MAME references and hardware observation.
README.md:127 **MAME does exactly the same thing, step for step**, which points at the game code itself rather than at the emulation: the geometry of the trap traces back to
README.md:141 DECO104 protection (I/O + data scramble) reproduced from MAME
README.md:142 MAME-accurate DECO16IC tilemaps (per-row / per-column scroll)
README.md:146 **Z80 audio chain fully working**: YM2151 + 2× OKI M6295, DECO104 sound latch, song data served through the Z80 I/O-mapped ROM (MAME `z80_sound_io`)
README.md:165 Two DECO16IC tilemap chips: BG0/BG1 (chip 0) + FG0/FG1 (chip 1), 16×16 and 8×8 tiles, per-row and per-column scroll — MAME-accurate

Says it matches, follows or was checked against MAME — 6

Template.sv:433 Ogni decode verificato bit-exact vs golden MAME.
rtl/cpu_arm/a23_copro_deco156.v:13 Behaviour is reproduced BIT-EXACT from MAME // src/devices/cpu/arm/arm.cpp (HandleCoPro, BCDToDecimal, // DecimalToBCD): //
rtl/cpu_arm/a23_copro_deco156.v:101 Combinational BCD <-> decimal (8 nibbles), matches MAME loops.
rtl/cpu_arm/a23_register_bank.v:322 Stessi reg che tb_cosim.sv confronta bit-exact vs golden MAME (vis_reg/vis_r15).
rtl/nightslashers/nightslashers_top.sv:559 Provato bit-exact in golden MAME + co-sim RTL (work/arm_decrypt).
rtl/nightslashers/nightslashers_top.sv:810 ── STRIDE FIX (causa NERO provata bit-exact via golden): il DECO156 e' ARM 32-bit, MAME mappa il video con handler _dword_w => indice = byteaddr>>2 (÷4).

Says it was translated, ported or taken from MAME — 7

rtl/nightslashers/deco16ic_jt.sv:154 State allargato a 5 bit per supportare colscroll lookup per-half (MAME 1:1).
rtl/nightslashers/deco16ic_jt.sv:385 COLSCROLL idx (per-half lookup, MAME 1:1 per pixel collassato a per-half perché cs_off è costante nei 8 px consecutivi per col_type≥8).
rtl/nightslashers/deco16ic_jt.sv:487 MAME 1:1: colscroll lookup PER PIXEL (in pratica per HALF di 8 px quando col_type≥8).
rtl/nightslashers/deco16ic_jt.sv:546 MAME 1:1.
rtl/nightslashers/deco16ic_jt.sv:727 MAME 1:1 per-pixel collapsed per HALF perché cs_off è costante negli 8 px consecutivi con col_type≥8.
rtl/nightslashers/deco16ic_jt.sv:890 COLSCROLL Y latched pf2 per-half (MAME 1:1).
rtl/nightslashers/nightslashers_top.sv:2364 Questa replica MAME 1:1.

Keeps a MAME approximation — 1

Template.sv:1128 MAME (placeholder, gestito sotto)

Shares text with the MAME driver without saying so — 8

Template.sv:296 MAME (ARM(config, m_maincpu, 28_MHz_XTAL/4)), e Night Slashers rallenta di — shares text with dataeast/fghthist.cpp:938
Template.sv:309 "P5O[43:38],BG0 X offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29,-2 — shares text with dataeast/deco146.h:71
Template.sv:310 "P5O[49:44],BG0 Y offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29,-2 — shares text with dataeast/deco146.h:71
Template.sv:311 "P5O[55:50],BG1 X offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29,-2 — shares text with dataeast/deco146.h:71
Template.sv:312 "P5O[61:56],BG1 Y offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29,-2 — shares text with dataeast/deco146.h:71
Template.sv:313 "P5O[79:74],FG X offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29,-28 — shares text with dataeast/deco146.h:71
Template.sv:314 "P5O[85:80],FG Y offset,0,+1,+2,+3,+4,+5,+6,+7,+8,+9,+10,+11,+12,+13,+14,+15,+16,+17,+18,+19,+20,+21,+22,+23,+24,+25,+26,+27,+28,+29,+30,+31,-32,-31,-30,-29,-28 — shares text with dataeast/deco146.h:71
rtl/nightslashers/ns_audio_z80.sv:513 map(0x0000, 0xffff).rom().region("audiocpu", 0); — shares text with dataeast/fghthist.cpp:733

NinjaKun#
Ninjakun Majou no Bouken, Nova 2001, Raiders5
MiSTer-devel/Arcade-NinjaKun_MiSTer @ 9f15cbc9
MAME compared: upl/nova2001.cpp + 2 related file(s)
Read: 20 HDL files, 6,760 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 2 toward MAME

Cites MAME source — 2

rtl/YM2149_linmix_sep.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA
README.txt:64 Note for Nova 2001 (From Mame)

OffTheWall#
Off the Wall
MiSTer-devel/Arcade-OffTheWall_MiSTer @ bf0f9281
MAME compared: atari/offtwall.cpp + 8 related file(s)
Read: 37 HDL files, 4,243 lines (Quartus project)

MiSTer official

Mostly hardware

low

28%

Statements: 17 toward hardware, 9 toward MAME, 10 not counted

Cites hardware documentation that MAME's driver does not — 16

rtl/io/offtwall_inputs.sv:1 SPDX-License-Identifier: GPL-3.0-or-later The I/O block at 260000: LS138 decoder 12J, player and status muxes, output latch 10J and the LETA at 16A.
rtl/io/offtwall_inputs.sv:73 LS174 10J: clocked by the rising edge of /LATCH, cleared by /SYSRES.
rtl/main/offtwall_cpu.sv:1 SPDX-License-Identifier: GPL-3.0-or-later 68000 at 13F: fx68k with its two clock-phase enables.
rtl/main/offtwall_decode.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Main address decode: the GAL at 15F and the F138 at 10F behind it.
rtl/main/offtwall_dtack.sv:1 SPDX-License-Identifier: GPL-3.0-or-later /DTACK: the 74F163 wait counter at 15J.
rtl/main/offtwall_eeprom_28c16.sv:1 SPDX-License-Identifier: GPL-3.0-or-later 28C16 EEPROM at 19L (2K x 8) and the flop that locks it.
rtl/main/offtwall_nvram_io.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Loads and saves the image of the 28C16 EEPROM at 19L (MiSTer only).
rtl/main/offtwall_watchdog.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Power-on reset and watchdog: the 74LS197 counter at 8D.
rtl/video/offtwall_lb.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Motion object line buffers (LB 137536-001 at 2N and its RAM): two banks, one written by the MOB for the next line while the other is displayed and erased behind the beam.
rtl/video/offtwall_mob.sv:1 SPDX-License-Identifier: GPL-3.0-or-later MOB 137593-001 at 8N: for every line, read the first link from the SLIP table, walk the linked list of motion objects in video RAM and draw the stamp rows that cross the line into the line buffer.
rtl/video/offtwall_vad_regs.sv:1 SPDX-License-Identifier: GPL-3.0-or-later VAD 137656-002 at 8F: the 32-word register file, the end-of-frame reload and the parameter-word decoder.
rtl/video/offtwall_vad_sync.sv:1 SPDX-License-Identifier: GPL-3.0-or-later VAD 137656-002 at 8F: beam counters, sync, blanking and the scanline interrupt, programmed by registers 01-05.
README.md:9 It was built from Atari's schematics and from the equations of the board's GAL chips, with MAME used as a cross-reference where the published documents are sile
README.md:107 | Address decode | GAL 136090-1003, with wait states from a 74F163 counter |
README.md:113 | Watchdog | a 74LS197 counting frames; also the power-on reset |
README.md:134 The I/O block, the LETA, the sound board's latches, mailbox, interrupt timer and analog filters follow Atari's schematics.

Cites hardware references or measurements that MAME's driver also gives — 10

rtl/gal/offtwall_gal_1003.sv:1 SPDX-License-Identifier: GPL-3.0-or-later GAL16V8 136090-1003 at 15F: main address decoder. — also in MAME: 136090-1003 atari/offtwall.cpp:593, 15F atari/offtwall.cpp:593
rtl/gal/offtwall_gal_1006.sv:1 SPDX-License-Identifier: GPL-3.0-or-later GAL16V8 136090-1006 at 5F. — also in MAME: 136090-1006 atari/offtwall.cpp:595, 5F atari/offtwall.cpp:595
rtl/gal/offtwall_gal_1007.sv:1 SPDX-License-Identifier: GPL-3.0-or-later GAL16V8 136090-1007 at 3F. — also in MAME: 136090-1007 atari/offtwall.cpp:596, 3F atari/offtwall.cpp:596
rtl/main/offtwall_sloop.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Program ROM bank device, 136090-1001 (a GAL6001 next to the program ROMs). — also in MAME: 136090-1001 atari/offtwall.cpp:591
rtl/mem/offtwall_prog_rom.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Program ROM, 256 KB (two 27C010 at 17E and 17J), held in block RAM so that every read takes the same time, as it does on the board. — also in MAME: 17E atari/offtwall.cpp:569, 17J atari/offtwall.cpp:570
rtl/video/offtwall_mixer.sv:2 5F (136090-1006) chooses the pen and 3F (136090-1007) the colour: the motion object wins wherever the line buffer holds one. — also in MAME: 5F atari/offtwall.cpp:595, 136090-1006 atari/offtwall.cpp:595, 3F atari/offtwall.cpp:596, 136090-1007 atari/offtwall.cpp:596
README.md:106 | Program ROM | 256 KB; the top 32 KB is bank-switched by the GAL 136090-1001 | — also in MAME: 136090-1001 atari/offtwall.cpp:591
README.md:108 | Video | VAD 137656-002 (timing, one scrolling playfield of 8 x 8 tiles, video RAM), MOB 137593-001 (motion objects) and its line buffer, mixer GALs 136090-100 — also in MAME: 136090-1006 atari/offtwall.cpp:595, 136090-1007 atari/offtwall.cpp:596
README.md:131 The main address decoder, the video mixer and the sound board's decoder use the equations of the board's GAL chips (136090-1003, -1006, -1007 and the JSA III's — also in MAME: 136090-1003 atari/offtwall.cpp:593, 136085-1038 atari/offtwall.cpp:587
README.md:153 Atari's schematics of this board's CPU, decode and video sections were never published, and the bank-switching GAL 136090-1001 has never been read out. — also in MAME: 136090-1001 atari/offtwall.cpp:591

Notes where it differs from MAME — 1

README.md:139 Where this core differs from MAME

Cites MAME source — 8

rtl/video/offtwall_vad_sync.sv:8 Register fields (layout as in MAME; the VAD sheet was never published): 01 vsync start line (11-3), vsync end (2-0) 02 last line (15-9), vblank start line (8-0) 03 scanline interrupt line (8-0) 04 hsync end / 2 (15-10), hsync start (9-0
README.md:9 It was built from Atari's schematics and from the equations of the board's GAL chips, with MAME used as a cross-reference where the published documents are sile
README.md:48 Until a save file exists the core starts from the factory settings in the MAME set.
README.md:141 | Behaviour | MAME | This core |
README.md:182 Every block has its own test bench, and the whole core was simulated with the real 68000 (fx68k), 6502 (T65) and YM2151 (jt51) models, loading the ROMs exactly
README.md:187 **Attract mode and a full game**, 1,480 frames of each set: every frame is a MAME frame, or lies between two consecutive MAME frames where the game changes the
README.md:194 **Sound board**, driven by MAME's command log: every byte between the two CPUs is passed in the same order as in MAME.
README.md:259 Thanks to the MAME team, whose `offtwall.cpp`, `atarijsa`, `atarivad` and `atarimo` code was the cross-reference throughout, and to the people who recovered the

Says it matches, follows or was checked against MAME — 1

rtl/video/offtwall_vad_regs.sv:7 The VAD sheet was never published; this follows MAME's atarivad and what the game program does.

Pacman#
Ali Baba and 40 Thieves, Birdiy, Pacman Club / Club Lambada, Korosuke Roller …
MiSTer-devel/Arcade-Pacman_MiSTer @ 9bcb0b6d
MAME compared: pacman/jrpacman.cpp, pacman/pacman.cpp + 3 related file(s)
Read: 21 HDL files, 8,553 lines (Quartus project)

MiSTer official

Mostly MAME

low

21%

Statements: 156 toward MAME, 3 not counted

Cites hardware references or measurements that MAME's driver also gives — 3

rtl/pacman.vhd:628 8 bit addressable latch 7K (made into register) — also in MAME: 7K pacman/pacman.cpp:3710
rtl/pacman.vhd:720 Pac-Man latch2 (0x5070-0x5077, LS259 1H) and scroll (0x5080), gated on mod_jr. — also in MAME: 1H pacman/jrpacman.cpp:281
rtl/pacman_rom_descrambler.vhd:49 Also the graphics ROMs at 5E, 5F on the main board are replaced. — also in MAME: 5E pacman/pacman.cpp:196, 5F pacman/pacman.cpp:245

Cites MAME source — 8

rtl/pacman.vhd:232 Pac-Man program-ROM DECRYPTION (jrpacman.cpp init_jrpacman, lines 384-425).
rtl/pacman.vhd:233 MAME decrypts by walking the maincpu region linearly and XORing each byte with a run-length-encoded value.
rtl/pacman.vhd:499 Pac-Man video RAM address (mod_jr) — faithful jrpacman_scan_rows (pacman_v.cpp:607; 36x54 map, per-column scroll) + per-column colour.
rtl/pacman.vhd:502 MAME's col-=2 / row+=2 therefore land on the 256H/256V boundary (0x20), NOT 0x02.
rtl/pacman.vhd:507 mc = map col = (hcnt 8:3) - 0x20 (== MAME col-2, wrap-correct); HUD edges when mc & 0x20.
rtl/pacman.vhd:508 mr = map row = ((vcnt[+scroll]) 8:3) - 0x20 (== MAME row+2; scroll applied to PLAYFIELD only).
rtl/pacman_rom_descrambler.vhd:39 The following comments and source code in the comments are from MAME source code and are included here to help make sense of the logic used in the VHDL address mapper and descrambler
rtl/sn76489/sn76489_noise.vhd:199 Tapped bits according to MAME's sn76496.c, implemented in function lfsr_tapped_f.

Shares text with the MAME driver without saying so — 148

rtl/pacman.vhd:233 The aux-board encryption PALs garble bits 0, 2, 7. MAME decrypts by walking the — shares text with pacman/jrpacman.cpp:369
rtl/pacman_rom_descrambler.vhd:49 Ms. Pac-Man has an auxiliary PCB with ribbon cable that plugs into the Z-80 CPU socket of a Pac-Man main PCB. Also the — shares text with pacman/pacman.cpp:906
rtl/pacman_rom_descrambler.vhd:50 graphics ROMs at 5E, 5F on the main board are replaced. — shares text with pacman/pacman.cpp:907
rtl/pacman_rom_descrambler.vhd:52 The aux board contains three ROMs (two 2532 at U6, U7 and one 2716 at U5), a Z-80, and four PAL/HAL logic chips. — shares text with pacman/pacman.cpp:909
rtl/pacman_rom_descrambler.vhd:54 The aux board logic decodes the Z-80 address and determines whether to enable the main board ROMs (containing Pac-Man — shares text with pacman/pacman.cpp:911
rtl/pacman_rom_descrambler.vhd:55 code) or the aux board ROMs (containing Ms. Pac-Man code). Normally the Pac-Man ROMs reside at address 0x0000-0x3fff — shares text with pacman/pacman.cpp:912
rtl/pacman_rom_descrambler.vhd:56 and are mirrored at 0x8000-0xbfff (Z-80 A15 is not used in Pac-Man). The aux board logic modifies the address map and — shares text with pacman/pacman.cpp:913
rtl/pacman_rom_descrambler.vhd:57 enables the aux board ROMs for addresses 0x3000-0x3fff and 0x8000-0x97ff. Furthermore there are forty 8-byte "patch" — shares text with pacman/pacman.cpp:914
rtl/pacman_rom_descrambler.vhd:58 regions which reside in the 0x0000-0x2fff address range. Any access to these patch addresses will disable the Pac-Man — shares text with pacman/pacman.cpp:915
rtl/pacman_rom_descrambler.vhd:59 ROMs and enable the aux board ROM. Aux board ROM addresses 0x8000-0x81ef are mapped onto the patch regions. These — shares text with pacman/pacman.cpp:916
rtl/pacman_rom_descrambler.vhd:60 patches typically insert jumps to new code above 0x8000. — shares text with pacman/pacman.cpp:917
rtl/pacman_rom_descrambler.vhd:62 The aux board logic also acts as a software protection circuit which inhibits dumping of the ROMs (e.g., using a — shares text with pacman/pacman.cpp:919
rtl/pacman_rom_descrambler.vhd:63 microprocessor emulator system). There are several "trap" address regions which enable and disable the decode — shares text with pacman/pacman.cpp:920
rtl/pacman_rom_descrambler.vhd:64 functions. In order to properly operate as Ms. Pac-Man you must access one of the "latch set" trap addresses. This — shares text with pacman/pacman.cpp:921
rtl/pacman_rom_descrambler.vhd:65 enables the decode. If a "latch clear" address is accessed then decode is disabled and all you get is Pac-Man. For — shares text with pacman/pacman.cpp:922
rtl/pacman_rom_descrambler.vhd:66 more info see U.S. Patent 4,525,599 "Software protection methods and apparatus". — shares text with pacman/pacman.cpp:923
rtl/pacman_rom_descrambler.vhd:68 The trap regions are 8 bytes in length starting on the following addresses: — shares text with pacman/pacman.cpp:925
rtl/pacman_rom_descrambler.vhd:82 Any memory access will trigger the trap behavior: instruction fetch, data read, data write. The latch clear addresses — shares text with pacman/pacman.cpp:939
rtl/pacman_rom_descrambler.vhd:83 should never be accessed during normal Ms. Pac-Man operation, so when the circuitry detects an access it clears the — shares text with pacman/pacman.cpp:940
rtl/pacman_rom_descrambler.vhd:84 latch and prevents any further dumping of the aux board ROMs. — shares text with pacman/pacman.cpp:941
rtl/pacman_rom_descrambler.vhd:86 The Pac-Man self-test code does a checksum of the ROM 0x0000-0x2fff. This works because the checksum routine walks the — shares text with pacman/pacman.cpp:943
rtl/pacman_rom_descrambler.vhd:87 ROM starting from the low address and hits the latch clear trap at 0x0038 prior to encountering any of the patch — shares text with pacman/pacman.cpp:944
rtl/pacman_rom_descrambler.vhd:88 regions. The decode stays disabled for the rest of the checksum routine, and thus the checksum is calculated for the — shares text with pacman/pacman.cpp:945
rtl/pacman_rom_descrambler.vhd:89 Pac-Man ROMs with no patches applied. — shares text with pacman/pacman.cpp:946
rtl/pacman_rom_descrambler.vhd:91 During normal operation every VBLANK (60.6Hz) interrupt will fetch its interrupt vector from the 0x3ff8 trap region, so — shares text with pacman/pacman.cpp:948
rtl/pacman_rom_descrambler.vhd:92 the latch is continually being enabled. — shares text with pacman/pacman.cpp:949
rtl/pacman_rom_descrambler.vhd:94 In a further attempt to thwart copying, the aux board ROMs have a simple encryption scheme: their address and data — shares text with pacman/pacman.cpp:959
rtl/pacman_rom_descrambler.vhd:95 lines are bit flipped (i.e., wired in a nonstandard fashion). The specific bit flips were selected to minimize the — shares text with pacman/pacman.cpp:960
rtl/pacman_rom_descrambler.vhd:96 vias required to lay out the aux PCB. — shares text with pacman/pacman.cpp:961
rtl/pacman_rom_descrambler.vhd:104 /* copy forty 8-byte patches into Pac-Man code */ — shares text with pacman/pacman.cpp:8640
rtl/pacman_rom_descrambler.vhd:107 ROM[0x0410+i] = ROM[0x8008+i]; — shares text with pacman/pacman.cpp:8643
rtl/pacman_rom_descrambler.vhd:108 ROM[0x08E0+i] = ROM[0x81D8+i]; — shares text with pacman/pacman.cpp:8644
rtl/pacman_rom_descrambler.vhd:109 ROM[0x0A30+i] = ROM[0x8118+i]; — shares text with pacman/pacman.cpp:8645
rtl/pacman_rom_descrambler.vhd:110 ROM[0x0BD0+i] = ROM[0x80D8+i]; — shares text with pacman/pacman.cpp:8646
rtl/pacman_rom_descrambler.vhd:111 ROM[0x0C20+i] = ROM[0x8120+i]; — shares text with pacman/pacman.cpp:8647
rtl/pacman_rom_descrambler.vhd:112 ROM[0x0E58+i] = ROM[0x8168+i]; — shares text with pacman/pacman.cpp:8648
rtl/pacman_rom_descrambler.vhd:113 ROM[0x0EA8+i] = ROM[0x8198+i]; — shares text with pacman/pacman.cpp:8649
rtl/pacman_rom_descrambler.vhd:115 ROM[0x1000+i] = ROM[0x8020+i]; — shares text with pacman/pacman.cpp:8651
rtl/pacman_rom_descrambler.vhd:116 ROM[0x1008+i] = ROM[0x8010+i]; — shares text with pacman/pacman.cpp:8652
rtl/pacman_rom_descrambler.vhd:117 ROM[0x1288+i] = ROM[0x8098+i]; — shares text with pacman/pacman.cpp:8653
rtl/pacman_rom_descrambler.vhd:118 ROM[0x1348+i] = ROM[0x8048+i]; — shares text with pacman/pacman.cpp:8654
rtl/pacman_rom_descrambler.vhd:119 ROM[0x1688+i] = ROM[0x8088+i]; — shares text with pacman/pacman.cpp:8655
rtl/pacman_rom_descrambler.vhd:120 ROM[0x16B0+i] = ROM[0x8188+i]; — shares text with pacman/pacman.cpp:8656
rtl/pacman_rom_descrambler.vhd:121 ROM[0x16D8+i] = ROM[0x80C8+i]; — shares text with pacman/pacman.cpp:8657
rtl/pacman_rom_descrambler.vhd:122 ROM[0x16F8+i] = ROM[0x81C8+i]; — shares text with pacman/pacman.cpp:8658
rtl/pacman_rom_descrambler.vhd:123 ROM[0x19A8+i] = ROM[0x80A8+i]; — shares text with pacman/pacman.cpp:8659
rtl/pacman_rom_descrambler.vhd:124 ROM[0x19B8+i] = ROM[0x81A8+i]; — shares text with pacman/pacman.cpp:8660
rtl/pacman_rom_descrambler.vhd:126 ROM[0x2060+i] = ROM[0x8148+i]; — shares text with pacman/pacman.cpp:8662
rtl/pacman_rom_descrambler.vhd:127 ROM[0x2108+i] = ROM[0x8018+i]; — shares text with pacman/pacman.cpp:8663
rtl/pacman_rom_descrambler.vhd:128 ROM[0x21A0+i] = ROM[0x81A0+i]; — shares text with pacman/pacman.cpp:8664
rtl/pacman_rom_descrambler.vhd:129 ROM[0x2298+i] = ROM[0x80A0+i]; — shares text with pacman/pacman.cpp:8665
rtl/pacman_rom_descrambler.vhd:130 ROM[0x23E0+i] = ROM[0x80E8+i]; — shares text with pacman/pacman.cpp:8666
rtl/pacman_rom_descrambler.vhd:131 ROM[0x2418+i] = ROM[0x8000+i]; — shares text with pacman/pacman.cpp:8667
rtl/pacman_rom_descrambler.vhd:132 ROM[0x2448+i] = ROM[0x8058+i]; — shares text with pacman/pacman.cpp:8668
rtl/pacman_rom_descrambler.vhd:133 ROM[0x2470+i] = ROM[0x8140+i]; — shares text with pacman/pacman.cpp:8669
rtl/pacman_rom_descrambler.vhd:134 ROM[0x2488+i] = ROM[0x8080+i]; — shares text with pacman/pacman.cpp:8670
rtl/pacman_rom_descrambler.vhd:135 ROM[0x24B0+i] = ROM[0x8180+i]; — shares text with pacman/pacman.cpp:8671
rtl/pacman_rom_descrambler.vhd:136 ROM[0x24D8+i] = ROM[0x80C0+i]; — shares text with pacman/pacman.cpp:8672
rtl/pacman_rom_descrambler.vhd:137 ROM[0x24F8+i] = ROM[0x81C0+i]; — shares text with pacman/pacman.cpp:8673
rtl/pacman_rom_descrambler.vhd:138 ROM[0x2748+i] = ROM[0x8050+i]; — shares text with pacman/pacman.cpp:8674
rtl/pacman_rom_descrambler.vhd:139 ROM[0x2780+i] = ROM[0x8090+i]; — shares text with pacman/pacman.cpp:8675
rtl/pacman_rom_descrambler.vhd:140 ROM[0x27B8+i] = ROM[0x8190+i]; — shares text with pacman/pacman.cpp:8676
rtl/pacman_rom_descrambler.vhd:141 ROM[0x2800+i] = ROM[0x8028+i]; — shares text with pacman/pacman.cpp:8677
rtl/pacman_rom_descrambler.vhd:142 ROM[0x2B20+i] = ROM[0x8100+i]; — shares text with pacman/pacman.cpp:8678
rtl/pacman_rom_descrambler.vhd:143 ROM[0x2B30+i] = ROM[0x8110+i]; — shares text with pacman/pacman.cpp:8679
rtl/pacman_rom_descrambler.vhd:144 ROM[0x2BF0+i] = ROM[0x81D0+i]; — shares text with pacman/pacman.cpp:8680
rtl/pacman_rom_descrambler.vhd:145 ROM[0x2CC0+i] = ROM[0x80D0+i]; — shares text with pacman/pacman.cpp:8681
rtl/pacman_rom_descrambler.vhd:146 ROM[0x2CD8+i] = ROM[0x80E0+i]; — shares text with pacman/pacman.cpp:8682
rtl/pacman_rom_descrambler.vhd:147 ROM[0x2CF0+i] = ROM[0x81E0+i]; — shares text with pacman/pacman.cpp:8683
rtl/pacman_rom_descrambler.vhd:148 ROM[0x2D60+i] = ROM[0x8160+i]; — shares text with pacman/pacman.cpp:8684
rtl/pacman_rom_descrambler.vhd:159 /* Pac-Man code is in low bank */ — shares text with pacman/pacman.cpp:8692
rtl/pacman_rom_descrambler.vhd:162 /* decrypted Ms. Pac-Man code is in high bank */ — shares text with pacman/pacman.cpp:8695
rtl/pacman_rom_descrambler.vhd:168 DROM[0x0000+i] = ROM[0x0000+i]; /* pacman.6e */ — shares text with pacman/pacman.cpp:8701
rtl/pacman_rom_descrambler.vhd:169 DROM[0x1000+i] = ROM[0x1000+i]; /* pacman.6f */ — shares text with pacman/pacman.cpp:8702
rtl/pacman_rom_descrambler.vhd:170 DROM[0x2000+i] = ROM[0x2000+i]; /* pacman.6h */ — shares text with pacman/pacman.cpp:8703
rtl/pacman_rom_descrambler.vhd:171 DROM[0x3000+i] = BITSWAP8(ROM[0xb000+BITSWAP16(i,15,14,13,12,11,3,7,9,10,8,6,5,4,2,1,0)],0,4,5,7,6,3,2,1); /* decrypt u7 */ — shares text with pacman/pacman.cpp:8704
rtl/pacman_rom_descrambler.vhd:175 DROM[0x8000+i] = BITSWAP8(ROM[0x8000+BITSWAP16(i,15,14,13,12,11,8,7,5,9,10,6,3,4,2,1,0)],0,4,5,7,6,3,2,1); /* decrypt u5 */ — shares text with pacman/pacman.cpp:8708
rtl/pacman_rom_descrambler.vhd:176 DROM[0x8800+i] = BITSWAP8(ROM[0x9800+BITSWAP16(i,15,14,13,12,11,3,7,9,10,8,6,5,4,2,1,0)],0,4,5,7,6,3,2,1); /* decrypt half of u6 */ — shares text with pacman/pacman.cpp:8704
rtl/pacman_rom_descrambler.vhd:177 DROM[0x9000+i] = BITSWAP8(ROM[0x9000+BITSWAP16(i,15,14,13,12,11,3,7,9,10,8,6,5,4,2,1,0)],0,4,5,7,6,3,2,1); /* decrypt half of u6 */ — shares text with pacman/pacman.cpp:8704
rtl/pacman_rom_descrambler.vhd:178 // 15,14,13,12,11,10,9,8,7,6,5,4,3,2,1,0 — shares text with pacman/pacman.cpp:8614
rtl/pacman_rom_descrambler.vhd:179 DROM[0x9800+i] = ROM[0x1800+i]; /* mirror of pacman.6f high */ — shares text with pacman/pacman.cpp:8711
rtl/pacman_rom_descrambler.vhd:183 DROM[0xa000+i] = ROM[0x2000+i]; /* mirror of pacman.6h */ — shares text with pacman/pacman.cpp:8715
rtl/pacman_rom_descrambler.vhd:184 DROM[0xb000+i] = ROM[0x3000+i]; /* mirror of pacman.6j */ — shares text with pacman/pacman.cpp:8716
rtl/pacman_rom_descrambler.vhd:189 /* mirror Pac-Man ROMs into upper addresses of normal bank */ — shares text with pacman/pacman.cpp:8722
rtl/pacman_rom_descrambler.vhd:192 ROM[0x8000+i] = ROM[0x0000+i]; — shares text with pacman/pacman.cpp:8725
rtl/pacman_rom_descrambler.vhd:193 ROM[0x9000+i] = ROM[0x1000+i]; — shares text with pacman/pacman.cpp:8726
rtl/pacman_rom_descrambler.vhd:194 ROM[0xa000+i] = ROM[0x2000+i]; — shares text with pacman/pacman.cpp:8727
rtl/pacman_rom_descrambler.vhd:195 ROM[0xb000+i] = ROM[0x3000+i]; — shares text with pacman/pacman.cpp:8728
rtl/pacman_rom_descrambler.vhd:199 machine().root_device().membank("bank1")->configure_entries(0, 2, &ROM[0x00000], 0x10000); — shares text with pacman/pacman.cpp:698
rtl/pacman_rom_descrambler.vhd:205 ROM_LOAD( "pacman.6e", 0x0000, 0x1000, CRC(c1e6ab10) SHA1(e87e059c5be45753f7e9f33dff851f16d6751181) ) — shares text with pacman/pacman.cpp:4318
rtl/pacman_rom_descrambler.vhd:206 ROM_LOAD( "pacman.6f", 0x1000, 0x1000, CRC(1a6fb2d4) SHA1(674d3a7f00d8be5e38b1fdc208ebef5a92d38329) ) — shares text with pacman/pacman.cpp:4319
rtl/pacman_rom_descrambler.vhd:207 ROM_LOAD( "pacman.6h", 0x2000, 0x1000, CRC(bcdd1beb) SHA1(8e47e8c2c4d6117d174cdac150392042d3e0a881) ) — shares text with pacman/pacman.cpp:4320
rtl/pacman_rom_descrambler.vhd:208 ROM_LOAD( "prg7", 0x3000, 0x0800, CRC(b6289b26) SHA1(d249fa9cdde774d5fee7258147cd25fa3f4dc2b3) ) — shares text with pacman/pacman.cpp:4155
rtl/pacman_rom_descrambler.vhd:209 ROM_LOAD( "prg8", 0x3800, 0x0800, CRC(17a88c13) SHA1(eb462de79f49b7aa8adb0cc6d31535b10550c0ce) ) — shares text with pacman/pacman.cpp:4156
rtl/pacman_rom_descrambler.vhd:212 ROM_REGION( 0x20000, "maincpu", 0 ) /* 64k for code+64k for decrypted code */ — shares text with pacman/pacman.cpp:6273
rtl/pacman_rom_descrambler.vhd:213 ROM_LOAD( "pacman.6e", 0x0000, 0x1000, CRC(c1e6ab10) SHA1(e87e059c5be45753f7e9f33dff851f16d6751181) ) — shares text with pacman/pacman.cpp:4318
rtl/pacman_rom_descrambler.vhd:214 ROM_LOAD( "pacman.6f", 0x1000, 0x1000, CRC(1a6fb2d4) SHA1(674d3a7f00d8be5e38b1fdc208ebef5a92d38329) ) — shares text with pacman/pacman.cpp:4319
rtl/pacman_rom_descrambler.vhd:215 ROM_LOAD( "pacman.6h", 0x2000, 0x1000, CRC(bcdd1beb) SHA1(8e47e8c2c4d6117d174cdac150392042d3e0a881) ) — shares text with pacman/pacman.cpp:4320
rtl/pacman_rom_descrambler.vhd:216 ROM_LOAD( "pacman.6j", 0x3000, 0x1000, CRC(817d94e3) SHA1(d4a70d56bb01d27d094d73db8667ffb00ca69cb9) ) — shares text with pacman/pacman.cpp:4321
rtl/pacman_rom_descrambler.vhd:218 ROM_LOAD( "u5", 0x8000, 0x0800, CRC(f45fbbcd) SHA1(b26cc1c8ee18e9b1daa97956d2159b954703a0ec) ) — shares text with pacman/pacman.cpp:6278
rtl/pacman_rom_descrambler.vhd:219 ROM_LOAD( "u6", 0x9000, 0x1000, CRC(a90e7000) SHA1(e4df96f1db753533f7d770aa62ae1973349ea4cf) ) — shares text with pacman/pacman.cpp:6279
rtl/pacman_rom_descrambler.vhd:220 ROM_LOAD( "u7", 0xb000, 0x1000, CRC(c82cd714) SHA1(1d8ac7ad03db2dc4c8c18ade466e12032673f874) ) — shares text with pacman/pacman.cpp:6280
rtl/pacman_rom_descrambler.vhd:223 Normally the Pac-Man ROMs reside at address 0x0000-0x3fff and are mirrored at 0x8000-0xbfff (Z-80 A15 is not used in Pac-Man). — shares text with pacman/pacman.cpp:912
rtl/pacman_rom_descrambler.vhd:224 The aux board logic modifies the address map and enables the aux board ROMs for addresses 0x3000-0x3fff and 0x8000-0x97ff. — shares text with pacman/pacman.cpp:913
rtl/pacman_rom_descrambler.vhd:310 The trap regions are 8 bytes in length starting on the following addresses: — shares text with pacman/pacman.cpp:925
rtl/pacman_rom_descrambler.vhd:397 Mr TNT program ROMs have data lines D3 and D5 swapped — shares text with pacman/pacman.cpp:8624
rtl/pacman_rom_descrambler.vhd:398 Mr TNT video ROMs have data lines D4 and D6 and address lines A0 and A2 swapped — shares text with pacman/pacman.cpp:8631
rtl/pacman_rom_descrambler.vhd:404 forty 8-byte patches into Pac-Man code — shares text with pacman/pacman.cpp:8640
rtl/pacman_rom_descrambler.vhd:409 ROM[0x0410+i] = ROM[0x8008+i] — shares text with pacman/pacman.cpp:8643
rtl/pacman_rom_descrambler.vhd:410 ROM[0x08E0+i] = ROM[0x81D8+i] — shares text with pacman/pacman.cpp:8644
rtl/pacman_rom_descrambler.vhd:411 ROM[0x0A30+i] = ROM[0x8118+i] — shares text with pacman/pacman.cpp:8645
rtl/pacman_rom_descrambler.vhd:412 ROM[0x0BD0+i] = ROM[0x80D8+i] — shares text with pacman/pacman.cpp:8646
rtl/pacman_rom_descrambler.vhd:413 ROM[0x0C20+i] = ROM[0x8120+i] — shares text with pacman/pacman.cpp:8647
rtl/pacman_rom_descrambler.vhd:414 ROM[0x0E58+i] = ROM[0x8168+i] — shares text with pacman/pacman.cpp:8648
rtl/pacman_rom_descrambler.vhd:415 ROM[0x0EA8+i] = ROM[0x8198+i] — shares text with pacman/pacman.cpp:8649
rtl/pacman_rom_descrambler.vhd:417 ROM[0x1000+i] = ROM[0x8020+i] — shares text with pacman/pacman.cpp:8651
rtl/pacman_rom_descrambler.vhd:418 ROM[0x1008+i] = ROM[0x8010+i] — shares text with pacman/pacman.cpp:8652
rtl/pacman_rom_descrambler.vhd:419 ROM[0x1288+i] = ROM[0x8098+i] — shares text with pacman/pacman.cpp:8653
rtl/pacman_rom_descrambler.vhd:420 ROM[0x1348+i] = ROM[0x8048+i] — shares text with pacman/pacman.cpp:8654
rtl/pacman_rom_descrambler.vhd:421 ROM[0x1688+i] = ROM[0x8088+i] — shares text with pacman/pacman.cpp:8655
rtl/pacman_rom_descrambler.vhd:422 ROM[0x16B0+i] = ROM[0x8188+i] — shares text with pacman/pacman.cpp:8656
rtl/pacman_rom_descrambler.vhd:423 ROM[0x16D8+i] = ROM[0x80C8+i] — shares text with pacman/pacman.cpp:8657
rtl/pacman_rom_descrambler.vhd:424 ROM[0x16F8+i] = ROM[0x81C8+i] — shares text with pacman/pacman.cpp:8658
rtl/pacman_rom_descrambler.vhd:425 ROM[0x19A8+i] = ROM[0x80A8+i] — shares text with pacman/pacman.cpp:8659
rtl/pacman_rom_descrambler.vhd:426 ROM[0x19B8+i] = ROM[0x81A8+i] — shares text with pacman/pacman.cpp:8660
rtl/pacman_rom_descrambler.vhd:428 ROM[0x2060+i] = ROM[0x8148+i] — shares text with pacman/pacman.cpp:8662
rtl/pacman_rom_descrambler.vhd:429 ROM[0x2108+i] = ROM[0x8018+i] — shares text with pacman/pacman.cpp:8663
rtl/pacman_rom_descrambler.vhd:430 ROM[0x21A0+i] = ROM[0x81A0+i] — shares text with pacman/pacman.cpp:8664
rtl/pacman_rom_descrambler.vhd:431 ROM[0x2298+i] = ROM[0x80A0+i] — shares text with pacman/pacman.cpp:8665
rtl/pacman_rom_descrambler.vhd:432 ROM[0x23E0+i] = ROM[0x80E8+i] — shares text with pacman/pacman.cpp:8666
rtl/pacman_rom_descrambler.vhd:433 ROM[0x2418+i] = ROM[0x8000+i] — shares text with pacman/pacman.cpp:8667
rtl/pacman_rom_descrambler.vhd:434 ROM[0x2448+i] = ROM[0x8058+i] — shares text with pacman/pacman.cpp:8668
rtl/pacman_rom_descrambler.vhd:435 ROM[0x2470+i] = ROM[0x8140+i] — shares text with pacman/pacman.cpp:8669
rtl/pacman_rom_descrambler.vhd:436 ROM[0x2488+i] = ROM[0x8080+i] — shares text with pacman/pacman.cpp:8670
rtl/pacman_rom_descrambler.vhd:437 ROM[0x24B0+i] = ROM[0x8180+i] — shares text with pacman/pacman.cpp:8671
rtl/pacman_rom_descrambler.vhd:438 ROM[0x24D8+i] = ROM[0x80C0+i] — shares text with pacman/pacman.cpp:8672
rtl/pacman_rom_descrambler.vhd:439 ROM[0x24F8+i] = ROM[0x81C0+i] — shares text with pacman/pacman.cpp:8673
rtl/pacman_rom_descrambler.vhd:440 ROM[0x2748+i] = ROM[0x8050+i] — shares text with pacman/pacman.cpp:8674
rtl/pacman_rom_descrambler.vhd:441 ROM[0x2780+i] = ROM[0x8090+i] — shares text with pacman/pacman.cpp:8675
rtl/pacman_rom_descrambler.vhd:442 ROM[0x27B8+i] = ROM[0x8190+i] — shares text with pacman/pacman.cpp:8676
rtl/pacman_rom_descrambler.vhd:443 ROM[0x2800+i] = ROM[0x8028+i] — shares text with pacman/pacman.cpp:8677
rtl/pacman_rom_descrambler.vhd:444 ROM[0x2B20+i] = ROM[0x8100+i] — shares text with pacman/pacman.cpp:8678
rtl/pacman_rom_descrambler.vhd:445 ROM[0x2B30+i] = ROM[0x8110+i] — shares text with pacman/pacman.cpp:8679
rtl/pacman_rom_descrambler.vhd:446 ROM[0x2BF0+i] = ROM[0x81D0+i] — shares text with pacman/pacman.cpp:8680
rtl/pacman_rom_descrambler.vhd:447 ROM[0x2CC0+i] = ROM[0x80D0+i] — shares text with pacman/pacman.cpp:8681
rtl/pacman_rom_descrambler.vhd:448 ROM[0x2CD8+i] = ROM[0x80E0+i] — shares text with pacman/pacman.cpp:8682
rtl/pacman_rom_descrambler.vhd:449 ROM[0x2CF0+i] = ROM[0x81E0+i] — shares text with pacman/pacman.cpp:8683
rtl/pacman_rom_descrambler.vhd:450 ROM[0x2D60+i] = ROM[0x8160+i] — shares text with pacman/pacman.cpp:8684

Pengo#
Pengo
MiSTer-devel/Arcade-Pengo_MiSTer @ 46d16b21
MAME compared: pacman/pengo.cpp + 2 related file(s)
Read: 13 HDL files, 5,779 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

17%

Statements: 2 toward MAME, 1 not counted

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/pengo.vhd:337 8 bit addressable latch 7K (made into register) — also in MAME: 7K pacman/pacman.cpp:3710

Cites MAME source — 1

rtl/pengo.vhd:381 Sega ROM descrambler adapted from MAME segacrpt.c source code

Shares text with the MAME driver without saying so — 1

Arcade-Pengo.sv:366 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |ON | | | | | | | | Bonus - 30,000* |OFF| | | | | | | | Bonus - 50,000 | |ON | | | | | — shares text with pacman/pacman.cpp:9012

PenguinKunWars#
Penguin-Kun Wars
MiSTer-devel/Arcade-PenguinKunWars_MiSTer @ 9243c087
MAME compared: upl/nova2001.cpp + 2 related file(s)
Read: 12 HDL files, 2,292 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

45%

Statements: 2 toward MAME

Cites MAME source — 2

Arcade-PenguinKunWars.sv:295 JPAC/IPAC/MAME Style Codes
rtl/YM2149_linmix_sep_mod.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA

Performan#
Performan
MiSTer-devel/Arcade-Performan_MiSTer @ 74652aee
MAME compared: toaplan/slapfght.cpp + 3 related file(s)
Read: 20 HDL files, 4,521 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

21%

Statements: 3 toward hardware, 1 toward MAME

Cites hardware documentation that MAME's driver does not — 3

rtl/ttl_chips.v:6 74LS74 Chip pinout:
rtl/ttl_chips.v:57 74LS107 Chip pinout:
rtl/ttl_chips.v:102 74LS139 Chip pinout:

Shares text with the MAME driver without saying so — 1

Arcade-Performan.sv:110 0 1 2 3 4 5 6 — shares text with toaplan/slapfght.cpp:820

Phoenix#
Phoenix, Pleiads
MiSTer-devel/Arcade-Phoenix_MiSTer @ e4bc0d5c
MAME compared: phoenix/phoenix.cpp + 6 related file(s)
Read: 14 HDL files, 5,165 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

No statements found

PinballAction#
Pinball Action
MiSTer-devel/Arcade-PinballAction @ 8a9fb51f
MAME compared: tecmo/pbaction.cpp
Read: 17 HDL files, 3,448 lines (Quartus project)

MiSTer official

Both

low

26%

Statements: 1 toward hardware, 7 toward MAME

Says it was checked against the original PCB — 1

README.md:88 Video timing verification against original hardware

Cites MAME source — 6

PinballAction.sv:55 MRA file will map MAME ROM regions to these indices
rtl/pbaction_sprites.v:68 MAME draws from offs=124 down to 0.
rtl/pbaction_sprites.v:329 MAME draws lower offsets later, therefore lower offsets have priority.
README.md:89 Remaining edge-case rendering differences from MAME
README.md:106 *MAME*
README.md:108 MAME serves as an invaluable reference for hardware behavior, device mappings, graphics layouts, and verification.

Says it matches, follows or was checked against MAME — 1

README.md:72 A small band approximately three scanlines tall does not perfectly match MAME:

Pleiads#

MiSTer-devel/Arcade-Pleiads_MiSTer @ 4144e0e8
MAME driver: not found
Read: 13 HDL files, 5,009 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

No statements found

PolePosition#
Pole Position, Pole Position II
MiSTer-devel/Arcade-PolePosition_MiSTer @ 278079e4 (matched by date)
MAME compared: namco/polepos.cpp + 14 related file(s)
Read: 37 HDL files, 11,611 lines (Quartus project)

MiSTer official

Mostly MAME

high

95%

Statements: 9 toward hardware, 505 toward MAME, 2 not counted

Cites hardware documentation that MAME's driver does not — 2

rtl/cpu/z8002/z8002.sv:10 This core is COMPLETE for everything Pole Position exercises: both sub ROMs co-sim-run to completion (pp_sub1 ~15M / pp_sub2 ~12M retires @30M cyc, ZERO dbg_illegal), and the NVI/ISR/IRET selftest passes.
rtl/custom/pp_road_gen.sv:233 The ONE input never observed on hardware is what the sub-CPUs write into road16_memory -- the CHA0-CHA9 lines on operators-manual Sheet 12B.

Cites hardware references or measurements that MAME's driver also gives — 2

rtl/PolePosition_CPU.sv:7 Ground truth: MAME polepos.cpp z80_map / z80_io / machine_config (LS259 @8E). — also in MAME: 8E namco/polepos.cpp:182
rtl/PolePosition_CPU.sv:193 IRQ generation (polepos.cpp scanline() :392-403) maincpu IRQ asserted at 64V and 192V when q0=1; q0=0 acks/clears. — also in MAME: 64V namco/polepos.cpp:396

Says it was checked on “real hardware” — 1

rtl/video/gen_video.sv:159 User confirmed on real HW the excess 32px is entirely on the LEFT, so trim only the deassert (left-edge/start-of-active) side by the full 32px; the assert (right edge) point is untouched.

Ships hardware documentation files — 4

Notes where it differs from MAME — 2

rtl/PolePosition_CPU.sv:240 Was plain `spram` (powers up 0x00, diverging from MAME); swapped to dpram_dc (already used above for prog_rom, same 1-cycle read latency — outdata_reg_a defaults UNREGISTERED, matching spram's registered-q timing) so its init_file generic c
rtl/cpu/mb88_sv/mb88_core.sv:31 NOT MODELLED — NONE are gaps (MAME doesn't model them for the default part, or no target device uses them): * STANDBY (stby_n pin): MAME has no standby/STOP state for mb88.

Cites MAME source — 427

Arcade-PolePosition.sv:104 Slot 4 is now Service Mode = MAME IN0 bit 7 (PORT_SERVICE, the cabinet self-test toggle) on physical Y. Keep this list and the MRA <buttons> element character-for-character identical.
Arcade-PolePosition.sv:116 MAME reads both ports with NO inversion -- polepos.cpp:905-906 (53xx input<2>/<3> = DSWA nibbles) and :888-889 (51xx input<0>/<1> = DSWB nibbles) -- so an MRA byte now equals the MAME DSW byte exactly, and every <dip> ids list in the MRA ca
Arcade-PolePosition.sv:123 NOTE the set mapping: MAME's WORLD set uses the *poleposa* port table -- GAME(1982, polepos, 0, polepos, poleposa, ...) at polepos.cpp:2556.
Arcade-PolePosition.sv:127 Power-on values are the MAME defaults (DSWA 0xFF, DSWB 0x74) so a stale MRA with no <switches> still gives 1C/1C, 90 secs, 3 laps rather than the all-zero Free Play / 120 secs / 4 laps / Rank G+H that the missing block used to produce.
Arcade-PolePosition.sv:261 MAME polepos.cpp:503 declares it PORT_BIT(0x02,...,IPT_BUTTON3) POLEPOS_TOGGLE, and :252 is `#define POLEPOS_TOGGLE PORT_TOGGLE` -- each press flips Lo<->Hi and it HOLDS.
Arcade-PolePosition.sv:275 It is now Service Mode (MRA / CONF_STR slot 4, physical Y) = MAME IN0 bit 7, PORT_SERVICE -- the cabinet's self-test toggle.
Arcade-PolePosition.sv:355 `audio` is the Namco WSG mixer's signed two's-complement sum (namco_wsg8.sv, MAME namco.cpp mixing math) -- was 0 (arbitrary) while audio was tied off.
Arcade-PolePosition.sv:381 Watchdog defeat switch (rtl/pp_watchdog.sv wdog_en, MAME polepos.cpp:925 set_vblank_count(...,16)).
Arcade-PolePosition.sv:388 MAME polepos "chars" = ioctl INDEX 1, offset 0x0000, 0x1000 bytes (pp3_28.1f, crc 2e77187e).
Arcade-PolePosition.sv:431 Index-1 stream, padded to MAME's declared region sizes so one gate set serves PP1 and PP2.
Arcade-PolePosition.sv:434 road 0x18000 | scalelut 0x1D000 end 0x1E000 bigsprites keeps MAME's internal 0x2000 gap at sprite_rom[0xA000-0xBFFF].
Arcade-PolePosition.sv:449 Namco WSG waveform PROM — ioctl INDEX 2, region-relative 0x1040-0x113F (256 bytes, right after the 0x1040-byte "proms" block; MAME polepos "namco" region, pp1-5.3b crc 8568decc; 8 waveforms x 32 4-bit samples).
Arcade-PolePosition.sv:473 Engine sound waveform ROM — ioctl index 5, region-relative 0x0000-0x3FFF (pp1_15.6a + pp1_16.5a, MAME's "engine" region).
Arcade-PolePosition.sv:487 Steering (MAME "STEER" IPT_DIAL) — no real spinner/analog input is wired at this top level yet (#unverified / KNOWN ITERATION POINT).
Arcade-PolePosition.sv:527 Full scale is 0x90, NOT 0xFF, per MAME PORT_MINMAX(0,0x90) on both ACCEL and BRAKE.
Arcade-PolePosition.sv:531 PEDALS-2026-09-23: OSD "Pedals" = Analog reads one combined axis (up = accelerate, down = brake), |Y| 0..128 -> 0..0x90 (MAME PORT_MINMAX(0,0x90)) with a dead zone.
Arcade-PolePosition.sv:609 NOTE: `service` is MAME IN0 bit 6 = IPT_SERVICE1, the service-CREDIT button -- a DIFFERENT control from the self-test switch above.
rtl/PolePosition_CPU.sv:34 ---- LS259 control-latch outputs (MAME polepos.cpp:931-943) ----------------
rtl/PolePosition_CPU.sv:35 q4 0 = Z8002 #1 held in reset (MAME .invert())
rtl/PolePosition_CPU.sv:36 q5 0 = Z8002 #2 held in reset (MAME .invert())
rtl/PolePosition_CPU.sv:37 q1 Namco 51/52/53/54xx reset (polarity #unverified vs namco51.cpp)
rtl/PolePosition_CPU.sv:42 q6 auto_start_mask = !q6 in MAME
rtl/PolePosition_CPU.sv:148 Address decode (z80_map, MAME polepos.cpp:435-453) — mirrors folded in
rtl/PolePosition_CPU.sv:171 Z80 I/O space: ADC0804 at port 0x00 (z80_io, polepos.cpp:456-460)
rtl/PolePosition_CPU.sv:193 IRQ generation (polepos.cpp scanline() :392-403) maincpu IRQ asserted at 64V and 192V when q0=1; q0=0 acks/clears.
rtl/PolePosition_CPU.sv:206 q0=0 forces clear (MAME .invert())
rtl/PolePosition_CPU.sv:212 READY read (0xA000, polepos.cpp ready_r :291-302) bit1 ^= 1 when vpos>=128 ; bit3 ^= 1 when ADC INTR asserted (done)
rtl/PolePosition_CPU.sv:236 NVRAM (0x3000-0x37FF, battery-backed in MAME) — 2 KB MAME ground truth: polepos.cpp:927 NVRAM(config, "nvram", nvram_device::DEFAULT_ALL_1) -> a fresh/unbacked NVRAM powers up filled with 0xFF.
rtl/PolePosition_subcpu.sv:7 Z80 BYTE LANE (verified in polepos_v.cpp): sprite_r/w, road_r/w, alpha_r/w, view_r/w ALL read/write ONLY THE LOW BYTE of the 16-bit word: sprite_r: return mem[offset] & 0xff; sprite_w: mem[offset] = (mem[offset] & 0xff00) | data; identical
rtl/PolePosition_subcpu.sv:52 #deviation: Z8002-side buffer/register accesses are treated as WORD-ONLY (wordacc/addr[0] byte lane not modeled on the Z8002 side — only the Z80 side is genuinely byte-oriented per polepos_v.cpp).
rtl/PolePosition_subcpu.sv:58 NVI: nvi_latch_subN is armed at each sub_nvi_trig pulse (from that CPU's nvi_enable at that instant) and cleared when that CPU writes 0 to 0x6000, per polepos.cpp:319.
rtl/PolePosition_subcpu.sv:64 0x6000/0xC000/0xC100 mirror-mask decodes derived from the given MAME AM_MIRROR masks (0x1FFE, 0x38FE): significant-bit mask = ~mirror_mask.
rtl/PolePosition_subcpu.sv:261 MAME's declared 0x8000 sub regions; must match SUB_WINDOW in mra_emit.py.
rtl/PolePosition_subcpu.sv:331 The Z80 writes the LOW byte only (polepos_v.cpp byte lane) => it drives the lo-array write-enable but never the hi array; the z8002s write the full word.
rtl/PolePosition_subcpu.sv:410 // road16_memory layout (MAME draw_road): // 0x000-0x1FF : yoffs -> roadpal in bits [3:0]
rtl/PolePosition_subcpu.sv:520 NVI line: armed at each sub_nvi_trig pulse (gated by that CPU's nvi_enable at that instant), and de-asserted when that CPU writes 0 to its own nvi_enable -- polepos.cpp:319 set_input_line(NVI_LINE, CLEAR).
rtl/cpu/mb88_sv/mb88.sv:57 Generate it here: one ena_timer pulse per 32 `ena` machine-cycle enables — MAME mb88 burn_cycles /32 (full timer overflow = ÷8192 of `ena`).
rtl/cpu/mb88_sv/mb88_core.sv:6 Oracle: MAME cpu/mb88xx/mb88xx.cpp (opcode-for-opcode).
rtl/cpu/mb88_sv/mb88_core.sv:14 COMPLETE vs MAME mb88xx.cpp — opcode AND non-opcode.
rtl/cpu/mb88_sv/mb88_core.sv:16 OPCODES: all 256 bytes, verified byte-for-byte vs mb88xx.cpp execute_run() (0x00-2f individual; 0x30-3f sbit/rbit/tbit/rti/jpa/en/dis; 0x40-7f setD/ rstD/tstD/tba/xd/xyd/lxi/call/jpl/ai; 0x80-bf lyi/li/cyi/ci; 0xc0-ff jmp).
rtl/cpu/mb88_sv/mb88_core.sv:23 * Timer: internal (pio7, ÷32 prescale) OR external TC pin (pio6) per MAME increment_timer() (2026-07-11 + 2026-07-17 fixes).
rtl/cpu/mb88_sv/mb88_core.sv:29 * O-port PLA: 8-bit cf-nibble-select outO = MAME write_pla with pla_bits==8 (the device default; what the Namco 5xxx use).
rtl/cpu/mb88_sv/mb88_core.sv:34 * External-clock serial (pio 0x10/0x30): MAME fatalerror's it (unsupported).
rtl/cpu/mb88_sv/mb88_core.sv:40 0 = legacy 1-ce entry (51xx/52xx/53xx rely on it; the global MAME-exact change broke the 51xx and the main-CPU POST on 2026-09-19).
rtl/cpu/mb88_sv/mb88_core.sv:41 3 = MAME burn_cycles(3); the 54xx needs it or its IRQ handler reads the command latch before the 06xx byte lands (verilator/n54_cosim).
rtl/cpu/mb88_sv/mb88_core.sv:59 MAME's write_pla() ends with an unconditional `m_write_o(0, m_o_output, mask)` (mb88xx.cpp:373), so consumers that latch the O port (e.g. namco_51xx's shared mailbox = MAME m_portO) must re-latch on every write, not on a value change.
rtl/cpu/mb88_sv/mb88_core.sv:69 interrupt injection (harness drives from the MAME trace during bug hunt)
rtl/cpu/mb88_sv/mb88_core.sv:100 ---- SERIAL (2026-07-18; faithful to MAME mb88xx.cpp serial_timer()/pio_enable()) ---- 4-bit RECEIVE shift register clocked at clock()/SERIAL_PRESCALE(=6), armed when pio[5:4]==2'b10 (MAME's (m_pio & 0x30)==0x20 = internal serial clock).
rtl/cpu/mb88_sv/mb88_core.sv:104 sf blocks further shifting until tsts clears it; SBcount runaway-disables at THRESH (MAME anti-hang).
rtl/cpu/mb88_sv/mb88_core.sv:105 External-clock serial (pio 0x10/0x30) is unsupported by MAME (fatalerror) so we just don't tick.
rtl/cpu/mb88_sv/mb88_core.sv:106 SO/transmit is not modeled in MAME's mb88 either.
rtl/cpu/mb88_sv/mb88_core.sv:110 MAME SERIAL_DISABLE_THRESH
rtl/cpu/mb88_sv/mb88_core.sv:160 SP[] and ram[] intentionally NOT reset (MAME device_reset doesn't clear data RAM/stack; ROM inits RAM; Verilator zero-inits arrays).
rtl/cpu/mb88_sv/mb88_core.sv:166 MAME mb88xx.cpp: `if (m_ctr && !state && (m_pio & 0x40)) increment_timer(); m_ctr = state;` i.e. on a FALLING edge of the TC pin, if external-counter mode (pio bit6/0x40) is enabled, tick the SAME timer.
rtl/cpu/mb88_sv/mb88_core.sv:169 This drives the 51xx's per-frame timer, which MAME clocks from screen vblank (namco51.cpp vblank() -> MB88XX_TC_LINE).
rtl/cpu/mb88_sv/mb88_core.sv:174 Two mutually-exclusive sources feed the ONE counter (a chip uses internal OR external mode, never both): internal clock (ena_timer & pio7 = MAME 0x80), OR external TC falling edge (pio6 = MAME 0x40).
rtl/cpu/mb88_sv/mb88_core.sv:178 MCU-TIMER-FIX-2026-07-11: pio7 gate (MAME 0x80); TC-TIMER-FIX-2026-07-17: + external TC path (pio6/MAME 0x40)
rtl/cpu/mb88_sv/mb88_core.sv:185 ---- SERIAL receive engine (MAME serial_timer).
rtl/cpu/mb88_sv/mb88_core.sv:189 MAME SERIAL_PRESCALE=6 divides the MB88 PIN clock; `ce` is already pin/6 (MCU_CEN_DIV), so the /6 must not be applied twice.
rtl/cpu/mb88_sv/mb88_core.sv:197 MAME: SB = (SB>>1) | (si?8:0)
rtl/cpu/mb88_sv/mb88_core.sv:218 MAME clears all pending on take
rtl/cpu/mb88_sv/mb88_core.sv:226 outO: cf=1->oh, cf=0->ol (MAME write_pla 8-bit / VHDL).
rtl/cpu/z8002/z8002.sv:5 References: MAME z8000ops.hxx / z8000tbl.hxx / z8000cpu.h (behavioral oracle).
rtl/cpu/z8002/z8002.sv:65 RRn register-pair select truncates bit0 (RRn = R[n&0xE]:R[n&0xE+1]) -- authority is MAME z8000cpu.h:41 `#define RL(n) m_regs.L[BYTE_XOR_BE((n) >> 1)]`, i.e. bit0 of the nibble is discarded.
rtl/cpu/z8002/z8002.sv:93 RQ(n) (quad/64-bit register group for MULTL/DIVL) truncates n's LOW TWO bits (MAME `#define RQ(n) m_regs.Q[(n)>>2]`) -- base = {n[3:2],2'b00}, big-endian word order R[base]:R[base+1]:R[base+2]:R[base+3] MSW-first (verified structurally cons
rtl/cpu/z8002/z8002.sv:171 SKIPPED: COMB @rd (0x0C, NIB3=0) -- z8000ops.hxx's handler reads GET_DST(OP0,NIB3) instead of NIB2 like every sibling sub-op, which (since NIB3 is the fixed sub-op-selector, always 0 here) means MAME itself always resolves dst=R0 for this o
rtl/cpu/z8002/z8002.sv:198 RLDB/RRDB were traced term-by-term through the actual MAME C body (not the mnemonic's naive "rotate" implication) -- RLDB's second register (b) algebraically comes out UNCHANGED (tmp captured before any write, then re-OR'd back into itself)
rtl/cpu/z8002/z8002.sv:250 FCW interrupt-enable masks (MAME z8000cpu.h): F_NVIE=bit11 F_VIE=bit12 F_S_N=bit14
rtl/cpu/z8002/z8002.sv:272 real internal-trap infrastructure (EPU/privileged-instruction trap/system-call), modeled EXACTLY on the already-verified NVI accept sequence (S_NVI_PC/FCW/VEC/RDFCW/RDPC) -- push PC, push OLD fcw, push the trapping opcode word (MAME: "for i
rtl/cpu/z8002/z8002.sv:290 This trap sequence inherits the SAME single-SP simplification for consistency with the rest of this core, not because it's what MAME's literal source does.
rtl/cpu/z8002/z8002.sv:300 `mode` (MAME's RDPORT/WRPORT first param, 0=standard I/O space / 1=special I/O space) is NOT modeled as a separate signal -- this core's bus has exactly one `iorq` pin (no second "special I/O" strobe), so both spaces collapse onto the same
rtl/cpu/z8002/z8002.sv:317 repeat-rewind (MAME's `m_pc -= 4`) combinational scratch for the block-form register bump (S_IOB_WR)
rtl/cpu/z8002/z8002.sv:336 BATCH 3: RQ (quad, 4x16-bit) base register index for MULTL/DIVL = {dst[3:2],2'b00} (MAME `#define RQ(n) m_regs.Q[(n)>>2]` truncates the low TWO bits of n, one level wider than RL's bit0 truncation).
rtl/cpu/z8002/z8002.sv:527 MAME z8000ops.hxx SRAW/SRAL/SRLW/ SRLL bodies verified: right-arithmetic-shift NEVER sets V despite the "flags CZSV--" doc-comment (CLR_CZSV then no `if(...)SET_V` at all) -- matched exactly below, not assumed from the mnemonic.
rtl/cpu/z8002/z8002.sv:535 ---- BATCH 8 2026-07-27: remaining ISA gaps found via full-trace audit against the user's MAME boot-to-attract traces (pp_sub1_fullboot.trace/pp_sub2_fullboot.trace) -- every opcode word ACTUALLY EXECUTED by either sub, cross-referenced aga
rtl/cpu/z8002/z8002.sv:540 Families: 0x4D indexed (CP/TEST/LD-imm with a base+index addr), 0x5C direct LOAD direction (0x5C09's STORE sibling), 0x5D indexed (LDL store), 0x71 (LD word, register+register indexed -- the last confirmed-needed sibling of the 0x70-0x77 fa
rtl/cpu/z8002/z8002.sv:616 `iorq` (previously hardwired 0) now asserts during these four states; addr/dout/ wordacc follow the SAME byte-lane-vs-plain-word convention this file already uses uniformly for every other byte/word pair (RDPORT_B/WRPORT_B are structurally
rtl/cpu/z8002/z8002.sv:657 BATCH 19: 0x3A/0x3B block-I/O read-side byte extraction (S_IOB_RD stages the full word read into `operand`; S_IOB_WR extracts the byte MAME actually transfers).
rtl/cpu/z8002/z8002.sv:659 True for the word family (io_wide) OR the ONE confirmed MAME quirk (Z3A_ssss_0011/SOUTIB reads via RDIR_W(src) where every sibling byte block-op uses RDIR_B/RDPORT_B -- transcribed LITERALLY per z8000ops.hxx, not "corrected" to match its si
rtl/cpu/z8002/z8002.sv:935 ---- BATCH 18: INB (read-only byte-discard, like every other *_RD byte state above) and OUTB (byte write, no RMW needed for I/O -- MAME's WRPORT_B replicates+byte-enable-masks, it never reads the old port value first) are both genuine byte
rtl/cpu/z8002/z8002.sv:1076 parity flag (byte AND/OR/XOR P/V, MAME z8000_zsp[])
rtl/cpu/z8002/z8002.sv:1148 level-triggered NVI latch (MAME execute_input_edge_triggered==false for NVI): ================= NVIEDGE-2026-09-05 ============================== Was `if (!nvi_n) nvi_pending <= 1'b1;` -- level-sampled every ce, so the accept's clear was un
rtl/cpu/z8002/z8002.sv:1155 MAME sets the request ONLY in execute_set_input(), which the scheduler calls on line TRANSITIONS -- z8000.cpp: ASSERT does `m_irq_req |= Z8000_NVI`, accept does `m_irq_req &= ~Z8000_NVI`, and nothing re-sets it while the line stays asserted
rtl/cpu/z8002/z8002.sv:1180 `cyc_count` ticks every ce cycle unconditionally (the default assignment at the top of this block, same idiom as `retire`) starting from the instant an instruction is dispatched (reset to 1 below); `target_cycles` is that instruction's real
rtl/cpu/z8002/z8002.sv:1196 ---- NVI accept (instruction-boundary check, ahead of decode) ---- MAME z8002_device::Interrupt(): (m_irq_req&Z8000_NVI)&&(m_fcw&F_NVIE)
rtl/cpu/z8002/z8002.sv:1238 ---- LD @rd,rs store (0x2F, NIB2=dst(ptr)!=0) : ptr=NIB2, data=NIB3 ---- MAME Z2F_ddN0_ssss requires ptr!=0 (R0-as-pointer is undefined here, same "N0" convention as every other @rd-pointer family in this file); the guard was missing -- fou
rtl/cpu/z8002/z8002.sv:1250 ==== BATCH 7: SLA/SRA rd,#imm (0xB3, NIB3=9) : MAME ZB3_dddd_1001_imm8 ====
rtl/cpu/z8002/z8002.sv:1254 ==== BATCH 7: SLAL/SRAL rrd,#imm (0xB3, NIB3=D) : MAME ZB3_dddd_1101_imm8 ==
rtl/cpu/z8002/z8002.sv:1258 ==== BATCH 7: SLLL/SRLL rrd,#imm (0xB3, NIB3=5) : MAME ZB3_dddd_0101_imm8 ==
rtl/cpu/z8002/z8002.sv:1262 ==== BATCH 7: LDA prd,addr (0x7600-0x760f, NIB2==0) : MAME Z76_0000_dddd_addr
rtl/cpu/z8002/z8002.sv:1266 ==== BATCH 7: LDA prd,addr(rs) (0x7610-0x76ff, NIB2!=0) : MAME Z76_ssN0_dddd_addr ====
rtl/cpu/z8002/z8002.sv:1271 ==== BATCH 8: LD rd,rs(rx) (0x71, NIB2!=0) : MAME Z71_ssN0_dddd_0000_xxxx_0000_0000.
rtl/cpu/z8002/z8002.sv:1315 ==== BATCH 16: JP cc,addr (0x5E00-0x5E0F, NIB2=0) : MAME Z5E_0000_cccc_addr "jp cc,addr".
rtl/cpu/z8002/z8002.sv:1321 ==== BATCH 16 BUG FIX: JP cc,addr(rd) (0x5E10-0x5EFF, NIB2=dst!=0) : MAME Z5E_ddN0_cccc_addr "jp cc,addr(rd)".
rtl/cpu/z8002/z8002.sv:1338 ---- LD @rd,#imm16 (0x0D, NIB3=5, dst!=0): EA=R[dst] ---- MAME Z0D_ddN0_0101_imm16 requires dst!=0 (R0-as-pointer undefined, same "N0" convention used elsewhere); guard was missing, found via the cycle-accuracy audit (dst==0 maps to MAME's
rtl/cpu/z8002/z8002.sv:1345 ---- direct group (0x4D, NIB2=0): 1=CP#imm 5=LD#imm 8=CLR 4=TEST ---- CP-DIRECT-FIX-2026-08-09: 4'h1 (CP addr,#imm16 -- MAME Z4D_0000_0001_addr_imm16) was MISSING here and fell to the default -> S_ILLEGAL, which is a silent terminal hang (`
rtl/cpu/z8002/z8002.sv:1370 ==== BATCH 8: indexed group (0x4D, NIB2!=0): addr(rx) instead of plain addr -- 1=CP#imm(NEW: MAME Z4D_ddN0_0001_addr_imm16, compare mem@addr(rx) against a fetched imm16, discard result, CZSV flags per the existing S_ALU CP shape) 5=LD#imm(M
rtl/cpu/z8002/z8002.sv:1374 "dst" here is really the INDEX register (MAME's own naming, kept only for its GET_DST macro use) -- reused as `idxr` per this file's convention.
rtl/cpu/z8002/z8002.sv:1375 ==== BATCH 10: added 4'h0/2/6 (COM/NEG/TSET via dadop+S_DAD_FETCHX) AND 4'h8 (CLR -- MAME Z4D_ddN0_1000_addr, was MISSING from this indexed case entirely, a second CP-DIRECT-FIX-shaped gap: it silently fell to S_ILLEGAL just like 4D01 did b
rtl/cpu/z8002/z8002.sv:1401 MAME QUIRK: Z4C_0000_0000_addr (COMB addr, direct, no index) reads via RDMEM_W not RDMEM_B in z8000ops.hxx -- an apparent source typo (every OTHER member of this family, incl.
rtl/cpu/z8002/z8002.sv:1434 ==== BATCH 10: LDB addr(rd),rbs (0x4E) -- MAME QUIRK: z8000tbl.hxx's ONLY table entry for this handler is `{0x4e11,0x4ef0,16,...}`, which (per the verified beg/end/step init loop in z8000.cpp: `for(val=beg;val<=end; val+=step) z8000_exec[va
rtl/cpu/z8002/z8002.sv:1439 Its semantic sibling Z6E_ddN0_ssss_addr (0x6E, already implemented) uses a DENSE step=1 table for the identical shape (index reg + byte value reg + fetched addr) -- confirming 2-free-nibble instructions normally get dense tables in this sou
rtl/cpu/z8002/z8002.sv:1500 MAME z8000ops.hxx ZF_dddd_0dsp7: RB(dst)-=1; if (RB(dst)) set_pc(m_pc - 2*dsp7); Same shape as the word form directly above.
rtl/cpu/z8002/z8002.sv:1532 No multiprocessor cascade exists on this board (single Z8002, mu pins unconnected) -- MAME's own bodies are LITERALLY EMPTY beyond the privilege check (just a comment: "/* set mu-0 line */" etc, no state/flag change at all, confirmed by rea
rtl/cpu/z8002/z8002.sv:1544 ==== BATCH 18: MREQ rd (0x7B_dddd_1101) : MAME Z7B_dddd_1101, flags -ZS---.
rtl/cpu/z8002/z8002.sv:1547 With mu-I tied low (no multiprocessor peer -- same "unconnected pin" precedent as vi_n/nmi_n elsewhere in this core), MAME's own body resolves UNCONDITIONALLY to Z=1,S=0 (verified term-by-term against the C body's two `if(m_mi)` branches wi
rtl/cpu/z8002/z8002.sv:1568 ==== BATCH 18: LDPS @rs (0x3910-0x39F0, NIB2=src!=0, NIB3=0 FIXED -- z8000tbl.hxx's ONLY entry is `{0x3910,0x39f0,16,...}`) : MAME Z39_ssN0_0000.
rtl/cpu/z8002/z8002.sv:1575 Single unified memory space (this core has never modeled a separate stack-vs-data space anywhere -- MAME's `src==SP?m_stack:m_data` distinction collapses to the same bus here, consistent with every other instruction in this file).
rtl/cpu/z8002/z8002.sv:1586 ==== BATCH 18: LDPS addr[,(rs)] (0x7900 exact / 0x7910-0x79F0, NIB3=0 FIXED in both) : MAME Z79_0000_0000_addr / Z79_ssN0_0000_addr.
rtl/cpu/z8002/z8002.sv:1613 ---- ==== BATCH 17: real internal traps, per MAME z8000ops.hxx/z8000.cpp exactly, using the S_TRAP_* sequence added this batch.
rtl/cpu/z8002/z8002.sv:1615 ==== ---- Z0E/Z0F/Z8E/Z8F (ext0e/ext0f/ext8e/ext8f) : MAME body calls CHECK_EXT_INSTR() = "if (!(m_fcw & F_EPU)) { trap; return; }" FIRST.
rtl/cpu/z8002/z8002.sv:1622 When F_EPU IS set, MAME's body does nothing beyond consuming imm8 (the "Z8001 EPU code goes here" branch is a literal empty comment in z8000ops.hxx, verified -- not guessed).
rtl/cpu/z8002/z8002.sv:1630 ---- Z36_0000_0000 (BPT, 0x3600 exact) : MAME body is `m_irq_req |= Z8000_TRAP;` UNCONDITIONALLY (no CHECK_ macro at all -- this one always traps, in any mode).
rtl/cpu/z8002/z8002.sv:1636 ---- Z7F_imm8 (SC, system call, 0x7F00-0x7FFF) : MAME body is `GET_IMM8(0); m_irq_req |= Z8000_SYSCALL;` UNCONDITIONALLY (no CHECK_ macro -- SC always traps, that's its entire purpose; imm8 is word0's own low byte, already consumed, no PC e
rtl/cpu/z8002/z8002.sv:1643 ==== BATCH 15 (still no-op, confirmed genuinely correct per MAME -- see report): Z38/Z78/Z7E/Z9D/Z9F/ZBF/Z36_imm8 have NO CHECK_EXT_INSTR call at all in their real C bodies (verified line-by-line) -- they just test `if (m_fcw & F_EPU)` and
rtl/cpu/z8002/z8002.sv:1647 Since F_EPU is realistically never set on this board, MAME's own source treats these as UNCONDITIONAL no-ops, never traps -- this is not a corner cut, it is the literal, correct behavior per the authoritative source.
rtl/cpu/z8002/z8002.sv:1677 ==== ---- INB rbd,@rs (0x3C) : MAME Z3C_ssss_dddd.
rtl/cpu/z8002/z8002.sv:1684 ---- IN rd,@rs (0x3D) : MAME Z3D_ssss_dddd.
rtl/cpu/z8002/z8002.sv:1690 ---- OUTB @rd,rbs (0x3E) : MAME Z3E_dddd_ssss.
rtl/cpu/z8002/z8002.sv:1696 ---- OUT @rd,rs (0x3F) : MAME Z3F_dddd_ssss.
rtl/cpu/z8002/z8002.sv:1703 UNLIKE the size=1 bucket above, these are genuinely SPARSE (multiple distinct sub-ops packed into one top byte, each pinned to specific NIB2/NIB3 values by its own table line) -- guards below reproduce each family's exact true valid set (NO
rtl/cpu/z8002/z8002.sv:1766 ---- DI/EI i2 (0x7C00-0x7C07): NIB2=0, bit2 0=DI/1=EI, imm2=din[1:0] ---- MAME: di fcw&=(imm2<<11)|0xe7ff ; ei fcw|=(~imm2<<11)&0x1800 i.e. per interrupt bit: imm2 bit=1 -> leave alone, bit=0 -> act (set/clear)
rtl/cpu/z8002/z8002.sv:1807 ==== BATCH 1: stack + control flow ==================================== ---- CALL @Rd indirect (0x1F, NIB2=dst!=0,NIB3=0) : MAME Z1F_ddN0_0000 ---- push PC (=pc2, already the post-fetch return addr), jump to R[dst].
rtl/cpu/z8002/z8002.sv:1813 ---- CALL addr direct (0x5F00 exact) : MAME Z5F_0000_0000_addr ---- fetch target word, then push PC(=old_pc+4)/jump.
rtl/cpu/z8002/z8002.sv:1818 ==== BATCH 11: CALL addr(rd) indexed (0x5F10-0x5FF0, NIB2=dst!=0) : MAME Z5F_ddN0_0000_addr.
rtl/cpu/z8002/z8002.sv:1819 NIB3 is a FIXED "0000" field here (unlike the 0x51/53/ 55/57 families where the low nibble is a genuine free index-register operand) -- z8000tbl.hxx's single table line `{0x5f10,0x5ff0,16,...}` confirms NIB3=0 always (BUG FOUND AND FIXED he
rtl/cpu/z8002/z8002.sv:1861 Indexed reuses S_LDA76_FETCH/GO verbatim -- its `operand + (lda76_has_src?R[src]:0)` formula IS R[src]+idx16 (addition commutes; MAME's own RDBX_*/add_to_ addr_reg helpers add register+fetched-word in either order, see report).
rtl/cpu/z8002/z8002.sv:1888 ---- CALR dsp12 (0xD000-0xDFFF) : MAME ZD_dsp12 ---- target = pc2 - 2*sext12(din[11:0]).
rtl/cpu/z8002/z8002.sv:1890 MAME (z8000ops.hxx:6834) writes this piecewise: dsp12 = (dsp12 & 2048) ?
rtl/cpu/z8002/z8002.sv:1895 Note the default direction is BACKWARD (bit11 clear => negative), which is why MAME's expression looks inverted.
rtl/cpu/z8002/z8002.sv:1901 ---- RET cc (0x9E, NIB2=0) : MAME Z9E_0000_cccc ---- conditional pop-PC; if cc false, stack is UNTOUCHED (MAME only pops inside the taken case) -- just retire in place.
rtl/cpu/z8002/z8002.sv:1911 ---- PUSH @Rd,Rs (0x93, NIB2=dst!=0) : MAME Z93_ddN0_ssss ----
rtl/cpu/z8002/z8002.sv:1915 ---- PUSH @Rd,#imm16 (0x0D, NIB2=dst!=0, NIB3=9) : MAME Z0D_ddN0_1001_imm16 ----
rtl/cpu/z8002/z8002.sv:1919 ---- PUSH @Rd,addr direct (0x53, NIB2=dst!=0,NIB3=0) : MAME Z53_ddN0_0000_addr ----
rtl/cpu/z8002/z8002.sv:1923 ==== BATCH 11: PUSH @Rd,addr(rs) indexed (0x53, NIB2=dst!=0,NIB3=src!=0) : MAME Z53_ddN0_ssN0_addr.
rtl/cpu/z8002/z8002.sv:1929 ---- POP Rd,@Rs (0x97, NIB2=src!=0) : MAME Z97_ssN0_dddd ----
rtl/cpu/z8002/z8002.sv:1933 ---- POP addr,@Rs direct (0x57, NIB2=src!=0,NIB3=0) : MAME Z57_ssN0_0000_addr ----
rtl/cpu/z8002/z8002.sv:1937 ==== BATCH 11: POP addr(rd),@Rs indexed (0x57, NIB2=src!=0,NIB3=dst!=0) : MAME Z57_ssN0_ddN0_addr.
rtl/cpu/z8002/z8002.sv:1938 src(NIB2)=POP source pointer register (postincrement, unchanged from the direct form); dst(NIB3)=index register added to the fetched addr (MAME names it "dst" only because GET_DST's macro shape fits -- it's a plain index register here, no r
rtl/cpu/z8002/z8002.sv:1946 ---- PUSHL @Rd,RRs (0x91, NIB2=dst!=0) : MAME Z91_ddN0_ssss ---- dst=pointer reg (plain); src=value register PAIR select (bit0 truncated, see file header).
rtl/cpu/z8002/z8002.sv:1953 ---- POPL RRd,@Rs (0x95, NIB2=src!=0) : MAME Z95_ssN0_dddd ---- src=pointer reg (plain); dst=dest register PAIR select (bit0 truncated).
rtl/cpu/z8002/z8002.sv:1959 ==== BATCH 11: PUSHL @Rd,addr[,(rs)] (0x51, NIB2=dst!=0) : MAME Z51_ddN0_0000_addr / Z51_ddN0_ssN0_addr.
rtl/cpu/z8002/z8002.sv:1970 ==== BATCH 11: POPL addr[,(rd)],@Rs (0x55, NIB2=src!=0) : MAME Z55_ssN0_0000_addr / Z55_ssN0_ddN0_addr.
rtl/cpu/z8002/z8002.sv:1979 ==== BATCH 11: SUBL rrd,addr[,(rs)] (0x52) : MAME Z52_0000_dddd_addr / Z52_ssN0_dddd_addr.
rtl/cpu/z8002/z8002.sv:1988 ==== BATCH 11: ADDL rrd,addr[,(rs)] (0x56) : MAME Z56_0000_dddd_addr / Z56_ssN0_dddd_addr.
rtl/cpu/z8002/z8002.sv:1995 ==== BATCH 11: MULTL rqd,addr[,(rs)] (0x58) : MAME Z58_0000_dddd_addr / Z58_ssN0_dddd_addr.
rtl/cpu/z8002/z8002.sv:2002 ==== BATCH 11: DIVL rqd,addr[,(rs)] (0x5A) : MAME Z5A_0000_dddd_addr / Z5A_ssN0_dddd_addr.
rtl/cpu/z8002/z8002.sv:2009 ==== BATCH 11: MULT rrd,addr[,(rs)] (0x59) : MAME Z59_0000_dddd_addr / Z59_ssN0_dddd_addr.
rtl/cpu/z8002/z8002.sv:2016 ==== BATCH 11: DIV rrd,addr[,(rs)] (0x5B) : MAME Z5B_0000_dddd_addr / Z5B_ssN0_dddd_addr.
rtl/cpu/z8002/z8002.sv:2023 ---- LDL RRd,RRs (0x94, full range) : MAME Z94_ssss_dddd ---- single-cycle reg-pair move, no memory access.
rtl/cpu/z8002/z8002.sv:2036 MAME Z94_ssss_dddd: RL(dst) = RL(src).
rtl/cpu/z8002/z8002.sv:2043 ---- LDL RRd,#imm32 (0x14, NIB2=0) : MAME Z14_0000_dddd_imm32 ---- imm32 = {word1(hi),word2(lo)} (verified via GET_IMM32 macro).
rtl/cpu/z8002/z8002.sv:2048 ---- LDL RRd,@Rs (0x14, NIB2=src!=0) : MAME Z14_ssN0_dddd ----
rtl/cpu/z8002/z8002.sv:2052 ---- LDL @Rd,RRs (0x1D, NIB2=dst!=0) : MAME Z1D_ddN0_ssss ----
rtl/cpu/z8002/z8002.sv:2056 ---- LDL RRd,addr direct (0x54, NIB2=0) : MAME Z54_0000_dddd_addr ----
rtl/cpu/z8002/z8002.sv:2060 ==== BATCH 7 (post-verify): LDL RRd,addr(rs) indexed (0x54, NIB2!=0) : MAME Z54_ssN0_dddd_addr.
rtl/cpu/z8002/z8002.sv:2066 ---- LDL addr,RRs direct (0x5D, NIB2=0) : MAME Z5D_0000_ssss_addr ----
rtl/cpu/z8002/z8002.sv:2070 ==== BATCH 8: LDL addr(rx),RRs indexed (0x5D, NIB2!=0) : MAME Z5D_ddN0_ssss_addr (dst here is the INDEX reg per z8000ops.hxx GET_DST, src is the reg-pair stored).
rtl/cpu/z8002/z8002.sv:2078 ---- LDM rd,@rs,n (0x1C, NIB2=src!=0,NIB3=1) : MAME Z1C_ssN0_0001_0000_dddd_0000_nmin1 ---- word2 = {4'b0,dst[11:8],4'b0,cnt[3:0]}; transfers cnt+1 words mem->regs, dst wraps mod 16 each step (natural 4-bit reg wrap == MAME's (dst+1)&15).
rtl/cpu/z8002/z8002.sv:2084 ---- LDM @rd,rs,n (0x1C, NIB2=dst!=0,NIB3=9) : MAME Z1C_ddN0_1001_0000_ssss_0000_nmin1 ----
rtl/cpu/z8002/z8002.sv:2088 ==== BATCH 15: TESTL @rd (0x1C, NIB2=dst!=0,NIB3=8) : MAME Z1C_ddN0_1000 "testl @rd", flags -ZS---.
rtl/cpu/z8002/z8002.sv:2097 ==== BATCH 7 (post-verify): LDM addr,rs,n (0x5C09) direct-address STORE : MAME Z5C_0000_1001_0000_ssss_0000_nmin1_addr.
rtl/cpu/z8002/z8002.sv:2104 ==== BATCH 11: LDM addr(rd),rs,n (0x5CN9, NIB2=idx!=0) indexed sibling of 0x5C09 above : MAME Z5C_ddN0_1001_0000_ssN0_0000_nmin1_addr.
rtl/cpu/z8002/z8002.sv:2111 ==== BATCH 8: LDM rd,addr,n (0x5C01) direct-address LOAD, the load-direction sibling of 0x5C09 above : MAME Z5C_0000_0001_0000_dddd_0000_nmin1_addr.
rtl/cpu/z8002/z8002.sv:2118 ==== BATCH 11: LDM rd,addr(rs),n (0x5CN1, NIB2=idx!=0) indexed sibling of 0x5C01 above : MAME Z5C_ssN0_0001_0000_dddd_0000_nmin1_addr.
rtl/cpu/z8002/z8002.sv:2124 ==== BATCH 11: TESTL addr (0x5C08 exact) : MAME Z5C_0000_1000_addr.
rtl/cpu/z8002/z8002.sv:2130 ==== BATCH 11: TESTL addr(rd) indexed (0x5CN8, NIB2=idx!=0) : MAME Z5C_ddN0_1000_addr.
rtl/cpu/z8002/z8002.sv:2135 ==== BATCH 2 PART A: indirect-indirect PUSHL/PUSH/POPL/POP ================ ---- PUSHL @Rd,@Rs (0x11) : MAME Z11_ddN0_ssN0 "pushl @rd,@rs" ---- value = long read INDIRECTLY at R[src] (src ptr unmodified); pushed (pre-decrement by 4) to R[ds
rtl/cpu/z8002/z8002.sv:2156 ---- PUSH @Rd,@Rs (0x13) : MAME Z13_ddN0_ssN0 "push @rd,@rs" ---- value = word read INDIRECTLY at R[src] (unmodified); hands off to the existing S_PUSH_W commit (addr=R[dst]-2,dout=operand,we=1) unchanged.
rtl/cpu/z8002/z8002.sv:2165 ---- POPL RRd,@Rs (0x15) : MAME Z15_ssN0_ddN0 "popl rd,@rs" ---- Body is BYTE-IDENTICAL to the already-implemented 0x95 (POPL RRd,@Rs): dst is a DIRECT register-pair write (RL(dst)=POPL(src)), never indirect -- despite MAME's disassembler (
rtl/cpu/z8002/z8002.sv:2180 ---- POP @Rd,@Rs (0x17) : MAME Z17_ssN0_ddN0 "pop @rd,@rs" ---- dst(NIB3)=target pointer (WRITTEN indirectly, itself never modified); src(NIB2)=source pointer (POPPED: read then +2).
rtl/cpu/z8002/z8002.sv:2192 ==== BATCH 2 PART B: byte ALU/LDB, LDB store, CPL, JP/EX, BIT/RES/SET ===== Shared byte pipeline (S_IMMB/S_MEMRDB/S_ALUB) mirrors the existing word ALU pipeline (S_IMM/S_MEMRD/S_ALU) exactly, but for the byte register file (RB(n): dst[3]?LO
rtl/cpu/z8002/z8002.sv:2200 ---- ADDB rd,#imm8 (0x00, NIB2=0) : MAME Z00_0000_dddd_imm8 ----
rtl/cpu/z8002/z8002.sv:2204 ---- SUBB rd,#imm8/@rs (0x02) : MAME Z02_0000_dddd_imm8 / Z02_ssN0_dddd ----
rtl/cpu/z8002/z8002.sv:2209 ---- ORB rd,#imm8/@rs (0x04) : MAME Z04_0000_dddd_imm8 / Z04_ssN0_dddd ----
rtl/cpu/z8002/z8002.sv:2214 ---- ANDB rd,#imm8/@rs (0x06) : MAME Z06_0000_dddd_imm8 / Z06_ssN0_dddd ----
rtl/cpu/z8002/z8002.sv:2219 ---- XORB rd,#imm8/@rs (0x08) : MAME Z08_0000_dddd_imm8 / Z08_ssN0_dddd ----
rtl/cpu/z8002/z8002.sv:2224 ---- CPB rd,#imm8/@rs (0x0A) : MAME Z0A_0000_dddd_imm8 / Z0A_ssN0_dddd ----
rtl/cpu/z8002/z8002.sv:2229 ---- LDB rd,#imm8/@rs (0x20) : MAME Z20_0000_dddd_imm8 / Z20_ssN0_dddd ----
rtl/cpu/z8002/z8002.sv:2246 ---- LDB @Rd,rbs store (0x2E, NIB2=dst!=0) : MAME Z2E_ddN0_ssss "ldb @rd,rbs" ---- RMW-safe byte store, see S_LDBST_RD/WR header comment (wordacc unconnected).
rtl/cpu/z8002/z8002.sv:2251 ---- JP cc,@Rd (0x1E, NIB2=dst!=0) : MAME Z1E_ddN0_cccc "jp cc,@rd" ---- addr_from_reg(dst) reduces to plain RW(dst) in non-segmented (Z8002) mode -- despite the MAME disassembler cosmetically showing "@rr1" (a segmented-mode register-pair
rtl/cpu/z8002/z8002.sv:2261 ---- CPL rrd,@rs (0x10, NIB2=src!=0) : MAME Z10_ssN0_dddd "cpl rrd,@rs" ---- compare-only long, no writeback.
rtl/cpu/z8002/z8002.sv:2267 ---- CPL rrd,rrs (0x90, full range) : MAME Z90_ssss_dddd "cpl rrd,rrs" ---- compare-only, no writeback, no memory access -- routed through S_CPL_RR (shares the same flag-compute code shape as the indirect form above).
rtl/cpu/z8002/z8002.sv:2273 ---- BITB @Rd,#imm4 (0x26, NIB2=dst!=0) : MAME Z26_ddN0_imm4, flags -Z---- ---- read-only (no RMW hazard).
rtl/cpu/z8002/z8002.sv:2279 ---- BIT @Rd,#imm4 (0x27, NIB2=dst!=0) : MAME Z27_ddN0_imm4, flags -Z---- ----
rtl/cpu/z8002/z8002.sv:2289 ---- RES @Rd,#imm4 (0x23, NIB2=dst!=0) : MAME Z23_ddN0_imm4, flags ------ ----
rtl/cpu/z8002/z8002.sv:2294 ---- SET @Rd,#imm4 (0x25, NIB2=dst!=0) : MAME Z25_ddN0_imm4, flags ------ ----
rtl/cpu/z8002/z8002.sv:2317 ---- EX rd,@rs (0x2D, NIB2=src!=0) : MAME Z2D_ssN0_dddd "ex rd,@rs", flags ------ ---- word-only exchange (safe, full-word RMW).
rtl/cpu/z8002/z8002.sv:2323 ==== BATCH 3 ============================================================= ---- INC addr,#n direct (0x6900-0x690F, NIB2=0) : MAME Z69_0000_imm4m1_addr, flags -ZSV--.
rtl/cpu/z8002/z8002.sv:2333 ---- DEC addr,#n direct (0x6B00-0x6B0F, NIB2=0) : MAME Z6B_0000_imm4m1_addr, flags -ZSV--.
rtl/cpu/z8002/z8002.sv:2338 ---- MULT rrd,#imm16 (0x1900-0x190F, NIB2=0) : MAME Z19_0000_dddd_imm16 ---- flags CZS--- ; V is NEVER set by MULTW despite the MAME doc-comment saying "CZSV--" -- the function body only calls CLR_CZSV, no SET_V anywhere.
rtl/cpu/z8002/z8002.sv:2345 ---- MULT rrd,@rs (0x1910-0x19FF, NIB2!=0) : MAME Z19_ssN0_dddd ----
rtl/cpu/z8002/z8002.sv:2349 ---- MULT rrd,rs (0x9900-0x99FF, full range) : MAME Z99_ssss_dddd ----
rtl/cpu/z8002/z8002.sv:2353 ---- DIV rrd,#imm16 (0x1B00-0x1B0F, NIB2=0) : MAME Z1B_0000_dddd_imm16 ---- flags CZSV--.
rtl/cpu/z8002/z8002.sv:2358 ---- DIV rrd,@rs (0x1B10-0x1BFF, NIB2!=0) : MAME Z1B_ssN0_dddd ----
rtl/cpu/z8002/z8002.sv:2362 ---- DIV rrd,rs (0x9B00-0x9BFF, full range) : MAME Z9B_ssss_dddd ----
rtl/cpu/z8002/z8002.sv:2366 ---- MULTL rqd,@rs (0x1810-0x18FF, NIB2!=0) : MAME Z18_ssN0_dddd ---- RQ(dst) truncates dst's low TWO bits (see header comment); the 32-bit dest value MULTL actually reads is the LOW half of the quad, i.e. RL(dst|2).
rtl/cpu/z8002/z8002.sv:2372 ==== BATCH 14: MULTL rqd,#imm32 (0x1800-0x180F, NIB2=0) : MAME Z18_00N0_dddd_imm32.
rtl/cpu/z8002/z8002.sv:2380 ---- MULTL rqd,rrs (0x9800-0x98FF, full range) : MAME Z98_ssss_dddd ---- src is a 32-bit register PAIR here (unlike MULT's plain-register src) -- staged combinationally straight off `din`, same convention already used by ADDL/SUBL reg-reg b
rtl/cpu/z8002/z8002.sv:2390 ---- DIVL rqd,@rs (0x1A10-0x1AFF, NIB2!=0) : MAME Z1A_ssN0_dddd ---- Dividend is the FULL 64-bit quad (read live off the regfile in S_DIVL_GO); only the 32-bit divisor needs fetching here.
rtl/cpu/z8002/z8002.sv:2396 ==== BATCH 14: DIVL rqd,#imm32 (0x1A00-0x1A0F, NIB2=0) : MAME Z1A_0000_dddd_imm32.
rtl/cpu/z8002/z8002.sv:2402 ---- DIVL rqd,rrs (0x9A00-0x9AFF, full range) : MAME Z9A_ssss_dddd ----
rtl/cpu/z8002/z8002.sv:2408 ---- ADDL rrd,#imm32 (0x1600-0x160F, NIB2=0) : MAME Z16_0000_dddd_imm32 ----
rtl/cpu/z8002/z8002.sv:2412 ---- ADDL rrd,@rs (0x1610-0x16FF, NIB2!=0) : MAME Z16_ssN0_dddd ----
rtl/cpu/z8002/z8002.sv:2416 ---- ADDL rrd,rrs (0x9600-0x96FF, full range) : MAME Z96_ssss_dddd ----
rtl/cpu/z8002/z8002.sv:2422 ---- SUBL rrd,#imm32 (0x1200-0x120F, NIB2=0) : MAME Z12_0000_dddd_imm32 ----
rtl/cpu/z8002/z8002.sv:2426 ---- SUBL rrd,@rs (0x1210-0x12FF, NIB2!=0) : MAME Z12_ssN0_dddd ----
rtl/cpu/z8002/z8002.sv:2430 ---- SUBL rrd,rrs (0x9200-0x92FF, full range) : MAME Z92_ssss_dddd ----
rtl/cpu/z8002/z8002.sv:2436 ---- LDB rbd,addr direct-load (0x6000-0x600F, NIB2=0) : MAME Z60_0000_dddd_addr "ldb rbd,addr", flags ------.
rtl/cpu/z8002/z8002.sv:2444 ---- LDB addr,rbs direct-store (0x6E00-0x6E0F, NIB2=0) : MAME Z6E_0000_ssss_addr "ldb addr,rbs", flags ------.
rtl/cpu/z8002/z8002.sv:2452 ---- CLRB rbd (0x8Cd8, NIB1=8) : MAME Z8C_dddd_1000, flags ------ ---- 0x8C is actually a 7-way static-op family (comb/negb/testb/tsetb/ldctlb-r/ clrb/ldctlb-w, selected by NIB1) -- the task brief's "CLRB/TESTB static" framing undersold the
rtl/cpu/z8002/z8002.sv:2463 ---- TESTB rbd (0x8Cd4, NIB1=4) : MAME Z8C_dddd_0100, flags -ZSP-- ---- Z/S/parity via the same z8000_zsp[]-equivalent formula already used for Batch 2's byte AND/OR/XOR P/V (parity, not overflow).
rtl/cpu/z8002/z8002.sv:2472 ---- RLB rbd,#1|#2 (0xB2d0/0xB2d2, NIB1={0,2}) : MAME ZB2_dddd_00I0, flags CZSV--.
rtl/cpu/z8002/z8002.sv:2484 ---- RRB rbd,#1|#2 (0xB2d4/0xB2d6, NIB1={4,6}) : MAME ZB2_dddd_01I0, flags CZSV--.
rtl/cpu/z8002/z8002.sv:2485 QUIRK (verified in RRB(), not the doc-comment): if result==0 only Z is set; else if result[7] BOTH S and C are set together (MAME SET_SC macro); else (positive nonzero) neither Z/S/C is touched.
rtl/cpu/z8002/z8002.sv:2499 ---- RRCB rbd,#1|#2 (0xB2dC/0xB2dE, NIB1={C,E}) : MAME ZB2_dddd_11I0 "rotate right through carry", flags CZSV-- (doc-comment says "-Z----", WRONG -- the RRCB() body clearly does CLR_CZSV + SET_C + SET_V, trusted the code).
rtl/cpu/z8002/z8002.sv:2518 ==== BATCH 14: RLCB rbd,#1|#2 (0xB2d8/0xB2dA, NIB1={8,A}) : MAME ZB2_dddd_10I0 "rotate left through carry", flags CZSV--.
rtl/cpu/z8002/z8002.sv:2537 ---- SLLB/SRLB rbd,#imm8 (0xB2d1, NIB1=1) : MAME ZB2_dddd_0001_imm8, sign of imm8 selects direction (matches the existing word S_SHIFT convention exactly, negative=right/SRLB, positive=left/SLLB).
rtl/cpu/z8002/z8002.sv:2547 ==== BATCH 14: SDLB rbd,rs (0xB2d3) : MAME ZB2_dddd_0011_0000_ssss_0000_0000, flags CZSV-- (its doc-comment AND body both confirm V IS set here, unlike SLLB's imm8 sibling above -- verified, not assumed from the "SD" prefix's resemblance to
rtl/cpu/z8002/z8002.sv:2550 Dynamic (register- count) sibling of SLLB/SRLB: count = sign-extended R[word2 NIB1][7:0], positive=left/negative=right (same convention as every imm-shift in this file), computed as a single barrel shift + explicit carry-capture -- proven e
rtl/cpu/z8002/z8002.sv:2562 ---- SDAB rbd,rs (0xB2dB) : MAME ZB2_dddd_1011_0000_ssss_0000_0000, flags CZSV--.
rtl/cpu/z8002/z8002.sv:2569 ==== BATCH 15: SLAB/SRAB rbd,#imm8 (0xB2d9) : MAME ZB2_dddd_1001_imm8, flags CZSV-- (byte arithmetic sibling of the already-implemented SLLB/ SRLB imm8, S_SHIFTB).
rtl/cpu/z8002/z8002.sv:2576 ==== BATCH 14: RL/RR/RLC/RRC rd,#1|#2 (0xB3d0/d2/d4/d6/d8/dA/dC/dE) : MAME ZB3_dddd_00I0/01I0/10I0/11I0, flags CZSV--.
rtl/cpu/z8002/z8002.sv:2651 ---- CPL rrd,addr direct (0x5000-0x500F, NIB2=0) : MAME Z50_0000_dddd_addr "cpl rrd,addr", compare-only, no writeback.
rtl/cpu/z8002/z8002.sv:2670 ---- LDB rbd,addr(Rs) indexed load (0x6010-0x60FF, NIB2=idx!=0) : MAME Z60_ssN0_dddd_addr.
rtl/cpu/z8002/z8002.sv:2675 ---- LDB addr(Rs),rbs indexed store (0x6E10-0x6EFF, NIB2=idx!=0) : MAME Z6E_ddN0_ssss_addr (field named "dd" but is the INDEX reg, not a dest -- same misleading-macro-name pattern already flagged for Z69/Z6B).
rtl/cpu/z8002/z8002.sv:2683 ---- CPL rrd,addr(Rs) indexed (0x5010-0x50FF, NIB2=idx!=0) : MAME Z50_ssN0_dddd_addr.
rtl/cpu/z8002/z8002.sv:2688 ---- INC addr(Rd),#n indexed (0x6910-0x69FF, NIB2=idx!=0) : MAME Z69_ddN0_imm4m1_addr.
rtl/cpu/z8002/z8002.sv:2694 ---- DEC addr(Rd),#n indexed (0x6B10-0x6BFF, NIB2=idx!=0) : MAME Z6B_ddN0_imm4m1_addr.
rtl/cpu/z8002/z8002.sv:2699 ==== BATCH 4: register-only bonus opcodes ================================== ---- NEG rd (0x8Dd2, NIB0=2) : MAME Z8D_dddd_0010, flags CZSV--.
rtl/cpu/z8002/z8002.sv:2712 ---- COM rd (0x8Dd0, NIB0=0) : MAME Z8D_dddd_0000, flags -ZS---.
rtl/cpu/z8002/z8002.sv:2720 ---- EXTSB rd (0xB1d0, NIB0=0) : MAME ZB1_dddd_0000 "extsb rd", flags ------.
rtl/cpu/z8002/z8002.sv:2729 ==== BATCH 8: DAB rbd (0xB0d0, NIB0=0) : MAME ZB0_dddd_0000 "dab rbd", flags CZS---.
rtl/cpu/z8002/z8002.sv:2733 idx into dab_rom = {DA,H,C,byte-value} per z8000dab.h's own header comment; CZS recomputed from the RESULT byte (CLR_CZS+CHK_XXXB_ZS: Z=(result==0), S=result[7]; H is left UNCHANGED -- MAME's DAB never touches F_H, matching CLR_CZS's mask e
rtl/cpu/z8002/z8002.sv:2745 ---- EXTS rrd (0xB1dA, NIB0=A) : MAME ZB1_dddd_1010 "exts rrd", flags ------.
rtl/cpu/z8002/z8002.sv:2754 ---- RESB @Rd,#imm4 (0x2210-0x22FF, NIB2=dst!=0) : MAME Z22_ddN0_imm4 "resb @rd,imm4", flags ------.
rtl/cpu/z8002/z8002.sv:2762 ---- SETB @Rd,#imm4 (0x2410-0x24FF, NIB2=dst!=0) : MAME Z24_ddN0_imm4 "setb @rd,imm4", flags ------.
rtl/cpu/z8002/z8002.sv:2769 ---- EXB rbd,@rs (0x2C10-0x2CFF, NIB2=src!=0) : MAME Z2C_ssN0_dddd "exb rbd,@rs", flags ------.
rtl/cpu/z8002/z8002.sv:2776 ---- EXB rbd,rbs (0xAC, full range) : MAME ZAC_ssss_dddd "exb rbd,rbs", flags ------.
rtl/cpu/z8002/z8002.sv:2785 ---- ADCB rd,rs (0xB4, full range) : MAME ZB4_ssss_dddd, flags CZSVDH (DA cleared -- CLR_DA in the macro body, like ADDB).
rtl/cpu/z8002/z8002.sv:2801 ---- ADC rd,rs (0xB5, full range) : MAME ZB5_ssss_dddd, flags CZSV-- (no H/DA, matches ADDW).
rtl/cpu/z8002/z8002.sv:2813 ---- SBCB rd,rs (0xB6, full range) : MAME ZB6_ssss_dddd, flags CZSVDH (DA SET unconditionally -- SET_DA in the macro body, like SUBB).
rtl/cpu/z8002/z8002.sv:2828 ---- SBC rd,rs (0xB7, full range) : MAME ZB7_ssss_dddd, flags CZSV-- (no H/DA, matches SUBW).
rtl/cpu/z8002/z8002.sv:2844 ---- RESB addr[,(rd)],#imm4 (0x6200-0x62FF) : MAME Z62_0000_imm4_addr / Z62_ddN0_imm4_addr, byte RMW, flags ------.
rtl/cpu/z8002/z8002.sv:2854 ---- RES addr[,(rd)],#imm4 (0x6300-0x63FF) : MAME Z63_0000_imm4_addr / Z63_ddN0_imm4_addr, word RMW, flags ------.
rtl/cpu/z8002/z8002.sv:2863 ---- SETB addr[,(rd)],#imm4 (0x6400-0x64FF) : MAME Z64_0000_imm4_addr / Z64_ddN0_imm4_addr, byte RMW, flags ------.
rtl/cpu/z8002/z8002.sv:2872 ---- SET addr[,(rd)],#imm4 (0x6500-0x65FF) : MAME Z65_0000_imm4_addr / Z65_ddN0_imm4_addr, word RMW, flags ------.
rtl/cpu/z8002/z8002.sv:2881 ---- BITB addr[,(rd)],#imm4 (0x6600-0x66FF) : MAME Z66_0000_imm4_addr / Z66_ddN0_imm4_addr, read-only byte, flags -Z----.
rtl/cpu/z8002/z8002.sv:2890 ---- BIT addr[,(rd)],#imm4 (0x6700-0x67FF) : MAME Z67_0000_imm4_addr / Z67_ddN0_imm4_addr, read-only word, flags -Z----.
rtl/cpu/z8002/z8002.sv:2899 ---- EXB rbd,addr[(rs)] (0x6C00-0x6CFF) : MAME Z6C_0000_dddd_addr / Z6C_ssN0_dddd_addr, byte RMW exchange, flags ------.
rtl/cpu/z8002/z8002.sv:2910 ---- EX rd,addr[(rs)] (0x6D00-0x6DFF) : MAME Z6D_0000_dddd_addr / Z6D_ssN0_dddd_addr, word exchange, flags ------.
rtl/cpu/z8002/z8002.sv:2919 ---- EX rd,rs reg-reg (0xAD, full range) : MAME ZAD_ssss_dddd "ex rd,rs", flags ------.
rtl/cpu/z8002/z8002.sv:2929 z8000tbl.hxx's table range for this whole family starts at NIB2=1 (0x0c10/0x0d10, NOT 0x0c00/ 0x0d00) -- dst=R0 is UNDEFINED here (falls to illegal on real MAME), so every arm below is gated din[7:4]!=0, matching the file's existing convent
rtl/cpu/z8002/z8002.sv:2944 COMB @rd (0x0C_x_0, NIB3=0000) : MAME Z0C_ddN0_0000 body reads GET_DST(OP0,NIB3) instead of NIB2 like EVERY sibling (NEGB/TESTB/TSETB/ CLRB/LDB/CPB all correctly use NIB2) -- since NIB3 is the FIXED sub-op selector here (always 0000 for thi
rtl/cpu/z8002/z8002.sv:2956 NEGB @rd (0x0C_x_2, NIB3=0010) : MAME Z0C_ddN0_0010, flags CZSV--.
rtl/cpu/z8002/z8002.sv:2960 CPB @rd,imm8 (0x0C_x_1, NIB3=0001) : MAME Z0C_ddN0_0001_imm8, flags CZSV--.
rtl/cpu/z8002/z8002.sv:2964 LDB @rd,imm8 (0x0C_x_5, NIB3=0101) : MAME Z0C_ddN0_0101_imm8, flags ------.
rtl/cpu/z8002/z8002.sv:2968 ---- TESTB @rd (0x0C10-0x0CF0, NIB3=4) : MAME Z0C_ddN0_0100 "testb @rd", read-only, flags -ZSP-- (same formula as the register-direct TESTB rbd, 0x8Cd4).
rtl/cpu/z8002/z8002.sv:2974 ---- TSETB @rd (0x0C16-0x0CF6, NIB3=6) : MAME Z0C_ddN0_0110 "tsetb @rd", byte RMW (wordacc rule), flags --S---.
rtl/cpu/z8002/z8002.sv:2980 ---- CLRB @rd (0x0C18-0x0CF8, NIB3=8) : MAME Z0C_ddN0_1000 "clrb @rd", byte RMW (wordacc rule, unconditional 0), flags ------.
rtl/cpu/z8002/z8002.sv:2985 ---- COM @rd (0x0D10-0x0DF0, NIB3=0) : MAME Z0D_ddN0_0000 "com @rd", word RMW, flags -ZS--- (same formula as the register-direct COM rd, 0x8Dd0).
rtl/cpu/z8002/z8002.sv:2991 ---- CP @rd,#imm16 (0x0D11-0x0DF1, NIB3=1) : MAME Z0D_ddN0_0001_imm16 "cp @rd,imm16", read-only compare, flags CZSV-- (same formula as the existing word CP aluop in S_ALU).
rtl/cpu/z8002/z8002.sv:2997 ---- NEG @rd (0x0D12-0x0DF2, NIB3=2) : MAME Z0D_ddN0_0010 "neg @rd", word RMW, flags CZSV-- (same formula as the register-direct NEG rd, 0x8Dd2).
rtl/cpu/z8002/z8002.sv:3003 ---- TEST @rd (0x0D14-0x0DF4, NIB3=4) : MAME Z0D_ddN0_0100 "test @rd", read-only, flags -ZS--- (same formula as the existing DA_TST direct-address test).
rtl/cpu/z8002/z8002.sv:3009 ---- TSET @rd (0x0D16-0x0DF6, NIB3=6) : MAME Z0D_ddN0_0110 "tset @rd", word RMW, flags --S---.
rtl/cpu/z8002/z8002.sv:3015 ---- CLR @rd (0x0D18-0x0DF8, NIB3=8) : MAME Z0D_ddN0_1000 "clr @rd", plain word write (no read needed), flags ------.
rtl/cpu/z8002/z8002.sv:3044 ==== BATCH 6: CPL rrd,imm32 (0x1000-0x100F, task item 2) ================ MAME Z10_0000_dddd_imm32, compare-only long against a 32-bit immediate (imm32={word1(hi),word2(lo)}, same GET_IMM32 convention as the existing LDL RRd,#imm32).
rtl/cpu/z8002/z8002.sv:3097 ==== BATCH 6: register-only closures (zero new states) =================== ---- COMB rbd (0x8Cd0) : MAME Z8C_dddd_0000, flags -ZSP-- (CHK_XXXB_ZSP, same parity convention as the already-implemented byte AND/OR/XOR/TESTB -- verified against
rtl/cpu/z8002/z8002.sv:3109 ---- NEGB rbd (0x8Cd2) : MAME Z8C_dddd_0010, flags CZSV-- (same formula as the already-implemented word NEG rd, 0x8Dd2, one level narrower).
rtl/cpu/z8002/z8002.sv:3118 ---- TSETB rbd (0x8Cd6) : MAME Z8C_dddd_0110, flags --S--- (S=old bit7, unconditional 0xFF -- same formula as the already-implemented register- INDIRECT TSETB @rd, S_TSETBI_RD, one level more direct: no memory access at all).
rtl/cpu/z8002/z8002.sv:3128 ---- LDCTLB rbd,flags (0x8Cd1) : MAME Z8C_dddd_0001 "ldctlb rbd,flags" -- reads the CURRENT flag byte (FCW bits[7:2] = C/Z/S/V/D/H, exactly this file's MC/MZ/MS/MV/MDA/MH bit positions) into rbd.
rtl/cpu/z8002/z8002.sv:3137 ---- LDCTLB flags,rbd (0x8Cd9) : MAME Z8C_dddd_1001 "ldctlb flags,rbd" -- writes rbd's value into FCW bits[7:2], mirror of the read form above.
rtl/cpu/z8002/z8002.sv:3144 ---- NOP (0x8D07 EXACT) : MAME Z8D_0000_0111 "nop" -- single exact opcode (not a NIB-varying family like its 0x8D siblings), no effect.
rtl/cpu/z8002/z8002.sv:3149 ---- TEST rd (0x8Dd4) : MAME Z8D_dddd_0100 "test rd", flags -ZS--- (same TESTW formula as the existing direct-address TEST, DA_TST).
rtl/cpu/z8002/z8002.sv:3155 ---- TSET rd (0x8Dd6) : MAME Z8D_dddd_0110 "tset rd", flags --S--- (S=old bit15, unconditional 0xFFFF -- same formula as the already-implemented register-INDIRECT TSET @rd, S_TSETI_RD).
rtl/cpu/z8002/z8002.sv:3168 ---- SETFLG/RESFLG/COMFLG imm4 (0x8D_imm4_0001/0011/0101, NIB0=1/3/5) : MAME Z8D_imm4_0001/0011/0101 -- set/clear/toggle FCW bits[7:4] (C/Z/S/V) directly from the OPCODE WORD's own bits[7:4] (m_fcw|=/&=~/^= m_op[0]& 0x00f0), no register/mem
rtl/cpu/z8002/z8002.sv:3182 ---- TESTL rrd (0x9C00-0x9CF8, NIB3={0,8} only per z8000tbl.hxx's step=8 table row -- the handler body ignores NIB3 entirely, GET_DST uses NIB2) : MAME Z9C_dddd_1000 "testl rrd", flags -ZS--- (32-bit long test, register-only; pair-select =
rtl/cpu/z8002/z8002.sv:3193 ---- RESB/RES/SETB/SET/BITB/BIT rd,imm4 register-DIRECT forms (0xA2- 0xA7, full range each) : MAME ZA2-ZA7_dddd_imm4 -- register-only bit-ops (no memory access at all), distinct from the already-implemented memory-form @Rd,#imm4 family (0x2
rtl/cpu/z8002/z8002.sv:3229 ---- TCCB cc,rbd / TCC cc,rd (0xAE/0xAF, full range) : MAME ZAE/ZAF_ dddd_cccc "tccb/tcc cc,rbd/rd", flags ------ -- bit0 UNCONDITIONALLY replaced by cc_true(cc) (not OR'd -- MAME clears bit0 first, then conditionally sets it, net effect =
rtl/cpu/z8002/z8002.sv:3244 ---- LDK rd,imm4 (0xBD, full range) : MAME ZBD_dddd_imm4 "ldk rd,imm4", flags ------ -- zero-extended 4-bit immediate load, cheapest possible instruction (no memory access, no flags, single word).
rtl/cpu/z8002/z8002.sv:3251 ---- RLDB rba,rbb (0xBC, full range) : MAME ZBC_aaaa_bbbb "rldb rba,rbb" -- a=NIB2,b=NIB3 (both plain byte-reg-codes, NOT gated non-zero).
rtl/cpu/z8002/z8002.sv:3268 ---- RRDB rba,rbb (0xBE, full range) : MAME ZBE_aaaa_bbbb "rrdb rba,rbb" -- same term-by-term trace discipline as RLDB above.
rtl/cpu/z8002/z8002.sv:3284 ---- EXTSL rqd (0xB1d7, NIB0=7) : MAME ZB1_dddd_0111 "extsl rqd", flags ------ -- sign-extends the LOW 32 bits of the quad (R[qbase+2]: R[qbase+3]) into the HIGH 32 bits (R[qbase]:R[qbase+1]), one level wider than the already-implemented EX
rtl/cpu/z8002/z8002.sv:3295 ---- LDB rd,imm8 short form (0xC000-0xCFFF, full range) : MAME ZC_dddd_imm8 "ldb rbd,imm8" -- dst=NIB1(din[11:8], byte-reg-code), imm8=din[7:0] (the SAME opcode word's low byte -- single-word instruction, no second-word fetch at all).
rtl/cpu/z8002/z8002.sv:3523 V: left sets it on a sign change (MAME `if((result^dest)&S16)SET_V`); right NEVER sets it -- SRAW's actual body has no SET_V call at all despite the "flags CZSV--" doc-comment, verified against the macro body, not assumed from the mnemonic.
rtl/cpu/z8002/z8002.sv:3581 No memory access at all -- `addr` is a raw absolute 16-bit operand word (MAME GET_ADDR_RAW, no PC-relative resolution needed off-segment), NOT a pointer to dereference.
rtl/cpu/z8002/z8002.sv:3590 `pc` here already equals the address of the dsp16 word being read as `din` this cycle (decode set pc<=pc2 one cycle earlier) -- MAME's GET_DSP16 evaluates addr_add(m_pc, (int16_t)tmp16) AFTER get_operand(1) has advanced m_pc PAST that word,
rtl/cpu/z8002/z8002.sv:3724 MAME: if(--RW(cnt)){CLR_V; if(cc==0)m_pc-=4;} else SET_V;
rtl/cpu/z8002/z8002.sv:3964 Flags CZSV per MAME CPL()/CHK_SUBL_V.
rtl/cpu/z8002/z8002.sv:4064 ---- MULT rrd,{#imm16|@rs|rs}: dest16 = LOW word of RL(dst) (MAME truncates RL(dst) to uint16_t for MULTW's `dest` param); product overwrites the FULL RL(dst) pair.
rtl/cpu/z8002/z8002.sv:4066 V is NEVER set (verified in MULTW's body -- only CLR_CZSV runs, no SET_V despite the doc-comment saying CZSV--); C uses MAME's exact asymmetric bounds (< -32767 or >= 32767), not +-32768.
rtl/cpu/z8002/z8002.sv:4309 ---- SLLB/SRLB rbd,#imm8: byte version of the existing word S_SHIFT, imm8 = LOW byte of the fetched word (MAME GET_IMM8 truncates get_operand() to uint8_t).
rtl/custom/adc0804.sv:11 conversion_done(): m_result = m_vin_callback(); set_interrupt(true); (the analog input is sampled AT completion, NOT at the start-conversion write) read(offset): set_interrupt(false); return m_result; (RD_STROBED mode — the default; polepo
rtl/custom/adc0804.sv:20 Instantiation (src/mame/namco/polepos.cpp): ADC0804(config, m_adc, MASTER_CLOCK/8/8); MASTER_CLOCK=24.576MHz -> 384 kHz m_adc->vin_callback().set(FUNC(polepos_state::analog_r)); z80_io: map(0x00,0x00).rw(m_adc, read, write); IN A,($00)=r
rtl/custom/adc0804.sv:25 Channel select (LS259 q3, MAME polepos.h/.cpp — VERIFIED, an earlier comment elsewhere in this codebase had this backwards): m_analog_io(*this, {"BRAKE", "ACCEL"}) // index 0 = BRAKE, index 1 = ACCEL analog_r() { return m_analog_io[m_adc_
rtl/custom/adc0804.sv:34 Pedal range: MAME PORT_MINMAX(0, 0x90) — full scale is 0x90, NOT 0xFF.
rtl/custom/adc0804.sv:53 ---- 384 kHz tick generator: clk_sys/128 clock-enable --------------------- 49.152 MHz / 128 = 384 kHz = MAME's ADC0804(config, m_adc, MASTER_CLOCK/8/8) with MASTER_CLOCK = 24.576 MHz (= clk_sys/2).
rtl/custom/adc0804.sv:65 MAME adc0804.cpp s_conversion_cycles
rtl/custom/adc0804.sv:70 mirrors MAME's m_intr_active (1 = INTR asserted/active)
rtl/custom/adc0804.sv:82 conversion_start(): ignored while a conversion is already in progress (MAME: `if (!m_timer->enabled())`).
… 127 more

Says it matches, follows or was checked against MAME — 54

Arcade-PolePosition.sv:265 Powers up 0 = Lo (matches MAME's PORT_TOGGLE off state -> in0_byte bit1 reads 1, inactive on the active-low IN0).
Arcade-PolePosition.sv:382 status[2]=0 (default) -> watchdog ON, matching MAME; status[2]=1 -> OFF.
rtl/PolePosition_CPU.sv:7 Ground truth: MAME polepos.cpp z80_map / z80_io / machine_config (LS259 @8E).
rtl/PolePosition_CPU.sv:40 (verified: MAME polepos.h m_analog_io{"BRAKE","ACCEL"} indexed by gasel via analog_r()/gasel_w())
rtl/PolePosition_subcpu.sv:4 Ground truth: MAME polepos.cpp (z8002_map / z8002_map_1/2) + polepos_v.cpp (sprite_r/w, road_r/w, alpha_r/w, view_r/w — Z80 byte-lane handlers).
rtl/PolePosition_subcpu.sv:406 // Basis: pp_road_gen is bit-exact vs MAME draw_road() on the REAL road ROM // (32,768 px, 0 mismatches, verilator/road `make view`), so the renderer is // already exonerated in sim -- this confirms it on hardware.
rtl/PolePosition_subcpu.sv:416 // VALIDATED 2026-08-10 by verilator/road `make view`: these exact two values // render a correct road (green grass, grey surface, red/white rumble stripes // converging to a vanishing point) identical to the MAME draw_road oracle.
rtl/cpu/mb88_sv/mb88_core.sv:75 PC of the executing instruction (matches MAME)
rtl/cpu/mb88_sv/mb88_core.sv:221 executing instruction's own PC (matches MAME)
rtl/cpu/mb88_sv/mb88_core.sv:305 jmp within page (INCPC-then-override, matches MAME)
rtl/cpu/z8002/z8002.sv:35 PP ties vi_n inactive (matches MAME: subs take NVI ONLY, asserted at vblank scanline 240).
rtl/cpu/z8002/z8002.sv:50 Baked-in (verified vs MAME): BIG-ENDIAN (word@A={mem[A]hi,mem[A+1]lo}); PC even; SP=R15; 16x16 regfile, byte reg n -> R[n&7] HIGH if n<8 else LOW; FCW C=b7 Z=b6 S=b5 P/V=b4 DA=b3 H=b2 ; reset reads FCW@mem[2], PC@mem[4].
rtl/cpu/z8002/z8002.sv:97 DIV/DIVL use Verilog's native signed `/`/`%` (truncate-toward-zero, remainder takes the dividend's sign) which is algebraically IDENTICAL to MAME's manual abs/sign-restore dance in DIVW/DIVL -- verified term-by-term, not assumed.
rtl/cpu/z8002/z8002.sv:314 against exactly 0, NOT run through cc_true() -- matches MAME's literal `if (cc == 0) m_pc -= 4;`)
rtl/cpu/z8002/z8002.sv:627 ---- BATCH 18: LDPS real functional sequence (0x39 @rs / 0x79 addr[(rs)]) -- shared RDFCW/RDPC tail (fcw=mem[ea], pc=mem[ea+2], matches both MAME bodies exactly once `ea` is set correctly per sub-form: 0x39 sets it directly from a register,
rtl/cpu/z8002/z8002.sv:675 OUT direction (io_sub[1]==1) writes to a PORT, which (matching MAME's WRPORT_B replicate+byte-enable-mask, no RMW) just replicates the byte into both halves, same as the standalone S_OUTB_GO built in Batch 18.
rtl/cpu/z8002/z8002.sv:691 NVI push / IRET pop addresses: SP=R[15]; pushes pre-decrement (addr=R15-2, and R15 itself is updated -=2 on the same edge), pops read at current R15 then post-increment (matches MAME PUSHW/POPW exactly).
rtl/cpu/z8002/z8002.sv:1021 ---- BATCH 17: trap accept push order (PC, then OLD fcw, then the trapping opcode word) -- matches MAME's PUSH_PC()/PUSHW(SP,fcw)/ PUSHW(SP,m_op[0]) sequence exactly (see S_TRAP_* state comments).
rtl/cpu/z8002/z8002.sv:1027 ---- BATCH 18: OUTB/OUT -- matches MAME's WRPORT_B(value16=value| (value<<8)) / WRPORT_W(value) exactly: byte form replicates the byte into both halves (the address-derived lane/lane-mask on the other end of the bus picks the real one, same
rtl/cpu/z8002/z8002.sv:1091 Magnitude division + sign restore reproduces Verilog's signed `/`,`%` semantics exactly (truncate toward zero; remainder takes the DIVIDEND's sign) -- which the old code's header already established is algebraically identical to MAME's DIVW
rtl/cpu/z8002/z8002.sv:1444 Implemented CONSERVATIVELY matching MAME's LITERAL dispatch only (src fixed at reg-code 1, dst/idxr=1..E) rather than guessing the broader "any src, any dst" interpretation -- flagged in report for the user's call.
rtl/cpu/z8002/z8002.sv:1529 ==== BATCH 18: MSET/MRES/MBIT (0x7B08/09/0A, exact match) : MAME Z7B_0000_1000/1001/1010 -- CHECK_PRIVILEGED_INSTR gated (traps to VEC_TRAP unless fcw[14]/F_S_N set).
rtl/cpu/z8002/z8002.sv:1560 ==== BATCH 18: HALT (0x7A00, exact match) : MAME Z7A_0000_0000.
rtl/cpu/z8002/z8002.sv:1618 F_EPU (fcw bit13) is never set anywhere in this core (no Z8001 EPU exists on this board) UNLESS a real ROM explicitly writes it via LDCTL FCW,Rn (a plain whole-fcw overwrite, already implemented) -- so this reads the LIVE fcw bit, matching
rtl/cpu/z8002/z8002.sv:2274 bit = 1<<NIB3 (NIB3 8-15 => bmask[7:0]==0, byte test naturally always-false, matching MAME's own uint8_t&uint16_t promotion).
rtl/cpu/z8002/z8002.sv:3304 All are UNREACHABLE by the Pole Position sub ROMs (co-sim runs both to completion, 0 illegal): 0x30-0x37 load-relative / base+displacement (LDR/LDRB/LDRL, LDB base+disp) 0x38-0x3F I/O + block I/O (IN/OUT/SIN/SOUT/INIR/OTIR...) - no I/O de
rtl/cpu/z8002/z8002.sv:3607 ---- Z34 direct: LDAR prd,dsp16 -- register-ONLY (no memory read of the target at all, matches MAME's addr_to_reg): single-cycle, computes the PC- relative address and writes it straight to R[dst].
rtl/cpu/z8002/z8002.sv:3643 BATCH 16 fix: when taken and jpx, add R[idxr] to the fetched addr (matches MAME's addr_add(addr,RW(dst)) BEFORE the cc test -- the addend is added whether or not cc is ultimately true, but since it's only ever CONSUMED on the taken path, co
rtl/cpu/z8002/z8002.sv:3647 Not-taken path is unaffected by indexing either way (matches MAME: the switch does nothing on !cc, leaving m_pc at its already-advanced-past-both-words value = our pc+2).
rtl/cpu/z8002/z8002.sv:3656 ---- BATCH 17: internal-trap accept sequence (EPU/TRAP/SYSCALL) -- push PC, push OLD fcw, push the trapping opcode word (`ir`, matches MAME's m_op[0]), then load new FCW/PC from PSAP+trap_vec/+trap_vec+2.
rtl/cpu/z8002/z8002.sv:3905 Read-then-write ordering (not read-both-then-write-both) matches MAME's own evaluation order for PUSHL(dst,RDIR_L(src)) since RDIR_L has no side effect on `src`, so any read/write region overlap resolves identically either way ----
rtl/cpu/z8002/z8002.sv:4082 Verilog signed `/`/`%` truncate toward zero with the remainder taking the dividend's sign -- algebraically IDENTICAL to MAME's manual abs/sign-restore dance in DIVW (verified term-by-term against z8000ops.hxx, see header).
rtl/custom/adc0804.sv:5 Ground truth: MAME src/devices/machine/adc0804.cpp/.h. adc0804_device::s_conversion_cycles = 74 (device clock ticks per conversion) write(offset,data): set_interrupt(false); conversion_start(); conversion_start(): only (re)starts the conv
rtl/custom/adc0804.sv:36 Fabric clock: clk_sys = CLK_49M = 49.152 MHz = 2x MASTER_CLOCK, so the 384 kHz ADC clock here = clk_sys / 128 (49.152MHz/128 = 384kHz, matching MAME's MASTER_CLOCK/8/8 exactly since MASTER_CLOCK = clk_sys/2).
rtl/custom/pp_road_gen.sv:230 XOFFS-BAR-DIAG-2026-08-10 ------------------------------------------------ The road renderer is PROVEN correct (bit-exact vs MAME draw_road on the real road ROM, verilator/road `make view`), and the ioctl ROM offsets are proven correct.
rtl/custom/pp_sprite_gen.sv:194 WHY NOT HERE YET: this engine is currently VERIFIED CORRECT against the MAME zoom_sprite/draw_sprites oracle (sprite co-sim: 0 / 57,344 px).
rtl/namco/namco_06xx.sv:4 Ground truth: MAME src/devices/machine/namco06.cpp (namco_06xx_device).
rtl/namco/namco_06xx.sv:7 Only chip0/chip1 are wired to real wrappers in this increment; chip2/chip3 read as 0xFF (matches MAME's devcb_read8 default) and have no write sink.
rtl/namco/namco_51xx.sv:4 Ground truth: MAME src/devices/machine/namco51.cpp (namco_51xx_device) + src/mame/namco/polepos.cpp machine_config (:887-893, :914-917).
rtl/namco/namco_51xx.sv:28 mb88_core's `o_out` register only models the MCU's own half of this; the external Z80-write half is modeled here as `mailbox`, which mirrors o_out whenever the MCU changes it, but a CPU write (wr_en) takes priority and temporarily overrides
rtl/namco/namco_51xx.sv:78 Now driven by mb88's real o_wr strobe, matching MAME exactly.
rtl/namco/namco_51xx.sv:99 Z80 write wins (matches MAME order)
rtl/namco/namco_52xx.sv:24 reset = LS259 q1 (namco_reset, shared with 51/53/54xx) chip_sel = 06xx chipsel[2] -> IRQ Like 54xx: namco52.cpp has NO read() method and polepos.cpp binds no read_callback<2> -- the Z80 never reads this chip back through 06xx, so (a) no
rtl/namco/namco_53xx.sv:4 Ground truth: MAME src/devices/machine/namco53.cpp (namco_53xx_device) + src/mame/namco/polepos.cpp machine_config (:901-906, :918-919) + the polepos_state steering helpers (polepos.cpp :362-389, steering_changed_r / steering_delta_r — thes
rtl/namco/namco_54xx.sv:10 polepos machine_config port wiring (namco54.cpp): K3:0 = command[7:4] (K_r() = m_latched_cmd >> 4) R0 = command[3:0] (R0_r() = m_latched_cmd & 0x0f) O-port = discrete circuit inputs NAMCO_54XX_0_DATA (ol, O0-O3) / NAMCO_54XX_1
rtl/namco/namco_wsg8.sv:5 Ground truth: MAME src/devices/sound/namco.cpp (namco_device::polepos_sound_r/w + namco_audio_device::{device_clock_changed,build_decoded_waveform, namco_update_one,sound_stream_update}).
rtl/namco/namco_wsg8.sv:42 volume[0] = (soundregs[base+3]>>4 + soundregs[base+0x23]>>4) / 2 volume[1] = (soundregs[base+3]&0xf + soundregs[base+2]>>4) / 2 (all other byte offsets in 0x00-0x3F are dead register-file bytes on real hardware: stored, but polepos_sound_w'
rtl/namco/namco_wsg8.sv:67 Running our own accumulator once per REAL 48kHz tick instead (matching the actual namco clock) and shifting the read window down by the same factor (17-2=15) yields IDENTICAL pitch: MAME: Hz = freq * 192000 / 2^22 (fracbits=17, +5-bit fi
rtl/namco/namco_wsg8.sv:100 - channels 0/1 are expected to read as silent/near-silent in normal play (their ch*4+0x23 ext-select bit routes them to 54xx/52xx instead, which are NOT built this pass) — that matches MAME's own comment, not a bug.
rtl/poleposition.vhd:578 Feeds ONLY u_pp_cpu (Z80 + both Z8002s), matching MAME's watchdog_fired()->schedule_soft_reset().
rtl/poleposition.vhd:619 The CPU divider WAS re-derived for the new clock (cen = clk/16 = 3.072 MHz, matching MAME's Z80 MASTER_CLOCK/8), which is why boot speed matches MAME while everything downstream of the first EI breaks.
rtl/poleposition.vhd:947 52xx and 54xx (both built 2026-07-28) legitimately have NO read_callback<2>/<3> bound in polepos.cpp -- namco52.cpp/namco54.cpp have no read() method at all -- so chip2_din/chip3_din staying tied to this 0xFF stub is CORRECT and permanent,
rtl/video/pp_palette_alpha.sv:19 128V banks 0x020+/0x060+ are physically IDENTICAL colours on real HW (MAME comment polepos_v.cpp:42-51) — we still implement the bank select for faithfulness; it is visually irrelevant, so first-light works with either.
rtl/video/pp_tile_decode.sv:4 Covers BOTH tilemap layers — alpha ("chars") and view ("tiles") — because they use the IDENTICAL MAME charlayout_2bpp (polepos.cpp:862-864).

Says it was translated, ported or taken from MAME — 10

rtl/cpu/z8002/z8002.sv:256 ==== BATCH 8: DAB (0xB0) result ROM, ported verbatim from MAME's Useful Stuff/mame/z8000/z8000dab.h (2048 x 9-bit, mechanically extracted -- NOT hand-transcribed -- and spot-checked against the source header: idx[8..0]=0 ->9'h008, idx=9->9'
rtl/cpu/z8002/z8002.sv:1537 True no-ops when privileged -- this is not a corner cut, it's what MAME's real C body does verbatim once past the privilege gate.
rtl/custom/adc0804.sv:2 adc0804.sv — ADC0804 8-bit A/D converter (Pole Position accelerator/brake pedal input), faithful port of MAME's device model.
rtl/custom/pp_ic25.sv:4 Based on MAME namco/polepos.cpp, polepos2_ic25_r() by the MAME team.
rtl/custom/pp_road_gen.sv:4 Faithful RTL port of MAME draw_road() (polepos_v.cpp:304-373).
rtl/custom/pp_sprite_gen.sv:4 Faithful RTL port of MAME draw_sprites()/zoom_sprite() (polepos_v.cpp :375-448).
rtl/video/pp_palette_alpha.sv:4 Ports MAME's polepos_palette() index arithmetic verbatim (polepos_v.cpp :30-135) for the alpha layer, per the audit's recommendation (avoid reverse-engineering the real PROM address-pin order).
rtl/video/pp_palette_road.sv:4 Ports MAME's polepos_palette() index arithmetic verbatim for the road layer (polepos_v.cpp:123-126), the sibling of pp_palette_view but with a 10-bit index (the road pen is (roadpal<<6)|roadval, not {color,pixel}):
rtl/video/pp_palette_sprite.sv:4 Ports MAME's polepos_palette() sprite arithmetic verbatim (polepos_v.cpp :106-114).
rtl/video/pp_palette_view.sv:4 Ports MAME's polepos_palette() index arithmetic verbatim for the bg/view layer (polepos_v.cpp:94-103), the sibling of pp_palette_alpha:

Keeps a MAME approximation — 1

rtl/cpu/z8002/z8002.sv:2949 Implemented with NIB2 instead, matching every sibling and the already-fixed Z4C_0000_0000_addr COMB precedent (same MAME-source-typo category) -- flagged in report, not silently guessed past.

Shares text with the MAME driver without saying so — 13

Arcade-PolePosition.sv:59 0 1 2 3 4 5 6 — shares text with namco/polepos.cpp:2311
rtl/PolePosition_CPU.sv:237 MAME ground truth: polepos.cpp:927 NVRAM(config, "nvram", nvram_device::DEFAULT_ALL_1) — shares text with namco/polepos.cpp:927
rtl/custom/pp_watchdog.sv:5 WATCHDOG_TIMER(config, "watchdog").set_vblank_count(m_screen, 16); — shares text with namco/polepos.cpp:925
rtl/custom/pp_watchdog.sv:7 map(0xa100, 0xa100).mirror(0x0cff).w("watchdog", FUNC(watchdog_timer_device::reset_w)); — shares text with namco/polepos.cpp:451
rtl/namco/namco_06xx.sv:38 simplification of MAME's attotime-based "delay to the next falling clock — shares text with namco/namco06.cpp:219
rtl/namco/namco_51xx.sv:62 MAME: m_screen->screen_vblank().set("51xx", vblank); vblank(state) drives — shares text with namco/polepos.cpp:953
rtl/namco/namco_52xx.sv:14 SI = constant 1 (namco_52xx_si_r(): "pulled to +5V") — shares text with namco/polepos.cpp:350
rtl/namco/namco_53xx.sv:14 k_port_callback = namco_53xx_k_r, HARDWIRED TO 0 in polepos.cpp (comment: — shares text with namco/polepos.cpp:356
rtl/namco/namco_wsg8.sv:18 NAMCO(config, m_namco_sound, MASTER_CLOCK/512) MASTER_CLOCK=24.576MHz — shares text with namco/polepos.cpp:964
rtl/namco/namco_wsg8.sv:21 m_latch->q_out_cb<2>().set(m_namco_sound, FUNC(namco_device::sound_enable_w)); — shares text with namco/polepos.cpp:937
rtl/poleposition.vhd:611 set_raw(MASTER_CLOCK/4, 384, 0, 256, 264, ...) with MASTER_CLOCK=24.576 MHz), — shares text with namco/polepos.cpp:950
rtl/video/pp_tile_decode.sv:54 MAME: code = (word & 0xff) | ((word & 0x4000) >> 6) = {word[14],word[7:0]} — shares text with namco/polepos_v.cpp:148
rtl/video/pp_tile_decode.sv:72 planeoffset{0,4}, xoffset{0,1,2,3, 8*8+0..3}, MSB-first bit addressing — shares text with namco/polepos.cpp:826

PolyPlay#
Poly-Play, Poly-Play
MiSTer-devel/Arcade-PolyPlay_MiSTer @ 800350bd
MAME compared: ddr/polyplay.cpp + 3 related file(s)
Read: 14 HDL files, 2,320 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 2 toward MAME

Cites MAME source — 2

rtl/periph/ctc_channel.vhd:163 now behaves like mame???
README.md:5 All information taken from [mame/polyplay.cpp](https://github.com/mamedev/mame/blob/master/src/mame/drivers/polyplay.cpp).

Pong#
Pong
MiSTer-devel/Arcade-Pong_MiSTer @ 3f7413bb
MAME compared: atari/pong.cpp + 8 related file(s)
Read: 45 HDL files, 3,116 lines (Quartus project)

MiSTer official

Mostly hardware

low

39%

Statements: 20 toward hardware

Cites hardware documentation that MAME's driver does not — 20

rtl/ls00.v:26 74LS00
rtl/ls02.v:26 74LS02
rtl/ls04.v:26 74LS04
rtl/ls10.v:26 74LS10
rtl/ls107.v:26 74LS107
rtl/ls153.v:26 74LS153
rtl/ls20.v:26 74LS20
rtl/ls25.v:26 74LS25
rtl/ls27.v:26 74LS27
rtl/ls30.v:26 74LS30
rtl/ls48.v:26 74LS48
rtl/ls50.v:26 74LS50
rtl/ls74.v:26 74LS74
rtl/ls83.v:26 74LS83
rtl/ls86.v:26 74LS86
rtl/ls90.v:26 74LS90
rtl/ls93.v:26 74LS93
rtl/pong.v:26 Arcade: Atari Pong (1972) A Verilog implementation based on the original schematics.
README.txt:3 ** A Verilog implementation based on the original schematics.
README.txt:39 A: This implementation is based on the original Atari schematics.

Pooyan#
Pooyan
MiSTer-devel/Arcade-Pooyan_MiSTer @ 858c6fb2
MAME compared: konami/pooyan.cpp + 1 related file(s)
Read: 10 HDL files, 2,711 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

54%

Statements: 3 toward MAME

Cites MAME source — 3

rtl/YM2149_linmix_sep.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA
rtl/pooyan.vhd:35 Use with MAME roms from pooyan.zip
rtl/pooyan.vhd:319 cpu input address decoding (mirror mostly from Mame)

Popeye#
Popeye, Sky Skipper
MiSTer-devel/Arcade-Popeye_MiSTer @ 9226c11b
MAME compared: nintendo/popeye.cpp + 4 related file(s)
Read: 5 HDL files, 2,645 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

79%

Statements: 1 toward hardware, 4 toward MAME, 4 not counted

Cites hardware documentation that MAME's driver does not — 1

rtl/popeye.vhd:51 Popeye Hardware caracteristics from schematics TPP2:

Cites hardware references or measurements that MAME's driver also gives — 4

rtl/popeye.vhd:1279 char graphics ROM 5N ch_graphics : entity work.popeye_ch_bits port map( clk => clock_vidn, addr => ch_code_line, data => ch_graphx_do — also in MAME: 5N nintendo/popeye.cpp:655
rtl/popeye.vhd:1301 sprite graphics ROM 1E sprite_graphics1 : entity work.popeye_sp_bits_1 port map( clk => clock_vidn, addr => sp_code_line, data => sp_graphx1_do — also in MAME: 1E nintendo/nl_popeye.cpp:44
rtl/popeye.vhd:1326 sprite graphics ROM 1F sprite_graphics2 : entity work.popeye_sp_bits_2 port map( clk => clock_vidn, addr => sp_code_line, data => sp_graphx2_do — also in MAME: 1F nintendo/popeye.cpp:660
rtl/popeye.vhd:1346 sprite graphics ROM 1J sprite_graphics3 : entity work.popeye_sp_bits_3 port map( clk => clock_vidn, addr => sp_code_line, data => sp_graphx3_do — also in MAME: 1J nintendo/popeye.cpp:661

Cites MAME source — 3

rtl/popeye.vhd:15 release rev 01 : added protection algorithm (straight forward from MAME) (01/01/2020) : tested ok for Popeye rev D level 1 at least...
rtl/popeye.vhd:45 Use with MAME roms from popeye.zip & popeyeu.zip
rtl/ym_2149_linmix.vhd:44 Clues from MAME sound driver and Kazuhiro TSUJIKAWA

Says it was translated, ported or taken from MAME — 1

rtl/popeye.vhd:321 Protection device (7K/7J): Algorithm is taken from MAME source code and seems to be ok for Popeye and Sky skipper.

PrimalRage#
Primal Rage, T-MEK
MiSTer-devel/Arcade-PrimalRage_MiSTer @ c3394c33
MAME compared: atari/atarigt.cpp + 8 related file(s)
Read: 17 HDL files, 9,688 lines (Quartus project)

MiSTer official

Mostly MAME

medium

93%

Statements: 1 toward hardware, 85 toward MAME

Cites hardware documentation that MAME's driver does not — 1

README.md:137 The sound board boot ROM of this prototype was never dumped; MAME uses the one from a later set (marked BAD_DUMP), and so does this core.

Cites MAME source — 71

Arcade-PrimalRage.sv:731 joystick_x bits: 0 right,1 left,2 down,3 up,4..7 buttons1-4,8 coin,9 start set_jan picks the primrage (1) or primrageo (0) button/start layout; see rtl/atarigt_inputs.sv for the MAME atarigt.cpp port mapping.
Arcade-PrimalRage.sv:1026 the game tells a cold boot from a watchdog reset by what it finds in work RAM, so zero it after the download like MAME does at power-up
rtl/atarigt_inputs.sv:69 T-MEK (MAME atarigt.cpp common INPUT_PORTS): one seat, P1/P2 buttons 1-2 are the right/left trigger and thumb on one pad; the service test shows no button 3, button4, start2 or P2 d-pad, so those stay released
rtl/atarigt_inputs.sv:78 One T-MEK board is one seat, so MAME P1/P2 are its right/left handles (service menu stick test): right = ch7/ch6 (AN3 X, AN2 Y), left = ch3/ch2 (AN1 X, AN4 Y); handle forward = low byte, so the right handle alone forward turns left
rtl/atarigt_video.sv:2 Reference: MAME atarigt_v.cpp (get_playfield_tile_info, get_alpha_tile_info, playfield_scan, scanline_update, screen_update Primal Rage branch) and MAME atarigt.cpp (pflayout, pftoplayout).
rtl/atarigt_video.sv:206 colorram_r in MAME returns whatever was last written at ANY word in 0x20000-0x27fff/0x30000-0x37fff, not just the 128 entries the mixer cares about.
rtl/c31/c31_core.sv:2 Semantics follow MAME's 320c3x_ops.ipp instruction by instruction, not real silicon.
rtl/c31/c31_core.sv:98 mod19 (bit-reversed) and 0x1A-0x1F: MAME's handlers just log and return address 0 with no AR side effect, and the access still happens, so match that rather than aborting the instruction
rtl/c31/c31_core.sv:173 float helpers, matching 320c3x_ops.ipp bit for bit
rtl/c31/c31_core.sv:266 AND/ANDN/NOT/OR/RPTS/TSTB/XOR take a zero-extended imm16 (MAME uint16_t), the rest sign-extend
rtl/c31/c31_core.sv:2100 MAME zeroes dst in this branch but then overwrites it on the way out with the locals it never touched, so src passes through
rtl/cage.sv:351 dsp_re/dsp_we come from the C31's own 0xA00000 window, decoded in cage_mem (MAME cage.cpp 0xA00000 rw)
rtl/cage.sv:363 latch bit21 (MAME reset_w) stays unwired: Primal Rage drops it only once at boot, while control_reg still holds the DSP in reset
rtl/cage_host.sv:1 CAGE host interface: the 68020 side registers at C00000, MAME atarigt.cpp sound_data_r/sound_data_w, and the DSP side of the handshake, MAME cage.cpp main_r/main_w/control_r/control_w/cage_from_main_r/cage_to_main_w.
rtl/cage_host.sv:26 C31 interrupt lines, active-low (int_n convention): int0_n is the host command-ready IRQ0 (MAME cage.cpp cage_deferred_w/ cage_from_main_r), int1_n mirrors TMS320C3X_IRQ1, asserted whenever (control & 3) == 0 (MAME cage.cpp control_w).
rtl/cage_host.sv:29 Both are levels, unlike cage_periph's TINT/DINT pulses, because MAME explicitly asserts and clears these two rather than only ever asserting them.
rtl/cage_host.sv:34 IOF bits this device drives: bit3 = cpu_to_cage_ready, bit7 = cage_to_cpu_ready (MAME cage.cpp update_control_lines: val &= ~0x88).
rtl/cage_host.sv:39 held while the DSP must stay in reset: control bits 0/1 both 0, or ext_reset (the 0xE08000 latch bit21 path, MAME atarigt.cpp reset_w)
rtl/cage_mem.sv:3 Address map: MAME cage.cpp.
rtl/cage_mem.sv:45 CAGE host latch, word address 0xA00000 (MAME cage.cpp cage_from_main_r/ cage_to_main_w): re/we are one-clock pulses, exactly one per access even if req is held
rtl/cage_mem.sv:80 Only the populated part of the 0xC00000-0xFFFFFF sound ROM bank (MAME cage.cpp: "the DSP sees the pair at 0xD00000-0xDFFFFF ...
rtl/cage_mem.sv:142 MAME cage set_mcbl_mode: the C31 boot ROM overlays 0x000000-0x000FFF and trap n loads its vector from word n there, which holds 0x809FC0+n
rtl/cage_mem.sv:145 sound ROM and boot ROM are read-only (MAME cage.cpp 3.1): a write to either is simply dropped rather than allocating/dirtying a line
rtl/cage_mem.sv:495 boot ROM direct path: uncached, byte-wide (MAME cage.cpp 3.1: one file byte per DSP word, stored packed as 512KB in DDR3)
rtl/cage_periph.sv:2 Register map, timer/serial/DMA timing: MAME cage.cpp tms320c31_io_r/w, update_timer, update_serial, update_dma_state.
rtl/cage_periph.sv:3 Register offsets below are the DSP's own word address within the block (periph_addr), identical to the offs_t values cage.cpp indexes m_tms320c31_io_regs with.
rtl/cage_periph.sv:6 The 0x808064 primary bus control mask (0x1FFE) and reset value (0x10F8) are not in cage.cpp (MAME never touches that register); they come from an observed hardware trace.
rtl/cage_periph.sv:12 held while the DSP is in reset (control bits 0/1 both 0, cage_host's dsp_hold_reset): mirrors MAME cage.cpp control_w, which zeroes offsets 0x00-0x5F of the peripheral array on this condition.
rtl/cage_periph.sv:28 xint/rint are not modeled, MAME cage.cpp never asserts them for CAGE.
rtl/cage_periph.sv:43 audio out, MAME cage.cpp 3.3 and atarigt.cpp atarigt_stereo routing (channels 0/3 -> right, 1/2 -> left)
rtl/cage_periph.sv:75 register offsets, MAME cage.cpp macros
rtl/cage_periph.sv:86 generic storage: every offset 0x00-0xFF is a plain read/write register, MAME cage.cpp COMBINE_DATA into m_tms320c31_io_regs[0x100].
rtl/cage_periph.sv:108 timers: real down-counters clocked by h1_tick (MAME's own COUNTER register, offset 0x24/0x34, is write-through storage only -- see the generic regs[] array above; this is separate internal state driving the interrupt cadence MAME models, 2*
rtl/cage_periph.sv:160 serial word clock chain, MAME cage.cpp update_serial: h1_tick -> /2 or /4 serial clock -> /SPORT_TIMER_PERIOD bit clock -> /bits_per_word word clock.
rtl/cage_periph.sv:162 The divider constants are latched from the register file one clock after a write to SPORT_GLOBAL_CTL/SPORT_TIMER_PERIOD, and only when the candidate rate is valid (TPER!=0, derived freq <100kHz) -- MAME cage.cpp update_serial's own dmadac g
rtl/cage_periph.sv:186 Rejecting it needs sp_ctl_reg != 0 at candidate time (below) -- an earlier attempt at this fixed the audio rate but broke the host<->DSP handshake, traced to the DINT timer stop rule using live register bits instead of MAME's internal dma_e
rtl/cage_periph.sv:317 H1_HZ/88200 = 192 exactly, and h1_ticks_per_word = serial_div * tper * bits_per_word by construction of the divider chain above, so comparing that count to 192 reproduces MAME's frequency check without any real division.
rtl/cage_periph.sv:334 DMA, MAME cage.cpp update_dma_state/dma_timer_callback (258-331).
rtl/cage_periph.sv:342 MAME cage.cpp tracks enable with its OWN m_dma_enabled flag, separate from the register bits: dma_enabled_reg mirrors that.
rtl/cage_periph.sv:361 forward this cycle's write into the enable check, mirroring MAME's update_dma_state which runs after COMBINE_DATA already applied it
rtl/cage_periph.sv:394 clamp derived from MAME's mixer formula (atarigt.cpp atarigt_stereo: add_route(0/3, "speaker", 1.0, right), add_route(1/2, "speaker", 1.0, left) -- two unity-gain routes summed per output, saturated to the 16-bit DAC range)
rtl/cage_periph.sv:423 MAME cage.cpp update_dma_state: runs only on a write to one of the four DMA regs, comparing enabled_new to the internal flag
rtl/cage_periph.sv:427 MAME cage.cpp update_dma_state starts every transfer at channel 0
rtl/cage_periph.sv:546 MAME cage.cpp control_w: memset(m_tms320c31_io_regs, 0, 0x60*4); 0x64 and above are outside that range and left alone clear once on the edge: a held level is a 96-way loop every clock in sim
rtl/cage_periph.sv:557 MAME cage.cpp tms320c31_io_w, SPORT_DATA_TX case
rtl/cage_periph.sv:562 MAME cage.cpp dma_timer_callback: DMA_SOURCE_ADDR/ DMA_TRANSFER_COUNT only change at DINT, to the final address / 0 -- never incrementally, matching what the CPU can observe (the transfer already happened up front)
rtl/cage_periph.sv:577 MAME cage.cpp tms320c31_io_r assigns the array's uint32_t element into a uint16_t before returning it, truncating every read to 16 bits (zero-extended back to 32); that MAME quirk is reproduced here deliberately, on the read side only -- th
rtl/cpu_bus.sv:89 MAME adc0808.cpp: 1 + 64 ADC clocks to convert, EOC 1 clock later; ADC clock = 14.318181 MHz/16 = 894.9 kHz, 66 clocks = 73.8 us, clk_cpu = 42.955 MHz -> 3168 clk_cpu ticks (research notes, adc finding)
rtl/cpu_bus.sv:104 T-MEK: colour writes are dropped while set (MAME atarigt.cpp colorram_protection_w)
rtl/cpu_bus.sv:106 T-MEK ADC0809 model (MAME atarigt.cpp analog_port_r): adc_q is the shared result register; clk_cpu may get no reset edge before its first use, so eoc (SERVICE bit3) derives from adc_busy instead of its own register
rtl/cpu_bus.sv:150 bit 7 is the live VBLANK signal (atarigt.cpp SERVICE port), not a switch; bit 3 is A2D.EOC when tmek (MAME atarigt.cpp:472), else the switch as-is
rtl/cpu_bus.sv:299 control_r has no side effect in MAME cage.cpp, only main_r does
rtl/cpu_bus.sv:373 MAME latch_w: ACCESSING_BITS_24_31 (uds, MO control) and ACCESSING_BITS_16_23 (lds, cage/coin) are masked separately, so an lds-only write must not touch the MO control bits that live in the uds byte
rtl/rle_objects.sv:1 Reference: MAME atarirle.cpp, modesc masks in MAME atarigt.cpp.
rtl/rle_objects.sv:472 vblank frame-aligns the accumulator (mirrors MAME's m_partial_scanline reset at vblank); mogo consumes it.
rtl/rle_objects.sv:586 clear the checksum BRAM first (MAME memsets m_checksums before accumulating; real BRAM power-on content is likewise undefined)
rtl/rle_objects.sv:894 draw command: whole-buffer erase (simplification: MAME does a partial erase from the current scanline; a full clear is simpler and cheap enough here), then sort_and_render
rtl/xga_prot.sv:14 word addresses = byte offset (atarixga.cpp PR_*) >> 1
rtl/xga_prot.sv:26 T-MEK word addresses (MAME atarixga.cpp TM_* byte offsets in the D80000 window >> 1)
rtl/xga_prot.sv:79 bit permutation of the query index, transcribed from atarixga.cpp
rtl/xga_prot.sv:93 kmap[k]: number of LFSR clocks for key byte k, verbatim from atarixga.cpp
rtl/xga_prot.sv:250 a write in DECIPHER mode (re)arms the engine and aborts any run still in progress (MAME: last write wins); busy stays high up to about 6 us at clk_cpu = 42.955 MHz
rtl/xga_prot.sv:343 T-MEK: write16 returns to IDLE right on the triggering write (MAME atarixga.cpp:526-530), not deferred to the RESULT read; a later write here would otherwise be misread as a second query
rtl/xga_prot.sv:390 restart from the SETUP start state (eng_x0), not the raw ciphertext: when c==0 that start state is 1, and eng_c==0 is a fixed point of the LFSR (MAME atarixga.cpp:100)
README.md:46 | MAME description | Set | Zip files needed |
README.md:103 XGA protection chip modelled after MAME
README.md:118 The core uses the MAME sets listed under Sets, as of MAME 0.289.
README.md:128 Put the zip files for the sets you want (see Sets) into `/games/mame`.
README.md:137 The sound board boot ROM of this prototype was never dumped; MAME uses the one from a later set (marked BAD_DUMP), and so does this core.
README.md:153 The sound DSP runs in lockstep against MAME's TMS320C31 core: a million instructions of the real CAGE program plus random instruction stress.
README.md:183 FPGA core development: Nortido Hardware reference: MAME `atarigt.cpp` and `cage.cpp` (Aaron Giles and contributors), `atarixga.cpp` (Morten Shearman Kirkegaard,

Says it matches, follows or was checked against MAME — 11

rtl/c31/c31_core.sv:27 for bits where iof_in_mask is set, the IOF register reads iof_in instead of its stored bit (bits 3 and 7 are driven by the CAGE host interface, matching MAME's set_state_int(TMS320C3X_IOF)); writes to IOF always go to storage, masked bits a
rtl/cage_host.sv:79 dsp_re/dsp_we/host_re apply first, using this cycle's pre-update state; host_we (main_w) applies after, so a same-cycle "DSP reads the old command" + "host posts a new one" ends with the new command's ready flag set, matching MAME's machine
rtl/cage_periph.sv:14 0x64 (primary bus control) is outside that range and is left alone, matching MAME.
rtl/cage_periph.sv:24 interrupts to the (not yet built) C31 core: one clk_sys pulse per event, matching MAME's set_input_line() with no explicit clear for TINT0/TINT1/DINT0 -- the core's own IF register is a rising-edge latch, so a level-with-ack scheme here wou
rtl/cage_periph.sv:312 matches MAME cage.cpp SPORT_DATA_TX special case: MAME compares the *derived word rate* to 22050*4 Hz (int(m_serial_period_per_word.
rtl/cage_periph.sv:334 Two independent pieces, matching MAME's split between the (instant) bulk transfer and the deferred periodic timer:
rtl/cage_periph.sv:338 (1) DINT timer: a free-running word-tick countdown, period = the transfer count latched at the FIRST arm after the timer was stopped (MAME cage.cpp only calls timer.adjust() when !m_dma_timer_enabled; a re-arm that lands while the timer is
rtl/cage_periph.sv:507 playback: one word every word_tick, gated on the SPORT being configured (rate_valid) only -- the stream runs whether or not the DMA is on, repeating the stale/silent holding_reg when nothing is queued or the prefetch hasn't refilled yet, sa
rtl/rle_objects.sv:1022 width==0 or height==0 means prescan found an invalid data offset for this object (matches MAME bailing on info.data == nullptr in draw_rle, before it ever divides by scaled_width/height)
README.md:102 Full CAGE sound: TMS320C31 DSP written from scratch and checked against MAME
README.md:155 A Verilator simulation runs the game ROMs through attract mode and play, and the sound output is checked against MAME's CAGE model.

Shares text with the MAME driver without saying so — 3

rtl/cpu_bus.sv:132 T-MEK's palette write-enable colour word (xga_prot's TM_COLOR, word 0x18000 = byte DB0000) — shares text with atari/atarigt.cpp:359
rtl/xga_prot.sv:79 bit permutation of the query index, transcribed from atarixga.cpp — shares text with atari/atarixga.cpp:632
rtl/xga_prot.sv:165 spclords_key_offset(index): bitswap<12>(index*2, 12,11,10,9,6,3,5,4,1,7,2,8) ^ 0x0b3; — shares text with atari/atarixga.cpp:86

Psikyo#
Battle K-Road, Gunbird, Strikers 1945, Sengoku Ace …
MiSTer-devel/Arcade-Psikyo_MiSTer @ e2f717e1
MAME compared: psikyo/psikyo.cpp + 2 related file(s)
Read: 41 HDL files, 9,989 lines (Quartus project)

MiSTer official

Mostly MAME

high

64%

Statements: 4 toward hardware, 118 toward MAME

Says it was checked against the original PCB — 1

rtl/cpu/maincpu.sv:232 ---- 16 MHz CPU clock enable ---- The real SH201B/KA302C board clocks the 68EC020 at 32MHz/2 = 16 MHz (MAME psikyo.cpp sngkace(), "verified on pcb").

Says it was checked on “real hardware” — 1

Psikyo.sv:519 FM timers drive music tempo -- with the IRQ disabled samuraia plays no music at all (verified by ear on hardware).

Notes where it differs from MAME — 2

rtl/cpu/s1945_mcu.sv:3 The real chip is a PIC16C57, but MAME never executes it (`PIC16C57(...).set_disable()`); psikyo.cpp instead simulates the protection as ~9 bytes of state plus a command decoder (`s1945_mcu_*`), and this module is a direct translation of tha
rtl/psikyo_core.sv:1249 MAME's boot never executes any of the loop's addresses, so this is a fault path, not game logic.

Cites MAME source — 91

Psikyo.sv:29 Input port bit layout is taken from psikyo.cpp's INPUT_PORTS: sngkace has a separate COIN port, gunbird/btlkroad fold coin/service/z80-nmi into the P1_P2 low byte instead.
Psikyo.sv:70 Every Psikyo board is mono (psikyo.cpp routes both chips' ALL_OUTPUTS to a single "mono" speaker), but the OPL4's PCM channels are panned, so the OSD's Stereo Mix defaults to mono: status 0 Mono (AUDIO_MIX 3), 1 None (0), 2 25% (1), 3 50% (
Psikyo.sv:285 ce_pix: exact 1-in-12 divide of clk_sys down to 7.159091 MHz, matching psikyo_v.cpp's real 14.31818MHz/2 screen clock exactly (see pll_0002.v's header for why 85.909091/12 lands on this exactly, not approximately).
Psikyo.sv:326 bit 1: samuraia/samuraiak/sngkace/sngkacea's ADPCM-A ROM needs MAME's init_sngkace() bit 6/7 swap applied at download time -- gunbird/btlkroad do not, despite sharing the same sound hardware (mod_board bit 0 alone can't distinguish them: bt
Psikyo.sv:360 Confirmed against psikyo.cpp's sngkace_input_r()/INPUT_PORTS_START (docs/ROADMAP.md's own "Progress" cites the exact fetch), not assumed: P1P2 is a 32-bit port with P2 in bits 23:16 and P1 in bits 31:24 (each laid out UP,DOWN,RIGHT,LEFT,B1,
Psikyo.sv:371 The LOW half differs: sngkace leaves it unused and puts coin/service/z80-nmi in the separate COIN port at $C00008, while gunbird/btlkroad have no COIN port and fold those same bits into this port's low byte instead (psikyo.cpp INPUT_PORTS):
Psikyo.sv:377 Bits 15:8 are where Battle K-Road's buttons 4-6 live -- it is a 6-button fighter sharing gunbird's board and memory map, and MAME's btlkroad PORT_MODIFY("P1_P2") puts them in this port's HIGH byte (checked against psikyo.cpp, not assumed):
Psikyo.sv:429 MAME's psikyo DSW port (psikyo.cpp, PORT_START("DSW") /* c00004 -> c00007 */) puts every DIP in the UPPER half of that long and leaves the lower half unused: PORT_BIT( 0x0000ffff, IP_ACTIVE_LOW, IPT_UNUSED ) 0x00010000 Flip Screen 0x00
Psikyo.sv:483 Freeze the 68020 so a frame can be captured and compared against a MAME dump of the same moment.
Psikyo.sv:518 MAME wires ymsnd.irq_handler() to the audiocpu.
Psikyo.sv:529 MAME's memory map calls the sprites "buffered by two frames (list buffered + fb buffered)": the list buffer is spriteram_dbuf's snapshot, and this is the fb half.
Psikyo.sv:596 COIN port (sngkace-only): COIN1 = bit16, COIN2 = bit17, both IP_ACTIVE_LOW; bit23 is MAME's z80_nmi_r() (IP_ACTIVE_HIGH, not inverted) -- rtl/psikyo_top.sv's own nmi_pending output mirrors that exact status (see rtl/sound/sound_cpu_sngkace.
Psikyo.sv:605 In MAME the equivalent read returns 0 almost immediately (the poll loop exits after a handful of iterations), so a constant 0 is the MAME-matching behaviour and costs no waiting.
Psikyo.sv:609 vblank_wait_en (OSD bit 53) selects: 0 = constant 0 (MAME-like, default), 1 = ~vblank (the previous behaviour).
Psikyo.sv:619 which MAME executes too, but MAME's falls through to 00044A and then copies 0x800 longs from $fffee000 to $400000 -- a sprite-RAM DMA, which is exactly the thing you time to vertical blanking.
Psikyo.sv:624 Inferred from the code's behaviour and MAME's execution path rather than read out of psikyo.cpp's INPUT_PORTS (not available locally), so treat the exact bit position as verified-by-experiment, not by source.
rtl/cpu/maincpu.sv:57 Requesting level 4 (Psikyo's vblank IRQ, `irq4_line_hold` in MAME) means driving IPL=3'b011 (NOT 3'b100).
rtl/cpu/maincpu.sv:193 Gates the 16 MHz clock enable, so the 68020 simply stops stepping; video timing and the debug overlay keep running, which is what makes a frame comparable against a MAME dump.
rtl/cpu/maincpu.sv:232 ---- 16 MHz CPU clock enable ---- The real SH201B/KA302C board clocks the 68EC020 at 32MHz/2 = 16 MHz (MAME psikyo.cpp sngkace(), "verified on pcb").
rtl/cpu/maincpu.sv:311 psikyo.cpp maps 0xc00000-0xc0000b to the input reader for sngkace and gunbird alike -- three longs: P1_P2, DSW, COIN.
rtl/cpu/maincpu.sv:326 An exact compare only fires for a move.b addressed at 0xC00013 itself; a move.w to 0xC00012 or a move.l to 0xC00010 (whose second word beat is 0xC00012 with the command byte on the low lane -- byte-lane dispatch MAME's address map performs
rtl/cpu/maincpu.sv:410 ---- read mux (BRAM + input ports; ROM comes via rom_data) ---- SH404 overrides (each replaces only the bits MAME's s1945 handlers own -- docs/phase2_sh404.md "Bit polarity" for why every bit here is deliberate): - P1_P2 low word bit 2: the
rtl/cpu/maincpu.sv:521 SH404 MCU register writes, byte-lane addressed exactly like MAME's byte handlers: a word write to 0xC00006 hits data (UDS) and bctrl (LDS) in the same cycle, each from its own lane.
rtl/cpu/s1945_mcu.sv:13 The index is 8-bit into a zero-filled 256-byte array, exactly like MAME's `static const u8 table[256]` with 44 initializers -- unwritten entries read 0.
rtl/cpu/s1945_mcu.sv:39 MAME sets the latching bit AFTER returning the data ("the read consumes it").
rtl/cpu/s1945_mcu.sv:58 ---- state (reset values = MAME machine_start init) ----
rtl/cpu/s1945_mcu.sv:103 MAME: switch (data | (direction ?
rtl/cpu/s1945_mcu.sv:126 unhandled commands are ignored, as in MAME
rtl/memory/gfxrom_byte_reorder.sv:13 This module is the seam between two self-consistent but OPPOSITE byte-order conventions: sdram.sv's is ordinary ascending-address-ascending-bit-position, matching standard little-endian ROM/CPU word semantics (and correct as-is for rtl/memo
rtl/memory/gfxrom_byte_reorder.sv:20 Neither side is wrong on its own, so the reorder belongs here, not in sdram.sv (correct for general ROM access) or in tilemap_line_engine.sv/sprite_render_engine.sv (correct against MAME's real tile format, and independently unit-tested tha
rtl/memory/psikyo_sdram_top.sv:123 SH201B (samuraia/sngkace) has no separate delta-T ROM -- MAME's YM2610 serves the deltat channel from the adpcma image, so the caller keeps bit 20 low and the samuraia/sngkace bit 6/7 download swap covers B automatically.
rtl/memory/rom_loader.sv:76 Per BYTE, and only inside the 1MB ADPCM-A window -- a ROM-mastering artifact of the individual sample bytes (MAME's init_sngkace).
rtl/psikyo_core.sv:17 ---- Sprite pipeline per-frame sequencing (the one genuinely new piece of control logic this module adds, not just wiring) ---- Per-scanline sprites, sequenced to psikyo_v.cpp's screen_vblank(): at frame_start, sprite_line_list rebuilds its
rtl/psikyo_core.sv:121 Freeze the main CPU, so a frame can be captured and compared against a MAME dump of the same moment without the game advancing underneath it.
rtl/psikyo_core.sv:170 ---- Flip Screen DIP (SW2:1, DSW bit 16, active low) ---- Wired straight to the video hardware: psikyo_v.cpp's flip_screen_set is "hardwired to a DSW bit", and the games do not react to it themselves -- a MAME capture of every set with the
rtl/psikyo_core.sv:331 Indexing by {vcnt[3:0],hcnt[7:0]} puts all 4096 words of both layers into 32 scanlines, so one screenshot carries the complete tilemap RAM for comparison against a MAME dump.
rtl/psikyo_core.sv:367 Precise on the first try when the target address+value are already known (e.g. from a MAME investigation), and immune to any timing jitter in the boot sequence, because it fires on the semantic event itself rather than a fixed offset.
rtl/psikyo_core.sv:529 Reads the CPU-VISIBLE buffer (the one spriteram_dbuf's cpu_addr/cpu_rdata port serves, i.e. the SAME buffer MAME's own debugger/memory viewer shows -- not the render engine's snapshot copy) so a probed value is directly comparable to a MAME
rtl/psikyo_core.sv:728 BOARD_GUNBIRD selects gunbird/btlkroad, which are exactly the Phase 1 boards with MAME's m_ka302c_banking (s1945n is the third, Phase 2).
rtl/psikyo_core.sv:762 Ruled out as a MAME register-level offset: psikyo_v.cpp's video_start() calls tilemap_create with no set_scrolldx/set_scrolldy at all, and get_tile_info<Layer> applies m_vram[Layer] directly with no per-layer adjustment.
rtl/psikyo_core.sv:967 ---- sprite pipeline sequencing ---- MAME's screen_vblank() (psikyo_v.cpp) runs get_sprites() and THEN m_spriteram->copy().
rtl/psikyo_core.sv:969 Here: at frame_start, sprite_line_list rebuilds the compact per-line table FROM the snapshot (the get_sprites step), and build_done triggers the snapshot refresh (the copy step) -- the capture lands at the frame boundary, MAME's instant, an
rtl/psikyo_core.sv:1202 backdrop_black is MAME's m_palette->black_pen() screen-clear fallback (see compositor.sv): no palette entry can stand in for it here, so it rides alongside sprite_sel and forces black at this mux.
rtl/psikyo_core.sv:1206 A sprite still paints over it: MAME fills the bitmap first and draws sprites afterwards, and primask entry 0x00/0xFC/0xFE all leave bit 0 clear, so a sprite over bare backdrop wins.
rtl/psikyo_top.sv:92 Mirrors MAME's psikyo_state::z80_nmi_r() -- see rtl/sound/sound_cpu.sv's own comment for the full derivation.
rtl/psikyo_top.sv:335 ---- YM2610 (jt10) ---- 8 MHz on both boards: sngkace XTAL(32MHz)/4, gunbird 16MHz/2 (psikyo.cpp machine configs).
rtl/psikyo_top.sv:432 Address bit 20 selects the delta-T ROM: KA302C boards (gunbird/btlkroad/s1945n) have their OWN delta-T image (u64) at +0x100000 in the sample region, while SH201B (samuraia/sngkace) has none and MAME's YM2610 serves deltat from the adpcma i
rtl/video/compositor.sv:8 The screen-clear/backdrop rule follows MAME PR 16050, "psikyo.cpp: Fix background colour", which replaced screen_update()'s dead `layers_ctrl` branch (a local hardcoded to -1, so only its first arm ever ran and the clear always came from la
rtl/video/compositor.sv:64 MAME's screen clear falls back to m_palette->black_pen() when neither layer offers a clear colour.
rtl/video/compositor.sv:89 {0x00, 0xFC, 0xFE, 0xFF} -- table per the author of MAME's Psikyo renderer (published psikyo_v.cpp reads {0,fc,ff,ff}; fe for field 2 makes it visible over backdrop where ff never draws).
rtl/video/compositor.sv:93 The mask is BIT-INDEXED by the destination priority value, exactly MAME's pdrawgfx convention: the sprite pixel is BLOCKED when primask[priority_val] is set.
rtl/video/compositor.sv:134 ---- backdrop / screen clear ---- MAME PR 16050 replaced the old dead-code `layers_ctrl` chain with:
rtl/video/compositor.sv:170 Confirmed 2026-09-05 by the author of PR 16050, who also wrote MAME's Psikyo renderer: 0x400 is intentional, and this core follows MAME rather than the inference above.
rtl/video/sprite_display_list_walker.sv:54 It was tried -- scan for the terminator, then emit from the last entry down to 0, on the reading that psikyo_v.cpp's `while (...) { sprite_ptr--; }` puts entry 0 on top.
rtl/video/sprite_line_list.sv:31 Ordering contract with spriteram_dbuf: build_done is the "get_sprites() finished with the buffer" moment -- psikyo_core triggers the snapshot refresh from it, preserving psikyo_v.cpp's get_sprites()-then-copy() generation ordering with the
rtl/video/sprite_pos_transform.sv:1 Applies the position offset correction and zoom-factor transform that get_sprites() does between decoding the raw record and iterating sub-tiles (psikyo_v.cpp:235-239):
rtl/video/sprite_pos_transform.sv:17 flip_screen (the DIP-controlled screen flip, psikyo_v.cpp:241-247) is not handled here: the core renders the mirrored source line and reads the line buffer right to left instead (psikyo_core.sv's flip_screen), which flips sprites and tilema
rtl/video/sprite_record_decode.sv:1 Decodes one raw 8-byte spriteram attribute record (4 x 16-bit words) into its constituent fields, per get_sprites() (psikyo_v.cpp:185-235, BEFORE the zoom-transform/position-offset math those fields feed into -- see sprite_pos_transform for
rtl/video/sprite_record_fetch.sv:3 Record layout (docs/phase1_memory_map.md, psikyo_v.cpp:145-183): 4 consecutive 16-bit words per sprite, base word address = sprite_index*4, laid out Y/X/attr/code_lo -- matching sprite_record_decode's port names exactly so the two wire toge
rtl/video/sprite_subtile_step.sv:1 Computes one 16x16 sub-tile's screen position and LUT-index code, from the get_sprites() sub-tile loop (psikyo_v.cpp, verified against the actual current source rather than re-derived by hand):
rtl/video/sprite_zoom_lut.sv:1 Sprite zoom scaling lookup: raw 4-bit zoom field -> (dst_size, dx), the two quantities drawgfxzoom_core (src/emu/drawgfxt.ipp:738) needs to render one 16x16 source tile at the requested scale.
rtl/video/sprite_zoom_src_index.sv:1 Per-destination-column source pixel index for the nearest-neighbor zoom-blit accumulator (gfx_element::drawgfxzoom_core, drawgfxt.ipp:738-805), collapsed to a closed form -- see docs/phase1_video_engine.md, "The actual per-tile scaling algo
rtl/video/spriteram_dbuf.sv:1 Hardware-buffered sprite RAM (0x400000-0x401FFF), modelling MAME's buffered_spriteram32_device.
rtl/video/spriteram_dbuf.sv:20 psikyo_v.cpp's screen_vblank does get_sprites() and THEN m_spriteram->copy() -- it builds the display list from the buffer as it stands and only then refreshes that buffer, so the list a frame renders is one buffer-generation old.
rtl/video/spriteram_dbuf.sv:141 The global sprite ENABLE is deliberately LIVE (ctrl_shadow, the last CPU-written value), not the frame-latched copy -- per the author of MAME's Psikyo renderer: the bit takes effect immediately, so the caller gates the DISPLAY with it and s
rtl/video/spriteram_dbuf.sv:148 The transparent-pen selects stay latched with the copy: they parameterize the RENDER pass, which consumes that snapshot -- a live pen change would tear the pass already in flight, and MAME likewise reads its sprite control word from the buf
rtl/video/tile_cell_decode.sv:1 Decodes a raw 16-bit tilemap VRAM cell (named vram_cell -- "cell" is a reserved SystemVerilog keyword, part of the config/cell/liblist/use declaration syntax) into a gfx-ROM tile number and palette color-group index, per get_tile_info<Layer
rtl/video/tile_row_decode.sv:1 Decodes one 16-pixel row of a 16x16x4bpp "packed_msb" tile (MAME's gfx_16x16x4_packed_msb layout, used for both the "sprites" and "tiles" gfx regions -- gfx_psikyo in psikyo.cpp) into 16 4-bit pixel/palette-nibble values.
rtl/video/tile_row_decode.sv:17 - Each byte's HIGH nibble is the even (left) pixel, LOW nibble is the odd (right) pixel ("x order: hi nibble first" per generic.cpp).
rtl/video/tilemap_addrgen.sv:5 See docs/phase1_video_engine.md ("Tilemap addressing") for the derivation: MAME's tile_scan<Layer> (psikyo_v.cpp) looks like a bit-interleave, but its result is always masked to the low 12 bits by the caller, and every extra term in each ca
rtl/video/tilemap_line_engine.sv:198 One-PIXEL alignment bias, measured on real hardware against the MAME reference (reported by the author of MAME's Psikyo renderer): screen_x shows tilemap pixel (scroll + screen_x + 1), moving the image one pixel LEFT of the unbiased sum.
rtl/video/video_timing.sv:1 Raw video timing generator for the Phase 1 screen configuration -- verified directly from psikyo.cpp's machine config, not assumed: m_screen->set_raw(14.318181_MHz_XTAL/2, 456, 0, 320, 262, 0, 224); i.e. pixel clock ~7.159MHz, htotal=456 (a
rtl/video/video_timing.sv:8 MAME's set_raw() only specifies the blanking BOUNDARIES it needs for its own rasterizer -- it doesn't drive a real CRT, so it has no opinion on actual hsync/vsync PULSE width/position within those blanking windows.
rtl/video/video_timing.sv:35 frame_start fires on vblank's RISING edge (vcnt going 223->224) -- matches psikyo_v.cpp's own sprite-buffer swap trigger (screen_vblank(), psikyo_v.cpp:667-675, already noted in docs/phase1_memory_map.md), so this is the natural place for a
rtl/video/vreg_decode.sv:20 Board-specific tile gfx banking -- MAME psikyo_v.cpp's m_ka302c_banking.
rtl/video/vreg_decode.sv:24 1 (gunbird/btlkroad, and s1945n in Phase 2): LIVE banking, each layer's bank taken from its own layer-control bit 10 (psikyo_v.cpp:477, `(layer_ctrl[layer] & 0x400) >> 10`).
rtl/video/vreg_decode.sv:28 Fixed banks assigned once at video_start -- layer 0 = bank 0, layer 1 = bank 1 (psikyo_v.cpp:135-136, "sngkace / samuraia don't use banking" / "They share gfx2 to save memory on other boards").
rtl/video/vreg_decode.sv:90 SH404 banking (s1945/tengai, wins over ka302c_banking): the security MCU's bctrl register drives both banks, full 2-bit -- layer 0 from bctrl[5:4], layer 1 from bctrl[7:6] (psikyo.cpp s1945_mcu_bctrl_w: switch_bgbanks(1, data>>6&3); switch_
rtl/video/vreg_decode.sv:144 ENABLE IS ACTIVE LOW: psikyo_v.cpp does m_tilemap[layer]->enable(~layer_ctrl[layer] & 1); Reading it active-high held both layers off for every value the game writes, so the compositor painted backdrop on every pixel and only sprites appear
rtl/video/vreg_decode.sv:153 Bit 2 is "?" in psikyo_v.cpp's own bit table, but the screen-clear rewrite in MAME PR 16050 ("psikyo.cpp: Fix background colour") gives it a job: bits 3 and 2 are a symmetric pair of "this pen is NOT the transparent one" flags, and whicheve
rtl/video/vreg_decode.sv:164 Row-scroll is active when EITHER control bit is set -- psikyo_v.cpp gates on `layer_ctrl[layer] & 0x0300`, with bit 9 selecting per-tile granularity (`tile_rowscroll = (layer_ctrl & 0x0200) >> 7`, i.e. index >> 4) rather than acting as a se
README.md:31 Refs: https://buffis.com/research/input-lag-in-psikyo-games-in-mame/
README.md:122 Put the MAME merged, or split roms in games/mame
README.md:134 **SH404 audio: from-scratch YMF278B (OPL4) core** (`rtl/sound/opl4/`, built against MAME's ymfm reference - see `docs/phase2_ymf278b.md`): full bus protocol, ch
README.md:151 Some improvements to priorities and background clear over MAME (which has regressed over the years)
README.md:176 It's a platform I'm familiar with, as I collaborated with other members of the MAME team on the video system to add the later games circa ~2002, and the video s
README.md:191 This has NOT been verified against a PCB other than the timing measurements back in the day and recorded in the MAME source.
README.md:202 Development was heavily AI-assisted, combined with experience of the platform from the original MAME emulation that I assisted with many years ago.
README.md:202 It has been validated against MAME, and it's various hardware tests including timings, MAMETesters reports etc.
README.md:206 **Manual testing on a real DE10-nano** — every supported game is played and A/B-compared against MAME on real hardware before release; the debugging instrumenta
README.md:219 The **MAMEdev team** (especially Olivier Galibert, R. Belmont and Luca Elia as well as my own work) for [MAME](https://github.com/mamedev/mame)'s `psikyo.cpp`/

Says it matches, follows or was checked against MAME — 14

Psikyo.sv:449 dsw_in[15:8] genuinely is unused and reads as 1s, matching MAME's IP_ACTIVE_LOW default.
Psikyo.sv:525 See the coin_in comment: 0 = constant 0 (matches MAME), 1 = ~vblank.
rtl/cpu/maincpu.sv:17 Main CPU subsystem for the SH201B/KA302C boards (68EC020 @16MHz, psikyo.cpp:254-266 base map + per-board overlay, re-verified against current MAME source): TG68K.C + address decode + BRAM-region ports + sound-latch write + held-autovectored
rtl/cpu/maincpu.sv:534 Match MAME's irq4_line_hold: assert on the RISING edge, hold until acknowledged, and let the acknowledge win.
rtl/cpu/s1945_mcu.sv:17 table_absent (tengai) is not the same as an all-zero table: MAME's command 0x013 leaves latch1 UNCHANGED when the table pointer is null, rather than loading a zero.
rtl/memory/gfxrom_byte_reorder.sv:1 Reorders a 64-bit SDRAM read granule (native ascending-address -> ascending-bit-position packing, as produced by rtl/memory/sdram/ sdram.sv's burst-4 read capture -- see that module's own STATE_READ0..STATE_READ3 comments, and confirmed dir
rtl/memory/psikyo_sdram_top.sv:55 samuraia/samuraiak/sngkace/sngkacea ONLY (not gunbird/btlkroad, despite identical sound hardware) -- MAME's init_sngkace() applies out[7]=in[6], out[6]=in[7] to the whole ymsnd:adpcma ROM region, a real ROM-mastering artifact that can't be
rtl/video/sprite_display_list_walker.sv:1 Walks the sprite display list (psikyo_v.cpp get_sprites(), re-verified against current MAME source, see docs/phase1_memory_map.md):
rtl/video/sprite_display_list_walker.sv:73 sram_data % 768, full 16-bit range (matches MAME's `sprite %= 0x300` applied directly to the raw 16-bit display-list word, no prior masking -- see this module's header).
rtl/video/spriteram_dbuf.sv:23 WHEN copy_start fires is the pipeline's capture instant and is owned by psikyo_core's sequencing (it depends on the swap policy -- see the spr_copy_start comment there): under the FrameStart policy it fires at the frame boundary, matching M
rtl/video/tile_row_decode.sv:6 Format, verified against MAME's actual decode algorithm (src/emu/drawgfx.cpp: gfx_element::decode()/readbit()), NOT just the gfx_layout struct's field values at face value -- a first pass at reading the struct alone (planeoffset={0,1,2,3})
rtl/video/vreg_decode.sv:148 Reset value 0 therefore means ENABLED, matching MAME, whose m_vregs also powers up zeroed.
README.md:37 MRAs: `<rotation>vertical (ccw)</rotation>` for all vertical sets, matching MAME
README.md:205 Behavior is checked against MAME's `psikyo.cpp`/`psikyo_v.cpp` as the reference, including regression tests written for every hardware-found bug.

Keeps a MAME approximation — 1

rtl/cpu/s1945_mcu.sv:41 - rd_status_toggle: the word at 0xC00002 was read; the free- running status bit flips (MAME's own "hack" -- POST spins on it going both ways).

Shares text with the MAME driver without saying so — 12

Psikyo.sv:530 memory map calls the sprites "buffered by two frames (list buffered + fb — shares text with psikyo/psikyo.cpp:257
rtl/video/compositor.sv:138 for (int layer = 0; layer < 2; layer++) — shares text with psikyo/psikyo_v.cpp:119
rtl/video/sprite_display_list_walker.sv:4 for (offs = 0; offs < (0x800-2)/2; offs++) { // 1023 entries max — shares text with psikyo/psikyo_v.cpp:201
rtl/video/sprite_subtile_step.sv:6 if (flipx) { xstart = nx-1; xend = -1; xinc = -1; } else { xstart = 0; xend = nx; xinc = +1; } — shares text with psikyo/psikyo_v.cpp:250
rtl/video/sprite_subtile_step.sv:8 if (flipy) { ystart = ny-1; yend = -1; yinc = -1; } else { ystart = 0; yend = ny; yinc = +1; } — shares text with psikyo/psikyo_v.cpp:254
rtl/video/sprite_subtile_step.sv:9 for (dy = ystart; dy != yend; dy += yinc) — shares text with psikyo/psikyo_v.cpp:257
rtl/video/sprite_subtile_step.sv:10 for (dx = xstart; dx != xend; dx += xinc) { — shares text with psikyo/psikyo_v.cpp:259
rtl/video/video_timing.sv:3 m_screen->set_raw(14.318181_MHz_XTAL/2, 456, 0, 320, 262, 0, 224); — shares text with psikyo/psikyo.cpp:1131
rtl/video/vreg_decode.sv:30 (psikyo_v.cpp:135-136, "sngkace / samuraia don't use banking" — shares text with psikyo/psikyo_v.cpp:135
rtl/video/vreg_decode.sv:31 "They share gfx2 to save memory on other boards"). get_tile_info — shares text with psikyo/psikyo_v.cpp:136
rtl/video/vreg_decode.sv:93 switch_bgbanks(1, data>>6&3); switch_bgbanks(0, data>>4&3)). Tengai's — shares text with psikyo/psikyo.cpp:157
rtl/video/vreg_decode.sv:145 m_tilemap[layer]->enable(~layer_ctrl[layer] & 1); — shares text with psikyo/psikyo_v.cpp:487

PsikyoSH2#
The Fallen Angels / Daraku Tenshi: The Fallen Angels, Dragon Blaze, Gunbarich, Gunbird 2 …
MiSTer-devel/Arcade-PsikyoSH2_MiSTer @ 35a135b0
MAME compared: psikyo/psikyo4.cpp, psikyo/psikyosh.cpp + 4 related file(s)
Read: 34 HDL files, 15,961 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

27%

Statements: 1 toward hardware, 2 toward MAME

Ships hardware documentation files — 1

hw/PS5 schematic .pdf

Cites MAME source — 2

rtl/PSH2/YMF278B.sv:1 license:BSD-3-Clause (PCM engine derived from MAME's ymf278b)
rtl/PSH2/YMF278B_pkg.sv:1 license:BSD-3-Clause (PCM engine derived from MAME's ymf278b)

Psychic5#
Psychic 5
MiSTer-devel/Arcade-Psychic5_MiSTer @ 22dcd342
MAME compared: jaleco/psychic5.cpp + 2 related file(s)
Read: 29 HDL files, 7,843 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

35%

Statements: 9 toward hardware, 4 toward MAME, 3 not counted

Cites hardware documentation that MAME's driver does not — 9

rtl/Psychic5_cpuboard/Psychic5_obj.v:579 LS273 8N
rtl/Psychic5_videoboard/Psychic5_video.v:289 LS74 7H
rtl/Psychic5_videoboard/Psychic5_video.v:309 LS74 7H
rtl/Psychic5_videoboard/Psychic5_video.v:330 LS74 8E
rtl/Psychic5_videoboard/Psychic5_video.v:351 LS74 8E
rtl/Psychic5_videoboard/Psychic5_video.v:372 LS74 7E
rtl/Psychic5_videoboard/Psychic5_video.v:392 LS74 7E
rtl/Psychic5_videoboard/Psychic5_video.v:422 LS175 8F
rtl/Psychic5_videoboard/Psychic5_video.v:656 LS273 6B

Cites hardware references or measurements that MAME's driver also gives — 3

rtl/Psychic5_cpuboard/Psychic5_obj.v:448 sequencer ROM MB7122E = 82S137 — also in MAME: 82S137 jaleco/psychic5.cpp:1352
rtl/Psychic5_emu.v:222 0x0007_0000 0x0000_0400 3t my09.3t 82S137 BRAM sprite engine sequencer(MB7122) — also in MAME: 3t jaleco/psychic5.cpp:1298, 82S137 jaleco/psychic5.cpp:1352
rtl/Psychic5_emu.v:223 0x0007_0400 0x0000_0200 7l my10.7l 82S131 BRAM grayscale LUT — also in MAME: 7l jaleco/psychic5.cpp:1297, 82S131 jaleco/psychic5.cpp:1421

Cites MAME source — 2

rtl/Psychic5_emu.v:211 start addr length comp num mame rom parts num location description
rtl/Psychic5_emu.v:226 Note 1: MAME states JP uses a 256k ROM, but I verified that an original PCB that holds JP release also used a 512k ROM instead of the 256k one.

Shares text with the MAME driver without saying so — 2

rtl/Psychic5_cpuboard/Psychic5_obj.v:258 (4) X7 X6 X5 X4 X3 X2 X1 X0 b 4T — shares text with jaleco/psychic5.cpp:300
rtl/Psychic5_videoboard/Psychic5_video.v:506 *Psychic 5 is a vertical screen game, so vertical scrolling effect that appears during play is actually horizontal scroll. -----------> CRT scanline d — shares text with jaleco/psychic5.cpp

QBert#
Mad Planets, Q*bert, Q*bert's Qubes, Reactor …
MiSTer-devel/Arcade-QBert_MiSTer @ 2a19606a
MAME compared: gottlieb/gottlieb.cpp
Read: 42 HDL files, 15,811 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

14%

Statements: 4 toward MAME

Cites MAME source — 3

Arcade-QBert.sv:451 test button (active-high per MAME IN1 bit0 IP_ACTIVE_HIGH): fire/"Service Select"
rtl/mylstar_board.v:214 Reactor: MAME documents mirror(0x0ff8) for all I/O ports, meaning addr[3] is a don't-care in the original hardware decoder.
rtl/sc01a/sc01a.vhd:12 Key differences from MAME reference: - All arithmetic in s(2.15) fixed-point (no floating point) - Filter coefficients pre-computed as static ROM tables - IIR filters implemented as sequential state machines - Clock enables (sclock_en, cclo

Says it was translated, ported or taken from MAME — 1

rtl/sc01a/sc01a.vhd:9 Based on the Votrax SC01-A simulation from MAME Copyright (c) Olivier Galibert

Qix#
Complex X, The Electric Yo-Yo, Kram, Qix …
MiSTer-devel/Arcade-Qix_MiSTer @ cd3ca552
MAME compared: taito/qix.cpp + 4 related file(s)
Read: 27 HDL files, 20,684 lines (Quartus project)

MiSTer official

Mostly hardware

medium

36%

Statements: 12 toward hardware, 32 toward MAME

Cites hardware documentation that MAME's driver does not — 5

rtl/Qix.sv:168 FIRQ cross-signals (from schematic Figure 13, U7 7474 dual flip-flop)
rtl/Qix_CPU.sv:127 FIRQ access pulses (from schematic Figure 13, U7/U8): $8C00 (even): assert FIRQ on video CPU $8C01 (odd): ack data CPU's own FIRQ One 20MHz cycle pulse at E-fall.
rtl/Qix_CPU.sv:226 Per schematic DSR 2/2, its port A is J17 = the player-2 / cocktail control panel, and the data CPU's input poll reads the player's buttons from HERE whenever $8400 != 0: E277: LDX #$9400 / E27A: TST $8400 / E27F: LDX #$9000 / E282: LDA ,X F
rtl/Qix_Sound.sv:234 sndPIA2 ($2000-$3FFF) — TMS5200 speech PIA (Kram's "KRAM!" voice) Wiring per Kram schematic: port B ↔ D0-D7
rtl/Qix_Video.sv:135 FIRQ access pulses (from schematic Figure 13, U7/U8): $8C00 (even): assert FIRQ on data CPU $8C01 (odd): ack video CPU's own FIRQ One 20MHz cycle pulse at E-fall.

Ships hardware documentation files — 7

Cites MAME source — 23

rtl/Qix.sv:180 FIRQ delay configuration MODE 0: No delay (direct latch, current behavior) MODE 1: Half E-cycle delay (~400ns at 1.25 MHz E clock) MODE 2: 1 E-cycle delay (~800ns) MODE 3: 2 E-cycle delay (~1600ns) MODE 4: Alternating execution (MAME-style
rtl/Qix.sv:210 --- MODE 5: MAME-style end-of-phase FIRQs ---
rtl/Qix.sv:244 --- MODE 4: Alternating execution (MAME-style) --- Use E clock phase to alternate: data CPU acts on E=1 half, video CPU acts on E=0 half.
rtl/Qix.sv:315 PIA input assembly — per-game, sourced from MAME qix.cpp INPUT_PORTS
rtl/Qix.sv:476 MAME fixes this with interleave=20.
rtl/Qix_CPU.sv:90 Per qix.cpp: "Zookeeper is almost the same, just the top bit of the address is inverted most of the time to make space for more ROM." XOR cpu_A[15] with is_zookeep so the existing I/O decoders match unchanged.
rtl/Qix_CPU.sv:266 MCU games: latched MCU PA output feeds PIA0 PB input, mirroring MAME's coin_r which returns m_68705_porta_out (captured by mcu_porta_w callback).
rtl/Qix_CPU.sv:282 MCU PA input latch: mirrors MAME's coin_w (PIA0 writepb_handler) — fires ONLY on true PB *port* writes (CRB bit2=1), NOT on DDRB writes (CRB bit2=0).
rtl/Qix_CPU.sv:354 Slither has no 6802 sound board (qix.cpp: "Slither uses 2 SN76489's for sound instead of the 6802+DAC; these are accessed via the PIAs").
rtl/Qix_CPU.sv:409 SLITHER_CLOCK_OSC is referenced at qix.cpp:737 but not defined in our (truncated) copy of the driver.
rtl/Qix_CPU.sv:604 Interface per MAME qix_m.cpp: - Data CPU writes PIA0 PB → MCU PA input (coin_w) - MCU PA output → PIA0 PB input (coin_r — already wired via pia0_pb_i mux above) - MCU PB = (coin & 0x0F) | ((coin & 0x80) >> 3) - MCU PC = (coinctrl
rtl/Qix_CPU.sv:646 MAME (`qix_m.cpp:185-197` coinctrl_w) asserts/clears M68705_IRQ_LINE from `BIT(data,2)` — the value the data CPU WROTE.
rtl/Qix_CPU.sv:656 Using the latch makes an undriven bit read 0 => IRQ deasserted => a real 0->1 write produces a real edge, as on hardware and in MAME.
rtl/Qix_Sound.sv:64 MAME: SOUND_CLOCK_OSC 7.3728 MHz, M6802(OSC/2) => 3.6864 MHz xtal, E = 921.6 kHz.
rtl/Qix_Sound.sv:68 hdl/6802.uc/.vh/_param.vh were generated with jtframe from a 6802 target whose per-opcode `cycles:` came from MAME's cycles_6800[].
rtl/Qix_Sound.sv:308 IRQ to audio CPU: OR of all PIA interrupt outputs (active-high) NOTE (2026-06-16): tried sndpia1-only (MAME-faithful) to fix ZK fast music — DISPROVEN on HW, music unchanged.
rtl/Qix_Sound.sv:310 sndpia2-in-sint is a real MAME deviation but NOT the music-tempo cause; revisit only with speech.
rtl/Qix_Sound.sv:363 Derived from the parallel resistor network in qix_a.cpp (MAME).
rtl/Qix_Video.sv:157 Zoo Keeper ROM-bank latch (per qix_m.cpp zookeep_state::bankswitch_w)
rtl/cpu/TMS5220/source/TMS5220.vhd:13 References: TMS5220 datasheet, US Patent US4335277 and TMS5220.cpp from MAME source code.
rtl/custom/sn76489/sn76489_noise.vhd:199 Tapped bits according to MAME's sn76496.c, implemented in function lfsr_tapped_f.
rtl/qix_display.sv:175 Display address Formula (from MAME qix.cpp): ((MA << 6) & 0xF800) | ((RA << 8) & 0x0700) | pix_cnt Expanded: bits [15:11] = MA[9:5] bits [10: 8] = RA[2:0] bits [ 7: 3] = 0 bits [ 2: 0] = pix_cnt
rtl/qix_palette.sv:53 RRGGBBII → RGB conversion (from MAME qix.cpp) Index = {color_value[1:0], intensity[1:0]}

Says it was translated, ported or taken from MAME — 2

Arcade-Qix.sv:359 Port byte = counter scaled by Trackball Speed: Normal = MAME's 50%, Fast = 1:1, Slow = 1:4
rtl/cpu/TMS5220/source/TMS5220.vhd:15 IMPORTANT NOTES: 1) This implementation does NOT implement the schematic in US4335277 2) It is based primarily on MAME source code and aims to be "functionally equivalent" to the "TMS5220" chip but not identical in terms of electrical circu

Shares text with the MAME driver without saying so — 7

rtl/Qix_CPU.sv:91 "Zookeeper is almost the same, just the top bit of the address is inverted — shares text with taito/qix.cpp:68
rtl/Qix_CPU.sv:92 most of the time to make space for more ROM." — shares text with taito/qix.cpp:68
rtl/Qix_CPU.sv:354 Slither has no 6802 sound board (qix.cpp: "Slither uses 2 SN76489's for sound — shares text with taito/qix.cpp:726
rtl/Qix_CPU.sv:355 instead of the 6802+DAC; these are accessed via the PIAs"). The data CPU writes — shares text with taito/qix.cpp:726
rtl/Qix_CPU.sv:411 Slither data CPU at OSC/4/4 ~= 1.34 MHz; this assumes the PSGs share that rate. — shares text with taito/qix.cpp:737
rtl/Qix_Video.sv:221 "[2] Slither only. This hardware feature is NOT present in the — shares text with taito/qix.cpp:122
rtl/qix_display.sv:177 ((MA << 6) & 0xF800) | ((RA << 8) & 0x0700) | pix_cnt — shares text with taito/qix_v.cpp:271

Raiden#
Raiden
MiSTer-devel/Arcade-Raiden_MiSTer @ 027e28a1
MAME compared: seibu/raiden.cpp + 4 related file(s)
Read: 37 HDL files, 11,693 lines (Quartus project)

MiSTer official

Both

medium

62%

Statements: 8 toward hardware, 104 toward MAME

Says it was checked against the original PCB — 1

rtl/Raiden/Raiden_video_timing.sv:11 RAIDEN (2026-08-21, refresh 1:1): le evidenze sul PCB Raiden convergono su 262 linee ≈ 59.6 Hz, NON 263: MAME raiden.cpp `set_refresh_hz(59.60) "verified on PCB"` (entrambi i set) e i vregs del CRTC reale che raidenb scrive al boot (V total

Reports a measurement taken on the original PCB — 1

rtl/Raiden/Raiden_video_timing.sv:8 PCB measurement Blood Bros: VSync 59.4094 Hz, HSync 15.6246 kHz, master XTAL 20 MHz (= 263 linee a 15.625 kHz).

Says it was checked on “real hardware” — 2

Raiden.sv:522 Il ricevitore Main ha lo stesso latch-FSM del Sub (main_top:128-152 = sub_top:112-134): protocollo ready-pulse gia' provato con la cache su HW.
Raiden.sv:1588 Verificato su HW il 2026-08-23.

Notes where it differs from MAME — 4

Raiden.sv:516 (Storico: il vecchio bypass "pattern WonderSwan" era di un'era pre-latch-FSM; oggi il ricevitore Main latcha il ready-pulse come il Sub -> cache ok.) MAIN ROM via rom_cache (come il Sub): senza cache il Main fetcha DIRETTO da SDRAM in arbit
rtl/Raiden/Raiden_main_top.sv:120 La coperta dichiarava 2 periodi dove ce n'e' 1: STA verde e SILICIO CHE SBAGLIA -- la stessa forma del bug punteggio storico (multicycle 9 falso, -11.03/-11.85) e di CE_HALF a +1 clk (-11.316, vedi cpu_v30_bridge).
rtl/Raiden/Raiden_sub_top.sv:102 La coperta dichiarava 2 periodi dove ce n'e' 1: STA verde e SILICIO CHE SBAGLIA -- la stessa forma del bug punteggio storico (multicycle 9 falso, -11.03/-11.85) e di CE_HALF a +1 clk (-11.316, vedi cpu_v30_bridge).
rtl/Raiden/v30_new/v30_bus.sv:644 Se in sim arrivano sbagliati (attivi bassi!), il gioco va in un'altra modalita' e tutto il confronto con MAME non vale niente.

Cites MAME source — 96

Raiden.sv:342 raiden_decrypt — applica MAME init_decryption() al volo durante download.
Raiden.sv:364 --- Joystick to Raiden input mapping --- MAME P1_P2 port ($E0002): active low.
Raiden.sv:367 MiSTer joy bits: joy[0]=R, joy[1]=L, joy[2]=D, joy[3]=U, joy[4]=A, joy[5]=B. Raiden P1_P2 layout MAME (raiden.cpp:589-605): bit 0=UP, 1=DOWN, 2=LEFT, 3=RIGHT, 4=BTN1(Fire), 5=BTN2(Bomb), 6=unused, 7=START1 bit 8-15 = P2 (stesso layout) MiST
Raiden.sv:631 MAME raiden.cpp:391-401 — scroll_ram è u16 array, indici 0xNN sono WORD index (non byte address).
Raiden.sv:633 Formula (raiden.cpp:398): ((b_hi & 0xF0) << 4) | ((b_lo & 0x7F) << 1) | ((b_lo & 0x80) >> 7) scrollregs[0] = BG_X = scroll_ram[0x09].lo<<4 | scroll_ram[0x0A].lo shifted scrollregs[1] = BG_Y = scroll_ram[0x01].lo<<4 | scroll_ram[0x02].lo shi
Raiden.sv:648 raidenb: gli scroll arrivano dal CRTC come word intere (raiden.cpp:407-410, nessuna ricomposizione byte) — mux sul board select.
Raiden.sv:651 L'algebra MAME completa (tilemap.cpp: scroll trasformato + CONTENUTO mirrorato) dimostra che il contratto di rotazione 180° si soddisfa con lo scroll RAW: nessuna negazione.
Raiden.sv:723 000 xBGR : R=[ 3:0] G=[ 7:4] B=[11:8] (MAME palette_device::xBGR_444)
Raiden.sv:732 xBGR (MAME palette_device::xBGR_444)
Raiden.sv:1052 ── Flip screen (CRTC reg 0x1A bit 0) ─────────────────────────────────────── MAME: BIT(reg_1a, 0) → flip_screen.
Raiden.sv:1079 MAME raiden.cpp: tilemap set_flip_all su 256 colonne = 255-x. FIX flip 2px (2026-08-21): dal commit 5dee128 (M10K read-ahead, 31 lug, NON nella 1.0 del 29 lug) il read-side legge linebuf[hpos+1] REGISTRATO.
Raiden.sv:1103 Raiden Text scroll fissi: 128 X (MAME), 16 Y (centratura HW reale)
Raiden.sv:1128 ── BG/FG layer renderer (16x16, 4bpp, 32x32) — fetch SDRAM via arbiter ── Raiden plain: NO MG layer (MAME raiden.cpp:493-495 sub_map ha solo bgram+fgram+palette).
Raiden.sv:1164 MAME gfx_raiden palette bases: bgtiles=0, fgtiles=256(0x100), sprites=512(0x200), text=768(0x300)
Raiden.sv:1166 BG palette base 0 (raiden.cpp:698 GFXDECODE bgtiles 0,16)
Raiden.sv:1187 FG palette base 256 (raiden.cpp:699 GFXDECODE fgtiles 256,16)
Raiden.sv:1444 Pixel pipeline MAME RAIDEN (raiden.cpp:286-358 draw_sprites + 361-397 update): Render order MAME: BG (priority 1) → FG (priority 2) → Text (priority 4) Sprite con pri_mask: pri=0 → SKIP (gestito nel renderer, opaque=0) pri=1 → mask = GFX_PM
Raiden.sv:1509 MAME: bitmap.fill(black_pen) prima di disegnare i layer → backdrop = NERO fisso, NON palette[0].
Raiden.sv:1525 is_backdrop_d forza nero (MAME bitmap.fill(black_pen)) → no scene-color dell'area "vuota" tra layer (es.
rtl/Raiden/Raiden_audio_z80.sv:7 Spec da MAME (reference/mame_seibu/seibusound.cpp + dcon.cpp): - Z80A @ 14.31818 MHz / 4 = 3.579545 MHz - YM2151 (jt51) @ 14.31818 / 4 = 3.579545 MHz - OKI M6295 (jt6295) @ 20 MHz / 16 = 1.25 MHz, PIN7=LOW
rtl/Raiden/Raiden_audio_z80.sv:57 OSD volume select (4-bit, pattern BoogieWings): 0=Default, 1=Mute, 2=MAME, 3..15 = percentuale del Default
rtl/Raiden/Raiden_audio_z80.sv:113 ─── Clock enable: clk_sys (80 MHz) → Z80/YM 3.579545 MHz, OKI 1 MHz ───── MAME raiden.cpp:724 Z80 @ 14.318181/4 = 3.579 MHz :744 YM3812 @ 14.318181/4 = 3.579 MHz (shared con Z80) 80/3.579545 = 22.349, NON intero: la divisione per 22 dava 3.
rtl/Raiden/Raiden_audio_z80.sv:141 OKI clock: MAME raiden.cpp:754 = 12 MHz / 12 = 1 MHz exact.
rtl/Raiden/Raiden_audio_z80.sv:183 MAME audiocpu region layout (sdgndmps):
rtl/Raiden/Raiden_audio_z80.sv:250 ─── sei80bu: opcode (M1) decrypt — Raiden Z80 ROM encryption ───────────── MAME raiden.cpp:768-769: opcodes via sei80bu_device::opcode_r, data via raw.
rtl/Raiden/Raiden_audio_z80.sv:253 GATE z80_decrypt_en (porta, dal board select MRA index=1): 0 = ROM raw (raidenb newer hardware, rai6.u212 in chiaro) 1 = sei80bu attivo (set classici, raiden.zip MAME originale)
rtl/Raiden/Raiden_audio_z80.sv:324 ─── ROM bank register (Z80 0x4007: bit0 → bank 0/1) ───────────────────── MAME seibu_sound_device::bank_w: m_rom_bank->set_entry(BIT(data,0))
rtl/Raiden/Raiden_audio_z80.sv:411 Main writes to 0xA0008 (MAME offset 4) → assert RST18 snd_addr = bus_addr[3:1], 0xA0008 → bit[3:1]=100 = 4
rtl/Raiden/Raiden_audio_z80.sv:437 ─── Soundlatch main_w/r logic ────────────────────────────────────────── snd_addr = bus_addr[3:1] = offset/2 (0=word 0, 1=word 1, 2=word 2, 3=word 3, 4=word 4, 5=word 5, 6=word 6) MAME usa byte access (umask16 0x00ff = byte basso).
rtl/Raiden/Raiden_audio_z80.sv:439 Mappa offset MAME → snd_addr: offset 0 (0xA0000) → snd_addr 0 offset 1 (0xA0002) → snd_addr 1 offset 2 (0xA0004) → snd_addr 2 offset 3 (0xA0006) → snd_addr 3 offset 5 (0xA000A) → snd_addr 5 offset 6 (0xA000C) → snd_addr 6
rtl/Raiden/Raiden_audio_z80.sv:462 Main writes (MAME seibu_sound_device::main_w): case 0/1: m_main2sub[offset] = data case 4: update_irq_lines(RST18_ASSERT) — gestito sopra case 2/6: pending flags (sub2main=0, main2sub=1)
rtl/Raiden/Raiden_audio_z80.sv:470 MAME case 2/6
rtl/Raiden/Raiden_audio_z80.sv:477 Z80 reads soundlatch (→ MAME implicit: nessun side effect) Z80 writes sub2main
rtl/Raiden/Raiden_audio_z80.sv:491 MAME seibu_sound_device::main_r (seibusound.cpp:285): offset 2,3: sub2main[0/1] (Z80 → main latch bytes) offset 5: main2sub_pending (main chiede: Z80 ha letto il mio comando?) default: 0xFF NO sdgndmps override per Raiden (era bug copi
rtl/Raiden/Raiden_audio_z80.sv:503 ─── YM3812 (jtopl2) mono ──────────────────────────────────────────────── MAME raiden.cpp:744 YM3812(config, "ymsnd", 14.318181_MHz_XTAL / 4) Mono → duplicato L/R nel mixer sotto.
rtl/Raiden/Raiden_audio_z80.sv:703 PIN7 = HIGH (MAME raiden.cpp:754 verified)
rtl/Raiden/Raiden_audio_z80.sv:811 I byte della ROM Z80 come li vede la CPU: in MAME 0010 = C3 76 10.
rtl/Raiden/Raiden_audio_z80.sv:901 ─── Mixer audio: jtframe_mixer Toki pattern (Q4.4 gains) ──────────────── Volume OSD pattern BoogieWings: Default/Mute/MAME + percentuali che scalano il DEFAULT.
rtl/Raiden/Raiden_audio_z80.sv:905 Default Raiden tarato HW (screenshot 2026-07-13): FM 500%, ADPCM 400% del gain MAME base (FM 0x10, OKI 0x0C).
rtl/Raiden/Raiden_audio_z80.sv:907 FM : 0x10 × 5 = 0x50 (= era 100% MAME × 5.0) OKI : 0x0C × 4 = 0x30 (= era 75% MAME × 4.0) Le percentuali OSD scalano da QUESTI nuovi default.
rtl/Raiden/Raiden_audio_z80.sv:909 MAME (sel 2) resta il valore MAME-esatto originale (0x10 / 0x0C) per chi vuole l'accurato.
rtl/Raiden/Raiden_main_top.sv:350 Equivale a MAME tilemap render fine-frame.
rtl/Raiden/Raiden_main_top.sv:371 Tutte le scritture nella text RAM, nello stesso formato del tap MAME.
rtl/Raiden/Raiden_main_top.sv:527 ─── control_w $0E006 (8-bit) — raidenb: $0B006 ──────────────────────── base (raiden.cpp:242-259): bit 0: BG dis, bit 1: FG dis, bit 2: TX dis, bit 3: SPR dis, bit 6: flipscreen raidenb (raiden.cpp:261-271): bit 1: flipscreen, bit 3: TX
rtl/Raiden/Raiden_main_top.sv:639 Confronto diretto con MAME sull'ATTRACT DEMO (stesso codice, nessun input, deterministico).
rtl/Raiden/Raiden_main_top.sv:641 MAME misurato: +44 ogni 300 frame video.
rtl/Raiden/Raiden_seibu_crtc.sv:12 Mappatura output sugli usi REALI di raidenb (raiden.cpp:273-282, 791-794), non sulla doc generica CRTC: reg 0x1C (layer_en): d0=BG disable, d1=FG disable, d4=SPR disable (in Raiden il layer FG e' lo "screen 2" del CRTC → bit 1).
rtl/Raiden/Raiden_seibu_crtc.sv:21 reg 0x1A: flip NON viene da qui in raidenb (callback non collegata in MAME); il flip sta nel control 0x0B006 d1.
rtl/Raiden/Raiden_seibu_crtc.sv:83 MAME raidenb layer_enable_w: bit=1 → layer DISABILITATO.
rtl/Raiden/Raiden_sprite_renderer.sv:9 Format word (formato "comune", non alt_format) da MAME src/mame/seibu/sei021x_sei0220_spr.cpp: w0 bit 15 = enable (0=skip, 1=draw) w0 bit 14 = flip_x w0 bit 13 = flip_y w0 bit 12..10 = sizex (3-bit, +1) → 1..8 tile larghezza
rtl/Raiden/Raiden_sprite_renderer.sv:24 Multi-tile: tile_code += 1 per sub-tile (TODO: ordine x-major o y-major da verificare con dump MAME — assunto x-major per ora).
rtl/Raiden/Raiden_sprite_renderer.sv:27 Priority callback dcon.cpp::pri_cb: pri=0 → above FG pri=1 → above MG pri=2 → above BG pri=3 → above Text (= sotto Text)
rtl/Raiden/Raiden_sprite_renderer.sv:81 ─── Line buffer ping-pong (320 × 10-bit: color[3:0] + pri[1:0] + pen[3:0]) ── Layout 10-bit: [9:6]=color (4-bit MAME Raiden), [5:4]=pri_code, [3:0]=pen Valid pixel = pen != 0xF (15 = trasparente in MAME)
rtl/Raiden/Raiden_sprite_renderer.sv:114 Decoded fields - MAME RAIDEN layout (raiden.cpp:298-316): w0: [15]=active, [14]=flipy, [13]=flipx, [11:8]=color(4-bit), [7:0]=Y(8-bit unsigned) w1: [11:0]=code(12-bit) w2: [15:14]=priority(2-bit, 0=SKIP), [8:0]=X(signed 9-bit) w3: unused Sp
rtl/Raiden/Raiden_sprite_renderer.sv:121 flip_screen (DIP) inverte flipx/flipy per-sprite (raiden.cpp:353-354).
rtl/Raiden/Raiden_sprite_renderer.sv:131 flip_screen (DIP): x = 240 - x (raiden.cpp:351).
rtl/Raiden/Raiden_sprite_renderer.sv:136 flip_screen: y = 240 - y (raiden.cpp:352).
rtl/Raiden/Raiden_sprite_renderer.sv:195 Inverte la priorità tra sprite rispetto al default MAME.
rtl/Raiden/Raiden_sprite_renderer.sv:435 priority=0 skip (MAME raiden.cpp:322-324).
rtl/Raiden/Raiden_text_renderer.sv:7 Specifiche da MAME (src/mame/seibu/dcon.cpp):
rtl/Raiden/Raiden_text_renderer.sv:51 (raiden.cpp:697 GFXDECODE text 768 16 → palette base 0x300)
rtl/Raiden/Raiden_text_renderer.sv:59 raidenb (newer hardware): text tilemap TILEMAP_SCAN_COLS (raiden.cpp:463-471) → vram_addr = col*32+row invece di row*32+col.
rtl/Raiden/Raiden_text_renderer.sv:133 --- Stage 0: tile coords --- MAME raiden.cpp:458 text_layer = TILEMAP_SCAN_ROWS, 8x8, 32x32 tiles.
rtl/Raiden/Raiden_text_renderer.sv:180 vram_data è valido in stage 1 (BRAM read latency 1 ce_pix) MAME raiden.cpp get_text_tile_info: tile = (data & 0xff) | ((data >> 6) & 0x300) = bit[7:0] | bit[15:14] in [9:8] color = (data >> 8) & 0x0f = bit[11:8]
rtl/Raiden/Raiden_tile_layer.sv:7 Differenze fra layer (da MAME dcon.cpp):
rtl/Raiden/Raiden_tile_layer.sv:227 MAME raiden.cpp:443 BG e FG usano TILEMAP_SCAN_COLS: tile_index = col * height + row = col * 32 + row Quindi vram_addr = {col[4:0], row[4:0]} (col high, row low).
rtl/Raiden/Raiden_tile_layer.sv:267 MAME raiden_tilelayout (raiden.cpp:685-694): planes = STEP4(12,-4) = {12, 8, 4, 0}
rtl/Raiden/Raiden_tile_layer.sv:284 MAME readbit MSB-first → bit_in_byte = 7 - (bitnum mod 8).
rtl/Raiden/Raiden_video_timing.sv:11 RAIDEN (2026-08-21, refresh 1:1): le evidenze sul PCB Raiden convergono su 262 linee ≈ 59.6 Hz, NON 263: MAME raiden.cpp `set_refresh_hz(59.60) "verified on PCB"` (entrambi i set) e i vregs del CRTC reale che raidenb scrive al boot (V total
rtl/Raiden/Raiden_video_timing.sv:18 Il pixel clock effettivo per matchare HSync 15.625 kHz con HTotal=384 (320 attivi + 64 blank ≈ 80% duty) è: pix_clk = HTotal × HSync = 384 × 15625 = 6.0 MHz Frame rate: 6e6 / (384 × 262) = 59.63 Hz (Raiden PCB 59.60, MAME verified)
rtl/Raiden/Raiden_video_timing.sv:23 Active area da MAME (sdgndmps_map): visarea 0..40*8-1, 2*8..30*8-1 quindi 320×224, V offset = 16 (top blank).
rtl/Raiden/raiden_addr_main.sv:6 Memory map MAME raiden_state::main_map (riga 475-488): 0x00000-0x06FFF RAM (28KB) → ram_memrq 0x07000-0x07FFF spriteram (4KB) → sprite_memrq 0x08000-0x08FFF shared RAM (Sub) → shared_memrq 0x0A000-0x0A00D
rtl/Raiden/raiden_addr_main.sv:19 board_raidenb=1: mappa raidenb_state::main_map (raiden.cpp:537-550) — shared 0x0A000, I/O+ctrl 0x0B00x, sound 0x0D000, Seibu CRTC 0x0D040-8F, niente scroll_ram.
rtl/Raiden/raiden_addr_main.sv:67 raidenb_state::main_map (raiden.cpp:537-550)
rtl/Raiden/raiden_addr_sub.sv:6 Memory map MAME raiden_state::sub_map (riga 490-501): 0x00000-0x01FFF RAM (8KB) → ram_memrq 0x02000-0x027FF bgram (R/W) → bgram_memrq 0x02800-0x02FFF fgram (R/W) → fgram_memrq 0x03000-0x03FFF pal
rtl/Raiden/raiden_ce_gen.sv:6 V30 spec MAME = 10 MHz esatti.
rtl/Raiden/raiden_ce_gen.sv:8 clk_sel[2:0] (da OSD P2O[22:20]): 0=10MHz → div 8 (10.0 MHz esatti) ← spec MAME 1=8MHz → div 10 (8.0 MHz) 2=12MHz → div 6 (13.3 MHz) 3=16MHz → div 5 (16.0 MHz) 4=24MHz → div 4 (20.0 MHz) 5=32MHz → div 2 (26.7 MHz)
rtl/Raiden/raiden_ce_gen.sv:48 10 MHz spec MAME (80/8)
rtl/Raiden/raiden_decrypt.sv:4 raiden_decrypt — passthrough ioctl_dout con decifrato MAME init_decryption()
rtl/Raiden/raiden_decrypt.sv:9 Range crittato (riferimento raiden.cpp:1187): - Main ROM section 2: MRA byte 0x020000-0x05FFFF (CPU 0xC0000-0xFFFFF) - Sub ROM tutto: MRA byte 0x060000-0x09FFFF (CPU 0xC0000-0xFFFFF)
rtl/Raiden/raiden_decrypt.sv:20 Bitswap16 da MAME bitswap<16>(d, b15..b0): out[15]=d[b15], ..., out[0]=d[b0].
rtl/Raiden/raiden_decrypt.sv:84 ── Output selection ──────────────────────────────────────────────── PRODUCTION MODE: decrypt runtime per usare raiden.zip originale MAME.
rtl/Raiden/raiden_decrypt.sv:86 I range enc_main (0x020000-0x05FFFF) e enc_sub (0x060000-0x09FFFF) sono applicati on-the-fly via XOR + bitswap MAME init_decryption() (raiden.cpp:1187).
rtl/Raiden/raiden_shared_ram.sv:19 MAME memory map: Main: $08000-$08FFF Sub : $04000-$04FFF
rtl/Raiden/raiden_sprite_mainbus.sv:4 Raiden sprite RAM bus (pattern Irem M72 board_b_d-style + BUFFERED_SPRITERAM16) Gestisce spriteram (Main side, $07000-$07FFF, 4KB = 2K word) con: - Porta A: Main V30 R/W - Buffer: copia spriteram → buf su rising vblank (MAME BUFFERED_SPRITE
rtl/Raiden/raiden_sprite_mainbus.sv:10 MAME memory map Main: $07000-$07FFF spriteram (4KB) — share "spriteram" (BUFFERED_SPRITERAM16)
rtl/Raiden/raiden_video_subbus.sv:13 MAME memory map Sub: $02000-$027FF bgram $02800-$02FFF fgram $03000-$03FFF palette
rtl/Raiden/sei80bu.v:4 sei80bu - SEI80BU Encrypted Z80 Interface Implementazione esatta da MAME mame/src/devices/machine/sei80bu.cpp: - data_r: 5 XOR + 2 bitswap (sempre) - opcode_r: 8 XOR + 4 bitswap (data + 3 XOR e 2 bitswap extra solo M1) Determinato runti
rtl/Raiden/v30_new/v30_bus.sv:577 COSTO IN CICLI CPU del codice di boot (deterministico, identico a MAME).
rtl/Raiden/v30_new/v30_bus.sv:578 Stampo il numero di CE (= clock CPU) alla n-esima scrittura nella finestra 00400-0040F: gli stessi eventi misurati in MAME con raiden_cycles.lua.
rtl/Raiden/v30_new/v30_bus.sv:590 Ogni volta che cambia e' un'istruzione completata: stampo ciclo + IP nella stessa finestra tracciata in MAME, cosi' il costo istruzione per istruzione si confronta uno a uno.
rtl/Raiden/v30_new/v30_bus.sv:601 Riferimento MAME da avvio: main ~4106/4186 per frame (con calo a ~3 ogni 6 frame), sub ~822/2992 alternati.
rtl/Raiden/v30_new/v30_bus.sv:616 costo di UN giro del ciclo di attesa: in MAME e' 23 cicli esatti (cmp [410h],5 = 10, blt = 13).
rtl/Raiden/v30_new/v30_bus.sv:634 In MAME viene messo a 1 una volta sola da EECE7 e da li' in poi la ISR lavora.
rtl/Raiden/v30_new/v30_bus.sv:668 In MAME sono ~73.380 cicli (44% del frame): e' il lavoro vero del frame.
README.md:11 This core reimplements the hardware in SystemVerilog/VHDL from MAME references and hardware observation.

Says it matches, follows or was checked against MAME — 1

rtl/Raiden/v30_new/v30_bus.sv:653 Confrontato con la traccia di MAME dice l'istruzione esatta in cui i due si separano.

Shares text with the MAME driver without saying so — 7

Raiden.sv:1448 pri=1 → mask = GFX_PMASK_4 | GFX_PMASK_2 → sotto FG e Text → SOPRA SOLO BG — shares text with seibu/raiden.cpp:327
rtl/Raiden/Raiden_audio_z80.sv:504 MAME raiden.cpp:744 YM3812(config, "ymsnd", 14.318181_MHz_XTAL / 4) — shares text with seibu/raiden.cpp:758
rtl/Raiden/Raiden_text_renderer.sv:4 Raiden_MiSTer — Text layer renderer Seibu D-Con (8x8, 4bpp, 64x32). Author: Umberto Parisi (rmonic79) Specifiche da MAME (src/mame/seibu/dcon.cpp): — shares text with seibu/raiden.cpp
rtl/Raiden/Raiden_tile_layer.sv:269 xoff = STEP4(0,1) | STEP4(16,1) | STEP4(512,1) | STEP4(528,1) — shares text with seibu/raiden.cpp:681
rtl/Raiden/Raiden_video_timing.sv:4 Raiden_MiSTer — Video timing single-screen Seibu D-Con. Author: Umberto Parisi (rmonic79) Raiden Psycho Salamander gira su Seibu D-Con (PB91008), stess — shares text with seibu/raiden.cpp
rtl/Raiden/raiden_decrypt.sv:63 Main: 15,14,10,12,11,13,9,8,3,2,5,4,7,1,6,0 — shares text with seibu/raiden.cpp:1205
rtl/Raiden/raiden_decrypt.sv:68 Sub: 15,14,13,9,11,10,12,8,2,0,5,4,7,3,1,6 — shares text with seibu/raiden.cpp:1216

Raiden2#
Raiden II, Raiden DX
MiSTer-devel/Arcade-Raiden2_MiSTer @ 534c84c5
MAME compared: seibu/raiden2.cpp + 12 related file(s)
Read: 39 HDL files, 15,779 lines (Quartus project)

MiSTer official

Mostly MAME

medium

73%

Statements: 5 toward hardware, 236 toward MAME

Says it was checked against the original PCB — 1

rtl/Raiden2/raiden2_ce_gen.sv:41 Il V30 della scheda gira a 16,000000 MHz (quarzo 32 MHz diviso 2, "verified on pcb"), quindi il rapporto esatto e' 16/96 = 20/120.

Says it was checked on “real hardware” — 3

rtl/Raiden2/Raiden2_cop3.sv:660 0 : 1 (unsigned <320 provato su HW = REGRESSIONE; il signed [-160,320) dell'intento MAME e' il comportamento giusto sul core)
rtl/Raiden2/Raiden2_sprite_renderer.sv:502 Scan INVERSO 511→0 (verificato su HW): lo fa la scan-ombra, e la FIFO conserva quell'ordine, quindi con last-write-wins l'entry 0 scrive per ultima e vince → entry 0 sopra.
rtl/Raiden2/Raiden2_tile_layer.sv:350 Plane order verificato su HW: BG/MG = DCBA (PEN_ORDER=0), FG = BADC (PEN_ORDER=1).

Notes where it differs from MAME — 1

rtl/Raiden2/Raiden2_cop3.sv:3702 La chiave e' la word CON SEGNO all'indirizzo ALLINEATO AL LONG: key = read_word( (sort_ram + val) & ~3 ) E' l'unica funzione che soddisfa i due testimoni del ROM: piani $00363E: $110004 + val (val ≡0 mod 4) = $1157EC, e la chiave e' la Y

Cites MAME source — 220

Raiden2.sv:327 Raiden II: il programma main V30 e' IN CHIARO (raiden2.cpp non ha init_decryption).
Raiden2.sv:337 --- Joystick to Raiden input mapping --- MAME P1_P2 port ($E0002): active low.
Raiden2.sv:340 MiSTer joy bits: joy[0]=R, joy[1]=L, joy[2]=D, joy[3]=U, joy[4]=A, joy[5]=B. Raiden P1_P2 layout MAME (raiden.cpp:589-605): bit 0=UP, 1=DOWN, 2=LEFT, 3=RIGHT, 4=BTN1(Fire), 5=BTN2(Bomb), 6=unused, 7=START1 bit 8-15 = P2 (stesso layout) MiST
Raiden2.sv:360 Seibu coin input: Raiden II usa SEIBU_COIN_INPUTS_INVERT (raiden2.cpp:768, tutti i bit ATTIVI BASSI, a riposo 0xFF — confermato dal ROM nella _old: il ramo che accredita e' quello con AND == 0).
Raiden2.sv:611 MAME raiden.cpp:391-401 — scroll_ram è u16 array, indici 0xNN sono WORD index (non byte address).
Raiden2.sv:613 Formula (raiden.cpp:398): ((b_hi & 0xF0) << 4) | ((b_lo & 0x7F) << 1) | ((b_lo & 0x80) >> 7) scrollregs[0] = BG_X = scroll_ram[0x09].lo<<4 | scroll_ram[0x0A].lo shifted scrollregs[1] = BG_Y = scroll_ram[0x01].lo<<4 | scroll_ram[0x02].lo shi
Raiden2.sv:664 ── Palette → RGB888 — COPIATA dalla _old (Raiden2_palette.sv:85-96, video HW-perfetto): Raiden2 = xBGR_555 (legionna.cpp:1212), NON 444.
Raiden2.sv:666 Layout word: bit[4:0]=R, bit[9:5]=G, bit[14:10]=B. Espansione 5→8 standard MAME palette_device: {val5, val5[4:2]}.
Raiden2.sv:869 Pixel clock 8 MHz = clk_sys/12, HTotal 512, VTotal 282 (raiden2.cpp: set_raw(32MHz/4, 512,0,320, 282,0,240)).
Raiden2.sv:898 ── Flip screen (CRTC reg 0x1A bit 0) ─────────────────────────────────────── MAME: BIT(reg_1a, 0) → flip_screen.
Raiden2.sv:1007 Scroll CRTC (legionna_v.cpp tile_scroll_w): ram[0/1]→BG, [2/3]→MG, [4/5]→FG.
Raiden2.sv:1104 La ROM e' CIFRATA (MAME init_raiden2 → raiden2_decrypt_sprites): l'algoritmo lavora su word da 32 bit, quindi si accumulano le due meta' a 16 bit da ioctl, si decifra, si scrivono entrambe.
Raiden2.sv:1437 Pixel pipeline MAME RAIDEN (raiden.cpp:286-358 draw_sprites + 361-397 update): Render order MAME: BG (priority 1) → FG (priority 2) → Text (priority 4) Sprite con pri_mask: pri=0 → SKIP (gestito nel renderer, opaque=0) pri=1 → mask = GFX_PM
Raiden2.sv:1465 ── Composizione raiden2_v (dalla _old): draw_raw + blend_layer con m_cur_spri = {0,1,2,3,-1} (raiden2.cpp:3165-3167).
Raiden2.sv:1480 Implementa il modello MAME per intero: fondale nero, poi gli 8 livelli dal FONDO in avanti, e un indice in tabella si MESCOLA al 50% con l'accumulato invece di sostituirlo.
rtl/Raiden2/Raiden2_audio_z80.sv:25 Spec da MAME (legionna.cpp godzilla machine config :1295-1355): - Z80 @ 14.318180/4 = 3.579545 MHz (seibu_sound_map + godzilla_sound_io_map) - YM2151/OPM (jt51) @ 28.63636/8 = 3.579545 MHz - OKI M6295 (jt6295) @ 20MHz/20 = 1.000 MHz, PIN7=H
rtl/Raiden2/Raiden2_audio_z80.sv:58 Raiden2 pcm.922 = 512KB: bit 18 = bank (Z80 IO port 0, MAME godzilla_oki_bank_w: set_rom_bank(data&1)).
rtl/Raiden2/Raiden2_audio_z80.sv:63 Secondo OKI (MAME raiden2.cpp:1151): ROM su DDR3, porta a priorita' bassa.
rtl/Raiden2/Raiden2_audio_z80.sv:74 master OKI2 (MAME instrada 0.40 CIASCUNO)
rtl/Raiden2/Raiden2_audio_z80.sv:192 MAME raiden2_sound_map: $6000 = oki1, $6002 = oki2 -> discrimina addr[1].
rtl/Raiden2/Raiden2_audio_z80.sv:265 raiden2_sound_map (raiden2.cpp:738) sposta bank_w a $401A: la mappa Seibu CONDIVISA lo ha a $4007, che qui NON e' mappato.
rtl/Raiden2/Raiden2_audio_z80.sv:491 MAME seibu_sound_device::main_r (seibusound.cpp:279): case 2,3: return sub2main[offset-2] (soundlatch data: coin/input dal Z80) case 5: return main2sub_pending ?
rtl/Raiden2/Raiden2_audio_z80.sv:574 ─── YM2151 (jt51) mono — Raiden II usa OPM, non OPL2 ─────────────────── MAME raiden2.cpp base_ym2151: ym2151_device @ XTAL(28'636'363)/8, route ALL_OUTPUTS 0.50 su mono.
rtl/Raiden2/Raiden2_audio_z80.sv:779 ─── OKI M6295 (jt6295) — MAME raiden2.cpp: XTAL 28.63636/28 = 1.0227 MHz, PIN7_HIGH, DUE chip instradati 0.40 ciascuno.
rtl/Raiden2/Raiden2_audio_z80.sv:957 Due OKI (MAME li instrada entrambi a 0.40 contro 0.50 dell'FM): si sommano a 17 bit PRIMA del guadagno, poi una sola moltiplicazione.
rtl/Raiden2/Raiden2_audio_z80.sv:960 I due OKI hanno ORA il loro guadagno master indipendente: in MAME sono due device distinti instradati 0.40 ciascuno, e nell'OSD sono due voci.
rtl/Raiden2/Raiden2_cop3.sv:4 MAME-faithful implementation of the Seibu SEI300 chip as used by the `legionna` driver (Raiden2 1992 — Banpresto/TAD).
rtl/Raiden2/Raiden2_cop3.sv:7 Reference (in this repo): MAME seibucop.cpp MAME seibucop_cmd.ipp MAME seibucop_dma.ipp MAME legionna.cpp
rtl/Raiden2/Raiden2_cop3.sv:57 MAME seibucop_cmd.ipp:471: execute_7e05: write_byte(0x470, read_byte(cop_regs[4])) Su DX $470 e' raidendx_cop_bank_2_w: bit 5-4 = banco FOREGROUND (bit 15-12 = banco programma, che una write a BYTE non tocca).
rtl/Raiden2/Raiden2_cop3.sv:165 Z-sorting DMA: registri $100450-$100458 (MAME cop_sort_*).
rtl/Raiden2/Raiden2_cop3.sv:178 MAME cop_itoa_digits[10]: BCD digits of cop_itoa (low<<0 | high<<16).
rtl/Raiden2/Raiden2_cop3.sv:182 Il vecchio loop a sottrazioni ripetute era O(valore) (~valore/9 clk): con i long 32-bit di godzilla (score, writer $156E/$1F93E) il 68k restava congelato (dma_busy include bcd_pending) fino a MILLISECONDI per chiamata — su MAME/HW reale i d
rtl/Raiden2/Raiden2_cop3.sv:195 MAME cop_program command table (seibucop.cpp lines 318-457) At boot, game code uploads 32 macro slots × 8 micro-op words via pgm_addr (0x100434) → slot*8 + sub-index pgm_data (0x100432) → micro-op word pgm_value (0x100438) → cop_func_valu
rtl/Raiden2/Raiden2_cop3.sv:202 MAME calls find_trigger_match(triggerval, 0xff00) to find the slot whose cop_func_trigger matches.
rtl/Raiden2/Raiden2_cop3.sv:330 Triggers (write-only addresses) MAME legionna.cpp:172 maps cop_cmd_w to $100500-$100505 (3 words).
rtl/Raiden2/Raiden2_cop3.sv:654 0x100410 sprite_dma_inc (MAME cop_sprite_dma_inc_w): if x_clip in [-160, 320): cop_regs[4] += 8.
rtl/Raiden2/Raiden2_cop3.sv:655 MA in MAME sprite_x e' uint16_t assegnato a int -> MAI negativo -> il -160 e' codice morto: check EFFETTIVO = unsigned < 320 (X "negative" 0xFFxx NON avanzano il puntatore entry).
rtl/Raiden2/Raiden2_cop3.sv:660 0 : 1 (unsigned <320 provato su HW = REGRESSIONE; il signed [-160,320) dell'intento MAME e' il comportamento giusto sul core)
rtl/Raiden2/Raiden2_cop3.sv:667 A size==0 NON wrappare (il size-- uint di MAME wrapperebbe a $FFFF: il loop del builder su status[1] andrebbe in livelock — provato peggio).
rtl/Raiden2/Raiden2_cop3.sv:718 Macro program upload — MAME seibucop.cpp lines 318-457 pgm_data writes one micro-op word to cop_program[latch_addr] AND latches the slot's trigger/value/mask from current latch regs.
rtl/Raiden2/Raiden2_cop3.sv:821 itoa_digits (MAME 0x100590-99, 5 word).
rtl/Raiden2/Raiden2_cop3.sv:833 Status / dist / angle (seibucop.cpp:916 cop_status_r → cop_status)
rtl/Raiden2/Raiden2_cop3.sv:841 MAME open bus
rtl/Raiden2/Raiden2_cop3.sv:915 commit write al dst ASSOLUTO (fill/mr), 1:1 MAME write_word(dst)
rtl/Raiden2/Raiden2_cop3.sv:951 LEGACY sprite-DMA (seibucop_cmd.ipp): 6880 (carica rel_xy), c480 (single-step: compone l'entry sprite a cop_regs[4]+offs con X/Y = rel + (obj - abs)).
rtl/Raiden2/Raiden2_cop3.sv:975 write angolo (word {0,angle} come MAME host_endian)
rtl/Raiden2/Raiden2_cop3.sv:976 5105/f105 — moltiplicatore 16.16 (ricavato da ROM+disasm, non da MAME: li' gli handler sono vuoti).
rtl/Raiden2/Raiden2_cop3.sv:988 dde5 — i PALLINI DEL RADAR (MAME LEGACY_execute_dde5).
rtl/Raiden2/Raiden2_cop3.sv:1010 ── sprite_prot / sprcpt: costruttore della display list di Raiden II ── MAME raiden2.cpp:474-503 (sprite_prot_src_w).
rtl/Raiden2/Raiden2_cop3.sv:1038 ── Registri sprite_prot ($6C0-$6DF), MAME raiden2.cpp:452-535 ──────────
rtl/Raiden2/Raiden2_cop3.sv:1075 Trigger latches — MAME seibucop.cpp cop_cmd_w line 1069.
rtl/Raiden2/Raiden2_cop3.sv:1076 MAME dispatches on raw data after clearing cop_status bit 15.
rtl/Raiden2/Raiden2_cop3.sv:1130 DMA mode 0x80-0x87: MAME dma_palette_brightness() fa FADE solo con pal_brightness_mode 4/5; con qualsiasi altro valore fa una COPIA SEMPLICE src->dst (ramo else, seibucop_dma.ipp:119-123) verso QUALUNQUE dst — incl.
rtl/Raiden2/Raiden2_cop3.sv:1138 DMA generici 0x09/0x0E: MAME write_word(dst) va nello spazio host = arriva a QUALSIASI RAM mappata, incluse le BRAM video ($101000-$105FFF: staging tilemap, palette-stage $104000, sprite $105000).
rtl/Raiden2/Raiden2_cop3.sv:1146 Output del fade/blend 0x8x: MAME dma_palette_brightness fa write_word(dst) nello SPAZIO HOST = raggiunge QUALUNQUE RAM mappata (pal-stage $104000, sprite $105800, Main RAM...).
rtl/Raiden2/Raiden2_cop3.sv:1149 Ora: pal_val registrato in D_FADE_WRITE e committato in D_FADE_COMMIT via canale fill (decode per dst assoluto in main_top: bg/fg/mg/txt/pal/spr) o mr (dst in Main RAM) — 1:1 MAME.
rtl/Raiden2/Raiden2_cop3.sv:1152 (Il vecchio dma80_to_spr era INVERTITO: il blit pietre e' src=$105800 dst=$104000, non il contrario — MAME map: $100478=SRC, $10047C=DST.)
rtl/Raiden2/Raiden2_cop3.sv:1155 LEGACY sprite-DMA state (MAME m_sprite_dma_rel_x/y, m_sprite_dma_x_clip)
rtl/Raiden2/Raiden2_cop3.sv:1170 Raiden II (raiden2.cpp:635-644): blocco contiguo $0C000-$0F7FF (SPR 4K + BG 2K + FG 2K + MG 2K + TXT 4K) piu' la palette $1F000-$1FFFF.
rtl/Raiden2/Raiden2_cop3.sv:1269 MAME cop_cmd_w (seibucop.cpp:1075):
rtl/Raiden2/Raiden2_cop3.sv:1281 MAME cop_sort_dma_trig_w -> dma_zsorting(data): n = data + 1
rtl/Raiden2/Raiden2_cop3.sv:1311 find_trigger_match (seibucop.cpp:464) Cerca slot N tale che (trigger & 0xf800) == (cop_func_trigger[N] & 0xf800) && cop_func_trigger[N] != 0.
rtl/Raiden2/Raiden2_cop3.sv:1313 Restituisce canonical trigger value del slot (NB: MAME LEGACY_cop_cmd_w usa il match slot per dispatchare; in pratica equivale a restituire cop_func_trigger[slot]).
rtl/Raiden2/Raiden2_cop3.sv:1334 fade_table — MAME seibucop.cpp:733 (reverse engineered from Seibu Cup Soccer bootleg) v = pal_channel(5-bit) | (brightness_val_xor_X) [10-bit input] low = v & 0x1F high = v & 0x3E0 return (low * (high | (high>>5)) + 0x210) >> 10 [8-bit o
rtl/Raiden2/Raiden2_cop3.sv:1373 ── Hitbox b100/b900 scratch (MAME cop_collision_update_hitbox) ────────────── dx[i] = int8 (signed) byte basso, size[i] = uint8 (unsigned) byte alto del word descrittore @ hitadr2+2*i. 3 assi (Y,X,Z) per Raiden2.
rtl/Raiden2/Raiden2_cop3.sv:1380 num_axis: MAME seibucop.cpp:1010 "if (data & 0x100) num_axis = 3" else 2.
rtl/Raiden2/Raiden2_cop3.sv:1382 res init 7 vs 3 (seibucop.cpp:1038-39).
rtl/Raiden2/Raiden2_cop3.sv:1388 Delta LATCHATI dall'ultimo comando d'angolo: il 3bb0 NON li ricalcola, li riusa (in MAME sono m_LEGACY_r0/r1, e il TODO sopra execute_3b30 dice esattamente questo).
rtl/Raiden2/Raiden2_cop3.sv:1405 dde5: divisore CON SEGNO (in MAME e' una divisione C int, quindi troncamento verso zero).
rtl/Raiden2/Raiden2_cop3.sv:1436 Con 16-bit frac + 24 iter + z>>16: 0 divergenze di decisione vs MAME int(atan(dx/dy)*128/pi) su ~640k casi (dimostrato numericamente).
rtl/Raiden2/Raiden2_cop3.sv:1709 MAME cop_dma_trigger_w: NON modifica cop_status (vedi seibucop.cpp:741).
rtl/Raiden2/Raiden2_cop3.sv:1717 MAME dma_tilemap_buffer: copy staging RAM → renderer BRAM src = cop_dma_src[mode] << 6 (byte addr 0x101000+ = staging) dst = i (loop counter 0..0x13FF = renderer index) count = 0x2800/2 = 5120 words seibucop_dma.ipp:8 — correzione SPECIFICA
rtl/Raiden2/Raiden2_cop3.sv:1733 MAME dma_palette_buffer: copy staging palette → renderer src = cop_dma_src[mode] << 6 (0x104000 = palette staging) dst = i (loop counter 0..0x7FF = renderer index) count = 0x1000/2 = 2048 words
rtl/Raiden2/Raiden2_cop3.sv:1743 MAME write_word(dst) su spazio host: con dst nelle BRAM video ($101000-$105FFF: staging/pal/spr, es.
rtl/Raiden2/Raiden2_cop3.sv:1759 simplified, MAME size>>1
rtl/Raiden2/Raiden2_cop3.sv:1764 MAME seibucop_dma.ipp dma_palette_brightness() mode 5/4.
rtl/Raiden2/Raiden2_cop3.sv:1767 MAME formulas: src = cop_dma_src[mode] << 6 dst = cop_dma_dst[mode] << 6 size = ((cop_dma_size << 5) - (cop_dma_dst << 6) + $20)/2 Init: src=$106000, dst=$104000, size=($827F<<5 - $4100<<6 + $20)/2 = ($104FE0 - $104000 + $20)/2 = $1000
rtl/Raiden2/Raiden2_cop3.sv:1778 MAME size = (((size<<5) - (dst<<6) + 0x20)/2)
rtl/Raiden2/Raiden2_cop3.sv:1784 MAME: mode 4/5 = fade palette; QUALSIASI ALTRO = copia semplice src->dst (seibucop_dma.ipp:119-123).
rtl/Raiden2/Raiden2_cop3.sv:1794 MAME seibucop.cpp cop_dma_trigger_w case 0x116 — SEIBUCUP: fill come 0x118 ma SENZA guard dst!=0 e length bytes = (size+1)<<4 (metà).
rtl/Raiden2/Raiden2_cop3.sv:1796 legionna.cpp:56-61: "The COP-MCU appears to write to the work ram area, otherwise it RESETS in mid-animation of the title screen" → senza questo fill il gioco torna al logo da solo.
rtl/Raiden2/Raiden2_cop3.sv:1807 Skip if dst != 0 (MAME guard, dma.ipp:135)
rtl/Raiden2/Raiden2_cop3.sv:1827 MAME sprite_prot_src_w (raiden2.cpp:474-503): src = (seg << 4) + data x = int16(read_dword(src+8) >> 16) - spr_x y = int16(read_dword(src+4) >> 16) - spr_y Su V30 (little-endian) la meta' ALTA di una dword sta a +2, quindi il >>16 significa
rtl/Raiden2/Raiden2_cop3.sv:1842 MAME cop_cmd_w (seibucop.cpp:1073): cop_status &= 0x7fff (clear bit 15).
rtl/Raiden2/Raiden2_cop3.sv:1844 MAME: cop_status &= 0x7fff (clear bit 15).
rtl/Raiden2/Raiden2_cop3.sv:1859 MAME LEGACY_cop_cmd_w: find_trigger_match(data, 0xF800) → slot per GRUPPO f800, poi handler dal microcodice caricato.
rtl/Raiden2/Raiden2_cop3.sv:1894 MAME execute_6200: cop_read_byte(cop_regs[0]+0x34); su V30 m_byte_endian_val=0 -> nessuno XOR -> byte host 0x34 (pari) = lane bassa della word a 0x34.
rtl/Raiden2/Raiden2_cop3.sv:1912 MAME lo esegue come una somma, quindi raddoppia il passo invece di annullarlo.
rtl/Raiden2/Raiden2_cop3.sv:1915 MAME execute_0205: read dword at cop_regs[0]+4+offset*4 (ppos)
rtl/Raiden2/Raiden2_cop3.sv:1936 0x138e / 0x338e — atan(dx/dy) MAME execute_338e.
rtl/Raiden2/Raiden2_cop3.sv:1938 Parte da r1+4 hi (offset 0x0004), come 3BB0/MAME.
rtl/Raiden2/Raiden2_cop3.sv:1969 0x2208 / 0x2288 - slot 04, MAME execute_2288 (seibucop_cmd.ipp:168) dx = read_word(cop_regs[0] + 0x12) dy = read_word(cop_regs[0] + 0x16) if(!dy){status|=0x8000; angle=0} else angle=atan(dx/dy)*128/pi, +0x80 se dy<0; if(data&0x80) write_byt
rtl/Raiden2/Raiden2_cop3.sv:2001 MAME: div = cop_read_word(r0+0x36).
rtl/Raiden2/Raiden2_cop3.sv:2049 MAME LEGACY_execute_dde5 (seibucop_cmd.ipp): offs = (offset & 3) * 4 div = read_word(cop_regs[4] + offs) dir_offset = read_word(cop_regs[4] + offs + 8) if (div == 0) div = 1 write_word(cop_regs[6] + offs + 4, (read_word(cop_reg
rtl/Raiden2/Raiden2_cop3.sv:2088 MAME: angle = word @ r0+0x34, amp = word @ r0+0x36 (V30: nessuno xor).
rtl/Raiden2/Raiden2_cop3.sv:2106 0x7E05 — SOLO Raiden DX (MAME: "raidendx only").
rtl/Raiden2/Raiden2_cop3.sv:2125 Raiden II triggera 0xa100, la famiglia legionna 0xa180: MAME (seibucop.cpp:1164-1167) dispatcha ENTRAMBI su execute_a100.
rtl/Raiden2/Raiden2_cop3.sv:2127 allow_swap = data & 0x0080 (seibucop_cmd.ipp:537-540): 0 per a100, 1 per a180 — NON e' costante, va preso dal bit 7.
rtl/Raiden2/Raiden2_cop3.sv:2129 MAME cop_collision_read_pos: cop_read_word(spradr+N) = host_read_word((spradr+N)^m_word_endian_val).
rtl/Raiden2/Raiden2_cop3.sv:2130 Su V30 il valore e' 0 (seibucop.cpp:291-297): flags @ host+2, pos[i] @ host+6+4i.
rtl/Raiden2/Raiden2_cop3.sv:2140 Raiden II triggera 0xa900 (seibucop.cpp:1169-1172 e :625); allow_swap = data & 0x0080 (seibucop_cmd.ipp:548-551).
rtl/Raiden2/Raiden2_cop3.sv:2153 b000 NON e' un no-op: il dispatcher LEGACY di godzilla (seibucop.cpp:1365) matcha con mask 0xf800, quindi la patch init_godzilla (b100->b000) ESEGUE comunque l'update ma con num_axis=2 (bit8=0 = Z disattivata).
rtl/Raiden2/Raiden2_cop3.sv:2175 MAME execute_2a05 (seibucop_cmd.ipp:193): delta = read_word (cop_regs[1] + 0x1e + offset*4) *(cop_regs[0] + 4 + 2 + offset*4) += delta *(cop_regs[0] + 0x1e + offset*4) += delta Le write_dword di MAME su una somma a 16 bit sono una svista
rtl/Raiden2/Raiden2_cop3.sv:2313 Mode 4 (SEIBUCUP/Denjin, seibucop_dma.ipp:87-117): indice = (val*2)[4:0], val 0x0010/0xFFFF = TARGET PURO, NESSUN bypass bit15.
rtl/Raiden2/Raiden2_cop3.sv:2360 MAME: m_host_space->write_word(dst, pal_val) — dst ASSOLUTO.
rtl/Raiden2/Raiden2_cop3.sv:2402 MAME (0x118 e 0x116): write_dword(i, v1 | v2<<16) su spazio LE V30 → word a i = v1, word a i+2 = v2 (alternati; su 68k BE era l'opposto).
rtl/Raiden2/Raiden2_cop3.sv:2415 Macro 0x0205 — linear movement (MAME execute_0205) ppos = read_dword(cop_regs[0]+0x04) vel = read_dword(cop_regs[0]+0x10) npos = ppos + vel write_dword(cop_regs[0]+0x04, npos) delta = (npos>>16) - (ppos>>16) write_word(cop_regs[0]+0x1E, re
rtl/Raiden2/Raiden2_cop3.sv:2473 MAME cop_read/write_word(cop_regs[0]+0x1e).
rtl/Raiden2/Raiden2_cop3.sv:2493 Macro 0x0905/0x0904 — jump (MAME execute_0904) write_dword(cop_regs[0]+0x10, read_dword(cop_regs[0]+0x10) ± read_dword(cop_regs[0]+0x28)) 0x0905 (bit 0=1) = +, 0x0904 (bit 0=0) = -
rtl/Raiden2/Raiden2_cop3.sv:2519 MAME execute_0904: bit 0 di data = 1 → add, =0 → sub.
rtl/Raiden2/Raiden2_cop3.sv:2552 0x138E/0x338E atan(dx/dy) — MAME execute_338e (cmd.ipp:159) dx = read_dword(r1+4) - read_dword(r0+4) dy = read_dword(r1+8) - read_dword(r0+8) if(!dy){status|=0x8000; angle=0} else angle=atan(dx/dy)*128/pi; dy<0→+0x80 if(data&0x80) write_byt
rtl/Raiden2/Raiden2_cop3.sv:2603 MAME: angle = atan(dx/dy)*128/pi (+0x80 se dy<0).
rtl/Raiden2/Raiden2_cop3.sv:2605 Cosi' z = atan(dx/dy) e il +0x80 (in WR) copre solo il quadrante, come MAME.
rtl/Raiden2/Raiden2_cop3.sv:2607 NIENTE prescale: i dword diff sono FIXED-POINT coord<<16 (come il 3BB0 che usa dx32[31:16] e MAME dx>>16), NON interi piccoli.
rtl/Raiden2/Raiden2_cop3.sv:2656 MAME (int)(...) tronca VERSO ZERO.
rtl/Raiden2/Raiden2_cop3.sv:2658 BUG TROVATO (validato vs MAME su 29241 casi): il CORDIC SOTTO-CONVERGE di 1 LSB sulle DIAGONALI (es.
rtl/Raiden2/Raiden2_cop3.sv:2663 Compenso l'epsilon di sotto-convergenza con +1 toward-zero PRIMA del troncamento: bias=1 azzera tutte le 133 divergenze (bias=0) -> 0/29241 vs MAME.
rtl/Raiden2/Raiden2_cop3.sv:2672 MAME execute_338e (seibucop_cmd.ipp:175-188): la write dell'angolo in RAM (obj+0x34 host, gated da data&0x80) e' FUORI dall'if/else di dy -> avviene SEMPRE, anche a dy==0 (dove cop_angle=0 -> scrive 0^0x80 = 0x80).
rtl/Raiden2/Raiden2_cop3.sv:2678 Ora calcolo ang_byte in entrambi i rami e scrivo SEMPRE, come MAME.
rtl/Raiden2/Raiden2_cop3.sv:2685 Scrivere l'angolo anche a dy==0 ("1:1 MAME") REGREDISCE: il martello scivola/moonwalk.
rtl/Raiden2/Raiden2_cop3.sv:2688 MAME: dy==0 -> cop_angle=0
rtl/Raiden2/Raiden2_cop3.sv:2695 Il chip lavora in PIXEL: le tabelle del bootleg mettono distanza e angolo nella STESSA word, indicizzata da (A<<9)|B con A,B a 9 bit (la documentazione del progetto), e il nostro stesso 3bb0 tronca gia' i delta con dx32[31:16] (come MAME m_
rtl/Raiden2/Raiden2_cop3.sv:2706 Stesso difetto in MAME (if (!dx) sui 32 bit), da cui il sintomo identico nei due emulatori.
rtl/Raiden2/Raiden2_cop3.sv:2714 118e/e18e len 4 -> caricano solo dx/dy: NON scrivono 130e/e30e len 7 -> calcolano l'angolo, non lo scrivono 138e/e38e len 8 -> scrivono Con la regola del bit 7 (quella di MAME) e18e sovrascrive obj+$37 su tutti gli oggetti ogni frame, fra i
rtl/Raiden2/Raiden2_cop3.sv:2725 SEIBUCUP: write RAW — il ROM carica il microcode 138e variante cupsoc/SDGundam (tabella $498: ...b9a b9a A9A) = MAME LEGACY_execute_130e_cupsoc, SENZA ^0x80 (il ^0x80 e' della variante famiglia $B9A / is_yflip: legionna).
rtl/Raiden2/Raiden2_cop3.sv:2729 PROVA sim 8 casi: col ^0x80 vettore sincos INVERTITO 180° vs MAME → boss 138e-driven marcia via (stage 4).
rtl/Raiden2/Raiden2_cop3.sv:2731 ⛔ NON toccare il sincos (lookup diretto = sin MAME): toccarlo inverte i game-written = regressione build 13.
rtl/Raiden2/Raiden2_cop3.sv:2744 0x2208 / 0x2288 (slot 04) - MAME execute_2288 (seibucop_cmd.ipp:168) Microcodice ROM: f8a b8a 388 b9a b9a a9a (valu 5, mask f5df).
rtl/Raiden2/Raiden2_cop3.sv:2749 MAME li mette in un int partendo da read_word() che ritorna uint16 -> zero-esteso -> il suo stesso 'if (dy < 0)' e' codice MORTO e l'angolo cade sempre nel primo quadrante.
rtl/Raiden2/Raiden2_cop3.sv:2837 MAME: !dy -> cop_status |= 0x8000, cop_angle = 0.
rtl/Raiden2/Raiden2_cop3.sv:2847 La write in RAM dipende dal bit 7 del trigger (MAME data&0x80), che qui coincide con la regola della LUNGHEZZA usata dal 138e: len = ((cmd>>7)&7)+1 -> 2288 len 6 = esegue anche l'ultima word 'a9a' (lo store), 2208 len 5 si ferma prima.
rtl/Raiden2/Raiden2_cop3.sv:2865 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197) dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (aritmetico) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = sqrt(dx*dx + dy*dy) if(data&0x80) write_word(r0 + (data&0x200?0x3a:0x38
rtl/Raiden2/Raiden2_cop3.sv:2932 E' il TODO dichiarato in MAME.
rtl/Raiden2/Raiden2_cop3.sv:2984 MAME: macro completata → cop_status = 7 (gate-poll del gioco).
rtl/Raiden2/Raiden2_cop3.sv:3050 MAME: if (div == 0) div = 1
rtl/Raiden2/Raiden2_cop3.sv:3061 In MAME read_word e' unsigned e dir_offset int16_t: la somma e' int, la divisione int/int -> troncamento VERSO ZERO.
rtl/Raiden2/Raiden2_cop3.sv:3125 0x8100/0x8900 sin/cos (MAME execute_8100/8900) raw_angle = cop_read_word(cop_regs[0]+0x34) & 0xff amp = (65536>>5) * (cop_read_word(cop_regs[0]+0x36) & 0xff) = 2048 * amp_byte if (raw_angle == 0xC0 sin / 0x80 cos): amp *= 2 res = int(
rtl/Raiden2/Raiden2_cop3.sv:3175 MAME special-case: sin && raw==0xC0 OR cos && raw==0x80 → amp *= 2
rtl/Raiden2/Raiden2_cop3.sv:3202 ── write_dword su V30 LITTLE-ENDIAN (2026-08-14) ────────────── MAME: write_dword(cop_regs[0]+0x10 sin / +0x14 cos, res).
rtl/Raiden2/Raiden2_cop3.sv:3210 PROVA DAL ROM (non da MAME): dopo OGNI 8100 il gioco esegue `sar word [bp+0x12],1` + `rcr word [bp+0x10],1` ($0AB121, $0A6D0B) = shift aritmetico a 32 bit con la word ALTA a +0x12; idem `sar [bp+0x16]`/`rcr [bp+0x14]` dopo ogni 8900.
rtl/Raiden2/Raiden2_cop3.sv:3237 0xa180/0xa980 — read pos (MAME cop_collision_read_pos) flags_swap = cop_read_word(spradr+2) → host_read_word(spradr+0) pos[0] = cop_read_word(spradr+6) → host_read_word(spradr+4) pos[1] = cop_read_word(spradr+10) → host_read_word(
rtl/Raiden2/Raiden2_cop3.sv:3244 Però MAME cop_read_word(+2) = host_read_word(+2^2) = host_read_word(+0).
rtl/Raiden2/Raiden2_cop3.sv:3255 rdata = word @ host+0 = flags (MAME cop_read_word(spradr+2) ^ 2).
rtl/Raiden2/Raiden2_cop3.sv:3264 rdata = word @ host+4 = pos[0] (Y axis per MAME)
rtl/Raiden2/Raiden2_cop3.sv:3284 0xb100/0xb900 — update hitbox & compute intersection (1:1 MAME cop_collision_update_hitbox, seibucop.cpp:1003-1065).
rtl/Raiden2/Raiden2_cop3.sv:3293 V30: extraxor=0 (seibucop.cpp:1008) e read_byte(pari)=lane bassa → stesse lane del 68k (extraxor=1 + read_byte(pari)=lane alta): NON toccare.
rtl/Raiden2/Raiden2_cop3.sv:3326 2 assi (b000/b800): terza word NON letta, dx/size azzerati (seibucop.cpp:1014-1022)
rtl/Raiden2/Raiden2_cop3.sv:3359 2 assi: l'asse 2 (Z) NON viene aggiornato (loop MAME i<num_axis)
rtl/Raiden2/Raiden2_cop3.sv:3378 res init: 3 assi = 111, 2 assi = 011 (seibucop.cpp:1038-39: bit Z gia' 0 = "collide banale" -> hit deciso solo da X/Y)
rtl/Raiden2/Raiden2_cop3.sv:3402 LEGACY 6880 — carica rel_xy per il prossimo c480 (MAME LEGACY_execute_6980: rel_xy = read_word(spr_src+4+offs))
rtl/Raiden2/Raiden2_cop3.sv:3423 LEGACY c480 — single-step sprite DMA (MAME LEGACY_execute_c480): info = read(spr_src+offs) + (param & 0x3f) -> entry+0 abs = read(regs[0]+8/+4) - spr_dma_abs_x/y X(fx/dx/rel_x) -> entry+4 (+ x_clip per l'inc $410) Y(fy/rel_y) -> entry+6
rtl/Raiden2/Raiden2_cop3.sv:3538 E' la variante FAMIGLIA => MAME execute_6200 (seibucop_cmd.ipp:337), primary_reg=0 / primary_offset=0x34.
rtl/Raiden2/Raiden2_cop3.sv:3567 wrap a signed 8-bit (MAME: +=/-=256 su int)
rtl/Raiden2/Raiden2_cop3.sv:3592 MAME execute_6200: cop_write_byte(cop_regs[0]+0x34).
rtl/Raiden2/Raiden2_cop3.sv:3603 5105 / f105 — MOLTIPLICATORE 16.16 (nessun handler in MAME: ricavato da ROM + disasm di cupsoc).
rtl/Raiden2/Raiden2_cop3.sv:3689 Z-sorting DMA ($1006FE) — MAME dma_zsorting (seibucop_dma.ipp:164) n = data+1 val = read_word(lookup + 2*i) (RAW, senza xor) key = (int16)cop_read_word(sort_ram + val) (host (addr)^2, CON SEGNO) param 1 = crescente, 2 =
rtl/Raiden2/Raiden2_cop3.sv:3732 Bubble sort: swap SOLO se strettamente fuori ordine = stabile come lo std::stable_sort di MAME.
rtl/Raiden2/Raiden2_cop3.sv:3749 (Difetto presente da sempre, anche nel core _old: li' la parte COP della lista cadeva in Main RAM e la sua assenza non si notava.) Ora ogni emissione e' spostata di uno stato in avanti, cosi' il latch allo stato N+2 riceve esattamente il ca
rtl/Raiden2/Raiden2_main_top.sv:246 Raiden DX: il banco programma lo scrivono DUE registri e vale l'ULTIMO (MAME: raiden2_bank_w da $6CB fa set_entry(BIT(~data,7)), raidendx_cop_bank_2_w da $470 fa set_entry(cop_bank>>12); su DX restano mappati entrambi).
rtl/Raiden2/Raiden2_main_top.sv:259 MAME riapplica anche set_entry(cop_bank>>12), che una write a byte non cambia: qui basta marcare che l'ultimo a scrivere il banco e' $470.
rtl/Raiden2/Raiden2_main_top.sv:269 Packing banchi tile (raiden2_v.cpp, trascritto dalla _old maincpu_map): $6CC byte basso: bg = (d&1)<<1 → 0/2 ; mid = 1|(d&2) → 1/3 $470 byte alto : fg = 4|(d>>14) → 4..7 (aggiornato solo con be[1], qui ricomposto dal registro cop_bank già l
rtl/Raiden2/Raiden2_main_top.sv:282 fg SOLO su write $470 be[1] (semantica commit/MAME: bank_reset tiene fg=6 finche' il gioco non scrive cbank; ricalcolarlo ogni clock lo forzava a 4 subito dopo il reset).
rtl/Raiden2/Raiden2_main_top.sv:286 Raiden DX : fg = 4 | ((cop_bank>>4)&3) -> bit 5-4, e MAME lo aggiorna a OGNI write di $470 (raiden2_v.cpp raidendx_cop_bank_2_w).
rtl/Raiden2/Raiden2_main_top.sv:303 ─── Latch buffered spriteram: write CPU a $68E (raiden2.cpp:623) ─────── NON a vblank come Raiden 1: e' il GIOCO a decidere quando fotografare la lista sprite.
rtl/Raiden2/Raiden2_main_top.sv:426 MAME raiden2.cpp:1126-1127: irq0_line_hold + vector_r 0xC0/4.
rtl/Raiden2/Raiden2_main_top.sv:535 Raiden II: la copia nel buffer parte dalla write CPU a $68E, non dal vblank (BUFFERED_SPRITERAM16 comandata dal gioco, raiden2.cpp:623).
rtl/Raiden2/Raiden2_main_top.sv:551 Equivale a MAME tilemap render fine-frame.
rtl/Raiden2/Raiden2_main_top.sv:655 ── SPLIT STAGING/RENDER (semantica MAME 2-stadi, pattern _old) ──────── STAGING (array qui sotto) = host RAM: porta A = CPU (+fill COP), porta B = sorgente del DMA.
rtl/Raiden2/Raiden2_main_top.sv:657 RENDERER (array _rend) = scritti SOLO dal DMA 0x14/0x15, letti dal video: coppia contenuto/scroll atomica come MAME.
rtl/Raiden2/Raiden2_main_top.sv:1016 ─── control_w $0E006 (8-bit) ────────────────────────────────────────── MAME bit 0: BG dis, bit 1: FG dis, bit 2: TX dis, bit 3: SPR dis bit 6: flipscreen
rtl/Raiden2/Raiden2_main_top.sv:1031 ─── Sound seibu ($00700-$0071F, 8-bit umask 00FF) ───────────────────── MAME main_r/main_w(offset>>1): registro seibu = (byte-$700)/4 = cpu_addr[4:2] (fix coin della _old: con [4:1] ogni registro tranne 0 era misaddressato e la coin non ven
rtl/Raiden2/Raiden2_seibu_crtc.sv:23 Seibu CRTC fedele a MAME (seibu_crtc.cpp).
rtl/Raiden2/Raiden2_seibu_crtc.sv:55 Raiden DX / Sky Smasher: registri [0x10] e [0x20] SCAMBIATI (MAME seibu_crtc.cpp read_alt/write_alt).
rtl/Raiden2/Raiden2_seibu_crtc.sv:177 MAME mappa: bit0=screen0(BG), bit1=screen2(MG), bit2=screen1(FG), bit3=screen3(Text) (vedi seibu_crtc.cpp commento "screen 0=BG, screen 1=FG, screen 2=MG, screen 3=Text") In SD Gundam dcon.cpp layer_en_w gira la maschera così: ~layer_en bit
rtl/Raiden2/Raiden2_seibu_crtc.sv:186 Il dispatcher MAME usa "if (BIT(~m_layer_en, n))" per saltare = layer disabilitato quando il bit è 1.
rtl/Raiden2/Raiden2_seibu_crtc.sv:191 Raiden2 layer ordering (legionna_v.cpp:384-390 screen_update_SEIBUCUP): bit 0 = BG (background) bit 1 = MG (midground) bit 2 = FG (foreground) bit 3 = Text bit 4 = Sprites ATTENZIONE: e' l'OPPOSTO di legionna (screen_update_legionna :342-34
rtl/Raiden2/Raiden2_seibu_crtc.sv:212 Scroll-base 0x2C-0x3A (seibu_crtc.cpp:243 layer_scroll_base_w; screen0=BG, screen2=MG, screen1=FG, screen3=Text).
rtl/Raiden2/Raiden2_seibu_crtc.sv:213 Raw esce qui; le formule (delta vs riferimento godzilla, Y invertita come il set_scrolldy(0x1ef-data) di MAME) stanno nel top.
rtl/Raiden2/Raiden2_sprite_renderer.sv:25 Formato spriteram quasi identico (entrambi MAME sei021x_sei0220_spr.cpp) — differenze: - Spriteram @ 0x105000-0x105FFF (4KB, 1024 word, 256 entry × 4 word) - w3 bit 15 = tile bank extra bit (denjinmk usa, Raiden2 base = 0)
rtl/Raiden2/Raiden2_sprite_renderer.sv:30 Format word (legionna_v.cpp:288-312): w0 bit 15 = enable (0=draw, 1=skip — TODO verify Raiden2) w0 bit 14 = flip_x w0 bit 13 = flip_y (???
rtl/Raiden2/Raiden2_sprite_renderer.sv:46 Priority callback legionna_v.cpp:314-317: pri_mask[0] = 0x0000 (sopra tutto) pri_mask[1] = 0xFFF0 pri_mask[2] = 0xFFFC pri_mask[3] = 0xFFFE
rtl/Raiden2/Raiden2_sprite_renderer.sv:139 CUPSOC: spriteram 2KB → 256 entry (MAME size/2/4 = 2048/2/4 = 256).
rtl/Raiden2/Raiden2_sprite_renderer.sv:145 Decoded fields — MAME sei0210_device::draw (non-alt format, riga 143): if (BIT(~spriteram[i], 15)) continue; → draw quando w0[15]==1.
rtl/Raiden2/Raiden2_sprite_renderer.sv:147 ─── Formato SEI25X_RISE1X (MAME sei25x_rise1x_spr.cpp:88-101) ────────── Raiden II NON usa il formato SEI0211 della famiglia legionna: i campi stanno su bit diversi.
rtl/Raiden2/Raiden2_sprite_renderer.sv:162 cupsoc_pri_cb (legionna_v.cpp:319): pri = (w1[15:14] & 2) | (ext & 1) → livello = {w1[15], w0[6]}.
rtl/Raiden2/Raiden2_sprite_renderer.sv:165 CUPSOC: pri_cb STANDARD (legionna_v.cpp pri_cb = mask[pri]) → livello = w1[15:14] pieno, NON il {w1[15],ext} di grainbow (che ha un pri_cb suo).
rtl/Raiden2/Raiden2_sprite_renderer.sv:181 MAME SEI0211 default m_xoffset/m_yoffset = 0 (sei021x_sei0220_spr.cpp:40-41).
rtl/Raiden2/Raiden2_sprite_renderer.sv:182 Raiden2 NON chiama set_offset (legionna.cpp:1214) → offset 0,0.
rtl/Raiden2/Raiden2_sprite_renderer.sv:221 Tile code finale Y-MAJOR (MAME draw_internal: ax=outer, ay=inner, code++): sub_index = ax*sizey + ay → cur_tile = code + eff_tile_x*sp_h + eff_tile_y Raiden II: NESSUN gfxbank_cb in raiden2.cpp -> il codice va usato tale e quale, ed e' a
rtl/Raiden2/Raiden2_sprite_renderer.sv:237 byte_lo = pf_rom_data[31:24]/[15:8], byte_hi = [23:16]/[7:0] Raiden II NON usa il tilelayout planare della famiglia legionna: usa gfx_16x16x4_packed_lsb (raiden2.cpp:1058), cioe' 4bpp PACKED, un nibble per pixel, 8 byte per riga da 16 pixel
rtl/Raiden2/Raiden2_sprite_renderer.sv:241 Con readbit() di MAME (0x80>>(bit%8)), planeoffset {0,1,2,3} e xoffset {1*4,0*4,3*4,2*4,...}: pixel PARI = nibble BASSO del byte, pixel DISPARI = nibble ALTO dello stesso byte, senza rimescolare bit.
rtl/Raiden2/Raiden2_sprite_renderer.sv:705 MAME gfx_legionna_spr: color base = 64*16 = 0x400 (64 colorset × 16 pen).
rtl/Raiden2/Raiden2_text_renderer.sv:25 Specifiche da MAME (legionna.cpp:1117-1126, 1167):
rtl/Raiden2/Raiden2_text_renderer.sv:47 Char ROM in MAME: "char" region 64KB = ROM_COPY user1[0x10000..0x1FFFF].
rtl/Raiden2/Raiden2_tile_layer.sv:25 Differenze fra layer (da MAME dcon.cpp):
rtl/Raiden2/Raiden2_tile_layer.sv:58 BB FG hardcoded +0x1000 (MAME bloodbro fg_tile_info)
rtl/Raiden2/Raiden2_tile_layer.sv:243 Tile index con eventuale gfx_bank (MG ha bit 12 = 13-bit totali, BG/FG = 12 bit) + TILE_CODE_OFS hardcoded (BB FG aggiunge 0x1000 secondo MAME bloodbro fg_tile_info).
rtl/Raiden2/Raiden2_tile_layer.sv:310 rom_addr = tile_idx*128 + banco*0x80000 + side_off + row*4 Raiden II: tile = (vram & 0xfff) | (bank << 12) -> 15 bit (raiden2_v.cpp:162-190 get_back/mid/fore_tile_info; bank 0..7 = 32768 tile = la region "tiles" da 4MB, unica per i 3 layer)
rtl/Raiden2/Raiden2_video_timing.sv:25 RAIDEN II — timing dal driver MAME (raiden2.cpp:1134): screen.set_raw(XTAL(32'000'000)/4, 512, 0, 40*8, 282, 0, 30*8) cioe' pixel clock 8.000 MHz, 512x282 totali, 320x240 visibili con blanking che parte da 0 su entrambi gli assi (nessuna fi
rtl/Raiden2/Raiden2_video_timing.sv:67 ── Pixel clock enable: 96 MHz / 12 = 8.000 MHz ───────────────────────── Raiden II reale (raiden2.cpp:1134 set_raw): XTAL(32 MHz)/4 = 8 MHz.
rtl/Raiden2/Raiden2_video_timing.sv:90 ── Constants timing ───────────────────────────────────────────────────── MAME raiden2.cpp:1134 screen.set_raw(XTAL(32'000'000)/4, 512, 0, 40*8, 282, 0, 30*8) = pixel clock 8.000 MHz, 512x282 totali, 320x240 visibili.
rtl/Raiden2/crypt/raiden2_sprite_decrypt.sv:4 Trascritto da MAME src/mame/seibu/r2crypt.cpp (raiden2_decrypt_sprites + core_decrypt) e seibu_helper.cpp (seibu_partial_carry_sum).
rtl/Raiden2/crypt/raiden2_sprite_decrypt.sv:29 ─── Tabelle (estratte da r2crypt.cpp) ──────────────────────────────────
rtl/Raiden2/crypt/raiden2_sprite_decrypt.sv:116 ─── somma con riporto parziale (seibu_helper.cpp:12) ─────────────────── Il riporto propaga solo dove CARRY_MASK ha 1; il riporto finale rientra in XOR sul bit 0.
rtl/Raiden2/ddram_sprite.sv:58 NIENTE swap per Raiden II: la region "sprites" e' ROM_REGION32_LE nativa e il download scrive gia' plain[15:0] a +0 e plain[31:16] a +2, quindi la dword in DDR3 e' identica a quella di MAME.
rtl/Raiden2/raiden2_addr_main.sv:5 Mappa MAME raiden2_mem (raiden2.cpp:626-646), fine-decode del blocco $400-$7FF trascritto dalla maincpu_map della repo _old (quella che bootava): $00000-$003FF RAM (IVT) → ram_memrq $00400-$006FF COP SEI300
rtl/Raiden2/raiden2_addr_main.sv:45 Raiden DX: mappa programma DIVERSA (MAME raidendx_mem).
rtl/Raiden2/raiden2_mixer.sv:11 MODELLO (MAME raiden2_v.cpp screen_update + blend_layer): si parte dal fondale NERO e si attraversano gli 8 livelli dal FONDO in avanti — spr0, BG, spr1, MG, spr2, FG, spr3, TEXT.
rtl/Raiden2/raiden2_mixer.sv:48 ── tabella: quali indici si mescolano (127 su 2048, da MAME) ─────────── PERCORSO ESPLICITO IN SINTESI: col nome nudo Quartus non la troverebbe (nessun SEARCH_PATH copre rtl/Raiden2) e resterebbe TUTTA A ZERO, cioe' blending inerte sul sili
rtl/Raiden2/raiden2_mixer.sv:79 palette xBGR_555 -> RGB888 (espansione MAME palette_device)
rtl/Raiden2/raiden2_mixer.sv:135 Trovato dal test contro il modello MAME (sim/tb_mixer.cpp).
rtl/Raiden2/raiden2_shared_ram.sv:19 MAME memory map: Main: $08000-$08FFF Sub : $04000-$04FFF
rtl/Raiden2/raiden2_sprite_mainbus.sv:4 Raiden sprite RAM bus (pattern Irem M72 board_b_d-style + BUFFERED_SPRITERAM16) Gestisce spriteram (Main side, $07000-$07FFF, 4KB = 2K word) con: - Porta A: Main V30 R/W - Buffer: copia spriteram → buf su rising vblank (MAME BUFFERED_SPRITE
rtl/Raiden2/raiden2_sprite_mainbus.sv:10 MAME memory map Main: $07000-$07FFF spriteram (4KB) — share "spriteram" (BUFFERED_SPRITERAM16)
rtl/Raiden2/raiden2_sprite_mainbus.sv:110 Copy FSM: trigger = vblank_rising (nel top = sprbuf_trig, write CPU $68E, BUFFERED_SPRITERAM16 come MAME).
rtl/Raiden2/sdram_bridge.sv:46 condivisa da BG, MG e FG (raiden2.cpp: i tre layer 16x16 indicizzano tutti gfx 1 con tile 15 bit) 0x290000-0x2AFFFF: OKI1 256KB (ioctl byte 0x520000) Totale 5.5MB sugli 8MB della finestra.
rtl/Raiden2/sdram_bridge.sv:325 --- FG address descramble (legionna.cpp:1129 descramble_legionnaire_gfx) --- MAME applica un bitswap<24> agli indirizzi della ROM "fore" durante init: src_descrambled[i] = src_raw[bitswap<24>(i, ...
rtl/Raiden2/sdram_bridge.sv:372 bitswap MAME del byte offset
rtl/Raiden2/sei80bu.v:4 sei80bu - SEI80BU Encrypted Z80 Interface Implementazione esatta da MAME mame/src/devices/machine/sei80bu.cpp: - data_r: 5 XOR + 2 bitswap (sempre) - opcode_r: 8 XOR + 4 bitswap (data + 3 XOR e 2 bitswap extra solo M1) Determinato runti
README.md:13 This core reimplements the hardware in SystemVerilog from MAME references, the ROM microcode tables and hardware observation.

Says it matches, follows or was checked against MAME — 7

Raiden2.sv:192 Offset layer COPIATI dalla _old (video HW-perfetto, Raiden2.sv:446-463): TRIM0 = 0 per TUTTI i layer ("esattamente il valore con cui il core girava"), sprite xoff = -1 ("base famiglia, match MAME su HW"), txt xoff = -1.
Raiden2.sv:1483 Provato contro un modello scritto dal codice MAME: sim/tb_mixer.cpp, 20000 pixel, ZERO differenze (1957 casi con piu' trasparenze sovrapposte).
rtl/Raiden2/Raiden2_cop3.sv:1854 LEGACY sprite-DMA (match a maschera, MAME find_trigger_match): c480 mask $FF00 -> qualunque c4xx; 6880 mask $FFF3.
rtl/Raiden2/Raiden2_cop3.sv:3190 res = prod >> 4 (= /16 per matchare formula MAME 2048/32768 = 1/16)
rtl/Raiden2/Raiden2_cop3.sv:3713 Verificato in gioco su MAME il 2026-07-29.
rtl/Raiden2/Raiden2_sprite_renderer.sv:183 +1 pixel a destra: offset verificato con pixel hunting su MAME (rmonic79).
README.md:129 The implementation here (`Raiden2_cop3.sv`) was written from those tables and checked command by command against MAME, including the DMA modes, the sorting used

Says it was translated, ported or taken from MAME — 2

rtl/Raiden2/Raiden2_cop3.sv:2873 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197): 1:1 dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (signed) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = floor(sqrt(dx*dx + dy*dy)) if(data&0x80) write_word(r0+(data&0x200?0x3
rtl/Raiden2/Raiden2_cop3.sv:2993 0x42C2/0x4AA0 divide — MAME execute_42c2/4aa0 (cmd.ipp:219/247): 1:1 DIVIDEND = cop_dist << (5 - cop_scale) (cop_scale 0..3 → shift 5..2) 42c2: div=cop_read_word(r0+0x36)→host 0x36; if(!div){status|=0x8000; write 0 a host 0x38} else write

Keeps a MAME approximation — 1

rtl/Raiden2/Raiden2_cop3.sv:253 MAME usa total_cycles%256 (surrogato dell'RNG hw ignoto): l'LFSR e' un surrogato equivalente ma robusto alle letture regolari.

Shares text with the MAME driver without saying so — 6

rtl/Raiden2/Raiden2_main_top.sv:273 Reset MAME bank_reset(0,6,1,0): bg=0 fg=6 mid=1. — shares text with seibu/raiden2.cpp:411
rtl/Raiden2/Raiden2_text_renderer.sv:23 Text layer renderer Seibu Raiden2 (8x8, 4bpp, 64x32). Specifiche da MAME (legionna.cpp:1117-1126, 1167): // charlayout 8x8, RGN_FRAC(1,1), 4 b — shares text with seibu/raiden2_v.cpp
rtl/Raiden2/Raiden2_video_timing.sv:23 Video timing single-screen Seibu D-Con. RAIDEN II — timing dal driver MAME (raiden2.cpp:1134): screen.set_raw(XTAL(32'000'000)/4, 512, 0, 40*8, 282 — shares text with seibu/raiden2.cpp:1134
rtl/Raiden2/Raiden2_video_timing.sv:92 screen.set_raw(XTAL(32'000'000)/4, 512, 0, 40*8, 282, 0, 30*8) — shares text with seibu/raiden2.cpp:1134
rtl/Raiden2/crypt/raiden2_sprite_decrypt.sv:13 x1lo = (x5[i2] << 11) ^ x11[i3] ^ gm(i4) — shares text with seibu/r2crypt.cpp:211
rtl/Raiden2/sdram_bridge.sv:327 src_descrambled[i] = src_raw[bitswap<24>(i, ... 6,5,15,14,13,12, 11,10,9,8, 7,4, 3..0)] — shares text with seibu/seibu_crtc.cpp:338

RallyX#
New Rally-X, Rally-X
MiSTer-devel/Arcade-RallyX_MiSTer @ abd3c384
MAME compared: namco/rallyx.cpp + 4 related file(s)
Read: 16 HDL files, 5,598 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 2 toward MAME

Cites MAME source — 2

rtl/nrx_bang.v:4 Fixed-point approximation of the Rally-X discrete explosion circuit modeled in MAME PR 15424.
README.md:27 copy ROM zip files to /media/fat/_Arcade/mame

Rampart#
Rampart
MiSTer-devel/Arcade-Rampart_MiSTer @ 01b708d0
MAME compared: atari/rampart.cpp + 4 related file(s)
Read: 39 HDL files, 5,176 lines (Quartus project)

MiSTer official

Both

medium

55%

Statements: 19 toward hardware, 31 toward MAME, 14 not counted

Cites hardware documentation that MAME's driver does not — 18

rtl/main/rampart_decode.sv:3 Main CPU address decode: GAL 12C and the two LS138s, 10C and 11C.
rtl/main/rampart_decode.sv:67 10C 74LS138: enabled by /A22; C B A = pins 19 18 17.
rtl/main/rampart_decode.sv:80 11C 74LS138: enabled by A22 and /IOSEL; C B A = A21 A20 A19.
rtl/main/rampart_eeprom.sv:3 EEPROM at 13F (2K x 8, 2816 class) and its write-unlock flop.
rtl/main/rampart_gal12c.sv:8 The board build decides which part is fitted: variant 0 = 136082-1006 (set rampart, trackballs: 2 x 64K + 2 x 512K ROMs) variant 1 = 136082-1056 (set rampart2p, joysticks: 2 x 128K + 2 x 512K ROMs) variant 2 = 136082-1005 (sets rampart2pa a
rtl/main/rampart_inputs.sv:3 Switch inputs IN0/IN1: the 74LS257 pair at 10B/11B, read at 0x640000.
rtl/main/rampart_latch.sv:3 Output latches at 0x640000: 7B 74LS273 (D15-8) and 6C 74LS174 (D5-0).
rtl/main/rampart_main.sv:88 ---- latch 7B/6C ----
rtl/main/rampart_watchdog.sv:3 Reset counter and watchdog: the 74LS197 at 7D.
rtl/video/rampart_gal4l.sv:7 Generated from the chip's fuse map (jedutil -view), one assign per output, terms in the fuse-map order.
rtl/video/rampart_gal7k.sv:7 Generated from the chip's fuse map (jedutil -view), one assign per output, terms in the fuse-map order.
rtl/video/rampart_gal8j.sv:7 Generated from the chip's fuse map (jedutil -view), one assign per output, terms in the fuse-map order.
rtl/video/rampart_gal8m.sv:7 Generated from the chip's fuse map (jedutil -view), one assign per output, terms in the fuse-map order.
rtl/video/rampart_lb.sv:3 Rampart motion-object line buffer: the Lb custom 137536-001 at 1F/H.
rtl/video/rampart_mix.sv:7 The priority PAL socket at 2J is empty on production boards, so the mux takes the motion object whenever its pen is not 0.
rtl/video/rampart_mob.sv:3 Rampart motion-object processor: the MOB 137593-001 at 2K/L.
rtl/video/rampart_sos2.sv:3 Rampart raster counters: the H count that feeds the 7K GAL and the vertical side of the SOS-2 sync generator (Atari 137550-001, 11K/L).
README.md:15 The address decoding and the video timing are transcribed from the board's own GAL chips, and the inputs, reset and watchdog, sync, colour output and sound circ

Cites hardware references or measurements that MAME's driver also gives — 14

Arcade-Rampart.sv:150 0x460800 0x000002 12C GAL variant code, input panel code — also in MAME: 12C atari/rampart.cpp:531
rtl/main/rampart_gal12c.sv:3 GAL16V8 at 12C: the main CPU address decoder. — also in MAME: 12C atari/rampart.cpp:531
rtl/main/rampart_slapstic.sv:16 /CS = A18 & /A19 & A20 & /A21 (from the 12C GAL): 0x140000- 0x17FFFF and its mirrors. — also in MAME: 12C atari/rampart.cpp:531
rtl/mem/rampart_rom_loader.sv:24 Which CPU addresses select which pair is decided by the 12C GAL, which differs between board variants, so the config byte names the variant: 0x06 = 136082-1006, 0x56 = 136082-1056, 0x05 = 136082-1005. — also in MAME: 12C atari/rampart.cpp:531, 136082-1006 atari/rampart.cpp:531, 136082-1056 atari/rampart.cpp:558, 136082-1005 atari/rampart.cpp:589
rtl/mem/rampart_rom_loader.sv:57 12C GAL variant code — also in MAME: 12C atari/rampart.cpp:531
rtl/rampart_core.sv:200 12C part: 0x06 = 136082-1006, 0x56 = 1056, 0x05 = 1005 — also in MAME: 12C atari/rampart.cpp:531, 136082-1006 atari/rampart.cpp:531
rtl/video/rampart_bitmap.sv:20 WAIT_MODEL = 1 adds the board's slot timing: the 8J GAL (clocked at 14 MHz) holds the CPU until its one slot per group while the raster fetches (8J pin 11 = 7K pin 15 low), and releases it at once in the fetch-free window. — also in MAME: 8J atari/rampart.cpp:529, 8J atari/rampart.cpp:529, 7K atari/rampart.cpp:528
rtl/video/rampart_gal4l.sv:3 4L GAL 136082-1001: motion-object RAM arbiter (GAL16V8, registered). — also in MAME: 4L atari/rampart.cpp:527, 136082-1001 atari/rampart.cpp:527
rtl/video/rampart_gal7k.sv:3 7K GAL 136082-1002: horizontal timing decode (GAL16V8, registered). — also in MAME: 7K atari/rampart.cpp:528, 136082-1002 atari/rampart.cpp:528
rtl/video/rampart_gal8j.sv:3 8J GAL 136082-1003: bitmap DRAM sequencer (GAL20V8, registered). — also in MAME: 8J atari/rampart.cpp:529, 136082-1003 atari/rampart.cpp:529
rtl/video/rampart_gal8m.sv:3 8M GAL 136082-1004: motion-object RAM address mux (GAL20V8). — also in MAME: 8M atari/rampart.cpp:530, 136082-1004 atari/rampart.cpp:530
rtl/video/rampart_moram.sv:18 WAIT_MODEL = 1 uses the 4L GAL (14 MHz) for the CPU wait: its pin 18 releases a CPU access only while no next-line work is pending. — also in MAME: 4L atari/rampart.cpp:527
rtl/video/rampart_video.sv:150 graphics ROM 2N, 128K x 8, loaded as dumped — also in MAME: 2N atari/rampart.cpp:516
README.md:33 The sets differ in their control panel and program-ROM layout, and so in the address-decode GAL fitted at 12C. — also in MAME: 12C atari/rampart.cpp:531

Notes where it differs from MAME — 1

README.md:156 Attract-mode and demo timing can differ from MAME by a frame or two; the game plays the same.

Cites MAME source — 29

Arcade-Rampart.sv:24 The MRA also carries MAME's factory EEPROM image, used when there is no save yet.
Arcade-Rampart.sv:81 Colour DAC: the board's resistor network (default) or MAME's linear table.
Arcade-Rampart.sv:257 IRQ_MODEL 0 is MAME's timing instead (see rtl/main/rampart_irq.sv).
rtl/main/rampart_irq.sv:15 The default, -3, lines the interrupts up with MAME's emulation of this board, the only timing reference there is: fx68k needs the request about three clocks earlier than MAME's 68000 to take it at the same instruction.
rtl/main/rampart_slapstic.sv:7 The state machine follows MAME's slapstic.cpp (BSD-3-Clause), class 111-118, used here as the functional reference.
rtl/main/rampart_slapstic.sv:68 Set to 1 to reset them on every board reset instead, as MAME does.
rtl/main/rampart_slapstic.sv:86 Current state in MAME's numbering (0 idle ...
rtl/mem/rampart_nvram_io.sv:13 Two load paths: ioctl index 2 is the .nvm restore/save channel; index 0 (the ROM stream) carries MAME's factory EEPROM image at 0x460000 as a seed (seed_we).
rtl/rampart_core.sv:25 The defaults follow MAME's timing; Arcade-Rampart.sv changes only IRQ_MODEL.
rtl/rampart_core.sv:61 0 = board DAC levels, 1 = MAME's
rtl/video/rampart_dac.sv:14 mame = 1 selects the plain linear scale instead, (code << 2) | (code >> 4), with no clamp.
README.md:17 Atari never published the pages for the CPU, the video RAMs and the custom chips, so MAME's Rampart driver filled those gaps.
README.md:19 Where the board and MAME differ, the core follows the board; the differences you may notice are listed below.
README.md:45 Put the ROM zips in `games/mame/` (see below).
README.md:53 The factory EEPROM image that MAME keeps in the set is used the first time a set is run.
README.md:98 | Colour levels | Board DAC, MAME | Board DAC | see below |
README.md:109 `Board DAC` reproduces the board's colour output circuit: each gun is a resistor ladder with a pull-up and a black clamp, so black is true black but every lit l
README.md:113 `MAME` uses MAME's plain linear scale instead.
README.md:134 Differences from MAME you may notice
README.md:136 **Colours.** With `Board DAC`, colours follow the board's resistor network: dark colours are brighter and contrast is lower than with MAME's linear palette.
README.md:141 The sound is therefore softer at the top end than MAME's unfiltered mix.
README.md:142 When the game lowers the ADPCM level, the board attenuates it rather than muting it as MAME does.
README.md:145 MAME draws the picture in four bands, so a change made mid-frame can appear a few lines lower, or a frame later, in MAME than on the board.
README.md:150 MAME resets the SLAPSTIC on every reset.
README.md:152 The core uses the one Atari drew for the closely related Klax board, which interrupts at lines 64, 128 and 192 and at the start of vertical blank (line 240); MA
README.md:158 **CPU timing.** The 68000 is a cycle-exact model of the real chip, so instruction timing can differ slightly from MAME's 68000.
README.md:167 whether the board adds CPU wait states for its slower chips (the core, like MAME, adds none);
README.md:169 where two motion objects overlap, which one is drawn on top (the core follows MAME: the later one in the list);
README.md:198 The MAME team: the Rampart driver served as a functional reference, and the MAME sets preserve the GAL fuse maps the core's address decoding and video timing ar

Says it matches, follows or was checked against MAME — 2

rtl/video/rampart_lb.sv:20 Which one the chip does is not known; 0 matches MAME.
README.md:138 Choose `MAME` to match MAME.

ReliefPitcher#
Relief Pitcher
MiSTer-devel/Arcade-ReliefPitcher_MiSTer @ f079a574
MAME compared: atari/relief.cpp + 4 related file(s)
Read: 38 HDL files, 4,458 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

14%

Statements: 2 toward hardware, 2 toward MAME, 8 not counted

Cites hardware documentation that MAME's driver does not — 2

rtl/main/relief_dtack.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Wait-state counter (a 74F163 on the board) that times DTACK for the CPU.
README.md:9 The core was built from the schematic sheets in Atari's TM-376 manual and the logic read from the board's GAL chips, with MAME 0.289 as a reference where those

Cites hardware references or measurements that MAME's driver also gives — 8

rtl/gal/relief_gal_0002.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Atari 136093-0002, a GAL16V8 at 15F: main address decoder. — also in MAME: 136093-0002 atari/relief.cpp:618, 15F atari/relief.cpp:618
rtl/gal/relief_gal_0003.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Atari 136093-0003, a GAL16V8 at 11R. — also in MAME: 136093-0003 atari/relief.cpp:619, 11R atari/relief.cpp:619
rtl/gal/relief_gal_0004.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Atari 136093-0004, a GAL16V8 at 5N. — also in MAME: 136093-0004 atari/relief.cpp:620, 5N atari/relief.cpp:620
rtl/gal/relief_gal_0005.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Atari 136093-0005, a GAL16V8 at 3F: colour select and upper pixel bits. — also in MAME: 136093-0005 atari/relief.cpp:621, 3F atari/relief.cpp:621
rtl/gal/relief_gal_0006.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Atari 136093-0006, a GAL16V8 at 5F: low pixel bits and transparent-pen detection. — also in MAME: 136093-0006 atari/relief.cpp:622, 5F atari/relief.cpp:622
rtl/gal/relief_gal_0008.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Atari 136093-0008, a GAL16V8 at 3E on the audio daughterboard. — also in MAME: 136093-0008 atari/relief.cpp:623, 3E atari/relief.cpp:623
rtl/gal/relief_gal_0009.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Atari 136093-0009, a GAL16V8 at 8A on the audio daughterboard. — also in MAME: 136093-0009 atari/relief.cpp:624, 8A atari/relief.cpp:624
rtl/gal/relief_gal_0010.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Atari 136093-0010, a GAL16V8 at 15A: daughterboard address decoder. — also in MAME: 136093-0010 atari/relief.cpp:625, 15A atari/relief.cpp:625

Cites MAME source — 2

Arcade-ReliefPitcher.sv:513 Keys follow MAME, plus F1 for a service credit and F2 for the self-test switch.
README.md:9 The core was built from the schematic sheets in Atari's TM-376 manual and the logic read from the board's GAL chips, with MAME 0.289 as a reference where those

RingKing#
King of Boxer
MiSTer-devel/Arcade-RingKing_MiSTer @ 51cbc3c3
MAME compared: dataeast/kingofb.cpp
Read: 22 HDL files, 7,825 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

No statements found

RiverPatrol#
River Patrol
MiSTer-devel/Arcade-RiverPatrol_MiSTer @ 2319de92
MAME compared: nichibutsu/cclimber.cpp
Read: 15 HDL files, 6,263 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

10%

Statements: 1 toward MAME

Cites MAME source — 1

rtl/ym_2149_linmix.vhd:44 Clues from MAME sound driver and Kazuhiro TSUJIKAWA

Robotron#
Alien Arena, Blaster, Bubbles, Joust …
MiSTer-devel/Arcade-Robotron_MiSTer @ 562a5dac
MAME compared: williams/williams.cpp + 5 related file(s)
Read: 16 HDL files, 12,567 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

12%

Statements: 5 toward MAME

Cites MAME source — 1

rtl/hc55564.vhd:4 This is a VHDL port of the MAME C++ CVSD emulator.

Says it matches, follows or was checked against MAME — 1

rtl/sc1.vhd:127 test blits 20k 16x16 blit in normal and same with slow flag match mame timing now

Shares text with the MAME driver without saying so — 3

rtl/williams_cpu.vhd:348 clock 0 1 2 3 4 5 6 7 8 9 10 11 — shares text with williams/williamsblitter.cpp:50
rtl/williams_cpu.vhd:349 Q 0 0 0 1 1 1 1 1 1 0 0 0 — shares text with williams/williams.cpp:448
rtl/williams_cpu.vhd:350 E 0 0 0 0 0 0 1 1 1 1 1 1 — shares text with williams/williams.cpp:448

RshnAtk#
Green Beret, Mr. Goemon
MiSTer-devel/Arcade-RushnAttack_MiSTer @ f6e6ab36
MAME compared: konami/gberet.cpp + 5 related file(s)
Read: 16 HDL files, 5,789 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

No statements found

Salamander#
Salamander
MiSTer-devel/Arcade-Salamander_MiSTer @ 99a6e3fd
MAME compared: konami/nemesis.cpp + 3 related file(s)
Read: 31 HDL files, 12,215 lines (Quartus project)

MiSTer official

Both

low

67%

Statements: 4 toward hardware, 10 toward MAME

Cites hardware documentation that MAME's driver does not — 3

rtl/Salamander_sound.v:389 GX587 output filters, sheet 2/2 FM C44 33n sees R82 1K || (R83 1K + R14 1K) = 667R -> 7.2kHz PCM C28 470p sees (ladder 100K + R51 20K) || R39/R40 23K5 = 19K65 -> 17.2kHz
rtl/ipcores/K007232.v:33 A fully synchronous model for Konami 007232 dual-channel PCM player based on the Furrtek's die shot based schematics:
README.md:2 Current status: Fixable, custom chip known as K005295 will be decapped.

Says it was checked on “real hardware” — 1

rtl/GX400_video/K005295.v:478 This has been confirmed by running test ROM on real hw.

Cites MAME source — 4

rtl/GX400_video/K005293.v:180 The chip showed us a total of 26 results and suggested that the source of MAME was a very empirical result.
rtl/Salamander_cpu.v:428 io0_cs C0001 : soundlatch C0002-3 : DSW0(MAME); DIPSW1(PCB) C0004-5 : watchdog
rtl/Salamander_cpu.v:433 io1_cs C2000-1 : IN0(MAME); DIPSW3(PCB)[2:0], coin/start C2002-3 : IN1(MAME); DIPSW3(PCB)[3], p1 C2004-5 : IN2(MAME); p2 C2006-7 : DSW1(MAME); DIPSW2(PCB)
rtl/Salamander_emu.v:54 start addr length comp num mame rom parts num location description

Shares text with the MAME driver without saying so — 6

Salamander.sv:216 0 1 2 3 4 5 6 — shares text with konami/nemesis.cpp:2898
rtl/GX400_video/GX400_video.v:355 FETCHES HSCROLL(1 PIXEL ROW) VALUE WHEN VCLK = 1 MCLK 0 1 2 3 4 5 0 1 2 3 4 5 CLK18M _|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_| — shares text with konami/nemesis.cpp
rtl/GX400_video/GX400_video.v:499 MCLK 0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5 CLK18M _|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯ — shares text with konami/nemesis.cpp
rtl/GX400_video/GX400_video.v:742 MCLK 1 1 0 1 2 3 4 5 6 7 8 9 0 1 CLK18M _|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯ — shares text with konami/nemesis.cpp:2898
rtl/GX400_video/K005290.v:38 pixel 0 1 2 3 4 5 6 7 1H _|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯| 2H ___|¯¯¯ — shares text with konami/nemesis.cpp:2898
rtl/ipcores/vlm5030_gl/vlm5030_gl.vhd:1343 9 8 7 6 5 4 3 2 1 0 — shares text with konami/nemesis.cpp:279

ScooterShooter#
Scooter Shooter
MiSTer-devel/Arcade-ScooterShooter_MiSTer @ 8d211dbf
MAME compared: konami/scotrsht.cpp + 1 related file(s)
Read: 9 HDL files, 6,674 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 1 toward hardware

Cites hardware documentation that MAME's driver does not — 1

rtl/ScooterShooter.sv:526 Scooter Shooter also uses 3 switchable low-pass filters on the SSG side of its YM2203 with a cutoff frequency of 723.432Hz (actually closer to 492.130Hz due to internal resistance inside the 74HC4066 handling the filter switching).

Scramble#
Amidar, Anteater, Armored Car, Battle of Atlantis …
MiSTer-devel/Arcade-Scramble_MiSTer @ 3712a29c
MAME compared: galaxian/galaxian.cpp, galaxian/scobra.cpp, galaxian/scramble.cpp + 12 related file(s)
Read: 14 HDL files, 5,467 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

11%

Statements: 1 toward MAME

Cites MAME source — 1

rtl/YM2149_linmix_sep.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA

SDGundamPS#
SD Gundam Psycho Salamander no Kyoui
MiSTer-devel/Arcade-GundamSD_MiSTer @ 957fc714
MAME compared: seibu/dcon.cpp + 4 related file(s)
Read: 20 HDL files, 6,275 lines (Quartus project)

MiSTer official

Mostly MAME

medium

59%

Statements: 3 toward hardware, 50 toward MAME

Cites hardware documentation that MAME's driver does not — 2

rtl/GundamSD/GundamSD_main_top.sv:31 Memory map SD Gundam (da MAME dcon.cpp + SD Gundam override): $000000-$07FFFF ROM 68K (512KB) $080000-$08BFFF Main RAM (48KB) $08C000-$08C7FF BG tile RAM (2KB) $08C800-$08CFFF FG tile RAM (2KB) $08D000-$08D7FF MG tile RAM
rtl/GundamSD/GundamSD_maincpu_map.sv:29 Memory map SD Gundam (da MAME dcon.cpp + sdgndmps_map override): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $080000-$08BFFF Main RAM (48KB) → BRAM $08C000-$08C7FF BG tile RAM → BRAM dual-port $08C800-$

Reports a measurement taken on the original PCB — 1

rtl/GundamSD/GundamSD_video_timing.sv:26 PCB measurement Blood Bros: VSync 59.4094 Hz, HSync 15.6246 kHz, master XTAL 20 MHz.

Cites MAME source — 45

GundamSD.sv:297 --- Joystick to SD Gundam input mapping --- MAME P1_P2 port ($E0002): active low.
GundamSD.sv:625 ── Flip screen (CRTC reg 0x1A bit 0) ─────────────────────────────────────── MAME: BIT(reg_1a, 0) → flip_screen.
GundamSD.sv:667 SD Gundam Text scroll fissi: 128 X (MAME), 16 Y (centratura HW reale)
GundamSD.sv:707 MAME +128 X + offset HW Y +16 (centratura calibrata su PCB Seibu D-Con)
GundamSD.sv:812 Pixel pipeline con sprite + priority callback (MAME pri_cb dcon.cpp).
GundamSD.sv:813 pri_code semantics (MAME pri_mask 0xF0/0xFC/0xFE/0): pri=3 → sprite ABOVE ALL (mask=0, copre Text/FG/MG/BG, INSERT COIN, HUD) pri=0 → sprite ABOVE FG (copre FG, MG, BG; coperto solo da Text) pri=1 → sprite ABOVE MG (copre MG, BG; coperto
rtl/GundamSD/GundamSD_audio_z80.sv:25 Spec da MAME (reference/mame_seibu/seibusound.cpp + dcon.cpp): - Z80A @ 14.31818 MHz / 4 = 3.579545 MHz - YM2151 (jt51) @ 14.31818 / 4 = 3.579545 MHz - OKI M6295 (jt6295) @ 20 MHz / 16 = 1.25 MHz, PIN7=LOW
rtl/GundamSD/GundamSD_audio_z80.sv:173 MAME audiocpu region layout (sdgndmps):
rtl/GundamSD/GundamSD_audio_z80.sv:257 ─── ROM bank register (Z80 0x4007: bit0 → bank 0/1) ───────────────────── MAME seibu_sound_device::bank_w: m_rom_bank->set_entry(BIT(data,0))
rtl/GundamSD/GundamSD_audio_z80.sv:328 Main writes to 0xA0008 (MAME offset 4) → assert RST18 snd_addr = bus_addr[3:1], 0xA0008 → bit[3:1]=100 = 4
rtl/GundamSD/GundamSD_audio_z80.sv:354 ─── Soundlatch main_w/r logic ────────────────────────────────────────── snd_addr = bus_addr[3:1] = offset/2 (0=word 0, 1=word 1, 2=word 2, 3=word 3, 4=word 4, 5=word 5, 6=word 6) MAME usa byte access (umask16 0x00ff = byte basso).
rtl/GundamSD/GundamSD_audio_z80.sv:356 Mappa offset MAME → snd_addr: offset 0 (0xA0000) → snd_addr 0 offset 1 (0xA0002) → snd_addr 1 offset 2 (0xA0004) → snd_addr 2 offset 3 (0xA0006) → snd_addr 3 offset 5 (0xA000A) → snd_addr 5 offset 6 (0xA000C) → snd_addr 6
rtl/GundamSD/GundamSD_audio_z80.sv:372 Main writes (MAME seibu_sound_device::main_w): case 0/1: m_main2sub[offset] = data case 4: update_irq_lines(RST18_ASSERT) — gestito sopra case 2/6: pending flags (sub2main=0, main2sub=1)
rtl/GundamSD/GundamSD_audio_z80.sv:380 MAME case 2/6
rtl/GundamSD/GundamSD_audio_z80.sv:387 Z80 reads soundlatch (→ MAME implicit: nessun side effect) Z80 writes sub2main
rtl/GundamSD/GundamSD_audio_z80.sv:401 MAME sdgndmps_sound_comms_r override (dcon.cpp:288): offset 5 hardcoded 1.
rtl/GundamSD/GundamSD_main_top.sv:31 Memory map SD Gundam (da MAME dcon.cpp + SD Gundam override): $000000-$07FFFF ROM 68K (512KB) $080000-$08BFFF Main RAM (48KB) $08C000-$08C7FF BG tile RAM (2KB) $08C800-$08CFFF FG tile RAM (2KB) $08D000-$08D7FF MG tile RAM
rtl/GundamSD/GundamSD_main_top.sv:251 VBLANK IRQ4 — MAME dcon.cpp: m_maincpu->set_vblank_int(irq4_line_hold) Rising edge di vblank → assert IRQ4 pending; IACK CPU → clear.
rtl/GundamSD/GundamSD_main_top.sv:399 XOR 0x400 lato CPU per allineare BRAM[N] = MAME text_vram[N] (renderer parte da addr 0).
rtl/GundamSD/GundamSD_main_top.sv:407 Quindi MAME palette[N] sta in vram_addr = (N + 0x400) & 0x7FF.
rtl/GundamSD/GundamSD_main_top.sv:408 Per allineare BRAM[N] = MAME palette[N] applichiamo XOR 0x400 SOLO al lato CPU (a_addr).
rtl/GundamSD/GundamSD_main_top.sv:409 Il renderer passa pen_index MAME nativo (BG=0x400+, MG=0x500+, ecc) e la BRAM è già allineata.
rtl/GundamSD/GundamSD_maincpu_map.sv:29 Memory map SD Gundam (da MAME dcon.cpp + sdgndmps_map override): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $080000-$08BFFF Main RAM (48KB) → BRAM $08C000-$08C7FF BG tile RAM → BRAM dual-port $08C800-$
rtl/GundamSD/GundamSD_maincpu_map.sv:160 ─── GFX bank register ─────────────────────────────────────────────────── MAME dcon.cpp gfxbank_w: SOLO bit0 → m_gfx_bank_select = 0x1000 oppure 0.
rtl/GundamSD/GundamSD_palette.sv:25 MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 2048); Address space CPU: 0x08E800..0x08F7FF (4 KB = 2048 word).
rtl/GundamSD/GundamSD_palette.sv:34 Espansione 5→8 bit con replica top-bits (standard MiSTer / MAME palette_device).
rtl/GundamSD/GundamSD_palette.sv:86 xBGR_555 → RGB888 con replica bit alti (5→8 standard MiSTer/MAME)
rtl/GundamSD/GundamSD_seibu_crtc.sv:23 Seibu CRTC fedele a MAME (src/mame/seibu/seibu_crtc.cpp).
rtl/GundamSD/GundamSD_seibu_crtc.sv:117 MAME mappa: bit0=screen0(BG), bit1=screen2(MG), bit2=screen1(FG), bit3=screen3(Text) (vedi seibu_crtc.cpp commento "screen 0=BG, screen 1=FG, screen 2=MG, screen 3=Text") In SD Gundam dcon.cpp layer_en_w gira la maschera così: ~layer_en bit
rtl/GundamSD/GundamSD_seibu_crtc.sv:126 Il dispatcher MAME usa "if (BIT(~m_layer_en, n))" per saltare = layer disabilitato quando il bit è 1.
rtl/GundamSD/GundamSD_sprite_renderer.sv:27 Format word (formato "comune", non alt_format) da MAME src/mame/seibu/sei021x_sei0220_spr.cpp: w0 bit 15 = enable (0=skip, 1=draw) w0 bit 14 = flip_x w0 bit 13 = flip_y w0 bit 12..10 = sizex (3-bit, +1) → 1..8 tile larghezza
rtl/GundamSD/GundamSD_sprite_renderer.sv:42 Multi-tile: tile_code += 1 per sub-tile (TODO: ordine x-major o y-major da verificare con dump MAME — assunto x-major per ora).
rtl/GundamSD/GundamSD_sprite_renderer.sv:45 Priority callback dcon.cpp::pri_cb: pri=0 → above FG pri=1 → above MG pri=2 → above BG pri=3 → above Text (= sotto Text)
rtl/GundamSD/GundamSD_sprite_renderer.sv:134 SEI0211 get_coordinate (MAME sei021x_sei0220_spr.h): coord &= 0x1ff; return (coord >= 0x180) ?
rtl/GundamSD/GundamSD_sprite_renderer.sv:181 Tile code finale Y-MAJOR (MAME draw_internal: ax=outer, ay=inner, code++): sub_index = ax*sizey + ay → cur_tile = code + eff_tile_x*sp_h + eff_tile_y
rtl/GundamSD/GundamSD_text_renderer.sv:25 Specifiche da MAME (src/mame/seibu/dcon.cpp):
rtl/GundamSD/GundamSD_text_renderer.sv:183 --- Stage 3: pen decode --- MAME readbit: bit MSB-first → src[bn/8] & (0x80 >> (bn%8)) In Verilog LSB-first, bit position = 7 - (bn%8).
rtl/GundamSD/GundamSD_tile_layer.sv:25 Differenze fra layer (da MAME dcon.cpp):
rtl/GundamSD/GundamSD_tile_layer.sv:277 MAME readbit: src[bitnum/8] & (0x80 >> (bitnum%8)) (MSB-first) Verilog è LSB-first: bit posizione = 7 - (bitnum%8).
rtl/GundamSD/GundamSD_video_timing.sv:35 Active area da MAME (sdgndmps_map): visarea 0..40*8-1, 2*8..30*8-1 quindi 320×224, V offset = 16 (top blank).
README.md:9 This core reimplements the hardware in SystemVerilog from MAME references (`seibu/dcon.cpp`, `seibu/seibu_crtc.cpp`), the Seibu CRTC documentation, the main 680
README.md:48 MAME-accurate Seibu CRTC (scroll, layer enable, flip screen) and SEI0211 sprite priority
README.md:63 YM2151 FM (jt51) + OKI M6295 ADPCM (jt6295) with MAME-accurate mixer
README.md:135 | Custom video CRTC| Seibu CRTC (legionna.cpp / seibu_crtc.cpp) |
README.md:216 The **MAME** project for invaluable hardware reference (`seibu/dcon.cpp`, `seibu/seibu_crtc.cpp`).

Says it matches, follows or was checked against MAME — 1

GundamSD.sv:305 SD Gundam SYSTEM port ($E0004) — verified MAME dcon.cpp:345-356 bit0 = START1 (active LOW) bit4 = START2 (active LOW) bit8 = SERVICE (active LOW) PORT_SERVICE_NO_TOGGLE altri = UNKNOWN/UNUSED → tied 1 Coin inputs NON sono qui

Shares text with the MAME driver without saying so — 4

rtl/GundamSD/GundamSD_audio_z80.sv:174 ROM_LOAD "911-a05.010" 0x00000, 0x8000 → primi 32KB del file → region 0x00000-0x07FFF — shares text with seibu/dcon.cpp:678
rtl/GundamSD/GundamSD_palette.sv:23 Palette RAM Seibu D-Con (xBGR_555, 2048 entries). MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 2048); Address space CPU: 0x08E — shares text with seibu/dcon.cpp:559
rtl/GundamSD/GundamSD_text_renderer.sv:23 Text layer renderer Seibu D-Con (8x8, 4bpp, 64x32). Specifiche da MAME (src/mame/seibu/dcon.cpp): // get_text_tile_info tile = textram[tile_i — shares text with seibu/dcon.cpp
rtl/GundamSD/GundamSD_video_timing.sv:23 Video timing single-screen Seibu D-Con. SD Gundam Psycho Salamander gira su Seibu D-Con (PB91008), stessa famiglia di Blood Bros (1990). PCB measuremen — shares text with seibu/dcon.cpp

SDGundamRainbow#
SD Gundam Sangokushi Rainbow Tairiku Senki
MiSTer-devel/Arcade-SDGundamRainbow_MiSTer @ 154ec6db
MAME compared: seibu/legionna.cpp + 8 related file(s)
Read: 24 HDL files, 10,821 lines (Quartus project)

MiSTer official

Mostly MAME

medium

71%

Statements: 5 toward hardware, 193 toward MAME, 1 not counted

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/SDGundamRainbow/SDGundamRainbow_maincpu_map.sv:23 Main CPU memory map SDGundamRainbow / SD Gundam (legionna.cpp grainbow_map): $000000-$0FFFFF ROM 68K (1MB) → SDRAM via bridge $100000-$1003FF RAM scratch (1KB) → BRAM (Main RAM low) $100400-$1006FF COP3 region — also in MAME: 68K seibu/legionna.cpp:46

Reports a measurement taken on the original PCB — 1

rtl/SDGundamRainbow/SDGundamRainbow_video_timing.sv:26 PCB measurement Blood Bros: VSync 59.4094 Hz, HSync 15.6246 kHz, master XTAL 20 MHz.

Says it was checked on “real hardware” — 4

rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:343 0 : 1 (unsigned <320 provato su HW = REGRESSIONE; il signed [-160,320) dell'intento MAME e' il comportamento giusto sul core)
rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:215 byte_lo = pf_rom_data[31:24]/[15:8], byte_hi = [23:16]/[7:0] Plane order DCBA (verificato su HW, come BG/MG/FG): pen[0] dal bit "D" (byte_hi[3-sub]), pen[3] dal bit "A" (byte_lo[7-sub]).
rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:332 Scan INVERSO 511→0 (verificato su HW: ordine sprite-su-sprite opposto al loop MAME 0→511).
rtl/SDGundamRainbow/SDGundamRainbow_tile_layer.sv:322 Plane order verificato su HW: BG/MG = DCBA (PEN_ORDER=0), FG = BADC (PEN_ORDER=1).

Cites MAME source — 176

SDGundamRainbow.sv:307 --- Joystick to SD Gundam input mapping --- MAME P1_P2 port ($E0002): active low.
SDGundamRainbow.sv:310 MiSTer joy bits: joy[0]=R, joy[1]=L, joy[2]=D, joy[3]=U, joy[4]=A, joy[5]=B. MAME PLAYERS12 (legionna.cpp:439-444): bit[0]=UP, [1]=DOWN, [2]=LEFT, [3]=RIGHT, [4]=BTN1, [5]=BTN2, [6]=BTN3, [7]=unused (active low).
SDGundamRainbow.sv:320 SDGundamRainbow SYSTEM port ($10074C) — MAME legionna.cpp:427-436 bit0 = START1 (active LOW) bit1 = START2 (active LOW) bit2..7 = UNKNOWN → tied 1 bit8..15 = UNKNOWN → tied 1 Coin inputs NON sono qui: vanno via SEIBU_COIN_INPUTS → Z80 → sou
SDGundamRainbow.sv:689 ── Flip screen (CRTC reg 0x1A bit 0) ─────────────────────────────────────── MAME: BIT(reg_1a, 0) → flip_screen.
SDGundamRainbow.sv:735 ── Text layer renderer (8x8, 4bpp, 64x32 grid) ───────────────────────────── SDGundamRainbow MAME (ROM_START godzilla): "char" = REGIONE PROPRIA 128KB (11.620/10.615, ROM_LOAD16_BYTE), NON dentro user1 come Legionnaire.
SDGundamRainbow.sv:748 SDGundamRainbow text scroll-base (CRTC reg 0x3A, hook godzilla-only legionna.cpp:1326).
SDGundamRainbow.sv:749 Calibrazione HW di famiglia (dump vregs in seibu_crtc.cpp): Legionnaire reg=0x01FF, visarea da riga 16 → 0x1FF-0x1EF=+16 = ESATTAMENTE il vecchio yoff text +16 del core Legionnaire funzionante; D-Con reg=0xFFEF (low9=0x1EF), visarea da 0 →
SDGundamRainbow.sv:753 La formula MAME set_scrolldy(0x1EF-data) è INVERTITA rispetto all'HW (convenzione dy del tilemap.cpp) — mai fidarsi del verso MAME.
SDGundamRainbow.sv:791 SDGundamRainbow CRTC scroll passthrough (legionna_v.cpp:34-49 tile_scroll_w): scroll_ram[0/1] → BG (m_background_layer) scroll_ram[2/3] → MG (m_midground_layer) scroll_ram[4/5] → FG (m_foreground_layer) Nel nostro CRTC: xscroll_l0 = ram[0/1
SDGundamRainbow.sv:814 SDGundamRainbow BG: tilemap 32x32 (legionna_v.cpp:204).
SDGundamRainbow.sv:815 MAME GFXDECODE "back" color base = 0 (gfx_legionna riga 1168), 32 colorset.
SDGundamRainbow.sv:816 HAS_TRANSP=1 perché m_background_layer->set_transparent_pen(15) in legionna_v.cpp:216 (pen 15 = trasparente, NON opaco come Blood Bros).
SDGundamRainbow.sv:838 SDGundamRainbow MG: 16x16, 4bpp, 32x32 tilemap (legionna_v.cpp:204).
SDGundamRainbow.sv:839 get_mid_tile_info_share_bgrom (legionna_v.cpp:158): MG share BG ROM, tile = (vram & 0xfff) | 0x1000 (= seconda metà della BG ROM) color = ((vram >> 12) & 0xf) | 0x10 (= palette set superiore: bit 4 = 1) In palette MAME "back" base = 0,
SDGundamRainbow.sv:866 SDGundamRainbow FG: tilemap 32x32 (legionna_v.cpp:213).
SDGundamRainbow.sv:868 MAME GFXDECODE "fore" color base = 32*16 = 0x200, 16 colorset.
SDGundamRainbow.sv:878 GRAINBOW: fore = bg2.619 ROM_LOAD16_WORD_SWAP (legionna.cpp:1987) = IDENTICO alla back bg1.618 → stesso decode DCBA di BG/MG (riscontro HW utente: col BADC il FG era sbagliato).
SDGundamRainbow.sv:886 SDGundamRainbow: bit 2 = FG (legionna_v.cpp:344)
SDGundamRainbow.sv:973 Anticipando di 1 l'indirizzo e il DE, il dato campionato al tick e' quello del pixel CORRENTE: allineamento coi tile ripristinato (= calibrazione +1 pixel-hunting MAME, fatta prima del fix CRT) e colonna 0 coperta.
SDGundamRainbow.sv:1007 MAME riferimenti (VIDEO_START grainbow, legionna_v.cpp:276-287): m_sprite_pri_mask per grainbow: pri=0 → 0xFFF0 (copre pri-value 0,1,2 → bg,mg,fg → SOTTO text) pri=1 → 0xFFFC (copre 0,1 → bg,mg → sotto fg,text) pri=2 → 0xFFFE (copre 0 →
SDGundamRainbow.sv:1017 Ordine composite RTL (front→back), derivato dalle pri_mask sopra: Sprite pri=3 (sopra tutto, text incluso) Text (pri-value 4) Sprite pri=0 (sopra bg/mg/fg, sotto text) FG (pri-value 2) Sprite pri=1 (sopra bg/mg) MG
rtl/SDGundamRainbow/SDGundamRainbow_audio_z80.sv:25 Spec da MAME (legionna.cpp godzilla machine config :1295-1355): - Z80 @ 14.318180/4 = 3.579545 MHz (seibu_sound_map + godzilla_sound_io_map) - YM2151/OPM (jt51) @ 3.579545 MHz, route ch0+ch1 0.50 su mono - OKI M6295 (jt6295) @ 20MHz/20 = 1.
rtl/SDGundamRainbow/SDGundamRainbow_audio_z80.sv:57 SDGundamRainbow pcm.922 = 512KB: bit 18 = bank (Z80 IO port 0, MAME godzilla_oki_bank_w: set_rom_bank(data&1)).
rtl/SDGundamRainbow/SDGundamRainbow_audio_z80.sv:364 MAME seibu_sound_device::main_r (seibusound.cpp:279): case 2,3: return sub2main[offset-2] (soundlatch data: coin/input dal Z80) case 5: return main2sub_pending ?
rtl/SDGundamRainbow/SDGundamRainbow_audio_z80.sv:379 ─── YM2151 (jt51) — GRAINBOW usa OPM, non OPL2 (legionna.cpp:1340) ────── Il driver Z80 programma i timer OPM (reg 0x10-0x14): su jtopl2 non scattava mai l'IRQ → RST10 morto → sequencer musica fermo.
rtl/SDGundamRainbow/SDGundamRainbow_audio_z80.sv:458 MAME: route 0.50+0.50 su mono (legionna.cpp:1342-1343)
rtl/SDGundamRainbow/SDGundamRainbow_audio_z80.sv:466 ─── OKI M6295 (jt6295) — PIN7_HIGH (20MHz/20 = 1.0 MHz, legionna.cpp:1345)
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:4 MAME-faithful implementation of the Seibu SEI300 chip as used by the `legionna` driver (SDGundamRainbow 1992 — Banpresto/TAD).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:7 Reference (in this repo): MAME seibucop.cpp MAME seibucop_cmd.ipp MAME seibucop_dma.ipp MAME legionna.cpp
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:136 MAME cop_itoa_digits[10]: BCD digits of cop_itoa (low<<0 | high<<16).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:140 Il vecchio loop a sottrazioni ripetute era O(valore) (~valore/9 clk): con i long 32-bit di godzilla (score, writer $156E/$1F93E) il 68k restava congelato (dma_busy include bcd_pending) fino a MILLISECONDI per chiamata — su MAME/HW reale i d
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:153 MAME cop_program command table (seibucop.cpp lines 318-457) At boot, game code uploads 32 macro slots × 8 micro-op words via pgm_addr (0x100434) → slot*8 + sub-index pgm_data (0x100432) → micro-op word pgm_value (0x100438) → cop_func_valu
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:160 MAME calls find_trigger_match(triggerval, 0xff00) to find the slot whose cop_func_trigger matches.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:263 Triggers (write-only addresses) MAME legionna.cpp:172 maps cop_cmd_w to $100500-$100505 (3 words).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:337 0x100410 sprite_dma_inc (MAME cop_sprite_dma_inc_w): if x_clip in [-160, 320): cop_regs[4] += 8.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:338 MA in MAME sprite_x e' uint16_t assegnato a int -> MAI negativo -> il -160 e' codice morto: check EFFETTIVO = unsigned < 320 (X "negative" 0xFFxx NON avanzano il puntatore entry).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:343 0 : 1 (unsigned <320 provato su HW = REGRESSIONE; il signed [-160,320) dell'intento MAME e' il comportamento giusto sul core)
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:350 A size==0 NON wrappare (il size-- uint di MAME wrapperebbe a $FFFF: il loop del builder su status[1] andrebbe in livelock — provato peggio).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:385 Macro program upload — MAME seibucop.cpp lines 318-457 pgm_data writes one micro-op word to cop_program[latch_addr] AND latches the slot's trigger/value/mask from current latch regs.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:486 itoa_digits (MAME 0x100590-99, 5 word).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:498 Status / dist / angle (seibucop.cpp:916 cop_status_r → cop_status)
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:506 MAME open bus
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:573 commit write al dst ASSOLUTO (fill/mr), 1:1 MAME write_word(dst)
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:609 LEGACY sprite-DMA (seibucop_cmd.ipp): 6880 (carica rel_xy), c480 (single-step: compone l'entry sprite a cop_regs[4]+offs con X/Y = rel + (obj - abs)).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:633 write angolo (word {0,angle} come MAME host_endian)
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:645 Trigger latches — MAME seibucop.cpp cop_cmd_w line 1069.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:646 MAME dispatches on raw data after clearing cop_status bit 15.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:700 DMA mode 0x80-0x87: MAME dma_palette_brightness() fa FADE solo con pal_brightness_mode 4/5; con qualsiasi altro valore fa una COPIA SEMPLICE src->dst (ramo else, seibucop_dma.ipp:119-123) verso QUALUNQUE dst — incl.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:708 DMA generici 0x09/0x0E: MAME write_word(dst) va nello spazio host = arriva a QUALSIASI RAM mappata, incluse le BRAM video ($101000-$105FFF: staging tilemap, palette-stage $104000, sprite $105000).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:716 Output del fade/blend 0x8x: MAME dma_palette_brightness fa write_word(dst) nello SPAZIO HOST = raggiunge QUALUNQUE RAM mappata (pal-stage $104000, sprite $105800, Main RAM...).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:719 Ora: pal_val registrato in D_FADE_WRITE e committato in D_FADE_COMMIT via canale fill (decode per dst assoluto in main_top: bg/fg/mg/txt/pal/spr) o mr (dst in Main RAM) — 1:1 MAME.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:722 (Il vecchio dma80_to_spr era INVERTITO: il blit pietre e' src=$105800 dst=$104000, non il contrario — MAME map: $100478=SRC, $10047C=DST.)
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:725 LEGACY sprite-DMA state (MAME m_sprite_dma_rel_x/y, m_sprite_dma_x_clip)
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:835 MAME cop_cmd_w (seibucop.cpp:1075):
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:869 find_trigger_match (seibucop.cpp:464) Cerca slot N tale che (trigger & 0xf800) == (cop_func_trigger[N] & 0xf800) && cop_func_trigger[N] != 0.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:871 Restituisce canonical trigger value del slot (NB: MAME LEGACY_cop_cmd_w usa il match slot per dispatchare; in pratica equivale a restituire cop_func_trigger[slot]).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:892 fade_table — MAME seibucop.cpp:733 (reverse engineered from Seibu Cup Soccer bootleg) v = pal_channel(5-bit) | (brightness_val_xor_X) [10-bit input] low = v & 0x1F high = v & 0x3E0 return (low * (high | (high>>5)) + 0x210) >> 10 [8-bit o
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:931 ── Hitbox b100/b900 scratch (MAME cop_collision_update_hitbox) ────────────── dx[i] = int8 (signed) byte basso, size[i] = uint8 (unsigned) byte alto del word descrittore @ hitadr2+2*i. 3 assi (Y,X,Z) per SDGundamRainbow.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:938 num_axis: MAME seibucop.cpp:1010 "if (data & 0x100) num_axis = 3" else 2.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:940 res init 7 vs 3 (seibucop.cpp:1038-39).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:967 Con 16-bit frac + 24 iter + z>>16: 0 divergenze di decisione vs MAME int(atan(dx/dy)*128/pi) su ~640k casi (dimostrato numericamente).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1212 MAME cop_dma_trigger_w: NON modifica cop_status (vedi seibucop.cpp:741).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1220 MAME dma_tilemap_buffer: copy staging RAM → renderer BRAM src = cop_dma_src[mode] << 6 (byte addr 0x101000+ = staging) dst = i (loop counter 0..0x13FF = renderer index) count = 0x2800/2 = 5120 words
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1230 MAME dma_palette_buffer: copy staging palette → renderer src = cop_dma_src[mode] << 6 (0x104000 = palette staging) dst = i (loop counter 0..0x7FF = renderer index) count = 0x1000/2 = 2048 words
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1240 MAME write_word(dst) su spazio host: con dst nelle BRAM video ($101000-$105FFF: staging/pal/spr, es.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1255 simplified, MAME size>>1
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1260 MAME seibucop_dma.ipp dma_palette_brightness() mode 5/4.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1263 MAME formulas: src = cop_dma_src[mode] << 6 dst = cop_dma_dst[mode] << 6 size = ((cop_dma_size << 5) - (cop_dma_dst << 6) + $20)/2 Init: src=$106000, dst=$104000, size=($827F<<5 - $4100<<6 + $20)/2 = ($104FE0 - $104000 + $20)/2 = $1000
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1274 MAME size = (((size<<5) - (dst<<6) + 0x20)/2)
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1280 MAME: mode 4/5 = fade palette; QUALSIASI ALTRO = copia semplice src->dst (seibucop_dma.ipp:119-123).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1290 MAME seibucop.cpp cop_dma_trigger_w case 0x116 — GRAINBOW: fill come 0x118 ma SENZA guard dst!=0 e length bytes = (size+1)<<4 (metà).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1292 legionna.cpp:56-61: "The COP-MCU appears to write to the work ram area, otherwise it RESETS in mid-animation of the title screen" → senza questo fill il gioco torna al logo da solo.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1303 Skip if dst != 0 (MAME guard, dma.ipp:135)
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1316 MAME cop_cmd_w (seibucop.cpp:1073): cop_status &= 0x7fff (clear bit 15).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1318 MAME: cop_status &= 0x7fff (clear bit 15).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1333 MAME LEGACY_cop_cmd_w: find_trigger_match(data, 0xF800) → slot per GRUPPO f800, poi handler dal microcodice caricato.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1380 MAME execute_0205: read dword at cop_regs[0]+4+offset*4 (ppos)
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1401 0x138e / 0x338e — atan(dx/dy) MAME execute_338e.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1403 Parte da r1+4 hi (offset 0x0004), come 3BB0/MAME.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1411 r1+4 hi (MAME read_dword(r1+4) primo)
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1426 MAME: raw_angle = cop_read_word(r0+0x34) = host_read_word(0x34^2 = 0x36); amp = cop_read_word(r0+0x36) = host_read_word(0x36^2 = 0x34).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1443 0xa180 — collision read pos for slot 0 MAME cop_collision_read_pos: cop_read_word(spradr+N) = host_read_word((spradr+N)^2) per host_endian=true.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1464 b000 NON e' un no-op: il dispatcher LEGACY di godzilla (seibucop.cpp:1365) matcha con mask 0xf800, quindi la patch init_godzilla (b100->b000) ESEGUE comunque l'update ma con num_axis=2 (bit8=0 = Z disattivata).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1572 Mode 4 (GRAINBOW/Denjin, seibucop_dma.ipp:87-117): indice = (val*2)[4:0], val 0x0010/0xFFFF = TARGET PURO, NESSUN bypass bit15.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1619 MAME: m_host_space->write_word(dst, pal_val) — dst ASSOLUTO.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1653 MAME (0x118 e 0x116): write_dword(i, v1 | v2<<16) su spazio BE 68k → word a i = v2, word a i+2 = v1 (alternati).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1666 Macro 0x0205 — linear movement (MAME execute_0205) ppos = read_dword(cop_regs[0]+0x04) vel = read_dword(cop_regs[0]+0x10) npos = ppos + vel write_dword(cop_regs[0]+0x04, npos) delta = (npos>>16) - (ppos>>16) write_word(cop_regs[0]+0x1E, re
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1709 MAME cop_read/write_word(cop_regs[0]+0x1e) = host word @ (0x1e^2)=0x1c (host endianness word^2; conferma doc 06 micro-op 'addmem16 0x1C(r0)').
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1727 Macro 0x0905/0x0904 — jump (MAME execute_0904) write_dword(cop_regs[0]+0x10, read_dword(cop_regs[0]+0x10) ± read_dword(cop_regs[0]+0x28)) 0x0905 (bit 0=1) = +, 0x0904 (bit 0=0) = -
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1753 MAME execute_0904: bit 0 di data = 1 → add, =0 → sub tmp32_a = vel ± grav.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1784 0x138E/0x338E atan(dx/dy) — MAME execute_338e (cmd.ipp:159) dx = read_dword(r1+4) - read_dword(r0+4) dy = read_dword(r1+8) - read_dword(r0+8) if(!dy){status|=0x8000; angle=0} else angle=atan(dx/dy)*128/pi; dy<0→+0x80 if(data&0x80) write_byt
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1832 MAME: angle = atan(dx/dy)*128/pi (+0x80 se dy<0).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1834 Cosi' z = atan(dx/dy) e il +0x80 (in WR) copre solo il quadrante, come MAME.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1836 NIENTE prescale: i dword diff sono FIXED-POINT coord<<16 (come il 3BB0 che usa dx32[31:16] e MAME dx>>16), NON interi piccoli.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1877 MAME (int)(...) tronca VERSO ZERO.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1879 BUG TROVATO (validato vs MAME su 29241 casi): il CORDIC SOTTO-CONVERGE di 1 LSB sulle DIAGONALI (es.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1884 Compenso l'epsilon di sotto-convergenza con +1 toward-zero PRIMA del troncamento: bias=1 azzera tutte le 133 divergenze (bias=0) -> 0/29241 vs MAME.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1893 MAME execute_338e (seibucop_cmd.ipp:175-188): la write dell'angolo in RAM (obj+0x34 host, gated da data&0x80) e' FUORI dall'if/else di dy -> avviene SEMPRE, anche a dy==0 (dove cop_angle=0 -> scrive 0^0x80 = 0x80).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1899 Ora calcolo ang_byte in entrambi i rami e scrivo SEMPRE, come MAME.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1906 Scrivere l'angolo anche a dy==0 ("1:1 MAME") REGREDISCE: il martello scivola/moonwalk.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1909 MAME: dy==0 -> cop_angle=0
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1920 GRAINBOW: write RAW — il ROM carica il microcode 138e variante cupsoc/SDGundam (tabella $498: ...b9a b9a A9A) = MAME LEGACY_execute_130e_cupsoc, SENZA ^0x80 (il ^0x80 e' della variante famiglia $B9A / is_yflip: legionna).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1924 PROVA sim 8 casi: col ^0x80 vettore sincos INVERTITO 180° vs MAME → boss 138e-driven marcia via (stage 4).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1926 ⛔ NON toccare il sincos (lookup diretto = sin MAME): toccarlo inverte i game-written = regressione build 13.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1940 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197) dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (aritmetico) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = sqrt(dx*dx + dy*dy) if(data&0x80) write_word(r0 + (data&0x200?0x3a:0x38
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2049 (Il fix MAME-aligned 0x3a:0x38 faceva fuggire i nemici -> MAME invertito vs HW.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2056 MAME: macro completata → cop_status = 7 (gate-poll del gioco).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2142 0x8100/0x8900 sin/cos (MAME execute_8100/8900) raw_angle = cop_read_word(cop_regs[0]+0x34) & 0xff amp = (65536>>5) * (cop_read_word(cop_regs[0]+0x36) & 0xff) = 2048 * amp_byte if (raw_angle == 0xC0 sin / 0x80 cos): amp *= 2 res = int(
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2181 MAME special-case: sin && raw==0xC0 OR cos && raw==0x80 → amp *= 2
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2227 0xa180/0xa980 — read pos (MAME cop_collision_read_pos) flags_swap = cop_read_word(spradr+2) → host_read_word(spradr+0) pos[0] = cop_read_word(spradr+6) → host_read_word(spradr+4) pos[1] = cop_read_word(spradr+10) → host_read_word(
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2234 Però MAME cop_read_word(+2) = host_read_word(+2^2) = host_read_word(+0).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2245 rdata = word @ host+0 = flags (MAME cop_read_word(spradr+2) ^ 2).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2254 rdata = word @ host+4 = pos[0] (Y axis per MAME)
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2274 0xb100/0xb900 — update hitbox & compute intersection (1:1 MAME cop_collision_update_hitbox, seibucop.cpp:1003-1065).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2321 2 assi (b000/b800): terza word NON letta, dx/size azzerati (seibucop.cpp:1014-1022)
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2360 2 assi: l'asse 2 (Z) NON viene aggiornato (loop MAME i<num_axis)
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2379 res init: 3 assi = 111, 2 assi = 011 (seibucop.cpp:1038-39: bit Z gia' 0 = "collide banale" -> hit deciso solo da X/Y)
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2403 LEGACY 6880 — carica rel_xy per il prossimo c480 (MAME LEGACY_execute_6980: rel_xy = read_word(spr_src+4+offs))
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2424 LEGACY c480 — single-step sprite DMA (MAME LEGACY_execute_c480): info = read(spr_src+offs) + (param & 0x3f) -> entry+0 abs = read(regs[0]+8/+4) - spr_dma_abs_x/y X(fx/dx/rel_x) -> entry+4 (+ x_clip per l'inc $410) Y(fy/rel_y) -> entry+6
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2537 6200 — rotate-towards (MAME execute_6200, variante grainbow che godzilla CARICA nella tabella): angle(obj host+0x37) ruota verso cop_angle_target di cop_angle_step; flags(host+2) bit2=raggiunto.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2540 Dominio angolo: il nostro 138e scrive in RAM plain^0x80 (is_yflip) -> lavoro nel dominio stored con target^0x80: il DELTA e' rotazione-invariante => matematica IDENTICA a MAME.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2543 Write angolo = WORD {0,angle} (MAME host_endian write-word).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2564 wrap a signed 8-bit (MAME: +=/-=256 su int)
rtl/SDGundamRainbow/SDGundamRainbow_main_top.sv:227 VBLANK IRQ4 — MAME legionna.cpp: m_maincpu->set_vblank_int(irq4_line_hold) MAME HOLD_LINE: IRQ asserted on edge, released ONLY at IACK (= when CPU fetches vector).
rtl/SDGundamRainbow/SDGundamRainbow_main_top.sv:232 VBLANK IRQ4 — MAME legionna.cpp: m_maincpu->set_vblank_int(irq4_line_hold) MAME HOLD_LINE: IRQ asserted on edge, released ONLY at IACK (= when CPU fetches vector).
rtl/SDGundamRainbow/SDGundamRainbow_main_top.sv:489 COP3 cmd 0x14 dma_tilemap_buffer (legionna_v.cpp:86 videowrite_cb_w): offset 0x000..0x3FF → BG (back_data) offset 0x400..0x7FF → FG (fore_data) offset 0x800..0xBFF → MG (mid_data) offset 0xC00..0x13FF → Text (textram, 0x800 word) SRC
rtl/SDGundamRainbow/SDGundamRainbow_main_top.sv:513 Il fill scrive le BRAM STAGING (= la host RAM di MAME): il per-frame DMA 0x14/0x15 le propaga al renderer.
rtl/SDGundamRainbow/SDGundamRainbow_main_top.sv:527 ── SPLIT STAGING vs RENDERER (semantica MAME 2-stadi, come la palette) ───── MAME godzilla: $101000-$103FFF e' .ram() PURO (handler background_w/… COMMENTATI nel map, legionna.cpp) — le scritture CPU NON toccano i tilemap.
rtl/SDGundamRainbow/SDGundamRainbow_main_top.sv:530 I tilemap leggono m_back/fore/mid_data/m_textram = buffer SEPARATI (make_unique_clear, legionna_v.cpp) scritti SOLO da videowrite_cb_w = DMA 0x14.
rtl/SDGundamRainbow/SDGundamRainbow_main_top.sv:535 u_XX_ram = STAGING: porta A = CPU (+fill 0x116/0x118, come MAME che filla la host RAM), porta B = sorgente del DMA 0x14.
rtl/SDGundamRainbow/SDGundamRainbow_main_top.sv:538 Coppia contenuto/scroll = atomica a livello ISR, come MAME.
rtl/SDGundamRainbow/SDGundamRainbow_main_top.sv:610 ── Palette: split STAGING ($104000) vs RENDERER (semantica MAME 2-stadi) ─── MAME: la CPU e il fade (cmd 0x80) scrivono la STAGING RAM a $104000.
rtl/SDGundamRainbow/SDGundamRainbow_main_top.sv:650 MAME godzilla: $104000 e' RAM pura (legionna.cpp:262, handler palette commentato) — la palette VISIBILE si aggiorna SOLO via paletteramout_cb = dma_palette_buffer 0x15 (seibucop_dma.ipp:27); il fade DMA scrive lo STAGING (host RAM, dma.ipp:
rtl/SDGundamRainbow/SDGundamRainbow_maincpu_map.sv:23 Main CPU memory map SDGundamRainbow / SD Gundam (legionna.cpp grainbow_map): $000000-$0FFFFF ROM 68K (1MB) → SDRAM via bridge $100000-$1003FF RAM scratch (1KB) → BRAM (Main RAM low) $100400-$1006FF COP3 region
rtl/SDGundamRainbow/SDGundamRainbow_maincpu_map.sv:119 ─── Region detect (MAME grainbow_map, legionna.cpp:324) ─────────────────
rtl/SDGundamRainbow/SDGundamRainbow_maincpu_map.sv:223 MAME legionna_map: main_r/main_w(offset>>1) con umask16(0x00ff).
rtl/SDGundamRainbow/SDGundamRainbow_maincpu_map.sv:227 Vedi seibusound.cpp main_r/main_w.
rtl/SDGundamRainbow/SDGundamRainbow_maincpu_map.sv:231 ─── GFX bank ──────────────────────────────────────────────────────────── grainbow non ha il tile bank register ($100470 assente dalla mappa MAME): gfx_bank resta 0.
rtl/SDGundamRainbow/SDGundamRainbow_maincpu_map.sv:335 Replica la latenza-zero-osservabile di MAME (cop_cmd_w sincrono): il gioco legge cop_hit_val_stat/cop_angle ($188/$1b4) nell'istruzione dopo il trigger.
rtl/SDGundamRainbow/SDGundamRainbow_palette.sv:25 MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 128*16); (legionna.cpp:1212, 128*16 = 2048 entry) Address space CPU: 0x104000..0x104FFF (4 KB = 2048 word).
rtl/SDGundamRainbow/SDGundamRainbow_palette.sv:35 Espansione 5→8 standard MAME palette_device: {val5, val5[4:2]} (bit replication che riempie i 3 LSB con i 3 MSB del valore 5-bit).
rtl/SDGundamRainbow/SDGundamRainbow_palette.sv:85 SDGundamRainbow: xBGR_555 → RGB888 (legionna.cpp:1212) Layout: bit[4:0]=R, bit[9:5]=G, bit[14:10]=B. 5 bit per canale.
rtl/SDGundamRainbow/SDGundamRainbow_palette.sv:87 Espansione 5→8 standard MAME palette_device: {val5, val5[4:2]} (replica i 3 MSB nei 3 LSB → range 0..255 con monotonia preservata).
rtl/SDGundamRainbow/SDGundamRainbow_seibu_crtc.sv:23 Seibu CRTC fedele a MAME (seibu_crtc.cpp).
rtl/SDGundamRainbow/SDGundamRainbow_seibu_crtc.sv:130 MAME mappa: bit0=screen0(BG), bit1=screen2(MG), bit2=screen1(FG), bit3=screen3(Text) (vedi seibu_crtc.cpp commento "screen 0=BG, screen 1=FG, screen 2=MG, screen 3=Text") In SD Gundam dcon.cpp layer_en_w gira la maschera così: ~layer_en bit
rtl/SDGundamRainbow/SDGundamRainbow_seibu_crtc.sv:139 Il dispatcher MAME usa "if (BIT(~m_layer_en, n))" per saltare = layer disabilitato quando il bit è 1.
rtl/SDGundamRainbow/SDGundamRainbow_seibu_crtc.sv:144 SDGundamRainbow layer ordering (legionna_v.cpp:384-390 screen_update_GRAINBOW): bit 0 = BG (background) bit 1 = MG (midground) bit 2 = FG (foreground) bit 3 = Text bit 4 = Sprites ATTENZIONE: e' l'OPPOSTO di legionna (screen_update_legionna
rtl/SDGundamRainbow/SDGundamRainbow_seibu_crtc.sv:165 Scroll-base 0x2C-0x3A (seibu_crtc.cpp:243 layer_scroll_base_w; screen0=BG, screen2=MG, screen1=FG, screen3=Text).
rtl/SDGundamRainbow/SDGundamRainbow_seibu_crtc.sv:166 Raw esce qui; le formule (delta vs riferimento godzilla, Y invertita come il set_scrolldy(0x1ef-data) di MAME) stanno nel top.
rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:25 Formato spriteram quasi identico (entrambi MAME sei021x_sei0220_spr.cpp) — differenze: - Spriteram @ 0x105000-0x105FFF (4KB, 1024 word, 256 entry × 4 word) - w3 bit 15 = tile bank extra bit (denjinmk usa, SDGundamRainbow base = 0)
rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:30 Format word (legionna_v.cpp:288-312): w0 bit 15 = enable (0=draw, 1=skip — TODO verify SDGundamRainbow) w0 bit 14 = flip_x w0 bit 13 = flip_y (???
rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:46 Priority callback legionna_v.cpp:314-317: pri_mask[0] = 0x0000 (sopra tutto) pri_mask[1] = 0xFFF0 pri_mask[2] = 0xFFFC pri_mask[3] = 0xFFFE
rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:140 0..511 (MAME size/2/4 = 4096/2/4 = 512)
rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:145 Decoded fields — MAME sei0210_device::draw (non-alt format, riga 143): if (BIT(~spriteram[i], 15)) continue; → draw quando w0[15]==1.
rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:154 grainbow_pri_cb (legionna_v.cpp:319): pri = (w1[15:14] & 2) | (ext & 1) → livello = {w1[15], w0[6]}.
rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:167 MAME SEI0211 default m_xoffset/m_yoffset = 0 (sei021x_sei0220_spr.cpp:40-41).
rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:168 SDGundamRainbow NON chiama set_offset (legionna.cpp:1214) → offset 0,0.
rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:200 Tile code finale Y-MAJOR (MAME draw_internal: ax=outer, ay=inner, code++): sub_index = ax*sizey + ay → cur_tile = code + eff_tile_x*sp_h + eff_tile_y grainbow: NESSUN gfxbank_cb (legionna.cpp:1449, solo pri_cb) — code puro 14 bit.
rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:537 MAME gfx_legionna_spr: color base = 64*16 = 0x400 (64 colorset × 16 pen).
rtl/SDGundamRainbow/SDGundamRainbow_text_renderer.sv:25 Specifiche da MAME (legionna.cpp:1117-1126, 1167):
rtl/SDGundamRainbow/SDGundamRainbow_text_renderer.sv:47 Char ROM in MAME: "char" region 64KB = ROM_COPY user1[0x10000..0x1FFFF].
rtl/SDGundamRainbow/SDGundamRainbow_text_renderer.sv:140 MAME `legionna_v.cpp:214`: text tilemap = 64×32 (8x8 tiles, TILEMAP_SCAN_ROWS).
rtl/SDGundamRainbow/SDGundamRainbow_text_renderer.sv:186 --- Stage 3: pen decode (charlayout planes packed in nibbles) --- Per col c (0..3 dentro la half-tile), bit position = 3 - c. pen[0] = word[bit_pos + 0] (plane 0) pen[1] = word[bit_pos + 4] (plane 1) pen[2] = word[bit_pos + 8] (plane
rtl/SDGundamRainbow/SDGundamRainbow_text_renderer.sv:192 MAME readbit usa MSB-first: bit_offs N → byte[N/8] bit (7-N%8).
rtl/SDGundamRainbow/SDGundamRainbow_text_renderer.sv:193 In Verilog word concat (lo=byte0[7:0], hi=byte1[7:0]) → MAME pos N = word[(7-N%8) + (N>=8?8:0)].
rtl/SDGundamRainbow/SDGundamRainbow_text_renderer.sv:210 MAME GFXDECODE char: color base = 48*16 = 0x300 (16 colorset × 16 pen).
rtl/SDGundamRainbow/SDGundamRainbow_tile_layer.sv:25 Differenze fra layer (da MAME dcon.cpp):
rtl/SDGundamRainbow/SDGundamRainbow_tile_layer.sv:58 BB FG hardcoded +0x1000 (MAME bloodbro fg_tile_info)
rtl/SDGundamRainbow/SDGundamRainbow_tile_layer.sv:221 Tile index con eventuale gfx_bank (MG ha bit 12 = 13-bit totali, BG/FG = 12 bit) + TILE_CODE_OFS hardcoded (BB FG aggiunge 0x1000 secondo MAME bloodbro fg_tile_info).
rtl/SDGundamRainbow/SDGundamRainbow_video_timing.sv:35 Active area da MAME (sdgndmps_map): visarea 0..40*8-1, 2*8..30*8-1 quindi 320×224, V offset = 16 (top blank).
rtl/SDGundamRainbow/SDGundamRainbow_video_timing.sv:60 ── Pixel clock enable: 96 MHz / 14 = 6.857 MHz ───────────────────────── SDGundamRainbow reale (legionna.cpp:1318 set_raw): pclk 14.318180/2 = 7.15909 MHz.
rtl/SDGundamRainbow/SDGundamRainbow_video_timing.sv:78 ── Constants timing ───────────────────────────────────────────────────── SDGundamRainbow REALE (legionna.cpp:1318): set_raw(14318180/2, 455, 0, 320, 258, 0, 224) = 320x224, HTotal 455 @7.159MHz = 15.734 kHz, VTotal 258 → 60.985 Hz.
rtl/SDGundamRainbow/sdram_bridge.sv:308 --- FG address descramble (legionna.cpp:1129 descramble_legionnaire_gfx) --- MAME applica un bitswap<24> agli indirizzi della ROM "fore" durante init: src_descrambled[i] = src_raw[bitswap<24>(i, ...
rtl/SDGundamRainbow/sdram_bridge.sv:355 bitswap MAME del byte offset
README.md:7 The game runs on the **Seibu `legionna.cpp` hardware family** — an M68000 board with a Seibu CRTC, the SEI252 sprite chip and the SEI300 / COP3 coprocessor.
README.md:12 This core reimplements the hardware in SystemVerilog from MAME references (`seibu/legionna.cpp`, `seibu/legionna_v.cpp`, `seibu/seibu_crtc.cpp`, `seibu/seibucop

Says it matches, follows or was checked against MAME — 6

SDGundamRainbow.sv:199 -1 = base famiglia (match MAME su HW)
SDGundamRainbow.sv:227 NB: gli offset per-layer (ex P5) sono HARDCODATI (osd_*_xoff/yoff costanti, match pixel-perfect MAME).
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1328 LEGACY sprite-DMA (match a maschera, MAME find_trigger_match): c480 mask $FF00 -> qualunque c4xx; 6880 mask $FFF3.
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2196 res = prod >> 4 (= /16 per matchare formula MAME 2048/32768 = 1/16)
rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:169 +1 pixel a destra: offset verificato con pixel hunting su MAME (rmonic79).
rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:332 Scan INVERSO 511→0 (verificato su HW: ordine sprite-su-sprite opposto al loop MAME 0→511).

Says it was translated, ported or taken from MAME — 2

rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:1948 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197): 1:1 dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (signed) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = floor(sqrt(dx*dx + dy*dy)) if(data&0x80) write_word(r0+(data&0x200?0x3
rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:2065 0x42C2/0x4AA0 divide — MAME execute_42c2/4aa0 (cmd.ipp:219/247): 1:1 DIVIDEND = cop_dist << (5 - cop_scale) (cop_scale 0..3 → shift 5..2) 42c2: div=cop_read_word(r0+0x36)→host 0x34; if(!div){status|=0x8000; write 0 a host 0x3a} else write

Keeps a MAME approximation — 1

rtl/SDGundamRainbow/SDGundamRainbow_cop3.sv:206 MAME usa total_cycles%256 (surrogato dell'RNG hw ignoto): l'LFSR e' un surrogato equivalente ma robusto alle letture regolari.

Shares text with the MAME driver without saying so — 8

SDGundamRainbow.sv:816 HAS_TRANSP=1 perché m_background_layer->set_transparent_pen(15) in — shares text with seibu/legionna_v.cpp:216
SDGundamRainbow.sv:839 get_mid_tile_info_share_bgrom (legionna_v.cpp:158): MG share BG ROM, — shares text with seibu/legionna.h:80
rtl/SDGundamRainbow/SDGundamRainbow_palette.sv:23 Palette RAM Seibu SDGundamRainbow (xBGR_555, 2048 entries). MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 128*16); (legio — shares text with seibu/legionna.cpp:1212
rtl/SDGundamRainbow/SDGundamRainbow_sprite_renderer.sv:146 if (BIT(~spriteram[i], 15)) continue; → draw quando w0[15]==1. — shares text with seibu/sei021x_sei0220_spr.cpp:128
rtl/SDGundamRainbow/SDGundamRainbow_text_renderer.sv:23 Text layer renderer Seibu SDGundamRainbow (8x8, 4bpp, 64x32). Specifiche da MAME (legionna.cpp:1117-1126, 1167): // charlayout 8x8, RGN_FRAC(1 — shares text with seibu/legionna.cpp
rtl/SDGundamRainbow/SDGundamRainbow_video_timing.sv:23 Video timing single-screen Seibu D-Con. SD Gundam Psycho Salamander gira su Seibu D-Con (PB91008), stessa famiglia di Blood Bros (1990). PCB measuremen — shares text with seibu/legionna.cpp
rtl/SDGundamRainbow/SDGundamRainbow_video_timing.sv:79 SDGundamRainbow REALE (legionna.cpp:1318): set_raw(14318180/2, 455, 0, — shares text with seibu/legionna.cpp:1318
rtl/SDGundamRainbow/sdram_bridge.sv:310 src_descrambled[i] = src_raw[bitswap<24>(i, ... 6,5,15,14,13,12, 11,10,9,8, 7,4, 3..0)] — shares text with seibu/legionna.cpp:1141

SegaG80V#
Eliminator, Space Fury, Star Trek, Tac / Scan …
MiSTer-devel/Arcade-SegaG80V_MiSTer @ 96b82aa2
MAME compared: sega/segag80v.cpp + 20 related file(s)
Read: 67 HDL files, 36,169 lines (Quartus project)

MiSTer official

Both

low

Statements: 6 toward hardware, 21 toward MAME, 1 not counted

Cites hardware documentation that MAME's driver does not — 6

rtl/sega_game_pkg.sv:7 Cross-checked against MAME segag80v.cpp and the Sega schematics.
rtl/sega_ports.sv:4 Input matrix: U1, U2, U5, and U9, four 74LS253 dual 4-to-1 muxes on the CPU board.
rtl/xy/sega_xy.sv:8 Cross-checked against MAME segag80v_v.cpp and the Sega X-Y schematics.
rtl/xy/sega_xy_top.sv:6 * 4K x 8 vector RAM at U24-U31 on X-Y Control drawing 800-0163 sheet 5.
README.md:34 Videodr0me rebuilt the vector generator for high-resolution raster presentation, integrated the CRT-effects pipeline, added video modes and geometry controls, e
README.md:37 He also rebuilt Zektor's discrete-audio implementation from its original schematics.

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/segag80v_cpu.sv:371 Interrupt chain (CPU board sheet 7/7) — also in MAME: sheet 7 sega/nl_astrob.cpp:637

Cites MAME source — 6

rtl/sega_inputs.sv:5 Bit positions follow MAME segag80v.cpp.
rtl/segag80v_cpu.sv:14 MAME's segag80v.cpp uses 2 and notes the real figure "depends on how many rising clock edges MEMRQ is held for, plus 1 additional cycle", with 3 causing visible slowdown in Space Fury.
rtl/segag80v_cpu.sv:134 MAME models this with adjust_icount(-2) on every program-space read and write and every opcode fetch, and does *not* apply it to I/O.
rtl/segag80v_cpu.sv:377 MAME latches the IRQ line and only recomputes it on an event, and the SERVICE input has no flip-flop — it contributes to exactly one update.
README.md:30 The original G80V machine core and speech implementation were created by alanswx from Sega hardware documentation and Aaron Giles' detailed G80 research in MAME
README.md:300 **Aaron Giles and MAME contributors:** detailed G80 machine, vector, and sound research and executable reference.

Says it matches, follows or was checked against MAME — 3

rtl/sega_game_pkg.sv:7 Cross-checked against MAME segag80v.cpp and the Sega schematics.
rtl/sega_security.sv:7 Cross-checked against MAME segag80_m.cpp and the Sega hardware mappings.
rtl/xy/sega_xy.sv:8 Cross-checked against MAME segag80v_v.cpp and the Sega X-Y schematics.

Shares text with the MAME driver without saying so — 12

Arcade-SegaG80V.sv:4 Eliminator, Space Fury, Zektor, Tac/Scan, Star Trek. — shares text with sega/segag80v.cpp:32
rtl/sega_ports.sv:9 D7 COINA n/c n/c n/c — shares text with sega/segag80v.cpp:243
rtl/sega_ports.sv:10 D6 COINB P1.13 P1.14 n/c (P1.13 = DRAW) — shares text with sega/segag80v.cpp:244
rtl/sega_ports.sv:11 D5 SERVICE P1.15 P1.16 P1.17 — shares text with sega/segag80v.cpp:245
rtl/sega_ports.sv:12 D4 P1.18 P1.19 P1.20 P1.21 — shares text with sega/segag80v.cpp:246
rtl/sega_ports.sv:13 D3 SW1.8 SW1.7 SW1.6 SW1.5 — shares text with sega/segag80v.cpp:247
rtl/sega_ports.sv:14 D2 SW1.4 SW1.3 SW1.2 SW1.1 — shares text with sega/segag80v.cpp:248
rtl/sega_ports.sv:15 D1 SW2.8 SW2.7 SW2.6 SW2.5 — shares text with sega/segag80v.cpp:249
rtl/sega_ports.sv:16 D0 SW2.4 SW2.3 SW2.2 SW2.1 — shares text with sega/segag80v.cpp:250
rtl/segag80v_cpu.sv:15 and notes the real figure "depends on how many rising clock edges MEMRQ — shares text with sega/segag80v.cpp:147
rtl/segag80v_cpu.sv:16 is held for, plus 1 additional cycle", with 3 causing visible slowdown in — shares text with sega/segag80v.cpp:148
rtl/xy/sega_xy.sv:161 steps down and large steps up. The carry out of bit 8 clocks the up/down — shares text with sega/segag80v_v.cpp:245

SEGASYS1#
4-D Warriors, Block Gal, The Togyu, Flicky …
MiSTer-devel/Arcade-SEGASYS1_MiSTer @ 83ea725f
MAME compared: sega/system1.cpp + 2 related file(s)
Read: 18 HDL files, 3,660 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 2 toward MAME

Cites MAME source — 2

rtl/sn76489/sn76489_noise.vhd:199 Tapped bits according to MAME's sn76496.c, implemented in function lfsr_tapped_f.
README.md:57 copy ROM zip files to /media/fat/_Arcade/mame

SegaVCO#
Buck Rogers: Planet of Zoom, Turbo
MiSTer-devel/Arcade-SegaVCO_MiSTer @ a7536fc3
MAME compared: sega/turbo.cpp + 3 related file(s)
Read: 50 HDL files, 16,947 lines (Quartus project)

MiSTer official

Both

medium

49%

Statements: 36 toward hardware, 25 toward MAME, 5 not counted

Cites hardware documentation that MAME's driver does not — 36

Arcade-SegaVCO.sv:170 SERVICE1 (IN1 bit 5) and TEST (IN1 bit 4) (sheet 4: I15=SERVICE, I14=TEST) are tied inactive; no button is mapped to them.
Arcade-SegaVCO.sv:173 in0[5:4] are ACC.LO/ACC.HI (sheet 4: two opto-isolated lines on the control connector).
rtl/audio/alarm_chan.sv:1 ALARM channel: IC15A 555 astable -> IC16 74LS393 ripple divider -> IC3/IC7 74123 retriggerable monostables (one per /ALARMn) -> IC11 74LS38 open-collector wire-OR node -> R154/C88 one-pole high-pass -> IC29/IC25 unity-follower + x(-2) gain
rtl/audio/alarm_chan.sv:29 Stage 2: IC16 74LS393 ripple divider, falling-edge triggered, never reset after power-on (1CLR/2CLR grounded on the board).
rtl/audio/alarm_chan.sv:67 Stage 4: IC11 74LS38 open-collector wire-OR node.
rtl/audio/alarm_chan.sv:112 Idle level: with no alarm gated every 74LS38 output is off and R153 holds the node HIGH, so x settles at X_LOW + X_SPAN.
rtl/audio/audio_top.sv:18 Turbo sound-board CN1 bundle, from the third 8255 (PPI2/IC123/CSFA) on the CPU board: raw port bytes in, named per the schematic below.
rtl/audio/audio_top.sv:126 CN1 bundle, decoded and named per the schematic (bit map below).
rtl/audio/audio_top.sv:469 CN2-pin-to-amp-channel mapping, from the cabinet wiring and power amp schematics (734-0048 Upright, 734-0049 Cockpit).
rtl/audio/exp_chan.sv:1 EXP channel (crack + rumble), sheet 2.
rtl/audio/hit_chan.sv:1 HIT channel, sheet 2 (same shape as exp_chan.sv).
rtl/audio/hit_chan.sv:13 The 74123 timing resistor has no designator or value on sheet 2.
rtl/audio/hit_chan.sv:78 Reset is the idle state (cap at 5V, silent), not 0V.
rtl/audio/la4460.sv:2 Sheet 1, PDF page 45.
rtl/audio/la4460.sv:20 Both come from a printed log graph (about +/-20 %); they are the only soft parameters here, sections 1 and 2 are computed from schematic values.
rtl/audio/mute_ctl.sv:1 DC-mute control node -- LA4460 pin 6 (sheet 1).
rtl/audio/rebound_chan.sv:1 REBOUND channel, sheet 2 (same shape as hit_chan.sv / exp_chan.sv).
rtl/audio/rebound_chan.sv:76 Reset is the idle state (cap at 5V, silent), not 0V.
rtl/audio/ship_chan.sv:1 SHIP engine channel (sheet 834-5122 sheet 1, "MY SHIP"): IC14 555 astable (R23/R24/C12); IC17 pins 1-3 buffer the C12 voltage, which feeds three relaxation oscillators (IC17 pins 5-7 and 12-14 with Tr2, IC26 pins 1-3 and 8-10 with Tr5, IC22
rtl/audio/turbo_alarm_chan.sv:1 Turbo ALARM channel (D-2/11): IC48 555 astable -> IC43 393 ripple divider -> IC46/IC53 74123 retriggerable monostables (one per /Trig1-4) -> IC47 74LS38 open-collector wire-OR node -> 5.1K/4.7uF one-pole high-pass -> IC33-A follower -> IC33
rtl/audio/turbo_alarm_chan.sv:92 Stage 4: IC47 74LS38 open-collector wire-OR node (gating per the header).
rtl/audio/turbo_crash_chan.sv:16 The CRASH.S filter is a one-pole approximation of the second-order IC2 pins 5-7 stage (not derived from the schematic).
rtl/audio/turbo_mixer.sv:46 MUTE: D-11/11 generates MUTE locally via IC42 (74LS123-family monostable, R286 = 220K / C137 = 33uF off a power-on 5V rail), a power-on delay mute.
rtl/audio/turbo_mute_ctl.sv:9 | timing | comparator crossing an RC | 74LS123 one-shot |
rtl/audio/turbo_mute_ctl.sv:13 Generator (D-11/11): IC42 = 74LS123 (dual monostable, one half used).
rtl/audio/turbo_mute_ctl.sv:35 RESET MODELS POWER-ON (same deliberate deviation as mute_ctl.sv): a core reset re-arms the full 3.27s mute, whereas the real 74LS123 triggers only on the 5V rail rising.
rtl/audio/turbo_othercars_chan.sv:55 Amplitudes (2686/5031/1660) and duties are the schematic nominals; the three N_UP/N_DOWN/STEP pairs sit inside the component tolerance band around the nominal frequencies (A 83 Hz -> 77.1 Hz, B 195 Hz -> 202.3 Hz, C 211 Hz -> 202.4 Hz); tha
rtl/audio/turbo_playercar_chan.sv:10 D9 control/VCA: IC41 (74LS139) BSEL decoder selects exactly one of BCONT0/1/2.
rtl/audio/turbo_playercar_chan.sv:632 BCONT0/1/2 gate targets (IC41 74LS139 decoder, one-hot).
rtl/audio/turbo_playercar_mycarsource.sv:11 The tone rate comes from the STEP_LUT law; the sub rate is a named operating-point parameter (0.43 Hz/V) because TR5's in-circuit VCE is not recoverable from the schematic.
rtl/segavco.v:1072 IC20 (PR-1116, TBP18S030 32x8 PROM; P-ROM board sheet 2/10) has address inputs PLB0-2 (A0-A2) and SLIPAR/ACCIAR (A3-A4), i.e. sprbits[26:24] and babit[4]/babit[5], matching turbo_v.cpp's ((sprbits>>24)&7) | ((babit&0x30)>>1).
rtl/segavco.v:1075 Its output feeds a 74LS376 latch (IC19) whose set/clear sequencing was not traced; the model OR-accumulates every visible pixel, is read at fe00 low nibble and cleared by any write to e800-efff.
rtl/video/mixer_turbo.v:1 Turbo mixer (schematic sheet 144): a bit-serial 16:1 multiplexer, not an ordinal priority chain -- the layer ordering is data (the contents of PR-1122/PR-1123), not structure.
rtl/video/mixer_turbo.v:146 16 bits wide: the three 74LS150s (IC38/39/40, P-ROM Board sheet 2/10) are 16:1 selectors with D15 grounded (0) and D14 pulled high (1).
README.md:12 Both sound boards are rebuilt as discrete circuits in fixed-point DSP, working from the original schematics: oscillators, 555 timers, one-shots, noise source, v
README.md:45 **Known gaps.** Some upper engine harmonics, the Other Cars second harmonic and the tunnel's room character do not yet match the cabinet recording, and the alar

Cites hardware references or measurements that MAME's driver also gives — 5

rtl/audio/fire_chan.sv:1 FIRE channel (laser), sheet 3. — also in MAME: sheet 3 sega/turbo.cpp:324
rtl/audio/noise_mm5837.sv:1 MM5837 pseudo-random noise generator (sheet 3). — also in MAME: sheet 3 sega/turbo.cpp:324
rtl/io/i8255.v:16 On the CPU board (834-5120 sheet 5) IC90's PC7 drives the sub Z80's /INT and PC6 comes from its /IORQ with no gating, so the command write is the interrupt and the sub CPU's own /IORQ (acknowledge, then the ISR's IN) clears it; there is no — also in MAME: sheet 5 sega/turbo.cpp:261
rtl/segavco.v:360 PC7 goes straight to the sub CPU's /INT (834-5120 sheet 5: IC90 pin 10 -> IC50 pin 16), so the write is the interrupt. — also in MAME: sheet 5 sega/turbo.cpp:261
rtl/video/video_timing.v:26 The original board's H SYNC (82S141 IC78 pin 9, pr-5197) is high for native counts 264..303, i.e. 528..607 here (8.01 us), leaving only 3.2 us of back porch; composite encoders such as the AD723 then fail to insert colour burst. — also in MAME: 82S141 sega/turbo.cpp:1708

Cites MAME source — 22

Arcade-SegaVCO.sv:333 Not on the original board; like MAME's lever artwork it is only a display aid, off by default.
rtl/io/steering_input.sv:6 The game reads a dial (MAME IPT_DIAL): only the change between two reads matters, not an absolute angle, which a free-running mod-256 accumulator models.
rtl/segavco.v:367 MAME clears the handshake a machine cycle later through its own scheduling; that is an emulator artifact and is not reproduced.
rtl/segavco.v:495 Turbo's proms blob has a different layout from Buck's (see turbo_v.cpp and the MRA) but uses the same shared proms_we/proms_wraddr slot as Buck's PROMs above.
rtl/segavco.v:503 no consumer in MAME -- loaded, not wired
rtl/segavco.v:969 LS148 priority encoder: index of the lowest-numbered set bit in plb (0-7), or 4'hf if plb==0 (MAME: countl_zero(bitswap<8>(plb,0,1,2,3,4,5,6,7)) with the mux==8 clamp folded in).
rtl/segavco.v:1034 repack_bg's shifts overflow 8 bits on purpose: MAME's palbits is a plain int, and this is how the bgcolor branch reaches the upper 3/4 of the 1024-entry (10-bit) palette.
rtl/segavco.v:1072 IC20 (PR-1116, TBP18S030 32x8 PROM; P-ROM board sheet 2/10) has address inputs PLB0-2 (A0-A2) and SLIPAR/ACCIAR (A3-A4), i.e. sprbits[26:24] and babit[4]/babit[5], matching turbo_v.cpp's ((sprbits>>24)&7) | ((babit&0x30)>>1).
rtl/video/fg_tilemap.v:4 Buck Rogers' column fetch is remapped through PR-5194 (an X-shift PROM): col = pr5194[((xx>>3)-1) & 0x1f] Output "foreraw" is MAME's `color*4 + pixel`, an 8-bit raw pen for the mixer.
rtl/video/fg_tilemap.v:21 It is a plain 8-native-pixel shift with the tilemap forced blank outside [8, 0x108) (MAME turbo_v.cpp: `foreraw = (xx<8||xx>=0x108) ?
rtl/video/fg_tilemap.v:47 Simulation-only combinational read port on the tilemap VRAM, for comparing the HUD cell-for-cell against MAME.
rtl/video/fg_tilemap.v:113 Turbo's blanking window (MAME turbo_v.cpp).
rtl/video/fg_tilemap.v:113 The ">=264" arm can never fire since xx is 8 bits; it is kept to mirror the MAME source.
rtl/video/mixer_turbo.v:3 Follows MAME's turbo_state::screen_update.
rtl/video/road_gen.v:3 Follows MAME's turbo_state::screen_update.
rtl/video/sprite_engine.v:13 Register widths stay at Buck Rogers' (larger) sizes; Turbo's narrower values are computed in their native width and then zero-extended, which reproduces MAME's masked/uint16_t arithmetic (e.g. Turbo's ROM address is a true 14-bit mask, `(of
rtl/video/sprite_engine.v:18 PR-5195 (the sprite state machine PROM) is intentionally not read: MAME's prepare_sprites() models that sequencer chip directly as boolean logic, as this module does.
rtl/video/sprite_engine.v:302 Gate on the full 9-bit vpos so the FSM runs exactly once per visible scanline (y_target_next = 0..VDISP-1), as MAME's per-line loop does: at vpos = VTOTAL-1 (wrap, prepares y=0) and vpos = 0..VDISP-2.
rtl/video/sprite_engine.v:449 ROM address from the 17-bit offset register: Buck Rogers uses offs[15:1]; Turbo masks to offs[14:1] (MAME's `(offs>>1)&0x3fff`), taken from the 16-bit slice so wraparound is confined to 16 bits.
rtl/video/sprite_engine.v:473 Gates the fetch/advance path and the output path (latched_masked) like MAME's local `sprlive`, but not lst_active's own accumulation.
README.md:70 *Gear Overlay* (off by default) shows a small L or H beside the TIME readout for the gear lever position the game is reading, like the lever graphic in MAME's a
README.md:90 **[MAME](https://www.mamedev.org/)** - reference driver source (`turbo.cpp`, `turbo_v.cpp`, `turbo_a.cpp`, `resnet.h`) for memory maps, table derivations and cr

Says it matches, follows or was checked against MAME — 1

rtl/video/sprite_engine.v:45 visible scanlines, y=0..VDISP-1 (matches MAME cliprect.min_y/max_y)

Shares text with the MAME driver without saying so — 2

rtl/segavco.v:970 or 4'hf if plb==0 (MAME: countl_zero(bitswap<8>(plb,0,1,2,3,4,5,6,7)) with — shares text with sega/turbo.cpp:1813
rtl/video/fg_tilemap.v:23 [8, 0x108) (MAME turbo_v.cpp: `foreraw = (xx<8||xx>=0x108) ? 0 : — shares text with sega/turbo_v.cpp:459

SegaVICZ80#
Carnival, Pulsar
MiSTer-devel/Arcade-SegaVICZ80_MiSTer @ 275d0d7e
MAME compared: sega/vicdual.cpp + 12 related file(s)
Read: 31 HDL files, 18,130 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 2 toward hardware, 2 toward MAME

Cites hardware documentation that MAME's driver does not — 2

rtl/system.v:432 Samurai protection circuit - taken from MAME as I can't find the schematics
rtl/system.v:652 - The U44 PROM and surrounding circuitry for colour output is taken from the Head On 2 schematic

Cites MAME source — 1

rtl/system.v:928 Wave sample player module - Used by Carnival, Invinco and Pulsar to emulate analog sound board by playing WAV samples sourced from MAME project

Says it was translated, ported or taken from MAME — 1

rtl/system.v:432 Samurai protection circuit - taken from MAME as I can't find the schematics

SegaXBoard#
A.B. Cop, After Burner, After Burner II, GP Rider …
MiSTer-devel/Arcade-SegaXBoard_MiSTer @ 83bb1314
MAME compared: sega/segaxbd.cpp + 12 related file(s)
Read: 31 HDL files, 5,748 lines (Quartus project)

MiSTer official

Mostly MAME

medium

67%

Statements: 8 toward hardware, 76 toward MAME

Cites hardware documentation that MAME's driver does not — 1

rtl/io/xb_adc0804.sv:6 Channel select = I/O chip #1 port C bits 4:2 (MAME, from the schematic).

Says it was checked on “real hardware” — 6

README.md:21 | M7 | After Burner and Thunder Blade | done: aburner (1.32/1.31), thndrbld1, thndrbldd confirmed on hardware; Thunder Blade pixel-exact vs MAME; FD1094 parent
README.md:22 | M8 | Super Monaco GP | done: smgpd (decrypted bootleg) with the second sound board and driving inputs, pixel-exact vs MAME, confirmed on hardware; official FD
README.md:24 | M10 | Racing Hero and A.B. Cop | done: six sets (bootlegs pixel-exact vs MAME, FD1094 parents), confirmed on hardware |
README.md:25 | M11 | GP Rider | done: three single-board FD1094 sets, confirmed on hardware |
README.md:26 | M12 | Last Survivor | done: input multiplexer, two players, bootleg and FD1094 sets, confirmed on hardware |
README.md:27 | M13 | Line of Fire | done: six sets, lightgun/gamepad gun control with cursor speed and crosshair, confirmed on hardware |

Notes where it differs from MAME — 1

README.md:165 `docs/DESIGN.md` records the results per milestone, and where the RTL deliberately differs from MAME.

Cites MAME source — 63

rtl/audio/xb_segapcm_5218.sv:2 Sega 315-5218 PCM (SegaPCM), MAME segapcm.cpp with BANK_512 (bankshift 12, bankmask 0x70).
rtl/audio/xb_segapcm_5218.sv:9 The sums are in MAME's 1/32768 units, i.e. directly 16-bit samples.
rtl/audio/xb_segapcm_5218.sv:11 ROM bytes come from SDRAM port p6 (16-bit words, byte selected by A0); the stream pads the PCM slot with 0xFF like MAME's ERASEFF region.
rtl/audio/xb_segapcm_5218.sv:42 MAME m_low: addr[7:0] per channel
rtl/audio/xb_soundsys.sv:7 Mix: MAME routes PCM at 0.35 and the YM2151 at 0.15 of full scale.
rtl/cpu/fd1094/jts16_fd1094_dec.v:146 decoding, pretty much copy-paste from MAME's fd1094.cpp I trust the synthesizer to simplify the equations
rtl/cpu/xb_cmptimer_5250.sv:2 Sega 315-5250 compare / timer / 68000-Z80 interface Word offsets (address bits 4:1), reference MAME segaic16_m.cpp: 0,1 bounds (write executes compare) 3 flags: 0x8000 below min,
rtl/cpu/xb_cmptimer_5250.sv:37 MAME's m_bit keeps counting; bits >= 16 fall off the u16
rtl/cpu/xb_math_5248.sv:4 Reference: MAME segaic16_m.cpp.
rtl/cpu/xb_math_5249.sv:10 Reference: MAME segaic16_m.cpp sega_315_5249_divider_device::execute.
rtl/cpu/xb_math_5249.sv:74 operands as they are after this same write (MAME updates the register first, then executes)
rtl/cpu/xb_math_5249.sv:151 MAME: remainder = dividend - clamped_q * divisor
rtl/io/xb_adc0804.sv:6 Channel select = I/O chip #1 port C bits 4:2 (MAME, from the schematic).
rtl/io/xb_adc0804.sv:7 Reference MAME adc0804.cpp + segaxbd.cpp analog_r.
rtl/io/xb_adc0804.sv:49 sampled at end of conversion (MAME)
rtl/io/xb_cxd1095.sv:6 Reference MAME cxd1095.cpp.
rtl/io/xb_cxd1095.sv:22 latch & ~dir (as MAME's dataout)
rtl/io/xb_cxd1095.sv:28 1 = input, per MAME m_data_dir
rtl/io/xb_stick.sv:5 Three opt-ins: ramp the D-pad drives a virtual stick 5 counts a frame (full lock in 26 frames, near MAME's PORT_KEYDELTA(4) over 0x20..0xE0) instead of snapping ~recenter releasing the D-pad leaves the virtual stick where it is; the op
rtl/mem/xb_fb_if.sv:5 Empty framebuffer pixel = 0xFFFF (MAME's transparent value).
rtl/mem/xb_fb_if.sv:6 Services (per DESIGN.md): - erase_line(y): fill line with 0xFFFF - write_run(...): pixel run writes from the sprite renderer; wr_shadow runs RMW dest &= 0x7fff instead (MAME shadow sprites clear framebuffer bit 15) - read_line(y):
rtl/video/xb_palette_5242.sv:4 Palette word: bit 15 = effects select (1 hilight / 0 shadow), 14:12 = LSB of B/G/R, 11:8 B, 7:4 G, 3:0 R (MAME paletteram_w).
rtl/video/xb_road_5275.sv:2 Sega 315-5275 road generator (X Board), MAME segaic16_road.cpp segaic16_road_outrun_draw with the X Board parameters (colorbase 0x1700 / 0x1720 / 0x1780, xoffs -166, control mask 7).
rtl/video/xb_road_5275.sv:73 MAME priority_map
rtl/video/xb_road_5275.sv:141 background colour for this line (MAME ROAD_BACKGROUND pass)
rtl/video/xb_sprite_5211.sv:4 Algorithm: MAME sega16sp.cpp sega_outrun_sprite_device::draw (xboard): w0: e------- -------- end of list; -h-h---- hide; ----bbb- bank; -------t tttttttt top + 256 w1: ROM offset (16-bit words of 32-bit pixels) w2: ppppppp- pitch (signed,
rtl/video/xb_sprite_5211.sv:20 At vblank the buffers swap only if a render ran since the previous swap, so a frame without a $110000 write keeps displaying the old image exactly like the real chip (MAME's every-frame redraw of the buffered list is an emulator artefact wi
rtl/video/xb_sprite_5211.sv:115 data[7] in MAME: the row's working pointer
rtl/video/xb_sprite_5211.sv:116 `addr` above is the row base, advanced by pitch at each row end (MAME's addr)
rtl/video/xb_sprite_5211.sv:134 pixel reordering for non-flipped sprites (MAME): reverse the nibble order
rtl/video/xb_sprite_5211.sv:140 MAME clips to the screen
rtl/video/xb_sprite_5211.sv:141 framebuffer x window: MAME clips to screen x 0..319 = fb x 190..509 (2x: 380..1019)
rtl/video/xb_sprite_5211.sv:291 MAME: data[7] = addr at row start
rtl/video/xb_sprite_5211.sv:306 MAME: second-to-last pixel of the group
rtl/video/xb_sprite_5211.sv:362 skip an off-screen row but advance the base address exactly like MAME (its own state so row_sum has settled since the last yacc write)
rtl/video/xb_tilemap_5197.sv:2 Sega 315-5197 tilemap generator, "16B" register layout (MAME segaic16.cpp tilemap_16b_*).
rtl/video/xb_tilemap_5197.sv:7 Text RAM (word offsets): 0x740..0x743 page select set 0..3 (E80..E87) 0x748..0x74B y scroll set 0..3, bit 15 = column scroll on (E90..E97) 0x74C..0x74F x scroll set 0..3, bit 15 = row scroll on (E98..E9F) 0x7C0 + 0x20*layer + (y>>3)
rtl/video/xb_tilemap_5197.sv:16 Tile word: 15 priority, 12:6 colour, 12:0 code (they overlap, as in MAME).
rtl/video/xb_tilerom.sv:5 Plane 2 (third ROM, epr-11113) is pen bit 2 (MAME gfx_8x8x3_planar: RGN_FRAC(2,3) is the MSB plane).
rtl/video/xb_video_timing.sv:4 MAME: m_screen->set_raw(MASTER_CLOCK/8, 400, 0, 320, 262, 0, 224).
rtl/video/xb_video_timing.sv:61 Sync widths follow the System 16-family convention used by MAME's screen layout: hsync from 336..367 (32 px), vsync lines 240..243 (4 lines).
rtl/xb_core.sv:161 ---------------------------------------------------------------- watchdog MB3773: kicked by I/O chip #1 port C bit 6 and by every vblank (MAME update_main_irqs).
rtl/xb_core.sv:195 main 68000 RESET instruction -> sub CPU reset (MAME m68k_reset_callback)
rtl/xb_core.sv:306 MAME writes 0xFFFF to word 0 of the bank handed back to the CPU after the swap ("hack for thunderblade"); it is invisible on After Burner II, so it is enabled per game through the descriptor.
rtl/xb_core.sv:350 MAME: active low unknown -> 1), D6 = ADC /INTR (active high), D7 n/c
rtl/xb_core.sv:352 MAME aburner2_motor_r / smgp_motor_r
rtl/xb_core.sv:357 Last Survivor: I/O chip 1 port B reads one of four input groups selected by I/O chip 0 port D bits 6:5 (MAME lastsurv_muxer_w / lastsurv_port_r): 0 = P2 stick + aim, 1 = P1 stick + aim, 2 = attack buttons (P1 bit 4, P2 bit 0), 3 = nothing.
rtl/xb_core.sv:360 The aim rotary is an 8-position encoder read back as a 4-bit active-low direction pattern (MAME lastsurv_position_table); it follows the right stick and keeps its last direction when released.
rtl/xb_core.sv:390 Positions are 0..255 like MAME's lightgun ports; the ADC reversal of the Y channels comes from the descriptor (MAME install_loffire).
rtl/xb_core.sv:438 MAME: set_display_enable(data & 0x20)
rtl/xb_core.sv:441 After Burner: MAME's ranges X 0x20..0xE0, Y 0x40..0xC0 with PORT_REVERSE (stick up reads high), throttle on channel 2.
rtl/xb_core.sv:485 driving (Super Monaco GP): steering 0x38..0xC8 on ADC0, gas 0x38..0xB8 on ADC1, brake 0x28..0xA8 on ADC2 (MAME ranges).
rtl/xb_core.sv:501 GP Rider: steering full range 0x01..0xFF on ADC0, pedals 0x10..0xEF read the other way up from the rest of the driving games (MAME PORT_REVERSE on both pedals): released is 0xEF, floored is 0x10.
rtl/xb_core.sv:807 crosshair overlay for the gamepad gun mode (P1 white, P2 yellow): the 0..255 positions map to the 320x224 screen as MAME's crosshairs do
rtl/xb_core.sv:842 Super Monaco GP's second sound board (deluxe cabinet rear speakers): the same Z80 + 315-5218 without the YM2151, fed by the same 315-5250 latch and NMI (MAME appends soundcpu2 to the zint line; either Z80's port 0x40 read clears it).
rtl/xb_pkg.sv:14 ---- video timing (MAME: MASTER_CLOCK/8, 400, 0, 320, 262, 0, 224) -----
README.md:15 | M1 | Both 68000s boot, math/timer/IO chips pass unit tests, PC traces track MAME | done in sim (self-test screen check moves to M2) |
README.md:20 | M6 | Hardware bring-up and timing closure | done: DIPs, NVRAM, MAME analog ranges, pause; zero negative slack all corners, 49% ALMs; ROM cache fill defect fix
README.md:45 | Game | MAME set | ROM zips (MAME 0.289) | Main CPU |
README.md:130 Needs Verilator, Icarus Verilog, Python 3.12 and MAME.
README.md:232 **MAME** (mamedev.org) — the behavioural reference for the whole board: `segaxbd.cpp` and the 16-bit Sega device family (`segaic16`, `sega16sp`, `segaic16_road`
README.md:236 Every custom chip model in `verif/models/` is a port of the MAME code, and MAME 0.289 produced the golden frames, traces and audio the RTL is checked against.
README.md:239 **Charles MacDonald** — "Sega X-Board hardware notes" (2004), the real-hardware description of the sprite sequencing, memory map and I/O used where MAME simplif

Says it matches, follows or was checked against MAME — 6

README.md:16 | M2 | Tilemap/text/palette pixel-exact against MAME | done in sim |
README.md:21 | M7 | After Burner and Thunder Blade | done: aburner (1.32/1.31), thndrbld1, thndrbldd confirmed on hardware; Thunder Blade pixel-exact vs MAME; FD1094 parent
README.md:22 | M8 | Super Monaco GP | done: smgpd (decrypted bootleg) with the second sound board and driving inputs, pixel-exact vs MAME, confirmed on hardware; official FD
README.md:23 | M9 | FD1094 | done: decryptor unit-verified against MAME; encrypted Thunder Blade and Super Monaco GP (World, Rev B) pixel-exact vs MAME and confirmed on hard
README.md:24 | M10 | Racing Hero and A.B. Cop | done: six sets (bootlegs pixel-exact vs MAME, FD1094 parents), confirmed on hardware |
README.md:157 What the tests show: the custom chips are checked against Python ports of MAME's C++ (the 315-5248/5249/5250 over 10^5 random operations, the FD1094 over 30,000

Says it was translated, ported or taken from MAME — 1

rtl/video/xb_mixer.sv:2 X Board video priority mixer (315-5279 PAL + 315-5197 pixel bus), a direct port of MAME segaxbd_state::screen_update: road background -> [road fg if road_priority == 0] -> bg pri0 (mark 1) -> bg pri1 (2) -> fg pri0 (2) -> fg pri1 (4) -> [ro

Keeps a MAME approximation — 2

rtl/xb_core.sv:190 GP Rider (MAME m_gprider_hack): with the link board absent the game must not see level 6, so timer+vblank together present level 4 (the timer follows after)
rtl/xb_pkg.sv:53 ---- per-game descriptor (first 64 bytes of the stream) ---------------- byte 0: game id (0 = aburner2, 1 = aburner, 2 = thndrbld, ...) byte 1: flags: bit0 road_priority (0: road fg under tiles, 1: over) bit1 thndrbld sprite-RAM wipe hack b

Shares text with the MAME driver without saying so — 4

rtl/cpu/xb_math_5249.sv:10 Reference: MAME segaic16_m.cpp sega_315_5249_divider_device::execute. — shares text with sega/segaic16_m.cpp:180
rtl/video/xb_sprite_5211.sv:379 yacc += vzoom; addr += pitch * (yacc >> 9); yacc &= 0x1ff — shares text with sega/sega16sp.cpp:1208
rtl/video/xb_video_timing.sv:4 MAME: m_screen->set_raw(MASTER_CLOCK/8, 400, 0, 320, 262, 0, 224). — shares text with sega/segaxbd.cpp:1842
rtl/xb_pkg.sv:14 ---- video timing (MAME: MASTER_CLOCK/8, 400, 0, 320, 262, 0, 224) ----- — shares text with sega/segaxbd.cpp:1842

SeibuCupSoccer#
Seibu Cup Soccer
MiSTer-devel/Arcade-SeibuCupSoccer_MiSTer @ 52c9fa22
MAME compared: seibu/legionna.cpp + 8 related file(s)
Read: 21 HDL files, 10,080 lines (Quartus project)

MiSTer official

Mostly MAME

medium

83%

Statements: 7 toward hardware, 234 toward MAME, 1 not counted

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/SeibuCup/SeibuCup_maincpu_map.sv:23 Main CPU memory map SeibuCup / SD Gundam (legionna.cpp cupsoc_map): $000000-$0FFFFF ROM 68K (1MB) → SDRAM via bridge $100000-$1003FF RAM scratch (1KB) → BRAM (Main RAM low) $100400-$1006FF COP3 region — also in MAME: 68K seibu/legionna.cpp:46

Says it was checked against the original PCB — 1

README.md:28 The core boots, plays and has been checked against the original PCB.

Reports a measurement taken on the original PCB — 1

rtl/SeibuCup/SeibuCup_video_timing.sv:26 PCB measurement Blood Bros: VSync 59.4094 Hz, HSync 15.6246 kHz, master XTAL 20 MHz.

Says it was checked on “real hardware” — 4

rtl/SeibuCup/SeibuCup_cop3.sv:387 0 : 1 (unsigned <320 provato su HW = REGRESSIONE; il signed [-160,320) dell'intento MAME e' il comportamento giusto sul core)
rtl/SeibuCup/SeibuCup_sprite_renderer.sv:218 byte_lo = pf_rom_data[31:24]/[15:8], byte_hi = [23:16]/[7:0] Plane order DCBA (verificato su HW, come BG/MG/FG): pen[0] dal bit "D" (byte_hi[3-sub]), pen[3] dal bit "A" (byte_lo[7-sub]).
rtl/SeibuCup/SeibuCup_sprite_renderer.sv:368 Scan INVERSO 511→0 (verificato su HW: ordine sprite-su-sprite opposto al loop MAME 0→511).
rtl/SeibuCup/SeibuCup_tile_layer.sv:322 Plane order verificato su HW: BG/MG = DCBA (PEN_ORDER=0), FG = BADC (PEN_ORDER=1).

Notes where it differs from MAME — 1

rtl/SeibuCup/SeibuCup_cop3.sv:3130 La chiave e' la word CON SEGNO all'indirizzo ALLINEATO AL LONG: key = read_word( (sort_ram + val) & ~3 ) E' l'unica funzione che soddisfa i due testimoni del ROM: piani $00363E: $110004 + val (val ≡0 mod 4) = $1157EC, e la chiave e' la Y

Cites MAME source — 216

SeibuCup.sv:225 La finestra visibile e' set_visarea(0,319, 8,247): in MAME lo sprite a Y=8 finisce sulla riga 8 della bitmap, che la visarea mostra IN CIMA (m_xoffset/m_yoffset del SEI0211 sono 0, legionna.cpp non chiama set_offset).
SeibuCup.sv:354 --- Joystick to SD Gundam input mapping --- MAME P1_P2 port ($E0002): active low.
SeibuCup.sv:357 MiSTer joy bits: joy[0]=R, joy[1]=L, joy[2]=D, joy[3]=U, joy[4]=A, joy[5]=B. MAME PLAYERS12 (legionna.cpp:439-444): bit[0]=UP, [1]=DOWN, [2]=LEFT, [3]=RIGHT, [4]=BTN1, [5]=BTN2, [6]=BTN3, [7]=unused (active low).
SeibuCup.sv:377 SeibuCup SYSTEM port ($10074C) — MAME legionna.cpp:427-436 bit0 = START1 (active LOW) bit1 = START2 (active LOW) bit2..7 = UNKNOWN → tied 1 bit8..15 = UNKNOWN → tied 1 Coin inputs NON sono qui: vanno via SEIBU_COIN_INPUTS → Z80 → soundlatch
SeibuCup.sv:384 bit8 = START3, bit9 = START4 (MAME porta "SYSTEM" di cupsoc).
SeibuCup.sv:421 00 = cupsoc / cupsoca nessuna modifica 01 = olysoc92 / a / b [$0FFFFE] = $3032 -> titolo Olympic Soccer '92 02 = cupsocb [$0FFFFA] = $00FF -> spegne il testo di debug Sono le stesse due scritture che MAME fa in ini
SeibuCup.sv:773 ── Flip screen (CRTC reg 0x1A bit 0) ─────────────────────────────────────── MAME: BIT(reg_1a, 0) → flip_screen.
SeibuCup.sv:819 ── Text layer renderer (8x8, 4bpp, 64x32 grid) ───────────────────────────── SeibuCup MAME (ROM_START godzilla): "char" = REGIONE PROPRIA 128KB (11.620/10.615, ROM_LOAD16_BYTE), NON dentro user1 come Legionnaire.
SeibuCup.sv:832 SeibuCup text scroll-base (CRTC reg 0x3A, hook godzilla-only legionna.cpp:1326).
SeibuCup.sv:833 Calibrazione HW di famiglia (dump vregs in seibu_crtc.cpp): Legionnaire reg=0x01FF, visarea da riga 16 → 0x1FF-0x1EF=+16 = ESATTAMENTE il vecchio yoff text +16 del core Legionnaire funzionante; D-Con reg=0xFFEF (low9=0x1EF), visarea da 0 →
SeibuCup.sv:837 La formula MAME set_scrolldy(0x1EF-data) è INVERTITA rispetto all'HW (convenzione dy del tilemap.cpp) — mai fidarsi del verso MAME.
SeibuCup.sv:875 SeibuCup CRTC scroll passthrough (legionna_v.cpp:34-49 tile_scroll_w): scroll_ram[0/1] → BG (m_background_layer) scroll_ram[2/3] → MG (m_midground_layer) scroll_ram[4/5] → FG (m_foreground_layer) Nel nostro CRTC: xscroll_l0 = ram[0/1], xscr
SeibuCup.sv:880 Finestra visibile di CUPSOC: legionna.cpp fa screen.set_visarea(0*8, 40*8-1, 1*8, 31*8-1) = [0..319] x [8..247] quindi origine X = 0 e origine Y = 8.
SeibuCup.sv:905 SeibuCup BG: tilemap 32x32 (legionna_v.cpp:204).
SeibuCup.sv:906 MAME GFXDECODE "back" color base = 0 (gfx_legionna riga 1168), 32 colorset.
SeibuCup.sv:907 HAS_TRANSP=1 perché m_background_layer->set_transparent_pen(15) in legionna_v.cpp:216 (pen 15 = trasparente, NON opaco come Blood Bros).
SeibuCup.sv:929 SeibuCup MG: 16x16, 4bpp, 32x32 tilemap (legionna_v.cpp:204).
SeibuCup.sv:930 get_mid_tile_info_share_bgrom (legionna_v.cpp:158): MG share BG ROM, tile = (vram & 0xfff) | 0x1000 (= seconda metà della BG ROM) color = ((vram >> 12) & 0xf) | 0x10 (= palette set superiore: bit 4 = 1) In palette MAME "back" base = 0,
SeibuCup.sv:957 SeibuCup FG: tilemap 32x32 (legionna_v.cpp:213).
SeibuCup.sv:959 MAME GFXDECODE "fore" color base = 32*16 = 0x200, 16 colorset.
SeibuCup.sv:969 SEIBUCUP: fore = bg2.619 ROM_LOAD16_WORD_SWAP (legionna.cpp:1987) = IDENTICO alla back bg1.618 → stesso decode DCBA di BG/MG (riscontro HW utente: col BADC il FG era sbagliato).
SeibuCup.sv:977 SeibuCup: bit 2 = FG (legionna_v.cpp:344)
SeibuCup.sv:1064 Anticipando di 1 l'indirizzo e il DE, il dato campionato al tick e' quello del pixel CORRENTE: allineamento coi tile ripristinato (= calibrazione +1 pixel-hunting MAME, fatta prima del fix CRT) e colonna 0 coperta.
SeibuCup.sv:1098 MAME riferimenti (VIDEO_START cupsoc, legionna_v.cpp:276-287): m_sprite_pri_mask per cupsoc: pri=0 → 0xFFF0 (copre pri-value 0,1,2 → bg,mg,fg → SOTTO text) pri=1 → 0xFFFC (copre 0,1 → bg,mg → sotto fg,text) pri=2 → 0xFFFE (copre 0 → bg →
SeibuCup.sv:1108 Ordine composite RTL (front→back), derivato dalle pri_mask sopra: Sprite pri=3 (sopra tutto, text incluso) Text (pri-value 4) Sprite pri=0 (sopra bg/mg/fg, sotto text) FG (pri-value 2) Sprite pri=1 (sopra bg/mg) MG
rtl/SeibuCup/SeibuCup_audio_z80.sv:25 Spec da MAME (legionna.cpp godzilla machine config :1295-1355): - Z80 @ 14.318180/4 = 3.579545 MHz (seibu_sound_map + godzilla_sound_io_map) - YM3812/OPL2 (jtopl2) @ 3.579545 MHz - OKI M6295 (jt6295) @ 20MHz/20 = 1.000 MHz, PIN7=HIGH, ROM 5
rtl/SeibuCup/SeibuCup_audio_z80.sv:57 SeibuCup pcm.922 = 512KB: bit 18 = bank (Z80 IO port 0, MAME godzilla_oki_bank_w: set_rom_bank(data&1)).
rtl/SeibuCup/SeibuCup_audio_z80.sv:385 MAME seibu_sound_device::main_r (seibusound.cpp:279): case 2,3: return sub2main[offset-2] (soundlatch data: coin/input dal Z80) case 5: return main2sub_pending ?
rtl/SeibuCup/SeibuCup_audio_z80.sv:446 ─── YM3812 (jtopl2) mono — CUPSOC usa OPL2, non OPM ──────────────────── MAME cupsoc machine config: ym3812_device @ 14318180/4 (legionna.cpp).
rtl/SeibuCup/SeibuCup_audio_z80.sv:491 ─── OKI M6295 (jt6295) — PIN7_HIGH (20MHz/20 = 1.0 MHz, legionna.cpp:1345)
rtl/SeibuCup/SeibuCup_cop3.sv:4 MAME-faithful implementation of the Seibu SEI300 chip as used by the `legionna` driver (SeibuCup 1992 — Banpresto/TAD).
rtl/SeibuCup/SeibuCup_cop3.sv:7 Reference (in this repo): MAME seibucop.cpp MAME seibucop_cmd.ipp MAME seibucop_dma.ipp MAME legionna.cpp
rtl/SeibuCup/SeibuCup_cop3.sv:140 Z-sorting DMA: registri $100450-$100458 (MAME cop_sort_*).
rtl/SeibuCup/SeibuCup_cop3.sv:153 MAME cop_itoa_digits[10]: BCD digits of cop_itoa (low<<0 | high<<16).
rtl/SeibuCup/SeibuCup_cop3.sv:157 Il vecchio loop a sottrazioni ripetute era O(valore) (~valore/9 clk): con i long 32-bit di godzilla (score, writer $156E/$1F93E) il 68k restava congelato (dma_busy include bcd_pending) fino a MILLISECONDI per chiamata — su MAME/HW reale i d
rtl/SeibuCup/SeibuCup_cop3.sv:170 MAME cop_program command table (seibucop.cpp lines 318-457) At boot, game code uploads 32 macro slots × 8 micro-op words via pgm_addr (0x100434) → slot*8 + sub-index pgm_data (0x100432) → micro-op word pgm_value (0x100438) → cop_func_valu
rtl/SeibuCup/SeibuCup_cop3.sv:177 MAME calls find_trigger_match(triggerval, 0xff00) to find the slot whose cop_func_trigger matches.
rtl/SeibuCup/SeibuCup_cop3.sv:299 Triggers (write-only addresses) MAME legionna.cpp:172 maps cop_cmd_w to $100500-$100505 (3 words).
rtl/SeibuCup/SeibuCup_cop3.sv:381 0x100410 sprite_dma_inc (MAME cop_sprite_dma_inc_w): if x_clip in [-160, 320): cop_regs[4] += 8.
rtl/SeibuCup/SeibuCup_cop3.sv:382 MA in MAME sprite_x e' uint16_t assegnato a int -> MAI negativo -> il -160 e' codice morto: check EFFETTIVO = unsigned < 320 (X "negative" 0xFFxx NON avanzano il puntatore entry).
rtl/SeibuCup/SeibuCup_cop3.sv:387 0 : 1 (unsigned <320 provato su HW = REGRESSIONE; il signed [-160,320) dell'intento MAME e' il comportamento giusto sul core)
rtl/SeibuCup/SeibuCup_cop3.sv:394 A size==0 NON wrappare (il size-- uint di MAME wrapperebbe a $FFFF: il loop del builder su status[1] andrebbe in livelock — provato peggio).
rtl/SeibuCup/SeibuCup_cop3.sv:437 Macro program upload — MAME seibucop.cpp lines 318-457 pgm_data writes one micro-op word to cop_program[latch_addr] AND latches the slot's trigger/value/mask from current latch regs.
rtl/SeibuCup/SeibuCup_cop3.sv:538 itoa_digits (MAME 0x100590-99, 5 word).
rtl/SeibuCup/SeibuCup_cop3.sv:550 Status / dist / angle (seibucop.cpp:916 cop_status_r → cop_status)
rtl/SeibuCup/SeibuCup_cop3.sv:558 MAME open bus
rtl/SeibuCup/SeibuCup_cop3.sv:625 commit write al dst ASSOLUTO (fill/mr), 1:1 MAME write_word(dst)
rtl/SeibuCup/SeibuCup_cop3.sv:661 LEGACY sprite-DMA (seibucop_cmd.ipp): 6880 (carica rel_xy), c480 (single-step: compone l'entry sprite a cop_regs[4]+offs con X/Y = rel + (obj - abs)).
rtl/SeibuCup/SeibuCup_cop3.sv:685 write angolo (word {0,angle} come MAME host_endian)
rtl/SeibuCup/SeibuCup_cop3.sv:686 5105/f105 — moltiplicatore 16.16 (ricavato da ROM+disasm, non da MAME: li' gli handler sono vuoti).
rtl/SeibuCup/SeibuCup_cop3.sv:698 dde5 — i PALLINI DEL RADAR (MAME LEGACY_execute_dde5).
rtl/SeibuCup/SeibuCup_cop3.sv:752 Trigger latches — MAME seibucop.cpp cop_cmd_w line 1069.
rtl/SeibuCup/SeibuCup_cop3.sv:753 MAME dispatches on raw data after clearing cop_status bit 15.
rtl/SeibuCup/SeibuCup_cop3.sv:807 DMA mode 0x80-0x87: MAME dma_palette_brightness() fa FADE solo con pal_brightness_mode 4/5; con qualsiasi altro valore fa una COPIA SEMPLICE src->dst (ramo else, seibucop_dma.ipp:119-123) verso QUALUNQUE dst — incl.
rtl/SeibuCup/SeibuCup_cop3.sv:815 DMA generici 0x09/0x0E: MAME write_word(dst) va nello spazio host = arriva a QUALSIASI RAM mappata, incluse le BRAM video ($101000-$105FFF: staging tilemap, palette-stage $104000, sprite $105000).
rtl/SeibuCup/SeibuCup_cop3.sv:823 Output del fade/blend 0x8x: MAME dma_palette_brightness fa write_word(dst) nello SPAZIO HOST = raggiunge QUALUNQUE RAM mappata (pal-stage $104000, sprite $105800, Main RAM...).
rtl/SeibuCup/SeibuCup_cop3.sv:826 Ora: pal_val registrato in D_FADE_WRITE e committato in D_FADE_COMMIT via canale fill (decode per dst assoluto in main_top: bg/fg/mg/txt/pal/spr) o mr (dst in Main RAM) — 1:1 MAME.
rtl/SeibuCup/SeibuCup_cop3.sv:829 (Il vecchio dma80_to_spr era INVERTITO: il blit pietre e' src=$105800 dst=$104000, non il contrario — MAME map: $100478=SRC, $10047C=DST.)
rtl/SeibuCup/SeibuCup_cop3.sv:838 LEGACY sprite-DMA state (MAME m_sprite_dma_rel_x/y, m_sprite_dma_x_clip)
rtl/SeibuCup/SeibuCup_cop3.sv:966 MAME cop_cmd_w (seibucop.cpp:1075):
rtl/SeibuCup/SeibuCup_cop3.sv:978 MAME cop_sort_dma_trig_w -> dma_zsorting(data): n = data + 1
rtl/SeibuCup/SeibuCup_cop3.sv:1006 find_trigger_match (seibucop.cpp:464) Cerca slot N tale che (trigger & 0xf800) == (cop_func_trigger[N] & 0xf800) && cop_func_trigger[N] != 0.
rtl/SeibuCup/SeibuCup_cop3.sv:1008 Restituisce canonical trigger value del slot (NB: MAME LEGACY_cop_cmd_w usa il match slot per dispatchare; in pratica equivale a restituire cop_func_trigger[slot]).
rtl/SeibuCup/SeibuCup_cop3.sv:1029 fade_table — MAME seibucop.cpp:733 (reverse engineered from Seibu Cup Soccer bootleg) v = pal_channel(5-bit) | (brightness_val_xor_X) [10-bit input] low = v & 0x1F high = v & 0x3E0 return (low * (high | (high>>5)) + 0x210) >> 10 [8-bit o
rtl/SeibuCup/SeibuCup_cop3.sv:1068 ── Hitbox b100/b900 scratch (MAME cop_collision_update_hitbox) ────────────── dx[i] = int8 (signed) byte basso, size[i] = uint8 (unsigned) byte alto del word descrittore @ hitadr2+2*i. 3 assi (Y,X,Z) per SeibuCup.
rtl/SeibuCup/SeibuCup_cop3.sv:1075 num_axis: MAME seibucop.cpp:1010 "if (data & 0x100) num_axis = 3" else 2.
rtl/SeibuCup/SeibuCup_cop3.sv:1077 res init 7 vs 3 (seibucop.cpp:1038-39).
rtl/SeibuCup/SeibuCup_cop3.sv:1083 Delta LATCHATI dall'ultimo comando d'angolo: il 3bb0 NON li ricalcola, li riusa (in MAME sono m_LEGACY_r0/r1, e il TODO sopra execute_3b30 dice esattamente questo).
rtl/SeibuCup/SeibuCup_cop3.sv:1107 dde5: divisore CON SEGNO (in MAME e' una divisione C int, quindi troncamento verso zero).
rtl/SeibuCup/SeibuCup_cop3.sv:1138 Con 16-bit frac + 24 iter + z>>16: 0 divergenze di decisione vs MAME int(atan(dx/dy)*128/pi) su ~640k casi (dimostrato numericamente).
rtl/SeibuCup/SeibuCup_cop3.sv:1391 MAME cop_dma_trigger_w: NON modifica cop_status (vedi seibucop.cpp:741).
rtl/SeibuCup/SeibuCup_cop3.sv:1399 MAME dma_tilemap_buffer: copy staging RAM → renderer BRAM src = cop_dma_src[mode] << 6 (byte addr 0x101000+ = staging) dst = i (loop counter 0..0x13FF = renderer index) count = 0x2800/2 = 5120 words
rtl/SeibuCup/SeibuCup_cop3.sv:1409 MAME dma_palette_buffer: copy staging palette → renderer src = cop_dma_src[mode] << 6 (0x104000 = palette staging) dst = i (loop counter 0..0x7FF = renderer index) count = 0x1000/2 = 2048 words
rtl/SeibuCup/SeibuCup_cop3.sv:1419 MAME write_word(dst) su spazio host: con dst nelle BRAM video ($101000-$105FFF: staging/pal/spr, es.
rtl/SeibuCup/SeibuCup_cop3.sv:1434 simplified, MAME size>>1
rtl/SeibuCup/SeibuCup_cop3.sv:1439 MAME seibucop_dma.ipp dma_palette_brightness() mode 5/4.
rtl/SeibuCup/SeibuCup_cop3.sv:1442 MAME formulas: src = cop_dma_src[mode] << 6 dst = cop_dma_dst[mode] << 6 size = ((cop_dma_size << 5) - (cop_dma_dst << 6) + $20)/2 Init: src=$106000, dst=$104000, size=($827F<<5 - $4100<<6 + $20)/2 = ($104FE0 - $104000 + $20)/2 = $1000
rtl/SeibuCup/SeibuCup_cop3.sv:1453 MAME size = (((size<<5) - (dst<<6) + 0x20)/2)
rtl/SeibuCup/SeibuCup_cop3.sv:1459 MAME: mode 4/5 = fade palette; QUALSIASI ALTRO = copia semplice src->dst (seibucop_dma.ipp:119-123).
rtl/SeibuCup/SeibuCup_cop3.sv:1469 MAME seibucop.cpp cop_dma_trigger_w case 0x116 — SEIBUCUP: fill come 0x118 ma SENZA guard dst!=0 e length bytes = (size+1)<<4 (metà).
rtl/SeibuCup/SeibuCup_cop3.sv:1471 legionna.cpp:56-61: "The COP-MCU appears to write to the work ram area, otherwise it RESETS in mid-animation of the title screen" → senza questo fill il gioco torna al logo da solo.
rtl/SeibuCup/SeibuCup_cop3.sv:1482 Skip if dst != 0 (MAME guard, dma.ipp:135)
rtl/SeibuCup/SeibuCup_cop3.sv:1502 MAME cop_cmd_w (seibucop.cpp:1073): cop_status &= 0x7fff (clear bit 15).
rtl/SeibuCup/SeibuCup_cop3.sv:1504 MAME: cop_status &= 0x7fff (clear bit 15).
rtl/SeibuCup/SeibuCup_cop3.sv:1519 MAME LEGACY_cop_cmd_w: find_trigger_match(data, 0xF800) → slot per GRUPPO f800, poi handler dal microcodice caricato.
rtl/SeibuCup/SeibuCup_cop3.sv:1569 MAME lo esegue come una somma, quindi raddoppia il passo invece di annullarlo.
rtl/SeibuCup/SeibuCup_cop3.sv:1572 MAME execute_0205: read dword at cop_regs[0]+4+offset*4 (ppos)
rtl/SeibuCup/SeibuCup_cop3.sv:1593 0x138e / 0x338e — atan(dx/dy) MAME execute_338e.
rtl/SeibuCup/SeibuCup_cop3.sv:1595 Parte da r1+4 hi (offset 0x0004), come 3BB0/MAME.
rtl/SeibuCup/SeibuCup_cop3.sv:1677 MAME LEGACY_execute_dde5 (seibucop_cmd.ipp): offs = (offset & 3) * 4 div = read_word(cop_regs[4] + offs) dir_offset = read_word(cop_regs[4] + offs + 8) if (div == 0) div = 1 write_word(cop_regs[6] + offs + 4, (read_word(cop_reg
rtl/SeibuCup/SeibuCup_cop3.sv:1716 MAME: raw_angle = cop_read_word(r0+0x34) = host_read_word(0x34^2 = 0x36); amp = cop_read_word(r0+0x36) = host_read_word(0x36^2 = 0x34).
rtl/SeibuCup/SeibuCup_cop3.sv:1733 0xa180 — collision read pos for slot 0 MAME cop_collision_read_pos: cop_read_word(spradr+N) = host_read_word((spradr+N)^2) per host_endian=true.
rtl/SeibuCup/SeibuCup_cop3.sv:1754 b000 NON e' un no-op: il dispatcher LEGACY di godzilla (seibucop.cpp:1365) matcha con mask 0xf800, quindi la patch init_godzilla (b100->b000) ESEGUE comunque l'update ma con num_axis=2 (bit8=0 = Z disattivata).
rtl/SeibuCup/SeibuCup_cop3.sv:1885 Mode 4 (SEIBUCUP/Denjin, seibucop_dma.ipp:87-117): indice = (val*2)[4:0], val 0x0010/0xFFFF = TARGET PURO, NESSUN bypass bit15.
rtl/SeibuCup/SeibuCup_cop3.sv:1944 MAME: m_host_space->write_word(dst, pal_val) — dst ASSOLUTO.
rtl/SeibuCup/SeibuCup_cop3.sv:1978 MAME (0x118 e 0x116): write_dword(i, v1 | v2<<16) su spazio BE 68k → word a i = v2, word a i+2 = v1 (alternati).
rtl/SeibuCup/SeibuCup_cop3.sv:1991 Macro 0x0205 — linear movement (MAME execute_0205) ppos = read_dword(cop_regs[0]+0x04) vel = read_dword(cop_regs[0]+0x10) npos = ppos + vel write_dword(cop_regs[0]+0x04, npos) delta = (npos>>16) - (ppos>>16) write_word(cop_regs[0]+0x1E, re
rtl/SeibuCup/SeibuCup_cop3.sv:2042 MAME cop_read/write_word(cop_regs[0]+0x1e) = host word @ (0x1e^2)=0x1c (host endianness word^2; conferma doc 06 micro-op 'addmem16 0x1C(r0)').
rtl/SeibuCup/SeibuCup_cop3.sv:2061 Macro 0x0905/0x0904 — jump (MAME execute_0904) write_dword(cop_regs[0]+0x10, read_dword(cop_regs[0]+0x10) ± read_dword(cop_regs[0]+0x28)) 0x0905 (bit 0=1) = +, 0x0904 (bit 0=0) = -
rtl/SeibuCup/SeibuCup_cop3.sv:2087 MAME execute_0904: bit 0 di data = 1 → add, =0 → sub tmp32_a = vel ± grav.
rtl/SeibuCup/SeibuCup_cop3.sv:2121 0x138E/0x338E atan(dx/dy) — MAME execute_338e (cmd.ipp:159) dx = read_dword(r1+4) - read_dword(r0+4) dy = read_dword(r1+8) - read_dword(r0+8) if(!dy){status|=0x8000; angle=0} else angle=atan(dx/dy)*128/pi; dy<0→+0x80 if(data&0x80) write_byt
rtl/SeibuCup/SeibuCup_cop3.sv:2169 MAME: angle = atan(dx/dy)*128/pi (+0x80 se dy<0).
rtl/SeibuCup/SeibuCup_cop3.sv:2171 Cosi' z = atan(dx/dy) e il +0x80 (in WR) copre solo il quadrante, come MAME.
rtl/SeibuCup/SeibuCup_cop3.sv:2173 NIENTE prescale: i dword diff sono FIXED-POINT coord<<16 (come il 3BB0 che usa dx32[31:16] e MAME dx>>16), NON interi piccoli.
rtl/SeibuCup/SeibuCup_cop3.sv:2225 MAME (int)(...) tronca VERSO ZERO.
rtl/SeibuCup/SeibuCup_cop3.sv:2227 BUG TROVATO (validato vs MAME su 29241 casi): il CORDIC SOTTO-CONVERGE di 1 LSB sulle DIAGONALI (es.
rtl/SeibuCup/SeibuCup_cop3.sv:2232 Compenso l'epsilon di sotto-convergenza con +1 toward-zero PRIMA del troncamento: bias=1 azzera tutte le 133 divergenze (bias=0) -> 0/29241 vs MAME.
rtl/SeibuCup/SeibuCup_cop3.sv:2241 MAME execute_338e (seibucop_cmd.ipp:175-188): la write dell'angolo in RAM (obj+0x34 host, gated da data&0x80) e' FUORI dall'if/else di dy -> avviene SEMPRE, anche a dy==0 (dove cop_angle=0 -> scrive 0^0x80 = 0x80).
rtl/SeibuCup/SeibuCup_cop3.sv:2247 Ora calcolo ang_byte in entrambi i rami e scrivo SEMPRE, come MAME.
rtl/SeibuCup/SeibuCup_cop3.sv:2254 Scrivere l'angolo anche a dy==0 ("1:1 MAME") REGREDISCE: il martello scivola/moonwalk.
rtl/SeibuCup/SeibuCup_cop3.sv:2257 MAME: dy==0 -> cop_angle=0
rtl/SeibuCup/SeibuCup_cop3.sv:2264 Il chip lavora in PIXEL: le tabelle del bootleg mettono distanza e angolo nella STESSA word, indicizzata da (A<<9)|B con A,B a 9 bit (la documentazione del progetto), e il nostro stesso 3bb0 tronca gia' i delta con dx32[31:16] (come MAME m_
rtl/SeibuCup/SeibuCup_cop3.sv:2275 Stesso difetto in MAME (if (!dx) sui 32 bit), da cui il sintomo identico nei due emulatori.
rtl/SeibuCup/SeibuCup_cop3.sv:2283 118e/e18e len 4 -> caricano solo dx/dy: NON scrivono 130e/e30e len 7 -> calcolano l'angolo, non lo scrivono 138e/e38e len 8 -> scrivono Con la regola del bit 7 (quella di MAME) e18e sovrascrive obj+$37 su tutti gli oggetti ogni frame, fra i
rtl/SeibuCup/SeibuCup_cop3.sv:2294 SEIBUCUP: write RAW — il ROM carica il microcode 138e variante cupsoc/SDGundam (tabella $498: ...b9a b9a A9A) = MAME LEGACY_execute_130e_cupsoc, SENZA ^0x80 (il ^0x80 e' della variante famiglia $B9A / is_yflip: legionna).
rtl/SeibuCup/SeibuCup_cop3.sv:2298 PROVA sim 8 casi: col ^0x80 vettore sincos INVERTITO 180° vs MAME → boss 138e-driven marcia via (stage 4).
rtl/SeibuCup/SeibuCup_cop3.sv:2300 ⛔ NON toccare il sincos (lookup diretto = sin MAME): toccarlo inverte i game-written = regressione build 13.
rtl/SeibuCup/SeibuCup_cop3.sv:2314 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197) dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (aritmetico) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = sqrt(dx*dx + dy*dy) if(data&0x80) write_word(r0 + (data&0x200?0x3a:0x38
rtl/SeibuCup/SeibuCup_cop3.sv:2381 E' il TODO dichiarato in MAME.
rtl/SeibuCup/SeibuCup_cop3.sv:2426 (Il fix MAME-aligned 0x3a:0x38 faceva fuggire i nemici -> MAME invertito vs HW.
rtl/SeibuCup/SeibuCup_cop3.sv:2433 MAME: macro completata → cop_status = 7 (gate-poll del gioco).
rtl/SeibuCup/SeibuCup_cop3.sv:2499 MAME: if (div == 0) div = 1
rtl/SeibuCup/SeibuCup_cop3.sv:2510 In MAME read_word e' unsigned e dir_offset int16_t: la somma e' int, la divisione int/int -> troncamento VERSO ZERO.
rtl/SeibuCup/SeibuCup_cop3.sv:2574 0x8100/0x8900 sin/cos (MAME execute_8100/8900) raw_angle = cop_read_word(cop_regs[0]+0x34) & 0xff amp = (65536>>5) * (cop_read_word(cop_regs[0]+0x36) & 0xff) = 2048 * amp_byte if (raw_angle == 0xC0 sin / 0x80 cos): amp *= 2 res = int(
rtl/SeibuCup/SeibuCup_cop3.sv:2613 MAME special-case: sin && raw==0xC0 OR cos && raw==0x80 → amp *= 2
rtl/SeibuCup/SeibuCup_cop3.sv:2659 0xa180/0xa980 — read pos (MAME cop_collision_read_pos) flags_swap = cop_read_word(spradr+2) → host_read_word(spradr+0) pos[0] = cop_read_word(spradr+6) → host_read_word(spradr+4) pos[1] = cop_read_word(spradr+10) → host_read_word(
rtl/SeibuCup/SeibuCup_cop3.sv:2666 Però MAME cop_read_word(+2) = host_read_word(+2^2) = host_read_word(+0).
rtl/SeibuCup/SeibuCup_cop3.sv:2677 rdata = word @ host+0 = flags (MAME cop_read_word(spradr+2) ^ 2).
rtl/SeibuCup/SeibuCup_cop3.sv:2686 rdata = word @ host+4 = pos[0] (Y axis per MAME)
rtl/SeibuCup/SeibuCup_cop3.sv:2706 0xb100/0xb900 — update hitbox & compute intersection (1:1 MAME cop_collision_update_hitbox, seibucop.cpp:1003-1065).
rtl/SeibuCup/SeibuCup_cop3.sv:2753 2 assi (b000/b800): terza word NON letta, dx/size azzerati (seibucop.cpp:1014-1022)
rtl/SeibuCup/SeibuCup_cop3.sv:2792 2 assi: l'asse 2 (Z) NON viene aggiornato (loop MAME i<num_axis)
rtl/SeibuCup/SeibuCup_cop3.sv:2811 res init: 3 assi = 111, 2 assi = 011 (seibucop.cpp:1038-39: bit Z gia' 0 = "collide banale" -> hit deciso solo da X/Y)
rtl/SeibuCup/SeibuCup_cop3.sv:2835 LEGACY 6880 — carica rel_xy per il prossimo c480 (MAME LEGACY_execute_6980: rel_xy = read_word(spr_src+4+offs))
rtl/SeibuCup/SeibuCup_cop3.sv:2856 LEGACY c480 — single-step sprite DMA (MAME LEGACY_execute_c480): info = read(spr_src+offs) + (param & 0x3f) -> entry+0 abs = read(regs[0]+8/+4) - spr_dma_abs_x/y X(fx/dx/rel_x) -> entry+4 (+ x_clip per l'inc $410) Y(fy/rel_y) -> entry+6
rtl/SeibuCup/SeibuCup_cop3.sv:2969 cupsoc carica il microcodice 3a0 3a6 380 aa0 2a6 => MAME LEGACY_execute_6200 ("this is for cupsoc, different sequence, works on different registers"): regs[1]+0x0c, NON regs[0]+0x34 della variante famiglia.
rtl/SeibuCup/SeibuCup_cop3.sv:2977 Write angolo = WORD {0,angle} (MAME host_endian write-word).
rtl/SeibuCup/SeibuCup_cop3.sv:2998 wrap a signed 8-bit (MAME: +=/-=256 su int)
rtl/SeibuCup/SeibuCup_cop3.sv:3023 MAME cop_write_byte(regs1+$0F): SOLO il byte basso (indirizzo dispari -> be[0], main_top.sv).
rtl/SeibuCup/SeibuCup_cop3.sv:3034 5105 / f105 — MOLTIPLICATORE 16.16 (nessun handler in MAME: ricavato da ROM + disasm di cupsoc).
rtl/SeibuCup/SeibuCup_cop3.sv:3117 Z-sorting DMA ($1006FE) — MAME dma_zsorting (seibucop_dma.ipp:164) n = data+1 val = read_word(lookup + 2*i) (RAW, senza xor) key = (int16)cop_read_word(sort_ram + val) (host (addr)^2, CON SEGNO) param 1 = crescente, 2 =
rtl/SeibuCup/SeibuCup_cop3.sv:3160 Bubble sort: swap SOLO se strettamente fuori ordine = stabile come lo std::stable_sort di MAME.
rtl/SeibuCup/SeibuCup_main_top.sv:246 VBLANK IRQ4 — MAME legionna.cpp: m_maincpu->set_vblank_int(irq4_line_hold) MAME HOLD_LINE: IRQ asserted on edge, released ONLY at IACK (= when CPU fetches vector).
rtl/SeibuCup/SeibuCup_main_top.sv:251 VBLANK IRQ4 — MAME legionna.cpp: m_maincpu->set_vblank_int(irq4_line_hold) MAME HOLD_LINE: IRQ asserted on edge, released ONLY at IACK (= when CPU fetches vector).
rtl/SeibuCup/SeibuCup_main_top.sv:513 COP3 cmd 0x14 dma_tilemap_buffer (legionna_v.cpp:86 videowrite_cb_w): offset 0x000..0x3FF → BG (back_data) offset 0x400..0x7FF → FG (fore_data) offset 0x800..0xBFF → MG (mid_data) offset 0xC00..0x13FF → Text (textram, 0x800 word) SRC
rtl/SeibuCup/SeibuCup_main_top.sv:537 Il fill scrive le BRAM STAGING (= la host RAM di MAME): il per-frame DMA 0x14/0x15 le propaga al renderer.
rtl/SeibuCup/SeibuCup_main_top.sv:551 ── SPLIT STAGING vs RENDERER (semantica MAME 2-stadi, come la palette) ───── MAME godzilla: $101000-$103FFF e' .ram() PURO (handler background_w/… COMMENTATI nel map, legionna.cpp) — le scritture CPU NON toccano i tilemap.
rtl/SeibuCup/SeibuCup_main_top.sv:554 I tilemap leggono m_back/fore/mid_data/m_textram = buffer SEPARATI (make_unique_clear, legionna_v.cpp) scritti SOLO da videowrite_cb_w = DMA 0x14.
rtl/SeibuCup/SeibuCup_main_top.sv:559 u_XX_ram = STAGING: porta A = CPU (+fill 0x116/0x118, come MAME che filla la host RAM), porta B = sorgente del DMA 0x14.
rtl/SeibuCup/SeibuCup_main_top.sv:562 Coppia contenuto/scroll = atomica a livello ISR, come MAME.
rtl/SeibuCup/SeibuCup_main_top.sv:634 ── Palette: split STAGING ($104000) vs RENDERER (semantica MAME 2-stadi) ─── MAME: la CPU e il fade (cmd 0x80) scrivono la STAGING RAM a $104000.
rtl/SeibuCup/SeibuCup_main_top.sv:674 MAME godzilla: $104000 e' RAM pura (legionna.cpp:262, handler palette commentato) — la palette VISIBILE si aggiorna SOLO via paletteramout_cb = dma_palette_buffer 0x15 (seibucop_dma.ipp:27); il fade DMA scrive lo STAGING (host RAM, dma.ipp:
rtl/SeibuCup/SeibuCup_maincpu_map.sv:23 Main CPU memory map SeibuCup / SD Gundam (legionna.cpp cupsoc_map): $000000-$0FFFFF ROM 68K (1MB) → SDRAM via bridge $100000-$1003FF RAM scratch (1KB) → BRAM (Main RAM low) $100400-$1006FF COP3 region
rtl/SeibuCup/SeibuCup_maincpu_map.sv:120 ─── Region detect (MAME cupsoc_map, legionna.cpp:324) ─────────────────
rtl/SeibuCup/SeibuCup_maincpu_map.sv:147 CUPSOC: spriteram e' META' di grainbow — $107000-$1077FF (2KB = 256 entry) e sopra c'e' la "Ani Dsp(?) Ram" $107800-$107FFF (RAM normale, MAME cupsoc_map).
rtl/SeibuCup/SeibuCup_maincpu_map.sv:228 MAME legionna_map: main_r/main_w(offset>>1) con umask16(0x00ff).
rtl/SeibuCup/SeibuCup_maincpu_map.sv:232 Vedi MAME seibusound.cpp main_r/main_w.
rtl/SeibuCup/SeibuCup_maincpu_map.sv:236 ─── GFX bank ──────────────────────────────────────────────────────────── cupsoc non ha il tile bank register ($100470 assente dalla mappa MAME): gfx_bank resta 0.
rtl/SeibuCup/SeibuCup_maincpu_map.sv:347 Replica la latenza-zero-osservabile di MAME (cop_cmd_w sincrono): il gioco legge cop_hit_val_stat/cop_angle ($188/$1b4) nell'istruzione dopo il trigger.
rtl/SeibuCup/SeibuCup_palette.sv:25 MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 128*16); (legionna.cpp:1212, 128*16 = 2048 entry) Address space CPU: 0x104000..0x104FFF (4 KB = 2048 word).
rtl/SeibuCup/SeibuCup_palette.sv:35 Espansione 5→8 standard MAME palette_device: {val5, val5[4:2]} (bit replication che riempie i 3 LSB con i 3 MSB del valore 5-bit).
rtl/SeibuCup/SeibuCup_palette.sv:85 SeibuCup: xBGR_555 → RGB888 (legionna.cpp:1212) Layout: bit[4:0]=R, bit[9:5]=G, bit[14:10]=B. 5 bit per canale.
rtl/SeibuCup/SeibuCup_palette.sv:87 Espansione 5→8 standard MAME palette_device: {val5, val5[4:2]} (replica i 3 MSB nei 3 LSB → range 0..255 con monotonia preservata).
rtl/SeibuCup/SeibuCup_seibu_crtc.sv:23 Seibu CRTC fedele a MAME (seibu_crtc.cpp).
rtl/SeibuCup/SeibuCup_seibu_crtc.sv:130 MAME mappa: bit0=screen0(BG), bit1=screen2(MG), bit2=screen1(FG), bit3=screen3(Text) (vedi seibu_crtc.cpp commento "screen 0=BG, screen 1=FG, screen 2=MG, screen 3=Text") In SD Gundam dcon.cpp layer_en_w gira la maschera così: ~layer_en bit
rtl/SeibuCup/SeibuCup_seibu_crtc.sv:139 Il dispatcher MAME usa "if (BIT(~m_layer_en, n))" per saltare = layer disabilitato quando il bit è 1.
rtl/SeibuCup/SeibuCup_seibu_crtc.sv:144 SeibuCup layer ordering (legionna_v.cpp:384-390 screen_update_SEIBUCUP): bit 0 = BG (background) bit 1 = MG (midground) bit 2 = FG (foreground) bit 3 = Text bit 4 = Sprites ATTENZIONE: e' l'OPPOSTO di legionna (screen_update_legionna :342-3
rtl/SeibuCup/SeibuCup_seibu_crtc.sv:165 Scroll-base 0x2C-0x3A (seibu_crtc.cpp:243 layer_scroll_base_w; screen0=BG, screen2=MG, screen1=FG, screen3=Text).
rtl/SeibuCup/SeibuCup_seibu_crtc.sv:166 Raw esce qui; le formule (delta vs riferimento godzilla, Y invertita come il set_scrolldy(0x1ef-data) di MAME) stanno nel top.
rtl/SeibuCup/SeibuCup_sprite_renderer.sv:25 Formato spriteram quasi identico (entrambi MAME sei021x_sei0220_spr.cpp) — differenze: - Spriteram @ 0x105000-0x105FFF (4KB, 1024 word, 256 entry × 4 word) - w3 bit 15 = tile bank extra bit (denjinmk usa, SeibuCup base = 0)
rtl/SeibuCup/SeibuCup_sprite_renderer.sv:30 Format word (legionna_v.cpp:288-312): w0 bit 15 = enable (0=draw, 1=skip — TODO verify SeibuCup) w0 bit 14 = flip_x w0 bit 13 = flip_y (???
rtl/SeibuCup/SeibuCup_sprite_renderer.sv:46 Priority callback legionna_v.cpp:314-317: pri_mask[0] = 0x0000 (sopra tutto) pri_mask[1] = 0xFFF0 pri_mask[2] = 0xFFFC pri_mask[3] = 0xFFFE
rtl/SeibuCup/SeibuCup_sprite_renderer.sv:140 CUPSOC: spriteram 2KB → 256 entry (MAME size/2/4 = 2048/2/4 = 256).
rtl/SeibuCup/SeibuCup_sprite_renderer.sv:146 Decoded fields — MAME sei0210_device::draw (non-alt format, riga 143): if (BIT(~spriteram[i], 15)) continue; → draw quando w0[15]==1.
rtl/SeibuCup/SeibuCup_sprite_renderer.sv:155 cupsoc_pri_cb (legionna_v.cpp:319): pri = (w1[15:14] & 2) | (ext & 1) → livello = {w1[15], w0[6]}.
rtl/SeibuCup/SeibuCup_sprite_renderer.sv:158 CUPSOC: pri_cb STANDARD (legionna_v.cpp pri_cb = mask[pri]) → livello = w1[15:14] pieno, NON il {w1[15],ext} di grainbow (che ha un pri_cb suo).
rtl/SeibuCup/SeibuCup_sprite_renderer.sv:170 MAME SEI0211 default m_xoffset/m_yoffset = 0 (sei021x_sei0220_spr.cpp:40-41).
rtl/SeibuCup/SeibuCup_sprite_renderer.sv:171 SeibuCup NON chiama set_offset (legionna.cpp:1214) → offset 0,0.
rtl/SeibuCup/SeibuCup_sprite_renderer.sv:203 Tile code finale Y-MAJOR (MAME draw_internal: ax=outer, ay=inner, code++): sub_index = ax*sizey + ay → cur_tile = code + eff_tile_x*sp_h + eff_tile_y cupsoc: NESSUN gfxbank_cb (legionna.cpp:1449, solo pri_cb) — code puro 14 bit.
rtl/SeibuCup/SeibuCup_sprite_renderer.sv:573 MAME gfx_legionna_spr: color base = 64*16 = 0x400 (64 colorset × 16 pen).
rtl/SeibuCup/SeibuCup_text_renderer.sv:25 Specifiche da MAME (legionna.cpp:1117-1126, 1167):
rtl/SeibuCup/SeibuCup_text_renderer.sv:47 Char ROM in MAME: "char" region 64KB = ROM_COPY user1[0x10000..0x1FFFF].
rtl/SeibuCup/SeibuCup_text_renderer.sv:140 MAME `legionna_v.cpp:214`: text tilemap = 64×32 (8x8 tiles, TILEMAP_SCAN_ROWS).
rtl/SeibuCup/SeibuCup_text_renderer.sv:186 --- Stage 3: pen decode (charlayout planes packed in nibbles) --- Per col c (0..3 dentro la half-tile), bit position = 3 - c. pen[0] = word[bit_pos + 0] (plane 0) pen[1] = word[bit_pos + 4] (plane 1) pen[2] = word[bit_pos + 8] (plane
rtl/SeibuCup/SeibuCup_text_renderer.sv:192 MAME readbit usa MSB-first: bit_offs N → byte[N/8] bit (7-N%8).
rtl/SeibuCup/SeibuCup_text_renderer.sv:193 In Verilog word concat (lo=byte0[7:0], hi=byte1[7:0]) → MAME pos N = word[(7-N%8) + (N>=8?8:0)].
rtl/SeibuCup/SeibuCup_text_renderer.sv:210 MAME GFXDECODE char: color base = 48*16 = 0x300 (16 colorset × 16 pen).
rtl/SeibuCup/SeibuCup_tile_layer.sv:25 Differenze fra layer (da MAME dcon.cpp):
rtl/SeibuCup/SeibuCup_tile_layer.sv:58 BB FG hardcoded +0x1000 (MAME bloodbro fg_tile_info)
rtl/SeibuCup/SeibuCup_tile_layer.sv:221 Tile index con eventuale gfx_bank (MG ha bit 12 = 13-bit totali, BG/FG = 12 bit) + TILE_CODE_OFS hardcoded (BB FG aggiunge 0x1000 secondo MAME bloodbro fg_tile_info).
rtl/SeibuCup/SeibuCup_video_timing.sv:35 Active area da MAME (sdgndmps_map): visarea 0..40*8-1, 2*8..30*8-1 quindi 320×224, V offset = 16 (top blank).
rtl/SeibuCup/SeibuCup_video_timing.sv:60 ── Pixel clock enable: 96 MHz / 14 = 6.857 MHz ───────────────────────── SeibuCup reale (legionna.cpp:1318 set_raw): pclk 14.318180/2 = 7.15909 MHz.
rtl/SeibuCup/SeibuCup_video_timing.sv:78 ── Constants timing ───────────────────────────────────────────────────── SeibuCup REALE (legionna.cpp:1318): set_raw(14318180/2, 455, 0, 320, 258, 0, 224) = 320x224, HTotal 455 @7.159MHz = 15.734 kHz, VTotal 258 → 60.985 Hz.
rtl/SeibuCup/SeibuCup_video_timing.sv:96 CUPSOC: 240 righe visibili (MAME visarea 8..247), 60 Hz.
rtl/SeibuCup/SeibuCup_video_timing.sv:103 Raster unico 262: 6.857e6/(436*262) = 60.03 Hz = i 60 Hz di MAME.
rtl/SeibuCup/sdram_bridge.sv:308 --- FG address descramble (legionna.cpp:1129 descramble_legionnaire_gfx) --- MAME applica un bitswap<24> agli indirizzi della ROM "fore" durante init: src_descrambled[i] = src_raw[bitswap<24>(i, ...
rtl/SeibuCup/sdram_bridge.sv:355 bitswap MAME del byte offset
README.md:6 Seibu Cup Soccer runs on the Seibu **`legionna.cpp` hardware family** — an M68000 board with a Seibu CRTC, the SEI252 sprite chip, and the **SEI300 / COP3 copro
README.md:8 It shares that board with Legionnaire, Heated Barrel, Denjin Makai, Godzilla and SD Gundam Sangokushi Rainbow, and it is the **only one of them that MAME still
README.md:13 This core reimplements the hardware in SystemVerilog from the program ROM, from MAME references (`legionna.cpp`, `legionna_v.cpp`, `seibu_crtc.cpp`, `seibucop.c
README.md:34 The COP: how a game MAME calls "unemulated protection" was solved
README.md:46 MAME marks Seibu Cup Soccer as unemulated protection, and the code that is there is partly guesswork — several of its comments turned out to be **wrong**, not m
README.md:51 **ROM > behaviour in game > MAME.**
README.md:54 MAME is a hint, and a good one, but never the last word.
README.md:60 MAME dispatches many of these commands by game name.
README.md:66 **Command `6200`** exists twice in MAME (`execute_6200` and `LEGACY_execute_6200`) with different registers and offsets.
README.md:76 **Who writes the resulting angle** is decided by the **length field** of the trigger, not by bit 7 as MAME has it: commands of length 8 write it, those of lengt
README.md:87 **A probe on the real thing.** A LUA tap on the COP window running under MAME showed which commands the game *actually* issues during a match.
README.md:94 That probe had itself been lying for a while: MAME's `install_read_tap` returns an object whose destructor removes the tap, so a script that does not keep the r
README.md:96 Every LUA measurement taken before that was found in the MAME source is untrustworthy — which explained a long run of inconsistent results.
README.md:124 And it answered a question MAME had given up on.
README.md:124 `seibucop.cpp` says *"atan maths are nowhere to be found from the roms"*.
README.md:133 — which also settled that the division **truncates** rather than rounding (MAME's comment says otherwise, and is right only 52% of the time), and that the ampli
README.md:138 Things MAME says that are not true
README.md:149 The correct version of command `3bb0` was already **in** MAME, but buried inside an `#ifdef UNUSED_COMMANDS` that is never defined.
README.md:236 The **sprite priority masks** are inherited from MAME, where two of the four values carry the authors' own question marks (`legionna_v.cpp` gives cupsoc `0xfff0

Says it matches, follows or was checked against MAME — 6

SeibuCup.sv:224 -1 = base famiglia (match MAME su HW)
rtl/SeibuCup/SeibuCup_cop3.sv:1514 LEGACY sprite-DMA (match a maschera, MAME find_trigger_match): c480 mask $FF00 -> qualunque c4xx; 6880 mask $FFF3.
rtl/SeibuCup/SeibuCup_cop3.sv:2628 res = prod >> 4 (= /16 per matchare formula MAME 2048/32768 = 1/16)
rtl/SeibuCup/SeibuCup_cop3.sv:3141 Verificato in gioco su MAME il 2026-07-29.
rtl/SeibuCup/SeibuCup_sprite_renderer.sv:172 +1 pixel a destra: offset verificato con pixel hunting su MAME (rmonic79).
rtl/SeibuCup/SeibuCup_sprite_renderer.sv:368 Scan INVERSO 511→0 (verificato su HW: ordine sprite-su-sprite opposto al loop MAME 0→511).

Says it was translated, ported or taken from MAME — 2

rtl/SeibuCup/SeibuCup_cop3.sv:2322 0x3BB0 dist — MAME execute_3b30 (cmd.ipp:197): 1:1 dx = (read_dword(r1+4) - read_dword(r0+4)) >> 16 (signed) dy = (read_dword(r1+8) - read_dword(r0+8)) >> 16 cop_dist = floor(sqrt(dx*dx + dy*dy)) if(data&0x80) write_word(r0+(data&0x200?0x3
rtl/SeibuCup/SeibuCup_cop3.sv:2442 0x42C2/0x4AA0 divide — MAME execute_42c2/4aa0 (cmd.ipp:219/247): 1:1 DIVIDEND = cop_dist << (5 - cop_scale) (cop_scale 0..3 → shift 5..2) 42c2: div=cop_read_word(r0+0x36)→host 0x34; if(!div){status|=0x8000; write 0 a host 0x3a} else write

Keeps a MAME approximation — 1

rtl/SeibuCup/SeibuCup_cop3.sv:223 MAME usa total_cycles%256 (surrogato dell'RNG hw ignoto): l'LFSR e' un surrogato equivalente ma robusto alle letture regolari.

Shares text with the MAME driver without saying so — 9

SeibuCup.sv:881 screen.set_visarea(0*8, 40*8-1, 1*8, 31*8-1) = [0..319] x [8..247] — shares text with seibu/legionna.cpp:1317
SeibuCup.sv:907 HAS_TRANSP=1 perché m_background_layer->set_transparent_pen(15) in — shares text with seibu/legionna_v.cpp:216
SeibuCup.sv:930 get_mid_tile_info_share_bgrom (legionna_v.cpp:158): MG share BG ROM, — shares text with seibu/legionna.h:80
rtl/SeibuCup/SeibuCup_palette.sv:23 Palette RAM Seibu SeibuCup (xBGR_555, 2048 entries). MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_555, 128*16); (legionna.cpp — shares text with seibu/legionna.cpp:1212
rtl/SeibuCup/SeibuCup_sprite_renderer.sv:147 if (BIT(~spriteram[i], 15)) continue; → draw quando w0[15]==1. — shares text with seibu/sei021x_sei0220_spr.cpp:128
rtl/SeibuCup/SeibuCup_text_renderer.sv:23 Text layer renderer Seibu SeibuCup (8x8, 4bpp, 64x32). Specifiche da MAME (legionna.cpp:1117-1126, 1167): // charlayout 8x8, RGN_FRAC(1,1), 4 — shares text with seibu/legionna.cpp
rtl/SeibuCup/SeibuCup_video_timing.sv:23 Video timing single-screen Seibu D-Con. SD Gundam Psycho Salamander gira su Seibu D-Con (PB91008), stessa famiglia di Blood Bros (1990). PCB measuremen — shares text with seibu/legionna.cpp
rtl/SeibuCup/SeibuCup_video_timing.sv:79 SeibuCup REALE (legionna.cpp:1318): set_raw(14318180/2, 455, 0, — shares text with seibu/legionna.cpp:1318
rtl/SeibuCup/sdram_bridge.sv:310 src_descrambled[i] = src_raw[bitswap<24>(i, ... 6,5,15,14,13,12, 11,10,9,8, 7,4, 3..0)] — shares text with seibu/legionna.cpp:1141

Shuuz#
Shuuz
MiSTer-devel/Arcade-Shuuz_MiSTer @ 4fb3ba9e
MAME compared: atari/shuuz.cpp + 4 related file(s)
Read: 36 HDL files, 4,230 lines (Quartus project)

MiSTer official

Both

low

43%

Statements: 24 toward hardware, 14 toward MAME, 9 not counted

Cites hardware documentation that MAME's driver does not — 24

rtl/io/shuuz_inputs.sv:4 Reads go through one 74LS257 (28A), selected by address line 1: 105000: bit 11 /VIDBL, bit 0 left coin, bit 1 right coin 105002: bit 11 self-test switch, bit 0 left button, bit 1 right button Its fourth section carries two JAMMA pins the Sh
rtl/io/shuuz_inputs.sv:11 Writes clock a 74LS174 (15A) from data lines 13-8 at the end of the write: 13 motor enable, 12 VCR power, 11 and 10 coin counters, 9 /AUDRES, 8 /PCMRES (0 holds the sound chip in reset).
rtl/main/shuuz_cpu.sv:1 SPDX-License-Identifier: GPL-3.0-or-later 68000 at 30C: fx68k with its two clock-phase enables.
rtl/main/shuuz_dtack.sv:1 SPDX-License-Identifier: GPL-3.0-or-later /DTACK: the 74LS163A wait counter at 50B.
rtl/main/shuuz_eeprom_28c16.sv:1 SPDX-License-Identifier: GPL-3.0-or-later 28C16 EEPROM at 38F (2K x 8) and the flop at 10B that locks it.
rtl/main/shuuz_eeprom_28c16.sv:137 ---- the unlock flop at 10B -------------------------------------------- /CLR = /SYSRES; /PRE (unlock) is a level and wins over its own /WL edge.
rtl/main/shuuz_main.sv:101 ---- address decode: the GAL at 55C and the 74LS138 at 55B ----
rtl/main/shuuz_nvram_io.sv:1 SPDX-License-Identifier: GPL-3.0-or-later MiSTer load and save of the 28C16 EEPROM at 38F.
rtl/main/shuuz_watchdog.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Power-on reset and watchdog: the 74LS197 counter at 30B.
rtl/shuuz_clocks.sv:6 The board divides the crystal with a free-running 74LS163 (62D): QB is 3.58 MHz, QC 1.79 MHz and QD 894.9 kHz, the clock of the MSM6295 and the LETA.
rtl/video/shuuz_cram.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Colour RAM at 3E0000 (the RAM at 54K; 1024 words are used): one copy read by the pixel scan and one by the processor, both written together.
rtl/video/shuuz_lb.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Motion object line buffers (LB 137536-001 at 85S and its RAM): two banks, one written by the MOB for the next line while the other is displayed and erased behind the beam.
rtl/video/shuuz_mob.sv:1 SPDX-License-Identifier: GPL-3.0-or-later MOB 137593-001 at 70S: for every line, read the first link from the SLIP table, walk the linked list of motion objects in video RAM and draw the stamp rows that cross the line into the line buffer.
rtl/video/shuuz_vad_regs.sv:1 SPDX-License-Identifier: GPL-3.0-or-later VAD 137656-001 at 50S (modelled as the -002 of the sister boards): the 32-word register file, the end-of-frame reload and the parameter-word decoder.
rtl/video/shuuz_vad_sync.sv:1 SPDX-License-Identifier: GPL-3.0-or-later VAD 137656-001 at 50S (modelled as the -002 of the sister boards): beam counters, sync, blanking and the scanline interrupt, programmed by registers 01-05.
rtl/video/shuuz_vram.sv:1 SPDX-License-Identifier: GPL-3.0-or-later The 64 KB video RAM block at 3F0000 (RAMs at 41N and 70N) and the VAD's access schedule.
README.md:9 It was built from the schematics in Atari's manual (TM-358) and the board's dumped GALs.
README.md:103 These parts follow the schematics and the GAL fuse maps:
README.md:106 **Address decode.** The GAL at 55C (136083-1050) and the 74LS138 at 55B, with the GAL's equations taken from its fuse map.
README.md:109 **Wait states.** The 74LS163A counter at 50B ends every bus cycle: no wait state for the program ROM, one for the EEPROM, two for the LETA and the MSM6295.
README.md:114 **Watchdog.** The 74LS197 at 30B holds the 68000 in reset for eight frames after power-on, and resets the board if the program stops writing to it for eight fra
README.md:117 **EEPROM.** The 28C16 with the flop at 10B that locks it.
README.md:174 | Audio filter | Response compared with the three stages computed from the schematic | Within 0.05 dB up to 4 kHz |
README.md:221 Comments in the RTL name board parts by their location on the PCB (for example "the 74LS163A at 50B") and signals by their schematic names, so they can be check

Cites hardware references or measurements that MAME's driver also gives — 9

rtl/gal/shuuz_gal_1050.sv:1 SPDX-License-Identifier: GPL-3.0-or-later GAL16V8 136083-1050 at 55C: main address decoder. — also in MAME: 136083-1050 atari/shuuz.cpp:466, 55C atari/shuuz.cpp:466
rtl/gal/shuuz_gal_1051.sv:1 SPDX-License-Identifier: GPL-3.0-or-later GAL16V8 136083-1051 at 45E. — also in MAME: 136083-1051 atari/shuuz.cpp:467, 45E atari/shuuz.cpp:467
rtl/gal/shuuz_gal_1053.sv:1 SPDX-License-Identifier: GPL-3.0-or-later GAL16V8 136083-1053 at 85N: motion object against playfield. — also in MAME: 136083-1053 atari/shuuz.cpp:469, 85N atari/shuuz.cpp:469
rtl/main/shuuz_main.sv:129 ---- the GAL at 45E: strobes for the video section, one clock late ---- — also in MAME: 45E atari/shuuz.cpp:467
rtl/mem/shuuz_prog_rom.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Program ROM, 256 KB (two 27C010 at 23P and 13P), held in block RAM so that every read takes the same time, as it does on the board. — also in MAME: 23P atari/shuuz.cpp:442, 13P atari/shuuz.cpp:443
rtl/shuuz_core.sv:183 Its sample ROMs 75B and 65B are one 256 KB block, 75B first. — also in MAME: 75B atari/shuuz.cpp:462, 65B atari/shuuz.cpp:463, 75B atari/shuuz.cpp:462
rtl/video/shuuz_mixer.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Colour RAM address from the playfield pixel and the line-buffer pixel, decided by the priority GAL at 85N (136083-1053). — also in MAME: 85N atari/shuuz.cpp:469, 136083-1053 atari/shuuz.cpp:469
README.md:119 **Video bus strobes.** The GAL at 45E (136083-1051) passes the bus strobes to the video section one clock late. — also in MAME: 45E atari/shuuz.cpp:467, 136083-1051 atari/shuuz.cpp:467
README.md:124 **Priority and shadows.** The GAL at 85N (136083-1053) decides whether a motion object pixel or the playfield shows. — also in MAME: 85N atari/shuuz.cpp:469, 136083-1053 atari/shuuz.cpp:469

Cites MAME source — 13

rtl/video/shuuz_mixer.sv:15 The wiring here follows the signal names MAME's source gives the equations.
rtl/video/shuuz_vad_sync.sv:9 Register fields (the layout MAME uses; the VAD sheet was never published): 01 vsync start (11-3), vsync end (2-0) 02 last line (15-9), vblank start (8-0) 03 scanline interrupt line (8-0) 04 hsync end / 2 (15-10), hsync start (9-0) 05 h
README.md:10 MAME 0.289 was used as a cross-check, and as the only source for the video chips, whose schematics were never published.
README.md:112 MAME has no wait states, so the game program runs slightly slower here, as on the board.
README.md:133 They cut off above about 900 Hz, so **the core sounds duller than MAME**, which plays the chip unfiltered.
README.md:139 What follows MAME instead
README.md:142 The VAD (timing, scroll registers, end-of-frame reload), the MOB (motion object list walk) and the line buffer therefore follow MAME's `atarivad` and `atarimo`
README.md:153 MAME draws whole frames and shows it on the next frame.
README.md:171 | Main bus | Boot of both program versions compared with MAME, bus access by bus access (polling loops merged) | The same 46,911 accesses in the same order, thr
README.md:172 | Video | 46 frames of each version (attract mode, a game, self-test) in which the program does not change the picture mid-frame, compared with MAME pixel by pi
README.md:173 | MSM6295 | Compared with MAME's own MSM6295 device, built from MAME's source and driven by the real sample ROMs | 17,811 samples equal |
README.md:175 | Whole core | Both versions run for 2,900 frames: attract mode, a coin, player selection and pitches with the trackball, then the game's own ROM and video RAM
README.md:244 **The MAME team**: `shuuz.cpp` (Aaron Giles), `atarivad`, `atarimo` and `okim6295`, the reference for everything the schematics do not settle.

Says it matches, follows or was checked against MAME — 1

rtl/video/shuuz_vad_regs.sv:8 The VAD sheet was never published; this follows MAME's atarivad and what the game program does.

SilverLand#
River Patrol
MiSTer-devel/Arcade-SilverLand_MiSTer @ 3ea85804
MAME compared: nichibutsu/cclimber.cpp
Read: 15 HDL files, 6,196 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

10%

Statements: 1 toward MAME

Cites MAME source — 1

rtl/ym_2149_linmix.vhd:44 Clues from MAME sound driver and Kazuhiro TSUJIKAWA

SkullXBones#
Skull & Crossbones
MiSTer-devel/Arcade-SkullXBones_MiSTer @ 73fdc240
MAME compared: atari/skullxbo.cpp + 8 related file(s)
Read: 34 HDL files, 7,927 lines (Quartus project)

MiSTer official

Both

high

82%

Statements: 93 toward hardware, 70 toward MAME, 3 not counted

Cites hardware documentation that MAME's driver does not — 86

rtl/main/skullxbo_addr_decode.sv:5 Schematic sheet 2: LS32 170E, LS139 140A (both halves), LS138 130A, LS139 170J, the LS00 120C MOBMSB latch and the gates that make /ROM, /SLAPSTIK and /VIDRAM; sheet 3: the LS139 220F program-ROM bank select.
rtl/main/skullxbo_addr_decode.sv:67 LS139 220F-1 (sheet 3; G = /ROM, A = A17, B = A18, unbuffered)
rtl/main/skullxbo_addr_decode.sv:136 ---- program ROM (sheet 3) ----
rtl/main/skullxbo_cpu.sv:3 Skull & Crossbones main CPU: fx68k (a cycle-exact 68000) wired as sheet 2 draws the 68000 at 245C.
rtl/main/skullxbo_cpu.sv:16 SOS-2 pin 12 (/7M) -> 110F F04 -> `7M` (PAL 110E, PFHS, SOS-1 195N) SOS-2 pin 13 ( 7M) -> 110F F04 -> `/7M` (68000 CLK, LS163A 230F)
rtl/main/skullxbo_cpu.sv:29 `ce_7m_cpu` is output because the LS163A 230F in skullxbo_dtack is clocked by the same /7M edge.
rtl/main/skullxbo_cpu.sv:32 Pins as sheet 2 wires them: CLK = /7M HALT, RESET = tied together to the /RESET net AS -> 200E LS14 -> `AS` (active high on the board) UDS, LDS -> 170E LS32 (/WH, /WL)
rtl/main/skullxbo_cpu.sv:76 the /7M rising tick, for skullxbo_dtack's LS163A 230F
rtl/main/skullxbo_dtack.sv:3 Skull & Crossbones /DTACK generation (schematic sheet 2): the LS163A wait counter at 230F, the LS11 90E clear gate, the LS74 130C-B /WAITHBL flop, the LS74 110C-B VCYCDONE flop and the LS27 210F that combines the three DTACK sources.
rtl/main/skullxbo_dtack.sv:14 The parts, as sheet 2 wires them: LS11 90E : /VIDRAM, /WAITHBL, AS -> 230F /CLR LS163A 230F : CK = /7M ; ENP = /DTACK ; ENT = /VPA ; /LOAD = QD ; D,C,B,A = 1, 1, /EEROM, 1 ; RCO -> LS27 210F LS08 200F : /VPA & VCYCDONE -> LS27 210F LS7
rtl/main/skullxbo_dtack.sv:69 /CLR dominates the clock on a 74LS74.
rtl/main/skullxbo_dtack.sv:94 ---------------- LS163A 230F -----------------------------------------
rtl/main/skullxbo_dtack.sv:101 LS11 90E pin 6 -> /CLR (SYNCHRONOUS on an LS163A)
rtl/main/skullxbo_eeprom_28c16.sv:3 28C16-45 (2 K x 8) EEPROM at 170A, plus the LS74 30H-A unlock flop and the LS08 60E gate that drives its /OE.
rtl/main/skullxbo_eeprom_28c16.sv:4 Schematic sheet 3.
rtl/main/skullxbo_eeprom_28c16.sv:12 Wiring: A10..A0 = BA11..BA1 D7..D0 = BD7:0 (the odd / low byte lane) /CE = /EEROM (0xFF6000-0xFF7FFF) /OE = LS08 60E /WE = /WL (every low-lane 68000 write)
rtl/main/skullxbo_eeprom_28c16.sv:22 Unlock / lock: LS74 30H-A : D = GND, CK = /WL (rising = end of any low-lane write), /PRE = /UNLOCK (a write to FF0C00), /CLR = /RESET LS08 60E : /OE = Q AND /RESET
rtl/main/skullxbo_eeprom_28c16.sv:74 LS08 60E pin 11 -> 170A pin 20
rtl/main/skullxbo_eeprom_28c16.sv:135 LS08 60E: /OE = Q AND /RESET.
rtl/main/skullxbo_eeprom_28c16.sv:144 ---- LS74 30H-A ------------------------------------------------------ /CLR = /RESET is asynchronous on the part; /UNLOCK (/PRE) is level sensitive and beats the /WL edge of its own cycle.
rtl/main/skullxbo_inputs.sv:3 Skull & Crossbones controls and status port: the two LS257 muxes 80B/100C (sheet 3) and the F244 150C status nibble (sheet 4).
rtl/main/skullxbo_inputs.sv:72 LS257 80B/100C -> BD15:8, ACTIVE LOW
rtl/main/skullxbo_irq.sv:3 Skull & Crossbones interrupts (schematic sheet 2): the LS11 90E band decoder, the LS10 90C gates, the LS74 130C-A scanline latch, the LS74 110C-A VBLANK latch and the LS00 120C / LS10 90C IPL encoder.
rtl/main/skullxbo_irq.sv:14 LS11 90E : /1V & 2V & 4V (high when V mod 8 == 6)
rtl/main/skullxbo_irq.sv:15 LS10 90C : NAND(90E, ANIRQ, /VBLANK) -> 130C-A D
rtl/main/skullxbo_irq.sv:16 LS74 130C-A : CK = HBLANK (board net), /PRE = /IRQACK, /Q = IRQ1 pending LS74 110C-A : D = GND, CK = VBLANK (SOS-2 pin), /PRE = /VBLACK, /Q = IRQ2 pending /IPL2 = SCOM 120E FULL, direct /IPL1 = NAND(/IPL2, IRQ2 pending) (
rtl/main/skullxbo_irq.sv:59 /1V -- LS11 90E pin 11
rtl/main/skullxbo_irq.sv:82 ---------------- LS11 90E + LS10 90C (the D input) -------------------
rtl/main/skullxbo_irq.sv:84 LS10 90C pin 6 (a 3-input NAND)
rtl/main/skullxbo_irq.sv:112 ---------------- LS00 120C + LS10 90C : the IPL encoder --------------
rtl/main/skullxbo_irq.sv:115 LS10 90C pin 12
rtl/main/skullxbo_main.sv:80 LS191 1VS..256VS
rtl/main/skullxbo_main.sv:135 BA11:1 (PAL 10F inverts BA11 into the
rtl/main/skullxbo_main.sv:138 BD15:0 (LS245 50B/50C are a WORD port)
rtl/main/skullxbo_main.sv:140 LS74 70C-B Q -- the one-pixel steal
rtl/main/skullxbo_main.sv:149 LS125 50H pin 3 = /4H, the link bit clock
rtl/main/skullxbo_main.sv:371 the LS163A wait sequencer, VCYCDONE and the /WAITHBL stall
rtl/main/skullxbo_main.sv:568 LS74 70C-A (an S-R latch, clock tied off) : /PRE = AS , /CLR = /CRAMD F32 60C pin 11 = OR( 70C-A /Q , /CRAM ) LS74 70C-B : D = 60C pin 11 , CP = /14MA , /PRE = AS , Q = /CRAMD => /CRAMD is a ONE-14MA-cycle low pulse, once per CPU colour-RAM
rtl/main/skullxbo_main.sv:572 Then, on sheet 9, F398 40J delays it one 14MB into /CRAMOO, and /CRWR = OR( OR(/CRAMOO, /W) , /14MA ) -- a half-cycle write pulse VIDCLK = OR( CRAMOO , /14MA ) -- HELD HIGH for that cycle The CPU steals exactly one pixel:
rtl/main/skullxbo_main.sv:601 LS245 50B/50C: a 16-bit WORD port
rtl/main/skullxbo_main.sv:633 LS125 50H pin 3 = /4H
rtl/main/skullxbo_main.sv:642 LS245 50B/50C, a WORD
rtl/main/skullxbo_watchdog.sv:3 Skull & Crossbones power-on reset and watchdog (schematic sheet 1): the Q1 / R62 / C55 power-on node into 200E LS14, the LS90 70F divider, the LS00 10D reset gate with jumper JP1, and Q3 driving the /RESET net.
rtl/main/skullxbo_watchdog.sv:23 LS90 70F, a BCD divide-by-ten: CKA = /VBLANK, QA -> CKB R0 (reset to 0) = LS00 10D output = NAND(/WDOG, JP1 node) R9 (set to 9) = the POR node, wins over R0 QD -> Q3 -> /RESET JP1 open (as shipped): a /WDOG write resets the count.
rtl/main/skullxbo_watchdog.sv:82 ---------------- LS00 10D + JP1 -------------------------------------- R0 = NAND( /WDOG , JP1node ) with JP1node = ~jp1
rtl/main/skullxbo_watchdog.sv:87 ---------------- LS90 70F -------------------------------------------- R9 (set to nine) dominates R0 on a 74LS90; both are LEVEL sensitive and asynchronous.
rtl/mem/skullxbo_prog_rom.sv:3 Skull & Crossbones 68000 program ROM: the eight 27512 sockets of sheet 3, served from SDRAM through a small direct-mapped cache with 4-word lines and a next-line prefetch.
rtl/mem/skullxbo_vram.sv:3 Skull & Crossbones video RAM: the two 16-bit memories (208H/235H and 221H/250H), the seven F253/LS253 address multiplexers, the F174 address latches, PAL16R8 110E (136072-2143, implemented directly from its fuse dump), the byte-lane write p
rtl/mem/skullxbo_vram.sv:135 LS191 1VS..256VS; only VS[8:3] are wired
rtl/mem/skullxbo_vram.sv:197 PAL16R8 110E (136072-2143): the eight registered equations
rtl/mem/skullxbo_vram.sv:199 From the 136072-2143 fuse dump, decoded with MAME's jedutil.
rtl/mem/skullxbo_vram.sv:436 A 74LS373 is TRANSPARENT while G is high and freezes on its falling edge, so the CPU gets a stable word after its single slot even though VD immediately reverts to the video fetches.
rtl/skullxbo_core.sv:220 ---- debug nets -------------------------------------------------------- `main_reset_n` is the LS90 70F /RESET net; `main_slip_n` / `main_slipup` / `main_pal_e` are PAL 110E's registered outputs; `main_cramd_n` / `main_cramoo_n` are the one
rtl/video/skullxbo_alpha.sv:3 Skull & Crossbones alphanumerics (schematic sheet 5): LS374 190K/220K, the 27256 character ROM at 250K, LS194A 230K/230L and LS174 190F (ANPAL3:0, ANBO, ANIRQ).
rtl/video/skullxbo_alpha.sv:26 Pipeline (why a cell is displayed one group late): mux slot (8k+3, b) -> the alpha word LS374 190K/220K clocked by 4HD14M, rising into (8k+4, b) LS194A S1 = NOR(1H,2H): parallel load once every four counts, shift th
rtl/video/skullxbo_alpha.sv:40 The LS194A clock 7MD/14M rises a quarter count after the count boundary; the pens are modelled on the boundary, which is the same thing at the resolution of the doubled alpha pixels.
rtl/video/skullxbo_alpha.sv:118 LS194A 230K / 230L
rtl/video/skullxbo_cram.sv:3 Skull & Crossbones colour RAM 40E / 50E, the /CRAMD pixel steal and the HC273 40B/40C output registers (schematic sheet 10).
rtl/video/skullxbo_cram.sv:9 The RAM: two 137534-001 2 K x 8 parts = 2048 x 16 at FF2000-FF2FFE, a 16-bit word port for the CPU (LS245 50B/50C), /CS = /OE = GND, /WE = /CRWR.
rtl/video/skullxbo_cram.sv:11 The video side addresses it with CRAMA10:1 from the F153 muxes plus PAL 10F pin 14 as A10.
rtl/video/skullxbo_cram.sv:17 The pixel steal: LS74 70C makes /CRAMD a one-14MA-cycle low pulse per CPU colour-RAM access; F398 40J delays it one 14MB into /CRAMOO; and VIDCLK = OR(CRAMOO, /14MA) is held high for that cycle, freezing the HC273 outputs.
rtl/video/skullxbo_cram.sv:58 /CRAMD, back into PAL 10F pin 1
rtl/video/skullxbo_dac.sv:3 Skull & Crossbones: the R-2R DACs RN1/RN2/RN3 and the analogue stage (schematic sheet 10), reduced to 8 bits per channel for MiSTer.
rtl/video/skullxbo_hstrobes.sv:3 Skull & Crossbones on-board horizontal strobes (schematic 046903-01 sheet 1: LS74 80E / 80F / 80C, LS02 70E, LS27 210F, LS08 200F, LS11 90E, LS10 90C, LS04 100E/40K, F174 160H).
rtl/video/skullxbo_hstrobes.sv:16 The HBLANK chain: LS74 80E-A : D = HBLANK(sos2), /CLR = HBLANK(sos2), CK = 16H Q = HBDLY LS02 70E-4 : NOR(/1H2H, /4H) = 1H & 2H & 4H (h == 7) LS74 80F-A : D = 1, /CLR = HBDLY, CK = (h == 7) LS74 80F-B : D = 80F-A Q, CK = /4HD/14M,
rtl/video/skullxbo_hstrobes.sv:84 7MD/14M rising: LS194A 230K/230L clock
rtl/video/skullxbo_lb.sv:3 Skull & Crossbones motion-object line buffers (schematic sheet 9: 80J/70J and 80K/70K, the F163 counters 90J/100J/110J and 90K/100K/110K, the LS244/LS125 write drivers, F398 50J/40J + F174 60J).
rtl/video/skullxbo_mo_fetch.sv:3 Skull & Crossbones motion-object stamp fetch and pixel shifters (schematic sheets 6-8: the five-plane 27512 banks, the LS373 60N/70N/50N/80N 32-bit row latch, the LS157 110M/100M plane-4 flip, and SOS-1 20N and 25L).
rtl/video/skullxbo_mo_fetch.sv:74 The transparent pen is 0 (MAME transpen 0, and PAL 10F's (LBPIX == 0) test), so this model carries the true pen and the line buffer suppresses pen 0.
rtl/video/skullxbo_mob.sv:3 Skull & Crossbones: the Atari MOB (137593-001) motion-object engine at 130K, schematic sheet 6.
rtl/video/skullxbo_pfhs.sv:3 Skull & Crossbones: the Atari PFHS (137419-104) at 195M, schematic sheet 5.
rtl/video/skullxbo_prio.sv:3 Skull & Crossbones: PAL16L8 10F (136072-1142, "PRI") and the F153 colour-RAM address multiplexers 10E / 20D / 30D / 30E / 20E (sheet 10).
rtl/video/skullxbo_prio.sv:9 The PAL equations are the 136072-1142 fuse dump, decoded with MAME's `jedutil -view <jed> GAL16V8`:
rtl/video/skullxbo_sos1.sv:3 One parameterised model, used three times: 195N (playfield, sheet 5), 20N (motion-object planes 3..0, sheet 8) and 25L (plane 4, sheet 8).
rtl/video/skullxbo_sos2_sync.sv:3 Skull & Crossbones SOS-2 sync generator (Atari custom 137550-001 at 95F, schematic 046903-01 sheet 1).
rtl/video/skullxbo_sos2_sync.sv:13 The board re-times the SOS-2's HBLANK and /HSYNC (LS74 80E / 80F / 80C) and gates RSTLB and LINKRES before anything uses them; those board nets are made in skullxbo_hstrobes.sv.
rtl/video/skullxbo_video.sv:13 Video-RAM port: video -> memory (address sources into the F253/LS253 muxes, sheet 4)
rtl/video/skullxbo_video.sv:412 The pen buses are combined by PAL 10F and the F153 muxes combinationally, registered by F174 50F/40F and again by the HC273s — two 14M stages.
rtl/video/skullxbo_vscroll.sv:3 Skull & Crossbones playfield vertical-scroll counters (LS191 150H / 130H / 140H, schematic sheet 6; the /LOAD term from 170H F02, 60H LS32 and 70H F27).
rtl/video/skullxbo_vscroll.sv:42 1 = 140H /CTEN is the VBLANK net (sheet 6, pin 4), so the chain holds through vertical blanking.
README.md:128 | Video RAM | two 16-bit RAMs (playfield; alphanumerics + sprites + work RAM), CPU access arbitrated by **PAL16R8 110E** (`136072-2143`), implemented from its f
README.md:133 | Priority | **PAL16L8 10F** (`136072-1142`), implemented from its fuse dump |
README.md:135 | Sound board | **JSA Audio II**: 6502 (T65) at 1.79 MHz, banked program ROM, **PAL16L8 2D** (`136056-2101`) from its fuse dump, periodic-interrupt divider |
README.md:165 All three programmable chips on the two boards — the video-RAM arbiter `136072-2143`, the priority PAL `136072-1142` and the sound address decoder `136056-2101`
README.md:340 Every equation, strobe, timing slot and raster position in this core was taken from the A046903-01 / A047184-02 schematics and the three PAL dumps; `NOTICE.md`
README.md:345 Thanks to the MAME team, whose `skullxbo.cpp`, `atarimo.cpp` and JSA sources served as the functional reference throughout, and to whoever preserved the Atari m

Cites hardware references or measurements that MAME's driver also gives — 3

rtl/main/skullxbo_dtack.sv:9 Structure ported from `Arcade-Badlands_MiSTer/rtl/main/badlands_dtack.sv` (GPL-3.0, same author, a 28R LS163A doing the same job); the loads, the three-way DTACK and both flops are this board's. — also in MAME: 28R atari/skullxbo.cpp:665
rtl/main/skullxbo_main.sv:156 `jsa:cpu` -> the 6502 ROM at 1B — also in MAME: 1B atari/skullxbo.cpp:661
rtl/mem/skullxbo_rom_loader.sv:18 0x2B8000 0x010000 jsa:cpu block RAM: the 6502 ROM at 1B — also in MAME: 1B atari/skullxbo.cpp:661

Reports a measurement taken on the original PCB — 1

README.md:236 A measurement on a real board, or a dump of the SOS-2, would settle it.

Says it was checked on “real hardware” — 2

Arcade-SkullXBones.sv:169 The read-capture phase can only be checked on hardware; see the README.
rtl/video/skullxbo_sos2_sync.sv:47 The start is placed by the program's scanline-interrupt timing and confirmed on hardware (the HUD lands on the right line); skullxbo_hstrobes explains why the end cannot be at the wrap.

Notes where it differs from MAME — 4

rtl/main/skullxbo_dtack.sv:28 EEPROM (FF6000) 13 2 (MAME does not model them)
rtl/main/skullxbo_main.sv:577 MAME does not model this.
rtl/video/skullxbo_cram.sv:20 MAME does not model this.
README.md:12 Where a schematic and MAME disagree, the schematic wins.

Cites MAME source — 64

Arcade-SkullXBones.sv:15 Skull & Crossbones runs on a horizontal monitor (MAME ROT0): no rotation.
Arcade-SkullXBones.sv:202 Pad n's coin goes to D(n-1): D0 is MAME's COIN1 and D1 its COIN2, the two the default "separate mechs" setting credits.
Arcade-SkullXBones.sv:203 (D3, which MAME marks unused, is debounced by the game but never gives a credit.)
Arcade-SkullXBones.sv:205 D0 J1-36 MAME COIN1
Arcade-SkullXBones.sv:206 D1 J1-35 MAME COIN2
Arcade-SkullXBones.sv:207 D2 J1-31 MAME COIN3
Arcade-SkullXBones.sv:208 D3 J1-33 MAME unused
rtl/main/skullxbo_addr_decode.sv:79 It selects which half of the motion-object list the MOB reads (MAME's `(offset >> 9) & 1`).
rtl/main/skullxbo_inputs.sv:24 AUX #1 and AUX #2 are marked "development only" in the manual (MAME calls them unused); they are wired here as on the board.
rtl/main/skullxbo_inputs.sv:36 The enable has no BA1 term, so the nibble appears on every /INPUTS read, at FF5800 as well as FF5802 (MAME shows it only at FF5802).
rtl/main/skullxbo_main.sv:35 MAME returns 0x0000 instead.
rtl/main/skullxbo_main.sv:47 What a floating data bus reads: 0xFFFF as on the board (MAME uses 0x0000).
rtl/mem/skullxbo_rom_loader.sv:13 stream base size MAME region destination
rtl/mem/skullxbo_rom_loader.sv:25 In MAME's region order the bytes of one hardware graphics fetch are 0x50000 apart (2 playfield columns, or 5 motion-object planes), so each byte would need its own SDRAM row activate, which is too slow.
rtl/mem/skullxbo_rom_loader.sv:64 The playfield bytes are stored raw: MAME inverts that region after loading, but on the board the inversion happens in the SOS-1 shifter, and this core does the same.
rtl/mem/skullxbo_vram.sv:104 This is MAME's `playfield_latched_w`, except that only the low byte of the 0xFFA000 word is rewritten (harmless: only D3:0 is used) and there is no "latch disabled" state; 140E always holds a value.
rtl/mem/skullxbo_vram.sv:199 From the 136072-2143 fuse dump, decoded with MAME's jedutil.
rtl/skullxbo_core.sv:81 UNDRIVEN_DATA what a floating data bus reads: 0xFFFF (no pull-ups); MAME's convention is 0x0000 POR_US the power-on reset length, 35-40 ms on the board
rtl/skullxbo_core.sv:306 MAME marks them unused; they are wired here as on the board.
rtl/video/skullxbo_alpha.sv:12 D14:11 = ANPAL3:0 D10:0 = the character code, with bit 10 inverted on its way to the ROM (200E LS14): MAME's `code = (data ^ 0x400)`
rtl/video/skullxbo_cram.sv:12 The physical A10 is the complement of MAME's, but the CPU side is inverted by the same PAL output, so this module simply stores the software-visible map (bit for bit MAME's FF2000 image); skullxbo_prio outputs that A10 as `shadow`.
rtl/video/skullxbo_dac.sv:11 D14..D10 = R5..R1 D9 ..D5 = G5..G1 D4 ..D0 = B5..B1 i.e. MAME's IRGB_1555.
rtl/video/skullxbo_lb.sv:24 Hence bank 0 is written while 1V = 1 and read while 1V = 0, and vice versa: the bank written during line L is read during line L+1, and the MOB builds line N+1 during line N. (MAME has no line buffers; this one-line delay is real hardware
rtl/video/skullxbo_lb.sv:35 MAME clears its motion-object bitmap every frame, which matches the first reading, so `LB_ERASE = 1` (the default) starts every write pass from an empty buffer.
rtl/video/skullxbo_mo_fetch.sv:14 byte in device = code[11:0]*16 + row*2 + MOHALF full stamp index = MOROMA[17:3] (MAME's 0x7fff mask)
rtl/video/skullxbo_mo_fetch.sv:34 MODp7 is the leftmost pixel of a byte (MAME molayout x offset 0), and plane 4 is the most significant pen bit.
rtl/video/skullxbo_mo_fetch.sv:44 MAME instead takes `code % 20480`, mirroring banks 0-4 into bank 5.
rtl/video/skullxbo_mo_fetch.sv:64 Under MHFLIP the three mechanisms together output the sixteen pens in the order 15, 14, ..., 0: MAME's mirrored tile.
rtl/video/skullxbo_mo_fetch.sv:74 The transparent pen is 0 (MAME transpen 0, and PAL 10F's (LBPIX == 0) test), so this model carries the true pen and the line buffer suppresses pen 0.
rtl/video/skullxbo_mob.sv:7 MAME's atarimo.cpp is the functional reference for the list semantics.
rtl/video/skullxbo_mob.sv:28 The list (MAME s_mob_config): entry at 0xFFD000 + 0x800*MOBMSB + 8*link : word 0 : D7:0 = the next link (D15:8 unused) word 1 : D14:0 = stamp code , D15 = H-flip word 2 : D3:0 = colour , D5:4 = priority , D15:6 = X word 3 : D15:7
rtl/video/skullxbo_mob.sv:35 Geometry (from atarimo.cpp::render_object).
rtl/video/skullxbo_mob.sv:35 MAME computes ypos = (-Y - yscroll - 8*height) & 0x1ff and draws tile row ty at sy = ypos + 8*ty.
rtl/video/skullxbo_mob.sv:45 (The mask cannot alias: MAME's ypos is within [-272, 240) and y within [0, 240).)
rtl/video/skullxbo_mob.sv:48 Horizontally MAME uses xpos = X - xscroll and, for H-flip, starts at xpos + (width-1)*16 with a negative step, so the tile at xpos + 16*k is width-1-k. The F163 line-buffer counters only count up, so the hardware walks k upward:
rtl/video/skullxbo_mob.sv:66 (MAME's maxperline = 0 has no limit.) * The walk ends when a link repeats (MAME's `visited[]`, `MOB_END_VISITED`).
rtl/video/skullxbo_mob.sv:79 The inferred choices and their defaults: `MOB_CODE_CARRY` 1: the per-tile stamp index is a full 15-bit add that carries into the bank bits MOROMA[17:15], as in MAME's flat code.
rtl/video/skullxbo_mob.sv:91 MOTL = 1 reproduces MAME's shadow rule and MOMISC = 0 MAME's "alpha always wins".
rtl/video/skullxbo_mob.sv:114 0 gives the literal "match against VS" reading, which puts the whole motion-object layer one scanline low against MAME.
rtl/video/skullxbo_mob.sv:133 1 = that one walk matches against the MOB's own 0xD register (the frame's vertical scroll, written by /MOBWR during VBLANK), which is the line MAME draws there.
rtl/video/skullxbo_mob.sv:380 MAME's loop is `while (!visited[link])` with `visited[link] = 1` before it follows the link, so an entry that links to itself is processed once.
rtl/video/skullxbo_pf.sv:45 The MRA stores the raw ROM bytes, so MAME's ROMREGION_INVERT must not be applied as well.
rtl/video/skullxbo_pfhs.sv:11 a nine-bit scroll register, D8:0 = BD15:7, latched on HS = /HSCRL (nine bits, which is what MAME's `2 * (xscroll >> 7)` needs); 2.
rtl/video/skullxbo_pfhs.sv:19 MAME: screen dot x shows playfield dot x + 2*scroll; in playfield pixels (one H count each) screen count m shows pixel m + scroll, i.e. column (m + scroll) >> 3 and pixel (m + scroll) & 7.
rtl/video/skullxbo_prio.sv:9 The PAL equations are the 136072-1142 fuse dump, decoded with MAME's `jedutil -view <jed> GAL16V8`:
rtl/video/skullxbo_prio.sv:43 Where MAME's comment and renderer differ from the fuses: * MAME's (LBPIX == 1) is really LBTL AND (LBPIX == 1), so MOTL is a per-object enable for the shadow effect; * LBMISC is in MAME's comment but not its renderer: the PAL lets LBMISC pu
rtl/video/skullxbo_prio.sv:50 Colour-RAM A10: pin 14 is inverting, so the physical A10 is the complement of MAME's. The CPU side goes through the same output, so software index n and video index n both land on physical row n XOR 0x400, and the palette map software sees
rtl/video/skullxbo_prio.sv:82 = NOT a10_pin = MAME's CRAM.A10
rtl/video/skullxbo_sos1.sv:28 This is inferred (the part is undumped) and agrees with three independent facts: the playfield ROMs are stored complemented (MAME's ROMREGION_INVERT) and PFPAL3:0 come off an LS175's /Q pins; 20N needs no inverter; and 25L's empty plane-4 b
rtl/video/skullxbo_sos2_sync.sv:70 MAME: 240 visible lines
rtl/video/skullxbo_vscroll.sv:20 This is MAME's "scanline 0 should re-latch the previous raw scroll": a hardware read of alpha RAM.
rtl/video/skullxbo_vscroll.sv:25 A core that decodes MAME's per-band command words would reload the scroll from ordinary character codes in alpha row 30 during gameplay.
rtl/video/skullxbo_vscroll.sv:30 MAME's `(yscroll >> 7) - scanline` with a tilemap that adds the scroll is the same number.
rtl/video/skullxbo_vscroll.sv:37 Net effect: VS over the visible part of line y is yscroll_raw + y, bit for bit MAME's tilemap row.
README.md:11 MAME was used as a functional reference where the drawings are silent.
README.md:42 | ROMs | Supplied by you from a MAME archive; none are included here |
README.md:89 Pad 1 is MAME's *Coin 1* and pad 2 its *Coin 2*, the pair the default "separate mechs" coin setting credits; pads 3 and 4 drive the other two inputs.
README.md:171 **Main CPU** — the 68000 bus is compared against MAME: **74,058 consecutive bus cycles agree** (address, read/write, data, size) through reset, the ROM checksum
README.md:175 **Video** — MAME was instrumented to capture the complete video state (playfield, alphanumerics, sprite and colour RAM) at chosen frames; those states are playe
README.md:186 **Sound** — the sound board is compared against MAME the same way: the command and response traffic between the boards, and the YM2151 and MSM6295 register writ
README.md:242 With that value the board's blanking signal clears the output on the same clock edge that would show screen x = 671, and the core treats that column as blanked;
README.md:250 And the motion-object list is read one line ahead of the line it fills, which is the whole 576-dot difference from MAME on the MOTION OBJECT TEST screen (displa
README.md:258 The core follows MAME's order (pad 1 = Coin 1), which credits correctly.
README.md:345 Thanks to the MAME team, whose `skullxbo.cpp`, `atarimo.cpp` and JSA sources served as the functional reference throughout, and to whoever preserved the Atari m

Says it matches, follows or was checked against MAME — 4

rtl/video/skullxbo_prio.sv:39 Pins 5, 16 and 18 are wired on the board but used by no equation; the equations match MAME's independently obtained comment, so the dump is taken as complete.
rtl/video/skullxbo_sos1.sv:43 The part only guarantees that the two are equal; 0 (the load edge presents group 0) is what matches MAME's frames.
README.md:193 Every program word lands correctly in SDRAM, the boot trace and the first sound round trip match MAME, and eight attract frames come out pixel-exact with all gr
README.md:236 The core uses **262 lines / 59.92 Hz**, the same as MAME.

Shares text with the MAME driver without saying so — 2

rtl/video/skullxbo_sos2_sync.sv:23 ph: 0 1 2 3 4 5 6 7 — shares text with atari/skullxbo.cpp:581
rtl/video/skullxbo_vscroll.sv:21 re-latch the previous raw scroll": a hardware read of alpha RAM. — shares text with atari/skullxbo.cpp:275

SkySmasher#
Sky Smasher
MiSTer-devel/Arcade_SkySmasher_MiSTer @ 30caa1a2
MAME compared: seibu/bloodbro.cpp + 4 related file(s)
Read: 20 HDL files, 5,953 lines (Quartus project)

MiSTer official

Mostly MAME

low

59%

Statements: 2 toward hardware, 46 toward MAME, 1 not counted

Cites hardware documentation that MAME's driver does not — 2

rtl/SkySmasher/SkySmasher_main_top.sv:31 Memory map SD Gundam (da MAME dcon.cpp + SD Gundam override): $000000-$07FFFF ROM 68K (512KB) $080000-$08BFFF Main RAM (48KB) $08C000-$08C7FF BG tile RAM (2KB) $08C800-$08CFFF FG tile RAM (2KB) $08D000-$08D7FF MG tile RAM
rtl/SkySmasher/SkySmasher_maincpu_map.sv:29 Memory map SD Gundam (da MAME dcon.cpp + sdgndmps_map override): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $080000-$08BFFF Main RAM (48KB) → BRAM $08C000-$08C7FF BG tile RAM → BRAM dual-port $08C800-$

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/SkySmasher/SkySmasher_video_timing.sv:26 PCB measurement Blood Bros: VSync 59.4094 Hz, HSync 15.6246 kHz, master XTAL 20 MHz. — also in MAME: 59.4094 seibu/bloodbro.cpp:970, 15.6246 seibu/bloodbro.cpp:971

Cites MAME source — 42

SkySmasher.sv:222 I valori di calibrazione pixel-perfect MAME sono hardcodati nelle cablature (sotto) / dentro i renderer: - BG X+0 Y+16 : .yoff(10'sd16) - MG X+0 Y+0 : .yoff(10'sd0) - FG X+0 Y+16 : .yoff(10'sd16) - SPR X+0 Y-16 : sprite renderer
SkySmasher.sv:302 --- Joystick to SD Gundam input mapping --- MAME P1_P2 port ($E0002): active low.
SkySmasher.sv:305 MiSTer joy bits: joy[0]=R, joy[1]=L, joy[2]=D, joy[3]=U, joy[4]=A, joy[5]=B. MAME bloodbro IN0: bit0..3 = U/D/L/R, bit4=Btn1 Fire, bit5=Btn2 Roll, bit6=Btn3 Dynamite (active low)
SkySmasher.sv:610 ── Flip screen (CRTC reg 0x1A bit 0) ─────────────────────────────────────── MAME: BIT(reg_1a, 0) → flip_screen.
SkySmasher.sv:652 Blood Bros Text: no scroll (MAME bloodbro.cpp non chiama set_scroll su tx_tilemap)
SkySmasher.sv:686 Blood Bros CRTC scroll passthrough — nessun offset (MAME bloodbro.cpp:427-430) Blood Bros usa scroll_ram[0/1] per BG e scroll_ram[2/3] per FG (MAME bloodbro.cpp:427-430).
SkySmasher.sv:709 Blood Bros: tilemap 32x16 (MAME bloodbro.cpp:292)
SkySmasher.sv:744 Blood Bros FG: palette base 0x500 (MAME bloodbro.cpp:808 = 0x50*16) MAME bloodbro fg_tile_info: tile = (vram & 0xFFF) + 0x1000 hardcoded.
SkySmasher.sv:751 Blood Bros: tilemap 32x16 (MAME bloodbro.cpp:293)
SkySmasher.sv:756 Blood Bros: bit 1 = FG (MAME bloodbro.cpp layer_en_w)
SkySmasher.sv:803 MAME bloodbro.cpp:379-382 pri_cb: pri=0 → mask 0 (above all), pri=1 → mask 0x02.
SkySmasher.sv:804 MAME draw order (riga 434-441): BG → FG → sprites → Text.
rtl/SkySmasher/SkySmasher_audio_z80.sv:25 Spec da MAME (reference/mame_seibu/seibusound.cpp + bloodbro.cpp): - Z80 @ 3.579545 MHz (XTAL 7.159090 / 2) - YM3812 (jtopl2) @ 3.579545 MHz - OKI M6295 (jt6295) @ 1.000 MHz (XTAL 12/12), PIN7=HIGH
rtl/SkySmasher/SkySmasher_audio_z80.sv:31 Main↔sub comm @ 0xA0000-0xA000D: standard MAME seibu_sound_device.
rtl/SkySmasher/SkySmasher_audio_z80.sv:315 ─── OKI M6295 (jt6295) — PIN7_HIGH (bloodbro.cpp:872) ──────────────────
rtl/SkySmasher/SkySmasher_main_top.sv:31 Memory map SD Gundam (da MAME dcon.cpp + SD Gundam override): $000000-$07FFFF ROM 68K (512KB) $080000-$08BFFF Main RAM (48KB) $08C000-$08C7FF BG tile RAM (2KB) $08C800-$08CFFF FG tile RAM (2KB) $08D000-$08D7FF MG tile RAM
rtl/SkySmasher/SkySmasher_main_top.sv:198 VBLANK IRQ2 — Sky Smasher: MAME bloodbro.cpp set_vblank_int(irq2_line_hold) Rising edge di vblank → assert IRQ2 pending; IACK CPU → clear.
rtl/SkySmasher/SkySmasher_main_top.sv:342 XOR 0x400 lato CPU per allineare BRAM[N] = MAME text_vram[N] (renderer parte da addr 0).
rtl/SkySmasher/SkySmasher_main_top.sv:350 Quindi MAME palette[N] sta in vram_addr = (N + 0x400) & 0x7FF.
rtl/SkySmasher/SkySmasher_main_top.sv:351 Per allineare BRAM[N] = MAME palette[N] applichiamo XOR 0x400 SOLO al lato CPU (a_addr).
rtl/SkySmasher/SkySmasher_main_top.sv:352 Il renderer passa pen_index MAME nativo (BG=0x400+, MG=0x500+, ecc) e la BRAM è già allineata.
rtl/SkySmasher/SkySmasher_main_top.sv:362 Sprite RAM CPU-side (write/read) — Blood Bros: 4KB = 2048 word (AW=11) MAME bloodbro.cpp:467 map(0x08b000, 0x08bfff).ram().share(m_spriteram) → 4KB.
rtl/SkySmasher/SkySmasher_maincpu_map.sv:29 Memory map SD Gundam (da MAME dcon.cpp + sdgndmps_map override): $000000-$07FFFF ROM 68K (512KB) → SDRAM via bridge $080000-$08BFFF Main RAM (48KB) → BRAM $08C000-$08C7FF BG tile RAM → BRAM dual-port $08C800-$
rtl/SkySmasher/SkySmasher_maincpu_map.sv:107 ─── Region detect (MAME bloodbro.cpp:465-483) ──────────────────────────
rtl/SkySmasher/SkySmasher_maincpu_map.sv:161 ─── GFX bank register ─────────────────────────────────────────────────── MAME dcon.cpp gfxbank_w: SOLO bit0 → m_gfx_bank_select = 0x1000 oppure 0.
rtl/SkySmasher/SkySmasher_palette.sv:25 MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_444, 2048); Address space CPU: 0x08E800..0x08F7FF (4 KB = 2048 word).
rtl/SkySmasher/SkySmasher_palette.sv:34 Espansione 5→8 bit con replica top-bits (standard MiSTer / MAME palette_device).
rtl/SkySmasher/SkySmasher_palette.sv:86 Blood Bros: xBGR_444 → RGB888 (MAME bloodbro.cpp:859 set_format xBGR_444) Layout: bit[11:8]=R, bit[7:4]=G, bit[3:0]=B. 4 bit per canale.
rtl/SkySmasher/SkySmasher_palette.sv:88 Replica 4→8 standard: {nibble, nibble} (MAME palette_device standard expansion)
rtl/SkySmasher/SkySmasher_seibu_crtc.sv:23 Seibu CRTC fedele a MAME (src/mame/seibu/seibu_crtc.cpp).
rtl/SkySmasher/SkySmasher_seibu_crtc.sv:83 Sky Smasher / Raiden DX: il CRTC usa "read_alt/write_alt" che applicano un bitswap su bit 3 e bit 4 dell'offset word (MAME seibu_crtc.cpp:379-387).
rtl/SkySmasher/SkySmasher_seibu_crtc.sv:123 MAME mappa: bit0=screen0(BG), bit1=screen2(MG), bit2=screen1(FG), bit3=screen3(Text) (vedi seibu_crtc.cpp commento "screen 0=BG, screen 1=FG, screen 2=MG, screen 3=Text") In SD Gundam dcon.cpp layer_en_w gira la maschera così: ~layer_en bit
rtl/SkySmasher/SkySmasher_seibu_crtc.sv:132 Il dispatcher MAME usa "if (BIT(~m_layer_en, n))" per saltare = layer disabilitato quando il bit è 1.
rtl/SkySmasher/SkySmasher_text_renderer.sv:25 Specifiche da MAME (src/mame/seibu/dcon.cpp):
rtl/SkySmasher/SkySmasher_tile_layer.sv:25 Differenze fra layer (da MAME dcon.cpp):
rtl/SkySmasher/SkySmasher_tile_layer.sv:58 BB FG hardcoded +0x1000 (MAME bloodbro fg_tile_info)
rtl/SkySmasher/SkySmasher_tile_layer.sv:169 Tile index con eventuale gfx_bank (MG ha bit 12 = 13-bit totali, BG/FG = 12 bit) + TILE_CODE_OFS hardcoded (BB FG aggiunge 0x1000 secondo MAME bloodbro fg_tile_info).
rtl/SkySmasher/SkySmasher_video_timing.sv:35 Active area da MAME (sdgndmps_map): visarea 0..40*8-1, 2*8..30*8-1 quindi 320×224, V offset = 16 (top blank).
rtl/SkySmasher/SkySmasher_video_timing.sv:72 ── Constants timing ───────────────────────────────────────────────────── Blood Bros: 256x224 active (MAME bloodbro.cpp:846-851 set_visarea 0..255, 16..239).
rtl/SkySmasher/sdram_bridge.sv:296 FG layer: Blood Bros shares ROM with BG (MAME bloodbro:807-808)
README.md:18 YM3812 OPL2 FM (jtopl2) + OKI M6295 ADPCM (jt6295) with MAME-accurate mixer
README.md:27 **MAME-accurate DIP switches**: Coin Mode (Mode 1 / Mode 2), Coinage, Starting Coin, Lives, Bonus Life, Difficulty, Allow Continue, Demo Sounds

Says it matches, follows or was checked against MAME — 1

SkySmasher.sv:311 SkySmasher SYSTEM port ($0E0004) IN1 — verified MAME bloodbro.cpp:746-754 bit0 = START1 (active LOW) bit4 = START2 (active LOW) bit12 = SERVICE1 (0x1000, active LOW) IPT_SERVICE1 altri = UNKNOWN/UNUSED → tied 1 Coin inputs NON s

Shares text with the MAME driver without saying so — 3

rtl/SkySmasher/SkySmasher_main_top.sv:363 MAME bloodbro.cpp:467 map(0x08b000, 0x08bfff).ram().share(m_spriteram) → 4KB. — shares text with seibu/bloodbro.cpp:467
rtl/SkySmasher/SkySmasher_palette.sv:23 Palette RAM Seibu Blood Bros (xBGR_444, 2048 entries). MAME: PALETTE(config, m_palette).set_format(palette_device::xBGR_444, 2048); Address space CPU: — shares text with seibu/bloodbro.cpp:859
rtl/SkySmasher/SkySmasher_video_timing.sv:23 Video timing single-screen Seibu D-Con. SD Gundam Psycho Salamander gira su Seibu D-Con (PB91008), stessa famiglia di Blood Bros (1990). PCB measuremen — shares text with seibu/bloodbro.cpp

SlapFight#
Slap Fight, Tiger-Heli
MiSTer-devel/Arcade-SlapFight_MiSTer @ 9ce05e39
MAME compared: toaplan/slapfght.cpp + 3 related file(s)
Read: 14 HDL files, 3,877 lines (Quartus project)

MiSTer official

Mostly hardware

low

21%

Statements: 17 toward hardware, 1 not counted

Cites hardware documentation that MAME's driver does not — 1

rtl/slapcore/slap_mcu.v:2 MCU Handshake Flip-Flops (directly from TTL 74LS74) Used for communication with external 68705 MCU (Slap Fight protection) This code does not function currently

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/slapcore/slap_sprites.v:271 Sprite 32K RAM Control Signals — also in MAME: 32K toaplan/slapfght.cpp:25

Ships hardware documentation files — 16

SMS#
Fantasy Zone II - The Tears of Opa-Opa, Hang-On Jr., Megumi Rescue, Opa Opa …
MiSTer-devel/SMS_MiSTer @ 3ae7eec9
MAME compared: sega/segae.cpp + 1 related file(s)
Read: 51 HDL files, 14,671 lines (Quartus project)

MiSTer official

Mostly MAME

low

29%

Statements: 13 toward MAME

Cites MAME source — 10

rtl/cart_eeprom.vhd:7 Write $8000: bit 2=CS bit 1=CLK bit 0=DI (MAME & Genesis-Plus-GX convention) Read $8000: bit 0=DO
rtl/system.vhd:344 4-PAK All Action mapper signals (HES 4 PAK All Action) References: MAME sega8_4pak_device (src/devices/bus/sega8/rom.cpp)
rtl/system.vhd:350 Zemina/Nemesis mapper family (MAME: sega8_zemina_device / sega8_nemesis_device) Zemina: 8KB banking via writes to $0000-$0003; $0000-$1FFF starts from page 0.
rtl/system.vhd:364 Static opcode-scan Zemina detection (computed during ROM download, ROMCL domain) Mirrors MAME's get_cart_type() logic: counts LD (nn),A opcodes targeting $0002/$0003/$0004 vs $FFFF in the first 32KB of the ROM.
rtl/system.vhd:373 Static Codemasters header detection (mirrors MAME get_cart_type) Checks: ROM[0x7FE0] & 0x0F <= 9, ROM[0x7FE3] in {0x93, 0x94, 0x95}, ROM[0x7FEF] = 0x00
rtl/system.vhd:1428 4-PAK All Action mapper (per MAME sega8_4pak_device): $3FFE: reg0=D; bank0=D; bank2=(reg0[5:4]+reg2) $7FFF: bank1=D (independent) $BFFF: reg2=D; bank2=(reg0[5:4]+D)
rtl/system.vhd:1560 MEKA mapper type 11: no mapper, linear ROM (MAME dahjee_typeb).
rtl/system.vhd:1585 (MAME devices: sega8_dahjee_typea_device) Dahjee Type A heuristic + OSD force.
rtl/system.vhd:1651 detect_zemina_static: MAME-equivalent static opcode scan result.
rtl/system.vhd:1915 No opcode-boundary tracking needed: same approach as MAME.

Says it matches, follows or was checked against MAME — 1

rtl/system.vhd:1912 Static Zemina opcode scan (MAME get_cart_type() port) Scans only the first 32KB (ROMAD < 0x8000), matching MAME exactly.

Says it was translated, ported or taken from MAME — 1

rtl/MC8123.v:1 Copyright 2021 by blackwine decryption algorithm based on MAME sources

Shares text with the MAME driver without saying so — 1

SMS.sv:181 0 1 2 3 4 5 6 — shares text with sega/segae.cpp:821

SNK6502#
Fantasy, Nibbler, Pioneer Balloon, Sasuke vs. Commander …
MiSTer-devel/Arcade-SNK6502_MiSTer @ 0e32dadc (matched by date)
MAME compared: snk/snk6502.cpp + 4 related file(s)
Read: 10 HDL files, 4,997 lines (Quartus project)

MiSTer official

Both

low

48%

Statements: 4 toward hardware, 28 toward MAME

Ships hardware documentation files — 3

Notes where it differs from MAME — 1

rtl/snk6502.v:462 MAME cannot arbitrate this: it ignores R12/R13 entirely and renders the tilemap from its own scan (TILEMAP_SCAN_ROWS, tile_index 0 at the origin, no scrolldx), so the whole question is invisible there.

Cites MAME source — 21

Arcade-SNK6502.sv:233 ----- Sasuke / SatanSat free-running counter ----- MAME (snk6502.cpp): 8-bit counter += 0x10 at 1.4 MHz; sasuke_count_r() = counter >> 4.
Arcade-SNK6502.sv:325 --- Fantasy (game_id=3) --- IN0 b7=L b6=R b5=U b4=D (8W); MAME has b3..0=UNKNOWN.
Arcade-SNK6502.sv:342 MAME maps debug service inputs (slow-down, pause, end-game) onto those bits for testing, but the ROM treats any high level on those bits as debug activity.
Arcade-SNK6502.sv:389 MAME custom bit — high when sound ch0 is muted
rtl/snk6502.v:46 Sound channel 0 mute status (MAME music0_playing — active high when muted).
rtl/snk6502.v:444 MEASURED (MAME debugger, user, 2026-08-04): Sasuke and Satan of Saturn program an IDENTICAL 6845 register table to Vanguard except for ONE register pair - the start address R12/R13.
rtl/snk6502.v:491 MAME applies the full 8-bit value (snk6502_v.cpp:139 set_scrolly(0, data)), so [7:3]-only is wrong vs reference.
rtl/snk6502.v:495 Vanguard writes $3300 (scroll_y) 2967 times vs 199 for $3200 in the MAME trace, so this is the axis that actually carries the scrolling.
rtl/snk6502.v:541 MAME maps speech_w at $3400 EXACTLY (snk6502.cpp vanguard_map:409); a stray write anywhere else in the page would feed a spurious nibble into the HD38880 command FSM and desync it.
rtl/snk6502.v:608 Mirror MAME's HOLD_LINE: assert on vblank rising edge, auto-clear when CPU starts fetching the IRQ vector ($FFFE).
rtl/snk6502.v:787 The colour is likewise delayed one character (bg_color_prev) so it still belongs to tile T. So f=0 reproduces the previous design exactly; only nonzero fine bits change anything, and MAME applies the full 8-bit scroll value the same way.
rtl/snk6502.v:849 MAME gfx_vanguard uses charlayout_memory for the FG with planes { 0, 256*8*8 }, and MAME's FIRST plane entry is the pixel MSB => MSB = charram+0x000 (= our charram_p0), LSB = charram+0x800 (= our charram_p1).
rtl/snk6502.v:990 MAME snk6502_v.cpp:26 (snk6502_palette; satansat_palette:189 is identical, so one formula covers all six games) uses resistor weights 0x21 / 0x47 / 0x97 per bit: r = 0x21*bit0 + 0x47*bit1 + 0x97*bit2 (prom bits 2:0) g = 0x21*bit3 + 0x4
rtl/snk6502.v:998 Bit-replication gave blue 0/85/170/255 - systematically ~15% too bright - which is why our cyan terrain measured (0,255,255) where MAME has (0,255,222).
rtl/snk6502.v:1108 Sound port write strobes — game-aware (per MAME memory maps) Fantasy/Nibbler: $2100-$2103 (port 3 also written by fantasy_flipscreen_w) Vanguard: $3100-$3102 (no port 3; $3103 is flipscreen only) Pioneer Balloon: $B100-$B102 (n
rtl/snk6502.v:1125 SASUKE-SATANSAT-SOUND-2026-08-03: Sasuke/SatanSat put their sound port at $B000/$B001 (MAME sasuke_map:347 / satansat_map:367), which was NOT DECODED ANYWHERE - so no sound command from either game ever reached snk6502_snd.
rtl/snk6502.v:1150 VANGUARD-SOUND-2026-08-03: selects MAME's vanguard_sound_device semantics instead of fantasy_sound_device's. See Claude/vanguard_audio_audit_2026-08-03.md
rtl/snk6502.v:1182 MAME vanguard_sound_device::sound_w port 0 (snk6502_a.cpp:577-617): bit 5 SHOT A -> sn76477.1 (was: NOT WIRED TO ANYTHING - silent gun) bit 6 SHOT B -> sn76477.2 (was: NOT WIRED TO ANYTHING) bit 7 BOMB -> "explsion" sample; left on the
rtl/snk6502.v:1186 MAME fantasy_sound_device::sound_w port 0 (:762-795): bit 7 BOMB -> sn76477.1 -> discrete, driven as a LEVEL (m_discrete->write(FANTASY_BOMB_EN, data & 0x80))
rtl/snk6502.v:1212 MAME routes this at 0.25 vs SHOT A's 0.50, hence half the amplitude.
rtl/snk6502.v:1255 MAME has the same imbalance - it routes Vanguard speech samples at 0.25 vs custom 0.50 / SHOT A 0.50 (snk6502_a.cpp:691-730) - and the user confirmed MAME Vanguard speech is inaudible without boosting the samples channel ~300% and reducing

Says it matches, follows or was checked against MAME — 4

Arcade-SNK6502.sv:295 Per-game IN0 / IN1 / IN2 construction (active high — matches MAME) Bit ordering reminder: {b7, b6, b5, b4, b3, b2, b1, b0}
rtl/snk6502.v:1002 Verified against screenshots: MAME's brightest blue really is 222.
rtl/snk6502.v:1022 Matches MAME's PORT_IMPULSE(1) + coin_inserted() semantics: NMI is asserted on the FALLING edge of the coin bit (i.e., when the user releases the coin button, or when MAME's 1-frame impulse expires).
rtl/snk6502.v:1199 ---- SN76477 leg A: 470k noise clock (3081.7 Hz) + 1.5M/220pF filter -------- Shared by Vanguard SHOT A and Fantasy BOMB: identical component values in MAME, and they belong to different games so the gates can never both be high.

Shares text with the MAME driver without saying so — 3

rtl/snk6502.v:4 Supports: Sasuke vs. Commander, Satan of Saturn / Zarzon, Vanguard, — shares text with snk/snk6502.cpp:8
rtl/snk6502.v:993 r = 0x21*bit0 + 0x47*bit1 + 0x97*bit2 (prom bits 2:0) — shares text with snk/snk6502_v.cpp:37
rtl/snk6502.v:1188 (m_discrete->write(FANTASY_BOMB_EN, data & 0x80)) — shares text with snk/snk6502_a.cpp:790

SNK_TripleZ80#
ASO - Armored Scrum Object
MiSTer-devel/Arcade-SNK_TripleZ80_MiSTer @ 7181e418
MAME compared: snk/snk.cpp + 2 related file(s)
Read: 79 HDL files, 9,067 lines (Quartus project)

MiSTer official

Mostly hardware

low

43%

Statements: 13 toward hardware, 3 toward MAME

Cites hardware documentation that MAME's driver does not — 11

rtl/clocks/AlphaMissionCore_Clocks_Sync.sv:199 74LS30 8-input positive NAND gate
rtl/clocks/pal16r6_15B_sync.v:1 Author: @RndMnkIII Date: 13/03/2022 Converted from ArmoredScrumObject_pal16r6a_3.jed using MAME's jedutil tool Many thanks to pldarchive.co.uk for the JED file.
rtl/cpuA_B/pal16l6c_A1_nodly.v:1 Author: @RndMnkIII Date: 14/12/2021 Converted from AlphaMission_PAL16L6C_1A.jed using MAME's jedutil tool Many thanks to pldarchive.co.uk for the JED file.
rtl/front/AlphaMissionCore_LineBuffer_sync.sv:155 74LS20 4-input NAND gate
rtl/ttl/ttl_74107a_sync.v:1 74LS107A: Dual J-/K flip-flop with clear; negative-edge-triggered Inputs Outputs
rtl/ttl/ttl_74163a_sync.v:1 4-bit modulo 16 binary counter with parallel load, *** FOR SYNTHESIS *** Synchronous Reset (SRn) -> LS163A <START_TEMPLATE> ttl_74161a #(.DELAY_RISE(20), .DELAY_FALL(25)) <NAME> (.Clear_bar(), .Load_bar(), .ENT(), .ENP(), .D(), .Clk(), .RCO
rtl/ttl/ttl_74373.sv:1 ttl_74373.sv Octal D transparent latch function table, logic diagrams and switching characteristics extracted from TI 74LS373 Datasheet.
rtl/ttl/ttl_74374_sync.sv:1 ttl_74374_sync.sv Octal D edge triggered FF function table, logic diagrams and switching characteristics extracted from TI 74LS374 Datasheet.
rtl/ym3526/jtopl_exprom.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.
rtl/ym3526/jtopl_logsin.v:16 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.
rtl/ym3526/jtopl_op.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.

Says it was checked on “real hardware” — 1

rtl/final_video/pal16l8a_F9_nodly.v:5 This PLD was simplified, cleaned and tested on real hardware (GAL16V8-25LP device)

Ships hardware documentation files — 1

docs/TNKIII_schematics.pdf

Cites MAME source — 3

rtl/SNK_TripleZ80.sv:257 0XCE00 cpuA write registers (Unknown meaning in MAME)
rtl/clocks/pal16r6_15B_sync.v:1 Author: @RndMnkIII Date: 13/03/2022 Converted from ArmoredScrumObject_pal16r6a_3.jed using MAME's jedutil tool Many thanks to pldarchive.co.uk for the JED file.
rtl/cpuA_B/pal16l6c_A1_nodly.v:1 Author: @RndMnkIII Date: 14/12/2021 Converted from AlphaMission_PAL16L6C_1A.jed using MAME's jedutil tool Many thanks to pldarchive.co.uk for the JED file.

SolomonsKey#
Solomon no Kagi
MiSTer-devel/Arcade-SolomonsKey_MiSTer @ 57b099d9
MAME compared: tecmo/solomon.cpp
Read: 17 HDL files, 6,424 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 1 toward MAME

Cites MAME source — 1

rtl/YM2149_linmix_sep.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA

Sonson#
Son Son
MiSTer-devel/Arcade-Sonson_MiSTer @ d0ac4b40
MAME compared: capcom/sonson.cpp
Read: 31 HDL files, 9,644 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 1 toward MAME

Cites MAME source — 1

rtl/ym2149/YM2149.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA

SpaceFirebird#
Space Firebird
MiSTer-devel/Arcade-SpaceFirebird_MiSTer @ ea952fe3
MAME compared: nintendo/spacefb.cpp
Read: 40 HDL files, 10,965 lines (Quartus project)

MiSTer official

Mostly MAME

low

13%

Statements: 2 toward hardware, 29 toward MAME, 1 not counted

Cites hardware documentation that MAME's driver does not — 2

rtl/dkongjr_dac.sv:8 Components R20, C32 and Q4 on schematics.
rtl/nintendo_sound.v:90 ---- DATA ROM 3H ---------------------------

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/SpaceFirebird.vhd:228 0000-3FFF ROM Code 8000-83FF RAM Sprite RAM C000-C7FF RAM Game RAM — also in MAME: 83FF nintendo/spacefb.cpp:28

Cites MAME source — 1

README.txt:20 The schematics show orange / yellow (but with one resistor mislabelled as 68 ohm) Mame uses red, because of this error on the schematics.

Shares text with the MAME driver without saying so — 28

rtl/SpaceFirebird.vhd:425 bit 5 = Char/Sprite Bank switch (VREF) — shares text with nintendo/spacefb.cpp:86
rtl/SpaceFirebird.vhd:426 bit 6 = Turns on Bit 2 of the color PROM. Used to change the bird colors. (CREF) — shares text with nintendo/spacefb.cpp:87
rtl/SpaceFirebird.vhd:429 bit 0 = discrete sound (Enemy death) — shares text with nintendo/spacefb.cpp:91
rtl/SpaceFirebird.vhd:431 bit 2 = T1 input to 8035 — shares text with nintendo/spacefb.cpp:93
rtl/SpaceFirebird.vhd:432 bit 3 = PB4 input to 8035 — shares text with nintendo/spacefb.cpp:94
rtl/SpaceFirebird.vhd:433 bit 4 = PB5 input to 8035 — shares text with nintendo/spacefb.cpp:95
rtl/SpaceFirebird.vhd:434 bit 5 = T0 input to 8035 — shares text with nintendo/spacefb.cpp:96
rtl/SpaceFirebird.vhd:435 bit 6 = discrete sound (Ship fire) — shares text with nintendo/spacefb.cpp:97
rtl/SpaceFirebird.vhd:436 bit 7 = discrete sound (Explosion noise) — shares text with nintendo/spacefb.cpp:98
rtl/SpaceFirebird.vhd:440 These are passed to the sound board and are used to produce a — shares text with nintendo/spacefb.cpp:102
rtl/SpaceFirebird.vhd:441 red flash effect when you die. — shares text with nintendo/spacefb.cpp:103
rtl/SpaceFirebird.vhd:443 bit 0 = CONT R Changes contrast of the red/green/blue part of the stars. This is used to make the starfield flicker — shares text with nintendo/spacefb.cpp:105
rtl/SpaceFirebird.vhd:446 bit 3 = ALRD Turns background red on — shares text with nintendo/spacefb.cpp:108
rtl/SpaceFirebird.vhd:447 bit 4 = ALBU Turns background blue on — shares text with nintendo/spacefb.cpp:109
rtl/SpaceFirebird.vhd:448 bit 7 = ALBA Turns off star field (no star field) — shares text with nintendo/spacefb.cpp:112
rtl/SpaceFirebird.vhd:497 bit 4 = Player 1 Warp / Escape — shares text with nintendo/spacefb.cpp:40
rtl/SpaceFirebird.vhd:504 bit 4 = Player 2 Warp / Escape — shares text with nintendo/spacefb.cpp:51
rtl/SpaceFirebird.vhd:509 bit 2 = Start 1 Player game — shares text with nintendo/spacefb.cpp:60
rtl/SpaceFirebird.vhd:510 bit 3 = Start 2 Players game — shares text with nintendo/spacefb.cpp:61
rtl/SpaceFirebird.vhd:512 bit 7 = Coin and Service switch — shares text with nintendo/spacefb.cpp:65
rtl/SpaceFirebird.vhd:599 bit 0 = discrete sound (Enemy death) — shares text with nintendo/spacefb.cpp:91
rtl/SpaceFirebird.vhd:604 bit 7 = discrete sound (Explosion noise) — shares text with nintendo/spacefb.cpp:98
rtl/SpaceFirebird.vhd:610 bit 6 = discrete sound (Ship fire) — shares text with nintendo/spacefb.cpp:97
rtl/SpaceFirebird_video.vhd:513 CONT R Changes contrast of the red/green/blue part of the stars. This is used to make the starfield flicker — shares text with nintendo/spacefb.cpp:105
rtl/nintendo_sound.v:44 -- bit 2 = T1 input to 8035 — shares text with nintendo/spacefb.cpp:93
rtl/nintendo_sound.v:45 -- bit 3 = PB4 input to 8035 — shares text with nintendo/spacefb.cpp:94
rtl/nintendo_sound.v:46 -- bit 4 = PB5 input to 8035 — shares text with nintendo/spacefb.cpp:95
rtl/nintendo_sound.v:47 -- bit 5 = T0 input to 8035 — shares text with nintendo/spacefb.cpp:96

SpaceInvaders#
280-ZZZAP, Attack Force, Balloon Bomber, Blue Shark …
MiSTer-devel/Arcade-SpaceInvaders_MiSTer @ 07386c17
MAME compared: midw8080/8080bw.cpp + 12 related file(s)
Read: 23 HDL files, 6,555 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

33%

Statements: 5 toward MAME

Cites MAME source — 2

Arcade-SpaceInvaders.sv:978 note because the CPU has the address line A9 (A1 for IO) inverted we have to be careful in looking at mame mapping Currently: GDB0-7 have A9 inverted, but PortWr doesn't we should probably not invert A9 in GDB0-7?
README.md:23 Included is a python script that converts the MAME .lay files into Taito color overlay rom format.

Shares text with the MAME driver without saying so — 3

Arcade-SpaceInvaders.sv:683 0x07, 0x06, 0x04, 0x05, 0x01, 0x00, 0x02 — shares text with midw8080/mw8080bw.cpp:432
Arcade-SpaceInvaders.sv:685 0x06, 0x02, 0x00, 0x04, 0x05, 0x01, 0x03 — shares text with midw8080/mw8080bw.cpp:539
Arcade-SpaceInvaders.sv:687 0x00, 0x04, 0x06, 0x07, 0x03, 0x01, 0x05 — shares text with midw8080/mw8080bw.cpp:1119

SpaceRace#
Space Race [TTL]
MiSTer-devel/Arcade-SpaceRace_MiSTer @ 93d68ce9
MAME driver: not found
Read: 40 HDL files, 3,672 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

11%

Statements: 1 toward hardware

Cites hardware documentation that MAME's driver does not — 1

Arcade-SpaceRace.sv:3 Based on Rev.F schematics

Sprint1#
Sprint 1
MiSTer-devel/Arcade-Sprint1_MiSTer @ fc0e8180
MAME compared: atari/sprint2.cpp + 2 related file(s)
Read: 20 HDL files, 5,306 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 3 toward hardware

Cites hardware documentation that MAME's driver does not — 3

rtl/collision.vhd:63 74LS279 quad SR latch at H6, all inputs are active low Made synchronous here
rtl/playfield.vhd:93 Some glue logic, may be re-written later to be cleaner and easier to follow without referring to schematic
rtl/playfield.vhd:169 74LS166 video shift register

Sprint2#
Sprint 1
MiSTer-devel/Arcade-Sprint2_MiSTer @ cd2b0025
MAME compared: atari/sprint2.cpp + 2 related file(s)
Read: 20 HDL files, 5,563 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 3 toward hardware

Cites hardware documentation that MAME's driver does not — 3

rtl/collision.vhd:69 74LS279 quad SR latch at H6, all inputs are active low These should probably be written as synchronous latches
rtl/playfield.vhd:95 Some glue logic, may be re-written later to be cleaner and easier to follow without referring to schematic
rtl/playfield.vhd:180 74LS166 video shift register

ST-V#
Astra SuperStars, Baku Baku Animal, Batman Forever, Columns '97 …
MiSTer-devel/Saturn_MiSTer @ db56bcec
MAME compared: sega/stv.cpp + 23 related file(s)
Read: 76 HDL files, 44,554 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 1 toward hardware, 5 toward MAME

Cites hardware documentation that MAME's driver does not — 1

rtl/Saturn/CART.sv:5 0-none, 1-ROM 2M, 2-DRAM 1M, 3-DRAM 4M, 4-DRAM 6M, 5-BACKUP

Shares text with the MAME driver without saying so — 5

Saturn.sv:276 0 1 2 3 4 5 6 7 8 9 — shares text with sega/315-5881_crypt.cpp:529
rtl/Saturn/STV/STVIO.sv:34 0x0007 PORT-D (OUTPUT) JAMMA (56P) + CN25 (JST NH 5P) RESERVED OUTPUT 4bit. (?) — shares text with sega/stv.cpp:134
rtl/Saturn/STV/STVIO.sv:35 0x0009 PORT-E (P3) CN32 (JST NH 9P) EXTENSION I/O 8bit. — shares text with sega/stv.cpp:135
rtl/Saturn/STV/STVIO.sv:36 0x000b PORT-F (P4 / Extra 6B layout) CN21 (JST NH 11P) EXTENSION I/O 8bit. — shares text with sega/stv.cpp:150
rtl/Saturn/STV/STVIO.sv:37 0x000d PORT-G CN20 (JST HN 10P) EXTENSION INPUT 8bit. (?) — shares text with sega/stv.cpp:137

Starforce#
Baluba-louk no Densetsu, Star Force
MiSTer-devel/Arcade-StarForce_MiSTer @ 9327e228
MAME compared: tecmo/senjyo.cpp
Read: 23 HDL files, 6,696 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

11%

Statements: 2 toward MAME

Cites MAME source — 2

Arcade-Starforce.sv:368 JPAC/IPAC/MAME Style Codes
rtl/sn76489/sn76489_noise.vhd:199 Tapped bits according to MAME's sn76496.c, implemented in function lfsr_tapped_f.

StarWars#
The Empire Strikes Back, Star Wars
MiSTer-devel/Arcade-StarWars_MiSTer @ 64aaa04a
MAME compared: atari/starwars.cpp + 4 related file(s)
Read: 37 HDL files, 20,579 lines (Quartus project)

MiSTer official

Both

low

17%

Statements: 28 toward hardware, 7 toward MAME, 6 not counted

Cites hardware documentation that MAME's driver does not — 28

rtl/avg/avg.vhd:104 On hardware, this is latched by the LS175 (6L, schematic p.25 Fig.1) from DVY10-DVY8, and drives the LS191 down-counter that gates additional fill-bit shifts into the timer at STROBE 1.
rtl/avg/avg.vhd:113 GO flag (schematic p.24 Fig.3: 2E LS32 pin 8).
rtl/avg/avg.vhd:123 Normalization at 12 MHz (schematic p.24 Fig.0: Normalization Flag circuit).
rtl/avg/avg.vhd:124 STROBE 0 + OP0=0 sets NORM (LS74 5K).
rtl/avg/avg.vhd:129 15-bit Vector Timer (schematic p.25 Fig.0: four cascaded LS161 counters 1D/1C/1B/2B, clocked at 12 MHz during draw, enabled by PR111 (+5V pull-up), loaded via fill-bit shifts during normalization and bin_scale).
rtl/avg/avg.vhd:137 Bin_scale shift mechanism at STROBE 1 (schematic p.25 Fig.1: Vector Scaling).
rtl/avg/avg.vhd:241 ===== VMEM bus arbitration: CPU accessing vector memory ===== On real hardware (schematic p.24 Fig.3), EVMEM from the main board gates the state machine clock via NOR gate 3E (LS02).
rtl/avg/avg.vhd:275 /LATCH1 clears three chip groups (schematic p.23): 5F,5H (Fig.2): DVY0-7 async cleared to 0 5A,5B,5C (Fig.2): DVX0-11 async cleared to 0 3C (Fig.0): Z0-Z2 + DVX12 async cleared to 0 6H(DVY8-11) has /CLR=PR110 (not cleared here).
rtl/avg/avg.vhd:312 STROBE0 + OP0=0 sets NORM (LS74 5K, p.24 Fig.0).
rtl/avg/avg.vhd:323 STROBE 1 (state $D): SP adjust for JSR/RTS, or Vector Scaling (schematic p.25 Fig.1) for VCTR/SVEC.
rtl/avg/avg.vhd:409 12 MHz Normalization Block (runs OUTSIDE clken gate) Schematic p.23 Fig.2: LS194 shift registers (3A-3D, 4A-4D) shift DVX/DVY left at 12 MHz, gated by ENORM.
rtl/avg/avg.vhd:412 Schematic p.25 Fig.0: LS161 timer chain (1D/1C/1B/2B) shifts right simultaneously, filling from the top.
rtl/avg/avg.vhd:414 Schematic p.24 Fig.0: NORM flag freezes PROM via SA.
rtl/avg/avg.vhd:454 12 MHz Bin_Scale Block (runs OUTSIDE clken gate) Schematic p.25 Fig.1: Vector Scaling circuit.
rtl/mathbox.sv:4 Hardware reference: - 4x 1Kx4 Microcode PROMs (136021-110 through 136021-113) - 74LS384 serial subtractor-multiplier-accumulator - 2Kx16 shared Math RAM ($5000-$5FFF as CPU sees it) - 15-bit unsigned fractional divider - 23-bit PRNG (LFSR)
rtl/mathbox.sv:16 Based on SWMP.DOC, TCODE2.MAC, SWSIG.DOC, and original schematics: - SP-225 Sheet 5B & 6A: Divider, Matrix Processor, and Multiplier-Accumulator Block Diagrams - SP-225 Sheet 9A, 9B: 15-bit Restoring Divider - SP-225 Sheet 10A: Multiplier/A
rtl/reticon_r5106.sv:4 Models the delay circuit on the original Atari Star Wars PCB (Sheet 16B): R5106 BBD: 512 stages, clocked at 37.8 kHz = 13.5 ms delay Recovery amp: TL084 (1/4 3C) with R45=470K, R46=12K Post-delay filter: TL084 (1/4 2B), R47=12K, C57/C58=270
rtl/reticon_r5106.sv:9 Schematic analysis (Sheet 16B, fig 2: "Output and Summing Amplifiers") shows the delayed signal feeds two TL084 stereo output amps alongside the dry "AUD" signal, creating what SWSIG.DOC calls "synthesized stereo." My interpretation: Left =
rtl/reticon_r5106.sv:13 The exact polarity is difficult to confirm from the available schematic scans.
rtl/slapstic101.vhd:1 Atari SLAPSTIC 137412-101 (Empire Strikes Back / Tetris) — faithful FPGA port of MAME's DECAPPED slapstic (src/mame/atari/slapstic.{cpp,h}, Aaron Giles & Frank Palazzolo).
rtl/slapstic101.vhd:16 KEY DECAPPED FACTS (type 101, 13 address lines A0-A12, banked region $8000-$9FFF): * range_mask = 0xE000, input_mask = 0x1FFF, range_value = 0x8000 * test_in(mv) : inside ($8000-$9FFF) AND (a & mv.mask)=mv.value
rtl/slapstic101.vhd:28 type-101 data (decapped): bankstart 3 ; bank = {0x0080,0x0090,0x00a0,0x00b0} alt1 {0x1f00,0x1e00} alt2 {0x1fff,0x1fff}(any/outside) alt3 {0x1ffc,0x1b5c} alt4 {0x1fcf,0x0080} altshift 0 bit1 {0x1ff0,0x1540} bit2 {0x1fcf,0x0080} bit3c0 {
rtl/starwars.sv:251 --- ROM Download Address Decoding --- ----- SW-mode dn_addr decoders ----- MRA ROM layout (index 0), based on actual file sizes: 0x00000-0x03FFF: Banked ROM (16KB: 136021.214.1f, two 8K bank pages) 0x04000-0x0BFFF: Main ROM (32KB: 4x 8KB f
rtl/starwars.sv:644 Bus arbitration: on real hardware, EVMEM gates the AVG state machine clock via NOR gate 3E (LS02) on the AVG board (schematic p.24 Fig.3).
rtl/starwars.sv:828 AUDIO MIXING (Based on original Atari schematic SP-225 Sheet 16A/16B)
rtl/starwars.sv:862 AUDIO PROCESSING (Sheet 16B: Filter + Reticon R5106 Delay/Stereo)
rtl/starwars.sv:889 Reticon R5106 Delay (13.5 ms) - Pseudo-Stereo The original PCB routes the delayed signal to stereo summing amps (Sheet 16B, fig 2) alongside the dry signal.
README.md:22 | **Vector Generator** | Atari Analog Vector Generator (AVG) with state machine PROM, 10-bit DACs, analog integrators | Cycle-exact digital AVG in `avg.vhd` bas

Cites hardware references or measurements that MAME's driver also gives — 6

rtl/avg/avg.vhd:63 Hardware: 136021-109.4b bipolar PROM — also in MAME: 136021-109 atari/starwars.cpp:391
rtl/avg/avg.vhd:109 PROM state machine signals (256x4 PROM 136021-109.4b, schematic p.24 Fig.3) — also in MAME: 136021-109 atari/starwars.cpp:391
rtl/mathbox.sv:220 Serial Multiplier State (74LS384 model) ACC += (A-B) * C * 4 (the <<2 models 74LS384 pipeline alignment) A-B is retained at 17 bits before the signed multiply. — also in MAME: 74LS384 atari/starwars_m.cpp:231, 74LS384 atari/starwars_m.cpp:231
rtl/mathbox.sv:367 Initialize serial multiplier (74LS384) A-B at 17-bit width (prevents wrapping), then sign-extended to 33 bits — also in MAME: 74LS384 atari/starwars_m.cpp:231
rtl/mathbox.sv:397 ----- MAC Stall: 33 cycles for serial multiply ----- Models the 74LS384 serial subtractor-multiplier-accumulator. — also in MAME: 74LS384 atari/starwars_m.cpp:231
README.md:21 | **Math Processor** | Custom TTL Mathbox (PROM-sequenced matrix processor, 74LS384 serial multiplier, 15-step restoring divider) | Fully modeled in `mathbox.sv — also in MAME: 74LS384 atari/starwars_m.cpp:231

Cites MAME source — 5

rtl/A6532.vhd:19 Reference: MOS 6532 datasheet, mos6532_device, Stella M6532, MAME
rtl/TMS5220.vhd:15 References: TMS5220 datasheet, US Patent US4335277 and TMS5220.cpp from MAME source code.
rtl/slapstic101.vhd:5 WHY THIS EXISTS (supersedes rtl/slapstic.vhd for ESB): rtl/slapstic.vhd is a verbatim translation of an OLD, *unconfirmed* MAME slapstic.
rtl/slapstic101.vhd:10 But ESB *gameplay* uses ALTERNATE ("devious") banking, confirmed via MAME (-log) over real play: 51 full alt-start/valid/select/commit sequences reaching banks 0/2.
rtl/slapstic101.vhd:24 MAME taps the WHOLE space; so must we.

Says it was translated, ported or taken from MAME — 2

rtl/TMS5220.vhd:17 IMPORTANT NOTES: 1) This implementation does NOT implement the schematic in US4335277 2) It is based primarily on MAME source code and aims to be "functionally equivalent" to the "TMS5220" chip but not identical in terms of electrical circu
rtl/slapstic101.vhd:1 Atari SLAPSTIC 137412-101 (Empire Strikes Back / Tetris) — faithful FPGA port of MAME's DECAPPED slapstic (src/mame/atari/slapstic.{cpp,h}, Aaron Giles & Frank Palazzolo).

Subs#
Subs
MiSTer-devel/Arcade-Subs_MiSTer @ 2d7bc75a
MAME compared: atari/subs.cpp + 2 related file(s)
Read: 22 HDL files, 7,628 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

16%

Statements: 10 toward hardware

Cites hardware documentation that MAME's driver does not — 10

rtl/cpu_mem.vhd:353 74LS42 at B9 decodes ROM and RAM enable signals
rtl/cpu_mem.vhd:364 74LS42 at D9 decodes IO enable signals Write to outputs
rtl/cpu_mem.vhd:379 74LS259 addressable latch at C9, this drives outputs
rtl/input.vhd:95 74LS251 data selector/multiplexer at E10
rtl/input.vhd:112 74LS251 data selector/multiplexer at F10
rtl/input.vhd:129 74LS253 dual selector/multiplexer at E9
rtl/mixer.vhd:74 74LS174 latches video signals with rising edge of 6MHz clock
rtl/playfield.vhd:119 74LS166 video shift register
rtl/playfield.vhd:176 74LS163 counter at L6 CEP and CET tied to ground, counter is used only as a synchronous latch
rtl/subs_core.vhd:16 Targeted to EP2C5T144C8 mini board but porting to nearly any FPGA should be fairly simple See Subs manual Figure 4-11 for video output details.

SuperBreakout#
Super Breakout
MiSTer-devel/Arcade-SuperBreakout_MiSTer @ 6d13f89b
MAME compared: atari/sbrkout.cpp
Read: 19 HDL files, 4,980 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

11%

Statements: 2 toward hardware, 1 toward MAME

Cites hardware documentation that MAME's driver does not — 2

rtl/paddle_analog.vhd:47 Logic gates in IC at M10 These should be a 74LS132 with Schmitt trigger inputs, may not work reliably using FPGA pins directly
rtl/playfield.vhd:114 74LS166 video shift register

Cites MAME source — 1

rtl/super_breakout.vhd:182 r 3 g 3 b 3 https://github.com/mamedev/mame/blob/master/src/mame/layout/sbrkout.lay

SuprLoco#
Super Locomotive
MiSTer-devel/Arcade-SuprLoco_MiSTer @ 8a31d652
MAME compared: sega/suprloco.cpp
Read: 16 HDL files, 3,290 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

58%

Statements: 7 toward hardware, 3 toward MAME

Cites hardware documentation that MAME's driver does not — 7

rtl/SuprLoco_emu.v:148 Note 1: TBP24S41 = 82S137 TBP28S46 = 82S141 TBP18S030 = 82S123
rtl/SuprLoco_top.v:44 82S137(AW10)
rtl/SuprLoco_top.v:45 82S141(AW9)
rtl/SuprLoco_top.v:46 82S123(AW5)
rtl/SuprLoco_top.v:56 74LS321 acts really weird - see the LS321 sigrok waveform
rtl/SuprLoco_top.v:410 74LS377
rtl/SuprLoco_top.v:411 74LS273

Cites MAME source — 1

rtl/SuprLoco_emu.v:128 start addr length comp num mame rom parts num location description

Shares text with the MAME driver without saying so — 2

SuprLoco.sv:214 0 1 2 3 4 5 6 — shares text with sega/suprloco.cpp:456
rtl/SuprLoco_top.v:55 74LS321 acts really weird - see the LS321 sigrok waveform CLK40M ¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_|¯|_| pres — shares text with sega/suprloco.cpp:456

TaitoAsuka#
Asuka & Asuka, Jigoku Meguri, Cadash, U.N. Defense Force: Earth Joker …
MiSTer-devel/Arcade-TaitoAsuka_MiSTer @ 747a777b
MAME compared: taito/asuka.cpp + 11 related file(s)
Read: 54 HDL files, 24,873 lines (Quartus project)

MiSTer official

Both

medium

40%

Statements: 6 toward hardware, 157 toward MAME, 2 not counted

Cites hardware documentation that MAME's driver does not — 3

rtl/asuka/z180/cadash_link_z180.sv:20 $8000-$87FF RAM condivisa col 68000 (2 KB) I/O $00-$3F registri interni -> z180_io
README.md:79 This core runs the **real firmware on an HDL model of the MCU**: [`jttc0030cmd`](https://github.com/jotego/jtcores) by **Andrea Bogazzi** wrapping **Raki**'s `I
README.md:272 **Raki** for **IKA87AD**, the uPD78C11 model reconstructed from the decapped die and the NEC datasheet, and **Andrea Bogazzi** ([@asturur](https://github.com/as

Cites hardware references or measurements that MAME's driver also gives — 2

rtl/asuka/asuka_top.sv:249 work RAM 32K word — ci vive lo stack della CPU — also in MAME: 32K taito/asuka.cpp:107
rtl/asuka/asuka_top.sv:251 sprite RAM 8K word — also in MAME: 8K taito/asuka.cpp:108

Notes where it differs from MAME — 3

rtl/asuka/tc_mame/tc0100scn_mame.sv:217 Chip MAME non finisce la scansione dentro hblank window (2652 clk a 96/24).
rtl/asuka/z180/cadash_link_rom.sv:15 Perche' BRAM e non SDRAM, visto che il canale `sub_rom_*` esisterebbe gia': se il canale seriale sbaglia anche un solo byte, il gioco scrive a video COMMUNICATION CHECKSUM ERROR e BLOCCA il 68000 con ori #$700,sr e un loop infinito.
README.md:127 That is not a bug, it was confirmed on a genuine PCB, and MAME does not reproduce it.

Cites MAME source — 145

Template.sv:338 Le due famiglie del driver asuka.cpp hanno disposizioni COMPLETAMENTE diverse: sbagliarle non sposta solo un tasto.
Template.sv:341 Misurato su MAME 0.286 con le porte a riposo:
Template.sv:376 Disposizione dei bit dalle ioport di MAME (asuka.cpp:1106-1110): PA "800007": 5=START2 6=START1 7=SERVICE, attivi bassi PB "800009": 0=COIN1 1=COIN2, attivi ALTI e a impulso PC "80000B": 0=TILT 2=SU 3=GIU 4=SX 5=DX 6=TASTO1 7=TASTO2, att
Template.sv:382 I coin sono l'unico punto delicato: in MAME hanno PORT_IMPULSE(1), cioe' valgono UN quadro e poi tornano a riposo anche se tieni premuto.
Template.sv:448 Sceglie di quale set del driver asuka.cpp il core deve fare le veci.
Template.sv:754 Hardcoded 16 MHz (Cadash MAME XTAL 32/2, asuka.cpp:1222).
Template.sv:767 Sprite: sincroni come in MAME (default) o in ritardo come sulla scheda.
Template.sv:868 1-bit OSD: 0=Polite (default), 1=MAME (100%)
Template.sv:937 Video: quarzo 26.686 MHz (header di asuka.cpp, PCB), TC0100SCN → pixel clock = 26.686/4 = 6.6715 MHz, riga di 424 pixel = 15.735 kHz (riga NTSC), quadro di 262 righe = 60.06 Hz.
Template.sv:940 Visibile 320x240 (MAME: set_size(320,256), visarea(0,319,16,255), 60 Hz).
Template.sv:1015 MAME warning overlay: "DON'T BREAK YOUR WOOFER!" per ~3s su edge status[95]
rtl/asuka/asuka_audio_top.sv:246 ROM bank register Cadash (mask 0x03 = 4 banchi, da YM2151 CT1/CT2) MAME asuka.cpp:1202 ymsnd.port_write_handler().set_membank(m_audiobank).mask(0x03) → quando jt51 emette CT1/CT2, bank = {ct2, ct1}.
rtl/asuka/asuka_audio_top.sv:317 YM2151 a 0x9000-0x90FF (decode larga, MAME mappa solo 9000/9001).
rtl/asuka/asuka_audio_top.sv:371 ADPCM-A: la scheda di Bonze NON monta la ROM del canale A (in MAME c'e' la sola regione ymsnd:adpcmb).
rtl/asuka/asuka_audio_top.sv:437 PSG resta non panneggiato (in MAME va al subwoofer mono, qui lo sommo a entrambi i canali).
rtl/asuka/asuka_audio_top.sv:463 osd_adpcmb e osd_psg restano inutilizzati: nessun set di asuka.cpp ha quei blocchi.
rtl/asuka/asuka_audio_top.sv:478 In MAME lo YM2151 va sul bus a 0.25 e l'MSM a 0.5, cioe' l'ADPCM e' il doppio del FM; qui pero' il FM e' gia' a fondo scala, quindi raddoppiarlo significherebbe solo saturare.
rtl/asuka/asuka_audio_top.sv:512 MAME msm_state (asuka.cpp), z80_map: $B000 w -> pos = (pos & 0x00FF) | (data << 8) $C000 w -> reset_w(0): parte.
rtl/asuka/asuka_maincpu_map.sv:24 MAME: cadash_state::main_map (asuka.cpp:638)
rtl/asuka/asuka_maincpu_map.sv:43 Mappa di memoria del 68000 (MAME asuka.cpp): 0 = cadash_state::main_map (Cadash) 1 = msm_state::asuka_map (Asuka & Asuka, Galmedes, Earth Joker, Maze of Flott) Cambia dove stanno IOC, PCR, PC060HA, sprite RAM e sprite ctrl.
rtl/asuka/asuka_maincpu_map.sv:144 --- Address decode --- Le due mappe, riga per riga (MAME asuka.cpp): cadash main_map asuka_map
rtl/asuka/asuka_maincpu_map.sv:159 eto (base_state::eto_map, asuka.cpp:653): ROM 000000-0FFFFF TC0110PCR palette 100000-10000F work RAM 200000-203FFF (16K)
rtl/asuka/asuka_maincpu_map.sv:169 a C04000-C0FFFF, sopra la sprite RAM TC0100SCN ctrl D20000-D2000F bonze (bonzeadv_state::main_map, asuka.cpp:597): ROM 000000-03FFFF e 080000-0FFFFF (il buco in mezzo non e' decodificato, come su asuka) TC0110PCR pale
rtl/asuka/asuka_maincpu_map.sv:211 Su eto l'IOC risponde anche a 400000-40000F, ma in sola LETTURA: e' il mirror che il gioco usa per il service mode (asuka.cpp:657).
rtl/asuka/asuka_maincpu_map.sv:217 La parola vale 00xx come in MAME, dove la porta e' a 8 bit e i bit alti restano a 0.
rtl/asuka/asuka_maincpu_map.sv:358 --- CPUA ctrl --- MAME cpua_ctrl_w: if only high byte is written (UDS only), shift high→low so bit 0 of the low byte is correctly set.
rtl/asuka/asuka_maincpu_map.sv:367 MAME-style high-byte-only normalization
rtl/asuka/asuka_maincpu_map.sv:377 --- TC0140SYT sound comm (real, no stub) --- MAME: $220001=master_port_w, $220003=master_comm_r/w Pilotiamo cs/wr/rd/a1 al TC0140SYT vero in audio_top.
rtl/asuka/asuka_sprite_renderer.sv:27 Sprite RAM format (MAME, 4 words per entry at $E00100): Darius 2 sprite format (ninjaw.cpp): word[0]: X position → sx = (data - 32) & 0x3FF word[1]: Y position → sy = data & 0x1FF word[2]: tile code[14:0] (0 = skip) word[3]: flipX[0], flipY
rtl/asuka/asuka_sprite_renderer.sv:45 0 = MAME : fotografia al filo `snap` del top, lo stesso clock in cui parte l'IRQ di vblank e il chip dei tile ferma scroll e tabelle -> niente scivolamento.
rtl/asuka/asuka_sprite_renderer.sv:51 Impulso di un clock dal top: in modo MAME fa partire la copia.
rtl/asuka/asuka_sprite_renderer.sv:53 1 = il PC090OJ di questa scheda ha il buffer (MAME set_usebuffer(true): config cadash e asuka).
rtl/asuka/asuka_sprite_renderer.sv:54 MAME disegna il quadro N con lo scroll di N e gli sprite copiati al vblank N-1: il renderer legge la copia del vblank precedente, la cascata di Raiden (raiden_sprite_mainbus.sv).
rtl/asuka/asuka_sprite_renderer.sv:65 X offset (scroll-dependent, from MAME draw_sprites x_offs parameter)
rtl/asuka/asuka_sprite_renderer.sv:95 PC090OJ sprite_colbank ($080000 write, MAME asuka.cpp:475): sprite_colbank = (sprite_ctrl & 0x3C) << 2 = top 4 bit di color 8-bit
rtl/asuka/asuka_sprite_renderer.sv:99 Non e' il registro del TC0100SCN: il PC090OJ ha il suo, la parola 0xdff della sprite RAM, ed e' attivo quando il bit 0 vale ZERO (pc090oj.cpp:199).
rtl/asuka/asuka_sprite_renderer.sv:126 y_offs = -8 from MAME + north adjust
rtl/asuka/asuka_sprite_renderer.sv:141 frozen = fotografia di questo filo (scritta dalla copia) frozen2 = quello che legge SEMPRE il renderer: buffer acceso (MAME) -> il vecchio contenuto di frozen, cioe' la fotografia del filo precedente (cascata); altrimenti -> lo s
rtl/asuka/asuka_sprite_renderer.sv:340 Priority mask MAME bit3 attr "unknown priority": pixel scritto da sprite con attr[3]=1 → prio_lb=1, vince anche su pixel gia' scritti da sprite con attr[3]=0.
rtl/asuka/asuka_sprite_renderer.sv:438 scn_sc[T+2] = pixel render_x[T] = render_x[T+2] - 2 (chip MAME stessa pipeline).
rtl/asuka/asuka_sprite_renderer.sv:461 Layout identico a TC0100SCN tile decoder (MAME gfx_8x8x4_packed_msb su half-row 4 byte).
rtl/asuka/asuka_sprite_renderer.sv:520 I numeri: dritto y = grezzo + 8 - 16 + yoff = grezzo - 8 + yoff capovolto y = (256 - grezzo - 16 + 2) + 8 - 16 - yoff = 234 - grezzo - yoff dove il 256-16 e' pc090oj.cpp, il +2 e' la riga che si sta preparando (una avanti), e yoff cam
rtl/asuka/asuka_sprite_renderer.sv:675 Cadash PC090OJ (pc090oj.cpp:193-208): y = m_ram_buffered[offs+1] & 0x1FF if (y > 0x140) y -= 0x200 // signed convert y += m_y_offset (=8 per Cadash, set_offsets(0,8)) cliprect.top = 16 (asuka.cpp:1248 visarea Y=16..255) → MAME render_y sc
rtl/asuka/asuka_sprite_renderer.sv:687 [FLIP] pc090oj.cpp:201-204: capovolto, y = 256 - y - 16, prima degli offset del chip.
rtl/asuka/asuka_sprite_renderer.sv:714 Cadash PC090OJ (pc090oj.cpp:192-207): x = m_ram_buffered[offs+3] & 0x1FF if (x > 0x140) x -= 0x200 // signed convert x += m_x_offset (=0 per Cadash)
rtl/asuka/asuka_sprite_renderer.sv:721 [FLIP] pc090oj.cpp:201-204: capovolto, x = 320 - x - 16.
rtl/asuka/asuka_sprite_renderer.sv:740 [FLIP] pc090oj.cpp:203-204: capovolto lo schermo, i flip del singolo sprite si rovesciano.
rtl/asuka/asuka_sprite_renderer.sv:746 MAME color = (attr & 0x0F) | sprite_colbank sprite_colbank = (ctrl & 0x3C) << 2 = bits[7:4] del color 8-bit fifo_color e' 7-bit → uso colbank[6:4] hi + attr[3:0] lo
rtl/asuka/asuka_sprite_renderer.sv:770 [FLIP] pc090oj.cpp:203-204: capovolto lo schermo, i flip del singolo sprite si rovesciano.
rtl/asuka/asuka_sprite_renderer.sv:776 MAME color = (attr & 0x0F) | sprite_colbank sprite_colbank = (ctrl & 0x3C) << 2 = bits[7:4] del color 8-bit fifo_color e' 7-bit → uso colbank[6:4] hi + attr[3:0] lo
rtl/asuka/asuka_sprite_renderer.sv:830 Lancia req ROM direttamente in RD_POP (mask 14-bit MAME drawgfx)
rtl/asuka/asuka_sprite_renderer.sv:994 Cadash xBGR444 → RGB888 (MAME color_xbgr444 asuka.cpp:484) R = data[3:0], G = data[7:4], B = data[11:8]
rtl/asuka/asuka_sprite_renderer.sv:1005 sprite_ob combinatorio da spr_disp_word (già registrato 1 clk da line buffer), allineato a scn_sc (anche registrato 1 clk dal chip MAME).
rtl/asuka/asuka_top.sv:78 MAME SYSTEM port: {00,start2,start1,tilt,service,coin2,coin1}
rtl/asuka/asuka_top.sv:80 Ingressi del C-Chip (solo Bonze): le tre porte GPIO del uPD78C11 piu' le linee AN, gia' composte in Template.sv come le vuole MAME.
rtl/asuka/asuka_top.sv:86 0 = MAME (scroll fermato a ogni quadro), 1 = scheda vera (scroll dal vivo).
rtl/asuka/asuka_top.sv:105 SCN rate selector rimosso — SCN ora usa ce_13m fisso (13.33 MHz, MAME-accurate).
rtl/asuka/asuka_top.sv:359 Da QUESTO filo, e da nessun'altra formula, escono: - l'IRQ di vblank (gen_vblank_irq qui sotto); - in modo MAME: il fermo degli otto registri del TC0100SCN, la copia delle tabelle di rowscroll/colscroll, il fermo del registro sprite; - in m
rtl/asuka/asuka_top.sv:364 E' Raiden (IRQ, copia sprite e latch dello scroll sullo stesso vblank_rising) ed e' MAME, che al vblank disegna tutto il quadro in un istante PRIMA che la CPU prenda l'IRQ.
rtl/asuka/asuka_top.sv:396 In modo MAME anche questo registro (banco colore, priorita') e' fermo al filo: MAME lo legge nell'istante in cui disegna.
rtl/asuka/asuka_top.sv:402 [FLIP] Il PC090OJ ha un SECONDO registro, che non sta sul bus ma dentro la sprite RAM: la parola 0xdff (pc090oj.cpp:154, "Bit 0 is flip control").
rtl/asuka/asuka_top.sv:405 Il bit e' attivo BASSO: sprite capovolti quando vale zero (pc090oj.cpp:199).
rtl/asuka/asuka_top.sv:406 All'accensione MAME parte da zero e il gioco lo scrive subito, e qui si fa uguale per non inventare uno stato che sul chip non c'e'.
rtl/asuka/asuka_top.sv:415 Fermo al filo come tutto il resto in modo MAME: il capovolgimento non puo' cambiare a meta' quadro mentre lo sfondo sta gia' disegnando col suo.
rtl/asuka/asuka_top.sv:420 sprite_colbank = (sprite_ctrl & 0x3C) << 2 (MAME fixed_colpri_cb asuka.cpp:475)
rtl/asuka/asuka_top.sv:496 --- VBlank IRQ4 + IRQ5 timer (Cadash: MAME asuka.cpp:522-532) --- IRQ4 = immediato a rising-edge VBlank.
rtl/asuka/asuka_top.sv:502 Tabella dei set del driver (MAME asuka.cpp).
rtl/asuka/asuka_top.sv:538 PC090OJ con buffer (MAME set_usebuffer(true)): config 'cadash' (asuka.cpp:1255) e config 'asuka' (asuka.cpp:1186), cioe' Cadash, Asuka, Galmedes, Earth Joker.
rtl/asuka/asuka_top.sv:586 Sul 68000 il riconoscimento spegne solo la linea servita: l'altra resta pendente e viene presa dopo (MAME fa lo stesso con HOLD_LINE).
rtl/asuka/asuka_top.sv:697 Main CPU clock divider (96MHz / den) clk_sel = 0 e' AUTOMATICO PER GIOCO: nel driver il 68000 non gira alla stessa velocita' su tutte le schede (MAME asuka.cpp).
rtl/asuka/asuka_top.sv:700 Cadash XTAL 32 MHz / 2 = 16 MHz (asuka.cpp:1222)
rtl/asuka/asuka_top.sv:701 tutte le altre XTAL 16 MHz / 2 = 8 MHz (asuka.cpp:1156)
rtl/asuka/asuka_top.sv:765 Il 68000 lo vede a 800000-800FFF, un byte ogni parola (MAME: umask 0x00ff), quindi l'indirizzo del chip e' main_bus_addr[11:1].
rtl/asuka/asuka_top.sv:922 --- TC0220IOC (Cadash, asuka.cpp:647 — 8 byte direct address) ---
rtl/asuka/asuka_top.sv:967 Il 68000 la vede dalla Port A a $800000-$800FFF, un byte per word (byte nella meta' bassa: MAME fa `m_shared_ram[offset] = data & 0xff`), quindi allo Z180 basta la corsia LO.
rtl/asuka/asuka_top.sv:1038 PHI dello Z180 = 8 MHz (MAME: HD64180RP clock=8000000).
rtl/asuka/asuka_top.sv:1499 --- CPU → TC0100SCN chip selects --- MAME cadash_state::main_map (asuka.cpp:638): $C00000-$C0FFFF → SCN RAM $C20000-$C2000F → SCN ctrl
rtl/asuka/asuka_top.sv:1514 PC060HA sound comm (Cadash, asuka.cpp:643): $0C0001 = master_port_w $0C0003 = master_comm_r/w Già gestito da pc060ha_link a $C00000-$C00003 (vecchio Darius2 path C00000), ma su Cadash è $0C0000-$0C0003.
rtl/asuka/asuka_top.sv:1642 MAME TC0100SCN wide mode: 0x00000-0x0FFFF = SCE0 (64KB = 32K word), 0x10000-0x13FFF = SCE1 (16KB = 8K word).
rtl/asuka/asuka_top.sv:1751 Port B fetch: il chip MAME emette vram_b_addr[15:0] (bit 15 = main/ext).
rtl/asuka/asuka_top.sv:1803 TC0100SCN bindings (chip MAME guida dout/dack/SC/rom; legacy wire tied-off)
rtl/asuka/asuka_top.sv:1809 CPU path: redirigi dout/dack dal chip MAME
rtl/asuka/asuka_top.sv:1820 Port B VRAM legacy tied-off (chip MAME guida via scn_m0_vram_b_addr)
rtl/asuka/asuka_top.sv:1841 MAME-model TC0100SCN instances (3×) — PARALLEL with Donlon for now.
rtl/asuka/asuka_top.sv:1843 In Step 3 Donlon will be disconnected and MAME will drive SC, rom_req, etc.
rtl/asuka/asuka_top.sv:1854 MAME chip signals (single chip)
rtl/asuka/asuka_top.sv:1920 Palette chip selects (from MAME darius2_master_map) TC0110PCR: $A00000-$A0000F su Cadash, $200000-$20000F su asuka_map
rtl/asuka/asuka_top.sv:2019 Priorita' sprite/tile: nel driver e' GLOBALE, decisa una volta per frame dal callback che riceve sprite_ctrl (MAME asuka.cpp:467-477), non per sprite.
rtl/asuka/asuka_top.sv:2078 Il TC0110PCR e' lo stesso, ma il driver lo legge in due modi diversi (MAME asuka.cpp:479-487):
rtl/asuka/asuka_top.sv:2084 L'espansione a 8 bit replica i bit alti (4'hF -> 8'hFF, 5'h1F -> 8'hFF), che e' quello che fanno pal4bit/pal5bit di MAME.
rtl/asuka/asuka_top.sv:2234 Gli sprite uscivano un pixel piu' a destra di MAME (visto su Bonze Adventure).
rtl/asuka/mame_warning_overlay.sv:22 mame_warning_overlay.sv — testo statico "DON'T BREAK YOUR WOOFER!" che appare per ~3 secondi quando l'utente attiva PSG=MAME nell'OSD audio mixer.
rtl/asuka/msm5205.sv:8 Fedele a MAME src/devices/sound/msm5205.cpp:
rtl/asuka/msm5205.sv:62 --- ampiezza del passo, a troncamenti separati come MAME -----------------
rtl/asuka/pc060ha_link.sv:25 Single-clock rewrite ispirato a jtrastan_pc060 (JTCORES by Jose Tejada), implementato secondo la descrizione di pc060ha_device in MAME.
rtl/asuka/tc0040ioc.sv:14 In MAME è un singolo chip con un solo m_port register.
rtl/asuka/tc0110pr.sv:110 MAME chip behaviour: cpu_mode only closes on explicit VA=10.
rtl/asuka/tc0110pr.sv:132 Priority MAME ninjaw (draw_sprites + primask): sprite prio 0 (OB[13]=0): sotto FG, sopra tutto il resto sprite prio 1 (OB[13]=1): sotto FG, sotto MID layer, sopra BOTTOM SC[14:13] dal chip MAME tc0100scn codifica il RUOLO del layer visibile
rtl/asuka/tc0110pr.sv:154 layer BG "top" → MAME mid
rtl/asuka/tc0140syt.sv:112 MAME ninjaw usa NMI per svegliare Z80 al ricevimento comando audio.
rtl/asuka/tc0220ioc.sv:10 MAME (taitoio.cpp:14-29): $00 R IN00-07 (DSWA) $00 W watchdog reset $01 R IN08-15 (DSWB) $02 R 1P inputs $02 W init / unknown $03 R 2P inputs $04 RW coin counters/lockout $05 W unknown $06 W unknown $07 R coin inputs
rtl/asuka/tc_mame/tc0100scn_cadash.sv:1 tc0100scn_cadash.sv — TC0100SCN Cadash dedicated, MAME-faithful.
rtl/asuka/tc_mame/tc0100scn_cadash.sv:3 Reference: MAME tc0100scn.cpp (Nicola Salmoria) + asuka.cpp (Cadash setup).
rtl/asuka/tc_mame/tc0100scn_cadash.sv:5 Cadash hardware: - Single-width tilemaps (no dual width) - 8x8x4 packed_msb BG tiles from external ROM - 2bpp FG text chars from internal VRAM word $3000-$37FF - VRAM layout (single): $0000-$1FFF BG0 tilemap (64×64 tile, 2 word/tile: attr+c
rtl/asuka/tc_mame/tc0100scn_cadash.sv:22 MAME tile_info (tc0100scn.cpp:400-401): code = m_ram[(2*tile_index) + 1 + Offset] ← word DISPARI attr = m_ram[(2*tile_index) + Offset] ← word PARI
rtl/asuka/tc_mame/tc0100scn_cadash.sv:79 Fotografia del quadro (modo MAME).
rtl/asuka/tc_mame/tc0100scn_cadash.sv:88 1 = MAME (fotografia), 0 = PCB (vivo)
rtl/asuka/tc_mame/tc0100scn_cadash.sv:141 MAME: Cadash fa set_offsets(1, 0) (asuka.cpp:1260); la famiglia asuka (Asuka & Asuka, Galmedes, Earth Joker, Maze of Flott) lascia il default (0, 0).
rtl/asuka/tc_mame/tc0100scn_cadash.sv:146 asuka.cpp:1248 visarea(0,319,16,255)
rtl/asuka/tc_mame/tc0100scn_cadash.sv:149 MAME tc0100scn.cpp:273-274: set_scrolldx(xd-16, ...), set_scrolldy(yd, ...) m_dx = xd-16 = -17.
rtl/asuka/tc_mame/tc0100scn_cadash.sv:155 VRAM bases (single-width, MAME tc0100scn.cpp:249-256, 442-444, 306)
rtl/asuka/tc_mame/tc0100scn_cadash.sv:165 Control registers (8 word, $C20000-$C2000F) MAME tc0100scn.cpp:454-472 (restore_scroll): ctrl[0] = BG0 scrollx, ctrl[1] = BG1 scrollx, ctrl[2] = FG0 scrollx ctrl[3] = BG0 scrolly, ctrl[4] = BG1 scrolly, ctrl[5] = FG0 scrolly ctrl[6] = layer
rtl/asuka/tc_mame/tc0100scn_cadash.sv:174 Fermo degli otto registri al clock di snap (solo modo MAME).
rtl/asuka/tc_mame/tc0100scn_cadash.sv:327 [FLIP] Schermo capovolto (ctrl[7] bit 0, tc0100scn.cpp:466).
rtl/asuka/tc_mame/tc0100scn_cadash.sv:412 Richiesta di fotografia delle tabelle: si alza al clock di snap (modo MAME), si abbassa quando la macchina entra nella copia.
rtl/asuka/tc_mame/tc0100scn_cadash.sv:460 MAME tilemap library standard (BG0): set_scrollx((j + bgscrolly) & 0x1ff, ...).
rtl/asuka/tc_mame/tc0100scn_cadash.sv:554 MAME BG1 path = tilemap_draw_fg custom, rowscroll j = (y_abs + scrolly_delta) & 0x1ff = (render_y + cliprect.top - m_dy) = render_y + 16 - 8 = render_y + 8 = render_y + SCROLLDY.
rtl/asuka/tc_mame/tc0100scn_cadash.sv:566 MAME tc0100scn.cpp:639-649: src_y_initial = fgscrolly + scrolly_delta + cliprect.top, scrolly_delta = -m_dy.
rtl/asuka/tc_mame/tc0100scn_cadash.sv:579 Col scroll per-tile (MAME tc0100scn.cpp:656)
rtl/asuka/tc_mame/tc0100scn_cadash.sv:718 SC output from line buffers MAME tilemap_draw: bottom layer opaque, then top BG, then FG.
rtl/asuka/tc_mame/tc0100scn_cadash.sv:766 MAME default (ctrl[6][3]=0): BG0 is bottom (bottomlayer=0), BG1 is top
rtl/asuka/tc_mame/tc0100scn_mame.sv:22 tc0100scn_mame.sv — TC0100SCN, MAME-accurate scanline renderer.
rtl/asuka/tc_mame/tc0100scn_mame.sv:24 Reference: MAME tc0100scn.cpp + ninjaw.cpp (Darius 2).
rtl/asuka/tc_mame/tc0100scn_mame.sv:25 Scroll math, tile lookup, pixel decode follow MAME exactly.
rtl/asuka/tc_mame/tc0100scn_mame.sv:33 MAME VRAM layout (wide mode, word offsets): $0000-$3FFF BG0 attrib+code (128×64 tiles, 2 words/tile) $4000-$7FFF BG1 attrib+code (128×64 tiles, 2 words/tile) $8000-$81FF BG0 row scroll (256 words) $8200-$83FF BG1 row scroll (256 words)
rtl/asuka/tc_mame/tc0100scn_mame.sv:53 0 = primo chip, 1 = chip successivi (flag MAME)
rtl/asuka/tc_mame/tc0100scn_mame.sv:121 Cadash (asuka.cpp).
rtl/asuka/tc_mame/tc0100scn_mame.sv:121 Formula MAME (tc0100scn.cpp:285-286): xd = -m_x_offset - m_multiscrn_xoffs; → Cadash: x_offset=1 → xd=-1 yd = 8 - m_y_offset; → Cadash: y_offset=0 → yd=8 MAME visarea Cadash (asuka.cpp:1248): visarea(0,319,16,255) clipre
rtl/asuka/tc_mame/tc0100scn_mame.sv:136 Cadash sempre single-width (asuka.cpp non chiama set_dblwidth, m_dblwidth=0).
rtl/asuka/tc_mame/tc0100scn_mame.sv:145 VRAM bases CADASH SINGLE-WIDTH (MAME tc0100scn.cpp:31-41).
rtl/asuka/tc_mame/tc0100scn_mame.sv:146 Layout word offset (m_ram[] u16 array): $0000-$1FFF BG0 (64×64 tile, 2 word/tile = 8K word) $2000-$3FFF FG0 tilemap (64×64, 1 word/tile) $3000-$3FFF FG0 gfx (256 char × 8 row × 2 plane = 4K word) [overlap mapping MAME] $4000-$5FFF BG1 (
rtl/asuka/tc_mame/tc0100scn_mame.sv:358 BUG3 fix: Row scroll index MAME (tc0100scn.cpp:623).
rtl/asuka/tc_mame/tc0100scn_mame.sv:359 MAME mappa j-esimo rowscroll_ram a tilemap row (j + bgscrolly).
rtl/asuka/tc_mame/tc0100scn_mame.sv:409 MAME lo fa internamente nel gfx_element (drawgfx code % elements()).
rtl/asuka/tc_mame/tc0100scn_mame.sv:439 BUG3 fix: BG1 rowscroll index = (rline - SCROLLDY) & 0x1ff (MAME).
rtl/asuka/tc_mame/tc0100scn_mame.sv:457 Col scroll per-tile (MAME tc0100scn.cpp:656): column_offset = colscroll_ram[src_x/8]; src_y_tile = line_sy - column_offset.
rtl/asuka/z180/cadash_link_z180.sv:18 Mappa dello Z180 (MAME asuka.cpp, cadash_state::sub_map):
rtl/asuka/z180/cadash_link_z180.sv:23 La RAM condivisa vista dai due lati (MAME asuka.cpp:709-723): $8000 'M' (0x4D) = questa scheda e' MASTER, altro = SLAVE $8002 'T' se sta trasmettendo, 'R' se sta ricevendo $8080-$80FF dati SLAVE (= $800100 lato 68000) $8100-$817F dati
rtl/asuka/z180/cadash_link_z180.sv:29 Il 68000 la vede a $800000-$800FFF, un byte per word (per questo MAME fa `data & 0xff`): word N del 68000 <-> byte N dello Z180.
README.md:3 FPGA core for the Taito hardware behind **Asuka & Asuka** — the family MAME collects in `asuka.cpp` — targeting the [MiSTer FPGA](https://github.com/MiSTer-deve
README.md:16 The core reimplements the hardware in SystemVerilog from the MAME driver, read line by line — every non-obvious fact in the RTL carries its `asuka.cpp:<line>` c
README.md:122 **Volume controls** for FM and ADPCM, and a MAME-compatible PSG mode.
README.md:134 At the vblank MAME draws the whole frame in one instant, *before* the 68000 enters the interrupt handler.
README.md:266 **David Graves** and **Brian Troha**, authors of MAME's `asuka.cpp`, with thanks to **Richard Bush**, and the **MAMEDev team** — memory maps, raster timing, gra
README.md:270 **Jonathan Gevaryahu** and **David Haywood** for MAME's C-Chip device, the reference the chip's behaviour was checked against.

Says it matches, follows or was checked against MAME — 3

Template.sv:348 Provato: forzando FF sull'IN2 di MAME si riproduce esatto lo schermo nero e muto, col programma che resta in $14xx come sulla MiSTer.
rtl/asuka/asuka_sprite_renderer.sv:467 Formula uguale al chip tile MAME: lat_gfx32 con byte-pair swap, base con bit scramble.
rtl/asuka/sdram_bridge.sv:266 Word-swap concat (SIM-verified MAME-compliant).

Shares text with the MAME driver without saying so — 9

rtl/asuka/asuka_audio_top.sv:247 MAME asuka.cpp:1202 ymsnd.port_write_handler().set_membank(m_audiobank).mask(0x03) — shares text with taito/asuka.cpp:1202
rtl/asuka/asuka_sprite_renderer.sv:96 sprite_colbank = (sprite_ctrl & 0x3C) << 2 = top 4 bit di color 8-bit — shares text with taito/asuka.cpp:469
rtl/asuka/asuka_sprite_renderer.sv:676 y = m_ram_buffered[offs+1] & 0x1FF — shares text with taito/pc090oj.cpp:193
rtl/asuka/asuka_sprite_renderer.sv:715 x = m_ram_buffered[offs+3] & 0x1FF — shares text with taito/pc090oj.cpp:192
rtl/asuka/asuka_top.sv:420 sprite_colbank = (sprite_ctrl & 0x3C) << 2 (MAME fixed_colpri_cb asuka.cpp:475) — shares text with taito/asuka.cpp:469
rtl/asuka/asuka_top.sv:969 `m_shared_ram[offset] = data & 0xff`), quindi allo Z180 basta la corsia LO. — shares text with taito/asuka.cpp:584
rtl/asuka/tc_mame/tc0100scn_cadash.sv:23 code = m_ram[(2*tile_index) + 1 + Offset] ← word DISPARI — shares text with taito/tc0100scn.cpp:402
rtl/asuka/tc_mame/tc0100scn_cadash.sv:24 attr = m_ram[(2*tile_index) + Offset] ← word PARI — shares text with taito/tc0100scn.cpp:403
rtl/asuka/tc_mame/tc0100scn_mame.sv:122 xd = -m_x_offset - m_multiscrn_xoffs; → Cadash: x_offset=1 → xd=-1 — shares text with taito/tc0100scn.cpp:287

TaitoF2#
Cameltry, Dead Connection, Dino Rex, Don Doko Don …
MiSTer-devel/Arcade-TaitoF2_MiSTer @ 664dbb74
MAME compared: taito/taito_f2.cpp + 19 related file(s)
Read: 43 HDL files, 29,921 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

36%

Statements: 1 toward MAME

Cites MAME source — 1

rtl/jt10_auto_ss.sv:8094 same values as in MAME

TaitoSJ#
Adventure Canoe, Alpine Ski, Bio Attack, Elevator Action …
MiSTer-devel/Arcade-TaitoSystemSJ_MiSTer @ 121cf1d5
MAME compared: taito/taitosj.cpp + 5 related file(s)
Read: 15 HDL files, 4,162 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

57%

Statements: 22 toward hardware, 4 not counted

Cites hardware documentation that MAME's driver does not — 22

rtl/TaitoSJCore.v:573 $8000-$87FF RAM
rtl/TaitoSJ_objbus.v:97 C0=1: 74LS83 carry-in unconnected, floats HIGH on hardware + 1
rtl/TaitoSJ_objbus.v:125 Hardware: ~OBJRQ connects to ~MR (pin 1) of U83 74LS273, acting as asynchronous master reset.
rtl/mcu_glue.v:12 Schematic blocks: (1) UMCU_7A, UMCU_7B — 74LS74 Handshake flip-flops (2) UMCU_9, UMCU_13 — 74LS374 Data latches (3) UMCU_10, UMCU_11B/D — 74LS374 + 74LS191 Address latch/counter (4) UMCU_18A — 74LS74 Interrupt gating fli
rtl/mcu_glue.v:119 --- UMCU_15C (74LS00 NAND) → 74LS04 inverter = AND --- NAND(~RESET, ~ZLREAD) → NOT → ~CLR for UMCU_7A Equivalent: ~CLR_7A = ~RESET & ~ZLREAD
rtl/mcu_glue.v:161 --- UMCU_9 (74LS374) — MCU→Z80 data latch --- Captures PA on rising edge of ~68LWR
rtl/mcu_glue.v:169 --- UMCU_13 (74LS374) — Z80→MCU data latch --- Captures Z80 data bus on rising edge of ~ZLWRITE (end of write cycle) ~OE = ~68LRD (output enabled when MCU reads)
rtl/mcu_glue.v:183 --- UMCU_10 (74LS374) — upper address latch A[15:8] --- Captures PA on rising edge of ~UAL (PB7) — latches on deassert
rtl/mcu_glue.v:191 --- UMCU_21D (74LS08 AND) — counter clock --- CNT_CLK = ~68WRITE & ~68READ
rtl/mcu_glue.v:195 --- UMCU_11B + UMCU_11D (74LS191 x2) — lower address counter A[7:0] --- ~PL = ~LAL (PB6), CLK = cnt_clk, D/~U = GND (count UP)
rtl/mcu_glue.v:208 (4) ~MCPUINT Interrupt Gating Circuit (from schematic image)
rtl/mcu_glue.v:210 Signal flow: UMCU_23A (OR): ~CPUM1 | ~CPUIORQ UMCU_23D (OR): ~68INTAK(~Q of 18A) | UMCU_23A_out UMCU_23B (OR): ~68INTRQ(PB2) | Q_18A ← Q feeds back from 18A UMCU_21B (AND): UMCU_23B_out & UMCU_23D_out = ~68IVR (clock for 18A)
rtl/mcu_glue.v:222 UMCU_23A (74LS32 OR): ~CPUM1 | ~CPUIORQ
rtl/mcu_glue.v:225 UMCU_23D (74LS32 OR): ~68INTAK(~Q of U18A) | UMCU_23A_out
rtl/mcu_glue.v:228 UMCU_23B (74LS32 OR): ~68INTRQ(PB2) | Q_18A
rtl/mcu_glue.v:231 UMCU_21B (74LS08 AND): ~68IVR = UMCU_23B_out & UMCU_23D_out
rtl/mcu_glue.v:254 UMCU_17D (74LS241 non-inverting buffer) on ~CPUINT: ~CPUINT → buffer → AND input (no polarity change) In FPGA: cpuint_n IS ~CPUINT, buffer is just a wire
rtl/mcu_glue.v:259 UMCU_21A (74LS08 AND): ~Q_18A (pin 6) & buffered ~CPUINT (pin 1) Output = ~MCPUINT
rtl/mcu_glue.v:266 (5) Status Buffer — UMCU_20B (74LS367)
rtl/mcu_glue.v:276 UMCU_16 (74LS245)
rtl/ttl_chips.v:57 74LS107 Chip pinout:
rtl/ttl_chips.v:102 74LS139 Chip pinout:

Cites hardware references or measurements that MAME's driver also gives — 4

rtl/mcu_glue.v:124 --- UMCU_7A (74LS74) — MCU→Z80 data available --- D = VCC, CLK = ~68LWR rising, ~CLR = clr_7a_n, ~PRE = VCC Q7A: 1 = MCU has written data for Z80 — also in MAME: 74LS74 taito/taitosj.h:104
rtl/mcu_glue.v:135 --- UMCU_7B (74LS74) — Z80→MCU data available --- D = GND, CLK = ~68LRD rising, ~CLR = ~RESET, ~PRE = ~ZLWRITE Q7B: 1 = Z80 has written data for MCU ~Q7B: 68ACCEPT (0 = data pending, interrupts MCU) — also in MAME: 74LS74 taito/taitosj.h:104
rtl/mcu_glue.v:234 --- UMCU_18A (74LS74) — interrupt gating toggle flip-flop --- D = ~Q (pin 2 tied to pin 6 on PCB), CLK = ~68IVR rising, ~PRE = VCC, ~CLR = ~RESET This makes it a toggle: each ~68IVR rising edge flips the state. — also in MAME: 74LS74 taito/taitosj.h:104
rtl/ttl_chips.v:6 74LS74 Chip pinout: — also in MAME: 74LS74 taito/taitosj.h:104

Tank#
Tank / Tank Cocktail
MiSTer-devel/Arcade-Tank_MiSTer @ 01b88927
MAME compared: atari/atarittl.cpp + 6 related file(s)
Read: 19 HDL files, 4,404 lines (Quartus project)

MiSTer official

Both

low

60%

Statements: 25 toward hardware, 25 toward MAME

Cites hardware documentation that MAME's driver does not — 25

rtl/game/tank_collision_hw.sv:17 The schematic shows two separate 6-bit counters; the netlist ties SCR1E and SCR2C to one D11 pin and swaps E11's CP0 / CP1.
rtl/game/tank_controls_hw.sv:105 (MAME's 7492 model swaps QB and QD on the pins, which makes its TM1 come in bursts of three; the 7492A datasheet and the schematic's pin labels give the even 1-in-6.)
rtl/game/tank_motion.sv:22 MAME's netlist takes HD1 / HD2 from 7474 pin 5 (Q) where the schematic uses pin 6 (Q-bar).
rtl/game/tank_shells.sv:11 IC_C9, the white tank's shell (netlist SHELL1): FIRE: the FIRE1_ADJUST 50k pot and C11 47 uF.
rtl/game/tank_shells.sv:36 The netlist's SHELL1 (IC_C9) is the white tank, which is the core's tank 2, so the pot sets core shell 2 and core shell 1 (black) gets the fixed 1.0784 s.
rtl/tank_core.sv:8 IC names (IC_xx) follow the Board I / II schematics and MAME's netlist (nl_tank.cpp).
rtl/tank_core.sv:12 The netlist numbers them the other way round (its TANK1 is the white tank); the screen matches the cabinet.
rtl/tank_core.sv:335 Where a shell appears (measured on the netlist): its 16 x 16 window starts at the tank's window + 1 clock, and the visible 4 x 4 shell is at columns 4-7, rows 8-11 of it.
rtl/tank_core.sv:493 (MAME's 7492 model maps pin 8 to QC, the 7490 / 7493 layout; the 7492A datasheet and the schematic put QD on pin 8.) tank_controls_hw keeps a twin of this counter for TM1, the chip's other output; both count the same frame_pulse.
rtl/tank_core.sv:554 The machine boots with ~2 s of both tanks flashing and firing locked out (measured in the full MAME netlist).
rtl/tank_core.sv:610 MAME's netlist leaves this switch out (it is wired as 25c).
rtl/tank_core.sv:656 (MAME's netlist leaves Q2.C and Q3.B unconnected, so GNE never asserts there.)
rtl/tank_core.sv:805 Outputs (the white tank is the core's tank 2, the netlist's TANK1): B10 (R5V 1k, sources on white-tank pixel) = is_tank2
rtl/video/blast_object.sv:23 MAME's netlist differs for BLAST1: it wires K3.5 to K3.3 (the tank-shape XOR) instead of K2.3, so its player 1 explosion carries the tank shape.
rtl/video/blast_object.sv:25 The core follows the schematic for both.
rtl/video/playfield.sv:5 The 2 KB ROM (90-2006, MK28000 at K10, drawn as IC_R10 in the netlist) is read through five 74153 muxes (IC_D9/E9/J9/H9/F9).
rtl/video/shell_object.sv:11 This module draws that block at (x, y); tank_video.sv puts the explosion window at (x - 4, y - 8) to match (checked on the netlist at 128 positions per player).
README.md:8 It was built from the Board I / Board II schematics and the Kee Games operator and service manuals, with MAME's Tank netlist as a cross-check.
README.md:10 Where the netlist and the schematics disagree, the core follows the schematics.
README.md:96 The parts below follow the schematics:
README.md:128 Where MAME's netlist differs
README.md:130 MAME's Tank netlist was the cross-check throughout.
README.md:130 Where it disagreed with the schematics, the core follows the schematics; examples are the score counter wiring, an output pin of the HD1 / HD2 flip-flops, and t
README.md:144 Each part was checked by simulation against the schematics and against measurements of the corrected MAME netlist before it counted as done.
README.md:153 | Analogue timings and levels | Measured in `nltool` on the corrected netlist with MAME's device models; datasheet timing for the DM9602 |

Cites MAME source — 25

Arcade-Tank.sv:188 Only the first 2 KB are written: MAME's tankii set is the same image plus one trailing 0xFF byte, which would wrap onto ROM[0].
rtl/game/tank_collision_hw.sv:4 The board's collision network (nl_tank.cpp gate names), on clk_pix with synchronous strobes in place of the board's gated and asynchronous latch clocks:
rtl/game/tank_controls_hw.sv:4 The board's control chain per tank: lever decode (IC_E15 / D15 NOR gates), rotation counter (74193 + 74107), speed counter (7493) and step divider (9316), with the gate equations of nl_tank.cpp.
rtl/game/tank_controls_hw.sv:105 (MAME's 7492 model swaps QB and QD on the pins, which makes its TM1 come in bursts of three; the 7492A datasheet and the schematic's pin labels give the even 1-in-6.)
rtl/game/tank_controls_hw.sv:158 tank_ctrl_chain_hw - one tank's rotation, speed and step divider, on clk_pix with frame_pulse / tm1 enables (gate names from nl_tank.cpp).
rtl/game/tank_motion.sv:22 MAME's netlist takes HD1 / HD2 from 7474 pin 5 (Q) where the schematic uses pin 6 (Q-bar).
rtl/game/tank_shells.sv:6 Pulse widths use the DM9602 datasheet equation Tw = 0.32 * R * C * (1 + 0.7 / R[kOhm]) (MAME's 9602 model uses the 74123's constant instead, which gives different widths.)
rtl/tank_core.sv:8 IC names (IC_xx) follow the Board I / II schematics and MAME's netlist (nl_tank.cpp).
rtl/tank_core.sv:295 The fire-arm clear is the other tank's BLO_UP (nl_tank.cpp): shell 1: CLR = NOR(BLO_UP2, SRS1) (IC_N7 -> IC_A15.1) shell 2: CLR = NOR(BLO_UP1, SRS2) (IC_N7 -> IC_A15.13) A tank CAN fire while it is itself exploding: its own BLO_UP has n
rtl/tank_core.sv:493 (MAME's 7492 model maps pin 8 to QC, the 7490 / 7493 layout; the 7492A datasheet and the schematic put QD on pin 8.) tank_controls_hw keeps a twin of this counter for TM1, the chip's other output; both count the same frame_pulse.
rtl/tank_core.sv:515 Each half is a monostable with TRIGGER and RESET both on the hit signal HT*Q = NOR(HIT*, MTK*), and 1.8M / 1uF timing: Tw = R*C*ln(3) = 1.9775 s (measured on MAME's NE555 model) = 120 fields at 60.797 Hz.
rtl/tank_core.sv:554 The machine boots with ~2 s of both tanks flashing and firing locked out (measured in the full MAME netlist).
rtl/tank_core.sv:596 GAME TIMER AND COINS (IC_H6 555 timer, IC_E6 74107, coin gates IC_B6 / D6 / J6 / N6), measured in nltool on MAME's device models.
rtl/tank_core.sv:610 MAME's netlist leaves this switch out (it is wired as 25c).
rtl/tank_core.sv:656 (MAME's netlist leaves Q2.C and Q3.B unconnected, so GNE never asserts there.)
rtl/tank_core.sv:788 Levels measured in nltool with MAME's gate and 1N914 models, in volts:
rtl/video/blast_object.sv:23 MAME's netlist differs for BLAST1: it wires K3.5 to K3.3 (the tank-shape XOR) instead of K2.3, so its player 1 explosion carries the tank shape.
README.md:8 It was built from the Board I / Board II schematics and the Kee Games operator and service manuals, with MAME's Tank netlist as a cross-check.
README.md:128 Where MAME's netlist differs
README.md:130 MAME's Tank netlist was the cross-check throughout.
README.md:130 Where it disagreed with the schematics, the core follows the schematics; examples are the score counter wiring, an output pin of the HD1 / HD2 flip-flops, and t
README.md:134 Most circuit timings that depend on analogue parts were measured in MAME's netlist simulator, `nltool`, with the corrected netlist; the DM9602 one-shots that ti
README.md:144 Each part was checked by simulation against the schematics and against measurements of the corrected MAME netlist before it counted as done.
README.md:153 | Analogue timings and levels | Measured in `nltool` on the corrected netlist with MAME's device models; datasheet timing for the DM9602 |
README.md:219 **The MAME team**: the Tank netlist (`nl_tank.cpp`) and the `netlist` library and `nltool` simulator, the cross-check for the whole core.

TankBattalion#
Tank Battalion
MiSTer-devel/Arcade-TankBattalion_MiSTer @ 6b84ddca (matched by date)
MAME compared: namco/tankbatt.cpp + 2 related file(s)
Read: 10 HDL files, 3,521 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

18%

Statements: 6 toward hardware, 1 not counted

Cites hardware documentation that MAME's driver does not — 6

rtl/ttl_chips.v:1 74LS74 Chip pinout:
rtl/ttl_chips.v:52 74LS107 Chip pinout:
rtl/ttl_chips.v:141 74LS273 Chip pinout:
rtl/ttl_chips.v:183 74LS166 Chip pinout:
rtl/ttl_chips.v:225 74LS174 Chip pinout:
rtl/ttl_chips.v:263 74LS139 Chip pinout:

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/ttl_chips.v:92 74LS161 Chip pinout: — also in MAME: 74LS161 namco/tankbatt.cpp:363

Tecmo#
Back Fire, Gemini Wing, Argus no Senshi, Silk Worm
MiSTer-devel/Arcade-Tecmo_MiSTer @ 9b62284b
MAME compared: tecmo/tecmo.cpp
Read: 30 HDL files, 6,442 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

20%

Statements: 1 toward hardware

Ships hardware documentation files — 1

doc/rygar-schematic.pdf

Tempest#
Tempest
MiSTer-devel/Arcade-Tempest_MiSTer @ bcd5bf4d
MAME compared: atari/tempest.cpp + 2 related file(s)
Read: 38 HDL files, 16,447 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 13 toward hardware, 2 not counted

Cites hardware documentation that MAME's driver does not — 13

rtl/avg/avg_prom_core.vhd:106 On hardware, this is latched by the LS175 (6L, schematic p.25 Fig.1) from DVY10-DVY8, and drives the LS191 down-counter that gates additional fill-bit shifts into the timer at STROBE 1.
rtl/avg/avg_prom_core.vhd:115 GO flag (schematic p.24 Fig.3: 2E LS32 pin 8).
rtl/avg/avg_prom_core.vhd:137 Bin_scale shift mechanism at STROBE 1 (schematic p.25 Fig.1: Vector Scaling).
rtl/avg/avg_prom_core.vhd:261 /LATCH1 clears three chip groups (schematic p.23): 5F,5H (Fig.2): DVY0-7 async cleared to 0 5A,5B,5C (Fig.2): DVX0-11 async cleared to 0 3C (Fig.0): Z0-Z2 + DVX12 async cleared to 0 6H(DVY8-11) has /CLR=PR110 (not cleared here).
rtl/avg/avg_prom_core.vhd:298 STROBE0 + OP0=0 sets NORM (LS74 5K, p.24 Fig.0).
rtl/avg/avg_prom_core.vhd:309 STROBE 1 (action $D): SP adjust for JSR/RTS, or Vector Scaling (schematic p.25 Fig.1) for VCTR/SVEC.
rtl/avg/avg_prom_core.vhd:339 Scale (0111_SSS LLLLLLLL) SSS = bin_scale -> LS175 latch (6L) -> LS191 counter (6M) LLLLLLLL = linear_scale -> LF13201 DAC (schematic p.26)
rtl/avg/avg_prom_core.vhd:411 Schematic p.23 Fig.2: LS194 shift registers (3A-3D, 4A-4D) shift DVX/DVY left at 12 MHz, gated by ENORM.
rtl/avg/avg_prom_core.vhd:413 Schematic p.25 Fig.0: LS161 timer chain (1D/1C/1B/2B) shifts right simultaneously, filling from the top.
rtl/avg/avg_prom_core.vhd:454 Schematic p.25 Fig.1: Vector Scaling circuit.
rtl/avg/vector_drawer.vhd:54 Linear scale velocity multiplier (schematic p.26: LF13201 multiplying DAC).
rtl/tempest_mathbox.sv:6 Implements the microcoded processor shown on Tempest schematic Sheet 3B.
README.md:9 This core reconstructs the original machine from Atari's schematics.

Cites hardware references or measurements that MAME's driver also gives — 2

rtl/avg/avg_prom_core.vhd:62 Hardware: 136002-125 at D7. — also in MAME: 136002-125 atari/tempest.cpp:713
rtl/avg/avg_prom_core.vhd:111 PROM state machine signals (256x4 PROM 136002-125 at D7) — also in MAME: 136002-125 atari/tempest.cpp:713

TIAMC1#
Billiard, Gorodki, Konek-Gorbunok, Snezhnaja Koroleva …
MiSTer-devel/Arcade-TIAMC1_MiSTer @ 7d29fffd
MAME compared: ussr/tiamc1.cpp + 4 related file(s)
Read: 12 HDL files, 2,871 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 1 toward MAME

Cites MAME source — 1

README.md:5 All information taken from [mame/tiamc1.cpp](https://github.com/mamedev/mame/blob/master/src/mame/drivers/tiamc1.cpp).

TimePilot#
Time Pilot
MiSTer-devel/Arcade-TimePilot_MiSTer @ 97033775
MAME compared: konami/timeplt.cpp + 1 related file(s)
Read: 16 HDL files, 3,596 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

42%

Statements: 5 toward hardware

Cites hardware documentation that MAME's driver does not — 5

rtl/TimePilot_CPU.sv:133 Address decoding for Z80 Most of the decoding is handled by the Konami 526 (82S153 PLA) - instantiate an instance of this IC here
rtl/TimePilot_CPU.sv:332 Time Pilot has an additional 82S153 PLA labelled K528 that controls the vertical counter latch and is used to control the state of the Konami 082's vertical counter (active or high impedance as the vertical counter is directly connected to
rtl/TimePilot_SND.sv:315 Time Pilot's AY-3-8910s contain selectable low-pass filters with the following cutoff frequencies: 3386.28Hz, 723.43Hz, 596.09Hz Model this here (the PCB handles this via 3 74HC4066 switching ICs located at A2, A3 and A4)
rtl/custom/k526.sv:3 SystemVerilog implementation of the Konami 526, an 82S153 PLA used for address decoding on Time Pilot Converted from dump available at the PLD Archive http://wiki.pldarchive.co.uk/index.php?title=Time_Pilot Copyright (C) 2021 Ace
rtl/custom/k528.sv:3 SystemVerilog implementation of the Konami 528, an 82S153 PLA used for controlling the vertical counter outputs on Time Pilot's Konami 082 Converted from dump available at the PLD Archive http://wiki.pldarchive.co.uk/index.php?title=Time_Pi

TimePilot84#
Time Pilot '84
MiSTer-devel/Arcade-TimePilot84_MISTer @ 217aba83
MAME compared: konami/tp84.cpp + 1 related file(s)
Read: 14 HDL files, 7,758 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

18%

Statements: 2 toward hardware

Cites hardware documentation that MAME's driver does not — 2

rtl/TimePilot84_CPU.sv:198 Primary CPU ROMs (there is a 5th ROM socket on the original PCB at 6J, but is unpopulated) ROM 1/4
rtl/TimePilot84_SND.sv:287 Time Pilot '84's SN76489s contain selectable low-pass filters with the following cutoff frequencies: 3386.28Hz, 723.43Hz, 596.09Hz Model this here (the PCB handles this via a 74HC4066 switching IC located at C6)

TNKIII#
T.A.N.K
MiSTer-devel/Arcade-TNKIII_MiSTer @ bffd85ea
MAME compared: snk/snk.cpp + 2 related file(s)
Read: 80 HDL files, 9,424 lines (Quartus project)

MiSTer official

Mostly hardware

low

43%

Statements: 13 toward hardware, 2 toward MAME

Cites hardware documentation that MAME's driver does not — 12

rtl/clocks/A5001_1.v:1 Author: @RndMnkIII Date: 13/03/2022 Converted from ArmoredScrumObject_pal16r6a_3.jed using MAME's jedutil tool Many thanks to pldarchive.co.uk for the JED file.
rtl/clocks/TNKIIICore_Clocks_Sync.sv:199 74LS30 8-input positive NAND gate
rtl/cpuA_B/A5001_2.v:1 Author: @RndMnkIII Date: 22/05/2022 Derived from TNKIII schematics and ASO PAL.
rtl/final_video/A5001_3.v:1 A5001_3.v Author: @RndMnkIII Date: 23/05/2022 Derived from TNKIII schematics and ASO PAL.
rtl/front/TNKIIICore_LineBuffer_sync.sv:156 74LS20 4-input NAND gate
rtl/ttl/ttl_74107a_sync.v:1 74LS107A: Dual J-/K flip-flop with clear; negative-edge-triggered Inputs Outputs
rtl/ttl/ttl_74163a_sync.v:1 4-bit modulo 16 binary counter with parallel load, *** FOR SYNTHESIS *** Synchronous Reset (SRn) -> LS163A <START_TEMPLATE> ttl_74161a #(.DELAY_RISE(20), .DELAY_FALL(25)) <NAME> (.Clear_bar(), .Load_bar(), .ENT(), .ENP(), .D(), .Clk(), .RCO
rtl/ttl/ttl_74373.sv:1 ttl_74373.sv Octal D transparent latch function table, logic diagrams and switching characteristics extracted from TI 74LS373 Datasheet.
rtl/ttl/ttl_74374_sync.sv:1 ttl_74374_sync.sv Octal D edge triggered FF function table, logic diagrams and switching characteristics extracted from TI 74LS374 Datasheet.
rtl/ym3526/jtopl_exprom.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.
rtl/ym3526/jtopl_logsin.v:16 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.
rtl/ym3526/jtopl_op.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.

Ships hardware documentation files — 1

docs/TNKIII_schematics.pdf

Cites MAME source — 2

rtl/clocks/A5001_1.v:1 Author: @RndMnkIII Date: 13/03/2022 Converted from ArmoredScrumObject_pal16r6a_3.jed using MAME's jedutil tool Many thanks to pldarchive.co.uk for the JED file.
rtl/cpuA_B/TNKIIICore_CPU_A_B_sync.sv:521 ONLY WRITABLE VIDEO RELATED REGISTERS (TNKIII) 1 1 1 1 1 | 1 | Address: 5 4 3 2 1 | 0 9 8 | 7 6 5 4 3 2 1 0 16'hC800 1 1 0 0 1 | 0 0 0 | x x x x x x x x MSB 16'hC900 1 1 0 0 1 | 0 0 1 | x x x x x x x x FSX 16'hCA00

Toobin#
Toobin'
MiSTer-devel/Arcade-Toobin_MiSTer @ 0e9fe7b5
MAME compared: atari/toobin.cpp + 6 related file(s)
Read: 33 HDL files, 4,254 lines (Quartus project)

MiSTer official

Both

medium

70%

Statements: 40 toward hardware, 49 toward MAME

Cites hardware documentation that MAME's driver does not — 34

rtl/main/toobin_addr_decode.sv:17 Source: Atari SP-320 schematics (main CPU decode); MAME's toobin.cpp.
rtl/main/toobin_eeprom_2804.sv:8 Board behavior (SP-320 sheet 3): /UNLOCK presets 14M (74LS74).
rtl/main/toobin_inputs.sv:8 Toobin uses four independent paddle-direction pushbuttons per player plus a Throw Can button, which the game also uses as Start (SP-320 sheet 18 and the FF8800 switch word, all active-low):
rtl/main/toobin_irq_wd.sv:13 Watchdog (SP-320 sheet 2, 8L LS90): /VSYNC clocks a decade counter.
rtl/main/toobin_irq_wd.sv:17 Source: Atari SP-320 schematics; MAME's toobin.cpp; the System 1 core's TG68K IPL convention (rtl/lib/TG68K/TG68K.vhd).
rtl/main/toobin_irq_wd.sv:53 74LS90 decade behavior: FF8000 clears to zero; /VSYNC advances 0..9.
rtl/main/toobin_main_bus.sv:13 Source: Atari SP-320 schematics (main CPU decode).
rtl/video/toobin_alpha_render.sv:9 SP-320 sheet 6 is the electrical authority: D11 drives ANHFLIP, D9:0 select one of the 1024 characters, and D10 reaches only the optional ANROMA14/VPP socket pin.
rtl/video/toobin_mo_linebuf.sv:8 SP-320 sheet 13 selects the two physical line-buffer banks directly with 1V and /1V, so line_swap always changes banks; it is deliberately not completion-gated.
rtl/video/toobin_mo_linebuf.sv:90 ---- unconditional 1V/inverse-1V bank parity (SP-320 sheet 13) ----
rtl/video/toobin_mo_list.sv:16 Word fields (schematic sheet 6 latch wiring + MAME atarimo config -- the link lives in w2, NOT w0; w0[7:0] is ypos-low/size bits): w0: abs[15], ypos[14:6], height[5:3], width[2:0] w1: vflip[15], hflip[14], code[13:0] w2: link[7:0]
rtl/video/toobin_mo_list.sv:104 Link pointer comes from WORD 2 (schematic sheet 6: 17F link register is loaded from the C09804 word; MAME linkmask {{0,0,0x00ff,0}}).
rtl/video/toobin_pf_render.sv:69 Sheet 14 clocks HSCROLL on the following scanline.
rtl/video/toobin_priority.sv:6 This is the real PAL 7E equation, not a functional approximation.
rtl/video/toobin_priority.sv:8 136061-1151 (PAL16L8A at 7E) was bruteforced by Caius and tested on a board by gamefixer; the JEDEC is on PLD Archive as `Toobin_136061-1151`, dated 07/10/2019.
rtl/video/toobin_priority.sv:10 Decoded with MAME's jedutil as a gal16v8: simple mode, active-low outputs, only pins 13/14 driven.
rtl/video/toobin_priority.sv:11 Those two pins are the shared SB/SA select rails of the five 74F153 muxes that build the colour-RAM address (pin14 -> F153 pin 2 = B/msb, pin13 -> F153 pin 14 = A/lsb), whose data inputs are C0=playfield, C1=motion object, C2=alpha, C3=CPU
rtl/video/toobin_raster.sv:6 SP-320 sheets 5-6: 640x416 total, 512x384 visible, HSYNC 544-607, VSYNC 388-391.
rtl/video/toobin_video.sv:134 SP-320 sheet 13 selects the two line-buffer banks directly from 1V//1V, and the displayed bank's chip select is gated only by 16MHZD and that parity -- there is no BLANK/active-display term, and R107-R114 pull the data bus to the transparen
rtl/video/toobin_video.sv:138 (Corroborated by Atari SP-284's LINEBUF.vhd, whose address counter increments on every master clock with no active-display qualifier.)
rtl/video/toobin_vscroll_ctrl.sv:6 SP-320 sheet 14 latches BD14:6 as VS8:0 and feeds two cascaded LS163 counters clocked by /HSYNC.
README.md:7 The core reconstructs the original PCB — a 68010 main board plus an Atari JSA I sound board — from Atari's SP-320 schematic package, with MAME used as a functio
README.md:169 It applies where the SP-320 schematics document something MAME's model does not, and in three of the seven cases MAME's own source flags the gap.
README.md:175 | Pixel priority merge | `toobin.cpp` brackets it with `not verified: logic is all controlled in a PAL`: playfield pen bit 3 *gates* the merge, and the motion o
README.md:178 | Alpha character flip | `(data >> 10) & 1` taken as the flip bit | sheet 6 routes `ANHFLIP` to **D11**; D10 reaches only the optional `ANROMA14/VPP` socket pin
README.md:181 | JSA `/RDIO` D6 | JSA I and II comments say active low, JSA III says active high | resolved from the sheet 22 LS240 |
README.md:183 **The output filter is the largest of these.** Sheet 21 draws a unity-gain Sallen-Key 2nd-order low-pass around LM324 4A, and the core implements it with the va
README.md:193 **The priority merge is the one backed by a fuse dump.** PAL 7E on sheet 16, Atari part 136061-1151, was brute-forced from a real part and tested on a board, so
README.md:242 Video DAC — a 32-step voltage sweep per channel.** Sheet 16 shows an R/2R ladder *and* a 74F260 five-input NOR acting as an all-bits-zero detect, both feeding t
README.md:251 End-to-end audio transfer.** The `/MIX` Sallen-Key and the POKEY transimpedance pole are derived from sheet 21's component values, but the baseline response of
README.md:262 JSA `/RDIO` D6.** Resolved here from sheet 22's LS240, against MAME comments that contradict each other between JSA I/II and JSA III.
README.md:263 The JSA I stand-alone audio PCB (Atari A-043713) is shared with Blasteroids, Vindicators, Xybots and Skull & Crossbones, so **SP-316**, **SP-317** and **SP-313*
README.md:295 Thanks to the MAME team, whose `toobin.cpp`, `atarijsa` and `atarimo` code served as the functional oracle throughout, and to whoever preserved the Atari SP-320
README.md:299 Thanks also to **Caius**, who brute-forced the priority PAL (136061-1151) off a real board, to **gamefixer**, who tested the result on hardware, and to the **PL

Says it was checked on “real hardware” — 1

README.md:299 Thanks also to **Caius**, who brute-forced the priority PAL (136061-1151) off a real board, to **gamefixer**, who tested the result on hardware, and to the **PL

Notes where it differs from MAME — 5

rtl/video/toobin_priority.sv:27 Two structural differences from MAME's model (toobin.cpp screen_update, which notes its own merge is unverified), each confirmed against all 1024 fuse vectors: (a) a layer's pen bit 3 SELECTS which of that layer's two priority bits is comp
README.md:9 Where a schematic and MAME disagree, the schematic wins and the disagreement is recorded — see [Where this core differs from MAME](#where-this-core-differs-from
README.md:166 Where this core differs from MAME
README.md:169 It applies where the SP-320 schematics document something MAME's model does not, and in three of the seven cases MAME's own source flags the gap.
README.md:195 The two differ structurally: MAME treats playfield pen bit 3 as a gate that must be set before the playfield may cover a motion object, where the hardware uses

Cites MAME source — 39

Toobin.sv:91 MAME's INPUT_PORTS_START(toobin) has only the FF8800 controls and the FF9000 service/status word; every operator setting lives in the X2804 EEPROM and is changed from the game's own self-test.
rtl/main/toobin_addr_decode.sv:6 Faithful reproduction of MAME toobin.cpp `main_map` semantics: 1.
rtl/main/toobin_addr_decode.sv:17 Source: Atari SP-320 schematics (main CPU decode); MAME's toobin.cpp.
rtl/main/toobin_addr_decode.sv:40 Per-entry hits (start, end, mirror straight from toobin.cpp).
rtl/main/toobin_irq_wd.sv:6 Interrupts (MAME toobin.cpp, set_interrupt_mixer(false)): scanline compare -> IPL0 pin (weight 1); latched, set by the video `scanline_match` pulse, cleared by a write to FF83C0 (irqack).
rtl/main/toobin_irq_wd.sv:17 Source: Atari SP-320 schematics; MAME's toobin.cpp; the System 1 core's TG68K IPL convention (rtl/lib/TG68K/TG68K.vhd).
rtl/main/toobin_main_bus.sv:197 MAME's INPUT_PORTS (hblank=D13, ready=D15) has these two swapped; the old RTL shipped MAME's layout, so the send gate was actually polling raster timing.
rtl/toobin_core.sv:217 A single latch is written by every decoded FF8380 alias and read back (MAME models it readable); the renderer consumes [7:0].
rtl/video/toobin_char_rom.sv:7 Decode per MAME `anlayout` (8x8, 2bpp, planes {0,4}, x-offsets {0,1,2,3,8,9,10,11}, y*16), MSB-first bits: row y uses bytes A=tile*16+y*2 (pixels 0-3) and B=A+1 (pixels 4-7); pixel x in 0-3: {A[3-x], A[7-x]}; x in 4-7: {B[3-(x-4)], B[7-(x-
rtl/video/toobin_char_rom.sv:42 {pix7,pix6,...,pix0}, each pixel = {MSB=plane[0]@off0, LSB=plane[1]@off4} (MAME: planeoffset[0] is the most-significant pixel bit).
rtl/video/toobin_mo_gfx.sv:6 MAME `molayout`: 16x16, 4bpp, RGN_FRAC(1,2) (sprites region 2 MB => 1 MB halves).
rtl/video/toobin_mo_list.sv:16 Word fields (schematic sheet 6 latch wiring + MAME atarimo config -- the link lives in w2, NOT w0; w0[7:0] is ypos-low/size bits): w0: abs[15], ypos[14:6], height[5:3], width[2:0] w1: vflip[15], hflip[14], code[13:0] w2: link[7:0]
rtl/video/toobin_mo_list.sv:104 Link pointer comes from WORD 2 (schematic sheet 6: 17F link register is loaded from the C09804 word; MAME linkmask {{0,0,0x00ff,0}}).
rtl/video/toobin_mo_pos.sv:6 Implements MAME atarimo render_object's coordinate math for ONE object against ONE render scanline Y (0..383), in closed form.
rtl/video/toobin_mo_render.sv:9 Faithful to MAME atarimo render_object (swapxy, forward order, transpen 0, pen base 0x100).
rtl/video/toobin_mo_render.sv:47 scroll (pixels; MAME feeds reg>>6)
rtl/video/toobin_mo_render.sv:238 evaluate the current column (MAME swapxy clip: break right, skip left)
rtl/video/toobin_palette.sv:6 Per MAME toobin.cpp paletteram_w / intensity_w: R5 = word[14:10], G5 = word[9:5], B5 = word[4:0] (5:5:5) base8 = (c5 * 224) >> 5 ; if (base8 != 0) base8 += 38 (per channel) bit15 (intensity-disable): 1 => pen at full brightness; 0 => pe
rtl/video/toobin_palette.sv:49 MAME applies the global brightness as a floating-point pen contrast -- `m_brightness = (double)(~data & 0x1f) / 31.0` in toobin.cpp intensity_w, then set_pen_contrast() -- and the float-to-8-bit conversion truncates.
rtl/video/toobin_priority.sv:10 Decoded with MAME's jedutil as a gal16v8: simple mode, active-low outputs, only pins 13/14 driven.
rtl/video/toobin_tile_dec.sv:7 One 8x8 tile row = 4 bytes: A,B from the first ROM half (planes 2,3), C,D from the second half (planes 0,1), per MAME pflayout {RGN_FRAC(1,2)+0,+4,0,4}, plane0 = MSB.
rtl/video/toobin_tile_reorg.sv:4 The tile ROM downloads in MAME pflayout order (first half 0..0x3FFFF = planes 2,3; second half 0x40000..0x7FFFF = planes 0,1).
rtl/video/toobin_video.sv:10 Layer order/merge exactly per MAME screen_update.
rtl/video/toobin_vram_cpu.sv:9 Per MAME get_playfield_tile_info the 32-bit word is {hi16, lo16} where hi16 (color/flip/cat, bits31:16) is the addr[1]=0 access and lo16 (code, bits15:0) is addr[1]=1 (big-endian).
README.md:7 The core reconstructs the original PCB — a 68010 main board plus an Atari JSA I sound board — from Atari's SP-320 schematic package, with MAME used as a functio
README.md:13 Toobin' is its own platform, not Atari System 1 or System 2 (MAME driver `toobin.cpp`); only the video sync chain resembles System 2.
README.md:18 Six MAME sets run on identical RTL — they differ only in the main CPU ROMs.
README.md:36 | ROMs | Supplied by you from a MAME archive; none are included here |
README.md:135 Those states are replayed through the real core RTL and the rendered frame is compared to MAME's own output pixel for pixel.
README.md:136 Across attract, self-test and gameplay captures, **10 / 10 in-scope frames are bit-identical over all 196,608 pixels.** One gameplay frame is a documented out-o
README.md:152 **Render-load oracle** — the motion-object budget is sized against measured game load, not a guess: a MAME script sweeps 36,000 frames of attract and gameplay a
README.md:168 MAME is this project's functional oracle, and every gate above measures the core *against* it — so this is a narrow claim, not a general one.
README.md:173 | Behaviour | MAME | This core |
README.md:175 | Pixel priority merge | `toobin.cpp` brackets it with `not verified: logic is all controlled in a PAL`: playfield pen bit 3 *gates* the merge, and the motion o
README.md:176 | JSA I `/MIX` low-pass bit | `atarijsa.cpp` carries `TODO: emulate the low pass filter!` — the bit does nothing | the real 2nd-order filter, component by compo
README.md:177 | POKEY stereo gating | `atarijsa.cpp` notes it is "currently only mono, only looking at `ym2151_ct1`" | CT1 gates the POKEY feed into the left path, CT2 into t
README.md:204 Under those two constraints the hardware equation reduces to exactly MAME's condition, so the two agree on every frame Toobin' can produce.
README.md:262 JSA `/RDIO` D6.** Resolved here from sheet 22's LS240, against MAME comments that contradict each other between JSA I/II and JSA III.
README.md:295 Thanks to the MAME team, whose `toobin.cpp`, `atarijsa` and `atarimo` code served as the functional oracle throughout, and to whoever preserved the Atari SP-320

Says it matches, follows or was checked against MAME — 6

rtl/main/toobin_addr_decode.sv:13 Read and write handlers are decoded SEPARATELY, matching MAME's independent .r()/.w() installs: a read of a write-only register (or vice-versa) yields REG_NONE (open bus).
rtl/main/toobin_addr_decode.sv:28 match(a, start, end, mirror): MAME global-mask + mirror-collapse + range.
rtl/mem/toobin_rom_loader.sv:19 Region sizes and order match MAME's ROM_START(toobin); the download itself arrives over the MiSTer ioctl interface (sys/hps_io.sv).
rtl/video/toobin_mo_linebuf.sv:12 Pen 0xFFFF is transparent (matches MAME's MO sentinel).
rtl/video/toobin_palette.sv:54 Every attract frame runs at intensity=00, where cn=31 and the divide is a pass-through, so the error is invisible there; a pixel-exact comparison against MAME on an intensity=01 self-test frame caught it (856 pixels, all exactly +1).
README.md:133 **Pixel-exact compositor gate** — MAME 0.288 is instrumented to capture complete video state (playfield, alpha, motion-object and palette RAM, plus the scroll/S

Shares text with the MAME driver without saying so — 4

rtl/video/toobin_char_rom.sv:8 (8x8, 2bpp, planes {0,4}, x-offsets {0,1,2,3,8,9,10,11}, y*16), MSB-first bits: — shares text with atari/toobin.cpp:472
rtl/video/toobin_mo_gfx.sv:7 planes {RGN_FRAC(1,2)+0, RGN_FRAC(1,2)+4, 0, 4} (plane0=MSB), y*32, x-offsets — shares text with atari/toobin.cpp:483
rtl/video/toobin_mo_gfx.sv:8 {0,1,2,3, 8,9,10,11, 16,17,18,19, 24,25,26,27}. Each row = 32 bits = 4 bytes/half; — shares text with atari/toobin.cpp:472
rtl/video/toobin_palette.sv:51 `m_brightness = (double)(~data & 0x1f) / 31.0` in toobin.cpp intensity_w, — shares text with atari/toobin.cpp:217

TraverseUSA#
Shot Rider, Traverse USA / Zippy Race
MiSTer-devel/Arcade-TraverseUSA_MiSTer @ bfda0a5b
MAME compared: irem/travrusa.cpp + 4 related file(s)
Read: 8 HDL files, 7,083 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

26%

Statements: 3 toward hardware, 4 toward MAME, 6 not counted

Cites hardware documentation that MAME's driver does not — 3

rtl/traverse_usa.vhd:365 vcnt <= '0'&x"E6"; -- from M52 schematics
rtl/traverse_usa.vhd:1074 sprite palette ROM 2H spr_palette: entity work.travusa_spr_palette port map( clk => clock_36n, addr => spr_palette_addr, data => spr_palette_do
rtl/traverse_usa.vhd:1095 sprite rgb lut ROM 1F spr_rgb_lut: entity work.travusa_spr_rgb_lut port map( clk => clock_36n, addr => spr_rgb_lut_addr, data => spr_rgb_lut_do

Cites hardware references or measurements that MAME's driver also gives — 6

rtl/traverse_usa.vhd:902 char graphics ROM 3E char_graphics_1 : entity work.travusa_chr_bit1 port map( clk => clock_36n, addr => chr_code_line, data => chr_graphx1_do — also in MAME: 3E irem/travrusa.cpp:849
rtl/traverse_usa.vhd:910 char graphics ROM 3E char_graphics_2 : entity work.travusa_chr_bit2 port map( clk => clock_36n, addr => chr_code_line, data => chr_graphx2_do — also in MAME: 3E irem/travrusa.cpp:849
rtl/traverse_usa.vhd:918 char graphics ROM 3E char_graphics_3 : entity work.travusa_chr_bit3 port map( clk => clock_36n, addr => chr_code_line, data => chr_graphx3_do — also in MAME: 3E irem/travrusa.cpp:849
rtl/traverse_usa.vhd:1012 sprite graphics ROM 3N sprite_graphics_1 : entity work.travusa_spr_bit1 port map( clk => clock_36n, addr => spr_code_line, data => spr_graphx1_do — also in MAME: 3N irem/travrusa.cpp:854
rtl/traverse_usa.vhd:1020 sprite graphics ROM 3L or 3M sprite_graphics_2 : entity work.travusa_spr_bit2 port map( clk => clock_36n, addr => spr_code_line, data => spr_graphx2_do — also in MAME: 3L irem/travrusa.cpp:841, 3M irem/travrusa.cpp:855
rtl/traverse_usa.vhd:1028 sprite graphics ROM 3K sprite_graphics3 : entity work.travusa_spr_bit3 port map( clk => clock_36n, addr => spr_code_line, data => spr_graphx3_do — also in MAME: 3K irem/travrusa.cpp:842

Cites MAME source — 4

rtl/YM2149.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA
rtl/traverse_usa.vhd:33 Use with MAME roms from travusa.zip
rtl/traverse_usa.vhd:78 (Reducing line count will result in missing sprites) May be this can be achieved by increasing CPU clock speed (web site and MAME report 4Mhz) My M52-A schematic clearly shows 18.432/6.
README.txt:175 (Reducing line count will result in missing sprites) May be this can be achieved by increasing CPU clock speed (web site and MAME report 4Mhz) My M52-A schemat

TrioThePunch#
Trio The Punch - Never Forget Me...
MiSTer-devel/Arcade-TrioThePunch_MiSTer @ 123d5db8
MAME compared: dataeast/actfancr.cpp + 4 related file(s)
Read: 32 HDL files, 15,230 lines (Quartus project)

MiSTer official

Both

medium

28%

Statements: 2 toward hardware, 63 toward MAME

Cites hardware documentation that MAME's driver does not — 1

rtl/actfancer/jtcop_bac06.v:41 The /NUDS and /NLDS inputs of all chips are gated via a 74LS32 chip by the /DSP chip select signal.

Says it was checked against the original PCB — 1

README.md:21 YM2203 OPN + YM3812 OPL2 + OKI M6295 ADPCM, MAME-accurate clocks (OKI @ 1.056 MHz **verified on PCB**, MAME triothep)

Cites MAME source — 49

TrioThePunch.sv:316 MAME actfancr.cpp port mapping: P1 bit 0=UP, 1=DOWN, 2=LEFT, 3=RIGHT, 4=BUTTON1, 5=BUTTON2, 7=START1 SYSTEM bit 0=COIN1, 1=COIN2 MiSTer hps_io with jn keywords (pattern BoogieWings/Darius DataEast): D-pad joy[0..3] = R,L,D,U J1 buttons base
rtl/actfancer/actfancer_bac06_wrap.sv:3 ActFancer's H6280 main CPU is 8-bit; MAME accesses BAC06 via pf_data_8bit_swap_w(): A0 selects high/low byte of the 16-bit word.
rtl/actfancer/actfancer_bac06_wrap.sv:6 We translate: cpu_8bit_addr[12:0] → cpu_dout[15:0] / cpu_dsn[1:0] / cpu_addr[12:1] such that for A0=0 → write hi byte, A0=1 → write lo byte (the "swap" variant in MAME swaps endianness vs the plain one).
rtl/actfancer/actfancer_bac06_wrap.sv:65 MAME pf_data_8bit_swap_w (decbac06.cpp:625-660): A0=0 → byte BASSO del word A0=1 → byte ALTO del word (validato in sim/tb_bac06_swap.sv)
rtl/actfancer/actfancer_chars.sv:3 Stessa architettura di actfancer_tiles ma con tile 8x8 + index VRAM da MAME tile_shape0_8x8_scan (cpp:173).
rtl/actfancer/actfancer_chars.sv:92 MAME tile_shape0_8x8_scan: idx = (col & 0x1f) + ((row & 0x1f) << 5) + ((col & 0x60) << 5)
rtl/actfancer/actfancer_main.sv:4 MAME reference: dataeast/actfancr.cpp::actfancr_state::prg_map (lines 154-173)
rtl/actfancer/actfancer_main.sv:131 MAME: 0x110000-0x110001 (buffer_spriteram_w 2 byte).
rtl/actfancer/actfancer_main.sv:161 SYSTEM port MAME (active-low except bit7=VBL active-high): bit 0 = COIN1, bit 1 = COIN2, bit 7 = VBL
rtl/actfancer/actfancer_main.sv:185 PF bus fanout (BAC06 wrapper esterno gestisce 8-bit→16-bit) MAME maps tightly: pf0: 0x060000-0x060007 ctrl0, 0x060010-0x06001F ctrl1, 0x062000-0x063FFF VRAM pf1: 0x070000-0x070007 ctrl0, 0x070010-0x07001F ctrl1, 0x072000-0x0727FF VRAM mod
rtl/actfancer/actfancer_main.sv:193 PF1 VRAM: MAME limita a 2KB (0x072000-0x0727FF) — restringo per evitare aliasing
rtl/actfancer/actfancer_obj_wrap.sv:10 MAME spriteram ActFancer (actfancr.cpp:150 buffer_spriteram_w): m_spriteram16[i] = m_spriteram[i*2] | (m_spriteram[(i*2)+1] << 8); LO byte HI byte Cioè LITTLE-ENDIAN dentro il word16: spriteram byte 2i = LO byte (= cpu A0=0) s
rtl/actfancer/actfancer_obj_wrap.sv:76 little-endian (MAME buffer_spriteram_w): A0=0 -> LO byte -> dsn = 2'b10 (we[0]=1 enable LO) A0=1 -> HI byte -> dsn = 2'b01 (we[1]=1 enable HI)
rtl/actfancer/actfancer_rom_bram32.sv:6 Layout MAME chars 8x8 4bpp = RGN_FRAC(1,4): 4 planes from {0/4, 1/4, 2/4, 3/4} of the region.
rtl/actfancer/actfancer_rom_bram32.sv:7 So: plane 0 = bytes 0x00000..0x07FFF plane 1 = bytes 0x08000..0x0FFFF plane 2 = bytes 0x10000..0x17FFF plane 3 = bytes 0x18000..0x1FFFF (vedi gfx_layout layout_8x8x4 in actfancr.cpp riga 308-317)
rtl/actfancer/actfancer_snd.sv:4 MAME reference: dataeast/actfancr.cpp::dec0_s_map (lines 196-204)
rtl/actfancer/actfancer_snd.sv:151 PIN7_HIGH (MAME)
rtl/actfancer/actfancer_sprites.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Act-Fancer DECO MXC06 sprite engine — 1:1 MAME decmxc06::draw_sprites.
rtl/actfancer/actfancer_sprites.sv:4 Reference: reference/decmxc06.cpp
rtl/actfancer/actfancer_sprites.sv:6 Sprite layout (4 word × 16 bit per sprite, big-endian sprite RAM 2KB = 256 sprite): word0 (byte0,1) = {byte0:[en, yflip, xflip, h[1:0], w[1:0], yh], byte1:[ylo[7:0]]} bit 15 : enable bit 14 : Y flip bit 13 : X flip bit 12:11 : height (1x, 2
rtl/actfancer/actfancer_sprites.sv:23 MAME conversion (cpp:80-85): sx = data2 & 0x01ff; if (sx >= 256) sx -= 512; sx = 240 - sx; sy = data0 & 0x01ff; if (sy >= 256) sy -= 512; sy = 240 - sy;
rtl/actfancer/actfancer_sprites.sv:44 MRA sprites interleave (B0..B3): B0 = region 1/4 B1 = region 3/4 B2 = region 0 B3 = region 2/4 MAME planes = {0, 1/4, 2/4, 3/4} → pen[3]=B2, pen[2]=B0, pen[1]=B3, pen[0]=B1.
rtl/actfancer/actfancer_sprites.sv:128 512 wide per gestire sx negativo (signed wrap MAME).
rtl/actfancer/actfancer_sprites.sv:270 Y: 9-bit (byte0 bit0 = Y[8]) - MAME conversion
rtl/actfancer/actfancer_sprites.sv:314 code per tile row in multi-h sprite: code = (code_base & ~(h-1)) if (parentFlipY) y_offset = -tile_yi else y_offset = (h-1) - tile_yi For multi-width (x_iter > 0): MAME consumes additional spriteram entries.
rtl/actfancer/actfancer_sprites.sv:327 rom_addr = {code_y[11:0], row_in_tile[3:0], half} (code_y truncated to 12 bit per MAME tile region size 1536 ≈ 11 bit) word32-index shiftato di 1 (bridge fa [17:1]<<1, preserva [1:17])
rtl/actfancer/actfancer_tiles.sv:13 VRAM indexing MAME (decbac06.cpp): - shape0 col-major: idx = (row & 0xf) + ((0xFF - col[7:0]) << 4) - shape0 row-major: idx = (col & 0xf) + ((row & 0xf) << 4) + ((col & 0x1f0) << 4) - shape1: idx = (col & 0xf) + ((row & 0x1f) << 4) + ((col
rtl/actfancer/actfancer_tiles.sv:97 scroll x invertito per col-major (MAME cpp:274-278)
rtl/actfancer/actfancer_tiles.sv:124 VRAM index calculation (MAME tile_shape*_scan)
rtl/actfancer/actfancer_tiles.sv:255 hflip from MAME: column-major -> TILE_FLIPX
rtl/actfancer/actfancer_top.sv:204 P1/P2 Trio: MAME P1 layout active-low bit 0=Up, 1=Down, 2=Left, 3=Right, 4=B1, 5=B2, 6=B3(Trio), 7=Start joy_w[7:0] è già rimappato dal top sv per matchare quest'ordine.
rtl/actfancer/actfancer_video.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Act-Fancer — Video subsystem v5 (custom MAME-faithful modules)
rtl/actfancer/actfancer_video.sv:4 Replaces previous jtcop_bac06/jtcop_obj with bespoke 1:1 MAME modules: actfancer_tiles → PF0 16x16 tiles (jtcop_bac06 ditched)
rtl/actfancer/actfancer_video.sv:328 Compositing: PF1 (chars) > sprite > PF0 (tiles) Indici palette base Trio The Punch (MAME GFXDECODE triothep): chars → 0x000 tiles → 0x200 (vs ActFancer 0x100) sprite → 0x100 (vs ActFancer 0x200)
rtl/actfancer/actfancer_video.sv:389 MAME pf_data_8bit_swap_w (decbac06.cpp:496+641): CPU A0=0 → MAME offset^1 → odd → mask 0x00ff → write LO byte CPU A0=1 → MAME offset^1 → even → mask 0xff00 → write HI byte
rtl/actfancer/jtcop_bac06.v:205 MAME pf_control1_8bit_w (decbac06.cpp:551-566): offset >= 4 sono 8-bit mirror, scrivono LO byte indipendentemente da addr pari/dispari.
rtl/actfancer/jtcop_bac06.v:286 hflip = TILE_FLIPX MAME: ON quando col-major (mode[0] bit1 = 0).
rtl/actfancer/jtcop_bac06.v:296 MAME decbac06.cpp ActFancer m_wide=2: GEOM_4X1 16x16: 256 cols × 16 rows tile_shape0_scan column-major: idx = (row & 0xf) + ((0xFF - col[7:0]) << 4) row-major: idx = (col & 0xf) + ((row & 0xf) << 4) + ((col & 0x1f0) << 4
rtl/actfancer/jtcop_bac06.v:310 In jtcop convention, msbrow_en=0 means "MAME column-major" (TILE_FLIPX implicit).
rtl/actfancer/jtcop_bac06.v:311 In jtcop convention, msbrow_en=1 means "MAME row-major".
rtl/actfancer/jtcop_bac06.v:312 Trio The Punch: MAME m_wide=0 (tilemap 1024 px).
rtl/actfancer/jtcop_bac06.v:314 8x8 cols = 128/64/32 (invariato MAME).
rtl/actfancer/jtcop_bac06.v:337 shape1 16x16: 32 × 32 (1024 entries) ← Trio PF0 MAME: (col & 0xf) + ((row & 0x1f) << 4) + ((col & 0x10) << 5)
rtl/actfancer/jtcop_bac06.v:487 MAME byte plane offset = 16+y (y=0..7) → DDR byte = T*128 + 64 + y*4 → rom_addr (word16-idx) = T*32 + 16 + y
rtl/actfancer/triothep_main.sv:4 MAME reference: dataeast/actfancr.cpp::triothep_state::prg_map (lines 175-192)
rtl/actfancer/triothep_main.sv:6 0x000000-0x03FFFF ROM 256KB 0x040000-0x040007 PF1 BAC06 control0 0x040010-0x04001F PF1 BAC06 control1 (8bit_swap) 0x044000-0x045FFF PF1 VRAM (R/W, 8bit_swap) 8KB region 0x046400-0x0467FF PF1 rowscroll (R/W, 8bit_swap) 0
rtl/actfancer/triothep_main.sv:126 $140000 (nopr MAME)
rtl/actfancer/triothep_main.sv:146 SYSTEM (VBL + coin) — MAME PORT_START("SYSTEM"): bit 0=COIN1, bit 1=COIN2, bit 2=SERVICE1 (tutti active-low), bits 3-6 = UNKNOWN active-low (default high), bit 7=VBL active-high.
rtl/actfancer/triothep_main.sv:216 VBL → IRQ1 (HOLD_LINE equivalente) MAME: screen.screen_vblank().set_inputline(m_maincpu, 0, HOLD_LINE)

Says it matches, follows or was checked against MAME — 1

README.md:21 YM2203 OPN + YM3812 OPL2 + OKI M6295 ADPCM, MAME-accurate clocks (OKI @ 1.056 MHz **verified on PCB**, MAME triothep)

Shares text with the MAME driver without saying so — 13

rtl/actfancer/actfancer_chars.sv:92 MAME tile_shape0_8x8_scan: idx = (col & 0x1f) + ((row & 0x1f) << 5) + ((col & 0x60) << 5) — shares text with dataeast/decbac06.cpp:173
rtl/actfancer/actfancer_sprites.sv:24 sx = data2 & 0x01ff; if (sx >= 256) sx -= 512; sx = 240 - sx; — shares text with dataeast/decmxc06.cpp:81
rtl/actfancer/actfancer_sprites.sv:31 if (parentFlipY) incy = -1; else { code += h-1; incy = 1; } — shares text with dataeast/decmxc06.cpp:116
rtl/actfancer/actfancer_tiles.sv:15 - shape0 row-major: idx = (col & 0xf) + ((row & 0xf) << 4) + ((col & 0x1f0) << 4) — shares text with dataeast/decbac06.cpp:145
rtl/actfancer/actfancer_tiles.sv:16 - shape1: idx = (col & 0xf) + ((row & 0x1f) << 4) + ((col & 0xf0) << 5) — shares text with dataeast/decbac06.cpp:159
rtl/actfancer/actfancer_tiles.sv:17 - shape2: idx = (col & 0xf) + ((row & 0x3f) << 4) + ((col & 0x70) << 6) — shares text with dataeast/decbac06.cpp:166
rtl/actfancer/jtcop_bac06.v:299 row-major: idx = (col & 0xf) + ((row & 0xf) << 4) + ((col & 0x1f0) << 4) — shares text with dataeast/decbac06.cpp:145
rtl/actfancer/jtcop_bac06.v:301 tile_shape1_scan: idx = (col & 0xf) + ((row & 0x1f) << 4) + ((col & 0xf0) << 5) — shares text with dataeast/decbac06.cpp:159
rtl/actfancer/jtcop_bac06.v:303 tile_shape2_scan: idx = (col & 0xf) + ((row & 0x3f) << 4) + ((col & 0x70) << 6) — shares text with dataeast/decbac06.cpp:166
rtl/actfancer/jtcop_bac06.v:305 GEOM_4X1: 128×32 → idx = (col & 0x1f) + ((row & 0x1f) << 5) + ((col & 0x60) << 5) — shares text with dataeast/decbac06.cpp:173
rtl/actfancer/jtcop_bac06.v:306 GEOM_2X2: 64×64 → idx = (col & 0x1f) + ((row & 0x1f) << 5) + ((row & 0x20) << 5) + ((col & 0x20) << 6) — shares text with dataeast/decbac06.cpp:172
rtl/actfancer/jtcop_bac06.v:338 MAME: (col & 0xf) + ((row & 0x1f) << 4) + ((col & 0x10) << 5) — shares text with dataeast/decbac06.cpp:159
rtl/actfancer/triothep_main.sv:217 MAME: screen.screen_vblank().set_inputline(m_maincpu, 0, HOLD_LINE) — shares text with dataeast/actfancr.cpp:381

TropicalAngel#
Tropical Angel
MiSTer-devel/Arcade-TropicalAngel_MiSTer @ 3fe315d7
MAME compared: irem/m57.cpp + 5 related file(s)
Read: 10 HDL files, 7,359 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

29%

Statements: 2 toward hardware, 3 toward MAME, 5 not counted

Cites hardware documentation that MAME's driver does not — 1

rtl/TropicalAngel.vhd:310 from M52 schematics

Cites hardware references or measurements that MAME's driver also gives — 5

rtl/TropicalAngel.vhd:843 char graphics ROM 3K — also in MAME: 3K irem/m57.cpp:564
rtl/TropicalAngel.vhd:857 char graphics ROM 3M — also in MAME: 3M irem/m57.cpp:565
rtl/TropicalAngel.vhd:871 char graphics ROM 3Q — also in MAME: 3Q irem/m57.cpp:567
rtl/TropicalAngel.vhd:913 sprite palette ROM 3D — also in MAME: 3D irem/m57.cpp:574
rtl/TropicalAngel.vhd:927 sprite rgb lut ROM 1B — also in MAME: 1B irem/m57.cpp:588

Reports a measurement taken on the original PCB — 1

Arcade-TropicalAngel.sv:413 oscillator for audio on pcb is 3.579545mhz divided by 4 according to measurements by Corrado (kold666) use clk_mem for in_clk because the snd rom vma is using clk_mem in the sensitivity list for it's CDC delay reg

Cites MAME source — 3

rtl/TropicalAngel.vhd:34 Use with MAME roms from troangel.zip
rtl/TropicalAngel.vhd:36 Tropical Angel (Irem M57) Hardware caracteristics : (No schematics available, video gen info is from MAME sources)
rtl/ym2149/YM2149.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA

TurkeyShoot#
Turkey Shoot
MiSTer-devel/Arcade-TurkeyShoot_MiSTer @ 57be18e3
MAME compared: williams/williams.cpp + 5 related file(s)
Read: 11 HDL files, 12,903 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

11%

Statements: 2 toward hardware, 2 toward MAME

Cites hardware documentation that MAME's driver does not — 2

rtl/tshoot_cmos_ram.vhd:37 @0C-0F: pricing selection (XXYY XX=value YY=index [0000 custom, 0909 free play] default 0303) 0000/0101/.../0909
rtl/tshoot_cmos_ram.vhd:49 @2C-2F: ?

Cites MAME source — 1

rtl/williams2.vhd:32 Use with MAME roms from tshoot.zip

Shares text with the MAME driver without saying so — 1

rtl/williams2.vhd:325 pixels |0|1|2|3|4|5|0|1|2|3|4|5| — shares text with williams/williamsblitter.cpp:50

Tutankham#
Tutankham
MiSTer-devel/Arcade-Tutankham_MiSTer @ 9cf75dc3
MAME compared: konami/tutankhm.cpp + 3 related file(s)
Read: 21 HDL files, 7,712 lines (Quartus project)

MiSTer official

Mostly hardware

low

36%

Statements: 7 toward hardware, 14 toward MAME

Cites hardware documentation that MAME's driver does not — 5

rtl/TimePilot_SND.sv:315 Time Pilot's AY-3-8910s contain selectable low-pass filters with the following cutoff frequencies: 3386.28Hz, 723.43Hz, 596.09Hz Model this here (the PCB handles this via 3 74HC4066 switching ICs located at A2, A3 and A4)
rtl/custom/k084.sv:31 Chip pinout, confirmed against the Stern Tutankham service manual, C.R.T. Board schematic 34D-0126-S, where the part is labelled "084 / F3".
rtl/custom/k084.sv:231 H8Q arrives inverted (MAME: h8q = BIT(~x, 3)) and, per sheet 34D-0126-S, already XORed with the buffered flip signal by the LS86 at F11.
rtl/custom/k526.sv:3 SystemVerilog implementation of the Konami 526, an 82S153 PLA used for address decoding on Time Pilot Converted from dump available at the PLD Archive http://wiki.pldarchive.co.uk/index.php?title=Time_Pilot Copyright (C) 2021 Ace
rtl/custom/k528.sv:3 SystemVerilog implementation of the Konami 528, an 82S153 PLA used for controlling the vertical counter outputs on Time Pilot's Konami 082 Converted from dump available at the PLD Archive http://wiki.pldarchive.co.uk/index.php?title=Time_Pi

Ships hardware documentation files — 2

Cites MAME source — 10

rtl/Tutankham_CPU.sv:438 Generate VBlank IRQ for MC6809E MAME: IRQ fires every other vblank frame when irq_enable is set.
rtl/Tutankham_CPU.sv:577 Against the ~130 ohm full-scale of the DAC those three star levels land at 194, 214 and 255 of 255 - the same figures galaxian.cpp derives - which is 24, 26 and 31 at 5 bits.
rtl/custom/k084.sv:6 Reconstructed from the 084 pinout, the Galaxian/Scramble star circuit that MAME models in tutankhm_v.cpp, and the Konami bootleg daughter-board that replaced this chip.
rtl/custom/k084.sv:32 That sheet also corrects two details of the pinout circulated with MAME: pin 12 is a second ground alongside pin 11, and pin 9 is not connected.
rtl/custom/k084.sv:68 Two deliberate departures from MAME, both settled - do not re-derive: * No H64/H128 pin exists, so MAME's ((x & 0xc0) ^ flipxor) != 0xc0 quarter-line suppression is not modelled.
rtl/custom/k084.sv:85 Set to 1 to reinstate MAME's galaxian-inherited x[7:6]==2'b11 suppression
rtl/custom/k084.sv:134 Pin 3 gates the LFSR to the 256 visible pixels of a line - 512 steps per line, which is exactly MAME's stars_draw_row(..., star_offs = y * 512).
rtl/custom/k084.sv:169 Bit numbering follows MAME's star palette: [5]/[4] red, [3]/[2] green, [1]/[0] blue, with the even index of each pair driving the 100 ohm (brighter) resistor.
rtl/custom/k084.sv:231 H8Q arrives inverted (MAME: h8q = BIT(~x, 3)) and, per sheet 34D-0126-S, already XORed with the buffered flip signal by the LS86 at F11.
rtl/custom/k084.sv:242 MAME's galaxian-inherited quarter-line suppression.

Says it matches, follows or was checked against MAME — 2

rtl/Tutankham_CPU.sv:386 Apply flip and scroll to VRAM read coordinates (matching MAME screen_update) CRT Flip XORs into the game's own flip registers, rotating the image 180 degrees
rtl/Tutankham_CPU.sv:453 Clear IRQ when irq_enable is turned off (matches MAME irq_enable_w)

Shares text with the MAME driver without saying so — 2

rtl/custom/k084.sv:35 _____________ _| |_ NE555 ~1Hz |_|10 24|_| VCC _| |_ 18MHz (401) |_|1 19|_| Rese — shares text with konami/tutankhm.cpp:28
rtl/custom/k084.sv:212 NE555 astable on pin 10: Ra=100k, Rb=10k, C=10uF gives 0.693*(Ra+2*Rb)*C — shares text with konami/tutankhm.cpp:312

Ultratank#
Ultra Tank
MiSTer-devel/Arcade-Ultratank_MiSTer @ 54e8136f
MAME compared: atari/ultratnk.cpp + 2 related file(s)
Read: 18 HDL files, 5,080 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 4 toward hardware

Cites hardware documentation that MAME's driver does not — 4

rtl/collision.vhd:52 74LS279 quad SR latch at L11, all inputs are active low
rtl/playfield.vhd:108 Some glue logic, may be re-written later to be cleaner and easier to follow without referring to schematic
rtl/playfield.vhd:142 74LS166 video shift register
rtl/playfield.vhd:236 74LS273 octal flip-flop with asynchronous clear at H10

UPLFramebuffer#
Ark Area, Mutant Night, Ninja-Kid II / NinjaKun Ashura no Shou, Omega Fighter …
MiSTer-devel/Arcade-UPLFramebuffer_MiSTer @ e5a4f40d
MAME compared: upl/ninjakd2.cpp
Read: 13 HDL files, 3,491 lines (Quartus project)

MiSTer official

Both

low

74%

Statements: 2 toward hardware, 30 toward MAME

Ships hardware documentation files — 2

Cites MAME source — 27

Arcade-UPLFramebuffer.sv:218 Every UPL set here is 2-button (ninjakd2.cpp INPUT_PORTS common / common_2p).
Arcade-UPLFramebuffer.sv:259 MAME port assembly (ninjakd2.cpp:1156).
rtl/UPLFramebuffer.sv:18 ---- controls, assembled into MAME port order by the wrapper (active low)
rtl/UPLFramebuffer.sv:183 mnight/mnightj/arkarea use an 11-bit bg tile index (ninjakd2.cpp:1047 family).
rtl/UPLFramebuffer.sv:268 Mono board - one SPEAKER (ninjakd2.cpp:1575)
rtl/UPLFramebuffer_MAIN.sv:5 Map from ninjakd2.cpp:1010 (ninjakd2_main_cpu).
rtl/UPLFramebuffer_MAIN.sv:18 ---- controls, assembled into MAME port order by the wrapper (active low)
rtl/UPLFramebuffer_MAIN.sv:63 ninjakd2 (ninjakd2.cpp:1026) and mnight (:1047) relocate every region, but the control and input offsets match, so only the selects differ.
rtl/UPLFramebuffer_MAIN.sv:136 only bit0 of MAME's tick counter is ever tested
rtl/UPLFramebuffer_MAIN.sv:138 Bank mask from ROM region size (ninjakd2.cpp:1521 machine_start): robokid/omegaf 0x50000 = 16 banks, ninjakd2/mnight/arkarea 0x30000 = 8.
rtl/UPLFramebuffer_MAIN.sv:157 bg_ctrl (ninjakd2.cpp:1285): +00/+01 scrollx, +02/+03 scrolly, +04 bit0 enable, +05 bank masked with (vram_alloc_size >> 10) - 1 — robokid 1 bit, omegaf 3.
rtl/UPLFramebuffer_MAIN.sv:192 omegaf I/O protection read model (ninjakd2.cpp:866).
rtl/UPLFramebuffer_MAIN.sv:219 MAME tests the POST-increment tick, so toggle on the leading edge and let the mux read it back the same cycle.
rtl/UPLFramebuffer_MAIN.sv:331 vblank IRQ: HOLD_LINE on the rising edge, acknowledge returns 0xD7 = RST 10h (ninjakd2.cpp:775).
rtl/ram_rom/upl_rom.sv:201 0x8000-0xBFFF is not encrypted (MAME decodes only the first 0x8000).
rtl/ram_rom/upl_rom.sv:244 gfx_unscramble, in flight (ninjakd2.cpp:2249 lineswap_gfx_roms).
rtl/ram_rom/upl_rom.sv:244 MAME rotates the low (bit+1) address bits left at load: da[bit:1] = sa[bit-1:0], da[0] = sa[bit]; bits above `bit` unchanged.
rtl/video/UPLFramebuffer_BGLAYER.sv:5 Single layer on ninjakd2/mnight/arkarea, three identical ones on robokid and omegaf (ninjakd2.cpp robokid_get_bg_tile_info<Layer>).
rtl/video/UPLFramebuffer_BGLAYER.sv:118 row_2x2 is 0 1 / 2 3, col_2x2 (robokid/omegaf) is 0 2 / 1 3: the sub-tile bits swap (emu/video/generic.cpp:145).
rtl/video/UPLFramebuffer_SPRITE.sv:8 ninjakd2.cpp reference points: draw_sprites() — 96 16x16 sprites per frame, a big (32x32) one counting as 4, a disabled sprite still counting as 1 erase_sprites() — clear to 0xf, or with overdraw only where the stencil hits stencil_*
rtl/video/UPLFramebuffer_SPRITE.sv:260 each 16x16 quadrant drawn counts against the 96 budget; MAME's quadrant order is x inner, y outer
rtl/video/UPLFramebuffer_VIDEO.sv:4 Layer order and palette bases from ninjakd2.cpp screen_update_*.
rtl/video/UPLFramebuffer_VIDEO.sv:61 Video timing (ninjakd2.cpp: 59.61 Hz).
rtl/video/UPLFramebuffer_VIDEO.sv:70 MAME visarea min_y
rtl/video/UPLFramebuffer_VIDEO.sv:104 ninjakd2.cpp get_fg_tile_info: tile = ((hi & 0xc0) << 2) | lo flipyx = (hi >> 4) & 3 color = hi & 0x0f, palette base 0x200
rtl/video/UPLFramebuffer_VIDEO.sv:174 Three identical bg layers (ninjakd2.cpp robokid_get_bg_tile_info<Layer>).
rtl/video/UPLFramebuffer_VIDEO.sv:234 fg transparent pen is 0xF, not 0 (ninjakd2.cpp:449 set_transparent_pen).

Shares text with the MAME driver without saying so — 3

rtl/video/UPLFramebuffer_BGLAYER.sv:83 (col & 0x0f) | ((row & 0x1f) << 4) | ((col & mask) << 5) — shares text with upl/ninjakd2.cpp:416
rtl/video/UPLFramebuffer_BGLAYER.sv:110 robokid/omegaf: 12-bit tile = ((hi&0x10)<<7)|((hi&0x20)<<5)|((hi&0xc0)<<2)|lo, — shares text with upl/ninjakd2.cpp:430
rtl/video/UPLFramebuffer_SPRITE.sv:99 code = sprptr[3] | (bitswap<3>(sprptr[2],3,7,6) << 8) — shares text with upl/ninjakd2.cpp:626

Vastar#
The Bounty, Dog Fight, Mogu Chan, The Percussor …
MiSTer-devel/Arcade-Vastar_MiSTer @ 746bb363 (matched by date)
MAME compared: orca/vastar.cpp, orca/zodiack.cpp + 4 related file(s)
Read: 8 HDL files, 2,137 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

49%

Statements: 4 toward MAME

Cites MAME source — 1

rtl/Vastar_CPU.sv:6 MAME reference: vastar.cpp, vastar_viddev.cpp Hardware: Z80 CPU1 + Z80 CPU2 @ 3.072 MHz (XTAL 18.432 / 6) AY-3-8910 @ 1.536 MHz (18.432 / 12) Screen: 288x264 total, visible 256x224 (lines 17-240), ~60.6 Hz (pixel clock 6.144 MHz = 18.432 XT

Says it matches, follows or was checked against MAME — 2

rtl/Vastar_CPU.sv:152 The per-sprite flipX/flipY inversion (below, in the sprite decode) is gated on flip_screen, matching MAME vastar_viddev.cpp: if (m_flip_screen) { flipx = !flipx; flipy = !flipy; } Using rot_flip there instead looks like a harmless simplific
rtl/Vastar_CPU.sv:305 BG tile ROMs — named by the layer they serve Note: bg0_tilerom loads from bgtiles1 ROM region (CS_DL=bgtile1_cs_i) bg1_tilerom loads from bgtiles0 ROM region (CS_DL=bgtile0_cs_i) This cross-mapping matches MAME's "4 - Which" gfx assignment.

Shares text with the MAME driver without saying so — 1

rtl/Vastar_CPU.sv:154 if (m_flip_screen) { flipx = !flipx; flipy = !flipy; } — shares text with orca/vastar_viddev.cpp:161

VBall#
U.S. Championship V'ball
MiSTer-devel/Arcade-VBall_MiSTer @ eec44180
MAME compared: technos/vball.cpp
Read: 13 HDL files, 3,106 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

No statements found

Victory#
Victory
MiSTer-devel/Arcade-Victory_MiSTer @ 5fc39e93
MAME compared: exidy/victory.cpp + 2 related file(s)
Read: 66 HDL files, 4,801 lines (Quartus project)

MiSTer official

Both

medium

42%

Statements: 48 toward hardware, 6 toward MAME, 1 not counted

Cites hardware documentation that MAME's driver does not — 48

rtl/victory_board.sv:267 Sheet 4's 14K LS241 status driver is a live bus.
rtl/victory_cpu_wait.sv:1 SPDX-License-Identifier: GPL-3.0-or-later CPU/audio drawing 77-0005-01 sheet 1: both H6 LS74 sections and N6 LS08.
rtl/video/victory_graphics.sv:64 Sheet 15 detects occupied pixels across RGB colors.
rtl/video/victory_graphics.sv:233 HSC sheet 15: 11H feeds SFCIRQ back into 10H.
rtl/video/victory_graphics.sv:265 Sheet 10's downloaded 13E PROM supplies both movement enables and directions.
rtl/video/victory_hsc_address.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 8: seven LS151 address selectors, MPXRC row/column selection.
rtl/video/victory_hsc_alignment_control.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 9: 18C transfer NAND, 18B manual-increment NAND, 16D alignment NAND, and the first section of 15E with 17E's SRE NAND.
rtl/video/victory_hsc_background_control.sv:30 Sheet 16 grounds CE15 and 16L selects +5 on WE13 when the access tag is high.
rtl/video/victory_hsc_background_display.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 16: 9K/9L/9M LS299s, 10L NAND mode gates and 10K endpoint mux.
rtl/video/victory_hsc_background_display.sv:3 Read bytes use logical RGB bit order, as sheet 6's RAM outputs.
rtl/video/victory_hsc_background_ram.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 6 background RAM: one address/read/write port per 2114 bank.
rtl/video/victory_hsc_blanking_control.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 4 pin network around 15J.
rtl/video/victory_hsc_busy_filter.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Sheet 4 R7=22 ohms, C27=0.01 uF feeds 14K LS241 pin 2 only.
rtl/video/victory_hsc_clock.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 2: 17A (74LS161), 16B (74LS74) and 15A (74S374).
rtl/video/victory_hsc_clock.sv:3 ce_master represents each inverted-crystal rising edge; PROM 16A is asynchronous and must settle before the next enabled edge.
rtl/video/victory_hsc_collision.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 15: 8E/8F/9E and 8D/9D/9F NOR each RGB triplet; 8C/9C OR the empty-pixel flags; 7C NANDs all eight results.
rtl/video/victory_hsc_coordinate_control.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC 77-0004-01 sheet 9: 18B manual-X NAND, 16C vector gates, 17C Y AND and the second section of 15E.
rtl/video/victory_hsc_coordinates.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 8: primary X (11B/13B LS169), sampled /LOAD (14A), Y-prime latch (10C), working X (12D/13D LS161) and Y (10B/8B LS169).
rtl/video/victory_hsc_counters.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 8: I counters 12C/11C/12B/14B, PC counters 9B/7B, PC bit zero at 12E.
rtl/video/victory_hsc_cpu_decode.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC 77-0004-01 sheet 1: 17L PROM, 19L/18L/19K/18K LS138s, 12H bus-selection OR and 12L address inverter.
rtl/video/victory_hsc_cpu_wait.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 5: 5J request/feedback NANDs, 8J and both sections of 9J.
rtl/video/victory_hsc_decode.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 9's next-address selection and raw PROM control outputs.
rtl/video/victory_hsc_decode.sv:15 18E (74LS151): D0=GND, D1=HTC, D2=/LTC, D3=/SETRDY, D4=/CM7, D5=VFIN, D6/D7=+5.
rtl/video/victory_hsc_dimensions.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 11: LS161 counters 3H/4H/5H, NAND 8H and inverters 9H.
rtl/video/victory_hsc_display.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 14: 1F/1E/1D LS299 and XH LS157.
rtl/video/victory_hsc_lookahead.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 16: 15M/16L address and /WE muxes, 15L LS174 address latch and 15K Signetics 82S09 (64x9).
rtl/video/victory_hsc_lookahead.sv:24 Sheet 5 SEALOK = SLOKEA OR SEAADV.
rtl/video/victory_hsc_lookahead.sv:33 82S09's open-collector outputs read the complemented stored word, and follow the complement of I0..8 during a write.
rtl/video/victory_hsc_memory_control.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheets 9/14: address/write NANDs, foreground write latch 16B and serial-register direction gates.
rtl/video/victory_hsc_memory_control.sv:23 Sheet 14 16B: D=S W VRAM, Q-bar pin 6 drives 6C and BIRWR.
rtl/video/victory_hsc_memory_control.sv:24 SCLK11 is the same inverted-crystal edge that advances clock latch 15A; sample the established phase before that latch updates its outputs.
rtl/video/victory_hsc_ram.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 14's three banks of 4116 DRAM, addressed through sheet 8.
rtl/video/victory_hsc_ram.sv:35 Sheet 14's RP3/RP2 pull-ups make floating bits high; represent that bus value without inferring FPGA internal tristates.
rtl/video/victory_hsc_raster_control.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 3: sync decoder, scroll loads and 13F blanking latches.
rtl/video/victory_hsc_raster_control.sv:43 Sheet 3 exports the second section's /Q8, not Q9.
rtl/video/victory_hsc_raster_counters.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 3 counter chain: 13H LS74, 17F LS161 and both 15F LS112 sections, with vertical 15H/16F LS161s.
rtl/video/victory_hsc_raster_counters.sv:23 Sheet 3's INVERT is the complement of raw S INVERT.
rtl/video/victory_hsc_register_decode.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 7: LS08 gates 19H/19J combine CPU and program-register strobes.
rtl/video/victory_hsc_register_decode.sv:17 Sheet 7's +5 wire enters D6/pin 13; it crosses the CM-load return without a dot.
rtl/video/victory_hsc_renderer.sv:23 Sheet 3 inverter 14H derives raster INVERT from raw S INVERT (CONTROL bit 3).
rtl/video/victory_hsc_renderer.sv:24 Sheet 14 uses the raw wire for LS299 direction and endpoint.
rtl/video/victory_hsc_renderer.sv:34 This is provisional glue, not a claim to reproduce missing PROM 15J.
rtl/video/victory_hsc_rgb.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Sheet 16 Q1..Q6 current-steering RGB drivers, normalized nominal transfer.
rtl/video/victory_hsc_rgb.sv:3 Low 82S09 pins sink emitter current through 3.9k/2k/1k branches.
rtl/video/victory_hsc_scroll.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC sheet 5: 3J LS157 clocks cascaded 1J/XJ and XL/XK LS193s.
rtl/video/victory_hsc_sequencer.sv:19 Sheet 8: 14E inverts the raw SEQ CLK to S SEQ CLK.
rtl/video/victory_hsc_sequencer.sv:19 Sheet 9: 17E NANDs that signal with the non-inverted 18E condition output.
rtl/video/victory_hsc_vector.sv:1 SPDX-License-Identifier: GPL-3.0-or-later HSC 77-0004-01 sheet 10: PROM 13E's address and movement outputs.

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/video/victory_hsc_scroll.sv:21 Follow the continuous wires at 3J pins 10/11: normal scan increments both X and Y, not just X. — also in MAME: 3J exidy/victory.cpp:286

Cites MAME source — 6

rtl/io/trackball_input.sv:4 Like MAME's IPT_TRACKBALL with PORT_KEYDELTA(4) at 80% sensitivity, a held D-pad direction adds a small fixed step every frame (no ramp, stops when released); the stick adds a step proportional to its deflection beyond a dead zone.
rtl/io/victory_inputs.sv:45 MAME declares PORT_REVERSE on Victory's dial.
rtl/victory_board.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Main board memory/PIO decode from the pinned MAME Victory driver.
rtl/video/victory_graphics.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Synthesizable command implementation based on Aaron Giles's BSD-licensed victory_v.cpp.
rtl/video/victory_graphics.sv:84 MAME's busy model uses 11.289 MHz / 8.
rtl/video/victory_timing.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Provisional raster from MAME victory.h; sync porches await PCB confirmation.

Vindicators#
Vindicators
MiSTer-devel/Arcade-Vindicators_MiSTer @ ad657d98
MAME compared: atari/vindictr.cpp + 6 related file(s)
Read: 36 HDL files, 8,392 lines (Quartus project)

MiSTer official

Both

high

87%

Statements: 310 toward hardware, 88 toward MAME

Cites hardware documentation that MAME's driver does not — 305

Arcade-Vindicators.sv:158 Per-player switch word, ACTIVE HIGH ("pressed"), in the order of the panel switches Pn-S1..Pn-S8 on SP-317 sheet 13 (= MAME 0x260000 D8..D15); see the port comment in vind_core.sv.
rtl/main/vind_addr_decode.sv:3 Vindicators 68010 address decode — SP-317 sheet 4 (PAL 3C, LS139 4J) and sheet 3 (LS138 7/8B), gate for gate.
rtl/main/vind_addr_decode.sv:7 Structure derives from the Xybots MiSTer core's `xybots_addr_decode.sv` (GPL-3.0); every equation below is Vindicators' own, read off SP-317 sheets 4 and 3.
rtl/main/vind_addr_decode.sv:11 ---- PAL16L8 3C = 136059-1150 (sheet 4) -------------------------------- Pin map from the drawing: 1=BAS 2=A19 3=A18 4=A17 5=A16 6=A15 7=A14 8=A13 9=BS0 11=BS1 | 12=MA14' 13=MA13' 14=/SLAPCS 15=/IOSEL 16=/COM 17=/ROM2 18=/ROM1 19=/ROM0.
rtl/main/vind_addr_decode.sv:14 Fuse map decoded from the PAL dump with `jedutil`, re-checked against the sheet:
rtl/main/vind_addr_decode.sv:30 The 2C slapstic socket is believed unpopulated (sheet 4).
rtl/main/vind_addr_decode.sv:36 ---- LS139 4J (sheet 4) ------------------------------------------------
rtl/main/vind_addr_decode.sv:44 ---- LS138 7/8B (sheet 3) ----------------------------------------------
rtl/main/vind_addr_decode.sv:49 `CA20`, `CA16`, `CA5`, `CA4` are the buffered copies of the CPU's A20/A16/A5/A4 (the A1..A16 buffers are 7E/8E on sheet 4; CA20's buffer is on the video sheets, so it is taken here as a straight copy of A20).
rtl/main/vind_addr_decode.sv:66 ---- derived control (sheet 4) -----------------------------------------
rtl/main/vind_addr_decode.sv:76 2C slapstic socket empty -> the PAL's BS inputs float HIGH (sheet 4).
rtl/main/vind_addr_decode.sv:87 ---- common-bus qualifiers, from the video sheets (sheet 3) ----
rtl/main/vind_addr_decode.sv:91 ---- PAL 3C ----
rtl/main/vind_addr_decode.sv:101 ---- LS139 4J ----
rtl/main/vind_addr_decode.sv:137 ---- LS139 4J --------------------------------------------------------
rtl/main/vind_cpu.sv:3 Vindicators main CPU wrapper — MC68010 at 5D, SP-317 sheet 4.
rtl/main/vind_cpu.sv:10 The part on the board is a **68010** (sheet 4, 64-pin DIP at 5D, CLK = RCLKA = 7.15909 MHz).
rtl/main/vind_cpu.sv:18 This wrapper presents the sheet's own active-high `BAS` and an active-high `dtack` to the rest of the main board, and A23..A1 with **no A0** — there is no A0 pin on a 68010 and none anywhere on this board; the byte lane is /UDS //LDS and no
rtl/main/vind_cpu.sv:30 * `/AS`, `/UDS`, `/LDS` and `R//W` are driven from a `cpu_cen`-gated state machine, so every strobe edge lands on an RCLKA boundary — the same edges the 8D LS163A samples (`vind_dtack`, /CLR = BAS, CK = RCLKA).
rtl/main/vind_cpu.sv:35 One extra RCLKA in the LS163A therefore becomes exactly one extra RCLKA of bus cycle, so the sheet's table maps one-for-one: 0 waits for ROM and the write strobes, **1** for /EEPROM, **stall until PVCPU** for /VRAM, **stall until EWAI** for
rtl/main/vind_cpu.sv:43 Nothing on this board looks at that: every terminator is /DTACK off the LS163A, /BERR is tied high (no timeout), and the video side re-times its own accesses through PVCPU / EWAI.
rtl/main/vind_cpu.sv:48 ---- /VPA and autovectors ---------------------------------------------- Sheet 4: `/VPA = ~(BAS & FC0 & FC1 & FC2)`, so every interrupt acknowledge is autovectored.
rtl/main/vind_cpu.sv:140 CPU generic defaults to "01" (68010) in TG68K.vhd; the ghdl-generated netlist bakes it in, so it is not overridden here (works for both).
rtl/main/vind_dtack.sv:3 Vindicators /DTACK and wait-state sequencer — SP-317 sheet 4, gate for gate (8D 74LS163A + 22F 74S74 + 23E/7D LS02 + 5F S32 + 22D LS10 + 24E LS86).
rtl/main/vind_dtack.sv:7 Modelled on the Xybots core's `xybots_dtack.sv` (GPL-3.0); the counter, the load vector and the COM grant latch below are Vindicators' own, read off SP-317 sheet 4.
rtl/main/vind_dtack.sv:35 ---- the sequencer ----------------------------------------------------- 22F 74S74 D = sd, CK = RCLKB, /PRE = /CLR = PR4 (inactive) Q -> 8D ENT 8D LS163A CK = RCLKA, /CLR = BAS (SYNCHRONOUS), /LD = QC (SYNCHRONOUS) ENT = 22F Q, ENP =
rtl/main/vind_dtack.sv:87 PAL 3C /COM
rtl/main/vind_dtack.sv:123 ---- 22F 74S74, clocked by RCLKB ------------------------------------
rtl/main/vind_dtack.sv:129 ---- 8D 74LS163A, clocked by RCLKA ----------------------------------
rtl/main/vind_eeprom_2804.sv:3 Vindicators X2804A (512 x 8) EEPROM at 1C + the 18E LS74 unlock latch — SP-317 sheet 4.
rtl/main/vind_eeprom_2804.sv:6 Ported from the Xybots MiSTer core's `xybots_eeprom_2804.sv` (itself from Toobin's `toobin_eeprom_2804.sv`), GPL-3.0, and re-derived against the SP-317 sheet-4 wiring.
rtl/main/vind_inputs.sv:3 Vindicators player / status input ports — SP-317 sheet 3 (1/2B, 3B, 6B LS244 and 9B LS367A).
rtl/main/vind_inputs.sv:7 Shaped after the Xybots core's `xybots_inputs.sv` (GPL-3.0); the bit map is Vindicators' own, read off SP-317 sheet 3.
rtl/main/vind_inputs.sv:10 ---- the three switch buffers ------------------------------------------ 1/2B LS244A (/PL1, 0x260000), 3B LS244B (/PL2, 0x260010) and 6B LS244C (/PL3, 0x260020) each drive the HIGH byte only, with BOTH enables tied to their strobe.
rtl/main/vind_inputs.sv:22 **Sheet 12's legend numbers the bits the other way round** ("D15 (Switch 1) ...
rtl/main/vind_inputs.sv:23 Sheet 3 is the wiring and wins; sheet 12 is just numbering bits top-down.
rtl/main/vind_inputs.sv:27 ---- the status byte (9B LS367A, enabled by /PL2) ---------------------- CD0 = /VBLANK (video sheets) CD1 = S-TEST (self-test switch, pulled up by R68 -> 1 = not pressed) CD2 = /SINT (SCOM FULL, sheet 2 — sound -> main byte waiting
rtl/main/vind_inputs.sv:37 ---- the unpopulated LETA / ADC0809 low byte (sheet 3) ---------------- 13B (LETA quadrature) would drive CD0-CD7 during /PL1 and 11B (ADC0809) during /PL3.
rtl/main/vind_inputs.sv:39 Neither is populated on Vindicators (sheet 12 lists no analog entry, MAME declares the low bytes IPT_UNUSED, and the cabinet has only twin digital sticks), so those lanes read the floating/pulled-up bus = **0xFF**.
rtl/main/vind_inputs.sv:64 the 9B LS367A byte, for observation in simulation
rtl/main/vind_inputs.sv:73 CD5 — LS367A pin 2 is a bare stub
rtl/main/vind_irq.sv:3 Vindicators interrupt encoding — SP-317 sheet 4 (21E LS08, R79/R80, 9F LS11, 20E LS00).
rtl/main/vind_irq.sv:7 Shaped after the Xybots core's `xybots_irq.sv` (GPL-3.0); the encoding is Vindicators' own, read off SP-317 sheet 4.
rtl/main/vind_irq.sv:24 /SINT is the SCOM's `FULL` pin, a push-pull output (sheet 2), so that half is settled; /VINT comes from the VIRQ latch on the video sheets, so the asymmetry is **(inferred)**.
rtl/main/vind_irq.sv:45 ---- acknowledge -------------------------------------------------------- /VACK (sheet 3 LS138 Y0, write 0x360000) clears the VIRQ latch, which lives on the VIDEO sheets — so this module takes /VINT as an input and exports the /VACK strobe
rtl/main/vind_irq.sv:57 /SINT — SCOM FULL, sheet 2
rtl/main/vind_main_bus.sv:3 Vindicators main board — SP-317 sheets 2, 3 and 4 as one block.
rtl/main/vind_main_bus.sv:10 Composes: vind_cpu (TG68K in 68010 mode) + vind_addr_decode (PAL 3C, LS139 4J, LS138 7/8B) + vind_dtack (8D LS163A sequencer + the EWAI latch) + vind_irq + vind_watchdog (22M/N LS197 + the sheet-2 one-shot) + vind_eeprom_2804 (1C + the 18E
rtl/main/vind_main_bus.sv:16 The memory map, the wait-state table and the schematic-vs-MAME decisions are documented in the submodule headers; this one records the composition.
rtl/main/vind_main_bus.sv:30 **The SCOM mailbox toward the JSA I board** — the SCOM device itself (14/15B on sheet 2, both halves of the 4-wire serial link) is `rtl/sound/vind_scom.sv`.
rtl/main/vind_main_bus.sv:36 ---- two buses, not one ------------------------------------------------ Sheet 4 gives the 7E/8E LS244 and 8C/7C LS245 enables as `/EWAI`, and EWAI = ~(ENOWAI + /COM), asserted **only** for /COM cycles.
rtl/main/vind_main_bus.sv:42 * sheet 6 — VRAM 1M/2M/2N/1N is addressed by **MA1..MA16** (the always-enabled 3D/3E LS244s) and sits on the **raw 68010 D0-D15**, through 3L/3K LS373 (read, G = VCPU, /OC = /VRAMRD = /VRAM + W//R) and 4L/4K LS244 (write, /G = VR//W).
rtl/main/vind_main_bus.sv:45 `/CLRAM = MA16` splits CRAM off, and sheet 10 puts the CRAM CPU port on the same raw D bus, direction `VW//R`.
rtl/main/vind_main_bus.sv:48 * so `/EWAI` gates only the I/O block on sheet 3 — the three LS244 switch ports, the 9B LS367A status byte, the SCOM and the 10B LS174.
rtl/main/vind_main_bus.sv:54 ---- CDS, /CIO and CW//R ----------------------------------------------- All three are generated on **sheet 5** (the unpopulated ECPU sheet), not on the video sheets: 23D LS158A muxes the two CPUs (`SEL = EWAI`, B = the main CPU), 20D LS32
rtl/main/vind_main_bus.sv:63 `/CIO` is the one thing the schematic does not settle: PAL 21D is undumped, but R78 470R ties `/CIO` to `/COM`, so `/CIO = /COM` (inferred).
rtl/main/vind_main_bus.sv:92 3D/3E LS244, ALWAYS driven (sheet 4)
rtl/main/vind_main_bus.sv:97 23D LS158A on sheet 5 (= A20 here)
rtl/main/vind_main_bus.sv:102 synthesised from sheet 5, see header
rtl/main/vind_main_bus.sv:103 synthesised from sheet 5, see header
rtl/main/vind_main_bus.sv:176 Decode (PAL 3C + LS139 4J + LS138 7/8B)
rtl/main/vind_main_bus.sv:193 The slapstic socket 2C is empty (sheet 4): /SLAPCS reaches nothing.
rtl/main/vind_main_bus.sv:234 Program ROM address (sheet 4: the six EPROMs in three 128 KB banks)
rtl/main/vind_main_bus.sv:244 This is the bus the program EPROMs, the EEPROM, the PAL, the VRAM (sheet 6) and the CRAM (sheet 10) all hang off.
rtl/main/vind_main_bus.sv:255 Sheet 5: 23D LS158A (SEL = EWAI) then 20D LS32 (9,10->8).
rtl/main/vind_main_bus.sv:258 PAL 21D, undumped; R78
rtl/main/vind_main_bus.sv:329 Inputs (1/2B, 3B, 6B LS244 + 9B LS367A) and the 10B LS174
rtl/main/vind_main_bus.sv:373 VRAM (3L/3K LS373, /OC = /VRAMRD) and CRAM (sheet 10) drive the RAW D bus — no /EWAI, no PVCPU: the LS373 holds the word the CPU slot fetched until /VRAMRD releases at the end of the cycle.
rtl/main/vind_main_bus.sv:407 DTACK / wait states (8D LS163A + 22F 74S74 + the EWAI latch)
rtl/main/vind_out_latch.sv:3 Vindicators output latch 10B 74LS174B — SP-317 sheet 3.
rtl/main/vind_out_latch.sv:30 Two of the six outputs (`/ERESET`, `PRBK`) leave sheet 3 for the video sheets and are exported here; `LTEST`/`LRESL` reach only the unpopulated LETA and are therefore genuinely inert on this board.
rtl/main/vind_watchdog.sv:3 Vindicators watchdog / reset counter — SP-317 sheet 4 (22M/N 74LS197, 18L LS08, the WDIS jumper) plus the sheet-2 power-on one-shot.
rtl/main/vind_watchdog.sv:15 22M/N 74LS197 (dual counter: CK1 -> QA divide-by-2; CK2 -> QB,QC,QD /8) pin 13 /CLR = POWER-ON (sheet 2)
rtl/main/vind_watchdog.sv:28 Sheet 12 says "128 msec.
rtl/main/vind_watchdog.sv:34 ---- one departure from the sheet -------------------------------------- Sheet 4 calls the C/L load "synchronous".
rtl/main/vind_watchdog.sv:50 sheet 2: R152 100 k x C60 0.1 uF ~ 10 ms (plus the Darlington Vbe)
rtl/main/vind_watchdog.sv:67 ---- sheet 2: the power-on one-shot ---------------------------------
rtl/main/vind_watchdog.sv:79 ---- 22M/N 74LS197 --------------------------------------------------- CK1 and CK2 are NEGATIVE-edge triggered; /VBLANK falls at the START of vertical blank, and QA's own falling edge clocks the divide-by-8 half.
rtl/mem/vind_char_rom.sv:3 Vindicators alphanumeric character ROM — the 27128 at 15/16N (SP-317 sheet 7), 16 K x 8 in one M10K-backed BRAM.
rtl/mem/vind_char_rom.sv:9 ---- the board (sheet 7) ------------------------------------------------- A13..A4 = AP9..AP0 the character code, alpha word D9:0 A3..A1 = 4V, 2V, 1V the pixel row inside the 8x8 cell
rtl/mem/vind_char_rom.sv:21 Unlike the graphics ROMs this data is NOT inverted anywhere: MAME applies ROMREGION_INVERT to `sprites_pf` only, and sheet 7's shifters take the ROM bits straight.
rtl/mem/vind_cpurom_sdram.sv:3 Vindicators 68010 program ROM out of SDRAM — the six 27512s at 1D/2D, 1F/2F, 1K/2K (SP-317 sheet 4) behind a prefetching set-associative cache.
rtl/mem/vind_cpurom_sdram.sv:14 But sheet 4 gives ROM cycles **zero wait states**: the 8D LS163A loads 15 the moment BAS rises and RCO asserts /DTACK immediately, with no term that depends on the ROM at all.
rtl/mem/vind_gfx_mem.sv:13 ---- what one request IS on the board (SP-317 sheet 9) ------------------- The sixteen graphics ROM sockets are wired as four quadrants, one per pixel bit-plane, all sharing ONE address bus:
rtl/mem/vind_gfx_mem.sv:36 GA15 exists on the board but is not decoded by the fitted ROMs (sheet 8), so the caller drops it.
rtl/mem/vind_gfx_mem.sv:44 (MAME's ROMREGION_INVERT is the same fact applied at load time; this core keeps the board's polarity so sheet 10's PAL equations can be written verbatim.) then drop *_req; the arbiter waits for the drop, so one request = exactly on
rtl/mem/vind_gfx_mem.sv:54 ---- budget --------------------------------------------------------------- Sheet 6 alternates the graphics ROM between the playfield and the motion object every 4 pixel clocks (MO//PF = 4HDL), and each layer's SLAGS pair is reloaded once p
rtl/mem/vind_mem.sv:41 PAL 3C decodes /ROM0..2 from the address alone, so `prog_rd` is asserted throughout the download even though the CPU is in reset, and a cache that fills from a not-yet-written SDRAM would hold zeros for ever.
rtl/mem/vind_mem.sv:59 **WARNING**: sheet 4 gives ROM cycles zero wait states and `vind_main_bus` implements that literally, so on a cache miss the CPU would latch stale data.
rtl/mem/vind_mem.sv:255 PAL 3C decodes /ROM0..2 from the address alone (sheet 4: there is no BAS term on those outputs), so `prog_rd` is HIGH at prog_a = 0 for the whole download, while the 68010 is still held in reset — and without this term the cache fills line
rtl/mem/vind_rom_loader.sv:28 * maincpu is emitted as BIG-ENDIAN INTERLEAVED WORDS — the MAME even-offset ROM (the `1x` sockets 1D/1F/1K, sheet 4, D15:8) is `map="01"`, the FIRST byte of each output word.
rtl/mem/vind_rom_loader.sv:36 * sprites_pf is emitted as a FOUR-WAY BYTE INTERLEAVE of the four bit planes, plane 0 (MSD0/PSD0) first, so the four plane bytes of one graphics address are consecutive and one 32-bit read returns the whole 8-pixel row the sheet 9 SLAGS pai
rtl/mem/vind_sdram_loader.sv:18 prog : the MRA interleaves the six 27512s into BIG-ENDIAN 68010 words, so the EVEN download byte is D15:8 (the `1x` sockets at 1D/1F/1K, sheet 4) and the ODD byte is D7:0.
rtl/video/vind_alpha.sv:3 Vindicators — SP-317 sheet 7 (`ALPHA`): the AP pipeline latch, the alpha control-word decoder, the VIRQ latch, the character ROM and its shifters, the playfield vertical counter and the motion-object X-scroll latch.
rtl/video/vind_alpha.sv:13 14M LS273K (CK = 4H) : MATCH->MATCHD, VRD14->AP14, VRD13->AP13, VRD11..VRD8 -> AP11..AP8, VRD15 -> BARE STUB 14L LS273A (CK = 4H) : VRD7..VRD0 -> AP7..AP0 VRD12 is latched NOWHERE on sheet 7 and there is no AP12 net.
rtl/video/vind_alpha.sv:16 That is not a missing bit: the alpha attribute bits D15, D12, D11 and D10 are latched INSIDE the GPC custom (15J/K pins 22..25, sheet 10) straight off the raw VRD bus, and D14/D13 come back as APAL4/APAL3 from 13M here.
rtl/video/vind_alpha.sv:46 One byte is four pixels of two bit planes; 19N/18N LS194A parallel-load on H03 and shift right for the other three FCLOCKs, so QD emits O7,O6,O5,O4 (APIX1, the pen MSB) and O3,O2,O1,O0 (APIX0).
rtl/video/vind_alpha.sv:56 19K/11L/13L LS163A, CK = 4H, /LD = /PFVS (AP8..AP0), ENT = PFHST (one pulse per line), ENP = /VBLANK (FROZEN during vertical blanking), /CLR = PR2.
rtl/video/vind_alpha.sv:65 19M/N LS74 + 10L/10M LS175, CK = /MOHS, /CLR = /SYSRES, taking the /Q outputs, so `/PF256L../PF1L` is the ONE'S COMPLEMENT of the 9-bit MO X scroll -- which is what sheet 8's LS283 chain wants (subtract by add of complement).
rtl/video/vind_alpha.sv:78 sheet 4 22M/N LS197, active high here
rtl/video/vind_alpha.sv:89 6F Q2 -- the LS194A parallel-load window
rtl/video/vind_alpha.sv:99 21E LS08 on sheet 8
rtl/video/vind_alpha.sv:100 14M LS273K Q12
rtl/video/vind_alpha.sv:114 sheet 3, write 0x360000
rtl/video/vind_alpha.sv:115 18E LS74 /Q -> sheet 4's IPL network
rtl/video/vind_alpha.sv:148 ap[12] has NO board net (VRD12 is latched nowhere on sheet 7) and is held at 0 so nothing can accidentally consume it.
rtl/video/vind_alpha.sv:175 13M LS174A -- CK = /4HDF [inferred]
rtl/video/vind_alpha.sv:177 Sheet 7 gives 13M's clock as `/4HDF`, a name that appears nowhere else in SP-317; the obvious reading is a drawing typo for `/4HDD` (SYNGEN pin 36).
rtl/video/vind_alpha.sv:222 Character ROM and the 19N / 18N LS194A shifters
rtl/video/vind_alpha.sv:246 v[7:3]: the alpha ROW index is formed on sheet 6, not here.
rtl/video/vind_alpha.sv:247 vrd[15]/vrd[12]: latched inside the GPC (sheet 10), never on this sheet.
rtl/video/vind_alpha.sv:253 19K / 11L / 13L LS163A -- the playfield vertical counter
rtl/video/vind_cram.sv:3 Vindicators — SP-317 sheet 10: the 2048 x 16 colour RAM (16K + 18K, 2K8-45A) and its CPU port.
rtl/video/vind_cram.sv:79 ---- the CPU's own read port ------------------------------------------ Clocked at clk_sys, NOT at ce_7m, for exactly the reason `vind_vram`'s read is: the board's 16K/18K are ASYNCHRONOUS 2K8-45A static RAMs, so during the CPU's one RCLKA
rtl/video/vind_cram.sv:95 3L/3K LS373 (sheet 6): transparent while the CPU owns the array, latched on the falling edge of that slot, driven onto D15:0 while /VRAMRD is low.
rtl/video/vind_gfx_hold.sv:10 ---- what the board does -------------------------------------------------- SP-317 sheet 9: the sixteen graphics EPROMs are asynchronous and permanently enabled.
rtl/video/vind_intensity_dac.sv:3 Vindicators — SP-317 sheet 10 (the 18M LS283 intensity adder, the 18D / 18F registers and the 17M/17L output registers) and sheet 11 (the RGBI current DACs, the ZREF reference and the all-zero clamps).
rtl/video/vind_intensity_dac.sv:10 THE INTENSITY ADDER (sheet 10)
rtl/video/vind_intensity_dac.sv:21 BLANKING (sheet 10, sheet 11)
rtl/video/vind_intensity_dac.sv:30 THE LADDER (sheet 11)
rtl/video/vind_intensity_dac.sv:119 The blanking level is still colour code 0 -- there is no separate pedestal (sheet 11), which is the only thing the clear was there to say.
rtl/video/vind_mo.sv:3 Vindicators — the motion-object engine: SP-317 sheet 8 (`MO-CTRL`) plus the two line-buffer customs on sheet 10.
rtl/video/vind_mo.sv:8 This module is only the wiring between `vind_mo_fetch` (the PAL 7N sequencer, the word latches, the adders, the two undumped PROMs and the MO half of the SLAGS shifters) and `vind_mo_linebuf` (14D/14E and the PAL 17E write sequencer).
rtl/video/vind_mo.sv:13 ---- the list walk, in one paragraph ------------------------------------ Sheet 6's NXLDL cycle reads the SLIP word for band PFV >> 3 out of alpha row 31 and 7L/7J latch its D9:0 into LNK9..LNK0.
rtl/video/vind_mo.sv:55 ---- back to sheet 6 / 7 ----
rtl/video/vind_mo.sv:62 ---- to the priority / GPC block (sheet 10) ----
rtl/video/vind_mo.sv:77 PAL 7N pin 13 (see vind_mo_fetch.sv)
rtl/video/vind_mo_fetch.sv:3 Vindicators — SP-317 sheet 8 (`MO-CTRL`): the PAL16R6A 7N slot sequencer, the 4J LS139 word strobes, the four motion-object word latches, the X adders, the two undumped bipolar PROMs, the graphics-address counters, the MATCH flip-flops and
rtl/video/vind_mo_fetch.sv:11 PAL16R6A 7N = 136059-1153 -- a dumped PAL, implemented VERBATIM
rtl/video/vind_mo_fetch.sv:14 jedutil prints the sum-of-products that drives each pin LOW, so `pin = ~SOP` and, for the registered pins, `Q = SOP` with the pin showing `~Q`.
rtl/video/vind_mo_fetch.sv:54 Sheet 6's 6F LS174C registers PVAS into VAS, so the RAM cycle happens one RCLKA later than the code above names it.
rtl/video/vind_mo_fetch.sv:58 THE TWO UNDUMPED PROMs (sheet 8, [inferred])
rtl/video/vind_mo_fetch.sv:60 11N 82S147 (512x8) and 9J 82S129 (256x4) are NOT in the MAME ROM set and cannot be read off the drawing.
rtl/video/vind_mo_fetch.sv:96 Sheet 8 routes PICTD/HORZD/VERTD through 7F LS175D first, so on the board the word latches clock on the RCLKA edge that ENDS the LS139 strobe cell (7F /Q = the active-high strobe, whose RISING edge is that boundary) and the 21F MATCH flip-f
rtl/video/vind_mo_fetch.sv:106 phase 0 : /GLD with MO//PF high -> the SLAGS load the MO column phase 2 : /LD01 -> 8K/8J take MAT, 9K takes the width, and the 14D/14E write pointers take HPOS (they present it from phase 3) phase 3 : 4H's RISING edge -- 12M LS378C and the
rtl/video/vind_mo_fetch.sv:144 14M LS273K Q12
rtl/video/vind_mo_fetch.sv:151 ---- to sheet 6 ----
rtl/video/vind_mo_fetch.sv:157 ---- to sheet 7 ----
rtl/video/vind_mo_fetch.sv:160 ---- to sheet 10 ----
rtl/video/vind_mo_fetch.sv:169 PAL 7N pin 13 IS the board's /BUFCLR (see section 3 below)
rtl/video/vind_mo_fetch.sv:178 PAL 7N -- state
rtl/video/vind_mo_fetch.sv:237 4J LS139 -- the four MO word strobes (sheet 8)
rtl/video/vind_mo_fetch.sv:250 7F LS175D -- the strobe pipeline and the line-buffer bank (sheet 8)
rtl/video/vind_mo_fetch.sv:257 Not settled by the schematic: sheet 8 also shows /BUFCLR on 7F's /CLR, and that cannot be taken literally -- an asynchronous clear on THIS register would pin the bank at 0 and there would be no ping-pong at all.
rtl/video/vind_mo_fetch.sv:279 The four word latches (sheet 8)
rtl/video/vind_mo_fetch.sv:298 GA15 (mo_tile[15]) is not decoded by the graphics ROM (sheet 9).
rtl/video/vind_mo_fetch.sv:311 10J / 10K / 4N -- HPOS = MO_X - MO_XSCROLL (sheet 8)
rtl/video/vind_mo_fetch.sv:315 ---- 12M LS378C -- the snapshot register (sheet 8) --------------------- 12M : CK = 4H , /G = /NEWMO D4 = MFLP -> Q5 ; D13/D3/D6 = 12N S3/S2/S1 (= diff[2:0]) -> the GP4V/GP2V/GP1V side of 12L ; D14 = MATCH -> Q15 -> 20F = GPEN.
rtl/video/vind_mo_fetch.sv:376 Vertical match (sheet 8)
rtl/video/vind_mo_fetch.sv:385 9J 82S129 + 9K LS169 -- the width counter and /END (sheet 8)
rtl/video/vind_mo_fetch.sv:387 The preset is **HSIZ** -- the object's width minus one -- which is exactly the three bits sheet 8's "9K D (pin 6) = GND" leaves room for, and it is the only value that draws HSIZ + 1 columns:
rtl/video/vind_mo_fetch.sv:417 Not settled by the schematic: sheet 8 reads 9K's CK as 4HD3 and its /LD as /LD01, but /LD01 is low only in phase 2 while 4HD3 rises in phase 7, so a LITERAL LS169 -- synchronous load -- would never take the preset at all.
rtl/video/vind_mo_fetch.sv:423 That is the only reconstruction in which the SAME three-bit 82S129 output produces both required behaviours:
rtl/video/vind_mo_fetch.sv:448 21F LS74 + 21E LS08 -- MATCH (sheet 8)
rtl/video/vind_mo_fetch.sv:467 11N 82S147 + 10N/9N LS169 + 8N/7M LS283 -- the graphics address
rtl/video/vind_mo_fetch.sv:469 Sheet 8 wires the 82S147's address from the LIVE nets -- A8 = /VMATCH, A7 = MFLP (9L), A6/A4/A3 = HSIZ (9L), A2:A0 = 14N S4:S2 -- not from 12M, and 10N/9N reload from it on EVERY 4H while /NEWMO is asserted.
rtl/video/vind_mo_fetch.sv:480 10N / 9N LS169: CK = 4H (sheet 8), /LD = /NEWMO, U//D = 6D LS04 from the snapshotted MFLP (12M Q5) -- the direction has to survive the whole locked-on fetch, so it cannot be the live 9L bit.
rtl/video/vind_mo_fetch.sv:556 12M LS378C / 12L LS257C / 20F LS32 (sheet 8) and the MO SLAGS half
rtl/video/vind_mo_fetch.sv:602 Every consumer -- the 17D/17E PAL equations, the 14D/14E line buffers and the GPC's M bus -- wants exactly that sense.
rtl/video/vind_mo_linebuf.sv:3 Vindicators — SP-317 sheet 10: the two Atari "LB" line-buffer customs 14D (pixel/colour plane) and 14E (attribute plane), the 14F LS32 bank strobes, the 16F LS32 intensity-kludge gates and the PAL16L8A at 17E (136059-1152) that sequences th
rtl/video/vind_mo_linebuf.sv:12 17E = 136059-1152 -- a dumped PAL, implemented VERBATIM
rtl/video/vind_mo_linebuf.sv:41 Sheet 10 records 17E pin 1 as `21E LS08 (9,10 -> 8) = MCKR & FCLOCK`.
rtl/video/vind_mo_linebuf.sv:87 ---- the LB custom's own output stage -------------------------------- The 40-pin Atari LB does not present the addressed cell straight on DO7..DO0: Gauntlet builds the same buffer out of discrete counters and '189s and still ends it in the
rtl/video/vind_mo_linebuf.sv:121 ---- 14E read side, latched by 18D LS373 on sheet 10 ----
rtl/video/vind_mo_vmatch.sv:3 Vindicators — SP-317 sheet 8: the motion-object VERTICAL MATCH.
rtl/video/vind_mo_vmatch.sv:33 14N S4:S2 is `(diff[5:3] + VSIZ + 1) mod 8` = the TILE ROW within the object counted from the top; it addresses the 82S147 at 11N.
rtl/video/vind_pf.sv:3 Vindicators — the playfield layer: the PFHS custom (15L/M, Atari 137419-104, SP-317 sheet 7), the playfield word decode and bank latch (sheet 8), the graphics-ROM fetch and the PF half of the SLAGS shifters (sheet 9).
rtl/video/vind_pf.sv:8 The PFHS and SLAGS behaviour is derived from `Arcade-Gauntlet_MiSTer/rtl/gauntlet/PFHS.vhd` and `SLAGS.vhd` (c) 2020 d18c7db, GPL-3.0 -- the SAME two Atari customs, whose internals SP-317 does not draw.
rtl/video/vind_pf.sv:14 THE PLAYFIELD WORD (sheet 8)
rtl/video/vind_pf.sv:16 5M LS374A (CK = /4H, /OC = MO//PF) : VRD15..VRD8 Q19 = PFHF (= VRD15, the tile's HORIZONTAL FLIP) and -> 5N D13 Q16,Q15,Q12 -> 5N (VRD14..VRD12) Q9..Q2 = GA11..GA8 3M LS374B (same clocks) : VRD7..VRD0 -> GA7..GA0 5N LS175B
rtl/video/vind_pf.sv:27 PFHS (sheet 7)
rtl/video/vind_pf.sv:29 * a 9-bit latch on HS (/PFHSLD) -- the playfield X scroll; * a 9-bit latch on SPC (/PFSPC) -- the "special" register; * a 6-bit counter loaded with scroll[8:3] at every ST (/PFHST, once per line) and incremented on 4H -> PF8H..PF256H, th
rtl/video/vind_pf.sv:44 PFX AND THE COLOUR ADDRESS (sheet 10, and the ambiguity it raises)
rtl/video/vind_pf.sv:47 Sheet 10 then holds GPC pin 32 (`P4`) at logic 0 through R87 1K / R86 10R, so ONE of the eight PFX bits never reaches the colour address.
rtl/video/vind_pf.sv:117 PF256H..PF8H -> sheet 6's VRAM mux
rtl/video/vind_pf.sv:120 5M Q19 -> 12L LS257C 4B
rtl/video/vind_pf.sv:157 5M / 3M LS374 and 5N LS175B / 6N LS174
rtl/video/vind_pf.sv:173 Either 5N's clock is not the same edge as the 5M/3M word latch (sheet 8 draws it as "[4HD3]", in brackets, i.e. uncertain), or 6N's stage is in the PS0..PS3 path rather than PS4..PS7.
rtl/video/vind_pf.sv:188 Graphics fetch (sheet 9) and the PF half of the SLAGS
rtl/video/vind_pf.sv:191 Row = PF4V/PF2V/PF1V through 12L LS257C's B side.
rtl/video/vind_pf.sv:208 latch 8B in SLAGS.vhd
rtl/video/vind_pf.sv:265 PFHS pins 25..17 take PS7..PS4 from 6N and PSD3..PSD0 STRAIGHT from the SLAGS (sheet 7), so the low nibble enters the delay RAM in the board's active-low sense and the RAM's inverting outputs turn it back into the active-high pen on PFX3..P
rtl/video/vind_pf.sv:280 4D latch, inverted data
rtl/video/vind_prio_gpc.sv:3 Vindicators — SP-317 sheet 10: the PAL16L8A at 17D (136059-1151, MO-pen-1 / SHADE / PF-M priority), the seven 13F/15F LS32 OR gates, the GPC custom 15J/K (Atari 137419-101), the 13J LS253C alpha/MO substitution, the 12F LS174D one-pixel pip
rtl/video/vind_prio_gpc.sv:10 The GPC's internals are derived from `Arcade-Gauntlet_MiSTer/rtl/gauntlet/GPC.vhd` (c) 2020 d18c7db, GPL-3.0 -- the SAME Atari custom (137419-101), whose internals SP-317 draws as a black box.
rtl/video/vind_prio_gpc.sv:13 Every wire around it is Vindicators' own and cited to sheet 10.
rtl/video/vind_prio_gpc.sv:17 17D = 136059-1151 -- a dumped PAL, implemented VERBATIM
rtl/video/vind_prio_gpc.sv:35 `PF/M` on pin 13 is the NET from sheet 7's PFHS custom (the per-playfield- colour "playfield in front of the MO" bit selected out of the /PFSPC register by PFX[2:0]); `PF/M` on GPC pin 18 is a PIN NAME inside the custom's box.
rtl/video/vind_prio_gpc.sv:41 13F / 15F -- the MO bus into the GPC (sheet 10)
rtl/video/vind_prio_gpc.sv:48 THE GPC (sheet 10, internals from the Gauntlet model)
rtl/video/vind_prio_gpc.sv:50 3H latch (H03 & /4H) : D3..D0 = VRD15, VRD10, VRD11, VRD12 3F latch : 3F2 = D3 (alpha OPAQUE), ALC2..ALC0 = D2..D0
rtl/video/vind_prio_gpc.sv:69 Sheet 7 leaves the latched VRD15 as a bare stub and never latches VRD12 at all, and asks where APAL2..APAL0 come from.
rtl/video/vind_prio_gpc.sv:73 APAL4 = D14 and APAL3 = D13 arrive separately from 13M on sheet 7 and are substituted onto CRA8/CRA6 by 13J.
rtl/video/vind_prio_gpc.sv:77 THE COLOUR-RAM ADDRESS (sheet 10)
rtl/video/vind_prio_gpc.sv:86 A8 = CA8 + (SHADE_delayed & CA9) -- 18L LS08 + 13F LS32 A9 = CA9 A10 = STAIN -- 19M/N LS74 through 12F Q7 CPU (via 14K LS257B and 19K LS244N): A10 = MA11, A9 = MA10 (the GPC's MA1/MA0 pins are BOTH tied to M
rtl/video/vind_prio_gpc.sv:108 Sheet 10 records the GPC's alpha attribute pins as D3 = VRD15, D2 = VRD10, D1 = VRD11, D0 = VRD12 -- a scrambled order (Xybots' GPC is scrambled too, differently).
rtl/video/vind_prio_gpc.sv:141 ---- CPU / colour-RAM select (sheet 6) ----
rtl/video/vind_prio_gpc.sv:184 The GPC's own 3H latch takes the raw alpha attribute nibble off VRD on the same edge as sheet 7's 14M/14L: the ce_7m edge that ENDS the alpha slot (phase 3), which is 4H's rising edge.
rtl/video/vind_prio_gpc.sv:196 3F latch
rtl/video/vind_prio_gpc.sv:204 only VRD15, VRD12..VRD10 reach the GPC's D pins (sheet 10).
rtl/video/vind_prio_gpc.sv:232 12F LS174D -- the one-pixel pipeline (CK = FCLOCK)
rtl/video/vind_prio_gpc.sv:267 13J LS253C and the 11-bit CRAM address
rtl/video/vind_prio_gpc.sv:275 /PRAM = ~/CLRAM, so /PRAM is low (13J driving) in every video slot and high (13J tri-stated) in a CPU colour-RAM cycle -- where 19K LS244N drives CRA8..CRA1 from MA8..MA1 instead.
rtl/video/vind_syngen.sv:4 Carried over from the Xybots core (SP-313 sheet 4, the same Atari part on the same crystal) and re-verified against SP-317 sheet 6.
rtl/video/vind_syngen.sv:15 SP-317 draws only its pinout, so its internal behaviour is reconstructed from the *same part* as implemented discretely on Atari System 1 (SP-277) and modelled in `Arcade-Gauntlet_MiSTer/rtl/gauntlet/SYNGEN.vhd` (d18c7db, GPL-3.0) + its `RO
rtl/video/vind_syngen.sv:22 * a 9-bit horizontal counter cleared by NXL, * an 82S153 PLA (Atari 136032-103) decoding H into NXL/HSYNC/HBLANK/LMPD/PFHST/BUFCLR/C0/C1/C2, all of them taken through one register (the "7E" 74S174), * an 8-bit vertical counter plus one extr
rtl/video/vind_syngen.sv:41 PIN DIRECTIONS, AS READ OFF SP-317 SHEET 6
rtl/video/vind_syngen.sv:43 This module started as the Xybots core's SYNGEN (SP-313 sheet 4, the same Atari custom on the same 14.318181 MHz crystal), so it carries the UNION of the two boards' pin sets and vind_video ties off what Vindicators leaves bare.
rtl/video/vind_syngen.sv:46 SP-317 sheet 6 is the authority for this board:
rtl/video/vind_syngen.sv:57 Three differences from the Xybots reading, all from sheet 6: * NXL (pin 21) IS wired here -- it starts the SLIP fetch once per line, and PAL 7N's own product terms fix its phase (see section 2 below); * /PFHST (pin 28) IS wired here -- Vind
rtl/video/vind_syngen.sv:66 The vertical counter is inside the custom -- there is no 256V net anywhere in the package, which is why the line total can only come from its own dumped PROM (see above).
rtl/video/vind_syngen.sv:97 Designators are SP-313 sheet 4's; on SP-317 sheet 6 the same squarers are 23F ----
rtl/video/vind_syngen.sv:99 14M (8B 74S04 1->2)
rtl/video/vind_syngen.sv:100 /14MP (8B 74S04 13->12)
rtl/video/vind_syngen.sv:101 7M (7B 74S74 Q)
rtl/video/vind_syngen.sv:102 /7M (7B 74S74 /Q)
rtl/video/vind_syngen.sv:103 DCLK (9B 74S74 Q)
rtl/video/vind_syngen.sv:104 RCLK (1C 74S74 Q, /PRE = DCLK)
rtl/video/vind_syngen.sv:105 VIDCLK (11J 74S04 3->4 from /CKO)
rtl/video/vind_syngen.sv:106 /VIDCLK (8B 74S04 9->8 from CKO)
rtl/video/vind_syngen.sv:129 10E 74S00 (1,2->3)
rtl/video/vind_syngen.sv:130 11J 74S04 (9->8)
rtl/video/vind_syngen.sv:132 11J 74S04 (11->10)
rtl/video/vind_syngen.sv:134 11J 74S04 (1->2)
rtl/video/vind_syngen.sv:142 ---- video-RAM access phase (sheet 5 LS253 select) ----
rtl/video/vind_syngen.sv:143 8M 74S32 (4 = /2HD1H, 5 = 4HD2H -> 6)
rtl/video/vind_syngen.sv:155 ---- interrupt ---- Sheet 2: 1B LS02 (11 = VBLANK, 12 = /HBLANK -> 13) then 10A LS20 with 4V,2V,1V then 4A LS04 (9->8).
rtl/video/vind_syngen.sv:157 The IRQ1 latch is set by `virq_gate & VIRQ`, where VIRQ is alpha-RAM bit 10 latched by 6D LS174E on sheet 7 (see vind_alpha.sv).
rtl/video/vind_syngen.sv:162 ---- SP-317 sheet 6 pin usage ------------------------------------------- Vindicators wires SIX SYNGEN pins that Xybots leaves as stubs, and leaves six that Xybots uses.
rtl/video/vind_syngen.sv:164 The Vindicators pin map, from sheet 6:
rtl/video/vind_syngen.sv:167 pin 22 C2 -> H03 source (via 6F LS174C) -> vrac2
rtl/video/vind_syngen.sv:168 pin 25 LMPD -> /LMPD -> mohr_n pin 35 4HDL -> PF//MO -> h_4hd1h_n pin 36 4HDD -> /4HDD -> h_4hd2h_n and pins 23 (C1), 24 (C0), 34 (4H), 18 (VSCK), 33 (2HDL), 17 (VRES
rtl/video/vind_syngen.sv:175 The Vindicators SYNGEN symbol has no BUFCLR pin (all 40 pins are accounted for on sheet 6), and Gauntlet -- the same custom set -- makes the net in discrete logic as /BUFCLR = /LMPD + /4H + 2H + /1H (`Arcade-Gauntlet_MiSTer/rtl/gauntlet/VID
rtl/video/vind_syngen.sv:187 SYNGEN pin 21 -- /PNXL (wired on SP-317)
rtl/video/vind_syngen.sv:194 clk_sys phase, and the 14M / MCKR chain (SP-317 sheet 6)
rtl/video/vind_syngen.sv:212 7B 74S74: D = /7M, CK = 14M -> divide by two, rising with ce_7m.
rtl/video/vind_syngen.sv:216 9B 74S74: D = /7M, CK = /14MP.
rtl/video/vind_syngen.sv:223 1C 74S74: D = 7M, CK = 14M, /PRE = DCLK (asynchronous), /CLR = PR1 = 1.
rtl/video/vind_syngen.sv:233 SYNGEN CKO (pin 29) = CK, /CKO (pin 4) = ~CK; both are re-inverted on the board, so VIDCLK is in phase with 7M and is the 68000 clock (sheet 2).
rtl/video/vind_syngen.sv:239 SYNGEN horizontal PLA (Atari 136032-103 / 82S153), inside the SYNGEN black box on SP-317 sheet 6
rtl/video/vind_syngen.sv:248 SP-317 PHASE CORRECTION FOR PIN 21 (/PNXL).
rtl/video/vind_syngen.sv:249 On SP-313 pin 21 is a bare stub, so nothing there could observe where the NXL pulse sits relative to 1H/2H/4H, and the System-1 model simply reuses the counter-clear term.
rtl/video/vind_syngen.sv:251 On SP-317 the pin is wired, and PAL 7N is hard evidence for its phase: every NXL product term in 7N's equations is qualified by `1H & 2H & 4H`, i.e. PHASE 7, and only with NXL there do the three consumers agree -- * PVAS1:PVAS0 = 10 at phas
rtl/video/vind_syngen.sv:284 o16 (C0) and o11 stay unimplemented: pin 24 is a bare stub on SP-317 sheet 6 as well as on SP-313 sheet 4, and the System-1 PLA's /o11 (/BUFCLR) has no pin in the Vindicators symbol -- see the port comment.
rtl/video/vind_syngen.sv:287 o12 (/PFHST) IS wired on SP-317 (pin 28 -> sheet 7's PF vertical counter and PFHS `ST`), so its System-1 PLA term is implemented here: /o12 = i4 & i5 & i6 & /i7 & i8 & i9 (h[8:3] == 6'b110111) with i1..i9 = h[0]..h[8].
rtl/video/vind_syngen.sv:297 SYNGEN vertical PROM (Atari 136032-102, 256 x 4), inside the SYNGEN black box on SP-317 sheet 6
rtl/video/vind_syngen.sv:331 The counters and the SYNGEN output register (74S174 "7E" / "7D")
rtl/video/vind_syngen.sv:392 Glue around SYNGEN (IC designators are SP-313 sheet 4's; the same circuit sits on SP-317 sheet 6)
rtl/video/vind_syngen.sv:402 8B 74S04
rtl/video/vind_syngen.sv:406 10E 74S00
rtl/video/vind_syngen.sv:408 11J 74S04
rtl/video/vind_syngen.sv:414 8M 74S32: VRAC0 = /2HD1H | 4HD2H.
rtl/video/vind_syngen.sv:419 g3b/g6b are the two unnamed intermediate nets on SP-313 sheet 4; /MOHR itself comes out of SYNGEN pin 25.
rtl/video/vind_testpat.sv:7 4 bits per channel, matching the CRAM's I:R:G:B 4:4:4:4 word (SP-317 sheet 10); full intensity only.
rtl/video/vind_video.sv:3 Vindicators video top — SP-317 sheets 6 (VRAM/SYNGEN), 7 (ALPHA), 8 (MO-CTRL), 9 (GR-MEM), 10 (line buffers / priority / GPC / CRAM) and 11 (RGBI DAC), plus the sheet-5 common-bus signals that terminate here.
rtl/video/vind_video.sv:11 ---- the sheet-5 question this module answers --------------------------- Sheet 5's ECPU half is not populated, so /ECOM is never asserted, the 23D LS158A mux is held permanently on the main CPU's side and the main CPU is granted the common
rtl/video/vind_video.sv:104 The SYNGEN model is shared with the Xybots core, so it carries the union of the two boards' pin sets; the six pins Vindicators leaves as bare stubs on SP-317 sheet 6 are tied off here.
rtl/video/vind_video.sv:141 Sheet 6 -- VRAM, the address multiplexers and the CPU slot
rtl/video/vind_video.sv:177 Sheet 7 -- alphanumerics, control words, PF vertical counter
rtl/video/vind_video.sv:264 Priority, GPC and the colour-RAM address (sheet 10)
rtl/video/vind_video.sv:290 Colour RAM (sheet 10)
rtl/video/vind_video.sv:306 /CLRAM is decoded from MA16 alone (sheet 6) and MA16 holds for the whole cycle, so it is what the mux takes.
rtl/video/vind_video.sv:342 The DAC's blanking is not a decoration: on sheet 10 /VIDBL ASYNCHRONOUSLY CLEARS the 17M/17L output registers, i.e. it acts on the pixel that is in those registers at that instant.
rtl/video/vind_vram.sv:3 Vindicators — SP-317 sheet 6 (`VRAM`): the four 8Kx8 static RAMs, the six 74LS253 + 3J LS257A address multiplexers, the CPU read/write path, the 6F LS174C / 11F LS175A pipeline registers and the 7L/7J LS378 MO link register.
rtl/video/vind_vram.sv:9 Structure follows the Xybots MiSTer core's video blocks (GPL-3.0); every equation here is Vindicators' own and cited to sheet 6.
rtl/video/vind_vram.sv:15 1M/2M carry VRD15..VRD8, 2N/1N carry VRD7..VRD0; `VRA14` and `/VRA14` are the two banks' CS2 and `VRA13..VRA1` are A12..A0, so the store is 16384 x 16 addressed by VRA14:VRA1 and VRAn == 68010 byte-address bit n. `VRA15` lands on pin 1, a N
rtl/video/vind_vram.sv:32 The video side drives VRA14:VRA13 = VAS1B:VAS0 (3J LS257A section 3/4), so each client lands in its own 8 KB quadrant, and the six LS253s pick VRA12..VRA1:
rtl/video/vind_vram.sv:53 7D LS02 : n = ~(DTACK + /VRAM) 9F LS11 : PVCPU = PVAS0 & PVAS1 & n -> sheet 4's wait counter 6F : VCPU = registered PVCPU 20F LS32: /VRAMRD = /VRAM + W//R 20E LS00: VR//W = ~(W//R & VCPU) 17F LS04: VW//R = ~VR//W 5F
rtl/video/vind_vram.sv:81 ---- SYNGEN taps (sheet 6) ----
rtl/video/vind_vram.sv:88 ---- slot selector from the sheet-8 PAL 7N (one RCLKA ahead) ----
rtl/video/vind_vram.sv:98 ---- CPU side (the raw 68010 bus, NOT the common bus -- sheet 6) ----
rtl/video/vind_vram.sv:101 sheet 4 4J LS139 Y3 (0x3E0000-0x3FFFFF)
rtl/video/vind_vram.sv:102 sheet 4 24D LS04 pin 4 (1 = write)
rtl/video/vind_vram.sv:106 -> sheet 4's DTACK wait term
rtl/video/vind_vram.sv:110 ---- colour-RAM select, exported to sheet 10 ----
rtl/video/vind_vram.sv:136 11F 74LS175A -- CK = RCLKA, /CLR = PR3 (never cleared)
rtl/video/vind_vram.sv:167 6F 74LS174C -- CK = RCLKA, /CLR = PR3
rtl/video/vind_vram.sv:208 6L LS253F's /2G is tied to GND, so VRA12 is never tri-stated by NXLDL; VRA11..VRA7 are, and RP2 then pulls them to 1 (alpha row 31).
rtl/video/vind_vram.sv:213 3J LS257A -- SEL = VCPU selects the B (CPU) inputs
rtl/video/vind_vram.sv:234 A CPU VRAM write lands only when /PRAM is low (A16 == 1); with A16 == 0 the same strobes drive the colour RAM on sheet 10.
rtl/video/vind_vram.sv:279 Transparent is the operative word: `q` is clk_sys-registered (section 6) so it already carries the CPU slot's word within that slot, and the sheet-4 LS163A asserts /DTACK **inside the slot** -- a latch that only captured after it would deli
rtl/video/vind_vram.sv:293 7L / 7J 74LS378 -- the MO link register
rtl/vind_core.sv:5 The four blocks below together model the SP-317 game board and the JSA I audio board:
rtl/vind_core.sv:8 vind_mem program EPROMs (sheet 4) and graphics ROMs (sheet 9), both held in SDRAM; the 15/16N character ROM; the MiSTer ROM download path and the sound-ROM write stream vind_main_bus sheets 2/3/4 — 68010 (TG68K), PAL 3C decode, LS163
rtl/vind_core.sv:21 ONE clock domain, clk_sys = 57.272727 MHz = 4 x the 14.318181 MHz crystal (sheet 6), with integer clock enables and no fractional enables anywhere.
rtl/vind_core.sv:29 ce_6502 = clk_sys / 32 = 1.789772 MHz JSA I 6502 ce_b4h = /B4H, the SCOM shift clock = 4H inverted (sheet 3, 17F), one pulse per rising edge of /B4H = falling edge of the SYNGEN 4H tap, 894.886 kHz
rtl/vind_core.sv:39 ---- the one deliberate departure from the sheets: `prog_stall` ------------ Sheet 4 gives program-ROM cycles ZERO wait states and vind_main_bus implements that literally.
rtl/vind_core.sv:93 [7] = Pn-S8, which sheet 13 wires as Left Trigger, Right Trigger, Left Thumb, Right Thumb, Left Forward, Right Forward, Left Back, Right Back (= MAME 0x260000 D8..D15).
rtl/vind_core.sv:311 /B4H (sheet 3, 17F LS04 = ~4H): the SCOM/LETA/ADC clock.
README.md:112 Every operator setting — difficulty, lives, coinage, tank damage, bookkeeping — lives in the on-board Atari 2804A EEPROM at 1C and is edited from the game's own
README.md:146 | Program ROM | 384 KB (six 27512s at 1D/2D, 1F/2F, 1K/2K), streamed from SDRAM behind a 32-word line cache |
README.md:147 | Sound board | Atari JSA I (A043713): 6502 @ 1.7897725 MHz + YM2151 @ 3.579545 MHz + **POKEY** @ 1.7897725 MHz. The TMS5220C at 3D is **not populated** and is
README.md:153 | Priority | PAL16L8 **17D** (`136059-1151`, the dumped fuse map, used verbatim) + the GPC custom at 13J |
README.md:187 **Schematic provenance** — every sheet of SP-317 that carries logic (2–11 for the game board, 14–17 for the audio board) was transcribed before any RTL was writ
README.md:232 It is where the SP-317 schematics document something MAME's model does not — and in one case MAME's own source flags the gap.
README.md:238 | **Playfield / motion-object priority** | "the MO wins unless `mopriority & 4`"; `/PFSPC` is a no-op | the decision the board actually makes, in **PAL 17D** (`
README.md:241 | **Lines per frame** | `set_raw(..., 262, ...)`, 59.923 Hz, above a comment saying these are *"from published specs, not derived"* | **263 lines, 59.696 Hz.**
README.md:245 | **Self-test switch source** | read from `0x260010` **bit 12** — which is a P2 stick switch, not a service switch | the cabinet service switch, routed to the a
README.md:248 | **Colour-RAM write during the picture** | the new colour simply takes effect; nothing else on the line changes | the CPU and the video share the colour RAM's
README.md:252 **Priority and SHADE.** These are the two divergences with a real chance of changing a pixel, and they are also the two where the hardware evidence is strongest
… 5 more

Notes where it differs from MAME — 5

rtl/video/vind_cram.sv:25 MAME does not model any of this.
rtl/video/vind_intensity_dac.sv:88 MAME does NOT compute this sum.
README.md:12 Where a schematic and MAME disagree, the schematic wins and the disagreement is recorded: see [Where this core differs from MAME](#where-this-core-differs-from-
README.md:229 Where this core differs from MAME
README.md:232 It is where the SP-317 schematics document something MAME's model does not — and in one case MAME's own source flags the gap.

Cites MAME source — 68

Arcade-Vindicators.sv:10 Vindicators runs on a HORIZONTAL monitor (MAME ROT0), so there is no rotation; the Orientation option only offers a 180-degree flip.
Arcade-Vindicators.sv:158 Per-player switch word, ACTIVE HIGH ("pressed"), in the order of the panel switches Pn-S1..Pn-S8 on SP-317 sheet 13 (= MAME 0x260000 D8..D15); see the port comment in vind_core.sv.
rtl/main/vind_eeprom_2804.sv:32 Exactly one write per unlock: this is the hardware behind MAME's `EEPROM_2804 ...
rtl/main/vind_eeprom_2804.sv:128 Nothing pulls D0-D7 down, so the modelled float value is 0xFF — also MAME's unmapped read.
rtl/main/vind_inputs.sv:24 MAME's `0x0100 = Left Stick Fire` therefore corresponds to Pn-S1, which is the mapping used here.
rtl/main/vind_inputs.sv:39 Neither is populated on Vindicators (sheet 12 lists no analog entry, MAME declares the low bytes IPT_UNUSED, and the cabinet has only twin digital sticks), so those lanes read the floating/pulled-up bus = **0xFF**.
rtl/main/vind_main_bus.sv:16 The memory map, the wait-state table and the schematic-vs-MAME decisions are documented in the submodule headers; this one records the composition.
rtl/main/vind_main_bus.sv:356 There is no bus-error timeout (BERR is tied to PR3), so such a cycle still gets DTACK with 0 waits and reads the pulled-up/floating value, modelled as 0xFFFF — which is also MAME's `unmap_value_high()`.
rtl/main/vind_out_latch.sv:30 MAME `nopw()`s this address.
rtl/mem/vind_char_rom.sv:17 That is MAME's `anlayout` exactly: 2 planes at bit offsets {0, 4}, xoffsets {0,1,2,3, 8,9,10,11}, 8*16 bits per character.
rtl/mem/vind_char_rom.sv:21 Unlike the graphics ROMs this data is NOT inverted anywhere: MAME applies ROMREGION_INVERT to `sprites_pf` only, and sheet 7's shifters take the ROM bits straight.
rtl/mem/vind_gfx_mem.sv:27 The MRA emits MAME's `sprites_pf` region as a four-way byte interleave of the planes, plane 0 first, so those four bytes are consecutive in SDRAM and the fetch is one 2-word burst:
rtl/mem/vind_gfx_mem.sv:44 (MAME's ROMREGION_INVERT is the same fact applied at load time; this core keeps the board's polarity so sheet 10's PAL equations can be written verbatim.) then drop *_req; the arbiter waits for the drop, so one request = exactly on
rtl/mem/vind_rom_loader.sv:17 stream base size MAME region destination
rtl/mem/vind_rom_loader.sv:28 * maincpu is emitted as BIG-ENDIAN INTERLEAVED WORDS — the MAME even-offset ROM (the `1x` sockets 1D/1F/1K, sheet 4, D15:8) is `map="01"`, the FIRST byte of each output word.
rtl/video/vind_alpha.sv:25 11M LS138 : G1 = 256H, /G2A = /HBLANK, /G2B = ~(MO//PF & 1V & 2V & 4V) SELC:SELB:SELA = AP11:AP10:AP9 Y2 /PFB playfield bank latch (AP3..AP0 -> GA15..GA12) Y3 /PFHSLD PFHS HS -- playfield X scroll, AP8..AP0 Y4 /MOHS MO X-scroll latch
rtl/video/vind_alpha.sv:36 MAME's `configure_scanline(..., 0, 8)` with `offset = ((scanline - 8) / 8) * 64 + 42` is the same thing said one line later.
rtl/video/vind_alpha.sv:49 That is exactly MAME's `anlayout` (planeoffset {0,4}, xoffset {0,1,2,3,8,9,10,11}) with planeoffset[0] the pen MSB.
rtl/video/vind_alpha.sv:58 Its outputs are the playfield tilemap row, the SLIP band index (PFV >> 3) and the MO vertical-match operand -- so the motion objects share the playfield's vertical scroll, exactly as MAME's `set_yscroll()` does.
rtl/video/vind_intensity_dac.sv:15 The kludge only fires when MAT6 and MSD3 are both set, where 16F LS32 lets MAT3..MAT1 through (the ACTIVE-LOW nets, i.e. the complement of the logical colour bits) -- exactly MAME's `if (mo[x] & 8) pf[x] |= (~mo[x] & 0xe0) << 6;`.
rtl/video/vind_intensity_dac.sv:47 MAME uses an exact `*15` multiply and the 17-step table ztable[] = { 0, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e, f, 10, 11 } whose shape (0 at code 0, n+2 for n >= 1) reproduces R121's threshold and R120's pedestal but not the ladder's curvature
rtl/video/vind_intensity_dac.sv:91 Hardware's idle MOG is 111, so `INT + 2*7 + 2 = INT + 16 = INT` and the two agree for ordinary pixels -- but on a kludge pixel hardware gives `INT + 2*MOG + 2` where MAME gives `INT + 2*MOG`, i.e. the hardware is TWO ztable steps higher.
rtl/video/vind_intensity_dac.sv:94 That is a real difference between the two, so DAC_MAME_COMPAT reproduces MAME's arithmetic as well as its table.
rtl/video/vind_intensity_dac.sv:139 MAME's ztable, and the resistor-derived intensity curve.
rtl/video/vind_intensity_dac.sv:180 MAME multiplies exactly; the hardware weights are 1.000 / 1.958 / 3.917 / 7.581, summing to 14.456, scaled by 15/14.456.
rtl/video/vind_intensity_dac.sv:203 The divisor puts the full-scale product (colour 15 x intensity 15) at 255 on both paths: MAME 240*272/256 = 255, hardware 240*282/265 = 255.
rtl/video/vind_intensity_dac.sv:214 Every entry is the integer result of that arithmetic (DIV = 256 for MAME's ztable, 265 for the resistor ladder) applied to the c16/z16 functions above.
rtl/video/vind_mo_fetch.sv:60 11N 82S147 (512x8) and 9J 82S129 (256x4) are NOT in the MAME ROM set and cannot be read off the drawing.
rtl/video/vind_mo_fetch.sv:61 Their FUNCTION is fixed by their wiring plus `atarimo.cpp`, and both are reconstructed here:
rtl/video/vind_mo_fetch.sv:81 MAME wraps X with `xpos & 0x1ff` and never clips, so no HPOS-dependent shortening is modelled; the HPOS inputs exist on the board to stop an object that would run off the end of the 512-entry line buffer, which cannot happen with a wrapping
rtl/video/vind_mo_fetch.sv:403 The columns start at phase 3 of the lock cell, one per cell, so the object is P + 1 = HSIZ + 1 columns wide -- MAME's `width`.
rtl/video/vind_mo_fetch.sv:406 A preset of `HSIZ + 1` instead draws ONE EXTRA column of the tile past the object's right edge on every object wider than one tile, as a pixel comparison against MAME shows.
rtl/video/vind_mo_fetch.sv:493 4M drives GA15..GA8 from the code word's high byte; 8N/7M add the offset into the LOW byte only, so the sum wraps at 256 -- a real hardware limit MAME does not have, and a deliberate difference from it.
rtl/video/vind_mo_fetch.sv:599 MSD3..MSD0 leave the SLAGS in the board's ACTIVE-LOW pixel sense: the ROM bytes arrive raw (the data lines carry 4.7K pull-ups, and MAME models the same fact with ROMREGION_INVERT at load time), so no inversion is needed here.
rtl/video/vind_mo_linebuf.sv:62 -- so a "special" object (priority bit 6) leaves the PIXEL plane untouched ("no draw", MAME's `if (mopriority & 4) continue;`) but still deposits its stain markers in the ATTRIBUTE plane.
rtl/video/vind_mo_linebuf.sv:64 /STON is exactly MAME's `START_MARKER = (4 << PRIORITY_SHIFT) | 2` and /STOFF its `END_MARKER = (4 << PRIORITY_SHIFT) | 4`.
rtl/video/vind_mo_linebuf.sv:96 It is measured the same way `vind_pf.sv`'s PFX_ALIGN is: at 1 the motion objects land on MAME's `xpos = X - xscroll` in every frame capture, at 0 they are one pixel to the left.
rtl/video/vind_mo_vmatch.sv:21 so /VMATCH is asserted exactly for -8*(VSIZ+1) <= diff <= -1: the object covers the 8*(VSIZ+1) scanlines ABOVE the row where PFV == ~Y. That is the same "negate Y, subtract the height" rule MAME uses (`ypos = -ypos; ypos -= yscroll; ypos
rtl/video/vind_mo_vmatch.sv:30 MAME simply does not render outside the visible area -- a different mechanism, same result.
rtl/video/vind_pf.sv:16 5M LS374A (CK = /4H, /OC = MO//PF) : VRD15..VRD8 Q19 = PFHF (= VRD15, the tile's HORIZONTAL FLIP) and -> 5N D13 Q16,Q15,Q12 -> 5N (VRD14..VRD12) Q9..Q2 = GA11..GA8 3M LS374B (same clocks) : VRD7..VRD0 -> GA7..GA0 5N LS175B
rtl/video/vind_pf.sv:39 MAME treats /PFSPC as a no-op (`case 5: break;`), so this whole input to the priority decision is absent from MAME; the core implements it.
rtl/video/vind_pf.sv:54 MAME (whose picture is known good) computes 0x200 + 32*((data>>12)&7) + pen, i.e. colour = VRD14:VRD12 in bits 7:5 with bit 4 always zero.
rtl/video/vind_pf.sv:58 The two readings differ by exactly one position, and only the MAME one is physically sensible (a flip bit is not a palette bit).
rtl/video/vind_pf.sv:109 MAME's ROMREGION_INVERT is the same fact applied at load time; this core keeps the board's polarity so sheets 7/10's PAL equations can be written verbatim.
rtl/video/vind_prio_gpc.sv:110 Taken literally the alpha colour address puts D10 in bit 4 and D12 in bit 2, while MAME's `color = ((data >> 10) & 0x0f) | ((data >> 9) & 0x20)` puts D12 in bit 4 and D10 in bit 2.
rtl/video/vind_prio_gpc.sv:113 ALPHA_D_MAME = 1 selects the descending order D3..D0 = VRD15, VRD12, VRD11, VRD10 that reproduces MAME.
rtl/video/vind_syngen.sv:32 The one place it does NOT agree with MAME is the total line count: this model gives **263 lines**, MAME's `set_raw` says 262.
rtl/video/vind_syngen.sv:34 MAME's own comment at that line notes that its parameters are taken from published specs rather than derived, and that the board uses a SYNGEN chip to generate video signals, so the derived value is used here.
rtl/video/vind_syngen.sv:37 Frame rate 7 159 090 / (456*263) = 59.696 Hz instead of MAME's 59.923 Hz.
rtl/video/vind_syngen.sv:112 visible pixel index = h - 9 (MAME hpos)
rtl/video/vind_video.sv:26 With PIPE_DLY = 2 the rendered frame sits at offset (0, 0) against MAME frame captures.
rtl/video/vind_vram.sv:15 1M/2M carry VRD15..VRD8, 2N/1N carry VRD7..VRD0; `VRA14` and `/VRA14` are the two banks' CS2 and `VRA13..VRA1` are A12..A0, so the store is 16384 x 16 addressed by VRA14:VRA1 and VRAn == 68010 byte-address bit n. `VRA15` lands on pin 1, a N
rtl/vind_core.sv:93 [7] = Pn-S8, which sheet 13 wires as Left Trigger, Right Trigger, Left Thumb, Right Thumb, Left Forward, Right Forward, Left Back, Right Back (= MAME 0x260000 D8..D15).
README.md:24 All eight MAME sets run on identical RTL.
README.md:51 | ROMs | Supplied by you from a MAME archive; none are included here |
README.md:107 (The sibling Xybots board does swap them; this one does not, and MAME agrees.)
README.md:133 It acts on the output side only (`rtl/video/vind_analog_adjust.sv`): the native 456 × 263 raster, the 7.159 MHz dot clock and the 59.696 Hz refresh are untouche
README.md:199 **Main CPU boot** — the 68010 bus is co-simulated against MAME 0.289 through reset, the RAM and ROM tests, the EEPROM unlock protocol and the scanline interrupt
README.md:204 **Video** — MAME is instrumented to capture complete video state (alpha, playfield and motion-object RAM plus the palette) at chosen frames; those states are re
README.md:212 **Sound** — the JSA I board is compared to MAME: the 6502's I/O accesses and the YM2151 register stream in order and in value, the SCOM command / response hands
README.md:231 MAME is this project's functional oracle and every check above measures the core *against* it, so this is a narrow list, not a general claim.
README.md:236 | Behaviour | MAME | This core |
README.md:254 The frame comparisons run against MAME's own rendered output and pass, so on the captured frames the two models agree; the difference is in what happens on fram
README.md:259 **The 57-object limit.** MAME draws every entry a list contains.
README.md:267 A `DAC_MAME_COMPAT` parameter selects MAME's curve so the frame comparisons can match bit for bit; the shipping build uses the schematic's.
README.md:271 **The colour-RAM write.** Vindicators writes its palette only outside the visible picture once it has booted — a MAME trace of 10,740 attract frames logged no c
README.md:323 The YM2151 : POKEY mix balance** is 2.98 : 1, computed from the sheet-16 resistor network, against MAME's 1.5 : 1.
README.md:390 Thanks to the MAME team, whose `vindictr.cpp`, `atarijsa.cpp` and `atarimo.cpp` served as the functional oracle throughout, and to whoever preserved the Atari S

Says it matches, follows or was checked against MAME — 12

rtl/mem/vind_rom_loader.sv:32 Getting this backwards byte-swaps every opcode and the CPU fetches a garbage reset vector with no error anywhere, so the assembled region is checked by CRC against MAME's own :maincpu region, 04f2ff51.
rtl/video/vind_cram.sv:13 So the CRAM word is INT3-0 : RED3-0 : GRN3-0 : BLU3-0 = D15..D0, matching MAME's `paletteram_w`, and the two byte lanes are written INDEPENDENTLY through their own /WE terms (which is how /UDS and /LDS are honoured).
rtl/video/vind_intensity_dac.sv:51 `DAC_MAME_COMPAT = 1` selects MAME's table and its exact multiply, for bit-exact comparison against MAME's rendering; the release build uses the resistor-ladder transfer, which is the default.
rtl/video/vind_intensity_dac.sv:60 1 = MAME's ztable and its exact multiply, for bit-exact comparison against MAME's rendering.
rtl/video/vind_intensity_dac.sv:113 Written literally as a synchronous clear in a pixel-quantised core it costs a WHOLE pixel -- the register is still holding zero throughout the first pixel after /VIDBL releases -- and the picture loses its leftmost column: one mismatching p
rtl/video/vind_mo_fetch.sv:619 Without it every motion object lands two pixels left of MAME's `xpos = X - xscroll`; with it the layer is pixel-exact against MAME frame captures.
rtl/video/vind_pf.sv:169 Sheets 7 and 8 draw two (5N then 6N), but the pen bits reach PFHS straight off the SLAGS, and the two paths only line up if the colour is one stage shorter than the drawing reads; with one stage the playfield is pixel-exact against MAME fra
rtl/video/vind_pf.sv:291 With PFX_ALIGN = 2 the playfield and the alphanumerics land on the same raster phase and the picture is pixel-exact against MAME frame captures.
rtl/video/vind_prio_gpc.sv:94 (that is the ALPHA_D_MAME = 1 order, the default, and it is IDENTICAL to MAME's; ALPHA_D_MAME = 0 reverses the D12/D10 run to the literal sheet-10 pin order) MO 0x100 | colour<<4 | pen
rtl/video/vind_prio_gpc.sv:100 All three rows agree with MAME exactly once ALPHA_D_MAME is set -- which is the default, and which is verified pixel-exact against MAME frame captures.
rtl/video/vind_video.sv:350 Delayed, the picture is pixel-exact against MAME frame captures.
rtl/vind_core.sv:62 1 selects MAME's ztable transfer instead of the sheet-11 resistor ladder, for bit-exact comparison against MAME; the release build uses the ladder.

Shares text with the MAME driver without saying so — 8

rtl/mem/vind_char_rom.sv:19 {0,1,2,3, 8,9,10,11}, 8*16 bits per character. — shares text with atari/vindictr.cpp:492
rtl/video/vind_alpha.sv:37 `offset = ((scanline - 8) / 8) * 64 + 42` is the same thing said one line — shares text with atari/vindictr.cpp:207
rtl/video/vind_alpha.sv:50 (planeoffset {0,4}, xoffset {0,1,2,3,8,9,10,11}) with planeoffset[0] the — shares text with atari/vindictr.cpp:492
rtl/video/vind_intensity_dac.sv:18 `if (mo[x] & 8) pf[x] |= (~mo[x] & 0xe0) << 6;`. — shares text with atari/vindictr.cpp:359
rtl/video/vind_intensity_dac.sv:91 pass, `pf[x] |= (~mo[x] & 0xe0) << 6`). Hardware's idle MOG is 111, so — shares text with atari/vindictr.cpp:360
rtl/video/vind_mo_linebuf.sv:65 `START_MARKER = (4 << PRIORITY_SHIFT) | 2` and /STOFF its `END_MARKER — shares text with atari/atarimo.cpp:241
rtl/video/vind_prio_gpc.sv:112 while MAME's `color = ((data >> 10) & 0x0f) | ((data >> 9) & 0x20)` puts — shares text with atari/vindictr.cpp:102
rtl/video/vind_syngen.sv:36 and that the board uses a SYNGEN chip to generate video signals, so the — shares text with atari/vindictr.cpp:548

Xevious#
Super Xevious, Xevious
MiSTer-devel/Arcade-Xevious_MiSTer @ 2b9e12df
MAME compared: namco/xevious.cpp + 12 related file(s)
Read: 24 HDL files, 7,767 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

22%

Statements: 1 toward MAME

Cites MAME source — 1

rtl/xevious.vhd:39 Use with MAME roms from xevious.zip

XSleena#
Xain'd Sleena
MiSTer-devel/Arcade-XSleena_MiSTer @ aee6831a (matched by date)
MAME compared: technos/xain.cpp + 2 related file(s)
Read: 49 HDL files, 16,034 lines (Quartus project)

MiSTer official

Mostly hardware

low

33%

Statements: 10 toward hardware, 3 toward MAME

Cites hardware documentation that MAME's driver does not — 9

rtl/XSleenaCore.sv:215 SHARED SIGNALS BETWEEN TOP AND BOTTOM BOARDS See schematics pages 10A and 10B
rtl/XSleenaCore_RGB4bitLUT.sv:5 LUT data calculated from LT Spice simulation recreating ASO schematics normalized and hex converted using the following python script: from matplotlib import pyplot as plt import numpy
rtl/XSleenaCore_SoundCPU.sv:46 *** Sound Cpu (Schematics page 7B,8B) ***
rtl/XSleenaCore_cpuA_B.sv:131 *** Main CPU (Schematics page 1B) ***
rtl/XSleenaCore_cpuA_B.sv:500 *** Sub Cpu (Schematics page 2B) ***
rtl/XSleenaCore_cpuA_B.sv:845 *** Shared SRAM (Schematics page 2B) ***
rtl/ttl_sync/ttl_74161_sync.v:1 4-bit modulo 16 binary counter with parallel load, *** FOR SYNTHESIS *** Asynchronous Reset (MRn) -> LS163A <START_TEMPLATE> ttl_74161a #(.DELAY_RISE(20), .DELAY_FALL(25)) <NAME> (.Clear_bar(), .Load_bar(), .ENT(), .ENP(), .D(), .Clk(), .RC
rtl/ttl_sync/ttl_74163a_sync.v:1 4-bit modulo 16 binary counter with parallel load, *** FOR SYNTHESIS *** Synchronous Reset (SRn) -> LS163A <START_TEMPLATE> ttl_74161a #(.DELAY_RISE(20), .DELAY_FALL(25)) <NAME> (.Clear_bar(), .Load_bar(), .ENT(), .ENP(), .D(), .Clk(), .RCO
rtl/ttl_sync/ttl_74374_sync_noHiZout.sv:1 ttl_74374.sv Octal D edge triggered FF function table, logic diagrams and switching characteristics extracted from TI 74LS374 Datasheet.

Ships hardware documentation files — 1

doc/Arkanoid_schema.pdf

Shares text with the MAME driver without saying so — 3

rtl/XSleenaCore_CLK.sv:339 NMI fires on scanline 248 (VBL) and is latched — shares text with technos/xain.cpp:215
rtl/XSleenaCore_CLK.sv:340 VBLK input bit is held high from scanlines 248-255: — shares text with technos/xain.cpp:219
rtl/XSleenaCore_CLK.sv:355 FIRQ (IMS) fires every on every 8th scanline (except 0) — shares text with technos/xain.cpp:211

Xybots#
Xybots
MiSTer-devel/Arcade-Xybots_MiSTer @ 3a3139ae
MAME compared: atari/xybots.cpp + 8 related file(s)
Read: 34 HDL files, 6,582 lines (Quartus project)

MiSTer official

Both

high

78%

Statements: 185 toward hardware, 98 toward MAME, 1 not counted

Cites hardware documentation that MAME's driver does not — 182

Arcade-Xybots.sv:5 This is the MiSTer `emu` wrapper around rtl/xybots_core.sv, which holds the whole game: the SP-313 main board, the SYNGEN raster and video pipeline, the motion-object engine and the JSA I audio PCB.
Arcade-Xybots.sv:17 Clocking: clk_sys = 57.272727 MHz = 4 x the SP-313 sheet-4 14.318181 MHz crystal.
Arcade-Xybots.sv:306 WIDTH = 336 = the visible width of the SP-313 raster (456 x 263 total).
rtl/main/xybots_addr_decode.sv:3 Xybots 68000 address decode — SP-313 sheet 2, gate for gate.
rtl/main/xybots_addr_decode.sv:8 Every select below is read off the drawn decoders on sheet 2, not off MAME's `main_map`.
rtl/main/xybots_addr_decode.sv:154 A22..A18 and A7..A1 reach no decoder on sheet 2 at all.
rtl/main/xybots_cpu.sv:3 Xybots main CPU — fx68k (cycle-exact 68000), wired as SP-313 sheet 2 draws it.
rtl/main/xybots_cpu.sv:24 fx68k's flops are `always_ff @(posedge clk) if (enPhiN)`, so `enPhi1 = ce_7m` puts the fx68k CPU clock edge on the `ce_7m` cycle itself and the rest of sheet 2 — the 5A LS163A /DTACK counter, the 7B 74S74 VRAC arbitration and the E-clock/VP
rtl/main/xybots_cpu.sv:37 BERRn = 1 (16A pin 22 = PR2): sheet 2 has no bus-error source.
rtl/main/xybots_cpu.sv:55 `oHALTEDn` (fx68k's double-bus-fault output) has no load on sheet 2 and is left unconnected.
rtl/main/xybots_cpu.sv:62 ---- /VPA, autovectoring and the RESET instruction ----------------------- Sheet 2 makes `/VPA = ~(FC0 & FC1 & FC2 & AS)` (10A LS20) and wires it to BOTH the 68000's VPA pin (21) and the 5A LS163A's ENT input.
rtl/main/xybots_cpu.sv:135 double bus fault; no load on sheet 2
rtl/main/xybots_dpram_be.sv:8 Used twice on the main board: * the 16 KB video RAM at 14J/14E (`AW = 13`, 8 K words), where the two 8464D70 SRAMs take independent /WE strobes so byte writes on either lane are honoured; * the 2 KB colour RAM at 17J/17K (`AW = 10`, 1 K wor
rtl/main/xybots_dtack.sv:3 Xybots /DTACK generator — SP-313 sheet 2 (5A LS163A + 7B 74S74 + 1B LS02).
rtl/main/xybots_dtack.sv:10 Non-video path — 5A LS163A, a SYNCHRONOUS-clear 4-bit binary counter: CK (2) = VIDCLK (= the 68000 clock, 7.15909 MHz) /CLR (1) = 2A LS08 (1 = /VRAM, 2 = AS -> 3) = /VRAM & AS -> the counter is held at 0 whenever there is no bus cycle
rtl/main/xybots_dtack.sv:27 Video path — 7B 74S74: D (12) = /VRAM CK (11) = VRAC2 /PRE (10) = AS -> with no bus cycle Q is preset to 1 /CLR (13) = PR3 (tied inactive) /Q (8) = VDTACK With AS inactive the preset holds Q = 1 so VDTACK = 0.
rtl/main/xybots_dtack.sv:67 ---- 5A LS163A -------------------------------------------------------
rtl/main/xybots_dtack.sv:86 ---- 7B 74S74 -------------------------------------------------------- /PRE = AS is asynchronous on the real part.
rtl/main/xybots_eeprom_2804.sv:3 Xicor X2804A (512 x 8) EEPROM at 20C/D — SP-313 sheet 3.
rtl/main/xybots_inputs.sv:3 Xybots control-panel and status ports — SP-313 sheet 4 (18F, 21E, 18J).
rtl/main/xybots_inputs.sv:8 ---- /SW, 0x806100 ------------------------------------------------------- 18F LS244B drives the HIGH byte and 21E LS244B the LOW byte; both /1G and /2G on both parts are `/SW`, so the port is a full 16-bit read and the game reads it as a w
rtl/main/xybots_inputs.sv:25 The `CLK0/DIR0/...` net names on the DC connector are vestigial; sheet 10 labels the same pins START, FIRE, TWIST RT, TWIST LT, RIGHT, LEFT, DOWN, UP.
rtl/main/xybots_inputs.sv:31 ---- /SYSIN, 0x806200 ---------------------------------------------------- 18J LS244A, both enables = `/SYSIN`, drives the HIGH byte only: D8 /SELFTEST D9 /AUDBUSY (SCOM 20E BUSY) D10 256H D11 VBLANK D12 SW8 D13 SW9 D14 SW1
rtl/main/xybots_irq.sv:3 Xybots interrupt encoder — SP-313 sheet 2 (1B LS02, 10A LS20, 4A LS04, 3B LS00, 1C 74S74, 10C LS00).
rtl/main/xybots_irq.sv:15 1C 74S74 as an S/R latch: D = CK = PR1 (it never clocks), /PRE = 3B/11, /CLR = /VIDACK, Q -> 10C LS00 pin 2 5.
rtl/main/xybots_irq.sv:19 ---- VIRQ is programmable, and that is the biggest schematic-vs-MAME difference in the whole core ---------------------------------------- `VIRQ` is not a raster signal.
rtl/main/xybots_irq.sv:21 SP-313 sheet 7, 6D LS174E (CK = 4H) latches **SCRAMD10 -> VIRQ**, i.e. bit 10 of the ALPHA tile word being fetched.
rtl/main/xybots_irq.sv:31 `virq` is the latched alpha bit 10 from the video timing block; the gating with V[2:0]/HBLANK/VBLANK is here because sheet 2 is where it is drawn.
rtl/main/xybots_irq.sv:57 The 1C 74S74 has no reset input on the board: its /CLR is `/VIDACK` and nothing else, so a watchdog timeout or a 68000 RESET instruction leaves a pending IRQ1 pending (the CPU comes out of reset with the SR mask at 7 anyway, and the handler
rtl/main/xybots_irq.sv:65 6D LS174E pin 2: latched alpha word bit 10
rtl/main/xybots_irq.sv:75 1C 74S74 Q; diagnostic output, no consumer in the core.
rtl/main/xybots_irq.sv:83 The latch is level-set: while VIRQ and the window are both true the preset holds Q at 1, so a /VIDACK write that lands in the same window cannot clear it (both /PRE and /CLR low on a 74S74 forces Q = /Q = 1; on release the preset wins here
rtl/main/xybots_main_bus.sv:3 Xybots main board — SP-313 sheet 2 as one block.
rtl/main/xybots_main_bus.sv:21 The CPU side is arbitrated: the CPU owns **VRAC phase 3** of the four-phase video-RAM multiplex, and the 7B 74S74 in xybots_dtack is what makes the CPU wait for that slot.
rtl/main/xybots_main_bus.sv:26 `virq` is the 6D LS174E output, i.e. bit 10 of the ALPHA word being fetched — see xybots_irq's header.
rtl/main/xybots_main_bus.sv:29 ---- the /RESET net ------------------------------------------------------ The watchdog's /RESET resets the 68000 AND (leaving sheet 2 for sheet 3 only) clears the EEPROM unlock flip-flop and forces the EEPROM /OE gate.
rtl/main/xybots_main_bus.sv:57 7B 74S74 clock
rtl/main/xybots_main_bus.sv:62 6D LS174E pin 2: latched alpha bit 10
rtl/main/xybots_main_bus.sv:131 Declared here because sheet 2 wires it to the 68000's VPA pin as well as to the 5A's ENT input, so the CPU instance needs it.
rtl/main/xybots_main_bus.sv:136 It regenerates the second clock phase fx68k needs from `ce_7m` itself, so sheet 2 hands it nothing but the enable that everything else here runs on.
rtl/main/xybots_main_bus.sv:149 Decode (sheet 2)
rtl/main/xybots_main_bus.sv:260 Sheet 9 draws exactly ONE /WE path for both 17J and 17K, and it is /WL-qualified — 15C LS32 (9 = /WL, 10 = /CRAMD) then 15C LS32 (13 = that, 12 = /7M).
rtl/main/xybots_main_bus.sv:322 Interrupts (sheet 2)
rtl/main/xybots_main_bus.sv:327 `reset` here is POWER-UP ONLY: the 1C 74S74's only clear is /VIDACK, so a watchdog timeout must not drop a pending IRQ1 (see xybots_irq's header).
rtl/main/xybots_main_bus.sv:379 Inputs (18F/21E/18J on sheet 4)
rtl/main/xybots_main_bus.sv:421 DTACK (5A LS163A + 7B 74S74 + 1B LS02)
rtl/main/xybots_slapstic.sv:3 Atari SLAPSTIC 137412-107 — SP-313 sheet 2, location 14B ("SLAPSTK7").
rtl/main/xybots_slapstic.sv:7 The state machine below was written from SP-313 sheet 2 and checked against MAME's `slapstic.cpp` (BSD-3-Clause); see NOTICE.md.
rtl/main/xybots_slapstic.sv:14 ---- pinout as wired on sheet 2 ----------------------------------------
rtl/main/xybots_slapstic.sv:42 Sheet 2 puts no R/W term on /CS or CK, so `we` does not reach the state machine.
rtl/main/xybots_slapstic.sv:90 One pulse per 68000 bus cycle = one CK (/AS) edge at 14B pin 7.
rtl/main/xybots_slapstic.sv:99 Present so the caller keeps the write cycles; the state machine ignores it, exactly as MAME and sheet 2 do.
rtl/main/xybots_watchdog.sv:3 Xybots watchdog — SP-313 sheet 2 (1A LS00, 3A LS90, 4A LS04).
rtl/main/xybots_watchdog.sv:46 power-on reset, active high (sheet 1, 11A LS14)
rtl/mem/xybots_prog_rom.sv:11 ---- what the four sockets are (SP-313 sheet 3) ------------------------- 17C/D + 19C/D PROM0 /CE = A17 -> 68000 0x000000-0x01FFFF (2 x 64 KB)
rtl/mem/xybots_prog_rom.sv:30 SLAPSTIC (sheet 2, 14B + 13C LS157): `slap_sel` = /SLAPSTIC asserted, i.e. A23=0 & A17=0 & A16=0 & A15=1.
rtl/video/xybots_alpha.sv:3 Xybots alphanumerics layer — SP-313 sheet 7 (6D/7D LS174E, 5C 2764, 2C/3C LS194A) and the VIRQ tap that sheet 2 turns into IRQ1.
rtl/video/xybots_alpha.sv:12 h = 8k+3 ALPHA VRAC phase: the word is on the SCRAM data bus -> 8k+4 6D/7D LS174E clock on 4H rising: code[9:0] and VIRQ latched; the attribute nibble (D15, D14:12) is NOT latched here on the board -- it runs straight to the GPC -- so
rtl/video/xybots_alpha.sv:30 ---- the character ROM is an 8 KB part in a 16 KB socket ----------------- Sheet 7 draws a U27128 at 5C with A13 wired to code bit 9, but the dumped part 136054-1101.5c is a 2764.
rtl/video/xybots_alpha.sv:39 ---- VIRQ --------------------------------------------------------------- 6D LS174E pin 3 -> pin 2 is SCRAMD10 of the alpha word, i.e. a per-tile-row programmable scanline interrupt.
rtl/video/xybots_alpha.sv:41 It leaves here as the RAW 6D output: the gate with V[2:0]==7 & HBLANK & ~VBLANK and the 1C 74S74 latch are on sheet 2 and live in rtl/main/xybots_irq.sv, which xybots_main_bus feeds from this port.
rtl/video/xybots_alpha.sv:54 ---- SYNGEN counters (SP-313 sheet 4) ----
rtl/video/xybots_alpha.sv:71 6D LS174E pin 2 = alpha word bit 10
rtl/video/xybots_alpha.sv:75 6D / 7D LS174E — clocked by 4H, which rises entering count h ≡ 4.
rtl/video/xybots_alpha.sv:96 5C character ROM address, straight off sheet 7 A13..A4 = code (A13 unconnected on the fitted 2764 -> code[9] dropped) A3..A1 = 4V, 2V, 1V A0 = /4H
rtl/video/xybots_alpha.sv:111 2C / 3C LS194A — S1 = 1H2H (load), CK = /VIDCLK.
rtl/video/xybots_cram.sv:3 Xybots colour-RAM read path and video output registers — SP-313 sheet 9 (17J/17K 2K8-100A used as 1K x 16, 18L and 19L LS273H).
rtl/video/xybots_cram.sv:14 18L / 19L are clocked by 8M 74S32 (12 = CRAMD, 13 = /7M -> 11).
rtl/video/xybots_cram.sv:38 ---- 18L / 19L LS273H ----
rtl/video/xybots_dac.sv:3 Xybots video DACs — SP-313 sheet 9: three identical 4-bit binary-weighted current DACs whose shared reference current is set by a fourth, 4-bit intensity ladder.
rtl/video/xybots_dac.sv:10 ---- the circuit --------------------------------------------------------- Each colour: open-collector U7406 inverters switching R = 620, 1.2K, 2.4K, 4.7K (bit 3..bit 0) into a summing node, plus a 74LS260 "all four bits zero" detect.
rtl/video/xybots_gpc.sv:3 Xybots GPC 14K — the Atari custom on SP-313 sheet 8 that turns the alpha attribute nibble, the P bus, the M bus and PF/MO into the 10-bit colour-RAM address.
rtl/video/xybots_gpc.sv:10 ---- this is the one place MAME is the oracle --------------------------- The GPC is an Atari custom and a black box: sheet 8 gives every pin connection and nothing about the inside.
rtl/video/xybots_gpc.sv:23 and that is a DEDUCTION FROM MAME, not from the schematic.
rtl/video/xybots_gpc.sv:34 The third row is MAME's `pf[x] = (mo[x] ^ 0x2f0)`, the case its comment calls "doesn't make sense from the schematics".
rtl/video/xybots_mo.sv:3 Xybots — the motion-object engine: SP-313 sheets 5, 6 and 8 tied together.
rtl/video/xybots_mo.sv:8 xybots_mo_fetch sheets 5 + 6 — the table walk, the object word latches, the vertical match (xybots_mo_vmatch), the sprite-ROM client and the pixel path xybots_mo_linebuf sheet 8 — the two LB customs (9K, 8K) as ping-pong line buffers wi
rtl/video/xybots_mo.sv:51 ---- SYNGEN (sheet 4) ----
rtl/video/xybots_mo.sv:106 The LB customs take their address inputs A8..A0 straight off SCRAMD15..7 (sheet 8): the object's X is loaded by /MOHLD during the word-3 fetch, from the video data bus, not from a latch.
rtl/video/xybots_mo_fetch.sv:3 Xybots — SP-313 sheets 5 and 6: the motion-object table walk, the object word latches, the vertical match pipeline, the sprite-ROM address and the pixel path (LS158 swap + LS194 shifters).
rtl/video/xybots_mo_fetch.sv:15 0 | MO word 2 | (fetch) entry n = H[8:3] 1 | MO word 0 | word 2 latched (10F/9E LS174A rises at h%8 == 1) 2 | CPU | word 0 latched (6F/6E LS273B on /4HD2H, rises at 2) 3 | ALPHA | 4 | PLAYFIELD | 5
rtl/video/xybots_mo_fetch.sv:32 455 (sheet 8, /DIE gated by 1VD8H), so entries 0..55 are drawn, entry 56 is fetched and thrown away, and entries 57..63 are never addressed at all.
rtl/video/xybots_mo_fetch.sv:67 ---- SYNGEN (sheet 4) ----
rtl/video/xybots_mo_fetch.sv:71 11J 74S04 (9->8)
rtl/video/xybots_mo_fetch.sv:74 ---- video-side VRAM port (sheet 5 LS253 mux, MO phase) ----
rtl/video/xybots_mo_fetch.sv:84 ---- to the line buffers (sheet 8), all in the INVERTED sense ----
rtl/video/xybots_mo_fetch.sv:107 10F/9E LS174A — word 2 [15:7]
rtl/video/xybots_mo_fetch.sv:108 10F/9E LS174A — word 2 [2:0]
rtl/video/xybots_mo_fetch.sv:109 6F/6E LS273B — word 0 [13:0]
rtl/video/xybots_mo_fetch.sv:111 8E LS174B — word 1 [3:0], true sense
rtl/video/xybots_mo_fetch.sv:146 Vertical match and the ROM address (sheet 5, combinational)
rtl/video/xybots_mo_fetch.sv:221 The draw-side pipeline (1D LS174C + 5F/5E LS273F, sheet 5/6)
rtl/video/xybots_mo_fetch.sv:250 7F LS86 + 6J/5J LS158 + 6K/5K LS194 (sheet 6)
rtl/video/xybots_mo_fetch.sv:261 The LS158s are INVERTING and their /G is /MOVMATCHD: with no vertical match every output is forced high, i.e. MOPIX = 4'hF = the transparent pen, which is what stops 8D LS20 (sheet 8) from writing anything.
rtl/video/xybots_mo_linebuf.sv:3 Xybots — SP-313 sheet 8: the two Atari "LB" line-buffer customs (9K and 8K) and the discrete logic that drives them.
rtl/video/xybots_mo_linebuf.sv:33 That is the only reading under which sheet 4's *crossed* pairing makes sense — /MOHLD1 (even lines) belongs to the buffer being written and /MOHR0 (even lines) to the buffer being read — and it is the only one in which the pointers do not c
rtl/video/xybots_mo_linebuf.sv:37 There is no BUFCLR pin on the Xybots LB symbol and no other clear anywhere on sheet 8, yet a buffer written on line N and read on line N+1 has to be empty again for line N+2.
rtl/video/xybots_mo_linebuf.sv:101 /DIE and /LBWR (sheet 8)
rtl/video/xybots_mo_vmatch.sv:3 Xybots — SP-313 sheet 5: the motion-object vertical match (9D, 10D, 3D, 8D) and the picture-code adder (4D, 5D).
rtl/video/xybots_mo_vmatch.sv:10 `xybots_mo_fetch` supplies the latched object words and clocks the result into the 1D LS174C / 5F-5E LS273F pipeline the sheet draws around it.
rtl/video/xybots_mo_vmatch.sv:16 The LS283 symbols on sheet 5 carry high-side pin numbers that do not match a real 74LS283, so their A/B/C0/S/C4 ROLE labels are authoritative and the pin numbers are not.
rtl/video/xybots_mo_vmatch.sv:23 `MOV0 | 1V` is exactly carry(MOV0 + 1V + 1), so 9D+10D compute the 9-bit U = MOV[8:0] + V[8:0] + 1 where V[8] is VBLANK (there is no 256V net anywhere in SP-313).
rtl/video/xybots_mo_vmatch.sv:25 The bit-0 sum, MOA2, is the matching XNOR — and sheet 5 builds MOA2 out of 2A LS08 + 1A LS00 + 4A LS04 + 1B LS02, which is an XNOR.
rtl/video/xybots_mo_vmatch.sv:30 The +1 is the line-buffer pipeline: a column computed while the beam is on line V is written into the off-screen buffer and read out on line V+1 (sheet 8, RSEL = 1V).
rtl/video/xybots_mo_vmatch.sv:66 5D's C4 goes NOWHERE, and MOPIC13..8 reach the ROM sockets unmodified through 5F/5E LS273F.
rtl/video/xybots_mo_vmatch.sv:76 object word 2, as latched by 10F/9E LS174A
rtl/video/xybots_mo_vmatch.sv:79 object word 0, as latched by 6F/6E LS273B
rtl/video/xybots_pf.sv:3 Xybots playfield layer — SP-313 sheet 7 (13F/13E LS273D, 13J LS174D, PFROM0-3, 6M/5M LS157A, 6L/5L LS194A, 13K LS273).
rtl/video/xybots_pf.sv:12 h = 8k+4 PLAYFIELD VRAC phase: the word is on the SCRAM data bus -> 8k+5 13F/13E LS273D clock on 4HD1H rising: PFHFLIP (bit 15), colour (bits 14:11) and the 13-bit code (bits 12:0) latched.
rtl/video/xybots_pf.sv:19 -> 8k+13 the prefetched row moves into the display slot h = 8k+14 ROM byte index {~4HD1H, 2HD1H} ^ {flip,flip} = 0 -> 8k+15 6L/5L LS194A parallel load (S1 = /1H), 13J-style colour move ...
rtl/video/xybots_pf.sv:43 ---- ROM address, straight off sheet 7 ---------------------------------- A15..A5 = PFPIC10..PFPIC0 A4..A2 = 4V, 2V, 1V A1 = /4HD1H XOR PFHFLIP A0 = 2HD1H XOR PFHFLIP socket = {PFPIC12, PFPIC11} -> MAME "tiles" region offse
rtl/video/xybots_pf.sv:91 13F / 13E LS273D — clocked by 4HD1H, which rises entering count h ≡ 5, so the PRE-edge condition is h[2:0] == 4.
rtl/video/xybots_pf.sv:129 13F/13E latch the new word and the fetch starts immediately
rtl/video/xybots_pf.sv:142 ROM byte index and the 6M/5M LS157A nibble swap A1 = /4HD1H XOR PFHFLIP, A0 = 2HD1H XOR PFHFLIP 4HD1H(h) = 4H(h-1) is high for h ≡ 5,6,7,0; 2HD1H(h) = 2H(h-1) is high for h ≡ 3,4,7,0.
rtl/video/xybots_pf.sv:174 6L / 5L LS194A — S1 = /1H, CK = VIDCLK: parallel load on the edge whose PRE-edge count is even, one shift per count.
rtl/video/xybots_pf.sv:195 13J LS174D — CK = 2HD1H, which rises entering counts h ≡ 3 and h ≡ 7, i.e. on the edges whose PRE-edge count has h[1:0] == 2.
rtl/video/xybots_prio.sv:3 Xybots priority network — SP-313 sheet 8: 9C LS10 (PRIEN), 12J 74S85 with its cascade trick, 11K 74S157 (the P bus) and the 12K + 14M LS32 gates (the M bus).
rtl/video/xybots_prio.sv:15 ---- 12J is a 74S85, not a PAL ------------------------------------------ A = LBPRI, B = PFCOL, A<BI = A>BI = GND and A=BI = PRIEN; the only output used is A>BO = PF/MO.
rtl/video/xybots_prio.sv:17 A 74S85 whose three cascade inputs are all low drives BOTH A>BO and A<BO high on A == B, so:
rtl/video/xybots_prio.sv:40 12J 74S85 pin 5 (A>BO): 1 = playfield wins
rtl/video/xybots_prio.sv:48 ---- 12J 74S85 --------------------------------------------------------- The structural device, so that the cascade state is modelled and not assumed.
rtl/video/xybots_prio.sv:58 With A>BI = 0 and A<BI = 0 the 74S85 gives {1,1,0} when A=BI is also 0, and {0,0,1} when A=BI is high.
rtl/video/xybots_prio.sv:70 ---- 11K 74S157 -------------------------------------------------------- SEL = 8M 74S32 ( PF/MO , 10E 74S00(PRIEN, 11J 74S04(LBCOL3)) ) = PF/MO | ~(PRIEN & ~LBCOL3) SEL = 1 selects the B inputs, i.e. PFPIX.
rtl/video/xybots_syngen.sv:3 Xybots — SP-313 sheet 4: master clock tree, SYNGEN custom (11E/F) and the discrete glue that surrounds it.
rtl/video/xybots_syngen.sv:11 This module is the whole of sheet 4 except the LS244 switch-input buffers (18F/18J/21E) — i.e. the oscillator/divider chain, the SYNGEN custom itself, and every gate that shapes SYNGEN's outputs into the nets the other eight sheets consume.
rtl/video/xybots_syngen.sv:19 SP-313 draws only its pinout, so its internal behaviour is reconstructed from the *same part* as implemented discretely on Atari System 1 (SP-277) and modelled in the Arcade-Gauntlet_MiSTer core's `rtl/gauntlet/SYNGEN.vhd` (d18c7db, GPL-3.0
rtl/video/xybots_syngen.sv:26 * a 9-bit horizontal counter cleared by NXL, * an 82S153 PLA (Atari 136032-103) decoding H into NXL/HSYNC/HBLANK/LMPD/PFHST/BUFCLR/C0/C1/C2, all of them taken through one register (the "7E" 74S174), * an 8-bit vertical counter plus one extr
rtl/video/xybots_syngen.sv:44 PIN DIRECTIONS ON SP-313 SHEET 4
rtl/video/xybots_syngen.sv:56 VSCK (vertical scroll clock) and /PFHST (playfield horizontal start) are the System-1 scrolling hooks: Xybots has no scrolling playfield, so both are bare stubs, as is C0 (Xybots makes its own VRAC0 with 8M 74S32 instead).
rtl/video/xybots_syngen.sv:87 14M (8B 74S04 1->2)
rtl/video/xybots_syngen.sv:88 /14MP (8B 74S04 13->12)
rtl/video/xybots_syngen.sv:89 7M (7B 74S74 Q)
rtl/video/xybots_syngen.sv:90 /7M (7B 74S74 /Q)
rtl/video/xybots_syngen.sv:91 DCLK (9B 74S74 Q)
rtl/video/xybots_syngen.sv:92 RCLK (1C 74S74 Q, /PRE = DCLK)
rtl/video/xybots_syngen.sv:93 VIDCLK (11J 74S04 3->4 from /CKO)
rtl/video/xybots_syngen.sv:94 /VIDCLK (8B 74S04 9->8 from CKO)
rtl/video/xybots_syngen.sv:117 10E 74S00 (1,2->3)
rtl/video/xybots_syngen.sv:118 11J 74S04 (9->8)
rtl/video/xybots_syngen.sv:120 11J 74S04 (11->10)
rtl/video/xybots_syngen.sv:122 11J 74S04 (1->2)
rtl/video/xybots_syngen.sv:130 ---- video-RAM access phase (sheet 5 LS253 select) ----
rtl/video/xybots_syngen.sv:131 8M 74S32 (4 = /2HD1H, 5 = 4HD2H -> 6)
rtl/video/xybots_syngen.sv:143 ---- interrupt ---- Sheet 2: 1B LS02 (11 = VBLANK, 12 = /HBLANK -> 13) then 10A LS20 with 4V,2V,1V then 4A LS04 (9->8).
rtl/video/xybots_syngen.sv:145 The IRQ1 latch is set by `virq_gate & VIRQ`, where VIRQ is alpha-RAM bit 10 latched by 6D LS174E on sheet 7; that half comes out of xybots_alpha.
rtl/video/xybots_syngen.sv:158 clk_sys phase, and the 14M / 7M chain (SP-313 sheet 4)
rtl/video/xybots_syngen.sv:175 7B 74S74: D = /7M, CK = 14M -> divide by two, rising with ce_7m.
rtl/video/xybots_syngen.sv:179 9B 74S74: D = /7M, CK = /14MP.
rtl/video/xybots_syngen.sv:186 1C 74S74: D = 7M, CK = 14M, /PRE = DCLK (asynchronous), /CLR = PR1 = 1.
rtl/video/xybots_syngen.sv:196 SYNGEN CKO (pin 29) = CK, /CKO (pin 4) = ~CK; both are re-inverted on the board, so VIDCLK is in phase with 7M and is the 68000 clock (sheet 2).
rtl/video/xybots_syngen.sv:202 SYNGEN horizontal PLA (Atari 136032-103 / 82S153), sheet-4 black box
rtl/video/xybots_syngen.sv:226 o16 (C0), o12 (/PFHST) and o11 (BUFCLR) are deliberately not implemented: pins 24 and 28 are bare stubs on sheet 4 and BUFCLR has no pin at all in the Xybots symbol, so nothing in this game can observe them.
rtl/video/xybots_syngen.sv:231 SYNGEN vertical PROM (Atari 136032-102, 256 x 4), sheet-4 black box
rtl/video/xybots_syngen.sv:264 The counters and the SYNGEN output register (74S174 "7E" / "7D")
rtl/video/xybots_syngen.sv:332 8B 74S04
rtl/video/xybots_syngen.sv:336 10E 74S00
rtl/video/xybots_syngen.sv:338 11J 74S04
rtl/video/xybots_syngen.sv:344 8M 74S32: VRAC0 = /2HD1H | 4HD2H.
rtl/video/xybots_syngen.sv:350 g3b/g6b are the two unnamed intermediate nets on sheet 4; /MOHR itself comes out of SYNGEN pin 25.
rtl/video/xybots_testpat.sv:22 4 bits per channel, which is the natural width for this game: Xybots' CRAM is 1024 x 16 in I:R:G:B 4:4:4:4 (SP-313 sheet 9), so the real palette output lands on the same bus.
rtl/video/xybots_video.sv:74 6D LS174E: raw alpha bit 10, UNDELAYED
rtl/video/xybots_video.sv:242 Compositor stage 1 — the GPC's 7M input register (sheet 8).
rtl/xybots_core.sv:7 The five blocks, and the SP-313 schematic sheets each one models:
rtl/xybots_core.sv:9 xybots_mem sheet 3 ROMs + the MiSTer download path + SDRAM xybots_main_bus sheet 2 — 68000, decode, DTACK, IRQ, watchdog, SLAPSTIC, EEPROM + NVRAM, inputs, video RAM, colour RAM xybots_video sheets 4/5/7/8/9 — SYNGEN, the VRAM ad
rtl/xybots_core.sv:23 ONE clock domain, clk_sys = 57.272727 MHz = 4 x the SP-313 sheet-4 crystal (14.318181 MHz), with integer clock enables and no fractional enables anywhere.
rtl/xybots_core.sv:28 ce_14m = clk_sys / 4 = 14.318181 MHz SYNGEN master (sheet 4)
rtl/xybots_core.sv:80 cpu_reset sys_reset | watchdog_reset — formed INSIDE xybots_main_bus, because the sheet-2 /RESET net reaches only the 68000's RESET/HALT pins and (on sheet 3) the EEPROM unlock latch and its /OE gate.
rtl/xybots_core.sv:141 ---- video out (single clk_sys domain, qualified by ce_pix) ---- 8 bits per channel: CRAM is I:R:G:B 4:4:4:4 (sheet 9), but the INTENSITY bit means the sheet-9 resistor-ladder DAC produces more than 16 levels per channel, so the core's outp
rtl/xybots_core.sv:403 Main board — SP-313 sheet 2
rtl/xybots_core.sv:459 JSA I audio PCB — SP-313 sheets 11-14
README.md:7 The core reconstructs the original PCB set — the game board (68000 + SLAPSTIC 137412-107) and the Atari **JSA I** stand-alone audio board (6502 + YM2151) — from
README.md:114 | Protection | Atari **SLAPSTIC 137412-107** at 14B, banking ROM `0x8000-0x9FFF` in 4 × 8 KB pages |
README.md:121 | Priority | The 74S85 magnitude comparator at 12J (not a PAL — sheet 8 is unambiguous) + the GPC custom at 14K form the colour-RAM address |
README.md:156 **Programmed logic** — the one PAL the core depends on, the JSA sound board's address decoder (Atari 136056-2101), is implemented from its fuse map rather than
README.md:163 **Video timing** — the SYNGEN raster is reconstructed from the real Atari System 1 sync PROM 136032-102 and checked by an exhaustive one-frame bench that rebuil
README.md:214 It is where the SP-313 schematics or the sound board's decoder PAL document something MAME's model does not — and in two of the seven cases MAME's own source fl
README.md:220 | Lines per frame | `set_raw(..., 262, ...)`, 59.923 Hz, above a comment saying these are *"from published specs, not derived"* and that the board uses a SYNGEN
README.md:225 | Sound CPU: YM2151 select | `0x2000-0x2001` | **`0x2000-0x27FF`** — the decoder PAL 136056-2101 sees neither SA10..SA1 nor anything the YM2151 (which has only
README.md:242 The decoder output exists on sheet 2 and goes nowhere, so the writes terminate like any other decoded-but-unconnected access and have no effect.
README.md:264 A SYNGEN dump would settle the 263-line count directly.** The vertical total is derived from the System 1 sync PROM and the discrete System 1 circuit that the S
README.md:313 The SLAPSTIC is *not* derived from those cores: it was written from SP-313 sheet 2 and verified against MAME's state machine.
README.md:317 Thanks to the MAME team, whose `xybots.cpp`, `atarijsa.cpp`, `atarimo.cpp` and `slapstic.cpp` served as the functional oracle throughout, and to whoever preserv

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/mem/xybots_prog_rom.sv:77 27256 at 17B/19B: pin 1 is VPP, A16 undecoded -> 0x30000 folds onto 0x20000 — also in MAME: 17B atari/xybots.cpp:416, 19B atari/xybots.cpp:417

Notes where it differs from MAME — 3

rtl/main/xybots_irq.sv:27 In attract and in play the game keeps exactly ONE armed word — row 29, column 42 — so the two models coincide at ~line 239; in SELF TEST the character-set and RAM-test screens set bit 10 in thousands of visible words and real hardware takes
README.md:11 Where a schematic and MAME disagree, the schematic wins and the disagreement is recorded: see [Where this core differs from MAME](#where-this-core-differs-from-
README.md:211 Where this core differs from MAME

Cites MAME source — 84

Arcade-Xybots.sv:12 Xybots runs on a HORIZONTAL monitor (MAME ROT0), so there is no rotation: the raster goes straight through arcade_video.
Arcade-Xybots.sv:86 Xybots has NO dip switches: MAME's INPUT_PORTS_START(xybots) has only the 0x806100 control word and the 0x806200 service/status word, and every operator setting lives in the X2804 EEPROM at 0x805000, changed from the game's own self-test.
Arcade-Xybots.sv:197 Coins are read on the JSA audio board and are SWAPPED on Xybots (MAME set_swapped_coins(true)); the swap is inside rtl/sound/xybots_jsa_io.sv, so coin1 here is the LEFT chute / player 1 exactly as the harness labels it.
rtl/main/xybots_addr_decode.sv:8 Every select below is read off the drawn decoders on sheet 2, not off MAME's `main_map`.
rtl/main/xybots_addr_decode.sv:9 The mirrors MAME documents fall OUT of the address bits those decoders never look at, so the two descriptions agree over the whole 24-bit space (see the mirror note at the end).
rtl/main/xybots_addr_decode.sv:46 ---- mirrors, i.e. which bits nobody looks at ---------------------------- A23 = 1 half: A22..A15 are not decoded at all -> everything repeats every 0x8000, which is MAME's `.mirror(0x7f8000)`.
rtl/main/xybots_addr_decode.sv:49 /CRAM covers 0x804000-0x804FFF but only A10..A1 reach the RAM -> MAME's 0x800 palette mirror.
rtl/main/xybots_addr_decode.sv:50 /EEROM covers 0x805000-0x805FFF but the X2804A only has A0..A8 -> MAME's 0xc00.
rtl/main/xybots_addr_decode.sv:52 A23 = 0 half: only A17 (ROM /CE) and A16/A15 (slapstic) are decoded, so the ROM repeats every 0x40000, which is MAME's `.mirror(0x7c0000)`.
rtl/main/xybots_addr_decode.sv:154 That omission is the WHOLE source of MAME's `.mirror(0x7c0000)` on the ROM half and `.mirror(0x7f8000)` plus the 0x100-byte I/O pages on the board half, so it is deliberate; sink the bits so the tools agree.
rtl/main/xybots_eeprom_2804.sv:18 The socket is wired for a 2 K x 8 part but the fitted X2804A is 512 x 8 (A0..A8 only), so the device repeats four times inside 0x805000-0x805FFF — which is exactly MAME's `.mirror(0x7f8c00)`.
rtl/main/xybots_eeprom_2804.sv:31 Exactly one write is permitted per unlock, which is MAME's `lock_after_write(true)`.
rtl/main/xybots_eeprom_2804.sv:225 The board has no bus pull-ups on D0B-D7B, so the modelled float value is the 0xFF that MAME's unmapped read gives.
rtl/main/xybots_inputs.sv:28 **MAME says** FFE100 bit 0 = START2 ...
rtl/main/xybots_inputs.sv:40 Two schematic-vs-MAME points: * **D12-D15 are four real switch inputs** on connector SWB that MAME declares `IPT_UNUSED`.
rtl/main/xybots_irq.sv:19 ---- VIRQ is programmable, and that is the biggest schematic-vs-MAME difference in the whole core ---------------------------------------- `VIRQ` is not a raster signal.
rtl/main/xybots_irq.sv:26 MAME instead does `screen_vblank() -> ASSERT_LINE M68K_IRQ_1`, one IRQ per frame.
rtl/main/xybots_irq.sv:45 MAME drives two independent input lines.
rtl/main/xybots_main_bus.sv:88 SWB-3..6 -> /SYSIN D12..D15 (MAME: unused)
rtl/main/xybots_main_bus.sv:194 So the access that selects a bank still reads the OLD bank and the new one applies from the next cycle — which is exactly what MAME's read TAP does (the tap runs after the underlying `bankr` read) and what the boot trace shows at pc 0x13F32
rtl/main/xybots_main_bus.sv:265 The game never notices: it touches CRAM with WORD accesses only, so this and MAME's per-lane `palette_device::write16` are indistinguishable here.
rtl/main/xybots_main_bus.sv:396 Everything else — reads of the write-only strobes (the `clr` read-modify-writes at pc 0x52A and the five `clr.w $ea00.w` sites), the three unconnected LS138 outputs, the undecoded 0x806300/0x806700/0x807000 pages — leaves the bus floating,
rtl/main/xybots_slapstic.sv:30 The transition structure MAME's `slapstic.cpp` gives for chip class 103-110, which is what 137412-107 belongs to.
rtl/main/xybots_slapstic.sv:31 MAME qualifies each match with a 32-bit range test as well as the chip's own address mask; on this board that range test reduces to exactly "A23=0 and A17=0 and A16=0 and A15=1", which IS /SLAPSTIC, so the two forms below are all that is ne
rtl/main/xybots_slapstic.sv:56 slapstic_data for 137412-107, verbatim from slapstic.cpp.
rtl/main/xybots_slapstic.sv:56 All values are CHIP word addresses (= 68000 A14..A1), which is what MAME's tables hold.
rtl/main/xybots_slapstic.sv:99 Present so the caller keeps the write cycles; the state machine ignores it, exactly as MAME and sheet 2 do.
rtl/main/xybots_slapstic.sv:107 MAME's S_* encoding; diagnostic output, no consumer in the core.
rtl/main/xybots_slapstic.sv:111 MAME slapstic.h `enum { S_IDLE, S_ACTIVE, S_ALT_VALID, S_ALT_SELECT, S_ALT_COMMIT, S_BIT_LOAD, S_BIT_SET_ODD, S_BIT_SET_EVEN, ...
rtl/main/xybots_slapstic.sv:125 68000 A0 does not exist on the bus, and MAME masks bit 0 out of every test, so nothing here depends on byte lane.
rtl/main/xybots_watchdog.sv:30 **MAME says** `WATCHDOG_TIMER(config, "watchdog")` with default timing: the 8-frame period, the 2-frame pulse and the park-at-9 power-up are not modelled there.
rtl/mem/xybots_prog_rom.sv:36 Result: an 8 KB page at 0x008000-0x009FFF repeated four times over 0x8000-0xFFFF, exactly MAME's `configure_entries(0, 4, base + 0x8000, 0x2000)`.
rtl/mem/xybots_rom_loader.sv:13 stream base size MAME region destination
rtl/mem/xybots_rom_loader.sv:25 * maincpu is emitted as BIG-ENDIAN INTERLEAVED WORDS — the even-offset MAME ROM (17cd/17b) is `map="01"`, the FIRST byte of each output word, i.e. D15:8.
rtl/video/xybots_alpha.sv:23 Two more pipeline stages downstream (GPC, then CRAM + 18L/19L) put that pixel on the DAC during count 8k+9+p, i.e. at hpos = 8k+p — where MAME's alpha tilemap puts it.
rtl/video/xybots_alpha.sv:119 Byte / plane order (MAME's `anlayout`): char_data[7:4] = ANPIX1 of pixels 0..3 (plane 0 = the MSB pen bit) char_data[3:0] = ANPIX0 of pixels 0..3 and A0 = /4H already selected pixels 0..3 vs 4..7.
rtl/video/xybots_dac.sv:34 Neither ladder is exactly binary: 4700/620 = 7.58 rather than 8, and 1000/120 = 8.33 rather than 8, so the colour curve sits slightly above MAME's straight n/15 in the low half and slightly below it in the high half, and the intensity curve
rtl/video/xybots_dac.sv:39 ---- MAME ---------------------------------------------------------------- MAME's `IRGB_4444` is, measured against two pixel-exact captured frames covering 25 distinct palette words:
rtl/video/xybots_dac.sv:46 `DAC_MAME_COMPAT = 1` reproduces it bit for bit, which is what a simulation comparing this core against MAME's rendered bitmap wants.
rtl/video/xybots_dac.sv:73 round(2^15 * fc(n)) for the 620 / 1.2K / 2.4K / 4.7K colour ladder, and MAME's 17*n when DAC_MAME_COMPAT is set.
rtl/video/xybots_dac.sv:117 The shifted product is 8-bit by construction — 255 * 2^30 >> 30 in schematic mode, 255*255 >> 8 in MAME mode — so the cast is exact.
rtl/video/xybots_gpc.sv:10 ---- this is the one place MAME is the oracle --------------------------- The GPC is an Atari custom and a black box: sheet 8 gives every pin connection and nothing about the inside.
rtl/video/xybots_gpc.sv:17 and MAME's alpha tile info is `color = (data >> 12) & 7`, `opaque = data & 0x8000`, with the "chars" gfx entry at palette base 0 and 4 pens per colour.
rtl/video/xybots_gpc.sv:23 and that is a DEDUCTION FROM MAME, not from the schematic.
rtl/video/xybots_gpc.sv:23 Likewise the palette bases 0 / 256 / 512 (and the otherwise unused 768) come from MAME's GFXDECODE entries.
rtl/video/xybots_gpc.sv:34 The third row is MAME's `pf[x] = (mo[x] ^ 0x2f0)`, the case its comment calls "doesn't make sense from the schematics".
rtl/video/xybots_gpc.sv:62 The alpha layer is on top; pen 0 is transparent unless the tile's opaque bit (word bit 15) is set -- MAME's TILE_FORCE_LAYER0.
rtl/video/xybots_gpc.sv:66 M is the line buffer's byte, inverted sense; ~M is MAME's {colour, pen}.
rtl/video/xybots_mo_fetch.sv:149 On a visible line that is simply MAME's vpos; on the last line of the frame (v256 phase, v = 255, VBLANK = 1) it is 511, and 511 + 1 = 0 mod 512 — which is exactly the display line the buffer written there feeds.
rtl/video/xybots_mo_linebuf.sv:129 The counters are nine bits, so a column that starts near 511 wraps into the left edge of the screen — which is exactly MAME's `xpos & 0x1ff` followed by the `xpos >= width ?
rtl/video/xybots_mo_vmatch.sv:32 So U = MOV + D for the DISPLAYED line D, which is MAME's coordinate directly.
rtl/video/xybots_mo_vmatch.sv:35 MAME (`atarimo.cpp::render_object`) puts the object at ypos = (-(Y + 8*height)) & 0x1FF and draws 8*height lines from there, i.e. D is covered iff (Y + D) mod 512 >= 512 - 8*height and the row inside the object is (Y + D) mod 512 - (512 - 8
rtl/video/xybots_mo_vmatch.sv:50 Two connections are ambiguous on the drawing and are read here as 3D B3 = 10D.S1 4D B1 = 3D.S1 4D's B1 is the load-bearing one: tied to GND the picture code would advance two tiles per row and only four rows could be addressed, whereas 3D
rtl/video/xybots_mo_vmatch.sv:67 So the add is EIGHT bits wide and a carry out of MOPIC7 is lost: tile index = {MOPIC[13:8], (MOPIC[7:0] + tile_row)[7:0]} MAME adds `code + row` in full 14-bit precision.
rtl/video/xybots_mo_vmatch.sv:70 That is a real difference between this core and MAME, kept because it is what the board does.
rtl/video/xybots_pf.sv:43 ---- ROM address, straight off sheet 7 ---------------------------------- A15..A5 = PFPIC10..PFPIC0 A4..A2 = 4V, 2V, 1V A1 = /4HD1H XOR PFHFLIP A0 = 2HD1H XOR PFHFLIP socket = {PFPIC12, PFPIC11} -> MAME "tiles" region offse
rtl/video/xybots_pf.sv:50 The empty 9L socket ({PFPIC12,PFPIC11} = 2, region 0x20000-0x2FFFF) floats and reads as 0xFF on the board; the MRA materialises 0xFF there while MAME leaves 0x00.
rtl/video/xybots_pf.sv:168 MAME's gfx_8x8x4_packed_msb: the HIGH nibble is the left pixel of the pair.
rtl/video/xybots_prio.sv:10 ---- everything from the line buffer is INVERTED sense ------------------- LBPIX = ~pen, LBCOL = ~colour, LBPRI = ~priority (= MAME's `mopriority`).
rtl/video/xybots_prio.sv:23 which is the pair of equations MAME uses.
rtl/video/xybots_syngen.sv:36 The one place it does NOT agree with MAME is the total line count: this model gives **263 lines**, MAME's `set_raw` says 262.
rtl/video/xybots_syngen.sv:38 MAME's own comment at that line says those parameters come from published specs rather than from the board, so the derived value is used here.
rtl/video/xybots_syngen.sv:40 Frame rate is therefore 7 159 090 / (456*263) = 59.696 Hz instead of MAME's 59.923 Hz.
rtl/video/xybots_syngen.sv:100 visible pixel index = h - 9 (MAME hpos)
rtl/video/xybots_video.sv:22 That is exactly where the board puts it and exactly where MAME puts tile column k: at x = 8k.
rtl/video/xybots_video.sv:34 1 = MAME's IRGB_4444 transfer
rtl/xybots_core.sv:92 1 selects MAME's IRGB_4444 transfer instead of the sheet-9 resistor ladder, bit-exactly.
rtl/xybots_core.sv:93 It exists so a simulation can be compared against MAME's rendered bitmap; the core itself uses the schematic curve and there is deliberately no OSD option for it.
rtl/xybots_core.sv:134 Coins live on the JSA board and are SWAPPED on Xybots (MAME set_swapped_coins(true)); the swap is inside xybots_jsa_io.
README.md:7 The core reconstructs the original PCB set — the game board (68000 + SLAPSTIC 137412-107) and the Atari **JSA I** stand-alone audio board (6502 + YM2151) — from
README.md:21 All five MAME sets run on identical RTL — they differ only in the main CPU ROMs (and, for `xybots0`, in three tile ROMs and the sound ROM's filename).
README.md:39 | ROMs | Supplied by you from a MAME archive; none are included here |
README.md:82 The operator manual's Switch Test page calls the knob switches *Turn Left* / *Turn Right*; MAME names the same two inputs *Twist Left* / *Twist Right*.
README.md:144 Like the other MiSTer arcade repositories, this one ships the core and its release files only; the simulation benches, MAME capture scripts and design notes are
README.md:168 **Main CPU boot** — the 68000 bus is co-simulated against MAME 0.288 through reset, the RAM and ROM tests, the SLAPSTIC checksum walk, 143 EEPROM writes and the
README.md:174 The SLAPSTIC 107 is proved equivalent to MAME's state machine over the full alt / bit / add sequences.
README.md:191 Those states are replayed through the real core RTL and compared to MAME's own rendered bitmap pixel for pixel.
README.md:213 MAME is this project's functional oracle and every gate above measures the core *against* it, so this is a narrow list, not a general claim.
README.md:214 It is where the SP-313 schematics or the sound board's decoder PAL document something MAME's model does not — and in two of the seven cases MAME's own source fl
README.md:218 | Behaviour | MAME | This core |
README.md:237 A `DAC_MAME_COMPAT` parameter selects MAME's curve so the frame-CRC gates can compare bit for bit; the shipping build uses the schematic's.
README.md:244 MAME does not map the address at all, and reaches the same outcome by a different route.
README.md:250 Neither row is observable in this game: the sound program addresses the YM2151 at `0x2000`/`0x2001` only and only ever *reads* `0x2806`, and MAME taps over attr
README.md:317 Thanks to the MAME team, whose `xybots.cpp`, `atarijsa.cpp`, `atarimo.cpp` and `slapstic.cpp` served as the functional oracle throughout, and to whoever preserv

Says it matches, follows or was checked against MAME — 9

Arcade-Xybots.sv:174 The /SW word at 0x806100 in its SCHEMATIC bit order, but ACTIVE HIGH ("pressed") — the 18F/21E LS244 inversion lives in rtl/main/xybots_inputs.sv, which is where the sheet-4 wiring is transcribed and verified (MAME's FFE100 agrees bit for b
rtl/main/xybots_inputs.sv:42 They are exposed here as inputs and default to inactive (reading 1), so the core matches MAME unless a user wires them.
rtl/main/xybots_inputs.sv:44 * **256H (D10) is never tested by the program.** MAME approximates it by XORing 0x0400 on every read of the port; this core drives the real 256H from the video counter, because nothing observable depends on it and the hardware signal is fre
rtl/main/xybots_slapstic.sv:7 The state machine below was written from SP-313 sheet 2 and checked against MAME's `slapstic.cpp` (BSD-3-Clause); see NOTICE.md.
rtl/main/xybots_slapstic.sv:90 It must pulse for EVERY cycle the chip can see, reads and writes alike, not only for cycles inside the banked window: alt1 is matched with MAME's `test_any`, and an out-of-window cycle breaks an alt sequence in progress.
rtl/video/xybots_cram.sv:16 Layout, straight off the wiring and identical to MAME's IRGB_4444:
README.md:189 **Pixel-exact video gates** — MAME is instrumented to capture complete video state (alpha, playfield and motion-object RAM plus the palette) at chosen frames.
README.md:192 The alpha layer, the playfield layer, the motion-object engine and the full compositor each have their own gate; the compositor is **bit-identical to MAME's `go
README.md:313 The SLAPSTIC is *not* derived from those cores: it was written from SP-313 sheet 2 and verified against MAME's state machine.

Says it was translated, ported or taken from MAME — 1

Arcade-Xybots.sv:174 The /SW word at 0x806100 in its SCHEMATIC bit order, but ACTIVE HIGH ("pressed") — the 18F/21E LS244 inversion lives in rtl/main/xybots_inputs.sv, which is where the sheet-4 wiring is transcribed and verified (MAME's FFE100 agrees bit for b

Keeps a MAME approximation — 1

rtl/main/xybots_inputs.sv:44 * **256H (D10) is never tested by the program.** MAME approximates it by XORing 0x0400 on every read of the port; this core drives the real 256H from the video counter, because nothing observable depends on it and the hardware signal is fre

Shares text with the MAME driver without saying so — 3

rtl/main/xybots_slapstic.sv:111 MAME slapstic.h `enum { S_IDLE, S_ACTIVE, S_ALT_VALID, S_ALT_SELECT, — shares text with atari/slapstic.h:283
rtl/main/xybots_slapstic.sv:112 S_ALT_COMMIT, S_BIT_LOAD, S_BIT_SET_ODD, S_BIT_SET_EVEN, ... }`. — shares text with atari/slapstic.h:283
rtl/video/xybots_gpc.sv:35 calls "doesn't make sense from the schematics". It does: 0x2f0 flips bit 9 — shares text with atari/xybots.cpp:205

Zaxxon#
Future Spy, Super Zaxxon, Zaxxon
MiSTer-devel/Arcade-Zaxxon_MiSTer @ 0bc93064
MAME compared: sega/zaxxon.cpp + 7 related file(s)
Read: 9 HDL files, 2,626 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

57%

Statements: 1 toward hardware, 1 toward MAME, 1 not counted

Cites hardware documentation that MAME's driver does not — 1

rtl/zaxxon.vhd:74 Schematics remarks : IC board 834-0214 and 834-0257 or 834-0211 some details are missing or seems to be wrong: - sprite buffer addresses flip control seems to be incomplete (fliping adresses both at read and write is useless !) - diagonal s

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/zaxxon.vhd:80 - 834-0211 sheet 7 of 9 : /128H, 128H and 256H dont agree with U21 Qc/Qd output ! — also in MAME: sheet 7 sega/nl_segausb.cpp:352

Cites MAME source — 1

rtl/zaxxon.vhd:36 Use with MAME roms from zaxxon.zip

ZigZag#
Zig Zag
MiSTer-devel/Arcade-ZigZag_MiSTer @ 5753cfd4
MAME compared: galaxian/galaxian.cpp + 7 related file(s)
Read: 21 HDL files, 7,034 lines (Quartus project)

MiSTer official

Not enough evidence in the code

insufficient

Statements: 1 toward MAME

Shares text with the MAME driver without saying so — 1

rtl/mc_inport.vhd:17 DIP SW 0 1 2 3 4 5 — shares text with galaxian/galaxian.cpp:2796

jt1942#
1942, Pirate Ship Higemaru, Vulgus
jotego/jtcores @ b672aca5
MAME compared: capcom/1942.cpp, capcom/higemaru.cpp, capcom/vulgus.cpp + 4 related file(s)
Read: 21 HDL files, 3,858 lines (files.yaml)

JTCORES

Both

low

15%

Statements: 8 toward hardware, 2 toward MAME

Cites hardware documentation that MAME's driver does not — 7

hdl/jt1942_colmix.v:5 1942 Colour Mixer Schematics page 4
hdl/jt1942_objtiming.v:79 But this should take the flip bit into account to work correctly and that isn't in the schematics.
hdl/jt1942_objtiming.v:101 objcnt[2:0] = H[6:4]; `else // 1942 scan sequence from schematics objcnt[4] = H[8]^~H[7]; objcnt[3] = (V[7] & objcnt[4]) ^ ~H[7]; objcnt[2:0] = H[6:4]; `endif end
hdl/jt1942_sound.v:5 1942 Sound Schematics page 3/8
cores/gng/hdl/jtgng_objdma.v:33 Ghosts'n Goblins copies only 'h180 objects as per schematics 1943 copy more, but it is not clear what the limit is.
README.md:14 This occurs because that logo is printed using two sprites right at the limit of the vertical split line (schematics 5/8).
README.md:21 The conversion was done based on 1942 schematics and MAME driver for Higemaru.

Notes where it differs from MAME — 1

hdl/jt1942_sound.v:23 MAME ignores one of them.

Cites MAME source — 2

README.md:21 The conversion was done based on 1942 schematics and MAME driver for Higemaru.
README.md:25 Interrupts are generated directly from the PROM and they do not occur at the same time as in MAME.

jt1943#
1943: Midway Kaisen, 1943 Kai: Midway Kaisen, 1943: The Battle of Midway Mark II
jotego/jtcores @ b672aca5
MAME compared: capcom/1943.cpp + 2 related file(s)
Read: 17 HDL files, 3,019 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

18%

Statements: 3 toward hardware, 1 toward MAME

Cites hardware documentation that MAME's driver does not — 3

cores/gng/hdl/jtgng_objdma.v:33 Ghosts'n Goblins copies only 'h180 objects as per schematics 1943 copy more, but it is not clear what the limit is.
cores/trojan/hdl/jttrojan_mcu.v:5 Following Trojan schematics, although it is not used in Trojan but Avengers
README.md:59 Changed object to 8MHz as per schematics.

Cites MAME source — 1

cores/gng/hdl/jtgng_sound.v:9 watch points for MAME: wpset e000,1,w,1,{printf "reg = %X", wpdata;g} wpset e001,1,w,1,{printf "val = %X", wpdata;g}

jtajax#
Ajax
jotego/jtcores @ b672aca5
MAME compared: konami/ajax.cpp + 7 related file(s)
Read: 15 HDL files, 3,247 lines (files.yaml)

JTCORES

Both

low

42%

Statements: 5 toward hardware, 8 toward MAME

Cites hardware documentation that MAME's driver does not — 5

hdl/jtajax_sub.v:79 OR'ed with blank output of 051316 (see J5 on sheet 2/3)
cores/aliens/hdl/jt051960.v:5 Based on Furrtek's RE work on die shots and MAME documentation
cores/aliens/hdl/jt051962.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
cores/aliens/hdl/jt052109.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
cores/aliens/hdl/jt052591.v:70 The die schematic gates external reads with BK (CPU_ERAM, sheet 3).

Cites MAME source — 4

cores/aliens/hdl/jt051960.v:5 Based on Furrtek's RE work on die shots and MAME documentation
cores/aliens/hdl/jt051960.v:104 original hardware outputs ram_dout[7:1], leaving 7'd0 for compatibility with MAME traces and it also simplifies logic
cores/aliens/hdl/jt051962.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
cores/aliens/hdl/jt052109.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi

Shares text with the MAME driver without saying so — 4

cores/aliens/hdl/jt052109.v:90 00 A~B 6~7 8~9 Reset state — shares text with konami/k052109.cpp:84
cores/aliens/hdl/jt052109.v:91 01 8~9 4~5 6~7 — shares text with konami/k052109.cpp:85
cores/aliens/hdl/jt052109.v:92 10 6~7 2~3 4~5 — shares text with konami/k052109.cpp:86
cores/aliens/hdl/jt052109.v:93 11 4~5 0~1 2~3 — shares text with konami/k052109.cpp:87

jtaliens#
Aliens, Crazy Cop, Crime Fighters, Super Contra: Alien no Gyakushuu …
jotego/jtcores @ b672aca5
MAME compared: konami/aliens.cpp, konami/crimfght.cpp, konami/thunderx.cpp + 7 related file(s)
Read: 11 HDL files, 2,931 lines (files.yaml)

JTCORES

Mostly hardware

low

54%

Statements: 22 toward hardware, 8 toward MAME

Cites hardware documentation that MAME's driver does not — 7

hdl/jt051960.v:5 Based on Furrtek's RE work on die shots and MAME documentation
hdl/jt051962.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
hdl/jt052109.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
hdl/jt052591.v:70 The die schematic gates external reads with BK (CPU_ERAM, sheet 3).
README.md:5 The PALs were dumped by Caius and are published [here](https://wiki.pldarchive.co.uk/index.php?title=Aliens).
README.md:38 /NAS & /A15 & /A14; /ROM1CS =/NAS & A15
README.md:40 /NAS & /NINITSET & A14 & A13 & /BK3; /ROM2CS = /NAS & /NINITSET & /A15 & A14 & A13 & BK3; /CHAIN = NRMRD & /A15 & /A14 & A13 & A12; /INCS = NINITSET & /A15

Ships hardware documentation files — 15

Cites MAME source — 4

hdl/jt051960.v:5 Based on Furrtek's RE work on die shots and MAME documentation
hdl/jt051960.v:104 original hardware outputs ram_dout[7:1], leaving 7'd0 for compatibility with MAME traces and it also simplifies logic
hdl/jt051962.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
hdl/jt052109.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi

Shares text with the MAME driver without saying so — 4

hdl/jt052109.v:90 00 A~B 6~7 8~9 Reset state — shares text with konami/k052109.cpp:84
hdl/jt052109.v:91 01 8~9 4~5 6~7 — shares text with konami/k052109.cpp:85
hdl/jt052109.v:92 10 6~7 2~3 4~5 — shares text with konami/k052109.cpp:86
hdl/jt052109.v:93 11 4~5 0~1 2~3 — shares text with konami/k052109.cpp:87

jtbiocom#
Top Secret
jotego/jtcores @ b672aca5
MAME compared: capcom/bionicc.cpp + 2 related file(s)
Read: 21 HDL files, 3,945 lines (files.yaml)

JTCORES

Mostly hardware

low

24%

Statements: 3 toward hardware, 1 toward MAME

Cites hardware documentation that MAME's driver does not — 1

cores/gng/hdl/jtgng_objdma.v:33 Ghosts'n Goblins copies only 'h180 objects as per schematics 1943 copy more, but it is not clear what the limit is.

Reports a measurement taken on the original PCB — 2

hdl/jtbiocom_colmix.v:5 Resistor values measured on PCB by Caius (Twitter @Caius63417737)
hdl/jtbiocom_main.v:397 Matches measurement of F1-Dream PCB, although the Bionic Commando schematics point to V256, that must be a typo or an old version using V256 prevents the game from registering coin inputs

Cites MAME source — 1

hdl/jtbiocom_mcu.v:86 Current MAME models the MCU-to-sound transfer on the 1-to-0 transition of P3.6.

jtblkout#
Block Out
jotego/jtcores @ b672aca5
MAME compared: technos/blockout.cpp
Read: 6 HDL files, 935 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

11%

Statements: 2 toward MAME

Cites MAME source — 2

hdl/jtblkout_fb.v:62 shift image up 10px (MAME visarea V=10)
README.md:3 FPGA core for the Technos **Block Out** board (MAME `technos/blockout.cpp`, 1989, Technos Japan / California Dreams), plus the `agress` variant on the same PCB

jtbtiger#
Black Dragon
jotego/jtcores @ b672aca5
MAME compared: capcom/blktiger.cpp
Read: 22 HDL files, 4,109 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

13%

Statements: 2 toward hardware, 2 toward MAME

Cites hardware documentation that MAME's driver does not — 2

hdl/jtbtiger_mcu.v:6 based on 1943 schematics
cores/gng/hdl/jtgng_objdma.v:33 Ghosts'n Goblins copies only 'h180 objects as per schematics 1943 copy more, but it is not clear what the limit is.

Cites MAME source — 2

hdl/jtbtiger_mcu.v:38 All bits active low 4 output enable of from-CPU latch 5 clock pin of to-CPU latch 1 clear interrupt only bit 1 is needed in FPGA implementation Note that MAME clears the interrupt in a different way as it does it when the main CPU reads fro
cores/gng/hdl/jtgng_sound.v:9 watch points for MAME: wpset e000,1,w,1,{printf "reg = %X", wpdata;g} wpset e001,1,w,1,{printf "val = %X", wpdata;g}

jtbubl#
Bubble Bobble, Tokio / Scramble Formation
jotego/jtcores @ b672aca5
MAME compared: taito/bublbobl.cpp + 3 related file(s)
Read: 7 HDL files, 1,564 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

42%

Statements: 2 toward hardware, 2 toward MAME

Cites hardware documentation that MAME's driver does not — 2

hdl/jtbubl_main.v:412 This is a jumper on the schematics it can come from P1[6] or from VBL
README.md:26 The cores have been developed by combining information in the MAME drivers with PLD dumps from the PLD archive and with full schematic extraction from the PCBs.

Cites MAME source — 2

cores/kunio/hdl/jtkunio_mcu.v:42 MCU semaphore in MAME jargon
README.md:26 The cores have been developed by combining information in the MAME drivers with PLD dumps from the PLD archive and with full schematic extraction from the PCBs.

jtcal50#
Caliber 50
jotego/jtcores @ b672aca5
MAME compared: seta/downtown.cpp + 2 related file(s)
Read: 10 HDL files, 1,866 lines (files.yaml)

JTCORES

Both

low

67%

Statements: 11 toward hardware, 6 toward MAME

Cites hardware documentation that MAME's driver does not — 1

cores/kiwi/hdl/jtkiwi_gfx.v:9 SETAX1-001, the die shot available shows what it seems to be an internal dual-line buffer and another larger memory

Reports a measurement taken on the original PCB — 1

hdl/jtcal50_video.v:98 Measured on PCB 64us per line, 8us blanking 17.45ms per frame, 2.05ms blanking, 512.5us sync (centered)

Ships hardware documentation files — 9

Cites MAME source — 5

cores/kiwi/hdl/jtkiwi_gfx.v:18 12 = 8kB sprite RAM, page selects the 0x800 half (tnzs/calibr50) 13 = 16kB, page selects the 0x1000 buffer (metafox/arbalest, MAME seta001 setac)
cores/kiwi/hdl/jtkiwi_gfx.v:125 16kB sprite RAM: cfg[1] carries the buffer bank (MAME seta001 setac_eof)
cores/kiwi/hdl/jtkiwi_gfx.v:290 Changed to 16-bit access to ease the drawing logic the upper byte refers to the upper half of the memory for the CPU In MAME the lower half is called spritecodelow and the upper spritecodehigh
cores/kiwi/hdl/jtkiwi_obj.v:12 12 = 8kB sprite RAM, page selects the 0x800 half (tnzs/calibr50) 13 = 16kB, page selects the 0x1000 buffer (metafox/arbalest, MAME seta001 setac)
cores/kiwi/hdl/jtkiwi_tilemap.v:107 This is probably some config setting unexplored by MAME

Says it was translated, ported or taken from MAME — 1

hdl/jtx1012.v:5 X1-012, tilemap currently based on MAME information 64 columns, 32 rows, 16x16 tiles 1024x512 pixels

jtcastle#
Akuma-Jou Dracula
jotego/jtcores @ b672aca5
MAME compared: konami/hcastle.cpp + 5 related file(s)
Read: 10 HDL files, 2,234 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

20%

Statements: 1 toward hardware

Ships hardware documentation files — 1

cores/castle/doc/Konami_052127.jed

jtcircus#
Circus Charlie
jotego/jtcores @ b672aca5
MAME compared: konami/circusc.cpp + 2 related file(s)
Read: 9 HDL files, 1,405 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

13%

Statements: 1 toward hardware

Cites hardware documentation that MAME's driver does not — 1

hdl/jtcircus_main.v:127 74LS259 @ 1D

jtcommnd#
Senjou no Ookami
jotego/jtcores @ b672aca5
MAME compared: capcom/commando.cpp
Read: 18 HDL files, 3,676 lines (files.yaml)

JTCORES

Both

low

41%

Statements: 5 toward hardware, 2 toward MAME, 2 not counted

Cites hardware documentation that MAME's driver does not — 2

hdl/jtcommnd_main.v:430 Schematic 7L - sound interrupter
cores/gng/hdl/jtgng_objdma.v:33 Ghosts'n Goblins copies only 'h180 objects as per schematics 1943 copy more, but it is not clear what the limit is.

Cites hardware references or measurements that MAME's driver also gives — 2

hdl/jtcommnd_game.v:117 PROM 6L (interrupts) — also in MAME: 6L capcom/commando.cpp:103
hdl/jtcommnd_main.v:68 PROM 6L (interrupts) — also in MAME: 6L capcom/commando.cpp:103

Ships hardware documentation files — 3

Cites MAME source — 2

cores/gng/hdl/jtgng_sound.v:9 watch points for MAME: wpset e000,1,w,1,{printf "reg = %X", wpdata;g} wpset e001,1,w,1,{printf "val = %X", wpdata;g}
README.md:24 The ROM Master, aka Bruno Silva, has provided us with a .bat file to generate the necessary ROM file using MAME ROM files.

jtcomsc#
Combat School
jotego/jtcores @ b672aca5
MAME compared: konami/combatsc.cpp + 8 related file(s)
Read: 10 HDL files, 2,241 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

No statements found

jtcontra#
Contra
jotego/jtcores @ b672aca5
MAME compared: konami/contra.cpp + 7 related file(s)
Read: 11 HDL files, 2,192 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

No statements found

jtcop#
Fighting Fantasy, Robocop
jotego/jtcores @ b672aca5
MAME compared: dataeast/dec0.cpp + 7 related file(s)
Read: 13 HDL files, 3,429 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

13%

Statements: 1 toward hardware

Cites hardware documentation that MAME's driver does not — 1

hdl/jtcop_bac06.v:27 The /NUDS and /NLDS inputs of all chips are gated via a 74LS32 chip by the /DSP chip select signal.

jtcps1#
1941: Counter Attack, Wonder 3, Area 88, Captain Commando …
jotego/jtcores @ b672aca5
MAME compared: capcom/cps1.cpp + 4 related file(s)
Read: 23 HDL files, 5,611 lines (files.yaml)

JTCORES

Both

low

11%

Statements: 2 toward hardware, 7 toward MAME, 1 not counted

Cites hardware documentation that MAME's driver does not — 2

README.md:100 Use the tool jedutil in order to extract the equations from them.
README.md:103 jedutil -view wl24b.1a gal16v8

Cites hardware references or measurements that MAME's driver also gives — 1

hdl/jtcps1_main.v:168 PAL IOA1 (16P8B @ 12F) — also in MAME: 12F capcom/cps1.cpp:35

Cites MAME source — 6

hdl/jtcps1_mmr.v:176 MAME uses the same values for layers 3 and 4 so I just skip layer 4 from the configuration.
README.md:262 Video only simulations can be done using mame dumps.
README.md:262 Use the tool *cfg2mame* in the *ver/video* folder to create two *.mame* files that can invoked from mame to dump the simulation data.
README.md:263 Run the game in debug mode but source from MAME the register file that *cfg2mame* creates.
README.md:264 Then at the point of interest souce *vram.mame*.
README.md:264 Copy that file to a directory with the mame name of the game.

Says it was translated, ported or taken from MAME — 1

hdl/jtcps1_prom_we.v:99 The decryption is literally copied from MAME, it is up to the synthesizer to optimize the code.

jtcps15#
Cadillacs: Kyouryuu Shin Seiki, Muscle Bomber: The Body Explosion, Muscle Bomber Duo: Heat Up Warriors, The Punisher …
jotego/jtcores @ b672aca5
MAME compared: capcom/cps1.cpp + 4 related file(s)
Read: 23 HDL files, 5,880 lines (files.yaml)

JTCORES

Both

low

11%

Statements: 2 toward hardware, 7 toward MAME, 1 not counted

Cites hardware documentation that MAME's driver does not — 2

README.md:92 Use the tool jedutil in order to extract the equations from them.
README.md:95 jedutil -view wl24b.1a gal16v8

Cites hardware references or measurements that MAME's driver also gives — 1

cores/cps1/hdl/jtcps1_main.v:168 PAL IOA1 (16P8B @ 12F) — also in MAME: 12F capcom/cps1.cpp:35

Cites MAME source — 6

cores/cps1/hdl/jtcps1_mmr.v:176 MAME uses the same values for layers 3 and 4 so I just skip layer 4 from the configuration.
README.md:254 Video only simulations can be done using mame dumps.
README.md:254 Use the tool *cfg2mame* in the *ver/video* folder to create two *.mame* files that can invoked from mame to dump the simulation data.
README.md:255 Run the game in debug mode but source from MAME the register file that *cfg2mame* creates.
README.md:256 Then at the point of interest souce *vram.mame*.
README.md:256 Copy that file to a directory with the mame name of the game.

Says it was translated, ported or taken from MAME — 1

cores/cps1/hdl/jtcps1_prom_we.v:99 The decryption is literally copied from MAME, it is up to the synthesizer to optimize the code.

jtcps2#
1944: The Loop Master, 19XX: The War Against Destiny, Powered Gear: Strategic Variant Armor Equipment, Alien vs. Predator …
jotego/jtcores @ b672aca5
MAME compared: capcom/cps2.cpp + 8 related file(s)
Read: 36 HDL files, 7,819 lines (files.yaml)

JTCORES

Both

low

15%

Statements: 3 toward hardware, 7 toward MAME

Cites hardware documentation that MAME's driver does not — 3

hdl/jtcps2_main.v:415 according to Loic's DL-1827 schematic
README.md:92 Use the tool jedutil in order to extract the equations from them.
README.md:95 jedutil -view wl24b.1a gal16v8

Cites MAME source — 6

cores/cps1/hdl/jtcps1_mmr.v:176 MAME uses the same values for layers 3 and 4 so I just skip layer 4 from the configuration.
README.md:253 Video only simulations can be done using mame dumps.
README.md:253 Use the tool *cfg2mame* in the *ver/video* folder to create two *.mame* files that can invoked from mame to dump the simulation data.
README.md:254 Run the game in debug mode but source from MAME the register file that *cfg2mame* creates.
README.md:255 Then at the point of interest souce *vram.mame*.
README.md:255 Copy that file to a directory with the mame name of the game.

Says it was translated, ported or taken from MAME — 1

cores/cps1/hdl/jtcps1_prom_we.v:99 The decryption is literally copied from MAME, it is up to the synthesizer to optimize the code.

jtcps3#
JoJo no Kimyou na Bouken: Mirai e no Isan, JoJo no Kimyou na Bouken, Warzard, Street Fighter III 2nd Impact: Giant Attack …
jotego/jtcores @ b672aca5
MAME compared: capcom/cps3.cpp + 3 related file(s)
Read: 25 HDL files, 6,271 lines (files.yaml)

JTCORES

Mostly hardware

low

27%

Statements: 47 toward hardware, 1 toward MAME

Ships hardware documentation files — 47

Cites MAME source — 1

hdl/jtcps3_chardma.v:78 Command list pointer: word index inside 8 MiB char RAM (MAME-style)

jtdd#
Double Dragon
jotego/jtcores @ b672aca5
MAME compared: technos/ddragon.cpp + 2 related file(s)
Read: 9 HDL files, 1,527 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

40%

Statements: 4 toward hardware, 2 toward MAME

Cites hardware documentation that MAME's driver does not — 4

hdl/jtdd_main.v:74 sheet 8/10
hdl/jtdd_main.v:155 Schematic sheet 3/9
hdl/jtdd_obj.v:5 Schematics 3-7/10 OBJ Object layer Max 32 sprites per line
hdl/jtdd_scroll.v:5 Schematics 8/10 and 9/10 BACK Scroll layer

Cites MAME source — 2

README.md:23 ADPCM sounds with less treble than in MAME.
README.md:106 The rom folder contains the batch files for both linux and windows to generate the ROM file starting from a MAME set.

jtdd2#
Double Dragon II: The Revenge
jotego/jtcores @ b672aca5
MAME compared: technos/ddragon.cpp + 2 related file(s)
Read: 8 HDL files, 1,477 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

42%

Statements: 4 toward hardware, 2 toward MAME

Cites hardware documentation that MAME's driver does not — 4

cores/dd/hdl/jtdd_main.v:74 sheet 8/10
cores/dd/hdl/jtdd_main.v:155 Schematic sheet 3/9
cores/dd/hdl/jtdd_obj.v:5 Schematics 3-7/10 OBJ Object layer Max 32 sprites per line
cores/dd/hdl/jtdd_scroll.v:5 Schematics 8/10 and 9/10 BACK Scroll layer

Cites MAME source — 2

README.md:23 ADPCM sounds with less treble than in MAME.
README.md:107 The rom folder contains the batch files for both linux and windows to generate the ROM file starting from a MAME set.

jtddrbl#
Double Dribble
jotego/jtcores @ b672aca5
MAME compared: konami/ddribble.cpp + 1 related file(s)
Read: 9 HDL files, 1,787 lines (files.yaml)

JTCORES

Both

low

51%

Statements: 10 toward hardware, 8 toward MAME

Cites hardware documentation that MAME's driver does not — 10

hdl/jtddrbl_main.v:4 Hardware on the same SCHEMATIC page that holds the MAIN MC6809E: - MC6809E main CPU (drawn as "6809E" — pin-compatible footprint) visible pins: HALT, NMI, IRQ, FIRQ, RESET, BS, BA, R/W, E, Q, AVMA, BUSY, LIC, TSC, A0..A15, D0..D7 - 27512 ma
hdl/jtddrbl_main.v:60 CPU A0..A15 bus (visible on SCHEMATIC page 1 main CPU pins)
hdl/jtddrbl_main.v:71 ROM address composition — physical chip is one 27512 (64 KB) on SCHEMATIC page 1.
hdl/jtddrbl_main.v:143 chip 1 NFIR (swap per schematic)
hdl/jtddrbl_main.v:144 chip 1 NIRQ (swap per schematic)
hdl/jtddrbl_sound.v:4 Hardware on SCHEMATIC page 1 top-right (tile_p1_topR.png): - MC6809E sound CPU - 27256 sound program EPROM (32 KB) — adjacent to the CPU - 2128SL sound work RAM (2 KB) — but MAME's map uses it as the SUB↔SOUND shared RAM (0x0000-0x07FF), so
hdl/jtddrbl_sound.v:18 YM2203 + VLM5030 both run on the 3.58 MHz xtal — SCHEMATIC page 1.
hdl/jtddrbl_sound.v:163 YM2203 runs on the 3.58 MHz xtal (SCHEMATIC page 1).
hdl/jtddrbl_sound.v:205 VLM5030 runs on the 3.58 MHz xtal (SCHEMATIC page 1), gated by vlm_cen.
hdl/jtddrbl_sub.v:4 Hardware on schematic page 1 (sub CPU + sound CPU + I/O): - MC6809E at designator A12 (top-left area of page 1), full 6809E pinout visible pins: HALT, NMI, IRQ, FIRQ, RESET, BS, BA, R/W, CLKE (pin 34), CLKQ (pin 35), AVMA, BUSY, TSC, A0..A1

Cites MAME source — 7

hdl/jtddrbl_main.v:115 MAME ref: konami/ddribble.cpp:331-334 void bankswitch_w(uint8_t data) { m_mainbank->set_entry(data & 0x07); } → 3-bit bank field, latched on write to 0x8000.
hdl/jtddrbl_obj.v:81 MAME masks the base number per size (ddribble.cpp draw_sprites):
hdl/jtddrbl_scroll.v:43 SDRAM is byteswap16(MAME) and the converter wants MAME packed_msb, so byteswap each 16-bit half before the transpose.
hdl/jtddrbl_sound.v:4 Hardware on SCHEMATIC page 1 top-right (tile_p1_topR.png): - MC6809E sound CPU - 27256 sound program EPROM (32 KB) — adjacent to the CPU - 2128SL sound work RAM (2 KB) — but MAME's map uses it as the SUB↔SOUND shared RAM (0x0000-0x07FF), so
hdl/jtddrbl_sound.v:19 MAME ref (pinned 347fd2c) for things not directly readable from the sheets: - konami/ddribble.cpp:413-419 sound CPU memory map (exact ranges)
hdl/jtddrbl_sound.v:89 Y1 (0x1000-0x1FFF) OPN → YM2203 /CS [MAME ddribble.cpp:416 = 0x1000-0x1001]
hdl/jtddrbl_sound.v:90 Y3 (0x3000-0x3FFF) VDATA → VLM5030 data latch [MAME ddribble.cpp:417 = 0x3000] Y6 (0x6000-0x6FFF) IRQEN → sound-IRQ ACKNOWLEDGE.

Shares text with the MAME driver without saying so — 1

hdl/jtddrbl_main.v:116 void bankswitch_w(uint8_t data) { m_mainbank->set_entry(data & 0x07); } — shares text with konami/ddribble.cpp:87

jtexed#
Exed Exes
jotego/jtcores @ b672aca5
MAME compared: capcom/exedexes.cpp
Read: 21 HDL files, 4,012 lines (files.yaml)

JTCORES

Mostly hardware

low

41%

Statements: 43 toward hardware

Cites hardware documentation that MAME's driver does not — 6

cores/commnd/hdl/jtcommnd_main.v:68 PROM 6L (interrupts)
cores/commnd/hdl/jtcommnd_main.v:430 Schematic 7L - sound interrupter
hdl/jtexed_game.v:153 PROM 6L (interrupts)
hdl/jtexed_sound.v:5 based on 1942 Schematics page 3/8
cores/gng/hdl/jtgng_objdma.v:33 Ghosts'n Goblins copies only 'h180 objects as per schematics 1943 copy more, but it is not clear what the limit is.
README.md:34 The core is made based on the actual schematics, not emulators.

Ships hardware documentation files — 37

jtflane#
Fast Lane
jotego/jtcores @ b672aca5
MAME compared: konami/fastlane.cpp + 7 related file(s)
Read: 9 HDL files, 1,919 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

No statements found

jtflstory#
Cycle Shooting, N.Y. Captor, The FairyLand Story, Onna Sanshirou - Typhoon Gal …
jotego/jtcores @ b672aca5
MAME compared: taito/flstory.cpp, taito/nycaptor.cpp + 1 related file(s)
Read: 17 HDL files, 2,212 lines (files.yaml)

JTCORES

Mostly hardware

low

24%

Statements: 28 toward hardware

Cites hardware documentation that MAME's driver does not — 3

hdl/jtflstory_mcu.v:69 74LS74 set input has priority over clock
hdl/jtflstory_mcu.v:75 74LS74 set input has priority over clock
README.md:3 This work is based on the schematic work we did on an original FairyLand arcade PCB.

Ships hardware documentation files — 25

jtfround#
Hard Puncher
jotego/jtcores @ b672aca5
MAME compared: konami/twin16.cpp + 3 related file(s)
Read: 13 HDL files, 2,375 lines (files.yaml)

JTCORES

Mostly hardware

low

37%

Statements: 17 toward hardware, 2 toward MAME

Cites hardware documentation that MAME's driver does not — 3

hdl/jt00778x.v:5 Based on Skutis' RE work on die shots and MAME documentation
hdl/jt00778x.v:80 original equation from schematics, it is the same as the start of vblank
README.md:20 This core is based on the official schematics for this system and the reverse engineering work done by Skutis on them.

Ships hardware documentation files — 14

Cites MAME source — 2

hdl/jt00778x.v:5 Based on Skutis' RE work on die shots and MAME documentation
hdl/jtfround_video.v:154 60.6 Hz according to MAME

jtgae1#
Big Karnak, Biomechanical Toy, Squash, Thunder Hoop
jotego/jtcores @ b672aca5
MAME compared: gaelco/gaelco.cpp + 4 related file(s)
Read: 9 HDL files, 1,473 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

Statements: 1 toward MAME

Says it was translated, ported or taken from MAME — 1

README.md:4 This core is based on the MAME driver for Gaelco GAE1 hardware and some PCB measurements to validate clock, video frequencies and discard DMA behavior.

jtgaiden#
Ninja Ryukenden, Raiga - Strato Fighter, Wild Fang
jotego/jtcores @ b672aca5
MAME compared: tecmo/gaiden.cpp + 2 related file(s)
Read: 17 HDL files, 1,814 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

Statements: 3 toward MAME

Cites MAME source — 3

README.md:7 The core mostly follows MAME, with deviations natural from a digital logic implementation point of view.
README.md:9 Blending is implemented by blinking the two elements to blend, this is different from MAME's implementation.
README.md:14 Some items may not be accurate on MAME driver and should be double checked:

jtgals#
Gals Panic
jotego/jtcores @ b672aca5
MAME compared: kaneko/galpanic.cpp + 5 related file(s)
Read: 7 HDL files, 1,087 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

No statements found

jtgng#
Makaimura
jotego/jtcores @ b672aca5
MAME compared: capcom/gng.cpp
Read: 18 HDL files, 3,370 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

13%

Statements: 2 toward hardware, 1 toward MAME

Cites hardware documentation that MAME's driver does not — 2

hdl/jtgng_objdma.v:33 Ghosts'n Goblins copies only 'h180 objects as per schematics 1943 copy more, but it is not clear what the limit is.
README.md:37 A verilog model of the original hardware, replicated from original schematics.

Cites MAME source — 1

hdl/jtgng_sound.v:9 watch points for MAME: wpset e000,1,w,1,{printf "reg = %X", wpdata;g} wpset e001,1,w,1,{printf "val = %X", wpdata;g}

jtgrad3#
Gradius III: Densetsu kara Shinwa e, Gradius III (NEW Ver.)
jotego/jtcores @ b672aca5
MAME compared: konami/gradius3.cpp + 7 related file(s)
Read: 14 HDL files, 2,851 lines (files.yaml)

JTCORES

Both

low

51%

Statements: 18 toward hardware, 8 toward MAME

Cites hardware documentation that MAME's driver does not — 5

cores/aliens/hdl/jt051960.v:5 Based on Furrtek's RE work on die shots and MAME documentation
cores/aliens/hdl/jt051962.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
cores/aliens/hdl/jt052109.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
hdl/jtgrad3_arbiter.v:5 F22, the video bus mutex: one 74LS74 with its halves clocked on opposite phases of the 24 MHz clock, each Q asynchronously presetting the other.
hdl/jtgrad3_colmix.v:5 Based on the work in Gradius III schematics by Skutis

Ships hardware documentation files — 13

Cites MAME source — 4

cores/aliens/hdl/jt051960.v:5 Based on Furrtek's RE work on die shots and MAME documentation
cores/aliens/hdl/jt051960.v:104 original hardware outputs ram_dout[7:1], leaving 7'd0 for compatibility with MAME traces and it also simplifies logic
cores/aliens/hdl/jt051962.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
cores/aliens/hdl/jt052109.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi

Shares text with the MAME driver without saying so — 4

cores/aliens/hdl/jt052109.v:90 00 A~B 6~7 8~9 Reset state — shares text with konami/k052109.cpp:84
cores/aliens/hdl/jt052109.v:91 01 8~9 4~5 6~7 — shares text with konami/k052109.cpp:85
cores/aliens/hdl/jt052109.v:92 10 6~7 2~3 4~5 — shares text with konami/k052109.cpp:86
cores/aliens/hdl/jt052109.v:93 11 4~5 0~1 2~3 — shares text with konami/k052109.cpp:87

jtgunsmk#
Gun.Smoke
jotego/jtcores @ b672aca5
MAME compared: capcom/gunsmoke.cpp
Read: 16 HDL files, 2,977 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

32%

Statements: 3 toward hardware, 1 toward MAME

Cites hardware documentation that MAME's driver does not — 2

cores/gng/hdl/jtgng_objdma.v:33 Ghosts'n Goblins copies only 'h180 objects as per schematics 1943 copy more, but it is not clear what the limit is.
hdl/jtgunsmk_main.v:200 1943 Schematics page 5/9, parts 12J and 14K

Reports a measurement taken on the original PCB — 1

hdl/jtgunsmk_game.v:123 Objects DMA timing measured on real PCB was roughly 130us which correspons to these parameters:

Cites MAME source — 1

cores/gng/hdl/jtgng_sound.v:9 watch points for MAME: wpset e000,1,w,1,{printf "reg = %X", wpdata;g} wpset e001,1,w,1,{printf "val = %X", wpdata;g}

jtharier#
Enduro Racer, Hang-On, Space Harrier
jotego/jtcores @ b672aca5
MAME compared: sega/segahang.cpp + 13 related file(s)
Read: 20 HDL files, 4,130 lines (files.yaml)

JTCORES

Both

medium

70%

Statements: 18 toward hardware, 30 toward MAME, 1 not counted

Cites hardware documentation that MAME's driver does not — 16

hdl/jtharier_cab.v:5 Flight-stick conditioning to ADC0/ADC1, CPU sheet 2/6 (IC126/IC125).
hdl/jtharier_colmix.v:65 SHADE from 315-5171, sheet 6/7.
hdl/jtharier_main.v:22 Address decode, CK-2605 315-5166 on CPU sheet 1/6
hdl/jtharier_main.v:38 Work RAM, IC96/IC83 on CPU sheet 1/6
hdl/jtharier_main.v:79 Sub PPI port A, CPU sheet 2/6
hdl/jtharier_main.v:83 i8751, CPU sheet 1/6
hdl/jtharier_main.v:174 IC106 (CK-2605 315-5168, control sheet 1/7) decides it from /VRAM, AD1, AD15, H3, HA3, HB3 and /HSYNC -- no vertical input, so it applies to every VRAM access all frame long.
hdl/jtharier_main.v:293 Flight-stick ADC at 140030, sheet 2/6: IC126 ADC0804 behind the IC125 CD4051 mux, channel select from PPI1 port A[3:2], /INTR returned on PPI1 port C bit 6.
hdl/jtharier_main.v:399 The board does this with the BREQ/BACK handshake at IC23/IC8/IC9 (sheet 1/6); jts16_main models the S16A equivalent, its IC69 82S153.
hdl/jtharier_road.v:5 Space Harrier road generator: the 315-5025 custom (sheet 4/6), road control RAM 2016 x2 (IC50/IC63), road data ROM EPR-7181 (IC2), LS669 x3 counters (IC14/15/16).
hdl/jtharier_road.v:7 The 315-5025 has no decap, so its per-pixel behaviour comes from MAME's model -- the last-resort source for a custom the schematic and the siblings cannot describe.
hdl/jtharier_roadarb.v:5 Road RAM CPU-port arbiter, CPU sheet 3/6.
hdl/jtharier_sound.v:15 Main CPU interface via PPI0, CPU sheet 2/6
hdl/jtharier_sub.v:14 Shared RAM and road RAM, dual ported through the LS157 mux IC80-IC83, CPU sheet 3/6
hdl/jtharier_sub.v:26 Program ROM EPR-7182/7183, CPU sheet 3/6
README.md:5 This core is based on the schematics for Space Harrier, the JTS16 and JTOUTRUN cores for parts of the graphics and sound system, and on the documentation of spr

Cites hardware references or measurements that MAME's driver also gives — 1

hdl/jtharier_road.v:95 4-bit counter at 9M, low 3 bits count bits in a byte — also in MAME: 9M sega/segaic16_road.cpp:111

Reports a measurement taken on the original PCB — 1

cores/s16/hdl/jts16_tilemap.v:135 Measured on PCB vint lasts 64us, starts one line before blanking vsync occurs 16 lines later

Ships hardware documentation files — 1

cores/harier/pal/315-5171.txt

Cites MAME source — 24

hdl/jtharier_main.v:158 Block the MCU's write to the main/MCU sync byte at 0x040385, as MAME does unconditionally (segahang.cpp i8751_w: "the cpu is too fast or the mcu too slow ...
hdl/jtharier_main.v:295 ADC0 is stick X and ADC1 stick Y, both centred at 0x80 (segahang.cpp:915).
hdl/jtharier_obj.v:111 The sharrier device origin is (189,-1) (sega16sp.cpp), so HOBJ_START = 189 reads device x 189 out on column 0, and HOBJ_FLIP = 508 is the same column flipped -- the buffer's own flip pivots on 511, the wrong point for a 189..508 window.
hdl/jtharier_obj_draw.v:7 ATTRIBUTION -- the draw algorithm is derived from MAME `sega_sharrier_sprite_device::draw` in sega16sp.cpp (Aaron Giles, BSD-3-Clause).
hdl/jtharier_obj_draw.v:12 Horizontal zoom is shrink-only, sega16sp.cpp:398: xacc = (xacc & 0xff) + hzoom; if(xacc < 0x100){ draw; screen x++ } The source pixel always advances; the screen pixel only when xacc did not carry.
hdl/jtharier_obj_draw.v:15 Flip reads words and nibbles in reverse (sega16sp.cpp:420).
hdl/jtharier_obj_draw.v:21 pal==6'h3f is shadow (segahang.cpp:282).
hdl/jtharier_obj_draw.v:39 MAME value: (field & 0x3f) << 1
hdl/jtharier_obj_draw.v:74 per-pixel shadow: shadow-enabled AND pix==0xA (segahang.cpp:282, (pix&0x80f)==0x00a)
hdl/jtharier_obj_scan.v:7 ATTRIBUTION -- derived from MAME `sega_sharrier_sprite_device::draw` in sega16sp.cpp (Aaron Giles, BSD-3-Clause).
hdl/jtharier_obj_scan.v:11 Descriptor (8 words, sega16sp.cpp:291); words +0..+8 only: +0 bbbbbbbb tttttttt bottom=[15:8], top=[7:0] (DEVICE scanlines) +2 -bbb---- -------- bank +2 -------x xxxxxxxx xpos (xpos $BD = screen X 0, applied in _obj.v) +4 s------
hdl/jtharier_obj_scan.v:26 Vertical zoom is stateful down the sprite, sega16sp.cpp:367: for y = top..bottom-1: addr += pitch; if(zoom[zaddr++] & zmask) addr += pitch zaddr = (vzoom & 0x38) << 5 == { vzoom[5:3], 8'd0 } zmask = 1 << (vzoom & 7) == zoom_data[ v
hdl/jtharier_obj_scan.v:195 MAME: (field & 0x3f) << 1
hdl/jtharier_road.v:7 The 315-5025 has no decap, so its per-pixel behaviour comes from MAME's model -- the last-resort source for a custom the schematic and the siblings cannot describe.
hdl/jtharier_road.v:9 The state names are MAME's and map onto the sheet-4/6 parts -- 9M/9N/9P = LS669, 8J = LS164, 9J = LS174 -- so the transcription can be checked against segaic16_road.cpp line for line.
hdl/jtharier_road.v:19 Road control RAM word map (roadram, 0x400 words used of 0x800), MAME offsets /2: 0x000-0x0FF per scanline: control [11:10] plycont road priority vs tilemaps/sprites [9] /CE of the road ROM (Space Harrier: 1 disables ROM data) [8]
hdl/jtharier_road.v:58 Colour bases, segahang.cpp:190 segaic16_road_init(0, ROAD_SHARRIER).
hdl/jtharier_road.v:63 The pipeline runs from x=-24 to warm ss8j and the counters but must not be drawn (segaic16_road.cpp:199).
hdl/jtharier_road.v:69 PROVISIONAL: this value agrees with MAME, and MAME is not the authority here.
hdl/jtharier_road.v:94 Per-pixel engine state, MAME node names retained
hdl/jtharier_road.v:122 ff9j1 with the forcing applied (MAME 137-142), combinational so the forced value feeds this cycle's 6M updates rather than the next.
hdl/jtharier_video.v:103 The fault is in the mask ROM, confirmed on the cabinet and in MAME.
hdl/jtharier_video.v:164 Text/HUD is at the very front: segahang.cpp inflates the text priority so sprites never cover the high scores.
README.md:5 This core is based on the schematics for Space Harrier, the JTS16 and JTOUTRUN cores for parts of the graphics and sound system, and on the documentation of spr

Says it matches, follows or was checked against MAME — 1

hdl/jtharier_cab.v:33 matches MAME PORT_KEYDELTA(4)

Says it was translated, ported or taken from MAME — 1

hdl/jtharier_road.v:14 license:BSD-3-Clause copyright-holders:Aaron Giles Transcribed from MAME segaic16_road.cpp, segaic16_road_hangon_draw (ROAD_SHARRIER path).

Shares text with the MAME driver without saying so — 4

hdl/jtharier_main.v:159 unconditionally (segahang.cpp i8751_w: "the cpu is too fast or the mcu too — shares text with sega/segahang.cpp:523
hdl/jtharier_main.v:160 slow ... the mcu clears this value after the cpu sets it"). If the clear lands, — shares text with sega/segahang.cpp:524
hdl/jtharier_obj_draw.v:5 Sprite row renderer for the Space Harrier custom (315-5011/5012). ATTRIBUTION -- the draw algorithm is derived from MAME `sega_sharrier_sprite_device:: — shares text with sega/sega16sp.cpp
hdl/jtharier_obj_scan.v:5 Sprite table scanner for the Space Harrier custom (315-5011/5012). ATTRIBUTION -- derived from MAME `sega_sharrier_sprite_device::draw` in sega16sp.cpp — shares text with sega/sega16sp.cpp

jtkarnov#
Atomic Runner Chelnov, Karnov, Wonder Planet
jotego/jtcores @ b672aca5
MAME compared: dataeast/karnov.cpp + 4 related file(s)
Read: 6 HDL files, 1,285 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

23%

Statements: 1 toward hardware

Cites hardware documentation that MAME's driver does not — 1

hdl/jtkarnov_main.v:103 page 7/16)

jtkchamp#
Karate Dou, Taisen Karate Dou
jotego/jtcores @ b672aca5
MAME compared: dataeast/kchamp.cpp + 2 related file(s)
Read: 7 HDL files, 1,139 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

Statements: 1 toward MAME

Cites MAME source — 1

README.md:15 The single player version was derived from the MAME driver and the 2P version.

jtkicker#
Kicker
jotego/jtcores @ b672aca5
MAME compared: konami/shaolins.cpp
Read: 8 HDL files, 1,393 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

20%

Statements: 2 toward hardware, 1 toward MAME

Cites hardware documentation that MAME's driver does not — 1

README.md:4 We have analysed the PCB and extracted full schematics from it.

Ships hardware documentation files — 1

cores/kicker/sch/kicker.kicad_sch

Cites MAME source — 1

README.md:4 The discoveries found during this process have been reported to the MAME team.

jtkiwi#
Arkanoid - Revenge of DOH, Chuka Taisen, Dr. Toppel's Tankentai, Extermination …
jotego/jtcores @ b672aca5
MAME compared: taito/tnzs.cpp + 3 related file(s)
Read: 9 HDL files, 2,131 lines (files.yaml)

JTCORES

Both

low

46%

Statements: 38 toward hardware, 6 toward MAME

Cites hardware documentation that MAME's driver does not — 2

hdl/jtkiwi_gfx.v:9 SETAX1-001, the die shot available shows what it seems to be an internal dual-line buffer and another larger memory
README.md:31 The cores have been developed by combining information in the MAME drivers with PLD dumps from the PLD archive and with full schematic extraction from the PCBs.

Ships hardware documentation files — 36

Cites MAME source — 6

hdl/jtkiwi_gfx.v:18 12 = 8kB sprite RAM, page selects the 0x800 half (tnzs/calibr50) 13 = 16kB, page selects the 0x1000 buffer (metafox/arbalest, MAME seta001 setac)
hdl/jtkiwi_gfx.v:125 16kB sprite RAM: cfg[1] carries the buffer bank (MAME seta001 setac_eof)
hdl/jtkiwi_gfx.v:290 Changed to 16-bit access to ease the drawing logic the upper byte refers to the upper half of the memory for the CPU In MAME the lower half is called spritecodelow and the upper spritecodehigh
hdl/jtkiwi_obj.v:12 12 = 8kB sprite RAM, page selects the 0x800 half (tnzs/calibr50) 13 = 16kB, page selects the 0x1000 buffer (metafox/arbalest, MAME seta001 setac)
hdl/jtkiwi_tilemap.v:107 This is probably some config setting unexplored by MAME
README.md:31 The cores have been developed by combining information in the MAME drivers with PLD dumps from the PLD archive and with full schematic extraction from the PCBs.

jtkunio#
Nekketsu Kouha Kunio-kun
jotego/jtcores @ b672aca5
MAME compared: technos/renegade.cpp
Read: 9 HDL files, 1,302 lines (files.yaml)

JTCORES

Mostly hardware

low

25%

Statements: 16 toward hardware, 3 toward MAME

Ships hardware documentation files — 16

Cites MAME source — 3

hdl/jtkunio_mcu.v:42 MCU semaphore in MAME jargon
README.md:23 ADPCM sounds with less treble than in MAME.
README.md:107 The rom folder contains the batch files for both linux and windows to generate the ROM file starting from a MAME set.

jtlabrun#
Labyrinth Runner
jotego/jtcores @ b672aca5
MAME compared: konami/labyrunr.cpp + 7 related file(s)
Read: 13 HDL files, 2,564 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

No statements found

jtmidres#
Midnight Resistance
jotego/jtcores @ b672aca5
MAME compared: dataeast/dec0.cpp + 7 related file(s)
Read: 12 HDL files, 3,164 lines (files.yaml)

JTCORES

Mostly hardware

low

35%

Statements: 7 toward hardware, 1 toward MAME

Cites hardware documentation that MAME's driver does not — 1

cores/cop/hdl/jtcop_bac06.v:27 The /NUDS and /NLDS inputs of all chips are gated via a 74LS32 chip by the /DSP chip select signal.

Ships hardware documentation files — 6

Cites MAME source — 1

hdl/jtmidres_colmix.v:5 The layer priority is solved as in MAME I hope to get access to a Midnight Resistance board at some point and derive the original circuit

jtmikie#
Shinnyuu Shain Tooru-kun
jotego/jtcores @ b672aca5
MAME compared: konami/mikie.cpp + 1 related file(s)
Read: 9 HDL files, 1,548 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

12%

Statements: 2 toward hardware, 1 toward MAME

Cites hardware documentation that MAME's driver does not — 2

hdl/jtmikie_main.v:126 74LS259
README.md:4 We have analysed the PCB and extracted full schematics from it.

Cites MAME source — 1

README.md:4 The discoveries found during this process have been reported to the MAME team.

jtmx5k#
Flak Attack
jotego/jtcores @ b672aca5
MAME compared: konami/flkatck.cpp + 7 related file(s)
Read: 12 HDL files, 2,416 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

Statements: 1 toward hardware

Cites hardware documentation that MAME's driver does not — 1

hdl/jtmx5k_video.v:149 Note that the logic gates 13F and 14F in the schematics use the object and tile blank information so the second K007121 selects between object and sprite correctly This second K007121 has been removed from the FPGA core and instead the pale

jtninja#
Dragonninja, Heavy Barrel
jotego/jtcores @ b672aca5
MAME compared: dataeast/dec0.cpp + 7 related file(s)
Read: 12 HDL files, 3,185 lines (files.yaml)

JTCORES

Mostly hardware

low

31%

Statements: 7 toward hardware, 1 toward MAME

Cites hardware documentation that MAME's driver does not — 1

cores/cop/hdl/jtcop_bac06.v:27 The /NUDS and /NLDS inputs of all chips are gated via a 74LS32 chip by the /DSP chip select signal.

Ships hardware documentation files — 6

Cites MAME source — 1

README.md:63 BAC06 chip | Region | Total Size | MSFT | MAME gfx

jtoutrun#
Out Run, Turbo Out Run
jotego/jtcores @ b672aca5
MAME compared: sega/segaorun.cpp + 15 related file(s)
Read: 24 HDL files, 5,534 lines (files.yaml)

JTCORES

Mostly hardware

low

60%

Statements: 7 toward hardware, 4 toward MAME

Cites hardware documentation that MAME's driver does not — 4

hdl/jtoutrun_colmix.v:5 Video board, schematic sheet 5 of 7
hdl/jtoutrun_main.v:28 SG bus on page 6/7
hdl/jtoutrun_video.v:149 first 8kB of pal RAM dumped
cores/s16b/hdl/jts16b_mapper.v:232 see schematics page 10

Reports a measurement taken on the original PCB — 1

cores/s16/hdl/jts16_tilemap.v:135 Measured on PCB vint lasts 64us, starts one line before blanking vsync occurs 16 lines later

Ships hardware documentation files — 1

cores/outrun/pal/315-5228.txt

Notes where it differs from MAME — 1

hdl/jtoutrun_snd.v:86 The schematics have it, MAME doesn't

Cites MAME source — 2

hdl/jtoutrun_motor.v:5 dummy motor, follows MAME's implementation
cores/s16/hdl/jts16_fd1094_dec.v:146 decoding, pretty much copy-paste from MAME's fd1094.cpp I trust the synthesizer to simplify the equations

Shares text with the MAME driver without saying so — 2

hdl/jtoutrun_pcm.v:6 Clock input 16.000MHz on pin 80 — shares text with sega/segaorun.cpp:100
hdl/jtoutrun_pcm.v:7 Clock outputs: pin 2 - 4.000MHz, pin 80 - 500.000kHz, pin 89 - 62.500KHz — shares text with sega/segaorun.cpp:101

jtpaclan#
Pac-Land
jotego/jtcores @ b672aca5
MAME compared: namco/pacland.cpp
Read: 15 HDL files, 1,613 lines (files.yaml)

JTCORES

Both

low

26%

Statements: 2 toward hardware, 3 toward MAME

Cites hardware documentation that MAME's driver does not — 1

cores/shouse/hdl/jtcus30.sv:5 Implementation of Namco's CUS30 - 8-channel stereo DAC Based on MAME's namco_snd.cpp information and Atari's schematics

Says it was checked against the original PCB — 1

hdl/jtpaclan_main.v:137 verified on PCB

Cites MAME source — 2

cores/shouse/hdl/jtcus30.sv:8 The frequency number is the step added to the channel counter each waveform is 32-byte long MAME reports 12kHz as sampling frequency 15 kHz * 8 = 120 kHz 1536 kHz / 120 kHz = 12
cores/shouse/hdl/jtshouse_vtimer.v:27 60.6 Hz according to MAME

Says it was translated, ported or taken from MAME — 1

cores/shouse/hdl/jtcus30.sv:5 Implementation of Namco's CUS30 - 8-channel stereo DAC Based on MAME's namco_snd.cpp information and Atari's schematics

jtpang#
Pomping World, Block Block, Capcom World, Dokaben …
jotego/jtcores @ b672aca5
MAME compared: capcom/mitchell.cpp + 2 related file(s)
Read: 7 HDL files, 1,183 lines (files.yaml)

JTCORES

Mostly hardware

low

20%

Statements: 9 toward hardware

Ships hardware documentation files — 9

jtparoda#
Parodius Da!: Shinwa kara Owarai e, Surprise Attack
jotego/jtcores @ b672aca5
MAME compared: konami/parodius.cpp, konami/surpratk.cpp + 9 related file(s)
Read: 19 HDL files, 4,250 lines (files.yaml)

JTCORES

Both

low

49%

Statements: 35 toward hardware, 9 toward MAME

Cites hardware documentation that MAME's driver does not — 2

cores/aliens/hdl/jt051962.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
cores/aliens/hdl/jt052109.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi

Ships hardware documentation files — 33

Cites MAME source — 5

cores/aliens/hdl/jt051962.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
cores/aliens/hdl/jt052109.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
cores/riders/hdl/jtriders_obj.v:93 As the object layer should not be drawn directly over a shadow, it looks like the logic must be like this - in the LUT the shadow bits are set for the whole sprite - when drawing the sprite, if the shadow is enabled and the sprite pen is 15
cores/simson/hdl/jtsimson_main.v:373 { 2'b11, eep_rdy, eep_do, 3'b111, dip_test } // use for MAME comparisons
cores/simson/hdl/jtsimson_obj.v:99 As the object layer should not be drawn directly over a shadow, it looks like the logic must be like this - in the LUT the shadow bits are set for the whole sprite - when drawing the sprite, if the shadow is enabled and the sprite pen is 15

Shares text with the MAME driver without saying so — 4

cores/aliens/hdl/jt052109.v:90 00 A~B 6~7 8~9 Reset state — shares text with konami/k052109.cpp:84
cores/aliens/hdl/jt052109.v:91 01 8~9 4~5 6~7 — shares text with konami/k052109.cpp:85
cores/aliens/hdl/jt052109.v:92 10 6~7 2~3 4~5 — shares text with konami/k052109.cpp:86
cores/aliens/hdl/jt052109.v:93 11 4~5 0~1 2~3 — shares text with konami/k052109.cpp:87

jtpinpon#
Konami's Ping-Pong
jotego/jtcores @ b672aca5
MAME compared: konami/pingpong.cpp
Read: 8 HDL files, 1,158 lines (files.yaml)

JTCORES

Mostly hardware

low

20%

Statements: 11 toward hardware, 1 toward MAME

Cites hardware documentation that MAME's driver does not — 1

README.md:4 We have analysed the PCB and extracted full schematics from it.

Ships hardware documentation files — 10

Cites MAME source — 1

README.md:4 The discoveries found during this process have been reported to the MAME team.

jtpktgal#
Pocket Gal
jotego/jtcores @ b672aca5
MAME compared: dataeast/pcktgal.cpp + 4 related file(s)
Read: 7 HDL files, 1,075 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

No statements found

jtprmr#
Premier Soccer
jotego/jtcores @ b672aca5
MAME compared: konami/tmnt2.cpp + 13 related file(s)
Read: 20 HDL files, 4,623 lines (files.yaml)

JTCORES

Both

low

61%

Statements: 21 toward hardware, 12 toward MAME, 3 not counted

Cites hardware documentation that MAME's driver does not — 8

cores/aliens/hdl/jt051960.v:5 Based on Furrtek's RE work on die shots and MAME documentation
cores/aliens/hdl/jt051962.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
cores/aliens/hdl/jt052109.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
hdl/jtprmr_main.v:116 10'0000 ~ 10'3FFF - LS138 @ 4G
hdl/jtprmr_main.v:124 12'0000 - LS138 @ 7E
hdl/jtprmr_main.v:125 12'1000 - LS138 @ 7E
hdl/jtprmr_main.v:127 12'2000 - LS138 @ 7E
hdl/jtprmr_main.v:128 12'3000 - LS138 @ 7E

Cites hardware references or measurements that MAME's driver also gives — 3

hdl/jtprmr_main.v:115 00'0000 ~ 0F'FFFF - LS139 @ 3F — also in MAME: 0F konami/k054000.cpp:104, 3F konami/k053251.cpp:52
hdl/jtprmr_main.v:129 20'0000 ~ 2F'FFFF - LS139 @ 3F — also in MAME: 2F konami/tmnt2.cpp:3233, 3F konami/k053251.cpp:52
hdl/jtprmr_main.v:130 30'0000 ~ 3F'FFFF - LS139 @ 3F — also in MAME: 3F konami/k053251.cpp:52, 3F konami/k053251.cpp:52

Ships hardware documentation files — 13

Cites MAME source — 8

cores/aliens/hdl/jt051960.v:5 Based on Furrtek's RE work on die shots and MAME documentation
cores/aliens/hdl/jt051960.v:104 original hardware outputs ram_dout[7:1], leaving 7'd0 for compatibility with MAME traces and it also simplifies logic
cores/aliens/hdl/jt051962.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
cores/aliens/hdl/jt052109.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
cores/riders/hdl/jtriders_colmix.v:174 this does not follow the same arrangement of the original it's only important if you try to load a dump from MAME
cores/riders/hdl/jtriders_obj.v:93 As the object layer should not be drawn directly over a shadow, it looks like the logic must be like this - in the LUT the shadow bits are set for the whole sprite - when drawing the sprite, if the shadow is enabled and the sprite pen is 15
cores/rungun/hdl/jt053936.v:10 MAME only seems to implement the 16-bit interface, so it might have been the only one used on commercial games.
cores/rungun/hdl/jtrungun_sound.v:35 Per-set gain from full-volume MAME peak captures

Shares text with the MAME driver without saying so — 4

cores/aliens/hdl/jt052109.v:90 00 A~B 6~7 8~9 Reset state — shares text with konami/k052109.cpp:84
cores/aliens/hdl/jt052109.v:91 01 8~9 4~5 6~7 — shares text with konami/k052109.cpp:85
cores/aliens/hdl/jt052109.v:92 10 6~7 2~3 4~5 — shares text with konami/k052109.cpp:86
cores/aliens/hdl/jt052109.v:93 11 4~5 0~1 2~3 — shares text with konami/k052109.cpp:87

jtrastan#
Operation Wolf, Rastan Saga, Rainbow Islands, Rainbow Islands - Extra Version
jotego/jtcores @ b672aca5
MAME compared: taito/opwolf.cpp, taito/rastan.cpp, taito/rbisland.cpp + 11 related file(s)
Read: 13 HDL files, 2,227 lines (files.yaml)

JTCORES

Both

low

43%

Statements: 9 toward hardware, 5 toward MAME

Cites hardware documentation that MAME's driver does not — 1

README.md:3 We have analysed the PCB and the official schematics.

Ships hardware documentation files — 8

Cites MAME source — 4

hdl/jt060dca.v:6 The gain curve matches the measured model in doc/tc0060dca.cpp.
hdl/jtrastan_main.v:159 Light-gun offsets come from the header (gun_xoffs/gun_yoffs inputs), derived per set at MRA build time from the same ROM bytes MAME's init_opwolf reads.
hdl/jtrastan_scr.v:5 This module implements the pc080sn logic The original clock was 26.686MHz/2 = 13.343MHz Using 48MHz as basis, the ratio is 1073/3860 Measurements on Operation Wolf reported in MAME VSync - 60.0551Hz HSync - 15.6742kHz
README.md:45 The digital amplifier TC0060DCA seems to be a kind of linear-in-db amplifier whose transmission function is documented in `cores/rastan/doc/tc0060dca.cpp`.

Shares text with the MAME driver without saying so — 1

hdl/jt060dca.v:5 Taito TC0060DCA stereo programmable volume control. — shares text with taito/tc0060dca.cpp:5

jtriders#
Golfing Greats, Trigon, Sunset Riders, Teenage Mutant Ninja Turtles: Turtles in Time
jotego/jtcores @ b672aca5
MAME compared: konami/tmnt2.cpp + 13 related file(s)
Read: 27 HDL files, 5,782 lines (files.yaml)

JTCORES

Both

medium

58%

Statements: 64 toward hardware, 14 toward MAME, 4 not counted

Cites hardware documentation that MAME's driver does not — 9

cores/aliens/hdl/jt051960.v:5 Based on Furrtek's RE work on die shots and MAME documentation
cores/aliens/hdl/jt051962.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
cores/aliens/hdl/jt052109.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
hdl/jtriders_main.v:142 not following the PALs as the dumps from PLD Archive are not readable with MAME's JEDUTIL
hdl/jtriders_main.v:198 12'0000 - LS138 @ 7E
hdl/jtriders_main.v:199 12'1000 - LS138 @ 7E
hdl/jtriders_main.v:200 12'2000 - LS138 @ 7E
hdl/jtriders_main.v:201 12'3000 - LS138 @ 7E
hdl/jtriders_main.v:202 12'5000 - LS138 @ 7E

Cites hardware references or measurements that MAME's driver also gives — 4

hdl/jtriders_main.v:189 00'0000 ~ 0F'FFFF - LS139 @ 3F — also in MAME: 0F konami/k054000.cpp:104, 3F konami/k053251.cpp:52
hdl/jtriders_main.v:190 10'0000 ~ 10'3FFF - LS138 @ 4F — also in MAME: 4F konami/tmnt2.cpp:3820
hdl/jtriders_main.v:204 20'0000 ~ 2F'FFFF - LS139 @ 3F — also in MAME: 2F konami/tmnt2.cpp:3233, 3F konami/k053251.cpp:52
hdl/jtriders_main.v:205 30'0000 ~ 3F'FFFF - LS139 @ 3F — also in MAME: 3F konami/k053251.cpp:52, 3F konami/k053251.cpp:52

Ships hardware documentation files — 55

Cites MAME source — 9

cores/aliens/hdl/jt051960.v:5 Based on Furrtek's RE work on die shots and MAME documentation
cores/aliens/hdl/jt051960.v:104 original hardware outputs ram_dout[7:1], leaving 7'd0 for compatibility with MAME traces and it also simplifies logic
cores/aliens/hdl/jt051962.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
cores/aliens/hdl/jt052109.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
hdl/jtriders_colmix.v:174 this does not follow the same arrangement of the original it's only important if you try to load a dump from MAME
hdl/jtriders_main.v:142 not following the PALs as the dumps from PLD Archive are not readable with MAME's JEDUTIL
hdl/jtriders_obj.v:93 As the object layer should not be drawn directly over a shadow, it looks like the logic must be like this - in the LUT the shadow bits are set for the whole sprite - when drawing the sprite, if the shadow is enabled and the sprite pen is 15
hdl/jtriders_prot.v:122 Data read MAME does a convoluted operation that seems to rely on the upper 16 bits being zero and getting set to 1 when v0 is negative.
cores/rungun/hdl/jt053936.v:10 MAME only seems to implement the 16-bit interface, so it might have been the only one used on commercial games.

Shares text with the MAME driver without saying so — 5

cores/aliens/hdl/jt052109.v:90 00 A~B 6~7 8~9 Reset state — shares text with konami/k052109.cpp:84
cores/aliens/hdl/jt052109.v:91 01 8~9 4~5 6~7 — shares text with konami/k052109.cpp:85
cores/aliens/hdl/jt052109.v:92 10 6~7 2~3 4~5 — shares text with konami/k052109.cpp:86
cores/aliens/hdl/jt052109.v:93 11 4~5 0~1 2~3 — shares text with konami/k052109.cpp:87
hdl/jtriders_tmnt2.v:176 flip y, flip x and sprite size; mirror y, mirror x, shadow — shares text with konami/tmnt2.cpp:1480

jtroadf#
Hyper Sports, Road Fighter
jotego/jtcores @ b672aca5
MAME compared: konami/hyperspt.cpp + 7 related file(s)
Read: 12 HDL files, 2,193 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

18%

Statements: 2 toward hardware, 2 toward MAME

Cites hardware documentation that MAME's driver does not — 2

hdl/jtroadf_main.v:158 74LS259 @ F2
README.md:4 We have analysed the PCB and extracted full schematics from it.

Cites MAME source — 2

hdl/jtroadf_scroll.v:75 is_hyper & attr[5]; // MAME uses this, but I don't see it in the schematics
README.md:4 The discoveries found during this process have been reported to the MAME team.

jtroc#
Roc'n Rope
jotego/jtcores @ b672aca5
MAME compared: konami/rocnrope.cpp + 3 related file(s)
Read: 10 HDL files, 1,679 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

12%

Statements: 2 toward hardware, 1 toward MAME

Cites hardware documentation that MAME's driver does not — 2

hdl/jtroc_main.v:140 74LS259
README.md:4 We have analysed the PCB and extracted full schematics from it.

Cites MAME source — 1

README.md:4 The discoveries found during this process have been reported to the MAME team.

jtrumble#
Rush & Crash
jotego/jtcores @ b672aca5
MAME compared: capcom/srumbler.cpp
Read: 19 HDL files, 3,907 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

29%

Statements: 3 toward hardware, 1 toward MAME

Cites hardware documentation that MAME's driver does not — 1

cores/gng/hdl/jtgng_objdma.v:33 Ghosts'n Goblins copies only 'h180 objects as per schematics 1943 copy more, but it is not clear what the limit is.

Ships hardware documentation files — 2

Cites MAME source — 1

cores/gng/hdl/jtgng_sound.v:9 watch points for MAME: wpset e000,1,w,1,{printf "reg = %X", wpdata;g} wpset e001,1,w,1,{printf "val = %X", wpdata;g}

jtrungun#
Slam Dunk
jotego/jtcores @ b672aca5
MAME compared: konami/rungun.cpp + 5 related file(s)
Read: 18 HDL files, 3,283 lines (files.yaml)

JTCORES

Mostly hardware

low

50%

Statements: 6 toward hardware, 3 toward MAME

Cites hardware documentation that MAME's driver does not — 2

hdl/jtrungun_main.v:151 same as RAM in PAL equations 74F138 at 11T
hdl/jtrungun_main.v:159 74F138 at 13P

Ships hardware documentation files — 4

Cites MAME source — 3

hdl/jt053936.v:10 MAME only seems to implement the 16-bit interface, so it might have been the only one used on commercial games.
hdl/jtrungun_sound.v:35 Per-set gain from full-volume MAME peak captures
cores/simson/hdl/jtsimson_obj.v:99 As the object layer should not be drawn directly over a shadow, it looks like the logic must be like this - in the LUT the shadow bits are set for the whole sprite - when drawing the sprite, if the shadow is enabled and the sprite pen is 15

jts16#
Ace Attacker, Action Fighter, Alex Kidd: The Lost Stars, Alien Syndrome …
jotego/jtcores @ b672aca5
MAME compared: sega/segas16a.cpp + 11 related file(s)
Read: 24 HDL files, 4,559 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

14%

Statements: 1 toward hardware, 1 toward MAME, 1 not counted

Cites hardware references or measurements that MAME's driver also gives — 1

hdl/jts16_main.v:431 This is done by IC69 (a 82S153 programmable logic chip) — also in MAME: 82S153 sega/segas16a.cpp:76

Reports a measurement taken on the original PCB — 1

hdl/jts16_tilemap.v:135 Measured on PCB vint lasts 64us, starts one line before blanking vsync occurs 16 lines later

Cites MAME source — 1

hdl/jts16_fd1094_dec.v:146 decoding, pretty much copy-paste from MAME's fd1094.cpp I trust the synthesizer to simplify the equations

jts16b#
Action Fighter, Alien Syndrome, Juuouki, Aurail …
jotego/jtcores @ b672aca5
MAME compared: sega/segas16b.cpp + 18 related file(s)
Read: 31 HDL files, 6,642 lines (files.yaml)

JTCORES

Mostly hardware

low

44%

Statements: 4 toward hardware, 6 toward MAME

Cites hardware documentation that MAME's driver does not — 2

cores/s16/hdl/jts16_main.v:431 This is done by IC69 (a 82S153 programmable logic chip)
hdl/jts16b_mapper.v:232 see schematics page 10

Reports a measurement taken on the original PCB — 1

cores/s16/hdl/jts16_tilemap.v:135 Measured on PCB vint lasts 64us, starts one line before blanking vsync occurs 16 lines later

Ships hardware documentation files — 1

cores/s16b/doc/315-5195_schematics.pdf

Cites MAME source — 4

cores/s16/hdl/jts16_fd1094_dec.v:146 decoding, pretty much copy-paste from MAME's fd1094.cpp I trust the synthesizer to simplify the equations
hdl/jts16b_timer.v:19 seems unconnected in MAME
hdl/jts16b_timer.v:20 seems unconnected in MAME
hdl/jts16b_timer.v:27 MAME keeps it hidden

Says it was translated, ported or taken from MAME — 2

hdl/jts16b_mul.v:5 SEGA 315-5248 model based on MAME driver
hdl/jts16b_timer.v:5 SEGA 315-5250 model, based on MAME driver

jts18#
Alien Storm, Bloxeed, Clutch Hitter, D. D. Crew …
jotego/jtcores @ b672aca5
MAME compared: sega/segas18.cpp + 17 related file(s)
Read: 29 HDL files, 13,517 lines (files.yaml)

JTCORES

Mostly hardware

low

71%

Statements: 38 toward hardware, 2 toward MAME

Cites hardware documentation that MAME's driver does not — 6

cores/s16b/hdl/jts16b_mapper.v:232 see schematics page 10
hdl/jts18_io.v:5 315-5296 IO controller Based on MAME's implementation and PCB schematics
hdl/ym7101.v:16 YM7101 emulator Thanks: Fritzchens Fritz: YM7101 decap and die shot.
hdl/ym7101.v:22 org (ogamespec): early YM7101 decap and die shot.
README.md:10 The source tree contains both the RTL implementation and the reverse-engineered schematics produced during the hardware study.
README.md:58 Relevant devices and blocks documented in the schematic set include:

Reports a measurement taken on the original PCB — 1

cores/s16/hdl/jts16_tilemap.v:135 Measured on PCB vint lasts 64us, starts one line before blanking vsync occurs 16 lines later

Ships hardware documentation files — 31

Cites MAME source — 1

cores/s16/hdl/jts16_fd1094_dec.v:146 decoding, pretty much copy-paste from MAME's fd1094.cpp I trust the synthesizer to simplify the equations

Says it was translated, ported or taken from MAME — 1

hdl/jts18_io.v:5 315-5296 IO controller Based on MAME's implementation and PCB schematics

jtsarms#
Hyper Dyne Side Arms
jotego/jtcores @ b672aca5
MAME compared: capcom/sidearms.cpp
Read: 19 HDL files, 3,490 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

30%

Statements: 3 toward hardware, 2 toward MAME

Cites hardware documentation that MAME's driver does not — 1

cores/gng/hdl/jtgng_objdma.v:33 Ghosts'n Goblins copies only 'h180 objects as per schematics 1943 copy more, but it is not clear what the limit is.

Ships hardware documentation files — 2

Cites MAME source — 2

cores/gng/hdl/jtgng_sound.v:9 watch points for MAME: wpset e000,1,w,1,{printf "reg = %X", wpdata;g} wpset e001,1,w,1,{printf "val = %X", wpdata;g}
README.md:22 For Side Arms there are some additional differences with MAME:

jtsbaskt#
Super Basketball
jotego/jtcores @ b672aca5
MAME compared: konami/sbasketb.cpp + 5 related file(s)
Read: 11 HDL files, 1,951 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

11%

Statements: 2 toward hardware, 1 toward MAME

Cites hardware documentation that MAME's driver does not — 2

hdl/jtsbaskt_main.v:141 74LS259
README.md:4 We have analysed the PCB and extracted full schematics from it.

Cites MAME source — 1

README.md:4 The discoveries found during this process have been reported to the MAME team.

jtsectnz#
Ares no Tsubasa, Section Z
jotego/jtcores @ b672aca5
MAME compared: capcom/lwings.cpp
Read: 19 HDL files, 3,842 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

34%

Statements: 5 toward hardware, 4 toward MAME, 1 not counted

Cites hardware documentation that MAME's driver does not — 5

cores/commnd/hdl/jtcommnd_main.v:68 PROM 6L (interrupts)
cores/gng/hdl/jtgng_objdma.v:33 Ghosts'n Goblins copies only 'h180 objects as per schematics 1943 copy more, but it is not clear what the limit is.
hdl/jtsectnz_colmix.v:91 There are writes outside the vertical blank If I gate the signals for VB only then the sea turns yellow in Legendary Wings after playing a game There could be an error bit like wrerr_n in Side Arms but it is not documented in MAME and I don
hdl/jtsectnz_game.v:93 PROM 6L (interrupts)
README.md:8 This work has been done based on other CAPCOM boards and schematics and on MAME sources.

Cites hardware references or measurements that MAME's driver also gives — 1

cores/commnd/hdl/jtcommnd_main.v:430 Schematic 7L - sound interrupter — also in MAME: 7L capcom/lwings.cpp:1628

Cites MAME source — 4

cores/gng/hdl/jtgng_sound.v:9 watch points for MAME: wpset e000,1,w,1,{printf "reg = %X", wpdata;g} wpset e001,1,w,1,{printf "val = %X", wpdata;g}
hdl/jtsectnz_colmix.v:91 There are writes outside the vertical blank If I gate the signals for VB only then the sea turns yellow in Legendary Wings after playing a game There could be an error bit like wrerr_n in Side Arms but it is not documented in MAME and I don
README.md:8 This work has been done based on other CAPCOM boards and schematics and on MAME sources.
README.md:14 -According to MAME the frame rate should be 55.37Hz, I find that not possible to done in a reasonable way in hardware.

jtsf#
Street Fighter
jotego/jtcores @ b672aca5
MAME compared: capcom/sf.cpp
Read: 22 HDL files, 4,226 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

36%

Statements: 2 toward hardware, 4 toward MAME

Cites hardware documentation that MAME's driver does not — 1

cores/gng/hdl/jtgng_objdma.v:33 Ghosts'n Goblins copies only 'h180 objects as per schematics 1943 copy more, but it is not clear what the limit is.

Ships hardware documentation files — 1

cores/sf/sch/sf.kicad_sch

Cites MAME source — 4

hdl/jtsf_main.v:279 IN0 in MAME
hdl/jtsf_main.v:289 IN1 in MAME
hdl/jtsf_main.v:312 IN2 in MAME
hdl/jtsf_mcu.v:47 Clock enable for 8MHz, like MAME.

jtshanon#
Super Hang-On
jotego/jtcores @ b672aca5
MAME compared: sega/segaorun.cpp + 15 related file(s)
Read: 25 HDL files, 5,591 lines (files.yaml)

JTCORES

Both

low

49%

Statements: 6 toward hardware, 5 toward MAME

Cites hardware documentation that MAME's driver does not — 4

cores/outrun/hdl/jtoutrun_main.v:28 SG bus on page 6/7
cores/outrun/hdl/jtoutrun_video.v:149 first 8kB of pal RAM dumped
cores/s16b/hdl/jts16b_mapper.v:232 see schematics page 10
hdl/jtshanon_colmix.v:5 Video board, schematic sheet 5 of 7

Reports a measurement taken on the original PCB — 1

cores/s16/hdl/jts16_tilemap.v:135 Measured on PCB vint lasts 64us, starts one line before blanking vsync occurs 16 lines later

Notes where it differs from MAME — 1

cores/outrun/hdl/jtoutrun_snd.v:86 The schematics have it, MAME doesn't

Cites MAME source — 2

cores/outrun/hdl/jtoutrun_motor.v:5 dummy motor, follows MAME's implementation
cores/s16/hdl/jts16_fd1094_dec.v:146 decoding, pretty much copy-paste from MAME's fd1094.cpp I trust the synthesizer to simplify the equations

Shares text with the MAME driver without saying so — 3

cores/outrun/hdl/jtoutrun_pcm.v:6 Clock input 16.000MHz on pin 80 — shares text with sega/segaorun.cpp:100
cores/outrun/hdl/jtoutrun_pcm.v:7 Clock outputs: pin 2 - 4.000MHz, pin 80 - 500.000kHz, pin 89 - 62.500KHz — shares text with sega/segaorun.cpp:101
hdl/jtshanon_colmix.v:88 The shadow doesn't seem to be used in the trees and other road objects — shares text with sega/segaic16.cpp:287

jtshouse#
Bakutotsu Kijuutei, Chou Zetsurinjin Berabowman, Blast Off, Blazer …
jotego/jtcores @ b672aca5
MAME compared: namco/namcos1.cpp + 11 related file(s)
Read: 15 HDL files, 3,012 lines (files.yaml)

JTCORES

Both

medium

56%

Statements: 8 toward hardware, 17 toward MAME

Cites hardware documentation that MAME's driver does not — 3

hdl/jtc117.v:5 Implementation of Namco's CUS117 - Memory Mapper for two CPUs Based on MAME's c117 information and Atari's schematics
hdl/jtcus30.sv:5 Implementation of Namco's CUS30 - 8-channel stereo DAC Based on MAME's namco_snd.cpp information and Atari's schematics
hdl/jtshouse_scr.sv:5 Implementation of C123 tilemaps based on MAME's namo_c123tmap.cpp and Atari's schematics 6 layers = 4 scroll + 2 fix 8x8 pixels, 8 bpp

Ships hardware documentation files — 5

Cites MAME source — 13

hdl/jtc117.v:62 to MAME
hdl/jtc117.v:63 to MAME
hdl/jtc117.v:64 to MAME
hdl/jtc117.v:65 to MAME
hdl/jtc117.v:66 to MAME
hdl/jtc117.v:67 to MAME
hdl/jtc117.v:68 to MAME
hdl/jtc117.v:69 to MAME
hdl/jtc117.v:70 MAME uses 32kB
hdl/jtcus30.sv:8 The frequency number is the step added to the channel counter each waveform is 32-byte long MAME reports 12kHz as sampling frequency 15 kHz * 8 = 120 kHz 1536 kHz / 120 kHz = 12
hdl/jtshouse_key.v:5 The implementation of the KEY chips follows MAME's namcos1_m.cpp These chips won't impact any timing accuracy
hdl/jtshouse_key.v:26 The random number generator follows MAME's implementation for the sake of comparing debug traces
hdl/jtshouse_vtimer.v:27 60.6 Hz according to MAME

Says it was translated, ported or taken from MAME — 3

hdl/jtc117.v:5 Implementation of Namco's CUS117 - Memory Mapper for two CPUs Based on MAME's c117 information and Atari's schematics
hdl/jtcus30.sv:5 Implementation of Namco's CUS30 - 8-channel stereo DAC Based on MAME's namco_snd.cpp information and Atari's schematics
hdl/jtshouse_scr.sv:5 Implementation of C123 tilemaps based on MAME's namo_c123tmap.cpp and Atari's schematics 6 layers = 4 scroll + 2 fix 8x8 pixels, 8 bpp

Keeps a MAME approximation — 1

hdl/jtshouse_mcu.v:111 the init_done mechanism mimics MAME's hack to prevent a lock up during the boot sequence see https://github.com/jotego/jtcores/issues/410

jtsimson#
Escape Kids, The Simpsons, Crime Fighters 2
jotego/jtcores @ b672aca5
MAME compared: konami/simpsons.cpp, konami/vendetta.cpp + 11 related file(s)
Read: 16 HDL files, 3,551 lines (files.yaml)

JTCORES

Both

low

50%

Statements: 27 toward hardware, 9 toward MAME

Cites hardware documentation that MAME's driver does not — 4

cores/aliens/hdl/jt051962.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
cores/aliens/hdl/jt052109.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
README.md:40 **053994** at 11C:
README.md:67 **053995** at 11D:

Ships hardware documentation files — 23

Cites MAME source — 5

cores/aliens/hdl/jt051962.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
cores/aliens/hdl/jt052109.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
hdl/jtsimson_main.v:373 { 2'b11, eep_rdy, eep_do, 3'b111, dip_test } // use for MAME comparisons
hdl/jtsimson_obj.v:99 As the object layer should not be drawn directly over a shadow, it looks like the logic must be like this - in the LUT the shadow bits are set for the whole sprite - when drawing the sprite, if the shadow is enabled and the sprite pen is 15
README.md:87 Based on 051960 (previous generation of sprite hardware) and MAME documentation

Shares text with the MAME driver without saying so — 4

cores/aliens/hdl/jt052109.v:90 00 A~B 6~7 8~9 Reset state — shares text with konami/k052109.cpp:84
cores/aliens/hdl/jt052109.v:91 01 8~9 4~5 6~7 — shares text with konami/k052109.cpp:85
cores/aliens/hdl/jt052109.v:92 10 6~7 2~3 4~5 — shares text with konami/k052109.cpp:86
cores/aliens/hdl/jt052109.v:93 11 4~5 0~1 2~3 — shares text with konami/k052109.cpp:87

jtskykid#
Dragon Buster, Sky Kid
jotego/jtcores @ b672aca5
MAME compared: namco/skykid.cpp
Read: 13 HDL files, 1,449 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

17%

Statements: 1 toward hardware, 3 toward MAME

Cites hardware documentation that MAME's driver does not — 1

cores/shouse/hdl/jtcus30.sv:5 Implementation of Namco's CUS30 - 8-channel stereo DAC Based on MAME's namco_snd.cpp information and Atari's schematics

Cites MAME source — 2

cores/shouse/hdl/jtcus30.sv:8 The frequency number is the step added to the channel counter each waveform is 32-byte long MAME reports 12kHz as sampling frequency 15 kHz * 8 = 120 kHz 1536 kHz / 120 kHz = 12
cores/shouse/hdl/jtshouse_vtimer.v:27 60.6 Hz according to MAME

Says it was translated, ported or taken from MAME — 1

cores/shouse/hdl/jtcus30.sv:5 Implementation of Namco's CUS30 - 8-channel stereo DAC Based on MAME's namco_snd.cpp information and Atari's schematics

jtslyspy#
Boulder Dash / Boulder Dash Part 2, Secret Agent
jotego/jtcores @ b672aca5
MAME compared: dataeast/dec0.cpp + 7 related file(s)
Read: 12 HDL files, 3,193 lines (files.yaml)

JTCORES

Mostly hardware

low

35%

Statements: 11 toward hardware, 1 toward MAME

Cites hardware documentation that MAME's driver does not — 1

cores/cop/hdl/jtcop_bac06.v:27 The /NUDS and /NLDS inputs of all chips are gated via a 74LS32 chip by the /DSP chip select signal.

Ships hardware documentation files — 10

Cites MAME source — 1

hdl/jtslyspy_colmix.v:5 The layer priority is solved as in MAME I hope to get access to a Midnight Resistance board at some point and derive the original circuit

jttaitox#
Balloon Brothers, Daisenpu, Gigandes, Last Striker / Kyuukyoku no Striker …
jotego/jtcores @ b672aca5
MAME compared: taito/taito_x.cpp + 3 related file(s)
Read: 14 HDL files, 2,393 lines (files.yaml)

JTCORES

Mostly MAME

low

35%

Statements: 3 toward hardware, 12 toward MAME

Cites hardware documentation that MAME's driver does not — 3

cores/kiwi/hdl/jtkiwi_gfx.v:9 SETAX1-001, the die shot available shows what it seems to be an internal dual-line buffer and another larger memory
README.md:28 A single 16 MHz oscillator feeds everything — confirmed on both the Superman schematic (drawing W5100307A, sheet 3) and the board photo in `doc/`.
README.md:87 The H and V totals are **not** derivable from the schematic: the dividers are inside the X1-001 die and the board carries no counter chain.

Cites MAME source — 9

cores/kiwi/hdl/jtkiwi_gfx.v:18 12 = 8kB sprite RAM, page selects the 0x800 half (tnzs/calibr50) 13 = 16kB, page selects the 0x1000 buffer (metafox/arbalest, MAME seta001 setac)
cores/kiwi/hdl/jtkiwi_gfx.v:125 16kB sprite RAM: cfg[1] carries the buffer bank (MAME seta001 setac_eof)
cores/kiwi/hdl/jtkiwi_gfx.v:290 Changed to 16-bit access to ease the drawing logic the upper byte refers to the upper half of the memory for the CPU In MAME the lower half is called spritecodelow and the upper spritecodehigh
cores/kiwi/hdl/jtkiwi_obj.v:12 12 = 8kB sprite RAM, page selects the 0x800 half (tnzs/calibr50) 13 = 16kB, page selects the 0x1000 buffer (metafox/arbalest, MAME seta001 setac)
cores/kiwi/hdl/jtkiwi_tilemap.v:107 This is probably some config setting unexplored by MAME
hdl/jttaitox_hawk_snd.v:25 The mailbox is the same silicon on both - MAME's pc060ha_device derives from tc0140syt_device - so this uses jtrastan_pc060 too.
README.md:48 MAME's single gfxdecode entry is "sprites & playfield", and the playfield is the X1-001's background *column* mode.
README.md:88 The only measured figures in the MAME driver (58 Hz / 15.22 kHz, line 217) belong to a P0-057A board, not to Superman, whose value has no measurement behind it.
README.md:109 `doc/` holds primary sources only — the MAME driver and device sources (`taito_x.cpp`, `seta001.cpp`, `taitosnd.cpp`, `taitocchip.cpp`) and photos of the P0-039

Says it matches, follows or was checked against MAME — 2

README.md:68 68000 boot verified against MAME: the FPGA fetch stream contains every one of MAME's 1464 distinct PCs on Superman, with no divergence.
README.md:72 Superman's title screen is byte-identical to a MAME screenshot — 0 of 92160 pixels differ.

Keeps a MAME approximation — 1

README.md:83 MAME's `set_size(52*8, 32*8)` is the usual Seta approximation — at MAME's own refresh it implies a 6.117 MHz dot clock and a 14.7 kHz line rate, which no JAMMA

jtthundr#
Alien Sector, Genpei ToumaDen, Hopping Mappy, Metro-Cross …
jotego/jtcores @ b672aca5
MAME compared: namco/baraduke.cpp, namco/namcos86.cpp + 6 related file(s)
Read: 25 HDL files, 2,979 lines (files.yaml)

JTCORES

Both

low

19%

Statements: 3 toward hardware, 3 toward MAME

Cites hardware documentation that MAME's driver does not — 2

cores/shouse/hdl/jtcus30.sv:5 Implementation of Namco's CUS30 - 8-channel stereo DAC Based on MAME's namco_snd.cpp information and Atari's schematics
hdl/jtthundr_cab.v:9 names from schematic

Says it was checked against the original PCB — 1

hdl/jtthundr_main.v:218 verified on PCB

Cites MAME source — 2

cores/shouse/hdl/jtcus30.sv:8 The frequency number is the step added to the channel counter each waveform is 32-byte long MAME reports 12kHz as sampling frequency 15 kHz * 8 = 120 kHz 1536 kHz / 120 kHz = 12
cores/shouse/hdl/jtshouse_vtimer.v:27 60.6 Hz according to MAME

Says it was translated, ported or taken from MAME — 1

cores/shouse/hdl/jtcus30.sv:5 Implementation of Namco's CUS30 - 8-channel stereo DAC Based on MAME's namco_snd.cpp information and Atari's schematics

jttmnt#
M.I.A.: Missing in Action, Punk Shot, Thunder Cross II, Teenage Mutant Ninja Turtles
jotego/jtcores @ b672aca5
MAME compared: konami/tmnt.cpp, konami/tmnt2.cpp + 13 related file(s)
Read: 13 HDL files, 3,390 lines (files.yaml)

JTCORES

Both

low

59%

Statements: 9 toward hardware, 10 toward MAME

Cites hardware documentation that MAME's driver does not — 4

cores/aliens/hdl/jt051960.v:5 Based on Furrtek's RE work on die shots and MAME documentation
cores/aliens/hdl/jt051962.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
cores/aliens/hdl/jt052109.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
README.md:20 This core is based on the official schematics for this system and the [reverse engineering work done by Furrtek](https://github.com/furrtek/SiliconRE/tree/maste

Ships hardware documentation files — 5

Cites MAME source — 6

cores/aliens/hdl/jt051960.v:5 Based on Furrtek's RE work on die shots and MAME documentation
cores/aliens/hdl/jt051960.v:104 original hardware outputs ram_dout[7:1], leaving 7'd0 for compatibility with MAME traces and it also simplifies logic
cores/aliens/hdl/jt051962.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
cores/aliens/hdl/jt052109.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
hdl/jttmnt_colmix.v:175 this does not follow the same arrangement of the original it's only important if you try to load a dump from MAME
hdl/jttmnt_main.v:302 active high (MAME EEPROMOUT bit is IP_ACTIVE_HIGH)

Shares text with the MAME driver without saying so — 4

cores/aliens/hdl/jt052109.v:90 00 A~B 6~7 8~9 Reset state — shares text with konami/k052109.cpp:84
cores/aliens/hdl/jt052109.v:91 01 8~9 4~5 6~7 — shares text with konami/k052109.cpp:85
cores/aliens/hdl/jt052109.v:92 10 6~7 2~3 4~5 — shares text with konami/k052109.cpp:86
cores/aliens/hdl/jt052109.v:93 11 4~5 0~1 2~3 — shares text with konami/k052109.cpp:87

jttoki#
Cabal, JuJu Densetsu
jotego/jtcores @ b672aca5
MAME compared: seibu/cabal.cpp, seibu/toki.cpp + 2 related file(s)
Read: 11 HDL files, 2,099 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

Statements: 1 toward MAME

Cites MAME source — 1

README.md:7 This core is based mainly on [MAME sources](https://github.com/mamedev/mame), some PCB measurements and ROM reverse-engineering.

jttora#
F-1 Dream, Tora e no Michi
jotego/jtcores @ b672aca5
MAME compared: capcom/tigeroad.cpp + 5 related file(s)
Read: 23 HDL files, 4,248 lines (files.yaml)

JTCORES

Both

low

39%

Statements: 3 toward hardware, 3 toward MAME

Cites hardware documentation that MAME's driver does not — 1

cores/gng/hdl/jtgng_objdma.v:33 Ghosts'n Goblins copies only 'h180 objects as per schematics 1943 copy more, but it is not clear what the limit is.

Reports a measurement taken on the original PCB — 2

cores/biocom/hdl/jtbiocom_main.v:397 Matches measurement of F1-Dream PCB, although the Bionic Commando schematics point to V256, that must be a typo or an old version using V256 prevents the game from registering coin inputs
hdl/jttora_video.v:170 Object DMA transfer takes ~164us as per bootleg PCB measurement pin A1 toggles as 250ns low, 250ns high So address bus is toggling with a 4MHz clock and at 250ns per address, it can sweep 640 locations in 160us.

Cites MAME source — 3

cores/biocom/hdl/jtbiocom_mcu.v:86 Current MAME models the MCU-to-sound transfer on the 1-to-0 transition of P3.6.
cores/gng/hdl/jtgng_sound.v:9 watch points for MAME: wpset e000,1,w,1,{printf "reg = %X", wpdata;g} wpset e001,1,w,1,{printf "val = %X", wpdata;g}
hdl/jttora_game.v:46 A and B are inverted in this game (or in MAME definition)

jttrack#
Track & Field
jotego/jtcores @ b672aca5
MAME compared: konami/trackfld.cpp + 7 related file(s)
Read: 13 HDL files, 2,219 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

10%

Statements: 2 toward hardware, 1 toward MAME

Cites hardware documentation that MAME's driver does not — 2

hdl/jttrack_main.v:143 74LS259 @ F2
README.md:4 We have analysed the PCB and extracted full schematics from it.

Cites MAME source — 1

README.md:4 The discoveries found during this process have been reported to the MAME team.

jttrojan#
Hissatsu Buraiken, Tatakai no Banka
jotego/jtcores @ b672aca5
MAME compared: capcom/lwings.cpp
Read: 23 HDL files, 4,593 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

36%

Statements: 5 toward hardware, 1 toward MAME, 1 not counted

Cites hardware documentation that MAME's driver does not — 5

cores/commnd/hdl/jtcommnd_main.v:68 PROM 6L (interrupts)
cores/gng/hdl/jtgng_objdma.v:33 Ghosts'n Goblins copies only 'h180 objects as per schematics 1943 copy more, but it is not clear what the limit is.
hdl/jttrojan_game.v:97 PROM 6L (interrupts)
hdl/jttrojan_main.v:64 PROM 6L (interrupts)
hdl/jttrojan_mcu.v:5 Following Trojan schematics, although it is not used in Trojan but Avengers

Cites hardware references or measurements that MAME's driver also gives — 1

cores/commnd/hdl/jtcommnd_main.v:430 Schematic 7L - sound interrupter — also in MAME: 7L capcom/lwings.cpp:1628

Cites MAME source — 1

cores/gng/hdl/jtgng_sound.v:9 watch points for MAME: wpset e000,1,w,1,{printf "reg = %X", wpdata;g} wpset e001,1,w,1,{printf "val = %X", wpdata;g}

jttwin16#
Cue Brick, Majuu no Ohkoku, Gradius II - GOFER no Yabou
jotego/jtcores @ b672aca5
MAME compared: konami/twin16.cpp + 3 related file(s)
Read: 18 HDL files, 2,941 lines (files.yaml)

JTCORES

Mostly hardware

low

33%

Statements: 84 toward hardware, 2 toward MAME

Cites hardware documentation that MAME's driver does not — 3

cores/fround/hdl/jt00778x.v:5 Based on Skutis' RE work on die shots and MAME documentation
cores/fround/hdl/jt00778x.v:80 original equation from schematics, it is the same as the start of vblank
README.md:20 This core is based on the official schematics for this system and the incredible reverse engineering work done by Skutis on them.

Ships hardware documentation files — 81

Cites MAME source — 2

cores/fround/hdl/jt00778x.v:5 Based on Skutis' RE work on die shots and MAME documentation
hdl/jttwin16_video.v:138 60.6 Hz according to MAME

jtvigil#
Vigilante
jotego/jtcores @ b672aca5
MAME compared: irem/vigilant.cpp + 3 related file(s)
Read: 9 HDL files, 1,290 lines (files.yaml)

JTCORES

Mostly hardware

low

39%

Statements: 5 toward hardware

Cites hardware documentation that MAME's driver does not — 3

hdl/jtvigil_colmix.v:5 The priority is controlled by a PAL, which was dumped and converted here http://wiki.pldarchive.co.uk/index.php?title=Vigilante_(M75)
README.md:3 We have analysed the PCB and the official schematics.
README.md:24 Measured on PCB and verified on the schematics, which are a bit hard to read but putting everything together, it makes sense.

Reports a measurement taken on the original PCB — 1

hdl/jtvigil_video.v:66 Measured on the original PCB Pixel clock is 6.144MHz H: 256 active pixels, 128 blank pixels HSync lasts for 32 pixels, from pixel 40 to 72.

Ships hardware documentation files — 1

cores/vigil/doc/pal/Vigilante-VG_B-4M.jed

jtvlfied#
Volfied
jotego/jtcores @ b672aca5
MAME compared: taito/volfied.cpp + 5 related file(s)
Read: 9 HDL files, 1,456 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

33%

Statements: 7 toward MAME

Cites MAME source — 5

hdl/jtvlfied_cchip.v:23 MCU port assignment (volfied.cpp machine_config): PA: bit5=START2 bit6=START1 bit7=SERVICE1 PB: bit0=COIN1 bit1=COIN2 PC: bit0=TILT bit2..5=U/D/L/R bit6=BUTTON1 AD: bit1=UP bit2=DOWN bit4=RIGHT bit5=BUTTON1 bit7=LEFT, all cocktail P2 Id
hdl/jtvlfied_cchip.v:45 Active LOW (idle = 1), matching JTFRAME/MAME convention.
hdl/jtvlfied_cchip.v:86 volfied.cpp: ext_interrupt on VBL
hdl/jtvlfied_fb.v:23 Pixel decode follows volfied.cpp refresh_pixel_layer.
hdl/jtvlfied_fb.v:166 The bitmap is read 11 pixels ahead of the raster: MAME reads videoram[y*512 + x+1], and the rest is the fixed skew of the VRAM serial port against the sprite path, which does not go through it.

Shares text with the MAME driver without saying so — 2

hdl/jtvlfied_fb.v:19 Player-drawn bitmap framebuffer, 512 KB in its own SDRAM bank: 2 pages x 256 rows x 512 columns x 16 bits. Page select is video_ctrl[0]; the word addres — shares text with taito/volfied.cpp:142
hdl/jtvlfied_main.v:140 PC090OJ colbank = 0x100 | ((sprite_ctrl & 0x3c)<<2), and its pen is — shares text with taito/volfied.cpp:233

jtwardnr#
Wardner no Mori
jotego/jtcores @ b672aca5
MAME compared: toaplan/wardner.cpp + 7 related file(s)
Read: 8 HDL files, 1,260 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

Statements: 1 toward MAME

Cites MAME source — 1

README.md:10 `doc/` holds the MAME 0.289 sources the core follows.

jtwc#
All American Football, Tehkan World Cup
jotego/jtcores @ b672aca5
MAME compared: tecmo/tehkanwc.cpp
Read: 10 HDL files, 1,519 lines (files.yaml)

JTCORES

Mostly hardware

low

27%

Statements: 27 toward hardware

Cites hardware documentation that MAME's driver does not — 1

hdl/jtwc_shared.v:59 following mostly the names in the schematics

Ships hardware documentation files — 26

jtwwfss#
WWF Superstars
jotego/jtcores @ b672aca5
MAME compared: technos/wwfsstar.cpp
Read: 6 HDL files, 1,023 lines (files.yaml)

JTCORES

Mostly hardware

low

57%

Statements: 22 toward hardware, 1 toward MAME

Cites hardware documentation that MAME's driver does not — 1

cores/dd/hdl/jtdd_obj.v:5 Schematics 3-7/10 OBJ Object layer Max 32 sprites per line

Ships hardware documentation files — 21

Cites MAME source — 1

hdl/jtwwfss_main.v:121 MAME assigns flip to bit 0 but it is dangling on the PCB

jtxmen#
X-Men
jotego/jtcores @ b672aca5
MAME compared: konami/xmen.cpp + 9 related file(s)
Read: 18 HDL files, 3,980 lines (files.yaml)

JTCORES

Both

low

54%

Statements: 29 toward hardware, 11 toward MAME

Cites hardware documentation that MAME's driver does not — 4

cores/aliens/hdl/jt051960.v:5 Based on Furrtek's RE work on die shots and MAME documentation
cores/aliens/hdl/jt051962.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
cores/aliens/hdl/jt052109.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
hdl/jtxmen_main.v:104 not following the PALs as the dumps from PLD Archive are not readable with MAME's JEDUTIL

Ships hardware documentation files — 25

Cites MAME source — 7

cores/aliens/hdl/jt051960.v:5 Based on Furrtek's RE work on die shots and MAME documentation
cores/aliens/hdl/jt051960.v:104 original hardware outputs ram_dout[7:1], leaving 7'd0 for compatibility with MAME traces and it also simplifies logic
cores/aliens/hdl/jt051962.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
cores/aliens/hdl/jt052109.v:5 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
cores/simson/hdl/jtsimson_obj.v:99 As the object layer should not be drawn directly over a shadow, it looks like the logic must be like this - in the LUT the shadow bits are set for the whole sprite - when drawing the sprite, if the shadow is enabled and the sprite pen is 15
hdl/jtxmen_colmix.v:123 this does not follow the same arrangement of the original it's only important if you try to load a dump from MAME
hdl/jtxmen_main.v:104 not following the PALs as the dumps from PLD Archive are not readable with MAME's JEDUTIL

Shares text with the MAME driver without saying so — 4

cores/aliens/hdl/jt052109.v:90 00 A~B 6~7 8~9 Reset state — shares text with konami/k052109.cpp:84
cores/aliens/hdl/jt052109.v:91 01 8~9 4~5 6~7 — shares text with konami/k052109.cpp:85
cores/aliens/hdl/jt052109.v:92 10 6~7 2~3 4~5 — shares text with konami/k052109.cpp:86
cores/aliens/hdl/jt052109.v:93 11 4~5 0~1 2~3 — shares text with konami/k052109.cpp:87

jtyiear#
Yie Ar Kung-Fu
jotego/jtcores @ b672aca5
MAME compared: konami/yiear.cpp + 3 related file(s)
Read: 8 HDL files, 1,387 lines (files.yaml)

JTCORES

Not enough evidence in the code

insufficient

Statements: 1 toward hardware, 1 toward MAME

Cites hardware documentation that MAME's driver does not — 1

README.md:4 We have analysed the PCB and extracted full schematics from it.

Cites MAME source — 1

README.md:4 The discoveries found during this process have been reported to the MAME team.

Alpha68k#
Battle Field, Gang Wars, Super Champion Baseball, Sky Adventure …
database (builds only)

Coin-Op Collection
default

Source not published

armedf#
Armed F, Tatakae! Big Fighter, Crazy Climber 2, Kozure Ookami …
database (builds only)

Coin-Op Collection
default

Source not published

batrider#
Armed Police Batrider
database (builds only)

Coin-Op Collection
default

Source not published

Published by the team — 2 item(s), not evidence of how this core was verified

Chosen and published by the developers. It shows what they decided to share, not how this core was built or checked. Anything pointing to MAME would not be visible here, so this list is one-sided by design; it places no needle and is not counted anywhere.

Platform write-up Toaplan2/Raizing/RA9704/README.md (names “armed police batrider”) — 25 schematic/layout/manual file(s) in Toaplan2/Raizing/RA9704
Platform write-up Toaplan2/Raizing/toaplan2_raizing.md (names “armed police batrider”) — written overview; no schematic files of its own

bbakraid#
Battle Bakraid - Unlimited Version, Battle Bakraid
database (builds only)

Coin-Op Collection
default

Source not published

Published by the team — 1 item(s), not evidence of how this core was verified

Platform write-up Toaplan2/Raizing/toaplan2_raizing.md (names “battle bakraid”) — written overview; no schematic files of its own

bgaregga#
Battle Garegga
database (builds only)

Coin-Op Collection
default

Source not published

Published by the team — 1 item(s), not evidence of how this core was verified

Platform write-up Toaplan2/Raizing/toaplan2_raizing.md (names “battle garegga”) — written overview; no schematic files of its own

blkheart#
Black Heart
database (builds only)

Coin-Op Collection
default

Source not published

boogwing#
The Great Ragtime Show
database (builds only)

Coin-Op Collection
default

Source not published

bublbobl#
Bubble Bobble
database (builds only)

Coin-Op Collection
opt-in (beta)

Source not published

captaven#
Captain America and The Avengers
database (builds only)

Coin-Op Collection
default

Source not published

cbuster#
Crude Buster
database (builds only)

Coin-Op Collection
default

Source not published

cninja#
Tatakae Genshizin Joe & Mac
database (builds only)

Coin-Op Collection
default

Source not published

cobracom#
Cobra-Command
database (builds only)

Coin-Op Collection
default

Source not published

darkmist#
The Lost Castle In Darkmist
database (builds only)

Coin-Op Collection
opt-in (beta)

Source not published

darkseal#
Dark Seal
database (builds only)

Coin-Op Collection
default

Source not published

dblewing#
Double Wings
database (builds only)

Coin-Op Collection
default

Source not published

demonwld#
Demon's World / Horror Story
database (builds only)

Coin-Op Collection
default

Source not published

dietgo#
Diet Go Go
database (builds only)

Coin-Op Collection
default

Source not published

edrandy#
The Cliffhanger - Edward Randy
database (builds only)

Coin-Op Collection
default

Source not published

fshark#
Hishou Zame
database (builds only)

Coin-Op Collection
default

Source not published

gijoe#
G.I. Joe
database (builds only)

Coin-Op Collection
default

Source not published

kikikai#
KiKi KaiKai
database (builds only)

Coin-Op Collection
default

Source not published

kingdmgp#
Shippu Mahou Daisakusen
database (builds only)

Coin-Op Collection
default

Source not published

Published by the team — 1 item(s), not evidence of how this core was verified

Platform write-up Toaplan2/Raizing/toaplan2_raizing.md (names “kingdom grandprix”) — written overview; no schematic files of its own

lkage#
The Legend of Kage
database (builds only)

Coin-Op Collection
default

Source not published

maniach#
Mania Challenge
database (builds only)

Coin-Op Collection
default

Source not published

matmania#
Mat Mania
database (builds only)

Coin-Op Collection
default

Source not published

MegaSys1_A#
The Lord of King, E.D.F.: Earth Defense Force, Hachoo!, Iga Ninjyutsuden …
database (builds only)

Coin-Op Collection
default

Source not published

metamrph#
Metamorphic Force
database (builds only)

Coin-Op Collection
opt-in (alpha)

Source not published

mutantf#
Death Brade
database (builds only)

Coin-Op Collection
default

Source not published

mystwarr#
Mystic Warriors
database (builds only)

Coin-Op Collection
opt-in (beta)

Source not published

NextSpace#
Paddle Mania, The Next Space
database (builds only)

Coin-Op Collection
default

Source not published

nitrobal#
Gun Ball
database (builds only)

Coin-Op Collection
default

Source not published

oscar#
Psycho-Nics Oscar
database (builds only)

Coin-Op Collection
default

Source not published

pipibibs#
Pipi & Bibis / Whoopee!!
database (builds only)

Coin-Op Collection
default

Source not published

prehisle#
Genshitou 1930's
database (builds only)

Coin-Op Collection
default

Source not published

rallybike#
Rally Bike / Dash Yarou
database (builds only)

Coin-Op Collection
default

Source not published

robocop2#
Robocop 2
database (builds only)

Coin-Op Collection
default

Source not published

rohga#
Wolf Fang: Kuuga 2001
database (builds only)

Coin-Op Collection
default

Source not published

SNK68#
Ikari Three, Datsugoku - Prisoners of War, SAR - Search And Rescue, Street Smart
database (builds only)

Coin-Op Collection
default

Source not published

snowbro2#
Snow Bros. 2 - With New Elves / Otenki Paradise
database (builds only)

Coin-Op Collection
default

Source not published

snowbros#
Snow Bros. - Nick & Tom
database (builds only)

Coin-Op Collection
default

Source not published

sstriker#
Mahou Daisakusen
database (builds only)

Coin-Op Collection
default

Source not published

Published by the team — 1 item(s), not evidence of how this core was verified

Platform write-up Toaplan2/Raizing/toaplan2_raizing.md (names “sorcer striker”) — written overview; no schematic files of its own

supbtime#
Super Burger Time
database (builds only)

Coin-Op Collection
default

Source not published

tdragon#
Thunder Dragon
database (builds only)

Coin-Op Collection
default

Source not published

tekipaki#
Teki Paki, Pipi & Bibis / Whoopee!!
database (builds only)

Coin-Op Collection
default

Source not published

terracresta#
Soldier Girl Amazon, Kid no Hore Hore Daisakusen, Terra Cresta
database (builds only)

Coin-Op Collection
default

Source not published

thndzone#
Thunder Zone
database (builds only)

Coin-Op Collection
default

Source not published

tmnt2#
Teenage Mutant Ninja Turtles: Turtles in Time
database (builds only)

Coin-Op Collection
default

Source not published

truxton2#
Tatsujin Oh
database (builds only)

Coin-Op Collection
default

Source not published

tumblep#
Tumble Pop
database (builds only)

Coin-Op Collection
default

Source not published

twincobr#
Kyukyoku Tiger
database (builds only)

Coin-Op Collection
default

Source not published

vaportra#
Kuhga - Operation Code 'Vapor Trail'
database (builds only)

Coin-Op Collection
default

Source not published

vimana#
Same! Same! Same!, Vimana
database (builds only)

Coin-Op Collection
default

Source not published

wardner#
Wardner no Mori
database (builds only)

Coin-Op Collection
default

Source not published

wizdfire#
Dark Seal 2
database (builds only)

Coin-Op Collection
default

Source not published

zerowing#
Hellfire, Out Zone, Truxton / Tatsujin
database (builds only)

Coin-Op Collection
default

Source not published

zerowing#
Zero Wing
database (builds only)

Coin-Op Collection
default

Source not published

Arcade-Alpha68kN#
Kyros no Yakata, Super Stingray
database (builds only)

MeatCores
independent database

Source not published

Arcade-Appoooh#
Appoooh, Robo Wres 2001
meathax/appoooh @ aefed6cc
MAME compared: sanritsu/appoooh.cpp
Read: 19 HDL files, 5,685 lines (Quartus project)

MeatCores
independent database

Mostly MAME

low

Statements: 8 toward MAME

Cites MAME source — 7

rtl/appoooh_memory.sv:108 MAME copies epr-7542 bytes 0x2000-0x5fff into the bank-1 window at 0x10000-0x13fff.
rtl/appoooh_sound.sv:22 Relative MAME gains .5,.5,.5,.75 with a common 1/4 headroom gain.
rtl/segacrp2_315_5179.sv:23 MAME selects a pair of tables from A14,A12,A9,A6,A3,A0; even is M1.
rtl/sn76496_jt89.sv:4 Timing/noise/defaults follow pinned MAME sn76496.cpp by Nicola Salmoria (BSD-3-Clause).
README.md:7 One Z80 CPU at the MAME-configured 3.072 MHz clock.
README.md:13 The memory map, ROM hashes, control bits, graphics layouts, and priority behavior are implemented from MAME's BSD-3-Clause Appoooh hardware reference: [appoooh.
README.md:13 MAME source is not included in this repository.

Says it was translated, ported or taken from MAME — 1

rtl/segacrp2_315_5179.sv:1 license:BSD-3-Clause copyright-holders:Nicola Salmoria, David Haywood 315-5179 decryption tables translated from MAME's segacrp2_device.cpp.

Arcade-Bucky#
Bucky O'Hare
database (builds only)

MeatCores
independent database

Source not published

Arcade-CrystalSystem#
The Crystal of Kings
database (builds only)

MeatCores
independent database

Source not published

Arcade-DoCastle#
American Soccer, Mr. Do! vs. Unicorns, Super Pierrot, Mr. Do's Wild Ride …
database (builds only)

MeatCores
independent database

Source not published

Arcade-DrMicro#
Dr. Micro
meathax/drmicro @ daf03685
MAME compared: sanritsu/drmicro.cpp
Read: 18 HDL files, 5,492 lines (Quartus project)

MeatCores
independent database

Mostly MAME

low

Statements: 22 toward MAME

Cites MAME source — 21

rtl/drmicro_bus.sv:24 Pinned MAME noprw port reads zero (confirmed by the reference read tap).
rtl/drmicro_sound.sv:22 Relative MAME gains .5,.5,.5,.75 with a common 1/4 headroom gain.
rtl/drmicro_video.sv:136 Vertical clipping is NOT modulo-256 wrapping in MAME.
rtl/sn76496_jt89.sv:4 Timing/noise/defaults follow pinned MAME sn76496.cpp by Nicola Salmoria (BSD-3-Clause).
README.md:3 MAME is used only as an external behavioural reference; no software CPU, renderer or recording runs inside the core.
README.md:37 This section separates what is backed by direct evidence from what is inferred from MAME.
README.md:37 MAME is a good functional reference for this board but its own driver marks the CPU clock and the vertical blanking interval as unverified, so it is not treated
README.md:42 | CPU / interrupt phase against the reference | **KNOWN** | A PC and refresh-register trace taken at every frame's NMI request agrees with MAME to the instructi
README.md:44 | SN76496 register model, noise LFSR, attenuation curve | **INFERRED** | Follows MAME's SN76496 variant (17-bit LFSR, taps 0x04/0x08, 2 dB steps) and is checked
README.md:45 | MSM5205 decode and sample sequencer | **INFERRED** | JT5205 decoder with MAME's 15-bit sample address, 6 kHz (S64) rate and `0x70` end marker; checked against
README.md:46 | Raster totals, blanking length, refresh rate | **HYPOTHESIS** | MAME uses 60 Hz with an explicitly "not accurate" 2.5 ms vblank. The core uses a 320×256 raste
README.md:47 | CPU and PSG clock | **HYPOTHESIS** | 18.432 MHz / 6 = 3.072 MHz per MAME, which marks it with a question mark. Older MAME versions clocked the PSGs at 18.432
README.md:48 | Port 05 read value, control-port bits 2 and 3, analogue mixing and filtering | **HYPOTHESIS** | Unknown; the core follows MAME (port 05 reads 0, bits 2/3 igno
README.md:50 The one remaining strict-comparison difference against MAME (a handful of background tiles in one frame of a moving-game capture) was traced to the two test har
README.md:57 | Address decoder, bus hold and I/O ports | `rtl/drmicro_bus.sv`, `rtl/drmicro_core.sv` | **INFERRED** from the MAME map |
README.md:60 | Colour PROM lookup and resistor-ladder DAC weights | `rtl/drmicro_memory.sv`, `rtl/drmicro_video.sv` | **INFERRED** (33/71/151 and 82/173 weights as in MAME)
README.md:61 | Three SN76496 PSGs | `rtl/sn76496_jt89.sv` (JT89 register structure, MAME SN76496 variant behaviour) | **INFERRED** |
README.md:72 Place the archive in MiSTer's MAME ROM directory:
README.md:125 This covers four-state unit tests for the CPU timing fixes, loader, bus and memory; independent fixture checks for the renderer, PSG and ADPCM; elaboration of t
README.md:125 Set `MAME` in `.tools/local_env.json` (or the environment) to a MAME 0.289 binary that includes the `drmicro` driver.
README.md:132 [MAME](https://www.mamedev.org/), and Uki's `drmicro` driver in particular, for reference behaviour, ROM naming and ROM mappings.

Says it matches, follows or was checked against MAME — 1

README.md:43 | Memory map, video RAM layout, tile and sprite formats, palette PROM decode | **INFERRED** | Derived from the ROM/PROM contents and the pinned MAME driver; con

Arcade-EscapeKids#
Escape Kids
meathax/escapekids @ 91dc26a4
MAME compared: konami/vendetta.cpp + 11 related file(s)
Read: 27 HDL files, 6,988 lines (Quartus project)

MeatCores
independent database

Mostly MAME

low

47%

Statements: 2 toward hardware, 44 toward MAME

Cites hardware documentation that MAME's driver does not — 2

rtl/vendor/jtcores/cores/aliens/hdl/jt051962.v:19 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
rtl/vendor/jtcores/cores/aliens/hdl/jt052109.v:19 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi

Cites MAME source — 35

rtl/vendor/jtcores/cores/aliens/hdl/jt051962.v:19 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
rtl/vendor/jtcores/cores/aliens/hdl/jt052109.v:19 Based on Furrtek's RE work on die shots and MAME documentation 8x8 tiles Games that may be using this chip _88games, ajax, aliens, blockhl, blswhstl, bottom9, crimfght, cuebrick, ddboy, devstors, esckids, fuusenpn, gbusters, glfgreat, gradi
rtl/vendor/jtcores/cores/riders/hdl/jt053244.sv:145 GX975 (Escape Kids) drives a 053246-style 256-entry sprite LUT through the k44 register interface: MAME vendetta.cpp copies 0x800 words (256 entries) per vblank DMA.
rtl/vendor/jtcores/cores/riders/hdl/jt053244_scan.sv:101 Escape Kids (GX975) is wired to a real 053246/053247 pair instead: MAME's own k053246_k053247_k055673.cpp sprite-format table documents word6[15]=mirror y, word6[14]=mirror x for that chip, with word6[9:8] instead being a game-dependent "ef
rtl/vendor/jtcores/cores/riders/hdl/jt053244_scan.sv:119 MAME subtracts the 053246 display-window X offset (ox-offx) before applying the per-game dx.
rtl/vendor/jtcores/cores/riders/hdl/jt053244_scan.sv:122 110 = the shared jtframe_objdraw pipeline constant 105 plus MAME's esckids dx=5.
rtl/vendor/jtcores/cores/riders/hdl/jt053244_scan.sv:263 MAME's GX975 zoom register is reciprocal (k053246_k053247_k055673.h, k053247_draw_single_sprite_gxcore): zoomx = raw ?
rtl/vendor/jtcores/cores/riders/hdl/jt053244_scan.sv:328 There is no additional edge offset in the MAME K053246 path; adding one displaces edge pixels into the opposite side of the frame.
rtl/vendor/jtcores/cores/riders/hdl/jtriders_obj.v:103 Escape Kids' K053246/053247 pair instead stores sprite tiles PACKED 4bpp (2 pixels per byte, both nibbles complete pixels) per MAME src/mame/konami/k053246_k053247_k055673.cpp k053247_device::device_start() "static const gfx_layout spritela
rtl/vendor/jtcores/cores/riders/hdl/jtriders_obj.v:108 } *4-bit nibbles charincrement 128*8 (128 bytes/tile, matching the esckids linear code*128 addressing already used above) For one 32-bit fetch (bytes d[7:0]/d[15:8]/d[23:16]/d[31:24] = half a tile row = 8 pixels), MAME's xoffset {2*4,3*4,0*
rtl/vendor/jtcores/cores/riders/hdl/jtriders_obj.v:117 Composed with the little-endian 32-bit fetch, screen pixel s=0..7 takes the nibble at d[4*{3,2,1,0,7,6,5,4}[s] +: 4]: within each 16-bit word the HIGH byte's two pixels come first, high nibble before low - i.e. the OBJ ROM data bus shifts t
rtl/vendor/jtcores/cores/riders/hdl/jtriders_obj.v:122 Proven exhaustively: a Python decode of all 524288 rows of the real interleaved 4MB sprite region with MAME's exact readbit algorithm matches this mapping with zero mismatches, and the same model byte-for-byte reproduces live Verilator fram
rtl/vendor/jtcores/cores/riders/hdl/jtriders_obj.v:159 GX975 (Escape Kids) instead drives a plain K053246/053247 pair (see MAME src/mame/konami/vendetta.cpp "ESCAPE KIDS uses 053246's unknown function" and k053246_k053247_k055673.cpp k053247_device::device_start() spritelayout), whose tile ROM
rtl/vendor/jtcores/cores/riders/hdl/jtriders_obj.v:175 As the object layer should not be drawn directly over a shadow, it looks like the logic must be like this - in the LUT the shadow bits are set for the whole sprite - when drawing the sprite, if the shadow is enabled and the sprite pen is 15
rtl/vendor/jtcores/cores/simson/hdl/jtsimson_main.v:144 Escape Kids has one active-low MAME SERVICE input for both the cabinet service controls and the physical test switch.
rtl/vendor/jtcores/cores/simson/hdl/jtsimson_main.v:467 Video-bank views are exclusive with the corresponding K052109 window, matching vendetta.cpp:405-436.
rtl/vendor/jtcores/cores/simson/hdl/jtsimson_main.v:494 MAME esckids_map maps 0x6000-0x7FFF as banked ROM, so this alias is retained as hardware/ROM-trace evidence, not inferred from the MAME address map alone.
rtl/vendor/jtcores/cores/simson/hdl/jtsimson_main.v:505 Aupper[3:0] is the lower four bank-line bits produced by JTKCPU; higher banks are not synthesized into a generic MAME-sized allocation.
rtl/vendor/jtcores/cores/simson/hdl/jtsimson_main.v:638 MAME's EEPROM port: DO, READY, service/test, and OBJ busy.
rtl/vendor/jtcores/cores/simson/hdl/jtsimson_main.v:647 { 2'b11, eep_rdy, eep_do, 3'b111, dip_test } // use for MAME comparisons
rtl/vendor/jtcores/cores/simson/hdl/jtsimson_obj.v:113 As the object layer should not be drawn directly over a shadow, it looks like the logic must be like this - in the LUT the shadow bits are set for the whole sprite - when drawing the sprite, if the shadow is enabled and the sprite pen is 15
rtl/vendor/jtcores/cores/simson/hdl/jtsimson_scroll.v:138 MAME's esckids_tile_callback: bank<<13, COL3:2 at code[12:11], COL1:0 at code[9:8], and COL4 at code[10].
rtl/vendor/jtcores/cores/simson/hdl/jtsimson_video.v:329 MAME konami/vendetta.cpp K052109_CB_MEMBER: vendetta_tile_callback uses a 2-bit color code (color&0xc0)>>6, but esckids_tile_callback (the callback actually bound for Escape Kids, vendetta.cpp:207-210) uses a 3-bit color code (color&0xe0)>>
README.md:27 | CUS1 / 053248 main CPU | `jtsimson_main.v` and `modules/jtkcpu` | Pinned `vendetta.cpp` main-CPU declaration/map plus JTCORES donor; INFERRED board integratio
README.md:28 | CUS8 / K052109 tile generator + CUS7 / K051962 timing | `jtsimson_scroll.v` through `jt052109.v` and `jt051962.v` | MAME K052109 map/device setup and JTCORES
README.md:29 | CUS4 / K053246 + CUS5 / K053247 GX975 sprite path | `jtriders_obj.v`, `jt053244.sv` and `jt053246_dma.v` | MAME GX975 sprite configuration/callback and JTCORE
README.md:30 | CUS6 / K053251 priority and palette control | `jtsimson_colmix.v` and `jtcolmix_053251.v` | MAME priority-register/palette configuration and JTCORES implement
README.md:31 | CUS2 / K053252 CCU | `jtsimson_video.v` with `jtk053252.v` and `jtk053252_mmr.sv` | Furrtek die reverse engineering establishes the counter/register fields; M
README.md:32 | CUS3 / K053260, YM2151 and Z80 sound system | `jtsimson_sound.v`, `jt053260`, `jt51` and `jtframe_z80.v` | Pinned MAME sound map/device setup plus JTCORES imp
README.md:33 | ER5911 serial EEPROM | `jtsimson_main.v` through `jt5911.sv` | MAME 128-byte EEPROM declaration and the JTCORES serial-device model; INFERRED board integratio
README.md:34 | Decoder/PAL glue | Escape branch of `jtsimson_main.v` | Pinned MAME `esckids_map` and the captured boot bus contract; INFERRED, with no standalone custom-PAL
README.md:40 JTCORES and MAME are used elsewhere as implementation/reference sources, not as independent PCB proof.
README.md:50 Supply legally obtained MAME ROM archives matching the set names above.
README.md:60 For the split layout, keep both archives in the MAME ROM directory.
README.md:91 The MAME project and its Konami/Vendetta driver for reference behavior and ROM mappings.

Says it matches, follows or was checked against MAME — 1

rtl/vendor/jtcores/cores/riders/hdl/jt053244_scan.sv:266 (0x400000+(raw>>1))/raw : 0x800000; if( objset1[3] ) zoomx >>= 1; // Escape Kids only jtframe_draw's own hz_cnt/HZONE accumulator is independently reciprocal in hzoom (its long-run scale factor is HZONE/hzoom), so the two reciprocals comp

Shares text with the MAME driver without saying so — 8

rtl/vendor/jtcores/cores/aliens/hdl/jt052109.v:106 00 A~B 6~7 8~9 Reset state — shares text with konami/k052109.cpp:84
rtl/vendor/jtcores/cores/aliens/hdl/jt052109.v:107 01 8~9 4~5 6~7 — shares text with konami/k052109.cpp:85
rtl/vendor/jtcores/cores/aliens/hdl/jt052109.v:108 10 6~7 2~3 4~5 — shares text with konami/k052109.cpp:86
rtl/vendor/jtcores/cores/aliens/hdl/jt052109.v:109 11 4~5 0~1 2~3 — shares text with konami/k052109.cpp:87
rtl/vendor/jtcores/cores/riders/hdl/jtriders_obj.v:108 xoffset { 2*4,3*4,0*4,1*4, 6*4,7*4,4*4,5*4, ... } *4-bit nibbles — shares text with konami/k053246_k053247_k055673.cpp:817
rtl/vendor/jtcores/cores/riders/hdl/jtriders_obj.v:112 row = 8 pixels), MAME's xoffset {2*4,3*4,0*4,1*4,6*4,7*4,4*4,5*4} is a BIT — shares text with konami/k053246_k053247_k055673.cpp:817
rtl/vendor/jtcores/cores/riders/hdl/jtriders_obj.v:160 (see MAME src/mame/konami/vendetta.cpp "ESCAPE KIDS uses 053246's unknown — shares text with konami/vendetta.cpp:27
rtl/vendor/jtcores/cores/simson/hdl/jtsimson_video.v:329 MAME konami/vendetta.cpp K052109_CB_MEMBER: vendetta_tile_callback uses — shares text with konami/vendetta.cpp:184

Arcade-I-Robot#
I, Robot
database (builds only)

MeatCores
independent database

Source not published

Arcade-IkkiSunsoft#
Pettan Pyuu, Markham, The Guiness
database (builds only)

MeatCores
independent database

Source not published

Arcade-MCR68#
Arch Rivals, Blasted, Pigskin 621AD, Xenophobe
database (builds only)

MeatCores
independent database

Source not published

Arcade-NamcoND1#
Namco Classic Collection Vol.1, Namco Classic Collection Vol.2
database (builds only)

MeatCores
independent database

Source not published

Arcade-NARC#
Narc
database (builds only)

MeatCores
independent database

Source not published

Arcade-Primal2#
Primal Rage II
database (builds only)

MeatCores
independent database

Source not published

Arcade-SegaSystem24#
Bonanza Bros, Crack Down, Gain Ground
database (builds only)

MeatCores
independent database

Source not published

Arcade-SegaSystem32#
Alien3: The Gun, Arabian Fight, Air Rescue, Burning Rival …
meathax/s32 @ 512b5470 (approx.)
MAME compared: sega/segas32.cpp + 7 related file(s)
Read: 32 HDL files, 18,906 lines (Quartus project)

MeatCores
independent database

Mostly MAME

medium

84%

Statements: 7 toward hardware, 215 toward MAME

Cites hardware documentation that MAME's driver does not — 7

README.md:63 | Board and clocks | Sega schematics 171-5964D / 171-5965C | Standard single-screen board; V60, Z80/YM3438, and PCM domains |
README.md:64 | Main CPU/controller | Schematics, sheet 1 | 16-bit V60 bus, interrupts, timers, and system control |
README.md:65 | Scroll hardware | Schematics, sheet 2; Sega 315-5387 | Four tilemap layers and dual-port VRAM |
README.md:67 | Colour/video output | Schematics, sheet 5; [315-5242 silicon evidence](https://github.com/furrtek/SiliconRE/tree/master/Sega/315-5242) | Palette, priority, sh
README.md:110 | Sega 315-5387 scroll | Tilemap VRAM and registers | [`s32_tilemap.sv`](rtl/video/s32_tilemap.sv); schematic sheet 2 |
README.md:112 | Sega 315-5296 I/O | JAMMA, DIP, service, coin | [`s32_io.sv`](rtl/io/s32_io.sv); schematic sheet 6 |
README.md:130 **Sega, Nemesis1207, and System 32 researchers** - original hardware and public schematic material used by this project.

Cites MAME source — 199

Arcade-SegaSystem32.sv:288 This is a model-consistency fix, not a turbo: the alternative consistent choice (both sides at 16.108 MHz) was measured to make Dark Edge's gameplay countdown advance every 70 frames against MAME's 35.
Arcade-SegaSystem32.sv:513 GA2's 315-5296 player ports follow MAME: {left,right,up,down,unused,button3,button2,button1}, active low.
Arcade-SegaSystem32.sv:759 MAME's Alien3 P1_A/P2_A masks leave only BUTTON1/2 (the trigger and the second cabinet button) connected; direction and BUTTON3 bits are physically unused.
Arcade-SegaSystem32.sv:822 MAME marks Air Rescue ANALOG1 PORT_REVERSE, ANALOG2 normal, and ANALOG3 centered.
Arcade-SegaSystem32.sv:844 MAME system32_generic: port C is unused; port E/SERVICE12 is {unknown[7:6], start2, start1, coin2, coin1, test, service}, active low.
Arcade-SegaSystem32.sv:883 GA2's 4-player i8255 port C is MAME EXTRA3 (ppi.in_pc_callback -> "EXTRA3").
Arcade-SegaSystem32.sv:997 Original = the 4:3 arcade monitor (MAME's default for both 320- and 416-wide System 32 modes); the old 13:7 square-pixel ratio stretched holo's 320 mode.
rtl/audio/s32_audio_mix.sv:30 Exact MAME route gains expressed as small integers: System 32: YM1 0.30 + YM2 0.30 + RF5C68 0.40 (divide by 10).
rtl/audio/s32_audio_mix.sv:33 Multi 32 cross-routes BOTH the YM and the MultiPCM (MAME segas32.cpp: multipcm add_route(1,"sleft") / add_route(0,"sright") — stream 1 -> left, stream 0 -> right — the same cross as the YM).
rtl/audio/s32_multipcm.sv:4 Register, descriptor, pitch and PCM semantics follow MAME multipcm.cpp and gew.cpp.
rtl/audio/s32_multipcm.sv:74 MAME update_step: base=(1+pitch/1024), exponent=(signed octave-1).
rtl/audio/s32_multipcm.sv:75 This RTL position uses sixteen fractional bits instead of MAME's TL_SHIFT.
rtl/audio/s32_multipcm.sv:107 9..15 attenuate right using MAME's inverted distance.
rtl/audio/s32_rf5c68.sv:4 Register map (per MAME rf5c68.cpp): 0 ENV, 1 PAN {R[7:4],L[3:0]}, 2 FDL, 3 FDH, 4 LSL, 5 LSH, 6 ST, 7 control {en[7], sel[6]: 1=cbank(ch) 0=wbank, val[3:0]}, 8 channel-OFF mask (active low enables) Samples: 8-bit sign-magnitude-ish (0xFF =
rtl/audio/s32_rf5c68.sv:227 MAME models the RF5C68 as a 10-bit DAC: clear the low six bits of an in-range mix, then clamp excursions to signed 16-bit full scale.
rtl/audio/s32_rf5c68.sv:303 A marker at the loop target is an empty/dead voice: retain the loop address and contribute silence, as MAME does.
rtl/audio/s32_soundsys.sv:216 MAME installs the Z80's 0xE000-0xFFFF onto the V60's 0x700000 window with 8-bit handlers on BOTH byte lanes and no umask16, so V60 byte k maps to Z80 0xE000+k (byte granularity, 8 KB mirror).
rtl/audio/s32_soundsys.sv:350 slot 3 = mask reg (MAME: m_sound_irq_control[3])
rtl/audio/s32_soundsys.sv:353 only YM #1 wired (MAME)
rtl/audio/s32_soundsys.sv:424 MAME maps D0-D3 mirrored only at D4-D7.
rtl/audio/s32_soundsys.sv:453 RF5C68 registers (0xC000-0xCFFF) are write-only; the sound map has no unmap_value_high, so reads there return 0x00 in MAME, not 0xFF (audit R20 AU-7).
rtl/cpu/v60/s32_v60.sv:5 Behavioral contract is MAME's v60 core (BSD-3-Clause, Farfetch'd / R. Belmont): opcode dispatch per optable.hxx, addressing modes per am1-3.hxx, exception entry per v60.cpp.
rtl/cpu/v60/s32_v60.sv:13 the fill/stop variants (MOVC*/CMPC*/SCHC*/SKPC*), TASI, bit ops, GETPSW/UPDPSW, TRAP/TRAPFL/BRK/BRKV, CHLVL, task save/load, privileged register moves (LDPR/STPR), and MAME-defined decimal/bit- string/bit-field groups.
rtl/cpu/v60/s32_v60.sv:20 - Not implemented (reserved-instruction exception, logged in sim): the un-dispatched 0x5C/0x5F sub-opcodes (MAME UNHANDLED).
rtl/cpu/v60/s32_v60.sv:21 MMU/TLB effects are absent like MAME, but CLRTLB still decodes its complete operand.
rtl/cpu/v60/s32_v60.sv:31 V60/V70 reset PC (MAME m_start_pc; audit V60-21)
rtl/cpu/v60/s32_v60.sv:129 PSW fields (MAME bit layout: Z=b0,S=b1,OV=b2,CY=b3,IE=b18,EL=b25:24,IS=b28)
rtl/cpu/v60/s32_v60.sv:685 C-style truncating divide-by-8 of a signed bit offset (MAME bamoffset/8)
rtl/cpu/v60/s32_v60.sv:775 stack switch on IS change, or EL change while IS=0 (MAME v60WritePSW)
rtl/cpu/v60/s32_v60.sv:1210 primary dispatch (per MAME optable.hxx)
rtl/cpu/v60/s32_v60.sv:1215 BRK — MAME skips this opcode (A4)
rtl/cpu/v60/s32_v60.sv:1235 ---- Bcc disp8 (0x60-0x6a,0x6c-0x6f) / disp16 equivalent ---- 0x6B/0x7B are holes in MAME's authoritative primary dispatch table, not branch-condition encodings.
rtl/cpu/v60/s32_v60.sv:1295 MAME opDBcc: reg ALWAYS decrements; branch iff cond true and decremented reg != 0.
rtl/cpu/v60/s32_v60.sv:1401 JMP/JSR/TASI: MAME sets moddim=0 — the dim scales INDEXED modes' index register, and ga2's jump tables (3-byte BR entries, `JMP [PC+d](rN)`) rely on the unscaled index (found by real-ROM boot: dim=2 quadrupled the index and jumped mid-table
rtl/cpu/v60/s32_v60.sv:1427 RETI adj (halfword, MAME moddim=1)
rtl/cpu/v60/s32_v60.sv:1451 MAME F7a/F7b decode with dim 0 (0x58 byte) / 1 (0x5A half): autoincrement/indexed AMs step and scale by the element size, and F7b immediates size accordingly — not dword.
rtl/cpu/v60/s32_v60.sv:1471 MAME implements ADDDC/SUBDC/SUBRDC/CVTDPZ/CVTDZP (radm timer); remaining subops are reserved there too.
rtl/cpu/v60/s32_v60.sv:1560 Unhandled sub-opcodes still take the reserved-instruction vector exactly as MAME's op5C/op5F UNHANDLED entries fatalerror.
rtl/cpu/v60/s32_v60.sv:1602 RSR (A9): pop PC ONLY (MAME opRSR: PC=[SP]; SP+=4)
rtl/cpu/v60/s32_v60.sv:1607 MAME/NEC floating-exception test: enabled TKCW causes are intersected with the PSW floating-status field.
rtl/cpu/v60/s32_v60.sv:1636 F12: plan operands per instflags (MAME F12DecodeOperands)
rtl/cpu/v60/s32_v60.sv:1645 MOVEA takes op1 as an ADDRESS (MAME ReadAMAddress) — decoding it as a value loaded SP with a byte read instead of the EA and sent ga2's boot stub off a cliff (found by real-ROM boot)
rtl/cpu/v60/s32_v60.sv:2277 MAME opDIVX/opDIVUX set only S/Z and leave OV unchanged; do not clear it.
rtl/cpu/v60/s32_v60.sv:2309 MAME opROTC*: the carry bit enters the active operand's LSB; bits above a byte/halfword operand are not part of the ring.
rtl/cpu/v60/s32_v60.sv:2640 pops (8) + frame-destroy operand (MAME: SP += amout), then the PSW write may bank-switch SP — order matters: adjust THEN switch.
rtl/cpu/v60/s32_v60.sv:2682 push highest set register first (MAME pushes from r31 down?
rtl/cpu/v60/s32_v60.sv:2730 TASI sets flags as SUBB(old, 0xFF, 0) before writing 0xFF (MAME opTASI).
rtl/cpu/v60/s32_v60.sv:2767 R27 (dst) / R28 (src) updated at completion (MAME MOVSTR).
rtl/cpu/v60/s32_v60.sv:2776 Element-size dim for both (MAME dim 0 byte / 1 half — see decode).
rtl/cpu/v60/s32_v60.sv:2793 V60-15: down-direction search (subop[0]=1, MAME opSEARCHD*).
rtl/cpu/v60/s32_v60.sv:2795 The down form scans the range in descending order from MAME's start index: byte reads op1+len1 down to op1 (len1+1 reads; the first read is one past the buffer, exactly as opSEARCHDB does), half reads op1+(len1-1)*2 down to op1 (len1 reads)
rtl/cpu/v60/s32_v60.sv:2820 MOVCD/MOVCFD (down copy) transfers the ascending range base..base+min-1 in descending element order (MAME opMOVSTRD): start at the TOP of that range and decrement, instead of walking physically below the base as the old code did (audit R20
rtl/cpu/v60/s32_v60.sv:2829 CMPCS (0x02): stop mode starts with CY=1, cleared when a fill (R26) byte is met in the compare (MAME opCMPSTR bStop).
rtl/cpu/v60/s32_v60.sv:2832 CMPCF (0x01): fill the SHORTER operand's tail with R26 BEFORE the compare (MAME bFill); MOVC fill happens AFTER the copy.
rtl/cpu/v60/s32_v60.sv:2861 Down exhaustion: the scan ran off the bottom to i=-1 (MAME opSEARCHD*), so Z=0, R27=0xFFFFFFFF, and str_src has already reached op1-step.
rtl/cpu/v60/s32_v60.sv:2876 CMPC exhausted the common prefix (all min elements equal): R28=len1+min*step, R27=len2+min*step, and S/Z from the length compare (MAME opCMPSTR tail).
rtl/cpu/v60/s32_v60.sv:2911 Z follows MAME's post-loop test i==len1: up never breaks at i==len1 (Z=0), down does so only at its one-past-the-top byte read (str_cnt==len1+1).
rtl/cpu/v60/s32_v60.sv:2950 CMPC (MAME opCMPSTR): compare source(op1) vs dest(op2).
rtl/cpu/v60/s32_v60.sv:3209 BAM: bit addressing modes for the 0x5B/0x5D groups (MAME BAMTable1/2 implemented subset — everything MAME fatalerrors on traps here too).
rtl/cpu/v60/s32_v60.sv:3683 exception / interrupt entry (MAME v60_do_irq): switch to interrupt context, push old PSW, push PC, PC = vector
rtl/cpu/v60/s32_v60.sv:3918 per-opcode dim helpers (operand sizes per MAME op12 handlers)
rtl/cpu/v60/s32_v60.sv:3920 F12 ops whose FIRST operand is an effective address, not a value (MAME F12DecodeFirstOperand(ReadAMAddress, ...)): MOVEA and IN
rtl/cpu/v60/s32_v60.sv:3941 NOTE: ROTH (8b) / ROTCH (9b) must NOT appear here — their op1 is the rotate COUNT, a byte (MAME ReadAM dim 0); listing them in the half group made `ROT.H #imm8, r6` decode one byte long and holo's EEPROM write loop entered mid-instruction (
rtl/cpu/v60/s32_v60.sv:3974 These read op2 as a VALUE (MAME ReadAM), so a memory operand must be loaded into op2val before exec; otherwise the exec fell back to the effective address / a stale op2val (audit R20 V60-18).
rtl/cpu/v60/s32_v60.sv:4060 MOVC completion (MAME opMOVSTRU*/opMOVSTRD*): publish R28/R27 for the final element index `idx`, and — for the fill variants (MOVCFU/MOVCFD) with the source shorter than the destination — kick off the R26 tail-fill phase.
rtl/cpu/v60/s32_v60.sv:4083 MAME pads the destination tail elements [idx, lenop2) with R26; the down form uses op2+dest+(lenop2-j-1) for bytes and op2+(lenop2-j-1)*2 for halves.
rtl/cpu/v60/s32_v60.sv:4164 MAME MOV sets no flags?
rtl/cpu/v60/s32_v60.sv:4285 A zero count must clear CY (MAME); the old code left it unchanged (audit R20 V60-7).
rtl/cpu/v60/s32_v60.sv:4312 MAME defines CY from the post-rotate wrap bit: LSB after a positive (left) rotate, MSB after a negative (right) rotate.
rtl/cpu/v60/s32_v60.sv:4323 MAME clears CY for a zero count; nonzero counts retain the final shifted-out bit, so only bypass the iterative state for zero.
rtl/cpu/v60/s32_v60.sv:4384 MAME divide-by-zero: destination unchanged and no trap, but Z/S are still set from the (unchanged) destination = the dividend, and OV is cleared (audit R20 V60-8); the old code left flags stale.
rtl/cpu/v60/s32_v60.sv:4417 MAME sets OV and leaves the destination unchanged (audit R20 V60-8); the old code always cleared OV and wrote the wrapped quotient.
rtl/cpu/v60/s32_v60.sv:4435 MAME opMULX/opMULUX leave OV unchanged
rtl/cpu/v60/s32_v60.sv:4451 MAME: no zero-divide trap
rtl/cpu/v60/s32_v60.sv:4523 MAME opCALL: SP-=4; [SP]=AP; AP=op2; SP-=4; [SP]=retPC; PC=op1.
rtl/cpu/v60/s32_v60.sv:4560 MAME opTRAP: the operand's HIGH nibble is a Bcc-encoded condition (cond 0xB never traps); only trap when it evaluates true, else fall through.
rtl/cpu/v60/s32_v60.sv:4810 SHA left-shift overflow (MAME SHIFTLEFT_OV op12.hxx): OV is set when the top `count` bits of the width-sized value are not all equal to the sign bit — i.e. a bit different from the sign is shifted out through the top.
rtl/cpu/v60/s32_v60.sv:4812 MAME masks exactly `count` bits (((1<<count)-1) << (bitsize-count)); using count+1 here spuriously set OV (e.g. SHA.B #1,0x40 gave OV=1 vs MAME OV=0), misbranching a following signed Bcc (S^OV).
rtl/cpu/v60/s32_v60.sv:4823 count > width: MAME's macro is UB here (bitsize-count<0); any nonzero value overflowed
rtl/cpu/v60/s32_v60.sv:4899 MAME opMUL/opMULU: OV = (product >> width) != 0 on the product's unsigned bit pattern (signed product for MUL, unsigned for MULU).
rtl/cpu/v60/s32_v60.sv:4901 For byte/half MAME shifts the 32-bit value; for word, the 64-bit one.
rtl/cpu/v60/s32_v60.sv:4924 MAME clears OV for REM/REMU (audit R20 V60-8)
rtl/cpu/v60/s32_v60.sv:4933 Behavioral contract is MAME op2.hxx/op5.hxx, which use host `float` — round-to-nearest-even, with gradual underflow (subnormals) and IEEE special values.
rtl/cpu/v60/s32_v60.sv:4949 NEGFS/ABSFS are NOT: MAME does ReadAMAddress + store only (no load) — they operate on op1 and must not read a possibly read-sensitive destination.
rtl/cpu/v60/s32_v60.sv:5125 Deliberate divergence from the pinned MAME for |n| > 30: MAME computes `appf * / (1 << n)` with the host's shift-count masking (&31, and 1 << 31 = INT_MIN there), so e.g. SCLFS(31) flips the sign and SCLFS(32) is a no-op on x86.
rtl/cpu/v60/s32_v60.sv:5182 Pinned MAME converts (uint32_t)(int64_t)val on its x86 host: NaN and out-of-int64-range saturate the hardware convert to INT64_MIN, whose low 32 bits are 0.
rtl/cpu/v60/s32_v60.sv:5205 MAME stores the LOW 32 BITS of the int64 truncation, not a clamp: well-defined in C for e in [31,62]; e >= 63 saturates the x86 convert to INT64_MIN (low 32 = 0).
rtl/cpu/v60/s32_v60.sv:5216 (MAME: (_S && val>=0) || (!_S && val<=-1); |val| >= 1 here).
rtl/cpu/v60/s32_v60.sv:5331 MAME materializes the subtraction: same-signed infinities give inf-inf = NaN, so they compare Z=0/S=0 like unordered operands.
rtl/io/s32_io.sv:51 MAME device_reset: m_cnt = 0
rtl/io/s32_io.sv:52 MAME device_reset: m_dir = 0
rtl/io/s32_io.sv:56 Ports A-H = 0-7, CNT = 0xE, direction = 0xF (per MAME map).
rtl/io/s32_io.sv:586 MAME WAIT_FOR_COMPLETION: CS ends it
rtl/io/s32_io.sv:618 MAME's d7_r returns shift_register[7] before applying the side-effecting left shift.
rtl/io/s32_io.sv:703 SegaSonic's X counter is reversed like the MAME TRACKX input; Y defaults positive-down and can be inverted with the descriptor-gated OSD option.
rtl/io/s32_io.sv:791 Control word powers up 0x9b (all ports input, mode 0) like MAME i8255 device_reset(); a mode-set write (port 3, bit7=1) latches it and a control-port read returns it with bit7 set.
rtl/io/s32_io.sv:799 MAME's i8255 implementation returns the external pin value for input bits and the output latch for output bits; returning pc_in unconditionally made a mode-set write such as 0x93 observe 0xff instead of the mixed Port-C value (upper output
rtl/io/s32_io.sv:818 MAME's set_mode() clears the output latches whenever a new mode word is written.
rtl/io/s32_io.sv:854 MAME interrupt_control_16_w: BOTH byte lanes are registers — even byte -> ctl[offset*2], odd byte -> ctl[offset*2+1] (ga2 programs vectors 0..4, the ack reg 7, and the timer highs 9/11 on both lanes; found by real-ROM boot: dropped acks mad
rtl/io/s32_io.sv:916 MAME device_reset (memset(m_v60_irq_control,0xff)) leaves the pending byte (index 7) = 0xff -> all 5 sources pending, but ctl[6]=0xff below masks them so no IRQ is delivered until the game unmasks.
rtl/io/s32_io.sv:928 MAME/device-reset contract: the complete 16-byte register file starts at FF.
rtl/io/s32_io.sv:979 n == 0: MAME only re-arms `if (duration)` — the write stores the register byte and leaves an in-flight one-shot running.
rtl/io/s32_io.sv:988 MAME/hardware: 0x100*N ticks at exactly 50 MHz/16.
rtl/io/s32_io.sv:995 n == 0: register write only, armed one-shot keeps running (MAME parity — see timer 0 above).
rtl/io/s32_io.sv:1003 MAME int_control_r/hardware-visible readback
rtl/mem/s32_fb_if.sv:6 Services (per DESIGN.md): - erase_line(y): fill line with 0xFFFF - write_run(...): pixel run writes from the sprite renderer; wr_shadow runs RMW dest &= 0x7fff instead (MAME shadow sprites clear framebuffer bit 15) - read_line(y):
rtl/mem/s32_rom_loader.sv:12 The inverse of MAME's destination-to-source address lookup is applied (see v25_stream_to_dst below and DESIGN.md §8.1).
rtl/mem/s32_rom_loader.sv:90 MAME describes the ROM as: descrambled[dst] = raw[bitswap(dst, 14,11,15,12,13,4,3,7, 5,10,2,8,9,6,1,0)] The ioctl loader visits raw source addresses in ascending order, so the BRAM write address must use the inverse permutation: dst = inver
rtl/prot/s32_prot.sv:104 Burning Rival ROM-string protection copy (MAME init_brival).
rtl/prot/s32_prot.sv:115 Read trap: the MAME handler is installed for word reads at 0x20BA00-07.
rtl/prot/s32_prot.sv:212 MAME's init_jleague installs a write16 handler at 0x20f700-0x20f705: offset 0 indexes the main-ROM table at 0x07bbc0 and publishes its low byte at work RAM 0x20f708; offset 2 (0x20f704) publishes the selected team byte at 0x200016.
rtl/prot/s32_prot.sv:303 Dragon Ball Z V.R. V.S. FD1149 protection handler (MAME init_dbzvrvs).
rtl/prot/s32_prot.sv:543 HLE: wakeup string + echo protocol (MAME simulation fallback) ga2: "wake up!
rtl/prot/s32_prot.sv:547 v1 provides the string + the ga2 sprite expansion results table (prot[16] from MAME).
rtl/prot/s32_prot.sv:581 ga2 sprite-expansion result table (MAME prot[16])
rtl/prot/s32_prot.sv:621 Air Rescue DSP register HLE (single-board reduction) MAME segas32_m.cpp maps the uPD7725-facing register block at 0xa00000-0xa00007.
rtl/prot/s32_prot.sv:644 MAME arescue_dsp_w uses COMBINE_DATA, so each CPU byte lane is retained.
rtl/s32_core.sv:12 In a captured pre-fix Dark Edge build, running both sides from ce_cpu made its displayed gameplay countdown advance every 70 frames instead of MAME's measured 35-frame writes to 0x20a112 at PC 0x087080, consistent with alternate VBlank work
rtl/s32_core.sv:180 Driving-cabinet games poll this at whatever cadence their own code takes (measured in MAME: every frame during Rad Mobile gameplay, every other frame on its Input Test screen) -- the host wheel adapter slews to this event directly instead o
rtl/s32_core.sv:304 MAME reset PC (audit R20 V60-21)
rtl/s32_core.sv:334 MAME's regular System 32 map exposes the communication-board CN and FG flip-flop registers at 0x801000/0x801002.
rtl/s32_core.sv:335 They are byte registers, not open-bus locations: reset reads 0xFE from both, CN stores bit 0, and FG stores bit 0 only while CN is enabled (s32comm.cpp).
rtl/s32_core.sv:354 MAME's I/O mirrors ignore A19:A7 (System 32) or A18:A7 (Multi 32).
rtl/s32_core.sv:707 The sprite engine keeps its own width bit (ctl_latched[6][0]) for sprite-side clipping, exactly MAME's split (games program both consistently).
rtl/s32_core.sv:941 The regular-PCB machine config instantiates S32COMM (MAME segas32_regular_state::device_add_mconfig), so this window behaves as byte-wide RAM even with no link partner: a game that writes then reads the share area must read its own data bac
rtl/s32_core.sv:945 Only D[7:0] is mapped (MAME maps 0x800000-0x800fff share_r/w with umask16 0x00ff); the title-gated Air Rescue 0x810000-0x810fff window reuses the high byte of this physical array for its 16-bit direct-link words.
rtl/s32_core.sv:1067 MAME's s32comm cn_w(0) invokes device_reset(), clearing FG too.
rtl/s32_core.sv:1074 MAME's EPR-14084 simulation starts with an offline link and performs the master handshake over 0xe8 VBLANK ticks.
rtl/s32_core.sv:1126 Multi 32 EEPROM DO is read on the SECOND I/O chip's SERVICE34_B bit 7 (MAME io_chip_1.in_pf = SERVICE34_B, do_read on bit 7); previously io1 got constant 0xff there, so Multi 32 NVRAM boot never converged (audit R23-F1).
rtl/s32_core.sv:1131 cnt1 = screen-B display enable (MAME io_chip_1 out_cnt1 -> display_enable_w<1>).
rtl/s32_core.sv:1509 MAME: map(0xf00000, 0xffffff).rom().region("maincpu", 0) — the top window mirrors the FIRST megabyte (the V60 reset stub at 0xFFFFF0 lives at maincpu offset 0xFFFF0).
rtl/s32_core.sv:1588 MAME returns machine().rand() (full-width, uncorrelated).
rtl/s32_core.sv:1633 MAME s32comm returns 0xFE | CN for CN and 0xFE | FG for FG with the unconnected ZFG held low; only the rest of 0x80xxxx remains open bus.
rtl/s32_core.sv:1635 The descriptor-selected EPR-14084 HLE publishes shared byte 4 after the MAME link timer expires.
rtl/s32_core.sv:1657 Open-bus when this board has no V25 (holo, spidman): MAME leaves 0xA00000 unmapped (audit R20 PF-7).
rtl/s32_core.sv:1667 MSM6253 serial output is wired to D7, not D0 (MAME msm6253 d7_r); audit R20 IO-3.
rtl/s32_pkg.sv:92 MAME mirrors the controller's 2-bit bank selection modulo that physical count.
rtl/video/s32_mixer.sv:9 This module implements MAME mix_all_layers' effective-priority scheme evaluated directly per pixel: - first = topmost non-transparent layer (the winner) - second = the scan continued below the winner (blend partner) - blend = (first*(7-f)
rtl/video/s32_mixer.sv:69 MAME video_start memsets mixer_control to 0xFF: unwritten registers read 0xFFFF, giving priority 0xF.
rtl/video/s32_mixer.sv:122 sprite pixel semantics (MAME mix loop, exactly): transparent when (pix & 0x7fff) == 0x7fff (covers 0xFFFF erase + 0x7FFF) shadow source a: bit15 CLEAR when reg 0x4C bit2 set (RMW shadow sprites) shadow source b: masked pen == sprshadow (0x7
rtl/video/s32_mixer.sv:164 MAME records the unresolved System 24-style hardware theory as a fallback above the backdrop but behind every real pixel; giving it the layer's ordinary programmed priority instead lets a blank NBG cover terrain and sprites.
rtl/video/s32_mixer.sv:188 disabled layers never mix (MAME enablemask) — a disabled layer's line buffer keeps stale pixels, so it must be gated here
rtl/video/s32_mixer.sv:276 backdrop pixel (MAME update_background): per line.
rtl/video/s32_mixer.sv:368 MAME uses the raw pixel-derived group for the per-layer sprite blend mask.
rtl/video/s32_mixer.sv:373 shadow applies when the scan passes the sprite layer's order slot: scan 1 (always): sprite at/above the winner scan 2 (only when the winner has blends): sprite below winner, at/above the partner — MAME's second loop re-evaluates shadow iden
rtl/video/s32_mixer.sv:405 MAME reads mixer control once per frame, after the frame is complete.
rtl/video/s32_mixer.sv:477 pixel pipeline: two palette lookups per pixel, then MAME's 5-bit-domain arithmetic.
rtl/video/s32_mixer.sv:518 This is the standard pal5bit expansion used by MAME: replicate the upper three bits into the low three bits so 5'b11111 becomes 8'hff (not 8'hf8).
rtl/video/s32_mixer.sv:526 MAME applies signed color offsets before blending and clamps only after the weighted sum.
rtl/video/s32_mixer.sv:666 With the bubble a pixel took 13 clk_ram edges from the display-X change — one more than the 12-edge 416-wide pixel period — so the display sampled the previous pixel and the whole 416-wide picture came out one column right of MAME.
rtl/video/s32_mixer.sv:691 Preserve MAME's order: offset, blend, then shadow.
rtl/video/s32_palette.sv:60 Disabled bits therefore remain from each half's own old word (MAME paletteram_w), rather than being copied from the source half.
rtl/video/s32_sprite.sv:74 MAME m_sprite_render_count (0/1)
rtl/video/s32_sprite.sv:115 MAME exposes only selected-buffer bit 0.
rtl/video/s32_sprite.sv:117 MAME reg 0 bit0 = (SPRITES.num < SPRITES_2.num), i.e. the CPU-visible identity of the displayed buffer.
rtl/video/s32_sprite.sv:157 MAME's controller model bounds a frame to the 0x20000-byte sprite RAM divided by one 16-byte command (8192 commands).
rtl/video/s32_sprite.sv:191 MAME controller model uses 16.16 zoom
rtl/video/s32_sprite.sv:194 wide MAME int-domain origin; no 12-bit wrap
rtl/video/s32_sprite.sv:198 The MiSTer SDRAM port is the only part of the Golden Axe sprite path that cannot be reproduced by the cycle-exact MAME/RTL replays.
rtl/video/s32_sprite.sv:219 MAME visits every word even if strong downscale emits no pixel from it.
rtl/video/s32_sprite.sv:241 Scaling setup is not on the pixel-rate path, so share one restoring divider across Y then X. The 25-bit numerators preserve MAME's unsigned 16.16 controller math.
rtl/video/s32_sprite.sv:261 MAME transparency_masks[ctl4 & 3][ctl5 & 3]
rtl/video/s32_sprite.sv:330 MAME never misses because its render is instantaneous.
rtl/video/s32_sprite.sv:350 Automatic mode uses MAME's 0/1 down-counter exactly, including mode changes between 60 Hz and 30 Hz.
rtl/video/s32_sprite.sv:359 audit R20 SP-2: on the 30Hz skip frame MAME leaves m_sprite_control[0] untouched (m_sprite_render_count-- != 0), so a CPU-written manual command still executes.
rtl/video/s32_sprite.sv:508 MAME: bit12 of word0 gates clip-in (words 0-3: y0,y1,x0,x1 sext12); bit13 gates clip-out (words 4-7)
rtl/video/s32_sprite.sv:517 MAME changes clip-out only when bit 13 is set.
rtl/video/s32_sprite.sv:542 MAME uses int arithmetic after sign-extending both 12-bit values.
rtl/video/s32_sprite.sv:595 MAME: entry & (bpp8 ?
rtl/video/s32_sprite.sv:603 Flip reverses the DESTINATION sweep while the source reads forward (hardware/MAME model) — end codes and word transparency track source order regardless of flip.
rtl/video/s32_sprite.sv:637 MAME applies latched controller flip while scanning the displayed sprite framebuffer.
rtl/video/s32_sprite.sv:715 MAME consumes m_spriteram_32bit MSB-first.
rtl/video/s32_sprite.sv:760 MAME clips the trailing xtarget before its source loop.
rtl/video/s32_sprite.sv:773 This keeps end_scan_word out of the 96.6 MHz cache/mux path while preserving MAME's sequential end-code scan.
rtl/video/s32_sprite.sv:858 MAME: first/last pixel of each 32-bit word uses transp (0x0f/0xff, or 0 when opaque); middle pixels use 0.
rtl/video/s32_tilemap.sv:2 System 32 scroll/tilemap engine — 315-5387 (DESIGN.md §6.2, Appendix C) Renders one scanline of each enabled layer into per-layer line buffers: NBG0/1: MAME-exact 12.20 X/Y zoom and fractional scroll ($1FF10-1E, $1FF50-56, 0x200=1.0) NBG2/3
rtl/video/s32_tilemap.sv:61 to the mixers (MAME enablemask, inverted)
rtl/video/s32_tilemap.sv:64 layer enable logic: $1FF02 low bits + $1FF8E second disable set (+ $1FF00 bits 12/13 disable NBG2/NBG3 — MAME update_tilemaps)
rtl/video/s32_tilemap.sv:98 MAME source coordinate/step, 12.20 modulo 2^32
rtl/video/s32_tilemap.sv:105 MAME's update_tilemap_rowscroll (segas32_v.cpp) hoists exactly these out of its inner loop: `xscroll`/`yscroll` and the flip flags are computed once for the layer, and each row resolves its effective source Y and its pair of page pixmaps (`
rtl/video/s32_tilemap.sv:137 NBG0/1 use MAME's exact (0x200 << 20)/zoom calculation on both axes.
rtl/video/s32_tilemap.sv:202 layer clip windows (MAME compute_clipping_extents, per-pixel form): rect i = clips[4i..4i+3] = {min_x[8:0], min_y[7:0], max_x[8:0], max_y[7:0]} (max inclusive); pixel drawn iff !enable | (inside-union ^ clipout)
rtl/video/s32_tilemap.sv:220 Text layer name address: MAME's get_text_tile_info uses the full five-bit page selector $1FF5C[8:4] (<<11 words).
rtl/video/s32_tilemap.sv:289 MAME uses zoom X for both axes unless independent Y zoom is selected by $1FF00 bit 14.
rtl/video/s32_tilemap.sv:292 MAME treats the destination center as signed 9-bit at neutral zoom and signed 10-bit whenever that axis is zoomed.
rtl/video/s32_tilemap.sv:373 V-2 (MAME update_tilemap_zoom): exact 12.20 reciprocal step, with destination zoom floored at 0x80.
rtl/video/s32_tilemap.sv:620 ---- bitmap layer (MAME update_bitmap) ---- 4bpp: 512x512, row = 128 words, y wraps 9 bits 8bpp: 512x256, row = 256 words, y wraps 8 bits color = (reg 0x1FF8C << 4) masked above the pen bits
rtl/video/s32_tilemap.sv:720 Each quotient takes 30 clocks and truncates toward zero exactly like MAME's unsigned integer division.
rtl/video/s32_tilemap_regcap.sv:18 Measured on Spider-Man (MAME 0.289, attract chapter 1): NBG2/NBG3 ($1FF22/$1FF2A) step -7 px/frame and wrap +505 every 73 frames, each wrap accompanied by a page rotation on $1FF48-$1FF4E in the same frame.
rtl/video/s32_vram.sv:143 register file powers up 0 (Cyclone V flops); $1FF00 gets the MAME device_start default.
rtl/video/s32_vram.sv:146 416-wide default (MAME device_start)
README.md:108 | Sega 315-5385 controller | V60 registers, IRQs, timers | [`s32_io.sv`](rtl/io/s32_io.sv); schematics and MAME behaviour |
README.md:115 | SegaSonic control-ball adapter | Three player channels, 12-bit relative X/Y counters, c00040/c00048/c00050-style byte reads and reset writes | [`s32_trackball
README.md:119 | FD1149 DBZ V.R.V.S. protection handler | V60 writes in `0xa00000-0xa7ffff`; work-RAM copy to `0x2080c8` | Descriptor-selected HLE in [`s32_prot.sv`](rtl/prot/
README.md:120 | Air Rescue reduced link/DSP profile | Main CPU 0x810000-0x810fff link RAM, ID 0x818000, DSP registers 0xa00000-0xa00007 | Title-gated FPGA abstraction in rtl/
README.md:132 **MAME developers** - [System 32 behavioural reference](https://github.com/mamedev/mame), including the uPD4701A trackball contract and SegaSonic ROM/input defi
README.md:133 **Air Rescue implementation evidence** - Pinned MAME System 32 map and DSP handler: https://github.com/mamedev/mame/blob/mame0282/src/mame/sega/segas32.cpp and
README.md:156 Intel Quartus, Verilator, Icarus Verilog, ModelSim, and MAME tool authors.
README.md:186 Place the required MAME ROM ZIPs in `/media/fat/games/mame/`, then launch a game from the MiSTer Arcade menu.

Says it matches, follows or was checked against MAME — 8

rtl/audio/s32_rf5c68.sv:213 sample[7]=1 is positive; sample[7]=0 is negative, matching MAME's RF5C68 sign/magnitude convention.
rtl/cpu/v60/s32_v60.sv:17 - Single-precision FP (0x5C/0x5F: CMPF/MOVFS/NEGFS/ABSFS/SCLFS/ADDFS/SUBFS/ MULFS/DIVFS/CVTWS/CVTSW): a binary32 unit (round-to-nearest-even, gradual underflow) matching MAME's host-float contract; no System 32 game uses it.
rtl/cpu/v60/s32_v60.sv:2972 Equal AND matches the stop byte: MAME clears CY and breaks; S/Z stay 0 (i != dest), R28/R27 at the current index.
rtl/cpu/v60/s32_v60.sv:4824 1 <= count <= width: exact MAME SHIFTLEFT_OV mask (count==width uses the full-width mask, matching MAME's count==bitsize case, e.g. SHA.B #8,-1 -> OV=0)
rtl/io/s32_io.sv:30 Matches MAME 315_5296.cpp read()/write() in MAME's 315_5296 device.
rtl/s32_core.sv:705 TM-1: CRT/tilemap screen-width authority is VRAM $1FF00 bit 15, matching MAME screen_update_system32 / multi32_update, which set the visible area to 52*8 (416) when that bit is set and 40*8 (320) otherwise.
rtl/s32_core.sv:1164 Power up at bank 0 to match MAME device_start (m_analog_bank = 0); System 32 analog games never write 0xC00060 so it would otherwise stay X in simulation and undefined at cold boot (audit R20 IO-15).
rtl/video/s32_sprite.sv:699 Repack each pair to the same byte layout as a sprite-ROM burst (matching the 315-5386/MAME controller model).

Keeps a MAME approximation — 1

rtl/video/s32_mixer.sv:160 MAME guesses sprites above every fixed layer; the Rad Mobile observation places them between NBG0 and NBG1, while Alien 3 and Sonic need that tie flipped.

Shares text with the MAME driver without saying so — 7

rtl/io/s32_io.sv:916 MAME device_reset (memset(m_v60_irq_control,0xff)) leaves the pending — shares text with sega/segas32.cpp:666
rtl/mem/s32_rom_loader.sv:91 descrambled[dst] = raw[bitswap(dst, 14,11,15,12,13,4,3,7, — shares text with sega/segas32_m.cpp:48
rtl/mem/s32_rom_loader.sv:92 5,10,2,8,9,6,1,0)] — shares text with sega/segas32_m.cpp:48
rtl/prot/s32_prot.sv:544 ga2: "wake up! GOLDEN AXE The Revenge of Death-Adder! " — shares text with sega/segas32_m.cpp:73
rtl/s32_core.sv:1164 Power up at bank 0 to match MAME device_start (m_analog_bank = 0); — shares text with sega/segas32.cpp:657
rtl/s32_core.sv:1509 MAME: map(0xf00000, 0xffffff).rom().region("maincpu", 0) — the top window — shares text with sega/segas32.cpp:1172
rtl/video/s32_tilemap.sv:526 bgcharlayout x-offsets {0,4,16,20,8,12,24,28,...}: column -> — shares text with sega/segas32.cpp:2225

Arcade-SegaSystem32Multi#
Hard Dunk, OutRunners, Stadium Cross, Title Fight
meathax/s32multi @ 02942d4e
MAME compared: sega/segas32.cpp + 7 related file(s)
Read: 25 HDL files, 16,508 lines (Quartus project)

MeatCores
independent database

Mostly MAME

medium

89%

Statements: 5 toward hardware, 239 toward MAME

Cites hardware documentation that MAME's driver does not — 4

README.md:59 | Scroll hardware | Sega schematics, sheet 2; Sega 315-5387 | Four tilemap layers and dual-port VRAM in [`s32_tilemap.sv`](rtl/video/s32_tilemap.sv) |
README.md:61 | Colour/video output | Sega schematics, sheet 5; [315-5242 silicon evidence](https://github.com/furrtek/SiliconRE/tree/master/Sega/315-5242) | Palette, priorit
README.md:62 | I/O, EEPROM, and OutRunners wheel vibration | Sega schematics, sheet 6; [OutRunners service manual](https://www.arcade-museum.com/manuals-videogames/O/Out-Run
README.md:104 **Sega, Nemesis1207, and System 32 researchers** - original hardware and public schematic material.

Says it was checked on “real hardware” — 1

rtl/video/s32_mixer.sv:23 Shadow/blank on real silicon is output-enable gating into an analog resistor network (BEXU/BUBU signals), not a digital halving; MAME's `>>1` shadow model is a software abstraction of that already validated against real hardware over decade

Cites MAME source — 224

Arcade-SegaSystem32Multi.sv:305 This is a model-consistency fix, not a turbo: the alternative consistent choice (both sides at 16.108 MHz) was measured to make Dark Edge's gameplay countdown advance every 70 frames against MAME's 35.
Arcade-SegaSystem32Multi.sv:519 GA2's 315-5296 player ports follow MAME: {left,right,up,down,unused,button3,button2,button1}, active low.
Arcade-SegaSystem32Multi.sv:534 The 24-count dead zone is below the MAME joystick's normal digital threshold and avoids centre jitter.
Arcade-SegaSystem32Multi.sv:625 MAME's Attack and Brake inputs are active low while Wheelie is active high; map them to MiSTer's A/B/X buttons without touching the unused port bits.
Arcade-SegaSystem32Multi.sv:651 Stadium Cross has three cabinet buttons in MAME (Attack/Wheelie/Brake), while MiSTer also exposes an assignable digital accelerator and the two handlebar pitch buttons above.
Arcade-SegaSystem32Multi.sv:674 OutRunners routes PLAYER 1's music keys through the P2_A port (MAME INPUT_PORTS_START(orunners): P2_A bit0 = P1 DJ/music, bit1 = P1 track <<, bit2 = P1 track >>).
Arcade-SegaSystem32Multi.sv:733 OutRunners is a two-cockpit cabinet: P2 gets its own wheel/pedal set on the second joystick's analog axes, read through the ADC's bank-1 slots (segas32.cpp in2_analog_read/in3_analog_read select m_analog_ports[bank*4+2/3] -- see the s32_msm
Arcade-SegaSystem32Multi.sv:776 MAME system32_generic: port C is unused; port E/SERVICE12 is {unknown[7:6], start2, start1, coin2, coin1, test, service}, active low.
Arcade-SegaSystem32Multi.sv:824 GA2's 4-player i8255 port C is MAME EXTRA3 (ppi.in_pc_callback -> "EXTRA3").
Arcade-SegaSystem32Multi.sv:910 Second cockpit (Player 2, joystick_1): P1_B bits 1:0 = P2 shift up/down, P2_B bits 2:0 = P2 DJ/music + track <</>> (MAME INPUT_PORTS_START(orunners) P1_B/P2_B).
Arcade-SegaSystem32Multi.sv:972 Original = the 4:3 arcade monitor (MAME's default for both 320- and 416-wide System 32 modes); the old 13:7 square-pixel ratio stretched holo's 320 mode.
rtl/audio/s32_audio_mix.sv:5 Exact MAME route gains (segas32.cpp): cross-routed YM 0.15 + MultiPCM 0.35, divide by 20.
rtl/audio/s32_multipcm.sv:4 Register, descriptor, pitch and PCM semantics follow MAME multipcm.cpp and gew.cpp (base class gew_pcm_device shared by the GEW family).
rtl/audio/s32_multipcm.sv:5 This revision adds an envelope generator, LFO (vibrato/tremolo) and 12-bit packed-sample playback, all MAME-behavioural: no silicon reverse engineering exists for 315-5560, so every curve below is reconstructed from MAME's gew.cpp/gew.h (en
rtl/audio/s32_multipcm.sv:12 Provenance notes for the tables/logic added in this revision: - Envelope generator: state_t {ATTACK,DECAY1,DECAY2,RELEASE} and the update/calc functions in gew.cpp (envelope_generator_update, envelope_generator_calc, get_rate).
rtl/audio/s32_multipcm.sv:15 BASE_TIMES[64] and the attack/decay-release step-per-sample formulas (envelope_generator_init) are reproduced exactly, evaluated offline for a 44100 Hz-class per-voice update rate (HYPOTHESIS: this design's 224-ce-tick voice cadence, 28 slo
rtl/audio/s32_multipcm.sv:23 - TL table: gew.cpp's per-level dB curve (-24dB over 64 steps) used to build m_left_pan_table/m_right_pan_table, taken as a standalone 128- entry linear gain table (TL_GAIN_ROM) here; the pan attenuation stays the pre-existing shift-based a
rtl/audio/s32_multipcm.sv:27 - LFO: LFO_FREQ[8]/PHASE_SCALE_LIMIT[8]/AMPLITUDE_SCALE_LIMIT[8] and the m_pitch_table/m_amplitude_table piecewise-linear waveform generators in gew.cpp's lfo_init() are reproduced exactly.
rtl/audio/s32_multipcm.sv:29 The depth (vibrato/ tremolo register bits 2:0) to linear-gain conversion is NOT MAME's raw powf()-derived 256-entry-per-depth table (2048 entries would be synthesis-heavy for a 28-voice multiplex); it is re-derived analytically from the sam
rtl/audio/s32_multipcm.sv:39 Both are HYPOTHESIS-labelled approximations of MAME's exact float table, not bit-exact ports.
rtl/audio/s32_multipcm.sv:41 - 12-bit sample fetch: gew.cpp's sound_stream_update() bit layout for format&4 (two 12-bit samples packed into 3 bytes) is reproduced exactly: read_byte(adr)<<8 | (read_byte(adr+1)&0xf)<<4 for the even sample, read_byte(adr+2)<<8 | (read_by
rtl/audio/s32_multipcm.sv:92 s_env_vol is the raw EG_SHIFT=16 fixed-point volume accumulator (0..0x3ff<<16); s_env_gain is the EXP_VOL_ROM-converted linear gain (Q12, matching gew.cpp's m_linear_to_exp_volume) latched once per voice per output-sample tick and consumed
rtl/audio/s32_multipcm.sv:152 The real 315-5560 runs a FIXED 224-clock sample frame (MAME models its stream at clk/224); ROM access is interleaved into that fixed slot schedule and can never stretch it.
rtl/audio/s32_multipcm.sv:219 Envelope-generator rate tables (gew.cpp envelope_generator_init, called as envelope_generator_init(BASE_TIMES, 14.32833)).
rtl/audio/s32_multipcm.sv:220 Values below are BASE_TIMES[64] evaluated through MAME's exact formula step[i] = (0x400<<EG_SHIFT) / (BASE_TIMES[i] * srate/1000) (attack) step[i] = (0x400<<EG_SHIFT) / (BASE_TIMES[i]*14.32833 * srate/1000) (decay/release
rtl/audio/s32_multipcm.sv:229 m_linear_to_exp_volume: gew.cpp builds this as db = -(96 - 96*i/1024); exp_volume = 10^(db/20); table[i]=round(exp_volume*4096) for i = 0..1023, TL_SHIFT=12.
rtl/audio/s32_multipcm.sv:234 TL_GAIN_ROM: gew.cpp's per-level total-level curve, -24dB over 64 steps (i.e. -0.375dB/step), i.e. gain(level) = 10^(level*-24/64/20); stored as a pure Q10 linear gain (1024 = unity) rather than MAME's pan-table-fused form, since this desig
rtl/audio/s32_multipcm.sv:241 LFO_FREQ[8] phase-step-per-voice-tick (gew.cpp lfo_compute_step: step = LFO_FREQ[freq]*256/srate, LFO_SHIFT=8), evaluated for the assumed srate=44100 with 16 extra fractional bits (this design's choice, see s_lfo_phase comment above).
rtl/audio/s32_multipcm.sv:247 PITCH_K_ROM: per-depth linear-in-cents coefficient reproducing gew.cpp's PHASE_SCALE_LIMIT[8]/128 * ln2/1200, Q24 fixed point (see file header LFO provenance note for the approximation this stands in for).
rtl/audio/s32_multipcm.sv:426 MAME update_step: base=(1+pitch/1024), exponent=(signed octave-1).
rtl/audio/s32_multipcm.sv:427 This RTL position uses sixteen fractional bits instead of MAME's TL_SHIFT.
rtl/audio/s32_multipcm.sv:439 gew.cpp envelope_generator_calc: rate = (octave + key_rate_scale)*2 + pitch_bit9, unless key_rate_scale==0xf (key scaling disabled -> rate=0).
rtl/audio/s32_multipcm.sv:462 gew.cpp get_rate(): val==0 -> step[0] (=0, infinite time); val==0xf -> step[0x3f] (fastest); otherwise clamp(4*val+rate_base, 0, 63).
rtl/audio/s32_multipcm.sv:495 gew.cpp lfo_init(): m_pitch_table piecewise-linear triangle, stored as an offset+128 value 1..255 (so it can index a scale table built for i in -128..127); returned here already converted back to a signed -127..127 offset for direct use in
rtl/audio/s32_multipcm.sv:561 MAME uses a 3 dB exponential step, represented here as the exact Q10 table.
rtl/audio/s32_multipcm.sv:567 9..15 attenuate right using MAME's inverted distance.
rtl/audio/s32_multipcm.sv:686 gew.cpp write(): key-off just sets envelope_gen.m_state=RELEASE; the voice keeps playing (s_active stays set) while the release rate ramps m_volume to zero, matching envelope_generator_update()'s RELEASE case which only clears m_playing at
rtl/audio/s32_multipcm.sv:714 multipcm.cpp init_sample(): attack/decay1 in byte 8, decay2/decay_level in byte 9, key_rate_scale/release in byte 10 (release already latched above).
rtl/audio/s32_multipcm.sv:750 gew.cpp retrigger_sample()+envelope_generator_calc: restart the envelope from ATTACK/vol=0 and recompute the key-scaled rate base.
rtl/audio/s32_multipcm.sv:788 12-bit samples (gew.cpp sound_stream_update, format&4): even index -> {byte(adr), nibble(adr+1), 4'b0}; odd index -> {byte(adr+2), nibble(adr+1)[7:4], 4'b0}.
rtl/audio/s32_multipcm.sv:1015 --- Envelope generator: one update per voice per output-sample tick, matching gew.cpp's envelope_generator_update() call cadence.
rtl/audio/s32_soundsys.sv:217 MAME installs the Z80's 0xE000-0xFFFF onto the V60's 0x700000 window with 8-bit handlers on BOTH byte lanes and no umask16, so V60 byte k maps to Z80 0xE000+k (byte granularity, 8 KB mirror).
rtl/audio/s32_soundsys.sv:247 RF5C68 removed: the real Multi 32 board carries one 315-5560 MultiPCM at this window and no RF5C68 (confirmed by physical board photos and MAME's device config).
rtl/audio/s32_soundsys.sv:283 One YM3438: the real Multi 32 board carries a single YM3438 (physical board photos, MAME device config) -- port 0x90-0x9F is unmapped hardware, not a second FM chip.
rtl/audio/s32_soundsys.sv:307 slot 3 = mask reg (MAME: m_sound_irq_control[3])
rtl/audio/s32_soundsys.sv:310 only YM #1 wired (MAME)
rtl/audio/s32_soundsys.sv:372 Stadium Cross drives both MultiPCM bank halves from the same three-bit latch (MAME scross_bank_w).
rtl/audio/s32_soundsys.sv:389 MAME maps D0-D3 mirrored only at D4-D7.
rtl/audio/s32_soundsys.sv:418 multipcm_device::read() always returns 0x00 in MAME -- the real 315-5560 register window is write-only.
rtl/cpu/v60/s32_v60.sv:5 Behavioral contract is MAME's v60 core (BSD-3-Clause, Farfetch'd / R. Belmont): opcode dispatch per optable.hxx, addressing modes per am1-3.hxx, exception entry per v60.cpp.
rtl/cpu/v60/s32_v60.sv:13 the fill/stop variants (MOVC*/CMPC*/SCHC*/SKPC*), TASI, bit ops, GETPSW/UPDPSW, TRAP/TRAPFL/BRK/BRKV, CHLVL, task save/load, privileged register moves (LDPR/STPR), and MAME-defined decimal/bit- string/bit-field groups.
rtl/cpu/v60/s32_v60.sv:20 - Not implemented (reserved-instruction exception, logged in sim): the un-dispatched 0x5C/0x5F sub-opcodes (MAME UNHANDLED).
rtl/cpu/v60/s32_v60.sv:21 MMU/TLB effects are absent like MAME, but CLRTLB still decodes its complete operand.
rtl/cpu/v60/s32_v60.sv:31 V60/V70 reset PC (MAME m_start_pc; audit V60-21)
rtl/cpu/v60/s32_v60.sv:129 PSW fields (MAME bit layout: Z=b0,S=b1,OV=b2,CY=b3,IE=b18,EL=b25:24,IS=b28)
rtl/cpu/v60/s32_v60.sv:682 C-style truncating divide-by-8 of a signed bit offset (MAME bamoffset/8)
rtl/cpu/v60/s32_v60.sv:772 stack switch on IS change, or EL change while IS=0 (MAME v60WritePSW)
rtl/cpu/v60/s32_v60.sv:1015 dim 3 = qword (MOVD): the V60 steps autoincrement/ autodecrement by the full 8-byte operand (MAME v60 m_moddim==3).
rtl/cpu/v60/s32_v60.sv:1212 primary dispatch (per MAME optable.hxx)
rtl/cpu/v60/s32_v60.sv:1217 BRK — MAME skips this opcode (A4)
rtl/cpu/v60/s32_v60.sv:1237 ---- Bcc disp8 (0x60-0x6a,0x6c-0x6f) / disp16 equivalent ---- 0x6B/0x7B are holes in MAME's authoritative primary dispatch table, not branch-condition encodings.
rtl/cpu/v60/s32_v60.sv:1297 MAME opDBcc: reg ALWAYS decrements; branch iff cond true and decremented reg != 0.
rtl/cpu/v60/s32_v60.sv:1403 JMP/JSR/TASI: MAME sets moddim=0 — the dim scales INDEXED modes' index register, and ga2's jump tables (3-byte BR entries, `JMP [PC+d](rN)`) rely on the unscaled index (found by real-ROM boot: dim=2 quadrupled the index and jumped mid-table
rtl/cpu/v60/s32_v60.sv:1429 RETI adj (halfword, MAME moddim=1)
rtl/cpu/v60/s32_v60.sv:1453 MAME F7a/F7b decode with dim 0 (0x58 byte) / 1 (0x5A half): autoincrement/indexed AMs step and scale by the element size, and F7b immediates size accordingly — not dword.
rtl/cpu/v60/s32_v60.sv:1473 MAME implements ADDDC/SUBDC/SUBRDC/CVTDPZ/CVTDZP (radm timer); remaining subops are reserved there too.
rtl/cpu/v60/s32_v60.sv:1562 Unhandled sub-opcodes still take the reserved-instruction vector exactly as MAME's op5C/op5F UNHANDLED entries fatalerror.
rtl/cpu/v60/s32_v60.sv:1604 RSR (A9): pop PC ONLY (MAME opRSR: PC=[SP]; SP+=4)
rtl/cpu/v60/s32_v60.sv:1609 MAME/NEC floating-exception test: enabled TKCW causes are intersected with the PSW floating-status field.
rtl/cpu/v60/s32_v60.sv:1638 F12: plan operands per instflags (MAME F12DecodeOperands)
rtl/cpu/v60/s32_v60.sv:1647 MOVEA takes op1 as an ADDRESS (MAME ReadAMAddress) — decoding it as a value loaded SP with a byte read instead of the EA and sent ga2's boot stub off a cliff (found by real-ROM boot)
rtl/cpu/v60/s32_v60.sv:1756 The generic value path left flag1=0, so exec's memory-source branch dereferenced R0's VALUE as the qword address; OutRunners' boot RAM-clear (`mov.d R0,[R10+]` at 0x5AE, R0=0) then copied the reset-vector instruction bytes over 0x20E000+ in
rtl/cpu/v60/s32_v60.sv:2290 MAME opDIVX/opDIVUX set only S/Z and leave OV unchanged; do not clear it.
rtl/cpu/v60/s32_v60.sv:2322 MAME opROTC*: the carry bit enters the active operand's LSB; bits above a byte/halfword operand are not part of the ring.
rtl/cpu/v60/s32_v60.sv:2609 pops (8) + frame-destroy operand (MAME: SP += amout), then the PSW write may bank-switch SP — order matters: adjust THEN switch.
rtl/cpu/v60/s32_v60.sv:2651 push highest set register first (MAME pushes from r31 down?
rtl/cpu/v60/s32_v60.sv:2699 TASI sets flags as SUBB(old, 0xFF, 0) before writing 0xFF (MAME opTASI).
rtl/cpu/v60/s32_v60.sv:2736 R27 (dst) / R28 (src) updated at completion (MAME MOVSTR).
rtl/cpu/v60/s32_v60.sv:2745 Element-size dim for both (MAME dim 0 byte / 1 half — see decode).
rtl/cpu/v60/s32_v60.sv:2762 V60-15: down-direction search (subop[0]=1, MAME opSEARCHD*).
rtl/cpu/v60/s32_v60.sv:2764 The down form scans the range in descending order from MAME's start index: byte reads op1+len1 down to op1 (len1+1 reads; the first read is one past the buffer, exactly as opSEARCHDB does), half reads op1+(len1-1)*2 down to op1 (len1 reads)
rtl/cpu/v60/s32_v60.sv:2789 MOVCD/MOVCFD (down copy) transfers the ascending range base..base+min-1 in descending element order (MAME opMOVSTRD): start at the TOP of that range and decrement, instead of walking physically below the base as the old code did (audit R20
rtl/cpu/v60/s32_v60.sv:2798 CMPCS (0x02): stop mode starts with CY=1, cleared when a fill (R26) byte is met in the compare (MAME opCMPSTR bStop).
rtl/cpu/v60/s32_v60.sv:2801 CMPCF (0x01): fill the SHORTER operand's tail with R26 BEFORE the compare (MAME bFill); MOVC fill happens AFTER the copy.
rtl/cpu/v60/s32_v60.sv:2830 Down exhaustion: the scan ran off the bottom to i=-1 (MAME opSEARCHD*), so Z=0, R27=0xFFFFFFFF, and str_src has already reached op1-step.
rtl/cpu/v60/s32_v60.sv:2845 CMPC exhausted the common prefix (all min elements equal): R28=len1+min*step, R27=len2+min*step, and S/Z from the length compare (MAME opCMPSTR tail).
rtl/cpu/v60/s32_v60.sv:2880 Z follows MAME's post-loop test i==len1: up never breaks at i==len1 (Z=0), down does so only at its one-past-the-top byte read (str_cnt==len1+1).
rtl/cpu/v60/s32_v60.sv:2919 CMPC (MAME opCMPSTR): compare source(op1) vs dest(op2).
rtl/cpu/v60/s32_v60.sv:3178 BAM: bit addressing modes for the 0x5B/0x5D groups (MAME BAMTable1/2 implemented subset — everything MAME fatalerrors on traps here too).
rtl/cpu/v60/s32_v60.sv:3652 exception / interrupt entry (MAME v60_do_irq): switch to interrupt context, push old PSW, push PC, PC = vector
rtl/cpu/v60/s32_v60.sv:3887 per-opcode dim helpers (operand sizes per MAME op12 handlers)
rtl/cpu/v60/s32_v60.sv:3889 F12 ops whose FIRST operand is an effective address, not a value (MAME F12DecodeFirstOperand(ReadAMAddress, ...)): MOVEA and IN
rtl/cpu/v60/s32_v60.sv:3910 NOTE: ROTH (8b) / ROTCH (9b) must NOT appear here — their op1 is the rotate COUNT, a byte (MAME ReadAM dim 0); listing them in the half group made `ROT.H #imm8, r6` decode one byte long and holo's EEPROM write loop entered mid-instruction (
rtl/cpu/v60/s32_v60.sv:3948 These read op2 as a VALUE (MAME ReadAM), so a memory operand must be loaded into op2val before exec; otherwise the exec fell back to the effective address / a stale op2val (audit R20 V60-18).
rtl/cpu/v60/s32_v60.sv:4034 MOVC completion (MAME opMOVSTRU*/opMOVSTRD*): publish R28/R27 for the final element index `idx`, and — for the fill variants (MOVCFU/MOVCFD) with the source shorter than the destination — kick off the R26 tail-fill phase.
rtl/cpu/v60/s32_v60.sv:4057 MAME pads the destination tail elements [idx, lenop2) with R26; the down form uses op2+dest+(lenop2-j-1) for bytes and op2+(lenop2-j-1)*2 for halves.
rtl/cpu/v60/s32_v60.sv:4138 MAME MOV sets no flags?
rtl/cpu/v60/s32_v60.sv:4259 A zero count must clear CY (MAME); the old code left it unchanged (audit R20 V60-7).
rtl/cpu/v60/s32_v60.sv:4286 MAME defines CY from the post-rotate wrap bit: LSB after a positive (left) rotate, MSB after a negative (right) rotate.
rtl/cpu/v60/s32_v60.sv:4297 MAME clears CY for a zero count; nonzero counts retain the final shifted-out bit, so only bypass the iterative state for zero.
rtl/cpu/v60/s32_v60.sv:4358 MAME divide-by-zero: destination unchanged and no trap, but Z/S are still set from the (unchanged) destination = the dividend, and OV is cleared (audit R20 V60-8); the old code left flags stale.
rtl/cpu/v60/s32_v60.sv:4391 MAME sets OV and leaves the destination unchanged (audit R20 V60-8); the old code always cleared OV and wrote the wrapped quotient.
rtl/cpu/v60/s32_v60.sv:4409 MAME opMULX/opMULUX leave OV unchanged
rtl/cpu/v60/s32_v60.sv:4425 MAME: no zero-divide trap
rtl/cpu/v60/s32_v60.sv:4497 MAME opCALL: SP-=4; [SP]=AP; AP=op2; SP-=4; [SP]=retPC; PC=op1.
rtl/cpu/v60/s32_v60.sv:4534 MAME opTRAP: the operand's HIGH nibble is a Bcc-encoded condition (cond 0xB never traps); only trap when it evaluates true, else fall through.
rtl/cpu/v60/s32_v60.sv:4784 SHA left-shift overflow (MAME SHIFTLEFT_OV op12.hxx): OV is set when the top `count` bits of the width-sized value are not all equal to the sign bit — i.e. a bit different from the sign is shifted out through the top.
rtl/cpu/v60/s32_v60.sv:4786 MAME masks exactly `count` bits (((1<<count)-1) << (bitsize-count)); using count+1 here spuriously set OV (e.g. SHA.B #1,0x40 gave OV=1 vs MAME OV=0), misbranching a following signed Bcc (S^OV).
rtl/cpu/v60/s32_v60.sv:4797 count > width: MAME's macro is UB here (bitsize-count<0); any nonzero value overflowed
rtl/cpu/v60/s32_v60.sv:4873 MAME opMUL/opMULU: OV = (product >> width) != 0 on the product's unsigned bit pattern (signed product for MUL, unsigned for MULU).
rtl/cpu/v60/s32_v60.sv:4875 For byte/half MAME shifts the 32-bit value; for word, the 64-bit one.
rtl/cpu/v60/s32_v60.sv:4898 MAME clears OV for REM/REMU (audit R20 V60-8)
rtl/cpu/v60/s32_v60.sv:4907 Behavioral contract is MAME op2.hxx/op5.hxx, which use host `float` — round-to-nearest-even, with gradual underflow (subnormals) and IEEE special values.
rtl/cpu/v60/s32_v60.sv:4923 NEGFS/ABSFS are NOT: MAME does ReadAMAddress + store only (no load) — they operate on op1 and must not read a possibly read-sensitive destination.
rtl/cpu/v60/s32_v60.sv:5099 Deliberate divergence from the pinned MAME for |n| > 30: MAME computes `appf * / (1 << n)` with the host's shift-count masking (&31, and 1 << 31 = INT_MIN there), so e.g. SCLFS(31) flips the sign and SCLFS(32) is a no-op on x86.
rtl/cpu/v60/s32_v60.sv:5156 Pinned MAME converts (uint32_t)(int64_t)val on its x86 host: NaN and out-of-int64-range saturate the hardware convert to INT64_MIN, whose low 32 bits are 0.
rtl/cpu/v60/s32_v60.sv:5179 MAME stores the LOW 32 BITS of the int64 truncation, not a clamp: well-defined in C for e in [31,62]; e >= 63 saturates the x86 convert to INT64_MIN (low 32 = 0).
rtl/cpu/v60/s32_v60.sv:5190 (MAME: (_S && val>=0) || (!_S && val<=-1); |val| >= 1 here).
rtl/cpu/v60/s32_v60.sv:5305 MAME materializes the subtraction: same-signed infinities give inf-inf = NaN, so they compare Z=0/S=0 like unordered operands.
rtl/io/s32_io.sv:51 MAME device_reset: m_cnt = 0
rtl/io/s32_io.sv:52 MAME device_reset: m_dir = 0
rtl/io/s32_io.sv:56 Ports A-H = 0-7, CNT = 0xE, direction = 0xF (per MAME map).
rtl/io/s32_io.sv:539 MAME WAIT_FOR_COMPLETION: CS ends it
rtl/io/s32_io.sv:571 MAME's d7_r returns shift_register[7] before applying the side-effecting left shift.
rtl/io/s32_io.sv:607 MAME interrupt_control_16_w: BOTH byte lanes are registers — even byte -> ctl[offset*2], odd byte -> ctl[offset*2+1] (ga2 programs vectors 0..4, the ack reg 7, and the timer highs 9/11 on both lanes; found by real-ROM boot: dropped acks mad
rtl/io/s32_io.sv:669 MAME device_reset (memset(m_v60_irq_control,0xff)) leaves the pending byte (index 7) = 0xff -> all 5 sources pending, but ctl[6]=0xff below masks them so no IRQ is delivered until the game unmasks.
rtl/io/s32_io.sv:681 MAME/device-reset contract: the complete 16-byte register file starts at FF.
rtl/io/s32_io.sv:732 n == 0: MAME only re-arms `if (duration)` — the write stores the register byte and leaves an in-flight one-shot running.
rtl/io/s32_io.sv:741 MAME/hardware: 0x100*N ticks at exactly 50 MHz/16.
rtl/io/s32_io.sv:748 n == 0: register write only, armed one-shot keeps running (MAME parity — see timer 0 above).
rtl/io/s32_io.sv:756 MAME int_control_r/hardware-visible readback
rtl/mem/s32_fb_if.sv:6 Services (per DESIGN.md): - erase_line(y): fill line with 0xFFFF - write_run(...): pixel run writes from the sprite renderer; wr_shadow runs RMW dest &= 0x7fff instead (MAME shadow sprites clear framebuffer bit 15) - read_line(y):
rtl/s32_core.sv:12 In a captured pre-fix Dark Edge build, running both sides from ce_cpu made its displayed gameplay countdown advance every 70 frames instead of MAME's measured 35-frame writes to 0x20a112 at PC 0x087080, consistent with alternate VBlank work
rtl/s32_core.sv:282 IS_V70=1: the real chip is a NEC D70632R-20 (V70), confirmed by physical board marking and MAME device config, not a V60.
rtl/s32_core.sv:288 MAME reset PC (audit R20 V60-21)
rtl/s32_core.sv:318 MAME's regular System 32 map exposes the communication-board CN and FG flip-flop registers at 0x801000/0x801002.
rtl/s32_core.sv:319 They are byte registers, not open-bus locations: reset reads 0xFE from both, CN stores bit 0, and FG stores bit 0 only while CN is enabled (s32comm.cpp).
rtl/s32_core.sv:327 MAME's I/O mirrors ignore A19:A7 (System 32) or A18:A7 (Multi 32).
rtl/s32_core.sv:361 OutRunners uses neither -- MAME's init_orunners() installs no protection -- so port B is tied inactive rather than carried as dead arbitration logic.
rtl/s32_core.sv:670 The sprite engine keeps its own width bit (ctl_latched[6][0]) for sprite-side clipping, exactly MAME's split (games program both consistently).
rtl/s32_core.sv:945 The regular-PCB machine config instantiates S32COMM (MAME segas32_regular_state::device_add_mconfig), so this window behaves as byte-wide RAM even with no link partner: a game that writes then reads the share area must read its own data bac
rtl/s32_core.sv:949 Only D[7:0] is mapped (MAME maps 0x800000-0x800fff share_r/w with umask16 0x00ff); the cn/fg link registers at 0x801000/2 retain their disconnected-link status semantics, and the rest of the 0x80xxxx page reads link-not-connected (0xFFFF).
rtl/s32_core.sv:989 MAME's s32comm cn_w(0) invokes device_reset(), clearing FG too.
rtl/s32_core.sv:1015 MAME wires DO to bit 7 of BOTH SERVICE34_A and SERVICE34_B on Multi 32 (segas32.cpp INPUT_PORTS_START(system32_generic)'s SERVICE34_A base definition is inherited unmodified by multi32_generic, and SERVICE34_B carries its own identical do_r
rtl/s32_core.sv:1032 Multi 32 EEPROM DO is read on the SECOND I/O chip's SERVICE34_B bit 7 (MAME io_chip_1.in_pf = SERVICE34_B, do_read on bit 7); previously io1 got constant 0xff there, so Multi 32 NVRAM boot never converged (audit R23-F1).
rtl/s32_core.sv:1037 cnt1 = screen-B display enable (MAME io_chip_1 out_cnt1 -> display_enable_w<1>).
rtl/s32_core.sv:1080 MAME wires only ADC channels 2/3 through the 4053 bank mux (sega_multi32_analog_state::in2_analog_read/in3_analog_read, m_analog_ports[bank*4+2/3]); channels 0/1 are fixed to ANALOG1/ANALOG2 (adc.set_input_tag<0/1>) regardless of bank.
rtl/s32_core.sv:1124 OutRunners is unprotected hardware (MAME's init_orunners() installs no protection responder) and Multi 32 has no V25 MCU (that chip is exclusive to Golden Axe: Revenge of Death Adder / Arabian Fight's standard-board revision).
rtl/s32_core.sv:1214 MAME: map(0xf00000, 0xffffff).rom().region("maincpu", 0) — the top window mirrors the FIRST megabyte (the V60 reset stub at 0xFFFFF0 lives at maincpu offset 0xFFFF0).
rtl/s32_core.sv:1293 MAME returns machine().rand() (full-width, uncorrelated).
rtl/s32_core.sv:1336 MAME s32comm returns 0xFE | CN for CN and 0xFE | FG for FG with the unconnected ZFG held low; only the rest of 0x80xxxx remains open bus.
rtl/s32_core.sv:1354 0xA00000-0xAFFFFF (V25/protection window) is open-bus: OutRunners has neither (MAME leaves this range unmapped, audit R20 PF-7).
rtl/s32_core.sv:1361 MSM6253 serial output is wired to D7, not D0 (MAME msm6253 d7_r); audit R20 IO-3.
rtl/s32_pkg.sv:92 MAME mirrors the controller's 2-bit bank selection modulo that physical count.
rtl/video/s32_mixer.sv:9 This module implements MAME mix_all_layers' effective-priority scheme evaluated directly per pixel: - first = topmost non-transparent layer (the winner) - second = the scan continued below the winner (blend partner) - blend = (first*(7-f)
rtl/video/s32_mixer.sv:23 Shadow/blank on real silicon is output-enable gating into an analog resistor network (BEXU/BUBU signals), not a digital halving; MAME's `>>1` shadow model is a software abstraction of that already validated against real hardware over decade
rtl/video/s32_mixer.sv:29 That is a board-to-connector question the M71064 Verilog itself cannot answer (its internal R/G naming is self-consistent either way) and MAME's channel order -- which this mixer follows -- is the higher-confidence source absent a real-hard
rtl/video/s32_mixer.sv:84 MAME video_start memsets mixer_control to 0xFF: unwritten registers read 0xFFFF, giving priority 0xF.
rtl/video/s32_mixer.sv:137 sprite pixel semantics (MAME mix loop, exactly): transparent when (pix & 0x7fff) == 0x7fff (covers 0xFFFF erase + 0x7FFF) shadow source a: bit15 CLEAR when reg 0x4C bit2 set (RMW shadow sprites) shadow source b: masked pen == sprshadow (0x7
rtl/video/s32_mixer.sv:168 A layer pixel is a mix candidate only when drawn (bit13, "opaque") and its layer's programmed priority is nonzero — plain MAME mix_all_layers semantics.
rtl/video/s32_mixer.sv:188 disabled layers never mix (MAME enablemask) — a disabled layer's line buffer keeps stale pixels, so it must be gated here
rtl/video/s32_mixer.sv:271 backdrop pixel (MAME update_background): per line.
rtl/video/s32_mixer.sv:363 MAME uses the raw pixel-derived group for the per-layer sprite blend mask.
rtl/video/s32_mixer.sv:368 shadow applies when the scan passes the sprite layer's order slot: scan 1 (always): sprite at/above the winner scan 2 (only when the winner has blends): sprite below winner, at/above the partner — MAME's second loop re-evaluates shadow iden
rtl/video/s32_mixer.sv:400 MAME reads mixer control once per frame, after the frame is complete.
rtl/video/s32_mixer.sv:472 pixel pipeline: two palette lookups per pixel, then MAME's 5-bit-domain arithmetic.
rtl/video/s32_mixer.sv:513 This is the standard pal5bit expansion used by MAME: replicate the upper three bits into the low three bits so 5'b11111 becomes 8'hff (not 8'hf8).
rtl/video/s32_mixer.sv:521 MAME applies signed color offsets before blending and clamps only after the weighted sum.
rtl/video/s32_mixer.sv:661 With the bubble a pixel took 13 clk_ram edges from the display-X change — one more than the 12-edge 416-wide pixel period — so the display sampled the previous pixel and the whole 416-wide picture came out one column right of MAME.
rtl/video/s32_mixer.sv:686 Preserve MAME's order: offset, blend, then shadow.
rtl/video/s32_palette.sv:60 Disabled bits therefore remain from each half's own old word (MAME paletteram_w), rather than being copied from the source half.
rtl/video/s32_splitscreen_composer.sv:34 Still no MAME/Verilator differential regression on the full core with Splitscreen enabled, and no hardware verification.
rtl/video/s32_sprite.sv:79 MAME m_sprite_render_count (0/1)
rtl/video/s32_sprite.sv:120 MAME exposes only selected-buffer bit 0.
rtl/video/s32_sprite.sv:122 MAME reg 0 bit0 = (SPRITES.num < SPRITES_2.num): reads 1 at power-up (6<8) and toggles to 0 after the first swap — the exact complement of the internal displaying-buffer selector, which resets to 0 and reads 1 after the first swap.
rtl/video/s32_sprite.sv:163 MAME's controller model bounds a frame to the 0x20000-byte sprite RAM divided by one 16-byte command (8192 commands).
rtl/video/s32_sprite.sv:197 MAME controller model uses 16.16 zoom
rtl/video/s32_sprite.sv:200 wide MAME int-domain origin; no 12-bit wrap
rtl/video/s32_sprite.sv:204 The MiSTer SDRAM port is the only part of the Golden Axe sprite path that cannot be reproduced by the cycle-exact MAME/RTL replays.
rtl/video/s32_sprite.sv:225 MAME visits every word even if strong downscale emits no pixel from it.
rtl/video/s32_sprite.sv:247 Scaling setup is not on the pixel-rate path, so share one restoring divider across Y then X. The 25-bit numerators preserve MAME's unsigned 16.16 controller math.
rtl/video/s32_sprite.sv:267 MAME transparency_masks[ctl4 & 3][ctl5 & 3]
rtl/video/s32_sprite.sv:336 MAME never misses because its render is instantaneous.
rtl/video/s32_sprite.sv:364 Automatic mode uses MAME's 0/1 down-counter exactly, including mode changes between 60 Hz and 30 Hz.
rtl/video/s32_sprite.sv:373 audit R20 SP-2: on the 30Hz skip frame MAME leaves m_sprite_control[0] untouched (m_sprite_render_count-- != 0), so a CPU-written manual command still executes.
rtl/video/s32_sprite.sv:519 MAME: bit12 of word0 gates clip-in (words 0-3: y0,y1,x0,x1 sext12); bit13 gates clip-out (words 4-7)
rtl/video/s32_sprite.sv:528 MAME changes clip-out only when bit 13 is set.
rtl/video/s32_sprite.sv:553 MAME uses int arithmetic after sign-extending both 12-bit values.
rtl/video/s32_sprite.sv:606 MAME: entry & (bpp8 ?
rtl/video/s32_sprite.sv:614 Flip reverses the DESTINATION sweep while the source reads forward (hardware/MAME model) — end codes and word transparency track source order regardless of flip.
rtl/video/s32_sprite.sv:648 MAME applies latched controller flip while scanning the displayed sprite framebuffer.
rtl/video/s32_sprite.sv:726 MAME consumes m_spriteram_32bit MSB-first.
rtl/video/s32_sprite.sv:771 MAME clips the trailing xtarget before its source loop.
rtl/video/s32_sprite.sv:784 This keeps end_scan_word out of the 96.6 MHz cache/mux path while preserving MAME's sequential end-code scan.
rtl/video/s32_sprite.sv:871 MAME: first/last pixel of each 32-bit word uses transp (0x0f/0xff, or 0 when opaque); middle pixels use 0.
rtl/video/s32_tilemap.sv:2 System 32 scroll/tilemap engine — 315-5387 (DESIGN.md §6.2, Appendix C) Renders one scanline of each enabled layer into per-layer line buffers: NBG0/1: MAME-exact 12.20 X/Y zoom and fractional scroll ($1FF10-1E, $1FF50-56, 0x200=1.0) NBG2/3
rtl/video/s32_tilemap.sv:63 to the mixers (MAME enablemask, inverted)
rtl/video/s32_tilemap.sv:66 layer enable logic: $1FF02 low bits + $1FF8E second disable set (+ $1FF00 bits 12/13 disable NBG2/NBG3 — MAME update_tilemaps)
rtl/video/s32_tilemap.sv:100 MAME source coordinate/step, 12.20 modulo 2^32
rtl/video/s32_tilemap.sv:111 MAME's update_tilemap_rowscroll (segas32_v.cpp) hoists exactly these out of its inner loop: `xscroll`/`yscroll` and the flip flags are computed once for the layer, and each row resolves its effective source Y and its pair of page pixmaps (`
rtl/video/s32_tilemap.sv:143 NBG0/1 use MAME's exact (0x200 << 20)/zoom calculation on both axes.
rtl/video/s32_tilemap.sv:208 layer clip windows (MAME compute_clipping_extents, per-pixel form): rect i = clips[4i..4i+3] = {min_x[8:0], min_y[7:0], max_x[8:0], max_y[7:0]} (max inclusive); pixel drawn iff !enable | (inside-union ^ clipout)
rtl/video/s32_tilemap.sv:242 Text layer name address: MAME's get_text_tile_info uses the full five-bit page selector $1FF5C[8:4] (<<11 words).
rtl/video/s32_tilemap.sv:349 MAME uses zoom X for both axes unless independent Y zoom is selected by $1FF00 bit 14.
rtl/video/s32_tilemap.sv:352 MAME treats the destination center as signed 9-bit at neutral zoom and signed 10-bit whenever that axis is zoomed.
rtl/video/s32_tilemap.sv:433 V-2 (MAME update_tilemap_zoom): exact 12.20 reciprocal step, with destination zoom floored at 0x80.
rtl/video/s32_tilemap.sv:575 MAME 0.289 keeps that reading permanently disabled, and Title Fight proves it on hardware: the game holds $1FF8E=$0C00 while the ring floor is the per-line backdrop; an opaque NBG2/NBG3 pen 0 would bury the floor under CRAM[$1800]=black (re
rtl/video/s32_tilemap.sv:676 ---- bitmap layer (MAME update_bitmap) ---- 4bpp: 512x512, row = 128 words, y wraps 9 bits 8bpp: 512x256, row = 256 words, y wraps 8 bits color = (reg 0x1FF8C << 4) masked above the pen bits
rtl/video/s32_tilemap.sv:776 Each quotient takes 30 clocks and truncates toward zero exactly like MAME's unsigned integer division.
rtl/video/s32_vram.sv:143 register file powers up 0 (Cyclone V flops); $1FF00 gets the MAME device_start default.
rtl/video/s32_vram.sv:146 416-wide default (MAME device_start)
README.md:70 **OutRunners (World):** MAME set `orunners`
README.md:71 **OutRunners (US):** MAME set `orunnersu`, parent `orunners`
README.md:72 **OutRunners (Japan):** MAME set `orunnersj`, parent `orunners`
README.md:73 **Title Fight (World):** MAME set `titlef`
README.md:74 **Title Fight (US):** MAME set `titlefu`, parent `titlef`
README.md:75 **Title Fight (Japan):** MAME set `titlefj`, parent `titlef`
README.md:76 **Hard Dunk (World):** MAME set `harddunk`
README.md:77 **Hard Dunk (Japan):** MAME set `harddunkj`, parent `harddunk`
README.md:78 **Stadium Cross (World):** MAME set `scross`
README.md:79 **Stadium Cross (US):** MAME set `scrossu`, parent `scross`
README.md:106 **MAME developers** - [System 32/Multi 32 behavioural reference](https://github.com/mamedev/mame).
README.md:117 Intel Quartus, Verilator, Icarus Verilog, ModelSim, and MAME tool authors.
README.md:134 Place the required MAME ROM ZIPs in `/media/fat/games/mame/`, then launch a game from the MiSTer Arcade menu.

Says it matches, follows or was checked against MAME — 10

Arcade-SegaSystem32Multi.sv:591 p_dig4 matches the MAME byte layout exactly: buttons 1..4 occupy bits 0..3 and the 8-way directions occupy bits 4..7.
Arcade-SegaSystem32Multi.sv:766 Channel layout matches MAME's fixed ANALOG1/2 + banked ANALOG3/4 (bank 0) and ANALOG7/8 (bank 1) -- see the s32_msm6253 instantiation comment.
rtl/audio/s32_multipcm.sv:510 gew.cpp lfo_init(): m_amplitude_table, unipolar triangle 0..255 (tremolo only ever attenuates, matching AMPLITUDE_SCALE_LIMIT being <=0 in MAME).
rtl/cpu/v60/s32_v60.sv:17 - Single-precision FP (0x5C/0x5F: CMPF/MOVFS/NEGFS/ABSFS/SCLFS/ADDFS/SUBFS/ MULFS/DIVFS/CVTWS/CVTSW): a binary32 unit (round-to-nearest-even, gradual underflow) matching MAME's host-float contract; no System 32 game uses it.
rtl/cpu/v60/s32_v60.sv:2941 Equal AND matches the stop byte: MAME clears CY and breaks; S/Z stay 0 (i != dest), R28/R27 at the current index.
rtl/cpu/v60/s32_v60.sv:4798 1 <= count <= width: exact MAME SHIFTLEFT_OV mask (count==width uses the full-width mask, matching MAME's count==bitsize case, e.g. SHA.B #8,-1 -> OV=0)
rtl/io/s32_io.sv:30 Matches MAME 315_5296.cpp read()/write() in MAME's 315_5296 device.
rtl/s32_core.sv:668 TM-1: CRT/tilemap screen-width authority is VRAM $1FF00 bit 15, matching MAME screen_update_system32 / multi32_update, which set the visible area to 52*8 (416) when that bit is set and 40*8 (320) otherwise.
rtl/s32_core.sv:1065 Power up at bank 0 to match MAME device_start (m_analog_bank = 0); System 32 analog games never write 0xC00060 so it would otherwise stay X in simulation and undefined at cold boot (audit R20 IO-15).
rtl/video/s32_sprite.sv:710 Repack each pair to the same byte layout as a sprite-ROM burst (matching the 315-5386/MAME controller model).

Shares text with the MAME driver without saying so — 5

rtl/io/s32_io.sv:669 MAME device_reset (memset(m_v60_irq_control,0xff)) leaves the pending — shares text with sega/segas32.cpp:666
rtl/s32_core.sv:1065 Power up at bank 0 to match MAME device_start (m_analog_bank = 0); — shares text with sega/segas32.cpp:657
rtl/s32_core.sv:1081 (sega_multi32_analog_state::in2_analog_read/in3_analog_read, — shares text with sega/segas32.cpp:2660
rtl/s32_core.sv:1214 MAME: map(0xf00000, 0xffffff).rom().region("maincpu", 0) — the top window — shares text with sega/segas32.cpp:1172
rtl/video/s32_tilemap.sv:582 bgcharlayout x-offsets {0,4,16,20,8,12,24,28,...}: column -> — shares text with sega/segas32.cpp:2225

Arcade-Simple156#
Cannon Dancer, Charlie Ninja, Joe & Mac Returns
database (builds only)

MeatCores
independent database

Source not published

Arcade-Simpsons#
The Simpsons
database (builds only)

MeatCores
independent database

Source not published

Arcade-SSV#
Change Air Blade, Drift Out '94 - The Hard Order, Dyna Gear, Monster Slider …
meathax/SVV @ b5490317
MAME compared: seta/ssv.cpp + 4 related file(s)
Read: 40 HDL files, 20,732 lines (Quartus project)

MeatCores
independent database

Mostly MAME

medium

80%

Statements: 2 toward hardware, 254 toward MAME

Cites hardware documentation that MAME's driver does not — 1

rtl/video/ssv_cached_sprite_renderer.sv:237 Use the explicit MLAB-shaped wrapper so the placement request is represented in the netlist rather than left to the fragile inference heuristic.

Notes where it differs from MAME — 1

rtl/cpu/upd96050/upd96050.sv:434 It is very likely a MAME bug for this part.

Cites MAME source — 228

rtl/audio/ssv_es5506_regs.sv:18 A watchdog reset is a device reset in MAME and must not erase the voice register banks.
rtl/audio/ssv_es5506_regs.sv:236 Every CR consumer (engine snapshot, host readback) sees the masks applied combinationally; the masks are flushed into the MLAB at the voice's next snapshot when the port is free, and a host CR write to the voice clears them (the host's late
rtl/audio/ssv_es5506_regs.sv:296 Its CR mask merge and flush must be voided for that pass -- the next snapshot redoes the work from the stored (new) value, which is MAME's serialization.
rtl/audio/ssv_es5506_regs.sv:307 The common factor is the snapshot colliding with a host read-steal of the shared MLAB read port (real hardware reads the ES5506 ~840x/s; MAME's map shows almost none, so no sim reproduced it) or with a same-voice commit still settling into
rtl/audio/ssv_es5506_regs.sv:315 This serializes host access against the snapshot exactly as MAME's ordering does, and it also closes the same-edge MLAB read-during-write capture window and the stale-_h fresh-bit gap by construction.
rtl/audio/ssv_es5506_regs.sv:627 MAME's ES5506 compute_tables() initializes every voice before the first device reset: stopped CR, half-scale L/R volume, and zero for the rest.
rtl/audio/ssv_es5506_regs.sv:854 MAME's es5506_device::device_reset() only restores these device-level timing controls.
rtl/audio/ssv_es5506_regs.sv:874 The next snapshot redoes them from the stored (new) CR -- MAME's serialized write-then-sample order.
rtl/audio/ssv_es5506_regs.sv:901 (The eng_wr_cr exclusion: on an exact same-cycle collision the engine transition merges and survives the host write -- a one-clock-stale CR bit is recoverable, a dropped BLE->LEI transition is a permanent loop.) Host CR write supersedes any
rtl/audio/ssv_es5506_regs.sv:992 MAME's read+ack is atomic and cannot lose it; the OTTO spec ties the release to the vector the host actually observed.
rtl/audio/ssv_es5506_voice.sv:3 2.3 + MAME es5506.cpp behavioral cross-check.
rtl/audio/ssv_es5506_voice.sv:258 The accumulator's fractional field is 11 bits (it also sets frequency resolution) but only the top 9 feed interpolation; 9 is correct here and MAME's 11-bit fraction is the deviation, not this.
rtl/audio/ssv_es5506_voice.sv:405 Dyna Gear populates bank 2 only, which is what the old hardwired `!= 2'b10` encoded; other SSV titles populate 0/1 and alias 2/3 onto them via MAME ROM_COPY, so the valid set is per game.
rtl/audio/ssv_es5506_voice.sv:431 MAME's get_integer_addr(accum, 1) adds the +1 to the accumulator's integer field BEFORE the 21-bit mask, so at the last word of a bank the tap wraps to word 0 of the SAME bank.
rtl/audio/ssv_es5506_voice.sv:437 Wrap the integer field first, as MAME does.
rtl/cpu/upd96050/ssv_st010_prg_fetch.sv:27 ce_dsp = 2.5 MHz (MAME's 10 MHz / 4-clock instruction)
rtl/cpu/upd96050/ssv_st010_prg_fetch.sv:55 MAME's dspprg is 32-bit BIG-endian and the fetch is read_dword(pc) >> 8: prg_data = { rom[4pc+0], rom[4pc+1], rom[4pc+2] } MSB first Instruction 2m of a line uses bytes 0,1,2; instruction 2m+1 uses 4,5,6.
rtl/cpu/upd96050/upd96050.sv:5 Used on the Seta SSV protection daughterboard as the "ST010" in Drift Out '94, Storm Blade and Twin Eagle II (ssv.cpp:2468 / :2642 / :2755).
rtl/cpu/upd96050/upd96050.sv:10 Bit-for-bit against MAME's portable core (originally byuu's): D:\Arcade\AI\MAMESOURCE\mame\src\devices\cpu\upd7725\upd7725.cpp Every decode field, ALU op, flag rule and register side effect below cites the line range it was taken from.
rtl/cpu/upd96050/upd96050.sv:13 Where MAME's behaviour is questionable (see the DP MODIFY note) this core reproduces MAME rather than guessing, because MAME is the only reference the testbench can be checked against.
rtl/cpu/upd96050/upd96050.sv:37 Recommended backing, which needs no cache RAM at all: MAME's dspprg region is 32 bits per instruction (4 bytes, 3 used), so four consecutive instructions are exactly one aligned 16-byte SDRAM read on a 128-bit port of the kind ssv_core alre
rtl/cpu/upd96050/upd96050.sv:48 The real part executes one instruction every 4 clocks (MAME execute_min_cycles/execute_max_cycles both return 4, upd7725.cpp:254-268), so 10 MHz -> 2.5 MIPS.
rtl/cpu/upd96050/upd96050.sv:52 For MAME parity on SSV (clk_sys = 48.324 MHz) use the same fractional accumulator style as ce_cpu with increment 3391: 3391/65536 * 48.324 MHz = 2.5003 MHz.
rtl/cpu/upd96050/upd96050.sv:55 MAME's own comment on the 10 MHz figure is "// TODO: correct?", so this is not a precise number to begin with.
rtl/cpu/upd96050/upd96050.sv:60 SI is never written and SIACK/SOACK are hardwired 0, exactly as in MAME -- so JNSIAK and JNSOAK always branch and JSIAK/JSOAK never do.
rtl/cpu/upd96050/upd96050.sv:75 /RESET: MAME device_reset retention
rtl/cpu/upd96050/upd96050.sv:78 MAME fetches opcode = read_dword(pc) >> 8 from a 32-bit big-endian space (upd7725.cpp:315), i.e. for ROM byte offset 4*pc the opcode is {b0, b1, b2} and b3 is discarded.
rtl/cpu/upd96050/upd96050.sv:89 MAME configures a 12-bit word space (upd7725.cpp:54) of which ssv.cpp:346 maps only 0x000-0x7ff, so reads at addr[11] return 0 there.
rtl/cpu/upd96050/upd96050.sv:97 Host data port -- the $480000 byte on SSV (necdsp data_r / data_w, upd7725.cpp:578-631).
rtl/cpu/upd96050/upd96050.sv:98 host_dp_dout is the value a read would return *now* and carries no side effect, mirroring MAME's side_effects_disabled() path; assert host_dp_rd for exactly one clk to apply the SR side effects of a real read.
rtl/cpu/upd96050/upd96050.sv:107 status_r (upd7725.cpp:572) = SR[15:8].
rtl/cpu/upd96050/upd96050.sv:107 Not mapped anywhere in ssv.cpp, exposed because it costs nothing and other uPD96050 boards do map it.
rtl/cpu/upd96050/upd96050.sv:169 Flag word packing follows MAME's Flag::operator unsigned() (upd7725.h:78): bit5 s1, bit4 s0, bit3 c, bit2 z, bit1 ov1, bit0 ov0.
rtl/cpu/upd96050/upd96050.sv:174 Bits 6:2 have no storage in MAME's Status struct, so a read of SR always returns 0 there and a write to them is discarded.
rtl/cpu/upd96050/upd96050.sv:181 Serial handshake acks: MAME clears them at reset and never sets them.
rtl/cpu/upd96050/upd96050.sv:200 upd7725.cpp:142-146
rtl/cpu/upd96050/upd96050.sv:219 Opcode fields (upd7725.cpp:350-358, :482-484, :543-545)
rtl/cpu/upd96050/upd96050.sv:296 OP / RT source select -> IDB (upd7725.cpp:360-377)
rtl/cpu/upd96050/upd96050.sv:320 ALU (upd7725.cpp:379-458).
rtl/cpu/upd96050/upd96050.sv:356 if (!flag.ov1) flag.s1 = flag.s0; -- flag.ov1 is still the OLD ov1 at this point, because MAME's earlier clears are overwritten by "flag = regs.flaga" (upd7725.cpp:384-399).
rtl/cpu/upd96050/upd96050.sv:396 LD stage (upd7725.cpp:543-570).
rtl/cpu/upd96050/upd96050.sv:396 Reached directly by an LD instruction and as the move-destination stage of OP/RT, so a destination write overrides the ALU result for the same accumulator -- MAME's order.
rtl/cpu/upd96050/upd96050.sv:429 DP / RP modify (upd7725.cpp:462-472).
rtl/cpu/upd96050/upd96050.sv:431 NOTE, deliberately faithful: MAME masks with 0xf0, which discards DP bits 15:8.
rtl/cpu/upd96050/upd96050.sv:435 It is reproduced rather than "fixed" because MAME is the only oracle the tests can be written against, and MAME is what the three ST010 titles are known to run under.
rtl/cpu/upd96050/upd96050.sv:454 JP (upd7725.cpp:481-541).
rtl/cpu/upd96050/upd96050.sv:502 unrecognised branch: fall through, as in MAME
rtl/cpu/upd96050/upd96050.sv:507 RT (upd7725.cpp:475-479): the OP body has already run above.
rtl/cpu/upd96050/upd96050.sv:517 Multiplier (upd7725.cpp:341-343) -- runs after EVERY instruction, using the values of K and L as they stand at the end of it.
rtl/cpu/upd96050/upd96050.sv:532 Walk port A once on every cold/download reset so a newly selected ST010 descriptor gets MAME's clean device-start data RAM.
rtl/cpu/upd96050/upd96050.sv:570 dsp_w duplicates the byte into both halves and lets the mask pick one (ssv.cpp:359-362), which is exactly a byte enable here.
rtl/cpu/upd96050/upd96050.sv:582 Host data port (upd7725.cpp:578-631)
rtl/cpu/upd96050/upd96050.sv:615 MAME device_start establishes a completely clean device.
rtl/cpu/upd96050/upd96050.sv:648 MAME necdsp_device::device_reset(): /RESET clears PC, SR, A/B flags and interrupt/serial handshake state.
rtl/cpu/upd96050/upd96050.sv:681 Interrupt entry (upd7725.cpp:318-331): a synthesised NOP, then LCALL 0x100.
rtl/cpu/upd96050/upd96050.sv:753 INT pin (upd7725.cpp:275-289): rising edge, and only when EI is set.
rtl/cpu/upd96050/upd96050_st010.sv:8 ssv.cpp:410-411 (drifto94_map) and :769-770 (twineag2_map):
rtl/cpu/upd96050/upd96050_st010.sv:13 and ssv.cpp:350-362:
rtl/cpu/upd96050/upd96050_st010.sv:26 It is the offset MAME hands an 8-bit handler installed with umask16 on a 16-bit space, and that is one step per bus WORD, not per byte.
rtl/cpu/upd96050/upd96050_st010.sv:28 From memory_units_descriptor (src/emu/emumem_mud.cpp) with Width=1, AddrShift=0, access_width=0, unitmask=0x00ff:
rtl/cpu/upd96050/upd96050_st010.sv:32 active_count_log = 0 base_shift = Width - access_width - active_count_log = 1 shift = base_shift + access_width + AddrShift = 1 handler offset = cpu_addr >> 1 (emumem_heu.cpp:86)
rtl/cpu/upd96050/upd96050_st010.sv:51 (The Phase 9 spec's "2048 usable bytes" is right; its "word n/2" is only right if n is read as MAME's offset, not as a CPU address.)
rtl/cpu/upd96050/upd96050_st010.sv:55 The SSV main CPU is a NEC V60 (ssv.cpp:112, :2433) whose program space is ENDIANNESS_LITTLE (v60.cpp:98), so D7:0 is the EVEN byte -- cpu_be[0] in this core, the same lane the ES5506 host port uses.
rtl/cpu/upd96050/upd96050_st010.sv:58 $480000 resolves to the same lane: with a one-byte range MAME reduces the default 0xffff unitmask to emask = make_bitmask((addrend-addrbase+1) << 3) = 0x00ff.
rtl/cpu/upd96050/upd96050_st010.sv:71 watchdog /RESET: MAME-retained state
rtl/cpu/upd96050/upd96050_st010.sv:72 On SSV, drive from a fractional accumulator with increment 3391 off clk_sys (48.324 MHz) for the 2.5 MIPS MAME models at its (self-flagged "TODO: correct?") 10 MHz.
rtl/cpu/upd96050/upd96050_st010.sv:93 MAME builds this from st010.bin bytes 0x00000-0x0ffff as a 32-bit big-endian region (ssv.cpp ROM_COPY into "dspprg") and fetches read_dword(pc) >> 8, so: prg_data = { rom[4*pc+0], rom[4*pc+1], rom[4*pc+2] } and rom[4*pc+3] is never used.
rtl/cpu/upd96050/upd96050_st010.sv:107 st010.bin bytes 0x10000-0x10fff, 16-bit big-endian ("dspdata", ssv.cpp ROM_COPY), 2048 words.
rtl/cpu/upd96050/upd96050_st010.sv:183 MAME's address_space unmapped read value defaults to 0, so a word read that straddles the mapped low byte returns 0 in the high byte.
rtl/cpu/upd96050/upd96050_st010.sv:215 ssv.cpp:346 maps only 0x000-0x7ff of the DSP's 12-bit data space, so the upper half reads as MAME's unmapped value, 0.
rtl/cpu/v60/s32_v60.sv:5 Behavioral contract is MAME's v60 core (BSD-3-Clause, Farfetch'd / R. Belmont): opcode dispatch per optable.hxx, addressing modes per am1-3.hxx, exception entry per v60.cpp.
rtl/cpu/v60/s32_v60.sv:13 the fill/stop variants (MOVC*/CMPC*/SCHC*/SKPC*), TASI, bit ops, GETPSW/UPDPSW, TRAP/TRAPFL/BRK/BRKV, CHLVL, task save/load, privileged register moves (LDPR/STPR), and MAME-defined decimal/bit- string/bit-field groups.
rtl/cpu/v60/s32_v60.sv:20 - Not implemented (reserved-instruction exception, logged in sim): the un-dispatched 0x5C/0x5F sub-opcodes (MAME UNHANDLED).
rtl/cpu/v60/s32_v60.sv:21 MMU/TLB effects are absent like MAME, but CLRTLB still decodes its complete operand.
rtl/cpu/v60/s32_v60.sv:33 V60/V70 reset PC (MAME m_start_pc; audit V60-21)
rtl/cpu/v60/s32_v60.sv:141 Keeping the definition here, instead of inferring it hierarchically in a bench, makes MAME/RTL sampling semantics reviewable.
rtl/cpu/v60/s32_v60.sv:171 PSW fields (MAME bit layout: Z=b0,S=b1,OV=b2,CY=b3,IE=b18,EL=b25:24,IS=b28)
rtl/cpu/v60/s32_v60.sv:730 C-style truncating divide-by-8 of a signed bit offset (MAME bamoffset/8)
rtl/cpu/v60/s32_v60.sv:846 stack switch on IS change, or EL change while IS=0 (MAME v60WritePSW)
rtl/cpu/v60/s32_v60.sv:991 MAME ReadAMAddress uses moddim=3 for qword lvalues (MOVD and the MULX/DIVX destination).
rtl/cpu/v60/s32_v60.sv:1208 primary dispatch (per MAME optable.hxx)
rtl/cpu/v60/s32_v60.sv:1213 BRK — MAME skips this opcode (A4)
rtl/cpu/v60/s32_v60.sv:1233 0x6B/0x7B are holes in MAME's authoritative primary dispatch table, not branch-condition encodings.
rtl/cpu/v60/s32_v60.sv:1310 MAME opDBcc: reg ALWAYS decrements; branch iff cond true and decremented reg != 0.
rtl/cpu/v60/s32_v60.sv:1390 JMP/JSR/TASI: MAME sets moddim=0 — the dim scales INDEXED modes' index register, and ga2's jump tables (3-byte BR entries, `JMP [PC+d](rN)`) rely on the unscaled index (found by real-ROM boot: dim=2 quadrupled the index and jumped mid-table
rtl/cpu/v60/s32_v60.sv:1416 RETI adj (halfword, MAME moddim=1)
rtl/cpu/v60/s32_v60.sv:1440 MAME F7a/F7b decode with dim 0 (0x58 byte) / 1 (0x5A half): autoincrement/indexed AMs step and scale by the element size, and F7b immediates size accordingly — not dword.
rtl/cpu/v60/s32_v60.sv:1460 MAME implements ADDDC/SUBDC/SUBRDC/CVTDPZ/CVTDZP (radm timer); remaining subops are reserved there too.
rtl/cpu/v60/s32_v60.sv:1538 Unhandled sub-opcodes still take the reserved-instruction vector exactly as MAME's op5C/op5F UNHANDLED entries fatalerror.
rtl/cpu/v60/s32_v60.sv:1579 RSR (A9): pop PC ONLY (MAME opRSR: PC=[SP]; SP+=4)
rtl/cpu/v60/s32_v60.sv:1584 MAME/NEC floating-exception test: enabled TKCW causes are intersected with the PSW floating-status field.
rtl/cpu/v60/s32_v60.sv:1613 F12: plan operands per instflags (MAME F12DecodeOperands)
rtl/cpu/v60/s32_v60.sv:1622 MOVEA takes op1 as an ADDRESS (MAME ReadAMAddress) — decoding it as a value loaded SP with a byte read instead of the EA and sent ga2's boot stub off a cliff (found by real-ROM boot)
rtl/cpu/v60/s32_v60.sv:1926 Immediate modes carry no address: the "address requested" path must still hand back the value (MAME LDPR-quirk equivalent), and op2 immediates pre-fill op2val so S_OP2_LD never dereferences a stale ea_addr (found by real-ROM boot: ga2's `LD
rtl/cpu/v60/s32_v60.sv:2055 MAME opMULX/opMULUX leave OV unchanged.
rtl/cpu/v60/s32_v60.sv:2088 MAME opDIVX/opDIVUX set only S/Z and leave OV unchanged; do not clear it.
rtl/cpu/v60/s32_v60.sv:2120 MAME opROTC*: the carry bit enters the active operand's LSB; bits above a byte/halfword operand are not part of the ring.
rtl/cpu/v60/s32_v60.sv:2447 pops (8) + frame-destroy operand (MAME: SP += amout), then the PSW write may bank-switch SP — order matters: adjust THEN switch.
rtl/cpu/v60/s32_v60.sv:2489 push highest set register first (MAME pushes from r31 down?
rtl/cpu/v60/s32_v60.sv:2537 TASI sets flags as SUBB(old, 0xFF, 0) before writing 0xFF (MAME opTASI).
rtl/cpu/v60/s32_v60.sv:2574 R27 (dst) / R28 (src) updated at completion (MAME MOVSTR).
rtl/cpu/v60/s32_v60.sv:2583 Element-size dim for both (MAME dim 0 byte / 1 half — see decode).
rtl/cpu/v60/s32_v60.sv:2600 V60-15: down-direction search (subop[0]=1, MAME opSEARCHD*).
rtl/cpu/v60/s32_v60.sv:2602 The down form scans the range in descending order from MAME's start index: byte reads op1+len1 down to op1 (len1+1 reads; the first read is one past the buffer, exactly as opSEARCHDB does), half reads op1+(len1-1)*2 down to op1 (len1 reads)
rtl/cpu/v60/s32_v60.sv:2627 MOVCD/MOVCFD (down copy) transfers the ascending range base..base+min-1 in descending element order (MAME opMOVSTRD): start at the TOP of that range and decrement, instead of walking physically below the base as the old code did (audit R20
rtl/cpu/v60/s32_v60.sv:2636 CMPCS (0x02): stop mode starts with CY=1, cleared when a fill (R26) byte is met in the compare (MAME opCMPSTR bStop).
rtl/cpu/v60/s32_v60.sv:2639 CMPCF (0x01): fill the SHORTER operand's tail with R26 BEFORE the compare (MAME bFill); MOVC fill happens AFTER the copy.
rtl/cpu/v60/s32_v60.sv:2668 Down exhaustion: the scan ran off the bottom to i=-1 (MAME opSEARCHD*), so Z=0, R27=0xFFFFFFFF, and str_src has already reached op1-step.
rtl/cpu/v60/s32_v60.sv:2683 CMPC exhausted the common prefix (all min elements equal): R28=len1+min*step, R27=len2+min*step, and S/Z from the length compare (MAME opCMPSTR tail).
rtl/cpu/v60/s32_v60.sv:2718 Z follows MAME's post-loop test i==len1: up never breaks at i==len1 (Z=0), down does so only at its one-past-the-top byte read (str_cnt==len1+1).
rtl/cpu/v60/s32_v60.sv:2756 CMPC (MAME opCMPSTR): compare source(op1) vs dest(op2).
rtl/cpu/v60/s32_v60.sv:3013 BAM: bit addressing modes for the 0x5B/0x5D groups (MAME BAMTable1/2 implemented subset — everything MAME fatalerrors on traps here too).
rtl/cpu/v60/s32_v60.sv:3405 CMPC finishes through S_STR_RD's exhaustion branch so the MAME length-tail flags/registers apply; MOVC finalizes R28/R27 from the operand bases and the copied count via movc_finish (which also scales by the element size and launches the MOV
rtl/cpu/v60/s32_v60.sv:3504 exception / interrupt entry (MAME v60_do_irq): switch to interrupt context, push old PSW, push PC, PC = vector Microcode response time for an accepted interrupt.
rtl/cpu/v60/s32_v60.sv:3752 per-opcode dim helpers (operand sizes per MAME op12 handlers)
rtl/cpu/v60/s32_v60.sv:3754 F12 ops whose FIRST operand is an effective address, not a value (MAME F12DecodeFirstOperand(ReadAMAddress, ...)): MOVEA and IN
rtl/cpu/v60/s32_v60.sv:3770 MAME opMOVD: both operands are qword lvalues.
rtl/cpu/v60/s32_v60.sv:3778 NOTE: ROTH (8b) / ROTCH (9b) must NOT appear here — their op1 is the rotate COUNT, a byte (MAME ReadAM dim 0); listing them in the half group made `ROT.H #imm8, r6` decode one byte long and holo's EEPROM write loop entered mid-instruction (
rtl/cpu/v60/s32_v60.sv:3795 MAME F12DecodeOperands passes moddim=3 for MOVD and for the MULX/MULUX/DIVX/DIVUX destination lvalue.
rtl/cpu/v60/s32_v60.sv:3823 These read op2 as a VALUE (MAME ReadAM), so a memory operand must be loaded into op2val before exec; otherwise the exec fell back to the effective address / a stale op2val (audit R20 V60-18).
rtl/cpu/v60/s32_v60.sv:3900 MOVC completion (MAME opMOVSTRU*/opMOVSTRD*): publish R28/R27 for the final element index `idx`, and — for the fill variants (MOVCFU/MOVCFD) with the source shorter than the destination — kick off the R26 tail-fill phase.
rtl/cpu/v60/s32_v60.sv:3923 MAME pads the destination tail elements [idx, lenop2) with R26; the down form uses op2+dest+(lenop2-j-1) for bytes and op2+(lenop2-j-1)*2 for halves.
rtl/cpu/v60/s32_v60.sv:3988 MAME MOV sets no flags?
rtl/cpu/v60/s32_v60.sv:4109 A zero count must clear CY (MAME); the old code left it unchanged (audit R20 V60-7).
rtl/cpu/v60/s32_v60.sv:4136 MAME defines CY from the post-rotate wrap bit: LSB after a positive (left) rotate, MSB after a negative (right) rotate.
rtl/cpu/v60/s32_v60.sv:4147 MAME clears CY for a zero count; nonzero counts retain the final shifted-out bit, so only bypass the iterative state for zero.
rtl/cpu/v60/s32_v60.sv:4212 MAME divide-by-zero: destination unchanged and no trap, but Z/S are still set from the (unchanged) destination = the dividend, and OV is cleared (audit R20 V60-8); the old code left flags stale.
rtl/cpu/v60/s32_v60.sv:4245 MAME sets OV and leaves the destination unchanged (audit R20 V60-8); the old code always cleared OV and wrote the wrapped quotient.
rtl/cpu/v60/s32_v60.sv:4271 MAME: no zero-divide trap
rtl/cpu/v60/s32_v60.sv:4352 MAME opCALL: SP-=4; [SP]=AP; AP=op2; SP-=4; [SP]=retPC; PC=op1.
rtl/cpu/v60/s32_v60.sv:4389 MAME opTRAP: the operand's HIGH nibble is a Bcc-encoded condition (cond 0xB never traps); only trap when it evaluates true, else fall through.
rtl/cpu/v60/s32_v60.sv:4639 SHA left-shift overflow (MAME SHIFTLEFT_OV op12.hxx): OV is set when the top `count` bits of the width-sized value are not all equal to the sign bit — i.e. a bit different from the sign is shifted out through the top.
rtl/cpu/v60/s32_v60.sv:4641 MAME masks exactly `count` bits (((1<<count)-1) << (bitsize-count)); using count+1 here spuriously set OV (e.g. SHA.B #1,0x40 gave OV=1 vs MAME OV=0), misbranching a following signed Bcc (S^OV).
rtl/cpu/v60/s32_v60.sv:4652 count > width: MAME's macro is UB here (bitsize-count<0); any nonzero value overflowed
rtl/cpu/v60/s32_v60.sv:4714 This retains MAME's unusual signed rule: every non-zero negative product has OV set because its sign-extended bit pattern has non-zero bits above the operand width.
rtl/cpu/v60/s32_v60.sv:4724 MAME opMUL/opMULU: OV = (product >> width) != 0 on the product's unsigned bit pattern (signed product for MUL, unsigned for MULU).
rtl/cpu/v60/s32_v60.sv:4726 For byte/half MAME shifts the 32-bit value; for word, the 64-bit one.
rtl/cpu/v60/s32_v60.sv:4743 MAME clears OV for REM/REMU (audit R20 V60-8)
rtl/cpu/v60/s32_v60.sv:4751 Behavioral contract is MAME op2.hxx/op5.hxx, which use host `float` — round-to-nearest-even, with gradual underflow (subnormals) and IEEE special values.
rtl/cpu/v60/s32_v60.sv:4767 NEGFS/ABSFS are NOT: MAME does ReadAMAddress + store only (no load) — they operate on op1 and must not read a possibly read-sensitive destination.
rtl/cpu/v60/s32_v60.sv:4942 Deliberate divergence from the pinned MAME for |n| > 30: MAME computes `appf * / (1 << n)` with the host's shift-count masking (&31, and 1 << 31 = INT_MIN there), so e.g. SCLFS(31) flips the sign and SCLFS(32) is a no-op on x86.
rtl/cpu/v60/s32_v60.sv:4999 Pinned MAME converts (uint32_t)(int64_t)val on its x86 host: NaN and out-of-int64-range saturate the hardware convert to INT64_MIN, whose low 32 bits are 0.
rtl/cpu/v60/s32_v60.sv:5022 MAME stores the LOW 32 BITS of the int64 truncation, not a clamp: well-defined in C for e in [31,62]; e >= 63 saturates the x86 convert to INT64_MIN (low 32 = 0).
rtl/cpu/v60/s32_v60.sv:5033 (MAME: (_S && val>=0) || (!_S && val<=-1); |val| >= 1 here).
rtl/cpu/v60/s32_v60.sv:5148 MAME materializes the subtraction: same-signed infinities give inf-inf = NaN, so they compare Z=0/S=0 like unordered operands.
rtl/io/ssv_93c46_16.sv:2 Organization is fixed to the 16-bit mode selected by EEPROM_93C46_16BIT in MAME.
rtl/io/ssv_adc0809.sv:2 The pinned MAME 0.289 driver supplies a 1 MHz clock but marks that clock unknown.
rtl/io/ssv_mahjong_matrix.sv:4 Addressing and permutations follow pinned MAME 0.289 ssv.cpp.
rtl/io/ssv_upd4701.sv:1 SPDX-License-Identifier: GPL-3.0-or-later MAME uPD4701-compatible SSV profile.
rtl/io/ssv_upd7001.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Deterministic MAME-profile serial ADC.
rtl/mem/ssv_hs_extram.sv:5 MAME maps SSV main RAM at $000000-$00ffff (block RAM in this core) and gives twineag2/ultrax a second RAM at $010000-$03ffff (ssv.cpp: "More RAM"), which this core keeps in SDRAM at SDR_CPU_RAM_BASE.
rtl/mem/ssv_nvram_bridge.sv:78 Each descriptor load first writes MAME's DEFAULT_ALL_0 image across exactly 2 KiB or 64 KiB.
rtl/mem/ssv_rom_loader.sv:348 Do not replace this with a shift/mask: 24 MiB and 12 MiB MAME regions have 6 MiB and 3 MiB quarters respectively.
rtl/mem/ssv_rom_loader.sv:417 MAME's region is ROM_REGION16_BE, so the word at index i is { rom[2i], rom[2i+1] } -- the OPPOSITE order from the little-endian pairing the SDRAM path uses, which is why wd is {byte_lo, ioctl_dout} and not {ioctl_dout, byte_lo}.
rtl/mem/ssv_rom_loader.sv:427 MRA sample streams reproduce MAME's ROM_REGION16_BE byte image.
rtl/ssv_core.sv:8 MAME's unconfigured WATCHDOG_TIMER defaults to exactly three seconds.
rtl/ssv_core.sv:26 cold_rst excludes watchdog and is used where MAME/device hardware retains state across /RESET.
rtl/ssv_core.sv:101 MAME maps SSV main RAM at $000000-$00ffff (ssv.cpp: map(0x000000, 0x00ffff).ram().share(m_mainram)), which is this core's work_ram, and its second port was tied off.
rtl/ssv_core.sv:288 Everything above that is tile/local sprite payload the games stream continuously during active display (measured in MAME 0.289 on vasara: offsets 0x08000-0x1806e written on every raster line 0..239 and 250..261).
rtl/ssv_core.sv:326 MAME maps the program ROM as `ssv_map(map, rom)` with rom..0xffffff, and in every SSV set rom == 0x1000000 - program_size: $f00000 for a 1 MB program (dynagear), $e00000 for 2 MB (cairblad, twineag2, ultrax), $c00000 for 4 MB (drifto94, stm
rtl/ssv_core.sv:331 0x1000000 does not fit the 24-bit CPU address, and it does not need to: in 24-bit arithmetic 0x1000000 - size is exactly -size, which yields 0xF00000 / 0xE00000 / 0xC00000 for 1 / 2 / 4 MB -- MAME's values.
rtl/ssv_core.sv:341 drifto94_map (ssv.cpp:410-411) and twineag2_map (:769-770): map(0x480000, 0x480000).rw(m_dsp, upd96050_device::data_r, data_w); map(0x482000, 0x482fff).rw(dsp_r, dsp_w).umask16(0x00ff); The window translation (offset = A[11:1], word = A[11:
rtl/ssv_core.sv:458 Scroll/CRTC registers are shared board RAM in MAME and machine_reset() does not clear them.
rtl/ssv_core.sv:789 Measured in MAME 0.289 (vasara, write taps on 0x100000-0x13ffff bucketed by beam line, 240 frames): the global-list writes land on raster lines 240-247 only, at offsets 0x00002-0x000be.
rtl/ssv_core.sv:910 MAME init_ssv() starts with video enabled; bit 7 of the lockout register can subsequently blank it.
rtl/ssv_core.sv:918 MAME derives a live top/left clip from the CRTC visible-area registers at $1c0062/$64 and $1c006a/$6c.
rtl/ssv_core.sv:949 MAME's screen_update() first bitmap.fill(0), then returns early when the video-enable latch is clear.
rtl/ssv_core.sv:1001 MAME's drifto94_unknown_r() returns machine().rand().
rtl/ssv_core.sv:1010 The V60 holds m_req throughout the core's wait/ack sequence, so advancing on a held request changes the value multiple times for one MAME handler transaction.
rtl/ssv_core.sv:1039 MAME: map(rom, 0xffffff).rom().region("maincpu", 0), where rom is the descriptor-sized base ($f00000/$e00000/$c00000).
rtl/ssv_core.sv:1267 MAME instantiates UPD96050 at 10 MHz with its own `// TODO: correct?`, so the clock is not authoritative.
rtl/ssv_core.sv:1335 MAME never wires the uPD96050's INT on SSV, and the DSP's P0/P1 outputs go nowhere on the daughterboard.
rtl/ssv_core.sv:1369 m_be[0] mirrors sound_host_we: MAME maps the ES5506 with umask16(0x00ff), so an odd-address byte read never reaches the device.
rtl/ssv_core.sv:1370 Without the gate the read still stole the register file's port and, for host_reg 0xE, cleared IRQV where MAME would not.
rtl/ssv_core.sv:1529 MAME's WATCHDOG_TIMER has no SSV-specific override, so watchdog.cpp uses its default attotime::from_seconds(3).
rtl/ssv_core.sv:1535 mode 2 write-kick vasara, vasara2 (reset16_w) mode 0 no device drifto94, stmblade MAME's WATCHDOG_TIMER first appears at ssv.cpp:2513, after the drifto94 and stmblade machine configs, so those two have no watchdog
rtl/ssv_core.sv:1565 MAME ssv_state::lockout_w / lockout_inv_w.
rtl/ssv_core.sv:1577 Cabinet bookkeeping and output latches are not cleared by MAME's machine_reset(); retain them across a watchdog reset.
rtl/ssv_core.sv:1624 V60 program space is configured with MAME's default unmapped value of zero.
rtl/ssv_core.sv:1636 ROM writes are nops (MAME image is read-only) but must still ack or a push into 0xFxxxxx hangs forever.
rtl/ssv_core.sv:1715 MAME's portr() values are eight-bit ports on this 16-bit V60 map.
rtl/ssv_core.sv:1737 Stable device identifiers shared with the MAME adapter.
rtl/ssv_irq.sv:7 A watchdog/machine reset clears only pending causes in MAME.
rtl/ssv_irq.sv:13 MAME's init_ssv_irq1 sets m_interrupt_ultrax for ultrax and twineag2; ssv.cpp notes it is "needed by ultrax to coin up, breaks cairblad", which is why it is per game and not unconditional.
rtl/ssv_irq.sv:66 MAME's SSV controller refreshes the CPU input line when a cause is raised or acknowledged.
rtl/ssv_irq.sv:154 MAME stores a 16-bit register, but SSV defines eight causes.
rtl/ssv_irq.sv:163 MAME searches pending levels from 0 through 7 and uses the first one.
rtl/ssv_pixel_retime.sv:31 The raster counters, renderers, IRQs and CPU-to-pixel ratio are untouched, so frame CRCs and MAME lockstep traces do not move.
rtl/ssv_pkg.sv:22 The graphics region is no longer a copy of MAME's sprite ROM.
rtl/ssv_pkg.sv:25 3 MAME graphics quarter 0 -> plane01 byte 4..
rtl/ssv_pkg.sv:120 Byte offset inside st010.bin where "dspdata" begins (ssv.cpp ROM_COPY).
rtl/ssv_pkg.sv:137 MAME ssv_state::vblank_r() returns the raster status in the upper byte: VBLANK sets bits 12 and 13 (0x3000), HBLANK sets bit 11 (0x0800).
rtl/ssv_pkg.sv:148 ES5506 compressed samples use the OTTO u-law equation from MAME's es5506_device::compute_tables(), rather than a conventional telephony u-law table.
rtl/ssv_pkg.sv:189 Sizes come from MAME's ROM_REGION declarations (src/mame/seta/ssv.cpp), which is the authority for every field here.
rtl/ssv_pkg.sv:192 MAME does `code % gfxelement->elements()` (ssv_v.cpp), a true MODULO, and elements() = sprites_region / 128:
rtl/ssv_pkg.sv:241 Extra CPU RAM selected by the MAME address map: 0 none, 1 = $400000-$43ffff, 2 = $010000-$03ffff.
rtl/ssv_pkg.sv:264 exact MAME visarea width / 2
rtl/ssv_pkg.sv:265 exact MAME visarea height
rtl/ssv_pkg.sv:287 These records mirror the generated MRA configuration block, whose fields are derived from MAME's ssv.cpp.
rtl/ssv_pkg.sv:440 MAME only decodes the extra-button window for maps that explicitly expose $500008-$500009.
rtl/ssv_pkg.sv:528 MAME's graphics region is split into four logical quarters, but the populated stream may contain only three of them.
rtl/ssv_pkg.sv:610 MAME's dspprg is a 32-bit big-endian region and the fetch is read_dword(pc) >> 8, so the instruction occupies bytes 4*pc + 0..2 and byte 4*pc + 3 is never used.
rtl/ssv_pkg.sv:734 The whole image must fit the region, and "dspdata" must start where MAME's ROM_COPY says it does.
rtl/ssv_video_timing.sv:135 Drift Out crops the visible area (and therefore its live VBLANK status) at line 238, but MAME's SSV scan timer and raw 262-line raster retain the line-240 interrupt.
rtl/ssv_video_timing.sv:192 The exact board sync widths are not documented by MAME's set_raw call.
rtl/video/ssv_bg_renderer.sv:78 MAME's init_ssv builds m_tile_code[i] = bitswap<4>(i,0,1,2,3) << 16, which is attr[13:10] REVERSED.
rtl/video/ssv_bg_renderer.sv:247 MAME fixes `page` from the raw scroll register before adding it (ssv_v.cpp:684 vs :702), so the origin passed here must stay `scroll_x`.
rtl/video/ssv_bg_renderer.sv:255 The horizontal origin must include the row-scroll offset: MAME sx1 = 0 - (tilemap_scrollx & 0xf) *after* the offset is added (ssv_v.cpp:702 then :706).
rtl/video/ssv_cached_sprite_renderer.sv:436 MAME's init_ssv builds m_tile_code[i] = bitswap<4>(i,0,1,2,3) << 16, which is attr[13:10] REVERSED.
rtl/video/ssv_cached_sprite_renderer.sv:1340 Combined with the `local_index < global_w0[4:0]` test in BUILD_ADVANCE this yields count+1 iterations, which is what MAME's `for (; num >= 0; num--)` does.
rtl/video/ssv_cached_sprite_renderer.sv:1343 Do NOT "optimise" a zero-count global into a skip: it would drop a descriptor MAME draws and break frame-CRC parity.
rtl/video/ssv_cached_sprite_renderer.sv:1413 Skip its cache slot and continue walking the MAME list.
rtl/video/ssv_cached_sprite_renderer.sv:1722 Adjacent 64-pixel tilemap slices overlap by one inclusive line in MAME.
rtl/video/ssv_cached_sprite_renderer.sv:1816 MAME fixes `page` from the raw scroll register before adding it (ssv_v.cpp:684 vs :702), so the origin passed here must stay `tile_scroll_x`.
rtl/video/ssv_gfx_row_fetch.sv:4 The ROM loader packs the three populated MAME graphics quarters into one aligned 16-byte record per tile row (ssv_pkg::gfx_record_addr), so what used to be two serial p1 transactions -- the packed Q0/Q1 beat, then the Q2 beat of which half
rtl/video/ssv_gfx_row_fetch.sv:7 MAME's absent fourth quarter reads as zero.
rtl/video/ssv_gfx_row_fetch.sv:38 Tile-code wrapping is MAME's `code % elements()`, and elements() is per-game (0x18000 / 0x20000 / 0x30000 / 0x40000).
rtl/video/ssv_palette_ram.sv:15 MAME clears the indexed bitmap to pen 0 before checking video-enable.
rtl/video/ssv_palette_ram.sv:43 The RAM's video port is already consumed by the live scanline index, while MAME's bitmap clear needs pen 0 concurrently when video is disabled.
README.md:13 The RTL has focused simulation and MAME differential evidence.
README.md:101 Simulation results, MAME-derived behavior, and unmeasured claims are documented elsewhere and are not presented as PCB accuracy here.
README.md:114 Other Sammy Seta Visco entries present in MAME are not currently claimed as supported by this core.
README.md:151 **MAMEdev and MAME contributors** — Sammy Seta Visco driver/video behavior, V60 behavior, uPD96050/ST010 behavior, ES5506 behavior, ROM definitions, controls, D
README.md:154 MAME source is used as a behavioral reference; it is not copied into the synthesizable core.
README.md:156 **Farfetch'd and R. Belmont** — MAME V60 behavioral reference credited by the imported V60 source.
README.md:158 **byuu and MAME contributors** — portable uPD7725/uPD96050 behavioral reference used for the ST010 implementation.
README.md:173 MAME and other references are credited above and are not a license to redistribute copyrighted game data.
README.md:186 Put your legally obtained game ROM ZIP in the appropriate MiSTer arcade/MAME ROM folder, then launch the game from the MiSTer Arcade menu.

Says it matches, follows or was checked against MAME — 9

Arcade-SSV.sv:772 The reset default matches MAME's dynagear (FF / FD) so the core still comes up sanely if an MRA carries no <switches> block at all.
rtl/audio/ssv_es5506_regs.sv:5 Register masks and reset behavior were cross-checked against MAME's BSD-3-Clause es5506.cpp and the zlib-licensed vgsound_emu ES550x model.
rtl/audio/ssv_es5506_regs.sv:284 Keep a one-cycle-delayed record of the last commit and re-assert its fresh bit after the snapshot clear (NBA ordering: the later assignment wins), so a write the snapshot could not see keeps its protection until the NEXT snapshot, exactly m
rtl/cpu/upd96050/upd96050.sv:58 NOT IMPLEMENTED (matching MAME, which also omits them)
rtl/cpu/upd96050/upd96050.sv:733 Applied after the execute writes above so that the pathological same-clk collision resolves host-last, matching MAME where a host access is a device call outside the execute step.
rtl/cpu/v60/s32_v60.sv:17 - Single-precision FP (0x5C/0x5F: CMPF/MOVFS/NEGFS/ABSFS/SCLFS/ADDFS/SUBFS/ MULFS/DIVFS/CVTWS/CVTSW): a binary32 unit (round-to-nearest-even, gradual underflow) matching MAME's host-float contract; no System 32 game uses it.
rtl/cpu/v60/s32_v60.sv:2778 Equal AND matches the stop byte: MAME clears CY and breaks; S/Z stay 0 (i != dest), R28/R27 at the current index.
rtl/cpu/v60/s32_v60.sv:4653 1 <= count <= width: exact MAME SHIFTLEFT_OV mask (count==width uses the full-width mask, matching MAME's count==bitsize case, e.g. SHA.B #8,-1 -> OV=0)
rtl/video/ssv_cached_sprite_renderer.sv:196 Consecutive identical ordinary descriptors are idempotent in MAME draw order, so keeping one copy avoids filling every affected scanline bucket with reset-list duplicates before the renderer ever sees them.

Says it was translated, ported or taken from MAME — 1

rtl/ssv_irq.sv:1 SPDX-License-Identifier: GPL-3.0-or-later SSV eight-level interrupt controller, translated from MAME ssv.cpp.

Keeps a MAME approximation — 2

rtl/ssv_core.sv:1680 MAME 0.289 compatibility assumption.
rtl/video/ssv_st0020_ctrl.sv:21 MAME-profile status/unknown register assumption

Shares text with the MAME driver without saying so — 14

rtl/cpu/upd96050/upd96050_st010.sv:10 map(0x480000, 0x480000).rw(m_dsp, upd96050_device::data_r, data_w); — shares text with seta/ssv.cpp:410
rtl/cpu/upd96050/upd96050_st010.sv:15 uint8_t dsp_r(offs_t offset) { — shares text with seta/ssv.h:166
rtl/cpu/upd96050/upd96050_st010.sv:16 uint16_t temp = m_dsp->dataram_r(offset / 2); — shares text with seta/ssv.cpp:353
rtl/cpu/upd96050/upd96050_st010.sv:17 uint8_t shift = BIT(offset, 0) << 3; — shares text with seta/ssv.cpp:354
rtl/cpu/upd96050/upd96050_st010.sv:20 void dsp_w(offs_t offset, uint8_t data) { — shares text with seta/ssv.h:167
rtl/cpu/upd96050/upd96050_st010.sv:21 uint8_t shift = BIT(offset, 0) << 3; — shares text with seta/ssv.cpp:354
rtl/cpu/upd96050/upd96050_st010.sv:22 m_dsp->dataram_w(offset / 2, (uint16_t(data) << 8) | data, — shares text with seta/ssv.cpp:361
rtl/ssv_core.sv:102 (ssv.cpp: map(0x000000, 0x00ffff).ram().share(m_mainram)), which is this — shares text with seta/ssv.cpp:376
rtl/ssv_core.sv:342 map(0x480000, 0x480000).rw(m_dsp, upd96050_device::data_r, data_w); — shares text with seta/ssv.cpp:410
rtl/ssv_core.sv:1039 MAME: map(rom, 0xffffff).rom().region("maincpu", 0), where rom is the — shares text with seta/ssv.cpp:393
rtl/video/ssv_bg_renderer.sv:78 MAME's init_ssv builds m_tile_code[i] = bitswap<4>(i,0,1,2,3) << 16, which — shares text with seta/ssv.cpp:2360
rtl/video/ssv_bg_renderer.sv:80 identity (m_tile_code[i] = i << 16), so the high nibble passes through in — shares text with seta/ssv.cpp:2374
rtl/video/ssv_cached_sprite_renderer.sv:436 MAME's init_ssv builds m_tile_code[i] = bitswap<4>(i,0,1,2,3) << 16, which — shares text with seta/ssv.cpp:2360
rtl/video/ssv_cached_sprite_renderer.sv:438 identity (m_tile_code[i] = i << 16), so the high nibble passes through in — shares text with seta/ssv.cpp:2374

Arcade-StoneBall#
Cheese Chase, Stone Ball, Ultimate Tennis
database (builds only)

MeatCores
independent database

Source not published

Arcade-StunRunner#
S.T.U.N. Runner
database (builds only)

MeatCores
independent database

Source not published

Arcade-Suna8bit#
Brick Zone, Hard Head 2, Hard Head
database (builds only)

MeatCores
independent database

Source not published

Arcade-Tumble#
B.C. Story, Choky! Choky!, Cookie & Bibi, Fancy World - Earth of Crisis …
database (builds only)

MeatCores
independent database

Source not published

Arcade-VioStorm#
Violent Storm
database (builds only)

MeatCores
independent database

Source not published

Arcade-YellowCab#
Yellow Cab
database (builds only)

MeatCores
independent database

Source not published

Arcade-ZeroTeam#
Zero Team
database (builds only)

MeatCores
independent database

Source not published

StunRunner#

database (builds only)

MeatCores
independent database

Source not published

Batsugun#
Batsugun, Batsugun Special Version
TheJesusFish/Arcade-Batsugun_MiSTer @ 304a83e1 (approx.)
MAME compared: toaplan/batsugun.cpp + 5 related file(s)
Read: 18 HDL files, 15,314 lines (Quartus project)

Slop Cores
independent database

Mostly MAME

low

59%

Statements: 15 toward MAME

Cites MAME source — 14

rtl/batsugun/batsugun_game.v:2 This is intentionally a video/ROM-load baseline while the TP-030 board logic is built from the local MAME references and the V25 VHDL core.
rtl/batsugun/batsugun_game.v:457 MAME negates the GP9001 tilemap scroll internally, so a direct renderer must add the raw flipped value after mirroring X/Y.
rtl/batsugun/batsugun_game.v:2656 All official MAME sets share the same initial stack pointer.
rtl/batsugun/batsugun_game.v:3429 MAME's original-board origins are +42/+40/+38 X and +17 Y modulo 512.
rtl/batsugun/batsugun_game.v:3436 MAME traces prove flip-on is an exact 180-degree transform of flip-off.
rtl/batsugun/batsugun_game.v:3487 MAME models each GP9001 scroll plane as a 32x32 map of 16x16 tiles, with two 16-bit words per tile.
rtl/batsugun/batsugun_highscore.sv:291 MAME's readiness bytes are initialization sentinels, not permanent table contents.
rtl/batsugun/batsugun_inputs.v:18 MAME/Toaplan: U,D,L,R,B1,B2,B3,unknown.
rtl/batsugun/batsugun_sound_mixer.v:24 MAME routes each YM channel and the OKI output at 0.5.
rtl/batsugun/batsugun_sound_mixer.v:24 JT6295's numeric output is eight times smaller than MAME's normalized OKI stream, so a coefficient of 16 before the final divide by two gives the same scale.
README.md:3 This is a vibe coded, MAME-based Batsugun arcade core for the MiSTer FPGA.
README.md:12 MAME models Batsugun as:
README.md:37 Behavioral references: [MAME Toaplan `batsugun.cpp`](https://github.com/mamedev/mame/blob/master/src/mame/toaplan/batsugun.cpp), [MAME Toaplan `gp9001.cpp`](htt
README.md:42 NEC V25 core: Batsugun-local compact implementation, validated against MAME/FBNeo behavior.

Says it was translated, ported or taken from MAME — 1

README.md:8 **This core is vibe coded based on MAME.

Dogyuun#
Dogyuun
TheJesusFish/Arcade-Dogyuun_MiSTer @ fa6e03d0 (approx.)
MAME compared: toaplan/dogyuun.cpp + 6 related file(s)
Read: 27 HDL files, 11,941 lines (Quartus project)

Slop Cores
independent database

Mostly MAME

low

24%

Statements: 11 toward MAME

Cites MAME source — 9

rtl/dogyuun/dogyuun_gp9001_line_mixer.sv:2 MAME clears, renders GP1, clears priority, then renders opaque GP0 pixels.
rtl/dogyuun/dogyuun_gp9001_object_line.sv:1 The descriptor walk and pixel ordering follow MAME 0.288 draw_sprites(): later equal-priority objects win.
rtl/dogyuun/dogyuun_gp9001_object_line.sv:190 MAME forms an 18-bit code and applies modulo total_elements, leaving attribute bit 0 as code bit 16.
rtl/dogyuun/dogyuun_gp9001_snapshot.sv:60 MAME presents current tile/scroll state with object RAM from the preceding display snapshot.
rtl/dogyuun/dogyuun_inputs.sv:18 MAME/Toaplan: U,D,L,R,B1,B2,B3,unknown.
rtl/dogyuun/dogyuun_palette_snapshot.sv:1 MAME renders each frame with one coherent palette state.
rtl/dogyuun/dogyuun_sound_mixer.sv:21 MAME routes both YM channels and the OKI output at 0.5.
rtl/dogyuun/dogyuun_v25_cpu.sv:1642 MAME's V20 timing is ten processor clocks here; the compact escape path supplies eleven half-clocks.
README.md:3 This is a vibe coded, MAME-based Dogyuun arcade core for the MiSTer FPGA.

Says it matches, follows or was checked against MAME — 2

rtl/dogyuun/dogyuun_gfx_repack.sv:2 The logical renderer address remains identical to MAME's region layout.
rtl/dogyuun/dogyuun_gp9001_snapshot.sv:1 Freeze CPU-mutating GP9001 tile and scroll state during vblank so every visible frame is rendered from one coherent state, matching MAME's update.

FixEight#
FixEight - Jigoku no Eiyuu Densetsu
TheJesusFish/Arcade-FixEight_MiSTer @ 3dcf5c6f (approx.)
MAME compared: toaplan/fixeight.cpp + 8 related file(s)
Read: 42 HDL files, 14,016 lines (Quartus project)

Slop Cores
independent database

Mostly MAME

low

23%

Statements: 16 toward MAME

Cites MAME source — 15

rtl/fixeight/fixeight_gp9001_line_mixer.sv:1 Resolve TP-026's one GP9001 tile/object line with MAME priority semantics.
rtl/fixeight/fixeight_gp9001_object_line.sv:1 The descriptor walk and pixel ordering follow MAME 0.288 draw_sprites(): later equal-priority objects win.
rtl/fixeight/fixeight_gp9001_object_line.sv:158 MAME's 18-bit descriptor code is reduced modulo that element count.
rtl/fixeight/fixeight_gp9001_object_line.sv:188 MAME forms an 18-bit descriptor code and applies modulo 2^16 elements.
rtl/fixeight/fixeight_gp9001_snapshot.sv:60 MAME presents current tile/scroll state with object RAM from the preceding display snapshot.
rtl/fixeight/fixeight_inputs.sv:19 MAME port bits are U,D,L,R,B1,B2.
rtl/fixeight/fixeight_palette_snapshot.sv:1 MAME renders each frame with one coherent palette state.
rtl/fixeight/fixeight_sound_mixer.sv:31 MAME routes both YM channels and OKI at 0.5.
rtl/fixeight/fixeight_sound_mixer.sv:33 JTFrame decodes OSD bits 7:6 with XOR 2: 0=Very Low, 1=Low, 2=High (the unchanged default/MAME reference), 3=Very High.
rtl/fixeight/fixeight_text.sv:1 SPDX-License-Identifier: BSD-3-Clause TP-026 dynamic 8x8 text layer with MAME 0.288 line select/scroll semantics.
rtl/fixeight/fixeight_text.sv:165 MAME programs per-destination-line scrolly as lineselect[y] - y. Its FixEight tilemap Y offset is already absorbed by the visible-area transform, so the low byte of lineselect is the effective character row.
rtl/fixeight/fixeight_v25_cpu.sv:1646 MAME's V20 timing is ten processor clocks here; the compact escape path supplies eleven half-clocks.
README.md:3 This is a vibe coded, MAME-based FixEight arcade core for the MiSTer FPGA, implementing Toaplan's 1992 TP-026 hardware.
README.md:10 MAME models FixEight as:
README.md:50 Behavioral references: [MAME 0.288 Toaplan `fixeight.cpp`](https://github.com/mamedev/mame/blob/mame0288/src/mame/toaplan/fixeight.cpp), [MAME 0.288 Toaplan `gp

Says it matches, follows or was checked against MAME — 1

rtl/fixeight/fixeight_gp9001_snapshot.sv:1 Freeze CPU-mutating GP9001 tile and scroll state during vblank so every visible frame is rendered from one coherent state, matching MAME's update.

Ghox#
Ghox
TheJesusFish/Arcade-Ghox_MiSTer @ 6531398f (approx.)
MAME compared: toaplan/ghox.cpp + 5 related file(s)
Read: 35 HDL files, 13,745 lines (Quartus project)

Slop Cores
independent database

Mostly MAME

low

33%

Statements: 22 toward MAME

Cites MAME source — 21

rtl/ghox/ghox_game.sv:214 JTFrame's game-facing signals are active-low, while MAME's Ghox IN1/IN2/SYS bytes are active-high (00 idle).
rtl/ghox/ghox_gfx_repack.sv:10 MAME 0.288's GP9001 layouts decode this region as 8192 16x16 tiles or 32768 8x8 sprite elements and wrap element codes to that population.
rtl/ghox/ghox_gp9001_object_line.sv:1 The descriptor walk and pixel ordering follow MAME 0.288 draw_sprites(): later equal-priority objects win.
rtl/ghox/ghox_gp9001_object_line.sv:127 MAME 0.288 layout lists the source planes as {upper+8, upper, lower+8, lower}.
rtl/ghox/ghox_gp9001_object_line.sv:128 A same-frame MAME/RTL palette snapshot proves that order is pen bits 3 down to 0.
rtl/ghox/ghox_gp9001_object_line.sv:197 MAME forms an 18-bit code and applies modulo total_elements, leaving attribute bit 0 as code bit 16.
rtl/ghox/ghox_gp9001_tile_line.sv:116 MAME 0.288 layout_16x16 lists the source planes as {upper+8, upper, lower+8, lower}.
rtl/ghox/ghox_gp9001_tile_line.sv:117 A same-frame MAME/RTL palette snapshot proves that order is pen bits 3 down to 0.
rtl/ghox/ghox_gp9001_video.sv:4 Ghox has one GP9001, so this wrapper applies only the per-GP priority rule from MAME 0.288: a nontransparent object pixel wins when its priority is greater than or equal to the tile pixel's priority.
rtl/ghox/ghox_main_decode.sv:1 Exact TP-021 MC68000 word-bus decode pinned to MAME 0.288 ghox.cpp.
rtl/ghox/ghox_rom_loader.sv:52 The MRA's 16-bit main interleave is emitted in MAME address order, so the even byte belongs in DQ[15:8].
rtl/ghox/ghox_sound.sv:3 The CPU is the Ghox-observed, MAME-pinned VHDL subset.
rtl/ghox/ghox_sound_restore.sv:3 Real-ROM/MAME proof establishes a one-byte command mailbox at shared offset zero.
rtl/ghox/ghox_sound_restore.sv:131 Runtime intent tracking is deliberately limited to the protocol classes proven by the Ghox ROM and MAME traces.
rtl/ghox/z180/T80.vhd:955 Last flag assignment wins: MAME 0.288 OTIM is exactly N | (B' == 0 ?
rtl/ghox/z180/ghox_hd647180.vhd:6 Semantics are pinned to MAME 0.288; see docs/HD647180_PROOF.md.
rtl/ghox/z180/ghox_hd647180.vhd:231 MAME-pinned internal I/O read values needed by the MCU subset.
README.md:3 This is a vibe coded, MAME-based Ghox arcade core for the MiSTer FPGA.
README.md:17 MAME models Ghox as:
README.md:44 Behavioral references: [MAME Toaplan `ghox.cpp`](https://github.com/mamedev/mame/blob/master/src/mame/toaplan/ghox.cpp), [MAME Toaplan `gp9001.cpp`](https://git
README.md:49 HD647180X-compatible core: Ghox-local wrapper around a BSD-licensed T80 derivative, extended for the Z180 MMU, internal I/O and RAM, and the observed OTIM behav

Says it was translated, ported or taken from MAME — 1

README.md:12 **This core is vibe coded based on MAME.

GrindStormer#
V-Five
TheJesusFish/Arcade-GrindStormer_MiSTer @ 11b2dfda (approx.)
MAME compared: toaplan/vfive.cpp + 6 related file(s)
Read: 28 HDL files, 12,320 lines (Quartus project)

Slop Cores
independent database

Mostly MAME

low

31%

Statements: 13 toward MAME

Cites MAME source — 12

rtl/grind_stormer/grind_stormer_gp9001_line_mixer.sv:1 Resolve TP-027's one GP9001 tile/object line with MAME priority semantics.
rtl/grind_stormer/grind_stormer_gp9001_object_line.sv:1 The descriptor walk and pixel ordering follow MAME 0.288 draw_sprites(): later equal-priority objects win.
rtl/grind_stormer/grind_stormer_gp9001_object_line.sv:156 MAME's 18-bit descriptor code is reduced modulo that element count.
rtl/grind_stormer/grind_stormer_gp9001_object_line.sv:185 MAME forms an 18-bit descriptor code and applies modulo 2^16 elements.
rtl/grind_stormer/grind_stormer_gp9001_snapshot.sv:60 MAME presents current tile/scroll state with object RAM from the preceding display snapshot.
rtl/grind_stormer/grind_stormer_inputs.sv:18 MAME/Toaplan: U,D,L,R,B1,B2,unknown,unknown.
rtl/grind_stormer/grind_stormer_palette_snapshot.sv:1 MAME renders each frame with one coherent palette state.
rtl/grind_stormer/grind_stormer_rom_identity.sv:4 The program CRC32 identifies the three official MAME 0.288 sets without relying on filenames or MRA ordering metadata.
rtl/grind_stormer/grind_stormer_rom_loader.sv:40 Program uses MAME ROM_LOAD16_WORD_SWAP: source byte 0 becomes the low byte of the CPU word.
rtl/grind_stormer/grind_stormer_sound.sv:69 Grind Stormer's encrypted bootstrap is a live two-CPU protocol: MAME shows the 68000 streaming changing tables while the V25 expands its program.
rtl/grind_stormer/grind_stormer_v25_cpu.sv:1643 MAME's V20 timing is ten processor clocks here; the compact escape path supplies eleven half-clocks.
README.md:3 This is a vibe coded, MAME-based Grind Stormer arcade core for the MiSTer FPGA.

Says it matches, follows or was checked against MAME — 1

rtl/grind_stormer/grind_stormer_gp9001_snapshot.sv:1 Freeze CPU-mutating GP9001 tile and scroll state during vblank so every visible frame is rendered from one coherent state, matching MAME's update.

ITech32#
BloodStorm, Street Fighter: The Movie, Time Killers
TheJesusFish/Arcade-ITech32_MiSTer @ 193921fc (approx.)
MAME compared: itech/itech32.cpp + 2 related file(s)
Read: 25 HDL files, 9,345 lines (Quartus project)

Slop Cores
independent database

Mostly MAME

low

69%

Statements: 27 toward MAME

Cites MAME source — 25

rtl/itech32/itech32_blitter.sv:4 This is a sequential, stall-safe implementation of the behavior modeled by MAME's itech32_v.cpp.
rtl/itech32/itech32_blitter.sv:358 MAME rectangle::contains() is inclusive at the bottom edge.
rtl/itech32/itech32_blitter.sv:750 Width/X are live command-3 row-reload values in MAME.
rtl/itech32/itech32_blitter.sv:1279 MAME raises the blitter interrupt only after the command has synchronously mutated VRAM.
rtl/itech32/itech32_core.sv:74 MAME's separate v1.10/v1.11 init address made those sets hang on MiSTer.
rtl/itech32/itech32_core.sv:223 CPU and sound rates retain their board frequencies when the 48 MHz MAME carrier is selected.
rtl/itech32/itech32_core.sv:242 MAME toggles the phase before returning the side-effecting special read.
rtl/itech32/itech32_inputs.sv:15 Direct MAME DIP values: bit 0 -> mask 0x00100000 (SW1:4), through bit 3 -> mask 0x00800000 (SW1:1).
rtl/itech32/itech32_main_bus.sv:31 Configuration-time contents only: MAME's all-zero BloodStorm NVRAM reproduces the invalid stock-score table; FF in byte8000..FFFF makes the game's own ROM install its defaults (native cure54F5529D).
rtl/itech32/itech32_main_bus.sv:363 MAME's itech020_map uses zero for unhandled SFTM reads; the ROM's 0x041107 probe relies on it.
rtl/itech32/itech32_main_bus.sv:442 MAME installs SFTM's handler across this dword with a 000000ff mask.
rtl/itech32/itech32_main_bus.sv:542 MAME bloodstm_paletteram_w folds an odd-word MSB-only write onto that word's LSB.
rtl/itech32/itech32_main_bus.sv:924 MAME 0.288 leaves this SFTM window unpopulated and returns zero.
rtl/itech32/itech32_mame_pll.sv:1 SPDX-License-Identifier: GPL-2.0-or-later Second always-locked carrier used by SFTM's optional MAME timing profile.
rtl/itech32/itech32_scanout.sv:55 MAME masks only the first source coordinate and then walks linearly, so a 384-pixel line beginning near the end of a source row legitimately continues into the next row.
rtl/itech32/itech32_scanout.sv:207 MAME allocates guard rows outside each logical 512x1024 plane and fills them with logical 16'h00ff.
rtl/itech32/itech32_tg68_bus_adapter.sv:22 MAME's ITech32 driver copies the first 0x80 program-ROM bytes to address zero before releasing the 68EC020.
rtl/memory/itech32_ddr_memory.sv:576 MAME wraps every ITech32 blitter source byte by the actual 0x2080000-byte SFTM GROM region.
rtl/memory/itech32_ddr_memory.sv:1168 MAME copies the first 0x80 bytes of program ROM to RAM before releasing reset.
rtl/memory/itech32_ddr_memory.sv:1184 MAME initializes each 16-bit framebuffer entry to logical 0x00ff.
README.md:3 This is a vibe coded, MAME-based Incredible Technologies ITech32 arcade core for the MiSTer FPGA.
README.md:12 MAME 0.288 models the supported ITech32 boards as:
README.md:24 MAME is a behavioral reference here, not proof of original-board oscillator or analog characteristics.
README.md:30 | Game | Version | MAME set |
README.md:82 Behavioral references: [MAME ITech32 driver](https://github.com/mamedev/mame/blob/mame0288/src/mame/itech/itech32.cpp), [MAME ITech32 video](https://github.com/

Says it matches, follows or was checked against MAME — 1

rtl/itech32/itech32_scanout.sv:428 Origin and scroll programming is frame-atomic, matching MAME's complete frame screen_update.

Says it was translated, ported or taken from MAME — 1

README.md:7 **This core is vibe coded based on MAME.

KnuckleBash#
Knuckle Bash
TheJesusFish/Arcade-KnuckleBash_MiSTer @ 4a55363b (approx.)
MAME compared: toaplan/kbash.cpp + 6 related file(s)
Read: 46 HDL files, 11,855 lines (Quartus project)

Slop Cores
independent database

Mostly MAME

low

44%

Statements: 24 toward MAME

Cites MAME source — 23

rtl/knuckle_bash/knuckle_bash_gp9001_cpu.sv:5 The four decoded ports follow MAME's GP9001 behavior: 0x0: VRAM word pointer write 0x4: VRAM read/write with post-increment 0x8: low-byte scroll/control selector write (data & 8'h8f) 0xc: status read or selected scroll/control write
rtl/knuckle_bash/knuckle_bash_gp9001_cpu.sv:280 MAME accepts only the low-byte selector.
rtl/knuckle_bash/knuckle_bash_gp9001_object_line.sv:5 Object descriptors are consumed in ascending RAM order, exactly as MAME 0.288 draw_sprites() does.
rtl/knuckle_bash/knuckle_bash_gp9001_object_line.sv:148 MAME's default GP9001 sprite offsets are -0x1cc/-0x17b in X and -0x1ef/-0x108 in Y. Negating the adjusted scroll values yields these modulo-512 origins.
rtl/knuckle_bash/knuckle_bash_gp9001_tile_line.sv:198 These are the MAME 0.288 GP9001 tilemap equations reduced modulo 512.
rtl/knuckle_bash/knuckle_bash_gp9001_video.sv:80 MAME clears the destination bitmap to palette index zero before drawing nonzero GP9001 pens.
rtl/knuckle_bash/knuckle_bash_highscore.sv:2 The MRA supplies MAME's exact descriptor at index 4 and a 264-byte NVRAM image at index 2.
rtl/knuckle_bash/knuckle_bash_inputs.sv:3 Convert MiSTer's active-high HPS joystick words to the active-high TP-023 input bytes exposed by MAME.
rtl/knuckle_bash/knuckle_bash_inputs.sv:18 MAME bit 6 is physically unpopulated; B2 is Jump and B1 Attack.
rtl/knuckle_bash/knuckle_bash_inputs.sv:35 MAME: unknown, start2, start1, coin2, coin1, test, tilt, service1.
rtl/knuckle_bash/knuckle_bash_jt6295.sv:19 The top remains identical to the protected JT6295 integration except that it binds the board-local serial scheduler with MAME-compatible inclusive phrase-end semantics.
rtl/knuckle_bash/knuckle_bash_jt6295_serial.sv:120 MAME counts both nibbles of the inclusive stop byte.
rtl/knuckle_bash/knuckle_bash_sdram.sv:113 Preserve the renderer's MAME-logical address while moving the plane selector from the MSB to the physical word LSB.
rtl/knuckle_bash/knuckle_bash_sdram_loader.sv:87 The HPS stream and ROM-valid CRC remain the authoritative raw MAME layout; only the physical bank-1 destination address is transformed.
rtl/knuckle_bash/knuckle_bash_sound.sv:3 The ROM-based encrypted V25 owns the low 2 KiB shared-RAM window and reaches YM2151/OKI devices at the MAME-audited map.
rtl/knuckle_bash/knuckle_bash_sound.sv:220 MAME maps 80000-87fff with mirror mask 78000.
rtl/knuckle_bash/knuckle_bash_sound.sv:287 Preserve their exact default/MAME behavior while production always supplies a known two-bit value.
rtl/knuckle_bash/knuckle_bash_sound_mixer.sv:23 MAME normalizes YM samples by 32768 and OKI samples by 2048, then routes each YM output and OKI to the mono speaker at gain 0.5.
rtl/knuckle_bash/knuckle_bash_sound_mixer.sv:30 High is the exact MAME route.
rtl/knuckle_bash/knuckle_bash_v25_cpu.sv:1642 MAME's V20 timing is ten processor clocks here; the compact escape path supplies eleven half-clocks.
README.md:3 This is a vibe coded, MAME-based Knuckle Bash arcade core for the MiSTer FPGA, implementing Toaplan's 1993 TP-023 hardware.
README.md:8 MAME models Knuckle Bash as:
README.md:56 Behavioral references: [MAME 0.288 Toaplan `kbash.cpp`](https://github.com/mamedev/mame/blob/mame0288/src/mame/toaplan/kbash.cpp), [MAME Toaplan `gp9001.cpp`](h

Says it matches, follows or was checked against MAME — 1

rtl/knuckle_bash/knuckle_bash_gp9001_snapshot.sv:7 In parallel it preserves the outgoing snapshot's 1024-word object window, giving the renderer current tile/scroll state with the preceding object state, matching MAME 0.288's update/eof ordering.

Arcade-GingaNin#
Ginga Ninkyouden
kuzearcade/Arcade-GingaNin_MiSTer @ 1dc66adb
MAME compared: jaleco/ginganin.cpp
Read: 26 HDL files, 10,705 lines (Quartus project)

kuzecores
independent database

Both

medium

23%

Statements: 4 toward hardware, 54 toward MAME

Cites hardware documentation that MAME's driver does not — 2

rtl/gingan/gn_sound.sv:6 Map (ginganin.cpp:390-398): 0000-07FF RAM 0800-0807 MC6840
rtl/gingan/gn_sound.sv:50 `hold` freezes the board's clock (6809, PTM, chips) from the moment every CPU is parked until the release; the state bus reads/writes the words below (ss_a, local word address; data one clock after the address, registered twice): 000-7FF RA

Reports a measurement taken on the original PCB — 1

GingaNin.sv:323 REFRESH_CYCLES 740 at 96 MHz (~7.7 us); the controller's default 850 was measured corrupting reads on silicon in the NMK16 work.

Notes where it differs from MAME — 1

README.md:29 The attract demo and scripted play diverge from MAME's later (GN-7, open).

Cites MAME source — 48

GingaNin.sv:10 * One 16-bit input word (MAME's P1_P2: both players, coins and starts) and one 16-bit DSW word (<switches> bytes 0 and 1).
GingaNin.sv:16 * No Service key: the board has none (MAME maps none).
GingaNin.sv:236 Bytes 0 and 1 are the low and high bytes of MAME's DSW word at 070002.
GingaNin.sv:248 Keyboard: MAME's default bindings, always live, ORed with the pads.
GingaNin.sv:294 Inputs: MAME's P1_P2 word at 070000, active low (ginganin.cpp): bit 0 up, 1 down, 2 left, 3 right, 4 B1, 5 B2 (player 1) bit 6 up, 7 down, 8 left, 9 right, 10 B1, 11 B2 (player 2) bit 12 coin 1, 13 coin 2, 14 start 1, 15 start 2 M
rtl/cheats.sv:1 Cheat engine — applies Pugsy MAME-database pokes to work RAM once a frame.
rtl/cheats.sv:34 Poke semantics follow MAME's "run" state: the value is written every frame for as long as the cheat is enabled, which is what makes "infinite" cheats hold against the game decrementing the counter.
rtl/gingan/gn_main.sv:5 Map (ginganin.cpp:374-387), byte addresses: 000000-01FFFF program ROM (writes ignored: the POST writes 10000-13FFF) 020000-023FFF work RAM 030000-0307FF text VRAM 040000-0407FF sprite RAM 050000-0507FF palette 06000
rtl/gingan/gn_main.sv:14 IRQ1 (MAME: irq1_line_hold at vblank) is raised at the start of line 240 and held until one level-1 interrupt-acknowledge cycle (MS1-23).
rtl/gingan/gn_main.sv:36 inputs, active low (MAME's P1_P2 and DSW words)
rtl/gingan/gn_main.sv:190 ---------------------------------------------------------------- latch one pulse per write cycle to 06000E (MAME: m_soundlatch->write(data), then pulse NMI): the low byte of the register after the write
rtl/gingan/gn_ptm6840.sv:1 Motorola MC6840 programmable timer module, written against MAME's machine/6840ptm.cpp (the oracle; no existing HDL was found, docs/PLAN.md fact 6).
rtl/gingan/gn_ptm6840.sv:3 Clocked by the E enable only: this board has no external timer clocks and no gate inputs (MAME: set_external_clocks(0, 0, 0)).
rtl/gingan/gn_ptm6840.sv:6 Registers (A2:A0), as MAME: W 0 CR1 if CR2 bit 0, else CR3 R 0 - W 1 CR2 R 1 status (bit 7 = any IRQ) W 2/4/6 MSB buffer (shared) R 2/4/6 counter MSB (LSB latched) W 3/5/7 latch n = {M
rtl/gingan/gn_ptm6840.sv:15 Counting follows MAME's reload_counter / state_changed: 16-bit continuous (modes 0, 2): expire after latch+1 E; the output toggles dual 8-bit: (lsb+1)*msb E with the output low, lsb+1 with it high one-shot (modes 4, 6): 1 E with the output
rtl/gingan/gn_ptm6840.sv:20 The output pins are MAME's out_cb: they follow a toggle only while the output is enabled, and go low when a control write clears the enable.
rtl/gingan/gn_ptm6840.sv:24 Ginga Ninkyouden (Q1, docs/known-issues.md GN-3) uses timer 1 only: the handler holds reset (CR1 = 1), loads 0x4800, and releases with CR1 = 0x92 (continuous, internal clock, output enabled, no IRQ); output 1 is the 6809's IRQ (MAME: o1_cal
rtl/gingan/gn_ptm6840.sv:51 MAME's m_output
rtl/gingan/gn_ptm6840.sv:52 MAME's timer armed
rtl/gingan/gn_ptm6840.sv:80 MAME's reset: CR1 = 1 (timers held)
rtl/gingan/gn_ptm6840.sv:85 counting and expiry (MAME's state_changed)
rtl/gingan/gn_ptm6840.sv:100 register writes (MAME's write)
rtl/gingan/gn_sound.sv:1 Ginga Ninkyouden sound board (docs/PLAN.md 1.3, 2.5): an MC6809 on the 3.579545 MHz crystal (E = /4), 2 KB of RAM, the MC6840 whose output 1 is the 6809's IRQ, the sound latch whose write pulses NMI, a YM2149 and a Y8950 (both write-only in
rtl/gingan/gn_sound.sv:6 Map (ginganin.cpp:390-398): 0000-07FF RAM 0800-0807 MC6840
rtl/gingan/gn_sound.sv:33 audio: MAME's mix (Y8950 at 1.0, each YM2149 channel at 0.10)
rtl/gingan/gn_sound.sv:167 latch and NMI (MAME: generic_latch_8, pulse_input_line(NMI)); the pulse is held low for two E cycles so the 6809's falling-Q sample sees it
rtl/gingan/gn_sound.sv:310 ---------------------------------------------------------------- mix MAME's YM2149 is a resistor model into a 1 kohm load (ay8910.cpp build_single_table, ym2149_param, not normalised): a channel outputs table[volume] (0.4159 at volume 0 up
rtl/gingan/gn_sound.sv:314 In WAV units that is table x 3277, with a DC floor of 1,363 per channel; the board's output is AC-coupled, so the mixer keeps MAME's AC part, (table[v] - table[0]) x 3277 (GN-5).
rtl/gingan/gn_sound.sv:329 Measured against MAME's YM2149-only WAV over 90 s of play (GN-5), the table alone is 4.5 dB low in every band; the level is calibrated to MAME's RMS (x 107/64), as MS1Z-13 calibrated its SSG.
rtl/gingan/gn_sprline.sv:3 256 entries of four words (MAME's draw_sprites): Y and X 9-bit signed ((v & 0xFF) - (v & 0x100)), code [13:0] with flip X [14] and flip Y [15], colour [15:12] of word 3.
rtl/gingan/gn_sprline.sv:7 MAME draws them in index order, so a later entry covers an earlier one; the engine walks the entries in the same order and a write simply overwrites the line buffer.
rtl/gingan/gn_tilerow.sv:3 The map is NCOLS x 32 tiles in column order (MAME's TILEMAP_SCAN_COLS: tile index = col * 32 + row), one word per tile: code [11:0], colour [15:12]; tile = code mod NTILES (1,024 here, a mask).
rtl/gingan/gn_tilerow.sv:5 For source line `line` (0-255 of MAME's 256-line frame) the engine draws the 17 tiles covering screen x 0-255 at scroll (sx, sy): map pixel (x + sx) mod (NCOLS*16), line (line + sy) mod 512 (MAME's tilemap scrolling).
rtl/gingan/gn_video.sv:5 Raster (D3): a 6 MHz dot (ce_pix = clk / 8), 400 dots x 250 lines = exactly 100,000 dots a frame = 60.000 Hz, MAME's frame period.
rtl/gingan/gn_video.sv:6 Lines are numbered as MAME's 256-line frame: 16-239 are visible (224), 240 starts vblank (IRQ1), the frame wraps after 249.
rtl/gingan/gn_video.sv:15 Composition (GN-2's model, exact against MAME): text over sprites over FG over BG; pen 15 is clear on text, sprites and FG; BG disabled shows pen 0.
rtl/gingan/gn_video.sv:17 Palette RGBx_444 looked up at scan-out; an entry never written shows MAME's default colour (GN-1).
rtl/gingan/gn_video.sv:326 MAME's default palette (GN-1)
rtl/gingan/gn_y8950.sv:1 Yamaha Y8950 (MSX-AUDIO) for Ginga Ninkyouden: no open implementation exists (docs/PLAN.md fact 3), so it is composed the way MAME's ymfm builds it (ymfm_opl.cpp y8950): FM jtopl (YM3526, jotego/jtopl, vendored unmodified) ADPCM gn_adp
rtl/gingan/gn_y8950.sv:15 The chip is write-only on this board (MAME maps no read), and its IRQ, timers and I/O ports are unused (GN-3).
README.md:3 **Ginga Ninkyouden** (Jaleco, 1987) for the MiSTer FPGA platform: one bitstream for both MAME sets, `ginganin` and `ginganina`.
README.md:14 It follows the methodology of Arcade-NMK16_MiSTer, Arcade-SandScrp_MiSTer, Arcade-JalecoMS1BCD_MiSTer and Arcade-JalecoMS1Z_MiSTer: MAME is the reference, and e
README.md:21 **Runs on the DE10-Nano.** Measured against MAME 0.289:
README.md:23 **video block:** 4,098 / 4,098 MAME frames reproduced pixel for pixel from MAME's own state (attract, scripted play, Flip Screen; GN-6).
README.md:25 The rest are tearing: the game rewrites sprites while the picture is on screen, and MAME draws the frame once, afterwards.
README.md:30 Each chip is within 0.21 dB of MAME's level, and the mix has an envelope correlation of 0.952 (GN-5).
README.md:67 `sim/rtl/video_state`: the video block against MAME states;
README.md:78 **MAME** `jaleco/ginganin.cpp` (driver by **Luca Elia**), with MAME's **ymfm** (Aaron Giles; `gn_adpcmb.sv` is a port of its ADPCM-B channel) and 6840 PTM: the

Says it matches, follows or was checked against MAME — 3

rtl/gingan/gn_sound.sv:289 ---------------------------------------------------------------- YM2149 ZX-Spectrum_MISTer's copy (it matches MAME's period-0 rule, GN-5): BDIR/BC = 1/1 latches the address, 1/0 writes data; SEL 0 = no /2 (MAME's default YM2149), MODE 0 = t
rtl/gingan/gn_video.sv:11 With flip (vregs[6] bit 0 clear) the whole 256 x 256 frame is turned 180 degrees: the engines draw source line 255 - y and the buffers are read mirrored (verified against MAME's flipped output, GN-2's sweep).
README.md:39 **board:** the attract matches MAME's frames on the board.

Says it was translated, ported or taken from MAME — 1

rtl/gingan/gn_adpcmb.sv:1 The Y8950's DELTA-T (ADPCM-B) unit: a port of MAME's ymfm adpcm_b_channel (3rdparty/ymfm/src/ymfm_adpcm.cpp, Aaron Giles, BSD-3-Clause), the oracle this core is measured against (docs/PLAN.md 2.5; GN-5).

Shares text with the MAME driver without saying so — 2

rtl/gingan/gn_ptm6840.sv:4 clocks and no gate inputs (MAME: set_external_clocks(0, 0, 0)). — shares text with jaleco/ginganin.cpp:506
rtl/gingan/gn_tilerow.sv:11 gfx_8x8x4_col_2x2_group_packed_msb: row r is bytes 4r..4r+3 for the left 8 — shares text with jaleco/ginganin.cpp:474

Arcade-JalecoMS1BCD#
64th. Street: A Detective Story, Phantasm, Big Striker, Chimera Beast …
kuzearcade/Arcade-JalecoMS1BCD_MiSTer @ 8c7a3b01
MAME compared: jaleco/megasys1.cpp + 6 related file(s)
Read: 30 HDL files, 11,973 lines (Quartus project)

kuzecores
independent database

Mostly MAME

medium

66%

Statements: 5 toward hardware, 114 toward MAME

Cites hardware documentation that MAME's driver does not — 2

rtl/ms1bcd/ms1_sound.sv:191 The sound 68000 and the YM2151 do not exist on System D. Held in reset rather than removed so one netlist serves all three boards; the mode byte is a false path (MS1-44), so this costs nothing in timing.
README.md:33 `iosim` is MAME's simulated I/O protection, `mcu` is the real TLCS-90 (TMP91640) running its dumped ROM.

Notes where it differs from MAME — 3

rtl/jaleco/ms1_video.sv:26 The palette bit layout differs by MODE, and MAME's own header comment about it is wrong.
rtl/tlcs90/tlcs90.sv:43 Still deferred: the TSET/LDA dead opcode space MAME's own reference model can't execute either — this is the CPU core's entire real opcode table, complete.
rtl/tlcs90/tlcs90_periph_ref.sv:47 - Watchdog (WDMOD/WDCR), serial (SCMOD/SCCR/SCBUF — not even mapped for this specific TLCS-90 variant in the reference), ADC (ADREG/ADMOD), stepping-motor mode (SMMOD's *functional* effect, though the register itself is stored and read back

Cites MAME source — 84

MS1BCD.sv:73 Only cybattlr is ROT90 in MAME; the other 16 sets are ROT0 and want Horz.
MS1BCD.sv:375 hayaosi1 and both peekaboo sets set it -- MAME overrides hayaosi1's OKIs to 2 MHz ("correct speed, but unknown OSC + divider combo") and derives System D's as XTAL(8MHz)/4.
MS1BCD.sv:384 Keyboard: MAME's own default bindings, always live, ORed with the pads.
MS1BCD.sv:389 Where that lands depends on the layout: DSW2 bit 7 on the generic boards, SYSTEM bit 3 on hayaosi1, SYSTEM bit 1 on peekaboo (the input MAME labels "test").
MS1BCD.sv:482 generic everything else -- MAME's INPUT_PORTS_START(megasys1_generic)
MS1BCD.sv:522 --- peekaboo: P1 and P2 are 8-bit PADDLES, not joysticks, clamped to the range MAME's PORT_MINMAX gives them.
MS1BCD.sv:540 SYSTEM's low bits 0 and 1 are COIN3 and COIN4, which MAME's comments name "service" and "test" -- they are coin slots, not the service switch.
MS1BCD.sv:941 MAME returns 0 from both OKI status registers, and every audio measurement this project has taken was taken against that.
MS1BCD.sv:973 Stereo: ms1_sound.sv pans the YM2151 and the two OKIM6295s the way MAME's machine configuration does.
rtl/cheats.sv:1 Cheat engine — applies Pugsy MAME-database pokes to work RAM once a frame.
rtl/cheats.sv:23 Poke semantics follow MAME's "run" state: the value is written every frame for as long as the cheat is enabled, which is what makes "infinite" cheats hold against the game decrementing the counter.
rtl/jaleco/ms1_iomcu.sv:9 TMP91640 internal map, from MAME's cpu/tlcs90/tlcs90.cpp tmp91640_mem: 0000-3FFF 16 KB internal ROM (the .mra's iomcu region; NEVER baked into the bitstream, see PLAN 2.3) FDC0-FFBF 512 B internal RAM FFC0-FFEF on-chip registers (th
rtl/jaleco/ms1_iomcu.sv:16 Everything else in the MCU's 20-bit space is the board's input latch, selected by the ADDRESS BANK -- MAME's mcu_capture_inputs_r takes offset>>16 and returns: 1 = P1, 2 = P2, 3 = DSW1, 4 = DSW2, 5 = SYSTEM, 7 = raise IRQ 2 on the MAIN CPU
rtl/jaleco/ms1_iomcu.sv:25 Host protocol (jaleco/megasys1.cpp): main CPU writes the protection port -> byte latched into `to_mcu`, and INT0 pulsed on the MCU MCU reads port 1 -> that byte MCU writes port 2 -> the answer main CPU r
rtl/jaleco/ms1_iomcu.sv:32 So the whole conversation is visible from the 68000 bus alone, which is what makes it checkable command by command against a MAME trace rather than by "the game boots" (docs/PLAN.md M2 gate 5).
rtl/jaleco/ms1_iomcu.sv:45 INT1 is the board's DISPLAY ENABLE, not a timer: MAME asserts it at scanline 16 (end of vblank) and clears it at 240 (start of vblank), so the MCU's whole command loop is paced by the video frame.
rtl/jaleco/ms1_iomcu.sv:116 INT1 is a LEVEL in MAME (assert/clear around the visible area) but the core latches irq_req internally and does not clear on take, so a held level would re-pend immediately and interrupt forever.
rtl/jaleco/ms1_prio.sv:4 MAME does NOT use it that way: it converts the PROM into sixteen "layer orders" at init (priority_create), by repeatedly asking which layer is on top of the remaining set, and then composites in that order -- a two-stage algorithm with a do
rtl/jaleco/ms1_prio.sv:20 Address, straight from the comment block in megasys1_v.cpp:
rtl/jaleco/ms1_sprites.sv:18 Order: MAME walks Object RAM DESCENDING (0x3fc down to 0, step 4) and the framebuffer write is FIRST-WRITER-WINS.
rtl/jaleco/ms1_sprites.sv:19 That makes the LAST entry frontmost, which contradicts megasys1_v.cpp's own comment ("From first in Object RAM (frontmost) to last") and the note carried into docs/PLAN.md 4.D item 8.
rtl/jaleco/ms1_sprites.sv:29 The framebuffer is one 256x256 plane of 9 bits {priority, colour, pen}, pen 15 meaning empty -- the same encoding MAME's 0x7fff fill uses.
rtl/jaleco/ms1_sprites.sv:291 source pixel inside the tile, with flip and MAME's mosaic filter
rtl/jaleco/ms1_sprites.sv:308 MAME's cliprect exactly: min_x 0, max_x 255, min_y 16, max_y 239 (megasys1.cpp set_visarea(0*8, 32*8-1, 2*8, 30*8-1)).
rtl/jaleco/ms1_sprites.sv:373 MAME then partially clears by pen, which is still not modelled -- MS1-17.
rtl/jaleco/ms1_tilemap.sv:67 TILES_PER_PAGE_X/Y are both 0x20, and the multipliers come straight from the eight tilemap_create() calls in ms1_tmap.cpp.
rtl/jaleco/ms1_tilemap.sv:69 Note 8x8 N=1 and N=2 are the SAME shape upstream; that is not a typo here, it is a duplicate in MAME.
rtl/jaleco/ms1_tilemap.sv:102 scan_8x8 / scan_16x16 from ms1_tmap.cpp.
rtl/jaleco/ms1_video.sv:18 SCREEN FLIP is a 180-degree rotation of the finished visible frame (docs/known-issues.md MS1-13), so it is applied here by mirroring the SAMPLE POINT rather than by flipping each layer and each sprite the way MAME does.
rtl/jaleco/ms1_video.sv:21 That is not an assumption: MAME was captured twice from the same point, flipped and not, and the two frames are rot180 of each other with zero differing pixels.
rtl/jaleco/ms1_video.sv:224 Measured against MAME on bigstrik's split scenes: the low group is the one whose attribute bit 3 is SET, not clear.
rtl/ms1bcd/ms1_main.sv:4 Built to be compared against MAME's own main-CPU bus trace (sim/oracle/ms1_bustrace.lua), which is docs/PLAN.md M2 gate (1).
rtl/ms1bcd/ms1_main.sv:35 000000-03FFFF ROM (one bank; there is no second one) 0C2000-0C2005 layer 0 scroll 0C2008-0C200D layer 1 scroll 0C2108 sprite bank -- MAME maps this .nopw(), so it is DECODED AND DISCARDED, not left to fall through
rtl/ms1bcd/ms1_main.sv:47 0E8000-0EBFFF scroll 0 VRAM ("scroll1") 0F0000 SYSTEM (read, 16 bits -- the six buttons are in the HIGH byte, which is why in_sys_hi exists; MS1-42) 0F8001 OKIM6295, low byte only 100000 protection (installed by in
rtl/ms1bcd/ms1_main.sv:60 MAME's ram_w says so in capitals -- "DON'T use COMBINE_DATA ...
rtl/ms1bcd/ms1_main.sv:68 All are HOLD_LINE in MAME, i.e. asserted until the CPU acknowledges.
rtl/ms1bcd/ms1_main.sv:143 megasys1_v.cpp's screen_vblank does buffer2 <- buffer <- live every vblank and draw_sprites reads buffer2, so the sprites on screen are those the CPU wrote two frames ago.
rtl/ms1bcd/ms1_main.sv:268 MAME's maps open with map.global_mask(0xfffff) on System B and 0x1fffff on System C, and the board really does ignore the high address lines.
rtl/ms1bcd/ms1_main.sv:292 monkelf has no protection device: the bootleg reads the five input ports DIRECTLY, at their own addresses just above the port the protected boards use (MAME's megasys1B_monkelf_map).
rtl/ms1bcd/ms1_main.sv:363 Then ROM 0x0030C6 does MOVEA.L ($080000).L,A0, gets 0x00000000 where MAME gets 0x0008000C, indexes off the null base, and copies low-ROM opcodes (0x4E75 RTS, 0x4DF9 LEA) into work RAM and on into the video registers -- which is the 0x4E7F t
rtl/ms1bcd/ms1_main.sv:732 MAME: scroll0: data -= ((data & 0x0f) > 0x0d) ?
rtl/ms1bcd/ms1_main.sv:767 prot == 2 (none) reads back 0, which is what MAME's iosim state does with no command table installed: the latch is never written.
rtl/ms1bcd/ms1_main.sv:840 ---- simulated protection (prot == 1), MAME's ip_select_w()
rtl/ms1bcd/ms1_main.sv:843 Anything else latches NOTHING and raises NOTHING -- MAME returns early, and a game that polls with a junk command must see no answer and no interrupt.
rtl/ms1bcd/ms1_main.sv:856 MAME masks the word to its low byte
rtl/ms1bcd/ms1_main.sv:858 IRQ2 has TWO sources on a simulated board, and MAME models both:
rtl/ms1bcd/ms1_main.sv:875 MAME's device_reset does the same, with the reason: "reset protection - some games expect this initial read without sending anything".
rtl/ms1bcd/ms1_main.sv:898 ---- System D's protection (prot == 3), MAME's protection_peekaboo_r/w.
rtl/ms1bcd/ms1_main.sv:900 Nothing like the B/C command table: there is no MCU device in system_D at all (peekaboo ships a dumped TMP91640 that MAME does not run), and the port is a plain 16-bit latch with three special read values.
rtl/ms1bcd/ms1_main.sv:1091 The interrupt-acknowledge cycle (FC = 111) is a real bus cycle on hardware -- the 68000 drives 0xFFFFFx with the level in A3:A1 -- but MAME services autovectors internally and its memory tap never sees it.
rtl/ms1bcd/ms1_main.sv:1113 MAME's set_input_line/HOLD_LINE is autovectored.
rtl/ms1bcd/ms1_sound.sv:28 MAME returns 0 from both OKI status registers unless the game is hachoo (`m_ignore_oki_status`, default 1), with the comment that it "fixes the music tempo in avspirit, 64street, astyanax etc. but makes most of the effects in hachoo disappe
rtl/ms1bcd/ms1_sound.sv:43 Sample clock, from the .mra's game-mode byte bit 4: 4 MHz (48/12) on System B and C, 2 MHz (48/24) on hayaosi1 and on all of System D. MAME's hayaosi1 comment calls 2 MHz the "correct speed, but unknown OSC + divider combo"; system_D derive
rtl/ms1bcd/ms1_sound.sv:62 screen_flag bit 4: the main CPU holds the whole sound subsystem in reset through this one bit -- the sound 68000, the YM2151 and both OKIs (megasys1_v.cpp:253-267).
rtl/ms1bcd/ms1_sound.sv:152 Getting this wrong runs the chip's timers fast, and megasys1.cpp:673 notes the YM2151 clock is what decides the music tempo -- so it lands straight on the gate (3) write counts.
rtl/ms1bcd/ms1_sound.sv:185 The debug counters, the clock dividers and the latches deliberately stay on `reset` alone: MAME's write counts accumulate across a sound reset, and the clock does not stop.
rtl/ms1bcd/ms1_sound.sv:194 The OKIs stay on snd_rst: screen_flag bit 4 resets OKI 1 on System D too (megasys1_v.cpp screen_flag_w tests m_oki[0].found(), not the presence of a sound CPU).
rtl/ms1bcd/ms1_sound.sv:445 MAME's oki_status_r returns 0 unless m_ignore_oki_status is cleared
rtl/ms1bcd/ms1_sound.sv:526 ---------------------------------------------------------------- mix MAME: YM2151 routed at 0.80 to both channels, each OKI at 0.30.
rtl/ms1bcd/ms1bcd_core.sv:399 monkelf's priority PROM is in the bootleg's own nibble-packed format: MAME expands it at init with for (i = 0x1fe; i >= 0; i -= 2) ROM[i] = ROM[i+1] = (ROM[i/2] >> 4) & 0x0f; i.e. entry A comes from the HIGH nibble of raw byte A>>1, each ra
rtl/rom_cache_n.sv:7 Why (docs/hw-bringup.md, "Slowdown"): the real board and MAME run the 68000 with zero wait states from EPROM.
rtl/rom_cache_n.sv:8 Through the 1-line rom_cache1 56% of ROM bus cycles missed (the instruction stream and the game's ROM data-table reads thrash a single pair) and each miss is a ~10 clk_sys SDRAM round trip, 1-2 wait states — 13-20% of every frame spent stal
rtl/savestate/savestate_ui.sv:4 Slot 2 is on F5 and NOT F2 because this core's own keyboard map already uses F2 for the Service Mode toggle (MAME's binding for it), and both were acting on the same press -- found on the board, 2026-09-20.
rtl/tlcs90/tlcs90.sv:190 debug: pulses dbg_valid for one cycle at the start of each new instruction with that instruction's own PC — the same point in time MAME's `trace` debugger command reports from, directly diffable against a captured disassembly oracle trace.
rtl/tlcs90/tlcs90.sv:201 debug: live register state, sampled alongside dbg_pc/dbg_valid — purely additive, for root-causing oracle divergences against MAME's own debugger register readout (A/HL/F match MAME's TLCS-90 debug state symbols of the same name).
rtl/tlcs90/tlcs90.sv:427 Same OP_MUL/OP_DIV the PFX_G8 register-operand form already uses (reference: tlcs90.cpp:367-370, "case 0x12: case 0x13: OP(MUL+b0-0x12,16) R16(1,HL) I8(2,READ8())") — missing here entirely, same silent-OP_NOP-fallthrough class as the ADD ix
rtl/tlcs90/tlcs90.sv:439 Confirmed directly against the reference (cpu/tlcs90/tlcs90.cpp:372-373, "case 0x14: case 0x15: case 0x16: OP16(ADD,6) R16(1,IX+b0-0x14) I16(2,READ16())") — this specific base (unprefixed) form was missing from this table entirely (the cycl
rtl/tlcs90/tlcs90.sv:492 LDW ($FF00+w),mn — reuses OP_LD (MAME's own execute() merges "case LDW:" and "case LD|OP_16:" into the identical Write1_16(Read2_16()) path, tlcs90.cpp:1497-1499, so no new opcode is needed).
rtl/tlcs90/tlcs90.sv:496 Missing here entirely (reference: tlcs90.cpp:419-420) — same silent-fallthrough class as above.
rtl/tlcs90/tlcs90.sv:598 Table extracted directly from mame/src/devices/cpu/tlcs90/tlcs90.cpp's own OP()/OPCC()/OP16()/OPCC16() macro table (CT*2 = real clock cycles; conditional entries use the branch-taken result via the same test_cc() the EXECUTE stage itself us
rtl/tlcs90/tlcs90.sv:604 DJNZ's own not-taken cost (0x18/0x19 below) is a deliberate exception to "look it up in this table": the reference's own `OP(DJNZ,10)` (tlcs90.cpp:379/381) only ever sets `m_cyc_t` — `m_cyc_f` (the not-taken cost `Cyc_f()` charges when the
rtl/tlcs90/tlcs90.sv:880 XCF ("extra carry", bit 3) on INC/INCX/DEC/DECX: the reference (tlcs90.cpp's INC/INCX/DEC/DECX cases) computes F from the SZHV table alone (which never touches XCF) and then, as a genuinely separate step, sets XCF if-and-only-if the 8-bit r
rtl/tlcs90/tlcs90.sv:885 This core's own szhv_inc8()/szhv_dec8() never included that bit, so every one of their 4 callers (OP_INC/OP_DEC's 8-bit forms, OP_INCX/OP_DECX) was silently clearing XCF to 0 unconditionally instead — found via a register-state trace diff a
rtl/tlcs90/tlcs90.sv:1899 Two bugs lived here in turn: (1) SET/ RES always wrote to eff2/dout regardless of mode2, discarding the register form's result entirely (found via a register-state trace diff against a MAME oracle, docs/hw-bringup.md's GunNail investigation
rtl/tlcs90/tlcs90_periph_ref.sv:25 - Timers 0-3 (8-bit, or 16-bit paired per TMOD) and timer 4/5 (16-bit compare-match with independent TREG4/TREG5 match points) are REAL counters, matching t90_timer_callback/t90_timer4_callback exactly — this is the one part of the peripher
rtl/tlcs90/tlcs90_periph_ref.sv:70 This peripheral register map (`tmp90840_regs` in the reference's own `cpu/tlcs90/tlcs90.cpp`) is identical between the TMP90840 (NMK004's own role) and TMP91640 (the protection-MCU role) — confirmed directly, not assumed — so one module ser
rtl/tlcs90/tlcs90_periph_ref.sv:135 P1 external-read override + P2 write tap: the same shape as the P5/P6 pair above, added for the Jaleco TMP91640 I/O MCU role, where MAME installs port_read<1> and port_write<2> (mcu_port1_r / mcu_port2_w in jaleco/megasys1.cpp).
rtl/tlcs90/tlcs90_periph_ref.sv:593 MAME: the byte is an interrupt index + 2; our bit is that index - 3, hence data - 5.
README.md:3 Jaleco **Mega System 1**, types **B**, **C** and **D**, for the MiSTer FPGA platform — a from-scratch RTL implementation of the board's tilemap, sprite and prio
README.md:18 The simulation harnesses compare frames pixel-for-pixel with MAME captures, the 68000 bus against MAME's own trace, and every ROM byte through the real SDRAM co
README.md:33 `iosim` is MAME's simulated I/O protection, `mcu` is the real TLCS-90 (TMP91640) running its dumped ROM.
README.md:67 `edfbl` is deliberately excluded: it is not a System B board (a PIC in place of the TMP91640, no sound CPU, a banked OKI), and MAME flags the whole machine `MAC
README.md:84 **The MAME driver is the reference this core was built against, and the debt is a large one.** `jaleco/megasys1.cpp` is the work of **Luca Elia**, who wrote the
README.md:89 Every behavioural claim in this repository is measured against that code running as MAME 0.289.

Says it matches, follows or was checked against MAME — 10

MS1BCD.sv:28 This compiles and is consistent with the simulations, which are pixel-exact against MAME through the SDRAM path, but no bitstream has been on a DE10-Nano.
MS1BCD.sv:1013 MEASURED against MAME: the board's columns 5..255 matched MAME's 0..250 with ZERO differing pixels, where the unshifted comparison differed in 23192.
rtl/jaleco/ms1_prio.sv:13 Measured: a per-pixel lookup is pixel-exact against MAME on all four oracle captures across all three game modes -- avspirit (B), 64street (C), bigstrik (C, sprite splitting) and peekaboo (D) -- while being one M10K and one read per pixel i
rtl/jaleco/ms1_tilemap.sv:3 The behaviour is taken from MAME's jaleco/ms1_tmap.cpp and verified pixel-exact against MAME by tools/ms1_video_model.py, which is the executable spec this mirrors.
rtl/ms1bcd/ms1_main.sv:868 Found by diffing the bus against MAME: identical for 79 accesses, then MAME fetches vector 0x68 and this core fetched 0x70.
rtl/tlcs90/tlcs90.sv:4 Built and verified against MAME's `cpu/tlcs90/tlcs90.cpp` reference model — see docs/tier2-tlcs90.md for the full ISA reference, memory map, and verification plan this was derived from (register model, addressing-mode encodings, exact per-o
rtl/tlcs90/tlcs90.sv:1102 LDW (mem),mn — reuses OP_LD same as the base-level 0x3f form above (MAME merges LDW into LD|OP_16's own execute case).
rtl/tlcs90/tlcs90_periph_ref.sv:3 Built and verified against MAME's cpu/tlcs90/tlcs90.cpp reference model — see docs/tier2-tlcs90.md's "Peripheral registers" section for the full register map and which registers are confirmed exercised by the NMK004 boot ROM.
rtl/tlcs90/tlcs90_periph_ref.sv:34 - IRF-clear (0xffc3 write) clears the named source's request flag, matching MAME's irf_clear_w(): the written byte is an interrupt index + 2, so `clear_irq(data - 2)` in MAME's enum order, which is our irq_pending bit (data - 5) for the ele
README.md:16 One core for every Mega System 1 B/C/D set, verified against MAME

Says it was translated, ported or taken from MAME — 1

rtl/jaleco/ms1_tilemap.sv:3 The behaviour is taken from MAME's jaleco/ms1_tmap.cpp and verified pixel-exact against MAME by tools/ms1_video_model.py, which is the executable spec this mirrors.

Shares text with the MAME driver without saying so — 19

MS1BCD.sv:531 high bit 0 1 2 3 4 5 6,7 — shares text with jaleco/megasys1.cpp:4356
rtl/jaleco/ms1_prio.sv:8 case ("the special value 0xfffff means that the order is either unknown or — shares text with jaleco/megasys1_v.cpp:545
rtl/jaleco/ms1_prio.sv:9 no simple stack of layers can account for the values in the PROM", and — shares text with jaleco/megasys1_v.cpp:546
rtl/jaleco/ms1_sprites.sv:8 02 H displacement 04 V displacement 06 number displacement — shares text with jaleco/megasys1_v.cpp:122
rtl/jaleco/ms1_sprites.sv:12 0A H position 0C V position 0E tile number — shares text with jaleco/megasys1_v.cpp:108
rtl/jaleco/ms1_sprites.sv:309 (megasys1.cpp set_visarea(0*8, 32*8-1, 2*8, 30*8-1)). The y bound used — shares text with jaleco/megasys1.cpp:2100
rtl/ms1bcd/ms1_main.sv:61 capitals -- "DON'T use COMBINE_DATA ... 64th Street and Chimera Beast rely — shares text with jaleco/megasys1.cpp:261
rtl/ms1bcd/ms1_main.sv:733 scroll0: data -= ((data & 0x0f) > 0x0d) ? 0x10 : 0 — shares text with jaleco/megasys1_v.cpp:292
rtl/ms1bcd/ms1_main.sv:734 scroll1: data -= ((data & 0x0f) > 0x0b) ? 0x10 : 0 — shares text with jaleco/megasys1_v.cpp:300
rtl/ms1bcd/ms1_main.sv:735 with the comment "code in routine $280 does this. — shares text with jaleco/megasys1_v.cpp:290
rtl/ms1bcd/ms1_main.sv:847 index 0 1 2 3 4 5 6 — shares text with jaleco/megasys1.cpp:4356
rtl/ms1bcd/ms1_main.sv:861 callback) does `if (scanline == 0 + 16) set_input_line(2, HOLD_LINE)`. — shares text with jaleco/megasys1.cpp:225
rtl/ms1bcd/ms1_main.sv:876 "reset protection - some games expect this initial read without — shares text with jaleco/megasys1.cpp:164
rtl/ms1bcd/ms1_main.sv:917 and then configure_entries(0, 7, ROM+0x20000, 0x20000), which fills — shares text with jaleco/megasys1.cpp:5272
rtl/ms1bcd/ms1_sound.sv:26 reads sound latch on irq 2") — shares text with jaleco/megasys1_v.cpp:283
rtl/ms1bcd/ms1_sound.sv:30 it "fixes the music tempo in avspirit, 64street, astyanax etc. but makes — shares text with jaleco/megasys1.cpp:106
rtl/ms1bcd/ms1_sound.sv:31 most of the effects in hachoo disappear", and that a bootleg patched the — shares text with jaleco/megasys1.cpp:107
rtl/ms1bcd/ms1bcd_core.sv:401 for (i = 0x1fe; i >= 0; i -= 2) — shares text with jaleco/megasys1.cpp:5288
rtl/ms1bcd/ms1bcd_core.sv:402 ROM[i] = ROM[i+1] = (ROM[i/2] >> 4) & 0x0f; — shares text with jaleco/megasys1.cpp:5290

Arcade-JalecoMS1Z#
Makai Densetsu
kuzearcade/Arcade-JalecoMS1Z_MiSTer @ 24226d7e
MAME compared: jaleco/megasys1.cpp + 6 related file(s)
Read: 28 HDL files, 7,545 lines (Quartus project)

kuzecores
independent database

Mostly MAME

medium

49%

Statements: 2 toward hardware, 70 toward MAME

Reports a measurement taken on the original PCB — 1

MS1Z.sv:400 REFRESH_CYCLES 740 at 96 MHz (~7.7 us); the controller's default 850 was measured corrupting reads on silicon in the NMK16 work.

Notes where it differs from MAME — 1

rtl/jaleco/ms1_video.sv:26 The palette bit layout differs by MODE, and MAME's own header comment about it is wrong.

Cites MAME source — 58

MS1Z.sv:271 Bytes 0 and 1 are DSW1 and DSW2 (MAME's 16-bit DSW port at 0x080006, low and high byte).
MS1Z.sv:291 Keyboard: MAME's default bindings, always live, ORed with the pads.
MS1Z.sv:371 Inputs: MAME's megasys1_generic layout, active low.
MS1Z.sv:609 The YM2203 is mono (MAME: one speaker, "mono").
rtl/cheats.sv:1 Cheat engine — applies Pugsy MAME-database pokes to work RAM once a frame.
rtl/cheats.sv:34 Poke semantics follow MAME's "run" state: the value is written every frame for as long as the cheat is enabled, which is what makes "infinite" cheats hold against the game decrementing the counter.
rtl/jaleco/ms1_prio.sv:4 MAME does NOT use it that way: it converts the PROM into sixteen "layer orders" at init (priority_create), by repeatedly asking which layer is on top of the remaining set, and then composites in that order -- a two-stage algorithm with a do
rtl/jaleco/ms1_prio.sv:20 Address, straight from the comment block in megasys1_v.cpp:
rtl/jaleco/ms1_sprites.sv:18 Order: MAME walks Object RAM DESCENDING (0x3fc down to 0, step 4) and the framebuffer write is FIRST-WRITER-WINS.
rtl/jaleco/ms1_sprites.sv:19 That makes the LAST entry frontmost, which contradicts megasys1_v.cpp's own comment ("From first in Object RAM (frontmost) to last") and the note carried into docs/PLAN.md 4.D item 8.
rtl/jaleco/ms1_sprites.sv:29 The framebuffer is one 256x256 plane of 9 bits {priority, colour, pen}, pen 15 meaning empty -- the same encoding MAME's 0x7fff fill uses.
rtl/jaleco/ms1_sprites.sv:54 megasys1_typez_state::draw_sprites walks the 128 Sprite Data entries themselves, 127 down to 0, through prio_transpen() -- and prio_transpen ORs bit 31 into the priority mask ("high bit of the mask is implicitly on", drawgfx.cpp), while eve
rtl/jaleco/ms1_sprites.sv:64 Attribute bit 3 has no effect: both of MAME's masks, 0x0a and 0x0c, hide a sprite under layer 1.
rtl/jaleco/ms1_sprites.sv:67 Measured against MAME's demo frames: docs/known-issues.md MS1Z-7.
rtl/jaleco/ms1_sprites.sv:326 source pixel inside the tile, with flip and MAME's mosaic filter
rtl/jaleco/ms1_sprites.sv:343 MAME's cliprect exactly: min_x 0, max_x 255, min_y 16, max_y 239 (megasys1.cpp set_visarea(0*8, 32*8-1, 2*8, 30*8-1)).
rtl/jaleco/ms1_sprites.sv:408 MAME then partially clears by pen, which is still not modelled -- MS1-17.
rtl/jaleco/ms1_tilemap.sv:37 MAME takes the tile code modulo the region's element count, so a code past the end of a small ROM WRAPS rather than reading the next SDRAM region.
rtl/jaleco/ms1_tilemap.sv:73 TILES_PER_PAGE_X/Y are both 0x20, and the multipliers come straight from the eight tilemap_create() calls in ms1_tmap.cpp.
rtl/jaleco/ms1_tilemap.sv:75 Note 8x8 N=1 and N=2 are the SAME shape upstream; that is not a typo here, it is a duplicate in MAME.
rtl/jaleco/ms1_tilemap.sv:108 scan_8x8 / scan_16x16 from ms1_tmap.cpp.
rtl/jaleco/ms1_video.sv:18 SCREEN FLIP is a 180-degree rotation of the finished visible frame (docs/known-issues.md MS1-13), so it is applied here by mirroring the SAMPLE POINT rather than by flipping each layer and each sprite the way MAME does.
rtl/jaleco/ms1_video.sv:21 That is not an assumption: MAME was captured twice from the same point, flipped and not, and the two frames are rot180 of each other with zero differing pixels.
rtl/jaleco/ms1_video.sv:52 Per-layer tile ROM byte masks and the sprite tile mask: MAME wraps an out-of-range code modulo the region, so a small ROM must not read into the next SDRAM region.
rtl/jaleco/ms1_video.sv:124 A simulation probe: it lets a frame be recoloured through another palette, which is what a comparison against MAME's pictures needs (they pair one frame's picture with the next frame's palette -- ms1z docs/known-issues.md MS1Z-5).
rtl/jaleco/ms1_video.sv:261 Measured against MAME on bigstrik's split scenes: the low group is the one whose attribute bit 3 is SET, not clear.
rtl/jaleco/ms1_video.sv:271 MS1-Z: screen_update hard-codes pri = 0x0314f -- layer 0 at the bottom (drawn opaque, so its pen 15 is a colour, not a hole), then the sprites, then layer 1 -- and MAME's own conversion of the board's two PROMs fails for every priority code
rtl/jaleco/ms1_video.sv:308 MS1-Z groups them differently (megasys1_v.cpp:79-92 and system_Z's tilemap/gfx bases): layer 0 at 0x000, SPRITES at 0x100, layer 1 at 0x200, and 0x300 unused.
rtl/ms1z/ms1z_core.sv:6 MAME's system_Z instead declares a 256-line screen at set_refresh_hz(56.18) ("same as nmk16.cpp based on YT videos"); the frame rates agree to 0.04 %, the interrupt spacing does not (docs/PLAN.md fact 5).
rtl/ms1z/ms1z_core.sv:9 HTOTAL and VTOTAL are parameters so a SIMULATION can run MAME's timing: 417 x 256 is exactly MAME's 56.18 Hz 256-line frame at a 6 MHz pixel clock -- and 417 x 256 = 384 x 278 = 106,752 pixel clocks, so the frame is the same length and only
rtl/ms1z/ms1z_core.sv:273 no active_layers register on type Z: MAME forces 0x000b (layers 0 and 1 and sprites); no sprite_flag, no sprite bank.
rtl/ms1z/ms1z_main.sv:5 Everything that board needed for protection, System D and the object-RAM double buffer is gone; what is left is MAME's megasys1Z_map, which is megasys_base_map plus one latch write (megasys1.cpp:251-281):
rtl/ms1z/ms1z_main.sv:23 Kept because MAME maps it.
rtl/ms1z/ms1z_main.sv:28 WORK RAM BYTE WRITES MIRROR INTO BOTH HALVES (MAME ram_w, "DON'T use COMBINE_DATA").
rtl/ms1z/ms1z_main.sv:29 Every OTHER RAM on this bus is COMBINE_DATA in MAME, so a byte write changes only its own lane; those are written with byte enables here.
rtl/ms1z/ms1z_main.sv:33 Interrupts (megasys_base_scanline, megasys1.cpp:207-231), all HOLD_LINE: raster line 16 -> level 3, line 96 -> level 1, line 240 -> level 2.
rtl/ms1z/ms1z_main.sv:35 lomakai points levels 1 and 3 at the same handler (0x42C), which reloads layer 1's scroll from RAM: the line-96 interrupt is a mid-screen scroll split, and MAME renders it (ms1_tmap.cpp scroll_w calls update_partial).
rtl/ms1z/ms1z_main.sv:75 MAME's type-Z draw_sprites reads live work RAM, and lomakai rewrites the list mid-frame (MS1Z-12), so there is no snapshot and no buffer.
rtl/ms1z/ms1z_main.sv:339 scroll_r: the two scroll triples read back; nothing else in the window has a read handler in MAME, so it reads 0.
rtl/ms1z/ms1z_main.sv:350 MAME returns 1s for bits a port DECLARES as active-low unknowns and 0s for bits it does not declare at all: SYSTEM and P2 declare 0xff00, P1 declares only its low byte.
rtl/ms1z/ms1z_main.sv:479 the autovector acknowledge is invisible to MAME's memory tap
rtl/ms1z/ms1z_sound.sv:4 MAME (megasys1.cpp:798-810, 2259, 2285): Z80 mem 0000-3FFF ROM (16 KB of lom_01.rom; the file is 64 KB and every byte above 0x3E30 is 0xFF -- docs/known-issues.md MS1Z-1) C000-C7FF RAM, 2 KB, no mirror E000 R sound latch (low byte) F
rtl/ms1z/ms1z_sound.sv:19 MS1BCD's equivalent resets the YM2151 and both OKIs too (MS1-30); here the YM2203 has no reset from it in MAME (screen_flag_w's ym2151 cast fails for it).
rtl/ms1z/ms1z_sound.sv:136 No reset line from the Z80's reset: MAME's latch survives a sound-CPU reset.
rtl/ms1z/ms1z_sound.sv:196 The mix, set by MEASUREMENT against MAME's isolated halves (MAME patched with MS1_SND_ISO=fm|ssg, the core's MS1_WAV_FM / MS1_WAV_SSG taps, lomakai's attract music, DC removed, 37-49 s):
rtl/ms1z/ms1z_sound.sv:199 FM core vs MAME -0.04 dB with fm >>> 1 (Sand Scorpion's SS-10
rtl/ms1z/ms1z_sound.sv:200 finding: FM at MAME's routed 0.5) SSG core vs MAME -4.11 dB with jt12_top's {psg,5'd0} >>> 1; the per-second ratio sits at 0.667 -- exactly 2/3 -- so the SSG is weighted x1.5 here: {psg,5'd0} + {psg,4'd0}.
rtl/ms1z/ms1z_sound.sv:358 ------------------------------------------------ Z80 read mux Unmapped reads return 0x00, MAME's default unmap value for both spaces.
rtl/ms1z/ms1z_sprline.sv:3 Why not MS1BCD's frame plane (docs/known-issues.md MS1Z-12): lomakai rewrites its sprite list during the first ~100 raster lines of every frame, and MAME's type Z draws sprites from live work RAM at render time, so a frame shows the list wr
rtl/ms1z/ms1z_sprline.sv:100 Byte k of source row gy: 128 bytes per tile, two 8-wide column halves (k[2] selects the right half, +64), 4 bytes per row, 2 pixels per byte -- the layout ms1_sprites.sv and MAME's gfx_8x8x4_col_2x2 use.
rtl/rom_cache_n.sv:7 Why (docs/hw-bringup.md, "Slowdown"): the real board and MAME run the 68000 with zero wait states from EPROM.
rtl/rom_cache_n.sv:8 Through the 1-line rom_cache1 56% of ROM bus cycles missed (the instruction stream and the game's ROM data-table reads thrash a single pair) and each miss is a ~10 clk_sys SDRAM round trip, 1-2 wait states — 13-20% of every frame spent stal
rtl/savestate/savestate_ui.sv:4 Slot 2 is on F5 and NOT F2 because this core's own keyboard map already uses F2 for the Service Mode toggle (MAME's binding for it), and both were acting on the same press -- found on the board, 2026-09-20.
README.md:21 **In development; runs on the DE10-Nano.** Measured against MAME 0.289:
README.md:23 **video block:** MAME's attract demo reproduced **pixel for pixel on 220 of 220 frames** from MAME's own state (layers, sprites, palette, the raster split);
README.md:30 **audio:** FM within 0.04 dB of MAME, the mix within 0.4 dB, band correlation 0.997 (MS1Z-13);
README.md:57 Simulation needs Verilator 5: `sim/rtl/ms1z_frames` (the whole board), `sim/rtl/video_state_z` (the video block against one MAME frame).
README.md:65 **MAME** `jaleco/megasys1.cpp`, `megasys1_v.cpp`, `ms1_tmap.cpp` -- driver by **Luca Elia** and **David Haywood** -- the behavioural reference for every part of

Says it matches, follows or was checked against MAME — 4

MS1Z.sv:647 MEASURED against MAME: the board's columns 5..255 matched MAME's 0..250 with ZERO differing pixels, where the unshifted comparison differed in 23192.
rtl/jaleco/ms1_prio.sv:13 Measured: a per-pixel lookup is pixel-exact against MAME on all four oracle captures across all three game modes -- avspirit (B), 64street (C), bigstrik (C, sprite splitting) and peekaboo (D) -- while being one M10K and one read per pixel i
rtl/jaleco/ms1_tilemap.sv:3 The behaviour is taken from MAME's jaleco/ms1_tmap.cpp and verified pixel-exact against MAME by tools/ms1_video_model.py, which is the executable spec this mirrors.
README.md:15 The board, verified against MAME: every claim in `docs/known-issues.md` is closed by a measurement, never by reasoning.

Says it was translated, ported or taken from MAME — 1

rtl/jaleco/ms1_tilemap.sv:3 The behaviour is taken from MAME's jaleco/ms1_tmap.cpp and verified pixel-exact against MAME by tools/ms1_video_model.py, which is the executable spec this mirrors.

Shares text with the MAME driver without saying so — 7

rtl/jaleco/ms1_prio.sv:8 case ("the special value 0xfffff means that the order is either unknown or — shares text with jaleco/megasys1_v.cpp:545
rtl/jaleco/ms1_prio.sv:9 no simple stack of layers can account for the values in the PROM", and — shares text with jaleco/megasys1_v.cpp:546
rtl/jaleco/ms1_sprites.sv:8 02 H displacement 04 V displacement 06 number displacement — shares text with jaleco/megasys1_v.cpp:122
rtl/jaleco/ms1_sprites.sv:12 0A H position 0C V position 0E tile number — shares text with jaleco/megasys1_v.cpp:108
rtl/jaleco/ms1_sprites.sv:60 comment says ("[MS1-Z] From last in Sprite RAM (frontmost) to first"). A — shares text with jaleco/megasys1_v.cpp:168
rtl/jaleco/ms1_sprites.sv:344 (megasys1.cpp set_visarea(0*8, 32*8-1, 2*8, 30*8-1)). The y bound used — shares text with jaleco/megasys1.cpp:2100
rtl/ms1z/ms1z_core.sv:7 set_refresh_hz(56.18) ("same as nmk16.cpp based on YT videos"); the frame — shares text with jaleco/megasys1.cpp:1906

Arcade-NamcoS2_LW#
Lucky & Wild
kuzearcade/Arcade-NamcoSystem2_MiSTer @ 5fe71a59
MAME compared: namco/namcos2.cpp + 23 related file(s)
Read: 48 HDL files, 23,027 lines (Quartus project)

kuzecores
independent database

Mostly MAME

medium

63%

Statements: 122 toward MAME

Cites MAME source — 116

NamcoS2.sv:98 180 degrees in the core, on every video path (ns2_flipbuf); a ROT180 set (MAME's Bubble Trouble) starts turned, and this turns it back
NamcoS2.sv:326 MAME's power-on analog and dial values (M5 maps the controls onto them)
NamcoS2.sv:338 Byte 0 is MAME's DSW port (the MCU's $2000; bit 7 the test switch).
NamcoS2.sv:352 Keyboard: MAME's default bindings, always live, ORed with the pads.
NamcoS2.sv:393 Inputs: MAME's ports (namcos2.cpp NAMCOS2_MCU_PORT_*_DEFAULT), active low.
NamcoS2.sv:402 The sets with a wheel and pedals, light guns or Metal Hawk's stick map the analog sticks and the mouse onto AN0-AN7 (ns2_controls, the set's control mode in config byte 33); the others keep MAME's power-on values.
NamcoS2.sv:733 Audio: MAME's routes (namcos2.cpp), both stereo, the set's own gains (config bytes 36-37, x128; NS2-26): the C140 at 0.75 (base2 and Metal Hawk 1.0, base3 0.45), the YM2151 at 0.80 (base3 1.0).
NamcoS2.sv:735 Each chip first through its anti-imaging interpolator (ns2_fir4: 4x, MAME's resampler's response in the passband, NS2-26 and NS2-29): a held sample has images above the chip's Nyquist (the C140's 10.67 kHz, jt51's 27.97 kHz, which MiSTer's
rtl/cheats.sv:1 Cheat engine — applies Pugsy MAME-database pokes to work RAM once a frame.
rtl/cheats.sv:34 Poke semantics follow MAME's "run" state: the value is written every frame for as long as the cheat is enabled, which is what makes "infinite" cheats hold against the game decrementing the counter.
rtl/ns2_board.sv:9 Line events, at the start of the line (MAME's scanline timer): 200 the MCU's IRQ1, 240 both C148s' VBLANK, (reg5 - 32) & 0xff POSIRQ.
rtl/ns2_board.sv:23 inputs (MAME's ports)
rtl/ns2_c123.sv:1 C123 tilemaps (namco_c123tmap.cpp; tools/ns2_model.py tilemap_layer is the specification): renders one line of the six planes into the composition line buffer, in MAME's draw order (priority 0..7, then plane 0..5), each opaque pixel overwri
rtl/ns2_c123.sv:51 The planes in MAME's draw order (priority 0..7, then plane 0..5) are listed first; then a fetch engine fills slot bank k & 1 for the k-th listed plane while the pixel engine draws the plane before it from the other bank: a line costs about
rtl/ns2_c140.sv:1 C140 (MAME c140.cpp): 24 PCM voices, the register file, the key-on status and the INT1 timer that drives the 6809's FIRQ.
rtl/ns2_c140.sv:3 0x000-0x17f 24 voices x 16 registers: 0 volume right, 1 volume left, 2-3 frequency, 4 bank, 5 mode (key-on on bit 7, or bit 6 while keyed; bit 4 loop, bit 3 compressed), 6-7 start, 8-9 end, 10-11 loop (sample words within the bank) 0x1f8
rtl/ns2_c140.sv:14 The voices, as MAME's sound_stream_update, one sample per base-rate tick (21.333 kHz: clk / 2304; MAME_RATE = 1 uses MAME's stream edges instead, its integer 21333 Hz, for the sample-exact comparison): offset += frequency * 2; pos += offset
rtl/ns2_c140.sv:24 MAME computes the samples whose edge has passed before it applies a register write, so a write never reaches a sample being computed: the voice register writes wait in a queue while the voices run (the CPU's view, the register reads and the
rtl/ns2_c140.sv:29 Voice ROM words: c140_rom_r (namcos2_m.cpp), the schematics' wiring: word address bit 21 picks voice1/voice2 for bits 15-8, bit 20 low enables voice0's nibble for bits 7-4, bit 19 low picks its low nibble.
rtl/ns2_c140.sv:48 the output, one sample per tick; raw_*: MAME's mixer sums (debug)
rtl/ns2_c140.sv:77 the timer counts clocks from the write, as MAME's (an exact duration, not the base-rate ticks' edges): (reload + 1) * 2 * 2304 clocks
rtl/ns2_c140.sv:120 the voices' state (MAME's C140_VOICE)
rtl/ns2_c140.sv:150 MAME's compressed table: j = (s8)i; s1 = j & 7; s2 = abs(j >> 3) & 31; v = ((0x80 << s1) & 0xff00) + (s2 << (s1 ?
rtl/ns2_c140.sv:167 MAME's put_int_clamp(v, 4096): +-1.0 full scale, as 16 bits
rtl/ns2_c140.sv:273 the key-on decision is MAME's, at the write
rtl/ns2_c140.sv:337 MAME's per-sample step, voice ev
rtl/ns2_c148.sv:1 C148: a 68000's interrupt controller and board control (namco_c148.cpp).
rtl/ns2_c148.sv:13 MAME drives the 68000's input line of the source's level, not a per-source OR: a trigger sets the line of the source's current level, an ack (or a level write, which acks first) clears it, whatever else shares the level.
rtl/ns2_c148.sv:94 line and hold are updated in order (blocking): the events of one clock apply as MAME applies them, one after another the acknowledge of a held level
rtl/ns2_c169.sv:1 C169 ROZ (namco_c169roz.cpp; tools/ns2_model.py c169_params / c169_rows / draw_c169 are the specification): renders one line of both layers, layer 1 then layer 0, each into its own line buffer with its priority and colour per pixel (the per
rtl/ns2_c355.sv:1 C355 sprites (namco_c355spr.cpp; tools/ns2_c355hw.py is the specification, proven equal to MAME's frame algorithm, tools/ns2_model.py sprites_c355).
rtl/ns2_c45.sv:1 C45 road (namco_c45road.cpp draw; tools/ns2_model.py road_line is the specification): renders one line of the road into the ROZ line buffer (a board has one or the other), with the line's priority.
rtl/ns2_c65.sv:1 The C65 I/O MCU (MAME namco65.cpp): the HD63705 (rtl/ns2_hd63705.v, NS2-7) at 2.048 MHz (its crystal clock: a clock enable every 24 clocks) and its memory map: 0000-003f RAM, reads of 01 (MCUB), 02 (MCUC), 03 (port D: the analog inputs over
rtl/ns2_c65.sv:13 IRQ1 (line 200) and the A/D interrupt are latched until the core fetches their vectors (0x1ff8, 0x1fea), as MAME's pending interrupts.
rtl/ns2_c65.sv:14 MAME holds the IRQ1 input (HOLD_LINE) until the core enters any interrupt, and the core latches IRQ1 only when that input changes: a line-200 event while the input is still held is lost.
rtl/ns2_c65.sv:40 inputs (MAME's ports, active low where the board is)
rtl/ns2_c65.sv:78 MAME's IRQ1 input: held until an interrupt is taken
rtl/ns2_c68.sv:1 The C68 I/O MCU (MAME namco68.cpp): an M37450 (rtl/ns2_m740.sv, NS2-9) at 8.192 MHz, a cycle every 4 clocks: 2.048 MHz, a clock enable every 24 clocks.
rtl/ns2_c68.sv:3 Its on-chip peripherals as MAME's m3745x.cpp: 0000-00bf RAM 00d6-00dd ports P3-P6 and their direction 00e2-00e3 A/D 00fc-00ff interrupt requests and enables 0100-01ff RAM (the stack) and the board's map (c68_default_am
rtl/ns2_c68.sv:16 Interrupts: MAME's m3745x maps the enabled requests to m740 lines; any raises irq and the lowest line gives the vector (0xfffc - 2 * line): requests 1 bit 2 (INT1, line 200's VBL) -> line 2, 0xfff8 requests 1 bits 3, 4 -> lines 3, 4; reque
rtl/ns2_c68.sv:42 inputs (MAME's ports)
rtl/ns2_c68.sv:50 MAME's taps see this access
rtl/ns2_c68.sv:103 the ports' inputs (MAME's read_p callbacks)
rtl/ns2_c68.sv:188 MAME's reset clears the requests: nothing from before the release
rtl/ns2_controls.sv:1 The players' controls onto the I/O MCU's ports (namcos2.cpp's input ports): the digital ports MCUB, MCUC, MCUH and the eight analog channels AN0-AN7, per the set's control mode (config byte 33, tools/ns2_romdata.py): [1:0] 0 digital (MAME's
rtl/ns2_controls.sv:14 Ghost!, Bubble Trouble); otherwise MCUH 5 and 4, the bombs MCUH 3 and 2 the wheel and pedals: [4] Start on MCUB 7 / 6 (Four Trax, Suzuka) [5] the gears on MCUB: 5 down (the d-pad's up, or B4), 7 up (the d-pad's down, or B3) (Dirt Fox) M
rtl/ns2_controls.sv:23 A gun's value is its position across the board's own picture, 0 at the left (top) to 255 at the right (bottom), as MAME's crosshair maps it; the players aim at the displayed picture, turned 180 degrees when `flip`.
rtl/ns2_controls.sv:26 Wheel: 0x01-0xff, 0x80 centred; accelerator 0-0x80, brake 0-0x40; Metal Hawk's stick and lever 0x20-0xe0 (MAME's PORT_MINMAX).
rtl/ns2_controls.sv:27 A stick sets a value outright; a button or the d-pad moves it a step a frame, as MAME's key delta, and it returns when released.
rtl/ns2_controls.sv:36 MAME's power-on AN0-AN7 (config bytes 21-28)
rtl/ns2_controls.sv:44 MAME's power-on MCUDI0-3 (config bytes 29-32)
rtl/ns2_controls.sv:101 ------------------------------------------------------------ the guns Each gun aims from the stick (or a MiSTer gun), the d-pad (8 a frame, MAME's key delta; it stays where it is left), or for player 1 the mouse: whichever moved last.
rtl/ns2_controls.sv:165 ------------------------------------------------------------ Assault Two 4-way sticks a player, a tank's two tracks (MAME's assault ports): the left on MCUB (up, down, left) and MCUH 7/6 (right), the right on MCUH (up, down) and MCUDI0 (rig
rtl/ns2_controls.sv:225 MAME's default ports (namcos2.cpp NAMCOS2_MCU_PORT_*_DEFAULT), active low
rtl/ns2_cpu.sv:1 One of the two 68000s with its own bus (namcos2.cpp master_common_am / slave_common_am): fx68k at 12.288 MHz (a PHI1 and a PHI2 enable every 4 clocks of the 49.152 MHz clk), its program ROM, 64 KB of work RAM (the slave's 0x100000-0x13ffff
rtl/ns2_cpu.sv:8 Interrupt acknowledges are answered with the autovector 24 + level (MAME's m68000 with the C148 on the IPL lines).
rtl/ns2_cpu.sv:264 ext_in: MAME leaves it unconnected (7)
rtl/ns2_fir4.sv:1 A sound chip's anti-imaging interpolator (NS2-26, NS2-29): its samples (one per in_stb) out at 4x through a 128-tap low-pass whose passband is MAME's own resampler's response (tools/ns2_firgen.py): a held sample puts images above the chip's
rtl/ns2_hd63705.v:1 Derived from jt6805 (jotego/jtcores modules/jt680x @ 3eb8fec, GPL-3.0-or-later, rtl/third_party/jt680x) for the C65's HD63705Z0 as MAME implements it (hd6305.cpp, docs/PLAN.md D2): 16-bit addresses; the stack in page 1 (0x100-0x17f, 7 bits)
rtl/ns2_hd63705_alu.v:1 Derived from jt6805 (jotego/jtcores modules/jt680x @ 3eb8fec, GPL-3.0-or-later, rtl/third_party/jt680x) for the C65's HD63705Z0 as MAME implements it (hd6305.cpp, docs/PLAN.md D2): 16-bit addresses; the stack in page 1 (0x100-0x17f, 7 bits)
rtl/ns2_hd63705_ctrl.v:1 Derived from jt6805 (jotego/jtcores modules/jt680x @ 3eb8fec, GPL-3.0-or-later, rtl/third_party/jt680x) for the C65's HD63705Z0 as MAME implements it (hd6305.cpp, docs/PLAN.md D2): 16-bit addresses; the stack in page 1 (0x100-0x17f, 7 bits)
rtl/ns2_hd63705_ctrl.v:66 MAME's order: IRQ1 before the A/D interrupt
rtl/ns2_hd63705_regs.v:1 Derived from jt6805 (jotego/jtcores modules/jt680x @ 3eb8fec, GPL-3.0-or-later, rtl/third_party/jt680x) for the C65's HD63705Z0 as MAME implements it (hd6305.cpp, docs/PLAN.md D2): 16-bit addresses; the stack in page 1 (0x100-0x17f, 7 bits)
rtl/ns2_key.sv:1 The key custom (namcos2_m.cpp namcos2_68k_key_r / _w): 8 word registers.
rtl/ns2_key.sv:2 Per set, some offsets return a constant (the protection check); every other read returns MAME's random value, which the oracle patch makes the LFSR r = (r >> 1) ^ (r & 1 ?
rtl/ns2_m740.sv:1 GENERATED by tools/ns2_740gen.py from MAME's devices/cpu/m6502 (dm740.lst, om740.lst, om6502.lst; BSD-3-Clause, Olivier Galibert): do not edit.
rtl/ns2_m740.sv:3 The Mitsubishi 740 core of the C68's M37450, cycle for cycle as MAME's m740 (NS2-9).
rtl/ns2_m740.sv:8 irq is MAME's m_irq_state (any enabled request), irq_vector its m_irq_vector; both are sampled at the opcode fetch, as MAME's prefetch_end.
rtl/ns2_m740.sv:10 On reset the registers take MAME's power-on values and the core runs reset_m (the vector at 0xfffe).
rtl/ns2_m740.sv:22 MAME's taps see this access (not read_pc, read_arg or a fetch)
rtl/ns2_m740.sv:33 MAME's registers (blocking: the statements between two bus cycles run in C's order within one clock; the bus outputs are registered from b_*)
rtl/ns2_m740.sv:72 ---------------------------------------------------------------- m6502.cpp
rtl/ns2_m740.sv:197 ---------------------------------------------------------------- m740.cpp: T mode on m_TMP
rtl/ns2_m740.sv:258 the prefetch's end: the opcode, then MAME's prefetch_end (the interrupt check)
rtl/ns2_m740.sv:2416 MAME's STATE_RESET: reset_m from its start
rtl/ns2_main.sv:1 The two 68000s and their shared bus (namcos2.cpp: namcos2_68k_default_cpu_board_am, common_default_am, common_finallap_am): the arbiter grants one access at a time (master first when both ask in the same clock); an access takes three clocks
rtl/ns2_main.sv:179 the arbiter: the grant with the address, then the devices' read latency, then the capture (three clocks, the master first): the 68000 gets DTACK in time for no wait state, as in MAME
rtl/ns2_main.sv:200 the boards' maps (namcos2.cpp): the CPU board's, then each graphics board's 0 standard: c00000 sprites, c40000 gfx_ctrl, c80000 ROZ RAM, cc0000 ROZ control, d00000 key 1 Final Lap: 300000 protection, 800000 sprites, 840000 gfx_ctrl, 880000
rtl/ns2_main.sv:318 (MAME's umask16 reads: the other lane 0)
rtl/ns2_main.sv:320 finallap_state::finallap_prot_r (namcos2_m.cpp): two tables on a counter that reads of words 3 and 1ffff advance
rtl/ns2_mem.sv:10 It applies the board wiring MAME applies after loading (tools/ns2_romdata.py WIRING): Metal Hawk's sprite reorder (a byte lands in 0, 1 or 2 places) and its transposed copy for the rot90 sprites, and Lucky & Wild's bit-reversed C169 mask.
rtl/ns2_mem.sv:18 WRAM_SD (the Suzuka and Lucky & Wild bitstreams): the 68000s' work RAMs and the C139's RAM are bank 1 clients that also write (ns2_wram_cache); the download first clears them, as MAME's RAM starts at 0 and the board's SDRAM keeps the last c
rtl/ns2_mem.sv:28 MAME loads one byte lane of some 16-bit regions and leaves the other at 0: the C140 voices' odd bytes always, the data ROM's second megabyte where these say (rthun2: the odd bytes; suzuka8h: the even).
rtl/ns2_mem.sv:106 Metal Hawk's reorder, per 4x4 block of a 32x32 tile: where a source byte (row r, column c in the block) goes; MAME's loop carries one byte into two places and drops another (tools/ns2_romdata.py _metlhawk_sprite)
rtl/ns2_roz.sv:1 ROZ (A) (namcos2_roz.cpp draw_roz; tools/ns2_model.py roz_layer is the specification): renders one line of the ROZ plane into its own line buffer.
rtl/ns2_roz.sv:3 The mixer resolves it against the tilemaps: MAME draws it after every plane of its priority or lower, so it wins over those and loses to higher ones.
rtl/ns2_roz.sv:9 Without wrap a pixel is inside when xpos <= size and ypos < size (MAME's comparisons).
rtl/ns2_sound.sv:1 The sound board (namcos2.cpp sound_default_am): the 6809 at 2.048 MHz (E and Q from clk: 24 clocks an E cycle), the YM2151 (jt51, 3.579545 MHz), the C140 (rtl/ns2_c140.sv), 8 KB of RAM and the DPRAM's third port.
rtl/ns2_sound.sv:4 0000-3fff banked ROM (16 KB banks; c000-c001 writes select data >> 4) 4000-4001 YM2151 5000-51ff, 6000-61ff C140 (mirrored) 7000-77ff DPRAM (mirrored) 8000-9fff RAM a000-bfff amplifier enable (writes ignored) c000-ffff ROM (the re
rtl/ns2_sound.sv:10 The YM2151's IRQ is not wired (MAME comments it out).
rtl/ns2_sprite_a.sv:1 Sprites (A) (namcos2_sprite.cpp draw_sprites; tools/ns2_model.py sprites_a is the specification): renders one line of the 128 sprites of the bank gfx_ctrl & 0xf into the sprite line buffer, in list order, a later sprite overwriting an earli
rtl/ns2_sprite_a.sv:7 MAME's zoom reduces to a screen size of sizex x sizey (sizex halved for 16x16), the source stepping by (gw << 16) / size per screen pixel, from the far edge when flipped: row = ((flipy ?
rtl/ns2_sprite_a.sv:41 (gw << 16) / n for n = 1..64, gw = 16 or 32: MAME's zoom step, from a table of (32 << 16) / n (a divider does not fit a clock); for gw 16 it is halved, floor(floor(x / n) / 2) being floor(x / 2n)
rtl/ns2_sprite_a.sv:74 the screen width: MAME's (scalex * gw + 0x8000) >> 16; Metal Hawk's scalex always divides by 0x20, so a 16-wide sprite is (sizex + 1) / 2
rtl/ns2_sprite_a.sv:122 w0 is in: the line test (sh >= 2 is MAME's sizey - 1 != 0); Metal Hawk's position also depends on word 6, so it tests later
rtl/ns2_video.sv:116 MAME's screen starts at the top of VBLANK (vpos 224)
rtl/ns2_video.sv:156 MAME's POSIRQ line: (C116 register 5 - 32) & 0xff (namcos2 get_pos_irq_scanline)
rtl/ns2_video.sv:239 the C116 sits on D7-D0 and takes any byte of the word (MAME's umask16(0x00ff).cswidth(16)): a byte write to the even address (UDS alone) writes too, with the byte the 68000 puts on both lanes
rtl/ns2_video.sv:263 registers 6 and 7 read 0xff (namcos2_base_state::c116_r, MAME's "fix for finallap boot")
rtl/ns2_video.sv:294 MAME's umask16 reads fill the other lane with 0
rtl/ns2_video.sv:524 At equal priority MAME draws planes, then ROZ or road, then C169 layer 1, then layer 0: the pixel shows the last drawn, the largest {priority, order}
rtl/ns2_ym_fifo.sv:2 jt51 applies an operator or key-on write over the next 32 of its cycles (64 with its half-rate phase), and a write before that cancels or redirects it; the games write every 26-28 cycles without reading the busy flag (Rolling Thunder 2: no
README.md:7 The joystick games use MAME's default ports (one joystick, three buttons, Start, Coin, Service).
README.md:18 **MAME as the reference.** MAME's `namco/namcos2.cpp` (K. Wilkins) and its devices, at a pinned commit (`deps.lock`), define the behaviour.
README.md:22 **Gates are measurements.** Each milestone ends in a measured gate, not a judgement: the video against MAME's state (M1), the whole board against MAME's bus tra
README.md:27 **Cycle-faithful CPUs.** Both 68000s, the 6809 and the I/O MCU (C65 or C68) run at MAME's clocks and bus timing.
README.md:30 **Every set in MAME's driver**, including Final Lap 1-3, Four Trax and the NB-1 boards (Steel Gunner, Suzuka 8 Hours, Lucky & Wild).
README.md:44 | Game | Year | MAME set | Bitstream | Controls | Alternates |
README.md:95 **Cheats** from Pugsy's MAME cheat database: ten fixed slots (Infinite Time, Infinite Credits, P1/P2 Invincibility, P1/P2 Infinite Lives, P1/P2 Infinite Energy,
README.md:118 The games on MAME's common ports have their own button names, and the buttons a game never reads are hidden: Cosmo Gang (Fire), Dragon Saber (Fire, Bomb), Marve
README.md:132 or the d-pad's up, as MAME's ports.
README.md:208 The C139 serial link between cabinets is not emulated (nor is it in MAME): each cabinet plays alone.
README.md:235 Derived from MAME (BSD-3-Clause), besides its use as the behavioural reference:
README.md:237 `rtl/ns2_m740.sv` (the C68's 740 core) is generated by `tools/ns2_740gen.py` from MAME's `dm740.lst`, `om740.lst` and `om6502.lst`, by Olivier Galibert; its hel
README.md:241 `rtl/ns2_c140.sv` ports MAME's `sound/c140.cpp`, by R. Belmont.
README.md:242 `tools/ns2_romdata.py` reads its ROM tables from MAME's `namcos2.cpp` (K. Wilkins and the MAME contributors).

Says it matches, follows or was checked against MAME — 1

README.md:122 Each was checked in MAME, a press in play against the same run without it.

Shares text with the MAME driver without saying so — 5

rtl/ns2_c123.sv:44 TilemapCB: bitswap<16>(code, 13,12,11,15,14,10..0); — shares text with namco/namcos2_v.cpp:12
rtl/ns2_c123.sv:45 TilemapCB_finalap2: bitswap<15>(code, 13,12,11,14,10..0) — shares text with namco/namcos2_v.cpp:18
rtl/ns2_c169.sv:65 bitswap<13>(c & 0x1fff, 11,10,9,12,8..0) — shares text with namco/namcos2_v.cpp:260
rtl/ns2_main.sv:1 The two 68000s and their shared bus (namcos2.cpp: namcos2_68k_default_cpu_board_am, — shares text with namco/namcos2.cpp:682
rtl/ns2_tile_filter.sv:47 TilemapCB undone: tile [15:11] = code {13, 12, 11, 15, 14} (standard), — shares text with namco/namcos2_v.cpp:12

Arcade-NamcoS2_MH#
Metal Hawk
kuzearcade/Arcade-NamcoSystem2_MiSTer @ 5fe71a59
MAME compared: namco/namcos2.cpp + 23 related file(s)
Read: 48 HDL files, 23,027 lines (Quartus project)

kuzecores
independent database

Mostly MAME

medium

63%

Statements: 122 toward MAME

Cites MAME source — 116

NamcoS2.sv:98 180 degrees in the core, on every video path (ns2_flipbuf); a ROT180 set (MAME's Bubble Trouble) starts turned, and this turns it back
NamcoS2.sv:326 MAME's power-on analog and dial values (M5 maps the controls onto them)
NamcoS2.sv:338 Byte 0 is MAME's DSW port (the MCU's $2000; bit 7 the test switch).
NamcoS2.sv:352 Keyboard: MAME's default bindings, always live, ORed with the pads.
NamcoS2.sv:393 Inputs: MAME's ports (namcos2.cpp NAMCOS2_MCU_PORT_*_DEFAULT), active low.
NamcoS2.sv:402 The sets with a wheel and pedals, light guns or Metal Hawk's stick map the analog sticks and the mouse onto AN0-AN7 (ns2_controls, the set's control mode in config byte 33); the others keep MAME's power-on values.
NamcoS2.sv:733 Audio: MAME's routes (namcos2.cpp), both stereo, the set's own gains (config bytes 36-37, x128; NS2-26): the C140 at 0.75 (base2 and Metal Hawk 1.0, base3 0.45), the YM2151 at 0.80 (base3 1.0).
NamcoS2.sv:735 Each chip first through its anti-imaging interpolator (ns2_fir4: 4x, MAME's resampler's response in the passband, NS2-26 and NS2-29): a held sample has images above the chip's Nyquist (the C140's 10.67 kHz, jt51's 27.97 kHz, which MiSTer's
rtl/cheats.sv:1 Cheat engine — applies Pugsy MAME-database pokes to work RAM once a frame.
rtl/cheats.sv:34 Poke semantics follow MAME's "run" state: the value is written every frame for as long as the cheat is enabled, which is what makes "infinite" cheats hold against the game decrementing the counter.
rtl/ns2_board.sv:9 Line events, at the start of the line (MAME's scanline timer): 200 the MCU's IRQ1, 240 both C148s' VBLANK, (reg5 - 32) & 0xff POSIRQ.
rtl/ns2_board.sv:23 inputs (MAME's ports)
rtl/ns2_c123.sv:1 C123 tilemaps (namco_c123tmap.cpp; tools/ns2_model.py tilemap_layer is the specification): renders one line of the six planes into the composition line buffer, in MAME's draw order (priority 0..7, then plane 0..5), each opaque pixel overwri
rtl/ns2_c123.sv:51 The planes in MAME's draw order (priority 0..7, then plane 0..5) are listed first; then a fetch engine fills slot bank k & 1 for the k-th listed plane while the pixel engine draws the plane before it from the other bank: a line costs about
rtl/ns2_c140.sv:1 C140 (MAME c140.cpp): 24 PCM voices, the register file, the key-on status and the INT1 timer that drives the 6809's FIRQ.
rtl/ns2_c140.sv:3 0x000-0x17f 24 voices x 16 registers: 0 volume right, 1 volume left, 2-3 frequency, 4 bank, 5 mode (key-on on bit 7, or bit 6 while keyed; bit 4 loop, bit 3 compressed), 6-7 start, 8-9 end, 10-11 loop (sample words within the bank) 0x1f8
rtl/ns2_c140.sv:14 The voices, as MAME's sound_stream_update, one sample per base-rate tick (21.333 kHz: clk / 2304; MAME_RATE = 1 uses MAME's stream edges instead, its integer 21333 Hz, for the sample-exact comparison): offset += frequency * 2; pos += offset
rtl/ns2_c140.sv:24 MAME computes the samples whose edge has passed before it applies a register write, so a write never reaches a sample being computed: the voice register writes wait in a queue while the voices run (the CPU's view, the register reads and the
rtl/ns2_c140.sv:29 Voice ROM words: c140_rom_r (namcos2_m.cpp), the schematics' wiring: word address bit 21 picks voice1/voice2 for bits 15-8, bit 20 low enables voice0's nibble for bits 7-4, bit 19 low picks its low nibble.
rtl/ns2_c140.sv:48 the output, one sample per tick; raw_*: MAME's mixer sums (debug)
rtl/ns2_c140.sv:77 the timer counts clocks from the write, as MAME's (an exact duration, not the base-rate ticks' edges): (reload + 1) * 2 * 2304 clocks
rtl/ns2_c140.sv:120 the voices' state (MAME's C140_VOICE)
rtl/ns2_c140.sv:150 MAME's compressed table: j = (s8)i; s1 = j & 7; s2 = abs(j >> 3) & 31; v = ((0x80 << s1) & 0xff00) + (s2 << (s1 ?
rtl/ns2_c140.sv:167 MAME's put_int_clamp(v, 4096): +-1.0 full scale, as 16 bits
rtl/ns2_c140.sv:273 the key-on decision is MAME's, at the write
rtl/ns2_c140.sv:337 MAME's per-sample step, voice ev
rtl/ns2_c148.sv:1 C148: a 68000's interrupt controller and board control (namco_c148.cpp).
rtl/ns2_c148.sv:13 MAME drives the 68000's input line of the source's level, not a per-source OR: a trigger sets the line of the source's current level, an ack (or a level write, which acks first) clears it, whatever else shares the level.
rtl/ns2_c148.sv:94 line and hold are updated in order (blocking): the events of one clock apply as MAME applies them, one after another the acknowledge of a held level
rtl/ns2_c169.sv:1 C169 ROZ (namco_c169roz.cpp; tools/ns2_model.py c169_params / c169_rows / draw_c169 are the specification): renders one line of both layers, layer 1 then layer 0, each into its own line buffer with its priority and colour per pixel (the per
rtl/ns2_c355.sv:1 C355 sprites (namco_c355spr.cpp; tools/ns2_c355hw.py is the specification, proven equal to MAME's frame algorithm, tools/ns2_model.py sprites_c355).
rtl/ns2_c45.sv:1 C45 road (namco_c45road.cpp draw; tools/ns2_model.py road_line is the specification): renders one line of the road into the ROZ line buffer (a board has one or the other), with the line's priority.
rtl/ns2_c65.sv:1 The C65 I/O MCU (MAME namco65.cpp): the HD63705 (rtl/ns2_hd63705.v, NS2-7) at 2.048 MHz (its crystal clock: a clock enable every 24 clocks) and its memory map: 0000-003f RAM, reads of 01 (MCUB), 02 (MCUC), 03 (port D: the analog inputs over
rtl/ns2_c65.sv:13 IRQ1 (line 200) and the A/D interrupt are latched until the core fetches their vectors (0x1ff8, 0x1fea), as MAME's pending interrupts.
rtl/ns2_c65.sv:14 MAME holds the IRQ1 input (HOLD_LINE) until the core enters any interrupt, and the core latches IRQ1 only when that input changes: a line-200 event while the input is still held is lost.
rtl/ns2_c65.sv:40 inputs (MAME's ports, active low where the board is)
rtl/ns2_c65.sv:78 MAME's IRQ1 input: held until an interrupt is taken
rtl/ns2_c68.sv:1 The C68 I/O MCU (MAME namco68.cpp): an M37450 (rtl/ns2_m740.sv, NS2-9) at 8.192 MHz, a cycle every 4 clocks: 2.048 MHz, a clock enable every 24 clocks.
rtl/ns2_c68.sv:3 Its on-chip peripherals as MAME's m3745x.cpp: 0000-00bf RAM 00d6-00dd ports P3-P6 and their direction 00e2-00e3 A/D 00fc-00ff interrupt requests and enables 0100-01ff RAM (the stack) and the board's map (c68_default_am
rtl/ns2_c68.sv:16 Interrupts: MAME's m3745x maps the enabled requests to m740 lines; any raises irq and the lowest line gives the vector (0xfffc - 2 * line): requests 1 bit 2 (INT1, line 200's VBL) -> line 2, 0xfff8 requests 1 bits 3, 4 -> lines 3, 4; reque
rtl/ns2_c68.sv:42 inputs (MAME's ports)
rtl/ns2_c68.sv:50 MAME's taps see this access
rtl/ns2_c68.sv:103 the ports' inputs (MAME's read_p callbacks)
rtl/ns2_c68.sv:188 MAME's reset clears the requests: nothing from before the release
rtl/ns2_controls.sv:1 The players' controls onto the I/O MCU's ports (namcos2.cpp's input ports): the digital ports MCUB, MCUC, MCUH and the eight analog channels AN0-AN7, per the set's control mode (config byte 33, tools/ns2_romdata.py): [1:0] 0 digital (MAME's
rtl/ns2_controls.sv:14 Ghost!, Bubble Trouble); otherwise MCUH 5 and 4, the bombs MCUH 3 and 2 the wheel and pedals: [4] Start on MCUB 7 / 6 (Four Trax, Suzuka) [5] the gears on MCUB: 5 down (the d-pad's up, or B4), 7 up (the d-pad's down, or B3) (Dirt Fox) M
rtl/ns2_controls.sv:23 A gun's value is its position across the board's own picture, 0 at the left (top) to 255 at the right (bottom), as MAME's crosshair maps it; the players aim at the displayed picture, turned 180 degrees when `flip`.
rtl/ns2_controls.sv:26 Wheel: 0x01-0xff, 0x80 centred; accelerator 0-0x80, brake 0-0x40; Metal Hawk's stick and lever 0x20-0xe0 (MAME's PORT_MINMAX).
rtl/ns2_controls.sv:27 A stick sets a value outright; a button or the d-pad moves it a step a frame, as MAME's key delta, and it returns when released.
rtl/ns2_controls.sv:36 MAME's power-on AN0-AN7 (config bytes 21-28)
rtl/ns2_controls.sv:44 MAME's power-on MCUDI0-3 (config bytes 29-32)
rtl/ns2_controls.sv:101 ------------------------------------------------------------ the guns Each gun aims from the stick (or a MiSTer gun), the d-pad (8 a frame, MAME's key delta; it stays where it is left), or for player 1 the mouse: whichever moved last.
rtl/ns2_controls.sv:165 ------------------------------------------------------------ Assault Two 4-way sticks a player, a tank's two tracks (MAME's assault ports): the left on MCUB (up, down, left) and MCUH 7/6 (right), the right on MCUH (up, down) and MCUDI0 (rig
rtl/ns2_controls.sv:225 MAME's default ports (namcos2.cpp NAMCOS2_MCU_PORT_*_DEFAULT), active low
rtl/ns2_cpu.sv:1 One of the two 68000s with its own bus (namcos2.cpp master_common_am / slave_common_am): fx68k at 12.288 MHz (a PHI1 and a PHI2 enable every 4 clocks of the 49.152 MHz clk), its program ROM, 64 KB of work RAM (the slave's 0x100000-0x13ffff
rtl/ns2_cpu.sv:8 Interrupt acknowledges are answered with the autovector 24 + level (MAME's m68000 with the C148 on the IPL lines).
rtl/ns2_cpu.sv:264 ext_in: MAME leaves it unconnected (7)
rtl/ns2_fir4.sv:1 A sound chip's anti-imaging interpolator (NS2-26, NS2-29): its samples (one per in_stb) out at 4x through a 128-tap low-pass whose passband is MAME's own resampler's response (tools/ns2_firgen.py): a held sample puts images above the chip's
rtl/ns2_hd63705.v:1 Derived from jt6805 (jotego/jtcores modules/jt680x @ 3eb8fec, GPL-3.0-or-later, rtl/third_party/jt680x) for the C65's HD63705Z0 as MAME implements it (hd6305.cpp, docs/PLAN.md D2): 16-bit addresses; the stack in page 1 (0x100-0x17f, 7 bits)
rtl/ns2_hd63705_alu.v:1 Derived from jt6805 (jotego/jtcores modules/jt680x @ 3eb8fec, GPL-3.0-or-later, rtl/third_party/jt680x) for the C65's HD63705Z0 as MAME implements it (hd6305.cpp, docs/PLAN.md D2): 16-bit addresses; the stack in page 1 (0x100-0x17f, 7 bits)
rtl/ns2_hd63705_ctrl.v:1 Derived from jt6805 (jotego/jtcores modules/jt680x @ 3eb8fec, GPL-3.0-or-later, rtl/third_party/jt680x) for the C65's HD63705Z0 as MAME implements it (hd6305.cpp, docs/PLAN.md D2): 16-bit addresses; the stack in page 1 (0x100-0x17f, 7 bits)
rtl/ns2_hd63705_ctrl.v:66 MAME's order: IRQ1 before the A/D interrupt
rtl/ns2_hd63705_regs.v:1 Derived from jt6805 (jotego/jtcores modules/jt680x @ 3eb8fec, GPL-3.0-or-later, rtl/third_party/jt680x) for the C65's HD63705Z0 as MAME implements it (hd6305.cpp, docs/PLAN.md D2): 16-bit addresses; the stack in page 1 (0x100-0x17f, 7 bits)
rtl/ns2_key.sv:1 The key custom (namcos2_m.cpp namcos2_68k_key_r / _w): 8 word registers.
rtl/ns2_key.sv:2 Per set, some offsets return a constant (the protection check); every other read returns MAME's random value, which the oracle patch makes the LFSR r = (r >> 1) ^ (r & 1 ?
rtl/ns2_m740.sv:1 GENERATED by tools/ns2_740gen.py from MAME's devices/cpu/m6502 (dm740.lst, om740.lst, om6502.lst; BSD-3-Clause, Olivier Galibert): do not edit.
rtl/ns2_m740.sv:3 The Mitsubishi 740 core of the C68's M37450, cycle for cycle as MAME's m740 (NS2-9).
rtl/ns2_m740.sv:8 irq is MAME's m_irq_state (any enabled request), irq_vector its m_irq_vector; both are sampled at the opcode fetch, as MAME's prefetch_end.
rtl/ns2_m740.sv:10 On reset the registers take MAME's power-on values and the core runs reset_m (the vector at 0xfffe).
rtl/ns2_m740.sv:22 MAME's taps see this access (not read_pc, read_arg or a fetch)
rtl/ns2_m740.sv:33 MAME's registers (blocking: the statements between two bus cycles run in C's order within one clock; the bus outputs are registered from b_*)
rtl/ns2_m740.sv:72 ---------------------------------------------------------------- m6502.cpp
rtl/ns2_m740.sv:197 ---------------------------------------------------------------- m740.cpp: T mode on m_TMP
rtl/ns2_m740.sv:258 the prefetch's end: the opcode, then MAME's prefetch_end (the interrupt check)
rtl/ns2_m740.sv:2416 MAME's STATE_RESET: reset_m from its start
rtl/ns2_main.sv:1 The two 68000s and their shared bus (namcos2.cpp: namcos2_68k_default_cpu_board_am, common_default_am, common_finallap_am): the arbiter grants one access at a time (master first when both ask in the same clock); an access takes three clocks
rtl/ns2_main.sv:179 the arbiter: the grant with the address, then the devices' read latency, then the capture (three clocks, the master first): the 68000 gets DTACK in time for no wait state, as in MAME
rtl/ns2_main.sv:200 the boards' maps (namcos2.cpp): the CPU board's, then each graphics board's 0 standard: c00000 sprites, c40000 gfx_ctrl, c80000 ROZ RAM, cc0000 ROZ control, d00000 key 1 Final Lap: 300000 protection, 800000 sprites, 840000 gfx_ctrl, 880000
rtl/ns2_main.sv:318 (MAME's umask16 reads: the other lane 0)
rtl/ns2_main.sv:320 finallap_state::finallap_prot_r (namcos2_m.cpp): two tables on a counter that reads of words 3 and 1ffff advance
rtl/ns2_mem.sv:10 It applies the board wiring MAME applies after loading (tools/ns2_romdata.py WIRING): Metal Hawk's sprite reorder (a byte lands in 0, 1 or 2 places) and its transposed copy for the rot90 sprites, and Lucky & Wild's bit-reversed C169 mask.
rtl/ns2_mem.sv:18 WRAM_SD (the Suzuka and Lucky & Wild bitstreams): the 68000s' work RAMs and the C139's RAM are bank 1 clients that also write (ns2_wram_cache); the download first clears them, as MAME's RAM starts at 0 and the board's SDRAM keeps the last c
rtl/ns2_mem.sv:28 MAME loads one byte lane of some 16-bit regions and leaves the other at 0: the C140 voices' odd bytes always, the data ROM's second megabyte where these say (rthun2: the odd bytes; suzuka8h: the even).
rtl/ns2_mem.sv:106 Metal Hawk's reorder, per 4x4 block of a 32x32 tile: where a source byte (row r, column c in the block) goes; MAME's loop carries one byte into two places and drops another (tools/ns2_romdata.py _metlhawk_sprite)
rtl/ns2_roz.sv:1 ROZ (A) (namcos2_roz.cpp draw_roz; tools/ns2_model.py roz_layer is the specification): renders one line of the ROZ plane into its own line buffer.
rtl/ns2_roz.sv:3 The mixer resolves it against the tilemaps: MAME draws it after every plane of its priority or lower, so it wins over those and loses to higher ones.
rtl/ns2_roz.sv:9 Without wrap a pixel is inside when xpos <= size and ypos < size (MAME's comparisons).
rtl/ns2_sound.sv:1 The sound board (namcos2.cpp sound_default_am): the 6809 at 2.048 MHz (E and Q from clk: 24 clocks an E cycle), the YM2151 (jt51, 3.579545 MHz), the C140 (rtl/ns2_c140.sv), 8 KB of RAM and the DPRAM's third port.
rtl/ns2_sound.sv:4 0000-3fff banked ROM (16 KB banks; c000-c001 writes select data >> 4) 4000-4001 YM2151 5000-51ff, 6000-61ff C140 (mirrored) 7000-77ff DPRAM (mirrored) 8000-9fff RAM a000-bfff amplifier enable (writes ignored) c000-ffff ROM (the re
rtl/ns2_sound.sv:10 The YM2151's IRQ is not wired (MAME comments it out).
rtl/ns2_sprite_a.sv:1 Sprites (A) (namcos2_sprite.cpp draw_sprites; tools/ns2_model.py sprites_a is the specification): renders one line of the 128 sprites of the bank gfx_ctrl & 0xf into the sprite line buffer, in list order, a later sprite overwriting an earli
rtl/ns2_sprite_a.sv:7 MAME's zoom reduces to a screen size of sizex x sizey (sizex halved for 16x16), the source stepping by (gw << 16) / size per screen pixel, from the far edge when flipped: row = ((flipy ?
rtl/ns2_sprite_a.sv:41 (gw << 16) / n for n = 1..64, gw = 16 or 32: MAME's zoom step, from a table of (32 << 16) / n (a divider does not fit a clock); for gw 16 it is halved, floor(floor(x / n) / 2) being floor(x / 2n)
rtl/ns2_sprite_a.sv:74 the screen width: MAME's (scalex * gw + 0x8000) >> 16; Metal Hawk's scalex always divides by 0x20, so a 16-wide sprite is (sizex + 1) / 2
rtl/ns2_sprite_a.sv:122 w0 is in: the line test (sh >= 2 is MAME's sizey - 1 != 0); Metal Hawk's position also depends on word 6, so it tests later
rtl/ns2_video.sv:116 MAME's screen starts at the top of VBLANK (vpos 224)
rtl/ns2_video.sv:156 MAME's POSIRQ line: (C116 register 5 - 32) & 0xff (namcos2 get_pos_irq_scanline)
rtl/ns2_video.sv:239 the C116 sits on D7-D0 and takes any byte of the word (MAME's umask16(0x00ff).cswidth(16)): a byte write to the even address (UDS alone) writes too, with the byte the 68000 puts on both lanes
rtl/ns2_video.sv:263 registers 6 and 7 read 0xff (namcos2_base_state::c116_r, MAME's "fix for finallap boot")
rtl/ns2_video.sv:294 MAME's umask16 reads fill the other lane with 0
rtl/ns2_video.sv:524 At equal priority MAME draws planes, then ROZ or road, then C169 layer 1, then layer 0: the pixel shows the last drawn, the largest {priority, order}
rtl/ns2_ym_fifo.sv:2 jt51 applies an operator or key-on write over the next 32 of its cycles (64 with its half-rate phase), and a write before that cancels or redirects it; the games write every 26-28 cycles without reading the busy flag (Rolling Thunder 2: no
README.md:7 The joystick games use MAME's default ports (one joystick, three buttons, Start, Coin, Service).
README.md:18 **MAME as the reference.** MAME's `namco/namcos2.cpp` (K. Wilkins) and its devices, at a pinned commit (`deps.lock`), define the behaviour.
README.md:22 **Gates are measurements.** Each milestone ends in a measured gate, not a judgement: the video against MAME's state (M1), the whole board against MAME's bus tra
README.md:27 **Cycle-faithful CPUs.** Both 68000s, the 6809 and the I/O MCU (C65 or C68) run at MAME's clocks and bus timing.
README.md:30 **Every set in MAME's driver**, including Final Lap 1-3, Four Trax and the NB-1 boards (Steel Gunner, Suzuka 8 Hours, Lucky & Wild).
README.md:44 | Game | Year | MAME set | Bitstream | Controls | Alternates |
README.md:95 **Cheats** from Pugsy's MAME cheat database: ten fixed slots (Infinite Time, Infinite Credits, P1/P2 Invincibility, P1/P2 Infinite Lives, P1/P2 Infinite Energy,
README.md:118 The games on MAME's common ports have their own button names, and the buttons a game never reads are hidden: Cosmo Gang (Fire), Dragon Saber (Fire, Bomb), Marve
README.md:132 or the d-pad's up, as MAME's ports.
README.md:208 The C139 serial link between cabinets is not emulated (nor is it in MAME): each cabinet plays alone.
README.md:235 Derived from MAME (BSD-3-Clause), besides its use as the behavioural reference:
README.md:237 `rtl/ns2_m740.sv` (the C68's 740 core) is generated by `tools/ns2_740gen.py` from MAME's `dm740.lst`, `om740.lst` and `om6502.lst`, by Olivier Galibert; its hel
README.md:241 `rtl/ns2_c140.sv` ports MAME's `sound/c140.cpp`, by R. Belmont.
README.md:242 `tools/ns2_romdata.py` reads its ROM tables from MAME's `namcos2.cpp` (K. Wilkins and the MAME contributors).

Says it matches, follows or was checked against MAME — 1

README.md:122 Each was checked in MAME, a press in play against the same run without it.

Shares text with the MAME driver without saying so — 5

rtl/ns2_c123.sv:44 TilemapCB: bitswap<16>(code, 13,12,11,15,14,10..0); — shares text with namco/namcos2_v.cpp:12
rtl/ns2_c123.sv:45 TilemapCB_finalap2: bitswap<15>(code, 13,12,11,14,10..0) — shares text with namco/namcos2_v.cpp:18
rtl/ns2_c169.sv:65 bitswap<13>(c & 0x1fff, 11,10,9,12,8..0) — shares text with namco/namcos2_v.cpp:260
rtl/ns2_main.sv:1 The two 68000s and their shared bus (namcos2.cpp: namcos2_68k_default_cpu_board_am, — shares text with namco/namcos2.cpp:682
rtl/ns2_tile_filter.sv:47 TilemapCB undone: tile [15:11] = code {13, 12, 11, 15, 14} (standard), — shares text with namco/namcos2_v.cpp:12

Arcade-NamcoS2_SG#
Steel Gunner, Steel Gunner 2
kuzearcade/Arcade-NamcoSystem2_MiSTer @ 5fe71a59
MAME compared: namco/namcos2.cpp + 23 related file(s)
Read: 48 HDL files, 23,027 lines (Quartus project)

kuzecores
independent database

Mostly MAME

medium

63%

Statements: 122 toward MAME

Cites MAME source — 116

NamcoS2.sv:98 180 degrees in the core, on every video path (ns2_flipbuf); a ROT180 set (MAME's Bubble Trouble) starts turned, and this turns it back
NamcoS2.sv:326 MAME's power-on analog and dial values (M5 maps the controls onto them)
NamcoS2.sv:338 Byte 0 is MAME's DSW port (the MCU's $2000; bit 7 the test switch).
NamcoS2.sv:352 Keyboard: MAME's default bindings, always live, ORed with the pads.
NamcoS2.sv:393 Inputs: MAME's ports (namcos2.cpp NAMCOS2_MCU_PORT_*_DEFAULT), active low.
NamcoS2.sv:402 The sets with a wheel and pedals, light guns or Metal Hawk's stick map the analog sticks and the mouse onto AN0-AN7 (ns2_controls, the set's control mode in config byte 33); the others keep MAME's power-on values.
NamcoS2.sv:733 Audio: MAME's routes (namcos2.cpp), both stereo, the set's own gains (config bytes 36-37, x128; NS2-26): the C140 at 0.75 (base2 and Metal Hawk 1.0, base3 0.45), the YM2151 at 0.80 (base3 1.0).
NamcoS2.sv:735 Each chip first through its anti-imaging interpolator (ns2_fir4: 4x, MAME's resampler's response in the passband, NS2-26 and NS2-29): a held sample has images above the chip's Nyquist (the C140's 10.67 kHz, jt51's 27.97 kHz, which MiSTer's
rtl/cheats.sv:1 Cheat engine — applies Pugsy MAME-database pokes to work RAM once a frame.
rtl/cheats.sv:34 Poke semantics follow MAME's "run" state: the value is written every frame for as long as the cheat is enabled, which is what makes "infinite" cheats hold against the game decrementing the counter.
rtl/ns2_board.sv:9 Line events, at the start of the line (MAME's scanline timer): 200 the MCU's IRQ1, 240 both C148s' VBLANK, (reg5 - 32) & 0xff POSIRQ.
rtl/ns2_board.sv:23 inputs (MAME's ports)
rtl/ns2_c123.sv:1 C123 tilemaps (namco_c123tmap.cpp; tools/ns2_model.py tilemap_layer is the specification): renders one line of the six planes into the composition line buffer, in MAME's draw order (priority 0..7, then plane 0..5), each opaque pixel overwri
rtl/ns2_c123.sv:51 The planes in MAME's draw order (priority 0..7, then plane 0..5) are listed first; then a fetch engine fills slot bank k & 1 for the k-th listed plane while the pixel engine draws the plane before it from the other bank: a line costs about
rtl/ns2_c140.sv:1 C140 (MAME c140.cpp): 24 PCM voices, the register file, the key-on status and the INT1 timer that drives the 6809's FIRQ.
rtl/ns2_c140.sv:3 0x000-0x17f 24 voices x 16 registers: 0 volume right, 1 volume left, 2-3 frequency, 4 bank, 5 mode (key-on on bit 7, or bit 6 while keyed; bit 4 loop, bit 3 compressed), 6-7 start, 8-9 end, 10-11 loop (sample words within the bank) 0x1f8
rtl/ns2_c140.sv:14 The voices, as MAME's sound_stream_update, one sample per base-rate tick (21.333 kHz: clk / 2304; MAME_RATE = 1 uses MAME's stream edges instead, its integer 21333 Hz, for the sample-exact comparison): offset += frequency * 2; pos += offset
rtl/ns2_c140.sv:24 MAME computes the samples whose edge has passed before it applies a register write, so a write never reaches a sample being computed: the voice register writes wait in a queue while the voices run (the CPU's view, the register reads and the
rtl/ns2_c140.sv:29 Voice ROM words: c140_rom_r (namcos2_m.cpp), the schematics' wiring: word address bit 21 picks voice1/voice2 for bits 15-8, bit 20 low enables voice0's nibble for bits 7-4, bit 19 low picks its low nibble.
rtl/ns2_c140.sv:48 the output, one sample per tick; raw_*: MAME's mixer sums (debug)
rtl/ns2_c140.sv:77 the timer counts clocks from the write, as MAME's (an exact duration, not the base-rate ticks' edges): (reload + 1) * 2 * 2304 clocks
rtl/ns2_c140.sv:120 the voices' state (MAME's C140_VOICE)
rtl/ns2_c140.sv:150 MAME's compressed table: j = (s8)i; s1 = j & 7; s2 = abs(j >> 3) & 31; v = ((0x80 << s1) & 0xff00) + (s2 << (s1 ?
rtl/ns2_c140.sv:167 MAME's put_int_clamp(v, 4096): +-1.0 full scale, as 16 bits
rtl/ns2_c140.sv:273 the key-on decision is MAME's, at the write
rtl/ns2_c140.sv:337 MAME's per-sample step, voice ev
rtl/ns2_c148.sv:1 C148: a 68000's interrupt controller and board control (namco_c148.cpp).
rtl/ns2_c148.sv:13 MAME drives the 68000's input line of the source's level, not a per-source OR: a trigger sets the line of the source's current level, an ack (or a level write, which acks first) clears it, whatever else shares the level.
rtl/ns2_c148.sv:94 line and hold are updated in order (blocking): the events of one clock apply as MAME applies them, one after another the acknowledge of a held level
rtl/ns2_c169.sv:1 C169 ROZ (namco_c169roz.cpp; tools/ns2_model.py c169_params / c169_rows / draw_c169 are the specification): renders one line of both layers, layer 1 then layer 0, each into its own line buffer with its priority and colour per pixel (the per
rtl/ns2_c355.sv:1 C355 sprites (namco_c355spr.cpp; tools/ns2_c355hw.py is the specification, proven equal to MAME's frame algorithm, tools/ns2_model.py sprites_c355).
rtl/ns2_c45.sv:1 C45 road (namco_c45road.cpp draw; tools/ns2_model.py road_line is the specification): renders one line of the road into the ROZ line buffer (a board has one or the other), with the line's priority.
rtl/ns2_c65.sv:1 The C65 I/O MCU (MAME namco65.cpp): the HD63705 (rtl/ns2_hd63705.v, NS2-7) at 2.048 MHz (its crystal clock: a clock enable every 24 clocks) and its memory map: 0000-003f RAM, reads of 01 (MCUB), 02 (MCUC), 03 (port D: the analog inputs over
rtl/ns2_c65.sv:13 IRQ1 (line 200) and the A/D interrupt are latched until the core fetches their vectors (0x1ff8, 0x1fea), as MAME's pending interrupts.
rtl/ns2_c65.sv:14 MAME holds the IRQ1 input (HOLD_LINE) until the core enters any interrupt, and the core latches IRQ1 only when that input changes: a line-200 event while the input is still held is lost.
rtl/ns2_c65.sv:40 inputs (MAME's ports, active low where the board is)
rtl/ns2_c65.sv:78 MAME's IRQ1 input: held until an interrupt is taken
rtl/ns2_c68.sv:1 The C68 I/O MCU (MAME namco68.cpp): an M37450 (rtl/ns2_m740.sv, NS2-9) at 8.192 MHz, a cycle every 4 clocks: 2.048 MHz, a clock enable every 24 clocks.
rtl/ns2_c68.sv:3 Its on-chip peripherals as MAME's m3745x.cpp: 0000-00bf RAM 00d6-00dd ports P3-P6 and their direction 00e2-00e3 A/D 00fc-00ff interrupt requests and enables 0100-01ff RAM (the stack) and the board's map (c68_default_am
rtl/ns2_c68.sv:16 Interrupts: MAME's m3745x maps the enabled requests to m740 lines; any raises irq and the lowest line gives the vector (0xfffc - 2 * line): requests 1 bit 2 (INT1, line 200's VBL) -> line 2, 0xfff8 requests 1 bits 3, 4 -> lines 3, 4; reque
rtl/ns2_c68.sv:42 inputs (MAME's ports)
rtl/ns2_c68.sv:50 MAME's taps see this access
rtl/ns2_c68.sv:103 the ports' inputs (MAME's read_p callbacks)
rtl/ns2_c68.sv:188 MAME's reset clears the requests: nothing from before the release
rtl/ns2_controls.sv:1 The players' controls onto the I/O MCU's ports (namcos2.cpp's input ports): the digital ports MCUB, MCUC, MCUH and the eight analog channels AN0-AN7, per the set's control mode (config byte 33, tools/ns2_romdata.py): [1:0] 0 digital (MAME's
rtl/ns2_controls.sv:14 Ghost!, Bubble Trouble); otherwise MCUH 5 and 4, the bombs MCUH 3 and 2 the wheel and pedals: [4] Start on MCUB 7 / 6 (Four Trax, Suzuka) [5] the gears on MCUB: 5 down (the d-pad's up, or B4), 7 up (the d-pad's down, or B3) (Dirt Fox) M
rtl/ns2_controls.sv:23 A gun's value is its position across the board's own picture, 0 at the left (top) to 255 at the right (bottom), as MAME's crosshair maps it; the players aim at the displayed picture, turned 180 degrees when `flip`.
rtl/ns2_controls.sv:26 Wheel: 0x01-0xff, 0x80 centred; accelerator 0-0x80, brake 0-0x40; Metal Hawk's stick and lever 0x20-0xe0 (MAME's PORT_MINMAX).
rtl/ns2_controls.sv:27 A stick sets a value outright; a button or the d-pad moves it a step a frame, as MAME's key delta, and it returns when released.
rtl/ns2_controls.sv:36 MAME's power-on AN0-AN7 (config bytes 21-28)
rtl/ns2_controls.sv:44 MAME's power-on MCUDI0-3 (config bytes 29-32)
rtl/ns2_controls.sv:101 ------------------------------------------------------------ the guns Each gun aims from the stick (or a MiSTer gun), the d-pad (8 a frame, MAME's key delta; it stays where it is left), or for player 1 the mouse: whichever moved last.
rtl/ns2_controls.sv:165 ------------------------------------------------------------ Assault Two 4-way sticks a player, a tank's two tracks (MAME's assault ports): the left on MCUB (up, down, left) and MCUH 7/6 (right), the right on MCUH (up, down) and MCUDI0 (rig
rtl/ns2_controls.sv:225 MAME's default ports (namcos2.cpp NAMCOS2_MCU_PORT_*_DEFAULT), active low
rtl/ns2_cpu.sv:1 One of the two 68000s with its own bus (namcos2.cpp master_common_am / slave_common_am): fx68k at 12.288 MHz (a PHI1 and a PHI2 enable every 4 clocks of the 49.152 MHz clk), its program ROM, 64 KB of work RAM (the slave's 0x100000-0x13ffff
rtl/ns2_cpu.sv:8 Interrupt acknowledges are answered with the autovector 24 + level (MAME's m68000 with the C148 on the IPL lines).
rtl/ns2_cpu.sv:264 ext_in: MAME leaves it unconnected (7)
rtl/ns2_fir4.sv:1 A sound chip's anti-imaging interpolator (NS2-26, NS2-29): its samples (one per in_stb) out at 4x through a 128-tap low-pass whose passband is MAME's own resampler's response (tools/ns2_firgen.py): a held sample puts images above the chip's
rtl/ns2_hd63705.v:1 Derived from jt6805 (jotego/jtcores modules/jt680x @ 3eb8fec, GPL-3.0-or-later, rtl/third_party/jt680x) for the C65's HD63705Z0 as MAME implements it (hd6305.cpp, docs/PLAN.md D2): 16-bit addresses; the stack in page 1 (0x100-0x17f, 7 bits)
rtl/ns2_hd63705_alu.v:1 Derived from jt6805 (jotego/jtcores modules/jt680x @ 3eb8fec, GPL-3.0-or-later, rtl/third_party/jt680x) for the C65's HD63705Z0 as MAME implements it (hd6305.cpp, docs/PLAN.md D2): 16-bit addresses; the stack in page 1 (0x100-0x17f, 7 bits)
rtl/ns2_hd63705_ctrl.v:1 Derived from jt6805 (jotego/jtcores modules/jt680x @ 3eb8fec, GPL-3.0-or-later, rtl/third_party/jt680x) for the C65's HD63705Z0 as MAME implements it (hd6305.cpp, docs/PLAN.md D2): 16-bit addresses; the stack in page 1 (0x100-0x17f, 7 bits)
rtl/ns2_hd63705_ctrl.v:66 MAME's order: IRQ1 before the A/D interrupt
rtl/ns2_hd63705_regs.v:1 Derived from jt6805 (jotego/jtcores modules/jt680x @ 3eb8fec, GPL-3.0-or-later, rtl/third_party/jt680x) for the C65's HD63705Z0 as MAME implements it (hd6305.cpp, docs/PLAN.md D2): 16-bit addresses; the stack in page 1 (0x100-0x17f, 7 bits)
rtl/ns2_key.sv:1 The key custom (namcos2_m.cpp namcos2_68k_key_r / _w): 8 word registers.
rtl/ns2_key.sv:2 Per set, some offsets return a constant (the protection check); every other read returns MAME's random value, which the oracle patch makes the LFSR r = (r >> 1) ^ (r & 1 ?
rtl/ns2_m740.sv:1 GENERATED by tools/ns2_740gen.py from MAME's devices/cpu/m6502 (dm740.lst, om740.lst, om6502.lst; BSD-3-Clause, Olivier Galibert): do not edit.
rtl/ns2_m740.sv:3 The Mitsubishi 740 core of the C68's M37450, cycle for cycle as MAME's m740 (NS2-9).
rtl/ns2_m740.sv:8 irq is MAME's m_irq_state (any enabled request), irq_vector its m_irq_vector; both are sampled at the opcode fetch, as MAME's prefetch_end.
rtl/ns2_m740.sv:10 On reset the registers take MAME's power-on values and the core runs reset_m (the vector at 0xfffe).
rtl/ns2_m740.sv:22 MAME's taps see this access (not read_pc, read_arg or a fetch)
rtl/ns2_m740.sv:33 MAME's registers (blocking: the statements between two bus cycles run in C's order within one clock; the bus outputs are registered from b_*)
rtl/ns2_m740.sv:72 ---------------------------------------------------------------- m6502.cpp
rtl/ns2_m740.sv:197 ---------------------------------------------------------------- m740.cpp: T mode on m_TMP
rtl/ns2_m740.sv:258 the prefetch's end: the opcode, then MAME's prefetch_end (the interrupt check)
rtl/ns2_m740.sv:2416 MAME's STATE_RESET: reset_m from its start
rtl/ns2_main.sv:1 The two 68000s and their shared bus (namcos2.cpp: namcos2_68k_default_cpu_board_am, common_default_am, common_finallap_am): the arbiter grants one access at a time (master first when both ask in the same clock); an access takes three clocks
rtl/ns2_main.sv:179 the arbiter: the grant with the address, then the devices' read latency, then the capture (three clocks, the master first): the 68000 gets DTACK in time for no wait state, as in MAME
rtl/ns2_main.sv:200 the boards' maps (namcos2.cpp): the CPU board's, then each graphics board's 0 standard: c00000 sprites, c40000 gfx_ctrl, c80000 ROZ RAM, cc0000 ROZ control, d00000 key 1 Final Lap: 300000 protection, 800000 sprites, 840000 gfx_ctrl, 880000
rtl/ns2_main.sv:318 (MAME's umask16 reads: the other lane 0)
rtl/ns2_main.sv:320 finallap_state::finallap_prot_r (namcos2_m.cpp): two tables on a counter that reads of words 3 and 1ffff advance
rtl/ns2_mem.sv:10 It applies the board wiring MAME applies after loading (tools/ns2_romdata.py WIRING): Metal Hawk's sprite reorder (a byte lands in 0, 1 or 2 places) and its transposed copy for the rot90 sprites, and Lucky & Wild's bit-reversed C169 mask.
rtl/ns2_mem.sv:18 WRAM_SD (the Suzuka and Lucky & Wild bitstreams): the 68000s' work RAMs and the C139's RAM are bank 1 clients that also write (ns2_wram_cache); the download first clears them, as MAME's RAM starts at 0 and the board's SDRAM keeps the last c
rtl/ns2_mem.sv:28 MAME loads one byte lane of some 16-bit regions and leaves the other at 0: the C140 voices' odd bytes always, the data ROM's second megabyte where these say (rthun2: the odd bytes; suzuka8h: the even).
rtl/ns2_mem.sv:106 Metal Hawk's reorder, per 4x4 block of a 32x32 tile: where a source byte (row r, column c in the block) goes; MAME's loop carries one byte into two places and drops another (tools/ns2_romdata.py _metlhawk_sprite)
rtl/ns2_roz.sv:1 ROZ (A) (namcos2_roz.cpp draw_roz; tools/ns2_model.py roz_layer is the specification): renders one line of the ROZ plane into its own line buffer.
rtl/ns2_roz.sv:3 The mixer resolves it against the tilemaps: MAME draws it after every plane of its priority or lower, so it wins over those and loses to higher ones.
rtl/ns2_roz.sv:9 Without wrap a pixel is inside when xpos <= size and ypos < size (MAME's comparisons).
rtl/ns2_sound.sv:1 The sound board (namcos2.cpp sound_default_am): the 6809 at 2.048 MHz (E and Q from clk: 24 clocks an E cycle), the YM2151 (jt51, 3.579545 MHz), the C140 (rtl/ns2_c140.sv), 8 KB of RAM and the DPRAM's third port.
rtl/ns2_sound.sv:4 0000-3fff banked ROM (16 KB banks; c000-c001 writes select data >> 4) 4000-4001 YM2151 5000-51ff, 6000-61ff C140 (mirrored) 7000-77ff DPRAM (mirrored) 8000-9fff RAM a000-bfff amplifier enable (writes ignored) c000-ffff ROM (the re
rtl/ns2_sound.sv:10 The YM2151's IRQ is not wired (MAME comments it out).
rtl/ns2_sprite_a.sv:1 Sprites (A) (namcos2_sprite.cpp draw_sprites; tools/ns2_model.py sprites_a is the specification): renders one line of the 128 sprites of the bank gfx_ctrl & 0xf into the sprite line buffer, in list order, a later sprite overwriting an earli
rtl/ns2_sprite_a.sv:7 MAME's zoom reduces to a screen size of sizex x sizey (sizex halved for 16x16), the source stepping by (gw << 16) / size per screen pixel, from the far edge when flipped: row = ((flipy ?
rtl/ns2_sprite_a.sv:41 (gw << 16) / n for n = 1..64, gw = 16 or 32: MAME's zoom step, from a table of (32 << 16) / n (a divider does not fit a clock); for gw 16 it is halved, floor(floor(x / n) / 2) being floor(x / 2n)
rtl/ns2_sprite_a.sv:74 the screen width: MAME's (scalex * gw + 0x8000) >> 16; Metal Hawk's scalex always divides by 0x20, so a 16-wide sprite is (sizex + 1) / 2
rtl/ns2_sprite_a.sv:122 w0 is in: the line test (sh >= 2 is MAME's sizey - 1 != 0); Metal Hawk's position also depends on word 6, so it tests later
rtl/ns2_video.sv:116 MAME's screen starts at the top of VBLANK (vpos 224)
rtl/ns2_video.sv:156 MAME's POSIRQ line: (C116 register 5 - 32) & 0xff (namcos2 get_pos_irq_scanline)
rtl/ns2_video.sv:239 the C116 sits on D7-D0 and takes any byte of the word (MAME's umask16(0x00ff).cswidth(16)): a byte write to the even address (UDS alone) writes too, with the byte the 68000 puts on both lanes
rtl/ns2_video.sv:263 registers 6 and 7 read 0xff (namcos2_base_state::c116_r, MAME's "fix for finallap boot")
rtl/ns2_video.sv:294 MAME's umask16 reads fill the other lane with 0
rtl/ns2_video.sv:524 At equal priority MAME draws planes, then ROZ or road, then C169 layer 1, then layer 0: the pixel shows the last drawn, the largest {priority, order}
rtl/ns2_ym_fifo.sv:2 jt51 applies an operator or key-on write over the next 32 of its cycles (64 with its half-rate phase), and a write before that cancels or redirects it; the games write every 26-28 cycles without reading the busy flag (Rolling Thunder 2: no
README.md:7 The joystick games use MAME's default ports (one joystick, three buttons, Start, Coin, Service).
README.md:18 **MAME as the reference.** MAME's `namco/namcos2.cpp` (K. Wilkins) and its devices, at a pinned commit (`deps.lock`), define the behaviour.
README.md:22 **Gates are measurements.** Each milestone ends in a measured gate, not a judgement: the video against MAME's state (M1), the whole board against MAME's bus tra
README.md:27 **Cycle-faithful CPUs.** Both 68000s, the 6809 and the I/O MCU (C65 or C68) run at MAME's clocks and bus timing.
README.md:30 **Every set in MAME's driver**, including Final Lap 1-3, Four Trax and the NB-1 boards (Steel Gunner, Suzuka 8 Hours, Lucky & Wild).
README.md:44 | Game | Year | MAME set | Bitstream | Controls | Alternates |
README.md:95 **Cheats** from Pugsy's MAME cheat database: ten fixed slots (Infinite Time, Infinite Credits, P1/P2 Invincibility, P1/P2 Infinite Lives, P1/P2 Infinite Energy,
README.md:118 The games on MAME's common ports have their own button names, and the buttons a game never reads are hidden: Cosmo Gang (Fire), Dragon Saber (Fire, Bomb), Marve
README.md:132 or the d-pad's up, as MAME's ports.
README.md:208 The C139 serial link between cabinets is not emulated (nor is it in MAME): each cabinet plays alone.
README.md:235 Derived from MAME (BSD-3-Clause), besides its use as the behavioural reference:
README.md:237 `rtl/ns2_m740.sv` (the C68's 740 core) is generated by `tools/ns2_740gen.py` from MAME's `dm740.lst`, `om740.lst` and `om6502.lst`, by Olivier Galibert; its hel
README.md:241 `rtl/ns2_c140.sv` ports MAME's `sound/c140.cpp`, by R. Belmont.
README.md:242 `tools/ns2_romdata.py` reads its ROM tables from MAME's `namcos2.cpp` (K. Wilkins and the MAME contributors).

Says it matches, follows or was checked against MAME — 1

README.md:122 Each was checked in MAME, a press in play against the same run without it.

Shares text with the MAME driver without saying so — 5

rtl/ns2_c123.sv:44 TilemapCB: bitswap<16>(code, 13,12,11,15,14,10..0); — shares text with namco/namcos2_v.cpp:12
rtl/ns2_c123.sv:45 TilemapCB_finalap2: bitswap<15>(code, 13,12,11,14,10..0) — shares text with namco/namcos2_v.cpp:18
rtl/ns2_c169.sv:65 bitswap<13>(c & 0x1fff, 11,10,9,12,8..0) — shares text with namco/namcos2_v.cpp:260
rtl/ns2_main.sv:1 The two 68000s and their shared bus (namcos2.cpp: namcos2_68k_default_cpu_board_am, — shares text with namco/namcos2.cpp:682
rtl/ns2_tile_filter.sv:47 TilemapCB undone: tile [15:11] = code {13, 12, 11, 15, 14} (standard), — shares text with namco/namcos2_v.cpp:12

Arcade-NamcoS2_STD#
Assault, Bubble Trouble - Golly! Ghost! 2, Burning Force (Japan, new version (Rev C)), Cosmo Gang the Video …
kuzearcade/Arcade-NamcoSystem2_MiSTer @ 5fe71a59
MAME compared: namco/namcos2.cpp + 23 related file(s)
Read: 48 HDL files, 23,027 lines (Quartus project)

kuzecores
independent database

Mostly MAME

medium

63%

Statements: 122 toward MAME

Cites MAME source — 116

NamcoS2.sv:98 180 degrees in the core, on every video path (ns2_flipbuf); a ROT180 set (MAME's Bubble Trouble) starts turned, and this turns it back
NamcoS2.sv:326 MAME's power-on analog and dial values (M5 maps the controls onto them)
NamcoS2.sv:338 Byte 0 is MAME's DSW port (the MCU's $2000; bit 7 the test switch).
NamcoS2.sv:352 Keyboard: MAME's default bindings, always live, ORed with the pads.
NamcoS2.sv:393 Inputs: MAME's ports (namcos2.cpp NAMCOS2_MCU_PORT_*_DEFAULT), active low.
NamcoS2.sv:402 The sets with a wheel and pedals, light guns or Metal Hawk's stick map the analog sticks and the mouse onto AN0-AN7 (ns2_controls, the set's control mode in config byte 33); the others keep MAME's power-on values.
NamcoS2.sv:733 Audio: MAME's routes (namcos2.cpp), both stereo, the set's own gains (config bytes 36-37, x128; NS2-26): the C140 at 0.75 (base2 and Metal Hawk 1.0, base3 0.45), the YM2151 at 0.80 (base3 1.0).
NamcoS2.sv:735 Each chip first through its anti-imaging interpolator (ns2_fir4: 4x, MAME's resampler's response in the passband, NS2-26 and NS2-29): a held sample has images above the chip's Nyquist (the C140's 10.67 kHz, jt51's 27.97 kHz, which MiSTer's
rtl/cheats.sv:1 Cheat engine — applies Pugsy MAME-database pokes to work RAM once a frame.
rtl/cheats.sv:34 Poke semantics follow MAME's "run" state: the value is written every frame for as long as the cheat is enabled, which is what makes "infinite" cheats hold against the game decrementing the counter.
rtl/ns2_board.sv:9 Line events, at the start of the line (MAME's scanline timer): 200 the MCU's IRQ1, 240 both C148s' VBLANK, (reg5 - 32) & 0xff POSIRQ.
rtl/ns2_board.sv:23 inputs (MAME's ports)
rtl/ns2_c123.sv:1 C123 tilemaps (namco_c123tmap.cpp; tools/ns2_model.py tilemap_layer is the specification): renders one line of the six planes into the composition line buffer, in MAME's draw order (priority 0..7, then plane 0..5), each opaque pixel overwri
rtl/ns2_c123.sv:51 The planes in MAME's draw order (priority 0..7, then plane 0..5) are listed first; then a fetch engine fills slot bank k & 1 for the k-th listed plane while the pixel engine draws the plane before it from the other bank: a line costs about
rtl/ns2_c140.sv:1 C140 (MAME c140.cpp): 24 PCM voices, the register file, the key-on status and the INT1 timer that drives the 6809's FIRQ.
rtl/ns2_c140.sv:3 0x000-0x17f 24 voices x 16 registers: 0 volume right, 1 volume left, 2-3 frequency, 4 bank, 5 mode (key-on on bit 7, or bit 6 while keyed; bit 4 loop, bit 3 compressed), 6-7 start, 8-9 end, 10-11 loop (sample words within the bank) 0x1f8
rtl/ns2_c140.sv:14 The voices, as MAME's sound_stream_update, one sample per base-rate tick (21.333 kHz: clk / 2304; MAME_RATE = 1 uses MAME's stream edges instead, its integer 21333 Hz, for the sample-exact comparison): offset += frequency * 2; pos += offset
rtl/ns2_c140.sv:24 MAME computes the samples whose edge has passed before it applies a register write, so a write never reaches a sample being computed: the voice register writes wait in a queue while the voices run (the CPU's view, the register reads and the
rtl/ns2_c140.sv:29 Voice ROM words: c140_rom_r (namcos2_m.cpp), the schematics' wiring: word address bit 21 picks voice1/voice2 for bits 15-8, bit 20 low enables voice0's nibble for bits 7-4, bit 19 low picks its low nibble.
rtl/ns2_c140.sv:48 the output, one sample per tick; raw_*: MAME's mixer sums (debug)
rtl/ns2_c140.sv:77 the timer counts clocks from the write, as MAME's (an exact duration, not the base-rate ticks' edges): (reload + 1) * 2 * 2304 clocks
rtl/ns2_c140.sv:120 the voices' state (MAME's C140_VOICE)
rtl/ns2_c140.sv:150 MAME's compressed table: j = (s8)i; s1 = j & 7; s2 = abs(j >> 3) & 31; v = ((0x80 << s1) & 0xff00) + (s2 << (s1 ?
rtl/ns2_c140.sv:167 MAME's put_int_clamp(v, 4096): +-1.0 full scale, as 16 bits
rtl/ns2_c140.sv:273 the key-on decision is MAME's, at the write
rtl/ns2_c140.sv:337 MAME's per-sample step, voice ev
rtl/ns2_c148.sv:1 C148: a 68000's interrupt controller and board control (namco_c148.cpp).
rtl/ns2_c148.sv:13 MAME drives the 68000's input line of the source's level, not a per-source OR: a trigger sets the line of the source's current level, an ack (or a level write, which acks first) clears it, whatever else shares the level.
rtl/ns2_c148.sv:94 line and hold are updated in order (blocking): the events of one clock apply as MAME applies them, one after another the acknowledge of a held level
rtl/ns2_c169.sv:1 C169 ROZ (namco_c169roz.cpp; tools/ns2_model.py c169_params / c169_rows / draw_c169 are the specification): renders one line of both layers, layer 1 then layer 0, each into its own line buffer with its priority and colour per pixel (the per
rtl/ns2_c355.sv:1 C355 sprites (namco_c355spr.cpp; tools/ns2_c355hw.py is the specification, proven equal to MAME's frame algorithm, tools/ns2_model.py sprites_c355).
rtl/ns2_c45.sv:1 C45 road (namco_c45road.cpp draw; tools/ns2_model.py road_line is the specification): renders one line of the road into the ROZ line buffer (a board has one or the other), with the line's priority.
rtl/ns2_c65.sv:1 The C65 I/O MCU (MAME namco65.cpp): the HD63705 (rtl/ns2_hd63705.v, NS2-7) at 2.048 MHz (its crystal clock: a clock enable every 24 clocks) and its memory map: 0000-003f RAM, reads of 01 (MCUB), 02 (MCUC), 03 (port D: the analog inputs over
rtl/ns2_c65.sv:13 IRQ1 (line 200) and the A/D interrupt are latched until the core fetches their vectors (0x1ff8, 0x1fea), as MAME's pending interrupts.
rtl/ns2_c65.sv:14 MAME holds the IRQ1 input (HOLD_LINE) until the core enters any interrupt, and the core latches IRQ1 only when that input changes: a line-200 event while the input is still held is lost.
rtl/ns2_c65.sv:40 inputs (MAME's ports, active low where the board is)
rtl/ns2_c65.sv:78 MAME's IRQ1 input: held until an interrupt is taken
rtl/ns2_c68.sv:1 The C68 I/O MCU (MAME namco68.cpp): an M37450 (rtl/ns2_m740.sv, NS2-9) at 8.192 MHz, a cycle every 4 clocks: 2.048 MHz, a clock enable every 24 clocks.
rtl/ns2_c68.sv:3 Its on-chip peripherals as MAME's m3745x.cpp: 0000-00bf RAM 00d6-00dd ports P3-P6 and their direction 00e2-00e3 A/D 00fc-00ff interrupt requests and enables 0100-01ff RAM (the stack) and the board's map (c68_default_am
rtl/ns2_c68.sv:16 Interrupts: MAME's m3745x maps the enabled requests to m740 lines; any raises irq and the lowest line gives the vector (0xfffc - 2 * line): requests 1 bit 2 (INT1, line 200's VBL) -> line 2, 0xfff8 requests 1 bits 3, 4 -> lines 3, 4; reque
rtl/ns2_c68.sv:42 inputs (MAME's ports)
rtl/ns2_c68.sv:50 MAME's taps see this access
rtl/ns2_c68.sv:103 the ports' inputs (MAME's read_p callbacks)
rtl/ns2_c68.sv:188 MAME's reset clears the requests: nothing from before the release
rtl/ns2_controls.sv:1 The players' controls onto the I/O MCU's ports (namcos2.cpp's input ports): the digital ports MCUB, MCUC, MCUH and the eight analog channels AN0-AN7, per the set's control mode (config byte 33, tools/ns2_romdata.py): [1:0] 0 digital (MAME's
rtl/ns2_controls.sv:14 Ghost!, Bubble Trouble); otherwise MCUH 5 and 4, the bombs MCUH 3 and 2 the wheel and pedals: [4] Start on MCUB 7 / 6 (Four Trax, Suzuka) [5] the gears on MCUB: 5 down (the d-pad's up, or B4), 7 up (the d-pad's down, or B3) (Dirt Fox) M
rtl/ns2_controls.sv:23 A gun's value is its position across the board's own picture, 0 at the left (top) to 255 at the right (bottom), as MAME's crosshair maps it; the players aim at the displayed picture, turned 180 degrees when `flip`.
rtl/ns2_controls.sv:26 Wheel: 0x01-0xff, 0x80 centred; accelerator 0-0x80, brake 0-0x40; Metal Hawk's stick and lever 0x20-0xe0 (MAME's PORT_MINMAX).
rtl/ns2_controls.sv:27 A stick sets a value outright; a button or the d-pad moves it a step a frame, as MAME's key delta, and it returns when released.
rtl/ns2_controls.sv:36 MAME's power-on AN0-AN7 (config bytes 21-28)
rtl/ns2_controls.sv:44 MAME's power-on MCUDI0-3 (config bytes 29-32)
rtl/ns2_controls.sv:101 ------------------------------------------------------------ the guns Each gun aims from the stick (or a MiSTer gun), the d-pad (8 a frame, MAME's key delta; it stays where it is left), or for player 1 the mouse: whichever moved last.
rtl/ns2_controls.sv:165 ------------------------------------------------------------ Assault Two 4-way sticks a player, a tank's two tracks (MAME's assault ports): the left on MCUB (up, down, left) and MCUH 7/6 (right), the right on MCUH (up, down) and MCUDI0 (rig
rtl/ns2_controls.sv:225 MAME's default ports (namcos2.cpp NAMCOS2_MCU_PORT_*_DEFAULT), active low
rtl/ns2_cpu.sv:1 One of the two 68000s with its own bus (namcos2.cpp master_common_am / slave_common_am): fx68k at 12.288 MHz (a PHI1 and a PHI2 enable every 4 clocks of the 49.152 MHz clk), its program ROM, 64 KB of work RAM (the slave's 0x100000-0x13ffff
rtl/ns2_cpu.sv:8 Interrupt acknowledges are answered with the autovector 24 + level (MAME's m68000 with the C148 on the IPL lines).
rtl/ns2_cpu.sv:264 ext_in: MAME leaves it unconnected (7)
rtl/ns2_fir4.sv:1 A sound chip's anti-imaging interpolator (NS2-26, NS2-29): its samples (one per in_stb) out at 4x through a 128-tap low-pass whose passband is MAME's own resampler's response (tools/ns2_firgen.py): a held sample puts images above the chip's
rtl/ns2_hd63705.v:1 Derived from jt6805 (jotego/jtcores modules/jt680x @ 3eb8fec, GPL-3.0-or-later, rtl/third_party/jt680x) for the C65's HD63705Z0 as MAME implements it (hd6305.cpp, docs/PLAN.md D2): 16-bit addresses; the stack in page 1 (0x100-0x17f, 7 bits)
rtl/ns2_hd63705_alu.v:1 Derived from jt6805 (jotego/jtcores modules/jt680x @ 3eb8fec, GPL-3.0-or-later, rtl/third_party/jt680x) for the C65's HD63705Z0 as MAME implements it (hd6305.cpp, docs/PLAN.md D2): 16-bit addresses; the stack in page 1 (0x100-0x17f, 7 bits)
rtl/ns2_hd63705_ctrl.v:1 Derived from jt6805 (jotego/jtcores modules/jt680x @ 3eb8fec, GPL-3.0-or-later, rtl/third_party/jt680x) for the C65's HD63705Z0 as MAME implements it (hd6305.cpp, docs/PLAN.md D2): 16-bit addresses; the stack in page 1 (0x100-0x17f, 7 bits)
rtl/ns2_hd63705_ctrl.v:66 MAME's order: IRQ1 before the A/D interrupt
rtl/ns2_hd63705_regs.v:1 Derived from jt6805 (jotego/jtcores modules/jt680x @ 3eb8fec, GPL-3.0-or-later, rtl/third_party/jt680x) for the C65's HD63705Z0 as MAME implements it (hd6305.cpp, docs/PLAN.md D2): 16-bit addresses; the stack in page 1 (0x100-0x17f, 7 bits)
rtl/ns2_key.sv:1 The key custom (namcos2_m.cpp namcos2_68k_key_r / _w): 8 word registers.
rtl/ns2_key.sv:2 Per set, some offsets return a constant (the protection check); every other read returns MAME's random value, which the oracle patch makes the LFSR r = (r >> 1) ^ (r & 1 ?
rtl/ns2_m740.sv:1 GENERATED by tools/ns2_740gen.py from MAME's devices/cpu/m6502 (dm740.lst, om740.lst, om6502.lst; BSD-3-Clause, Olivier Galibert): do not edit.
rtl/ns2_m740.sv:3 The Mitsubishi 740 core of the C68's M37450, cycle for cycle as MAME's m740 (NS2-9).
rtl/ns2_m740.sv:8 irq is MAME's m_irq_state (any enabled request), irq_vector its m_irq_vector; both are sampled at the opcode fetch, as MAME's prefetch_end.
rtl/ns2_m740.sv:10 On reset the registers take MAME's power-on values and the core runs reset_m (the vector at 0xfffe).
rtl/ns2_m740.sv:22 MAME's taps see this access (not read_pc, read_arg or a fetch)
rtl/ns2_m740.sv:33 MAME's registers (blocking: the statements between two bus cycles run in C's order within one clock; the bus outputs are registered from b_*)
rtl/ns2_m740.sv:72 ---------------------------------------------------------------- m6502.cpp
rtl/ns2_m740.sv:197 ---------------------------------------------------------------- m740.cpp: T mode on m_TMP
rtl/ns2_m740.sv:258 the prefetch's end: the opcode, then MAME's prefetch_end (the interrupt check)
rtl/ns2_m740.sv:2416 MAME's STATE_RESET: reset_m from its start
rtl/ns2_main.sv:1 The two 68000s and their shared bus (namcos2.cpp: namcos2_68k_default_cpu_board_am, common_default_am, common_finallap_am): the arbiter grants one access at a time (master first when both ask in the same clock); an access takes three clocks
rtl/ns2_main.sv:179 the arbiter: the grant with the address, then the devices' read latency, then the capture (three clocks, the master first): the 68000 gets DTACK in time for no wait state, as in MAME
rtl/ns2_main.sv:200 the boards' maps (namcos2.cpp): the CPU board's, then each graphics board's 0 standard: c00000 sprites, c40000 gfx_ctrl, c80000 ROZ RAM, cc0000 ROZ control, d00000 key 1 Final Lap: 300000 protection, 800000 sprites, 840000 gfx_ctrl, 880000
rtl/ns2_main.sv:318 (MAME's umask16 reads: the other lane 0)
rtl/ns2_main.sv:320 finallap_state::finallap_prot_r (namcos2_m.cpp): two tables on a counter that reads of words 3 and 1ffff advance
rtl/ns2_mem.sv:10 It applies the board wiring MAME applies after loading (tools/ns2_romdata.py WIRING): Metal Hawk's sprite reorder (a byte lands in 0, 1 or 2 places) and its transposed copy for the rot90 sprites, and Lucky & Wild's bit-reversed C169 mask.
rtl/ns2_mem.sv:18 WRAM_SD (the Suzuka and Lucky & Wild bitstreams): the 68000s' work RAMs and the C139's RAM are bank 1 clients that also write (ns2_wram_cache); the download first clears them, as MAME's RAM starts at 0 and the board's SDRAM keeps the last c
rtl/ns2_mem.sv:28 MAME loads one byte lane of some 16-bit regions and leaves the other at 0: the C140 voices' odd bytes always, the data ROM's second megabyte where these say (rthun2: the odd bytes; suzuka8h: the even).
rtl/ns2_mem.sv:106 Metal Hawk's reorder, per 4x4 block of a 32x32 tile: where a source byte (row r, column c in the block) goes; MAME's loop carries one byte into two places and drops another (tools/ns2_romdata.py _metlhawk_sprite)
rtl/ns2_roz.sv:1 ROZ (A) (namcos2_roz.cpp draw_roz; tools/ns2_model.py roz_layer is the specification): renders one line of the ROZ plane into its own line buffer.
rtl/ns2_roz.sv:3 The mixer resolves it against the tilemaps: MAME draws it after every plane of its priority or lower, so it wins over those and loses to higher ones.
rtl/ns2_roz.sv:9 Without wrap a pixel is inside when xpos <= size and ypos < size (MAME's comparisons).
rtl/ns2_sound.sv:1 The sound board (namcos2.cpp sound_default_am): the 6809 at 2.048 MHz (E and Q from clk: 24 clocks an E cycle), the YM2151 (jt51, 3.579545 MHz), the C140 (rtl/ns2_c140.sv), 8 KB of RAM and the DPRAM's third port.
rtl/ns2_sound.sv:4 0000-3fff banked ROM (16 KB banks; c000-c001 writes select data >> 4) 4000-4001 YM2151 5000-51ff, 6000-61ff C140 (mirrored) 7000-77ff DPRAM (mirrored) 8000-9fff RAM a000-bfff amplifier enable (writes ignored) c000-ffff ROM (the re
rtl/ns2_sound.sv:10 The YM2151's IRQ is not wired (MAME comments it out).
rtl/ns2_sprite_a.sv:1 Sprites (A) (namcos2_sprite.cpp draw_sprites; tools/ns2_model.py sprites_a is the specification): renders one line of the 128 sprites of the bank gfx_ctrl & 0xf into the sprite line buffer, in list order, a later sprite overwriting an earli
rtl/ns2_sprite_a.sv:7 MAME's zoom reduces to a screen size of sizex x sizey (sizex halved for 16x16), the source stepping by (gw << 16) / size per screen pixel, from the far edge when flipped: row = ((flipy ?
rtl/ns2_sprite_a.sv:41 (gw << 16) / n for n = 1..64, gw = 16 or 32: MAME's zoom step, from a table of (32 << 16) / n (a divider does not fit a clock); for gw 16 it is halved, floor(floor(x / n) / 2) being floor(x / 2n)
rtl/ns2_sprite_a.sv:74 the screen width: MAME's (scalex * gw + 0x8000) >> 16; Metal Hawk's scalex always divides by 0x20, so a 16-wide sprite is (sizex + 1) / 2
rtl/ns2_sprite_a.sv:122 w0 is in: the line test (sh >= 2 is MAME's sizey - 1 != 0); Metal Hawk's position also depends on word 6, so it tests later
rtl/ns2_video.sv:116 MAME's screen starts at the top of VBLANK (vpos 224)
rtl/ns2_video.sv:156 MAME's POSIRQ line: (C116 register 5 - 32) & 0xff (namcos2 get_pos_irq_scanline)
rtl/ns2_video.sv:239 the C116 sits on D7-D0 and takes any byte of the word (MAME's umask16(0x00ff).cswidth(16)): a byte write to the even address (UDS alone) writes too, with the byte the 68000 puts on both lanes
rtl/ns2_video.sv:263 registers 6 and 7 read 0xff (namcos2_base_state::c116_r, MAME's "fix for finallap boot")
rtl/ns2_video.sv:294 MAME's umask16 reads fill the other lane with 0
rtl/ns2_video.sv:524 At equal priority MAME draws planes, then ROZ or road, then C169 layer 1, then layer 0: the pixel shows the last drawn, the largest {priority, order}
rtl/ns2_ym_fifo.sv:2 jt51 applies an operator or key-on write over the next 32 of its cycles (64 with its half-rate phase), and a write before that cancels or redirects it; the games write every 26-28 cycles without reading the busy flag (Rolling Thunder 2: no
README.md:7 The joystick games use MAME's default ports (one joystick, three buttons, Start, Coin, Service).
README.md:18 **MAME as the reference.** MAME's `namco/namcos2.cpp` (K. Wilkins) and its devices, at a pinned commit (`deps.lock`), define the behaviour.
README.md:22 **Gates are measurements.** Each milestone ends in a measured gate, not a judgement: the video against MAME's state (M1), the whole board against MAME's bus tra
README.md:27 **Cycle-faithful CPUs.** Both 68000s, the 6809 and the I/O MCU (C65 or C68) run at MAME's clocks and bus timing.
README.md:30 **Every set in MAME's driver**, including Final Lap 1-3, Four Trax and the NB-1 boards (Steel Gunner, Suzuka 8 Hours, Lucky & Wild).
README.md:44 | Game | Year | MAME set | Bitstream | Controls | Alternates |
README.md:95 **Cheats** from Pugsy's MAME cheat database: ten fixed slots (Infinite Time, Infinite Credits, P1/P2 Invincibility, P1/P2 Infinite Lives, P1/P2 Infinite Energy,
README.md:118 The games on MAME's common ports have their own button names, and the buttons a game never reads are hidden: Cosmo Gang (Fire), Dragon Saber (Fire, Bomb), Marve
README.md:132 or the d-pad's up, as MAME's ports.
README.md:208 The C139 serial link between cabinets is not emulated (nor is it in MAME): each cabinet plays alone.
README.md:235 Derived from MAME (BSD-3-Clause), besides its use as the behavioural reference:
README.md:237 `rtl/ns2_m740.sv` (the C68's 740 core) is generated by `tools/ns2_740gen.py` from MAME's `dm740.lst`, `om740.lst` and `om6502.lst`, by Olivier Galibert; its hel
README.md:241 `rtl/ns2_c140.sv` ports MAME's `sound/c140.cpp`, by R. Belmont.
README.md:242 `tools/ns2_romdata.py` reads its ROM tables from MAME's `namcos2.cpp` (K. Wilkins and the MAME contributors).

Says it matches, follows or was checked against MAME — 1

README.md:122 Each was checked in MAME, a press in play against the same run without it.

Shares text with the MAME driver without saying so — 5

rtl/ns2_c123.sv:44 TilemapCB: bitswap<16>(code, 13,12,11,15,14,10..0); — shares text with namco/namcos2_v.cpp:12
rtl/ns2_c123.sv:45 TilemapCB_finalap2: bitswap<15>(code, 13,12,11,14,10..0) — shares text with namco/namcos2_v.cpp:18
rtl/ns2_c169.sv:65 bitswap<13>(c & 0x1fff, 11,10,9,12,8..0) — shares text with namco/namcos2_v.cpp:260
rtl/ns2_main.sv:1 The two 68000s and their shared bus (namcos2.cpp: namcos2_68k_default_cpu_board_am, — shares text with namco/namcos2.cpp:682
rtl/ns2_tile_filter.sv:47 TilemapCB undone: tile [15:11] = code {13, 12, 11, 15, 14} (standard), — shares text with namco/namcos2_v.cpp:12

Arcade-NamcoS2_SZ#
Suzuka 8 Hours 2, Suzuka 8 Hours
kuzearcade/Arcade-NamcoSystem2_MiSTer @ 5fe71a59
MAME compared: namco/namcos2.cpp + 23 related file(s)
Read: 48 HDL files, 23,027 lines (Quartus project)

kuzecores
independent database

Mostly MAME

medium

63%

Statements: 122 toward MAME

Cites MAME source — 116

NamcoS2.sv:98 180 degrees in the core, on every video path (ns2_flipbuf); a ROT180 set (MAME's Bubble Trouble) starts turned, and this turns it back
NamcoS2.sv:326 MAME's power-on analog and dial values (M5 maps the controls onto them)
NamcoS2.sv:338 Byte 0 is MAME's DSW port (the MCU's $2000; bit 7 the test switch).
NamcoS2.sv:352 Keyboard: MAME's default bindings, always live, ORed with the pads.
NamcoS2.sv:393 Inputs: MAME's ports (namcos2.cpp NAMCOS2_MCU_PORT_*_DEFAULT), active low.
NamcoS2.sv:402 The sets with a wheel and pedals, light guns or Metal Hawk's stick map the analog sticks and the mouse onto AN0-AN7 (ns2_controls, the set's control mode in config byte 33); the others keep MAME's power-on values.
NamcoS2.sv:733 Audio: MAME's routes (namcos2.cpp), both stereo, the set's own gains (config bytes 36-37, x128; NS2-26): the C140 at 0.75 (base2 and Metal Hawk 1.0, base3 0.45), the YM2151 at 0.80 (base3 1.0).
NamcoS2.sv:735 Each chip first through its anti-imaging interpolator (ns2_fir4: 4x, MAME's resampler's response in the passband, NS2-26 and NS2-29): a held sample has images above the chip's Nyquist (the C140's 10.67 kHz, jt51's 27.97 kHz, which MiSTer's
rtl/cheats.sv:1 Cheat engine — applies Pugsy MAME-database pokes to work RAM once a frame.
rtl/cheats.sv:34 Poke semantics follow MAME's "run" state: the value is written every frame for as long as the cheat is enabled, which is what makes "infinite" cheats hold against the game decrementing the counter.
rtl/ns2_board.sv:9 Line events, at the start of the line (MAME's scanline timer): 200 the MCU's IRQ1, 240 both C148s' VBLANK, (reg5 - 32) & 0xff POSIRQ.
rtl/ns2_board.sv:23 inputs (MAME's ports)
rtl/ns2_c123.sv:1 C123 tilemaps (namco_c123tmap.cpp; tools/ns2_model.py tilemap_layer is the specification): renders one line of the six planes into the composition line buffer, in MAME's draw order (priority 0..7, then plane 0..5), each opaque pixel overwri
rtl/ns2_c123.sv:51 The planes in MAME's draw order (priority 0..7, then plane 0..5) are listed first; then a fetch engine fills slot bank k & 1 for the k-th listed plane while the pixel engine draws the plane before it from the other bank: a line costs about
rtl/ns2_c140.sv:1 C140 (MAME c140.cpp): 24 PCM voices, the register file, the key-on status and the INT1 timer that drives the 6809's FIRQ.
rtl/ns2_c140.sv:3 0x000-0x17f 24 voices x 16 registers: 0 volume right, 1 volume left, 2-3 frequency, 4 bank, 5 mode (key-on on bit 7, or bit 6 while keyed; bit 4 loop, bit 3 compressed), 6-7 start, 8-9 end, 10-11 loop (sample words within the bank) 0x1f8
rtl/ns2_c140.sv:14 The voices, as MAME's sound_stream_update, one sample per base-rate tick (21.333 kHz: clk / 2304; MAME_RATE = 1 uses MAME's stream edges instead, its integer 21333 Hz, for the sample-exact comparison): offset += frequency * 2; pos += offset
rtl/ns2_c140.sv:24 MAME computes the samples whose edge has passed before it applies a register write, so a write never reaches a sample being computed: the voice register writes wait in a queue while the voices run (the CPU's view, the register reads and the
rtl/ns2_c140.sv:29 Voice ROM words: c140_rom_r (namcos2_m.cpp), the schematics' wiring: word address bit 21 picks voice1/voice2 for bits 15-8, bit 20 low enables voice0's nibble for bits 7-4, bit 19 low picks its low nibble.
rtl/ns2_c140.sv:48 the output, one sample per tick; raw_*: MAME's mixer sums (debug)
rtl/ns2_c140.sv:77 the timer counts clocks from the write, as MAME's (an exact duration, not the base-rate ticks' edges): (reload + 1) * 2 * 2304 clocks
rtl/ns2_c140.sv:120 the voices' state (MAME's C140_VOICE)
rtl/ns2_c140.sv:150 MAME's compressed table: j = (s8)i; s1 = j & 7; s2 = abs(j >> 3) & 31; v = ((0x80 << s1) & 0xff00) + (s2 << (s1 ?
rtl/ns2_c140.sv:167 MAME's put_int_clamp(v, 4096): +-1.0 full scale, as 16 bits
rtl/ns2_c140.sv:273 the key-on decision is MAME's, at the write
rtl/ns2_c140.sv:337 MAME's per-sample step, voice ev
rtl/ns2_c148.sv:1 C148: a 68000's interrupt controller and board control (namco_c148.cpp).
rtl/ns2_c148.sv:13 MAME drives the 68000's input line of the source's level, not a per-source OR: a trigger sets the line of the source's current level, an ack (or a level write, which acks first) clears it, whatever else shares the level.
rtl/ns2_c148.sv:94 line and hold are updated in order (blocking): the events of one clock apply as MAME applies them, one after another the acknowledge of a held level
rtl/ns2_c169.sv:1 C169 ROZ (namco_c169roz.cpp; tools/ns2_model.py c169_params / c169_rows / draw_c169 are the specification): renders one line of both layers, layer 1 then layer 0, each into its own line buffer with its priority and colour per pixel (the per
rtl/ns2_c355.sv:1 C355 sprites (namco_c355spr.cpp; tools/ns2_c355hw.py is the specification, proven equal to MAME's frame algorithm, tools/ns2_model.py sprites_c355).
rtl/ns2_c45.sv:1 C45 road (namco_c45road.cpp draw; tools/ns2_model.py road_line is the specification): renders one line of the road into the ROZ line buffer (a board has one or the other), with the line's priority.
rtl/ns2_c65.sv:1 The C65 I/O MCU (MAME namco65.cpp): the HD63705 (rtl/ns2_hd63705.v, NS2-7) at 2.048 MHz (its crystal clock: a clock enable every 24 clocks) and its memory map: 0000-003f RAM, reads of 01 (MCUB), 02 (MCUC), 03 (port D: the analog inputs over
rtl/ns2_c65.sv:13 IRQ1 (line 200) and the A/D interrupt are latched until the core fetches their vectors (0x1ff8, 0x1fea), as MAME's pending interrupts.
rtl/ns2_c65.sv:14 MAME holds the IRQ1 input (HOLD_LINE) until the core enters any interrupt, and the core latches IRQ1 only when that input changes: a line-200 event while the input is still held is lost.
rtl/ns2_c65.sv:40 inputs (MAME's ports, active low where the board is)
rtl/ns2_c65.sv:78 MAME's IRQ1 input: held until an interrupt is taken
rtl/ns2_c68.sv:1 The C68 I/O MCU (MAME namco68.cpp): an M37450 (rtl/ns2_m740.sv, NS2-9) at 8.192 MHz, a cycle every 4 clocks: 2.048 MHz, a clock enable every 24 clocks.
rtl/ns2_c68.sv:3 Its on-chip peripherals as MAME's m3745x.cpp: 0000-00bf RAM 00d6-00dd ports P3-P6 and their direction 00e2-00e3 A/D 00fc-00ff interrupt requests and enables 0100-01ff RAM (the stack) and the board's map (c68_default_am
rtl/ns2_c68.sv:16 Interrupts: MAME's m3745x maps the enabled requests to m740 lines; any raises irq and the lowest line gives the vector (0xfffc - 2 * line): requests 1 bit 2 (INT1, line 200's VBL) -> line 2, 0xfff8 requests 1 bits 3, 4 -> lines 3, 4; reque
rtl/ns2_c68.sv:42 inputs (MAME's ports)
rtl/ns2_c68.sv:50 MAME's taps see this access
rtl/ns2_c68.sv:103 the ports' inputs (MAME's read_p callbacks)
rtl/ns2_c68.sv:188 MAME's reset clears the requests: nothing from before the release
rtl/ns2_controls.sv:1 The players' controls onto the I/O MCU's ports (namcos2.cpp's input ports): the digital ports MCUB, MCUC, MCUH and the eight analog channels AN0-AN7, per the set's control mode (config byte 33, tools/ns2_romdata.py): [1:0] 0 digital (MAME's
rtl/ns2_controls.sv:14 Ghost!, Bubble Trouble); otherwise MCUH 5 and 4, the bombs MCUH 3 and 2 the wheel and pedals: [4] Start on MCUB 7 / 6 (Four Trax, Suzuka) [5] the gears on MCUB: 5 down (the d-pad's up, or B4), 7 up (the d-pad's down, or B3) (Dirt Fox) M
rtl/ns2_controls.sv:23 A gun's value is its position across the board's own picture, 0 at the left (top) to 255 at the right (bottom), as MAME's crosshair maps it; the players aim at the displayed picture, turned 180 degrees when `flip`.
rtl/ns2_controls.sv:26 Wheel: 0x01-0xff, 0x80 centred; accelerator 0-0x80, brake 0-0x40; Metal Hawk's stick and lever 0x20-0xe0 (MAME's PORT_MINMAX).
rtl/ns2_controls.sv:27 A stick sets a value outright; a button or the d-pad moves it a step a frame, as MAME's key delta, and it returns when released.
rtl/ns2_controls.sv:36 MAME's power-on AN0-AN7 (config bytes 21-28)
rtl/ns2_controls.sv:44 MAME's power-on MCUDI0-3 (config bytes 29-32)
rtl/ns2_controls.sv:101 ------------------------------------------------------------ the guns Each gun aims from the stick (or a MiSTer gun), the d-pad (8 a frame, MAME's key delta; it stays where it is left), or for player 1 the mouse: whichever moved last.
rtl/ns2_controls.sv:165 ------------------------------------------------------------ Assault Two 4-way sticks a player, a tank's two tracks (MAME's assault ports): the left on MCUB (up, down, left) and MCUH 7/6 (right), the right on MCUH (up, down) and MCUDI0 (rig
rtl/ns2_controls.sv:225 MAME's default ports (namcos2.cpp NAMCOS2_MCU_PORT_*_DEFAULT), active low
rtl/ns2_cpu.sv:1 One of the two 68000s with its own bus (namcos2.cpp master_common_am / slave_common_am): fx68k at 12.288 MHz (a PHI1 and a PHI2 enable every 4 clocks of the 49.152 MHz clk), its program ROM, 64 KB of work RAM (the slave's 0x100000-0x13ffff
rtl/ns2_cpu.sv:8 Interrupt acknowledges are answered with the autovector 24 + level (MAME's m68000 with the C148 on the IPL lines).
rtl/ns2_cpu.sv:264 ext_in: MAME leaves it unconnected (7)
rtl/ns2_fir4.sv:1 A sound chip's anti-imaging interpolator (NS2-26, NS2-29): its samples (one per in_stb) out at 4x through a 128-tap low-pass whose passband is MAME's own resampler's response (tools/ns2_firgen.py): a held sample puts images above the chip's
rtl/ns2_hd63705.v:1 Derived from jt6805 (jotego/jtcores modules/jt680x @ 3eb8fec, GPL-3.0-or-later, rtl/third_party/jt680x) for the C65's HD63705Z0 as MAME implements it (hd6305.cpp, docs/PLAN.md D2): 16-bit addresses; the stack in page 1 (0x100-0x17f, 7 bits)
rtl/ns2_hd63705_alu.v:1 Derived from jt6805 (jotego/jtcores modules/jt680x @ 3eb8fec, GPL-3.0-or-later, rtl/third_party/jt680x) for the C65's HD63705Z0 as MAME implements it (hd6305.cpp, docs/PLAN.md D2): 16-bit addresses; the stack in page 1 (0x100-0x17f, 7 bits)
rtl/ns2_hd63705_ctrl.v:1 Derived from jt6805 (jotego/jtcores modules/jt680x @ 3eb8fec, GPL-3.0-or-later, rtl/third_party/jt680x) for the C65's HD63705Z0 as MAME implements it (hd6305.cpp, docs/PLAN.md D2): 16-bit addresses; the stack in page 1 (0x100-0x17f, 7 bits)
rtl/ns2_hd63705_ctrl.v:66 MAME's order: IRQ1 before the A/D interrupt
rtl/ns2_hd63705_regs.v:1 Derived from jt6805 (jotego/jtcores modules/jt680x @ 3eb8fec, GPL-3.0-or-later, rtl/third_party/jt680x) for the C65's HD63705Z0 as MAME implements it (hd6305.cpp, docs/PLAN.md D2): 16-bit addresses; the stack in page 1 (0x100-0x17f, 7 bits)
rtl/ns2_key.sv:1 The key custom (namcos2_m.cpp namcos2_68k_key_r / _w): 8 word registers.
rtl/ns2_key.sv:2 Per set, some offsets return a constant (the protection check); every other read returns MAME's random value, which the oracle patch makes the LFSR r = (r >> 1) ^ (r & 1 ?
rtl/ns2_m740.sv:1 GENERATED by tools/ns2_740gen.py from MAME's devices/cpu/m6502 (dm740.lst, om740.lst, om6502.lst; BSD-3-Clause, Olivier Galibert): do not edit.
rtl/ns2_m740.sv:3 The Mitsubishi 740 core of the C68's M37450, cycle for cycle as MAME's m740 (NS2-9).
rtl/ns2_m740.sv:8 irq is MAME's m_irq_state (any enabled request), irq_vector its m_irq_vector; both are sampled at the opcode fetch, as MAME's prefetch_end.
rtl/ns2_m740.sv:10 On reset the registers take MAME's power-on values and the core runs reset_m (the vector at 0xfffe).
rtl/ns2_m740.sv:22 MAME's taps see this access (not read_pc, read_arg or a fetch)
rtl/ns2_m740.sv:33 MAME's registers (blocking: the statements between two bus cycles run in C's order within one clock; the bus outputs are registered from b_*)
rtl/ns2_m740.sv:72 ---------------------------------------------------------------- m6502.cpp
rtl/ns2_m740.sv:197 ---------------------------------------------------------------- m740.cpp: T mode on m_TMP
rtl/ns2_m740.sv:258 the prefetch's end: the opcode, then MAME's prefetch_end (the interrupt check)
rtl/ns2_m740.sv:2416 MAME's STATE_RESET: reset_m from its start
rtl/ns2_main.sv:1 The two 68000s and their shared bus (namcos2.cpp: namcos2_68k_default_cpu_board_am, common_default_am, common_finallap_am): the arbiter grants one access at a time (master first when both ask in the same clock); an access takes three clocks
rtl/ns2_main.sv:179 the arbiter: the grant with the address, then the devices' read latency, then the capture (three clocks, the master first): the 68000 gets DTACK in time for no wait state, as in MAME
rtl/ns2_main.sv:200 the boards' maps (namcos2.cpp): the CPU board's, then each graphics board's 0 standard: c00000 sprites, c40000 gfx_ctrl, c80000 ROZ RAM, cc0000 ROZ control, d00000 key 1 Final Lap: 300000 protection, 800000 sprites, 840000 gfx_ctrl, 880000
rtl/ns2_main.sv:318 (MAME's umask16 reads: the other lane 0)
rtl/ns2_main.sv:320 finallap_state::finallap_prot_r (namcos2_m.cpp): two tables on a counter that reads of words 3 and 1ffff advance
rtl/ns2_mem.sv:10 It applies the board wiring MAME applies after loading (tools/ns2_romdata.py WIRING): Metal Hawk's sprite reorder (a byte lands in 0, 1 or 2 places) and its transposed copy for the rot90 sprites, and Lucky & Wild's bit-reversed C169 mask.
rtl/ns2_mem.sv:18 WRAM_SD (the Suzuka and Lucky & Wild bitstreams): the 68000s' work RAMs and the C139's RAM are bank 1 clients that also write (ns2_wram_cache); the download first clears them, as MAME's RAM starts at 0 and the board's SDRAM keeps the last c
rtl/ns2_mem.sv:28 MAME loads one byte lane of some 16-bit regions and leaves the other at 0: the C140 voices' odd bytes always, the data ROM's second megabyte where these say (rthun2: the odd bytes; suzuka8h: the even).
rtl/ns2_mem.sv:106 Metal Hawk's reorder, per 4x4 block of a 32x32 tile: where a source byte (row r, column c in the block) goes; MAME's loop carries one byte into two places and drops another (tools/ns2_romdata.py _metlhawk_sprite)
rtl/ns2_roz.sv:1 ROZ (A) (namcos2_roz.cpp draw_roz; tools/ns2_model.py roz_layer is the specification): renders one line of the ROZ plane into its own line buffer.
rtl/ns2_roz.sv:3 The mixer resolves it against the tilemaps: MAME draws it after every plane of its priority or lower, so it wins over those and loses to higher ones.
rtl/ns2_roz.sv:9 Without wrap a pixel is inside when xpos <= size and ypos < size (MAME's comparisons).
rtl/ns2_sound.sv:1 The sound board (namcos2.cpp sound_default_am): the 6809 at 2.048 MHz (E and Q from clk: 24 clocks an E cycle), the YM2151 (jt51, 3.579545 MHz), the C140 (rtl/ns2_c140.sv), 8 KB of RAM and the DPRAM's third port.
rtl/ns2_sound.sv:4 0000-3fff banked ROM (16 KB banks; c000-c001 writes select data >> 4) 4000-4001 YM2151 5000-51ff, 6000-61ff C140 (mirrored) 7000-77ff DPRAM (mirrored) 8000-9fff RAM a000-bfff amplifier enable (writes ignored) c000-ffff ROM (the re
rtl/ns2_sound.sv:10 The YM2151's IRQ is not wired (MAME comments it out).
rtl/ns2_sprite_a.sv:1 Sprites (A) (namcos2_sprite.cpp draw_sprites; tools/ns2_model.py sprites_a is the specification): renders one line of the 128 sprites of the bank gfx_ctrl & 0xf into the sprite line buffer, in list order, a later sprite overwriting an earli
rtl/ns2_sprite_a.sv:7 MAME's zoom reduces to a screen size of sizex x sizey (sizex halved for 16x16), the source stepping by (gw << 16) / size per screen pixel, from the far edge when flipped: row = ((flipy ?
rtl/ns2_sprite_a.sv:41 (gw << 16) / n for n = 1..64, gw = 16 or 32: MAME's zoom step, from a table of (32 << 16) / n (a divider does not fit a clock); for gw 16 it is halved, floor(floor(x / n) / 2) being floor(x / 2n)
rtl/ns2_sprite_a.sv:74 the screen width: MAME's (scalex * gw + 0x8000) >> 16; Metal Hawk's scalex always divides by 0x20, so a 16-wide sprite is (sizex + 1) / 2
rtl/ns2_sprite_a.sv:122 w0 is in: the line test (sh >= 2 is MAME's sizey - 1 != 0); Metal Hawk's position also depends on word 6, so it tests later
rtl/ns2_video.sv:116 MAME's screen starts at the top of VBLANK (vpos 224)
rtl/ns2_video.sv:156 MAME's POSIRQ line: (C116 register 5 - 32) & 0xff (namcos2 get_pos_irq_scanline)
rtl/ns2_video.sv:239 the C116 sits on D7-D0 and takes any byte of the word (MAME's umask16(0x00ff).cswidth(16)): a byte write to the even address (UDS alone) writes too, with the byte the 68000 puts on both lanes
rtl/ns2_video.sv:263 registers 6 and 7 read 0xff (namcos2_base_state::c116_r, MAME's "fix for finallap boot")
rtl/ns2_video.sv:294 MAME's umask16 reads fill the other lane with 0
rtl/ns2_video.sv:524 At equal priority MAME draws planes, then ROZ or road, then C169 layer 1, then layer 0: the pixel shows the last drawn, the largest {priority, order}
rtl/ns2_ym_fifo.sv:2 jt51 applies an operator or key-on write over the next 32 of its cycles (64 with its half-rate phase), and a write before that cancels or redirects it; the games write every 26-28 cycles without reading the busy flag (Rolling Thunder 2: no
README.md:7 The joystick games use MAME's default ports (one joystick, three buttons, Start, Coin, Service).
README.md:18 **MAME as the reference.** MAME's `namco/namcos2.cpp` (K. Wilkins) and its devices, at a pinned commit (`deps.lock`), define the behaviour.
README.md:22 **Gates are measurements.** Each milestone ends in a measured gate, not a judgement: the video against MAME's state (M1), the whole board against MAME's bus tra
README.md:27 **Cycle-faithful CPUs.** Both 68000s, the 6809 and the I/O MCU (C65 or C68) run at MAME's clocks and bus timing.
README.md:30 **Every set in MAME's driver**, including Final Lap 1-3, Four Trax and the NB-1 boards (Steel Gunner, Suzuka 8 Hours, Lucky & Wild).
README.md:44 | Game | Year | MAME set | Bitstream | Controls | Alternates |
README.md:95 **Cheats** from Pugsy's MAME cheat database: ten fixed slots (Infinite Time, Infinite Credits, P1/P2 Invincibility, P1/P2 Infinite Lives, P1/P2 Infinite Energy,
README.md:118 The games on MAME's common ports have their own button names, and the buttons a game never reads are hidden: Cosmo Gang (Fire), Dragon Saber (Fire, Bomb), Marve
README.md:132 or the d-pad's up, as MAME's ports.
README.md:208 The C139 serial link between cabinets is not emulated (nor is it in MAME): each cabinet plays alone.
README.md:235 Derived from MAME (BSD-3-Clause), besides its use as the behavioural reference:
README.md:237 `rtl/ns2_m740.sv` (the C68's 740 core) is generated by `tools/ns2_740gen.py` from MAME's `dm740.lst`, `om740.lst` and `om6502.lst`, by Olivier Galibert; its hel
README.md:241 `rtl/ns2_c140.sv` ports MAME's `sound/c140.cpp`, by R. Belmont.
README.md:242 `tools/ns2_romdata.py` reads its ROM tables from MAME's `namcos2.cpp` (K. Wilkins and the MAME contributors).

Says it matches, follows or was checked against MAME — 1

README.md:122 Each was checked in MAME, a press in play against the same run without it.

Shares text with the MAME driver without saying so — 5

rtl/ns2_c123.sv:44 TilemapCB: bitswap<16>(code, 13,12,11,15,14,10..0); — shares text with namco/namcos2_v.cpp:12
rtl/ns2_c123.sv:45 TilemapCB_finalap2: bitswap<15>(code, 13,12,11,14,10..0) — shares text with namco/namcos2_v.cpp:18
rtl/ns2_c169.sv:65 bitswap<13>(c & 0x1fff, 11,10,9,12,8..0) — shares text with namco/namcos2_v.cpp:260
rtl/ns2_main.sv:1 The two 68000s and their shared bus (namcos2.cpp: namcos2_68k_default_cpu_board_am, — shares text with namco/namcos2.cpp:682
rtl/ns2_tile_filter.sv:47 TilemapCB undone: tile [15:11] = code {13, 12, 11, 15, 14} (standard), — shares text with namco/namcos2_v.cpp:12

Arcade-NMK16_Afega#
Bubble 2000, Fire Hawk / Huohu Chuanshuo, Sen Jing - Guardian Storm, Mang-Chi …
kuzearcade/Arcade-NMK16_MiSTer @ c6af34e9
MAME compared: nmk/nmk16.cpp + 10 related file(s)
Read: 33 HDL files, 15,128 lines (Quartus project)

kuzecores
independent database

Mostly MAME

high

74%

Statements: 10 toward hardware, 212 toward MAME, 2 not counted

Cites hardware documentation that MAME's driver does not — 5

NMK16_Afega.sv:5 Split out of NMK16_Gunnail.rbf on 2026-09-13: identical framework wiring, but gunnail_core is built with INCLUDE_AFEGA(1)/INCLUDE_NMK(0), so the NMK004/protection TLCS-90 cores, the YM2203 and the Seibu/YM3812 sound board are elaborated awa
rtl/gunnail/gunnail_core.sv:21 - The nine others: set_screen_lowres (384 x 278 at 6 MHz, visible 92..347 — the same 64 us line as the 512 x 8 MHz raster, so this core keeps its raster and draws a 256-px window at hcount 92..347), 32x32 TX tilemap, frame-constant scroll r
rtl/gunnail/gunnail_core.sv:2879 Unlike tharrier's own undumped/simulated MCU above, this bootleg's chip is fully dumped, so the game runs against the real thing: rtl/m68705/m68705_core.sv (jotego's jt6805 plus this project's peripheral wrapper), verified instruction-for-i
rtl/nmk_irq/nmk_irq.sv:29 Verified via a live MAME debugger capture (breakpoints at mustang's own IRQ1-4 ISR entry addresses, resolved from the ROM's own autovector table, printing the debugger's `beamy` pseudo-symbol) against mustang's real, dumped V-PROM (`10.bpr`
README.md:71 | `NMK16_Afega` | The Afega derivative boards: 12 MHz 68000 with address-scrambled program ROMs decoded per fetch, Z80 + YM2151 + OKI or twin-OKI sound, an 8bpp

Cites hardware references or measurements that MAME's driver also gives — 2

rtl/gunnail/gunnail_core.sv:3614 Their PROM (ssm-pr1.114 / 82s147.uh6, both CRC ed0bd072) is a 512-byte dump of a 256-byte device in which every other 32-byte block was never programmed: blocks with address bit 5 set are all 0x00, and the real table is the concatenation of — also in MAME: 82s147 nmk/nmk16.cpp:4318, 1.114 nmk/nmk16.cpp:7680
rtl/nmk_irq/nmk_irq.sv:57 NMK-29: half-populated 82S147 dump (ssmissin/airattck, A5 tied to GND). — also in MAME: 82S147 nmk/nmk16.cpp:4318

Says it was checked against the original PCB — 1

rtl/gunnail/gunnail_core.sv:573 mustangb3: XTAL(8 MHz) verified on PCB; acrobatmbl/hachamfb2 8_MHz_XTAL; tdragonb 10 MHz; ssmissin 8 MHz

Notes where it differs from MAME — 4

rtl/gunnail/gunnail_core.sv:3710 That is a MAME limitation rather than board behaviour, so the whole composed output is mirrored here exactly as for the other families -- a deliberate, documented divergence from MAME on Afega sprite pixels.
rtl/tlcs90/nmk004_periph.sv:41 - Watchdog (WDMOD/WDCR), serial (SCMOD/SCCR/SCBUF — not even mapped for this specific TLCS-90 variant in the reference), ADC (ADREG/ADMOD), stepping-motor mode (SMMOD's *functional* effect, though the register itself is stored and read back
rtl/tlcs90/tlcs90.sv:43 Still deferred: the TSET/LDA dead opcode space MAME's own reference model can't execute either — this is the CPU core's entire real opcode table, complete.
README.md:94 | `tdragonb2` | *"runs too quickly, Oki sounds terrible (IRQ problems?)"* | Not attempted — it would mean diverging from MAME's own known-broken timing. |

Cites MAME source — 165

NMK16_Afega.sv:13 (original NMK16_Gunnail.sv header follows) NMK16 MiSTerFPGA project — real hardware top-level for the "Gunnail" RBF: GunNail (gunnail, gunnailp — nmk16.cpp gunnail_prot()) and, since 2026-09-11, the nine lowres NMK004 boards (macross, blkhe
NMK16_Afega.sv:19 Cloned from NMK16_Raphero.sv: the same framework wiring (hps_io, SDRAM, MAME-style keyboard, P1/P2 autofire, framebuffer rotation, .mra DIP capture) plus NMK16_Macross2.sv's video output retimer (here at 48 MHz: 8 MHz pixels for gunnail's 5
NMK16_Afega.sv:77 A vertical (MAME ROT270) game drawn on its side by the board; the two "Vert" choices both present it upright through the framebuffer, as MAME does — "Vert 270" (the MAME-correct rotate_ccw direction) and "Vert 90" (the opposite quarter-turn
NMK16_Afega.sv:199 MAME ORIENTATION_FLIP_Y sets (grdnstrm, grdnstrmau, firehawk, spec2kh): the board draws upside down for a monitor mounted that way; the picture is read out bottom-up (rd_y mirrored) so it displays upright, as MAME does.
NMK16_Afega.sv:292 Keyboard: MAME's default key bindings, always active, ORed with the joysticks.
NMK16_Afega.sv:295 P1: Up/Down/Left/Right arrows, B1 LCtrl, B2 LAlt, B3 Space, Start 1 P2: R/F/D/G, B1 A, B2 S, B3 Q, Start 2 Coin 1 = 5, Coin 2 = 6, Service (IPT_SERVICE1) = 9 Test / Service Mode = F2: a TOGGLE, as in MAME, flipping DSW1 SW1:8 (PORT_SERVICE_
NMK16_Afega.sv:397 gunnail has no service-mode DIP (DSW1 bit 0 is Flip Screen); MAME's F2 maps to nothing here, so the DIP bytes pass straight through.
NMK16_Afega.sv:575 Cheats (rtl/cheats.sv) — Pugsy's MAME cheat database, seven fixed slots with this game's addresses supplied by the .mra as <rom index="5">.
NMK16_Afega.sv:805 ROT270 in MAME: the board's image is turned counter-clockwise to stand upright, which is screen_rotate's rotate_ccw=1 case ("Vert 270"); "Vert 90" is rotate_ccw=0, the opposite quarter-turn, for cabinets whose vertical monitor is mounted th
rtl/bjtwin/nmk_irq_hacky.sv:33 manybloc (nmk16.cpp manybloc_scanline + set_periodic_int, 2026-09-14): a different fixed table on a 240-line screen -- scanline 248 -> sprite DMA, then IRQ4 (both in the same callback, the memcpy first: vpos 248 is the line after the last
rtl/bjtwin/video_timing.sv:7 Reset-time raster phase: `vcount` resets to `VACTIVE_END` (240, the first scanline of vblank), not 0 — confirmed directly against real MAME's own screen device (Family D bring-up investigation, tdragon1): `screen.vpos()` at machine time 0 s
rtl/bjtwin/video_timing.sv:11 Measured two independent ways that agree: (1) a MAME Lua memory-read tap on the protection MCU's own P5 register (`screen.vpos()>>2`, the *exact* value real game code observes) showed vpos in [44,47] at real time 5.260ms after machine start
rtl/bjtwin/video_timing.sv:41 MAME's manybloc_scanline fires off screen vpos, and vpos 0/248 line up with vcount 0/248 exactly under this window.
rtl/cheats.sv:1 Cheat engine — applies Pugsy MAME-database pokes to work RAM once a frame.
rtl/cheats.sv:23 Poke semantics follow MAME's "run" state: the value is written every frame for as long as the cheat is enabled, which is what makes "infinite" cheats hold against the game decrementing the counter.
rtl/gunnail/gunnail_core.sv:14 What the boards are (nmk16.cpp, cross-checked per game): - gunnail: 68000 at 10 MHz, gunnail_map: I/O at 0x080000, palette 0x088000, gunnail_scrollram/scrollramy at 0x08C000/0x08C200 (write-only, 256 words each), BG VRAM 0x090000 (8192 word
rtl/gunnail/gunnail_core.sv:51 - NMK-215 protection MCU (TMP90840, nmk_prot_core.sv, 8 KB ROM nmk-215.bin, byte-identical between gunnail and macross) at 4 MHz: it only loads the two NMK214 descrambler configs at boot through its port 3/port 7 (a MAME Lua trace over 30 s
rtl/gunnail/gunnail_core.sv:112 Same-scene MAME comparison (2026-09-14, HW_ROMS=0 sim only, inert unless the files are given).
rtl/gunnail/gunnail_core.sv:113 The attract demo drifts from MAME within a minute (NMK-7), so a late scene cannot be compared by frame index.
rtl/gunnail/gunnail_core.sv:115 These load a MAME video-state dump straight into this core's own VRAM/palette arrays and hold the 68000 in reset, so the picture is rendered by the FULL core -- every per-game mux exactly as it ships -- rather than by a standalone video_mac
rtl/gunnail/gunnail_core.sv:132 HW_ROMS=0 only: 1 = the DIP switches come from dsw1_i/dsw2_i (the testbench drives the .mra defaults, so the MAME comparison covers language/demo-sound dependent screens); 0 = 0xFFFF as before.
rtl/gunnail/gunnail_core.sv:266 per-source audio taps (sim level checks against MAME's routes)
rtl/gunnail/gunnail_core.sv:301 pixel readback (mirrors MAME's screen:pixel(x,y))
rtl/gunnail/gunnail_core.sv:394 Every per-game difference is a function of game_sel; the values are transcribed from nmk16.cpp's machine configs, memory maps, GFXDECODE tables and ROM_START blocks (see the header).
rtl/gunnail/gunnail_core.sv:427 2026-09-13: the Afega boards (Family H, afega_state in nmk16.cpp): 12 MHz 68000 on afega_map (16-bit DSW at +4, four scroll words at 0x084000/0x08C000, 768-entry palette, main RAM mirrored at 0x0C0000 and 0x0F0000), fixed-scanline IRQs, a Z
rtl/gunnail/gunnail_core.sv:516 decode_ssmissin() is decode_tdragonb's GFX half and nothing else -- nmk16.cpp calls it "Like Thunder Dragon Bootleg without the Program Rom Swapping", and its table is byte-identical to decode_data_tdragonbgfx: {7,6,5,3,4,2,1,0}, i.e. bits
rtl/gunnail/gunnail_core.sv:589 Memory maps (nmk16.cpp): the decode function below keys on these.
rtl/gunnail/gunnail_core.sv:1255 Afega's decryptcode(): the program ROM is stored with address bits 17..13 permuted — MAME un-permutes the image once at init, this core permutes the 68000's address on every fetch instead (the .mra streams the raw files).
rtl/gunnail/gunnail_core.sv:1258 Table t: the SOURCE bit for each of dest bits 17..13, i.e. RAM[i] = file[src] with src[17:13] = {i[a17], i[a16], i[a15], i[a14], i[a13]} (bitswap<24>'s argument order, nmk16.cpp).
rtl/gunnail/gunnail_core.sv:1280 tdragonb (decode_tdragonb, nmk16.cpp): every program word is bitswapped — decode_word's table {e,c,a,8,7,5,3,1,f,d,b,9,6,4,2,0} gives dest bit (15-i) = src bit table[i].
rtl/gunnail/gunnail_core.sv:1322 16 pairs + next-pair prefetch instead of rom_cache1's single pair: see rtl/rom_cache_n.sv (68000 slowdown vs MAME).
rtl/gunnail/gunnail_core.sv:1618 MAME video-state injection (see the STATE_* parameters).
rtl/gunnail/gunnail_core.sv:1763 ssmissin itself never uses the mirror, but airattck/airattcka (the same map and game id) write through it EXCLUSIVELY -- 4096 of 4096 writes measured in MAME -- so without this their TX layer is entirely lost.
rtl/gunnail/gunnail_core.sv:1890 MAME keeps the whole 4 KB as plain .ram() and re-derives the BG scroll from two fixed words of it on EVERY write to the region (manybloc_scroll_w): 0x82/2 = word 0x41 is scrollx, 0xc2/2 = word 0x61 is scrolly.
rtl/gunnail/gunnail_core.sv:1953 Frame-constant scroll registers (every game but gunnail), in the board's own format (nmk16_v.cpp): scroll_w<Layer> (macross_map/acrobatm/tdragon/hachamf/strahl on the LOW byte of words 0x...0/2/4/6; bioship on the HIGH byte — umask16(0xff00
rtl/gunnail/gunnail_core.sv:2031 The screen_update variants read them differently (nmk16_v.cpp video_update / redhawki_video_update / screen_update_firehawk): see afega_vid.
rtl/gunnail/gunnail_core.sv:2179 bioship ROM-tilemap DMA (2026-09-11): MAME's bioship_get_bg_tile_info reads the tile index from the "tilerom" region at (bank << 13) | tile_index on every tile fetch.
rtl/gunnail/gunnail_core.sv:2666 x 3/2 (was 3/8 -- measured 8-13dB quiet vs MAME's real OKI:FM balance)
rtl/gunnail/gunnail_core.sv:2669 jt51's left/right averaged; the OKI's 14-bit `sound` x 2.75 (~0.7 of the 16-bit scale MAME's stream has).
rtl/gunnail/gunnail_core.sv:2679 x3: the Seibu boards' OKI (route 0.40) measured ~6 dB low at x3/2 on the board (mustangb/acrobatmbl vs MAME)
rtl/gunnail/gunnail_core.sv:2691 no FM chip on this board at all: the single OKI alone, at its own 1.0 MAME route
rtl/gunnail/gunnail_core.sv:2722 The firmware is now read back from SDRAM after reset — 8/16 KB over the port-3 arbiter, ~2.5 ms at most — with the 68000 and the MCU held in reset until it is in; the NMK004 boots meanwhile and just waits for its first command, as it does i
rtl/gunnail/gunnail_core.sv:2845 tharrier_map reads IN0 active HIGH, IN1 through the (undumped) MCU — word reads return ~IN1 (start/coin bits, active high on the bus), byte reads of the upper byte return a 15-entry sequence (tharrier_mcu_r), except at two program counters
rtl/gunnail/gunnail_core.sv:2859 NMK-23b: this concatenation was 17 bits wide assigned to a 16-bit wire (verilator WIDTHTRUNC), so the MSB was dropped and every field above it sat one bit too high -- IPT_START2 "in game" landed on bit 9 instead of MAME's 0x0100 (bit 8), so
rtl/gunnail/gunnail_core.sv:2870 Check code at 0x005640") that MAME leaves idle-high, so the port is the constant 0x8000.
rtl/gunnail/gunnail_core.sv:2966 Protection?"): MAME keys on m_maincpu->pc() == 0x416 / 0x64E — the address AFTER the reading instruction (move.w $80006,D0 at 0x410 / 0x648, six bytes each; the boot loops there until the word equals ROM $640 = 0x9000, then ROM $3E7C = 0x54
rtl/gunnail/gunnail_core.sv:2978 Family E (2026-09-14) protection reads and the acrobatmbl ROM patch: tdragonb_prot_r: 0x044022 reads 0x0003 ("no sprites without this"); tdragonb3: that read is unmapped (MAME's unmap value 0) and 0x060000-0x060021 read 0x00EE ("no sprites
rtl/gunnail/gunnail_core.sv:3020 Family E (2026-09-14): the Seibu Sound System board (seibu_sound_map: ROM 0000-1FFF, RAM 2000-27FF, the seibu_sound register block at 4000-401F (rtl/seibu/seibu_sound.sv: latches, IM0 vector arbitration RST10 = YM3812 / RST18 = the 68000's
rtl/gunnail/gunnail_core.sv:3153 The data lanes are captured through the 68000's write cycle (each lane as its strobe says, the other keeps its previous value: MAME's mem_mask) and handed over as a one-clock strobe on the cycle's trailing edge — a level would re-assert RST
rtl/gunnail/gunnail_core.sv:3319 unmapped ports read 0 (MAME's unmap value): gunnailb's Air Buster driver spins at 0x528 until port 4 (its absent OKI, noprw) reads no busy channel
rtl/gunnail/gunnail_core.sv:3349 cactus (2026-09-12): sabotenb's scrambled ROM data on a board with no NMK-215 — MAME's init_nmk table decode is the NMK214 scheme with the configs the NMK-215 sends sabotenb; they are written here after reset instead (the same two-byte sequ
rtl/gunnail/gunnail_core.sv:3555 vandykeb_r: 0; tharrier: soundlatch2; comad boards have no NMK004 there -- twinactn_map noprw()s 0x08000E-F and ssmissin_map leaves it out entirely, both reading 0 in MAME
rtl/gunnail/gunnail_core.sv:3572 MAME's unmap value for a 68000 program space is 0, but this core has always returned 0xFFFF and no shipped game noticed -- they do not read unmapped addresses.
rtl/gunnail/gunnail_core.sv:3574 airattcka does: it reads 0x0C000C (unmapped in ssmissin_map, MAME returns 0x0000) during boot, and on 0xFFFF it computes a bad jump target and spins in unmapped space at PC 0x5F0C56 forever -- a black screen from frame ~50 on.
rtl/gunnail/gunnail_core.sv:3668 The games read their Flip Screen DIP and write bit 0 of the flipscreen register (nmk16_v.cpp flipscreen_w -> flip_screen_set + m_spritegen->set_flip_screen); the register was being latched here and then ignored, so the DIP did nothing on an
rtl/gunnail/gunnail_core.sv:3672 MAME flips the tilemaps and mirrors the sprite coordinates internally, but for a full-screen window the net result is exactly a 180-degree rotation of the visible area -- measured, not assumed: tdragon2 frame 600 with the DIP on is bit-iden
rtl/gunnail/gunnail_core.sv:3677 So the readback coordinates are mirrored here, which reproduces MAME by construction and leaves the tilemap/sprite/prefetch pipeline alone.
rtl/gunnail/gunnail_core.sv:3707 MAME flips only the tilemaps on these boards and leaves the sprites unmirrored ("flip-screen doesn't work on sprites for all sets" on the grdnstrm GAME line, ~5-9k sprite pixels out of place in a frame diff).
rtl/macross2/video_macross2.sv:2 Confirmed directly from the reference: `VIDEO_START_MEMBER(nmk16_state,macross2)` (nmk16_v.cpp:150-162) creates a `common_get_bg_tile_info<0,1>`-driven, `tilemap_scan_pages`-mapped, 256x32-tile (16x16 px) BG tilemap — the SAME BG geometry `
rtl/macross2/video_macross2.sv:16 **No NMK214 descrambling** — macross2 has no protection MCU at all (`init_banked_audiocpu` only, nmk16.cpp:10736); bgtile/sprites ROM data is read directly, unlike video_macross.sv's own two live nmk214 instances.
rtl/macross2/video_macross2.sv:20 **5-bit sprite colour, not 4** — `macross2()`'s own machine config uses `get_colour_5bit` (nmk16.cpp:5457, `colour &= 0x1f`), not `get_colour_4bit` every single prior port in this project has used.
rtl/macross2/video_macross2.sv:23 `gfx_macross2`'s own GFXDECODE_START (nmk16.cpp:4194-4198) confirms the palette layout this requires: sprites at colour base `0x100` with **32** colours (`0x100-0x2FF`, matching the 5-bit index exactly), NOT `0x200` like macross's/gunnail's
rtl/macross2/video_macross2.sv:34 Per-scanline raster scroll: macross2/tdragon2 (RASTER_SCROLL=0) have a single `scroll_w<0>` register (nmk16.cpp:1094) — `bg_xscroll`/ `bg_yscroll` below are frame-constant register inputs.
rtl/macross2/video_macross2.sv:36 raphero (RASTER_SCROLL=1, VIDEO_START gunnail) instead has the two 256-word tables gunnail_scrollram/scrollramy, applied per bitmap line by nmk16_v.cpp bg_update(): for bitmap line y (16..239, i == y1 there), yscroll = scrollramy[0] + scrol
rtl/macross2/video_macross2.sv:76 Sizes the sim array and the tile-code wrap (MAME draws code % elements, elements = bytes/128); the powerins mode's 16-bit code never wraps.
rtl/macross2/video_macross2.sv:86 NMK214=1: BG bytes and sprite words pass through the two NMK214 descramblers (nmk16.cpp base_nmk214_215), configured by the protection MCU through nmk214_cfg_we/data.
rtl/macross2/video_macross2.sv:148 HW_ROMS=1: 1 = the sprite region streams in ROM_LOAD16_WORD_SWAP (or odd-chip-first byte-pair) order, so the byte cache inverts address bit 0 (see the sprite cache comment); 0 = a plain ROM_LOAD byte ROM in MAME's own order (bioship, strahl
rtl/macross2/video_macross2.sv:192 1 = every tile byte's nibbles are swapped (MAME's *_packed_lsb layouts: gfx_powerinsc).
rtl/macross2/video_macross2.sv:196 Afega boards (2026-09-13, Family H on the Gunnail rbf): bg_8bpp: the BG is MAME's tilelayout_8bpp — the ROM region's two halves each hold a col_2x2_group 4bpp tile; MAME's decoder puts plane 0 in the pixel's MSB, so the FIRST half is the hi
rtl/macross2/video_macross2.sv:207 bg_code_mod12k: the 8bpp region holds 12288 tiles per half (a 3 MB region: bubl2000) — MAME's gfx element indexing wraps the code modulo the element count, which a power-of-two mask cannot do.
rtl/macross2/video_macross2.sv:214 Family E bootlegs (2026-09-14, Gunnail rbf): static byte bitswaps MAME applies to the raw GFX ROMs once at init, applied here to every fetched tile byte before the nibble extraction instead (the .mra streams the raw files): gfx_swap34 = dec
rtl/macross2/video_macross2.sv:261 The real board's sprite DMA holds the 68000 off the bus for the ~200us the copy takes; MAME copies the whole table in an instant.
rtl/macross2/video_macross2.sv:276 bgvideoram_w<Layer>/scroll_w<Layer> (nmk16.cpp:465-503): macross2's own bgvideoram is FOUR "banks" of the same 8192-tile-position tilemap (0x10000 bytes vs. every other port's own 0x4000 — see module header), selected by bits[5:4] of the sc
rtl/macross2/video_macross2.sv:318 pixel readback for the testbench (mirrors MAME's screen:pixel(x,y))
rtl/macross2/video_macross2.sv:331 set_scrolldx(28+64,28+64) and the sprite generator's videoshift(28+64) — both in MAME BITMAP coordinates, see BITMAP_X0 below
rtl/macross2/video_macross2.sv:332 MAME positions tilemaps and sprites in BITMAP coordinates: the bitmap spans the whole raster (512x278) and the visible area starts at bitmap (28,16) — the hblank/vblank widths.
rtl/macross2/video_macross2.sv:334 scrolldx(92) therefore means tilemap x = bitmap_x - 92 + scrollx = screen_x + 28 - 92 + scrollx (hence MAME's own "leftmost 64 pixels have to be retrieved from the other side" comment), tilemap y = screen_y + 16 + scrolly, and a sprite at X
rtl/macross2/video_macross2.sv:350 MAME set_screen_midres (nmk16.cpp): raw 448 x 278 at 7 MHz, visible x 60..379 (320 px) — bitmap origin (60,16), the same 64 us line as the 512 x 8 MHz raster this module's callers run (448/7 MHz = 512/8 MHz), so the raster is unchanged and
rtl/macross2/video_macross2.sv:355 Sprite generator: set_mask(0x3ff, 0x3ff) — 10-bit coordinates, wrap modulus 1024 (nmk16spr.cpp: `if (sx > max_x) sx -= xpos_max`), against 0x1ff/512 for the hi-res boards; max_sprite_clock 448*263.
rtl/macross2/video_macross2.sv:514 Layer B's prefetch stream shares port B with the sprite fetch, real-time stream first: the sprite pass is a background compositing pass that simply runs slower while a two-layer game is drawing (its MAME budget is 25 % smaller on the lowres
rtl/macross2/video_macross2.sv:591 Sprite ROM byte order on the hardware path: the ROMs are ROM_LOAD16_WORD_SWAP, and MAME's graphics decoder reads the region BYTE-wise from the swapped memory image, where byte b is raw file byte b^1 (the sim's $readmemh array is built that
rtl/macross2/video_macross2.sv:681 Palette decode: RRRRGGGGBBBBRGBx (emupal.cpp RRRRGGGGBBBBRGBx_decoder)
rtl/macross2/video_macross2.sv:761 cfg_rt: the full 14-bit (bank[1:0], code[11:0]) masked to the ROM's tile count (MAME: code % elements, a power of two for every board but the sprites' — see spr_units); the parameter form is the same for the two masks it can express.
rtl/macross2/video_macross2.sv:782 one 256-colour bank: tilelayout_8bpp's planes 0-3 (the FIRST half, layer A) are MAME's pixel bits 7-4, planes 4-7 (the second half, layer B) bits 3-0
rtl/macross2/video_macross2.sv:826 Found by comparing real-hardware captures against MAME snapshots, see docs/hw-bringup.md.
rtl/macross2/video_macross2.sv:897 MAME copies the table atomically at the trigger (`sprite_dma()` from the scanline timer), as real hardware does.
rtl/macross2/video_macross2.sv:1103 powerins mode only (get_flip_extcode_powerins, attr bit 12): the unit's SOURCE columns are mirrored (nmk16spr.cpp draws each tile with flipx through gfx->transpen) and the units are placed right to left (sx += delta*w, xinc negated) while t
rtl/macross2/video_macross2.sv:1119 Tile code wraps modulo the ROM's element count (MAME: gfx_element does code %= total_elements).
rtl/macross2/video_macross2.sv:1123 hachamf draws its big character sprite (the one over GAME OVER, and on the name-entry screen) with code 0x81D6 = 33238 against spr_units = 8192: MAME gives tile 33238 % 8192 = 470, the old chain gave 33238 - 2*8192 = 16854, which is not jus
rtl/macross2/video_macross2.sv:1176 NMK214 descramble (NMK214=1) — per-fetch, exactly what MAME's decode_nmk214() precomputes: BG byte at byte address A becomes decode_byte(A, rom[A]); the big-endian sprite word at word address W becomes decode_word(W, word).
rtl/macross2/video_macross2.sv:1181 Address bitswap tables: nmk16.cpp nmk214_bg_address_bitswap / nmk214_sprites_address_bitswap.
rtl/macross2/video_macross2.sv:1444 Tiles that lie wholly outside the screen are skipped on their first pixel (MAME clips them too); the game keeps plenty of off-screen objects in its table, and walking their 256 pixels each (and fetching their ROM data) was a large part of w
rtl/macross2/video_macross2.sv:1522 Reference (nmk16_v.cpp screen_update_macross draws m_spriteram_old2, sprite_dma() shifts old2 <- old <- mainram at line 242, the frame is rendered at VBOUT 240 before that DMA): frame j shows the table from DMA j-2.
rtl/macross2/video_macross2.sv:1525 Pure RTL measurement — no MAME frame-index alignment involved.
rtl/nmk112/nmk112.sv:6 Register interface: 8 write-only bank-select registers, addressed offset 0-7 (`okibank_w(offset,data)`, nmk112.cpp:86-98).
rtl/nmk112/nmk112.sv:12 Address remap: PURE address-range decode, no awareness of which of jt6295's own 4 internal ADPCM channels issued a given fetch — confirmed directly from nmk112.cpp's own `oki_map()`/`oki_bank` (nmk112.cpp: 105-130): each OKI's own logical 0
rtl/nmk112/nmk112.sv:23 Confirmed by reading jt6295's own internal channel round-robin (`rtl/third_party/jt6295/ hdl/jt6295_serial.v`'s own `ch` register) — it is NOT exposed on jt6295's own top-level port list, and (per the address-only nature of nmk112.cpp's own
rtl/nmk112/nmk112.sv:31 Paged mode ("sample address table" independent per-voice banking, nmk112.cpp:6-9's own header comment): `is_paged(chip) = BIT(m_page_mask,chip)`, and the device's own default constructor value is `m_page_mask(0xff)` — since none of this pro
rtl/nmk112/nmk112.sv:36 In paged mode, the FIRST 0x400 bytes of the chip's own ENTIRE logical address space (not per-window — confirmed: `map(0x00000,0x000ff)`..`map(0x00300,0x003ff)` are absolute, not offset by any bank window) are overlaid: sub-range N*0x100..N*
rtl/nmk112/nmk112.sv:79 The core drives `hold` = "a gated cen is passing this clock"; the write is captured and applied on the next clock, after the latch — a 25 ns shift, far inside MAME's own sub-sample write/fetch ordering.
rtl/nmk112/nmk112.sv:109 nmk112.cpp:93/96 mask every written page index with `data & m_bankmask[chip]` before storing it (m_bankmask is size-1 for a power-of-two page count, which every real OKI ROM in this hardware family is — 0x80000/0x100000/0x200000/0x400000 al
rtl/nmk214/nmk214.sv:9 The descramble itself is address-dependent: which bitswap gets applied to a given word/byte depends on 3 bits pulled out of the *address* (after first re-ordering the address through ADDR_BITSWAP, since the 13 NMK214 address pins are wired
rtl/nmk214/nmk214.sv:30 Width of the raw ROM address this instance's own ADDR_BITSWAP entries index into — NOT 13 bits: the reference's own per-game bitswap tables (nmk16.cpp's nmk214_sprites_address_bitswap/ nmk214_bg_address_bitswap) pick individual bits out of
rtl/nmk214/nmk214.sv:72 Hardwired tables — verbatim from nmk214.cpp's own anonymous namespace.
rtl/nmk_irq/nmk_irq.sv:10 MAME's own nmk_irq_device does NOT consume the H-timing PROM at all (commented out in nmk_irq.h/.cpp, and that file's own "TODO: Horizontal timing generator emulation?") — screen geometry instead comes from the fixed per-resolution-class pi
rtl/nmk_irq/nmk_irq.sv:18 Every game using this hardware calls set_interrupt_timing() in nmk16.cpp unconditionally with the SAME fixed configuration (prom_start_offset=0x75, vtiming_prom_usage=0x100) — only the V-PROM's own 256-byte contents vary per game — so those
rtl/nmk_irq/nmk_irq.sv:29 Verified via a live MAME debugger capture (breakpoints at mustang's own IRQ1-4 ISR entry addresses, resolved from the ROM's own autovector table, printing the debugger's `beamy` pseudo-symbol) against mustang's real, dumped V-PROM (`10.bpr`
rtl/rom_cache_n.sv:7 Why (docs/hw-bringup.md, "Slowdown"): the real board and MAME run the 68000 with zero wait states from EPROM.
rtl/rom_cache_n.sv:8 Through the 1-line rom_cache1 56% of ROM bus cycles missed (the instruction stream and the game's ROM data-table reads thrash a single pair) and each miss is a ~10 clk_sys SDRAM round trip, 1-2 wait states — 13-20% of every frame spent stal
rtl/savestate/savestate_ui.sv:4 Slot 2 is on F5 and NOT F2 because every top level here already uses F2 for the Service Mode toggle (MAME's binding), and both were acting on the same press -- found on the board in the sibling Sand Scorpion core, 2026-09-20, which shares t
rtl/seibu/seibu_sound.sv:7 Owns: the Z80-side register block at 0x4000-0x401B (seibu_sound_map, seibusound.cpp:333-350), the IM0 interrupt-vector arbitration between the YM3812 (RST10) and the 68000 (RST18) (update_irq_lines/im0_vector_cb, seibusound.cpp:137-204), an
rtl/seibu/seibu_sound.sv:20 - YM3812's own register/data ports and audio synthesis (jtopl2) — this module only arbitrates cs/we/addr_sel and passes data through, exactly matching ym_r/ym_w's own pure pass-through implementation (seibusound.cpp:230-238).
rtl/seibu/seibu_sound.sv:25 Main-CPU-side interface: mustangb (unlike the "full" Seibu games this device was originally written for) only ever exercises `main_mustb_w` — a single word write at 0x08001E/0x08001F on the 68000 side (main_mustb_w, seibusound.cpp:319-329)
rtl/seibu/seibu_sound.sv:29 Confirmed directly against `mustangb_map` (nmk16.cpp:682-698): there is no read of main_r/soundlatch/pending anywhere in that map, so this module does NOT implement `main_r`'s own offset switch (the 68000-side readback of sub2main0/1/main2s
rtl/seibu/seibu_sound.sv:43 RST18 takes priority when both are pending (im0_vector_cb, seibusound.cpp:184-204) — replicated exactly via the same VECTOR_INIT/RST10_*/RST18_* state machine the reference uses (update_irq_lines, seibusound.cpp:137-181), so a simultaneous
rtl/seibu/seibu_sound.sv:94 ROM bank select (bank_w — BIT(data,0), seibusound.cpp:242-243)
rtl/seibu/seibu_sound.sv:108 IRQ arbitration state — mirrors m_rst10_irq/m_rst10_service/ m_rst18_irq/m_rst18_service exactly (seibusound.cpp update_irq_lines, state names kept for direct traceability against the reference).
rtl/seibu/seibu_sound.sv:120 RST18 wins over RST10 when both pending (im0_vector_cb, seibusound.cpp:186-197).
rtl/seibu/seibu_sound.sv:148 main2sub / sub2main latches (soundlatch_r offset 0/1, main_data_w offset 0/1 — seibusound.cpp:257-270,295-329)
rtl/seibu/seibu_sound.sv:155 One-cycle-delayed edge detect for the IACK acknowledge state updates below — matches the reference's own synchronize()-deferred (but same-effective-cycle, since MAME's scheduler.synchronize with no delay runs "now") state transitions: RST10
rtl/seibu/seibu_sound.sv:182 RST10 (YM3812) assert/clear tracks the chip's own irq_n level directly (fm_irqhandler, seibusound.cpp:225-228).
rtl/seibu/seibu_sound.sv:186 RST18 assert: main_mustb_w always asserts, unconditionally (seibusound.cpp:328).
rtl/seibu/seibu_sound.sv:194 IACK: acknowledge the vector actually driven this cycle (RST10_ACKNOWLEDGE / RST18_ACKNOWLEDGE — note RST18's own acknowledge ALSO clears rst18_irq immediately, matching seibusound.cpp:171-174 exactly; RST10's ack only raises rst10_service,
rtl/seibu/seibu_sound.sv:227 Z80-side register reads (main_r-equivalent offsets folded in: soundlatch_r=0x4010/11, main_data_pending_r=0x4012, coin_r=0x4013 hardwired 0xFF per mustangb's own machine config (coin_io_callback().set_constant(0xff), nmk16.cpp:4668))
rtl/seibu/seibu_sound.sv:236 main_data_pending_r reads m_sub2main_pending, not m_main2sub_pending (seibusound.cpp:262-265)
rtl/seibu/seibu_sound.sv:245 YM3812 pass-through (ym_r/ym_w, seibusound.cpp:230-238)
rtl/tlcs90/nmk004_core.sv:90 debug: live register state + a direct peek at internal RAM[dbg_hl] — purely additive, for root-causing oracle divergences against MAME's own debugger register/memory readout (see docs/tier2-system.md, "RET Z at 0x0E5F").
rtl/tlcs90/nmk004_periph.sv:25 - Timers 0-3 (8-bit, or 16-bit paired per TMOD) and timer 4/5 (16-bit compare-match with independent TREG4/TREG5 match points) are REAL counters, matching t90_timer_callback/t90_timer4_callback exactly — this is the one part of the peripher
rtl/tlcs90/nmk004_periph.sv:64 This peripheral register map (`tmp90840_regs` in the reference's own `cpu/tlcs90/tlcs90.cpp`) is identical between the TMP90840 (NMK004's own role) and TMP91640 (the protection-MCU role) — confirmed directly, not assumed — so one module ser
rtl/tlcs90/nmk_prot_core.sv:1 NMK-110/113/215 TLCS-90 shared-RAM protection MCU board wrapper — Tier 2's own Family D (`tdragon_prot_state` in the reference, mame/src/mame/nmk/nmk16.cpp:4895-5123 and nmk16.h:281-308).
rtl/tlcs90/nmk_prot_core.sv:13 Confirmed directly from `mame/src/devices/cpu/tlcs90/ tlcs90.cpp`: `tmp91640_mem` (this role's own device, "TMP91640"/ "NMK-110"/"NMK-113") uses the *exact same* `tmp90840_regs` on-chip peripheral register map (0xffc0-0xffef) as `tmp90840_m
rtl/tlcs90/nmk_prot_core.sv:24 Memory map (see tdragon_prot_map/tdragon_prot() in nmk16.cpp): 0x0000-0x3fff internal boot ROM (16KB — the actual protection program; per-game, e.g. nmk-110-tdragon.bin) 0xfdc0-0xffbf internal RAM (512B) 0xffc0-0xffef on-chip peripherals
rtl/tlcs90/nmk_prot_core.sv:45 Port 5/6 protection-signalling (confirmed directly against `tdragon_prot_state::mcu_port5_r`/`mcu_port6_r`/`mcu_port6_w` in nmk16.cpp, not assumed from a generic port-latch model): - **Port 5 read** returns the current scanline position (`s
rtl/tlcs90/nmk_prot_core.sv:87 `config.set_maximum_quantum(attotime::from_hz(6000))` in the reference (a scheduler-quantum tightening MAME itself needs for this specific timing-sensitive interaction) has no RTL analog: this design's own single shared `clk_sys` domain alr
rtl/tlcs90/nmk_prot_core.sv:165 debug: live HL/A, for root-causing shared-RAM-content divergences against MAME's own debugger register readout (same technique nmk004_core.sv's own dbg_a/dbg_f/dbg_hl already use).
rtl/tlcs90/tlcs90.sv:188 debug: pulses dbg_valid for one cycle at the start of each new instruction with that instruction's own PC — the same point in time MAME's `trace` debugger command reports from, directly diffable against a captured disassembly oracle trace.
rtl/tlcs90/tlcs90.sv:196 debug: live register state, sampled alongside dbg_pc/dbg_valid — purely additive, for root-causing oracle divergences against MAME's own debugger register readout (A/HL/F match MAME's TLCS-90 debug state symbols of the same name).
rtl/tlcs90/tlcs90.sv:420 Same OP_MUL/OP_DIV the PFX_G8 register-operand form already uses (reference: tlcs90.cpp:367-370, "case 0x12: case 0x13: OP(MUL+b0-0x12,16) R16(1,HL) I8(2,READ8())") — missing here entirely, same silent-OP_NOP-fallthrough class as the ADD ix
rtl/tlcs90/tlcs90.sv:432 Confirmed directly against the reference (cpu/tlcs90/tlcs90.cpp:372-373, "case 0x14: case 0x15: case 0x16: OP16(ADD,6) R16(1,IX+b0-0x14) I16(2,READ16())") — this specific base (unprefixed) form was missing from this table entirely (the cycl
rtl/tlcs90/tlcs90.sv:485 LDW ($FF00+w),mn — reuses OP_LD (MAME's own execute() merges "case LDW:" and "case LD|OP_16:" into the identical Write1_16(Read2_16()) path, tlcs90.cpp:1497-1499, so no new opcode is needed).
rtl/tlcs90/tlcs90.sv:489 Missing here entirely (reference: tlcs90.cpp:419-420) — same silent-fallthrough class as above.
rtl/tlcs90/tlcs90.sv:591 Table extracted directly from mame/src/devices/cpu/tlcs90/tlcs90.cpp's own OP()/OPCC()/OP16()/OPCC16() macro table (CT*2 = real clock cycles; conditional entries use the branch-taken result via the same test_cc() the EXECUTE stage itself us
rtl/tlcs90/tlcs90.sv:597 DJNZ's own not-taken cost (0x18/0x19 below) is a deliberate exception to "look it up in this table": the reference's own `OP(DJNZ,10)` (tlcs90.cpp:379/381) only ever sets `m_cyc_t` — `m_cyc_f` (the not-taken cost `Cyc_f()` charges when the
rtl/tlcs90/tlcs90.sv:873 XCF ("extra carry", bit 3) on INC/INCX/DEC/DECX: the reference (tlcs90.cpp's INC/INCX/DEC/DECX cases) computes F from the SZHV table alone (which never touches XCF) and then, as a genuinely separate step, sets XCF if-and-only-if the 8-bit r
rtl/tlcs90/tlcs90.sv:878 This core's own szhv_inc8()/szhv_dec8() never included that bit, so every one of their 4 callers (OP_INC/OP_DEC's 8-bit forms, OP_INCX/OP_DECX) was silently clearing XCF to 0 unconditionally instead — found via a register-state trace diff a
rtl/tlcs90/tlcs90.sv:1890 Two bugs lived here in turn: (1) SET/ RES always wrote to eff2/dout regardless of mode2, discarding the register form's result entirely (found via a register-state trace diff against a MAME oracle, docs/hw-bringup.md's GunNail investigation
README.md:23 Sets MAME flags `MACHINE_NOT_WORKING` are out of scope until MAME can run them.
README.md:26 Verify against MAME as the golden reference before hardware bring-up: MAME Lua tracers dump bus cycles, frames and RAM state, and Verilator testbenches diff the
README.md:28 Hardware is then compared to MAME with HDMI screenshots and audio captures.
README.md:31 MAME is used as a behavioural reference only.
README.md:31 No MAME code is part of the built core.
README.md:66 | Core (`releases/*.rbf`) | Hardware | Games (MAME set names) |
README.md:68 | `NMK16_Macross2` | 68000 + Z80 sound, YM2203, 2x OKIM6295 with NMK112 banking; hi-res and Power Instinct's 320-px board as runtime modes, plus the bootleg boa
README.md:70 | `NMK16_Gunnail` | NMK004 sound MCU, YM2203, 2x OKIM6295; NMK-215/113/110 protection MCUs with dual NMK214; hi-res per-line scroll (GunNail), the nine lowres N
README.md:75 Audio is compared band by band against MAME captures.
README.md:85 The four that do not ship are all `MACHINE_NOT_WORKING` in MAME itself, for reasons MAME states on its own `GAME` lines, and are outside this project's goal unt
README.md:90 | Set | MAME's reason | Here |
README.md:93 | `macrossbl` | *"not looked at yet"* | Not attempted — MAME has not characterised this bootleg at all, so there is nothing to port against. |
README.md:120 Player inputs follow MAME's default key layout.
README.md:211 The simulations read ROM images built from the MAME zips with the scripts in `tools/`.
README.md:231 | `sim/oracle/`, `sim/compare/` | MAME Lua tracer and trace comparison |
README.md:272 jt6805 is a **microcoded** design, and the control store is not jotego's. `rtl/m68705/6805.uc` (4096 x 39 bits) and the `6805.vh` / `6805_param.vh` headers that
README.md:300 The behavioural reference is [MAME](https://github.com/mamedev/mame), in particular `src/mame/nmk/nmk16.cpp`, `nmk16_v.cpp`, `nmk16spr.cpp`, `nmk214.cpp`, `nmk0
README.md:309 The project structure and the simulate-against-MAME methodology follow [kaneko16-mister](https://github.com/alphanu1/kaneko16-mister) and the MiSTer-devel arcad
README.md:324 The MAME source tree and the arcade ROM images are not part of this repository and are not covered by this licence.

Says it matches, follows or was checked against MAME — 14

rtl/bjtwin/nmk_irq_hacky.sv:18 IRQ levels are held (matching MAME's HOLD_LINE semantics for M68K, which auto-clears when the CPU takes the interrupt) until the CPU performs an interrupt-acknowledge bus cycle at that level.
rtl/bjtwin/video_timing.sv:22 This was NOT assumed or guessed: every prior port's own polling loops tolerated the old vcount=0 reset silently (it only ever showed up as an already- documented, bounded residual cycle-cost mismatch in verification), and this project spent
rtl/bjtwin/video_timing.sv:64 see header — matches MAME's own reset-time raster phase
rtl/gunnail/gunnail_core.sv:2862 Widths now sum to exactly 16 and the layout matches tharrier's IN1 as MAME returns it (~IN1): bit0 START1, bit1 START2, bit5 COIN2, bit7 COIN1, bit8 START2.
rtl/gunnail/gunnail_core.sv:2879 Unlike tharrier's own undumped/simulated MCU above, this bootleg's chip is fully dumped, so the game runs against the real thing: rtl/m68705/m68705_core.sv (jotego's jt6805 plus this project's peripheral wrapper), verified instruction-for-i
rtl/gunnail/gunnail_core.sv:3578 Matched to MAME for this map only, to keep the blast radius off every other game on the rbf.
rtl/gunnail/gunnail_core.sv:3689 afega_state::video_update instead reads the DIP bus LIVE every frame, as two independent axes: flip_screen_x_set(BIT(~m_dsw_io[0]->read(), 8)); // horizontal flip_screen_y_set(BIT(~m_dsw_io[0]->read(), 9)); // vertical (active low, and
rtl/macross2/video_macross2.sv:340 Before this conversion the whole picture sat 28 pixels right and 16 lines down of MAME's (measured: shifting a sim frame by (-28,-16) matched MAME's snapshot on 96.5% of all pixels), pushing the rightmost 28 columns and bottom 16 rows off-s
rtl/macross2/video_macross2.sv:1361 Latching in the same cycle as the address change (as this once did) delivered every word one offset late — the visible flag from the previous slot's colour word, the size from the flag word, the code from the size word — which is why moving
rtl/nmk_irq/nmk_irq.sv:24 Phase calibration (empirically verified, not derived from documentation alone): MAME's own screen.vpos() — the `y` the reference's address formula uses directly — is NOT the same numbering as this project's own video_timing.sv `vcount` (bot
rtl/tlcs90/nmk004_periph.sv:3 Built and verified against MAME's cpu/tlcs90/tlcs90.cpp reference model — see docs/tier2-tlcs90.md's "Peripheral registers" section for the full register map and which registers are confirmed exercised by the NMK004 boot ROM.
rtl/tlcs90/tlcs90.sv:4 Built and verified against MAME's `cpu/tlcs90/tlcs90.cpp` reference model — see docs/tier2-tlcs90.md for the full ISA reference, memory map, and verification plan this was derived from (register model, addressing-mode encodings, exact per-o
rtl/tlcs90/tlcs90.sv:1095 LDW (mem),mn — reuses OP_LD same as the base-level 0x3f form above (MAME merges LDW into LD|OP_16's own execute case).
README.md:73 Each core is pixel-identical to MAME in simulation for the whole attract sequence that timing allows, and pixel-identical in hardware screenshots of static scen

Says it was translated, ported or taken from MAME — 4

rtl/nmk112/nmk112.sv:2 Ported directly from mame/src/devices/machine/nmk112.cpp (131 lines, read in full before implementing — every detail below is confirmed against that source, not assumed).
rtl/nmk214/nmk214.sv:1 NMK214 GFX descrambler — a stateless, table-driven dynamic bitswap of graphics-ROM data, ported directly from mame/src/mame/nmk/nmk214.cpp (device comment there has the hardware background: works in tandem with the NMK215/TMP90840 protectio
rtl/nmk_irq/nmk_irq.sv:5 Ported directly from mame/src/mame/nmk/nmk_irq.cpp's own scanline_callback() — see that file's extensive header comment for the hardware background (dual counters + H/V timing PROMs inside the NMK902 custom chip).
rtl/seibu/seibu_sound.sv:3 Ported directly from `seibu_sound_device` (mame/src/mame/shared/ seibusound.{h,cpp}), the Z80 sound-board peripheral used by mustangb/tdragonb/acrobatmbl/strahljbl (Tier 5, Family E — "Raiden sound" bootlegs of NMK16-family games that other

Keeps a MAME approximation — 3

rtl/bjtwin/nmk_irq_hacky.sv:1 nmk_irq "hacky" fixed-scanline interrupt generator — the variant `cactus` uses (undumped timing PROMs on this bootleg; MAME substitutes a fixed scanline table, nmk16.cpp set_hacky_interrupt_timing()/nmk16_hacky_scanline, nmk16.cpp:4482-4511
rtl/gunnail/gunnail_core.sv:21 - The nine others: set_screen_lowres (384 x 278 at 6 MHz, visible 92..347 — the same 64 us line as the 512 x 8 MHz raster, so this core keeps its raster and draws a 256-px window at hcount 92..347), 32x32 TX tilemap, frame-constant scroll r
rtl/gunnail/gunnail_core.sv:3585 Raster timing + interrupt generation: the V-PROM state machine (three PROM tables, vprom_sel) or MAME's fixed-scanline substitute for strahl (irq_hacky).

Shares text with the MAME driver without saying so — 26

NMK16_Afega.sv:403 acrobatmbl reads its DSW1 word with SW1 in the HIGH byte ("changed from move.w to move.b"), DSW2 as acrobatm — shares text with nmk/nmk16.cpp:2222
rtl/gunnail/gunnail_core.sv:517 nmk16.cpp calls it "Like Thunder Dragon Bootleg without the Program Rom — shares text with nmk/nmk16.cpp:6129
rtl/gunnail/gunnail_core.sv:896 afega_unknown_r: 0x0100 ("fixes the text in Service Mode") — shares text with nmk/nmk16.cpp:6313
rtl/gunnail/gunnail_core.sv:2019 word 0x9F00 ("the protection device probably copies this to the — shares text with nmk/nmk16_v.cpp:432
rtl/gunnail/gunnail_core.sv:2172 ("otherwise bioship doesn't hit the NMI enough"). — shares text with nmk/nmk16.cpp:237
rtl/gunnail/gunnail_core.sv:2870 an active-low IPT_UNKNOWN ("VBLANK ? Check code at 0x005640") that — shares text with nmk/nmk16.cpp:1441
rtl/gunnail/gunnail_core.sv:2981 0x060000-0x060021 read 0x00EE ("no sprites in attract mode without — shares text with nmk/nmk16.cpp:893
rtl/gunnail/gunnail_core.sv:3691 flip_screen_x_set(BIT(~m_dsw_io[0]->read(), 8)); // horizontal — shares text with nmk/nmk16_v.cpp:519
rtl/gunnail/gunnail_core.sv:3692 flip_screen_y_set(BIT(~m_dsw_io[0]->read(), 9)); // vertical — shares text with nmk/nmk16_v.cpp:520
rtl/macross2/video_macross2.sv:3 `VIDEO_START_MEMBER(nmk16_state,macross2)` (nmk16_v.cpp:150-162) creates — shares text with nmk/nmk16_v.cpp:150
rtl/macross2/video_macross2.sv:4 a `common_get_bg_tile_info<0,1>`-driven, `tilemap_scan_pages`-mapped, — shares text with nmk/nmk16_v.cpp:123
rtl/macross2/video_macross2.sv:331 set_scrolldx(28+64,28+64) and the sprite generator's videoshift(28+64) — both in MAME BITMAP coordinates, see BITMAP_X0 below — shares text with nmk/nmk16_v.cpp:160
rtl/macross2/video_macross2.sv:336 scrollx (hence MAME's own "leftmost 64 pixels have to be retrieved — shares text with nmk/nmk16_v.cpp:159
rtl/macross2/video_macross2.sv:648 BG tile-fetch address — gfx_8x8x4_col_2x2_group_packed_msb layout: — shares text with nmk/nmk16.cpp:4184
rtl/macross2/video_macross2.sv:737 tilemap_scan_pages: (row&0xf) | ((col&0xff)<<4) | ((row&0x10)<<8) — shares text with nmk/nmk16_v.cpp:36
rtl/macross2/video_macross2.sv:752 common_get_bg_tile_info<0,1>: (code&0xfff)|(m_bgbank<<12) — 14-bit — shares text with nmk/nmk16_v.cpp:123
rtl/macross2/video_macross2.sv:788 palette base and tile ROM; common_get_bg_tile_info<1, Gfx> — the — shares text with nmk/nmk16_v.cpp:107
rtl/macross2/video_macross2.sv:829 TILEMAP_SCAN_COLS 8,8,32,32 — 256 logical px, the whole screen), so — shares text with nmk/nmk16_v.cpp:108
rtl/macross2/video_macross2.sv:1182 nmk214_bg_address_bitswap / nmk214_sprites_address_bitswap. — shares text with nmk/nmk16.cpp:5700
rtl/tlcs90/nmk004_periph.sv:59 reference (`tdragon_prot_state::mcu_port5_r`/`mcu_port6_r` — shares text with nmk/nmk16.cpp:5040
rtl/tlcs90/nmk_prot_core.sv:34 `m_maincpu->space(AS_PROGRAM).read_byte(offset)`/`write_byte` — — shares text with nmk/nmk16.cpp:5100
rtl/tlcs90/nmk_prot_core.sv:46 `tdragon_prot_state::mcu_port5_r`/`mcu_port6_r`/`mcu_port6_w` in — shares text with nmk/nmk16.cpp:5040
rtl/tlcs90/nmk_prot_core.sv:61 "the actual mechanism is a little more complex, but these are — shares text with nmk/nmk16.cpp:5022
rtl/tlcs90/nmk_prot_core.sv:62 written at the start and end of the take/release bus function"): — shares text with nmk/nmk16.cpp:5022
rtl/tlcs90/nmk_prot_core.sv:87 `config.set_maximum_quantum(attotime::from_hz(6000))` in the — shares text with nmk/nmk16.cpp:5122
rtl/tlcs90/nmk_prot_core.sv:371 only qualifying ones, matching `m_init_clock_nmk214 = BIT(data,2)` — shares text with nmk/nmk16.cpp:5669

Arcade-NMK16_Gunnail#
Acrobat Mission, Air Attack, Space Battle Ship Gomorrah, Bombjack Twin …
kuzearcade/Arcade-NMK16_MiSTer @ c6af34e9
MAME compared: nmk/nmk16.cpp + 10 related file(s)
Read: 38 HDL files, 15,852 lines (Quartus project)

kuzecores
independent database

Mostly MAME

high

73%

Statements: 12 toward hardware, 219 toward MAME, 2 not counted

Cites hardware documentation that MAME's driver does not — 7

NMK16_Gunnail.sv:482 2026-09-13: the 27 Afega sets (ids 23-43) moved to their own NMK16_Afega.rbf, so this build leaves their YM2151 out of the netlist (INCLUDE_AFEGA(0)) and keeps everything else.
rtl/gunnail/gunnail_core.sv:21 - The nine others: set_screen_lowres (384 x 278 at 6 MHz, visible 92..347 — the same 64 us line as the 512 x 8 MHz raster, so this core keeps its raster and draws a 256-px window at hcount 92..347), 32x32 TX tilemap, frame-constant scroll r
rtl/gunnail/gunnail_core.sv:2879 Unlike tharrier's own undumped/simulated MCU above, this bootleg's chip is fully dumped, so the game runs against the real thing: rtl/m68705/m68705_core.sv (jotego's jt6805 plus this project's peripheral wrapper), verified instruction-for-i
rtl/m68705/m68705_core.sv:4 Used only by tharrierb (Task Force Harrier, Lettering bootleg): its "MCU" is a genuine, fully-dumped M68705R3 (mc68705r35.bin, the whole 0x1000-byte internal image — bootstrap ROM + option byte + interrupt vectors included), not an undumped
rtl/m68705/m68705_core.sv:21 Address map (M68705R3, 12-bit bus, m6805_hmos_device::internal_map + m68705_device + m68705r_device): 0x00/01/02/03 port A/B/C/D data, 0x04/05/06 DDR A/B/C (port D has none — it is a dedicated INPUT-only port on this chip, matching tharrier
rtl/nmk_irq/nmk_irq.sv:29 Verified via a live MAME debugger capture (breakpoints at mustang's own IRQ1-4 ISR entry addresses, resolved from the ROM's own autovector table, printing the debugger's `beamy` pseudo-symbol) against mustang's real, dumped V-PROM (`10.bpr`
README.md:71 | `NMK16_Afega` | The Afega derivative boards: 12 MHz 68000 with address-scrambled program ROMs decoded per fetch, Z80 + YM2151 + OKI or twin-OKI sound, an 8bpp

Cites hardware references or measurements that MAME's driver also gives — 2

rtl/gunnail/gunnail_core.sv:3614 Their PROM (ssm-pr1.114 / 82s147.uh6, both CRC ed0bd072) is a 512-byte dump of a 256-byte device in which every other 32-byte block was never programmed: blocks with address bit 5 set are all 0x00, and the real table is the concatenation of — also in MAME: 82s147 nmk/nmk16.cpp:4318, 1.114 nmk/nmk16.cpp:7680
rtl/nmk_irq/nmk_irq.sv:57 NMK-29: half-populated 82S147 dump (ssmissin/airattck, A5 tied to GND). — also in MAME: 82S147 nmk/nmk16.cpp:4318

Says it was checked against the original PCB — 1

rtl/gunnail/gunnail_core.sv:573 mustangb3: XTAL(8 MHz) verified on PCB; acrobatmbl/hachamfb2 8_MHz_XTAL; tdragonb 10 MHz; ssmissin 8 MHz

Notes where it differs from MAME — 4

rtl/gunnail/gunnail_core.sv:3710 That is a MAME limitation rather than board behaviour, so the whole composed output is mirrored here exactly as for the other families -- a deliberate, documented divergence from MAME on Afega sprite pixels.
rtl/tlcs90/nmk004_periph.sv:41 - Watchdog (WDMOD/WDCR), serial (SCMOD/SCCR/SCBUF — not even mapped for this specific TLCS-90 variant in the reference), ADC (ADREG/ADMOD), stepping-motor mode (SMMOD's *functional* effect, though the register itself is stored and read back
rtl/tlcs90/tlcs90.sv:43 Still deferred: the TSET/LDA dead opcode space MAME's own reference model can't execute either — this is the CPU core's entire real opcode table, complete.
README.md:94 | `tdragonb2` | *"runs too quickly, Oki sounds terrible (IRQ problems?)"* | Not attempted — it would mean diverging from MAME's own known-broken timing. |

Cites MAME source — 172

NMK16_Gunnail.sv:1 NMK16 MiSTerFPGA project — real hardware top-level for the "Gunnail" RBF: GunNail (gunnail, gunnailp — nmk16.cpp gunnail_prot()) and, since 2026-09-11, the nine lowres NMK004 boards (macross, blkheart, mustang, bioship, vandyke, acrobatm, s
NMK16_Gunnail.sv:6 Cloned from NMK16_Raphero.sv: the same framework wiring (hps_io, SDRAM, MAME-style keyboard, P1/P2 autofire, framebuffer rotation, .mra DIP capture) plus NMK16_Macross2.sv's video output retimer (here at 48 MHz: 8 MHz pixels for gunnail's 5
NMK16_Gunnail.sv:64 A vertical (MAME ROT270) game drawn on its side by the board; the two "Vert" choices both present it upright through the framebuffer, as MAME does — "Vert 270" (the MAME-correct rotate_ccw direction) and "Vert 90" (the opposite quarter-turn
NMK16_Gunnail.sv:189 MAME ORIENTATION_FLIP_Y sets (grdnstrm, grdnstrmau, firehawk, spec2kh): the board draws upside down for a monitor mounted that way; the picture is read out bottom-up (rd_y mirrored) so it displays upright, as MAME does.
NMK16_Gunnail.sv:282 Keyboard: MAME's default key bindings, always active, ORed with the joysticks.
NMK16_Gunnail.sv:285 P1: Up/Down/Left/Right arrows, B1 LCtrl, B2 LAlt, B3 Space, Start 1 P2: R/F/D/G, B1 A, B2 S, B3 Q, Start 2 Coin 1 = 5, Coin 2 = 6, Service (IPT_SERVICE1) = 9 Test / Service Mode = F2: a TOGGLE, as in MAME, flipping DSW1 SW1:8 (PORT_SERVICE_
NMK16_Gunnail.sv:387 gunnail has no service-mode DIP (DSW1 bit 0 is Flip Screen); MAME's F2 maps to nothing here, so the DIP bytes pass straight through.
NMK16_Gunnail.sv:575 Cheats (rtl/cheats.sv) — Pugsy's MAME cheat database, seven fixed slots with this game's addresses supplied by the .mra as <rom index="5">.
NMK16_Gunnail.sv:606 This board has a third master -- the protection MCU -- and main RAM is its channel ("inc sprites, shared with MCU", nmk16.cpp hachamf_map).
NMK16_Gunnail.sv:816 ROT270 in MAME: the board's image is turned counter-clockwise to stand upright, which is screen_rotate's rotate_ccw=1 case ("Vert 270"); "Vert 90" is rotate_ccw=0, the opposite quarter-turn, for cabinets whose vertical monitor is mounted th
rtl/bjtwin/nmk_irq_hacky.sv:33 manybloc (nmk16.cpp manybloc_scanline + set_periodic_int, 2026-09-14): a different fixed table on a 240-line screen -- scanline 248 -> sprite DMA, then IRQ4 (both in the same callback, the memcpy first: vpos 248 is the line after the last
rtl/bjtwin/video_timing.sv:7 Reset-time raster phase: `vcount` resets to `VACTIVE_END` (240, the first scanline of vblank), not 0 — confirmed directly against real MAME's own screen device (Family D bring-up investigation, tdragon1): `screen.vpos()` at machine time 0 s
rtl/bjtwin/video_timing.sv:11 Measured two independent ways that agree: (1) a MAME Lua memory-read tap on the protection MCU's own P5 register (`screen.vpos()>>2`, the *exact* value real game code observes) showed vpos in [44,47] at real time 5.260ms after machine start
rtl/bjtwin/video_timing.sv:41 MAME's manybloc_scanline fires off screen vpos, and vpos 0/248 line up with vcount 0/248 exactly under this window.
rtl/cheats.sv:1 Cheat engine — applies Pugsy MAME-database pokes to work RAM once a frame.
rtl/cheats.sv:23 Poke semantics follow MAME's "run" state: the value is written every frame for as long as the cheat is enabled, which is what makes "infinite" cheats hold against the game decrementing the counter.
rtl/gunnail/gunnail_core.sv:14 What the boards are (nmk16.cpp, cross-checked per game): - gunnail: 68000 at 10 MHz, gunnail_map: I/O at 0x080000, palette 0x088000, gunnail_scrollram/scrollramy at 0x08C000/0x08C200 (write-only, 256 words each), BG VRAM 0x090000 (8192 word
rtl/gunnail/gunnail_core.sv:51 - NMK-215 protection MCU (TMP90840, nmk_prot_core.sv, 8 KB ROM nmk-215.bin, byte-identical between gunnail and macross) at 4 MHz: it only loads the two NMK214 descrambler configs at boot through its port 3/port 7 (a MAME Lua trace over 30 s
rtl/gunnail/gunnail_core.sv:112 Same-scene MAME comparison (2026-09-14, HW_ROMS=0 sim only, inert unless the files are given).
rtl/gunnail/gunnail_core.sv:113 The attract demo drifts from MAME within a minute (NMK-7), so a late scene cannot be compared by frame index.
rtl/gunnail/gunnail_core.sv:115 These load a MAME video-state dump straight into this core's own VRAM/palette arrays and hold the 68000 in reset, so the picture is rendered by the FULL core -- every per-game mux exactly as it ships -- rather than by a standalone video_mac
rtl/gunnail/gunnail_core.sv:132 HW_ROMS=0 only: 1 = the DIP switches come from dsw1_i/dsw2_i (the testbench drives the .mra defaults, so the MAME comparison covers language/demo-sound dependent screens); 0 = 0xFFFF as before.
rtl/gunnail/gunnail_core.sv:266 per-source audio taps (sim level checks against MAME's routes)
rtl/gunnail/gunnail_core.sv:301 pixel readback (mirrors MAME's screen:pixel(x,y))
rtl/gunnail/gunnail_core.sv:394 Every per-game difference is a function of game_sel; the values are transcribed from nmk16.cpp's machine configs, memory maps, GFXDECODE tables and ROM_START blocks (see the header).
rtl/gunnail/gunnail_core.sv:427 2026-09-13: the Afega boards (Family H, afega_state in nmk16.cpp): 12 MHz 68000 on afega_map (16-bit DSW at +4, four scroll words at 0x084000/0x08C000, 768-entry palette, main RAM mirrored at 0x0C0000 and 0x0F0000), fixed-scanline IRQs, a Z
rtl/gunnail/gunnail_core.sv:516 decode_ssmissin() is decode_tdragonb's GFX half and nothing else -- nmk16.cpp calls it "Like Thunder Dragon Bootleg without the Program Rom Swapping", and its table is byte-identical to decode_data_tdragonbgfx: {7,6,5,3,4,2,1,0}, i.e. bits
rtl/gunnail/gunnail_core.sv:589 Memory maps (nmk16.cpp): the decode function below keys on these.
rtl/gunnail/gunnail_core.sv:1255 Afega's decryptcode(): the program ROM is stored with address bits 17..13 permuted — MAME un-permutes the image once at init, this core permutes the 68000's address on every fetch instead (the .mra streams the raw files).
rtl/gunnail/gunnail_core.sv:1258 Table t: the SOURCE bit for each of dest bits 17..13, i.e. RAM[i] = file[src] with src[17:13] = {i[a17], i[a16], i[a15], i[a14], i[a13]} (bitswap<24>'s argument order, nmk16.cpp).
rtl/gunnail/gunnail_core.sv:1280 tdragonb (decode_tdragonb, nmk16.cpp): every program word is bitswapped — decode_word's table {e,c,a,8,7,5,3,1,f,d,b,9,6,4,2,0} gives dest bit (15-i) = src bit table[i].
rtl/gunnail/gunnail_core.sv:1322 16 pairs + next-pair prefetch instead of rom_cache1's single pair: see rtl/rom_cache_n.sv (68000 slowdown vs MAME).
rtl/gunnail/gunnail_core.sv:1618 MAME video-state injection (see the STATE_* parameters).
rtl/gunnail/gunnail_core.sv:1763 ssmissin itself never uses the mirror, but airattck/airattcka (the same map and game id) write through it EXCLUSIVELY -- 4096 of 4096 writes measured in MAME -- so without this their TX layer is entirely lost.
rtl/gunnail/gunnail_core.sv:1890 MAME keeps the whole 4 KB as plain .ram() and re-derives the BG scroll from two fixed words of it on EVERY write to the region (manybloc_scroll_w): 0x82/2 = word 0x41 is scrollx, 0xc2/2 = word 0x61 is scrolly.
rtl/gunnail/gunnail_core.sv:1953 Frame-constant scroll registers (every game but gunnail), in the board's own format (nmk16_v.cpp): scroll_w<Layer> (macross_map/acrobatm/tdragon/hachamf/strahl on the LOW byte of words 0x...0/2/4/6; bioship on the HIGH byte — umask16(0xff00
rtl/gunnail/gunnail_core.sv:2031 The screen_update variants read them differently (nmk16_v.cpp video_update / redhawki_video_update / screen_update_firehawk): see afega_vid.
rtl/gunnail/gunnail_core.sv:2179 bioship ROM-tilemap DMA (2026-09-11): MAME's bioship_get_bg_tile_info reads the tile index from the "tilerom" region at (bank << 13) | tile_index on every tile fetch.
rtl/gunnail/gunnail_core.sv:2666 x 3/2 (was 3/8 -- measured 8-13dB quiet vs MAME's real OKI:FM balance)
rtl/gunnail/gunnail_core.sv:2669 jt51's left/right averaged; the OKI's 14-bit `sound` x 2.75 (~0.7 of the 16-bit scale MAME's stream has).
rtl/gunnail/gunnail_core.sv:2679 x3: the Seibu boards' OKI (route 0.40) measured ~6 dB low at x3/2 on the board (mustangb/acrobatmbl vs MAME)
rtl/gunnail/gunnail_core.sv:2691 no FM chip on this board at all: the single OKI alone, at its own 1.0 MAME route
rtl/gunnail/gunnail_core.sv:2722 The firmware is now read back from SDRAM after reset — 8/16 KB over the port-3 arbiter, ~2.5 ms at most — with the 68000 and the MCU held in reset until it is in; the NMK004 boots meanwhile and just waits for its first command, as it does i
rtl/gunnail/gunnail_core.sv:2845 tharrier_map reads IN0 active HIGH, IN1 through the (undumped) MCU — word reads return ~IN1 (start/coin bits, active high on the bus), byte reads of the upper byte return a 15-entry sequence (tharrier_mcu_r), except at two program counters
rtl/gunnail/gunnail_core.sv:2859 NMK-23b: this concatenation was 17 bits wide assigned to a 16-bit wire (verilator WIDTHTRUNC), so the MSB was dropped and every field above it sat one bit too high -- IPT_START2 "in game" landed on bit 9 instead of MAME's 0x0100 (bit 8), so
rtl/gunnail/gunnail_core.sv:2870 Check code at 0x005640") that MAME leaves idle-high, so the port is the constant 0x8000.
rtl/gunnail/gunnail_core.sv:2966 Protection?"): MAME keys on m_maincpu->pc() == 0x416 / 0x64E — the address AFTER the reading instruction (move.w $80006,D0 at 0x410 / 0x648, six bytes each; the boot loops there until the word equals ROM $640 = 0x9000, then ROM $3E7C = 0x54
rtl/gunnail/gunnail_core.sv:2978 Family E (2026-09-14) protection reads and the acrobatmbl ROM patch: tdragonb_prot_r: 0x044022 reads 0x0003 ("no sprites without this"); tdragonb3: that read is unmapped (MAME's unmap value 0) and 0x060000-0x060021 read 0x00EE ("no sprites
rtl/gunnail/gunnail_core.sv:3020 Family E (2026-09-14): the Seibu Sound System board (seibu_sound_map: ROM 0000-1FFF, RAM 2000-27FF, the seibu_sound register block at 4000-401F (rtl/seibu/seibu_sound.sv: latches, IM0 vector arbitration RST10 = YM3812 / RST18 = the 68000's
rtl/gunnail/gunnail_core.sv:3153 The data lanes are captured through the 68000's write cycle (each lane as its strobe says, the other keeps its previous value: MAME's mem_mask) and handed over as a one-clock strobe on the cycle's trailing edge — a level would re-assert RST
rtl/gunnail/gunnail_core.sv:3319 unmapped ports read 0 (MAME's unmap value): gunnailb's Air Buster driver spins at 0x528 until port 4 (its absent OKI, noprw) reads no busy channel
rtl/gunnail/gunnail_core.sv:3349 cactus (2026-09-12): sabotenb's scrambled ROM data on a board with no NMK-215 — MAME's init_nmk table decode is the NMK214 scheme with the configs the NMK-215 sends sabotenb; they are written here after reset instead (the same two-byte sequ
rtl/gunnail/gunnail_core.sv:3555 vandykeb_r: 0; tharrier: soundlatch2; comad boards have no NMK004 there -- twinactn_map noprw()s 0x08000E-F and ssmissin_map leaves it out entirely, both reading 0 in MAME
rtl/gunnail/gunnail_core.sv:3572 MAME's unmap value for a 68000 program space is 0, but this core has always returned 0xFFFF and no shipped game noticed -- they do not read unmapped addresses.
rtl/gunnail/gunnail_core.sv:3574 airattcka does: it reads 0x0C000C (unmapped in ssmissin_map, MAME returns 0x0000) during boot, and on 0xFFFF it computes a bad jump target and spins in unmapped space at PC 0x5F0C56 forever -- a black screen from frame ~50 on.
rtl/gunnail/gunnail_core.sv:3668 The games read their Flip Screen DIP and write bit 0 of the flipscreen register (nmk16_v.cpp flipscreen_w -> flip_screen_set + m_spritegen->set_flip_screen); the register was being latched here and then ignored, so the DIP did nothing on an
rtl/gunnail/gunnail_core.sv:3672 MAME flips the tilemaps and mirrors the sprite coordinates internally, but for a full-screen window the net result is exactly a 180-degree rotation of the visible area -- measured, not assumed: tdragon2 frame 600 with the DIP on is bit-iden
rtl/gunnail/gunnail_core.sv:3677 So the readback coordinates are mirrored here, which reproduces MAME by construction and leaves the tilemap/sprite/prefetch pipeline alone.
rtl/gunnail/gunnail_core.sv:3707 MAME flips only the tilemaps on these boards and leaves the sprites unmirrored ("flip-screen doesn't work on sprites for all sets" on the grdnstrm GAME line, ~5-9k sprite pixels out of place in a frame diff).
rtl/m68705/m68705_core.sv:4 Used only by tharrierb (Task Force Harrier, Lettering bootleg): its "MCU" is a genuine, fully-dumped M68705R3 (mc68705r35.bin, the whole 0x1000-byte internal image — bootstrap ROM + option byte + interrupt vectors included), not an undumped
rtl/m68705/m68705_core.sv:21 Address map (M68705R3, 12-bit bus, m6805_hmos_device::internal_map + m68705_device + m68705r_device): 0x00/01/02/03 port A/B/C/D data, 0x04/05/06 DDR A/B/C (port D has none — it is a dedicated INPUT-only port on this chip, matching tharrier
rtl/m68705/m68705_core.sv:42 `cen_e` (pulsing once per real bus cycle, cen/4 — matching jt680x's own "crystal = 4x E" convention) drives it once per cycle rather than MAME's own once-per-instruction bulk credit; mathematically identical for this purely-linear prescale/
rtl/m68705/m68705_core.sv:98 Cleared when the vector at 0x0FFA is fetched, which is the RTL's observable equivalent of MAME's interrupt() clearing the bit.
rtl/m68705/m68705_core.sv:120 Simulation only: an INSTRUCTION trace, directly comparable with a MAME m6805 trace.
rtl/m68705/m68705_core.sv:121 jt6805's `ni` microinstruction starts the next instruction with its opcode already in md and PC on that instruction, which is exactly what MAME's trace line shows.
rtl/macross2/video_macross2.sv:2 Confirmed directly from the reference: `VIDEO_START_MEMBER(nmk16_state,macross2)` (nmk16_v.cpp:150-162) creates a `common_get_bg_tile_info<0,1>`-driven, `tilemap_scan_pages`-mapped, 256x32-tile (16x16 px) BG tilemap — the SAME BG geometry `
rtl/macross2/video_macross2.sv:16 **No NMK214 descrambling** — macross2 has no protection MCU at all (`init_banked_audiocpu` only, nmk16.cpp:10736); bgtile/sprites ROM data is read directly, unlike video_macross.sv's own two live nmk214 instances.
rtl/macross2/video_macross2.sv:20 **5-bit sprite colour, not 4** — `macross2()`'s own machine config uses `get_colour_5bit` (nmk16.cpp:5457, `colour &= 0x1f`), not `get_colour_4bit` every single prior port in this project has used.
rtl/macross2/video_macross2.sv:23 `gfx_macross2`'s own GFXDECODE_START (nmk16.cpp:4194-4198) confirms the palette layout this requires: sprites at colour base `0x100` with **32** colours (`0x100-0x2FF`, matching the 5-bit index exactly), NOT `0x200` like macross's/gunnail's
rtl/macross2/video_macross2.sv:34 Per-scanline raster scroll: macross2/tdragon2 (RASTER_SCROLL=0) have a single `scroll_w<0>` register (nmk16.cpp:1094) — `bg_xscroll`/ `bg_yscroll` below are frame-constant register inputs.
rtl/macross2/video_macross2.sv:36 raphero (RASTER_SCROLL=1, VIDEO_START gunnail) instead has the two 256-word tables gunnail_scrollram/scrollramy, applied per bitmap line by nmk16_v.cpp bg_update(): for bitmap line y (16..239, i == y1 there), yscroll = scrollramy[0] + scrol
rtl/macross2/video_macross2.sv:76 Sizes the sim array and the tile-code wrap (MAME draws code % elements, elements = bytes/128); the powerins mode's 16-bit code never wraps.
rtl/macross2/video_macross2.sv:86 NMK214=1: BG bytes and sprite words pass through the two NMK214 descramblers (nmk16.cpp base_nmk214_215), configured by the protection MCU through nmk214_cfg_we/data.
rtl/macross2/video_macross2.sv:148 HW_ROMS=1: 1 = the sprite region streams in ROM_LOAD16_WORD_SWAP (or odd-chip-first byte-pair) order, so the byte cache inverts address bit 0 (see the sprite cache comment); 0 = a plain ROM_LOAD byte ROM in MAME's own order (bioship, strahl
rtl/macross2/video_macross2.sv:192 1 = every tile byte's nibbles are swapped (MAME's *_packed_lsb layouts: gfx_powerinsc).
rtl/macross2/video_macross2.sv:196 Afega boards (2026-09-13, Family H on the Gunnail rbf): bg_8bpp: the BG is MAME's tilelayout_8bpp — the ROM region's two halves each hold a col_2x2_group 4bpp tile; MAME's decoder puts plane 0 in the pixel's MSB, so the FIRST half is the hi
rtl/macross2/video_macross2.sv:207 bg_code_mod12k: the 8bpp region holds 12288 tiles per half (a 3 MB region: bubl2000) — MAME's gfx element indexing wraps the code modulo the element count, which a power-of-two mask cannot do.
rtl/macross2/video_macross2.sv:214 Family E bootlegs (2026-09-14, Gunnail rbf): static byte bitswaps MAME applies to the raw GFX ROMs once at init, applied here to every fetched tile byte before the nibble extraction instead (the .mra streams the raw files): gfx_swap34 = dec
rtl/macross2/video_macross2.sv:261 The real board's sprite DMA holds the 68000 off the bus for the ~200us the copy takes; MAME copies the whole table in an instant.
rtl/macross2/video_macross2.sv:276 bgvideoram_w<Layer>/scroll_w<Layer> (nmk16.cpp:465-503): macross2's own bgvideoram is FOUR "banks" of the same 8192-tile-position tilemap (0x10000 bytes vs. every other port's own 0x4000 — see module header), selected by bits[5:4] of the sc
rtl/macross2/video_macross2.sv:318 pixel readback for the testbench (mirrors MAME's screen:pixel(x,y))
rtl/macross2/video_macross2.sv:331 set_scrolldx(28+64,28+64) and the sprite generator's videoshift(28+64) — both in MAME BITMAP coordinates, see BITMAP_X0 below
rtl/macross2/video_macross2.sv:332 MAME positions tilemaps and sprites in BITMAP coordinates: the bitmap spans the whole raster (512x278) and the visible area starts at bitmap (28,16) — the hblank/vblank widths.
rtl/macross2/video_macross2.sv:334 scrolldx(92) therefore means tilemap x = bitmap_x - 92 + scrollx = screen_x + 28 - 92 + scrollx (hence MAME's own "leftmost 64 pixels have to be retrieved from the other side" comment), tilemap y = screen_y + 16 + scrolly, and a sprite at X
rtl/macross2/video_macross2.sv:350 MAME set_screen_midres (nmk16.cpp): raw 448 x 278 at 7 MHz, visible x 60..379 (320 px) — bitmap origin (60,16), the same 64 us line as the 512 x 8 MHz raster this module's callers run (448/7 MHz = 512/8 MHz), so the raster is unchanged and
rtl/macross2/video_macross2.sv:355 Sprite generator: set_mask(0x3ff, 0x3ff) — 10-bit coordinates, wrap modulus 1024 (nmk16spr.cpp: `if (sx > max_x) sx -= xpos_max`), against 0x1ff/512 for the hi-res boards; max_sprite_clock 448*263.
rtl/macross2/video_macross2.sv:514 Layer B's prefetch stream shares port B with the sprite fetch, real-time stream first: the sprite pass is a background compositing pass that simply runs slower while a two-layer game is drawing (its MAME budget is 25 % smaller on the lowres
rtl/macross2/video_macross2.sv:591 Sprite ROM byte order on the hardware path: the ROMs are ROM_LOAD16_WORD_SWAP, and MAME's graphics decoder reads the region BYTE-wise from the swapped memory image, where byte b is raw file byte b^1 (the sim's $readmemh array is built that
rtl/macross2/video_macross2.sv:681 Palette decode: RRRRGGGGBBBBRGBx (emupal.cpp RRRRGGGGBBBBRGBx_decoder)
rtl/macross2/video_macross2.sv:761 cfg_rt: the full 14-bit (bank[1:0], code[11:0]) masked to the ROM's tile count (MAME: code % elements, a power of two for every board but the sprites' — see spr_units); the parameter form is the same for the two masks it can express.
rtl/macross2/video_macross2.sv:782 one 256-colour bank: tilelayout_8bpp's planes 0-3 (the FIRST half, layer A) are MAME's pixel bits 7-4, planes 4-7 (the second half, layer B) bits 3-0
rtl/macross2/video_macross2.sv:826 Found by comparing real-hardware captures against MAME snapshots, see docs/hw-bringup.md.
rtl/macross2/video_macross2.sv:897 MAME copies the table atomically at the trigger (`sprite_dma()` from the scanline timer), as real hardware does.
rtl/macross2/video_macross2.sv:1103 powerins mode only (get_flip_extcode_powerins, attr bit 12): the unit's SOURCE columns are mirrored (nmk16spr.cpp draws each tile with flipx through gfx->transpen) and the units are placed right to left (sx += delta*w, xinc negated) while t
rtl/macross2/video_macross2.sv:1119 Tile code wraps modulo the ROM's element count (MAME: gfx_element does code %= total_elements).
rtl/macross2/video_macross2.sv:1123 hachamf draws its big character sprite (the one over GAME OVER, and on the name-entry screen) with code 0x81D6 = 33238 against spr_units = 8192: MAME gives tile 33238 % 8192 = 470, the old chain gave 33238 - 2*8192 = 16854, which is not jus
rtl/macross2/video_macross2.sv:1176 NMK214 descramble (NMK214=1) — per-fetch, exactly what MAME's decode_nmk214() precomputes: BG byte at byte address A becomes decode_byte(A, rom[A]); the big-endian sprite word at word address W becomes decode_word(W, word).
rtl/macross2/video_macross2.sv:1181 Address bitswap tables: nmk16.cpp nmk214_bg_address_bitswap / nmk214_sprites_address_bitswap.
rtl/macross2/video_macross2.sv:1444 Tiles that lie wholly outside the screen are skipped on their first pixel (MAME clips them too); the game keeps plenty of off-screen objects in its table, and walking their 256 pixels each (and fetching their ROM data) was a large part of w
rtl/macross2/video_macross2.sv:1522 Reference (nmk16_v.cpp screen_update_macross draws m_spriteram_old2, sprite_dma() shifts old2 <- old <- mainram at line 242, the frame is rendered at VBOUT 240 before that DMA): frame j shows the table from DMA j-2.
rtl/macross2/video_macross2.sv:1525 Pure RTL measurement — no MAME frame-index alignment involved.
rtl/nmk112/nmk112.sv:6 Register interface: 8 write-only bank-select registers, addressed offset 0-7 (`okibank_w(offset,data)`, nmk112.cpp:86-98).
rtl/nmk112/nmk112.sv:12 Address remap: PURE address-range decode, no awareness of which of jt6295's own 4 internal ADPCM channels issued a given fetch — confirmed directly from nmk112.cpp's own `oki_map()`/`oki_bank` (nmk112.cpp: 105-130): each OKI's own logical 0
rtl/nmk112/nmk112.sv:23 Confirmed by reading jt6295's own internal channel round-robin (`rtl/third_party/jt6295/ hdl/jt6295_serial.v`'s own `ch` register) — it is NOT exposed on jt6295's own top-level port list, and (per the address-only nature of nmk112.cpp's own
rtl/nmk112/nmk112.sv:31 Paged mode ("sample address table" independent per-voice banking, nmk112.cpp:6-9's own header comment): `is_paged(chip) = BIT(m_page_mask,chip)`, and the device's own default constructor value is `m_page_mask(0xff)` — since none of this pro
rtl/nmk112/nmk112.sv:36 In paged mode, the FIRST 0x400 bytes of the chip's own ENTIRE logical address space (not per-window — confirmed: `map(0x00000,0x000ff)`..`map(0x00300,0x003ff)` are absolute, not offset by any bank window) are overlaid: sub-range N*0x100..N*
rtl/nmk112/nmk112.sv:79 The core drives `hold` = "a gated cen is passing this clock"; the write is captured and applied on the next clock, after the latch — a 25 ns shift, far inside MAME's own sub-sample write/fetch ordering.
rtl/nmk112/nmk112.sv:109 nmk112.cpp:93/96 mask every written page index with `data & m_bankmask[chip]` before storing it (m_bankmask is size-1 for a power-of-two page count, which every real OKI ROM in this hardware family is — 0x80000/0x100000/0x200000/0x400000 al
rtl/nmk214/nmk214.sv:9 The descramble itself is address-dependent: which bitswap gets applied to a given word/byte depends on 3 bits pulled out of the *address* (after first re-ordering the address through ADDR_BITSWAP, since the 13 NMK214 address pins are wired
rtl/nmk214/nmk214.sv:30 Width of the raw ROM address this instance's own ADDR_BITSWAP entries index into — NOT 13 bits: the reference's own per-game bitswap tables (nmk16.cpp's nmk214_sprites_address_bitswap/ nmk214_bg_address_bitswap) pick individual bits out of
rtl/nmk214/nmk214.sv:72 Hardwired tables — verbatim from nmk214.cpp's own anonymous namespace.
rtl/nmk_irq/nmk_irq.sv:10 MAME's own nmk_irq_device does NOT consume the H-timing PROM at all (commented out in nmk_irq.h/.cpp, and that file's own "TODO: Horizontal timing generator emulation?") — screen geometry instead comes from the fixed per-resolution-class pi
rtl/nmk_irq/nmk_irq.sv:18 Every game using this hardware calls set_interrupt_timing() in nmk16.cpp unconditionally with the SAME fixed configuration (prom_start_offset=0x75, vtiming_prom_usage=0x100) — only the V-PROM's own 256-byte contents vary per game — so those
rtl/nmk_irq/nmk_irq.sv:29 Verified via a live MAME debugger capture (breakpoints at mustang's own IRQ1-4 ISR entry addresses, resolved from the ROM's own autovector table, printing the debugger's `beamy` pseudo-symbol) against mustang's real, dumped V-PROM (`10.bpr`
rtl/rom_cache_n.sv:7 Why (docs/hw-bringup.md, "Slowdown"): the real board and MAME run the 68000 with zero wait states from EPROM.
rtl/rom_cache_n.sv:8 Through the 1-line rom_cache1 56% of ROM bus cycles missed (the instruction stream and the game's ROM data-table reads thrash a single pair) and each miss is a ~10 clk_sys SDRAM round trip, 1-2 wait states — 13-20% of every frame spent stal
rtl/savestate/savestate_ui.sv:4 Slot 2 is on F5 and NOT F2 because every top level here already uses F2 for the Service Mode toggle (MAME's binding), and both were acting on the same press -- found on the board in the sibling Sand Scorpion core, 2026-09-20, which shares t
rtl/seibu/seibu_sound.sv:7 Owns: the Z80-side register block at 0x4000-0x401B (seibu_sound_map, seibusound.cpp:333-350), the IM0 interrupt-vector arbitration between the YM3812 (RST10) and the 68000 (RST18) (update_irq_lines/im0_vector_cb, seibusound.cpp:137-204), an
rtl/seibu/seibu_sound.sv:20 - YM3812's own register/data ports and audio synthesis (jtopl2) — this module only arbitrates cs/we/addr_sel and passes data through, exactly matching ym_r/ym_w's own pure pass-through implementation (seibusound.cpp:230-238).
rtl/seibu/seibu_sound.sv:25 Main-CPU-side interface: mustangb (unlike the "full" Seibu games this device was originally written for) only ever exercises `main_mustb_w` — a single word write at 0x08001E/0x08001F on the 68000 side (main_mustb_w, seibusound.cpp:319-329)
rtl/seibu/seibu_sound.sv:29 Confirmed directly against `mustangb_map` (nmk16.cpp:682-698): there is no read of main_r/soundlatch/pending anywhere in that map, so this module does NOT implement `main_r`'s own offset switch (the 68000-side readback of sub2main0/1/main2s
rtl/seibu/seibu_sound.sv:43 RST18 takes priority when both are pending (im0_vector_cb, seibusound.cpp:184-204) — replicated exactly via the same VECTOR_INIT/RST10_*/RST18_* state machine the reference uses (update_irq_lines, seibusound.cpp:137-181), so a simultaneous
rtl/seibu/seibu_sound.sv:94 ROM bank select (bank_w — BIT(data,0), seibusound.cpp:242-243)
rtl/seibu/seibu_sound.sv:108 IRQ arbitration state — mirrors m_rst10_irq/m_rst10_service/ m_rst18_irq/m_rst18_service exactly (seibusound.cpp update_irq_lines, state names kept for direct traceability against the reference).
rtl/seibu/seibu_sound.sv:120 RST18 wins over RST10 when both pending (im0_vector_cb, seibusound.cpp:186-197).
rtl/seibu/seibu_sound.sv:148 main2sub / sub2main latches (soundlatch_r offset 0/1, main_data_w offset 0/1 — seibusound.cpp:257-270,295-329)
rtl/seibu/seibu_sound.sv:155 One-cycle-delayed edge detect for the IACK acknowledge state updates below — matches the reference's own synchronize()-deferred (but same-effective-cycle, since MAME's scheduler.synchronize with no delay runs "now") state transitions: RST10
rtl/seibu/seibu_sound.sv:182 RST10 (YM3812) assert/clear tracks the chip's own irq_n level directly (fm_irqhandler, seibusound.cpp:225-228).
rtl/seibu/seibu_sound.sv:186 RST18 assert: main_mustb_w always asserts, unconditionally (seibusound.cpp:328).
rtl/seibu/seibu_sound.sv:194 IACK: acknowledge the vector actually driven this cycle (RST10_ACKNOWLEDGE / RST18_ACKNOWLEDGE — note RST18's own acknowledge ALSO clears rst18_irq immediately, matching seibusound.cpp:171-174 exactly; RST10's ack only raises rst10_service,
rtl/seibu/seibu_sound.sv:227 Z80-side register reads (main_r-equivalent offsets folded in: soundlatch_r=0x4010/11, main_data_pending_r=0x4012, coin_r=0x4013 hardwired 0xFF per mustangb's own machine config (coin_io_callback().set_constant(0xff), nmk16.cpp:4668))
rtl/seibu/seibu_sound.sv:236 main_data_pending_r reads m_sub2main_pending, not m_main2sub_pending (seibusound.cpp:262-265)
rtl/seibu/seibu_sound.sv:245 YM3812 pass-through (ym_r/ym_w, seibusound.cpp:230-238)
rtl/tlcs90/nmk004_core.sv:90 debug: live register state + a direct peek at internal RAM[dbg_hl] — purely additive, for root-causing oracle divergences against MAME's own debugger register/memory readout (see docs/tier2-system.md, "RET Z at 0x0E5F").
rtl/tlcs90/nmk004_periph.sv:25 - Timers 0-3 (8-bit, or 16-bit paired per TMOD) and timer 4/5 (16-bit compare-match with independent TREG4/TREG5 match points) are REAL counters, matching t90_timer_callback/t90_timer4_callback exactly — this is the one part of the peripher
rtl/tlcs90/nmk004_periph.sv:64 This peripheral register map (`tmp90840_regs` in the reference's own `cpu/tlcs90/tlcs90.cpp`) is identical between the TMP90840 (NMK004's own role) and TMP91640 (the protection-MCU role) — confirmed directly, not assumed — so one module ser
rtl/tlcs90/nmk_prot_core.sv:1 NMK-110/113/215 TLCS-90 shared-RAM protection MCU board wrapper — Tier 2's own Family D (`tdragon_prot_state` in the reference, mame/src/mame/nmk/nmk16.cpp:4895-5123 and nmk16.h:281-308).
rtl/tlcs90/nmk_prot_core.sv:13 Confirmed directly from `mame/src/devices/cpu/tlcs90/ tlcs90.cpp`: `tmp91640_mem` (this role's own device, "TMP91640"/ "NMK-110"/"NMK-113") uses the *exact same* `tmp90840_regs` on-chip peripheral register map (0xffc0-0xffef) as `tmp90840_m
rtl/tlcs90/nmk_prot_core.sv:24 Memory map (see tdragon_prot_map/tdragon_prot() in nmk16.cpp): 0x0000-0x3fff internal boot ROM (16KB — the actual protection program; per-game, e.g. nmk-110-tdragon.bin) 0xfdc0-0xffbf internal RAM (512B) 0xffc0-0xffef on-chip peripherals
rtl/tlcs90/nmk_prot_core.sv:45 Port 5/6 protection-signalling (confirmed directly against `tdragon_prot_state::mcu_port5_r`/`mcu_port6_r`/`mcu_port6_w` in nmk16.cpp, not assumed from a generic port-latch model): - **Port 5 read** returns the current scanline position (`s
rtl/tlcs90/nmk_prot_core.sv:87 `config.set_maximum_quantum(attotime::from_hz(6000))` in the reference (a scheduler-quantum tightening MAME itself needs for this specific timing-sensitive interaction) has no RTL analog: this design's own single shared `clk_sys` domain alr
rtl/tlcs90/nmk_prot_core.sv:165 debug: live HL/A, for root-causing shared-RAM-content divergences against MAME's own debugger register readout (same technique nmk004_core.sv's own dbg_a/dbg_f/dbg_hl already use).
rtl/tlcs90/tlcs90.sv:188 debug: pulses dbg_valid for one cycle at the start of each new instruction with that instruction's own PC — the same point in time MAME's `trace` debugger command reports from, directly diffable against a captured disassembly oracle trace.
rtl/tlcs90/tlcs90.sv:196 debug: live register state, sampled alongside dbg_pc/dbg_valid — purely additive, for root-causing oracle divergences against MAME's own debugger register readout (A/HL/F match MAME's TLCS-90 debug state symbols of the same name).
rtl/tlcs90/tlcs90.sv:420 Same OP_MUL/OP_DIV the PFX_G8 register-operand form already uses (reference: tlcs90.cpp:367-370, "case 0x12: case 0x13: OP(MUL+b0-0x12,16) R16(1,HL) I8(2,READ8())") — missing here entirely, same silent-OP_NOP-fallthrough class as the ADD ix
rtl/tlcs90/tlcs90.sv:432 Confirmed directly against the reference (cpu/tlcs90/tlcs90.cpp:372-373, "case 0x14: case 0x15: case 0x16: OP16(ADD,6) R16(1,IX+b0-0x14) I16(2,READ16())") — this specific base (unprefixed) form was missing from this table entirely (the cycl
rtl/tlcs90/tlcs90.sv:485 LDW ($FF00+w),mn — reuses OP_LD (MAME's own execute() merges "case LDW:" and "case LD|OP_16:" into the identical Write1_16(Read2_16()) path, tlcs90.cpp:1497-1499, so no new opcode is needed).
rtl/tlcs90/tlcs90.sv:489 Missing here entirely (reference: tlcs90.cpp:419-420) — same silent-fallthrough class as above.
rtl/tlcs90/tlcs90.sv:591 Table extracted directly from mame/src/devices/cpu/tlcs90/tlcs90.cpp's own OP()/OPCC()/OP16()/OPCC16() macro table (CT*2 = real clock cycles; conditional entries use the branch-taken result via the same test_cc() the EXECUTE stage itself us
rtl/tlcs90/tlcs90.sv:597 DJNZ's own not-taken cost (0x18/0x19 below) is a deliberate exception to "look it up in this table": the reference's own `OP(DJNZ,10)` (tlcs90.cpp:379/381) only ever sets `m_cyc_t` — `m_cyc_f` (the not-taken cost `Cyc_f()` charges when the
rtl/tlcs90/tlcs90.sv:873 XCF ("extra carry", bit 3) on INC/INCX/DEC/DECX: the reference (tlcs90.cpp's INC/INCX/DEC/DECX cases) computes F from the SZHV table alone (which never touches XCF) and then, as a genuinely separate step, sets XCF if-and-only-if the 8-bit r
rtl/tlcs90/tlcs90.sv:878 This core's own szhv_inc8()/szhv_dec8() never included that bit, so every one of their 4 callers (OP_INC/OP_DEC's 8-bit forms, OP_INCX/OP_DECX) was silently clearing XCF to 0 unconditionally instead — found via a register-state trace diff a
rtl/tlcs90/tlcs90.sv:1890 Two bugs lived here in turn: (1) SET/ RES always wrote to eff2/dout regardless of mode2, discarding the register form's result entirely (found via a register-state trace diff against a MAME oracle, docs/hw-bringup.md's GunNail investigation
README.md:23 Sets MAME flags `MACHINE_NOT_WORKING` are out of scope until MAME can run them.
README.md:26 Verify against MAME as the golden reference before hardware bring-up: MAME Lua tracers dump bus cycles, frames and RAM state, and Verilator testbenches diff the
README.md:28 Hardware is then compared to MAME with HDMI screenshots and audio captures.
README.md:31 MAME is used as a behavioural reference only.
README.md:31 No MAME code is part of the built core.
README.md:66 | Core (`releases/*.rbf`) | Hardware | Games (MAME set names) |
README.md:68 | `NMK16_Macross2` | 68000 + Z80 sound, YM2203, 2x OKIM6295 with NMK112 banking; hi-res and Power Instinct's 320-px board as runtime modes, plus the bootleg boa
README.md:70 | `NMK16_Gunnail` | NMK004 sound MCU, YM2203, 2x OKIM6295; NMK-215/113/110 protection MCUs with dual NMK214; hi-res per-line scroll (GunNail), the nine lowres N
README.md:75 Audio is compared band by band against MAME captures.
README.md:85 The four that do not ship are all `MACHINE_NOT_WORKING` in MAME itself, for reasons MAME states on its own `GAME` lines, and are outside this project's goal unt
README.md:90 | Set | MAME's reason | Here |
README.md:93 | `macrossbl` | *"not looked at yet"* | Not attempted — MAME has not characterised this bootleg at all, so there is nothing to port against. |
README.md:120 Player inputs follow MAME's default key layout.
README.md:211 The simulations read ROM images built from the MAME zips with the scripts in `tools/`.
README.md:231 | `sim/oracle/`, `sim/compare/` | MAME Lua tracer and trace comparison |
README.md:272 jt6805 is a **microcoded** design, and the control store is not jotego's. `rtl/m68705/6805.uc` (4096 x 39 bits) and the `6805.vh` / `6805_param.vh` headers that
README.md:300 The behavioural reference is [MAME](https://github.com/mamedev/mame), in particular `src/mame/nmk/nmk16.cpp`, `nmk16_v.cpp`, `nmk16spr.cpp`, `nmk214.cpp`, `nmk0
README.md:309 The project structure and the simulate-against-MAME methodology follow [kaneko16-mister](https://github.com/alphanu1/kaneko16-mister) and the MiSTer-devel arcad
README.md:324 The MAME source tree and the arcade ROM images are not part of this repository and are not covered by this licence.

Says it matches, follows or was checked against MAME — 14

rtl/bjtwin/nmk_irq_hacky.sv:18 IRQ levels are held (matching MAME's HOLD_LINE semantics for M68K, which auto-clears when the CPU takes the interrupt) until the CPU performs an interrupt-acknowledge bus cycle at that level.
rtl/bjtwin/video_timing.sv:22 This was NOT assumed or guessed: every prior port's own polling loops tolerated the old vcount=0 reset silently (it only ever showed up as an already- documented, bounded residual cycle-cost mismatch in verification), and this project spent
rtl/bjtwin/video_timing.sv:64 see header — matches MAME's own reset-time raster phase
rtl/gunnail/gunnail_core.sv:2862 Widths now sum to exactly 16 and the layout matches tharrier's IN1 as MAME returns it (~IN1): bit0 START1, bit1 START2, bit5 COIN2, bit7 COIN1, bit8 START2.
rtl/gunnail/gunnail_core.sv:2879 Unlike tharrier's own undumped/simulated MCU above, this bootleg's chip is fully dumped, so the game runs against the real thing: rtl/m68705/m68705_core.sv (jotego's jt6805 plus this project's peripheral wrapper), verified instruction-for-i
rtl/gunnail/gunnail_core.sv:3578 Matched to MAME for this map only, to keep the blast radius off every other game on the rbf.
rtl/gunnail/gunnail_core.sv:3689 afega_state::video_update instead reads the DIP bus LIVE every frame, as two independent axes: flip_screen_x_set(BIT(~m_dsw_io[0]->read(), 8)); // horizontal flip_screen_y_set(BIT(~m_dsw_io[0]->read(), 9)); // vertical (active low, and
rtl/macross2/video_macross2.sv:340 Before this conversion the whole picture sat 28 pixels right and 16 lines down of MAME's (measured: shifting a sim frame by (-28,-16) matched MAME's snapshot on 96.5% of all pixels), pushing the rightmost 28 columns and bottom 16 rows off-s
rtl/macross2/video_macross2.sv:1361 Latching in the same cycle as the address change (as this once did) delivered every word one offset late — the visible flag from the previous slot's colour word, the size from the flag word, the code from the size word — which is why moving
rtl/nmk_irq/nmk_irq.sv:24 Phase calibration (empirically verified, not derived from documentation alone): MAME's own screen.vpos() — the `y` the reference's address formula uses directly — is NOT the same numbering as this project's own video_timing.sv `vcount` (bot
rtl/tlcs90/nmk004_periph.sv:3 Built and verified against MAME's cpu/tlcs90/tlcs90.cpp reference model — see docs/tier2-tlcs90.md's "Peripheral registers" section for the full register map and which registers are confirmed exercised by the NMK004 boot ROM.
rtl/tlcs90/tlcs90.sv:4 Built and verified against MAME's `cpu/tlcs90/tlcs90.cpp` reference model — see docs/tier2-tlcs90.md for the full ISA reference, memory map, and verification plan this was derived from (register model, addressing-mode encodings, exact per-o
rtl/tlcs90/tlcs90.sv:1095 LDW (mem),mn — reuses OP_LD same as the base-level 0x3f form above (MAME merges LDW into LD|OP_16's own execute case).
README.md:73 Each core is pixel-identical to MAME in simulation for the whole attract sequence that timing allows, and pixel-identical in hardware screenshots of static scen

Says it was translated, ported or taken from MAME — 4

rtl/nmk112/nmk112.sv:2 Ported directly from mame/src/devices/machine/nmk112.cpp (131 lines, read in full before implementing — every detail below is confirmed against that source, not assumed).
rtl/nmk214/nmk214.sv:1 NMK214 GFX descrambler — a stateless, table-driven dynamic bitswap of graphics-ROM data, ported directly from mame/src/mame/nmk/nmk214.cpp (device comment there has the hardware background: works in tandem with the NMK215/TMP90840 protectio
rtl/nmk_irq/nmk_irq.sv:5 Ported directly from mame/src/mame/nmk/nmk_irq.cpp's own scanline_callback() — see that file's extensive header comment for the hardware background (dual counters + H/V timing PROMs inside the NMK902 custom chip).
rtl/seibu/seibu_sound.sv:3 Ported directly from `seibu_sound_device` (mame/src/mame/shared/ seibusound.{h,cpp}), the Z80 sound-board peripheral used by mustangb/tdragonb/acrobatmbl/strahljbl (Tier 5, Family E — "Raiden sound" bootlegs of NMK16-family games that other

Keeps a MAME approximation — 3

rtl/bjtwin/nmk_irq_hacky.sv:1 nmk_irq "hacky" fixed-scanline interrupt generator — the variant `cactus` uses (undumped timing PROMs on this bootleg; MAME substitutes a fixed scanline table, nmk16.cpp set_hacky_interrupt_timing()/nmk16_hacky_scanline, nmk16.cpp:4482-4511
rtl/gunnail/gunnail_core.sv:21 - The nine others: set_screen_lowres (384 x 278 at 6 MHz, visible 92..347 — the same 64 us line as the 512 x 8 MHz raster, so this core keeps its raster and draws a 256-px window at hcount 92..347), 32x32 TX tilemap, frame-constant scroll r
rtl/gunnail/gunnail_core.sv:3585 Raster timing + interrupt generation: the V-PROM state machine (three PROM tables, vprom_sel) or MAME's fixed-scanline substitute for strahl (irq_hacky).

Shares text with the MAME driver without saying so — 26

NMK16_Gunnail.sv:395 acrobatmbl reads its DSW1 word with SW1 in the HIGH byte ("changed from move.w to move.b"), DSW2 as acrobatm — shares text with nmk/nmk16.cpp:2222
rtl/gunnail/gunnail_core.sv:517 nmk16.cpp calls it "Like Thunder Dragon Bootleg without the Program Rom — shares text with nmk/nmk16.cpp:6129
rtl/gunnail/gunnail_core.sv:896 afega_unknown_r: 0x0100 ("fixes the text in Service Mode") — shares text with nmk/nmk16.cpp:6313
rtl/gunnail/gunnail_core.sv:2019 word 0x9F00 ("the protection device probably copies this to the — shares text with nmk/nmk16_v.cpp:432
rtl/gunnail/gunnail_core.sv:2172 ("otherwise bioship doesn't hit the NMI enough"). — shares text with nmk/nmk16.cpp:237
rtl/gunnail/gunnail_core.sv:2870 an active-low IPT_UNKNOWN ("VBLANK ? Check code at 0x005640") that — shares text with nmk/nmk16.cpp:1441
rtl/gunnail/gunnail_core.sv:2981 0x060000-0x060021 read 0x00EE ("no sprites in attract mode without — shares text with nmk/nmk16.cpp:893
rtl/gunnail/gunnail_core.sv:3691 flip_screen_x_set(BIT(~m_dsw_io[0]->read(), 8)); // horizontal — shares text with nmk/nmk16_v.cpp:519
rtl/gunnail/gunnail_core.sv:3692 flip_screen_y_set(BIT(~m_dsw_io[0]->read(), 9)); // vertical — shares text with nmk/nmk16_v.cpp:520
rtl/macross2/video_macross2.sv:3 `VIDEO_START_MEMBER(nmk16_state,macross2)` (nmk16_v.cpp:150-162) creates — shares text with nmk/nmk16_v.cpp:150
rtl/macross2/video_macross2.sv:4 a `common_get_bg_tile_info<0,1>`-driven, `tilemap_scan_pages`-mapped, — shares text with nmk/nmk16_v.cpp:123
rtl/macross2/video_macross2.sv:331 set_scrolldx(28+64,28+64) and the sprite generator's videoshift(28+64) — both in MAME BITMAP coordinates, see BITMAP_X0 below — shares text with nmk/nmk16_v.cpp:160
rtl/macross2/video_macross2.sv:336 scrollx (hence MAME's own "leftmost 64 pixels have to be retrieved — shares text with nmk/nmk16_v.cpp:159
rtl/macross2/video_macross2.sv:648 BG tile-fetch address — gfx_8x8x4_col_2x2_group_packed_msb layout: — shares text with nmk/nmk16.cpp:4184
rtl/macross2/video_macross2.sv:737 tilemap_scan_pages: (row&0xf) | ((col&0xff)<<4) | ((row&0x10)<<8) — shares text with nmk/nmk16_v.cpp:36
rtl/macross2/video_macross2.sv:752 common_get_bg_tile_info<0,1>: (code&0xfff)|(m_bgbank<<12) — 14-bit — shares text with nmk/nmk16_v.cpp:123
rtl/macross2/video_macross2.sv:788 palette base and tile ROM; common_get_bg_tile_info<1, Gfx> — the — shares text with nmk/nmk16_v.cpp:107
rtl/macross2/video_macross2.sv:829 TILEMAP_SCAN_COLS 8,8,32,32 — 256 logical px, the whole screen), so — shares text with nmk/nmk16_v.cpp:108
rtl/macross2/video_macross2.sv:1182 nmk214_bg_address_bitswap / nmk214_sprites_address_bitswap. — shares text with nmk/nmk16.cpp:5700
rtl/tlcs90/nmk004_periph.sv:59 reference (`tdragon_prot_state::mcu_port5_r`/`mcu_port6_r` — shares text with nmk/nmk16.cpp:5040
rtl/tlcs90/nmk_prot_core.sv:34 `m_maincpu->space(AS_PROGRAM).read_byte(offset)`/`write_byte` — — shares text with nmk/nmk16.cpp:5100
rtl/tlcs90/nmk_prot_core.sv:46 `tdragon_prot_state::mcu_port5_r`/`mcu_port6_r`/`mcu_port6_w` in — shares text with nmk/nmk16.cpp:5040
rtl/tlcs90/nmk_prot_core.sv:61 "the actual mechanism is a little more complex, but these are — shares text with nmk/nmk16.cpp:5022
rtl/tlcs90/nmk_prot_core.sv:62 written at the start and end of the take/release bus function"): — shares text with nmk/nmk16.cpp:5022
rtl/tlcs90/nmk_prot_core.sv:87 `config.set_maximum_quantum(attotime::from_hz(6000))` in the — shares text with nmk/nmk16.cpp:5122
rtl/tlcs90/nmk_prot_core.sv:371 only qualifying ones, matching `m_init_clock_nmk214 = BIT(data,2)` — shares text with nmk/nmk16.cpp:5669

Arcade-NMK16_Macross2#
Thunder Dragon 2, Super Spacefortress Macross II / Chou-Jikuu Yousai Macross II, Gouketsuji Ichizoku
kuzearcade/Arcade-NMK16_MiSTer @ c6af34e9
MAME compared: nmk/nmk16.cpp + 10 related file(s)
Read: 26 HDL files, 10,175 lines (Quartus project)

kuzecores
independent database

Mostly MAME

medium

61%

Statements: 4 toward hardware, 135 toward MAME, 1 not counted

Cites hardware documentation that MAME's driver does not — 2

rtl/nmk_irq/nmk_irq.sv:29 Verified via a live MAME debugger capture (breakpoints at mustang's own IRQ1-4 ISR entry addresses, resolved from the ROM's own autovector table, printing the debugger's `beamy` pseudo-symbol) against mustang's real, dumped V-PROM (`10.bpr`
README.md:71 | `NMK16_Afega` | The Afega derivative boards: 12 MHz 68000 with address-scrambled program ROMs decoded per fetch, Z80 + YM2151 + OKI or twin-OKI sound, an 8bpp

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/nmk_irq/nmk_irq.sv:57 NMK-29: half-populated 82S147 dump (ssmissin/airattck, A5 tied to GND). — also in MAME: 82S147 nmk/nmk16.cpp:4318

Says it was checked on “real hardware” — 1

NMK16_Macross2.sv:30 - Player input bit mapping (joystick_0/1 -> IN0/IN1) is now cross-checked bit-for-bit against nmk16.cpp's own INPUT_PORTS_START(tdragon2)/(macross2) (see in0_i/in1_i's own comment below — macross2's own IN0/IN1 layout is confirmed a strict

Notes where it differs from MAME — 1

README.md:94 | `tdragonb2` | *"runs too quickly, Oki sounds terrible (IRQ problems?)"* | Not attempted — it would mean diverging from MAME's own known-broken timing. |

Cites MAME source — 113

NMK16_Macross2.sv:30 - Player input bit mapping (joystick_0/1 -> IN0/IN1) is now cross-checked bit-for-bit against nmk16.cpp's own INPUT_PORTS_START(tdragon2)/(macross2) (see in0_i/in1_i's own comment below — macross2's own IN0/IN1 layout is confirmed a strict
NMK16_Macross2.sv:86 tdragon2 is a vertical (MAME ROT270) game drawn on its side by the board; the two "Vert" choices both present it upright through the framebuffer, as MAME does — "Vert 270" (the MAME-correct rotate_ccw direction) and "Vert 90" (the opposite
NMK16_Macross2.sv:147 "DIP;" is where MiSTer inserts the DIP-switch submenu it builds from the loaded .mra's <switches>/<dip> entries (releases/*.mra declare every DSW1/DSW2 option from nmk16.cpp).
NMK16_Macross2.sv:299 Player inputs — cross-checked bit-for-bit against INPUT_PORTS_START(tdragon2) (nmk16.cpp:2890-2917).
NMK16_Macross2.sv:300 Also verified against INPUT_PORTS_START(macross2) (nmk16.cpp:2801-2826): IN0 is identical, and IN1 is a strict SUBSET (same R/L/D/U/Button1/Button2/ Start/Coin bit positions, just missing tdragon2's own Button3 — that bit is simply IPT_UNKN
NMK16_Macross2.sv:308 IN0: bit0=COIN1 bit1=COIN2 bit2=SERVICE1 bit3=START1 bit4=START2 bits[7:5]=unused IN1: bit0=P1_RIGHT bit1=P1_LEFT bit2=P1_DOWN bit3=P1_UP bit4=P1_BUTTON1 bit5=P1_BUTTON2 bit6=P1_BUTTON3(tdragon2 only) bit7=unused; bits[14:8]=same 7-bit patt
NMK16_Macross2.sv:315 joystick_0/1 bit convention (MiSTer standard): [0]=Right [1]=Left [2]=Down [3]=Up, then buttons assigned sequentially starting at [4] in the SAME order CONF_STR's own "J1,..." list declares them above (Button1=[4], Button2=[5], Button3=[6],
NMK16_Macross2.sv:328 Keyboard: MAME's default key bindings, always active, ORed with the joysticks.
NMK16_Macross2.sv:333 P1: Up/Down/Left/Right arrows, B1 LCtrl, B2 LAlt, B3 Space, Start 1 P2: R/F/D/G, B1 A, B2 S, B3 Q, Start 2 Coin 1 = 5, Coin 2 = 6, Service (IPT_SERVICE1) = 9 Test / Service Mode = F2: a TOGGLE, as in MAME, flipping DSW1 SW1:8 (PORT_SERVICE_
NMK16_Macross2.sv:340 button 4 (powerins): Left Shift / W, MAME's defaults
NMK16_Macross2.sv:423 Bit 7 of each player byte is BUTTON4 on Power Instinct (nmk16.cpp INPUT_PORTS_START(powerins)); tdragon2/macross2 leave it unused (the port is active low, so an undriven bit reads 1 = released), which is why it is only driven in the powerin
NMK16_Macross2.sv:437 Both tdragon2.mra and macross2.mra pack DSW1 at status[7:0] and DSW2 at status[15:8] (byte order matches the core's own address decode, sel_dsw1 before sel_dsw2 — same for both games, see either .mra's own header for the derivation), so thi
NMK16_Macross2.sv:552 F2 toggles it like MAME's Service Mode key, on top of whatever the OSD DIP setting is.
NMK16_Macross2.sv:598 VTIMING_FILE: nmk_irq.sv's own V-PROM (tdragon2's own "10.bpr", ROM_START(tdragon2), nmk16.cpp:8357-8358) has no HW_ROMS gating at all — it's always loaded via $readmemh, baked into the bitstream at synthesis time rather than through ioctl_
NMK16_Macross2.sv:606 Without this, vtiming_prom is never initialized (stays all-zeros), silently breaking frame-IRQ/ sprite-DMA-trigger timing on real hardware despite a clean compile — this file must exist locally at quartus_map time (generated the same way th
NMK16_Macross2.sv:710 Cheats (rtl/cheats.sv) — Pugsy's MAME cheat database, seven fixed slots with this game's addresses supplied by the .mra as <rom index="5">.
NMK16_Macross2.sv:1197 tdragon2 is ROT270 in MAME, i.e. the board's image has to be turned counter-clockwise to stand upright, which is screen_rotate's rotate_ccw=1 case ("Vert 270"); "Vert 90" is rotate_ccw=0, the opposite quarter-turn, for cabinets whose vertic
rtl/bjtwin/video_timing.sv:7 Reset-time raster phase: `vcount` resets to `VACTIVE_END` (240, the first scanline of vblank), not 0 — confirmed directly against real MAME's own screen device (Family D bring-up investigation, tdragon1): `screen.vpos()` at machine time 0 s
rtl/bjtwin/video_timing.sv:11 Measured two independent ways that agree: (1) a MAME Lua memory-read tap on the protection MCU's own P5 register (`screen.vpos()>>2`, the *exact* value real game code observes) showed vpos in [44,47] at real time 5.260ms after machine start
rtl/bjtwin/video_timing.sv:41 MAME's manybloc_scanline fires off screen vpos, and vpos 0/248 line up with vcount 0/248 exactly under this window.
rtl/cheats.sv:1 Cheat engine — applies Pugsy MAME-database pokes to work RAM once a frame.
rtl/cheats.sv:23 Poke semantics follow MAME's "run" state: the value is written every frame for as long as the cheat is enabled, which is what makes "infinite" cheats hold against the game decrementing the counter.
rtl/macross2/video_macross2.sv:2 Confirmed directly from the reference: `VIDEO_START_MEMBER(nmk16_state,macross2)` (nmk16_v.cpp:150-162) creates a `common_get_bg_tile_info<0,1>`-driven, `tilemap_scan_pages`-mapped, 256x32-tile (16x16 px) BG tilemap — the SAME BG geometry `
rtl/macross2/video_macross2.sv:16 **No NMK214 descrambling** — macross2 has no protection MCU at all (`init_banked_audiocpu` only, nmk16.cpp:10736); bgtile/sprites ROM data is read directly, unlike video_macross.sv's own two live nmk214 instances.
rtl/macross2/video_macross2.sv:20 **5-bit sprite colour, not 4** — `macross2()`'s own machine config uses `get_colour_5bit` (nmk16.cpp:5457, `colour &= 0x1f`), not `get_colour_4bit` every single prior port in this project has used.
rtl/macross2/video_macross2.sv:23 `gfx_macross2`'s own GFXDECODE_START (nmk16.cpp:4194-4198) confirms the palette layout this requires: sprites at colour base `0x100` with **32** colours (`0x100-0x2FF`, matching the 5-bit index exactly), NOT `0x200` like macross's/gunnail's
rtl/macross2/video_macross2.sv:34 Per-scanline raster scroll: macross2/tdragon2 (RASTER_SCROLL=0) have a single `scroll_w<0>` register (nmk16.cpp:1094) — `bg_xscroll`/ `bg_yscroll` below are frame-constant register inputs.
rtl/macross2/video_macross2.sv:36 raphero (RASTER_SCROLL=1, VIDEO_START gunnail) instead has the two 256-word tables gunnail_scrollram/scrollramy, applied per bitmap line by nmk16_v.cpp bg_update(): for bitmap line y (16..239, i == y1 there), yscroll = scrollramy[0] + scrol
rtl/macross2/video_macross2.sv:76 Sizes the sim array and the tile-code wrap (MAME draws code % elements, elements = bytes/128); the powerins mode's 16-bit code never wraps.
rtl/macross2/video_macross2.sv:86 NMK214=1: BG bytes and sprite words pass through the two NMK214 descramblers (nmk16.cpp base_nmk214_215), configured by the protection MCU through nmk214_cfg_we/data.
rtl/macross2/video_macross2.sv:148 HW_ROMS=1: 1 = the sprite region streams in ROM_LOAD16_WORD_SWAP (or odd-chip-first byte-pair) order, so the byte cache inverts address bit 0 (see the sprite cache comment); 0 = a plain ROM_LOAD byte ROM in MAME's own order (bioship, strahl
rtl/macross2/video_macross2.sv:192 1 = every tile byte's nibbles are swapped (MAME's *_packed_lsb layouts: gfx_powerinsc).
rtl/macross2/video_macross2.sv:196 Afega boards (2026-09-13, Family H on the Gunnail rbf): bg_8bpp: the BG is MAME's tilelayout_8bpp — the ROM region's two halves each hold a col_2x2_group 4bpp tile; MAME's decoder puts plane 0 in the pixel's MSB, so the FIRST half is the hi
rtl/macross2/video_macross2.sv:207 bg_code_mod12k: the 8bpp region holds 12288 tiles per half (a 3 MB region: bubl2000) — MAME's gfx element indexing wraps the code modulo the element count, which a power-of-two mask cannot do.
rtl/macross2/video_macross2.sv:214 Family E bootlegs (2026-09-14, Gunnail rbf): static byte bitswaps MAME applies to the raw GFX ROMs once at init, applied here to every fetched tile byte before the nibble extraction instead (the .mra streams the raw files): gfx_swap34 = dec
rtl/macross2/video_macross2.sv:261 The real board's sprite DMA holds the 68000 off the bus for the ~200us the copy takes; MAME copies the whole table in an instant.
rtl/macross2/video_macross2.sv:276 bgvideoram_w<Layer>/scroll_w<Layer> (nmk16.cpp:465-503): macross2's own bgvideoram is FOUR "banks" of the same 8192-tile-position tilemap (0x10000 bytes vs. every other port's own 0x4000 — see module header), selected by bits[5:4] of the sc
rtl/macross2/video_macross2.sv:318 pixel readback for the testbench (mirrors MAME's screen:pixel(x,y))
rtl/macross2/video_macross2.sv:331 set_scrolldx(28+64,28+64) and the sprite generator's videoshift(28+64) — both in MAME BITMAP coordinates, see BITMAP_X0 below
rtl/macross2/video_macross2.sv:332 MAME positions tilemaps and sprites in BITMAP coordinates: the bitmap spans the whole raster (512x278) and the visible area starts at bitmap (28,16) — the hblank/vblank widths.
rtl/macross2/video_macross2.sv:334 scrolldx(92) therefore means tilemap x = bitmap_x - 92 + scrollx = screen_x + 28 - 92 + scrollx (hence MAME's own "leftmost 64 pixels have to be retrieved from the other side" comment), tilemap y = screen_y + 16 + scrolly, and a sprite at X
rtl/macross2/video_macross2.sv:350 MAME set_screen_midres (nmk16.cpp): raw 448 x 278 at 7 MHz, visible x 60..379 (320 px) — bitmap origin (60,16), the same 64 us line as the 512 x 8 MHz raster this module's callers run (448/7 MHz = 512/8 MHz), so the raster is unchanged and
rtl/macross2/video_macross2.sv:355 Sprite generator: set_mask(0x3ff, 0x3ff) — 10-bit coordinates, wrap modulus 1024 (nmk16spr.cpp: `if (sx > max_x) sx -= xpos_max`), against 0x1ff/512 for the hi-res boards; max_sprite_clock 448*263.
rtl/macross2/video_macross2.sv:514 Layer B's prefetch stream shares port B with the sprite fetch, real-time stream first: the sprite pass is a background compositing pass that simply runs slower while a two-layer game is drawing (its MAME budget is 25 % smaller on the lowres
rtl/macross2/video_macross2.sv:591 Sprite ROM byte order on the hardware path: the ROMs are ROM_LOAD16_WORD_SWAP, and MAME's graphics decoder reads the region BYTE-wise from the swapped memory image, where byte b is raw file byte b^1 (the sim's $readmemh array is built that
rtl/macross2/video_macross2.sv:681 Palette decode: RRRRGGGGBBBBRGBx (emupal.cpp RRRRGGGGBBBBRGBx_decoder)
rtl/macross2/video_macross2.sv:761 cfg_rt: the full 14-bit (bank[1:0], code[11:0]) masked to the ROM's tile count (MAME: code % elements, a power of two for every board but the sprites' — see spr_units); the parameter form is the same for the two masks it can express.
rtl/macross2/video_macross2.sv:782 one 256-colour bank: tilelayout_8bpp's planes 0-3 (the FIRST half, layer A) are MAME's pixel bits 7-4, planes 4-7 (the second half, layer B) bits 3-0
rtl/macross2/video_macross2.sv:826 Found by comparing real-hardware captures against MAME snapshots, see docs/hw-bringup.md.
rtl/macross2/video_macross2.sv:897 MAME copies the table atomically at the trigger (`sprite_dma()` from the scanline timer), as real hardware does.
rtl/macross2/video_macross2.sv:1103 powerins mode only (get_flip_extcode_powerins, attr bit 12): the unit's SOURCE columns are mirrored (nmk16spr.cpp draws each tile with flipx through gfx->transpen) and the units are placed right to left (sx += delta*w, xinc negated) while t
rtl/macross2/video_macross2.sv:1119 Tile code wraps modulo the ROM's element count (MAME: gfx_element does code %= total_elements).
rtl/macross2/video_macross2.sv:1123 hachamf draws its big character sprite (the one over GAME OVER, and on the name-entry screen) with code 0x81D6 = 33238 against spr_units = 8192: MAME gives tile 33238 % 8192 = 470, the old chain gave 33238 - 2*8192 = 16854, which is not jus
rtl/macross2/video_macross2.sv:1176 NMK214 descramble (NMK214=1) — per-fetch, exactly what MAME's decode_nmk214() precomputes: BG byte at byte address A becomes decode_byte(A, rom[A]); the big-endian sprite word at word address W becomes decode_word(W, word).
rtl/macross2/video_macross2.sv:1181 Address bitswap tables: nmk16.cpp nmk214_bg_address_bitswap / nmk214_sprites_address_bitswap.
rtl/macross2/video_macross2.sv:1444 Tiles that lie wholly outside the screen are skipped on their first pixel (MAME clips them too); the game keeps plenty of off-screen objects in its table, and walking their 256 pixels each (and fetching their ROM data) was a large part of w
rtl/macross2/video_macross2.sv:1522 Reference (nmk16_v.cpp screen_update_macross draws m_spriteram_old2, sprite_dma() shifts old2 <- old <- mainram at line 242, the frame is rendered at VBOUT 240 before that DMA): frame j shows the table from DMA j-2.
rtl/macross2/video_macross2.sv:1525 Pure RTL measurement — no MAME frame-index alignment involved.
rtl/nmk112/nmk112.sv:6 Register interface: 8 write-only bank-select registers, addressed offset 0-7 (`okibank_w(offset,data)`, nmk112.cpp:86-98).
rtl/nmk112/nmk112.sv:12 Address remap: PURE address-range decode, no awareness of which of jt6295's own 4 internal ADPCM channels issued a given fetch — confirmed directly from nmk112.cpp's own `oki_map()`/`oki_bank` (nmk112.cpp: 105-130): each OKI's own logical 0
rtl/nmk112/nmk112.sv:23 Confirmed by reading jt6295's own internal channel round-robin (`rtl/third_party/jt6295/ hdl/jt6295_serial.v`'s own `ch` register) — it is NOT exposed on jt6295's own top-level port list, and (per the address-only nature of nmk112.cpp's own
rtl/nmk112/nmk112.sv:31 Paged mode ("sample address table" independent per-voice banking, nmk112.cpp:6-9's own header comment): `is_paged(chip) = BIT(m_page_mask,chip)`, and the device's own default constructor value is `m_page_mask(0xff)` — since none of this pro
rtl/nmk112/nmk112.sv:36 In paged mode, the FIRST 0x400 bytes of the chip's own ENTIRE logical address space (not per-window — confirmed: `map(0x00000,0x000ff)`..`map(0x00300,0x003ff)` are absolute, not offset by any bank window) are overlaid: sub-range N*0x100..N*
rtl/nmk112/nmk112.sv:79 The core drives `hold` = "a gated cen is passing this clock"; the write is captured and applied on the next clock, after the latch — a 25 ns shift, far inside MAME's own sub-sample write/fetch ordering.
rtl/nmk112/nmk112.sv:109 nmk112.cpp:93/96 mask every written page index with `data & m_bankmask[chip]` before storing it (m_bankmask is size-1 for a power-of-two page count, which every real OKI ROM in this hardware family is — 0x80000/0x100000/0x200000/0x400000 al
rtl/nmk_irq/nmk_irq.sv:10 MAME's own nmk_irq_device does NOT consume the H-timing PROM at all (commented out in nmk_irq.h/.cpp, and that file's own "TODO: Horizontal timing generator emulation?") — screen geometry instead comes from the fixed per-resolution-class pi
rtl/nmk_irq/nmk_irq.sv:18 Every game using this hardware calls set_interrupt_timing() in nmk16.cpp unconditionally with the SAME fixed configuration (prom_start_offset=0x75, vtiming_prom_usage=0x100) — only the V-PROM's own 256-byte contents vary per game — so those
rtl/nmk_irq/nmk_irq.sv:29 Verified via a live MAME debugger capture (breakpoints at mustang's own IRQ1-4 ISR entry addresses, resolved from the ROM's own autovector table, printing the debugger's `beamy` pseudo-symbol) against mustang's real, dumped V-PROM (`10.bpr`
rtl/rom_cache_n.sv:7 Why (docs/hw-bringup.md, "Slowdown"): the real board and MAME run the 68000 with zero wait states from EPROM.
rtl/rom_cache_n.sv:8 Through the 1-line rom_cache1 56% of ROM bus cycles missed (the instruction stream and the game's ROM data-table reads thrash a single pair) and each miss is a ~10 clk_sys SDRAM round trip, 1-2 wait states — 13-20% of every frame spent stal
rtl/savestate/savestate_ui.sv:4 Slot 2 is on F5 and NOT F2 because every top level here already uses F2 for the Service Mode toggle (MAME's binding), and both were acting on the same press -- found on the board in the sibling Sand Scorpion core, 2026-09-20, which shares t
rtl/tdragon2/tdragon2_core.sv:11 This merge exists because `tdragon2()` and `macross2()`'s own machine configs (nmk16.cpp:5490-5533 / 5444-5488) are BYTE-FOR-BYTE IDENTICAL (same 68000/Z80 clocks, same macross2_sound_map/io_map — literally the same functions — same gfx_mac
rtl/tdragon2/tdragon2_core.sv:36 Difference (the one genuine runtime behavior split) — mainram address-line swap (nmk16.cpp:280-288,1100-1104): `tdragon2_map` is `macross2_map(map)` plus one override, `map(0x1f0000,0x1fffff).rw(mainram_swapped_r,mainram_swapped_w)`, which
rtl/tdragon2/tdragon2_core.sv:49 CRITICAL: this swap applies ONLY to the 68000 CPU-facing bus handler (mainram_swapped_r/w, both directions) — it does NOT apply to MAME's own sprite-DMA snapshot mechanism.
rtl/tdragon2/tdragon2_core.sv:51 Confirmed directly: `sprite_dma()` (nmk16.cpp:4518-4524, the SAME shared function every game in this driver uses, including tdragon2 via nmk_irq's own sprite_dma_cb) does a raw C++ `memcpy(m_spriteram_old.get(), m_mainram + m_sprdma_base/2,
rtl/tdragon2/tdragon2_core.sv:192 MAME runs it silent (no YM2203 on the PCB, "needs emulation of the mechanism used to simulate the missing YM2203's IRQs"); the PCB works with a YM fitted and the sound program is tdragon2's, so this core keeps the YM2203 and plays the full
rtl/tdragon2/tdragon2_core.sv:206 game_pi_gfxlsb (powerinsc): gfx_powerinsc — every tile byte's nibbles swapped (packed_lsb), the 8x8 layer's ROM at +0x280000 of the BG region, the sprite ROMs loaded as byte pairs (MAME marks the set not working: its sprite format is undeci
rtl/tdragon2/tdragon2_core.sv:308 per-source audio taps (sim level checks against MAME's routes)
rtl/tdragon2/tdragon2_core.sv:330 pixel readback for the testbench (mirrors MAME's screen:pixel(x,y))
rtl/tdragon2/tdragon2_core.sv:363 IN0 (nmk16.cpp tdragon2/macross2 INPUT_PORTS): coin/start/service, active low, low byte only.
rtl/tdragon2/tdragon2_core.sv:681 MAME clocks both OKIs at XTAL(16MHz)/4 with pin 7 LOW (nmk16.cpp's macross2/tdragon2 config: `OKIM6295(config, m_oki[n], XTAL(16'000'000) / 4, PIN7_LOW)`), i.e. a 4MHz/165 = 24.24kHz sample rate, and jt6295's `cen` IS the chip clock (its ow
rtl/tdragon2/tdragon2_core.sv:686 This used to be 1MHz (40MHz/40): every sample played four times too slow and two octaves too low — the "muddled" drums, voices and effects heard on real hardware; measured as the hardware spectrum sitting ~4-6 dB below MAME's at 2-4kHz and
rtl/tdragon2/tdragon2_core.sv:797 powerins_map differs (nmk16.cpp:1193): 1 MB ROM, palette 0x120000- 0x120FFF (2048 entries), bgvram 0x140000-0x143FFF, mainram 0x180000- 0x18FFFF, 0x100016 a plain nopw (no Z80 reset), no soundlatch2 read.
rtl/tdragon2/tdragon2_core.sv:918 16 pairs + next-pair prefetch instead of rom_cache1's single pair: see rtl/rom_cache_n.sv (68000 slowdown vs MAME).
rtl/tdragon2/tdragon2_core.sv:1879 powerins_sound_map (nmk16.cpp:1219): 0000-BFFF flat ROM (no bank register, no A000 hole), C000-DFFF RAM, E000 soundlatch read; no soundlatch2 and E001 is a nop (the driver writes it once).
rtl/tdragon2/tdragon2_core.sv:1915 tdragon3h: tdragon2's, with the single OKI's data (MAME "oki2") in the oki1 slot (0x6C0000) — no 2 MB filler for the absent chip.
rtl/tdragon2/tdragon2_core.sv:2098 oki1_rom (chip 1 / MAME tag "oki2") is sized 0x200000/ 21-bit-addressed for both games (macross2's own real chip is half that — harmless, see header); its own OKI2_ROM_FILE simply loads into the low half when macross2's own smaller image is
rtl/tdragon2/tdragon2_core.sv:2295 Balance follows MAME's routing for these boards: FM at 1.20, each OKI at 0.10 (nmk16.cpp macross2 config).
rtl/tdragon2/tdragon2_core.sv:2296 MAME's OKI stream is a 16-bit full-scale signal, i.e. jt6295's 14-bit `sound` x4, so the OKI-to-FM ratio is (4 x 0.10) / 1.20 = 1/3 of the 14-bit value; 3/8 below is the nearest cheap shift-add.
rtl/tdragon2/tdragon2_core.sv:2299 The previous mix put each OKI at x4 — full 16-bit scale next to the FM, ~12x louder than MAME — which, together with the wrong OKI clock above, is what swamped the music.
rtl/tdragon2/tdragon2_core.sv:2306 x 3/2 (was 3/8 -- measured 8-13dB quiet vs MAME's real OKI:FM balance); tdragon3h: chip not fitted
rtl/tdragon2/tdragon2_core.sv:2526 The games read their Flip Screen DIP and write bit 0 of the flipscreen register (nmk16_v.cpp flipscreen_w -> flip_screen_set + m_spritegen->set_flip_screen); the register was being latched here and then ignored, so the DIP did nothing on an
rtl/tdragon2/tdragon2_core.sv:2530 MAME flips the tilemaps and mirrors the sprite coordinates internally, but for a full-screen window the net result is exactly a 180-degree rotation of the visible area -- measured, not assumed: tdragon2 frame 600 with the DIP on is bit-iden
rtl/tdragon2/tdragon2_core.sv:2535 So the readback coordinates are mirrored here, which reproduces MAME by construction and leaves the tilemap/sprite/prefetch pipeline alone.
README.md:23 Sets MAME flags `MACHINE_NOT_WORKING` are out of scope until MAME can run them.
README.md:26 Verify against MAME as the golden reference before hardware bring-up: MAME Lua tracers dump bus cycles, frames and RAM state, and Verilator testbenches diff the
README.md:28 Hardware is then compared to MAME with HDMI screenshots and audio captures.
README.md:31 MAME is used as a behavioural reference only.
README.md:31 No MAME code is part of the built core.
README.md:66 | Core (`releases/*.rbf`) | Hardware | Games (MAME set names) |
README.md:68 | `NMK16_Macross2` | 68000 + Z80 sound, YM2203, 2x OKIM6295 with NMK112 banking; hi-res and Power Instinct's 320-px board as runtime modes, plus the bootleg boa
README.md:70 | `NMK16_Gunnail` | NMK004 sound MCU, YM2203, 2x OKIM6295; NMK-215/113/110 protection MCUs with dual NMK214; hi-res per-line scroll (GunNail), the nine lowres N
README.md:75 Audio is compared band by band against MAME captures.
README.md:85 The four that do not ship are all `MACHINE_NOT_WORKING` in MAME itself, for reasons MAME states on its own `GAME` lines, and are outside this project's goal unt
README.md:90 | Set | MAME's reason | Here |
README.md:93 | `macrossbl` | *"not looked at yet"* | Not attempted — MAME has not characterised this bootleg at all, so there is nothing to port against. |
README.md:120 Player inputs follow MAME's default key layout.
README.md:211 The simulations read ROM images built from the MAME zips with the scripts in `tools/`.
README.md:231 | `sim/oracle/`, `sim/compare/` | MAME Lua tracer and trace comparison |
README.md:272 jt6805 is a **microcoded** design, and the control store is not jotego's. `rtl/m68705/6805.uc` (4096 x 39 bits) and the `6805.vh` / `6805_param.vh` headers that
README.md:300 The behavioural reference is [MAME](https://github.com/mamedev/mame), in particular `src/mame/nmk/nmk16.cpp`, `nmk16_v.cpp`, `nmk16spr.cpp`, `nmk214.cpp`, `nmk0
README.md:309 The project structure and the simulate-against-MAME methodology follow [kaneko16-mister](https://github.com/alphanu1/kaneko16-mister) and the MiSTer-devel arcad
README.md:324 The MAME source tree and the arcade ROM images are not part of this repository and are not covered by this licence.

Says it matches, follows or was checked against MAME — 7

rtl/bjtwin/video_timing.sv:22 This was NOT assumed or guessed: every prior port's own polling loops tolerated the old vcount=0 reset silently (it only ever showed up as an already- documented, bounded residual cycle-cost mismatch in verification), and this project spent
rtl/bjtwin/video_timing.sv:64 see header — matches MAME's own reset-time raster phase
rtl/macross2/video_macross2.sv:340 Before this conversion the whole picture sat 28 pixels right and 16 lines down of MAME's (measured: shifting a sim frame by (-28,-16) matched MAME's snapshot on 96.5% of all pixels), pushing the rightmost 28 columns and bottom 16 rows off-s
rtl/macross2/video_macross2.sv:1361 Latching in the same cycle as the address change (as this once did) delivered every word one offset late — the visible flag from the previous slot's colour word, the size from the flag word, the code from the size word — which is why moving
rtl/nmk_irq/nmk_irq.sv:24 Phase calibration (empirically verified, not derived from documentation alone): MAME's own screen.vpos() — the `y` the reference's address formula uses directly — is NOT the same numbering as this project's own video_timing.sv `vcount` (bot
rtl/tdragon2/tdragon2_core.sv:1661 vid_mainram_addr/dout is DELIBERATELY UNSWAPPED — see header ("Difference 1"): it mirrors MAME's own raw sprite_dma() memcpy, which bypasses the swapped bus handler entirely.
README.md:73 Each core is pixel-identical to MAME in simulation for the whole attract sequence that timing allows, and pixel-identical in hardware screenshots of static scen

Says it was translated, ported or taken from MAME — 2

rtl/nmk112/nmk112.sv:2 Ported directly from mame/src/devices/machine/nmk112.cpp (131 lines, read in full before implementing — every detail below is confirmed against that source, not assumed).
rtl/nmk_irq/nmk_irq.sv:5 Ported directly from mame/src/mame/nmk/nmk_irq.cpp's own scanline_callback() — see that file's extensive header comment for the hardware background (dual counters + H/V timing PROMs inside the NMK902 custom chip).

Shares text with the MAME driver without saying so — 13

rtl/macross2/video_macross2.sv:3 `VIDEO_START_MEMBER(nmk16_state,macross2)` (nmk16_v.cpp:150-162) creates — shares text with nmk/nmk16_v.cpp:150
rtl/macross2/video_macross2.sv:4 a `common_get_bg_tile_info<0,1>`-driven, `tilemap_scan_pages`-mapped, — shares text with nmk/nmk16_v.cpp:123
rtl/macross2/video_macross2.sv:331 set_scrolldx(28+64,28+64) and the sprite generator's videoshift(28+64) — both in MAME BITMAP coordinates, see BITMAP_X0 below — shares text with nmk/nmk16_v.cpp:160
rtl/macross2/video_macross2.sv:336 scrollx (hence MAME's own "leftmost 64 pixels have to be retrieved — shares text with nmk/nmk16_v.cpp:159
rtl/macross2/video_macross2.sv:648 BG tile-fetch address — gfx_8x8x4_col_2x2_group_packed_msb layout: — shares text with nmk/nmk16.cpp:4184
rtl/macross2/video_macross2.sv:737 tilemap_scan_pages: (row&0xf) | ((col&0xff)<<4) | ((row&0x10)<<8) — shares text with nmk/nmk16_v.cpp:36
rtl/macross2/video_macross2.sv:752 common_get_bg_tile_info<0,1>: (code&0xfff)|(m_bgbank<<12) — 14-bit — shares text with nmk/nmk16_v.cpp:123
rtl/macross2/video_macross2.sv:788 palette base and tile ROM; common_get_bg_tile_info<1, Gfx> — the — shares text with nmk/nmk16_v.cpp:107
rtl/macross2/video_macross2.sv:829 TILEMAP_SCAN_COLS 8,8,32,32 — 256 logical px, the whole screen), so — shares text with nmk/nmk16_v.cpp:108
rtl/macross2/video_macross2.sv:1182 nmk214_bg_address_bitswap / nmk214_sprites_address_bitswap. — shares text with nmk/nmk16.cpp:5700
rtl/tdragon2/tdragon2_core.sv:40 applies `bitswap<16>(offset,15,14,13,12,11,7,9,8,10,6,5,4,3,2,1,0)` to the — shares text with nmk/nmk16.cpp:282
rtl/tdragon2/tdragon2_core.sv:54 `memcpy(m_spriteram_old.get(), m_mainram + m_sprdma_base/2, 0x1000)` — — shares text with nmk/nmk16.cpp:4522
rtl/tdragon2/tdragon2_core.sv:804 tdragon3h_map: "bootleg has these 2 swapped" — DSW2 at 0x10000E, the — shares text with nmk/nmk16.cpp:1106

Arcade-NMK16_Raphero#
Arcadia
kuzearcade/Arcade-NMK16_MiSTer @ c6af34e9
MAME compared: nmk/nmk16.cpp + 10 related file(s)
Read: 28 HDL files, 11,563 lines (Quartus project)

kuzecores
independent database

Mostly MAME

medium

66%

Statements: 5 toward hardware, 128 toward MAME, 1 not counted

Cites hardware documentation that MAME's driver does not — 2

rtl/nmk_irq/nmk_irq.sv:29 Verified via a live MAME debugger capture (breakpoints at mustang's own IRQ1-4 ISR entry addresses, resolved from the ROM's own autovector table, printing the debugger's `beamy` pseudo-symbol) against mustang's real, dumped V-PROM (`10.bpr`
README.md:71 | `NMK16_Afega` | The Afega derivative boards: 12 MHz 68000 with address-scrambled program ROMs decoded per fetch, Z80 + YM2151 + OKI or twin-OKI sound, an 8bpp

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/nmk_irq/nmk_irq.sv:57 NMK-29: half-populated 82S147 dump (ssmissin/airattck, A5 tied to GND). — also in MAME: 82S147 nmk/nmk16.cpp:4318

Notes where it differs from MAME — 3

rtl/tlcs90/nmk004_periph.sv:41 - Watchdog (WDMOD/WDCR), serial (SCMOD/SCCR/SCBUF — not even mapped for this specific TLCS-90 variant in the reference), ADC (ADREG/ADMOD), stepping-motor mode (SMMOD's *functional* effect, though the register itself is stored and read back
rtl/tlcs90/tlcs90.sv:43 Still deferred: the TSET/LDA dead opcode space MAME's own reference model can't execute either — this is the CPU core's entire real opcode table, complete.
README.md:94 | `tdragonb2` | *"runs too quickly, Oki sounds terrible (IRQ problems?)"* | Not attempted — it would mean diverging from MAME's own known-broken timing. |

Cites MAME source — 106

NMK16_Raphero.sv:1 NMK16 MiSTerFPGA project — real hardware top-level for the "Raphero" RBF: Rapid Hero / Arcadia (arcadian, raphero, rapheroa — one machine config, nmk16.cpp raphero()).
NMK16_Raphero.sv:3 Cloned from NMK16_Macross2.sv: the same framework wiring (hps_io, SDRAM, video sync, MAME-style keyboard, P1/P2 autofire, framebuffer rotation, .mra DIP capture) around rtl/raphero/raphero_core.sv instead of tdragon2_core.sv, without the ga
NMK16_Raphero.sv:60 A vertical (MAME ROT270) game drawn on its side by the board; the two "Vert" choices both present it upright through the framebuffer, as MAME does — "Vert 270" (the MAME-correct rotate_ccw direction) and "Vert 90" (the opposite quarter-turn
NMK16_Raphero.sv:250 Player inputs — INPUT_PORTS_START(raphero) is laid out exactly as tdragon2's (nmk16.cpp), so this is NMK16_Macross2.sv's own derivation: IN0: bit0=COIN1 bit1=COIN2 bit2=SERVICE1 bit3=START1 bit4=START2 IN1: bit0=P1_RIGHT bit1=P1_LEFT bit2=P
NMK16_Raphero.sv:259 Keyboard: MAME's default key bindings, always active, ORed with the joysticks.
NMK16_Raphero.sv:262 P1: Up/Down/Left/Right arrows, B1 LCtrl, B2 LAlt, B3 Space, Start 1 P2: R/F/D/G, B1 A, B2 S, B3 Q, Start 2 Coin 1 = 5, Coin 2 = 6, Service (IPT_SERVICE1) = 9 Test / Service Mode = F2: a TOGGLE, as in MAME, flipping DSW1 SW1:8 (PORT_SERVICE_
NMK16_Raphero.sv:366 F2 toggles it like MAME's Service Mode key, on top of whatever the OSD DIP setting is.
NMK16_Raphero.sv:515 Cheats (rtl/cheats.sv) — Pugsy's MAME cheat database, seven fixed slots with this game's addresses supplied by the .mra as <rom index="5">.
NMK16_Raphero.sv:739 ROT270 in MAME: the board's image is turned counter-clockwise to stand upright, which is screen_rotate's rotate_ccw=1 case ("Vert 270"); "Vert 90" is rotate_ccw=0, the opposite quarter-turn, for cabinets whose vertical monitor is mounted th
rtl/bjtwin/video_timing.sv:7 Reset-time raster phase: `vcount` resets to `VACTIVE_END` (240, the first scanline of vblank), not 0 — confirmed directly against real MAME's own screen device (Family D bring-up investigation, tdragon1): `screen.vpos()` at machine time 0 s
rtl/bjtwin/video_timing.sv:11 Measured two independent ways that agree: (1) a MAME Lua memory-read tap on the protection MCU's own P5 register (`screen.vpos()>>2`, the *exact* value real game code observes) showed vpos in [44,47] at real time 5.260ms after machine start
rtl/bjtwin/video_timing.sv:41 MAME's manybloc_scanline fires off screen vpos, and vpos 0/248 line up with vcount 0/248 exactly under this window.
rtl/cheats.sv:1 Cheat engine — applies Pugsy MAME-database pokes to work RAM once a frame.
rtl/cheats.sv:23 Poke semantics follow MAME's "run" state: the value is written every frame for as long as the cheat is enabled, which is what makes "infinite" cheats hold against the game decrementing the counter.
rtl/macross2/video_macross2.sv:2 Confirmed directly from the reference: `VIDEO_START_MEMBER(nmk16_state,macross2)` (nmk16_v.cpp:150-162) creates a `common_get_bg_tile_info<0,1>`-driven, `tilemap_scan_pages`-mapped, 256x32-tile (16x16 px) BG tilemap — the SAME BG geometry `
rtl/macross2/video_macross2.sv:16 **No NMK214 descrambling** — macross2 has no protection MCU at all (`init_banked_audiocpu` only, nmk16.cpp:10736); bgtile/sprites ROM data is read directly, unlike video_macross.sv's own two live nmk214 instances.
rtl/macross2/video_macross2.sv:20 **5-bit sprite colour, not 4** — `macross2()`'s own machine config uses `get_colour_5bit` (nmk16.cpp:5457, `colour &= 0x1f`), not `get_colour_4bit` every single prior port in this project has used.
rtl/macross2/video_macross2.sv:23 `gfx_macross2`'s own GFXDECODE_START (nmk16.cpp:4194-4198) confirms the palette layout this requires: sprites at colour base `0x100` with **32** colours (`0x100-0x2FF`, matching the 5-bit index exactly), NOT `0x200` like macross's/gunnail's
rtl/macross2/video_macross2.sv:34 Per-scanline raster scroll: macross2/tdragon2 (RASTER_SCROLL=0) have a single `scroll_w<0>` register (nmk16.cpp:1094) — `bg_xscroll`/ `bg_yscroll` below are frame-constant register inputs.
rtl/macross2/video_macross2.sv:36 raphero (RASTER_SCROLL=1, VIDEO_START gunnail) instead has the two 256-word tables gunnail_scrollram/scrollramy, applied per bitmap line by nmk16_v.cpp bg_update(): for bitmap line y (16..239, i == y1 there), yscroll = scrollramy[0] + scrol
rtl/macross2/video_macross2.sv:76 Sizes the sim array and the tile-code wrap (MAME draws code % elements, elements = bytes/128); the powerins mode's 16-bit code never wraps.
rtl/macross2/video_macross2.sv:86 NMK214=1: BG bytes and sprite words pass through the two NMK214 descramblers (nmk16.cpp base_nmk214_215), configured by the protection MCU through nmk214_cfg_we/data.
rtl/macross2/video_macross2.sv:148 HW_ROMS=1: 1 = the sprite region streams in ROM_LOAD16_WORD_SWAP (or odd-chip-first byte-pair) order, so the byte cache inverts address bit 0 (see the sprite cache comment); 0 = a plain ROM_LOAD byte ROM in MAME's own order (bioship, strahl
rtl/macross2/video_macross2.sv:192 1 = every tile byte's nibbles are swapped (MAME's *_packed_lsb layouts: gfx_powerinsc).
rtl/macross2/video_macross2.sv:196 Afega boards (2026-09-13, Family H on the Gunnail rbf): bg_8bpp: the BG is MAME's tilelayout_8bpp — the ROM region's two halves each hold a col_2x2_group 4bpp tile; MAME's decoder puts plane 0 in the pixel's MSB, so the FIRST half is the hi
rtl/macross2/video_macross2.sv:207 bg_code_mod12k: the 8bpp region holds 12288 tiles per half (a 3 MB region: bubl2000) — MAME's gfx element indexing wraps the code modulo the element count, which a power-of-two mask cannot do.
rtl/macross2/video_macross2.sv:214 Family E bootlegs (2026-09-14, Gunnail rbf): static byte bitswaps MAME applies to the raw GFX ROMs once at init, applied here to every fetched tile byte before the nibble extraction instead (the .mra streams the raw files): gfx_swap34 = dec
rtl/macross2/video_macross2.sv:261 The real board's sprite DMA holds the 68000 off the bus for the ~200us the copy takes; MAME copies the whole table in an instant.
rtl/macross2/video_macross2.sv:276 bgvideoram_w<Layer>/scroll_w<Layer> (nmk16.cpp:465-503): macross2's own bgvideoram is FOUR "banks" of the same 8192-tile-position tilemap (0x10000 bytes vs. every other port's own 0x4000 — see module header), selected by bits[5:4] of the sc
rtl/macross2/video_macross2.sv:318 pixel readback for the testbench (mirrors MAME's screen:pixel(x,y))
rtl/macross2/video_macross2.sv:331 set_scrolldx(28+64,28+64) and the sprite generator's videoshift(28+64) — both in MAME BITMAP coordinates, see BITMAP_X0 below
rtl/macross2/video_macross2.sv:332 MAME positions tilemaps and sprites in BITMAP coordinates: the bitmap spans the whole raster (512x278) and the visible area starts at bitmap (28,16) — the hblank/vblank widths.
rtl/macross2/video_macross2.sv:334 scrolldx(92) therefore means tilemap x = bitmap_x - 92 + scrollx = screen_x + 28 - 92 + scrollx (hence MAME's own "leftmost 64 pixels have to be retrieved from the other side" comment), tilemap y = screen_y + 16 + scrolly, and a sprite at X
rtl/macross2/video_macross2.sv:350 MAME set_screen_midres (nmk16.cpp): raw 448 x 278 at 7 MHz, visible x 60..379 (320 px) — bitmap origin (60,16), the same 64 us line as the 512 x 8 MHz raster this module's callers run (448/7 MHz = 512/8 MHz), so the raster is unchanged and
rtl/macross2/video_macross2.sv:355 Sprite generator: set_mask(0x3ff, 0x3ff) — 10-bit coordinates, wrap modulus 1024 (nmk16spr.cpp: `if (sx > max_x) sx -= xpos_max`), against 0x1ff/512 for the hi-res boards; max_sprite_clock 448*263.
rtl/macross2/video_macross2.sv:514 Layer B's prefetch stream shares port B with the sprite fetch, real-time stream first: the sprite pass is a background compositing pass that simply runs slower while a two-layer game is drawing (its MAME budget is 25 % smaller on the lowres
rtl/macross2/video_macross2.sv:591 Sprite ROM byte order on the hardware path: the ROMs are ROM_LOAD16_WORD_SWAP, and MAME's graphics decoder reads the region BYTE-wise from the swapped memory image, where byte b is raw file byte b^1 (the sim's $readmemh array is built that
rtl/macross2/video_macross2.sv:681 Palette decode: RRRRGGGGBBBBRGBx (emupal.cpp RRRRGGGGBBBBRGBx_decoder)
rtl/macross2/video_macross2.sv:761 cfg_rt: the full 14-bit (bank[1:0], code[11:0]) masked to the ROM's tile count (MAME: code % elements, a power of two for every board but the sprites' — see spr_units); the parameter form is the same for the two masks it can express.
rtl/macross2/video_macross2.sv:782 one 256-colour bank: tilelayout_8bpp's planes 0-3 (the FIRST half, layer A) are MAME's pixel bits 7-4, planes 4-7 (the second half, layer B) bits 3-0
rtl/macross2/video_macross2.sv:826 Found by comparing real-hardware captures against MAME snapshots, see docs/hw-bringup.md.
rtl/macross2/video_macross2.sv:897 MAME copies the table atomically at the trigger (`sprite_dma()` from the scanline timer), as real hardware does.
rtl/macross2/video_macross2.sv:1103 powerins mode only (get_flip_extcode_powerins, attr bit 12): the unit's SOURCE columns are mirrored (nmk16spr.cpp draws each tile with flipx through gfx->transpen) and the units are placed right to left (sx += delta*w, xinc negated) while t
rtl/macross2/video_macross2.sv:1119 Tile code wraps modulo the ROM's element count (MAME: gfx_element does code %= total_elements).
rtl/macross2/video_macross2.sv:1123 hachamf draws its big character sprite (the one over GAME OVER, and on the name-entry screen) with code 0x81D6 = 33238 against spr_units = 8192: MAME gives tile 33238 % 8192 = 470, the old chain gave 33238 - 2*8192 = 16854, which is not jus
rtl/macross2/video_macross2.sv:1176 NMK214 descramble (NMK214=1) — per-fetch, exactly what MAME's decode_nmk214() precomputes: BG byte at byte address A becomes decode_byte(A, rom[A]); the big-endian sprite word at word address W becomes decode_word(W, word).
rtl/macross2/video_macross2.sv:1181 Address bitswap tables: nmk16.cpp nmk214_bg_address_bitswap / nmk214_sprites_address_bitswap.
rtl/macross2/video_macross2.sv:1444 Tiles that lie wholly outside the screen are skipped on their first pixel (MAME clips them too); the game keeps plenty of off-screen objects in its table, and walking their 256 pixels each (and fetching their ROM data) was a large part of w
rtl/macross2/video_macross2.sv:1522 Reference (nmk16_v.cpp screen_update_macross draws m_spriteram_old2, sprite_dma() shifts old2 <- old <- mainram at line 242, the frame is rendered at VBOUT 240 before that DMA): frame j shows the table from DMA j-2.
rtl/macross2/video_macross2.sv:1525 Pure RTL measurement — no MAME frame-index alignment involved.
rtl/nmk112/nmk112.sv:6 Register interface: 8 write-only bank-select registers, addressed offset 0-7 (`okibank_w(offset,data)`, nmk112.cpp:86-98).
rtl/nmk112/nmk112.sv:12 Address remap: PURE address-range decode, no awareness of which of jt6295's own 4 internal ADPCM channels issued a given fetch — confirmed directly from nmk112.cpp's own `oki_map()`/`oki_bank` (nmk112.cpp: 105-130): each OKI's own logical 0
rtl/nmk112/nmk112.sv:23 Confirmed by reading jt6295's own internal channel round-robin (`rtl/third_party/jt6295/ hdl/jt6295_serial.v`'s own `ch` register) — it is NOT exposed on jt6295's own top-level port list, and (per the address-only nature of nmk112.cpp's own
rtl/nmk112/nmk112.sv:31 Paged mode ("sample address table" independent per-voice banking, nmk112.cpp:6-9's own header comment): `is_paged(chip) = BIT(m_page_mask,chip)`, and the device's own default constructor value is `m_page_mask(0xff)` — since none of this pro
rtl/nmk112/nmk112.sv:36 In paged mode, the FIRST 0x400 bytes of the chip's own ENTIRE logical address space (not per-window — confirmed: `map(0x00000,0x000ff)`..`map(0x00300,0x003ff)` are absolute, not offset by any bank window) are overlaid: sub-range N*0x100..N*
rtl/nmk112/nmk112.sv:79 The core drives `hold` = "a gated cen is passing this clock"; the write is captured and applied on the next clock, after the latch — a 25 ns shift, far inside MAME's own sub-sample write/fetch ordering.
rtl/nmk112/nmk112.sv:109 nmk112.cpp:93/96 mask every written page index with `data & m_bankmask[chip]` before storing it (m_bankmask is size-1 for a power-of-two page count, which every real OKI ROM in this hardware family is — 0x80000/0x100000/0x200000/0x400000 al
rtl/nmk_irq/nmk_irq.sv:10 MAME's own nmk_irq_device does NOT consume the H-timing PROM at all (commented out in nmk_irq.h/.cpp, and that file's own "TODO: Horizontal timing generator emulation?") — screen geometry instead comes from the fixed per-resolution-class pi
rtl/nmk_irq/nmk_irq.sv:18 Every game using this hardware calls set_interrupt_timing() in nmk16.cpp unconditionally with the SAME fixed configuration (prom_start_offset=0x75, vtiming_prom_usage=0x100) — only the V-PROM's own 256-byte contents vary per game — so those
rtl/nmk_irq/nmk_irq.sv:29 Verified via a live MAME debugger capture (breakpoints at mustang's own IRQ1-4 ISR entry addresses, resolved from the ROM's own autovector table, printing the debugger's `beamy` pseudo-symbol) against mustang's real, dumped V-PROM (`10.bpr`
rtl/raphero/raphero_core.sv:1 NMK16 MiSTerFPGA project — Rapid Hero / Arcadia (raphero, arcadian, rapheroa: one machine config, nmk16.cpp raphero()) system-level integration, hardware-ready.
rtl/raphero/raphero_core.sv:10 What differs from tdragon2/macross2 (cross-checked against nmk16.cpp):
rtl/raphero/raphero_core.sv:22 - Per-scanline X+Y background scroll: gunnail_scrollram/scrollramy at 0x130000/0x130200 (256 words each), raphero_scroll_w deriving tilerambank from bits [13:12] of scrollram[0] (nmk16_v.cpp:295-311), applied per bitmap line by bg_update()
rtl/raphero/raphero_core.sv:150 per-source audio taps (sim level checks against MAME's routes)
rtl/raphero/raphero_core.sv:175 pixel readback (mirrors MAME's screen:pixel(x,y))
rtl/raphero/raphero_core.sv:418 Address decode (raphero_map, nmk16.cpp)
rtl/raphero/raphero_core.sv:510 16 pairs + next-pair prefetch instead of rom_cache1's single pair: see rtl/rom_cache_n.sv (68000 slowdown vs MAME).
rtl/raphero/raphero_core.sv:1340 x 3/2 (was 3/8 -- measured 8-13dB quiet vs MAME's real OKI:FM balance)
rtl/raphero/raphero_core.sv:1536 The games read their Flip Screen DIP and write bit 0 of the flipscreen register (nmk16_v.cpp flipscreen_w -> flip_screen_set + m_spritegen->set_flip_screen); the register was being latched here and then ignored, so the DIP did nothing on an
rtl/raphero/raphero_core.sv:1540 MAME flips the tilemaps and mirrors the sprite coordinates internally, but for a full-screen window the net result is exactly a 180-degree rotation of the visible area -- measured, not assumed: tdragon2 frame 600 with the DIP on is bit-iden
rtl/raphero/raphero_core.sv:1545 So the readback coordinates are mirrored here, which reproduces MAME by construction and leaves the tilemap/sprite/prefetch pipeline alone.
rtl/rom_cache_n.sv:7 Why (docs/hw-bringup.md, "Slowdown"): the real board and MAME run the 68000 with zero wait states from EPROM.
rtl/rom_cache_n.sv:8 Through the 1-line rom_cache1 56% of ROM bus cycles missed (the instruction stream and the game's ROM data-table reads thrash a single pair) and each miss is a ~10 clk_sys SDRAM round trip, 1-2 wait states — 13-20% of every frame spent stal
rtl/savestate/savestate_ui.sv:4 Slot 2 is on F5 and NOT F2 because every top level here already uses F2 for the Service Mode toggle (MAME's binding), and both were acting on the same press -- found on the board in the sibling Sand Scorpion core, 2026-09-20, which shares t
rtl/tlcs90/nmk004_periph.sv:25 - Timers 0-3 (8-bit, or 16-bit paired per TMOD) and timer 4/5 (16-bit compare-match with independent TREG4/TREG5 match points) are REAL counters, matching t90_timer_callback/t90_timer4_callback exactly — this is the one part of the peripher
rtl/tlcs90/nmk004_periph.sv:64 This peripheral register map (`tmp90840_regs` in the reference's own `cpu/tlcs90/tlcs90.cpp`) is identical between the TMP90840 (NMK004's own role) and TMP91640 (the protection-MCU role) — confirmed directly, not assumed — so one module ser
rtl/tlcs90/tlcs90.sv:188 debug: pulses dbg_valid for one cycle at the start of each new instruction with that instruction's own PC — the same point in time MAME's `trace` debugger command reports from, directly diffable against a captured disassembly oracle trace.
rtl/tlcs90/tlcs90.sv:196 debug: live register state, sampled alongside dbg_pc/dbg_valid — purely additive, for root-causing oracle divergences against MAME's own debugger register readout (A/HL/F match MAME's TLCS-90 debug state symbols of the same name).
rtl/tlcs90/tlcs90.sv:420 Same OP_MUL/OP_DIV the PFX_G8 register-operand form already uses (reference: tlcs90.cpp:367-370, "case 0x12: case 0x13: OP(MUL+b0-0x12,16) R16(1,HL) I8(2,READ8())") — missing here entirely, same silent-OP_NOP-fallthrough class as the ADD ix
rtl/tlcs90/tlcs90.sv:432 Confirmed directly against the reference (cpu/tlcs90/tlcs90.cpp:372-373, "case 0x14: case 0x15: case 0x16: OP16(ADD,6) R16(1,IX+b0-0x14) I16(2,READ16())") — this specific base (unprefixed) form was missing from this table entirely (the cycl
rtl/tlcs90/tlcs90.sv:485 LDW ($FF00+w),mn — reuses OP_LD (MAME's own execute() merges "case LDW:" and "case LD|OP_16:" into the identical Write1_16(Read2_16()) path, tlcs90.cpp:1497-1499, so no new opcode is needed).
rtl/tlcs90/tlcs90.sv:489 Missing here entirely (reference: tlcs90.cpp:419-420) — same silent-fallthrough class as above.
rtl/tlcs90/tlcs90.sv:591 Table extracted directly from mame/src/devices/cpu/tlcs90/tlcs90.cpp's own OP()/OPCC()/OP16()/OPCC16() macro table (CT*2 = real clock cycles; conditional entries use the branch-taken result via the same test_cc() the EXECUTE stage itself us
rtl/tlcs90/tlcs90.sv:597 DJNZ's own not-taken cost (0x18/0x19 below) is a deliberate exception to "look it up in this table": the reference's own `OP(DJNZ,10)` (tlcs90.cpp:379/381) only ever sets `m_cyc_t` — `m_cyc_f` (the not-taken cost `Cyc_f()` charges when the
rtl/tlcs90/tlcs90.sv:873 XCF ("extra carry", bit 3) on INC/INCX/DEC/DECX: the reference (tlcs90.cpp's INC/INCX/DEC/DECX cases) computes F from the SZHV table alone (which never touches XCF) and then, as a genuinely separate step, sets XCF if-and-only-if the 8-bit r
rtl/tlcs90/tlcs90.sv:878 This core's own szhv_inc8()/szhv_dec8() never included that bit, so every one of their 4 callers (OP_INC/OP_DEC's 8-bit forms, OP_INCX/OP_DECX) was silently clearing XCF to 0 unconditionally instead — found via a register-state trace diff a
rtl/tlcs90/tlcs90.sv:1890 Two bugs lived here in turn: (1) SET/ RES always wrote to eff2/dout regardless of mode2, discarding the register form's result entirely (found via a register-state trace diff against a MAME oracle, docs/hw-bringup.md's GunNail investigation
README.md:23 Sets MAME flags `MACHINE_NOT_WORKING` are out of scope until MAME can run them.
README.md:26 Verify against MAME as the golden reference before hardware bring-up: MAME Lua tracers dump bus cycles, frames and RAM state, and Verilator testbenches diff the
README.md:28 Hardware is then compared to MAME with HDMI screenshots and audio captures.
README.md:31 MAME is used as a behavioural reference only.
README.md:31 No MAME code is part of the built core.
README.md:66 | Core (`releases/*.rbf`) | Hardware | Games (MAME set names) |
README.md:68 | `NMK16_Macross2` | 68000 + Z80 sound, YM2203, 2x OKIM6295 with NMK112 banking; hi-res and Power Instinct's 320-px board as runtime modes, plus the bootleg boa
README.md:70 | `NMK16_Gunnail` | NMK004 sound MCU, YM2203, 2x OKIM6295; NMK-215/113/110 protection MCUs with dual NMK214; hi-res per-line scroll (GunNail), the nine lowres N
README.md:75 Audio is compared band by band against MAME captures.
README.md:85 The four that do not ship are all `MACHINE_NOT_WORKING` in MAME itself, for reasons MAME states on its own `GAME` lines, and are outside this project's goal unt
README.md:90 | Set | MAME's reason | Here |
README.md:93 | `macrossbl` | *"not looked at yet"* | Not attempted — MAME has not characterised this bootleg at all, so there is nothing to port against. |
README.md:120 Player inputs follow MAME's default key layout.
README.md:211 The simulations read ROM images built from the MAME zips with the scripts in `tools/`.
README.md:231 | `sim/oracle/`, `sim/compare/` | MAME Lua tracer and trace comparison |
README.md:272 jt6805 is a **microcoded** design, and the control store is not jotego's. `rtl/m68705/6805.uc` (4096 x 39 bits) and the `6805.vh` / `6805_param.vh` headers that
README.md:300 The behavioural reference is [MAME](https://github.com/mamedev/mame), in particular `src/mame/nmk/nmk16.cpp`, `nmk16_v.cpp`, `nmk16spr.cpp`, `nmk214.cpp`, `nmk0
README.md:309 The project structure and the simulate-against-MAME methodology follow [kaneko16-mister](https://github.com/alphanu1/kaneko16-mister) and the MiSTer-devel arcad
README.md:324 The MAME source tree and the arcade ROM images are not part of this repository and are not covered by this licence.

Says it matches, follows or was checked against MAME — 9

rtl/bjtwin/video_timing.sv:22 This was NOT assumed or guessed: every prior port's own polling loops tolerated the old vcount=0 reset silently (it only ever showed up as an already- documented, bounded residual cycle-cost mismatch in verification), and this project spent
rtl/bjtwin/video_timing.sv:64 see header — matches MAME's own reset-time raster phase
rtl/macross2/video_macross2.sv:340 Before this conversion the whole picture sat 28 pixels right and 16 lines down of MAME's (measured: shifting a sim frame by (-28,-16) matched MAME's snapshot on 96.5% of all pixels), pushing the rightmost 28 columns and bottom 16 rows off-s
rtl/macross2/video_macross2.sv:1361 Latching in the same cycle as the address change (as this once did) delivered every word one offset late — the visible flag from the previous slot's colour word, the size from the flag word, the code from the size word — which is why moving
rtl/nmk_irq/nmk_irq.sv:24 Phase calibration (empirically verified, not derived from documentation alone): MAME's own screen.vpos() — the `y` the reference's address formula uses directly — is NOT the same numbering as this project's own video_timing.sv `vcount` (bot
rtl/tlcs90/nmk004_periph.sv:3 Built and verified against MAME's cpu/tlcs90/tlcs90.cpp reference model — see docs/tier2-tlcs90.md's "Peripheral registers" section for the full register map and which registers are confirmed exercised by the NMK004 boot ROM.
rtl/tlcs90/tlcs90.sv:4 Built and verified against MAME's `cpu/tlcs90/tlcs90.cpp` reference model — see docs/tier2-tlcs90.md for the full ISA reference, memory map, and verification plan this was derived from (register model, addressing-mode encodings, exact per-o
rtl/tlcs90/tlcs90.sv:1095 LDW (mem),mn — reuses OP_LD same as the base-level 0x3f form above (MAME merges LDW into LD|OP_16's own execute case).
README.md:73 Each core is pixel-identical to MAME in simulation for the whole attract sequence that timing allows, and pixel-identical in hardware screenshots of static scen

Says it was translated, ported or taken from MAME — 2

rtl/nmk112/nmk112.sv:2 Ported directly from mame/src/devices/machine/nmk112.cpp (131 lines, read in full before implementing — every detail below is confirmed against that source, not assumed).
rtl/nmk_irq/nmk_irq.sv:5 Ported directly from mame/src/mame/nmk/nmk_irq.cpp's own scanline_callback() — see that file's extensive header comment for the hardware background (dual counters + H/V timing PROMs inside the NMK902 custom chip).

Shares text with the MAME driver without saying so — 11

rtl/macross2/video_macross2.sv:3 `VIDEO_START_MEMBER(nmk16_state,macross2)` (nmk16_v.cpp:150-162) creates — shares text with nmk/nmk16_v.cpp:150
rtl/macross2/video_macross2.sv:4 a `common_get_bg_tile_info<0,1>`-driven, `tilemap_scan_pages`-mapped, — shares text with nmk/nmk16_v.cpp:123
rtl/macross2/video_macross2.sv:331 set_scrolldx(28+64,28+64) and the sprite generator's videoshift(28+64) — both in MAME BITMAP coordinates, see BITMAP_X0 below — shares text with nmk/nmk16_v.cpp:160
rtl/macross2/video_macross2.sv:336 scrollx (hence MAME's own "leftmost 64 pixels have to be retrieved — shares text with nmk/nmk16_v.cpp:159
rtl/macross2/video_macross2.sv:648 BG tile-fetch address — gfx_8x8x4_col_2x2_group_packed_msb layout: — shares text with nmk/nmk16.cpp:4184
rtl/macross2/video_macross2.sv:737 tilemap_scan_pages: (row&0xf) | ((col&0xff)<<4) | ((row&0x10)<<8) — shares text with nmk/nmk16_v.cpp:36
rtl/macross2/video_macross2.sv:752 common_get_bg_tile_info<0,1>: (code&0xfff)|(m_bgbank<<12) — 14-bit — shares text with nmk/nmk16_v.cpp:123
rtl/macross2/video_macross2.sv:788 palette base and tile ROM; common_get_bg_tile_info<1, Gfx> — the — shares text with nmk/nmk16_v.cpp:107
rtl/macross2/video_macross2.sv:829 TILEMAP_SCAN_COLS 8,8,32,32 — 256 logical px, the whole screen), so — shares text with nmk/nmk16_v.cpp:108
rtl/macross2/video_macross2.sv:1182 nmk214_bg_address_bitswap / nmk214_sprites_address_bitswap. — shares text with nmk/nmk16.cpp:5700
rtl/tlcs90/nmk004_periph.sv:59 reference (`tdragon_prot_state::mcu_port5_r`/`mcu_port6_r` — shares text with nmk/nmk16.cpp:5040

Arcade-NMKBP964#
Macross Plus, Quiz Bishoujo Senshi Sailor Moon - Chiryoku Tairyoku Toki no Un
kuzearcade/Arcade-NMKBP964_MiSTer @ b02b9f75
MAME compared: nmk/macrossp.cpp
Read: 26 HDL files, 9,442 lines (Quartus project)

kuzecores
independent database

Mostly MAME

medium

58%

Statements: 1 toward hardware, 43 toward MAME

Cites hardware documentation that MAME's driver does not — 1

rtl/macplus/macplus_sound.sv:119 RAM 16K words, byte lanes

Cites MAME source — 39

MacPlus.sv:11 * Four buttons; the INPUTS word is MAME's (PLAN 1.6).
MacPlus.sv:12 * The raster is MAME's 512 x 256 at exactly 60 Hz (D4).
MacPlus.sv:208 <switches>, ioctl index 254: bytes 0/1 are DSW1/DSW2 (MAME's DSW[23:16] and [31:24]); byte 2 is the game mode (bit 0 quizmoon, bit 7 Autofire unlock).
MacPlus.sv:224 Keyboard: MAME's default keys, ORed with the pads.
MacPlus.sv:294 INPUTS (MAME, active low): [0] start 1, [1] start 2, [2] coin 1, [3] coin 2, [5] service 1; [19:16] P1 up/down/left/right, [23:20] P1 B1..B4; [31:24] P2.
rtl/cheats.sv:1 Cheat engine — applies Pugsy MAME-database pokes to work RAM once a frame.
rtl/cheats.sv:34 Poke semantics follow MAME's "run" state: the value is written every frame for as long as the cheat is enabled, which is what makes "infinite" cheats hold against the game decrementing the counter.
rtl/macplus/macplus_bgline.sv:25 Text codes at or above code_limit lie in the zero-filled part of MAME's 4 MB region and are transparent without a fetch.
rtl/macplus/macplus_bgline.sv:26 Colour modes other than 01/10 (MAME: rand(), Q2) draw colour 0 and are counted.
rtl/macplus/macplus_cpu_bus.sv:8 What is new is the timing (MP-6): ITech32's adapter spends about eight fabric clocks on every 16-bit access, which made TG68K 2.4x slower than MAME's 68020 here.
rtl/macplus/macplus_main.sv:11 B0000C DSW in [31:16]; [15:0] read FFFF B00012 fade: high byte of a 16-bit write (0xFF is ignored, as MAME) B00008, B00020 written, ignored C00000 sound command: a write to the upper halfword latches it, sets pending
rtl/macplus/macplus_main.sv:15 MAME also stalls the main CPU 50 us here; the board does not.
rtl/macplus/macplus_main.sv:37 D3 set the board's value, 33/48 (MacPlus.sv), from busy time against MAME on injected MAME states (docs/known-issues.md MP-13); the default here is only nominal.
rtl/macplus/macplus_main.sv:62 active low, MAME's INPUTS layout
rtl/macplus/macplus_main.sv:218 MAME's window starts at the vector fetch, which is the same instant.
rtl/macplus/macplus_main.sv:235 macplus_inject.lua measures MAME the same way.
rtl/macplus/macplus_sound.sv:5 Map (macrossp.cpp:843-849): 000000-0FFFFF program ROM (rom_* port, 16-bit) 200000-207FFF RAM 400000-40007F ES5506 on the LOW byte of each word: register (A >> 1) & 0x3F 600000-600001 sound latch read; clears the main CPU's pending bit I
rtl/macplus/macplus_sound.sv:10 The ES5506 IRQ is MAME's "never seen" line (Q12): it is counted, not wired, until measured.
rtl/macplus/macplus_sound.sv:16 Output: the ES5506's channel 0, 20-bit stereo, at MAME's level.
rtl/macplus/macplus_sound.sv:16 MAME puts the sample out as sample / 2^19 (es5506.cpp put_int_clamp(..., 1 << 19)), routes it at 1.6, and a 16-bit WAV is that times 32768: sample * 0.1.
rtl/macplus/macplus_sound.sv:18 Here (sample * 205) >> 11 = sample * 0.10010, saturated to 16 bits (the level is then confirmed against MAME's WAV, MS1Z-13).
rtl/macplus/macplus_sprites.sv:1 Macross Plus sprites: the three sprite RAMs, the vblank buffer copy, and a line renderer (docs/PLAN.md 1.5, 2.6.3-2.6.4; MP-1 proved the rules below against MAME's pictures, MP-3 measured the load).
rtl/macplus/macplus_sprites.sv:6 At the start of vblank MAME does old2 <- old <- live and draws old2 (macrossp.cpp:752-753).
rtl/macplus/macplus_sprites.sv:13 Entry (3 x 32 bits): w0: high[29:26] y[25:16] colmode[15:14] wide[13:10] x[9:0] w1: yzoom[25:16] xzoom[9:0] 0x100 = 1.0 w2: flipy[31] flipx[30] alpha[29] pri[27:26] col[23:19] tile[15:0] MAME draws entry 1023 first and ent
rtl/macplus/macplus_timing.sv:1 Macross Plus raster (docs/PLAN.md 1.5, D4: MAME's timing is what ships).
rtl/macplus/macplus_timing.sv:3 MAME: 512 x 256 total at 60 Hz, vblank time 0, visible 384 x 240 (macrossp) or 384 x 224 (quizmoon).
rtl/macplus/macplus_timing.sv:9 vblank begins at the first line after the visible area (MAME raises IRQ3 there, set_vblank_int), and vtick marks the last pixel of every line, when the line renderers swap buffers (as ms1z_sprline).
rtl/macplus/macplus_video.sv:13 Composition per pixel (MP-1 proved it against MAME's pictures): layer colour = text if opaque, else the first opaque SCR layer in (priority descending, index ascending) order, else black layer bits = OR of (1 << pri) over opaque SCR layer
rtl/macplus/macplus_video.sv:21 `rgb` is the picture MAME's screen:pixels() returns (no brightness); `rgb_fade` has the fade register applied (Q10 fixes its exact curve).
rtl/macplus/macplus_video.sv:284 fade: MAME scales by (255 - fade) / 255 where fade = u8((d - 40) / 212 * 255); d = 0xFF leaves it alone.
rtl/rom_cache_n.sv:7 Why (docs/hw-bringup.md, "Slowdown"): the real board and MAME run the 68000 with zero wait states from EPROM.
rtl/rom_cache_n.sv:8 Through the 1-line rom_cache1 56% of ROM bus cycles missed (the instruction stream and the game's ROM data-table reads thrash a single pair) and each miss is a ~10 clk_sys SDRAM round trip, 1-2 wait states — 13-20% of every frame spent stal
rtl/savestate/savestate_ui.sv:4 Slot 2 is on F5 and NOT F2 because this core's own keyboard map already uses F2 for the Service Mode toggle (MAME's binding for it), and both were acting on the same press -- found on the board, 2026-09-20.
rtl/savestate/ss_tg68_park.sv:28 MON_BASE must be unmapped on the board: 0x7F8000 is in 400000-7FFFFF, which macrossp.cpp:812-844 leaves empty.
rtl/third_party/es5506/itech32_es5506.sv:4 The register protocol and sample-generation order follow MAME's BSD-3-Clause es5506 device.
README.md:21 MAME's `nmk/macrossp.cpp` (David Haywood, Paul Priest) is the behavioural reference, and every claim below is a measurement against it (`docs/known-issues.md`):
README.md:25 **Video block:** MAME's pictures reproduced **pixel for pixel** from MAME's own state.
README.md:29 The 68EC020 runs at 33/48 of 48 MHz, set against MAME on injected game states (MP-13).
README.md:49 MAME's driver: David Haywood, Paul Priest.

Says it matches, follows or was checked against MAME — 1

README.md:28 **Whole board from reset:** boots, runs the attract, and matches MAME frame for frame at a constant offset.

Says it was translated, ported or taken from MAME — 1

rtl/macplus/macplus_main.sv:63 MAME's DSW[31:16]

Keeps a MAME approximation — 2

rtl/macplus/macplus_bgline.sv:4 SCR A/B/C (TEXT=0): 64x64 tiles of 16x16 at 8 bpp, 32-bit tile words, scroll from vr0, and the per-line zoom MAME guesses at (vr2[31:28] == 0xE):
rtl/macplus/macplus_main.sv:4 Map (byte addresses, macrossp.cpp:807-841): 000000-3FFFFF program ROM (rom_* port; the core supplies SDRAM or an array) 800000-A03FFF video (macplus_video's CPU port) B00000 INPUTS (32-bit, active low) B00004 sound status:

Arcade-SandScrp#
Sand Scorpion
kuzearcade/Arcade-SandScrp_MiSTer @ d3ca399c
MAME compared: kaneko/sandscrp.cpp + 6 related file(s)
Read: 26 HDL files, 6,824 lines (Quartus project)

kuzecores
independent database

Mostly MAME

medium

41%

Statements: 58 toward MAME

Cites MAME source — 47

SandScrp.sv:19 * The game is ROT90, where the NMK16 sets are ROT270, so the two Vert choices are the other way round: rotate_ccw = 0 is the MAME-correct quarter turn here.
SandScrp.sv:23 Every consumer of it (video_retime, crt_chain) is parameterised, and the numbers themselves are a documented unknown -- see docs/known-issues.md SS-1: nothing in MAME describes this board's timing, so these come from the closest sibling Kan
SandScrp.sv:71 Sand Scorpion is ROT90 in MAME: a vertical game the board draws on its side.
SandScrp.sv:72 Both Vert choices present it upright through the framebuffer; "Vert 90" is the MAME-correct direction here (the NMK16 sets are ROT270 and want the other one), and "Vert 270" exists because a cabinet's monitor can be mounted either way round
SandScrp.sv:275 Keyboard: MAME's own default bindings, always live, ORed with the pads.
SandScrp.sv:680 Sand Scorpion is ROT90 in MAME, so the image has to be turned CLOCKWISE to stand upright, which is screen_rotate's rotate_ccw = 0 case -- the opposite of the NMK16 sets, which are ROT270.
SandScrp.sv:682 "Vert 90" is therefore the MAME-correct choice here and is offered first; "Vert 270" is for a cabinet whose monitor is mounted the other way round.
rtl/cheats.sv:1 Cheat engine — applies Pugsy MAME-database pokes to work RAM once a frame.
rtl/cheats.sv:23 Poke semantics follow MAME's "run" state: the value is written every frame for as long as the cheat is enabled, which is what makes "infinite" cheats hold against the game decrementing the counter.
rtl/kaneko/kaneko_hit.sv:1 Kaneko CALC1 (40-pin DIP ULA, no internal ROM), the `kaneko_hit` type 0 of MAME kaneko/kaneko_hit.cpp: eight rectangle registers, a 16x16 multiplier and a random source, behind ten word registers at 0x200000.
rtl/kaneko/kaneko_hit.sv:5 MAME's own note calls Sand Scorpion a set that "only uses Random Number?".
rtl/kaneko/kaneko_hit.sv:28 A random Anything else reads 0 (MAME logs and returns its `data`, which is 0 there).
rtl/kaneko/kaneko_hit.sv:32 MAME's own `machine().rand()` advances per call, so this is the closer model -- and it makes the generator's state a function of how many times the game has read it, which is savestate state.
rtl/kaneko/pandora.sv:1 Kaneko PANDORA (PX79C480FP-3) sprite generator, as MAME kaneko/kan_pand.cpp models it: 512 x 8-byte entries in a 4 KB RAM, rendered whole into a framebuffered plane at every eof() (vblank start), double buffered ("4 64x4 DRAMs - 256x256 8 b
rtl/kaneko/pandora.sv:11 7 [7] flip X [6] flip Y [5:0] code high 6 bits (kan_pand.cpp draw(): flipx = BIT(attr,7), flipy = BIT(attr,6) -- the code, not the table comment above it, which has the two swapped) Entries are walked 0..511; with bit 2 set dx/dy are A
rtl/kaneko/pandora.sv:18 Flip screen (irq_cause bit 0 on this board, which MAME leaves commented out -- measured 2026-09-19 with the Flip Screen DIP: the game writes 0x1b/0x33/0x3b instead of 0x1a/0x32/0x3a): sx = 240 - x, sy = 240 - y, both flips inverted.
rtl/kaneko/pandora.sv:31 * eof: SNAPSHOT the whole RAM into snap[] (1024 dwords, ~1024 cycles); cpu_hold is high meanwhile so the core stalls any CPU access to the RAM (MAME's copy is instantaneous; the game's vblank handler starts rewriting the table right after t
rtl/kaneko/pandora.sv:39 * Swap: the finished plane goes on display at the next eof (lag: the table snapshotted at eof N is visible from the frame after eof N+1, one frame later than MAME) unless LAG1 is set, in which case a pass that finished before the next visib
rtl/kaneko/pandora.sv:196 running position (MAME ints; only bits 8:0 matter)
rtl/kaneko/pandora.sv:217 whole tile off the plane: skip it (MAME clips; walking 256 pixels each is what makes a pass long)
rtl/kaneko/video_sandscrp.sv:1 Sand Scorpion video: VIEW2 (two tile layers) + PANDORA (sprite plane) + the 2048-entry xGRB_555 palette, composed per pixel exactly as sandscrp.cpp screen_update draws: fill with palette index 0; tile categories 0..3 (layer 0 then layer 1 f
rtl/kaneko/video_timing_sandscrp.sv:1 Nothing in MAME documents this board's raster (sandscrp.cpp: set_refresh_hz(60), set_vblank_time(2500 us) "not accurate", set_size(256,256), set_visarea(0,255,16,239)); the values here are the sibling Kaneko/Pandora board snowbros.cpp's con
rtl/kaneko/video_timing_sandscrp.sv:11 Coordinates are MAME's BITMAP coordinates: vcount == bitmap row, so the visible window is rows 16..239 (224 lines) and columns 0..255 of the 384-pixel line.
rtl/kaneko/video_timing_sandscrp.sv:13 The vblank interrupt, the sprite interrupt and Pandora's eof all happen at the first vblank line (vcount == VACTIVE_END, hcount 0), which MAME models as one instant (screen.cpp vblank_begin: render, then the vblank callbacks).
rtl/kaneko/video_timing_sandscrp.sv:18 Reset phase: vcount starts at VACTIVE_END, the first vblank line, as MAME's screen device does at machine time 0 (NMK16 video_timing.sv's measured finding), so the first interrupt comes one full frame after reset.
rtl/kaneko/view2.sv:1 Kaneko VIEW2 tilemap chip, as MAME kaneko/kaneko_tmap.cpp models it for Sand Scorpion (one chip, two 512x512 layers of 16x16x4 tiles, per-row line scroll, 8 priority categories).
rtl/kaneko/view2.sv:14 The chip's own register documentation in kaneko_tmap.cpp lists bits 1/0 as a second, per-layer flip pair, but prepare_common() ignores them: it gives m_tmap[0] AND m_tmap[1] the flip taken from bits 9/8.
rtl/kaneko/view2.sv:17 Sand Scorpion writes 0x0303 with the Flip Screen DIP on -- both pairs at once -- so this capture cannot tell the two readings apart; MAME's behaviour is what the core matches.
rtl/kaneko/view2.sv:20 Tile attr: bits 10-8 category, 7-2 colour, bit 1 flip Y, bit 0 flip X (tileinfo.set(..., TILE_FLIPXY(attr & 3)); TILE_FLIPX == 0x01 -- the comment block in kaneko_tmap.cpp has the two swapped).
rtl/kaneko/view2.sv:25 Geometry, straight from tilemap.cpp with set_offset(0x5b, 0, 256, 224) (layer 0 dx = -0x5b, layer 1 dx = -(0x5b+2); dx_flipped = xdim + dx - 1, dy_flipped = ydim - 1; the flip "around the centre of the visible area" uses xextent = 256 and y
rtl/rom_cache_n.sv:7 Why (docs/hw-bringup.md, "Slowdown"): the real board and MAME run the 68000 with zero wait states from EPROM.
rtl/rom_cache_n.sv:8 Through the 1-line rom_cache1 56% of ROM bus cycles missed (the instruction stream and the game's ROM data-table reads thrash a single pair) and each miss is a ~10 clk_sys SDRAM round trip, 1-2 wait states — 13-20% of every frame spent stal
rtl/sandscrp/sandscrp_core.sv:6 From kaneko/sandscrp.cpp: TMP68HC000N-12 @ 12 MHz, Z8400AB1 @ 4 MHz, YM2203C @ 4 MHz, OKIM6295 @ 12 MHz/6 = 2 MHz pin 7 HIGH, watchdog 3 s. The Z80 reads BOTH DIP banks through the YM2203's port A/B; the 68000 never sees them, so the OSD DI
rtl/sandscrp/sandscrp_core.sv:18 Everything not listed is unmapped and reads 0x0000 -- MAME's unmapped value for this driver, which has no set_unmap_high; a core that returns 0xFFFF instead can spin forever on a bad vector (NMK16's airattcka).
rtl/sandscrp/sandscrp_core.sv:405 PANDORA's flip: the two lines that would set it are commented out in sandscrp.cpp, but the game writes this bit exactly when the Flip Screen DIP is on (0x1b/0x33/0x3b instead of 0x1a/0x32/0x3a -- measured), and the chip has the mechanism.
rtl/sandscrp/sandscrp_core.sv:486 Unmapped reads give 0x0000 (MAME's unmap value here).
rtl/sandscrp/sandscrp_core.sv:791 MAME routes both chips at 0.5; its OKI stream is full 16-bit scale, i.e. jt6295's 14-bit `sound` x4, so the OKI term is shifted up two places against the FM before the halving.
rtl/savestate/savestate_ui.sv:4 Slot 2 is on F5 and NOT F2 because this core's own keyboard map already uses F2 for the Service Mode toggle (MAME's binding for it), and both were acting on the same press -- found on the board, 2026-09-20.
README.md:3 Sand Scorpion (FACE, 1992) for the MiSTer FPGA platform — a from-scratch implementation of the Kaneko VIEW2 tilemap chip and PANDORA sprite generator, built aga
README.md:63 The watchdog reboot the game needs in order to boot at all fires at the core's frame 180 against MAME's 179.
README.md:67 The one frame that matches at no offset is a boot flash: the core renders one line ahead of the raster like the board, so a palette write during the visible are
README.md:84 **CALC1: 200,000 randomised cases against a transcription of MAME's own collision and multiply code, 0 mismatches**, including values straddling 0x8000, sums th
README.md:105 sandscrp_rom_hw.sv the SDRAM side: caches, arbiters, download rtl/ SDRAM controller, ROM caches, prefetch, video retimer, CRT Adjust chain, cheat
README.md:109 sim/rtl/ video_state one frame of video from a MAME state dump
README.md:171 **The MAME driver is the reference this core was built against**, and the debt is a large one.
README.md:172 `kaneko/sandscrp.cpp` is **by Luca Elia**, who wrote the Sand Scorpion driver and is its copyright holder; the Kaneko chip devices this project reimplements in
README.md:180 Every behavioural claim in this repository is measured against that code running as MAME 0.289.

Says it matches, follows or was checked against MAME — 7

SandScrp.sv:29 Everything below compiles and is consistent with the simulations, which are pixel-exact against MAME through the SDRAM path, but no bitstream has been on a DE10-Nano.
README.md:13 **Status: it boots and plays on real hardware.** Milestones 0 to 3 of `docs/PLAN.md` are done and measured: the video path, the whole board, and the whole board
README.md:27 Orientation cannot be observed with the tools to hand, cheats are inconclusive and autofire is untested; audio against MAME and a frame-level comparison with th
README.md:61 **The whole board, run from reset with nothing preloaded, is pixel-exact against MAME**: **43 of 44** dumped frames match with zero differing pixels, through th
README.md:71 **The same core with every ROM byte coming out of the real SDRAM controller is also pixel-exact against MAME**, and an exhaustive golden-byte audit walks all **
README.md:75 **Video: 61 of 61 frames identical to an independent model of MAME.** Each frame is rendered from a MAME state capture and compared three ways — the RTL, a Pyth
README.md:78 31 of the 61 are additionally pixel-exact against MAME; the rest deviate identically in both renderers, because the game rewrites its sprite table 1,747 times p

Shares text with the MAME driver without saying so — 4

rtl/kaneko/pandora.sv:4 ("4 64x4 DRAMs - 256x256 8 bit, double buffered"); the screen shows the — shares text with kaneko/kan_pand.cpp:82
rtl/kaneko/pandora.sv:23 Tile pixels: gfx_8x8x4_row_2x2_group_packed_msb -- 128 bytes per tile, — shares text with kaneko/kaneko_tmap.cpp:136
rtl/kaneko/view2.sv:25 Geometry, straight from tilemap.cpp with set_offset(0x5b, 0, 256, 224) — shares text with kaneko/sandscrp.cpp:456
rtl/kaneko/view2.sv:42 Pixels: gfx_8x8x4_row_2x2_group_packed_lsb -- 128 bytes per tile, blocks — shares text with kaneko/kaneko_tmap.cpp:136

ffaerofgt#
Aero Fighters
jlrh/videosystem-fpga @ ac10643e
MAME compared: vsystem/aerofgt.cpp + 4 related file(s)
Read: 8 HDL files, 2,331 lines (all HDL files: no Quartus project found)

jlrh
independent database

Not enough evidence in the code

insufficient

No statements found

ffaligator#
Alligator Hunt
jlrh/gaelco-fpga @ 90fad211
MAME compared: gaelco/gaelco2.cpp + 5 related file(s)
Read: 19 HDL files, 32,669 lines (all HDL files: no Quartus project found)

jlrh
independent database

Not enough evidence in the code

insufficient

No statements found

ffaltair#
Altair, Altair II
jlrh/cidelsa-fpga @ 066b6f59
MAME compared: efo/cidelsa.cpp + 2 related file(s)
Read: 16 HDL files, 3,721 lines (all HDL files: no Quartus project found)

jlrh
independent database

Not enough evidence in the code

insufficient

Statements: 2 toward MAME

Cites MAME source — 1

README.md:48 **The MAME team** — for the emulation used as a golden reference.

Says it matches, follows or was checked against MAME — 1

README.md:15 Video is pixel-perfect against MAME (0.00% on the validated scenes) and the CPU is validated (OUT stream identical to MAME).

ffasterix#
Asterix
jlrh/konami-fpga @ 238c56fe
MAME compared: konami/asterix.cpp + 11 related file(s)
Read: 9 HDL files, 2,787 lines (all HDL files: no Quartus project found)

jlrh
independent database

Not enough evidence in the code

insufficient

35%

Statements: 2 toward MAME

Cites MAME source — 2

cores/asterix/hdl/jtasterix_sound.v:11 DELTA de asterix (asterix.cpp:319 sound_map):
cores/asterix/hdl/jtasterix_main.v:17 FASE 1 (2026-07-19): escrito al mapa REAL de asterix (konami/asterix.cpp asterix_state::main_map, lineas 295-317).

ffbbusters#
Beast Busters
jlrh/snk-fpga @ 0b121f6f
MAME compared: snk/bbusters.cpp + 2 related file(s)
Read: 8 HDL files, 1,278 lines (all HDL files: no Quartus project found)

jlrh
independent database

Not enough evidence in the code

insufficient

No statements found

ffbigkarnk#
Big Karnak
jlrh/gaelco-fpga @ fb2255fb
MAME compared: gaelco/gaelco.cpp + 4 related file(s)
Read: 26 HDL files, 7,710 lines (all HDL files: no Quartus project found)

jlrh
independent database

Not enough evidence in the code

insufficient

No statements found

ffbiomtoy#
Biomechanical Toy
jlrh/gaelco-fpga @ 49b17096
MAME compared: gaelco/gaelco.cpp + 4 related file(s)
Read: 28 HDL files, 7,684 lines (all HDL files: no Quartus project found)

jlrh
independent database

Not enough evidence in the code

insufficient

No statements found

ffblswhstl#
Detana!! Twin Bee
jlrh/konami-fpga @ 3eeb75d4
MAME compared: konami/tmnt2.cpp + 13 related file(s)
Read: 14 HDL files, 3,577 lines (all HDL files: no Quartus project found)

jlrh
independent database

Not enough evidence in the code

insufficient

No statements found

ffcheqflag#
Chequered Flag
jlrh/konami-fpga @ 1a59e9b1
MAME compared: konami/chqflag.cpp + 7 related file(s)
Read: 159 HDL files, 41,073 lines (all HDL files: no Quartus project found)

jlrh
independent database

Mostly MAME

medium

Statements: 2 toward hardware, 95 toward MAME

Cites hardware documentation that MAME's driver does not — 1

README.md:262 The GX400 video, sound and board logic are the **GX400 core by LMN-san, OScherler and Raki** (GPLv3), built from the schematics and measured on real boards; thi

Says it was checked against the original PCB — 1

README.md:174 Work in progress: it is still being checked stage by stage against the original board.

Cites MAME source — 84

cores/asterix/hdl/jtasterix_sound.v:11 DELTA de asterix (asterix.cpp:319 sound_map):
cores/asterix/hdl/jtasterix_main.v:17 FASE 1 (2026-07-19): escrito al mapa REAL de asterix (konami/asterix.cpp asterix_state::main_map, lineas 295-317).
cores/moomesa/hdl/cowboys_sound.v:121 SONDA (solo sim): captura las escrituras/lecturas del Z80 al k054539 para compararlas con la traza REAL de MAME (debug/k539_trace.txt).
cores/moomesa/hdl/cowboys_sound.v:122 Confirma si el Z80 del core programa el chip IGUAL que MAME (bug interno) o DISTINTO (bug aguas arriba).
cores/moomesa/hdl/cowboys_sound.v:124 reg = A-0xe000 (0x000-0x22f), formato identico al tap de MAME.
cores/moomesa/hdl/cowboys_video.v:179 moomesa reparte 256 slots de sprite con paso 0x100 sobre los 64 kB de 0x190000 (moo.cpp:416 `object_dma`: `src += 0x80` words, y solo las 8 primeras words de cada slot importan).
cores/moomesa/hdl/cowboys_video.v:193 MAME no ordena en el DMA, ordena AL DIBUJAR (`k053246_k053247_k055673.cpp:324-374`, `sortedlist` por el byte de prioridad); `k053246_dma` hace esa misma ordenacion en el DMA via LUT (`dma_bufa <= {sort_24x,3'd0}`) = como el chip real.
cores/moomesa/hdl/cowboys_video.v:263 MAME no tiene la carrera porque `moo_interrupt` muestrea `k053246_is_irq_enabled()` en el INSTANTE del vblank, antes de la ISR.
cores/moomesa/hdl/cowboys_colmix.v:98 Ver HANDOFF sesion 7 §D (ya estaba anotado como "diferencia real contra MAME -> vigilar") y sesion 10.
cores/moomesa/hdl/cowboys_colmix.v:108 Un tile sin marcar sale OPACO aunque alpha_lv sea 0 — antes se suprimía la capa frontal entera y eso borraba el cráter del attract (1200/1350), que es el bug de MAME.
cores/moomesa/hdl/cowboys_colmix.v:112 053251 wiring — mapeo REAL de moomesa (moo.cpp screen_update + k051_palette_index del golden): SPRITES = CI0 (colorbase get_palette_index(CI0)=idx0; prioridad DINAMICA por sprite via pri0, porque EXTEN[0]=0 -> el K053251 usa el input pri0).
cores/moomesa/hdl/cowboys_colmix.v:154 ⭐⭐ AQUI SE ARREGLA UN BUG QUE MAME NUNCA RESOLVIO (sesion 24).
cores/moomesa/hdl/cowboys_colmix.v:156 MAME (moo.cpp:377-385) decide la mezcla POR CAPA y se inventa el enable: m_alpha_enabled = ...
cores/moomesa/hdl/cowboys_colmix.v:157 & K338_CTL_MIXPRI; // DUMMY <- lo admite el propio MAME if (alpha > 0) tilemap_draw(layer[2], ...); // con alpha==0 NO DIBUJA la capa entera Con k38[13]=0 (alpha_lv=0) eso BORRA la capa frontal completa.
cores/moomesa/hdl/cowboys_colmix.v:159 En 1200/1350 esa capa lleva 6841 px: EL CRATER del que sale la mesa -> en MAME la montaña sale flotando.
cores/moomesa/hdl/cowboys_colmix.v:160 Bug conocido y no resuelto (moo.cpp:88-113 "needs a correct enable/disable bit in Moo (INTRO GFX MISSING and fog blocking view)"; moomesa lleva MACHINE_IMPERFECT_GRAPHICS).
cores/moomesa/hdl/cowboys_colmix.v:162 MAME buscaba "un bit de control" y no lo hallaba.
cores/moomesa/hdl/cowboys_colmix.v:164 ✅ EL BIT NO ESTA EN NINGUN REGISTRO: ESTA EN EL ATRIBUTO DEL TILE, y MAME lo TIRA.
cores/moomesa/hdl/cowboys_colmix.v:165 moo.cpp:290 tile_callback: color = m_layer_colorbase[layer] | (color >> 2 & 0x0f); El campo de color son 6 bits (colpre = attr[7:2]); MAME usa colpre[5:2] y DESCARTA colpre[1:0].
cores/moomesa/hdl/cowboys_colmix.v:167 MEDIDO: colpre[0] (= attr[2]) es el flag de mezcla POR TILE: attr[2]=0 -> tile OPACO (el blender no le aplica) attr[2]=1 -> tile MEZCLADO al nivel alpha_lv Con alpha_lv=0 UNA sola regla da las dos conductas que parecian contradictorias: * c
cores/moomesa/hdl/cowboys_colmix.v:177 Evidencia: placa real (sources/crater-captura.png) + `tools/cowboys_tilebits.py` (histograma de los 2 bits descartados) + regresion golden en 15 escenas: 13 IDENTICAS a MAME, solo 1200/1350 cambian.
cores/moomesa/hdl/cowboys_colmix.v:179 ⚠️ En 1200 y 1350 golden y RTL DIVERGEN DE MAME a proposito (~6400 px): ahi el oraculo es la PLACA, no MAME.
cores/moomesa/hdl/cowboys_colmix.v:180 NO lo "arregles" volviendo a casar con MAME.
cores/moomesa/hdl/cowboys_colmix.v:183 5b->8b (=set_alpha_level de MAME)
cores/moomesa/hdl/cowboys_colmix.v:213 El HW no hace eso: k054338.cpp:88-93 -> d = m_regs[K338_REG_SHAD1R + i] & 0x1ff; if (d >= 0x100) d -= 0x200; palette.set_shadow_dRGB32(tabla, dR, dG, dB, noclip) Es un DELTA CON SIGNO (9 bits) que se SUMA a cada canal y se satura.
cores/moomesa/hdl/cowboys_colmix.v:225 Si alguna escena lo pone a 1, hay que revisar (MAME lo pasa a set_shadow_dRGB32).
cores/moomesa/hdl/cowboys_colmix.v:327 Réplica del compositing painter's de moo.cpp screen_update.
cores/moomesa/hdl/cowboys_colmix.v:389 Sin este termino, con alpha_lv=0 la capa frontal entera desaparecia (= el bug del crater de MAME).
cores/moomesa/hdl/cowboys_main.v:19 FASE 1 (sesion 5, 2026-07-16): reescrito al mapa REAL de moomesa (moo.cpp moo_prot_state::moo_map).
cores/moomesa/hdl/cowboys_main.v:21 Referencias: research/moo.cpp lineas 520-587 (moo_map), 393-482 (control2/IRQ), 663-701 (puertos).
cores/moomesa/hdl/cowboys_main.v:92 0x0de000 (moo.cpp control2_w)
cores/moomesa/hdl/cowboys_main.v:189 Evidencia (no suposicion): · `jtframe_dip.v:87` -> `assign dip_test = ~status[10] & game_test; // assumes it is always active low` · `jtframe_inputs.v:184` -> el puerto interno se llama **`coin_n`** (_n = activo bajo) · el core hermano sims
cores/moomesa/hdl/cowboys_main.v:202 defaults (DIP switches hardcoded to MAME defaults: 4 players, stereo, common coin — TODO wire dipsw)
cores/moomesa/hdl/cowboys_main.v:206 IN0 (moo.cpp:664-671): bit0-3 COIN1-4, bit4-7 SERVICE1-4 — todos ACTIVE_LOW
cores/moomesa/hdl/cowboys_main.v:208 IN1 (moo.cpp:674-687): bit0 eep_do, bit1 eep_rdy, bit2 unk(1), bit3 SERVICE (ACTIVE_LOW), bit4 SndOut(0=Stereo), bit5 CoinMech(1=Common), bit7:6 Players(10=4) — defaults de MAME.
cores/moomesa/hdl/cowboys_main.v:225 ---------------- control2 (0x0de000) + EEPROM ---------------- moo.cpp control2_w: bit0 eep di, bit1 eep cs, bit2 eep clk, bit5 IRQ5 en, bit8 objcha (spr ROM read), bit10 watchdog, bit11 IRQ4 en.
cores/moomesa/hdl/cowboys_main.v:280 ================= moo_prot (053990): HLE del blitter — FASE 4 ================= Spec EXACTA = research/moo.cpp:520-545 (moo_prot_state::moo_prot_w), autoridad validada.
cores/moomesa/hdl/cowboys_main.v:283 Escribir el indice 0xc DISPARA: src1={protram[1][7:0],protram[0]} src2={protram[3][7:0],protram[2]} dst ={protram[5][7:0],protram[4]} length=protram[0xf] while(length--) { *dst = *src1 + 2 * *src2; src1+=2; src2+=2; dst+=2; } (protram[8..
cores/moomesa/hdl/cowboys_main.v:312 direccion de byte de 24 bits (MAME) -> direccion de WORD [23:1]; +=2 bytes == +1 word
cores/moomesa/hdl/cowboys_main.v:330 El POST usa src1=paleta(0x1c0000), src2=work RAM(0x180000), dst=work RAM(0x181000); se admite ROM por generalidad (MAME usa space.read_word, todo el mapa).
cores/moomesa/hdl/cowboys_main.v:364 length==0 -> MAME no hace NADA (while(length))
cores/moomesa/hdl/cowboys_main.v:385 res = a + 2*b. MAME lo calcula en 32 bits y write_word TRUNCA a 16 -> el desbordamiento de 16 bits es el comportamiento correcto, no un bug.
cores/moomesa/hdl/cowboys_obj.v:161 As the object layer should not be drawn directly over a shadow, it looks like the logic must be like this - in the LUT the shadow bits are set for the whole sprite - when drawing the sprite, if the shadow is enabled and the sprite pen is 15
cores/moomesa/hdl/cowboys_k056832.v:60 ⭐ SESION 18: el 456 provisional daba 17.54kHz/66.5Hz en placa (real moo.cpp:82-83 = 15.20kHz/59.19Hz) -> refresh ~12% rapido -> JUDDER de scroll (66.5 vs 60 de la tele) y quiza tiles corruptos (poco hblank para el fetch de los line buffers)
cores/moomesa/hdl/cowboys_k056832.v:73 El RGB compuesto (tiles Y sprites, que pasan ambos por colmix -> retardo UNIFORME) sale 3 px tarde; sin compensar, jtframe muestrea desde H=0 y los 3 primeros px activos son basura pre-activo (COLUMNA NEGRA a la izq + todo corrido 3 px a la
cores/moomesa/hdl/cowboys_k056832.v:286 MAME (moo.cpp:290 tile_callback) usa SOLO colpre[5:2] como color y **DESCARTA colpre[1:0]**.
cores/moomesa/hdl/cowboys_k056832.v:287 Medido: colpre[0] (= attr[2]) es el flag "este tile se mezcla" del K054338: attr[2]=0 -> tile OPACO, el blender NO le aplica attr[2]=1 -> tile MEZCLADO al nivel alpha_lv Con alpha_lv=0 eso da las dos conductas que parecian contradictorias,
cores/moomesa/hdl/cowboys_k056832.v:295 MAME no podia hallarlo mirando registros.
cores/moomesa/hdl/k054539.v:3 Escrito de cero contra el golden de MAME (k054539.cpp) y la RE de silicio de Furrtek (github.com/furrtek/SiliconRE/Konami/054539).
cores/moomesa/hdl/k054539.v:57 Mapeo offsets MAME -> modulo: canales 0x0xx igual; control 0x2xx -> 0x1xx active=0x22c->0x12c ctrl=0x22f->0x12f keyon=0x214->0x114 keyoff=0x215->0x115 canal ch base1=0x20*ch (igual) base2=0x200+2*ch -> 0x100+2*ch CPU es el UNICO que es
cores/moomesa/hdl/k054539.v:92 canales sonando (MAME 0x22c)
cores/moomesa/hdl/k054539.v:119 acumuladores en Q16 (como MAME: suma en full-precision, >>16 UNA vez al final)
cores/moomesa/hdl/k054539.v:123 Reverb — linea de retardo mono (MAME k054539.cpp).
cores/moomesa/hdl/k054539.v:163 --- Reverb: parametros del canal en curso (MAME, modo FIXED) --- rdelta = ({base1[7],base1[6]} >> 3); rdelta = (rdelta+revpos)&0x3fff; widx = (rdelta + revpos) & 0x1fff; (revpos sumado DOS veces: quirk exacto de MAME)
cores/moomesa/hdl/k054539.v:415 Q16 -> entero (>>16), clamp del PCM (como MAME), y trim de PCM en vivo
README.md:31 One-on-one fighting game (GX234 board, `mystwarr.cpp` family — the same MAME driver as Mystic Warriors).
README.md:62 Four-player ninja run-and-gun (GX128 board, `mystwarr.cpp` family — the same MAME driver as Martial Champion, and the game the driver is named after).
README.md:114 Western run-and-gun beat-'em-up (GX063 board, `tmnt2.cpp` family).
README.md:129 Vertical cute-'em-up (GX060 board, `tmnt2.cpp` family — the same MAME driver as Sunset Riders).
README.md:135 ℹ️ Unlike every other `tmnt2.cpp`-family board in this repo, **this one has no physical DIP switches
README.md:136 at all** — confirmed against the MAME driver source, `INPUT_PORTS_START(blswhstl)` declares none.
README.md:227 A third K051316 on the sub CPU's bus is not emulated by MAME either.
README.md:241 ℹ️ MAME is **not** a complete reference for this game (`MACHINE_NOT_WORKING`): it does not draw the
README.md:243 core was checked against **video recorded from a real PCB** and against a MAME patched to match that
README.md:311 **MAME** — hardware reference (`moo.cpp` driver, `k054539.cpp` sound chip; `konami/asterix.cpp` and `konami/tmnt2.cpp` drivers, `k052109.cpp` / `k053244_k053245
README.md:321 To the **MAME community**, for the preservation and reverse-engineering work without which this core would not be possible.
README.md:365 Juego de lucha uno contra uno (placa GX234, familia `mystwarr.cpp` — el mismo driver de MAME que Mystic Warriors).
README.md:397 Run-and-gun de ninjas para cuatro jugadores (placa GX128, familia `mystwarr.cpp` — el mismo driver de MAME que Martial Champion, y el juego que le da nombre).
README.md:450 Run-and-gun / yo-contra-el-barrio del oeste (placa GX063, familia `tmnt2.cpp`).
README.md:466 Shoot-'em-up vertical "cute" (placa GX060, familia `tmnt2.cpp` — el mismo driver de MAME que Sunset Riders).
README.md:472 ℹ️ A diferencia del resto de placas de la familia `tmnt2.cpp` de este repo, **ésta no lleva ni un
README.md:473 solo dip switch físico** — confirmado contra el fuente del driver de MAME,
README.md:477 **Estado: jugable en MiSTer** — el arranque, el vídeo (tilemap + sprites + prioridad) y el chip de colisión K054000 funcionan en hardware; el camino de color se
README.md:508 No existe RTL público del K053250 en ningún sitio; se ha escrito a partir del modelo de MAME y se ha validado píxel a píxel contra MAME sobre capturas de fotogr
README.md:551 **Estado: en desarrollo — arranca y se juega en MiSTer.** El vídeo y el sonido del modo attract, grabados en hardware, coinciden con MAME.
README.md:565 **Estado: en desarrollo — arranca y se juega en MiSTer.** En simulación el vídeo coincide con MAME píxel a píxel (160 escenas de attract y de partida), la CPU p
README.md:567 Un tercer K051316 en el bus de la CPU secundaria tampoco lo emula MAME.
README.md:581 ℹ️ MAME **no** es una referencia completa para este juego (`MACHINE_NOT_WORKING`): no dibuja la
README.md:584 MAME parcheado para casar con ese vídeo; donde no coinciden, manda la PCB.
README.md:606 **Estado: en desarrollo — arranca y se juega en MiSTer.** En simulación el vídeo coincide con MAME cuadro a cuadro en el arranque, el attract y la salida de la
README.md:609 El banco de sonido (Z80 + 2× AY + K005289) coincide con los tiempos de MAME.
README.md:650 **MAME** — referencia de hardware (driver `moo.cpp`, chip de sonido `k054539.cpp`; drivers `konami/asterix.cpp` y `konami/tmnt2.cpp`, chips de vídeo/colisión `k
README.md:660 A la **comunidad MAME**, por el trabajo de preservación e ingeniería inversa sin el cual este core no sería posible.
README.md:827 | jtkcpu — CPU Konami 052001 (CPU principal). Commit 4b9caa1 + cores/chequeredflag/patches/jtkcpu_alu-mul-lmul-flags.patch (flags Z/C de MUL y LMUL como MAME; s

Says it matches, follows or was checked against MAME — 10

README.md:52 The **K054539** PCM chip is the same from-scratch module as `moomesa`'s — there is no `jt539` in jtframe, it is a private module — validated **bit-exact** again
README.md:102 The K054539 is validated **bit-exact** against a MAME-derived C++ model.
README.md:140 **Status: playable on MiSTer** — boot, video (tilemap + sprites + priority) and the K054000 collision chip all run on hardware; the color path was pixel-matched
README.md:169 The K053250 has no public RTL anywhere; it was written from the MAME model and validated pixel-exact against MAME on frame captures.
README.md:211 **Status: work in progress — boots and plays on MiSTer.** Video and audio of the attract mode, recorded on hardware, match MAME.
README.md:225 **Status: work in progress — boots and plays on MiSTer.** In simulation the video matches MAME pixel for pixel (160 attract and in-game scenes), the main CPU ru
README.md:266 **Status: work in progress — boots and plays on MiSTer.** In simulation the video matches MAME frame by frame in boot, attract and race start; the only differen
README.md:268 The sound bench (Z80 + 2× AY + K005289) matches MAME's timing.
README.md:387 El chip PCM **K054539** es el mismo módulo escrito desde cero que el de `moomesa` — no existe `jt539` en jtframe, es un módulo privado — validado **bit-exacto**
README.md:438 El K054539 está validado **bit-exacto** contra un modelo C++ derivado de MAME.

Keeps a MAME approximation — 1

README.md:266 **Status: work in progress — boots and plays on MiSTer.** In simulation the video matches MAME frame by frame in boot, attract and race start; the only differen

ffdeadang#
Lead Angle
database (builds only)

jlrh
independent database

Source not published

ffdestroyer#
Destroyer
jlrh/cidelsa-fpga @ 066b6f59
MAME compared: efo/cidelsa.cpp + 2 related file(s)
Read: 16 HDL files, 3,721 lines (all HDL files: no Quartus project found)

jlrh
independent database

Not enough evidence in the code

insufficient

Statements: 2 toward MAME

Cites MAME source — 1

README.md:48 **The MAME team** — for the emulation used as a golden reference.

Says it matches, follows or was checked against MAME — 1

README.md:15 Video is pixel-perfect against MAME (0.00% on the validated scenes) and the CPU is validated (OUT stream identical to MAME).

ffdraco#
Draco
jlrh/cidelsa-fpga @ 066b6f59
MAME compared: efo/cidelsa.cpp + 2 related file(s)
Read: 16 HDL files, 3,721 lines (all HDL files: no Quartus project found)

jlrh
independent database

Not enough evidence in the code

insufficient

Statements: 2 toward MAME

Cites MAME source — 1

README.md:48 **The MAME team** — for the emulation used as a golden reference.

Says it matches, follows or was checked against MAME — 1

README.md:15 Video is pixel-perfect against MAME (0.00% on the validated scenes) and the CPU is validated (OUT stream identical to MAME).

ffempirecity#
Empire City: 1931
jlrh/seibu-fpga @ a1712904
MAME compared: seibu/stfight.cpp + 4 related file(s)
Read: 8 HDL files, 1,908 lines (all HDL files: no Quartus project found)

jlrh
independent database

Mostly MAME

low

90%

Statements: 23 toward MAME, 1 not counted

Cites hardware references or measurements that MAME's driver also gives — 1

cores/empirecity/hdl/empirecity_video.v:238 ⭐ NIBBLES: en el HW real fg/bg/spr_clut son DOS PROMs 82s129 de 256x4 (dato en el nibble BAJO). — also in MAME: 82s129 seibu/stfight.cpp:858

Cites MAME source — 20

cores/empirecity/hdl/empirecity_mcu.v:2 Réplica EXACTA de los handlers del .cpp (stfight.cpp _68705_port_a/b/c_w, _68705_port_b_r, mcu_w): · main escribe nibble en 0xc600 -> cpu_to_mcu_data (4b) + cpu_to_mcu_empty=0.
cores/empirecity/hdl/empirecity_video.v:239 Aquí se cargan CRUDAS (= lo que hay en el zip / lo que el .mra puede entregar) y se combinan `{hi[3:0], lo[3:0]}`, igual que hace MAME al cargar (ROM_LOAD_NIB_HIGH/LOW) y que el HW real.
cores/empirecity/hdl/empirecity_video.v:241 ⚠ ANTES se cargaban las 4 CLUTs YA FUNDIDAS por MAME: **la placa NO puede recibir eso** (un .mra no combina nibbles) -> era la misma clase de bug que el cifrado del main.
cores/empirecity/hdl/empirecity_video.v:242 Ver HANDOFF §6-B. Combinación verificada byte-exacta contra los volcados de MAME (fg/bg/spr: IDENTICO).
cores/empirecity/hdl/empirecity_main.v:9 `tools/empirecity_decrypt.py` sigue siendo la REFERENCIA (verificada byte-exacta vs MAME) contra la que se validaron estas ecuaciones.
cores/empirecity/hdl/empirecity_main.v:22 Ver stfight.cpp _68705_port_c_w.
cores/empirecity/hdl/empirecity_main.v:128 Pero en MAME 0xc804 = `io_w` = SOLO contadores de moneda (stfight.cpp:436); el `set_entry(bitswap(data,7,2))` (línea 413) es `cshooter_bank_w`, de **Cross Shooter, OTRO juego** (solo en cshooter_cpu1_map @0xc801).
cores/empirecity/hdl/empirecity_main.v:130 En stfight/empcity: `set_entry(0)` en el init y NUNCA más ("It's entirely possible that this bank is never switched out", stfight.cpp:409).
cores/empirecity/hdl/empirecity_main.v:193 ⛔ NO INVERTIR: jtframe entrega cab_1p/coin/joystick **ACTIVO-BAJO**, igual que los espera MAME (IP_ACTIVE_LOW).
cores/empirecity/hdl/empirecity_main.v:235 ⚠ Ecuaciones DERIVADAS del port de MAME y **verificadas EXHAUSTIVAMENTE** contra `decrypt()` de `empirecity_decrypt.py`: 0x8000 direcciones x 256 bytes = 8.388.608 combinaciones, 0 discrepancias.
cores/empirecity/hdl/empirecity_main.v:295 MAME: rst08_tick -> vector 0xd7, armado por vb_interrupt con `m_int1_timer->adjust(attotime::from_hz(120))`.
cores/empirecity/hdl/empirecity_main.v:311 Del oráculo (MAME): E43B lo incrementa SOLO el handler de VBLANK (RST08=0xcf, 0x2CA2), y solo si E00F==0 (`2CB0: ld a,($E00F) / and a / jp nz,$2CC7` se salta el `inc (hl)` de 2CC6).
cores/empirecity/hdl/empirecity_adpcm.v:2 Réplica de stfight.cpp adpcm_int + _68705_port_c_w: · la MCU latchea la parte alta de la dir (port A) al SOLTAR el reset (port C bit2, flanco de bajada): offs = start<<9 (uint16, por eso start[6:0]<<9).
cores/empirecity/hdl/empirecity_sound.v:8 cpu2_map (del stfight.cpp): 0x0000-0x7fff ROM sonido (32 KB) 0xc000-0xc001 YM2203 #1 (r/w, addr=A0) 0xc800-0xc801 YM2203 #2 (r/w, addr=A0)
cores/empirecity/hdl/empirecity_sound.v:93 Réplica fiel de MAME fm_r/fm_w (atómicos).
cores/empirecity/hdl/empirecity_sound.v:370 ¿el Z80 llega a la rutina FM de MAME?
cores/empirecity/hdl/empirecity_sound.v:375 ¿el Z80 entra en la región de dispatch/FM de MAME (0x0273..0x05be)?
cores/empirecity/hdl/empirecity_sound.v:382 log de cada escritura del Z80 al YM (addr-reg vs data-reg) para comparar con MAME
cores/empirecity/hdl/empirecity_coinmech.v:8 · línea baja demasiado tiempo (contador > 0x05D0; ~0.355 s MEDIDOS en MAME) -> "stuck coin": 214: bclr 3,$02 ; NMI al main 216: bset 3,$02 218: bra $218 ; ⭐ BUCLE INFINITO — EL MCU NO VUELVE JAMÁS (anti-tamper del mecanismo) En MiSTer
cores/empirecity/hdl/empirecity_coinmech.v:20 VERIFICADO contra el oráculo (MAME 0.288, empcityu): acepta 0.10 s y 0.25 s; a 0.355 s se cuelga.

Shares text with the MAME driver without saying so — 3

cores/empirecity/hdl/empirecity_main.v:129 el `set_entry(bitswap(data,7,2))` (línea 413) es `cshooter_bank_w`, de **Cross Shooter, OTRO — shares text with seibu/stfight.cpp:413
cores/empirecity/hdl/empirecity_main.v:131 NUNCA más ("It's entirely possible that this bank is never switched out", stfight.cpp:409). — shares text with seibu/stfight.cpp:409
cores/empirecity/hdl/empirecity_main.v:296 armado por vb_interrupt con `m_int1_timer->adjust(attotime::from_hz(120))`. — shares text with seibu/stfight.cpp:429

ffglass#
Glass
jlrh/gaelco-fpga @ 6d22004c
MAME compared: gaelco/glass.cpp + 2 related file(s)
Read: 34 HDL files, 34,059 lines (all HDL files: no Quartus project found)

jlrh
independent database

Not enough evidence in the code

insufficient

No statements found

ffgwar#
Guevara
jlrh/snk-fpga @ 2875c4d9
MAME compared: snk/snk.cpp + 2 related file(s)
Read: 10 HDL files, 1,458 lines (all HDL files: no Quartus project found)

jlrh
independent database

Not enough evidence in the code

insufficient

No statements found

ffhotchase#
Hot Chase
jlrh/konami-fpga @ ec62e018
the repository holds builds or MRAs, no HDL

jlrh
independent database

Source not published

ffkonamigt#
Konami GT
jlrh/konami-fpga @ 863d6975
MAME compared: konami/nemesis.cpp + 3 related file(s)
Read: 23 HDL files, 6,019 lines (all HDL files: no Quartus project found)

jlrh
independent database

Not enough evidence in the code

insufficient

No statements found

ffmechatt#
Mechanized Attack
jlrh/snk-fpga @ 515eea28
MAME compared: snk/mechatt.cpp + 2 related file(s)
Read: 7 HDL files, 1,193 lines (all HDL files: no Quartus project found)

jlrh
independent database

Not enough evidence in the code

insufficient

No statements found

ffmegaphx#
Hammer Boy, Mega Phoenix, Little Robin
jlrh/inder-dinamic-fpga @ 44efc758
the repository holds builds or MRAs, no HDL

jlrh
independent database

Source not published

ffmoomesa#
Wild West C.O.W.-Boys of Moo Mesa
jlrh/konami-fpga @ e1a8a625
MAME compared: konami/moo.cpp + 15 related file(s)
Read: 21 HDL files, 6,013 lines (all HDL files: no Quartus project found)

jlrh
independent database

Mostly MAME

low

47%

Statements: 58 toward MAME

Cites MAME source — 53

cores/moomesa/hdl/cowboys_sound.v:121 SONDA (solo sim): captura las escrituras/lecturas del Z80 al k054539 para compararlas con la traza REAL de MAME (debug/k539_trace.txt).
cores/moomesa/hdl/cowboys_sound.v:122 Confirma si el Z80 del core programa el chip IGUAL que MAME (bug interno) o DISTINTO (bug aguas arriba).
cores/moomesa/hdl/cowboys_sound.v:124 reg = A-0xe000 (0x000-0x22f), formato identico al tap de MAME.
cores/moomesa/hdl/cowboys_video.v:179 moomesa reparte 256 slots de sprite con paso 0x100 sobre los 64 kB de 0x190000 (moo.cpp:416 `object_dma`: `src += 0x80` words, y solo las 8 primeras words de cada slot importan).
cores/moomesa/hdl/cowboys_video.v:193 MAME no ordena en el DMA, ordena AL DIBUJAR (`k053246_k053247_k055673.cpp:324-374`, `sortedlist` por el byte de prioridad); `k053246_dma` hace esa misma ordenacion en el DMA via LUT (`dma_bufa <= {sort_24x,3'd0}`) = como el chip real.
cores/moomesa/hdl/cowboys_video.v:263 MAME no tiene la carrera porque `moo_interrupt` muestrea `k053246_is_irq_enabled()` en el INSTANTE del vblank, antes de la ISR.
cores/moomesa/hdl/cowboys_colmix.v:98 Ver HANDOFF sesion 7 §D (ya estaba anotado como "diferencia real contra MAME -> vigilar") y sesion 10.
cores/moomesa/hdl/cowboys_colmix.v:108 Un tile sin marcar sale OPACO aunque alpha_lv sea 0 — antes se suprimía la capa frontal entera y eso borraba el cráter del attract (1200/1350), que es el bug de MAME.
cores/moomesa/hdl/cowboys_colmix.v:112 053251 wiring — mapeo REAL de moomesa (moo.cpp screen_update + k051_palette_index del golden): SPRITES = CI0 (colorbase get_palette_index(CI0)=idx0; prioridad DINAMICA por sprite via pri0, porque EXTEN[0]=0 -> el K053251 usa el input pri0).
cores/moomesa/hdl/cowboys_colmix.v:154 ⭐⭐ AQUI SE ARREGLA UN BUG QUE MAME NUNCA RESOLVIO (sesion 24).
cores/moomesa/hdl/cowboys_colmix.v:156 MAME (moo.cpp:377-385) decide la mezcla POR CAPA y se inventa el enable: m_alpha_enabled = ...
cores/moomesa/hdl/cowboys_colmix.v:157 & K338_CTL_MIXPRI; // DUMMY <- lo admite el propio MAME if (alpha > 0) tilemap_draw(layer[2], ...); // con alpha==0 NO DIBUJA la capa entera Con k38[13]=0 (alpha_lv=0) eso BORRA la capa frontal completa.
cores/moomesa/hdl/cowboys_colmix.v:159 En 1200/1350 esa capa lleva 6841 px: EL CRATER del que sale la mesa -> en MAME la montaña sale flotando.
cores/moomesa/hdl/cowboys_colmix.v:160 Bug conocido y no resuelto (moo.cpp:88-113 "needs a correct enable/disable bit in Moo (INTRO GFX MISSING and fog blocking view)"; moomesa lleva MACHINE_IMPERFECT_GRAPHICS).
cores/moomesa/hdl/cowboys_colmix.v:162 MAME buscaba "un bit de control" y no lo hallaba.
cores/moomesa/hdl/cowboys_colmix.v:164 ✅ EL BIT NO ESTA EN NINGUN REGISTRO: ESTA EN EL ATRIBUTO DEL TILE, y MAME lo TIRA.
cores/moomesa/hdl/cowboys_colmix.v:165 moo.cpp:290 tile_callback: color = m_layer_colorbase[layer] | (color >> 2 & 0x0f); El campo de color son 6 bits (colpre = attr[7:2]); MAME usa colpre[5:2] y DESCARTA colpre[1:0].
cores/moomesa/hdl/cowboys_colmix.v:167 MEDIDO: colpre[0] (= attr[2]) es el flag de mezcla POR TILE: attr[2]=0 -> tile OPACO (el blender no le aplica) attr[2]=1 -> tile MEZCLADO al nivel alpha_lv Con alpha_lv=0 UNA sola regla da las dos conductas que parecian contradictorias: * c
cores/moomesa/hdl/cowboys_colmix.v:177 Evidencia: placa real (sources/crater-captura.png) + `tools/cowboys_tilebits.py` (histograma de los 2 bits descartados) + regresion golden en 15 escenas: 13 IDENTICAS a MAME, solo 1200/1350 cambian.
cores/moomesa/hdl/cowboys_colmix.v:179 ⚠️ En 1200 y 1350 golden y RTL DIVERGEN DE MAME a proposito (~6400 px): ahi el oraculo es la PLACA, no MAME.
cores/moomesa/hdl/cowboys_colmix.v:180 NO lo "arregles" volviendo a casar con MAME.
cores/moomesa/hdl/cowboys_colmix.v:183 5b->8b (=set_alpha_level de MAME)
cores/moomesa/hdl/cowboys_colmix.v:213 El HW no hace eso: k054338.cpp:88-93 -> d = m_regs[K338_REG_SHAD1R + i] & 0x1ff; if (d >= 0x100) d -= 0x200; palette.set_shadow_dRGB32(tabla, dR, dG, dB, noclip) Es un DELTA CON SIGNO (9 bits) que se SUMA a cada canal y se satura.
cores/moomesa/hdl/cowboys_colmix.v:225 Si alguna escena lo pone a 1, hay que revisar (MAME lo pasa a set_shadow_dRGB32).
cores/moomesa/hdl/cowboys_colmix.v:327 Réplica del compositing painter's de moo.cpp screen_update.
cores/moomesa/hdl/cowboys_colmix.v:389 Sin este termino, con alpha_lv=0 la capa frontal entera desaparecia (= el bug del crater de MAME).
cores/moomesa/hdl/cowboys_main.v:19 FASE 1 (sesion 5, 2026-07-16): reescrito al mapa REAL de moomesa (moo.cpp moo_prot_state::moo_map).
cores/moomesa/hdl/cowboys_main.v:21 Referencias: research/moo.cpp lineas 520-587 (moo_map), 393-482 (control2/IRQ), 663-701 (puertos).
cores/moomesa/hdl/cowboys_main.v:92 0x0de000 (moo.cpp control2_w)
cores/moomesa/hdl/cowboys_main.v:189 Evidencia (no suposicion): · `jtframe_dip.v:87` -> `assign dip_test = ~status[10] & game_test; // assumes it is always active low` · `jtframe_inputs.v:184` -> el puerto interno se llama **`coin_n`** (_n = activo bajo) · el core hermano sims
cores/moomesa/hdl/cowboys_main.v:202 defaults (DIP switches hardcoded to MAME defaults: 4 players, stereo, common coin — TODO wire dipsw)
cores/moomesa/hdl/cowboys_main.v:206 IN0 (moo.cpp:664-671): bit0-3 COIN1-4, bit4-7 SERVICE1-4 — todos ACTIVE_LOW
cores/moomesa/hdl/cowboys_main.v:208 IN1 (moo.cpp:674-687): bit0 eep_do, bit1 eep_rdy, bit2 unk(1), bit3 SERVICE (ACTIVE_LOW), bit4 SndOut(0=Stereo), bit5 CoinMech(1=Common), bit7:6 Players(10=4) — defaults de MAME.
cores/moomesa/hdl/cowboys_main.v:225 ---------------- control2 (0x0de000) + EEPROM ---------------- moo.cpp control2_w: bit0 eep di, bit1 eep cs, bit2 eep clk, bit5 IRQ5 en, bit8 objcha (spr ROM read), bit10 watchdog, bit11 IRQ4 en.
cores/moomesa/hdl/cowboys_main.v:280 ================= moo_prot (053990): HLE del blitter — FASE 4 ================= Spec EXACTA = research/moo.cpp:520-545 (moo_prot_state::moo_prot_w), autoridad validada.
cores/moomesa/hdl/cowboys_main.v:283 Escribir el indice 0xc DISPARA: src1={protram[1][7:0],protram[0]} src2={protram[3][7:0],protram[2]} dst ={protram[5][7:0],protram[4]} length=protram[0xf] while(length--) { *dst = *src1 + 2 * *src2; src1+=2; src2+=2; dst+=2; } (protram[8..
cores/moomesa/hdl/cowboys_main.v:312 direccion de byte de 24 bits (MAME) -> direccion de WORD [23:1]; +=2 bytes == +1 word
cores/moomesa/hdl/cowboys_main.v:330 El POST usa src1=paleta(0x1c0000), src2=work RAM(0x180000), dst=work RAM(0x181000); se admite ROM por generalidad (MAME usa space.read_word, todo el mapa).
cores/moomesa/hdl/cowboys_main.v:364 length==0 -> MAME no hace NADA (while(length))
cores/moomesa/hdl/cowboys_main.v:385 res = a + 2*b. MAME lo calcula en 32 bits y write_word TRUNCA a 16 -> el desbordamiento de 16 bits es el comportamiento correcto, no un bug.
cores/moomesa/hdl/cowboys_obj.v:161 As the object layer should not be drawn directly over a shadow, it looks like the logic must be like this - in the LUT the shadow bits are set for the whole sprite - when drawing the sprite, if the shadow is enabled and the sprite pen is 15
cores/moomesa/hdl/cowboys_k056832.v:60 ⭐ SESION 18: el 456 provisional daba 17.54kHz/66.5Hz en placa (real moo.cpp:82-83 = 15.20kHz/59.19Hz) -> refresh ~12% rapido -> JUDDER de scroll (66.5 vs 60 de la tele) y quiza tiles corruptos (poco hblank para el fetch de los line buffers)
cores/moomesa/hdl/cowboys_k056832.v:73 El RGB compuesto (tiles Y sprites, que pasan ambos por colmix -> retardo UNIFORME) sale 3 px tarde; sin compensar, jtframe muestrea desde H=0 y los 3 primeros px activos son basura pre-activo (COLUMNA NEGRA a la izq + todo corrido 3 px a la
cores/moomesa/hdl/cowboys_k056832.v:286 MAME (moo.cpp:290 tile_callback) usa SOLO colpre[5:2] como color y **DESCARTA colpre[1:0]**.
cores/moomesa/hdl/cowboys_k056832.v:287 Medido: colpre[0] (= attr[2]) es el flag "este tile se mezcla" del K054338: attr[2]=0 -> tile OPACO, el blender NO le aplica attr[2]=1 -> tile MEZCLADO al nivel alpha_lv Con alpha_lv=0 eso da las dos conductas que parecian contradictorias,
cores/moomesa/hdl/cowboys_k056832.v:295 MAME no podia hallarlo mirando registros.
cores/moomesa/hdl/k054539.v:3 Escrito de cero contra el golden de MAME (k054539.cpp) y la RE de silicio de Furrtek (github.com/furrtek/SiliconRE/Konami/054539).
cores/moomesa/hdl/k054539.v:57 Mapeo offsets MAME -> modulo: canales 0x0xx igual; control 0x2xx -> 0x1xx active=0x22c->0x12c ctrl=0x22f->0x12f keyon=0x214->0x114 keyoff=0x215->0x115 canal ch base1=0x20*ch (igual) base2=0x200+2*ch -> 0x100+2*ch CPU es el UNICO que es
cores/moomesa/hdl/k054539.v:92 canales sonando (MAME 0x22c)
cores/moomesa/hdl/k054539.v:119 acumuladores en Q16 (como MAME: suma en full-precision, >>16 UNA vez al final)
cores/moomesa/hdl/k054539.v:123 Reverb — linea de retardo mono (MAME k054539.cpp).
cores/moomesa/hdl/k054539.v:163 --- Reverb: parametros del canal en curso (MAME, modo FIXED) --- rdelta = ({base1[7],base1[6]} >> 3); rdelta = (rdelta+revpos)&0x3fff; widx = (rdelta + revpos) & 0x1fff; (revpos sumado DOS veces: quirk exacto de MAME)
cores/moomesa/hdl/k054539.v:415 Q16 -> entero (>>16), clamp del PCM (como MAME), y trim de PCM en vivo

Shares text with the MAME driver without saying so — 5

cores/moomesa/hdl/cowboys_colmix.v:161 (moo.cpp:88-113 "needs a correct enable/disable bit in Moo (INTRO GFX MISSING and fog blocking — shares text with konami/moo.cpp:91
cores/moomesa/hdl/cowboys_colmix.v:165 moo.cpp:290 tile_callback: color = m_layer_colorbase[layer] | (color >> 2 & 0x0f); — shares text with konami/moo.cpp:288
cores/moomesa/hdl/cowboys_colmix.v:214 k054338.cpp:88-93 -> d = m_regs[K338_REG_SHAD1R + i] & 0x1ff; if (d >= 0x100) d -= 0x200; — shares text with konami/k054338.cpp:90
cores/moomesa/hdl/cowboys_main.v:281 Spec EXACTA = research/moo.cpp:520-545 (moo_prot_state::moo_prot_w), autoridad validada. — shares text with konami/moo.cpp:520
cores/moomesa/hdl/cowboys_main.v:286 while(length--) { *dst = *src1 + 2 * *src2; src1+=2; src2+=2; dst+=2; } — shares text with konami/moo.cpp:539

ffmtlchamp#
Martial Champion
jlrh/konami-fpga @ ec3ffcef
MAME compared: konami/mystwarr.cpp + 19 related file(s)
Read: 19 HDL files, 4,822 lines (all HDL files: no Quartus project found)

jlrh
independent database

Not enough evidence in the code

insufficient

No statements found

ffmystwarr#
Mystic Warriors
jlrh/konami-fpga @ 8a0dff7f
the repository holds builds or MRAs, no HDL

jlrh
independent database

Source not published

ffopwolf#
Operation Wolf
jlrh/taito-fpga @ c3956814
MAME compared: taito/opwolf.cpp + 11 related file(s)
Read: 16 HDL files, 4,206 lines (all HDL files: no Quartus project found)

jlrh
independent database

Mostly MAME

low

94%

Statements: 1 toward hardware, 61 toward MAME

Cites hardware documentation that MAME's driver does not — 1

cores/opwolf/hdl/opwolf_gun.v:20 En el PCB real (esquematicos hoja 6-6) unas cadenas de 74LS161 cuentan el barrido (H1-H9, V1-V9) y, cuando el sensor optico ve el haz, unos 74LS373 los CONGELAN.

Cites MAME source — 58

cores/opwolf/hdl/opwolf_pc060.v:19 Designed according to MAME's description: it lacks the mute output for the amp
cores/opwolf/hdl/upd7810.v:25 3) Las tablas de LONGITUD y DECODIFICACION estan GENERADAS desde las fuentes de MAME (tools/upd7810_gen.py).
cores/opwolf/hdl/upd7810.v:34 El testbench vuelca el PC de CADA instruccion y se DIFFEA contra la traza real del depurador de MAME (1.218.766 instrucciones).
cores/opwolf/hdl/upd7810.v:79 MAME: al leer un
cores/opwolf/hdl/upd7810.v:85 Ver upd7810.cpp RP()/device_reset.
cores/opwolf/hdl/upd7810.v:109 El uPD7810 gasta 'cycles' ciclos-maquina por instruccion (tabla de MAME), y CADA ciclo-maquina son 3 periodos de reloj (upd7810.h: execute_cycles_to_clocks = cycles*3).
cores/opwolf/hdl/upd7810.v:123 (MAME: 'PAIR ea = m_va' -> ea = {V, offset}.) Funcionaba de casualidad porque el arranque hace MVI V,$FF; con otro V habria escrito en la pagina equivocada.
cores/opwolf/hdl/upd7810.v:166 Codigos (derivados de la tabla de MAME, no supuestos): 1=AN 2=XR 3=OR 5=GT 7=LT 8=ADD 9=ON 10=ADC 11=OFF 12=SUB 13=NE 14=SBB 15=EQ Implementarla asi tumba DECENAS de instrucciones de golpe en vez de una a una.
cores/opwolf/hdl/upd7810.v:173 Ajuste del DAA, traducido de MAME (upd7810_opcodes.cpp: DAA)
cores/opwolf/hdl/upd7810.v:191 Flags de una RESTA (ZHC_SUB de MAME): las comparaciones EQI/NEI/LTI las usan.
cores/opwolf/hdl/upd7810.v:219 reset: todos los puertos a ENTRADA (MAME device_reset)
cores/opwolf/hdl/upd7810.v:233 La IRQ NO cuenta como instruccion (MAME no le cobra ciclos): no toca 'used'/'want'.
cores/opwolf/hdl/upd7810.v:239 MAME: SP--; WM(SP,PSW); SP--; WM(SP,PCH); SP--; WM(SP,PCL); PSW &= ~(SK|L0|L1); PC = vector;
cores/opwolf/hdl/upd7810.v:357 (MAME: 48 35 = RLL_A, 48 36 = RLL_B, 48 37 = RLL_C.)
cores/opwolf/hdl/upd7810.v:378 MAME RP(): bits de ENTRADA (modo=1) devuelven el pin; bits de SALIDA (modo=0) devuelven el latch de salida.
cores/opwolf/hdl/upd7810.v:385 CR0 (A/D): en la tabla del 7810 de MAME es 'illegal2' = NO-OP.
cores/opwolf/hdl/upd7810.v:515 (MAME: SKIP_CY y luego restaura CY.) Sin esto el bucle de espera del arranque NO TERMINA JAMAS: fue la primera divergencia contra la traza golden (instruccion 58).
cores/opwolf/hdl/upd7810.v:542 Patron sacado de la tabla de MAME: opcodes 0x_6 / 0x_7 con bit7=0
cores/opwolf/hdl/upd7810.v:598 destino = {0x08 + (op & 7), imm} (MAME: w.b.h = 0x08 + (OP & 0x07))
cores/opwolf/hdl/upd7810.v:609 BLOCK: copia (HL)->(DE) byte a byte, DE++/HL++/C--, y se REPITE ella misma (MAME hace PC-- hasta que C pasa de 0 a 0xFF).
cores/opwolf/hdl/upd7810.v:627 MAME: el ajuste depende de HC, del nibble bajo, del alto y del CY.
cores/opwolf/hdl/opwolf_tilemap.v:67 OFFSETS medidos contra el golden (validado 0.00% vs MAME) con la escena 1200: con los de rastan (hrdout -5, vf +8) la imagen salia 5 px a la IZQUIERDA y 1 linea ABAJO.
cores/opwolf/hdl/opwolf_snd.v:19 SONIDO DE OPERATION WOLF (opwolf.cpp) Z80 @ 4 MHz (8 MHz XTAL / 2) | YM2151 @ 4 MHz | 2x MSM5205 @ 384 kHz (S48_4B -> 8 kHz) PC060HA (CIU) para hablar con el 68000 | 2x TC0060DCA (volumen digital)
cores/opwolf/hdl/opwolf_snd.v:96 En MAME lo pone el port write del YM2151 (mask 0x03), que son sus pines CT1/CT2 -> aqui salen del jt51.
cores/opwolf/hdl/opwolf_snd.v:137 MAME arranca con atten_table[0xff]
cores/opwolf/hdl/jtopwolf_game.v:120 Polaridad (opwolf.cpp, INPUT_PORTS opwolf): IN0: bit0 COIN1, bit1 COIN2 -> ACTIVOS A NIVEL ALTO (jtframe los da activos BAJOS -> invertir) bits 2-7 sin uso, ACTIVOS A NIVEL BAJO -> se leen como 1 IN1: bit0 BUTTON1(gatillo), bit1 BUTTON2(gr
cores/opwolf/hdl/jtopwolf_game.v:136 ⚠ TOQUE CORTO de moneda (10 frames): un mantenido largo tripa el "COIN ERROR" del C-Chip (bug reproducido; MAME acepta 40 frames).
cores/opwolf/hdl/opwolf_gun.v:25 Asi que en vez de sintetizar el haz, se calcula el valor que el juego espera leer, que es el que MAME reproduce (opwolf.cpp: gun_x_r / gun_y_r):
cores/opwolf/hdl/opwolf_gun.v:35 ⚠ Los OFFSETS DEPENDEN DEL SET (opwolf.cpp, init_*): opwolfb : XOFFS = -2, YOFFS = 17 opwolfp : XOFFS = 5, YOFFS = 30 opwolf : se leen de la propia ROM (0x3ffb0 / 0x3ffae) Ahora mismo se fijan por parametro y el core se compila con los de
cores/opwolf/hdl/opwolf_dca.v:20 De MAME (mame-src/taito/tc0060dca.cpp, "volume curve measured by Stephen Leary"):
cores/opwolf/hdl/opwolf_cchip78.v:12 MAPA (de mame-src/taito/taitocchip.cpp)
cores/opwolf/hdl/opwolf_cchip78.v:172 (igual que en MAME)
cores/opwolf/hdl/opwolf_cchip78.v:178 MAME ejecuta ~6645 instr/frame; si el RTL hace muchas mas, la CPU va demasiado rapida y el rebote de entradas cuenta de mas.
cores/opwolf/hdl/opwolf_cchip78.v:190 MAME: 1 pulso por moneda.
cores/opwolf/hdl/opwolf_adpcm.v:21 BANCO DE REGISTROS (opwolf.cpp: adpcm_w<N>).
cores/opwolf/hdl/opwolf_adpcm.v:30 SECUENCIA (opwolf.cpp: msm5205_vck_w<N>) - dos VCK por byte: VCK impar : lee el byte en pos, entrega el nibble ALTO, pos++ VCK par : entrega el nibble BAJO; si pos == end -> PARA (reset del MSM) El contador {pos, nib} incrementa en cada V
cores/opwolf/hdl/opwolf_adpcm.v:103 el volumen se captura EN EL DISPARO (como MAME)
cores/opwolf/hdl/opwolf_adpcm.v:182 ok = 0 -> el byte NO habia llegado: nibble BASURA (el de la muestra anterior) nib = 1 -> se colo el nibble BAJO primero (MAME entrega el ALTO): orden invertido
cores/opwolf/hdl/opwolf_colmix.v:57 PRIORIDAD (delta vs rastan) — opwolf.cpp: colpri_cb() -> pri_mask = 0xfc "sprites under top bg layer": el PC080SN dibuja la capa 0 (BG, opaca, prio 1) y la capa 1 (FG, prio 2); el PC090OJ dibuja con prio_transpen(pri_mask=0xfc) -> el sprite
cores/opwolf/hdl/opwolf_colmix.v:60 La regla la cablea el PAL16L8 de la posición 19 (B20-09, sin dumpear), así que sale de MAME/golden, no del esquemático (GAPS-REPORT.md §G-11).
cores/opwolf/hdl/opwolf_colmix.v:102 FORMATO DE PALETA (opwolf.cpp:869): palette_device::xRGBRRRRGGGGBBBB_bit0
cores/opwolf/hdl/opwolf_main.v:163 Mapa de Operation Wolf (mame-src/taito/opwolf.cpp -> opwolf_map).
cores/opwolf/hdl/opwolf_main.v:210 En opwolf van por el C-Chip y MAME los declara IPT_UNUSED ACTIVOS A NIVEL BAJO -> se leen como "no pulsado" (1).
cores/opwolf/hdl/opwolf_main.v:211 En opwolfp (sin C-Chip) SI se usan y el mapeo es este (opwolf.cpp, INPUT_PORTS opwolfp).
cores/opwolf/hdl/opwolf_main.v:257 spritectrl_w (0x380000) — de opwolf.cpp: bit 0-1 = transistores MOTOR1/MOTOR2 (retroceso) bit 2 = reset del C-Chip y del PC050CM (activo bajo) bit 4 = LATCH: habilita latchear la posición de la pistola en vblank bit 5-7 = banco de palet
cores/opwolf/hdl/opwolf_main.v:275 ⚠ bit2 = "reset C-Chip + PC050CM" (activo bajo) EN EL PCB, pero MAME (que emula el uPD78C11 REAL) NUNCA resetea el C-Chip desde aqui: spritectrl_w solo toca sprite_ctrl (paleta/prioridad) y el motor (opwolf.cpp:634-651).
cores/opwolf/hdl/opwolf_main.v:279 Aplicarlo (como haciamos) reseteaba el C-Chip en cada pulso del 68000: - con cycle-timing a velocidad real -> bucle de reset -> NO ARRANCA (patron test, §0-BIS) - al disparar/pulsar -> se pierde el debounce del firmware -> "coge varias puls
cores/opwolf/hdl/opwolf_main.v:286 Lectura en 0x380000/2: A[1]=0 -> DSWA, A[1]=1 -> DSWB ⚠ Los inputs de jugador (monedas, gatillo, granada, start, service, tilt) NO están en el bus del 68000: entran por los puertos PB/PC del C-Chip (opwolf.cpp, in_pb/in_pc_callback).
cores/opwolf/hdl/opwolf_main.v:294 MAME lo IGNORA; el RTL lo aplica.
cores/opwolf/hdl/opwolf_main.v:318 El 68000 real va a 8 MHz (16 MHz XTAL / 2, opwolf.cpp:840).
cores/opwolf/hdl/opwolf_scr.v:19 This module implements the pc080sn logic The original clock was 26.686MHz/2 = 13.343MHz Using 48MHz as basis, the ratio is 1073/3860 Measurements on Operation Wolf reported in MAME VSync - 60.0551Hz HSync - 15.6742kHz
cores/opwolf/hdl/opwolf_scr.v:141 Derivado de las medidas del PCB (cabecera de opwolf.cpp): VSync 60.0551 Hz, HSync 15.6742 kHz, pixel clock = 26.68558/4 = 6.6714 MHz:
cores/opwolf/hdl/opwolf_scr.v:145 Área visible (MAME): 320x240, visarea(0..319, 8..247).
cores/opwolf/hdl/opwolf_scr.v:146 ⚠ FASE 2: confirmar HB/VS/HS contra el golden y las capturas de MAME antes de dar esto por bueno.
cores/opwolf/hdl/opwolf_cchip.v:27 INTERFAZ (opwolf.cpp: opwolfb_map + opwolfb_sub_z80_map) Lado 68000: 0x0f0000-0x0f0fff -> RAM compartida de 2 KB.
cores/opwolf/hdl/opwolf_cchip.v:29 En MAME es literalmente `m_cchip_ram[offset]` con offset = indice de PALABRA -> aqui el indice es A[11:1].
cores/opwolf/hdl/opwolf_obj.v:73 MAME recorta los sprites al area visible (0..239): un sprite fuera de ella simplemente NO se dibuja.
cores/opwolf/hdl/opwolf_obj.v:113 Palabras del sprite en la RAM (igual que pc090oj.cpp): 0=attr 1=ypos 2=code 3=xpos.

Shares text with the MAME driver without saying so — 3

cores/opwolf/hdl/opwolf_dca.v:20 De MAME (mame-src/taito/tc0060dca.cpp, "volume curve measured by Stephen Leary"): — shares text with taito/tc0060dca.cpp:6
cores/opwolf/hdl/opwolf_dca.v:22 atten[x] = 1.0 / (1.0 + exp(-10 * ((x / 256.0) - 0.6))) x = 0..255 — shares text with taito/tc0060dca.cpp:43
cores/opwolf/hdl/opwolf_main.v:278 "usually 0x4, changes when you fire" -> en juego el bit2 se queda a 1. — shares text with taito/opwolf.cpp:393

ffoverdriv#
Over Drive
jlrh/konami-fpga @ ed7af630
the repository holds builds or MRAs, no HDL

jlrh
independent database

Source not published

ffshadfrce#
Shadow Force - Henshin Ninja
jlrh/technos-fpga @ b33735ff
MAME compared: technos/shadfrce.cpp
Read: 5 HDL files, 1,190 lines (all HDL files: no Quartus project found)

jlrh
independent database

Not enough evidence in the code

insufficient

No statements found

ffsquash#
Squash
jlrh/gaelco-fpga @ 9b7371ae
MAME compared: gaelco/gaelco.cpp + 4 related file(s)
Read: 28 HDL files, 7,827 lines (all HDL files: no Quartus project found)

jlrh
independent database

Not enough evidence in the code

insufficient

No statements found

ffssriders#
Sunset Riders
jlrh/konami-fpga @ 54181488
MAME compared: konami/tmnt2.cpp + 13 related file(s)
Read: 12 HDL files, 3,464 lines (all HDL files: no Quartus project found)

jlrh
independent database

Not enough evidence in the code

insufficient

No statements found

ffthoop#
Thunder Hoop
jlrh/gaelco-fpga @ d545a12e
MAME compared: gaelco/gaelco.cpp + 4 related file(s)
Read: 28 HDL files, 7,678 lines (all HDL files: no Quartus project found)

jlrh
independent database

Not enough evidence in the code

insufficient

No statements found

ffthoop2#
TH Strikes Back
jlrh/gaelco-fpga @ 94ee36d8
MAME compared: gaelco/thoop2.cpp + 2 related file(s)
Read: 30 HDL files, 33,555 lines (all HDL files: no Quartus project found)

jlrh
independent database

Not enough evidence in the code

insufficient

No statements found

ffwecleman#
WEC Le Mans 24
jlrh/konami-fpga @ 900b0637
the repository holds builds or MRAs, no HDL

jlrh
independent database

Source not published

ffwrally#
World Rally Championship
jlrh/gaelco-fpga @ 0b7f9e5d
MAME compared: gaelco/wrally.cpp + 6 related file(s)
Read: 34 HDL files, 34,536 lines (all HDL files: no Quartus project found)

jlrh
independent database

Not enough evidence in the code

insufficient

No statements found

ffwrally2#
World Rally 2: Twin Racing
jlrh/gaelco-fpga @ 1ee2ee94
MAME compared: gaelco/gaelco2.cpp + 5 related file(s)
Read: 21 HDL files, 33,228 lines (all HDL files: no Quartus project found)

jlrh
independent database

Not enough evidence in the code

insufficient

No statements found

ffxexex#
Xexex
jlrh/konami-fpga @ d87eb6d5
MAME compared: konami/xexex.cpp + 15 related file(s)
Read: 23 HDL files, 5,507 lines (all HDL files: no Quartus project found)

jlrh
independent database

Not enough evidence in the code

insufficient

No statements found

mystston#
Mysterious Stones: Dr. John's Adventure
bmo00/arcfpga-cores @ da412d49
MAME compared: technos/mystston.cpp
Read: 7 HDL files, 1,676 lines (all HDL files: no Quartus project found)

arcfpga
independent database

Mostly MAME

medium

100%

Statements: 1 toward hardware, 34 toward MAME

Ships hardware documentation files — 1

cores/mystston/sch/schematics.pdf

Cites MAME source — 21

cores/mystston/hdl/mystston_scroll.v:2 mystston_scroll — Background tilemap renderer for Mysterious Stones Verified against mystston.cpp's get_bg_tile_info()/video_start() (TILEMAP_SCAN_COLS_FLIP_X, 16x16 tiles, 16 cols x 32 rows virtual map) and the spritelayout gfx descriptor
cores/mystston/hdl/mystston_scroll.v:18 No transparency: mystston.cpp never calls set_transparent_pen() on m_bg_tilemap (only on m_fg_tilemap), so every background pixel is opaque.
cores/mystston/hdl/mystston_sound.v:2 mystston_sound — Sound subsystem for Mysterious Stones (Technos 1984) Two AY-3-8910 driven through a shared BC1/BDIR bus (mystston.cpp's ay8910_select_w): bits 4/5 = BC1/BDIR for chip 0, bits 6/7 = BC1/BDIR for chip 1.
cores/mystston/hdl/mystston_sound.v:5 jt49's real interface (modules/jt49/hdl/jt49.v — cfg/files.yaml's bare `jt49:` key resolves here, not modules/jt12/jt49/) is a plain decoded register-file bus (addr/cs_n/wr_n/din, no bc1/bdir pins at all), so this module translates the BC1/
cores/mystston/hdl/mystston_sound.v:33 One-cycle-delayed copy of snd_sel to detect BDIR falling edges and read what BC1 was during the preceding BDIR-high phase, exactly like mystston.cpp's ay8910_select_w compares *m_ay8910_select (old) to data (new, i.e. today's snd_sel).
cores/mystston/hdl/mystston_main.v:23 vcnt: video timing from mystston_video.v — V counter, 0 = start of visible area (MAME's raw vpos shifted by -8) so JTFRAME's non-wrapping vtimer model can express the driver's wrap-around blanking window; see mystston_video.v's jtframe_vtim
cores/mystston/hdl/mystston_main.v:120 Address decode — matches mystston.cpp's main_map() exactly, including the mirror masks on the I/O register block (mirror(0x1f8f) ignores address bits [12:7] and [3:0]; paletteram's mirror(0x1f80) ignores only [12:7]).
cores/mystston/hdl/mystston_main.v:173 Input read mux (IN0 @ 0x2000, IN1 @ 0x2010 — mystston.cpp INPUT_PORTS_START)
cores/mystston/hdl/mystston_main.v:179 in0/in1 bit order (LSB first): right,left,up,down,button1,button2, coin1/cab2,coin2/cab1 (mystston.cpp IN0/IN1: bit0=right,1=left,2=up, 3=down,4=btn1,5=btn2,6/7=coin or cabinet start).
cores/mystston/hdl/mystston_main.v:242 dipsw[13] is the Flip Screen DIP (DSW1 bit5); see doc/IMPLEMENTATION.md's Implementation log (Video) for why it's inverted here relative to mystston.cpp's own flip formula.
cores/mystston/hdl/mystston_main.v:248 Scanline interrupt — mystston.cpp: interrupt every 16 scanlines starting at vpos=8 (FIRST_INT_VPOS), wrapping at VBSTART=248, 16 interrupts/frame.
cores/mystston/hdl/mystston_main.v:250 mystston_video.v's vtimer is configured so its own V counter is MAME's vpos shifted by -8 (V=0 is vpos=8, the first visible line) — in that numbering the interrupt scanlines are V=0,16,32,...,240 (240 = vpos 248, the entry into vblank), i.e
cores/mystston/hdl/mystston_main.v:254 irq_clear_w (0x2010 write) clears the CPU's IRQ line (line 0 in MAME, i.e. the CPU's single maskable IRQ input).
cores/mystston/hdl/mystston_main.v:283 Coin NMI — mystston.cpp's coin_inserted(): NMI is ASSERTED on the falling edge of the raw (active-low) coin switch signal, i.e. the instant the switch is pressed, and stays asserted (a level, not a latched one-shot) until the switch is rele
cores/mystston/hdl/mystston_video.v:7 Video timing: mystston.cpp's screen.set_raw(PIXEL_CLOCK,384,0,256,272,8,248) gives a WRAPAROUND vertical blanking window (blank=[248,271]+[0,7], visible =[8,247]) — jtframe_vtimer supports this natively (its LVBL update is a case-match on v
cores/mystston/hdl/mystston_video.v:83 Scanline counter for main CPU IRQ generation — see mystston_main.v's port comment: 0 = start of visible area (MAME's vpos shifted by -8)
cores/mystston/hdl/mystston_video.v:93 HS_START/HS_END come straight from mystston.cpp's screen.set_raw(PIXEL_CLOCK,384,0,256,272,8,248) with no hand-tuned shift: CRT horizontal centering is a jtframe_resync/OSD H-Offset concern (arcfpga-frame/doc/video.md, "CRT Adjustments"), n
cores/mystston/hdl/mystston_video.v:186 Verified against mystston.cpp's get_fg_tile_info()/ video_start(): TILEMAP_SCAN_COLS_FLIP_X, 32 cols x 32 rows, no scroll, no per-tile Y-flip quirk (unlike bg).
cores/mystston/hdl/mystston_video.v:188 gfx_8x8x3_planar layout: row R col C -> byte (plane*0x4000 + code*8 + R), bit(7-C) (see emu/video/ generic.cpp's gfx_8x8x3_planar; only one byte per plane per row, unlike the 16x16 sprite/bg layout's two halves).
cores/mystston/hdl/mystston_obj.v:2 mystston_obj — Sprite renderer for Mysterious Stones (Technos 1984) Verified against mystston.cpp's draw_sprites() and the spritelayout gfx descriptor: static const gfx_layout spritelayout = { 16,16, RGN_FRAC(1,3), 3, { RGN_FRAC(2,3), RGN_F
cores/mystston/hdl/jtmystston_game.v:43 page_select = video_control[2]; fg_color = {video_control[0], video_control[1]} (mystston.cpp's get_fg_tile_info(): color = ((vc&1)<<1)|((vc&2)>>1), i.e. the two bits swapped, not a plain slice).

Says it matches, follows or was checked against MAME — 4

cores/mystston/hdl/mystston_colmix.v:2 mystston_colmix — Color mixer for Mysterious Stones (Technos 1984) Verified against mystston.cpp's set_palette()/screen_update() and the GFXDECODE_START palette bases: sprites: GFXDECODE_ENTRY("fgtiles_sprites",0,spritelayout,0*8,2) -> base
cores/mystston/hdl/mystston_main.v:2 mystston_main — Main CPU subsystem for Mysterious Stones (Technos 1984) Verified against src/mame/technos/mystston.cpp (M6502(config,...,MASTER_CLOCK/8), main_map(), video_control_w(), ay8910_select_w(), on_scanline_interrupt(), irq_clear_w
cores/mystston/hdl/mystston_main.v:19 LVBL is already active-high-during-active-display, matching MAME's IP_ACTIVE_LOW inversion, so no extra inversion is needed here.
cores/mystston/hdl/mystston_video.v:137 Sprite/bg/fg tile lookups key off the screen's absolute 256-line raster position (visible range 8..247), matching how MAME's own tilemaps are drawn — not a tilemap-local 0..239 index.

Shares text with the MAME driver without saying so — 9

cores/mystston/hdl/mystston_colmix.v:5 sprites: GFXDECODE_ENTRY("fgtiles_sprites",0,spritelayout,0*8,2) -> base — shares text with technos/mystston.cpp:375
cores/mystston/hdl/mystston_colmix.v:7 background: GFXDECODE_ENTRY("bgtiles",0,spritelayout,2*8,1) -> base 16, — shares text with technos/mystston.cpp:374
cores/mystston/hdl/mystston_colmix.v:9 foreground: GFXDECODE_ENTRY("fgtiles_sprites",0,gfx_8x8x3_planar,4*8,4) — shares text with technos/mystston.cpp:373
cores/mystston/hdl/mystston_main.v:17 line (PORT_READ_LINE_DEVICE_MEMBER("screen",vblank)). The game busy-waits — shares text with technos/mystston.cpp:525
cores/mystston/hdl/mystston_video.v:7 Video timing: mystston.cpp's screen.set_raw(PIXEL_CLOCK,384,0,256,272,8,248) — shares text with technos/mystston.cpp:97
cores/mystston/hdl/mystston_video.v:94 screen.set_raw(PIXEL_CLOCK,384,0,256,272,8,248) with no hand-tuned — shares text with technos/mystston.cpp:97
cores/mystston/hdl/mystston_obj.v:5 static const gfx_layout spritelayout = { 16,16, RGN_FRAC(1,3), 3, — shares text with technos/mystston.cpp:358
cores/mystston/hdl/mystston_obj.v:6 { RGN_FRAC(2,3), RGN_FRAC(1,3), RGN_FRAC(0,3) }, — shares text with technos/mystston.cpp:363
cores/mystston/hdl/mystston_obj.v:7 { 16*8+0..16*8+7, 16*0+0..16*0+7 }, { 0*8, 1*8, ..., 15*8 }, 32*8 }; — shares text with technos/mystston.cpp:364

blahm1d_exidy440#
Combat, Cheyenne, Chiller, Clay Pigeon …
database (builds only)

blahm1d
independent database

Source not published

blahm1d_gladiator#
Ougon no Shiro
database (builds only)

blahm1d
independent database

Source not published

blahm1d_invasion#
Invasion: The Abductors
database (builds only)

blahm1d
independent database

Source not published

blahm1d_legendofkage#
The Legend of Kage
database (builds only)

blahm1d
independent database

Source not published

blahm1d_mk4#
Mortal Kombat 4
database (builds only)

blahm1d
independent database

Source not published

blahm1d_narc#
Narc
database (builds only)

blahm1d
independent database

Source not published

blahm1d_nightslashers#
Night Slashers
database (builds only)

blahm1d
independent database

Source not published

blahm1d_tunit#
Judge Dredd, Mortal Kombat, NBA Jam, NBA Jam Tournament Edition
database (builds only)

blahm1d
independent database

Source not published

blahm1d_tunitdcs#
Mortal Kombat II
database (builds only)

blahm1d
independent database

Source not published

blahm1d_vunit#
Cruis'n USA, Cruis'n World, Off Road Challenge
database (builds only)

blahm1d
independent database

Source not published

blahm1d_wargods#
War Gods
database (builds only)

blahm1d
independent database

Source not published

blahm1d_wolfunit#
Mortal Kombat 3, NBA Hangtime, NHL Open Ice: 2 on 2 Challenge, Rampage: World Tour …
database (builds only)

blahm1d
independent database

Source not published

blahm1d_xunit#
Revolution X
database (builds only)

blahm1d
independent database

Source not published

blahm1d_yunit#
High Impact Football, Strike Force, Super High Impact, Smash T.V. …
database (builds only)

blahm1d
independent database

Source not published

blahm1d_yunitadpcm#
Mortal Kombat, Terminator 2 - Judgment Day, Total Carnage
database (builds only)

blahm1d
independent database

Source not published

10yardfight (adreeve)#
10-Yard Fight
adreeve/Arcade-10YardFight_MiSTer @ aa6346f4
MAME compared: irem/m58.cpp + 5 related file(s)
Read: 29 HDL files, 9,558 lines (Quartus project)

adreeve
repository only

Both

low

17%

Statements: 7 toward hardware, 12 toward MAME

Cites hardware documentation that MAME's driver does not — 4

rtl/iremm62_video_controller.vhd:65 from M52 schematics
rtl/tilemapctl.vhd:184 CENTER PCB sheet 4 of 4: the '157 at 6F puts H4E, H8, H16 and H32 on RAMA0..3, so the panel RAM column is h_eff(5 downto 2) and the pixel within the byte is h_eff(1 downto 0), h_eff being the counter after the flip XORs on BOTTOM sheet 1.
rtl/tilemapctl.vhd:193 It is PSOUT from the 74LS85 at 2B, which compares H64E/H32/H16/H8 (h_eff bits 6..3) against A = 8 + FLIP, with A3 strapped to +5V, A2/A1 to ground (pins 13, 12), A0 and the A=B and A>B cascade inputs on the FLIP net, and A<B-in on +5V.
README.md:92 `docs/hardware-notes.md` records what has been verified against Irem's own schematics rather than against MAME: the raster presets (384x282), the colour resisto

Says it was checked on “real hardware” — 3

rtl/tilemapctl.vhd:204 Confirmed on hardware with the result matching the board model.
README.md:6 Flip screen (the 180 degree cocktail rotation) works and is verified on hardware too.
README.md:73 [x] High score saving (verified on hardware)

Cites MAME source — 10

rtl/Sound_Board.vhd:358 The board feeds VR1 through R15 2.2K (read from a photo) against R25 10K for the AYs, so it mixes the samples hotter than MAME's flat routing; the exact factor is set by ear (OSD).
rtl/platform.vhd:124 MAME resnet weights (220/470/1000 ohm, common scale): 3-bit ladder 0,33,71,104,151,184,222,255 - 2-bit ladder 0,71,151,222.
rtl/platform.vhd:392 MAME tests the whole byte, so treat any non-zero as disabled
rtl/platform.vhd:606 The radar palette is packed the same way as the character palette and uses the same ladders (MAME computes both in one call, no pulldown).
rtl/tilemapctl.vhd:190 The pixel data lags the addressing counter by M58_PANEL_LAG: solving the board's column against MAME's unflipped picture gives 4 uniquely.
rtl/tilemapctl.vhd:198 Flipped it opens to h_eff 192..255 - screen x 0..63, 64 pixels wide - and with the data lag the content lands 8 pixels in: x 0..7 show RAM columns 0 and 15, which MAME never draws, and x 8..63 show panel source 55 down to 0.
README.md:45 MAME's own `m58.cpp` notes that the driver is "loosely based on the Kung Fu Master driver."
README.md:74 [ ] The board's LM358 ADPCM low-pass, which MAME omits (OSD "Audio filter", built, awaiting a hardware listen; see docs/hardware-notes.md)
README.md:80 All six sets in MAME's `m58.cpp`, all the same game:
README.md:97 That comparator makes the flipped panel 64 pixels wide with its content 8 pixels in from the edge, which is what the board does and not what MAME draws.

Says it matches, follows or was checked against MAME — 1

README.md:100 `tools/verify_palette.py` proves every palette entry matches MAME's computed palette exactly.

Shares text with the MAME driver without saying so — 1

rtl/platform.vhd:409 flip_screen_set(BIT(data,0) ^ BIT(~dsw2,0)): the dip reads 1 for — shares text with irem/m58.cpp:260

Arcade-10YardFight (harlock74)#
10-Yard Fight
harlock74/Arcade-10YardFight_MiSTer @ fdcbdc57
MAME compared: irem/m58.cpp + 5 related file(s)
Read: 29 HDL files, 7,891 lines (Quartus project)

harlock74
repository only

Mostly MAME

low

35%

Statements: 5 toward hardware, 26 toward MAME

Cites hardware documentation that MAME's driver does not — 5

rtl/m58_sprite_assets.sv:4 BOTTOM Sheet 3 contains the corresponding six 2764 ROMs and six LS194 parallel-load/shift devices.
rtl/m58_sprite_linebuffer.sv:2 Two 256x4 ping-pong buffers model the pair of 2149 SRAMs on BOTTOM Sheet 4.
rtl/m58_sprite_ram.sv:2 BOTTOM Sheet 2 contains a separate 2128 with LS367/LS273 support, but its unused physical addresses and exact arbitration are not yet traced.
rtl/m58_timing.sv:38 Clear correspondences to the named 1H..H256 and 1V..V256 schematic signals: bit N of these buses is the same counter phase named 2**N.
README.md:9 Long-term goal: progressively improve the core through visual audits of schematic sheets and move it closer to a schematic-aligned implementation where possible

Cites MAME source — 24

Arcade-10YardFight.sv:107 MAME defaults: DSW1 normal/1C_1C, DSW2 upright/mode 1/cheats off.
rtl/audio/YM2149.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA
rtl/audio/m52_large_ports.vhd:34 MAME write_port2 behavior, including its all-input callback convention.
rtl/audio/m52_msm5205.vhd:1 Arithmetic cross-check: MAME msm5205.cpp, Aaron Giles, BSD-3-Clause; step table also used by Dar's Moon Patrol core.
rtl/m58_background.sv:56 MAME applies the 9-bit X value and 8-bit Y value directly to its 512x256 tilemap.
rtl/m58_inputs.sv:30 MAME models SERVICE1 as a 19-frame impulse so it is recognized reliably.
rtl/m58_main_board.sv:474 MAME's HOLD_LINE behavior: latch at VBLANK and release on Z80 ack.
rtl/m58_main_board.sv:484 MAME combines the software bit with active-low DSW2:1.
rtl/m58_radar_panel.sv:2 The 4 KiB logical store reproduces MAME's $9000-$9fff behavior; it is not a claim that the physical BOTTOM-5 2128 has this literal capacity or address wiring.
rtl/m58_radar_panel.sv:65 MAME accepts writes only for logical byte columns 1..14.
rtl/m58_radar_panel.sv:70 Normal MAME clipping exposes bitmap X 8..55 at screen X 208..255.
rtl/m58_sprite_palette.sv:2 MAME's sprite pen indirection is exactly the hardware-friendly value to keep in each four-bit 2149 line-buffer entry.
rtl/m58_sprite_palette.sv:32 These values reproduce MAME's legacy resistor calculation.
rtl/m58_sprite_ram.sv:2 CPU-visible MAME sprite window.
rtl/m58_sprite_renderer.sv:167 Historical plane names identify fetch lanes, not numerical significance: ascending ROM groups carry pen bits 0,1,2 (MAME's first layout plane is MSB).
rtl/m58_tile_assets.sv:2 MAME's first layout plane supplies the most-significant pen bit.
rtl/m58_tile_assets.sv:18 MAME gfx_8x8x3_planar assigns pen bit 0 to the final region third.
rtl/m58_tilemap_addr.sv:2 MAME-confirmed logical 64x32 mapper.
rtl/m58_timing.sv:2 Normalized MAME raster counters plus the equivalent original TTL counter phases.
rtl/m58_timing.sv:3 The physical counters run H=0x100..0x1ff,0x080..0x0ff and V=0x0e6..0x1ff; normalized zero is the start of MAME's raw frame.
rtl/m58_video_mixer.sv:2 MAME-observable final layer order: radar/panel over non-transparent sprite over playfield.
rtl/m58_video_ram.sv:3 The two 2K banks preserve the physical capacity split while presenting the MAME-confirmed linear 4K byte window.
README.md:13 Only the MAME parent set `10yard` (World, set 1) is supported.
README.md:66 | M58 game/video and M52 sound implementation | harlock74; schematic and MAME references | Scoped [owner grant](LICENSE) |

Says it was translated, ported or taken from MAME — 1

README.md:7 Current status: functional behavioural implementation, mainly based on MAME/reference behaviour and available hardware documentation.

Keeps a MAME approximation — 1

rtl/audio/m52_large_audio.vhd:2 Physical/MAME distinctions and intentional approximations are documented in Detailed comparison retained in development; see NOTICE.md for attribution.

Arcade-Atari-G1 (Gm0rk)#
Hydra, Pit Fighter
Gm0rk/Arcade-Atari-G1_MiSTer @ e67a767d
MAME compared: atari/atarig1.cpp + 12 related file(s)
Read: 39 HDL files, 12,273 lines (Quartus project)

Gm0rk
repository only

Mostly MAME

high

63%

Statements: 13 toward hardware, 133 toward MAME, 1 not counted

Cites hardware documentation that MAME's driver does not — 9

Arcade-Atari-G1.sv:920 self_test is the same switch as IN0 bit 14: one /SELFTEST net joins JAMMA pin 15, the game PCB (AUD-29) and the JSA II's SW1 (J1-29), and the 6502 reads it through inverting buffer 2F (74LS240), so it is active high here.
rtl/jsa2/g1_jsa2.sv:6 Follows MAME's atari_jsa_ii_device (atarijsa.cpp) and the JSA II schematic (Pit Fighter manual, fig. 5-2).
rtl/jsa2/g1_jsa2.sv:480 Bit 7 follows the schematic, not MAME (which always reads 0): the SELF-TEST net (low = test; shared with the game PCB and JAMMA pin 15) reaches SD7 through 2F, an inverting 74LS240, so test mode reads 1.
rtl/jsa2/g1_jsa2.sv:487 0x80 self test, active high (via 74LS240)
README.md:34 manual and its schematics.
README.md:105 Each of these follows the board schematics in the Pit Fighter operator's manual, and was checked against the game code before changing:
README.md:347 Each block is checked against a reference derived from MAME, or from the board's schematics, rather than against expectations:
README.md:405 **The *Pit Fighter* operator's manual** (Atari Games), with its game PCB, JSA Audio II and wiring schematics.
README.md:409 **The *Hydra* Universal Kit installation instructions** (Atari Games, TM-354): control wiring, game play, self-test and schematics.

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/cpu/g1_addr_decode.sv:21 $FD8000-$FDFFFF RW EEPROM, 2 KB, low byte only (umask16 $00FF) $FE0000-$FE7FFF - Open bus (decode space of the A048490-01 "G1 OOPS" daughter card at 10P, which carries the Slapstic) $FE8000-$FE89FF RW Palette RAM, 1280 entries $FF000 — also in MAME: 10P atari/atarig1.cpp:666

Says it was checked on “real hardware” — 2

README.md:76 | Tilemaps | **Working on hardware.** Confirmed on hardware |
README.md:350 **Slapstic.** Randomised accesses against a port of `slapstic.cpp` for every type, then confirmed on hardware by the game reaching code that only a working bank

Notes where it differs from MAME — 2

README.md:12 [Where the core deliberately differs from MAME](#where-the-core-deliberately-differs-from-mame)
README.md:103 Where the core deliberately differs from MAME

Cites MAME source — 115

Arcade-Atari-G1.sv:11 Coins are not on the 68000's input ports: COIN1/2/3 are on the JSA II's RDIO port (6502 $2804, active high) and reach the 68000 only through the sound command latch (MAME port definitions).
Arcade-Atari-G1.sv:649 Bit assignments follow MAME's INPUT_PORTS.
Arcade-Atari-G1.sv:661 MAME's PORT_SERVICE; both games check it at boot to enter the test menu.
Arcade-Atari-G1.sv:669 Pit Fighter player port, MAME order: down, up, right, left, Punch, Kick, Jump/Start.
Arcade-Atari-G1.sv:683 MAME order: Left Trigger, Right Trigger, Left Thumb, Right Thumb, Boost -- the same order as the MRA's buttons, so bit n is joystick bit n+4.
Arcade-Atari-G1.sv:700 The JSA II's third coin input is counted by the 6502 but credited by neither game (MAME), so player 3's coin drops into the right mech and coin 3 reads 0: no switch is wired to it.
Arcade-Atari-G1.sv:715 IN0 bits 11:8: unused in MAME, but on the PCB (manual fig. 5-1, buffer 35A) they repeat player 2's JAMMA lines through R15/R16/R13/R14: bit 8 JAM-Z (Punch 2), 9 JAM-a (Kick 2), 10 JAM-b (Jump 2), 11 JAM-c (spare, pulled up).
Arcade-Atari-G1.sv:923 MAME reads 0 (it inverts the line twice).
Arcade-Atari-G1.sv:1042 MAME uses vpos only through min(239, vpos) and partial = vpos, so any value >= 240 is exact for all of VBLANK (vis_y reads 0 there).
Arcade-Atari-G1.sv:1262 The opaque flag is tile data[15], which is also the top bit of the colour field (as in MAME).
rtl/board/g1_adc0809.sv:13 Timing follows MAME adc0808.cpp.
rtl/board/g1_adc0809.sv:13 The ADC clock is 14.318181 MHz / 16 (894.9 kHz, atarig1.cpp) = 64 clk_sys.
rtl/board/g1_adc0809.sv:101 EOC keeps its state until the sample point, as in MAME
rtl/board/g1_ce.sv:14 The board clocks the 68000 from the 14.318 MHz oscillator at x1 (as MAME does), though the fitted part is an MC68HC000P12F (12.5 MHz grade); cpu_div2 selects 7.159 MHz instead at runtime.
rtl/board/g1_ce.sv:25 0 = 68000 at 14.318181 MHz (MAME, default) 1 = 68000 at 7.159090 MHz Safe to change at any time: the divider is free-running.
rtl/board/g1_eeprom.sv:5 CPU $FD8000-$FDFFFF, low byte only (MAME umask16 $00FF).
rtl/board/g1_eeprom.sv:8 MAME: EEPROM_2816 with lock_after_write(true).
rtl/board/g1_eeprom.sv:42 Power up as $FF like a blank part and MAME (eeprom.cpp nvram_default is ~0; atarig1 gives no default region).
rtl/board/g1_hydra_controls.sv:6 The pedal is also the start control; there is no start button (manual TM-354 table 1-3, MAME hydra ports).
rtl/board/g1_hydra_controls.sv:9 Inside its dead zone the d-pad ramps the axis out by 10 per frame and back to centre by 20 (MAME KEYDELTA 10).
rtl/board/g1_hydra_controls.sv:15 Pedal (ADC channel 2): the largest of the Pedal button (ramps up 16 per frame while held, MAME KEYDELTA 16, down 32 after release), the right stick pushed up, and the paddle.
rtl/board/g1_hydra_controls.sv:17 All rest at 0 (MAME's rest value).
rtl/board/g1_top.sv:8 Follows MAME atarig1.cpp.
rtl/board/g1_top.sv:352 rle_cmd_wr is high exactly while rle_cmd holds a freshly written value; g1_rle latches its command on it (MAME: mo_command_w -> command_write on every write).
rtl/board/g1_top.sv:532 $F90000 is a byte handler on an even address in MAME (map(0xf90000, 0xf90000)): D15:8 with UDS.
rtl/board/g1_top.sv:550 As in MAME control_write, a write that leaves the byte unchanged is ignored, comparing all eight bits (Hydra ORs game state into bits 7:3 on its second write).
rtl/board/g1_top.sv:628 Unmapped space also asserts DTACK and reads $0000, as in MAME (the G1 map does not set unmap_value_high).
rtl/board/g1_top.sv:629 That includes $FE0000, whose MAME handler is commented out: Hydra tests bit 0 of $FE0001 at $70E2 and only enters its bit-bang routine when it reads 1.
rtl/board/g1_watchdog.sv:5 MAME uses a WATCHDOG_TIMER with the default period: reset the CPU if no write is seen for 3 seconds (180 frames at 59.923 Hz).
rtl/cpu/g1_addr_decode.sv:8 Memory map (MAME atarig1.cpp main_map / pitfight_map / hydra_map): $000000-$07FFFF R Program ROM (512 KB region) $038000-$039FFF R Slapstic window, Pit Fighter, mirrored every $2000 $078000-$079FFF R Slapstic window, Hydra, mirrore
rtl/cpu/g1_addr_decode.sv:67 In the Slapstic window the bank replaces bits [14:13]: MAME configure_entries(0, 4, maincpu + $38000, $2000) puts the four banks at ROM $38000-$3FFFF, the window's own range.
rtl/cpu/g1_addr_decode.sv:148 Palette is $A00 bytes of the $8000 slot; above entry 1279 is unmapped, not aliased (MAME: 1280 words).
rtl/cpu/g1_addr_decode.sv:155 $FE0000-$FE7FFF is unmapped in MAME too (its map line is commented out).
rtl/cpu/g1_slapstic.sv:10 MAME taps the whole address space (install_readwrite_tap over addrmask), because for types 111-118 the 1st and 3rd steps of the alt sequence match at any address.
rtl/cpu/g1_slapstic.sv:50 Type tables: (mask, value) pairs tested against addr14, copied from slapstic.cpp.
rtl/cpu/g1_slapstic.sv:159 MAME checker primitives
rtl/cpu/g1_slapstic.sv:169 Sequence recognition FSM (types 111..118), after the slapstic.cpp state classes: IDLE wait for a reset access (offset 0 in range) ACTIVE direct bank select, or start alt (alt1, any address) or additive (add1, in range) ALT_VALID
rtl/cpu/g1_slapstic.sv:189 MAME: loaded_bank = (addr >> (1 + altshift)) & 3, i.e. addr14 >> altshift
rtl/cpu/g1_slapstic.sv:197 MAME: byte offset & 0x3FFF
rtl/g1_pkg.sv:19 MAME set_raw(14.318181MHz/2, 456, 0, 336, 262, 0, 240): 7.159 MHz dot clock, 15.700 kHz line, 59.923 Hz frame.
rtl/g1_pkg.sv:20 MAME's totals come from published specs; the porch/sync split of the blanking is chosen for a standard 15 kHz CRT.
rtl/g1_pkg.sv:71 MAME gfx_element::get_data wraps (code % elements), so bank bit 2 is ignored.
rtl/g1_pkg.sv:94 MAME's lookup tables all reduce to bit slicing (see g1_rle_decode.sv).
rtl/g1_pkg.sv:123 MAME's general form is "if bit 15, XOR with $FFFF".
rtl/jsa2/g1_jsa2.sv:6 Follows MAME's atari_jsa_ii_device (atarijsa.cpp) and the JSA II schematic (Pit Fighter manual, fig. 5-2).
rtl/jsa2/g1_jsa2.sv:11 6502 memory map (MAME atarijsa2_map): $0000-$1FFF RAM (8 KB)
rtl/jsa2/g1_jsa2.sv:33 WRIO ($2A04, MAME wrio_w): 0xC0 program ROM bank 0x04 OKI6295 reset, active low 0x20 coin counter 2 0x02 (JSA III only) 0x10 coin counter 1 0x01 YM2151 reset, active low 0x08 OKI6295 PIN7 (sample rate).
rtl/jsa2/g1_jsa2.sv:40 MIX ($2A06): 0x20 low-pass filter enable (not emulated, nor by MAME) 0x0E YM2151 volume, 0-7 0x01 OKI6295 volume, 0 = half, 1 = full
rtl/jsa2/g1_jsa2.sv:45 Analog filtering is not modelled (nor by MAME); the real board sounds duller than MAME, the ADPCM most of all.
rtl/jsa2/g1_jsa2.sv:53 6502 IRQ = periodic timer (249.7 Hz) OR YM2151 IRQ, as MAME's update_sound_irq().
rtl/jsa2/g1_jsa2.sv:170 The I/O block is mirrored as in MAME ($07FE for the YM, $01F9 for the rest).
rtl/jsa2/g1_jsa2.sv:223 YM2151 CT1 output pin; gates the OKI as in MAME (see Mixer).
rtl/jsa2/g1_jsa2.sv:475 All polarities are applied here (MAME jsa_ii_ioports).
rtl/jsa2/g1_jsa2.sv:500 MAME (atarijsa.cpp, JSA II), mono: out = 0.60 * (L + R) * vol/7 + 0.75 * g * oki vol = MIX bits 3:1, g = 1.0 or 0.5 from MIX bit 0, one full-scale OKI voice = 1.0 (okim6295.cpp: 12-bit sample x volume 32 / 2).
rtl/jsa2/g1_jsa2.sv:505 The schematic (fig. 5-2) has the same structure: YM3012 L and R are summed by 6B through equal resistor pairs switched 1:2:4 by MIX bits 1-3 (4066 3B), i.e. (L+R) * vol/7; the OKI half/full switch is ~2.4:1 at DC vs MAME's 2:1.
rtl/jsa2/g1_jsa2.sv:508 The YM:OKI balance depends on DAC swings the schematic does not give, so MAME's 0.60/0.75 are used.
rtl/jsa2/g1_jsa2.sv:511 MAME's ratio, halved for headroom:
rtl/jsa2/g1_jsa2.sv:515 Full-scale YM at vol 7 gives 0.60 of full scale, one OKI voice 0.375; four loud voices can clip, as in MAME.
rtl/jsa2/g1_jsa2.sv:522 OKI gated by YM2151 CT1, as in MAME's update_all_volumes() (gain = overall * oki volume * ct1).
rtl/jsa2/g1_jsa2.sv:524 On the JSA II schematic CT1/CT2 are not connected (3A pins 8 and 9); MAME's gating comes from the JSA I. It makes no difference here: both games write $C0 to $1B during boot, before any OKI sample, and never clear it.
rtl/video/g1_alpha.sv:5 Follows MAME get_alpha_tile_info.
rtl/video/g1_alpha.sv:10 bits 15:12 colour bank -- four bits including the opaque bit, as in MAME's (data >> 12) & $0F bits 11:0 character code Palette index = $100 + (colour << 4) + pixel.
rtl/video/g1_mixer.sv:5 Fixed order, no inter-layer priority, as MAME atarig1_state::screen_update (playfield draw, copybitmap_trans of the MO bitmap with colour 0 transparent, alpha draw).
rtl/video/g1_palette.sv:5 CPU $FE8000-$FE89FF: 1280 16-bit entries in MAME palette format IRGB_1555.
rtl/video/g1_palette.sv:70 MAME raw_to_rgb_converter::IRRRRRGGGGGBBBBB_decoder.
rtl/video/g1_palette.sv:88 Reference values from MAME's decoder: $7C00 -> R = $FB (r6 = 62), $FC00 -> R = $FF (r6 = 63).
rtl/video/g1_playfield.sv:6 Follows MAME get_playfield_tile_info.
rtl/video/g1_playfield.sv:12 Only 16384 tiles exist and MAME wraps with code % elements, so bank bit 2 is a don't-care; the mask also keeps fetches inside the ROM region.
rtl/video/g1_playfield.sv:17 5bpp ROM layout (MAME pflayout + pftoplayout + blend_gfx(0, 2, $0F, $10)): planeoffset {0, 0, 1, 2, 3} repeats offset 0 for the placeholder plane that blend_gfx masks off, so the four real planes are four consecutive bits and each nibble is
rtl/video/g1_playfield.sv:130 Tile bit 15 is the flags argument of MAME's tileinfo.set, i.e. TILE_FLIPX; a flip just reverses the pixel index.
rtl/video/g1_scroll.sv:6 From MAME atarig1_state::scanline_update:
rtl/video/g1_scroll.sv:77 MAME's "if (offset >= 0x800) return": alpha RAM is 2048 words.
rtl/video/g1_video_timing.sv:5 456 x 262 raster, 336 x 240 visible, from a 7.159090 MHz dot enable (MAME set_raw(14.318181 MHz / 2, 456, 0, 336, 262, 0, 240)).
rtl/video/g1_video_timing.sv:18 MAME's totals come from published specs; the split is an estimate, so it is a parameter.
rtl/video/mob/g1_rle.sv:15 Each write to $FF2000 (a work RAM word, snooped) latches the command as MAME mo_command_w does: CHECKSUM if 0 on Pit Fighter, else DRAW; NOP until the first write.
rtl/video/mob/g1_rle.sv:94 MAME: m_rle->command_write((data == 0 && m_is_pitfight) ?
rtl/video/mob/g1_rle.sv:170 Indexed by the object's code, not its slot (MAME: m_info[code]).
rtl/video/mob/g1_rle.sv:262 MAME sort_and_render: x += m_cliprect.left().
rtl/video/mob/g1_rle.sv:467 Skip null objects and out-of-range codes (MAME: if (code >= count) continue).
rtl/video/mob/g1_rle.sv:488 Wait out any queued or running erase of the render buffer, so it completes before this object draws, as in MAME (g1_rle_fb).
rtl/video/mob/g1_rle_checksum.sv:6 MAME atarirle.cpp:
rtl/video/mob/g1_rle_decode.sv:5 MAME builds lookup tables for this (build_rle_tables()), but every entry is a bit-slice of its index, e.g. for 4bpp:
rtl/video/mob/g1_rle_decode.sv:79 Simulation self-check against the arithmetic of MAME build_rle_tables()
rtl/video/mob/g1_rle_fb.sv:15 MAME atarirle.cpp (control_write / vblank_callback): control_write(data), only if data != old bits: if old ERASE: clear buffer[old FRAME] over lines max(0, partial+1) ..
rtl/video/mob/g1_rle_fb.sv:34 MAME's operations are instant; here each erase request latches its buffer and line range when made (FRAME can flip mid-erase) into a one-deep queue per buffer, where overlapping requests merge.
rtl/video/mob/g1_rle_fb.sv:37 rnd_hold is high while an erase of the render target is queued or running; g1_rle waits for it before drawing each object, so the erase completes first, as in MAME.
rtl/video/mob/g1_rle_fb.sv:91 MAME m_control_bits (low three)
rtl/video/mob/g1_rle_fb.sv:100 Both use the current FRAME, so they merge into one range; the VBLANK request is evaluated first, as in MAME.
rtl/video/mob/g1_rle_objram.sv:6 MAME reads them live during sort_and_render(); here a DRAW copies all 2048 words into BRAM in one burst and releases the work RAM video port, which would otherwise be contended with the tile fetchers for most of a frame.
rtl/video/mob/g1_rle_objram.sv:163 X and Y: 10-bit signed fields in bits 15:6, sign extended (MAME: if (x & 0x200) x |= ~0x3ff).
rtl/video/mob/g1_rle_prescan.sv:5 After the ROM download this walks every object once (MAME prescan_rle()) and fills a BRAM table that the render engine reads in one clock per object:
rtl/video/mob/g1_rle_prescan.sv:19 MAME's general test is "bit 15 set, XOR with $FFFF"; in both G1 ROM sets $FFFF is the only value with bit 15 set, so an equality test is used.
rtl/video/mob/g1_rle_prescan.sv:184 Null object (MAME prescan_rle): a data offset at or before the object's own header entry.
rtl/video/mob/g1_rle_prescan.sv:223 MAME caps the walk at 1024 rows.
rtl/video/mob/g1_rle_render.sv:6 Port of the inner loop of MAME draw_rle_zoom():
rtl/video/mob/g1_rle_scaler.sv:6 Port of the setup half of MAME draw_rle_zoom():
rtl/video/mob/g1_rle_scaler.sv:165 MAME: if (scale == 0) continue
README.md:33 It worked from MAME's source, from the operator's
README.md:99 **Clocks:** all six within 1 ppm of MAME's values.
README.md:109 MAME reads it as 0 always, because it inverts twice.
README.md:114 MAME calls those bits unused.
README.md:193 | CPU clock | **14.318MHz (MAME)**, 7.159MHz | The 68000's clock. The board runs it at the full crystal rate; half speed is a diagnostic. |
README.md:350 **Slapstic.** Randomised accesses against a port of `slapstic.cpp` for every type, then confirmed on hardware by the game reaching code that only a working bank
README.md:357 It is pixel-exact against a port of `atarirle.cpp` over hundreds of object/scale/flip cases and on MAME's own fight-screen object RAM.
README.md:360 **Sound.** The real 6502 program runs on the JSA model (T65 converted with GHDL) behind an SDRAM latency model, and answers the 68000 byte for byte as MAME's do
README.md:364 **MAME itself.** Where behaviour over time mattered, Ubuntu's MAME 0.264 was run headless with Lua probes for reference data: the coin protocol, which coin inpu
README.md:368 **The schematics.** The Pit Fighter operator's manual's schematics settled what MAME could not: the test-switch polarity on the sound board, the coin mechs, the
README.md:391 **[MAME](https://www.mamedev.org/)**, the reference for essentially all hardware behaviour.
README.md:396 | `atarig1.cpp`, `atarig1.h` | Aaron Giles | memory map, machine configuration, interrupt levels, MO command register, input ports |
README.md:397 | `atarig1_v.cpp` | Aaron Giles | video registers, tilemap layout, per-scanline scroll, colour mixing |
README.md:398 | `atarirle.cpp`, `atarirle.h` | Aaron Giles | the RLE object engine: list scan, object table, decode, scaling, flip |
README.md:399 | `slapstic.cpp` | Aaron Giles | the Slapstic bank controller state machine |
README.md:400 | `atarijsa.cpp` | Aaron Giles | JSA II sound board configuration, comm registers and mixing |
README.md:401 | `eeprom.cpp` | Aaron Giles | EEPROM behaviour and the unlock sequence |
README.md:403 MAME is a reference for *behaviour*; no MAME code is compiled into this core.

Says it matches, follows or was checked against MAME — 8

rtl/cpu/g1_slapstic.sv:15 Matching uses addr14 = cpu_addr[14:1], which absorbs MAME's shift of 1 for a 16-bit bus, so the table constants are identical to slapstic.cpp.
rtl/jsa2/g1_jsa2.sv:527 Kept so the core matches MAME; removing it would match the board.
README.md:73 | 68000 + Slapstic | **Working on hardware.** Every Slapstic type is vector-matched against MAME (400,000 accesses per seed, 0 mismatches) |
README.md:77 | Motion objects (RLE) | **Working on hardware.** Fighters and crowd draw and animate. In simulation, the engine running on the real ROMs is pixel-exact against
README.md:347 Each block is checked against a reference derived from MAME, or from the board's schematics, rather than against expectations:
README.md:355 The frames come out pixel-identical to MAME's snapshots, with the SDRAM bus loaded or idle.
README.md:362 The mixer is checked against MAME's formula and music/speech ratio.
README.md:374 How the game treats the pedal was checked in MAME first: it starts on a press from rest, with either the pedal polarity MAME uses or the real pot's.

Says it was translated, ported or taken from MAME — 5

rtl/cpu/g1_slapstic.sv:7 Port of MAME slapstic.cpp (atari_slapstic_device).
rtl/jsa2/g1_sound_comm.sv:5 Port of MAME's atari_sound_comm_device: two single-byte latches, each with a full flag that drives an interrupt line (as a level, not a pulse).
rtl/video/mob/g1_rle.sv:5 Port of MAME atarirle.cpp as configured by atarig1.cpp:
rtl/video/mob/g1_rle_sort.sv:7 Port of MAME sort_and_render():
README.md:77 | Motion objects (RLE) | **Working on hardware.** Fighters and crowd draw and animate. In simulation, the engine running on the real ROMs is pixel-exact against

Shares text with the MAME driver without saying so — 5

rtl/g1_pkg.sv:19 MAME set_raw(14.318181MHz/2, 456, 0, 336, 262, 0, 240): 7.159 MHz dot — shares text with atari/atarig1.cpp:363
rtl/jsa2/g1_jsa2.sv:254 Periodic IRQ: JSA_MASTER_CLOCK / 4 / 16 / 16 / 14 = 3579545 / 14336 — shares text with atari/atarijsa.cpp:793
rtl/jsa2/g1_jsa2.sv:488 0x40 NMI line state, active low — shares text with atari/atarijsa.cpp:666
rtl/video/g1_video_timing.sv:6 (MAME set_raw(14.318181 MHz / 2, 456, 0, 336, 262, 0, 240)). This is the — shares text with atari/atarig1.cpp:363
rtl/video/mob/g1_rle_decode.sv:9 table[0][i] = (((i & 0xF0) + 0x10) << 4) | (i & 0x0F) — shares text with atari/atarirle.cpp:292

Arcade-Atari-G42 (Gm0rk)#
Danger Express, Guardians of the 'Hood, Road Riot 4WD
Gm0rk/Arcade-Atari-G42_MiSTer @ 354d53de
MAME compared: atari/atarig42.cpp + 12 related file(s)
Read: 45 HDL files, 13,682 lines (Quartus project)

Gm0rk
repository only

Mostly MAME

high

64%

Statements: 5 toward hardware, 166 toward MAME, 1 not counted

Cites hardware documentation that MAME's driver does not — 2

rtl/asic65/g42_asic65.sv:7 rom_based = 1 (Road Riot 4WD, ASIC65_ROMBASED): a TMS32010-family DSP (tms32010.sv) runs the 136089-1012 program from a 2K x 16 block RAM that the ROM loader fills (words 0x800-0xFFF of the 4K program space read 0, as MAME's zero-filled reg
rtl/jsa3/g42_jsa3.sv:6 Follows MAME's atari_jsa_iii_device (atarijsa.cpp, "full map verified from schematics and Batman GALs") and is derived from the Atari G1 JSA II (g1_jsa2.sv), whose hardware-verified bus timing, JT51/JT6295 hookup and comm latches it keeps.

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/asic65/g42_asic65.sv:67 ---- program download (Road Riot 136089-1012, word k at address k) ---- — also in MAME: 136089-1012 atari/atarig42.cpp:636

Notes where it differs from MAME — 3

rtl/board/g42_top.sv:786 synthesis translate_off Unmapped accesses are legal (MAME ignores them) but worth seeing in a simulation log.
rtl/jsa3/g42_jsa3.sv:39 As on the G1 JSA II, whose schematic shows the 6502 reading the test line through an inverting buffer, the 6502 here reads test-on as 1: at reset all three programs test bit 7 of $280C and run their RAM/ROM diagnostics (bank walk $45/$85/$C
README.md:71 Where the core differs from MAME, it follows the board: the sound CPU sees the test switch, and the ASIC65's data RAM is the real TMS320C15's 256 words.

Cites MAME source — 152

rtl/asic65/g42_asic65.sv:5 Follows MAME asic65.cpp in its two G42 flavours, selected at runtime:
rtl/asic65/g42_asic65.sv:7 rom_based = 1 (Road Riot 4WD, ASIC65_ROMBASED): a TMS32010-family DSP (tms32010.sv) runs the 136089-1012 program from a 2K x 16 block RAM that the ROM loader fills (words 0x800-0xFFF of the 4K program space read 0, as MAME's zero-filled reg
rtl/asic65/g42_asic65.sv:13 Host latches, as MAME's synced_write / read / io_r / m68k_r/w / stat_r/w: 68000 write $F80000/2 : TDATA = data, CMD = offset, TFULL = 1, and a DSP interrupt request (pending until taken)
rtl/asic65/g42_asic65.sv:21 (bit 12 is a jumper; MAME and the program's normal path want it set) DSP OUT port 1 : XFLG = data & 1 BIO : asserted while TFULL == 0 asic_reset holds the DSP in reset and does not touch the latches: the game writ
rtl/asic65/g42_asic65.sv:30 rom_based = 0 (Guardians of the 'Hood, Danger Express, ASIC65_GUARDIANS): the DSP is held in reset and the answers come from MAME's C++ (command_map row 2): REFLECT, CHECKSUM (0x0027), VERSION (0x0013), RAMTEST (0), RESET, INITBANKS, SETBAN
rtl/asic65/g42_asic65.sv:34 Parameters go to a 32-word array, a command write resets both indices, and read() applies its side effects in MAME's order.
rtl/asic65/g42_asic65.sv:37 Undefined behaviour in the C++ is replaced by its sane equivalent: m_command == -1 decodes as OP_UNKNOWN (result 0); parameters past the 32nd are dropped (MAME writes past the array into m_yorigin, unused in this mode); SETBANK with m_param
rtl/asic65/g42_asic65.sv:52 DSP data RAM: 256 = TMS320C15 (real part), 144 = MAME
rtl/asic65/g42_asic65.sv:73 DSP program counter (16 bits, as MAME)
rtl/asic65/g42_asic65.sv:124 MAME's io map mirrors ports 0/1 at 2/4/6 and 3/5/7: bits 2-1 are not decoded
rtl/asic65/tms32010.sv:5 Instruction-exact model of MAME's tms320c1x.cpp (0.264: tms32010.cpp, functionally identical): same architectural results for every opcode, including MAME's quirks, and the same cycle count per execute_run() iteration.
rtl/asic65/tms32010.sv:8 Quirks reproduced on purpose: * the PC is 16 bits and never masked (branch operands are loaded whole); program addresses (fetch, TBLR/TBLW, CALA) and the stack use 12 bits * ST bits 12-9 and 7-1 read as 1; LST keeps INTM and ignores next-AR
rtl/asic65/tms32010.sv:23 An iteration of MAME's loop (optional interrupt entry + one instruction) runs in four clocks, S_IDLE -> S_DEC -> S_OPR -> S_EXE, and all its effects (register writes, the data RAM write, the I/O strobe, the BIO sample) land in S_EXE.
rtl/asic65/tms32010.sv:27 A signed budget counts ce pulses minus the cycles MAME charges: an iteration starts whenever the budget is positive, exactly like MAME's do { } while (icount > 0), so a 0-cycle illegal opcode is followed at once by the next instruction and
rtl/asic65/tms32010.sv:35 TBLW writes are dropped (MAME maps the space as ROM).
rtl/asic65/tms32010.sv:37 DRAM_WORDS selects the map: 144 = TMS320C10 (0x00-0x8F, what MAME instantiates), 256 = TMS320C15 (the part Road Riot actually uses).
rtl/asic65/tms32010.sv:42 rst_n: power-on, every register as MAME's device_start() followed by device_reset().
rtl/asic65/tms32010.sv:43 reset: the RS pin (MAME INPUT_LINE_RESET), held while 1: PC, ACC, the pending interrupt and ST (= 0x7EFE) are reset, the other registers keep their values, nothing runs.
rtl/asic65/tms32010.sv:45 Like MAME, which acts on the line between loop iterations, an iteration already in flight completes first (at most four clocks).
rtl/asic65/tms32010.sv:76 program counter (16 bits, as MAME)
rtl/asic65/tms32010.sv:93 ce pulses not yet spent (MAME's icount)
rtl/asic65/tms32010.sv:100 stk3 is the top (MAME m_STACK[3])
rtl/asic65/tms32010.sv:195 7Fxx group: MAME dispatches on the low five bits only
rtl/asic65/tms32010.sv:214 Instructions that address data memory (getdata/putdata in MAME); their indirect forms update AR[ARP] and, unless noted, ARP.
rtl/asic65/tms32010.sv:248 Add/subtract with MAME's CALCULATE_ADD/SUB_OVERFLOW
rtl/asic65/tms32010.sv:269 SACH: high word of ACC shifted left by 0-7 (MAME allows all eight)
rtl/asic65/tms32010.sv:321 Iteration start: interrupt check (MAME Ext_IRQ) and budget
rtl/asic65/tms32010.sv:388 an interrupt stays pending until taken (MAME: cannot be cleared)
rtl/asic65/tms32010.sv:559 RS pin: MAME device_reset(), applied while held and idle
rtl/board/g42_adc0809.sv:5 68000 $E00020-$E0002F, one byte per word on D15:8 (MAME umask16 $FF00).
rtl/board/g42_adc0809.sv:6 MAME a2d_select_w / a2d_data_r: a write starts a conversion of channel (word offset & 7); a read returns the result register and also starts a new conversion of the channel it addresses.
rtl/board/g42_adc0809.sv:11 channels 2-7 not connected: MAME's default input reads $FF
rtl/board/g42_adc0809.sv:13 Timing follows MAME adc0808.cpp with the ADC clock at 14.318181 MHz / 16 (894.9 kHz = 64 clk_sys): from the start, +2 ADC clocks the input is sampled into the result register and EOC drops; +66 it is sampled again and EOC rises.
rtl/board/g42_adc0809.sv:16 The result powers up as $FF and EOC as 1, as in MAME.
rtl/board/g42_adc0809.sv:17 Danger Express and Guardians have no ADC: the core does not start conversions there and the 68000 reads $FF (MAME a2d_data_r).
rtl/board/g42_adc0809.sv:65 EOC keeps its state until the sample point, as in MAME
rtl/board/g42_controls.sv:5 The cabinet's wheel and pedal are potentiometers read through the ADC0809 (g42_adc0809): channel 0 wheel (MAME A2D0, AD_STICK_X, centre $80), channel 1 pedal (A2D1, PEDAL, rest $00).
rtl/board/g42_controls.sv:11 Wheel, in order of precedence: - the left analog stick X, outside its dead zone, scaled by the OSD sensitivity; - the d-pad, ramping out 10 per frame and back to centre 20 per frame (MAME KEYDELTA 10), the way a keyboard steers in MAME; - a
rtl/board/g42_controls.sv:19 Pedal: the largest of the Pedal button (ramps up 16 per frame while held, MAME KEYDELTA 16, down 32 after release) and the right stick pushed up.
rtl/board/g42_eeprom.sv:5 68000 $FA0000-$FA0FFF, low byte only (MAME umask16 $00FF).
rtl/board/g42_eeprom.sv:7 MAME: EEPROM_2816 with lock_after_write(true): a write is ignored unless the 68000 has written to $E00060 since the last accepted one, which guards the settings against a runaway program.
rtl/board/g42_eeprom.sv:12 the factory image in the ROM set (*-eeprom.5c), snooped from the ROM download (def_*), as MAME loads it when there is no .nv file; 2.
rtl/board/g42_top.sv:9 Follows MAME atarig42.cpp.
rtl/board/g42_top.sv:18 D13:11 MO control {FRAME,ERASE,MOGO} D3, D0 coin counters (not used) So after reset the sound board and the ASIC65 stay in reset until the game releases them (Guardians within its first frames; Road Riot keeps the sound board in reset throu
rtl/board/g42_top.sv:286 The SLOOP sees every cycle in $000000-$07FFFF, reads (including opcode fetches) and writes, as MAME's handler does.
rtl/board/g42_top.sv:310 Banked window $078000-$07FFFF -> ROM $078000 + bank x $2000, the 8 KB bank mirrored four times (MAME: 0x78000/2 + bank * 0x1000 + (offset & 0xfff)).
rtl/board/g42_top.sv:482 The word at $080000: MAME's region is $80004 bytes, zero past the program, and Guardians' init patches an RTS in (the game calls $080000).
rtl/board/g42_top.sv:505 $FF7000 (word $3800) is the MO command: ordinary RAM that the MO hardware reacts to (MAME mo_command_w: 0 = CHECKSUM, else DRAW).
rtl/board/g42_top.sv:530 Plain RAM in MAME.
rtl/board/g42_top.sv:580 Written per byte lane (MAME io_latch_w with mem_mask).
rtl/board/g42_top.sv:580 The MO control bits are passed on every upper-byte write; g42_rle ignores a write that does not change them, as MAME's control_write does.
rtl/board/g42_top.sv:667 A read or a write of $E00020-$E0002F starts a conversion of the channel it addresses (MAME a2d_data_r / a2d_select_w).
rtl/board/g42_top.sv:701 Unmapped reads return $0000 (MAME).
rtl/board/g42_top.sv:793 With +iolog: every access to the sound board, the ASIC65 and the I/O latch, with the frame number, for comparison with a MAME tap log.
rtl/board/g42_watchdog.sv:5 MAME's WATCHDOG_TIMER with the default period: the game is reset if no write reaches $E03800 for 3 seconds.
rtl/cpu/g42_addr_decode.sv:6 This is the only module that knows the memory map, which is MAME atarig42.cpp main_map, address for address (no mirrors: the board's decode PALs are read-protected and MAME is the only reference).
rtl/cpu/g42_addr_decode.sv:10 $000000-$07FFFF R program ROM; $078000-$07FFFF is the SLOOP window W (no memory: the SLOOP sees the cycle) $080000-$080001 R ROM word past the program: $4E75 (RTS) on Guardians, where the game calls it, $0000 otherwise (MAME) $E0000
rtl/cpu/g42_addr_decode.sv:22 $E00050-$E00051 W I/O latch: ASIC65 reset, MO control, sound reset $E00060-$E00061 W EEPROM unlock $E03000-$E03001 W VBLANK interrupt acknowledge $E03800-$E03801 W watchdog $E80000-$E80FFF RW 4 KB RAM $F40000-$F40001 R ASIC
rtl/cpu/g42_sloop.sv:10 Follows MAME atarig42.cpp roadriot_sloop_tweak / guardians_sloop_tweak.
rtl/cpu/g42_sloop.sv:31 MAME applies the change before it returns the data of the cycle that made it, so the ROM fetch must use the bank one clock after acc_strobe (see g42_top).
rtl/cpu/g42_sloop.sv:33 The state survives a watchdog reset, as in MAME (only its machine_start clears it): it is cleared by rst_n alone.
rtl/cpu/g42_sloop.sv:54 byte address, for comparison with MAME
rtl/cpu/g42_sloop.sv:69 One history entry per bus cycle at or above $07F7C0: bit 5 set means the cycle was outside the pattern area $07F7C0-$07F7FF (MAME keeps the whole offset; any value outside the area only has to fail the compare), bits 4:0 are the word within
rtl/g42_core.sv:108 rst_n: the game itself and the video, also held until that prescan has finished, so the game boots with its objects ready, as the MAME driver does (its prescan runs at start-up).
rtl/g42_core.sv:358 MAME port layouts (atarig42.cpp).
rtl/g42_core.sv:406 Road Riot: IN0 10 left trigger (MAME Button 2), 9 right trigger (Button 3), 8 start.
rtl/g42_core.sv:598 The test switch reaches the JSA III too (MAME main_test_read_line).
rtl/g42_core.sv:934 One line per frame: the 68000's bus address at VBLANK, for comparison with a MAME PC trace
rtl/g42_pkg.sv:19 MAME set_raw(14.318181 MHz / 2, 456, 0, 336, 262, 0, 240): 7.159 MHz dot clock, 15.700 kHz line, 59.923 Hz frame.
rtl/g42_pkg.sv:84 MAME's lookup tables reduce to bit slices (g42_rle_decode).
rtl/g42_pkg.sv:125 [1] ASIC65 is ROM-based: run the TMS32010 (Road Riot); else high-level (Guardians) [2] RTS at $080000 (Guardians, as MAME) [3] 32768 playfield tiles (else 16384)
rtl/g42_pkg.sv:132 RLE objects in the ROM (MAME
rtl/jsa3/g42_jsa3.sv:6 Follows MAME's atari_jsa_iii_device (atarijsa.cpp, "full map verified from schematics and Batman GALs") and is derived from the Atari G1 JSA II (g1_jsa2.sv), whose hardware-verified bus timing, JT51/JT6295 hookup and comm latches it keeps.
rtl/jsa3/g42_jsa3.sv:10 MAME 0.264 and current MAME behave the same for everything here.
rtl/jsa3/g42_jsa3.sv:12 6502 memory map (MAME atarijsa3_map).
rtl/jsa3/g42_jsa3.sv:30 Reads of the write block and of $2806 return 0, as MAME's unmapped/ack reads.
rtl/jsa3/g42_jsa3.sv:33 RDIO ($2804) and the 68000's raw port $E00012 (jsaiii_port): 0x80 self test, 1 = on 0x08 service (coin door), active high 0x40 command latch empty 0x04 tilt, active high 0x20 response latch full 0x02 coin L, active hi
rtl/jsa3/g42_jsa3.sv:46 WRIO ($2A04, MAME wrio_w): 0xC0 program ROM bank 0x04 OKI6295 reset, active low 0x30 coin counters (unused) 0x02 OKI bank bit 0 0x08 OKI6295 PIN7: 1 = /132 0x01 YM2151 reset, active low
rtl/jsa3/g42_jsa3.sv:51 MIX ($2A06, MAME mix_w): 0x20 low-pass filter enable (not emulated, nor by MAME) 0x10 OKI bank bit 1 0x0E YM2151 volume, 0-7 0x01 OKI6295 volume, 0 = half, 1 = full Overall volume ($2800 write): gain = data / 127 on YM and OKI.
rtl/jsa3/g42_jsa3.sv:65 6502 IRQ = periodic timer (249.7 Hz) OR YM2151 IRQ, as MAME's update_sound_irq(); $2806 read or write acknowledges the timer.
rtl/jsa3/g42_jsa3.sv:127 mono, half of MAME's level (see Mixer)
rtl/jsa3/g42_jsa3.sv:261 YM2151 CT1 output pin; gates the OKI as in MAME (see Mixer).
rtl/jsa3/g42_jsa3.sv:264 Reset values: WRIO as cleared (YM and OKI held in reset until the 6502 releases them, bank 0), PIN7 high and the volumes at MAME's reset values (1.0), which Guardians depends on.
rtl/jsa3/g42_jsa3.sv:301 The count restarts when the board leaves reset, as MAME re-arms its periodic timer when the 6502 is reset.
rtl/jsa3/g42_jsa3.sv:334 The image is the ROM file as-is for all three games (MAME's dangerex region moves the file's first 16 KB to $10000, which its 6502 never reads).
rtl/jsa3/g42_jsa3.sv:470 The programs poll busy before every write ($511F in Road Riot), so this keeps their write timing to the chip's (and MAME's).
rtl/jsa3/g42_jsa3.sv:543 Banking: the OKI's 18-bit address becomes a 19-bit address in the 512 KB sample ROM (MAME atari_jsa_oki_base_device::device_start).
rtl/jsa3/g42_jsa3.sv:598 The raw port as MAME builds it (jsa_iii_ioports).
rtl/jsa3/g42_jsa3.sv:598 The 6502 reads the same value: bits 4 and 7 are the test switch as the 68000 sees it, without MAME's 0x90 XOR (see header).
rtl/jsa3/g42_jsa3.sv:632 MAME (atarijsa.cpp JSA III + atarig42.cpp), mono, full scale = 1.0: out = 0.8 * ov * ( 0.60 * (L + R) * vol/7 + 0.75 * g * ct1 * oki ) ov = overall volume / 127, vol = MIX bits 3:1, g = 1.0 or 0.5 from MIX bit 0, ct1 = YM2151 CT1; L, R =
rtl/jsa3/g42_jsa3.sv:644 MAME peaks at 29089 in the Road Riot attract (overall $63) and would reach ~37300 at the top setting $7F; here that is ~18650.
rtl/jsa3/g42_jsa3.sv:646 Four loud OKI voices can still clip, as in MAME.
rtl/jsa3/g42_jsa3.sv:649 OKI gated by YM2151 CT1, as MAME's update_all_volumes().
rtl/jsa3/g42_sound_comm.sv:18 MAME instead clears them once per io_latch write with bit 4 low (m_jsa->reset()), so a command written while the board is held in reset survives there and is lost here.
rtl/jsa3/g42_sound_comm.sv:23 main_dout is captured when the 68000 read starts: a response written by the 6502 later in the same 68000 bus cycle then stays in the latch for the next read instead of being returned with its flag already cleared (MAME's read handler takes
rtl/mem/g42_rom_loader.sv:10 While the image goes by, two regions are also copied on chip: SDR_EEP 2 KB the factory EEPROM image -> g42_eeprom (eep_*), one byte at a time, so a game with no saved NVRAM starts from it as in MAME SDR_DSP 8 KB the ASIC65 TMS32010 prog
rtl/video/g42_alpha.sv:5 Follows MAME atarig42_v.cpp get_alpha_tile_info; line buffers as the G1 core's g1_alpha.sv.
rtl/video/g42_alpha.sv:15 Columns 48-63 of every row also hold the playfield control words (g42_scroll); like MAME, this layer does not special-case them (only 42 columns are ever on screen).
rtl/video/g42_mixer.sv:5 MAME atarig42_state::screen_update, with the palette address as the colour-MUX PALs build it (equations in the comments of init_roadriot / init_guardian in atarig42.cpp; CRAn = colour RAM address bit n):
rtl/video/g42_mixer.sv:22 MAME computes the playfield index as 32 * colour + pen: blend_gfx keeps the 5bpp element's granularity (32) although pens are 6 bits, so pen bit 5 adds into the tile colour and a sum can carry into bit 10 and beyond.
rtl/video/g42_mixer.sv:30 PF_MAME_FORM = 1 selects MAME's sum, truncated to 11 bits.
rtl/video/g42_mixer.sv:38 0: colour-MUX PAL form, 1: MAME's 32 * colour + pen
rtl/video/g42_palette.sv:5 CPU $FC0000-$FC0FFF: 2048 16-bit entries in MAME's IRGB_1555 format (PALETTE(config, "palette").set_format(palette_device::IRGB_1555, 2048)).
rtl/video/g42_palette.sv:12 Decode (MAME raw_to_rgb_converter::IRRRRRGGGGGBBBBB_decoder): the intensity bit is the shared LSB of three 6-bit channels, not a brightness flag; pal6bit expands 6 to 8 bits by repeating the top two:
rtl/video/g42_playfield.sv:5 Follows MAME atarig42_v.cpp (get_playfield_tile_info, the playfield scan mapper) and the gfx layouts of atarig42.cpp; line buffers and fetch order as the G1 core's g1_playfield.sv.
rtl/video/g42_playfield.sv:18 Pixels: 6 bits from the three thirds of MAME's "tiles" region, A (first), B, C, one 16-bit big-endian word per tile row each at SDRAM SDR_PFx + code * 16 + row * 2.
rtl/video/g42_playfield.sv:255 MAME code % elements: 14 or 15 bits
rtl/video/g42_scroll.sv:6 MAME atarig42_state::scanline_update:
rtl/video/g42_video.sv:15 MAME latches the control words of lines 0..255 (lines 240-255 are in VBLANK but still latch, and what they latch carries into the next frame's line 0), so the sequencer runs one job per line:
rtl/video/g42_video.sv:24 Every line's words are latched once a frame, in MAME's order, each just before its own fetch (so line 0 only after lines 240-255).
rtl/video/g42_video.sv:29 MAME reads the words of lines 8k..8k+7 at line 8k; this reads line L's at the start of line L-1.
rtl/video/g42_video.sv:60 playfield colour: 0 PAL form, 1 MAME form (g42_mixer)
rtl/video/g42_video_timing.sv:5 456 x 262 raster, 336 x 240 visible, from a 7.159090 MHz dot enable (MAME set_raw(14.318181 MHz / 2, 456, 0, 336, 262, 0, 240)); the counters and strobes are those of the hardware-proven G1 timing generator.
rtl/video/g42_video_timing.sv:24 MAME's totals come from published specs; the split is an estimate (the board's SOS chip is undocumented), so it is a parameter.
rtl/video/mob/g42_rle.sv:18 Command: every write to $FF7000 latches CHECKSUM if the value is 0, else DRAW (MAME mo_command_w; a byte write puts the byte on both halves, so "0" means the written byte is 0); NOP until the first write.
rtl/video/mob/g42_rle.sv:32 Pixel colour: MAME master aligns the pen base to the object's depth, pen = (palette base + (color << 4)) & ~((1 << bpp) - 1), pixel = pen + value (MAME 0.264 does not; see sim/rle/README.md).
rtl/video/mob/g42_rle.sv:318 Pen base bits 8:0: {color[4:0], 0000} with the object's low bpp bits cleared (MAME master's alignment); the packet value fills them.
rtl/video/mob/g42_rle.sv:462 MAME: scale > 0 && code < count
rtl/video/mob/g42_rle_checksum.sv:7 MAME atarirle.cpp:
rtl/video/mob/g42_rle_checksum.sv:17 Road Riot's ROM is 2 MB (16 chunks), Guardians' 6 MB (48), Danger Express' 8 MB (64); entries past the ROM stay 0, as in MAME.
rtl/video/mob/g42_rle_checksum.sv:21 The same snoop measures the ROM: rom_words is one past the highest RLE word written, which is MAME's m_rombase.length() for g42_rle_prescan (the RLE ROM is the last SDRAM region, so the download ends with it).
rtl/video/mob/g42_rle_fb.sv:6 MAME calls control_write((data >> 11) & 7) on every write that includes the upper byte; ctrl_wr pulses for each, and the "nothing changed" early return is made here:
rtl/video/mob/g42_rle_fb.sv:25 MAME's erases are instant; here each request latches its buffer and line range when made and waits in a 4-deep FIFO for the engine, which clears 4 pixels per clock (a full buffer in 20,160 clocks).
rtl/video/mob/g42_rle_fb.sv:27 rnd_hold is high while any erase of the render target is queued or running; g42_rle waits for it before drawing, so the erase lands first, as in MAME.
rtl/video/mob/g42_rle_fb.sv:101 MAME m_control_bits
rtl/video/mob/g42_rle_fb.sv:111 Both use the current FRAME (the write erases with the old bits), so they merge into one range; the VBLANK request is evaluated first, as in MAME.
rtl/video/mob/g42_rle_fb.sv:182 MAME device_reset: partial = -1
rtl/video/mob/g42_rle_objram.sv:6 MAME reads them in sort_and_render(), instantly at the MOGO; here a DRAW copies them into BRAM and releases the work RAM video port, which would otherwise be contended with the tile fetchers for a whole frame.
rtl/video/mob/g42_rle_objram.sv:10 The games start rewriting object RAM soon after the MOGO (earliest seen in MAME: Danger Express 3.8 lines, Guardians 7.5, Road Riot 13.2), so the copy has to be quick.
rtl/video/mob/g42_rle_objram.sv:16 Descriptor (modesc_0x200 / modesc_0x400 in atarig42.cpp), 8 words: word 0 [14:0] code, [15] hflip word 1 [9:4] color ($1F mask on Road Riot, $3F on the others; bit 9 is also priority bit 0), [11:9] priority word 2 [15:6] X position, 10-b
rtl/video/mob/g42_rle_pkg.sv:5 MAME build_rle_tables() fills one 256-entry table per encoding mode with (run << 8) | value, but every entry is a bit slice of its index, e.g. for 4bpp: table[i] = ((i & 0xF0) + 0x10) << 4 | (i & 0x0F), so value = i[3:0] and run = i[7:4] +
rtl/video/mob/g42_rle_pkg.sv:22 MAME's prescan_rle() rewrites any count with bit 15 set as its complement ("inverted"), and the renderer only ever reads counts the prescan has visited, so undoing it on the fly is exact.
rtl/video/mob/g42_rle_pkg.sv:56 Row count word as MAME's renderer sees it after prescan_rle()
rtl/video/mob/g42_rle_prescan.sv:5 After the ROM download this walks every object once (MAME prescan_rle()) and fills a table the render engine reads in one clock per object:
rtl/video/mob/g42_rle_prescan.sv:22 An object MAME treats as invalid (data offset below its own header entry or past the ROM) is stored as width 0, as is a valid object with no rows: MAME draws nothing for either, so width 0 simply means "skip".
rtl/video/mob/g42_rle_prescan.sv:28 Codes at or above obj_count are never looked up (MAME: code < m_objectcount).
rtl/video/mob/g42_rle_prescan.sv:53 ROM length in words (MAME length())
rtl/video/mob/g42_rle_prescan.sv:123 MAME stops a walk at 1024 rows
rtl/video/mob/g42_rle_prescan.sv:136 The 24-bit data offset of the header being read, and MAME's validity test: offset >= which * 4 && offset < length.
rtl/video/mob/g42_rle_prescan.sv:207 MAME: "base < end" ends the object at the ROM end after counting this row; its packets are cut off.
rtl/video/mob/g42_rle_prescan.sv:229 MAME's 1024-row cap
rtl/video/mob/g42_rle_render.sv:5 Port of the row loop of MAME draw_rle_zoom[_hflip]():
rtl/video/mob/g42_rle_render.sv:29 It does not fetch the tail of a row that lies past the far clip edge (src_limit), where MAME's clipped loop stops.
rtl/video/mob/g42_rle_render.sv:41 Pixels leave as {priority[2:0], index[8:0]}: pix_base holds the priority and the pen base (low bpp bits zero, MAME's alignment), the packet value fills the low bits.
rtl/video/mob/g42_rle_render.sv:442 synthesis translate_off The packet decode against MAME build_rle_tables(), every mode and byte (the ROM sets use only modes 0, 2 and 5).
rtl/video/mob/g42_rle_scaler.sv:5 The setup half of MAME draw_rle() and draw_rle_zoom[_hflip](), once per object:
rtl/video/mob/g42_rle_scaler.sv:25 MAME's clipped loops skip the pixels left of the screen (right of it when flipped) and stop at the other clip edge; its unclipped loops stop only when the row's runs end, which can be one or two pixels past the scaled width.
rtl/video/mob/g42_rle_scaler.sv:35 fetch src_limit = (dx/2 + k_last * dx) >> 16 is the last source pixel the far edge can reach; the renderer does not fetch the rest of a row (MAME's clipped loop stops there too).
README.md:13 working from MAME's source and the games' own test screens.
README.md:15 run in a full-system simulation against MAME, and it was then tested on a
README.md:136 **[MAME](https://www.mamedev.org/)**, the reference for the hardware's behaviour: `atarig42.cpp`, `atarig42_v.cpp` (Aaron Giles), `atarirle.cpp`, `asic65.cpp`,
README.md:138 No MAME code is compiled into the core.

Says it matches, follows or was checked against MAME — 3

rtl/jsa3/g42_jsa3.sv:43 Verified against MAME with that bit forced on (sim/jsa3/README.md).
rtl/video/g42_playfield.sv:20 pflayout + pftoplayout + blend_gfx(0, 2, $0F, $30) give, for pixel x (derived from the layouts' MSB-first bit offsets and checked against a generic MAME decode of every tile of every game, sim/video/py/check_pf_permutation.py):
README.md:14 checked in simulation against a MAME-derived reference, the whole core was

Says it was translated, ported or taken from MAME — 3

rtl/jsa3/g42_sound_comm.sv:5 Port of MAME's atari_sound_comm_device (atariscom.cpp): two single-byte latches, each with a full flag that drives an interrupt line as a level.
rtl/video/mob/g42_rle.sv:5 Port of MAME atarirle.cpp as configured by atarig42.cpp (modesc_0x200 for Road Riot, modesc_0x400 for Guardians and Danger Express), derived from the Atari G1 engine:
rtl/video/mob/g42_rle_sort.sv:5 Port of MAME sort_and_render():

Shares text with the MAME driver without saying so — 8

rtl/g42_pkg.sv:19 MAME set_raw(14.318181 MHz / 2, 456, 0, 336, 262, 0, 240): 7.159 MHz dot — shares text with atari/atarig42.cpp:584
rtl/jsa3/g42_jsa3.sv:300 Periodic IRQ: JSA_MASTER_CLOCK / 4 / 16 / 16 / 14 = 3579545 / 14336 — shares text with atari/atarijsa.cpp:793
rtl/jsa3/g42_jsa3.sv:544 512 KB sample ROM (MAME atari_jsa_oki_base_device::device_start). — shares text with atari/atarijsa.cpp:579
rtl/jsa3/g42_jsa3.sv:603 0x40 NMI line state, active low — shares text with atari/atarijsa.cpp:666
rtl/video/g42_palette.sv:6 (PALETTE(config, "palette").set_format(palette_device::IRGB_1555, 2048)). — shares text with atari/atarig42.cpp:573
rtl/video/g42_video_timing.sv:6 (MAME set_raw(14.318181 MHz / 2, 456, 0, 336, 262, 0, 240)); the counters — shares text with atari/atarig42.cpp:584
rtl/video/mob/g42_rle_pkg.sv:7 4bpp: table[i] = ((i & 0xF0) + 0x10) << 4 | (i & 0x0F), so value = i[3:0] — shares text with atari/atarirle.cpp:292
rtl/video/mob/g42_rle_render.sv:10 sourcex = dx / 2, rle_end = 0 — shares text with atari/atarirle.cpp:611

Arcade-Bakraid (zakk4223)#
Battle Bakraid - Unlimited Version, Battle Bakraid
zakk4223/Arcade-Raizing_MiSTer @ 2ea8aa8d
MAME compared: toaplan/raizing_batrider.cpp + 9 related file(s)
Read: 17 HDL files, 8,846 lines (Quartus project)

zakk4223
repository only

Not enough evidence in the code

insufficient

Statements: 1 not counted

Cites hardware references or measurements that MAME's driver also gives — 1

cores/bakraid/hdl/model/bakraid_game.v:143 68K ROM — also in MAME: 68K toaplan/raizing.cpp:230

Arcade-BallySente (ppriest)#
Chicken Shift, Goalie Ghost, Gimme A Break, Grudge Match …
ppriest/Arcade-BallySente_MiSTer @ ccf8dd92
MAME compared: bally/balsente.cpp + 5 related file(s)
Read: 21 HDL files, 7,487 lines (Quartus project)

ppriest
repository only

Mostly MAME

medium

40%

Statements: 1 toward hardware, 96 toward MAME

Cites hardware documentation that MAME's driver does not — 1

rtl/video/video_timing.sv:16 MAME's set_raw() carries no sync position -- it models blanking only -- and there is no schematic here.

Cites MAME source — 83

BallySente.sv:36 The 6VB's six voices, mono (sente6vb.cpp routes all six to one speaker).
BallySente.sv:176 MAME's default keys, ORed into the pads so every reader of joystick_0/1 sees them.
rtl/acia6850.sv:6 It is transcribed rather than written from the datasheet for the same reason as the 8253 (rtl/sound/pit8253.sv): MAME is the reference, and the main program's timing depends on details the datasheet leaves open.
rtl/acia6850.sv:10 cshift sends 0xE0 at boot and polls status until the 6VB answers, which it does when its calibration ends (frame 560 in MAME); after that it streams commands one character time apart -- ~400 CPU cycles, 10 bits x 16 / 500 kHz -- pacing itse
rtl/acia6850.sv:16 THE PROTOCOL cshift uses, from MAME's trace.
rtl/acia6850.sv:18 Streaming after that is polled, so status reads return 0x02 -- TDRE set, IRQ clear -- on every one of MAME's 479,062 polls.
rtl/acia6850.sv:27 The IRQ output is delayed one clk_sys cycle, standing in for MAME's `scheduler().synchronize()` in output_irq(): the status IRQ bit and the pin both change after the access that caused them, not during it.
rtl/acia6850.sv:78 MAME's m_irq: 1 = inactive
rtl/acia6850.sv:267 MAME shifts the parity bit in too, as bit 8 of an int, and truncates it away in the 8-bit m_rdr.
rtl/acia6850.sv:309 -------------------------------------------------------- irq One cycle late, as MAME's synchronize() is: the status bit and the pin follow the access that changed them.
rtl/adc.sv:3 The main board's ADC, as balsente_m.cpp models it (adc_select_w, adc_finished, adc_data_r).
rtl/adc.sv:6 A write to 0x9000-0x9007 selects a channel and starts a conversion that ends 50 us later -- a later select restarts it (MAME re-arms its timer; Mini Golf depends on the delay).
rtl/adc.sv:11 With `raw` (MAME's shift of 32, Stompin' and Shrike) the channel reads its port directly; `raw_ob` makes that port offset binary, 0x80 at rest, as Shrike Avenger's stick is (MAME AD_STICK with a default of 0x80), where the ports here are si
rtl/analog_inputs.sv:3 The four analog ports the ADC converts (MAME's AN0-AN3), made from MiSTer's mouse, analog sticks and spinners and latched once a frame at the start of vblank, as balsente_m.cpp update_analog_inputs() caches them.
rtl/analog_inputs.sv:9 [7] reverse (MAME's PORT_REVERSE): the value is negated [6] half: MAME sensitivity 50 rather than 100
rtl/analog_inputs.sv:17 Trackballs and dials are relative (MAME's PORT_RESET): the movement since the last frame, clamped to a signed byte.
rtl/analog_inputs.sv:18 Player 1's comes from the mouse; any player's also from its analog stick as a rate, and from its d-pad as MAME's default mapping does, down increasing Y, but at 10 a frame where MAME's PORT_KEYDELTA is 20: 20 was reported too fast on hardwa
rtl/analog_inputs.sv:22 Sticks are absolute, the position as a signed byte, plus a position the d-pad moves as MAME's keys move an AD_STICK: PORT_KEYDELTA(20) a frame while held, and back toward centre by the same 20 (its centre delta) once released.
rtl/analog_inputs.sv:26 MAME's screen Y grows downward and a PS/2 mouse's grows upward, so the mouse's Y is negated.
rtl/balsente_core.sv:33 rtl/main_bus.sv; 0 only to compare with MAME
rtl/balsente_core.sv:120 Shrike Avenger's sprite bank, delayed as MAME's shrike_sprite_select_w() delays it (the palette bank's rule, rtl/video/video.sv): a write during raster line v shows from line v + 16.
rtl/balsente_core.sv:165 A bit in configuration bytes 8 (IN0) or 9 (IN1) is MAME's PORT_TOGGLE, Stocker's gear shift: each press flips it, and it reads pressed (low) while on.
rtl/balsente_core.sv:167 It starts off, as MAME's does.
rtl/balsente_core.sv:197 Everything else is released on the clock where the raster reaches the point reset puts it at -- line 256, pixel 0, the start of a pixel -- so the machine starts in the state sim/board_tb and MAME start in.
rtl/balsente_core.sv:287 MAME's level peaks near -20 dBFS in every game recorded (debug/*-snd), under a MiSTer's noise floor; x8, saturating (docs/HACKS.md).
rtl/game_board.sv:24 See rtl/main_bus.sv: 1 floats an undriven read as the board does, 0 is MAME's 0x00.
rtl/game_board.sv:25 Passed through so a bench can compare against MAME.
rtl/game_board.sv:62 The analog ports the ADC converts (rtl/analog_inputs.sv), and how the game reads them (MAME's config_shooter_adc: a shift, or raw)
rtl/game_board.sv:69 teamht's input groups; Grudge Match's three wheel positions; Night Stocker's gun position (MAME's FAKEX/FAKEY, 0x80 at the centre)
rtl/game_board.sv:162 A blank X2212 reads 0xF in every nibble (MAME x2212.cpp nvram_default).
rtl/game_board.sv:197 Line 0 (once, after reset) presents 0: MAME shifts by -1 there.
rtl/game_board.sv:257 -------------------------------------------------------------- ACIA Clocked by the 6VB's 500 kHz output, which is already the inverse of that board's own ACIA clock (sente6vb.cpp uart_clock_w).
rtl/grudge_steering.sv:3 Grudge Match's steering register at 0x9400, as balsente_m.cpp models it (update_grudge_steering, grudge_steering_r).
rtl/irq_timer.sv:5 balsente_m.cpp `interrupt_timer()`.
rtl/lightgun.sv:3 Night Stocker's gun: MAME's FAKEX/FAKEY ports (0..255, 0x80 at the centre), which the board reads two bits at a time (game_board.sv), and a crosshair where the gun points, since the monitor has none.
rtl/lightgun.sv:16 MAME's crosshair instead spreads 0-255 over the 240 visible rows, which puts it 16 lines low.
rtl/main_bus.sv:6 From balsente.cpp `cpu1_base_map` and balsente_m.cpp.
rtl/main_bus.sv:23 Some cartridges change the map (`cfg_variant`, balsente.cpp cpu1_*_map): 1 teamht 9000-9007 w selects an input group, 9404 r reads it; no ADC 2 grudge 9400 r is the steering register, not the ADC 3 spiker 9f80-9f8f rw the pixel-exp
rtl/main_bus.sv:44 0 is MAME, which returns its unmapped value of 0x00 for both.
rtl/main_bus.sv:44 Kept as a parameter rather than deleted because the bus-trace diff against MAME is the only verification this board has, and an open bus diverges from it on every NOVRAM read.
rtl/main_bus.sv:177 ------------------------------------------------------------ variants teamht_multiplex_select_w: offsets 4-7 load an input group into the latch 9404 reads; 0-3 leave it (MAME logs them as unhandled).
rtl/main_bus.sv:248 ------------------------------------------------- cartridge mapping balsente.cpp expand_roms(): bank pointers, not a ROM transform.
rtl/main_bus.sv:275 -------------------------------------------------- hardware random balsente_m.cpp poly17_init() and random_num_r().
rtl/main_bus.sv:279 MAME indexes it by `total_cycles * 12.5` -- 12 steps on an even CPU cycle and 13 on an odd one -- because it computes (cc<<3)+(cc<<2)+(cc>>1).
rtl/main_bus.sv:283 Reproduced anyway, because MAME is the reference and a different value desynchronises a bus trace immediately; docs/MAME_KLUDGES.md has the entry.
rtl/main_bus.sv:298 computed at 24 bits then masked to 17, as MAME's & POLY17_SIZE does
rtl/mame_keys.sv:1 MAME's default keys (src/emu/inpttype.ipp) in hps_io's joystick layout, to OR into joystick_0/1: right, left, down, up at bits 0-3, buttons 1-6 at 4-9, Start, Coin, Pause, Service at the J1 line's own positions (parameters).
rtl/mame_keys.sv:7 P1 arrows, LCtrl LAlt Space LShift Z X, 1 start, 5 coin P2 R F D G, A S Q W E (MAME gives P2 no sixth key), 2 start, 6 coin F2 service (test) switch, 9 and 0 service coins 1 and 2, P pause
rtl/mame_keys.sv:24 MAME's Service 1, 2: wire to the board's SERVICE1/2 bits, if any
rtl/memory/dpram_tdp.sv:14 A write on both ports to one address in one clock is undefined, as on the M10K; the two CPUs here do not arbitrate, as MAME does not.
rtl/shrike_board.sv:3 Shrike Avenger's second board: a 68000 with its own 16 KB program, 4 KB of RAM shared with the 6809, and sixteen I/O words, as MAME models it (balsente.cpp shrike68k_map and cpu1_shrike_map, balsente_m.cpp shrike_*).
rtl/shrike_board.sv:21 Two exceptions (shrike_shared_6809_r/_w): 9E06 reads 0, MAME's "motors OK" until the motion base is modelled -- MAME has none -- and a write to 9E01 also selects the sprite bank (shrike_sprite_select_w).
rtl/shrike_board.sv:24 MAME computes that bank as (data & 0x80 >> 7) ^ 1, which C parses as (data & 1) ^ 1: data bit 0 clear selects the upper 64 KB.
rtl/shrike_board.sv:28 Clock: MAME runs the 68000 at 8 MHz.
rtl/video/sprite_engine.sv:12 A sprite pixel is the HIGH nibble of a palette index and the background supplies the low nibble, and each sprite reads that low nibble from the BACKGROUND rather than from an earlier sprite's result (balsente_v.cpp: `old` points into the ex
rtl/video/sprite_engine.sv:29 MAME walks ypos from `sprite[2] + 17 + VBEND` -- which reaches 288 and is NOT masked on the first iteration -- masking only after each increment.
rtl/video/sprite_engine.sv:123 9 bits, because MAME keeps currx as an int and clips at 256: a sprite at x=252 loses its right-hand pixels rather than wrapping to the left edge.
rtl/video/video.sv:43 0 is the natural one and is what sim/video_tb mirrors; the board passes 256 so its raster is in the same phase as MAME's screen, which starts at vblank.
rtl/video/video.sv:124 MAME's palette_select_w() redraws up to vpos() - 1 + VBEND before a bank change, and vpos() is already absolute, so a write during raster line v shows from line v + 16 on, a whole line at a time (docs/MAME_KLUDGES.md).
rtl/video/video_timing.sv:7 Geometry from balsente.h, through MAME's set_raw():
rtl/video/video_timing.sv:16 MAME's set_raw() carries no sync position -- it models blanking only -- and there is no schematic here.
rtl/video/video_timing.sv:35 MAME starts a screen at VBLANK START, so a bench comparing against its trace must too or every VBLANK the CPU reads is a whole frame out of phase.
README.md:3 A MiSTer FPGA core for Bally/Sente's SAC-I arcade hardware (MAME's `bally/balsente.cpp`), built with Quartus Prime 17.0.2 Lite for the DE10-nano.
README.md:45 MAME lists 41 sets; 39 are on SAC-I hardware and in scope.
README.md:78 | MAME description | Why |
README.md:80 | Trivial Pursuit (Volumen IV / Volumen V, Spanish, Maibesa hardware) (`triviaes4`, `triviaes5`) | different Maibesa hardware (MC6845 CRTC, Z80 with 2×AY8910 an
README.md:90 | CEM3394 ×6 | synthesiser voices: oscillator, 4-pole filter, mixer, VCA | written here from MAME's numerical model, in fixed point; one oscillator, one filter
README.md:91 | MM5837 | noise source into every voice | written here, from MAME's `mm5837` |
README.md:93 | main board logic | address decode, bank mapper, palette bank, random number source, interrupt timer | written here from `balsente.cpp` and `balsente_m.cpp` |
README.md:94 | video | 4bpp bitmap and a line-buffered sprite engine, racing the beam as the board does | written here from `balsente_v.cpp`, checked against a beam-accurate
README.md:110 The core models the chips from MAME's numerical CEM3394 model, in fixed point at 96 kHz.
README.md:122 The numbers are MAME's `set_raw()` for the driver; there is no PCB measurement.
README.md:239 MAME plays that calibration (`docs/MAME_KLUDGES.md`).
README.md:296 MAME is the accuracy reference, with its own acknowledged uncertainties noted where they matter.
README.md:299 **Main CPU:** 400,000 bus cycles of `sentetst` from reset against MAME's trace; all 52,232 writes identical in address, data and order.
README.md:301 **Sound CPU:** 1,200,000 bus accesses against MAME's trace; all reads and writes identical in address and data (one instruction orders its two writes differentl
README.md:307 **Video:** six MAME beam captures against a beam-accurate model, 0 differing pixels each.
README.md:310 **Sound calibration:** the 6VB's boot calibration against MAME's I/O trace; the voice, mode, control voltage and count match on every measurement.
README.md:312 **Sound:** the fixed-point specification against MAME's Chicken Shift recording, 10 s in-game: level +0.01 dB, worst octave 0.20 dB, envelope correlation +0.986
README.md:314 The RTL against that specification, driven by MAME's recorded 6VB writes: 1,920,000 samples, 698,696 writes, 0 mismatches.
README.md:324 The **MAMEdev team** — Aaron Giles for `balsente.cpp` and the CEM3394, m1macrophage for the CEM3394's current model and the `va_*` primitives it is built from —
README.md:345 | `debug` | reference captures from MAME used as ground truth (gitignored) |
README.md:346 | `roms` | your own MAME sets (gitignored, never committed) |

Says it matches, follows or was checked against MAME — 4

rtl/grudge_wheels.sv:3 Grudge Match's three steering wheels as positions (MAME's AN0-AN2 dials, not PORT_RESET), for grudge_steering.sv, which reports only which way each moved between interrupts.
README.md:86 | MC6809E @ 1.25 MHz | main CPU | vendored: Greg Miller's `mc6809i`, jotego's clock-enable fork; checked against MAME's bus trace |
README.md:87 | Z80 @ 4 MHz | 6VB sound CPU | vendored: MiSTer-devel T80, unchanged; checked against MAME's bus trace |
README.md:114 `scripts/sente6vb_audio.py` is the integer specification: it matches MAME's recorded Chicken Shift audio in level to 0.01 dB and in every octave band to 0.2 dB,

Says it was translated, ported or taken from MAME — 4

rtl/acia6850.sv:3 Motorola 6850 ACIA, transcribed from MAME's devices/machine/6850acia.cpp.
README.md:88 | MC6850 ACIA ×2 | the serial link between the boards | written here, transcribed from MAME's `6850acia.cpp` |
README.md:89 | 8253 PIT | 6VB timing and the oscillator measurement | written here, transcribed from MAME's `pit8253.cpp`; modes 0 and 1 only (all the boot uses) |
README.md:243 `docs/MAME_KLUDGES.md` lists what is taken from MAME as behaviour and what is known not to be right.

Keeps a MAME approximation — 1

README.md:116 The mix is raised 18 dB over MAME's level, which is too quiet for a MiSTer (`docs/HACKS.md`).

Shares text with the MAME driver without saying so — 4

rtl/adc.sv:11 games seem to have a dead zone in the middle"), and clipped to 255. With — shares text with bally/balsente_m.cpp:296
rtl/irq_timer.sv:16 HBLANK -- `m_irq_off_timer->adjust(time_until_pos(param, BALSENTE_HBSTART))` — shares text with bally/balsente_m.cpp:39
rtl/main_bus.sv:280 and 13 on an odd one -- because it computes (cc<<3)+(cc<<2)+(cc>>1). — shares text with bally/balsente_m.cpp:153
rtl/video/sprite_engine.sv:26 +2 Y position, offset by 17 and then by VBEND, wrapping at 256 — shares text with bally/balsente.cpp:78

Arcade-Batrider (zakk4223)#
Armed Police Batrider
zakk4223/Arcade-Raizing_MiSTer @ 2ea8aa8d
MAME compared: toaplan/raizing_batrider.cpp + 9 related file(s)
Read: 16 HDL files, 5,428 lines (Quartus project)

zakk4223
repository only

Not enough evidence in the code

insufficient

Statements: 1 not counted

Cites hardware references or measurements that MAME's driver also gives — 1

cores/batrider/hdl/model/batrider_game.v:145 68K ROM — also in MAME: 68K toaplan/raizing.cpp:230

Arcade-BlackWidow (blahm1dplays)#
Black Widow, Gravitar
blahm1dplays/Arcade-BlackWidow_MiSTer @ b1d0da18
MAME compared: atari/bwidow.cpp + 2 related file(s)
Read: 22 HDL files, 6,231 lines (Quartus project)

blahm1dplays
repository only

Not enough evidence in the code

insufficient

Statements: 3 toward MAME, 2 not counted

Cites hardware references or measurements that MAME's driver also gives — 2

rtl/pgmrom.vhd:57 136017-101.d1 4096 0 0000 000000000000 136017-102.ef1 4096 4096 0001 000000000000 136017-103.h1 4096 8192 0010 000000000000 136017-104.j1 4096 12288 0011 000000000000 136017-105.kl1 4096 16384 0100 000000000000 136017-106.m1 4096 2048 — also in MAME: 136017-101 atari/bwidow.cpp:855, 136017-102 atari/bwidow.cpp:856, 136017-103 atari/bwidow.cpp:857, 136017-104 atari/bwidow.cpp:858, 136017-105 atari/bwidow.cpp:859, 136017-106 atari/bwidow.cpp:860
rtl/vecrom.vhd:50 136017-107.l7 2048 24576 0110 000000000000 blank 2048 26624 0110 100000000000 136017-108.mn7 4096 28672 0111 000000000000 136017-109.np7 4096 32768 1000 000000000000 136017-110.r7 4096 36864 1001 000000000000 — also in MAME: 136017-107 atari/bwidow.cpp:850, 136017-108 atari/bwidow.cpp:851, 136017-109 atari/bwidow.cpp:852, 136017-110 atari/bwidow.cpp:853

Cites MAME source — 3

rtl/avg/avg.vhd:325 thanks to the mame source for this line.
README.md:19 in your MiSTer's `games/mame/` folder.
README.md:109 The broader **MiSTer** and **MAME** communities — Atari AVG hardware lineage and reference models.

Arcade-DEC8 (shmupfan)#
Makyou Senshi, Last Mission, SRD: Super Real Darwin
shmupfan/Arcade-DEC8_MiSTer @ 373e4834
MAME compared: dataeast/ghostb.cpp, dataeast/lastmisn.cpp, dataeast/srdarwin.cpp + 8 related file(s)
Read: 23 HDL files, 9,298 lines (Quartus project)

shmupfan
repository only

Mostly MAME

medium

32%

Statements: 5 toward hardware, 74 toward MAME

Cites hardware documentation that MAME's driver does not — 3

rtl/d8_board.sv:26 The MRA streams the ROMs as dumped and the board swaps the sprite word address bits 0 and 1 instead (every lane of a sprite word comes from the same region offset, tools/gfx_layout.py), which reads the same data as MAME's fixed-up region.
rtl/d8_board.sv:194 AC coupling: the boards couple every source into the amplifier through capacitors (4.7 uF after each YM3014 buffer, the SSG through its network; LM-SCH sheet 27, GONDO-TSM sheet 28), so the amplifier never sees DC.
rtl/d8_snd.sv:43 The schematics' equal 10 kOhm summing resistors (Last Mission sheet 27, Gondomania sheet 28) do not give 1:1: the chips' DAC words differ in level.

Reports a measurement taken on the original PCB — 1

rtl/d8_board.sv:190 ------------------------------------------------------------------ audio d8_snd's mix (YM2203 FM + SSG + OPL at the PCB-measured balance, R20), AC coupled, times a per-machine gain in 1/16 steps, then the OSD volume, saturated.

Notes where it differs from MAME — 1

README.md:114 Gondomania's random numbers in gameplay and SRD's MCU timing differ from MAME because of it (docs/m2_findings.md).

Cites MAME source — 70

Arcade-DEC8.sv:133 keyboard, MAME default keys (ps2_key: [10] toggles per event, [9] pressed, [8] extended, [7:0] set-2 scancode) P1: arrows, LCtrl = B1, LAlt = B2, Space = B3, Z / X = turn left / right (Gondomania), 1 = Start, 5 = Coin P2: R/F/D/G, A = B1, S
Arcade-DEC8.sv:188 inputs, active low, in MAME's port layout (dec8.cpp L824-904, L1028-1116, L1552-1622; the vblank bits are merged inside d8_sys) Last Mission IN0/IN1 = P1/P2: 0 up, 1 down, 2 left, 3 right, 4 shoot, 5 bomb, 6 select; IN2: 2 start 1, 3 start
Arcade-DEC8.sv:267 video: 256 x 240 (MAME visarea 0-255 x 8-247), ROT270 for all three games: the picture is turned 90 degrees counter-clockwise (MAME).
rtl/d8_board.sv:19 254 DIP switches: byte 0 = DSW0 (SW1), byte 1 = DSW1 (SW2), MAME's port layout.
rtl/d8_board.sv:24 srdarwinb's sprite ROMs hold bytes 1 and 2 of every 4-byte group swapped (MAME init_srdarwinb, dec8.cpp L4097-4110, swaps them back after loading).
rtl/d8_board.sv:26 The MRA streams the ROMs as dumped and the board swaps the sprite word address bits 0 and 1 instead (every lane of a sprite word comes from the same region offset, tools/gfx_layout.py), which reads the same data as MAME's fixed-up region.
rtl/d8_board.sv:45 inputs as MAME's ports (active low, vblank bits merged in d8_sys)
rtl/d8_mcu.sv:1 i8751 MCU for the DEC8 boards (PLAN M2): jt8051 with its program ROM and internal RAM, wired exactly as jtframe's jtframe_8751mcu (jtcores a72a4460, the wrapper jt8051 is verified in): the ROM address is registered every clock, ROM and RAM
rtl/d8_mcu.sv:7 `cen` is the 8 MHz oscillator enable (96 MHz / 12): a machine cycle is 12 of them (1.5 us), MAME's I8751 at 8 MHz (dec8.cpp:1997, 2111, 2426).
rtl/d8_mcu.sv:29 SFR write events (MAME port_out callbacks fire on every port write)
rtl/d8_rotary.sv:3 The board reads the rotary as a 12-bit one-hot code (d8_sys R_P1ROT*, dec8.cpp gondo_player_*_r); i_an0/i_an1 of d8_sys take MAME's AN port value, 0-11.
rtl/d8_rotary.sv:5 MAME's port (dec8.cpp L1081-1085) is PORT_POSITIONS(12) PORT_WRAPS PORT_REVERSE with Z (decrement) and X (increment) for player 1, so the increment key lowers the value the game reads.
rtl/d8_rotary.sv:7 Here "turn right" is MAME's increment key (X for player 1, M for player 2) and lowers `pos`; "turn left" (Z, N) raises it.
rtl/d8_rotary.sv:9 Which way that turns the soldier on screen is what MAME's key assignment gives; not checked on a real controller.
rtl/d8_rotary.sv:12 Three ways to turn, all active at once (no OSD switch needed): buttons Turn Left / Turn Right (keys or a gamepad): one step per press, then repeated every 100 ms after 250 ms held spinner hps_io spinner: [7:0] signed delta, [8] toggles
rtl/d8_snapram.sv:10 MODE 2: two-stage snapshot for the sprite list (spec 8, tecmo16.cpp:330-341): on `snap`, S2 <= S and S <= L at that clock, the renderer reads S2.
rtl/d8_snapram.sv:12 MAME draws frame N from the buffer as it stood at vblank N-1, which holds the live RAM of vblank N-2; S is that buffer, S2 the copy the line renderer reads during frame N.
rtl/d8_snapram.sv:16 MAME's copy is instantaneous at the vblank callback.
rtl/d8_snd.sv:3 Reference: MAME 0.288 dataeast/dec8.cpp (reference/mame/v0288/), "dec8:L" = line numbers there; "spec N" = docs/dec8_system_spec.md.
rtl/d8_snd.sv:6 lastmisn R65C02 1.5 MHz (12 MHz / 8, dec8:1992), ym3526_s_map (dec8:651-658): RAM 0000-05FF, YM2203 0800-0801, YM3526 1000-1001, latch read 3000, ROM 8000-FFFF gondo R65C02 1.5 MHz (dec8:2109), oscar_s_map (dec8:635-641): YM2203 2000-2
rtl/d8_snd.sv:22 The chips are mapped write-only in MAME; a 6502 read of them returns the unmapped value 0, as does any other unmapped read.
rtl/d8_snd.sv:23 The oracle's sound log (sim/mame/d8_oracle.lua SNDLOG) shows the sound programs never read the chips (m3_findings).
rtl/d8_snd.sv:39 Measured on a real SRD board (PCB capture of power-on and both demos, fitted against this core's chip outputs over 100 s): OPL:FM 1.65 (90% interval 1.60-1.77 before MAME-bias correction), SSG 3400-3900 for FM 102.
rtl/d8_snd.sv:45 MAME: OPL 2x on lastmisn/srdarwin, 1.25x on gondo.
rtl/d8_snd.sv:49 0.40 (MAME's FM route)
rtl/d8_snd.sv:50 PCB fit (MAME 2775: 0.20 per channel on jt49's sum)
rtl/d8_snd.sv:51 PCB fit, 1.67 x FM (MAME 0.80 = 205)
rtl/d8_snd.sv:52 as OPL_GAIN (MAME 0.50 = 128)
rtl/d8_snd.sv:93 37,464 is the reset length of the M2/M3 harness (m2/tb_sys.cpp), so the sound board leaves reset in exactly the state the M3 results (compared with MAME) were measured from: 585 YM2203 and 1,170 OPL enables, enough to fill the chips' pipeli
rtl/d8_sys.sv:3 Reference: MAME 0.288 dataeast/dec8.cpp (and dec8_v.cpp, cpu/mcs51, machine/input_merger) vendored in reference/mame/v0288/; "spec N" = docs/dec8_system_spec.md, "dec8:L" = dec8.cpp line numbers.
rtl/d8_sys.sv:28 RAM and I/O: the main CPU's access at ph = SLOT_M, the sub CPU's at SLOT_S (lastmisn shares the video, work RAM and I/O between the two CPUs; MAME runs them instruction by instruction with no contention), writes as a single strobe at the sl
rtl/d8_sys.sv:55 inputs as MAME's ports (active low), DIPs, rotary positions (gondo)
rtl/d8_sys.sv:208 MAME maps this address (for the unmapped counter)
rtl/d8_sys.sv:372 MAME screen vblank: lines 248-271 and 0-7
rtl/d8_sys.sv:534 NMI enable timer: one 6309 cycle (32 clocks), MAME's m_nmi_timer->adjust(minimum_quantum_time()) (dec8:204-206, R8)
rtl/d8_sys.sv:629 ================================================================ interrupts MAME screen vblank: true from line 248 to the end of line 7 vblank_l = (line >= 248 || line < 8), as a register in d8_video (M4: the comparator on the line counter
rtl/d8_sys.sv:646 ================================================================ MCU P0/P1 inputs: the external latches (dec8:689-707); P2 not hooked (MAME reads 0xff); P3 = COIN.
rtl/d8_video.sv:4 "spec N" = docs/dec8_system_spec.md; dec8/v/krn line numbers = reference/mame/v0288/dec8.cpp, dec8_v.cpp, deckarn.cpp.
rtl/d8_video.sv:7 Contents: - raster: 384 pixels per line at a 6 MHz pixel enable (96 MHz / 16), 272 lines, visible 256 x 240 at lines 8-247, vblank from line 248 (dec8:1977-1981, "DECO video CRTC, matches PCB measurements") - CPU-side RAMs, byte wide on the
rtl/d8_video.sv:21 MAME draws each frame once at vblank; m1_findings lists every frame where that differs.
rtl/d8_video.sv:23 - KRN_FLIP = 0 (default, MAME, PLAN 5.4): the Karnov sprites of lastmisn/gondo are not flipped with the screen (dec8.cpp never sets the sprite chip's flip flag, R7); 1 applies the chip's flip path (krn:79-86) whenever the screen is flipped
rtl/d8_video.sv:63 m_scroll[i_scr_sel] = din (MAME's 4 scroll bytes)
rtl/d8_video.sv:89 current line (M2: MAME's vblank = lines 248-271, 0-7)
rtl/d8_video.sv:90 MAME's vblank (lines 248-271, 0-7), registered (M4 timing)
rtl/d8_video.sv:117 power-on phase as MAME: the screen starts at the first vblank line
rtl/d8_video.sv:143 MAME m_scroll[0..3]: x MSB, x LSB, y MSB, y LSB
rtl/d8_video.sv:240 bg logical line: (line + sy) unflipped, (sy + 255 - line) flipped (tilemap.cpp, spec 3); srdarwin has no y scroll and is 256 high
rtl/d8_video.sv:662 DECO RM-C3 (decrmc3.cpp:214-224): R = bits 0-3, G = 4-7, B = ext 0-3, each bit weighted 0x0e, 0x1f, 0x43, 0x8f
rtl/vendor/jt8051/jt8051.v:29 DEC8 patch 1 (PROVENANCE.md): SFR write port for the MAME-style port write callbacks (MAME calls port_out_cb on every write to P0-P3)
rtl/vendor/jt8051/jt8051.v:34 DEC8 patch 2: MAME's set_port_forced_input for P0: a pin read returns (latch | p0_force) & p0_i (mcs51 p0_r, i8051.cpp:282-285)
README.md:3 Three vertical shooters on Data East's 1986-87 8-bit boards, from one RBF: Last Mission, Gondomania and SRD: Super Real Darwin, ten MAME sets.
README.md:16 The sound CPU is the 6502A named in the Last Mission and Gondomania board documents (MAME emulates an R65C02) and Data East's DECO 222 on SRD.
README.md:52 Which set to play: the World parents of Last Mission and Gondomania, and the Japanese SRD, carry MCU programs that MAME marks as bad dumps (Gondomania's is hand
README.md:56 The bad-dump sets are offered because they are the parent sets in MAME.
README.md:73 The buttons are named per game in the MAME driver's terms: Last Mission Shoot, Bomb, Select; Gondomania and SRD Button 1, Button 2.
README.md:79 Turn Right is MAME's increment key (X), which lowers the position the game reads, as MAME's reversed port does.
README.md:85 DIP switches per set, every switch the MAME driver names, with MAME's defaults (see Accuracy notes for the operator manuals).
README.md:87 Aspect ratio, Orientation (Vertical, Horizontal), Rotate (CCW, the MAME direction, or CW for monitors mounted for the other rotation), scandoubler effects, HDMI
README.md:104 MAME 0.288 is the reference.
README.md:107 Where MAME and the hardware are likely to differ, the core follows the most plausible hardware behaviour and the difference is logged as a research item in docs
README.md:112 **i8751 interrupt timing** follows Intel's documented response (at least three machine cycles), where MAME enters the handler at the next instruction.
README.md:116 **Sound CPU timing.** Two cycle-count errors in the vendored jt65c02 (ADC/SBC one cycle long, untaken branches 2.25 cycles) are fixed to the 6502 data sheets, w
README.md:124 On the board the music chip (YM3526 / YM3812) plays at 1.65 times the effects chip (YM2203 FM); MAME uses 2 times.
README.md:125 The core uses 1.67, and the YM2203's square-wave channels about 3 dB above MAME's level, also from the recording.
README.md:133 **Mid-screen writes** (palette, tiles, scroll) are drawn as the beam meets them; MAME draws each frame at once.
README.md:135 **Gondomania's main CPU** runs at 3 MHz as in MAME.
README.md:138 **DIP switches**: the Last Mission and Gondomania operator manuals (Data East USA) list the same switches as MAME, except three that MAME found in the program c
README.md:142 The core offers them as MAME does.
README.md:142 The Last Mission manual gives the second bonus life setting as 40K/70K and every 90K; the program's tables in the World, US revision 6 and US revision 5 sets al
README.md:175 The core relies on MAME's DEC8 driver by Bryan McPhail and Stephane Humbert.

Says it matches, follows or was checked against MAME — 3

rtl/d8_video.sv:3 Reference model: sim/oracle/d8_render.py, pixel-exact against MAME 0.288 on every M0 capture.
rtl/vendor/jt65c02/jt65c02_regs.v:87 to start up the same as MAME.
README.md:104 Every part of the core was checked against it in simulation: the video against 12,678 MAME frames (pixel-exact), the full systems from power-on against MAME's I

Shares text with the MAME driver without saying so — 1

rtl/d8_video.sv:10 (dec8:1977-1981, "DECO video CRTC, matches PCB measurements") — shares text with dataeast/ghostb.cpp:1095

Arcade-DemoDerby (alanswx)#
Demolition Derby
alanswx/Arcade-DemoDerby_MiSTer @ b5001e46
MAME compared: bally/mcr.cpp + 7 related file(s)
Read: 16 HDL files, 10,708 lines (Quartus project)

alanswx
repository only

Not enough evidence in the code

insufficient

21%

Statements: 1 toward hardware, 4 toward MAME, 2 not counted

Cites hardware documentation that MAME's driver does not — 1

rtl/dderby.vhd:74 Sprite are 32x32 pixels with 1x1 pixel definition, 16 lines for odd 1/2 frame and 16 lines for even 2/2 frame thanks to V8 on sprite rom ROMAD2 (look at 74ls86 G1 pin 9 on video genration board schematics)

Cites hardware references or measurements that MAME's driver also gives — 2

rtl/dderby.vhd:873 background graphics ROM 6F bg_graphics_1 : entity work.dderby_bg_bits_1 — also in MAME: 6F bally/mcr.cpp:2578
rtl/dderby.vhd:892 background graphics ROM 5F bg_graphics_2 : entity work.dderby_bg_bits_2 — also in MAME: 5F bally/mcr.cpp:2579

Cites MAME source — 3

Arcade-DemoDerby.sv:307 JPAC/IPAC/MAME Style Codes
rtl/YM2149_linmix_sep.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA
rtl/dderby.vhd:34 Use with MAME roms from timber.zip

Shares text with the MAME driver without saying so — 1

rtl/turbo_cheap_squeak.vhd:1 Midway Turbo Cheap Squeak sound board — shares text with bally/midway_sound.cpp:34

Arcade-DonkeyKong3 (gaz68)#
Donkey Kong 3
gaz68/Arcade-DonkeyKong3_MiSTer_WIP @ 6b286665
MAME compared: nintendo/dkong.cpp + 3 related file(s)
Read: 29 HDL files, 11,052 lines (Quartus project)

gaz68
repository only

Mostly hardware

low

26%

Statements: 18 toward hardware, 1 toward MAME, 19 not counted

Cites hardware documentation that MAME's driver does not — 18

rtl/apu.sv:441 Values read directly from the netlist
rtl/apu.sv:718 This is implemented from the original LSFR frame counter logic taken from the 2A03 netlists.
rtl/dkong3_adec.v:74 CPU can clear the NMI via register @ 3E.
rtl/dkong3_adec.v:102 74LS139 @ 3B
rtl/dkong3_adec.v:126 74LS138 @ 2A
rtl/dkong3_adec.v:145 74LS138 @ 3A
rtl/dkong3_adec.v:163 74LS138 @ 4E Same as 4F except used for writes.
rtl/dkong3_adec.v:182 74LS138 @ 4F Enable signals for reading inputs and and DIP switches
rtl/dkong3_adec.v:205 74LS259 @ 3E Misc control signals (7E80H - 7E87H)
rtl/dkong3_adec.v:235 74LS174 @ 5H Reset signal to sub CPU's
rtl/dkong3_col_pal.v:34 Parts 3M, 3L (74LS157) Selects sprites or backgound pixels Sprites take priority
rtl/dkong3_obj.v:93 Object RAM 6P, 6R
rtl/dkong3_roms.v:11 0x00000 - 0x01FFF 7B PROGRAM ROM (8KB) 0x02000 - 0x03FFF 7C PROGRAM ROM (8KB) 0x04000 - 0x05FFF 7D PROGRAM ROM (8KB) 0x06000 - 0x06FFF 3P GFX ROM (4KB) 0x07000 - 0x07FFF 3N GFX ROM (4KB) 0x08000 - 0x09FFF 7E PROGRAM ROM (8KB) 0x0A000 - 0x0A
rtl/dkong3_sound.v:120 74LS374 @ 4J Input port 0 for Sub CPU 1
rtl/dkong3_sound.v:145 74LS374 @ 4H Input port 1 for sub CPU 1
rtl/dkong3_sound.v:201 ROM 6M for Sub CPU 2
rtl/dkong3_sound.v:212 RAM @ 6F for Sub CPU 2
rtl/dkong3_sound.v:235 74LS374 @ 5F Input port for Sub CPU 2

Cites hardware references or measurements that MAME's driver also gives — 19

rtl/dkong3_adec.v:90 Address Decoder PROM @ 5E — also in MAME: 5E nintendo/dkong.cpp:292
rtl/dkong3_main.v:172 Main CPU RAM 7F (2KB) — also in MAME: 7F nintendo/dkong.cpp:2564
rtl/dkong3_main.v:194 Main CPU RAMs 7H (2KB) This is also read by the DMA controller. — also in MAME: 7H nintendo/dkong.cpp:2913
rtl/dkong3_roms.v:119 Object/Sprite ROMs 7C,7D,7E,7F. — also in MAME: 7C nintendo/dkong.cpp:2561, 7D nintendo/dkong.cpp:2562, 7E nintendo/dkong.cpp:2563, 7F nintendo/dkong.cpp:2564
rtl/dkong3_roms.v:193 CLUT PROM 1D (512x8) Only 256 entries are used. — also in MAME: 1D nintendo/dkong.cpp:2148
rtl/dkong3_roms.v:221 CLUT PROM 1C (512x4) Only 256 entries are used. — also in MAME: 1C nintendo/dkong.cpp:1058
rtl/dkong3_roms.v:249 Colour palette PROM 2N (256x4) 4-bit output. — also in MAME: 2N nintendo/dkong.cpp:2569
rtl/dkong3_roms.v:276 Address decoder PROM 5E (32x8) — also in MAME: 5E nintendo/dkong.cpp:292
rtl/dkong3_roms.v:302 Sub CPU 1 (Sound) ROM 5L. — also in MAME: 5L nintendo/dkong.cpp:2050
rtl/dkong3_roms.v:330 Sub CPU 2 (Sound) ROM 6H. — also in MAME: 6H nintendo/dkong.cpp:804
rtl/dkong3_sound.v:54 Sub CPU 1 @ 4M (Ricoh 2A03) — also in MAME: 4M nintendo/dkong.cpp:2172
rtl/dkong3_sound.v:86 ROM 5L for Sub CPU 1 — also in MAME: 5L nintendo/dkong.cpp:2050
rtl/dkong3_sound.v:97 RAM @ 5K — also in MAME: 5K nintendo/dkong.cpp:333
rtl/dkong3_sound.v:169 Sub CPU 2 @ 5J (Ricoh 2A03) — also in MAME: 5J nintendo/dkong_a.cpp:865
rtl/dkong3_vram.v:47 VRAM 2 x 2114 @ 2P, 2R (1KB) — also in MAME: 2P nintendo/dkong.cpp:2932, 2R nintendo/dkong.cpp:2931
rtl/dkong3_vram.v:74 Colour PROM 2N — also in MAME: 2N nintendo/dkong.cpp:2569
rtl/dkong3_vram.v:106 Video ROMs 3N, 3P — also in MAME: 3N nintendo/dkong.cpp:2557, 3P nintendo/dkong.cpp:2558
rtl/dkong3_vram.v:178 VRAM BUSY signal @ 2K — also in MAME: 2K nintendo/dkong.cpp:2178
rtl/dkong3_vram.v:194 ESBLK signal @ 2K This signal doesn't go anywhere on the schematic. — also in MAME: 2K nintendo/dkong.cpp:2178

Cites MAME source — 1

Arcade-DonkeyKong3.sv:218 JPAC/IPAC/MAME Style Codes

Arcade-Eolith (ppriest)#
Candy Candy, Crazy War, Fortress 2 Blue Arcade, Hidden Catch 2 …
ppriest/Arcade-Eolith_MiSTer @ c8bf860c
MAME compared: eolith/eolith.cpp, eolith/eolith16.cpp, eolith/vegaeo.cpp + 2 related file(s)
Read: 31 HDL files, 8,331 lines (Quartus project)

ppriest
repository only

Mostly MAME

medium

69%

Statements: 2 toward hardware, 110 toward MAME

Notes where it differs from MAME — 2

rtl/qs1000/vh_qs1000_voice.sv:8 With loop_pcb high (Arcade-Eolith_MiSTer docs/QS1000_FEATURES.md, Recording): a voice reaching its loop end goes back to its loop start (ADPCM with the decoder state it had there, MAME's disabled save/restore), key-off fades it out (`env`)
README.md:185 Where the QS1000 differs from MAME it follows recordings (`docs/QS1000_FEATURES.md`): it loops held notes and fades them at key-off (MAME stops them at the samp

Cites MAME source — 104

Eolith.sv:3 Eolith (MAME eolith/vegaeo.cpp so far): the Hyperstone E1 boards of Eolith; sets in scripts/build_mra.py SETS.
Eolith.sv:257 Active low: COIN1 (P1's coin), COIN2 (P2's), START1, START2, SERVICE1, SERVICE (momentary, as MAME's PORT_SERVICE_NO_TOGGLE); eo_main places them per board
rtl/e1/e1_pipe.sv:1 Hyperstone E1-16 / E1-32 CPU core, pipelined, written from MAME's interpreter (src/devices/cpu/e132xs/e132xs.cpp, e132xsop.hxx, e1defs.h; BSD-3-Clause, copyright-holders Pierpaolo Prazzoli and the MAME team).
rtl/e1/e1_pipe.sv:21 Behaviour follows the interpreter, including its quirks; each is marked "MAME:" where it is not what the ISA manual says.
rtl/e1/e1_pipe.sv:25 Not implemented: power-down, floating point (the FP opcodes trap to their emulation code as in MAME).
rtl/e1/e1_pipe.sv:339 MAME adjust_timer_interrupt: fire when TR has reached TCR and the interrupt is enabled
rtl/e1/e1_pipe.sv:379 MAME: a user-mode write that sets L is a privilege error (checked here, applied at commit)
rtl/e1/e1_pipe.sv:386 raw write: no side effects (MAME writes global_regs[] directly in several places)
rtl/e1/e1_pipe.sv:489 MAME: subtracts the halfword count, not bytes
rtl/e1/e1_pipe.sv:490 MAME: RET does not set P
rtl/e1/e1_pipe.sv:563 MAME: the interpreter sets ILC from this table once, before the first instruction after reset (get_instruction_length); the long-branch and 0xb0-0xbc entries are what MAME does
rtl/e1/e1_pipe.sv:756 D reads what the forwarding does not cover: LDW.S / STW.S (the frame slot through port 4; with them the other e1 subtype-3 N forms), extend (G14, G15 in ST_EXEC); and MOV from TR (e1_tb loads TR with MAME's value once the instruction before
rtl/e1/e1_pipe.sv:1052 MAME: RET with PC/SR source does nothing
rtl/e1/e1_pipe.sv:1061 MAME: the loop runs after the exception entry, with the new frame pointer
rtl/e1/e1_pipe.sv:1081 MAME: same-register and PC/SR sources do nothing
rtl/e1/e1_pipe.sv:1146 MAME: tests src_code against SR even for a local source
rtl/e1/e1_pipe.sv:1165 MAME: BCR, TPR, FCR and MCR read as zero
rtl/e1/e1_pipe.sv:1540 SETADR: the wrap carry goes into bit 9, as MAME's original comment says; MAME's code puts it in bit 0 (MAME_KLUDGES.md, CPU and I/O: mrkickera hangs with it)
rtl/e1/e1_pipe.sv:1882 MAME's get_lhs is the LOW half, get_rhs the HIGH half.
rtl/e1/e1_pipe.sv:2096 MAME: PC/SR as the pointer register does nothing
rtl/e1/e1_pipe.sv:2143 MAME: base update skipped when it is either destination register
rtl/e1/e1_pipe.sv:2221 MAME: when the pointer's own register-file slot is the target, the update adds to the stored value The update goes in the queue first, where it lands then not depending on the comparison with SP, and the store into the register file after i
rtl/e1/e1_pipe.sv:2260 MAME: STD.P reads the second source after the pointer update
rtl/e1/e1_pipe.sv:2262 MAME: updated before the store
rtl/e1/e1_pipe.sv:2272 MAME: skipped when the pointer is also a destination
rtl/eo_busws.sv:4 The board's E1 has no data cache and runs every access at the timing its BCR sets per area (MAME's update_bus_control decodes it; raccoon writes 0xfa1501c4: MEM0-2 two cycles, MEM3 eleven plus one hold, at 45 MHz).
rtl/eo_cpumem.sv:7 Program space, per board (e132xs.cpp iram_4k_map for all):
rtl/eo_eeprom93cxx.sv:3 93Cxx serial EEPROM as MAME's eeprom_serial_93cxx_device behaves (eepromser.cpp): Vamphalf's rtl/vh_eeprom93c46.v (from Arcade-KonamiGX_MiSTer) with the size as parameters and the array in block RAM.
rtl/eo_eeprom93cxx.sv:5 Eolith: EEPROM_93C66_8BIT, 512 x 8, 9 address bits, write and erase 250 us (eolith.cpp 704-706, eolith16.cpp 174-176); WRITEALL and ERASEALL keep MAME's 8 ms (eeprom.cpp 45-48).
rtl/eo_eeprom93cxx.sv:20 MAME applies a write's bits in order CS, CLK, DI, so a CLK edge samples DI as it was before the write (di_l), and a CLK edge in the write that raises CS is not a start bit.
rtl/eo_main.sv:2 `board` 0, Vega (vegaeo.cpp vega_map 116-129):
rtl/eo_main.sv:13 `board` 1, Gradation 2D (eolith.cpp eolith_map 371-383, inputs 405-456):
rtl/eo_main.sv:24 `board` 2, eolith16 (eolith16.cpp eolith16_map 79-92, inputs 94-122), a 16-bit bus: a halfword at a dword's address is bits 31:16 of it
rtl/eo_main.sv:39 COIN2 is read on every Gradation 2D set; MAME declares it on hidnctch, hidctch2 and candy and leaves the bit IPT_UNUSED (reads 1 when not pressed, as here) on the others.
rtl/eo_main.sv:42 The AT28C16 as MAME's at28c16.cpp: a write of a byte that differs from the stored one stores it and starts a 200 us write cycle; during it writes are ignored and reads return the written byte with bit 7 inverted.
rtl/eo_main.sv:61 DSW1 (Gradation 2D), as MAME's port
rtl/eo_main.sv:223 MAME's machine().rand() & 0x300: a free-running LFSR
rtl/eo_pens.sv:1 hidctch3's light pens, from the MiSTer pad: held positions in the game's units (MAME's PORT_MINMAX, X 0-159, Y 0-119), kept as the picture shows them and turned the game's way when the picture is flipped.
rtl/eo_video.sv:4 board 0, Vega (vegaeo.cpp vram_w/vram_r 89-99, screen_update_vega 173-183): two 320 x 256 byte buffers (0x14000 each); byte k of dword d of buffer b is bank k at d + b * 20480.
rtl/eo_video.sv:8 board 1, Gradation 2D (eolith.cpp eolith_vram_w/r 206-221, screen_update_eolith 234-244): two buffers of 15-bit pixels, a line every 336 halfwords; the CPU's window here is lines 0-239 (halfwords 0-80639; eo_cpumem sends the rest to SDRAM).
rtl/eo_video.sv:13 board 2, eolith16 (eolith16.cpp 63-71, 124-164): two 64 KB byte buffers, the CPU's chosen by `vbuf` (bit 7 of 0xffe80000, inverted there); byte k of dword d of buffer b is bank k at d + b * 16384.
rtl/eo_video.sv:15 The display always shows buffer 0 (MAME reads m_vram's base), 320 x 200, through the fixed 3-3-2 palette, the low byte of each halfword first: dot x is CPU byte x ^ 1.
rtl/eo_video.sv:16 (MAME keeps the share in host order on the 16-bit bus and reads it as bytes, 132-141; the CPU's halfword 0x0109 at x shows 0x09 then 0x01.
rtl/eo_video.sv:22 vblank_flag is MAME's "vpos >= 240" on every board (eolith_speedup.cpp:112), the bit the games poll.
rtl/eo_video.sv:53 hidctch3's light pens: a cross at each pen's dot (MAME draws the crosshairs in its UI)
rtl/mame_keys.sv:1 MAME's default keys (src/emu/inpttype.ipp) in hps_io's joystick layout, to OR into joystick_0/1: right, left, down, up at bits 0-3, buttons 1-6 at 4-9, Start, Coin, Pause, Service at the J1 line's own positions (parameters).
rtl/mame_keys.sv:7 P1 arrows, LCtrl LAlt Space LShift Z X, 1 start, 5 coin P2 R F D G, A S Q W E (MAME gives P2 no sixth key), 2 start, 6 coin F2 service (test) switch, 9 and 0 service coins 1 and 2, P pause
rtl/mame_keys.sv:24 MAME's Service 1, 2: wire to the board's SERVICE1/2 bits, if any
rtl/qs1000/eo_qs1000.sv:1 The QS1000 sound board as vegaeo.cpp wires it (208-217, 69-87, 298-305) and qs1000.cpp has it: an 8052 on the 24 MHz oscillator, the main CPU's sound latch, and the wavetable engine reading the sample ROM from SDRAM.
rtl/qs1000/eo_qs1000.sv:3 With `grad`, as eolith.cpp wires it (343-363, 727-732): commands arrive on the 8052's RxD from the sound CPU (eo_sndcpu), P1 reads 1, P2 0, P3 only RxD (qs1000_p3_r), and the data space is the RAM and the voice registers alone (qs1000_data_
rtl/qs1000/eo_qs1000.sv:20 (MAME's crazywar in play: at most 84 banked reads a frame, over 647 lines in 2,600 frames; docs/HARDWARE_NOTES.md.)
rtl/qs1000/eo_qs1000.sv:37 mix balance: the PCB recording's, or MAME's (vh_qs1000_voice)
rtl/qs1000/eo_qs1000.sv:38 looping and the key-off fade, or MAME's neither (vh_qs1000_voice)
rtl/qs1000/eo_qs1000.sv:161 The bank is MAME's memory bank: entry 0 from reset, set by each write to P3 (qs1000_p3_w), not the P3 latch itself, which resets to 0xff.
rtl/qs1000/eo_qs1000.sv:202 with grad, P3.2 and P3.3 read 1 here: jt8052 takes the INT pins from them, MAME's lines are separate
rtl/qs1000/eo_sndcpu.sv:1 The Gradation 2D's sound CPU as eolith.cpp wires it (eolith45 689-735, sound maps 397-412, 261-266, 311-322): an i8032 on 12 MHz that takes the main CPU's sound latch and sends the QS1000 its commands over the UART.
rtl/qs1000/eo_sndcpu.sv:11 MAME holds the line asserted (machine_reset 265) because its timer GATE counts while IE1 is set (i8051.cpp 832); the program runs timer 1 gated (TMOD 0xa1) as the UART's baud clock, which on the part counts while /INT1 is high (docs/MAME_KL
rtl/qs1000/eo_sndcpu.sv:19 (MAME, 1,800 frames: at most 105 banked reads a frame, puzzlekg; docs/HARDWARE_NOTES.md.)
rtl/qs1000/eo_sndcpu.sv:106 the bank: MAME's memory bank, set by each P1 write; jt8052 shows the P1 latch only, so a write is seen as a change of it (P1 resets to 0xff, the bank to entry 0)
rtl/qs1000/eo_sndcpu.sv:161 MAME's m_sound_txd starts at 0 (eolith.cpp 180) and the i8032's reset writes P3 before its UART idles the pin high (i8051.cpp 1347, 1357), so the QS1000 sees RxD low until the first transmit(1): the first command (B0 0A 40 on hidnctch) arri
rtl/qs1000/jt8052/jt8052_periph.v:33 [EO] the 8052's timer 2 (T2CON 0xc8, RCAP2 0xca/0xcb, TL2/TH2 0xcc/0xcd, vector 0x2b, ET2 IE.5, PT2 IP.5): timer and capture modes on the machine cycle, as MAME's i8052 update_timer_t2.
rtl/qs1000/vh_qs1000_voice.sv:1 QS1000 wavetable engine, as MAME models it (devices/sound/qs1000.cpp; scripts/qs1000_model.py is the same model in Python and the bench's reference).
rtl/qs1000/vh_qs1000_voice.sv:4 MAME runs the engine at 24 MHz / 32 = 750 kHz: per tick every playing voice outputs one sample (8-bit PCM, or IMA ADPCM decoded one nibble per address step, high nibble first, its 16-bit signal wrapping instead of saturating: Arcade-Eolith_
rtl/qs1000/vh_qs1000_voice.sv:7 With loop_pcb low, as MAME: no looping, a voice stops at its loop end, and key-off does nothing.
rtl/qs1000/vh_qs1000_voice.sv:13 Register writes (0x200-0x211 of the 8052's data space, `wr_*`) and ticks (`tick`) enter one queue in arrival order and are applied in that order, so the output sequence is MAME's even when a key-on waits for its ROM reads; the engine catche
rtl/qs1000/vh_qs1000_voice.sv:23 mix_valid pulses once per tick with the left and right sums (before MAME's /4096); out_l/out_r are the 16-bit output, the mean of 16 ticks (46.875 kHz), clamped.
rtl/qs1000/vh_qs1000_voice.sv:34 1: the PCB recording's balance (the core); 0: MAME's (benches).
rtl/qs1000/vh_qs1000_voice.sv:35 1: looping, the key-off fade, pitch bend (the core); 0: MAME's (benches)
rtl/qs1000/vh_qs1000_voice.sv:59 a write arriving with a tick is queued a clock after it: it belongs to the next sample, as MAME applies a write stamped with the current tick before that tick's sample (the 8052 writes once in 28 clocks or more, so the held write is never o
rtl/qs1000/vh_qs1000_voice.sv:308 loop_pcb: the nibble decoded is lstart's, so its pre-decode state is the one to restore at each wrap; and the address after this tick reaches lend, so the voice is written back at lstart, its nibble index one before, with that state: the ne
rtl/qs1000/vh_qs1000_voice.sv:419 [207] left, [206] right: MAME has them the
rtl/qs1000/vh_qs1000_voice.sv:465 MAME: return
rtl/qs1000/vh_qs1000_voice.sv:472 descriptor (MAME start_voice): start = bytes 0-2, loop start = {byte 0 [7:4], bytes 3-4, byte 5 [7:4]}, loop end = {byte 0 [7:4], byte 5 [3:0], bytes 6-7}
rtl/qs1000/vh_qs1000_voice.sv:568 after reset every voice is stopped, as MAME's device_reset
rtl/qs1000/vh_qs1000_voice.sv:604 bal_pcb low: ADPCM x4, PCM x1 (MAME's gains, qs1000.cpp:484, :513).
README.md:3 A MiSTer FPGA core for Eolith's Hyperstone arcade boards (MAME's `vegaeo.cpp`, `eolith.cpp` and `eolith16.cpp`), built with Quartus Prime 17.0.2 Lite for the DE
README.md:34 QS1000 sound closer to the chip than MAME, from a Hidden Catch PCB recording, a Mission Craft PCB recording and General MIDI files recorded on a QS1000 (`docs/Q
README.md:37 Raccoon World (MACHINE_NOT_WORKING in MAME): 23 sets
README.md:52 Three boards, each a Hyperstone CPU drawing into a double-buffered frame buffer, with no sprites or tiles: the Vega (Crazy War: GMS30C2132, 8-bit pixels through
README.md:74 | Candy Candy | 1999 | Eolith | `candy` | Gradation 2D | IMPERFECT_GRAPHICS in MAME |
README.md:75 | Hidden Catch 2 (pcb ver 3.03) (Kor/Eng) (AT89c52 protected) | 1999 | Eolith | `hidctch2` | Gradation 2D | MAME's protection patch |
README.md:77 | Hidden Catch 2000 (AT89c52 protected) | 1999 | Eolith | `hidnc2k` | Gradation 2D | MAME's protection patch |
README.md:79 | Land Breaker (World) / Miss Tang Ja Ru Gi (Korea) (pcb ver 3.03) (AT89c52 protected) | 1999 | Eolith | `landbrka` | Gradation 2D | Clone of `landbrk`; MAME's
README.md:80 | Land Breaker (World) / Miss Tang Ja Ru Gi (Korea) (pcb ver 1.0) (AT89c52 protected) | 1999 | Eolith | `landbrkb` | Gradation 2D | Clone of `landbrk`; MAME's p
README.md:85 | Raccoon World | 1998 | Eolith | `raccoon` | Gradation 2D | MACHINE_NOT_WORKING in MAME ("game animation & timers seem too fast?") |
README.md:97 | MAME description | Why |
README.md:99 | BnB Arcade, Happy Tour, Touryuumon (`ghosteo.cpp`) | A 200 MHz ARM920T system-on-chip with an MMU; shares only the QS1000 with these boards |
README.md:105 | Hyperstone GMS30C2132 (Vega), E1-32N (Gradation 2D), E1-16T (`eolith16`) | Main CPU | Arcade-Vamphalf_MiSTer's pipelined `e1_pipe.sv`, written there from MAME
README.md:107 | QS1000 (8052 + 32-voice wavetable) | Sound, Vega and Gradation 2D | From Arcade-Vamphalf_MiSTer: jotego's JT8051 with changes (`rtl/qs1000/PROVENANCE.md`), th
README.md:116 MAME gives no video timing (`set_refresh_hz(60)`, `set_size(512, 262)` are placeholders, `eolith.cpp:714-717`); the dot clock is half the boards' 14.31818 MHz c
README.md:133 A 64 MB SDRAM module is required: Crazy War and 16 of the 22 `eolith.cpp` sets are larger than 32 MB.
README.md:185 Sound has not been compared with MAME by ear on the board.
README.md:190 The M6295's output (KlonDike+) has not been compared with MAME; nor have Hidden Catch 3's pens, which work on the board.
README.md:227 [ ] Sound judged against MAME on the board
README.md:228 [ ] Frame times on the board against MAME's (the `Eolith_stp` revision's probes)
README.md:253 MAME's `vegaeo.cpp`, `eolith.cpp`, `eolith16.cpp`, `qs1000.cpp` and `e132xs` are the reference.
README.md:257 CPU: `e1_pipe` agrees with MAME's interpreter after every instruction (PC, SR, all registers, every bus access), at 0 and 3 bus wait states, on Crazy War's firs
README.md:261 Whole board (`sim/sys_tb`, the SDRAM controller and a chip model) against MAME's trace from reset: all 2,000,000 retired PCs on `crazywar` (178,383 of 178,383 d
README.md:269 EEPROM: MAME's pin traffic for `hidnctch` over 1,200 frames, from blank: 12,112 of 12,112 data reads agree (`sim/ee_tb`).
README.md:271 Gradation 2D sound (`sim/snd_tb`, `hidnctch`, 1,200 frames with a coin and a start): 4,711 of 4,711 QS1000 register writes and 1,805 of 1,805 sound CPU data rea
README.md:273 No interrupts: over 3,000 frames, no timer, INT1-4 or IO entries on any set of the three drivers in MAME (`scripts/mame_irqcount.py`); the games poll vblank.
README.md:281 The **MAMEdev team**: Tomasz Slanina and Pierpaolo Prazzoli (`eolith.cpp`), Pierpaolo Prazzoli (`vegaeo.cpp`, `eolith16.cpp`, `e132xs`), Philip Bennett (`qs1000
README.md:298 | `debug` | reference captures from MAME used as ground truth (gitignored) |
README.md:299 | `roms` | your own MAME sets (gitignored, never committed) |

Says it matches, follows or was checked against MAME — 3

rtl/eo_video.sv:18 Checked: the core's VRAM writes equal MAME's on hidden text, debug/sysk/vwlog.txt against debug/tmp/textsrc.txt, and only with the swap does the text read as MAME's.)
README.md:206 Flip screen, HDMI and analog, from the OSD or the DIP (fake DIP where the game has none): done, from the OSD (no board here has a flip); checked in simulation o
README.md:265 Video: the scan-out is pixel-identical to MAME on 40 of 40 captured `crazywar` frames, 6 of 6 `hidnctch` and 6 of 6 `klondkp` frames (attract and play).

Says it was translated, ported or taken from MAME — 2

Eolith.sv:242 A byte per player, active low, as MAME's P1_P2 (Vega) and IN0 bits 31:16 (Gradation 2D): U D L R, buttons 1-3.
README.md:193 `docs/MAME_KLUDGES.md` lists what is taken from MAME as behaviour and what is known not to be right.

Keeps a MAME approximation — 1

README.md:254 Where the core follows MAME on something MAME marks as uncertain, it is listed in `docs/MAME_KLUDGES.md`; the core's own approximations are in `docs/HACKS.md`.

Arcade-FireTrap (Usquebagh)#
Fire Trap
Usquebagh/Arcade-FireTrap_MiSTer @ f0d756f4
MAME compared: dataeast/firetrap.cpp
Read: 18 HDL files, 4,520 lines (Quartus project)

Usquebagh
repository only

Mostly MAME

low

38%

Statements: 7 toward hardware, 26 toward MAME, 1 not counted

Cites hardware documentation that MAME's driver does not — 7

rtl/ft_core.v:124 ---------------------------------------------------------------- VRAM wait (sheet 17) Tile RAM (D000-E7FF) is only available to the Z80 during blanking.
rtl/ft_core.v:233 ---------------------------------------------------------------- I/O writes (sheet 16) Board latches clock on the rising (trailing) edge of the decoded write strobe.
rtl/ft_core.v:280 ---------------------------------------------------------------- interrupts (sheet 15) NMI: the enable is latched at the start of VBLANK; NMI is held for the rest of VBLANK.
rtl/ft_core.v:300 ---------------------------------------------------------------- 8751 (sheet 26) INT0 flip-flop: set by a write to F005, held reset while P3.1 is low.
rtl/ft_sound.v:7 The LS157 6K feeds the MSM the high nibble of the 2000 latch, then the low one, toggling on each VCK (MAME: adpcm_int / ls157).
README.md:28 | **Video** | Text layer, two scrolling 16×16 tile layers, 96 sprites, priority and palette PROMs, DECO custom chips | `ft_video.v`, `ft_render.v`, from the sch
README.md:140 **Reference:** MAME `firetrap` driver by Nicola Salmoria and Stephane Humbert, and the schematics in the Data East installation & service manual

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/ft_video.v:206 Priority PROM 1A: A7:6 FG pixel, A5 sprite priority, A4 sprite transparent, A3:0 BG1 pixel — also in MAME: 1A dataeast/firetrap.cpp:117

Cites MAME source — 23

Arcade-FireTrap.sv:162 Holding up alternates the hands automatically every N frames (MAME test: the climb speed levels off at about 40 frames per swap); other directions go to both sticks.
Arcade-FireTrap.sv:347 ROT90 (MAME): rotate clockwise.
rtl/ft_cheats.v:13 Codes for work RAM (C000-CFFF) are applied the way MAME's cheat scripts are: the value is written into RAM once per frame (start of VBLANK), so the game still sees its own writes in between.
rtl/ft_core.v:13 Z80 waits for blanking on tile-RAM access (not in MAME)
rtl/ft_core.v:153 BG (MAME tilelayout + ROM_CONTINUE): quarter n = {c[1], f[13]}, q = {c[0], f[14], f[12:0]}
rtl/ft_core.v:223 RAM dump for comparisons with MAME (sim_main pulses dbg_dump)
rtl/ft_inputs.v:63 4-way joystick filter (MAME PORT_4WAY): when two directions are held, the one pressed most recently wins.
rtl/ft_render.v:14 Layer conventions follow MAME firetrap.cpp (tilemap mappers, scroll signs, sprite rules).
rtl/ft_render.v:67 Flip screen: MAME flips tilemaps around the visible area (256 x 256 incl.
rtl/ft_render.v:70 MAME: scrolly = -register
rtl/ft_render.v:73 MAME get_bg_memory_offset: ((row & 0xF) ^ 0xF) | (col & 0xF) << 4 | (row & 0x10) << 5 | (col & 0x10) << 6
rtl/ft_render.v:76 Sprite geometry (MAME draw_sprites)
rtl/ft_render.v:128 sprite X wraps (MAME draws at x and x-256)
rtl/ft_render.v:191 Bit 3 flips X and bit 2 flips Y in screen (native) orientation: MAME's TILE_FLIPXY((attr & 0x0c) >> 2) ends up this way, and the game's mirrored building halves (attr bit 2 set) only join up like this.
rtl/ft_sound.v:7 The LS157 6K feeds the MSM the high nibble of the 2000 latch, then the low one, toggling on each VCK (MAME: adpcm_int / ls157).
rtl/ft_sound.v:140 ---------------------------------------------------------------- mix (MAME: OPL 1.0, MSM 0.30)
rtl/ft_video.v:5 Visible area as MAME: H 0-255, V 8-247.
rtl/ft_video.v:161 ---------------------------------------------------------------- FG layer + mixer Screen position as seen by the FG tilemap (MAME flips the whole 256x256 map)
README.md:86 | Advanced → Z80 VRAM Wait | *On (Board)*: the Z80 waits for blanking when it touches tile RAM, as the schematics show. *Off (MAME)*: no waits, as in MAME. |
README.md:93 Like MAME's, they write the value into RAM once per frame.
README.md:110 Use the MAME "firetrap" set (merged, MAME 0.289).
README.md:126 A Verilator simulation, with tools to compare frames and audio against MAME, is in `sim/`.
README.md:140 **Reference:** MAME `firetrap` driver by Nicola Salmoria and Stephane Humbert, and the schematics in the Data East installation & service manual

Says it was translated, ported or taken from MAME — 2

README.md:92 **Cheats** (OSD **Cheats** menu): P1/P2 Infinite Lives, P1/P2 Infinite Time and the 3-Way Powerup, converted from the MAME cheat file.
README.md:139 **Cheats:** converted from the MAME cheat file at [mamecheat.co.uk](https://www.mamecheat.co.uk)

Shares text with the MAME driver without saying so — 1

rtl/ft_render.v:73 MAME get_bg_memory_offset: ((row & 0xF) ^ 0xF) | (col & 0xF) << 4 | (row & 0x10) << 5 | (col & 0x10) << 6 — shares text with dataeast/firetrap.cpp:399

Arcade-Garegga (zakk4223)#
Battle Garegga, Shippu Mahou Daisakusen, Mahou Daisakusen
zakk4223/Arcade-Raizing_MiSTer @ 2ea8aa8d
MAME compared: toaplan/raizing.cpp + 9 related file(s)
Read: 15 HDL files, 4,965 lines (Quartus project)

zakk4223
repository only

Not enough evidence in the code

insufficient

Statements: 1 not counted

Cites hardware references or measurements that MAME's driver also gives — 1

cores/garegga/hdl/model/garegga_game.v:143 68K ROM — also in MAME: 68K toaplan/raizing.cpp:230

Arcade-Gyruss (MrX-8B)#
Gyruss
MrX-8B/MiSTer-Arcade-Gyruss @ e5c41036
MAME compared: konami/gyruss.cpp + 3 related file(s)
Read: 38 HDL files, 19,149 lines (Quartus project)

MrX-8B
repository only

Not enough evidence in the code

insufficient

Statements: 3 toward MAME

Cites MAME source — 3

Arcade-GYRUSS.sv:196 JPAC/IPAC/MAME Style Codes
src/YM2149_linmix_sep.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA
README.txt:57 copy ROM zip files to /media/fat/_Arcade/mame

Arcade-Intrepid (harlock74)#
Intrepid
harlock74/Arcade-Intrepid_MiSTer @ f2074ea4
MAME compared: taito/roundup.cpp
Read: 38 HDL files, 6,620 lines (Quartus project)

harlock74
repository only

Mostly MAME

low

Statements: 20 toward MAME

Cites MAME source — 17

rtl/intrepid/intrepid_ay8910.sv:1 See LICENSES/MAME-AY8910-notice.txt for reference attribution.
rtl/intrepid/intrepid_ay8910.sv:42 MAME device reset preserves port registers 14 and 15.
rtl/intrepid/intrepid_ay8910.sv:78 MAME 1000-ohm legacy-normalized per-channel DAC, round-to-nearest Q15.
rtl/intrepid/intrepid_ay8910.sv:142 MAME preserves count.
rtl/intrepid/intrepid_background.sv:3 MAME layout plane 0 (gfx +0x1000) has weight 2, plane 1 (+0) weight 1.
rtl/intrepid/intrepid_composition.sv:1 Pinned roundup.cpp screen_update: solid category 0, transparent tile, low sprite, solid category 1, high sprite.
rtl/intrepid/intrepid_inputs.sv:1 Pinned MAME reference: contracts/stage_k_integration.json.
rtl/intrepid/intrepid_inputs.sv:2 Game A000 is active high after MAME's input-port inversion.
rtl/intrepid/intrepid_main_bus.sv:54 MAME sound latch reset preserves its stored value.
rtl/intrepid/intrepid_raster.sv:1 CONFIRMED-MAME: roundup.cpp set_raw(6144000,384,0,256,264,16,240).
rtl/intrepid/intrepid_scroll_coordinates.sv:1 Stage G inverse coordinates, derived from pinned MAME tilemap draw placement.
rtl/intrepid/intrepid_sound_bus.sv:2 MAME provenance and collision choices: validation/stage_j/ARCHITECTURE.md.
rtl/intrepid/intrepid_sound_bus.sv:66 MAME default unmapped value is zero for these address maps; IRQ vector ff.
rtl/intrepid/intrepid_sound_clocks.sv:1 Accepted 20 MHz system clock; MAME-configured 2.5 MHz CPU and 1.536 MHz AY.
rtl/intrepid/intrepid_sound_mixer.sv:1 Six pinned-MAME mono routes at 0.25.
rtl/intrepid/intrepid_sprite_pixel.sv:1 Stage H: one bounded pixel of a MAME sprite; no physical-ROM interleave.
README.md:78 | Intrepid and AY functional reference | MAME contributors | Reference implementation; AY BSD-3-Clause attribution retained |

Says it matches, follows or was checked against MAME — 1

rtl/intrepid/intrepid_main_ram.sv:3 Power-up zero matches MAME allocation; soft reset never clears RAM.

Says it was translated, ported or taken from MAME — 1

README.md:7 Current status: functional behavioural implementation, mainly based on MAME/reference behaviour.

Keeps a MAME approximation — 1

rtl/intrepid/intrepid_composition.sv:2 Synthetic RGB is MAME-derived, DOCUMENTED-APPROXIMATION / UNRESOLVED for original hardware fidelity.

Arcade-JalecoMS32 (ppriest)#
Mahjong Angel Kiss, Best Bout Boxing, Vs. Janshi Brandnew Stars, Desert War / Wangan Sensou …
ppriest/Arcade-JalecoMS32_MiSTer @ 1e3cf916
MAME compared: jaleco/ms32.cpp + 8 related file(s)
Read: 34 HDL files, 12,147 lines (Quartus project)

ppriest
repository only

Mostly MAME

medium

75%

Statements: 121 toward MAME

Cites MAME source — 109

MS32.sv:9 A capture blob (scripts/build_capture_blob.py, ioctl index 2) can still be loaded with the CPU held (mod byte bit 7), so a frame MAME rendered is rendered by the hardware from the real ROMs.
MS32.sv:40 The mainboard's own output is mono (ms32.cpp header), so the OSD's Stereo Mix defaults to it: status 0 Mono (AUDIO_MIX 3), 1 None (0), 2 25% (1), 3 50% (2).
MS32.sv:226 ms32.cpp INPUTS at 0xFCC00004, active low.
MS32.sv:232 keyboard 5 and 6, MAME's coin keys, on every set (decoded below)
MS32.sv:241 Mahjong panel (ms32.cpp ms32_mahjong, mahjong.cpp mahjong_matrix_1p) from a PS/2 keyboard with MAME's default keys: A-N, Kan LCtrl, Pon LAlt, Chi Space, Reach LShift, Ron Z, Start 1 (or joystick Start).
rtl/cpu/ms32_cpu_sys.sv:3 The MS32 main CPU and its memory map: the vendored V70 (s32_v60, IS_V70) behind ms32_v70_bus, ms32.cpp's ms32_map decoded with its mirrors, work RAM and NVRAM, the CPU port of every video RAM (the RAMs live in ms32_video as dual-clock block
rtl/cpu/ms32_cpu_sys.sv:31 Charles MacDonald's measurements of a Desert War board head MAME's ms32.cpp; docs/HARDWARE_NOTES.md checks this module against each (memory map, mirroring, sound latches, I/O ports, unused-space reads).
rtl/cpu/ms32_cpu_sys.sv:39 ms32.cpp sound_command_w spins the V70 for 40 us after a latch write "to give the Z80 time to respond"; 800 clk_cpu clocks at 20 MHz
rtl/cpu/ms32_cpu_sys.sv:307 ms32.cpp mahjong_ctrl_r: 0xFD1C0000 (write-only) selects key rows by bits 0-4; the rows selected are ANDed, then bitswap<6>(v, 4,2,3,1,0,5) puts the Start column in bit 0, and bits 7:6 read 1.
rtl/cpu/ms32_cpu_sys.sv:323 ------------------------------------------------------------- sound latches ms32.cpp: 0xFC800000 loads the Z80's command latch (in ms32_sound); the Z80's write to 0x3F10 loads to_main and raises IRQ level 1; 0xFD000000 returns to_main inver
rtl/cpu/ms32_sysctrl.sv:3 The interrupt side of jaleco_ms32_sysctrl plus ms32.cpp's irq_raise, in the CPU's clock domain.
rtl/cpu/ms32_sysctrl.sv:7 ms32.cpp: m_irqreq is a 16-bit set of levels; the V70's line is asserted while any bit is set and irq_callback() returns the highest set bit.
rtl/cpu/ms32_sysctrl.sv:89 jaleco_ms32_sysctrl calls m_field_cb at the vblank line when inverted, and ms32.cpp wires m_vblank_cb to level 10 and m_field_cb to level 9 unconditionally, so vblank_ack (m_vblank_cb(0)) clears 10 and field_ack clears 9 on every set.
rtl/cpu/ms32_v70_bus.sv:33 word a[1:0]==0 1 otherwise 2 Unaligned halves and words are legal on a V70 and MAME's core issues them (read_dword_unaligned throughout v60.cpp); the trace shows the CPU doing exactly that on tetrisp's boot.
rtl/cpu/v60/s32_v60.sv:21 2026-09-13 Charles MacDonald's hardware notes (ms32.cpp header): PIR reads 0x00007007 on a uPD70632GD-20 (was MAME's 0x7000), and MOV.D's register-pair source for R31 is R31:R31, not R31 and the register after it.
rtl/cpu/v60/s32_v60.sv:25 2026-09-13 MAME's dim 3 (qword) operands: MOVD's register source in the F2 D=0 short form is the register PAIR (op1 an lvalue, as XCH), and autoincrement, autodecrement and index scaling step by 8 for MOVD's operands and the second operand
rtl/cpu/v60/s32_v60.sv:37 Behavioral contract is MAME's v60 core (BSD-3-Clause, Farfetch'd / R. Belmont): opcode dispatch per optable.hxx, addressing modes per am1-3.hxx, exception entry per v60.cpp.
rtl/cpu/v60/s32_v60.sv:45 the fill/stop variants (MOVC*/CMPC*/SCHC*/SKPC*), TASI, bit ops, GETPSW/UPDPSW, TRAP/TRAPFL/BRK/BRKV, CHLVL, task save/load, privileged register moves (LDPR/STPR), and MAME-defined decimal/bit- string/bit-field groups.
rtl/cpu/v60/s32_v60.sv:52 - Not implemented (reserved-instruction exception, logged in sim): the un-dispatched 0x5C/0x5F sub-opcodes (MAME UNHANDLED).
rtl/cpu/v60/s32_v60.sv:53 MMU/TLB effects are absent like MAME, but CLRTLB still decodes its complete operand.
rtl/cpu/v60/s32_v60.sv:63 V60/V70 reset PC (MAME m_start_pc; audit V60-21)
rtl/cpu/v60/s32_v60.sv:167 PSW fields (MAME bit layout: Z=b0,S=b1,OV=b2,CY=b3,IE=b18,EL=b25:24,IS=b28)
rtl/cpu/v60/s32_v60.sv:727 C-style truncating divide-by-8 of a signed bit offset (MAME bamoffset/8)
rtl/cpu/v60/s32_v60.sv:817 stack switch on IS change, or EL change while IS=0 (MAME v60WritePSW)
rtl/cpu/v60/s32_v60.sv:1065 [MS32] qword operands, MAME's moddim 3 (op12.hxx): both of MOVD's, and the second of MULX/MULUX/DIVX/DIVUX.
rtl/cpu/v60/s32_v60.sv:1264 primary dispatch (per MAME optable.hxx)
rtl/cpu/v60/s32_v60.sv:1269 BRK — MAME skips this opcode (A4)
rtl/cpu/v60/s32_v60.sv:1289 ---- Bcc disp8 (0x60-0x6a,0x6c-0x6f) / disp16 equivalent ---- 0x6B/0x7B are holes in MAME's authoritative primary dispatch table, not branch-condition encodings.
rtl/cpu/v60/s32_v60.sv:1349 MAME opDBcc: reg ALWAYS decrements; branch iff cond true and decremented reg != 0.
rtl/cpu/v60/s32_v60.sv:1455 JMP/JSR/TASI: MAME sets moddim=0 — the dim scales INDEXED modes' index register, and ga2's jump tables (3-byte BR entries, `JMP [PC+d](rN)`) rely on the unscaled index (found by real-ROM boot: dim=2 quadrupled the index and jumped mid-table
rtl/cpu/v60/s32_v60.sv:1481 RETI adj (halfword, MAME moddim=1)
rtl/cpu/v60/s32_v60.sv:1505 MAME F7a/F7b decode with dim 0 (0x58 byte) / 1 (0x5A half): autoincrement/indexed AMs step and scale by the element size, and F7b immediates size accordingly — not dword.
rtl/cpu/v60/s32_v60.sv:1525 MAME implements ADDDC/SUBDC/SUBRDC/CVTDPZ/CVTDZP (radm timer); remaining subops are reserved there too.
rtl/cpu/v60/s32_v60.sv:1614 Unhandled sub-opcodes still take the reserved-instruction vector exactly as MAME's op5C/op5F UNHANDLED entries fatalerror.
rtl/cpu/v60/s32_v60.sv:1656 RSR (A9): pop PC ONLY (MAME opRSR: PC=[SP]; SP+=4)
rtl/cpu/v60/s32_v60.sv:1661 MAME/NEC floating-exception test: enabled TKCW causes are intersected with the PSW floating-status field.
rtl/cpu/v60/s32_v60.sv:1690 F12: plan operands per instflags (MAME F12DecodeOperands)
rtl/cpu/v60/s32_v60.sv:1699 MOVEA takes op1 as an ADDRESS (MAME ReadAMAddress) — decoding it as a value loaded SP with a byte read instead of the EA and sent ga2's boot stub off a cliff (found by real-ROM boot)
rtl/cpu/v60/s32_v60.sv:2331 MAME opDIVX/opDIVUX set only S/Z and leave OV unchanged; do not clear it.
rtl/cpu/v60/s32_v60.sv:2363 MAME opROTC*: the carry bit enters the active operand's LSB; bits above a byte/halfword operand are not part of the ring.
rtl/cpu/v60/s32_v60.sv:2694 pops (8) + frame-destroy operand (MAME: SP += amout), then the PSW write may bank-switch SP — order matters: adjust THEN switch.
rtl/cpu/v60/s32_v60.sv:2736 push highest set register first (MAME pushes from r31 down?
rtl/cpu/v60/s32_v60.sv:2784 TASI sets flags as SUBB(old, 0xFF, 0) before writing 0xFF (MAME opTASI).
rtl/cpu/v60/s32_v60.sv:2821 R27 (dst) / R28 (src) updated at completion (MAME MOVSTR).
rtl/cpu/v60/s32_v60.sv:2830 Element-size dim for both (MAME dim 0 byte / 1 half — see decode).
rtl/cpu/v60/s32_v60.sv:2847 V60-15: down-direction search (subop[0]=1, MAME opSEARCHD*).
rtl/cpu/v60/s32_v60.sv:2849 The down form scans the range in descending order from MAME's start index: byte reads op1+len1 down to op1 (len1+1 reads; the first read is one past the buffer, exactly as opSEARCHDB does), half reads op1+(len1-1)*2 down to op1 (len1 reads)
rtl/cpu/v60/s32_v60.sv:2874 MOVCD/MOVCFD (down copy) transfers the ascending range base..base+min-1 in descending element order (MAME opMOVSTRD): start at the TOP of that range and decrement, instead of walking physically below the base as the old code did (audit R20
rtl/cpu/v60/s32_v60.sv:2883 CMPCS (0x02): stop mode starts with CY=1, cleared when a fill (R26) byte is met in the compare (MAME opCMPSTR bStop).
rtl/cpu/v60/s32_v60.sv:2886 CMPCF (0x01): fill the SHORTER operand's tail with R26 BEFORE the compare (MAME bFill); MOVC fill happens AFTER the copy.
rtl/cpu/v60/s32_v60.sv:2915 Down exhaustion: the scan ran off the bottom to i=-1 (MAME opSEARCHD*), so Z=0, R27=0xFFFFFFFF, and str_src has already reached op1-step.
rtl/cpu/v60/s32_v60.sv:2930 CMPC exhausted the common prefix (all min elements equal): R28=len1+min*step, R27=len2+min*step, and S/Z from the length compare (MAME opCMPSTR tail).
rtl/cpu/v60/s32_v60.sv:2965 Z follows MAME's post-loop test i==len1: up never breaks at i==len1 (Z=0), down does so only at its one-past-the-top byte read (str_cnt==len1+1).
rtl/cpu/v60/s32_v60.sv:3004 CMPC (MAME opCMPSTR): compare source(op1) vs dest(op2).
rtl/cpu/v60/s32_v60.sv:3263 BAM: bit addressing modes for the 0x5B/0x5D groups (MAME BAMTable1/2 implemented subset — everything MAME fatalerrors on traps here too).
rtl/cpu/v60/s32_v60.sv:3737 exception / interrupt entry (MAME v60_do_irq): switch to interrupt context, push old PSW, push PC, PC = vector
rtl/cpu/v60/s32_v60.sv:3975 per-opcode dim helpers (operand sizes per MAME op12 handlers)
rtl/cpu/v60/s32_v60.sv:3977 F12 ops whose FIRST operand is an effective address, not a value (MAME F12DecodeFirstOperand(ReadAMAddress, ...)): MOVEA and IN
rtl/cpu/v60/s32_v60.sv:3998 NOTE: ROTH (8b) / ROTCH (9b) must NOT appear here — their op1 is the rotate COUNT, a byte (MAME ReadAM dim 0); listing them in the half group made `ROT.H #imm8, r6` decode one byte long and holo's EEPROM write loop entered mid-instruction (
rtl/cpu/v60/s32_v60.sv:4031 These read op2 as a VALUE (MAME ReadAM), so a memory operand must be loaded into op2val before exec; otherwise the exec fell back to the effective address / a stale op2val (audit R20 V60-18).
rtl/cpu/v60/s32_v60.sv:4117 MOVC completion (MAME opMOVSTRU*/opMOVSTRD*): publish R28/R27 for the final element index `idx`, and — for the fill variants (MOVCFU/MOVCFD) with the source shorter than the destination — kick off the R26 tail-fill phase.
rtl/cpu/v60/s32_v60.sv:4140 MAME pads the destination tail elements [idx, lenop2) with R26; the down form uses op2+dest+(lenop2-j-1) for bytes and op2+(lenop2-j-1)*2 for halves.
rtl/cpu/v60/s32_v60.sv:4221 MAME MOV sets no flags?
rtl/cpu/v60/s32_v60.sv:4344 A zero count must clear CY (MAME); the old code left it unchanged (audit R20 V60-7).
rtl/cpu/v60/s32_v60.sv:4371 MAME defines CY from the post-rotate wrap bit: LSB after a positive (left) rotate, MSB after a negative (right) rotate.
rtl/cpu/v60/s32_v60.sv:4382 MAME clears CY for a zero count; nonzero counts retain the final shifted-out bit, so only bypass the iterative state for zero.
rtl/cpu/v60/s32_v60.sv:4443 MAME divide-by-zero: destination unchanged and no trap, but Z/S are still set from the (unchanged) destination = the dividend, and OV is cleared (audit R20 V60-8); the old code left flags stale.
rtl/cpu/v60/s32_v60.sv:4476 MAME sets OV and leaves the destination unchanged (audit R20 V60-8); the old code always cleared OV and wrote the wrapped quotient.
rtl/cpu/v60/s32_v60.sv:4494 MAME opMULX/opMULUX leave OV unchanged
rtl/cpu/v60/s32_v60.sv:4510 MAME: no zero-divide trap
rtl/cpu/v60/s32_v60.sv:4582 MAME opCALL: SP-=4; [SP]=AP; AP=op2; SP-=4; [SP]=retPC; PC=op1.
rtl/cpu/v60/s32_v60.sv:4619 MAME opTRAP: the operand's HIGH nibble is a Bcc-encoded condition (cond 0xB never traps); only trap when it evaluates true, else fall through.
rtl/cpu/v60/s32_v60.sv:4869 SHA left-shift overflow (MAME SHIFTLEFT_OV op12.hxx): OV is set when the top `count` bits of the width-sized value are not all equal to the sign bit — i.e. a bit different from the sign is shifted out through the top.
rtl/cpu/v60/s32_v60.sv:4871 MAME masks exactly `count` bits (((1<<count)-1) << (bitsize-count)); using count+1 here spuriously set OV (e.g. SHA.B #1,0x40 gave OV=1 vs MAME OV=0), misbranching a following signed Bcc (S^OV).
rtl/cpu/v60/s32_v60.sv:4882 count > width: MAME's macro is UB here (bitsize-count<0); any nonzero value overflowed
rtl/cpu/v60/s32_v60.sv:4958 MAME opMUL/opMULU: OV = (product >> width) != 0 on the product's unsigned bit pattern (signed product for MUL, unsigned for MULU).
rtl/cpu/v60/s32_v60.sv:4960 For byte/half MAME shifts the 32-bit value; for word, the 64-bit one.
rtl/cpu/v60/s32_v60.sv:4983 MAME clears OV for REM/REMU (audit R20 V60-8)
rtl/cpu/v60/s32_v60.sv:4992 Behavioral contract is MAME op2.hxx/op5.hxx, which use host `float` — round-to-nearest-even, with gradual underflow (subnormals) and IEEE special values.
rtl/cpu/v60/s32_v60.sv:5008 NEGFS/ABSFS are NOT: MAME does ReadAMAddress + store only (no load) — they operate on op1 and must not read a possibly read-sensitive destination.
rtl/cpu/v60/s32_v60.sv:5184 Deliberate divergence from the pinned MAME for |n| > 30: MAME computes `appf * / (1 << n)` with the host's shift-count masking (&31, and 1 << 31 = INT_MIN there), so e.g. SCLFS(31) flips the sign and SCLFS(32) is a no-op on x86.
rtl/cpu/v60/s32_v60.sv:5241 Pinned MAME converts (uint32_t)(int64_t)val on its x86 host: NaN and out-of-int64-range saturate the hardware convert to INT64_MIN, whose low 32 bits are 0.
rtl/cpu/v60/s32_v60.sv:5264 MAME stores the LOW 32 BITS of the int64 truncation, not a clamp: well-defined in C for e in [31,62]; e >= 63 saturates the x86 convert to INT64_MIN (low 32 = 0).
rtl/cpu/v60/s32_v60.sv:5275 (MAME: (_S && val>=0) || (!_S && val<=-1); |val| >= 1 here).
rtl/cpu/v60/s32_v60.sv:5390 MAME materializes the subtraction: same-signed infinities give inf-inf = NaN, so they compare Z=0/S=0 like unordered operands.
rtl/debug/ms32_capture_loader.sv:5 Each word becomes one bus write at the CPU address MAME's ms32_map gives it, issued into ms32_cpu_sys's loader port while the V70 is held in reset -- so playback goes through the same decode, RAM ports and register mailbox as the game's own
rtl/memory/ms32_jalcrpt_pkg.sv:3 See that script: MAME reads dest[i] = src[L(i ^ addr_xor)] ^ (i & 0xff) ^ data_xor; the download stores source byte j at i = Linv(j) ^ addr_xor (bg: bits above 19 pass through), XORed with (i & 0xff) ^ data_xor.
rtl/memory/ms32_sdram_top.sv:6 Region sizes are the largest in the game list (ROADMAP "Game scope"); an .mra fills each region by REPEATING its ROM data to the region size, which reproduces MAME's tile-number wrap (off % rom_length) for any ROM length, so the engines sim
rtl/memory/ms32_sdram_top.sv:22 Every other set masks sprite addresses to 24 bits, which with the .mra's repeat is MAME's page wrap for any power-of-two ROM up to 16 MB; spr25 (mod byte bit 4, bbbxing only) masks to 25 bits instead.
rtl/video/ms32_crtc.sv:7 Reset values are MAME's defaults (384 x 263 total, 320 x 224 visible), which the sysctrl comments say the hardware must produce before any write because bnstars1 never programs the CRTC and still expects a vblank.
rtl/video/ms32_crtc.sv:20 That is the MAME screen configuration (visarea 0..hdisplay-1) and the order the tilemap engines assume.
rtl/video/ms32_crtc.sv:23 MAME only logs hbp/hfp/vbp/vfp ("HSYNC back porch", "front porch") and never uses them.
rtl/video/ms32_mixer.sv:3 MS32 mixer, palette and brightness: ms32_v.cpp screen_update() as the pixel-exact model has it (scripts/render_model.py mix()), per dot:
rtl/video/ms32_mixer.sv:17 MAME's case table on (primask, tpri, sprite opaque): 0x00 sprite if opaque 0xf0 ...
rtl/video/ms32_mixer.sv:20 and (tpri & 2) == 0 anything else: black (MAME draws noise for 0xc0 and pops a message) 5.
rtl/video/ms32_mixer.sv:26 The priority RAM is 0x2000 bytes of 8-bit entries; the mixer holds only the 3 + 128 probe results, refreshed by walking the RAM at frame_start, so a change the game makes takes effect at the next frame -- the same granularity as MAME, which
rtl/video/ms32_mixer.sv:162 Where nothing is opaque MAME shows the tilemap's pen 0, i.e. palette entry 0 (the model's zero-initialised tile array); an unhandled primask is black (the model's out[m] = 0).
rtl/video/ms32_mixer.sv:200 A serial shift-add over the dot period would fit at 6 MHz (16 clocks) with 9 steps but has no margin at 8 MHz (12 clocks); three DSP-sized multipliers are the cheaper certainty until the brightness mechanism itself is understood (ROADMAP: M
rtl/video/ms32_objram.sv:4 ms32_v.cpp screen_vblank() copies the whole RAM into m_sprram_buffer at the START of vblank and draw_sprites renders from the copy; the game rewrites the live RAM during that same vblank.
rtl/video/ms32_roz.sv:3 MS32 ROZ line engine: the rotate/zoom tilemap (128x128 tiles of 16x16, 8bpp, palette base 0x2000), transcribed from ms32_v.cpp draw_roz and tilemap_t::draw_roz_core, as the pixel-exact model has it (scripts/render_model.py render_roz):
rtl/video/ms32_roz.sv:20 All of it is 32-bit wrapping arithmetic in MAME; only bits 26:16 of the accumulators reach the map, and addition modulo 2^27 leaves those bits as MAME's, so the accumulators and every term added into them are 27 bits.
rtl/video/ms32_roz.sv:123 Lines are fetched in order once per frame, so the sum is the product MAME computes for registers held across the frame -- the only case MAME renders as intended, since screen_update reads them once.
rtl/video/ms32_sprite.sv:4 Transcribed from ms32_v.cpp draw_sprites, ms32_sprite.cpp extract_parameters and draw_sprite_zoom_core, and checked against the pixel-exact model (scripts/render_model.py render_sprites).
rtl/video/ms32_sprite.sv:30 MAME walks the list tail->0 when sprite_ctrl[0x10] bit 15 is clear (0->tail-1 otherwise) with a first-drawn-wins pixel op.
rtl/video/ms32_sprite.sv:49 sprite_ctrl[0x10] bit 15 CLEAR (MAME's "reverseorder")
rtl/video/ms32_sprite.sv:99 Widths are the largest value each can hold (MAME's are all 32 bits): srcend <= 0x10000 (17), srcstart <= 0xFF00 (16), inc <= 0xFFFF (16) srcx/srcy after the clip <= 1024 x 0xFFFF (26); in a row srcx < srcendx cursrcx < srcendx + incx (18);
rtl/video/ms32_sprite.sv:142 MAME recomputes srcend - cursrcx - 1 for every pixel; the two agree while cursrcx < srcendx, which is the only time pxabs is used.
rtl/video/ms32_tilemap.sv:5 Transcribed from ms32_v.cpp's tilemap setup and the pixel-exact model in scripts/render_model.py (draw_tilemap):
rtl/video/ms32_video.sv:99 MAME's video_start defaults, "tp2m32 doesn't set the brightness registers so we need sensible defaults" (ms32_v.cpp 82-84): the brightness pair 0xFFFF and sprite control 0x10 = 0x8000 (list walked 0->tail).

Says it matches, follows or was checked against MAME — 4

rtl/cpu/ms32_cpu_sys.sv:16 As sim/v70_boot_tb, which matched MAME over 5M accesses of the tetrisp boot: every RAM region mirrors address bits 29:26, so am = a & 0xC3FFFFFF picks the region and the bits each mirror leaves live index it.
rtl/cpu/v60/s32_v60.sv:49 - Single-precision FP (0x5C/0x5F: CMPF/MOVFS/NEGFS/ABSFS/SCLFS/ADDFS/SUBFS/ MULFS/DIVFS/CVTWS/CVTSW): a binary32 unit (round-to-nearest-even, gradual underflow) matching MAME's host-float contract; no System 32 game uses it.
rtl/cpu/v60/s32_v60.sv:3026 Equal AND matches the stop byte: MAME clears CY and breaks; S/Z stay 0 (i != dest), R28/R27 at the current index.
rtl/cpu/v60/s32_v60.sv:4883 1 <= count <= width: exact MAME SHIFTLEFT_OV mask (count==width uses the full-width mask, matching MAME's count==bitsize case, e.g. SHA.B #8,-1 -> OV=0)

Keeps a MAME approximation — 1

rtl/cpu/ms32_sysctrl.sv:21 The timer period is MAME's guess, 500 us * interval (the driver says the real timing is unknown); at clk_cpu = 20 MHz that is 10,000 clocks.

Shares text with the MAME driver without saying so — 7

rtl/cpu/ms32_cpu_sys.sv:40 give the Z80 time to respond"; 800 clk_cpu clocks at 20 MHz — shares text with jaleco/ms32.cpp:502
rtl/cpu/ms32_cpu_sys.sv:308 bits 0-4; the rows selected are ANDed, then bitswap<6>(v, 4,2,3,1,0,5) — shares text with jaleco/ms32.cpp:495
rtl/cpu/v60/s32_v60.sv:4253 "mov.d r31, [r0] ; Write pair R31:R31 to [R0]") — shares text with jaleco/ms32.cpp:455
rtl/video/ms32_sprite.sv:22 drawy = (srcstarty + (flipy ? srcendy - srcy - 1 : srcy)) >> 8; skip row if >= 256 — shares text with jaleco/ms32_sprite.cpp:1068
rtl/video/ms32_sprite.sv:24 drawx = (srcstartx + (flipx ? srcendx - cursrcx - 1 : cursrcx)) >> 8; skip if >= 256 — shares text with jaleco/ms32_sprite.cpp:1079
rtl/video/ms32_video.sv:99 MAME's video_start defaults, "tp2m32 doesn't set the brightness — shares text with jaleco/ms32_v.cpp:90
rtl/video/ms32_video.sv:100 registers so we need sensible defaults" (ms32_v.cpp 82-84): the — shares text with jaleco/ms32_v.cpp:90

Arcade-JalecoMS32F1 (ppriest)#
F-1 Super Battle
ppriest/Arcade-JalecoMS32_MiSTer @ a5ac6abf
MAME compared: jaleco/ms32.cpp + 8 related file(s)
Read: 38 HDL files, 14,051 lines (Quartus project)

ppriest
repository only

Mostly MAME

medium

76%

Statements: 154 toward MAME

Cites MAME source — 131

MS32.sv:9 A capture blob (scripts/build_capture_blob.py, ioctl index 2) can still be loaded with the CPU held (mod byte bit 7), so a frame MAME rendered is rendered by the hardware from the real ROMs.
MS32.sv:40 The mainboard's own output is mono (ms32.cpp header), so the OSD's Stereo Mix defaults to it: status 0 Mono (AUDIO_MIX 3), 1 None (0), 2 25% (1), 3 50% (2).
MS32.sv:261 F-1 Super Battle's controls (ms32.cpp analog_r and the f1superb ports).
MS32.sv:268 AN2 eight switches, all pulled up: MAME calls bit 7 "Shift Brake" and does not know the rest.
MS32.sv:269 Left at 0xFF, as MAME leaves them.
MS32.sv:290 The shifter is a two-position lever, so MAME gives it PORT_TOGGLE: one press of the button changes gear rather than holding it there.
MS32.sv:313 ms32.cpp INPUTS at 0xFCC00004, active low.
MS32.sv:319 keyboard 5 and 6, MAME's coin keys, on every set (decoded below)
MS32.sv:335 Mahjong panel (ms32.cpp ms32_mahjong, mahjong.cpp mahjong_matrix_1p) from a PS/2 keyboard with MAME's default keys: A-N, Kan LCtrl, Pon LAlt, Chi Space, Reach LShift, Ron Z, Start 1 (or joystick Start).
rtl/cpu/jalfpu/jalfpu.sv:11 Where MAME says a thing is unverified or unimplemented, so is this: unknown function codes do nothing, memory selector 0 uses base 0, and the control words other than halt are markers.
rtl/cpu/jalfpu/jalfpu.sv:37 Host window (32-bit bus, same clock), the map jalfpu.cpp's host_map gives: 0x0000-0x23ff data RAM (one u16 per 32-bit slot), 0x2400-0x24ff registers, 0x4000-0x5fff program RAM (a word's argument and opcode in separate longs).
rtl/cpu/jalfpu/jalfpu.sv:51 For sim/jalfpu_tb, which diffs these against MAME's own trace after every instruction.
rtl/cpu/jalfpu/jalfpu.sv:151 jalfpu.cpp's LOAD_SEL, GROUP_REG and MODE_BASE tables
rtl/cpu/jalfpu/jalfpu.sv:201 unknown condition: never taken, as MAME
rtl/cpu/jalfpu/jalfpu.sv:223 The quotient overflows 16 bits exactly when the dividend's high half already reaches the divisor, which also catches division by zero; jalfpu.cpp saturates rather than trapping.
rtl/cpu/jalfpu/jalfpu.sv:243 The routine sits that cycle out: its own port A access or register write in the same cycle would override the host's. MAME has no such overlap -- the V70 never writes while a routine runs there -- but this FPU is slower than MAME's, so on t
rtl/cpu/jalfpu/jalfpu.sv:380 unimplemented, as MAME logs it
rtl/cpu/jalfpu/jalfpu.sv:524 saturate, as jalfpu.cpp does
rtl/cpu/ms32_cpu_sys.sv:3 The MS32 main CPU and its memory map: the vendored V70 (s32_v60, IS_V70) behind ms32_v70_bus, ms32.cpp's ms32_map decoded with its mirrors, work RAM and NVRAM, the CPU port of every video RAM (the RAMs live in ms32_video as dual-clock block
rtl/cpu/ms32_cpu_sys.sv:31 Charles MacDonald's measurements of a Desert War board head MAME's ms32.cpp; docs/HARDWARE_NOTES.md checks this module against each (memory map, mirroring, sound latches, I/O ports, unused-space reads).
rtl/cpu/ms32_cpu_sys.sv:39 ms32.cpp sound_command_w spins the V70 for 40 us after a latch write "to give the Z80 time to respond"; 800 clk_cpu clocks at 20 MHz
rtl/cpu/ms32_cpu_sys.sv:312 The road RAMs hold what the game uses, not what MAME declares; a write past the end wraps, and is counted so the probe can say it happened.
rtl/cpu/ms32_cpu_sys.sv:338 ms32.cpp mahjong_ctrl_r: 0xFD1C0000 (write-only) selects key rows by bits 0-4; the rows selected are ANDed, then bitswap<6>(v, 4,2,3,1,0,5) puts the Start column in bit 0, and bits 7:6 read 1.
rtl/cpu/ms32_cpu_sys.sv:354 ------------------------------------------------------------- sound latches ms32.cpp: 0xFC800000 loads the Z80's command latch (in ms32_sound); the Z80's write to 0x3F10 loads to_main and raises IRQ level 1; 0xFD000000 returns to_main inver
rtl/cpu/ms32_cpu_sys.sv:422 The comms RAM is the link board's, which is not emulated -- MAME keeps the RAM and so does this, or the game's test mode reports FLAM ERROR.
rtl/cpu/ms32_cpu_sys.sv:474 ms32.cpp maps this one as plain .ram() with no umask32, unlike every other 16-bit region on this bus, so a 16-bit RAM here drops the top half of every write.
rtl/cpu/ms32_cpu_sys.sv:536 AN2 is a bank of eight pulled-up switches; MAME names only bit 7, "Shift Brake", and reads them all off.
rtl/cpu/ms32_sysctrl.sv:3 The interrupt side of jaleco_ms32_sysctrl plus ms32.cpp's irq_raise, in the CPU's clock domain.
rtl/cpu/ms32_sysctrl.sv:7 ms32.cpp: m_irqreq is a 16-bit set of levels; the V70's line is asserted while any bit is set and irq_callback() returns the highest set bit.
rtl/cpu/ms32_sysctrl.sv:93 jaleco_ms32_sysctrl calls m_field_cb at the vblank line when inverted, and ms32.cpp wires m_vblank_cb to level 10 and m_field_cb to level 9 unconditionally, so vblank_ack (m_vblank_cb(0)) clears 10 and field_ack clears 9 on every set.
rtl/cpu/ms32_v70_bus.sv:33 word a[1:0]==0 1 otherwise 2 Unaligned halves and words are legal on a V70 and MAME's core issues them (read_dword_unaligned throughout v60.cpp); the trace shows the CPU doing exactly that on tetrisp's boot.
rtl/cpu/v60/s32_v60.sv:21 2026-09-13 Charles MacDonald's hardware notes (ms32.cpp header): PIR reads 0x00007007 on a uPD70632GD-20 (was MAME's 0x7000), and MOV.D's register-pair source for R31 is R31:R31, not R31 and the register after it.
rtl/cpu/v60/s32_v60.sv:25 2026-09-13 MAME's dim 3 (qword) operands: MOVD's register source in the F2 D=0 short form is the register PAIR (op1 an lvalue, as XCH), and autoincrement, autodecrement and index scaling step by 8 for MOVD's operands and the second operand
rtl/cpu/v60/s32_v60.sv:37 Behavioral contract is MAME's v60 core (BSD-3-Clause, Farfetch'd / R. Belmont): opcode dispatch per optable.hxx, addressing modes per am1-3.hxx, exception entry per v60.cpp.
rtl/cpu/v60/s32_v60.sv:45 the fill/stop variants (MOVC*/CMPC*/SCHC*/SKPC*), TASI, bit ops, GETPSW/UPDPSW, TRAP/TRAPFL/BRK/BRKV, CHLVL, task save/load, privileged register moves (LDPR/STPR), and MAME-defined decimal/bit- string/bit-field groups.
rtl/cpu/v60/s32_v60.sv:52 - Not implemented (reserved-instruction exception, logged in sim): the un-dispatched 0x5C/0x5F sub-opcodes (MAME UNHANDLED).
rtl/cpu/v60/s32_v60.sv:53 MMU/TLB effects are absent like MAME, but CLRTLB still decodes its complete operand.
rtl/cpu/v60/s32_v60.sv:63 V60/V70 reset PC (MAME m_start_pc; audit V60-21)
rtl/cpu/v60/s32_v60.sv:167 PSW fields (MAME bit layout: Z=b0,S=b1,OV=b2,CY=b3,IE=b18,EL=b25:24,IS=b28)
rtl/cpu/v60/s32_v60.sv:727 C-style truncating divide-by-8 of a signed bit offset (MAME bamoffset/8)
rtl/cpu/v60/s32_v60.sv:817 stack switch on IS change, or EL change while IS=0 (MAME v60WritePSW)
rtl/cpu/v60/s32_v60.sv:1065 [MS32] qword operands, MAME's moddim 3 (op12.hxx): both of MOVD's, and the second of MULX/MULUX/DIVX/DIVUX.
rtl/cpu/v60/s32_v60.sv:1264 primary dispatch (per MAME optable.hxx)
rtl/cpu/v60/s32_v60.sv:1269 BRK — MAME skips this opcode (A4)
rtl/cpu/v60/s32_v60.sv:1289 ---- Bcc disp8 (0x60-0x6a,0x6c-0x6f) / disp16 equivalent ---- 0x6B/0x7B are holes in MAME's authoritative primary dispatch table, not branch-condition encodings.
rtl/cpu/v60/s32_v60.sv:1349 MAME opDBcc: reg ALWAYS decrements; branch iff cond true and decremented reg != 0.
rtl/cpu/v60/s32_v60.sv:1455 JMP/JSR/TASI: MAME sets moddim=0 — the dim scales INDEXED modes' index register, and ga2's jump tables (3-byte BR entries, `JMP [PC+d](rN)`) rely on the unscaled index (found by real-ROM boot: dim=2 quadrupled the index and jumped mid-table
rtl/cpu/v60/s32_v60.sv:1481 RETI adj (halfword, MAME moddim=1)
rtl/cpu/v60/s32_v60.sv:1505 MAME F7a/F7b decode with dim 0 (0x58 byte) / 1 (0x5A half): autoincrement/indexed AMs step and scale by the element size, and F7b immediates size accordingly — not dword.
rtl/cpu/v60/s32_v60.sv:1525 MAME implements ADDDC/SUBDC/SUBRDC/CVTDPZ/CVTDZP (radm timer); remaining subops are reserved there too.
rtl/cpu/v60/s32_v60.sv:1614 Unhandled sub-opcodes still take the reserved-instruction vector exactly as MAME's op5C/op5F UNHANDLED entries fatalerror.
rtl/cpu/v60/s32_v60.sv:1656 RSR (A9): pop PC ONLY (MAME opRSR: PC=[SP]; SP+=4)
rtl/cpu/v60/s32_v60.sv:1661 MAME/NEC floating-exception test: enabled TKCW causes are intersected with the PSW floating-status field.
rtl/cpu/v60/s32_v60.sv:1690 F12: plan operands per instflags (MAME F12DecodeOperands)
rtl/cpu/v60/s32_v60.sv:1699 MOVEA takes op1 as an ADDRESS (MAME ReadAMAddress) — decoding it as a value loaded SP with a byte read instead of the EA and sent ga2's boot stub off a cliff (found by real-ROM boot)
rtl/cpu/v60/s32_v60.sv:2331 MAME opDIVX/opDIVUX set only S/Z and leave OV unchanged; do not clear it.
rtl/cpu/v60/s32_v60.sv:2363 MAME opROTC*: the carry bit enters the active operand's LSB; bits above a byte/halfword operand are not part of the ring.
rtl/cpu/v60/s32_v60.sv:2694 pops (8) + frame-destroy operand (MAME: SP += amout), then the PSW write may bank-switch SP — order matters: adjust THEN switch.
rtl/cpu/v60/s32_v60.sv:2736 push highest set register first (MAME pushes from r31 down?
rtl/cpu/v60/s32_v60.sv:2784 TASI sets flags as SUBB(old, 0xFF, 0) before writing 0xFF (MAME opTASI).
rtl/cpu/v60/s32_v60.sv:2821 R27 (dst) / R28 (src) updated at completion (MAME MOVSTR).
rtl/cpu/v60/s32_v60.sv:2830 Element-size dim for both (MAME dim 0 byte / 1 half — see decode).
rtl/cpu/v60/s32_v60.sv:2847 V60-15: down-direction search (subop[0]=1, MAME opSEARCHD*).
rtl/cpu/v60/s32_v60.sv:2849 The down form scans the range in descending order from MAME's start index: byte reads op1+len1 down to op1 (len1+1 reads; the first read is one past the buffer, exactly as opSEARCHDB does), half reads op1+(len1-1)*2 down to op1 (len1 reads)
rtl/cpu/v60/s32_v60.sv:2874 MOVCD/MOVCFD (down copy) transfers the ascending range base..base+min-1 in descending element order (MAME opMOVSTRD): start at the TOP of that range and decrement, instead of walking physically below the base as the old code did (audit R20
rtl/cpu/v60/s32_v60.sv:2883 CMPCS (0x02): stop mode starts with CY=1, cleared when a fill (R26) byte is met in the compare (MAME opCMPSTR bStop).
rtl/cpu/v60/s32_v60.sv:2886 CMPCF (0x01): fill the SHORTER operand's tail with R26 BEFORE the compare (MAME bFill); MOVC fill happens AFTER the copy.
rtl/cpu/v60/s32_v60.sv:2915 Down exhaustion: the scan ran off the bottom to i=-1 (MAME opSEARCHD*), so Z=0, R27=0xFFFFFFFF, and str_src has already reached op1-step.
rtl/cpu/v60/s32_v60.sv:2930 CMPC exhausted the common prefix (all min elements equal): R28=len1+min*step, R27=len2+min*step, and S/Z from the length compare (MAME opCMPSTR tail).
rtl/cpu/v60/s32_v60.sv:2965 Z follows MAME's post-loop test i==len1: up never breaks at i==len1 (Z=0), down does so only at its one-past-the-top byte read (str_cnt==len1+1).
rtl/cpu/v60/s32_v60.sv:3004 CMPC (MAME opCMPSTR): compare source(op1) vs dest(op2).
rtl/cpu/v60/s32_v60.sv:3263 BAM: bit addressing modes for the 0x5B/0x5D groups (MAME BAMTable1/2 implemented subset — everything MAME fatalerrors on traps here too).
rtl/cpu/v60/s32_v60.sv:3737 exception / interrupt entry (MAME v60_do_irq): switch to interrupt context, push old PSW, push PC, PC = vector
rtl/cpu/v60/s32_v60.sv:3975 per-opcode dim helpers (operand sizes per MAME op12 handlers)
rtl/cpu/v60/s32_v60.sv:3977 F12 ops whose FIRST operand is an effective address, not a value (MAME F12DecodeFirstOperand(ReadAMAddress, ...)): MOVEA and IN
rtl/cpu/v60/s32_v60.sv:3998 NOTE: ROTH (8b) / ROTCH (9b) must NOT appear here — their op1 is the rotate COUNT, a byte (MAME ReadAM dim 0); listing them in the half group made `ROT.H #imm8, r6` decode one byte long and holo's EEPROM write loop entered mid-instruction (
rtl/cpu/v60/s32_v60.sv:4031 These read op2 as a VALUE (MAME ReadAM), so a memory operand must be loaded into op2val before exec; otherwise the exec fell back to the effective address / a stale op2val (audit R20 V60-18).
rtl/cpu/v60/s32_v60.sv:4117 MOVC completion (MAME opMOVSTRU*/opMOVSTRD*): publish R28/R27 for the final element index `idx`, and — for the fill variants (MOVCFU/MOVCFD) with the source shorter than the destination — kick off the R26 tail-fill phase.
rtl/cpu/v60/s32_v60.sv:4140 MAME pads the destination tail elements [idx, lenop2) with R26; the down form uses op2+dest+(lenop2-j-1) for bytes and op2+(lenop2-j-1)*2 for halves.
rtl/cpu/v60/s32_v60.sv:4221 MAME MOV sets no flags?
rtl/cpu/v60/s32_v60.sv:4344 A zero count must clear CY (MAME); the old code left it unchanged (audit R20 V60-7).
rtl/cpu/v60/s32_v60.sv:4371 MAME defines CY from the post-rotate wrap bit: LSB after a positive (left) rotate, MSB after a negative (right) rotate.
rtl/cpu/v60/s32_v60.sv:4382 MAME clears CY for a zero count; nonzero counts retain the final shifted-out bit, so only bypass the iterative state for zero.
rtl/cpu/v60/s32_v60.sv:4443 MAME divide-by-zero: destination unchanged and no trap, but Z/S are still set from the (unchanged) destination = the dividend, and OV is cleared (audit R20 V60-8); the old code left flags stale.
rtl/cpu/v60/s32_v60.sv:4476 MAME sets OV and leaves the destination unchanged (audit R20 V60-8); the old code always cleared OV and wrote the wrapped quotient.
rtl/cpu/v60/s32_v60.sv:4494 MAME opMULX/opMULUX leave OV unchanged
rtl/cpu/v60/s32_v60.sv:4510 MAME: no zero-divide trap
rtl/cpu/v60/s32_v60.sv:4582 MAME opCALL: SP-=4; [SP]=AP; AP=op2; SP-=4; [SP]=retPC; PC=op1.
rtl/cpu/v60/s32_v60.sv:4619 MAME opTRAP: the operand's HIGH nibble is a Bcc-encoded condition (cond 0xB never traps); only trap when it evaluates true, else fall through.
rtl/cpu/v60/s32_v60.sv:4869 SHA left-shift overflow (MAME SHIFTLEFT_OV op12.hxx): OV is set when the top `count` bits of the width-sized value are not all equal to the sign bit — i.e. a bit different from the sign is shifted out through the top.
rtl/cpu/v60/s32_v60.sv:4871 MAME masks exactly `count` bits (((1<<count)-1) << (bitsize-count)); using count+1 here spuriously set OV (e.g. SHA.B #1,0x40 gave OV=1 vs MAME OV=0), misbranching a following signed Bcc (S^OV).
rtl/cpu/v60/s32_v60.sv:4882 count > width: MAME's macro is UB here (bitsize-count<0); any nonzero value overflowed
rtl/cpu/v60/s32_v60.sv:4958 MAME opMUL/opMULU: OV = (product >> width) != 0 on the product's unsigned bit pattern (signed product for MUL, unsigned for MULU).
rtl/cpu/v60/s32_v60.sv:4960 For byte/half MAME shifts the 32-bit value; for word, the 64-bit one.
rtl/cpu/v60/s32_v60.sv:4983 MAME clears OV for REM/REMU (audit R20 V60-8)
rtl/cpu/v60/s32_v60.sv:4992 Behavioral contract is MAME op2.hxx/op5.hxx, which use host `float` — round-to-nearest-even, with gradual underflow (subnormals) and IEEE special values.
rtl/cpu/v60/s32_v60.sv:5008 NEGFS/ABSFS are NOT: MAME does ReadAMAddress + store only (no load) — they operate on op1 and must not read a possibly read-sensitive destination.
rtl/cpu/v60/s32_v60.sv:5184 Deliberate divergence from the pinned MAME for |n| > 30: MAME computes `appf * / (1 << n)` with the host's shift-count masking (&31, and 1 << 31 = INT_MIN there), so e.g. SCLFS(31) flips the sign and SCLFS(32) is a no-op on x86.
rtl/cpu/v60/s32_v60.sv:5241 Pinned MAME converts (uint32_t)(int64_t)val on its x86 host: NaN and out-of-int64-range saturate the hardware convert to INT64_MIN, whose low 32 bits are 0.
rtl/cpu/v60/s32_v60.sv:5264 MAME stores the LOW 32 BITS of the int64 truncation, not a clamp: well-defined in C for e in [31,62]; e >= 63 saturates the x86 convert to INT64_MIN (low 32 = 0).
rtl/cpu/v60/s32_v60.sv:5275 (MAME: (_S && val>=0) || (!_S && val<=-1); |val| >= 1 here).
rtl/cpu/v60/s32_v60.sv:5390 MAME materializes the subtraction: same-signed infinities give inf-inf = NaN, so they compare Z=0/S=0 like unordered operands.
rtl/debug/ms32_capture_loader.sv:5 Each word becomes one bus write at the CPU address MAME's ms32_map gives it, issued into ms32_cpu_sys's loader port while the V70 is held in reset -- so playback goes through the same decode, RAM ports and register mailbox as the game's own
rtl/memory/ms32_jalcrpt_pkg.sv:3 See that script: MAME reads dest[i] = src[L(i ^ addr_xor)] ^ (i & 0xff) ^ data_xor; the download stores source byte j at i = Linv(j) ^ addr_xor (bg: bits above 19 pass through), XORed with (i & 0xff) ^ data_xor.
rtl/memory/ms32_sdram_top.sv:6 Region sizes are the largest in the game list (ROADMAP "Game scope"); an .mra fills each region by REPEATING its ROM data to the region size, which reproduces MAME's tile-number wrap (off % rom_length) for any ROM length, so the engines sim
rtl/memory/ms32_sdram_top.sv:22 Every other set masks sprite addresses to 24 bits, which with the .mra's repeat is MAME's page wrap for any power-of-two ROM up to 16 MB; spr25 (mod byte bit 4, bbbxing and f1superb) masks to 25 bits instead.
rtl/video/ms32_crtc.sv:7 Reset values are MAME's defaults (384 x 263 total, 320 x 224 visible), which the sysctrl comments say the hardware must produce before any write because bnstars1 never programs the CRTC and still expects a vblank.
rtl/video/ms32_crtc.sv:20 That is the MAME screen configuration (visarea 0..hdisplay-1) and the order the tilemap engines assume.
rtl/video/ms32_crtc.sv:23 MAME only logs hbp/hfp/vbp/vfp ("HSYNC back porch", "front porch") and never uses them.
rtl/video/ms32_crtc.sv:39 Interrupt events, one clk each, at the moments jaleco_ms32_sysctrl's scanline timer raises them: vblank_ev when vcnt reaches vdisplay, field_ev when vcnt reaches 0 on an odd frame (the 30 Hz "field" line) -- or, with FIELD_LAST_ACTIVE, when
rtl/video/ms32_lineplane.sv:336 G_ROW2 left the line's colour word here; a line that draws nothing reports zero, as MAME's line_colour[] does, so the mixer's depth bits match when both planes are blank
rtl/video/ms32_mixer.sv:3 From ms32_v.cpp mix_layers() as of MAME PR 16243 (ms32_state's for the twenty-one sets, ms32_f1superbattle_state's for F1=1), checked against scripts/render_model.py mix() and mix_f1().
rtl/video/ms32_mixer.sv:24 F1=1: no brightness (MAME's f1superb mixer applies none), and bit 2 clear halves every layer.
rtl/video/ms32_mixer.sv:27 Not here: MAME's apply_sprite_effects() second pass, which redoes the lookup where a sprite's box covers a pixel but no pen of it is opaque.
rtl/video/ms32_mixer.sv:33 The index is formed and read every dot, so a change the game makes to the priority RAM takes effect immediately, as MAME reads it per pixel.
rtl/video/ms32_mixer.sv:76 MAME tests the pen's low byte
rtl/video/ms32_mixer.sv:112 3, 5, 7: nothing, as MAME
rtl/video/ms32_objram.sv:4 ms32_v.cpp screen_vblank() copies the whole RAM into m_sprram_buffer at the START of vblank and draw_sprites renders from the copy; the game rewrites the live RAM during that same vblank.
rtl/video/ms32_roz.sv:3 MS32 ROZ line engine: the rotate/zoom tilemap (128x128 tiles of 16x16, 8bpp, palette base 0x2000), transcribed from ms32_v.cpp draw_roz and tilemap_t::draw_roz_core, as the pixel-exact model has it (scripts/render_model.py render_roz):
rtl/video/ms32_roz.sv:20 All of it is 32-bit wrapping arithmetic in MAME; only bits 26:16 of the accumulators reach the map, and addition modulo 2^27 leaves those bits as MAME's, so the accumulators and every term added into them are 27 bits.
rtl/video/ms32_roz.sv:123 Lines are fetched in order once per frame, so the sum is the product MAME computes for registers held across the frame -- the only case MAME renders as intended, since screen_update reads them once.
rtl/video/ms32_sprite.sv:4 Transcribed from ms32_v.cpp draw_sprites, ms32_sprite.cpp extract_parameters and draw_sprite_zoom_core, and checked against the pixel-exact model (scripts/render_model.py render_sprites).
rtl/video/ms32_sprite.sv:30 MAME walks the list tail->0 when sprite_ctrl[0x10] bit 15 is clear (0->tail-1 otherwise) with a first-drawn-wins pixel op.
rtl/video/ms32_sprite.sv:62 sprite_ctrl[0x10] bit 15 CLEAR (MAME's "reverseorder")
rtl/video/ms32_sprite.sv:97 The first drawn sprite of the frame carrying flipy, with the slot it came from: MAME never sets that bit in this game, so whatever is here says whether the record is a plausible sprite or corrupted object RAM.
rtl/video/ms32_sprite.sv:160 Widths are the largest value each can hold (MAME's are all 32 bits): srcend <= 0x10000 (17), srcstart <= 0xFF00 (16), inc <= 0xFFFF (16) srcx/srcy after the clip <= 1024 x 0xFFFF (26); in a row srcx < srcendx cursrcx < srcendx + incx (18);
rtl/video/ms32_sprite.sv:202 MAME recomputes srcend - cursrcx - 1 for every pixel; the two agree while cursrcx < srcendx, which is the only time pxabs is used.
rtl/video/ms32_tilemap.sv:5 Transcribed from ms32_v.cpp's tilemap setup and the pixel-exact model in scripts/render_model.py (draw_tilemap):
rtl/video/ms32_video.sv:131 MAME's video_start defaults, "tp2m32 doesn't set the brightness registers so we need sensible defaults" (ms32_v.cpp 82-84): the brightness pair 0xFFFF and sprite control 0x10 = 0x8000 (list walked 0->tail).
rtl/video/ms32_video.sv:157 ms32_crtc: MAME's set_field_irq_last_active_line
rtl/video/ms32_video.sv:211 The game writes 448 words of the map and 2,048 of the line RAM, where MAME declares 32,768 of each; the decode wraps rather than the address widening, and ms32_core counts a write that reaches past the end.

Says it matches, follows or was checked against MAME — 6

rtl/cpu/jalfpu/jalfpu.sv:168 selector 0 unverified, as in MAME
rtl/cpu/ms32_cpu_sys.sv:16 As sim/v70_boot_tb, which matched MAME over 5M accesses of the tetrisp boot: every RAM region mirrors address bits 29:26, so am = a & 0xC3FFFFFF picks the region and the bits each mirror leaves live index it.
rtl/cpu/v60/s32_v60.sv:49 - Single-precision FP (0x5C/0x5F: CMPF/MOVFS/NEGFS/ABSFS/SCLFS/ADDFS/SUBFS/ MULFS/DIVFS/CVTWS/CVTSW): a binary32 unit (round-to-nearest-even, gradual underflow) matching MAME's host-float contract; no System 32 game uses it.
rtl/cpu/v60/s32_v60.sv:3026 Equal AND matches the stop byte: MAME clears CY and breaks; S/Z stay 0 (i != dest), R28/R27 at the current index.
rtl/cpu/v60/s32_v60.sv:4883 1 <= count <= width: exact MAME SHIFTLEFT_OV mask (count==width uses the full-width mask, matching MAME's count==bitsize case, e.g. SHA.B #8,-1 -> OV=0)
rtl/video/ms32_video.sv:102 A window on the video RAMs, for dumping them off a running board and rendering the result with scripts/render_model.py -- the same renderer that matches MAME pixel for pixel, so it says whether the RAM is right and the RTL wrong, or the RAM

Says it was translated, ported or taken from MAME — 2

rtl/cpu/jalfpu/jalfpu.sv:7 TRANSCRIBED FROM MAME's src/devices/cpu/jalfpu/jalfpu.cpp (BSD-3-Clause, copyright Andrea Bogazzi), from mamedev/mame PR 16135.
rtl/video/ms32_lineplane.sv:6 Transcribed from ms32_v.cpp draw_line_plane() as MAME PR 16135 adds it, and checked against scripts/render_model.py, which renders a whole f1superb frame pixel for pixel (ROADMAP, "F-1 Super Battle").

Keeps a MAME approximation — 2

rtl/cpu/jalfpu/jalfpu.sv:26 The real chip's clock is unknown -- MAME guesses 48 MHz / 8 and runs one instruction per cycle.
rtl/cpu/ms32_sysctrl.sv:23 The timer period is MAME's guess, 500 us * interval (the driver says the real timing is unknown); at clk_cpu = 20 MHz that is 10,000 clocks.

Shares text with the MAME driver without saying so — 13

MS32.sv:266 pressed -- the game takes the rest value at boot and subtracts. — shares text with jaleco/ms32.cpp:1414
rtl/cpu/ms32_cpu_sys.sv:40 give the Z80 time to respond"; 800 clk_cpu clocks at 20 MHz — shares text with jaleco/ms32.cpp:502
rtl/cpu/ms32_cpu_sys.sv:339 bits 0-4; the rows selected are ANDed, then bitswap<6>(v, 4,2,3,1,0,5) — shares text with jaleco/ms32.cpp:495
rtl/cpu/v60/s32_v60.sv:4253 "mov.d r31, [r0] ; Write pair R31:R31 to [R0]") — shares text with jaleco/ms32.cpp:455
rtl/video/ms32_crtc.sv:43 MAME's set_field_irq_last_active_line(), which F-1 Super Battle alone has. — shares text with jaleco/jaleco_ms32_sysctrl.h:45
rtl/video/ms32_mixer.sv:12 bit 8 road plane transparent (always 1 unless F1) — shares text with jaleco/ms32_v.cpp:178
rtl/video/ms32_mixer.sv:15 bits 2-0 line depth (F1 only, else 0): colour bits 6-4 of the ROZ — shares text with jaleco/ms32_v.cpp:181
rtl/video/ms32_mixer.sv:18 and the byte there says what to show: bits 5-3 the layer (0 sprite, 1 BG, — shares text with jaleco/ms32_v.cpp:183
rtl/video/ms32_sprite.sv:22 drawy = (srcstarty + (flipy ? srcendy - srcy - 1 : srcy)) >> 8; skip row if >= 256 — shares text with jaleco/ms32_sprite.cpp:1068
rtl/video/ms32_sprite.sv:24 drawx = (srcstartx + (flipx ? srcendx - cursrcx - 1 : cursrcx)) >> 8; skip if >= 256 — shares text with jaleco/ms32_sprite.cpp:1079
rtl/video/ms32_video.sv:131 MAME's video_start defaults, "tp2m32 doesn't set the brightness — shares text with jaleco/ms32_v.cpp:90
rtl/video/ms32_video.sv:132 registers so we need sensible defaults" (ms32_v.cpp 82-84): the — shares text with jaleco/ms32_v.cpp:90
rtl/video/ms32_video.sv:157 ms32_crtc: MAME's set_field_irq_last_active_line — shares text with jaleco/jaleco_ms32_sysctrl.h:45

Arcade-Jedi (Usquebagh)#
Return of the Jedi
Usquebagh/Arcade-Jedi_MiSTer @ 0463a8dd
MAME compared: atari/jedi.cpp
Read: 11 HDL files, 4,263 lines (Quartus project)

Usquebagh
repository only

Mostly MAME

low

56%

Statements: 3 toward hardware, 16 toward MAME, 10 not counted

Cites hardware documentation that MAME's driver does not — 3

rtl/jedi_core.v:375 ---- TMS5220 speech (sheet 7A) ---------------------------------------------- 1100 data latch (4D), 1200/1300 /WS strobe on/off (A8), 1500 D0 = speech enable (gates the chip's supply on the real board; modelled as output mute), 1C00 b7 = /R
rtl/jedi_timing.v:1 Video timing (SP-227 sheet 4A).
README.md:17 | **Video** | Alphanumerics, scrolling playfield, 48 motion objects, 1024-colour palette with no priority logic | `jedi_core.v`, from the SP-227 schematics |

Cites hardware references or measurements that MAME's driver also gives — 10

rtl/jedi_core.v:21 136030-126 (playfield planes, first half) — also in MAME: 136030-126 atari/jedi.cpp:1000
rtl/jedi_core.v:22 136030-127 — also in MAME: 136030-127 atari/jedi.cpp:1001
rtl/jedi_core.v:23 136030-130 + -131 — also in MAME: 136030-130 atari/jedi.cpp:1004
rtl/jedi_core.v:24 136030-128 + -129 — also in MAME: 136030-128 atari/jedi.cpp:1006
rtl/jedi_core.v:25 136030-117 (horizontal smoothing) — also in MAME: 136030-117 atari/jedi.cpp:1010
rtl/jedi_core.v:26 136030-118 (vertical smoothing) — also in MAME: 136030-118 atari/jedi.cpp:1011
rtl/jedi_core.v:304 Output latch 14J (LS259): 0/1 coin counters, 2/3 LEDs, 4 alpha bank, 6 sound /reset, 7 video off — also in MAME: 14J atari/jedi.cpp:922
rtl/jedi_core.v:561 82S137 smoothing PROMs, 4 pages of 256 x 4 selected by the PIXI register — also in MAME: 82S137 atari/jedi.cpp:16
rtl/jedi_core.v:573 PIXI II line buffer (2149 at 2A): previous line's pre-smoothed pixels — also in MAME: 2A atari/jedi.cpp:471
README.md:18 | **Smoothing** | PIXI II board: two 82S137 PROMs + line buffer blend each background pixel with its neighbours | Modelled in `jedi_core.v` | — also in MAME: 82S137 atari/jedi.cpp:16

Cites MAME source — 13

Arcade-Jedi.sv:163 0C00: b7 coin R, b6 coin L, b5 aux coin, b4 /self-test, b3 spare (reads 0 in MAME), b2 /L thumb, b1 /trigger, b0 /R thumb - all active low
rtl/jedi_core.v:121 Asserted while 32V is low (MAME: lines 64,128,192,256 assert; 32,96,...
rtl/jedi_core.v:174 EEPROM defaults (rtl/novram_init.hex) start from MAME's fill (0x0F, 0x50-0x5F zero), but all-zero data has a *valid* checksum in the small blocks, so: - stats (50-54, checksum 5C) and options (55-56, checksum 5D) get checksum FF, making the
rtl/jedi_core.v:544 Processed per pixel pair (MAME draw_background_and_text).
rtl/jedi_core.v:583 MAME clears it at the top of the frame
rtl/jedi_core.v:722 States 16..23 write pixels 0..7 (transparent colour 0 is skipped; later sprites overwrite earlier ones, as in MAME)
rtl/jedi_timing.v:8 Visible area 296 x 240 as in MAME.
rtl/pokey.v:2 Behaviour follows the Atari POKEY data sheet and MAME's pokey.cpp, including its poly4/poly5/poly9/poly17 generator definitions.
rtl/pokey.v:24 Polynomial counters, stepped every POKEY clock (MAME poly_init_*)
rtl/pokey.v:192 RANDOM = inverted poly bits (MAME); IRQST/SKSTAT idle; pots/keyboard/serial = 0
rtl/tms5220/TMS5220.vhd:18 References: TMS5220 datasheet, US Patent US4335277 and TMS5220.cpp from MAME source code.
README.md:53 Use the MAME "jedi" set.
README.md:76 **Reference:** MAME `jedi` driver by Dan Boris and Aaron Giles

Says it matches, follows or was checked against MAME — 1

rtl/jedi_core.v:425 Relative levels are provisional (to be matched against MAME's mixer).

Says it was translated, ported or taken from MAME — 2

rtl/tms5220/TMS5220.vhd:20 IMPORTANT NOTES: 1) This implementation does NOT implement the schematic in US4335277 2) It is based primarily on MAME source code and aims to be "functionally equivalent" to the "TMS5220" chip but not identical in terms of electrical circu
README.md:75 **Cheats:** converted from the MAME cheat file at [mamecheat.co.uk](https://www.mamecheat.co.uk)

Arcade-Kikikaikai (alpuy)#
KiKi KaiKai
alpuy/Arcade-Kikikaikai_MiSTer @ 8e31882e
MAME compared: taito/kikikai.cpp
Read: 23 HDL files, 11,356 lines (Quartus project)

alpuy
repository only

Not enough evidence in the code

insufficient

Statements: 1 toward hardware, 8 toward MAME

Cites hardware documentation that MAME's driver does not — 1

rtl/kikikai_core.sv:31 24 MHz matches the board's own master oscillator, so cen_6m/cen_3m below are the same /4 and /8 the schematic actually uses.

Cites MAME source — 7

rtl/kikikai_core.sv:172 IN1/IN2 bit order (kikikai.cpp INPUT_PORTS): up,down,left,right,ofuda,oharai.
rtl/kikikai_maincpu.sv:133 F800-FFFF: "subram", the 4-player sub-board comms RAM (main_map, kikikai.cpp) -- unused by this game's own logic, but it's real, readable/writable RAM on the address bus regardless, and a boot-time sweep does walk through it.
rtl/video/gfx_decode.sv:1 Kiki KaiKai charlayout tile pixel decode, kikikai.cpp:964-977.
rtl/video/gfx_decode.sv:5 Final pixel value is assembled MSB-first over MAME's planeoffset array (plane0 -> bit 3), not LSB-first as the array order suggests -- see docs/LESSONS_LEARNED.md, [Kikikaikai], for how that was found.
rtl/video/palette_dac.sv:1 palette_device::palette_init_rgb_444_proms (src/emu/emupal.cpp): a weighted-resistor ladder per gun, not a linear 4-bit expansion -- 0x0e/0x1f/0x43/0x8f per bit.
README.md:3 A MiSTer FPGA core for Taito's Kiki KaiKai (1986) arcade hardware (MAME's `src/mame/taito/kikikai.cpp`), built with Quartus Prime 17.0.2 Lite for the DE10-nano.
README.md:93 The **MAMEdev team** — Ernesto Corvi (original driver author) and contributors, including mamehaze's MC6801U4 hookup and Raki's firmware dump — for `src/mame/ta

Shares text with the MAME driver without saying so — 1

rtl/kikikai_core.sv:135 in_p1_cb().set_ioport("IN0").invert() — shares text with taito/kikikai.cpp:1088

Arcade-MajorHavoc (blahm1dplays)#
Major Havoc
blahm1dplays/Arcade-MajorHavoc_MiSTer @ 74f677fc
MAME compared: atari/mhavoc.cpp
Read: 14 HDL files, 5,989 lines (Quartus project)

blahm1dplays
repository only

Mostly MAME

low

27%

Statements: 35 toward MAME, 2 not counted

Cites hardware references or measurements that MAME's driver also gives — 2

rtl/avg/avg_majorhavoc.vhd:3 Same AVG family + same micro-instruction PROM (136002-125) as Tempest/Gravitar, so the FSM and opcodes are identical. — also in MAME: 136002-125 atari/mhavoc.cpp:39
rtl/majorhavoc.vhd:279 MAME alpha_map RAM regions (exact): $0000-01FF RAM A, $0200-07FF bank, $0800-09FF RAM B, $0A00-0FFF bank. — also in MAME: 01FF atari/mhavoc.cpp:50, 07FF atari/mhavoc.cpp:51, 09FF atari/mhavoc.cpp:52

Cites MAME source — 32

Arcade-StarWars.sv:422 HW-VERIFY direction (MAME IPT_DIAL PORT_REVERSE) -- negate sp_delta / flip m_inc if inverted.
rtl/avg/avg_majorhavoc.vhd:10 * AVG fetch path (memory_din, 14-bit pc; MAME avg_mhavoc_device::update_databus): pc $0000-$0FFF vector RAM (4K) -> inferred 4K vecram pc $1000-$1FFF vector ROM (4K) -> vecrom[$0000-$0FFF]
rtl/avg/avg_majorhavoc.vhd:20 (MAME alpha_map: $5000 vectorrom @0, $6000 vectorrom @$1000 mirror $1000.
rtl/avg/avg_majorhavoc.vhd:91 AVG X-flip (MAME m_xdac_xor) = STAT bit 10
rtl/avg/avg_majorhavoc.vhd:93 sparkle LFSR (MAME m_spkl_shift)
rtl/avg/avg_majorhavoc.vhd:148 MAME mhavoc_data: m_bank_region[(m_map<<13) | (pc & $1FFF)].
rtl/avg/avg_majorhavoc.vhd:165 X-flip (MAME mhavoc_strobe2: STAT b10 -> m_xdac_xor=0x1FF inverts the X DAC): negate the X delta so symmetric content (e.g. maze halves) draws mirrored.
rtl/avg/avg_majorhavoc.vhd:184 MAME centres the AVG at m_xcenter/m_ycenter (mid-screen) and the X/Y DACs XOR the position with 0x200 to convert the signed accumulator to unsigned screen coords.
rtl/avg/avg_majorhavoc.vhd:197 Sparkle LFSR free-runs (MAME mhavoc_strobe3): next = (shift<<1) | (b6 xor b5 xor 1), reset to 0 if the low 7 bits hit all-ones (the lock state).
rtl/avg/avg_majorhavoc.vhd:211 MAME mhavoc_vgrst clears m_enspkl
rtl/avg/avg_majorhavoc.vhd:431 SPARKLE (MAME mhavoc_strobe3): when enabled the colour twinkles from the UPPER palette colorram[0xF + bitswap<4>(spkl,0,2,4,6)] driven by the free-running LFSR; else the normal 4-bit index (entries 0-15).
rtl/avg/avg_majorhavoc.vhd:433 (Behavioural twinkle: this colours the whole vector from the sparkle palette rather than MAME's sparse half-step dots -- a first cut; not visually validated since the attract frame has no sparkle STAT.
rtl/majorhavoc.vhd:19 VALIDATE IN SIM: the comms handshake-flag bit positions/polarity in IN0/IN1 are best-effort from the handoff; confirm against MAME INPUT_PORTS(mhavoc) + the jessaskey self-test (mhavocpe-ref/Source/mh_alpha.asm) before trusting them.
rtl/majorhavoc.vhd:141 Entries 0-15 = normal colours (4-bit STAT colour); 16-31 = the sparkle palette (MAME reads colorram[0xf + bitswap(spkl)]).
rtl/majorhavoc.vhd:147 ---- IRQ: 5 kHz LS161 dividers (MHAVOC_CLOCK_5K = 10 MHz/2048 = 4882.8 Hz), per mhavoc.cpp ----
rtl/majorhavoc.vhd:210 ROMs (loaded from download; see entity header for the concatenation) alpha 64K : dn 0x00000-0x0FFFF (= MAME alpha region $8000-$17FFF) gamma 16K : dn 0x10000-0x13FFF vectorrom 8K: dn 0x14000-0x15FFF
rtl/majorhavoc.vhd:236 MAME alpha_map: map(0x0000,0x01ff).ram().
rtl/majorhavoc.vhd:237 RAM A and RAM B MUST be separate (they are two distinct .ram() shares in MAME); the old single-1K-aram decode aliased $00A5<->$08A5<->$04A5, so a RAM-B write to $08A5 wiped $A5's D3 bit and the IRQ handler's player-mux write ($87C9 STA $160
rtl/majorhavoc.vhd:246 MAME alpha_map: map(0x0800,0x09ff).ram().
rtl/majorhavoc.vhd:251 MAME: map(0x0200,0x07ff)+map(0x0a00,0x0fff) both .bankrw(rambank); rambank entry = rampg (0/1).
rtl/majorhavoc.vhd:277 ALPHA address decode + read mux (MAME alpha_map)
rtl/majorhavoc.vhd:279 MAME alpha_map RAM regions (exact): $0000-01FF RAM A, $0200-07FF bank, $0800-09FF RAM B, $0A00-0FFF bank.
rtl/majorhavoc.vhd:298 $1200 IN0 -- CANONICAL mhavoc.cpp INPUT_PORTS(mhavoc), verified vs mamedev master: b0=avg done(=avg_halted), b1=2.4kHz(=clk24), b2=gamma_xmtd, b3=gamma_rcvd, b4=diag-step(SVC2,act-low), b5=service1(act-low), b7:6=coin/service mux.
rtl/majorhavoc.vhd:337 GAMMA address decode + read mux (MAME gamma_map)
rtl/majorhavoc.vhd:344 Quad POKEY decode (MAME mhavoc quad_pokeyn): select = g_ad(4:3); register = {g_ad(5), g_ad(2:0)} (the PCB's quirky address-line wiring -> ALLPOT for DSW1 lands at +$20).
rtl/majorhavoc.vhd:357 $2800 IN1 -- CANONICAL mhavoc.cpp: b0=alpha_xmtd, b1=alpha_rcvd (both active-high, direct); b2=TIRDY (unused on base mhavoc -- no TMS5200); b3=unused; b7:4=fire/shield buttons (P1 b7:6, P2 b5:4).
rtl/majorhavoc.vhd:369 Inter-CPU comms latches + handshake (MAME gamma_w/alpha_w/alpha_r/gamma_r)
rtl/majorhavoc.vhd:377 alpha resets gamma ($1600 D3=0) -> clear all 4 handshake flags (MAME out_0_w)
rtl/majorhavoc.vhd:405 IRQ: faithful port of mhavoc.cpp cpu_irq_clock + the two irq_ack handlers.
README.md:18 `games/mame/` folder.
README.md:185 **T65 / POKEY** authors and the broader MiSTer/MAME communities — the Atari vector hardware lineage and reference models.
README.md:187 **MAME** — the authoritative Major Havoc memory map and hardware behavior.

Says it matches, follows or was checked against MAME — 1

rtl/avg/avg_majorhavoc.vhd:7 IMPORTANT: the AVG's INTERNAL pc space is NOT the same as the alpha CPU's view (MAME set_memory(alpha, AS_PROGRAM, $4000) + the mhavoc_data() override).

Says it was translated, ported or taken from MAME — 2

rtl/majorhavoc.vhd:6 Implements, from MAME src/mame/atari/mhavoc.cpp (verbatim maps, 2026-05-29 fetch): * ALPHA 6502 @ 2.5 MHz (10/4) + GAMMA 6502 @ 1.25 MHz (10/8), separate buses.
README.md:38 **New — the Major Havoc game module** (`rtl/majorhavoc.vhd`, `rtl/avg/avg_majorhavoc.vhd`, `rtl/mhavoc_sw.sv`), transcribed from MAME's `atari/mhavoc.cpp`:

Arcade-NixPirates (ppriest)#
Genix Family, Pirates
ppriest/Arcade-NixPirates_MiSTer @ 0b8847ce
MAME compared: nix/pirates.cpp
Read: 14 HDL files, 2,751 lines (Quartus project)

ppriest
repository only

Mostly MAME

low

53%

Statements: 25 toward MAME

Cites MAME source — 24

NixPirates.sv:4 NIX's Pirates / Genix Family board (MAME src/mame/nix/pirates.cpp): sets in scripts/build_mra.py SETS.
NixPirates.sv:43 Orientation: Auto follows the set, and every set is horizontal (pirates.cpp GAME lines, ROT0)
NixPirates.sv:209 MAME's INPUTS (pirates.cpp 365-381), a byte per player, active low: up, down, left, right, buttons 1-3, start.
NixPirates.sv:224 SYSTEM (383-400): 0 COIN1, 1 COIN2, 2 SERVICE1, 3 service mode (momentary, as MAME's PORT_SERVICE_NO_TOGGLE), active low; 4 the EEPROM's DO; 5, 6 unknown, read 0; 7 the protection bit, which MAME's prot_r reads as 1; 8-15 unknown, read 0.
NixPirates.sv:245 out_w (pirates.cpp 289-301): 0 EEPROM CS, 1 CLK, 2 DI, 6 OKI bank, 7 unknown
NixPirates.sv:272 After a write the 93C46 is busy, DO low, for MAME's write time (eeprom.cpp 42, 1750 us).
NixPirates.sv:403 mono (pirates.cpp 460), the same on both channels; the menu reads Mono, None, 25%, 50%
rtl/mame_keys.sv:1 MAME's default keys (src/emu/inpttype.ipp) in hps_io's joystick layout, to OR into joystick_0/1: right, left, down, up at bits 0-3, buttons 1-6 at 4-9, Start, Coin, Pause, Service at the J1 line's own positions (parameters).
rtl/mame_keys.sv:7 P1 arrows, LCtrl LAlt Space LShift Z X, 1 start, 5 coin P2 R F D G, A S Q W E (MAME gives P2 no sixth key), 2 start, 6 coin F2 service (test) switch, 9 and 0 service coins 1 and 2, P pause
rtl/mame_keys.sv:24 MAME's Service 1, 2: wire to the board's SERVICE1/2 bits, if any
rtl/np_dpram.sv:61 zero in simulation, as MAME's RAM; on the board M10K comes up zero from configuration (and Quartus refuses an initial loop past 5000 iterations)
rtl/np_main.sv:8 Unmapped reads return 0 and unmapped writes are dropped, as MAME's. The second ports only read (np_dpram); other writers go through the CPU's port while it is paused.
rtl/np_main.sv:12 I/O read data comes from the parent (inputs, SYSTEM with the EEPROM's DO and the protection bit, the M6295's status), so a bench can replay MAME's.
rtl/np_main.sv:15 MAME's protection kludges, by the mod byte (rtl/np_rom_map.svh): pirates/piratesb program word 0x62c0 reads 0x6006 (init_pirates, 618) genix reads of 0x109e98/0x109e9a return 0x0004/0x0000; writes still reach work RAM (init_gen
rtl/np_main.sv:107 bus_cs is every access, not only the ROM's: a write's strobes come out at S4, and DTACK, registered from them, would miss that phase's sample and cost a wait state the board does not have (sim/boot_tb: 22% of cycles at 7 phases, +4% clocks
rtl/np_main.sv:176 MAME's split into the three layers is the video's business (352-356).
rtl/np_sound.sv:3 The OKI M6295 (pirates.cpp 460): 24 MHz / 18 = 1.3333 MHz, pin 7 low, samples on SDRAM bank 3.
rtl/np_video.sv:4 The video of src/mame/nix/pirates.cpp (186-285, 405-456), per scanline.
rtl/np_video.sv:7 Visible 288 x 224, MAME's lines 16-239; IRQ1 at line 240.
rtl/np_video.sv:9 tiles bg, fg, tx: jtframe_scroll each, 8x8 4bpp, column-major maps of code and colour words in one tile RAM at MAME's bases (352-356).
rtl/np_video.sv:85 MAME's vblank start (wtiming: line 240)
rtl/np_video.sv:101 Flip: the board has none (MAME), so it is the finished picture turned round.
README.md:3 A MiSTer FPGA core for NIX's Pirates hardware (MAME's `nix/pirates.cpp`), built with Quartus Prime 17.0.2 Lite for the DE10-nano.
README.md:56 David Haywood, Nicola Salmoria and Paul Priest, and the MAMEdev team, for `pirates.cpp`.

Says it was translated, ported or taken from MAME — 1

rtl/np_main.sv:4 The 68000 and its memory map, from MAME src/mame/nix/pirates.cpp prg_map() (340-359).

Arcade-PenguinKunWars (MrX-8B)#
Penguin-Kun Wars
MrX-8B/MiSTer-Arcade-PenguinKunWars @ 8d83776f
MAME compared: upl/nova2001.cpp + 2 related file(s)
Read: 12 HDL files, 2,178 lines (Quartus project)

MrX-8B
repository only

Not enough evidence in the code

insufficient

42%

Statements: 2 toward MAME

Cites MAME source — 2

Arcade-PenguinKunWars.sv:196 JPAC/IPAC/MAME Style Codes
rtl/YM2149_linmix_sep_mod.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA

Arcade-RoundUp (harlock74)#
T.T Fitter
harlock74/Arcade-RoundUp_MiSTer @ a00aba87
MAME compared: taito/roundup.cpp
Read: 33 HDL files, 2,717 lines (Quartus project)

harlock74
repository only

Mostly MAME

low

10%

Statements: 1 toward hardware, 9 toward MAME

Says it was checked on “real hardware” — 1

README.md:66 High-score saving and replacement have been successfully tested on hardware.

Cites MAME source — 6

rtl/roundup_controls.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Round-Up's independent menu encoding and MAME-functional Q2 coin lockout.
rtl/roundup_controls.sv:13 MAME Q2 callback sends !Q2 to coin_lockout_w: Q2=0 locks coin 1.
rtl/thepit_background.sv:1 SPDX-License-Identifier: GPL-3.0-or-later MAME-functional tile/sprite composition.
rtl/thepit_background.sv:54 Pinned MAME order, top first: high sprite, front solid, low sprite, transparent foreground, rear solid.
rtl/thepit_mainbus.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Stage D MAME-functional CPU bus.
rtl/thepit_mainbus.sv:111 functional MAME default, not physical open bus

Says it matches, follows or was checked against MAME — 1

rtl/thepit_mainbus.sv:48 Configuration-time RAM contents match MAME's cold zero allocation.

Says it was translated, ported or taken from MAME — 1

README.md:7 Current status: functional behavioural implementation, mainly based on MAME/reference behaviour and available arcade hardware documentation.

Keeps a MAME approximation — 1

rtl/thepit_background.sv:95 MAME-COMPATIBILITY-APPROXIMATION: these eight digital primary colours are generated separately.

Arcade-SegaSpaceHarrier (rossops)#
Enduro Racer, Hang-On, Space Harrier
rossops/Arcade-SegaSpaceHarrier_MiSTer @ 049ee211
MAME compared: sega/segahang.cpp + 13 related file(s)
Read: 37 HDL files, 10,320 lines (Quartus project)

rossops
repository only

Mostly MAME

medium

28%

Statements: 6 toward hardware, 106 toward MAME, 1 not counted

Cites hardware documentation that MAME's driver does not — 5

rtl/audio/sh_soundsys.sv:85 The vendored T80 (as the GHDL-converted netlist verif/board/t80/T80s_ghdl.v), kept for the bench's cross-check only (make ...
rtl/io/sh_adc0804.sv:2 ADC0804 with the analog input multiplexer (74HC4052 on this board) A write starts a conversion (ignored while one is running); 74 ADC clocks later (ADC clock = 25.1748 MHz/4/6 = 1.049 MHz -> 70.5 us) the result is latched and /INTR asserts.
rtl/sh_core.sv:528 ---- ADC0804 (E03021, odd byte): one converter behind the 74HC4052 mux selected by PPI1 port A bits 3:2
rtl/sh_core.sv:778 road: ROM in BRAM from the loader, the netlist renderer on road RAM's second port
rtl/video/sh_road.sv:55 netlist state

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/video/sh_road.sv:2 segaic16 road generator, HANGON/SHARRIER variant — a port of MAME's netlist emulation (segaic16_road.cpp segaic16_road_hangon_draw: the counters at 9M and 9N/9P, the two 9J flip-flops, the 8S serial shift register). — also in MAME: 9M sega/segaic16_road.cpp:111, 9N sega/segaic16_road.cpp:114, 9P sega/segaic16_road.cpp:114, 9J sega/segaic16_road.cpp:117, 8S sega/segaic16_road.cpp:123

Notes where it differs from MAME — 1

README.md:191 The re-entry count differs from MAME's because our bus cycles carry DTACK latency MAME doesn't model — same shape the Y Board saw.

Cites MAME source — 93

rtl/audio/sh_segapcm_5218.sv:2 Sega 315-5218 PCM (SegaPCM), MAME segapcm.cpp.
rtl/audio/sh_segapcm_5218.sv:11 The sums are in MAME's 1/32768 units, i.e. directly 16-bit samples.
rtl/audio/sh_segapcm_5218.sv:13 ROM bytes come from SDRAM port p6 (16-bit words, byte selected by A0); the stream pads the PCM slot with 0xFF like MAME's ERASEFF region.
rtl/audio/sh_segapcm_5218.sv:20 MAME m_bankshift (BANK_512: every segahang set)
rtl/audio/sh_segapcm_5218.sv:27 channel slots 8-15, no banking (MAME 0.289)
rtl/audio/sh_segapcm_5218.sv:48 MAME m_low: addr[7:0] per channel
rtl/audio/sh_segapcm_5218.sv:71 MAME runs the stream up to every register write before applying it, so a driver restarting a playing voice always ends with its new address in 0x84/0x85.
rtl/audio/sh_segapcm_5218.sv:78 So: a Z80 write to 0x84/0x85/0x86 of the channel in flight marks that byte dirty and the engine skips its own write to it; the sample already accumulated from the old address stands, as MAME's does.
rtl/audio/sh_segapcm_5218.sv:117 the page after end, as MAME through 0.288: 0.289's rewrite compares
rtl/audio/sh_soundsys.sv:19 Mix, from MAME's segahang routes: the 2203 board (ymfm rotation understood: outputs 0-2 = SSG A/B/C, 3 = FM) SSG 0.05 each, FM 0.15, PCM 0.40; the 2151 board YM 0.30, PCM 0.70.
rtl/audio/sh_soundsys.sv:188 The sim zero-fills it: the game tests bytes it never wrote (C01F gates the whole song-activation path), MAME zero- fills its RAM regions, and the FPGA M10K powers up zero; only the simulator's x-assign disagreed, which cost a day of sound d
rtl/audio/sh_soundsys.sv:210 MAME 0.289's discrete-board model is not used: the M7
rtl/audio/sh_soundsys.sv:268 ---- mix (MAME's routes): PCM 0.40, FM 0.15, SSG channels 0.05 each, the 8-bit SSG channels scaled by 128 toward 16 bits
rtl/cpu/sh_fd1089b.sv:2 FD1089B decrypt (Enduro Racer's main CPU, key 317-0013A), the static per-address table from MAME's fd1089.cpp (Salmoria, Naive, MacDonald).
rtl/cpu/sh_fd1089b.sv:11 Opcode = a program-space fetch (FC 2 or 6), MAME's AS_OPCODES: the 68000's instruction and extension words alike.
rtl/cpu/sh_m68k_bus.sv:8 Bus contract towards the board: bus_valid high from the clk after ASn falls until ASn rises bus_start one-clk pulse on the first bus_valid clk (decoders sample) bus_rd/wr read or write cycle; bus_be = {UDS, LDS} bus_ack board asse
rtl/cpu/sh_mcu.sv:17 The program drives level 4 once per vblank and nothing else; the level is latched here and cleared by the 68000's interrupt acknowledge, not by the MCU releasing it (MAME: HOLD_LINE).
rtl/io/sh_adc0804.sv:6 Channel select = the sub PPI port A bits 3:2 (MAME segahang.cpp).
rtl/io/sh_adc0804.sv:7 Reference MAME adc0804.cpp + segaxbd.cpp analog_r.
rtl/io/sh_adc0804.sv:52 sampled at end of conversion (MAME)
rtl/io/sh_i8255.sv:2 i8255 PPI (MAME i8255.cpp is the behavioural reference).
rtl/io/sh_i8255.sv:51 Mode-2 status: PC5 = IBF (always 0 here: the input half has no writer — the Z80 side has no path to strobe data in, in MAME or on this board), PC4 = INTE2 (its BSR flip-flop).
rtl/io/sh_i8255.sv:94 mode set: group A mode from bits 6:5, direction bits 4 (A), 3 (C upper), 1 (B), 0 (C lower); output latches clear (MAME does the same)
rtl/sh_core.sv:2 Sega Space Harrier / Hang-On — board top M1: the two 68000s (fx68k) with ROM caches on the hangon memory map, every CPU-visible RAM, the shared sub/road RAM behind a hold-through-RMW arbiter (with a third requester slot reserved for the i87
rtl/sh_core.sv:92 The M11 option raises it for Enduro Racer only: the game is vblank-synced but CPU-bound, and drops frames under load that MAME's zero-wait 68000 does not; 32540 / 39048 / 52064 give 12.5 / 15 / 20 MHz for both 68000s, everything else at the
rtl/sh_core.sv:177 ---------------------------------------------------------------- interrupts Main: IRQ4 raised entering vblank (line 224) and held until the CPU's interrupt acknowledge (MAME irq4_line_hold).
rtl/sh_core.sv:180 Sub: level 4 is a plain level from PPI1 port A bit 6, active low, no acknowledge (MAME sub_control_adc_w).
rtl/sh_core.sv:185 held until the 68000 acknowledges that level (MAME HOLD_LINE)
rtl/sh_core.sv:186 MAME: every P1 write with a level is set_input_line(level, HOLD_LINE): the line stands until the 68000 takes it and is then dropped, whatever the MCU's pin does.
rtl/sh_core.sv:253 MAME suppresses the same write for the same reason.
rtl/sh_core.sv:302 main decode: the hangon map (MAME hangon_map) or, by the descriptor, the sharrier map (sharrier_map: Space Harrier and Enduro Racer).
rtl/sh_core.sv:330 ---- main ROM cache (256 KB, plus the bootleg sets' decrypted-opcode image as a second 256 KB behind address bit 19: MAME's AS_OPCODES for endurobl/endurob2, whose program-space fetches read the mainops slot)
rtl/sh_core.sv:360 fd1089.cpp decrypt_one
rtl/sh_core.sv:509 enduror (MAME `enduror` port): start is bit 6, bits 7, 5 and 4 unused; its list is J1: 4 Gas, 5 Brake, 6 Start, 7 Wheelie, 8 Coin, 9 Pause, 10 Test, 11 Service (the pedals and coin group as on Hang-On and Space Harrier, so the core's gas/br
rtl/sh_core.sv:609 enduror's bank channel (MAME ADC2: 0x00-0xFF, rest 0x20, no reverse): MAME scales a stick's two halves separately, so pulling back runs 0x20 up to 0xFF and pushing forward 0x20 down to 0x00; the Wheelie button (J1 bit 7) is a full pull
rtl/sh_core.sv:639 sub decode: 19-bit space (MAME global_mask 0x7ffff)
rtl/sh_core.sv:663 One access per clock in priority order; a CPU that has read keeps the space until its next bus cycle starts, an RMW write is served first and an instruction fetch releases the hold, so tas and the two-cycle bclr/bset/addq on memory are atom
rtl/sh_core.sv:719 ================================================================ read muxes Writes into ROM space (main program ROM and the sub-ROM window) are acknowledged and dropped: real DTACK logic ignores R/W, MAME drops them silently, and a decode t
rtl/sh_core.sv:821 A sprite pixel with colour bits all ones is the shadow pen: the underlying pixel moves to the shadow or hilight palette bank, picked by the PPI's SHADE0 bit (MAME video_lamps_w: ~portB & 0x40 truthy selects hilight).
rtl/sh_pkg.sv:21 ---- video timing: 400 x 262 at clk_sys/8 = 6.2937 MHz, 320 x 224 ----- MAME 0.289 set_raw(25.1748 MHz/4, 400, 0, 320, 262, 0, 224) — measured, unlike the Y Board's set_size placeholder.
rtl/video/sh_palette_5242.sv:4 Palette word: bit 15 = effects select (1 hilight / 0 shadow), 14:12 = LSB of B/G/R, 11:8 B, 7:4 G, 3:0 R (MAME paletteram_w).
rtl/video/sh_road.sv:5 Renders the next scanline from live road RAM into a double-buffered line buffer at two clocks per pixel (state step + ROM fetch), 24 warm-up pixels before x 0 as in MAME's loop from -24.
rtl/video/sh_road.sv:13 Colour bases (segahang_v.cpp): road pixels 0x038, background 0x7C0.
rtl/video/sh_road.sv:57 MAME keeps an int; 9 bits covers its range
rtl/video/sh_road.sv:68 MAME's loop-top order: the 0xFF clear first, then the control-bit-8 set, so the set wins when both apply
rtl/video/sh_sprite.sv:2 SEGA_HANGON_SPRITES and, with `sharrier`, SEGA_SHARRIER_SPRITES (sega16sp.cpp) as a line renderer.
rtl/video/sh_sprite.sv:7 MAME draws whole sprites from live RAM with a per-sprite row-base accumulator (`addr`, advanced by pitch, doubled on zoom-ROM row skips) and a scratch fetch pointer (data[7]); the real chip is line-based.
rtl/video/sh_sprite.sv:10 This renderer takes a private copy of sprite RAM once per frame (at line 260, after the game's vblank writes) with word 7 initialised to word 3, then per line walks the list: an entry spanning the line advances its word-7 row base exactly a
rtl/video/sh_sprite.sv:18 ROM words come from SDRAM port p2 in 128-bit bursts, cached one burst at a time; the row's fetch direction is bit 15 of the row base at row start (the address-overflow-into-flip interaction rides on the 16-bit add and the 15-bit fetch mask,
rtl/video/sh_sprite.sv:21 Pen 0 and 15 transparent, pen 15 in a word's last position ends the row; the row also ends at the word boundary after x passes the right edge (MAME's group re-entry check).
rtl/video/sh_sprite.sv:165 Word 7 of each entry is initialised to its word 3 (MAME's data[7] = addr).
rtl/video/sh_sprite.sv:251 MAME's group re-entry check
rtl/video/sh_tilemap_5012.sv:2 Sega 315-5011/5012 tilemap generator, "TILEMAP_HANGON" register layout (MAME segaic16.cpp tilemap_16a_*, the 4-page 16A variant).
rtl/video/sh_tilemap_5012.sv:68 0 fg, 1 bg (MAME's 'which')
rtl/video/sh_tilerom.sv:6 Plane 2 (third ROM, epr-6843) is pen bit 2 (MAME gfx_8x8x3_planar: RGN_FRAC(2,3) is the MSB plane).
rtl/video/sh_video_timing.sv:4 MAME 0.289: m_screen->set_raw(25.1748 MHz/4, 400, 0, 320, 262, 0, 224).
rtl/video/sh_video_timing.sv:5 vbl_irq is a 1-line level during VBLANK_LINE (224, the first vblank line, where MAME fires IRQ4); latch_pulse at line 261 frames the bench (the HANGON tilemap has no register latch of its own).
rtl/video/sh_video_timing.sv:38 Sync widths follow the System 16-family convention used by MAME's screen layout: hsync from 336..367 (32 px), vsync lines 240..243 (4 lines).
README.md:28 | M1 | Two 68000s, shared RAM, PPIs, ADC, interrupts track MAME | done (2026-08-31) |
README.md:31 | M4 | Hang-On sprites and mixer: full frames vs MAME | done (2026-08-31) |
README.md:32 | M5 | YM2203 + PCM sound vs MAME recordings | done (2026-08-31) |
README.md:35 | M7b | Space Harrier gamepad feel (optional): MAME-style stick slew | not started |
README.md:37 | M11 | Enduro Racer 60 fps mode (optional): an OSD CPU speed for both 68000s | measured 2026-09-07: not a CPU limit; a 20 MHz 68000 trims a quarter second of r
README.md:43 Core vs MAME
README.md:45 MAME 0.289 is this core's behavioural reference: every renderer has a Python golden model ported line for line from it, and the gates compare frames and traces
README.md:47 But MAME is an emulator with its own conveniences, and a cycle-concurrent board sometimes has to model what MAME can skip.
README.md:57 Video timing is MAME's measured `set_raw`: 400x262 at 25.1748 MHz/4, 320x224 visible.
README.md:60 All four video layers (tilemaps, text, road, sprites), the mixer's priority rules and the three-bank shadow/hilight palette reproduce MAME's screenshots pixel f
README.md:63 The main CPU's vblank interrupt is held until acknowledge, exactly MAME's `irq4_line_hold`.
README.md:65 Analog reversal follows MAME's PORT_REVERSE arithmetic: `0x100 - value` on every reversed channel (the carried module said `255 - value`, one count off centre;
README.md:68 The 315-5218 PCM ticks at clock/128 per MAME.
README.md:76 MAME never needs this because its instructions are atomic; the real bus has the race, and the Y Board's Power Drift deadlocked twice to prove it.
README.md:79 MAME drops them silently; a decode that only acks reads stalls a real 68000 until the watchdog.
README.md:82 The renderers work the way the chips do, not the way MAME draws: the sprite generator is line-based with a private copy of the list (the chip's word-7 scratch w
README.md:86 MAME draws whole frames at frame end from end-of-frame state.
README.md:94 The one level the MCU drives, IRQ 4 once per vblank, is armed when the MCU asserts it and dropped at the 68000's acknowledge, MAME's HOLD_LINE exactly.
README.md:100 The PCM engine keeps the loop rule MAME used through 0.288 (a voice wraps or stops when its page passes the end register) and the 16-voice 315-5218 with banking
README.md:102 MAME 0.289 rewrote the device: the end check lost its plus one, and the YM2203 board became an 8-voice discrete model without banking.
README.md:109 So the older MAME wins on hardware evidence, and the M8 audio gate records its reference with a MAME 0.289 built with that rule restored (tools/mame_ref_build.s
README.md:114 The game is vblank-synced but CPU-bound: MAME's zero-wait 68000 drops a fifth of the frames in the busy first seconds of a race, and ours, behind an SDRAM cache
README.md:128 Space Harrier's attract demo drifts against MAME by one frame per 450 or so, with the scene otherwise identical: the MCU's 71 bus accesses a frame halt the 6800
README.md:146 MAME re-synchronises its scheduler on every access to the main PPI (`sync_ppi_w`) to keep the sound handshake ordered.
README.md:151 The simulation-only tv80 it replaces turned out to be the less faithful core; the attract audio's envelope correlation with MAME rose from 0.94 to 0.97 the day
README.md:164 The main PPI runs in i8255 mode 2, not the mode-1-style handshake MAME's driver comments suggest — the game programs control word 0xC0 and uses the bidirectiona
README.md:166 Two of our bugs came from assuming mode 2 was absent; MAME's i8255 device had it right all along.
README.md:171 The YM2203 timer flags cleared wrong twice in our vendored jt12, and MAME's ymfm was the faithful one both times.
README.md:194 Uninitialised RAM: MAME zero-fills its RAM regions and the FPGA's M10K blocks power up cleared, and Hang-On's sound driver counts on it — it reads a byte it nev
README.md:201 Instrumented MAME is not MAME.
README.md:201 The Lua read/write taps we used to trace the YM2203 flipped MAME's own sound driver onto the wrong side of an internal channel race, and the trace then "confirm
README.md:204 A single minimal tap reproduced MAME's real output exactly.
README.md:208 The PCM chip's register file has a real race MAME hides.
README.md:216 The engine now yields to the Z80's write, which is what MAME's ordering amounts to (M6 findings).
README.md:233 MAME lands on the side where the coin sound is rejected and the theme ends on schedule; our cycle-timed board (and MAME itself, once taps perturb its scheduler)

Says it matches, follows or was checked against MAME — 7

rtl/io/sh_i8255.sv:15 Reset (and any control-word write): all ports mode 0 inputs, latches 0, which matches MAME driving its output callbacks with the tri value (0) until the game programs the chip.
README.md:9 Hang-On's video is complete — full frames match MAME's screenshots on every pixel, confirmed on a DE10-Nano — and the sound board plays: the attract sequence's
README.md:49 This section is the running scorecard — where we match MAME exactly, where we deliberately go past it toward the real hardware, and where chasing a bug taught u
README.md:55 Matching MAME exactly
README.md:120 Off matches MAME's mapping; On is a player preference layered on top.
README.md:125 Checked word for word against MAME's decrypted sets: the only differences are two words at 0xFF0 the decrypted bootlegs patch themselves.
README.md:198 Every game-visible RAM now zero-inits in simulation to match both MAME and the silicon.

Says it was translated, ported or taken from MAME — 2

rtl/video/sh_road.sv:2 segaic16 road generator, HANGON/SHARRIER variant — a port of MAME's netlist emulation (segaic16_road.cpp segaic16_road_hangon_draw: the counters at 9M and 9N/9P, the two 9J flip-flops, the 8S serial shift register).
README.md:4 Same approach as the X Board and Y Board cores it descends from: simulate the board, verify every custom chip against a Python port of MAME, then check whole fr

Keeps a MAME approximation — 2

README.md:58 Unusually for this board family, MAME's numbers here are real measurements, not placeholders.
README.md:133 MAME suppresses the MCU's write to 040385 as a sync hack, and after the first hardware test we do the same, now knowing why.

Shares text with the MAME driver without saying so — 2

rtl/sh_pkg.sv:22 MAME 0.289 set_raw(25.1748 MHz/4, 400, 0, 320, 262, 0, 224) — measured, — shares text with sega/segahang.cpp:1024
rtl/video/sh_video_timing.sv:4 MAME 0.289: m_screen->set_raw(25.1748 MHz/4, 400, 0, 320, 262, 0, 224). — shares text with sega/segahang.cpp:1024

Arcade-Seta (ppriest)#
Athena no Hatena?, Blandia, Block Carnival / Thunder & Lightning 2, Daioh …
ppriest/Arcade-Seta_MiSTer @ 1bcfc9e3
MAME compared: seta/seta.cpp + 2 related file(s)
Read: 32 HDL files, 8,122 lines (Quartus project)

ppriest
repository only

Mostly MAME

medium

77%

Statements: 5 toward hardware, 107 toward MAME

Says it was checked against the original PCB — 2

README.md:189 The one marked "verified on PCB" in `seta.cpp` is Daioh's 57.42 Hz; the 60 Hz sets carry no comment.
README.md:191 Confirmed on a PCB: Guru's measurement of Caliber 50 (`downtown.cpp`, same X1-001 / X1-007 / X1-012 chipset, Seta_Downtown core) is **HSync 15.6250 kHz, VSync 5

Reports a measurement taken on the original PCB — 2

rtl/seta_board_cfg.sv:163 Timing: 8 MHz dot clock, htotal 512, vtotal 272 = 57.44 Hz, matching daioh's rate, the only one seta.cpp marks as measured on a PCB (the 60 Hz sets carry no comment).
README.md:191 Confirmed on a PCB: Guru's measurement of Caliber 50 (`downtown.cpp`, same X1-001 / X1-007 / X1-012 chipset, Seta_Downtown core) is **HSync 15.6250 kHz, VSync 5

Notes where it differs from MAME — 1

README.md:424 See `docs/MAME_DIVERGENCE.md` for cases that are considered 'hacks' from MAME, and also any cases where we diverge from MAME.

Cites MAME source — 101

Seta.sv:3 Seta X1-010 hardware for MiSTer -- seta/seta.cpp, Group A.
Seta.sv:360 downtown.cpp: input_layout 0 is common_type1 (LRUD at 0-3, as seta_port's JOY2), 1 is common_type2 (UDLR at 0-3).
Seta.sv:368 downtown.cpp's coins are PORT_IMPULSE(5): a press is five frames of coin, however long the button is held (a held coin miscounted on DownTown and Twin Eagle).
rtl/cpu/adc0834.sv:1 ADC0834 serial ADC behind Zombie Raid's guns: MAME's adc083x.cpp state machine for the 0834.
rtl/cpu/adc0834.sv:3 Within a write the /CS step is applied before the clock step, as MAME's gun_w orders them.
rtl/cpu/maincpu.sv:36 gun ADC at 0xf00000 downtown.cpp downtown_map (downtown, twineagl, metafox, arbalest); its sub CPU, tile bank and control registers are decoded in seta_core
rtl/cpu/maincpu.sv:40 downtown.cpp calibr50_map: X1-010 on the 65C02, battery RAM, uPD4701
rtl/cpu/maincpu.sv:42 downtown.cpp tndrcade_map: no tile layer, sound on the 65C02
rtl/cpu/maincpu.sv:72 Undriven reads are zero, as MAME's unmapped reads.
rtl/cpu/maincpu.sv:122 RAM above the palette, where MAME maps one
rtl/cpu/maincpu.sv:480 downtown.cpp downtown_map
rtl/cpu/maincpu.sv:498 downtown.cpp calibr50_map
rtl/cpu/maincpu.sv:517 downtown.cpp tndrcade_map
rtl/cpu/seta_irq.sv:5 seta.cpp's ipl0/1/2_ack_w clear levels 1/2/4.
rtl/cpu/seta_pit.sv:1 uPD71054C (8254) PIT, channel 0 only: seta.cpp clocks channel 0 at 1 MHz and wires OUT0's rising edge to IPL 4 (pit_out0); channels 1 and 2 are unconnected.
rtl/memory/gfx_swizzle.sv:1 MAME's gfx1 (RGN_FRAC(1,2) 4bpp) keeps a tile row's four 16-bit words in four places; permuted, a row is one 64-bit SDRAM granule addressed by {tile, yh, yl}.
rtl/memory/seta_sdram_top.sv:1 SDRAM: every ROM the core reads at runtime, on one chip through sdram.sv's three fixed-priority ports (port 0 preempts 1, 1 preempts 2): port 0 sprite and tile graphics (arbiter, 3 clients) port 1 X1-010 samples (byte bridge
rtl/memory/seta_sdram_top.sv:8 Address map, per layout (bases below; scripts/build_mra.py reads the localparams, so every .mra loads to these offsets): A maincpu 0, gfx1 1M (2 MB), x1snd 3M B maincpu 0, gfx1 1M (1 MB), gfx2 2M, x1snd 4M C maincpu 0, gfx1 2M (4 MB), gf
rtl/memory/seta_sdram_top.sv:89 downtown.cpp "sub" region, byte address (SUB)
rtl/memory/seta_sdram_top.sv:138 LAYOUT_G: downtown.cpp
rtl/seta_board_cfg.sv:1 Values come from each set's machine_config and memory map in seta.cpp: CPU clock (cpu_div), gfx1 size (gfx_half_words = bytes / 4, code_mask), PALETTE entries, GFXDECODE bases, interrupt sources and acknowledges, set_*offsets (flip, noflip)
rtl/seta_board_cfg.sv:100 VIDEO_UPDATE_AFTER_VBLANK (blandia, blandiap): MAME copies, then draws
rtl/seta_board_cfg.sv:102 snapshot on this line instead of at vblank (0 = the board's usual point): for a game that writes its list all frame, a line where it does not (docs/MAME_DIVERGENCE.md, "When the games write, in MAME")
rtl/seta_board_cfg.sv:144 Flipped foreground y is -0x0a on the 240-line sets: with MAME's -0x12 a flipped frame is the rotated unflipped one moved 8 lines.
rtl/seta_board_cfg.sv:150 madshark: flip value makes a flipped frame the unflipped one rotated 180 (MAME: 0)
rtl/seta_board_cfg.sv:163 Timing: 8 MHz dot clock, htotal 512, vtotal 272 = 57.44 Hz, matching daioh's rate, the only one seta.cpp marks as measured on a PCB (the 60 Hz sets carry no comment).
rtl/seta_board_cfg.sv:286 flip value makes a flipped frame the unflipped one rotated 180 (MAME: 2)
rtl/seta_board_cfg.sv:327 flip value makes a flipped frame the unflipped one rotated 180 (MAME: 0)
rtl/seta_board_cfg.sv:345 flip value makes a flipped frame the unflipped one rotated 180 (MAME: 0)
rtl/seta_board_cfg.sv:403 flip value makes a flipped frame the unflipped one rotated 180 (MAME: 0)
rtl/seta_board_cfg.sv:410 two buttons: MAME's BUTTON3 is read nowhere
rtl/seta_board_cfg.sv:456 no set_xoffsets; flip value makes a flipped frame the unflipped one rotated 180 (MAME: 0)
rtl/seta_board_cfg.sv:464 flip value makes a flipped frame the unflipped one rotated 180 (MAME: 0)
rtl/seta_board_cfg.sv:531 flip value makes a flipped frame the unflipped one rotated 180 (MAME: 0)
rtl/seta_board_cfg.sv:568 flip -4 rotates frame 2000 exactly; the game's flipped scroll writes are not consistent across frames (MAME: 0)
rtl/seta_board_cfg.sv:627 flip value makes a flipped frame the unflipped one rotated 180 (MAME: 0)
rtl/seta_core.sv:62 downtown.cpp: DownTown's rotary joysticks, positions 0..11
rtl/seta_core.sv:181 downtown.cpp's tile bank, declared before seta_video uses it (ModelSim)
rtl/seta_core.sv:511 not on the downtown.cpp boards (calibr50's battery RAM is in the downtown.cpp block)
rtl/seta_core.sv:658 ---- downtown.cpp: the 65C02 system and the board's own registers ---- map_board: 18 downtown_map, 19 calibr50_map, 20 tndrcade_map
rtl/seta_core.sv:795 tndrcade: YM2203 (DSW 1 on port A, DSW 2 on port B: dsw1_r / dsw2_r) and YM3812, both 16 MHz / 4; mixed 0.35 and 0.5 as MAME routes them
rtl/seta_prot_pairlove.sv:1 pairlove's 0x900000 block (seta.cpp prot_r/prot_w): a write saves the cell's value and stores the new one; a read returns the value and then reverts the cell to the saved one.
rtl/seta_prot_thunderl.sv:3 Transcribed bit for bit from seta.cpp.
rtl/video/seta_palette.sv:1 X1-006 palette RAM: xRRRRRGGGGGBBBBB words, looked up per pixel, expanded with MAME's pal5bit, (v << 3) | (v >> 2).
rtl/video/seta_video.sv:31 setac_eof, and whether MAME draws after it (x1_001.sv)
rtl/video/seta_video.sv:147 every line start, with the line starting (MAME's numbering)
rtl/video/seta_video_timing.sv:1 MAME gives only refresh rates and visible areas; the totals come from seta_board_cfg.sv (8 MHz dot clock, htotal 512).
rtl/video/seta_video_timing.sv:3 `line` is MAME screen-space y.
rtl/video/seta_video_timing.sv:30 the line starting, as MAME numbers it (scanline timers), with line_start
rtl/video/seta_video_timing.sv:32 MAME scanline 240
rtl/video/seta_video_timing.sv:33 MAME scanline 112
rtl/video/x1_001.sv:2 Reference: scripts/x1_001_model.py (MAME's video/x1_001.cpp), checked by sim/x1_001_tb.
rtl/video/x1_001.sv:11 Per scanline L, MAME's four wrap copies reduce to: fg: covered iff ((L + Y) & 0xff) < 16, Y = (sy + fg_yoffs) & 0xff bg: row r = (L - S0) >> 4, S0 = -(scrolly + bg_yoffs) x: (sx + xoffs) & 0x1ff on a 512-wide buffer
rtl/video/x1_001.sv:69 VIDEO_UPDATE_AFTER_VBLANK: MAME runs the copy, then draws
rtl/video/x1_001.sv:80 tndrcade: its vblank handler copies half of a work-RAM list each frame, and the list is rebuilt every other frame between the two halves' copies, so sprite RAM holds two list versions on alternate frames (MAME: PC 0x10430 and 0x103a2; the f
rtl/video/x1_001.sv:141 Games rewrite the list mid-frame (daioh, eightfrc at line 112); MAME draws at vblank.
rtl/video/x1_001.sv:186 setac_eof, at vblank, in MAME's order for the board (docs/MAME_DIVERGENCE.md, "setac_eof: the copy and the draw").
rtl/video/x1_001.sv:188 Draw-then-copy boards (drgnunit, stg, qzkklogy, qzkklgy2, msgundam): MAME draws at vblank start from the RAM as it stands, then copies.
rtl/video/x1_001.sv:237 MAME draws at vblank from the half selected then, as it stands then; the game may keep writing other halves right through the frame (stg does), so there is no settled moment to copy both.
rtl/video/x1_001.sv:632 MAME draws offs 2r then 2r+1
rtl/video/x1_011_index.sv:1 MAME's colortables (gundhara_palette, jjsquawk_palette, zingzip_palette, blandia_palette) reduce to arithmetic:
rtl/video/x1_012.sv:2 Reference: scripts/x1_012_model.py (MAME's video/x1_012.cpp).
rtl/video/x1_012.sv:53 downtown.cpp twineagl_tile_offset: codes 0x3exx take bits 13-7 from one of four bank bytes (>> 1), selected by code bits 8-7
rtl/video/x1_012.sv:59 bank select and scroll are latched at vblank_rise, as MAME draws the frame
rtl/video/x1_012.sv:61 raster: latched at every line_start instead, and a scroll or bank write also releases the queued VRAM writes -- MAME redraws the lines above at each such write (calibr50's trampoline), so the lines after it see the VRAM as it stood then.
rtl/video/x1_012.sv:111 CPU writes are queued and applied at vblank_rise, so a frame renders from VRAM as it stood at vblank, with the scroll latched there: MAME draws the frame at vblank from both.
rtl/video/x1_012.sv:123 Blandia tests its VRAM at boot, 12288 reads a layer in MAME, and read back old words it stopped with a black screen.
rtl/video/x1_012.sv:181 twineagl writes its tile bank mid-frame (lines 32-120 after vblank start, scripts/write_timing.py --extra tbank:400000:400007); MAME draws with the value it holds at vblank.
README.md:6 **Seta** — MAME's `seta/seta.cpp`
README.md:7 **Seta_Downtown** — MAME's `seta/downtown.cpp`: + 65C02 sub CPU
README.md:36 Downtown core: a coin press is five frames of coin, as MAME's `PORT_IMPULSE(5)`.
README.md:37 Twin Eagle: the carrier no longer flickers (the sprite snapshot fell among the vblank handler's sprite Y writes), and its tile bank is taken at vblank, as MAME
README.md:48 Sprites: the vblank copy runs in each board's order, as MAME's; Quiz Kokology's bees and Blandia's intro illustration are right
README.md:54 Button 3 wired for Blandia, as MAME's JOY_TYPE1_3BUTTONS; J. J. Squawkers shows two buttons (MAME declares three, the game reads two)
README.md:61 Flip screen DIP now works for all games that have one, as a true 180 degree rotation (MAME is 128 px / 8 lines out, see `docs/MAME_DIVERGENCE.md`)
README.md:85 The goal is to support the collection of hardware covered by MAME in `seta.cpp` and `downtown.cpp`.
README.md:142 | MAME description | Why |
README.md:165 | U.S. Classic (`downtown.cpp`) | Not yet: two trackballs through a uPD4701, colour PROMs, 6bpp tiles |
README.md:189 MAME gives only refresh rates.
README.md:189 The one marked "verified on PCB" in `seta.cpp` is Daioh's 57.42 Hz; the 60 Hz sets carry no comment.
README.md:191 Confirmed on a PCB: Guru's measurement of Caliber 50 (`downtown.cpp`, same X1-001 / X1-007 / X1-012 chipset, Seta_Downtown core) is **HSync 15.6250 kHz, VSync 5
README.md:197 | Caliber 50 | 15.6250 kHz | 57.4449 Hz | `downtown.cpp`, Guru |
README.md:198 | SD Gundam Neo Battling (in this core) | 15.22 kHz | 58 Hz | `seta.cpp`, Guru |
README.md:199 | Crazy Fight (out of scope) | 15.1433 kHz | 59.1851 Hz | `seta.cpp`, Guru |
README.md:200 | Thundercade (Seta_Downtown core) | 15.21 kHz | 59.1845 Hz | `downtown.cpp`, Guru |
README.md:415 Put the MAME merged or split ROMs in `games/mame`
README.md:420 The same in MAME.
README.md:421 MAME shows the same.
README.md:422 The same in MAME.
README.md:433 [ ] Upstream to MAME: Thundercade's sprites updated only on frames after a control byte write (`docs/MAME_DIVERGENCE.md`, "Thundercade: sprites update at 30 Hz"
README.md:434 [ ] Upstream to MAME: flip screen as the unflipped frame rotated 180 -- the x1_012 tilemap mirror about the 512x256 bitmap, and the per-game flip offsets (`fg_y
README.md:450 The author is somewhat familiar with some of the games on this platform, being a co-author of the MAME driver.
README.md:454 MAME is the accuracy reference for the most part, with its own acknowledged uncertainties noted where they matter.
README.md:456 Hardware facts come from the MAME driver and verified against it.
README.md:458 The CPU is diffed against a real MAME trace
README.md:459 The sprite engine and the video path are diffed against MAME's own render
README.md:460 The sound is diffed against a line-by-line transcription of MAME's mixer.
README.md:475 The **MAMEdev team** — in particular **Luca Elia** and **David Haywood** — for [MAME](https://github.com/mamedev/mame)'s `seta/seta.cpp`, `video/x1_001.cpp` and
README.md:477 There is no FPGA implementation of the X1-010 anywhere, so MAME's C++ is the whole specification for the sound chip.
README.md:496 | `debug` | reference captures from MAME used as ground truth (gitignored) |
README.md:497 | `roms` | your own MAME sets (gitignored, never committed) |

Says it matches, follows or was checked against MAME — 3

README.md:171 | X1-001A + X1-002A | Sprites, and the "floating tilemap" made of sprite columns | Written, verified against MAME |
README.md:174 | X1-010 | 16-voice PCM / wavetable sound | Written, verified against MAME |
README.md:178 | X1-012 | Tilemaps | Written, verified against MAME |

Keeps a MAME approximation — 1

README.md:424 See `docs/MAME_DIVERGENCE.md` for cases that are considered 'hacks' from MAME, and also any cases where we diverge from MAME.

Shares text with the MAME driver without saying so — 2

rtl/video/x1_011_index.sv:5 0x400 + ((((color & ~3) << 4) + pen) & 0x1ff) PAL_MASKED — shares text with seta/seta.cpp:1833
rtl/video/x1_012.sv:200 if (flip) { x = -x - 512; y = y - vis_dimy; } — shares text with seta/x1_012.cpp:134

Arcade-SetaDowntown (ppriest)#
Arbalester, Caliber 50, DownTown / Mokugeki, Meta Fox …
ppriest/Arcade-Seta_MiSTer @ 4f54f2d4
MAME compared: seta/downtown.cpp + 2 related file(s)
Read: 40 HDL files, 10,683 lines (Quartus project)

ppriest
repository only

Mostly MAME

medium

57%

Statements: 5 toward hardware, 113 toward MAME, 2 not counted

Cites hardware references or measurements that MAME's driver also gives — 2

rtl/downtown/downtown_board_cfg.sv:264 224 lines; MAME's 60 Hz, Guru's PCB measurement 59.1845 Hz. — also in MAME: 59.1845 seta/downtown.cpp:95
README.md:197 Confirmed on a PCB: Guru's measurement of Caliber 50 (`downtown.cpp`, same X1-001 / X1-007 / X1-012 chipset, Seta_Downtown core) is **HSync 15.6250 kHz, VSync 5 — also in MAME: 15.6250 seta/downtown.cpp:208, 57.4449 seta/downtown.cpp:209

Says it was checked against the original PCB — 3

rtl/downtown/downtown_board_cfg.sv:152 272 lines = 57.44 Hz (downtown, twineagl: 57.42 in MAME, "verified on pcb" for downtown); 264 lines = 59.19 Hz (metafox, arbalest: MAME's 59.1845, Thundercade's PCB measurement).
README.md:195 The one marked "verified on PCB" in `seta.cpp` is Daioh's 57.42 Hz; the 60 Hz sets carry no comment.
README.md:197 Confirmed on a PCB: Guru's measurement of Caliber 50 (`downtown.cpp`, same X1-001 / X1-007 / X1-012 chipset, Seta_Downtown core) is **HSync 15.6250 kHz, VSync 5

Reports a measurement taken on the original PCB — 1

rtl/seta_board_cfg.sv:163 Timing: 8 MHz dot clock, htotal 512, vtotal 272 = 57.44 Hz, matching daioh's rate, the only one seta.cpp marks as measured on a PCB (the 60 Hz sets carry no comment).

Notes where it differs from MAME — 1

README.md:443 See `docs/MAME_DIVERGENCE.md` for cases that are considered 'hacks' from MAME, and also any cases where we diverge from MAME.

Cites MAME source — 108

Seta_Downtown.sv:1 Seta_Downtown: MAME's seta/downtown.cpp boards (docs/DOWNTOWN.md).
rtl/cpu/adc0834.sv:1 ADC0834 serial ADC behind Zombie Raid's guns: MAME's adc083x.cpp state machine for the 0834.
rtl/cpu/adc0834.sv:3 Within a write the /CS step is applied before the clock step, as MAME's gun_w orders them.
rtl/cpu/maincpu.sv:36 gun ADC at 0xf00000 downtown.cpp downtown_map (downtown, twineagl, metafox, arbalest); its sub CPU, tile bank and control registers are decoded in seta_core
rtl/cpu/maincpu.sv:40 downtown.cpp calibr50_map: X1-010 on the 65C02, battery RAM, uPD4701
rtl/cpu/maincpu.sv:42 downtown.cpp tndrcade_map: no tile layer, sound on the 65C02
rtl/cpu/maincpu.sv:72 Undriven reads are zero, as MAME's unmapped reads.
rtl/cpu/maincpu.sv:122 RAM above the palette, where MAME maps one
rtl/cpu/maincpu.sv:480 downtown.cpp downtown_map
rtl/cpu/maincpu.sv:498 downtown.cpp calibr50_map
rtl/cpu/maincpu.sv:517 downtown.cpp tndrcade_map
rtl/cpu/seta_irq.sv:5 seta.cpp's ipl0/1/2_ack_w clear levels 1/2/4.
rtl/cpu/seta_pit.sv:1 uPD71054C (8254) PIT, channel 0 only: seta.cpp clocks channel 0 at 1 MHz and wires OUT0's rising edge to IPL 4 (pit_out0); channels 1 and 2 are unconnected.
rtl/downtown/downtown_board_cfg.sv:1 Per-game constants for the downtown.cpp boards, selected by the .mra mod byte: the same outputs as seta_board_cfg.sv (seta_core picks this module under SETA_DOWNTOWN), plus the sub CPU's. Values from each set's machine_config and memory map
rtl/downtown/downtown_board_cfg.sv:95 calibr50: tile scroll taken each line, tile VRAM written live (its scroll is changed mid-frame; MAME redraws at each write)
rtl/downtown/downtown_board_cfg.sv:152 272 lines = 57.44 Hz (downtown, twineagl: 57.42 in MAME, "verified on pcb" for downtown); 264 lines = 59.19 Hz (metafox, arbalest: MAME's 59.1845, Thundercade's PCB measurement).
rtl/downtown/downtown_board_cfg.sv:205 downtown, twineagl: sprite Y written 0-24 lines after vblank start (248), codes through the frame, ending by about line 208 (MAME, scripts/write_timing.py).
rtl/downtown/downtown_board_cfg.sv:209 MAME draws at 248, before them.
rtl/downtown/downtown_board_cfg.sv:257 Sprites: flipped at line 249 every frame, Y written from 248 through line 15 (MAME, 900 frames).
rtl/downtown/downtown_board_cfg.sv:260 MAME draws at vblank start, 248, before any of it.
rtl/downtown/downtown_board_cfg.sv:264 224 lines; MAME's 60 Hz, Guru's PCB measurement 59.1845 Hz.
rtl/downtown/downtown_board_cfg.sv:277 No page flip and no setac_eof: one sprite list, written from line 248 (Y) through about line 100 (codes) -- MAME, 900 frames (scripts/write_timing.py tndrcade).
rtl/downtown/downtown_board_cfg.sv:281 MAME draws at vblank start, 240, inside the quiet window: take it as the engine starts rendering line 240.
rtl/downtown/downtown_board_cfg.sv:286 A PCB recording flickers the same way (README), so the frames are drawn as they come, as MAME does.
rtl/downtown/downtown_sub.sv:1 The downtown.cpp boards' 65C02 sub CPU: T65 (rtl/cpu/t65c02.vhd) and what each map puts on its bus.
rtl/downtown/rotary_input.sv:1 Rotary joysticks for the downtown.cpp games, with the controls the Ikari Warriors core (MiSTer-devel/Arcade-IkariWarriors_MiSTer) gives: Rotate Left and Rotate Right buttons step the stick while held, at the OSD's Rotary Speed, and a GRS Su
rtl/memory/gfx_swizzle.sv:1 MAME's gfx1 (RGN_FRAC(1,2) 4bpp) keeps a tile row's four 16-bit words in four places; permuted, a row is one 64-bit SDRAM granule addressed by {tile, yh, yl}.
rtl/memory/seta_sdram_top.sv:1 SDRAM: every ROM the core reads at runtime, on one chip through sdram.sv's three fixed-priority ports (port 0 preempts 1, 1 preempts 2): port 0 sprite and tile graphics (arbiter, 3 clients) port 1 X1-010 samples (byte bridge
rtl/memory/seta_sdram_top.sv:8 Address map, per layout (bases below; scripts/build_mra.py reads the localparams, so every .mra loads to these offsets): A maincpu 0, gfx1 1M (2 MB), x1snd 3M B maincpu 0, gfx1 1M (1 MB), gfx2 2M, x1snd 4M C maincpu 0, gfx1 2M (4 MB), gf
rtl/memory/seta_sdram_top.sv:89 downtown.cpp "sub" region, byte address (SUB)
rtl/memory/seta_sdram_top.sv:138 LAYOUT_G: downtown.cpp
rtl/seta_board_cfg.sv:1 Values come from each set's machine_config and memory map in seta.cpp: CPU clock (cpu_div), gfx1 size (gfx_half_words = bytes / 4, code_mask), PALETTE entries, GFXDECODE bases, interrupt sources and acknowledges, set_*offsets (flip, noflip)
rtl/seta_board_cfg.sv:100 VIDEO_UPDATE_AFTER_VBLANK (blandia, blandiap): MAME copies, then draws
rtl/seta_board_cfg.sv:102 snapshot on this line instead of at vblank (0 = the board's usual point): for a game that writes its list all frame, a line where it does not (docs/MAME_DIVERGENCE.md, "When the games write, in MAME")
rtl/seta_board_cfg.sv:144 Flipped foreground y is -0x0a on the 240-line sets: with MAME's -0x12 a flipped frame is the rotated unflipped one moved 8 lines.
rtl/seta_board_cfg.sv:150 madshark: flip value makes a flipped frame the unflipped one rotated 180 (MAME: 0)
rtl/seta_board_cfg.sv:163 Timing: 8 MHz dot clock, htotal 512, vtotal 272 = 57.44 Hz, matching daioh's rate, the only one seta.cpp marks as measured on a PCB (the 60 Hz sets carry no comment).
rtl/seta_board_cfg.sv:286 flip value makes a flipped frame the unflipped one rotated 180 (MAME: 2)
rtl/seta_board_cfg.sv:327 flip value makes a flipped frame the unflipped one rotated 180 (MAME: 0)
rtl/seta_board_cfg.sv:345 flip value makes a flipped frame the unflipped one rotated 180 (MAME: 0)
rtl/seta_board_cfg.sv:403 flip value makes a flipped frame the unflipped one rotated 180 (MAME: 0)
rtl/seta_board_cfg.sv:410 two buttons: MAME's BUTTON3 is read nowhere
rtl/seta_board_cfg.sv:456 no set_xoffsets; flip value makes a flipped frame the unflipped one rotated 180 (MAME: 0)
rtl/seta_board_cfg.sv:464 flip value makes a flipped frame the unflipped one rotated 180 (MAME: 0)
rtl/seta_board_cfg.sv:531 flip value makes a flipped frame the unflipped one rotated 180 (MAME: 0)
rtl/seta_board_cfg.sv:568 flip -4 rotates frame 2000 exactly; the game's flipped scroll writes are not consistent across frames (MAME: 0)
rtl/seta_board_cfg.sv:627 flip value makes a flipped frame the unflipped one rotated 180 (MAME: 0)
rtl/seta_core.sv:62 downtown.cpp: DownTown's rotary joysticks, positions 0..11
rtl/seta_core.sv:181 downtown.cpp's tile bank, declared before seta_video uses it (ModelSim)
rtl/seta_core.sv:510 not on the downtown.cpp boards (calibr50's battery RAM is in the downtown.cpp block)
rtl/seta_core.sv:657 ---- downtown.cpp: the 65C02 system and the board's own registers ---- map_board: 18 downtown_map, 19 calibr50_map, 20 tndrcade_map
rtl/seta_core.sv:794 tndrcade: YM2203 (DSW 1 on port A, DSW 2 on port B: dsw1_r / dsw2_r) and YM3812, both 16 MHz / 4; mixed 0.35 and 0.5 as MAME routes them
rtl/seta_prot_pairlove.sv:1 pairlove's 0x900000 block (seta.cpp prot_r/prot_w): a write saves the cell's value and stores the new one; a read returns the value and then reverts the cell to the saved one.
rtl/seta_prot_thunderl.sv:3 Transcribed bit for bit from seta.cpp.
rtl/video/seta_palette.sv:1 X1-006 palette RAM: xRRRRRGGGGGBBBBB words, looked up per pixel, expanded with MAME's pal5bit, (v << 3) | (v >> 2).
rtl/video/seta_video.sv:31 setac_eof, and whether MAME draws after it (x1_001.sv)
rtl/video/seta_video.sv:144 every line start, with the line starting (MAME's numbering)
rtl/video/seta_video_timing.sv:1 MAME gives only refresh rates and visible areas; the totals come from seta_board_cfg.sv (8 MHz dot clock, htotal 512).
rtl/video/seta_video_timing.sv:3 `line` is MAME screen-space y.
rtl/video/seta_video_timing.sv:30 the line starting, as MAME numbers it (scanline timers), with line_start
rtl/video/seta_video_timing.sv:32 MAME scanline 240
rtl/video/seta_video_timing.sv:33 MAME scanline 112
rtl/video/x1_001.sv:2 Reference: scripts/x1_001_model.py (MAME's video/x1_001.cpp), checked by sim/x1_001_tb.
rtl/video/x1_001.sv:11 Per scanline L, MAME's four wrap copies reduce to: fg: covered iff ((L + Y) & 0xff) < 16, Y = (sy + fg_yoffs) & 0xff bg: row r = (L - S0) >> 4, S0 = -(scrolly + bg_yoffs) x: (sx + xoffs) & 0x1ff on a 512-wide buffer
rtl/video/x1_001.sv:69 VIDEO_UPDATE_AFTER_VBLANK: MAME runs the copy, then draws
rtl/video/x1_001.sv:133 Games rewrite the list mid-frame (daioh, eightfrc at line 112); MAME draws at vblank.
rtl/video/x1_001.sv:178 setac_eof, at vblank, in MAME's order for the board (docs/MAME_DIVERGENCE.md, "setac_eof: the copy and the draw").
rtl/video/x1_001.sv:180 Draw-then-copy boards (drgnunit, stg, qzkklogy, qzkklgy2, msgundam): MAME draws at vblank start from the RAM as it stands, then copies.
rtl/video/x1_001.sv:229 MAME draws at vblank from the half selected then, as it stands then; the game may keep writing other halves right through the frame (stg does), so there is no settled moment to copy both.
rtl/video/x1_001.sv:617 MAME draws offs 2r then 2r+1
rtl/video/x1_011_index.sv:1 MAME's colortables (gundhara_palette, jjsquawk_palette, zingzip_palette, blandia_palette) reduce to arithmetic:
rtl/video/x1_012.sv:2 Reference: scripts/x1_012_model.py (MAME's video/x1_012.cpp).
rtl/video/x1_012.sv:53 downtown.cpp twineagl_tile_offset: codes 0x3exx take bits 13-7 from one of four bank bytes (>> 1), selected by code bits 8-7
rtl/video/x1_012.sv:59 bank select and scroll are latched at vblank_rise, as MAME draws the frame
rtl/video/x1_012.sv:61 raster: latched at every line_start instead, and a scroll or bank write also releases the queued VRAM writes -- MAME redraws the lines above at each such write (calibr50's trampoline), so the lines after it see the VRAM as it stood then.
rtl/video/x1_012.sv:111 CPU writes are queued and applied at vblank_rise, so a frame renders from VRAM as it stood at vblank, with the scroll latched there: MAME draws the frame at vblank from both.
rtl/video/x1_012.sv:123 Blandia tests its VRAM at boot, 12288 reads a layer in MAME, and read back old words it stopped with a black screen.
rtl/video/x1_012.sv:181 twineagl writes its tile bank mid-frame (lines 32-120 after vblank start, scripts/write_timing.py --extra tbank:400000:400007); MAME draws with the value it holds at vblank.
README.md:6 **Seta** — MAME's `seta/seta.cpp`
README.md:7 **Seta_Downtown** — MAME's `seta/downtown.cpp`: + 65C02 sub CPU
README.md:47 Sprites: the vblank copy runs in each board's order, as MAME's; Quiz Kokology's bees and Blandia's intro illustration are right
README.md:53 Button 3 wired for Blandia, as MAME's JOY_TYPE1_3BUTTONS; J. J. Squawkers shows two buttons (MAME declares three, the game reads two)
README.md:60 Flip screen DIP now works for all games that have one, as a true 180 degree rotation (MAME is 128 px / 8 lines out, see `docs/MAME_DIVERGENCE.md`)
README.md:84 The goal is to support the collection of hardware covered by MAME in `seta.cpp` and `downtown.cpp`.
README.md:148 | MAME description | Why |
README.md:171 | U.S. Classic (`downtown.cpp`) | Not yet: two trackballs through a uPD4701, colour PROMs, 6bpp tiles |
README.md:195 MAME gives only refresh rates.
README.md:195 The one marked "verified on PCB" in `seta.cpp` is Daioh's 57.42 Hz; the 60 Hz sets carry no comment.
README.md:197 Confirmed on a PCB: Guru's measurement of Caliber 50 (`downtown.cpp`, same X1-001 / X1-007 / X1-012 chipset, Seta_Downtown core) is **HSync 15.6250 kHz, VSync 5
README.md:203 | Caliber 50 | 15.6250 kHz | 57.4449 Hz | `downtown.cpp`, Guru |
README.md:204 | SD Gundam Neo Battling (in this core) | 15.22 kHz | 58 Hz | `seta.cpp`, Guru |
README.md:205 | Crazy Fight (out of scope) | 15.1433 kHz | 59.1851 Hz | `seta.cpp`, Guru |
README.md:206 | Thundercade (Seta_Downtown core) | 15.21 kHz | 59.1845 Hz | `downtown.cpp`, Guru |
README.md:434 Put the MAME merged or split ROMs in `games/mame`
README.md:439 The same in MAME.
README.md:440 MAME shows the same, and so does a [PCB recording](https://www.youtube.com/watch?v=g4TswNhGXjM), so the core draws every frame as it comes (`docs/MAME_DIVERGENC
README.md:441 The same in MAME.
README.md:452 [ ] Upstream to MAME: flip screen as the unflipped frame rotated 180 -- the x1_012 tilemap mirror about the 512x256 bitmap, and the per-game flip offsets (`fg_y
README.md:468 The author is somewhat familiar with some of the games on this platform, being a co-author of the MAME driver.
README.md:472 MAME is the accuracy reference for the most part, with its own acknowledged uncertainties noted where they matter.
README.md:474 Hardware facts come from the MAME driver and verified against it.
README.md:476 The CPU is diffed against a real MAME trace
README.md:477 The sprite engine and the video path are diffed against MAME's own render
README.md:478 The sound is diffed against a line-by-line transcription of MAME's mixer.
README.md:493 The **MAMEdev team** — in particular **Luca Elia** and **David Haywood** — for [MAME](https://github.com/mamedev/mame)'s `seta/seta.cpp`, `video/x1_001.cpp` and
README.md:495 There is no FPGA implementation of the X1-010 anywhere, so MAME's C++ is the whole specification for the sound chip.
README.md:514 | `debug` | reference captures from MAME used as ground truth (gitignored) |
README.md:515 | `roms` | your own MAME sets (gitignored, never committed) |

Says it matches, follows or was checked against MAME — 3

README.md:177 | X1-001A + X1-002A | Sprites, and the "floating tilemap" made of sprite columns | Written, verified against MAME |
README.md:180 | X1-010 | 16-voice PCM / wavetable sound | Written, verified against MAME |
README.md:184 | X1-012 | Tilemaps | Written, verified against MAME |

Keeps a MAME approximation — 1

README.md:443 See `docs/MAME_DIVERGENCE.md` for cases that are considered 'hacks' from MAME, and also any cases where we diverge from MAME.

Shares text with the MAME driver without saying so — 1

rtl/video/x1_012.sv:200 if (flip) { x = -x - 512; y = y - vis_dimy; } — shares text with seta/x1_012.cpp:134

Arcade-SKNS (srg320)#
Cyvern - The Dragon Weapons, Gals Panic 4, Gals Panic S - Extra Edition, Gals Panic S2 …
srg320/Arcade-SKNS_MiSTer @ 001965f1
MAME compared: kaneko/suprnova.cpp + 4 related file(s)
Read: 39 HDL files, 15,097 lines (Quartus project)

srg320
repository only

Not enough evidence in the code

insufficient

25%

Statements: 1 toward hardware, 2 toward MAME

Ships hardware documentation files — 1

hw/SKNS schematic.pdf

Cites MAME source — 2

rtl/SKNS/YMZ280B.sv:1 license:BSD-3-Clause (derived from MAME's ymz280b)
rtl/SKNS/YMZ280B_pkg.sv:1 license:BSD-3-Clause (derived from MAME's ymz280b)

Arcade-SuperBagman (cavemanxzx)#
Bagman, Super Bagman
cavemanxzx/MiSTer-Arcade-SuperBagman @ 443cf5eb
MAME compared: valadon/bagman.cpp + 3 related file(s)
Read: 9 HDL files, 2,728 lines (Quartus project)

cavemanxzx
repository only

Mostly MAME

low

54%

Statements: 6 toward MAME

Cites MAME source — 5

Arcade-SuperBagman.sv:211 JPAC/IPAC/MAME Style Codes
rtl/bagman_pal16r6.vhd:6 MAME show a complete pal16r6 simulation from fusemap.
rtl/bagman_pal16r6.vhd:45 Clock scheme within MAME seems to be missing.
rtl/plc10_speech_synthetizer.vhd:4 Main part of the TMS5110 simulation - algorithm is from MAME source Job here includes parsing the bit stream from PROM data and computes speech samples
rtl/ym_2149_linmix.vhd:44 Clues from MAME sound driver and Kazuhiro TSUJIKAWA

Says it was translated, ported or taken from MAME — 1

rtl/bagman_pal16r6.vhd:4 Pal contents comes from MAME src/machine/bagman.c fusemap.

Arcade-SuperCobra (gaz68)#
Super Cobra
gaz68/Arcade-SuperCobra_MiSTer @ 7ba241c0
MAME compared: galaxian/galaxian.cpp + 7 related file(s)
Read: 16 HDL files, 7,966 lines (Quartus project)

gaz68
repository only

Not enough evidence in the code

insufficient

18%

Statements: 2 toward hardware, 2 toward MAME

Cites hardware documentation that MAME's driver does not — 2

scobra.vhd:192 089 (081 according to schematics?)
scobra.vhd:194 0FF (0F9 according to schematics?)

Cites MAME source — 2

Arcade-SuperCobra.sv:192 'h005: btn_one_player <= pressed; // F1 'h006: btn_two_players <= pressed; // F2 JPAC/IPAC/MAME Style Codes
YM2149_linmix_sep.vhd:45 Clues from MAME sound driver and Kazuhiro TSUJIKAWA

Arcade-SuperMouse (harlock74)#
Funny Mouse
harlock74/Arcade-SuperMouse_MiSTer @ 59896546
MAME compared: taito/roundup.cpp
Read: 33 HDL files, 2,764 lines (Quartus project)

harlock74
repository only

Mostly MAME

low

21%

Statements: 15 toward MAME

Cites MAME source — 12

SuperMouse.sv:193 The selected MAME decode has no second pair; an assertion exposes an unsupported mode.
rtl/supermouse_background.sv:1 SPDX-License-Identifier: GPL-3.0-or-later MAME-functional tile/sprite composition.
rtl/supermouse_background.sv:48 MAME layout: region +2000 is pen bit 0, +1000 bit 1, +0000 bit 2.
rtl/supermouse_background.sv:55 Pinned MAME order, top first: high sprite, front solid, low sprite, transparent foreground, rear solid.
rtl/supermouse_background.sv:105 Pinned-MAME digital conversion, not a measured resistor-DAC model.
rtl/supermouse_controls.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Super Mouse input byte and all eight MAME-functional DIP bits.
rtl/supermouse_controls.sv:13 MAME Q2 callback sends !Q2 to coin_lockout_w: Q2=0 locks coin 1.
rtl/supermouse_mainbus.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Super Mouse MAME-functional Intrepid map.
rtl/supermouse_mainbus.sv:46 MAME allocates zero-filled 5000-7fff in its mapped ROM region.
rtl/supermouse_mainbus.sv:114 functional MAME default, not physical open bus
rtl/supermouse_maincpu.vhd:90 The selected MAME graphics decode has only one tile/sprite pair; no second physical bank is fabricated here.
README.md:5 FPGA implementation of **Super Mouse**, based on the original arcade game supported by MAME as `suprmous`.

Says it matches, follows or was checked against MAME — 1

rtl/supermouse_mainbus.sv:51 Configuration-time RAM contents match MAME's cold zero allocation.

Says it was translated, ported or taken from MAME — 1

README.md:7 Current status: functional behavioural implementation, mainly based on MAME/reference behaviour and available arcade hardware documentation.

Keeps a MAME approximation — 1

rtl/supermouse_background.sv:98 MAME-COMPATIBILITY-APPROXIMATION: these eight digital primary colours are generated separately.

Arcade-SystemC2 (Mezzow)#
Bloxeed, Borench, Columns II: The Voyage Through Time, Columns …
Mezzow/Arcade-SystemC2_MiSTer @ acb14620
MAME compared: sega/segac2.cpp + 5 related file(s)
Read: 22 HDL files, 8,550 lines (Quartus project)

Mezzow
repository only

Mostly MAME

medium

76%

Statements: 2 toward hardware, 68 toward MAME

Cites hardware documentation that MAME's driver does not — 1

README.md:65 No service manual, schematic or die shot for System C/C-2 has been located; MAME is the authority for everything here; every hardware fact in this core is cited

Says it was checked on “real hardware” — 1

README.md:214 **Audio is confirmed by ear on hardware** as of 2026-09-04: uPD7759 voice samples play, and the FM and PSG sit together in the mix.

Cites MAME source — 60

Arcade-SystemC2.sv:304 A C-2 board is NTSC only (segac2.cpp sets is_pal(false) and 262 lines), so the same reconfiguration runs once, unconditionally, and never again.
Arcade-SystemC2.sv:386 All 64 KB of work RAM at 0xE00000 is battery backed on the board (segac2.cpp:775 shares it as "nvram"), so a cabinet that has been switched on before starts from the previous session rather than from any constant.
Arcade-SystemC2.sv:392 c2_system's port B is the save port and already maps one for one: BRAM_A is a flat byte address over exactly 64 KB and BRAM_A[0] picks the byte lane, so file byte N is the 68000 byte at 0xE00000 + N -- the same layout MAME writes.
Arcade-SystemC2.sv:571 The bit order is from INPUT_PORTS_START(systemc_generic) in segac2.cpp: P1/P2 0 B1, 1 B2, 2 B3, 3 unused, 4 down, 5 up, 6 right, 7 left SERVICE 0 coin1, 1 coin2, 2 test, 3 service1, 4 start1, 5 start2 MiSTer joystick bits: 0 right, 1 left
Arcade-SystemC2.sv:594 The TEST switch is momentary (segac2.cpp:824, PORT_SERVICE_NO_TOGGLE), and a press of it *latches* the game into the service menu -- ten frames is enough.
rtl/c2_io.sv:7 Modelled from MAME 0.276 src/mame/sega/315_5296.cpp.
rtl/c2_io.sv:19 MAME masks the direction with 0x0F for that set (segac2.cpp:1931).
rtl/c2_io.sv:60 The pull-ups on the board mean an input-configured output port reads as 0 at the far end, which is how MAME models it (it calls the output handler with 0).
rtl/c2_palette.sv:9 Index (11 bits), from segac2.cpp recompute_palette_tables():
rtl/c2_palette.sv:23 Colour word is xBGRBBBB GGGGRRRR: four bits per channel plus one extra "half" bit each in 14:12, giving five bits per channel (segac2.cpp:481).
rtl/c2_palette.sv:25 MAME's own comment next to the highlight case is "how is it calculated on c2?", so treat any difference there as unverified rather than as a defect in this module.
rtl/c2_palette.sv:70 palette_r / palette_w, segac2.cpp:466 and :460.
rtl/c2_palette.sv:79 pal is the 9-bit value MAME calls bgpal/sppal with the colour index folded into the low nibble: bit 8 selects the sprite half, 7:6 the palbase, 5:4 the palette line, 3:0 the colour.
rtl/c2_palette.sv:84 segac2.cpp:1767 switches on bits 7:6 of the VDP's raw line: 0x80 is the only code that selects sp_pal_lookup, and 315_5313.cpp:2181 only emits it for `(sprite) normal pri, no shadow sprite, no highlight`.
rtl/c2_palette.sv:95 recompute_palette_tables(), segac2.cpp:532.
rtl/c2_palette.sv:156 MAME pal5bit
rtl/c2_prot.sv:23 Every one of the 18 protection functions in segac2.cpp is combinational, so each chip collapses to a 256x4 table.
rtl/c2_prot.sv:29 control_w bit 1 low clears both FIFO stages (segac2.cpp:637).
rtl/c2_romload.sv:21 segac2.cpp:375 takes the bank count from the declared region size, so ribbit has four banks even though only the first is dumped -- which is why c2_rom.py emits the declared size, not the used one.
rtl/c2_romload.sv:57 0xFF is "no override" and is what every set but one wants; tfrceacjpb needs 0x0F because it writes a bad DDR value and would otherwise read the service port as though TEST were held (segac2.cpp:1931).
rtl/c2_romload.sv:68 borencha and borenchj want 0xFF instead -- they never write the YM3438 panning registers and rely on the fill to leave them enabled, which is MAME's reason for NVRAM(DEFAULT_ALL_1) (segac2.cpp:1873).
rtl/c2_system.sv:12 Differences from a Mega Drive that matter, all from MAME 0.276 segac2.cpp:
rtl/c2_system.sv:101 Reads of the 315-5296, so a divergence that shows up only in what the game *reads* can be compared against MAME the way the writes already are.
rtl/c2_system.sv:228 segac2.cpp int_callback only clears the VDP's pending H-int, and only on a level 4 acknowledge.
rtl/c2_system.sv:238 MAME asserts it with HOLD_LINE, i.e. it stays up until acknowledged, so latch the VDP's self-clearing pulse.
rtl/c2_system.sv:473 That is what MAME's screen bitmap contains, and comparing a 344x243 bordered frame against a 320x224 one only ever reports SIZE MISMATCH.
rtl/c2_system.sv:475 An arcade monitor showed the border; MAME's bitmap does not, and MAME is the reference.
rtl/c2_system.sv:564 control_w bit 0 blanks the whole screen, which Bloxeed uses while it rewrites tiles (segac2.cpp:632, and screen_update_segac2_new fills the bitmap with black when it is clear).
rtl/c2_system.sv:587 control_w, segac2.cpp:628.
rtl/c2_system.sv:650 D7 is the MB3773P watchdog output, D6 the uPD7759 /BUSY (segac2.cpp:559).
rtl/c2_system.sv:718 A CPU write to 0x880000 loads the sample number and pulses /START low then high (segac2_upd7759_w, segac2.cpp:434).
rtl/c2_system.sv:752 The bank comes from I/O port H bits 3:2, masked by how many banks the loaded sample ROM actually has (segac2.cpp:604).
rtl/c2_system.sv:791 They transfer because this is the same jt12 + jt89 pair under the same weights: segac2.cpp routes the FM at 0.50 (:1912) and the VDP at 0.50 (:1893) with 315_5313.cpp:248 putting SEGAPSG into the VDP at 0.50 -- the megadriv values, unchange
rtl/c2_system.sv:794 Do not read those weights as a peak ratio; each MAME device normalises its own output differently, which is why the ratio here comes from a mix that was tuned against hardware rather than from arithmetic on the route numbers.
rtl/c2_system.sv:799 The uPD7759 goes in at MAME's weight for it, equal to the FM (:1925 0.50 against :1912 0.50).
rtl/c2_system.sv:818 The board is mono, and only the YM3438's left output reaches the amplifier: segac2.cpp:1912 routes output 0 alone and the line below it says "right channel not connected".
rtl/c2_system.sv:836 Reset fill is 0xFF, not 0x00: borencha has no sound otherwise, because it lacks the init code its sibling set has (segac2.cpp:1873).
rtl/c2_system.sv:846 The whole 64 KB at 0xE00000 is battery backed on the board (segac2.cpp:775 shares it as "nvram"), so on any machine that has been switched on before it holds the previous session's contents.
rtl/c2_system.sv:851 It used to be 0xFF for every set, copying MAME's NVRAM(DEFAULT_ALL_1).
rtl/c2_system.sv:851 That value was chosen in MAME for borencha alone -- it never writes the YM3438 panning registers and needs the fill to leave them enabled -- and it is wrong for wwanpanm and soniccar, whose sound driver reads its pending-sample byte out of
rtl/c2_system.sv:859 Measured both ways in MAME, see NOTES.md.
rtl/c2_system.sv:934 A byte write to the even address of the same word puts the data on D15-D8, where the device cannot see it -- MAME's mask drops it, and so must this.
rtl/c2_system.sv:970 Taken bit for bit from the mirror masks in segac2.cpp:766-782.
rtl/c2_system.sv:1217 The sound driver polls the YM3438 status before nearly every write -- MAME's puyo does 5478 reads in 60 frames, getting 0x00 and 0x80.
rtl/vdp.vhd:2874 Measured against MAME: the captured frame had a black first row, every row below it carried the content of the row above, and the bottom line was missing.
README.md:15 assistant** (Anthropic's Claude), working from MAME's source under human direction.
README.md:26 framework, and the MAME team whose driver is the only public documentation of this hardware.
README.md:63 **MAME** (`src/mame/sega/segac2.cpp` by David Haywood and Aaron Giles, `src/mame/sega/315_5296.cpp` by hap with thanks to Charles MacDonald, `src/devices/video/
README.md:65 No service manual, schematic or die shot for System C/C-2 has been located; MAME is the authority for everything here; every hardware fact in this core is cited
README.md:82 **Protection tables.** The 317-xxxx chips are a two-stage FIFO around a purely combinational 8-in/4-out function — 25 of them in MAME's driver, one per chip — s
README.md:166 `wwjumbo` and `wwpajero` were added to `segac2.cpp` after the MAME 0.276 this core is pinned to; their layout and switch definitions are carried as data alongsi
README.md:224 Only the four sets above have MRAs and have been tested; the rest of `segac2.cpp` is untested.
README.md:225 Residual differences against MAME, all in mid-display raster timing rather than in what is drawn: Puyo Puyo frames 120 and 300 (851 and 177 pixels of 71680), Se
README.md:228 does not write the two uPD7759 samples MAME writes at frame 285.
README.md:229 **Three sets do not work.** Two of them fail for the same reason: MAME gives the machine a small per-game bus quirk that this core has no equivalent for.
README.md:232 | set | what MAME does that the core does not |
README.md:249 The Megalo 50 moving-seat device that MAME wires to Puyo Puyo and Ribbit!
README.md:269 A Verilator bench runs each game's ROMs through the whole core — including the real `sdram.sv` against an SDRAM model, not a flat memory — and compares its fram
README.md:276 Sound is checked as a register stream, not as "it is not silent": a MAME Lua trace and the bench are compared write for write, per device, with the frame each s
README.md:282 The 317-xxxx protection tables are generated by parsing and evaluating the boolean expressions in `segac2.cpp` rather than re-typing them, then checked against

Says it matches, follows or was checked against MAME — 4

README.md:18 The core has been checked against MAME reference frames in simulation and runs the games listed
README.md:106 | Columns (World) | `columns` | System C | yes | none | boots and plays; **7/7 frames pixel-identical to MAME** |
README.md:219 What is gated in simulation is still the register stream the 68000 writes to each chip, which matches MAME write for write on all four local sets, plus a check
README.md:267 The core is verified against MAME 0.276 rather than by looking at it.

Keeps a MAME approximation — 1

README.md:21 undocumented the core does what MAME does, and where MAME's own comments say "guess", so does

Shares text with the MAME driver without saying so — 3

rtl/c2_io.sv:2 Sega 315-5296 I/O chip — shares text with sega/315_5296.cpp:6
rtl/c2_palette.sv:26 next to the highlight case is "how is it calculated on c2?", so treat any — shares text with sega/segac2.cpp:494
rtl/c2_system.sv:752 The bank comes from I/O port H bits 3:2, masked by how many banks the loaded — shares text with sega/segac2.cpp:511

Arcade-TaitoGNET (shmupfan)#
Chaos Heat, Flip Maze, Go By RC, Kollon …
shmupfan/Arcade-TaitoGNET_MiSTer @ 25227595
MAME compared: sony/taitogn.cpp + 6 related file(s)
Read: 122 HDL files, 53,936 lines (Quartus project)

shmupfan
repository only

Both

high

39%

Statements: 8 toward hardware, 189 toward MAME

Cites hardware documentation that MAME's driver does not — 1

rtl/gnet/znmcu.vhd:1 ZN I/O MCU (NEC uPD78081, ROM not dumped): behavioural model on SIO0.

Says it was checked on “real hardware” — 4

rtl/cd_top.vhd:1121 Reject pause while seeking (SeekL/SeekP) or while reading/playing before the first sector has been processed (verified on real hardware).
README.md:18 The other games, the first-boot copy and several shell features still need testing on real hardware, and some timings are known to differ from the real board (s
README.md:31 Batches 2 and 3 share the same hardware paths in the core, but have had little or no testing on hardware, so expect bugs.
README.md:53 | Batch 2 (this release) | Other Type 1 card games and versions | Play testing on hardware, and a look at the interrupt quirk MAME works around for Kollon (V2.0

Notes where it differs from MAME — 3

rtl/gnet/zn2_io.vhd:15 Map (MAME 0.288 zn.cpp maincpu_program_map 146-164 and zn2_maincpu_program_map 166-173, taitogn.cpp 473-488): A00000 P1, A00100 P2, A00200 SERVICE, A00300 SYSTEM (8-bit, lane 0; active low; writes ignored: the BIOS writes 1-7 and 0Fh to A00
README.md:210 The core also applies the SPU main volume the games set, which MAME ignores, so at MAME's setting the effects are quieter than in MAME (by 2.5 to 14.1 dB depend
README.md:238 Where the core differs from MAME, and why.

Cites MAME source — 180

PSX.sv:520 Game configuration from the MRA (ioctl index 7, one byte): bit 0 = the set is vertical (ROT270 in MAME taitogn.cpp: psyvaria, psyvarij, psyvarrv, xiistag, shikigam, shikigama).
PSX.sv:523 Bit 1 = the set has no Taito Zoom board (MAME init_nozoom, taitogn.cpp 416-419: otenamih, otenamhf, zokuoten, zokuotena, zooo, sianniv and the 2011 conversions): the Zoom's MN10200 stays in reset whatever the game writes to the control regi
PSX.sv:839 Keyboard, MAME default keys (ps2_key: [10] toggles per event, [9] pressed, [8] extended, [7:0] set-2 scancode) P1: arrows, LCtrl = B1, LAlt = B2, Space = B3, 1 = Start, 5 = Coin P2: R/F/D/G, A = B1, S = B2, Q = B3, 2 = Start, 6 = Coin 9 = S
PSX.sv:884 Special controls (gnet_inmode, MAME 0.288 taitogn.cpp INPUT_PORTS mahjngoh, usagi and gobyrc).
PSX.sv:885 Bits MAME marks unused read as released.
PSX.sv:893 Mahjong panel (taitogn.cpp ttgnmp_state, rows KEY0-KEY3 of mame shared/mahjong.cpp mahjong_matrix_1p) on the keyboard, MAME's default keys (emu/inpttype.ipp): A to N, Kan = LCtrl, Pon = LAlt, Chi = Space, Reach = LShift, Ron = Z; Start 1 is
PSX.sv:896 LCtrl, LAlt and Space also stay P1 buttons 1-3, as MAME binds both by default.
PSX.sv:937 Wheel: the analog stick's X, or the paddle once it moves (the source that moved last is used); trigger: the stick's Y reversed as MAME's PORT_REVERSE (stick up = FFh).
PSX.sv:1883 G-NET: inputs active low (MAME zn/taitogn input ports, docs/zn2_layer_design.md 7.1) zj1/zj2: joysticks, with the MAME keyboard keys in GNET_SHELL builds
PSX.sv:1948 MAME taitogn.cpp 441-448: SPU to the speakers at 0.3, Zoom at 1.0, both 16-bit full scale (rtl/zoom/zoom_mix.sv; the PCB balance is open, R13).
PSX.sv:1950 The SPU gain is the OSD SFX Level in shell builds (0.3 default): MAME's spu.cpp ignores the SPU main volume the games set (Ray Crisis 0x1125, about 0.27), spu.vhd applies it, so the effects come out quieter than in MAME at the same route.
PSX.sv:1965 OSD SFX Level: 0.3 (MAME, default) ...
PSX.sv:1967 0.3, MAME's route
rtl/gnet/gnet_ata.sv:15 Evidence: CF+ and CompactFlash specification Rev 1.4 (task file, status, attribute memory); MAME 0.288 ataflash.cpp, atahle.cpp, atastorage.cpp for the Taito lock and every behaviour the specification leaves open.
rtl/gnet/gnet_ata.sv:19 Per-game data comes in through the meta load port (byte address): 000h-1FFh IDENTIFY block (CHD metadata IDNT, returned verbatim as MAME) 200h-2FFh CIS (CHD metadata CIS, padded with FFh) 300h-304h unlock key (CHD metadata KEY); key_valid =
rtl/gnet/gnet_ata.sv:29 Attribute memory (16-bit word offsets, MAME read_reg/write_reg): 000h-0FFh CIS byte; 100h configuration option; 101h configuration and status; 102h pin replacement (reset 002Eh); Type 1 only (not Type 2 or CompactFlash): 201h lock status (1
rtl/gnet/gnet_ata.sv:42 While BSY every command block read except the data port returns status (MAME).
rtl/gnet/gnet_ata.sv:43 Commands: 20h READ SECTORS, 30h WRITE SECTORS, ECh IDENTIFY DEVICE; any other command ends with ERR and ABRT (MAME also implements 90h, EFh, E7h and the multiple/DMA forms; the games never issue them).
rtl/gnet/gnet_ata.sv:46 While locked every command ends with ERR, error 00h and DRDY clear (all three card types, MAME).
rtl/gnet/gnet_ata.sv:49 Type 2 unlock (MAME 0.288 taito_pccard2_device): locked at power-on when a key is loaded.
rtl/gnet/gnet_ata.sv:54 MAME also raises IRQ for FEh and FCh; this card has no IRQ output (the G-NET BIOS polls status), as for the other commands.
rtl/gnet/gnet_ata.sv:58 CompactFlash unlock (MAME 0.288 taito_compact_flash_device): locked at power-on when a key is loaded.
rtl/gnet/gnet_ata.sv:59 0Fh, at once and whether locked or not: unlock if feature, sector count, sector number, cylinder low and cylinder high equal key bytes 0-4 (sector count as MAME holds it: 00h written is 100h), else DRDY clears and the card stays locked; no
rtl/gnet/gnet_ata.sv:63 MAME's IRQ for 0Fh is left out as for the other commands.
rtl/gnet/gnet_ata.sv:65 Timing (MAME 0.288 values as defaults, all parameters): reset detect 2 ms then diagnostic 2 ms; IDENTIFY 10 us busy; first sector of a read 0 (CF seek time); between sectors 400 ns; each written sector 100 us.
rtl/gnet/gnet_ata.sv:67 Status bit IDX is always 0 (CF 1.4); MAME's hard disk model has an index pulse in calculate_status, but it never appears in the oracle traces, so MAME and the specification agree.
rtl/gnet/gnet_ata.sv:73 A read fills the sector buffer in the background; data port reads stall (op_ack) until their word has arrived, so DRQ timing stays as MAME's. A written sector goes to storage during its busy time and sets its 4 KB hunk in the dirty map.
rtl/gnet/gnet_ata.sv:257 registers the reset sequence leaves (device_reset in MAME)
rtl/gnet/gnet_ata.sv:539 status as a read sees it: DRDY is set lazily on every register read once the card is ready (MAME command_r/control_r)
rtl/gnet/gnet_ctrl.sv:13 Registers (main CPU, MAME 0.288 taitogn.cpp, docs/hardware_inventory.md 4): 0x1fb40000 control 8-bit R/W, reset 0x10: bit 5 MB3773 CK, bit 4 Zoom reset (1 = held), bit 2 flash bank select 0x1fb60000 control2 16-bit, write only 0x1fa30000 c
rtl/gnet/gnet_fc.sv:15 000000-7fffff flash bank window (16-bit devices), bank = control bit 2 | JP1 << 1 (MAME 0.288 taitogn.cpp flashbank_map): bank 0: U30 000000-1fffff, card attribute memory 200000-2fffff (RF5C296 memory window), U27 300000-37ffff bank 1, 3: U
rtl/gnet/gnet_fc.sv:32 card_present = 0 (empty slot): the RF5C296 reports no card and card attribute memory and task file read FFFFh, writes ignored, as MAME's empty pccard slot (pccard.cpp read_memory/read_reg return 0xffff).
rtl/gnet/gnet_flash.sv:17 Commands (Intel 28F160S3 290608-005 and 28F400B5; MAME intelfsh.cpp for the mode transitions the datasheets leave open): FFh/F0h read array, 90h read identifier, 70h read status register, 50h clear status register (enters read status, as MA
rtl/gnet/gnet_flash.sv:24 TE28F160: B0h/D0h; E28F400B: 89h/4471h (values as MAME; 28F160S3 datasheet Table 12 p24 gives B0h/D0h).
rtl/gnet/gnet_flash.sv:28 Program: the stored word becomes old AND new (PROGRAM_AND = 1, datasheet: programming only clears bits) or new (PROGRAM_AND = 0, MAME overwrites).
rtl/gnet/gnet_flash.sv:32 Timing (cycles of clk), PRESET 1 = MAME 0.288 (program instant; erase 1.0 s, E28F400B 0.3 s boot/parameter and 0.6 s main), PRESET 2 = 28F160S3 typical at 2.7 V VPP (290608-005 p50: 20.0 us per word, 0.56 s per block), PRESET 3 = 28F160S5 t
rtl/gnet/gnet_flash.sv:39 When a program or erase completes, status returns to 80h whatever the read mode (datasheet: the WSM finishes); MAME only does this in read status mode.
rtl/gnet/gnet_flash.sv:145 A program or erase that started at the write of cycle W is complete for a status read at cycle R when R - W >= T: the timer then holds 1 (MAME: ready when the read happens at or after the write time + T).
rtl/gnet/gnet_rf5c296.sv:28 MAME 0.288 returns 00h for every register; the BIOS never reads one (oracle), so the difference is not visible.
rtl/gnet/gnet_rf5c296.sv:30 Index read back: the last index written (as MAME).
rtl/gnet/gnet_rf5c296.sv:31 Level, so the card starts its power-on sequence when the bit is set; MAME resets the card at each write with bit 6 = 0 instead.
rtl/gnet/pll_vid_fixed.v:12 pll2's static setting is already 53.693175 MHz (NTSC), which is also the ZN-2 GPU dot clock crystal (MAME zn.cpp: CXD8654Q at 53.693175 MHz).
rtl/gnet/zn2_board.vhd:13 Contents: * bus top: memorymux's zn_* port (expansion 1 and 3, ZN2_MAP = 1) to gnet_fc (flash window, control3, RF5C296 / ATA, control, control2, 0x1FB70000) or zn2_io (inputs, board registers, EEPROM, Zoom stub); anything else answers 0 *
rtl/gnet/zn2_board.vhd:44 gnet_flash timing: 1 = MAME, 2 = 28F160S3 2.7 V, 3 = 28F160S5 (FC PCB part)
rtl/gnet/zn2_board.vhd:80 special controls (MRA game configuration byte bits 3:2, PSX.sv): mahjong panel rows (zn2_io A10100) and the znmcu analog channels 0 and 1 (Go By RC / RC De Go wheel and trigger; FFh when unused, as MAME's unused ANALOG ports)
rtl/gnet/zn2_board.vhd:257 Taito Zoom ports (taitogn.cpp 483-487; rtl/zoom/zoom_host.sv decodes the same)
rtl/gnet/zn2_io.vhd:25 MAME's KEY ports define bits 0-5 only, so a selected row reads bits 6 and 7 as 0 (mahjong.cpp mahjong_matrix_1p) A10200 board configuration (BOARDCFG; MAME 69h = 4 MB RAM, 2 MB VRAM, 512 KB SPU RAM, revision 1) A10300 znsecsel (R/W): bit 2
rtl/gnet/zn2_io.vhd:35 The games' SPU register read routine does a dummy read at A51C00 + register offset, polls A60000 until bit 3 is set (up to 100 tries, then "SPU:T/O [ReadStatusFlag Error]"), then reads the SPU register itself (MAME trace, main docs/r1_cpu_d
rtl/gnet/zn2_io.vhd:39 SPU_STATUS = 0: bit 3 toggles on every read of the low half, starting at 1 (MAME); 1: bit 3 always 1 (enough for raycris and psyvaria per that trace, one poll per SPU read) AF0000-AF07FF AT28C16 EEPROM, byte per address: a write starts a se
rtl/gnet/zn2_io.vhd:46 MAME skips writes of the value already stored (at28c16.cpp 172); the datasheet does not, nor does this model.
rtl/gnet/zn2_io.vhd:49 B20000-B20007 reads FFFFh (zn.cpp unknown_r) Taito Zoom stub (no Zoom in the silent build): B80000-B80003 register writes ignored, BA0000 write ignored, BC0000 reads 0 (as taito_zm.cpp sound_irq_r), BE0000-BE01FF M66220FP mailbox, 256 x 8 o
rtl/gnet/zn2_io.vhd:83 inputs, active low (zn.cpp INPUT_PORTS in taitogn.cpp 798-857)
rtl/gnet/zn_cat702.vhd:13 Behaviour from the algorithm description and model in MAME 0.288 src/devices/machine/cat702.cpp (smf; no datasheet exists, evidence rank 5), written as hardware: no code taken.
rtl/gnet/zn_cat702.vhd:16 select falling : state = FCh, bit counter = 0 select rising : output = 1 SCK falling : if bit counter = 0, state = TF2(state) (fixed initial sbox); output = state(bit counter) SCK rising : if TXD = 0, state = sbox[bit counter](state
rtl/gnet/zn_cat702.vhd:29 This is MAME's order inside one SIO tick (sio.cpp 125-189: SCK low, TXD, SCK high, sample) with no extra clock of latency.
rtl/gnet/zn_cat702.vhd:77 sbox[n] from sbox[n-1] (cat702.cpp compute_sbox_coef)
rtl/gnet/zn_sio0.vhd:14 Register behaviour from MAME 0.288 src/devices/cpu/psx/sio.cpp (rank 5; no CXD8661R document), written as hardware, on PSX_MiSTer's bus_pad port (offsets 0-F of 0x1F801040): 0 data write: TX byte; TX ready and TX empty cleared; the bit t
rtl/gnet/zn_sio0.vhd:32 That is MAME's order inside sio_tick (SCK low, TXD, SCK high, sample).
rtl/gnet/zn_sio0.vhd:38 DSR: status bit 7 follows the line (low = set); a falling edge with the DSR interrupt enabled raises IRQ (sio.cpp write_dsr).
rtl/gnet/zn_sio0.vhd:48 0 = MAME (prescaler x baud per bit), 1 = joypad.vhd (baud per bit)
rtl/gnet/zn_sio0.vhd:153 DSR line (sio.cpp write_dsr)
rtl/gnet/znmcu.vhd:13 The MCU ROM is NO_DUMP (taitogn.cpp 1023-1024, R16), so this follows the behaviour of MAME 0.288 src/mame/sony/znmcu.cpp (rank 5), written as hardware (docs/zn2_layer_design.md 7): select falling : byte and bit counters 0; 50 us later DSR g
rtl/gpu.vhd:687 GPU type (G-NET: the ZN-2 CXD8654Q answers 2, MAME psxgpu.cpp case 0x07; PS1 mode unchanged)
rtl/gpu_pixelpipeline.vhd:340 texture page Y base: PS1 = tpage bit 4 (0 or 256); ZN-2 CXD8654Q = tpage bits 11 and 4 (0, 256, 512, 768), as MAME 0.288 decode_tpage for GPU type 2
rtl/psx_mister.vhd:316 no Taito Zoom board (MAME init_nozoom): its MN10200 held in reset
rtl/psx_top.vhd:34 gnet_flash timing: 1 = MAME, 2 = 28F160S3 2.7 V, 3 = 28F160S5 (FC PCB part)
rtl/psx_top.vhd:35 zn_sio0: 0 = MAME bit timing, 1 = joypad.vhd rule
rtl/psx_top.vhd:36 zn2_io 0x1FA60000: 0 = MAME toggle, 1 = bit 3 set
rtl/psx_top.vhd:285 no Taito Zoom board (MAME init_nozoom), clk1x, set at load
rtl/psx_top.vhd:3442 a set without the Zoom board (MAME init_nozoom, taitogn.cpp 416-419, 519-535): the MN10200 stays in reset as at power-on (taitogn.cpp 467), the game's control bit 4 is ignored; the host side (shared RAM, sound_irq_r reads 0) answers as with
rtl/zoom/mn10200.sv:18 0: shared prescalers as on the chip, 1: MAME timer phase (mn10200_periph.sv)
rtl/zoom/mn10200_core.sv:12 Semantics follow the MN102L manual; where the MN1020012A differs or the manual is silent, MAME 0.288 mn10200.cpp is the reference (design study 1.1, 1.2, 2.5) and the comments say so.
rtl/zoom/mn10200_core.sv:58 interrupt entry: MAME charges them before the access debug / trace port (design study 5.8)
rtl/zoom/mn10200_core.sv:92 MAME m_possible_irq: re-check at next boundary
rtl/zoom/mn10200_core.sv:412 Zoom board time base (docs/zoom_board_design.md 6.2): an external access lands at the end of its instruction in machine time (mn10200.cpp charges every cycle before the access), so the board looks this far ahead.
rtl/zoom/mn10200_core.sv:416 first instruction of a handler: no interrupt check (MAME)
rtl/zoom/mn10200_core.sv:516 ---------------------------------------------------------- reset: clear D0-D3, A0-A3 (MAME device_reset)
rtl/zoom/mn10200_core.sv:528 MAME take_irq: psw = (psw & 0xf0ff) | level << 8, which clears IE (bit 11) too; the MN102H manual also clears IE on acceptance.
rtl/zoom/mn10200_core.sv:575 MAME samples interrupts only when m_possible_irq is set (mn10200.cpp execute_run); the core keeps the same flag.
rtl/zoom/mn10200_core.sv:604 MAME sets m_possible_irq on MOV Dn,PSW and OR imm16,PSW, not on AND imm16,PSW
rtl/zoom/mn10200_core.sv:622 n = MDR:Dm, d = Dn; overflow (q >= 0x10000, includes d = 0) exactly when MDR >= d. MAME: VF set, Dm and MDR unchanged.
rtl/zoom/mn10200_core.sv:644 undefined opcode: MAME sets NMICR bit 1 (illegal()) and re-checks synthesis translate_off
rtl/zoom/mn10200_core.sv:666 flags from (byte & Dm) on 16 bits: NF = 0, ZF, CF = VF = 0 (MAME test_nz16)
rtl/zoom/mn10200_core.sv:700 MAME: PSW &= 0xff00 first.
rtl/zoom/mn10200_periph.sv:5 Everything else reads 0 and ignores writes, as MAME 0.288 mn10200.cpp io_control_r/w does for registers it does not decode.
rtl/zoom/mn10200_periph.sv:9 The register layout is the older MN10200 generation that MAME implements (design study 1 and 4.1; the MN102H manual describes a different map).
rtl/zoom/mn10200_periph.sv:14 A timer expires (pb + 1) x (cur + 1) machine cycles after it was armed, as MAME's refresh_timer computes; arming by a mode write takes effect at the end of the writing instruction, which is where MAME's write lands in machine time (all cycl
rtl/zoom/mn10200_periph.sv:20 1: MAME-exact timer phase: each armed timer expires (prescaler base + 1) x (cur + 1) machine cycles after arming, with its own prescale counter and the base latched at arming (mn10200.cpp refresh_timer).
rtl/zoom/mn10200_periph.sv:60 out | ~dir, as MAME's write_port callbacks
rtl/zoom/mn10200_periph.sv:84 ------------------------------------------------------------------ interrupt priority MAME check_irq: the lowest level number below PSW.IM wins, ties to the lowest group (strict "<" while scanning groups 1 to 10).
rtl/zoom/mn10200_periph.sv:106 Values as MAME io_control_r; undecoded registers read 0.
rtl/zoom/mn10200_periph.sv:145 ------------------------------------------------------------------ timers Per timer: armed (counting from a prescaler) and the cnt down counter; TIMER_EXACT adds a prescale counter and the prescaler base latched at arming (MAME fixes the pe
rtl/zoom/mn10200_periph.sv:170 chain upwards: a cascaded timer is ticked when the one below underflows (MAME timer_tick_simple)
rtl/zoom/mn10200_periph.sv:176 does the chain above t fully underflow (MAME return value != 2)
rtl/zoom/mn10200_periph.sv:192 MAME device_reset: CPUM = 0x8000, then 0 to every register
rtl/zoom/mn10200_periph.sv:271 re-arm with the new cur (MAME simple_timer_cb -> refresh_timer)
rtl/zoom/tms57002.sv:2 Own implementation from docs/zoom_zsg2_tms57002_design.md and the TMS57002 User's Guide (TI 1992, "guide" below); MAME 0.288 (src/devices/cpu/tms57002 at tag mame0288) is used only where the guide is silent, and the comments say so.
rtl/zoom/tms57002.sv:160 Opcode numbers as in MAME's tmsinstr.lst.
rtl/zoom/tms57002.sv:210 Post increments apply to an operand the word references (MAME tms57kdec.cpp:15-30; the guide is silent; both programs set E or P only on referenced operands, docs/tms57002_rtl.md).
rtl/zoom/tms57002.sv:249 RND 1 rounds to 32 bits (bit 15, MAME tmsmake.py:48); RND 0 is 48 bits
rtl/zoom/tms57002.sv:279 secondary (category 2) results first: they use the old AACC and MACC and own the bus, so a primary reading the same operand sees them (guide p.4-2; MAME runs them first, tmsmake.py EmitCdec)
rtl/zoom/tms57002.sv:327 32-bit overflow sets AOV; ST1 bit 3 (MAME's AOVM, set by SAOM) saturates.
rtl/zoom/tms57002.sv:328 Bit 3 is "reserved" in Fig. 3-24 and SAOM / RAOM are not in the guide: MAME tmsmake.py:70 and tmsinstr.lst:549.
rtl/zoom/tms57002.sv:403 RS (p.3-34) plus MAME tms57002.cpp:76-102 for what the guide omits
rtl/zoom/tms57002.sv:420 MAME tms57002.cpp:40-74: PLOAD low restarts the download at ST0 and resets PC and CA; CLOAD low expects SA next.
rtl/zoom/tms57002.sv:467 Ignored while PLOAD is low (MAME tms57002.cpp:220; the guide is silent).
rtl/zoom/zoom_board.sv:22 Reset sequencing (taitogn.cpp:513-533, taito_zm.cpp:73-79): - zoom_reset is control bit 4 (gnet_fc).
rtl/zoom/zoom_board.sv:25 - On its falling edge MAME resets the taito_zoom device, so the ZSG-2, the TMS57002 and the MN10200 restart; the ZSG-2 and the TMS57002 are not held during the reset period (MAME) unless RST_LEVEL = 1 (the PCB's wiring is unknown, docs/zoom
rtl/zoom/zoom_board.sv:32 ZSG-2 register 0xB read (MAME 61c7940)
rtl/zoom/zoom_board.sv:35 MN10200 timers: 1 = MAME phase (verification)
rtl/zoom/zoom_board.sv:47 the lockstep testbench uses MAME's 32,552 Hz
rtl/zoom/zoom_board.sv:48 volume law: 0 MB87078, 1 MAME linear
rtl/zoom/zoom_board.sv:50 TMS57002: 0 the User's Guide (default), 1 MAME 0.288 (oracle)
rtl/zoom/zoom_board.sv:89 testbench: IRQ1 pin from tb_pin1 (MAME FC57)
rtl/zoom/zoom_board.sv:176 port 1 input: MAME's tms_ctrl_r returns the last value written (taito_zm.cpp:99-112), which is out | ~dir (mn10200.cpp:2080)
rtl/zoom/zoom_board.sv:250 A host byte (0xC00000) and a PLOAD/CLOAD change (port 1 bits 0 and 1) reach the DSP at the end of the writing instruction in virtual time, where MAME places every access (mn10200.cpp charges the cycles first): machine cycle cyc_cnt + acc_cy
rtl/zoom/zoom_board.sv:385 route gains 0.5 / 0.5 / 1 / 1 and SIM = 1 (taito_zm.cpp:205-208, tms57002.cpp:927-931)
rtl/zoom/zoom_bus.sv:3 Map (taito_zm.cpp:114-125, MAME 0.288): 0x080000-0x0FFFFF program flash U27, read only (program cache) 0x400000-0x41FFFF work RAM (32 KB on the PCB, mirrored; zoom_wram) 0x800000-0x8007FF ZSG-2, 16-bit (zsg2) 0xC00000 TMS57002
rtl/zoom/zoom_bus.sv:15 Before a ZSG-2 access the decoder asks the time base to tick any sample boundary that MAME would place before the access (zoom_tbase look_*), then waits a clock so the ZSG-2 has counted the tick.
rtl/zoom/zoom_host.sv:3 Addresses are offsets from 0x1F000000, the convention of gnet_fc and the zn bus (32-bit data, byte enables, req pulse, ack pulse with data): B80000 lane 0-1 reg_data_w (MAME taitogn.cpp:483, taito_zm.cpp:151-172) B80000 lane 2-3 reg_
rtl/zoom/zoom_host.sv:22 MAME (MAME_GAIN = 1): register 4 sets the left gain and 5 the right gain to (data & 0x3F) / 63, linear; the register number resets to 0 at the Zoom reset (taito_zm.cpp:73-79).
rtl/zoom/zoom_host.sv:81 MAME: round(32768 x d / 63)
rtl/zoom/zoom_host.sv:92 MAME m_reg_address
rtl/zoom/zoom_mbox.sv:6 MAME models it as a plain 256-byte shared RAM (taito_zm.cpp:88-96, 124; taitogn.cpp:487), and so does this block: a true dual-port RAM, one port per side.
rtl/zoom/zoom_mbox.sv:8 The collision arbiter is not modelled (Not Ready never reaches either CPU in MAME).
rtl/zoom/zoom_mix.sv:3 MAME routes the SPU to the speaker at 0.3 and the Zoom at 1.0 (taitogn.cpp:441-448); both streams are 16-bit full scale there (spu.cpp put_int(..., 32768); tms57002.cpp:933-936 puts so << 8 / 2^31, so the 16-bit SO1 word is full scale).
rtl/zoom/zoom_mix.sv:7 MAME's 0.3 was set by ear in 2018 (before: SPU 0.35/0.45 against Zoom 0.5, a ratio of about 0.9), and MAME's spu.cpp ignores the SPU main volume (0x1F801D80/82, spureg.mvol_l/r stored, never applied), which the games set low (Ray Crisis 0x1
rtl/zoom/zoom_mix.sv:11 So the SPU gain is selectable (spu_lvl, the shell's OSD "SFX level"): 0 = G_SPU (0.3, MAME), 1 = 0.45, 2 = 0.6, 3 = 0.9 (the pre-2018 MAME ratio), 4 = 1.2, 5 = 1.5, 6 and 7 = G_SPU.
rtl/zoom/zoom_out.sv:11 Gain: unsigned Q1.15 per channel from zoom_host (MB87078 law or MAME's linear law), applied as (s x g) >> 15, which cannot overflow 16 bits for g <= 32768.
rtl/zoom/zoom_pcache.sv:1 Taito Zoom board: MN10200 program cache for flash U27 (512 KB at 0x080000-0x0FFFFF, taito_zm.cpp:116-117), docs/zoom_board_design.md 4.
rtl/zoom/zoom_pcache.sv:18 The board sweeps while the Zoom is held in reset, which is the only time the main CPU writes U27 (MAME traces, all six games, docs/zoom_board_design.md 3.3).
rtl/zoom/zoom_tbase.sv:7 While the CPU is held in reset the cycles come from a real-time accumulator (the ZSG-2 keeps rendering in MAME while the MN10200 is held, taitogn.cpp:519-533).
rtl/zoom/zoom_tbase.sv:12 An external access of the MN10200 lands at the end of its instruction in machine time (mn10200.cpp charges every cycle before the access), so before a ZSG-2 access the bus asks look_req with the instruction's cycles; a boundary inside that
rtl/zoom/zoom_tbase.sv:26 MAME 0.288 computes the ZSG-2 stream rate as 25 MHz / 768 in integers, 32,552 Hz (zsg2.cpp:137), which is 6,250,000 / 32,552 = 192 + 16 / 32,552 cycles; the testbench uses that and loads the phase at each Zoom reset.
rtl/zoom/zoom_tmsfeed.sv:16 Host events (I5, docs/zoom_board_design.md 15): a TMS57002 host byte or a PLOAD/CLOAD change carries its time in slots (ev_slot = 2 x the machine cycle count at the end of the writing instruction, where MAME places the access).
rtl/zoom/zoom_wram.sv:3 The FC PCB carries one LH52B256 (32 KB, PLAN.md R7); MAME maps 128 KB at 0x400000-0x41FFFF (taito_zm.cpp:121).
rtl/zoom/zsg2.sv:2 Written from docs/zoom_zsg2_tms57002_design.md (sections 3 and 6.2) and the behaviour of MAME's zsg2.cpp (0.288 and commit 61c7940); status and verification in docs/zsg2_rtl.md.
rtl/zoom/zsg2.sv:14 The bus therefore sees the state MAME shows at the same sample position.
rtl/zoom/zsg2.sv:22 reg 0xB read = vol >> 3 (MAME 61c7940); 0 = MAME 0.288
rtl/zoom/zsg2.sv:30 Zoom reset: MAME device_reset semantics (zsg2.cpp:193-205)
rtl/zoom/zsg2.sv:40 outputs after each pass (out_valid one clock): sends 0-3 = reverb, chorus, left direct, right direct; si0-si3 = the TMS57002 serial input words as taito_zm.cpp:205-208 routes them (sends 0/1 at 0.5) with SIM = 1 (tms57002.cpp:927-931)
rtl/zoom/zsg2.sv:67 send gain table: 65535 * 10^(-(31 - i) / 20) truncated, entry 0 = 0 (MAME's -1 dB per step law, zsg2.cpp:148-154)
rtl/zoom/zsg2.sv:82 ramp byte to step: low nibble sign-extended, XOR 8, shifted left by the high nibble, truncated to 16 bits, arithmetic shift right 4 (zsg2.cpp:494-499)
rtl/zoom/zsg2.sv:93 one ramp step with clamp at the target (zsg2.cpp:501-510)
rtl/zoom/zsg2.sv:101 decode sample i of a block: 42222222 51111111 60000000 ssss3333, 7-bit value left-aligned in 16 bits, arithmetic shift right by s (zsg2.cpp:249-262)
rtl/zoom/zsg2.sv:115 position after the next block advance: cur + 1, or the loop point at the end; stop when loop + 1 >= end (zsg2.cpp:301-312).
rtl/zoom/zsg2.sv:116 Positions are 17 bits so that start - 1 wraps like MAME's 32-bit cur_pos.
rtl/zoom/zsg2.sv:139 registers: words 0-191 = channel ch registers 4w..4w+3 at {ch, w}; words 192-199 = control registers 0x00-0x1f (MAME m_reg)
rtl/zoom/zsg2.sv:268 register fields (zsg2.cpp:365-465)
rtl/zoom/zsg2.sv:429 ---------------- reset sweep (MAME device_reset) ----------------
rtl/zoom/zsg2.sv:481 ---------------- key on / key off (zsg2.cpp:518-554) ----------------
rtl/zoom/zsg2.sv:543 ---------------- one sample: the channel pass (zsg2.cpp:286-361) ----------------
rtl/zoom/zsg2_fetch.sv:10 32-bit blocks present (MAME m_mem_blocks)
README.md:25 The research behind the core, with the evidence for each subsystem and every known difference from MAME and from the real board, is in [docs/ACCURACY.md](docs/A
README.md:53 | Batch 2 (this release) | Other Type 1 card games and versions | Play testing on hardware, and a look at the interrupt quirk MAME works around for Kollon (V2.0
README.md:54 | Batch 3 (this release) | No Zoom board, Type 2 and CompactFlash cards, special controls | A first hardware test of each new feature, the same interrupt quirk
README.md:78 You need your own MAME 0.288 files.
README.md:87 MiSTer cannot read MAME's hard-disk CHD files, so each game's card is converted once on a computer.
README.md:88 With Python 3 and MAME's `chdman`:
README.md:91 python3 tools/gnet/gnet_tester_zips.py --roms <your MAME roms folder> --out <a new folder>
README.md:135 MAME gives no button names for these games and I have not found the game manuals, so the buttons are Button 1 to 3.
README.md:150 Batch 3 has two other control types, as MAME 0.288 maps them:
README.md:179 **SFX Level**: the PlayStation SPU's level in the mix against the Zoom board: 0.7 (the default, estimated from a recording of a real Psyvariar Revision cabinet)
README.md:185 Switch 4 is Test Mode (the operator manual says to use switch 4 only); switch 2 is the BIOS service mode in MAME; switches 1 and 3 are unknown.
README.md:204 **Loading is slower than on the board.** The CPU spends about 9.6 of its cycles on each main RAM load where the real chip needs about 7, so CPU-bound work runs
README.md:208 Screens after the loaders come 1.5 to 5 s later than in MAME.
README.md:209 **Sound balance.** MAME mixes the SPU at 0.3 under the Zoom board, a setting chosen by ear.
README.md:212 This release defaults to 0.7, estimated from one phone recording of a real cabinet (Psyvariar Revision); MAME's 0.3 is one of the SFX Level settings.
README.md:225 **Watchdog period.** The core uses 8 s where MAME uses 5 s; the board's real period is not known (the timing capacitor's value is not legible in any photo I hav
README.md:228 **Frame rate.** The core runs 59.817 Hz (3413 x 263 at 53.693175 MHz); MAME and a note from a real board give 59.826 Hz.
README.md:229 A cabinet recording agrees with MAME to about 0.3%, which cannot tell the two apart; a frequency counter on a board would.
README.md:241 **GPU rasteriser.** The PSX_MiSTer GPU matches the PS1 hardware test images of JaCzekanski's ps1-tests (Gouraud steps, blend mode 0, texture coordinates, edges,
README.md:245 **ZSG-2 voice readback.** The Zoom sound driver needs a 13-bit volume readback; MAME 0.288 returns 16 bits, which corrupts its voice allocator in every game, no
README.md:247 The core follows MAME's later fix (commit 61c7940).
README.md:249 **TMS57002 effects DSP.** The core follows the TI User's Guide on three points where MAME does not (multiplier input width, the coefficient update rule and the
README.md:253 **Watchdog.** Three games run a 2.5 million iteration delay loop with no watchdog kick (2.4 to 2.9 s in MAME, longer on the slower real CPU), so the board's wat
README.md:295 The MAME 0.288 sources used as the reference are not copied into the repository; `docs/mame_sources.md` links each one at the exact version, with its md5.
README.md:311 The MAME reference traces need MAME 0.288 and your own files; the trace scripts are in `tools/mame/`.
README.md:328 **MAME** is the behavioural reference for everything without a better source: the taitogn, zn and taito_zm drivers and the zsg2, tms57002, mn10200, psx, cat702,
README.md:332 The core follows superctr's later ZSG-2 fix (MAME commit 61c7940).

Says it matches, follows or was checked against MAME — 5

rtl/gnet/gnet_flash.sv:30 Erase blocks: TE28F160 64 KB; E28F400B bottom boot 16 KB, 8 KB, 8 KB, 96 KB, then 128 KB (28F400B5 datasheet; same as MAME).
rtl/zoom/tms57002.sv:22 Parameters select MAME 0.288 behaviour where it differs from the guide, for the bit-exact replay against MAME (sim/tms57002/tb.cpp): XM_CYCLES external RAM access length in slots: 6 = guide (DRAM, 8-bit port, 16-bit word: 2(m+1), p.3-
rtl/zoom/zoom_board.sv:395 TMS57002 parameters (docs/tms57002_rtl.md 5): the guide's behaviour by default; TMS_MAME = 1 selects the set that is bit-exact with MAME 0.288
README.md:60 In full-system simulation of the core, Ray Crisis, Psyvariar -Medium Unit-, XII Stag, Shikigami no Shiro and Night Raid boot from power-on through the BIOS, the
README.md:66 Taito Zoom music and effects (MN10200, ZSG-2, TMS57002), checked against MAME instruction by instruction and sample by sample.

Keeps a MAME approximation — 3

rtl/gnet/gnet_ata.sv:40 Access width follows each access (MAME's m_8bit_data_transfers hack: byte accesses move one byte of the sector buffer, 16-bit accesses two).
rtl/gnet/gnet_ctrl.sv:25 MAME uses 5 s, a guess.
rtl/gnet/gnet_flash.sv:41 zoom_release puts U27 and the wave chips into read array mode (MAME taitogn.cpp control_w: "assume that this also readies the sound flash chips"; no board evidence).

Shares text with the MAME driver without saying so — 1

rtl/gnet/gnet_flash.sv:42 taitogn.cpp control_w: "assume that this also readies the sound flash — shares text with sony/taitogn.cpp:529

Arcade-Tempest (blahm1dplays)#
Tempest
blahm1dplays/Arcade-Tempest_MiSTer @ b6636a42
MAME compared: atari/tempest.cpp + 2 related file(s)
Read: 17 HDL files, 6,215 lines (Quartus project)

blahm1dplays
repository only

Mostly MAME

low

41%

Statements: 2 toward hardware, 13 toward MAME, 1 not counted

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/tempest.vhd:15 Memory map transcribed from MAME atari/tempest.cpp main_map(): $0000-$07FF RAM (2K) $0800-$080F AVG colour RAM (write only) <- Tempest palette $0C00 IN0 (coins/tilt/selftest/diag + AVG-halt b6 + 3kHz b7) $0D00 DS — also in MAME: 2K atari/tempest.cpp:19, 4K atari/tempest.cpp:33, 4K atari/tempest.cpp:33

Says it was checked on “real hardware” — 2

README.md:13 confirmed on hardware via both the analog stick and a **USB mouse / spinner**
README.md:108 The path is confirmed on hardware with a **USB mouse** (which is how most

Cites MAME source — 9

Arcade-StarWars.sv:406 ===== Spinner -> 4-bit knob counter (t_spin) ===== MAME models Tempest's knob as a 4-bit (0x0f) up/down count read on IN1_DSW0[3:0] (atari/tempest.cpp: IPT_DIAL, FULL_TURN_COUNT 72, into POKEY1).
Arcade-StarWars.sv:554 IN0 (coins/tilt/service, active low): COIN1 = bit2 (MAME tempest)
rtl/avg/avg_tempest.vhd:199 Tempest STAT (MAME avg_tempest::handler_6): for the 0x60 opcode, instruction(11) selects colour-index latch vs intensity latch.
rtl/avg/avg_tempest.vhd:322 thanks to the mame source for this line.
rtl/avg/avg_tempest.vhd:326 The nibble {d3,d2,d1,d0} is active-low and maps to {G, B, Rhi, Rlo} (MAME avg_tempest::handler_7).
rtl/tempest.vhd:40 Math box is MiSTer-devel Arcade-BattleZone (behavioral model of MAME's Eric-Smith mathbox.cpp, BSD-3).
README.md:18 `games/mame/` folder.
README.md:159 **Dave Wood / fpgaarcade / alanswx** and the broader MiSTer/MAME communities — the Atari vector hardware lineage, T65, POKEY, math box, and reference models.
README.md:161 **MAME** — the authoritative Tempest memory map and hardware behavior.

Says it matches, follows or was checked against MAME — 2

rtl/mathbox.sv:85 Reading combinationally lets the poll release the instant the FSM is IDLE (status=$00, matching MAME mathbox.cpp status_r "always done").
rtl/pokey.vhd:318 POT read -- DIGITAL/BIMODAL model matching MAME's Tempest hookup.

Says it was translated, ported or taken from MAME — 2

rtl/tempest.vhd:15 Memory map transcribed from MAME atari/tempest.cpp main_map(): $0000-$07FF RAM (2K) $0800-$080F AVG colour RAM (write only) <- Tempest palette $0C00 IN0 (coins/tilt/selftest/diag + AVG-halt b6 + 3kHz b7) $0D00 DS
README.md:40 **6502 (T65)** CPU with Tempest's memory map, transcribed from MAME's `atari/tempest.cpp` — program ROM/RAM, vector RAM (4K) + vector ROM (4K), the 16-entry col

Arcade-ThePit (harlock74)#
The Pit
harlock74/Arcade-ThePit_MiSTer @ 8c932ffc
MAME compared: taito/roundup.cpp
Read: 32 HDL files, 2,618 lines (Quartus project)

harlock74
repository only

Mostly MAME

low

10%

Statements: 2 toward hardware, 7 toward MAME

Cites hardware documentation that MAME's driver does not — 1

README.md:9 Long-term goal: progressively improve the core through visual audits of schematic sheets and move it closer to a schematic-aligned implementation where possible

Says it was checked on “real hardware” — 1

README.md:58 High-score saving and restoration have been successfully tested on hardware within the accepted test scope.

Cites MAME source — 4

rtl/thepit_background.sv:1 SPDX-License-Identifier: GPL-3.0-or-later MAME-functional tile/sprite composition.
rtl/thepit_background.sv:54 Pinned MAME order, top first: high sprite, front solid, low sprite, transparent foreground, rear solid.
rtl/thepit_mainbus.sv:1 SPDX-License-Identifier: GPL-3.0-or-later Stage D MAME-functional CPU bus.
rtl/thepit_mainbus.sv:111 functional MAME default, not physical open bus

Says it matches, follows or was checked against MAME — 1

rtl/thepit_mainbus.sv:48 Configuration-time RAM contents match MAME's cold zero allocation.

Says it was translated, ported or taken from MAME — 1

README.md:7 Current status: functional behavioural implementation, mainly based on MAME/reference behaviour and available arcade hardware documentation.

Keeps a MAME approximation — 1

rtl/thepit_background.sv:95 MAME-COMPATIBILITY-APPROXIMATION: these eight digital primary colours are generated separately.

Arcade-Vamphalf (ppriest)#
Age Of Heroes - Silkroad 2, Boong-Ga Boong-Ga, Cool Minigame Collection, Date Quiz Go Go Episode 2 …
ppriest/Arcade-Vamphalf_MiSTer @ 975d4fb0
MAME compared: misc/vamphalf.cpp + 2 related file(s)
Read: 31 HDL files, 10,432 lines (Quartus project)

ppriest
repository only

Mostly MAME

medium

73%

Statements: 3 toward hardware, 139 toward MAME

Says it was checked against the original PCB — 1

README.md:205 MAME's `vamphalf.cpp`, `vamphalf_prot.cpp`, `qs1000.cpp` and `e132xs` are the reference, except for the QS1000's sound levels, which are set from and checked ag

Notes where it differs from MAME — 2

rtl/vh_eeprom93c46.v:109 MAME ignores a CLK edge at the same moment as the CS rise
README.md:35 Boong-Ga Boong-Ga: the Test menu's items can be used (Start to move, Right to select) (unlike MAME)

Cites MAME source — 135

Vamphalf.sv:3 Vamphalf (MAME misc/vamphalf.cpp): the driver's Hyperstone E1 boards; sets in scripts/build_mra.py SETS.
Vamphalf.sv:46 Rotation: Auto follows the set's MAME rotation from the mod byte (Mission Craft ROT90, Wivern Wings ROT270, the others ROT0).
Vamphalf.sv:230 MAME "common" P1_P2, active low: per player U D L R, buttons 1-4.
Vamphalf.sv:234 MAME's default keys (rtl/mame_keys.sv) ORed into the pads.
Vamphalf.sv:234 F2 is MAME's service switch (SYSTEM bits 3 and 4, IPT_SERVICE, momentary: PORT_SERVICE_NO_TOGGLE), on the pads' Service Mode bit (12); 9 is SERVICE1.
rtl/e1/e1_cpu.sv:1 Hyperstone E1-16 / E1-32 CPU core, written from MAME's interpreter (src/devices/cpu/e132xs/e132xs.cpp, e132xsop.hxx, e1defs.h; BSD-3-Clause, copyright-holders Pierpaolo Prazzoli and the MAME team).
rtl/e1/e1_cpu.sv:8 Behaviour follows the interpreter, including its quirks; each is marked "MAME:" where it is not what the ISA manual says.
rtl/e1/e1_cpu.sv:14 Not implemented: power-down, floating point (the FP opcodes trap to their emulation code as in MAME).
rtl/e1/e1_cpu.sv:271 MAME adjust_timer_interrupt: fire when TR has reached TCR and the interrupt is enabled
rtl/e1/e1_cpu.sv:307 MAME: a user-mode write that sets L is a privilege error (checked here, applied at commit)
rtl/e1/e1_cpu.sv:314 raw write: no side effects (MAME writes global_regs[] directly in several places)
rtl/e1/e1_cpu.sv:382 MAME: subtracts the halfword count, not bytes
rtl/e1/e1_cpu.sv:383 MAME: RET does not set P
rtl/e1/e1_cpu.sv:455 MAME: the interpreter sets ILC from this table once, before the first instruction after reset (get_instruction_length); the long-branch and 0xb0-0xbc entries are what MAME does
rtl/e1/e1_cpu.sv:886 MAME: RET with PC/SR source does nothing
rtl/e1/e1_cpu.sv:894 MAME: the loop runs after the exception entry, with the new frame pointer
rtl/e1/e1_cpu.sv:914 MAME: same-register and PC/SR sources do nothing
rtl/e1/e1_cpu.sv:979 MAME: tests src_code against SR even for a local source
rtl/e1/e1_cpu.sv:998 MAME: BCR, TPR, FCR and MCR read as zero
rtl/e1/e1_cpu.sv:1374 SETADR: the wrap carry goes into bit 9, as MAME's original comment says; MAME's code puts it in bit 0 (MAME_KLUDGES.md, CPU and I/O: mrkickera hangs with it)
rtl/e1/e1_cpu.sv:1707 MAME's get_lhs is the LOW half, get_rhs the HIGH half.
rtl/e1/e1_cpu.sv:1815 MAME: PC/SR as the pointer register does nothing
rtl/e1/e1_cpu.sv:1862 MAME: base update skipped when it is either destination register
rtl/e1/e1_cpu.sv:1946 MAME: when the pointer's own register-file slot is the target, the update adds to the stored value
rtl/e1/e1_cpu.sv:1976 MAME: STD.P reads the second source after the pointer update
rtl/e1/e1_cpu.sv:1978 MAME: updated before the store
rtl/e1/e1_cpu.sv:1985 MAME: skipped when the pointer is also a destination
rtl/e1/e1_pipe.sv:1 Hyperstone E1-16 / E1-32 CPU core, pipelined, written from MAME's interpreter (src/devices/cpu/e132xs/e132xs.cpp, e132xsop.hxx, e1defs.h; BSD-3-Clause, copyright-holders Pierpaolo Prazzoli and the MAME team).
rtl/e1/e1_pipe.sv:21 Behaviour follows the interpreter, including its quirks; each is marked "MAME:" where it is not what the ISA manual says.
rtl/e1/e1_pipe.sv:25 Not implemented: power-down, floating point (the FP opcodes trap to their emulation code as in MAME).
rtl/e1/e1_pipe.sv:337 MAME adjust_timer_interrupt: fire when TR has reached TCR and the interrupt is enabled
rtl/e1/e1_pipe.sv:379 MAME: a user-mode write that sets L is a privilege error (checked here, applied at commit)
rtl/e1/e1_pipe.sv:386 raw write: no side effects (MAME writes global_regs[] directly in several places)
rtl/e1/e1_pipe.sv:456 MAME: subtracts the halfword count, not bytes
rtl/e1/e1_pipe.sv:457 MAME: RET does not set P
rtl/e1/e1_pipe.sv:530 MAME: the interpreter sets ILC from this table once, before the first instruction after reset (get_instruction_length); the long-branch and 0xb0-0xbc entries are what MAME does
rtl/e1/e1_pipe.sv:723 D reads what the forwarding does not cover: LDW.S / STW.S (the frame slot through port 4; with them the other e1 subtype-3 N forms), extend (G14, G15 in ST_EXEC); and MOV from TR (e1_tb loads TR with MAME's value once the instruction before
rtl/e1/e1_pipe.sv:1013 MAME: RET with PC/SR source does nothing
rtl/e1/e1_pipe.sv:1022 MAME: the loop runs after the exception entry, with the new frame pointer
rtl/e1/e1_pipe.sv:1042 MAME: same-register and PC/SR sources do nothing
rtl/e1/e1_pipe.sv:1107 MAME: tests src_code against SR even for a local source
rtl/e1/e1_pipe.sv:1126 MAME: BCR, TPR, FCR and MCR read as zero
rtl/e1/e1_pipe.sv:1501 SETADR: the wrap carry goes into bit 9, as MAME's original comment says; MAME's code puts it in bit 0 (MAME_KLUDGES.md, CPU and I/O: mrkickera hangs with it)
rtl/e1/e1_pipe.sv:1843 MAME's get_lhs is the LOW half, get_rhs the HIGH half.
rtl/e1/e1_pipe.sv:2052 MAME: PC/SR as the pointer register does nothing
rtl/e1/e1_pipe.sv:2099 MAME: base update skipped when it is either destination register
rtl/e1/e1_pipe.sv:2183 MAME: when the pointer's own register-file slot is the target, the update adds to the stored value
rtl/e1/e1_pipe.sv:2213 MAME: STD.P reads the second source after the pointer update
rtl/e1/e1_pipe.sv:2215 MAME: updated before the store
rtl/e1/e1_pipe.sv:2222 MAME: skipped when the pointer is also a destination
rtl/mame_keys.sv:1 MAME's default keys (src/emu/inpttype.ipp) in hps_io's joystick layout, to OR into joystick_0/1: right, left, down, up at bits 0-3, buttons 1-6 at 4-9, Start, Coin, Pause, Service at the J1 line's own positions (parameters).
rtl/mame_keys.sv:7 P1 arrows, LCtrl LAlt Space LShift Z X, 1 start, 5 coin P2 R F D G, A S Q W E (MAME gives P2 no sixth key), 2 start, 6 coin F2 service (test) switch, 9 and 0 service coins 1 and 2, P pause alt (solitaire's PORT_CODEs, which replace P1's b
rtl/mame_keys.sv:27 MAME's Service 1, 2: wire to the board's SERVICE1/2 bits, if any
rtl/qs1000/vh_qs1000.sv:1 The QS1000 sound board as vamphalf.cpp and qs1000.cpp have it: an 8052 on the 24 MHz oscillator, its program and data in u7, a sound latch from the main CPU, and the wavetable engine reading the sample ROM from SDRAM.
rtl/qs1000/vh_qs1000.sv:5 8052 program 0x0000-0x7fff u7 (MAME maps only the first 32 KB; above reads 0xff) 8052 data 0x0000-0x00ff RAM 0x0100-0xffff u7[(bank * 0x7f00 + addr) mod 128 KB], bank = P3 bits 2:0 (MAME reloads u7 four times in its 512 KB region, s
rtl/qs1000/vh_qs1000.sv:22 mix balance: the PCB recording's, or MAME's (vh_qs1000_voice)
rtl/qs1000/vh_qs1000.sv:40 The 750 kHz tick is every 32nd enable, as MAME's 24 MHz / 32.
rtl/qs1000/vh_qs1000.sv:100 SD_SAMPLES holds the first 4 MB of MAME's 16 MB region, which is empty above 0x280000: lines past 4 MB read as zero without a request.
rtl/qs1000/vh_qs1000_voice.sv:1 QS1000 wavetable engine, as MAME models it (devices/sound/qs1000.cpp; scripts/qs1000_model.py is the same model in Python and the bench's reference).
rtl/qs1000/vh_qs1000_voice.sv:4 MAME runs the engine at 24 MHz / 32 = 750 kHz: per tick every playing voice outputs one sample (8-bit PCM, or OKI ADPCM decoded one nibble per address step), scaled by left/right and voice volume, and advances its address by an 18-bit-fract
rtl/qs1000/vh_qs1000_voice.sv:6 No envelope, no filter, no looping: a voice stops at its loop end (all as MAME, which marks them TODO).
rtl/qs1000/vh_qs1000_voice.sv:9 Register writes (0x200-0x211 of the 8052's data space, `wr_*`) and ticks (`tick`) enter one queue in arrival order and are applied in that order, so the output sequence is MAME's even when a key-on waits for its ROM reads; the engine catche
rtl/qs1000/vh_qs1000_voice.sv:19 mix_valid pulses once per tick with the left and right sums (before MAME's /4096); out_l/out_r are the 16-bit output, the mean of 16 ticks (46.875 kHz), clamped.
rtl/qs1000/vh_qs1000_voice.sv:30 1: the PCB recording's balance (the core); 0: MAME's (benches).
rtl/qs1000/vh_qs1000_voice.sv:54 a write arriving with a tick is queued a clock after it: it belongs to the next sample, as MAME applies a write stamped with the current tick before that tick's sample (the 8052 writes once in 28 clocks or more, so the held write is never o
rtl/qs1000/vh_qs1000_voice.sv:137 ---------------------------------------------------------------- ADPCM (okiadpcm.cpp)
rtl/qs1000/vh_qs1000_voice.sv:385 MAME: return
rtl/qs1000/vh_qs1000_voice.sv:392 descriptor (MAME start_voice): start = bytes 0-2, loop end = {byte 0 [7:4], byte 5 [3:0], bytes 6-7}; loop start unused
rtl/qs1000/vh_qs1000_voice.sv:469 after reset every voice is stopped, as MAME's device_reset
rtl/qs1000/vh_qs1000_voice.sv:503 MAME: ADPCM x4, PCM x1 (qs1000.cpp:484, :513).
rtl/qs1000/vh_qs1000_voice.sv:503 bal_pcb, the PCB balance (MAME_KLUDGES.md, Sound): ADPCM x2, PCM x4, PCM 18 dB higher against ADPCM than MAME has it
rtl/vh_cpumem.sv:4 Program space (vamphalf.cpp common_map / common_32bit_map, e132xs.cpp iram_4k_map): 0x00000000-0x001fffff work RAM, 2 MB SDRAM WRAM_BASE, through the caches 0x40000000-0x4000ffff sprite RAM vh_video spr_* 0x40010000-0x4003ffff
rtl/vh_eeprom93c46.v:3 93C46 serial EEPROM, 64 x 16 bits (MAME EEPROM_93C46_16BIT), as MAME's eeprom_serial_base_device / eeprom_serial_93cxx_device behave, the reference the game's boot is compared against.
rtl/vh_eeprom93c46.v:19 Writes and erases are refused while locked; the part powers up locked, as MAME's does.
rtl/vh_eeprom93c46.v:22 BUSY, as MAME's eeprom_base_device: a WRITE, ERASE, WRITEALL or ERASEALL that goes through holds the part busy for MAME's default times (the driver sets none): 1.75 ms, 1 ms, 8 ms and 8 ms.
rtl/vh_eeprom93c46.v:24 While busy, DO reads 0 in WAIT_FOR_START (MAME's do_read gives ready there) and a start bit is ignored.
rtl/vh_eeprom93c46.v:28 The contents are the 128-byte image MAME saves in nvram/<set>/eeprom, big endian words: load_we/load_addr/load_data write it (the .mra's default image, then the saved .nvm), rd_addr/rd_data read it back for the save, and `written` pulses wh
rtl/vh_eeprom93c46.v:36 MAME's defaults (eeprom.cpp); a driver may set its own
rtl/vh_eeprom93c46.v:64 The top holds blank from configuration until the ROM download starts, and the set's default image (MAME's "eeprom" region, ioctl index 2) is loaded during the download; the benches hold it through rst and load after.
rtl/vh_main.sv:3 I/O space (the port is the CPU's I/O address >> 13, e132xs.cpp m_read_io / m_write_io; MAME's I/O maps count in that unit: 16-bit words on the E1-16 (address shift -1), so 0x180 and 0x181 are two ports): Mission Craft (board 0, misncrft_io,
rtl/vh_main.sv:15 The YM2151 + M6295 boards (family 2 on, all E1-16), per their map in vamphalf.cpp: family 2 vamphalf_io: 0x030 OKI, 0x050/0x051 YM, 0x070 R EEPROM, 0x090 W flip (bit 7), 0x180 R SYSTEM, 0x181 R P1_P2, 0x182 W EEPROM family 3 coolmini_io:
rtl/vh_main.sv:36 The vertical blank interrupt is INT2, held until the CPU takes it: MAME's irq1_line_hold asserts input line 1, which the E1 numbers INPUT_INT2 (e132xs.h; ISR bit 1, inhibited by FCR bit 29).
rtl/vh_main.sv:51 active low, as MAME's P1_P2
rtl/vh_main.sv:52 active low, as MAME's SYSTEM bits 7:0
rtl/vh_main.sv:218 ---------------------------------------------------------------- I/O decode E1-16: 9-bit word address; E1-32: 13-bit space, dword entries (MAME's map address is io_port)
rtl/vh_main.sv:262 mrkickera_io (vamphalf.cpp:585-599) and finalgdr_io (:567-583), the same handlers at other ports; the sound chips and the inputs are on bits 15:8 and 31:16
rtl/vh_main.sv:276 aoh_io (vamphalf.cpp:658-665)
rtl/vh_main.sv:283 yorijori_io (vamphalf.cpp:683-693): the QS1000's latch on bits 15:8
rtl/vh_main.sv:295 aoh (vamphalf.cpp:990-1030): P1_P2 player 2 on bits 7:0, player 1 on 23:16; SYSTEM bits 0 COIN2, 1 START2, 4 EEPROM DO (active high), 5 SERVICE1, 16 COIN1, 17 START1, 20 the service mode switch
rtl/vh_main.sv:299 solitaire (vamphalf.cpp:1102-1131): P1_P2 bits 6:0 columns 1-7 (buttons 1-4, then xbtn 2:0), bits 11:8 Turn Up Card, Select Turned Up Card, Register, Gift (xbtn 6:3); SYSTEM is the common port's
rtl/vh_main.sv:302 boonggab (vamphalf.cpp:1032-1060): P1_P2 bit 0 START1, bits 2/3 left/right, bits 13:11 the photo sensors' strength code, boonggab_photo_sensors_r's 7 none ..
rtl/vh_main.sv:312 vamphalf.cpp common(): write and erase take 1 us (MAME_KLUDGES.md); the -all commands keep MAME's 8 ms
rtl/vh_main.sv:319 Wivern Wings' 0x1800 is a 16-bit handler on the 32-bit bus: MAME calls it once per half, in ascending address order, so a dword write is the high half's value, then the low half's (emumem_heu.cpp sorts the subunits by offset).
rtl/vh_prot.sv:1 The two boards' FPGA protection, as MAME models it (vamphalf_prot.cpp): a seed written one value per write, committed by 0xffff, looked up in a table of the seeds MAME has seen; an unknown seed gives 0.
rtl/vh_prot.sv:4 A write at position k clears, for every table entry, a "still matches" flag when the value differs from the entry's value k. At the commit an entry matches when its flag is set and at least as many values were written as the entry is long:
rtl/vh_prot.sv:11 A read at either gives bit 7-idx of the result as 0xffff or 0 and advances idx (0 from idx 8 on: MAME shifts by a negative count there, which x86 takes modulo 32).
rtl/vh_prot_wa.sv:1 World Adventure's FPGA protection as MAME models it (worldadv_fpga_prot_device, vamphalf_prot.cpp:318-419): 33 seed bits written one per access (bit 0), restarted by 0xffff; at the 33rd the seed is looked up among the seven MAME has seen, t
rtl/vh_prot_wa.sv:4 An unknown seed arms with the previous result, as MAME leaves m_retval unchanged.
rtl/vh_prot_wa.sv:5 MAME's notes put the seeds, in this order, at about 0:30 of play, then every 15 minutes to 2:00.
rtl/video/vh_video.sv:1 Vamphalf video: one layer of 16x16 8bpp sprites (MAME vamphalf.cpp draw_sprites), drawn per scanline.
rtl/video/vh_video.sv:23 16'h7fff for the 8 MB graphics ROM (MAME wraps codes by the element count)
rtl/video/vh_video.sv:61 one clock at the start of line 252, 240 on aoh (MAME's vblank callback)
rtl/video/vh_video.sv:103 flipped: MAME's visible area moves to 20..255; aoh's 180-degree turn of 16..239 puts it at 32
README.md:3 A MiSTer FPGA core for the Hyperstone E1-based arcade boards of MAME's `vamphalf` driver (Danbi / F2 System, SemiCom, Sun, Omega System, Logic), built with Quar
README.md:40 Kicker (SEMICOM-003b PCB) hanging when it rewrites its EEPROM and Yori Jori Kuk Kuk from booting without a CPU fix (PR for MAME too)
README.md:70 | Name | Year | Manufacturer | Set | Board | MAME trace | Notes |
README.md:77 | Yori Jori Kuk Kuk | 2002 | Golden Bell Entertainment | `yorijori` | E1-32, QS1000 | 439,730, then the timer interrupt's timing differs | MACHINE_NOT_WORKING i
README.md:86 | Mr. Kicker (SEMICOM-003b PCB) | 2001 | SemiCom | `mrkickera` | E1-32, YM2151 + M6295 | 1,000,000 of 1,000,000 | Clone of `mrkicker`. MACHINE_NOT_WORKING in MA
README.md:100 | World Adventure | 1999 | Logic / F2 System | `worldadv` | E1-16, YM2151 + M6295 | 1,000,000 of 1,000,000 | Protection: MAME's seven checks replayed, 0 differ
README.md:101 | Solitaire (version 2.5) | 1999 | F2 System | `solitaire` | E1-16, YM2151 + M6295 | 869,671, then a YM2151 status read differs (busy in MAME) | Eleven buttons
README.md:110 | Hyperstone E1-16T / GMS30C2116, E1-32T, 50 MHz | Main CPU | Written here (`rtl/e1/e1_cpu.sv`) from MAME's `e132xs`, multi-cycle, behind a 16 KB I-cache and a
README.md:112 | QS1000 (8052 + 32-voice wavetable) | Sound, QS1000 boards | 8052: jotego's JT8051, changed (`rtl/qs1000/PROVENANCE.md`); wavetable written here from MAME's `q
README.md:116 | Protection | Mission Craft, Wivern Wings, World Adventure | MAME's tables (`vamphalf_prot.cpp`): `rtl/vh_prot.sv`, `rtl/vh_prot_wa.sv` |
README.md:121 Source: MAME's `set_raw` (`vamphalf.cpp:156-161`, `:1150`).
README.md:150 MAME gives the boards no DIP switches; Service Mode is the test switch, momentary as in MAME (held, not toggled), and has no default pad button.
README.md:156 Solitaire has eleven buttons, with MAME's names: Column 1-7, Turn Up Card, Select Turned Up Card, Register and Gift.
README.md:167 **Age Of Heroes shows its sprites one frame later than MAME**: the core takes the sprite list at the start of the vertical blank, before the game rewrites it, b
README.md:171 The QS1000 follows MAME's model, which has no envelopes, filter or looping.
README.md:183 [ ] Video frames against MAME for the sets other than Mission Craft and Wivern Wings
README.md:205 MAME's `vamphalf.cpp`, `vamphalf_prot.cpp`, `qs1000.cpp` and `e132xs` are the reference, except for the QS1000's sound levels, which are set from and checked ag
README.md:211 CPU: `rtl/e1/e1_cpu.sv` agrees with MAME's interpreter after every instruction (PC, SR, all registers, every bus access), at 0 and 3 bus wait states, on Mission
README.md:215 Whole board (`sim/sys_tb`, the SDRAM controller and a chip model) against MAME's trace from reset: 1,000,000 of 1,000,000 instructions on `misncrft`, `coolmini`
README.md:218 `finalgdr` from a saved backup RAM: its first 2,091 backup RAM accesses as MAME's.
README.md:227 QS1000: the 8052 with the board's memories agrees with MAME's trace for 3,000,000 instructions per set (`sim/qs1000_tb`); the wavetable engine equals a transcri
README.md:233 The shot peaks at a median -2.9 dB of the recording's RMS (range -5.5 to -1.9 dB over 18 one-minute windows); MAME's balance gives -20.3 dB.
README.md:234 The core's balance (ADPCM x2, PCM x4: effects 18 dB higher against the music than MAME) gives -2.6 dB with the same measurement (`scripts/qs1000_stems.py`, `doc
README.md:237 SETADR: MAME puts the frame-wrap carry in bit 0 where its original source says bit 9.
README.md:237 With MAME's version Mr.
README.md:238 Kicker (SEMICOM-003b PCB) hangs whenever it rewrites its EEPROM (from blank, or after a damaged save), which is why MAME marks it not working; with the carry in
README.md:241 MAME's ROM patch for Yori Jori Kuk Kuk works around the same fault: with the carry in bit 9, MAME boots it unpatched.
README.md:243 YM2151 + M6295 against MAME's audio of `vamphalf`: correlation 0.971, RMS ratio 1.008.
README.md:244 Protection: Mission Craft's power-on check, 90 of 90 accesses as MAME; World Adventure's seven checks of a 2-hour MAME run, 0 differences.
README.md:252 The **MAMEdev team**: Angelo Salese, David Haywood, Pierpaolo Prazzoli and Tomasz Slanina (`vamphalf.cpp`), Philip Bennett (`qs1000.cpp`), Pierpaolo Prazzoli (`
README.md:270 | `debug` | reference captures from MAME used as ground truth (gitignored) |
README.md:271 | `roms` | your own MAME sets (gitignored, never committed) |

Says it matches, follows or was checked against MAME — 1

README.md:220 Video: the line engine renders 38 of 38 frames per set pixel-identical to a model of MAME's `draw_sprites`, which is pixel-identical to MAME on 342 of 342 captu

Keeps a MAME approximation — 3

rtl/vh_main.sv:303 0 strongest as the callback gives it (MAME's active-low field inverts it, which the game takes as a hit at rest: MAME_KLUDGES.md); buttons 1-4 give MAME's 1st, 3rd, 5th and 7th strengths (HACKS.md); bits 10:8 sensors 1-3 idle; SYSTEM bits 7
rtl/video/vh_video.sv:118 aoh never writes it and rewrites only part of the list, in lines 240..247 in MAME (docs/write_timing_mame.txt); its copy is taken at line 240, before that pass, so a pass the CPU has not finished cannot tear it: a frame later than MAME draw
README.md:207 Where the core follows MAME on something MAME marks as uncertain, it is listed in `docs/MAME_KLUDGES.md`; the core's own approximations are in `docs/HACKS.md`.

Arcade-WolfUnit (Kuba-J)#
Mortal Kombat 3, NBA Hangtime, NHL Open Ice: 2 on 2 Challenge, Rampage: World Tour …
Kuba-J/wolf-unit @ acf7fe7d
MAME compared: williams/midwunit.cpp + 6 related file(s)
Read: 5 HDL files, 1,667 lines (Quartus project)

Kuba-J
repository only

Mostly MAME

low

96%

Statements: 1 toward hardware, 17 toward MAME

Says it was checked on “real hardware” — 1

README.md:43 **Confirmed on a real cabinet.

Cites MAME source — 14

Arcade-SmashTV.sv:455 The MRA presents the 34010 maincpu region as its two raw 0x80000-byte EPROMs: [0x000000, 0x080000) u54 -> program-ROM LOW byte lane (34010 D0-7, EVEN) [0x080000, 0x100000) u63 -> program-ROM HIGH byte lane (34010 D8-15, ODD) Each 34010
Arcade-SmashTV.sv:667 MAME defaults: powerup test off, 2-player cabinet, CMOS coinage.
Arcade-SmashTV.sv:672 Rampage World Tour gospel: mame-gospel/midway/midwunit.cpp INPUT_PORTS_START(rmpgwt):437-527 (D:/deck/fpga/rampageworldtour/DRIVER-SPEC.md §4).
Arcade-SmashTV.sv:698 IN2 (midwunit.cpp:511-526): COIN1/2=bits0-1, START1=bit2, TILT=bit3, SERVICE (test toggle)=bit4, START2=bit5, SERVICE1(credit)=bit6, COIN3/4=bits7-8, START3=bit9, START4=bit10 (harness has 4 slots; only 3 players wired), VOL-=11, VOL+=12, I
Arcade-SmashTV.sv:713 DSW live idle value, per-field gospel defaults OR'd with the active-low IPT_UNUSED bits (an inactive active-low input READS 1), midwunit.cpp:466-508: CoinageSource=CMOS(bit0=0) | Coinage=USA-1(0x003E) | Counters=Two(bit6=0)
Arcade-SmashTV.sv:722 UMK3 gospel: mame-gospel/midway/midwunit.cpp INPUT_PORTS_START(mk3):136-215 (umk3 shares the "mk3" ioport tag per its GAME() macro).
Arcade-SmashTV.sv:756 DSW: gospel-exact MAME defaults (mame-gospel/midway/midwunit.cpp INPUT_PORTS_START(mk3): 166-213), NOT a blanket 0xFFFF.
Arcade-SmashTV.sv:769 The three IPT_UNUSED bits 8/11/13 are IP_ACTIVE_LOW (midwunit.cpp:196,203,207 = 0x2900) and an inactive active-low input READS 1, so the LIVE port value = 0xD47D | 0x2900 = 0xFD7D — exactly what MAME measures on every idle DSW read (mame-go
Arcade-SmashTV.sv:1015 rmpgwt = wunit_picemu serial 465 (midwunit.cpp:1767; dump 465_rampage_wt.u64).
Arcade-SmashTV.sv:1016 16-byte table captured live from MAME 0.280 (two fresh-NVRAM runs byte-identical): idx0..F = 5B 08 03 10 10 41 0D D7 61 7F 19 25 CD 69 09 8C, byte0 in [7:0].
Arcade-SmashTV.sv:1030 Preserve the Wolf ASIC/MAME completion cadence that feeds each game's software DMA queue.
rtl/wolf/wolf_game_inputs.sv:98 Defaults are MAME live values including inactive active-low unused inputs.
rtl/wolf/wolf_nvram_bridge.sv:5 The memory-side interface is byte-wide so the saved file is byte-for-byte compatible with MAME's 0x6000 little-endian u16 words.
README.md:88 **MAME** — *the MAME development team.* The behavioural reference this core was diffed against, line by line.

Says it matches, follows or was checked against MAME — 2

Arcade-SmashTV.sv:918 Standalone DCS bring-up must reproduce the board events captured by the bit-exact MAME trace.
rtl/wolf/wolf_gfx_interleave.sv:1 wolf_gfx_interleave.sv — combinational transform: linear MRA-part-stream byte address (as the 20 gfx chips arrive back-to-back, ordered u133,u132,u131,u130, u129,...,u110 -- matching sim/make_wolf_gfx_hex.py's GROUPS list) -> the correct by

Keeps a MAME approximation — 1

README.md:92 Without MAME this core is guesswork with a soldering iron.

CrazyClimber (RodimusFVC)#
Au, Bagman, Crazy Kong, Cannon Ball …
RodimusFVC/Arcade-CrazyClimber_MiSTer @ d14bba86
MAME compared: nichibutsu/cclimber.cpp
Read: 8 HDL files, 2,826 lines (Quartus project)

RodimusFVC
repository only

Mostly MAME

medium

92%

Statements: 8 toward hardware, 36 toward MAME, 1 not counted

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/cclimber_board.sv:1101 MAME: gradient[bank << 8 | flip << 7 | i] with a 3-bit bank, so only the low 2K of each 4K ROM is addressed — also in MAME: 2K nichibutsu/cclimber.cpp:58, 4K nichibutsu/cclimber.cpp:2880

Ships hardware documentation files — 8

Cites MAME source — 33

Arcade-CrazyClimber.sv:306 Per-game port layout and polarity (MAME INPUT_PORTS)
rtl/cclimber_board.sv:7 Video timing and scanout pipeline ported from Crazy Climber FPGA by Dar (darfpga@aol.fr, http://darfpga.blogspot.fr) Memory maps, opcode decryption and sound model per MAME cclimber.cpp (Nicola Salmoria)
rtl/cclimber_board.sv:350 Top Roller: 0000-3FFF from bank {Q6,Q5}, 4000-5FFF fixed (the slice MAME ROM_COPYs into every bank), C000-FFFF plain
rtl/cclimber_board.sv:369 Bootleg data-bus inverters (MAME init_rpatrol / init_ckongb / init_dking)
rtl/cclimber_board.sv:381 MAME init_cannonb: only 0000-0FFF, key picked by A9/A7
rtl/cclimber_board.sv:480 Le Bagnard: fixed 0x3F (MAME)
rtl/cclimber_board.sv:513 Le Bagnard: the mask gates an IRQ instead, held until acknowledged (MAME bagmanf_vblank_irq, HOLD_LINE)
rtl/cclimber_board.sv:588 Le Bagnard: Y flip draws the pair's other character with ITS attribute (MAME tile_index ^ 0x20)
rtl/cclimber_board.sv:625 Y flip (attr bit 7) swaps the two characters of a row pair, as the pair shares one attribute (MAME tile_index ^ 0x20)
rtl/cclimber_board.sv:717 Plane order follows the MAME "tile" region: first plane = pixel MSB
rtl/cclimber_board.sv:767 Swimmer draws sprites one pixel left of CC (MAME x vs x+1, flipped 240-x vs 242-x)
rtl/cclimber_board.sv:819 Visibility (MAME: only the lower-right quadrant of the 32x32 map) travels with the tile through the same pipeline stages as its pixels, so the window edge lands exactly on the map tile boundary
rtl/cclimber_board.sv:825 Top Roller: ctrl bits 4/5 are code bit 9 / priority, and the big sprite follows the screen flip (MAME toprollr_draw_bigsprite)
rtl/cclimber_board.sv:1000 MAME screen_update_toprollr: bg, then big sprite / sprites (ctrl1 bit 5 puts the big sprite on top), all clipped; the playfield goes over everything, unclipped
rtl/cclimber_board.sv:1049 CC resistor DAC: R/G 1K/470/220, B 470/220 (MAME compute_resistor_weights)
rtl/cclimber_board.sv:1063 Swimmer levels are binary weighted 0x20/0x40/0x80 (MAME swimmer_palette)
rtl/cclimber_board.sv:1072 Au xBGR_333: MAME pal3bit expansion
rtl/cclimber_board.sv:1088 Yamato character pens: 4-bit weights 0E/1F/43/8F; big sprite 3-bit 21/47/97 (MAME yamato_palette)
rtl/cclimber_board.sv:1097 Yamato gradient: 2 x 4K ROMs, bank {Q3,Q5,Q6}, bit 7 = flip, one entry per 2-pixel column (MAME screen_update_yamato)
rtl/cclimber_board.sv:1101 MAME: gradient[bank << 8 | flip << 7 | i] with a 3-bit bank, so only the low 2K of each 4K ROM is addressed
rtl/cclimber_board.sv:1272 A800-A807 LS259 (bagman.cpp): Q0-Q2 speech ROM bit select, Q3 start, Q4/Q5 ROM chip selects
rtl/cclimber_board.sv:1350 Speech added 1:1 to the CK mix (MAME bagman: AY 0.40, TMS5110 1.0), saturated
rtl/cpu/segacrypt/sega_315_5018.sv:24 MAME: if (src & 0x80) { col = 3 - col; xorval = 0xa8; }
rtl/ram_rom/rom_loader.sv:55 ioctl index 7 (Top Roller: banked 315-5018 CPU, 12 MHz board; best effort without schematics): 0x00000 - 0x0BFFF "user1" banks 0-2, 0000-3FFF of each (bank n = user1 n*0x6000) 0x0C000 - 0x0DFFF "user1" 0x4000-0x5FFF: the slice MAME ROM_CO
rtl/toprollr_video.sv:6 Behaviour per MAME cclimber.cpp (Nicola Salmoria); the 256x2 PROM at S9 is not emulated, as in MAME.
rtl/toprollr_video.sv:13 MAME x of the first displayed pixel of a line
rtl/toprollr_video.sv:14 MAME y rendered = displayed line + Y_OFS
rtl/toprollr_video.sv:125 MAME x being computed for the next output
rtl/toprollr_video.sv:156 MAME line being drawn
rtl/toprollr_video.sv:169 MAME toprollr_draw_sprites: x = spr[3], y = 240 - spr[2]; flip screen mirrors both and inverts the flips
rtl/toprollr_video.sv:273 MAME toproller_get_bg_tile_info: code {col[6], vram}, colour col[3:0], TILE_FLIPX; one X scroll for the layer
rtl/toprollr_video.sv:297 MAME clips background and sprites to x 40..231 (24..215 when flipped); the playfield is not clipped
README.md:13 Every board family in MAME's `cclimber.cpp` driver is supported, including the TMS5110 speech of Le Bagnard and the separate sound boards of Swimmer, Guzzler, Y

Says it matches, follows or was checked against MAME — 1

rtl/ram_rom/rom_loader.sv:3 Crazy Climber ROM loader ROM layout matched to MAME cclimber.cpp regions

Says it was translated, ported or taken from MAME — 2

rtl/cpu/segacrypt/sega_315_5018.sv:6 Port of MAME src/devices/machine/segacrpt_device.cpp (BSD-3-Clause; Nicola Salmoria, David Haywood).
README.md:58 DIP switches for every set, taken from MAME

Crystal (kyledlester)#
The Crystal of Kings, Evolution Soccer, Office Yeoin Cheonha, Top Blade V
kyledlester/BrezzaSoft_Crystal_System_MiSTer @ 94776940
MAME compared: misc/crystal.cpp
Read: 25 HDL files, 6,876 lines (Quartus project)

kyledlester
repository only

Mostly MAME

medium

71%

Statements: 1 toward hardware, 85 toward MAME

Notes where it differs from MAME — 1

README.md:109 The core differs from MAME in one place on purpose.

Cites MAME source — 83

rtl/cpu/se3208/se3208_cpu.sv:4 Behaviour: MAME se3208.cpp (c2334733) as documented in docs/SE3208.md, verified instruction by instruction against sim/reference/se3208_ref.h (sim/cpu).
rtl/cpu/se3208/se3208_cpu.sv:10 * Data port: one aligned 32-bit bus cycle per request with byte enables (d_be) and lane-placed data, exactly the accesses MAME makes: aligned 8/16/32-bit accesses are single cycles, unaligned 16/32-bit accesses are split into byte cycles in
rtl/cpu/se3208/se3208_cpu.sv:13 * Pacing: a new instruction starts only when `start_ok` is high (credit counter outside, MAME timing = one instruction per 6 clk_sys on average); `retire` pulses when an instruction (and its interrupt entry) is done.
rtl/cpu/se3208/se3208_cpu.sv:15 * Undecodable opcodes execute as NOPs like MAME but pulse `illegal` (simulation stops on it).
rtl/cpu/se3208/se3208_cpu.sv:235 branch condition, MAME flag semantics
rtl/cpu/se3208/se3208_cpu.sv:528 push PC (of the SWI itself, as MAME), push SR, clear ENI/E/M, PC = vector 0x10+n
rtl/cpu/se3208/se3208_cpu.sv:698 SWI: PC = vector (MAME: -2 then +2)
rtl/crystal/crystal_board.sv:4 SE3208 + VRender0 blocks + board glue (crystal.cpp main_map), with memory traffic leaving through abstract ports that carry *physical* addresses (docs/SDRAM_BANDWIDTH.md): phys[27] = 0: SDRAM byte address phys[24:0] (bank0 work RAM, bank
rtl/crystal/crystal_board.sv:15 protection PIC (Top Blade V: PIC16F628A, Office Yeoin Cheonha: PIC16F84A; others: none, MAME NO_DUMP)
rtl/crystal/crystal_board.sv:28 inputs (active low, MAME port layout)
rtl/crystal/crystal_board.sv:378 MAME master: PIC data line (b29) = !written b29 (undumped PIC never drives it) PIC data line (MAME crystal.cpp): the CPU writes !PIO bit 29, the PIC drives it from port A bit 0 when that is an output; both read it back (PIO external data bi
rtl/crystal/crystal_board.sv:381 Without a PIC (crysking, evosocc: undumped in MAME) only the CPU writes it.
rtl/crystal/crystal_core.sv:126 VRender0/CPU clock enable: Top Blade V programs its PLL for 80.013 MHz = 85.909 MHz * 95/102 (MAME topbladv machine); the screen keeps the 14.318 MHz crystal timing.
rtl/crystal/crystal_core.sv:163 ------------------------------------------------------------------ inputs (MiSTer joystick -> MAME ports) joystick bits: 0 right, 1 left, 2 down, 3 up, 4 B1, 5 B2, 6 B3, 7 B4, 8 start, 9 coin, 10 service
rtl/crystal/crystal_core.sv:182 Office Yeoin Cheonha (MAME INPUT_PORTS officeye): three players with Red / Green / Blue (buttons 1-3); P1_P2 b0/b2/b4 P2 R/G/B, b6 start 2, b16/b18/b20 P1 R/G/B, b17/b19/b21 P3 R/G/B, b22 start 1, b23 start 3; SYSTEM starts unused.
rtl/crystal/crystal_core.sv:191 Top Blade V (MAME INPUT_PORTS topbladv): two buttons per player, P3/P4 unused; SYSTEM b6 = test (service mode), b7 = service 1; coins are one-frame impulses (PORT_IMPULSE(1)).
rtl/crystal/crystal_ds1302.sv:4 Serial protocol and register/RAM behaviour as MAME machine/ds1302.cpp (Curt Coder, c2334733): command byte LSB first on SCLK rising edges, read data shifted out on falling edges, burst mode, write protect, 31 bytes of RAM, user copy of the
rtl/crystal/crystal_ds1302.sv:81 ce_w, then io_w, then sclk_w (MAME pioldat_w order)
rtl/crystal/crystal_ds1302.sv:119 MAME checks WRITE_PROTECT before every store (the control register too)
rtl/crystal/crystal_ds1302.sv:156 MAME: io_w stores the line even when CE is low; output follows the last driven value
rtl/crystal/crystal_ds1302.sv:159 MAME io_w: the shared line takes the written value (read back by PIOEDAT b28)
rtl/crystal/crystal_loader.sv:4 MRA streams (docs/ROM_LAYOUT.md), hps_io WIDE=1 (16-bit words, byte addresses): index 1 board record "CRYS", version, game id, flash banks index 254 DIP switches (MRA <switches>), byte 0 = DSW index 3 protection PIC firmware (MAME image
rtl/crystal/crystal_nvram.sv:13 File format = MAME's nvram/crysking/nvram: byte i = CPU address 0x01400000 + i (little endian).
rtl/crystal/crystal_pic16.sv:4 Behaviour: MAME src/devices/cpu/pic16x8x/pic16x8x.cpp (c2334733) through the reference model sim/reference/pic16_ref.h, instruction for instruction: the 35 instructions with MAME's flags and cycle counts (1; 2 for CALL/GOTO/RETURN/RETFIE/RE
rtl/crystal/crystal_pic16.sv:16 Board hookup (MAME crystal.cpp): port A bit 0 is the data line shared with the CPU's PIO bit 29; port A writes report the driven bits (porta_we, porta_val, porta_mask); the CPU holds the PIC in reset with PIO bit 30 (hold).
rtl/crystal/crystal_pic16.sv:31 firmware load (MAME image layout, 16-bit words: program at word 0, EEPROM at word 0x2100 + i)
rtl/crystal/crystal_pic16.sv:154 reading PORTB updates the RB7:RB4 change latch (MAME portb_r); also on a write to PORTB
rtl/crystal/crystal_pic16.sv:177 interrupt pending (MAME irq_active)
rtl/crystal/crystal_pic16.sv:189 MAME device_reset (power-on values of the registers MAME initialises at start are 0)
rtl/crystal/crystal_pic16.sv:205 MAME check_irqs: port B change detection, wake from sleep, interrupt entry
rtl/crystal/crystal_pic16.sv:229 F84A: 1K words, addresses wrap (MAME 10-bit space)
rtl/crystal/crystal_pic16.sv:249 ---------------- execute one instruction (MAME pic16x8x_device op_*)
rtl/crystal/crystal_pic16.sv:335 ---------------- register write (file destination); MAME store_regfile, SFR side effects
rtl/crystal/crystal_pic16.sv:358 MAME: inst+2, less this instruction
rtl/crystal/crystal_pic16.sv:433 ---------------- TMR0 (MAME update_timer after the instruction, internal clock)
rtl/crystal/crystal_prot_overlay.sv:1 BrezzaSoft Crystal System MiSTer core -- MAME-compatible protection overlay (game-specific, isolated).
rtl/crystal/crystal_prot_overlay.sv:5 MAME's init_crysking() (c2334733) writes the expected words into the flash region; this module substitutes exactly the same words into the download stream on its way to the volatile DDR3 flash store.
rtl/crystal/crystal_prot_overlay.sv:7 docs/PROTECTION.md Evolution Soccer (game id 2): the same mechanism for MAME's init_evosocc() (PIC "dgSMART-PR2" undumped), eight words in flash bank 2 (u16 offset 0x1000000 = byte 0x2000000).
rtl/crystal/crystal_texq.sv:4 Why: MAME renders each display-list packet almost as soon as it is queued (one per 1100 clocks), so by the time the CPU goes on to upload the next frame's sprite textures, the list it submitted has long been drawn.
rtl/crystal/crystal_texq.sv:11 How: CPU/DMA writes to texture RAM and the display-list queue-front updates (written by the CPU to the video registers) go through ONE ordered queue: * a texture write is applied to SDRAM only when the renderer has caught up with the queue
rtl/vrender0/vr0_render.sv:4 Behaviour: MAME video/vrender0.cpp process_packet / draw_quad / draw_quad_fill / do_alpha / do_shade (c2334733), docs/VRENDER0_VIDEO.md.
rtl/vrender0/vr0_render.sv:9 render state latch (MAME sticky / default rules) and palette load (256 RGB888 dwords -> RGB565 with MAME's collision nudge) 3.
rtl/vrender0/vr0_render.sv:11 pixel pipeline, one pixel per clock when the caches hit: P0 coordinates (x, y, tx, ty accumulators, MAME 32-bit wrapping arithmetic, clamp test) P1 tile-map word lookup (texture cache port A), linear offset P2 texel word lookup (texture cac
rtl/vrender0/vr0_render.sv:349 P6: blend products (MAME: (s * fsel(src) + d * fsel(dst)) >> 8 per channel, saturated)
rtl/vrender0/vr0_render.sv:437 render state (MAME process_packet)
rtl/vrender0/vr0_scanout.sv:4 MAME screen_update: pixel (x,y) = frame RAM word at display_dest + ((x & 0x3ff) | (y & 0x1ff) << 10) * 2, RGB565 expanded with MAME's pal5bit/pal6bit (bit replication).
rtl/vrender0/vr0_sound.sv:4 Behaviour: MAME sound/vrender0.cpp render_audio() (c2334733), docs/VRENDER0_AUDIO.md.
rtl/vrender0/vr0_sound.sv:5 For channels 0..MaxChn with Status and RS set, in order: read the channel words (vr0_sound_regs channel RAM), fetch one sample from frame or texture RAM, decode (u-law table, 8-bit, 16-bit), advance CurSAddr by DSAddr*div>>16, loop or stop
rtl/vrender0/vr0_sound.sv:11 Known approximation: EnvVol is kept as the 24-bit register image between samples (MAME keeps an s32); only envelopes that overflow 24 bits differ (KNOWN_ISSUES K5).
rtl/vrender0/vr0_sound.sv:52 u-law table (Evoga), MAME ulaw_to_16
rtl/vrender0/vr0_sound.sv:80 divider: div = 0x1E8000 / (clk+1) (MAME ((30 << 16) | 0x8000) / (num + 1)), or 0x10000 when num == 0
rtl/vrender0/vr0_sound.sv:223 MAME: cur_saddr += (ds_addr * div) >> 16 in C int arithmetic (32-bit wrap, arithmetic shift)
rtl/vrender0/vr0_sound.sv:252 MAME: the voice ended -> 'break' out of the channel loop for this sample (cur written back)
rtl/vrender0/vr0_sound.sv:255 volume (once) and the envelope stages, sequentially like MAME's level loop; each level takes two clocks (rate product, then add and target compare)
rtl/vrender0/vr0_sound_regs.sv:4 Behaviour: MAME sound/vrender0.cpp (c2334733), docs/VRENDER0_AUDIO.md.
rtl/vrender0/vr0_sound_regs.sv:5 Channel parameters live in a 32 x 16-word RAM (512 x 16) so the sample engine can read them in its time slot; the engine writes back the dynamic fields (CurSAddr, EnvVol, EnvStage) through port B. Read-back follows MAME bit for bit, includi
rtl/vrender0/vr0_sound_regs.sv:38 Channel registers: 32 channels x 16 words stored as the MAME channel_t::read() image, in block RAM: even and odd words in separate RAMs (a dword-aligned CPU access touches one of each), each split into byte lanes; port A = CPU, port B = sam
rtl/vrender0/vr0_sound_regs.sv:44 CPU-side channel word read-modify-write uses the stored read-back image; the stored image already has the MAME read masks applied (see wfix()).
rtl/vrender0/vr0_sound_regs.sv:65 MAME: m_status >> 4
rtl/vrender0/vr0_sound_regs.sv:144 ------------------------------------------------------------------ channel RAM (block RAM) reset-time fill with MAME's channel_t defaults (word 3 = 0x7100: ld = 1, env_stage = 1)
rtl/vrender0/vr0_sys.sv:5 Behaviour: MAME machine/vrender0.cpp (c2334733), docs/VRENDER0_SYSTEM.md.
rtl/vrender0/vr0_sys.sv:37 the written data as MAME passes it (unaccessed lanes 0)
rtl/vrender0/vr0_sys.sv:197 ---------------- interrupt latch (masked requests are dropped, as MAME)
rtl/vrender0/vr0_sys.sv:254 ---------------- CRTC derived geometry (MAME crtc_update), one cycle after a changing write
rtl/vrender0/vr0_sys.sv:286 external VCLK: MAME fatalerror; keep the previous geometry
rtl/vrender0/vr0_sys.sv:371 TCOL: not stored by MAME
rtl/vrender0/vr0_video_regs.sv:4 Behaviour: MAME video/vrender0.cpp (c2334733), docs/VRENDER0_VIDEO.md.
rtl/vrender0/vr0_video_regs.sv:30 minimum clocks between packet starts (MAME: 1100)
rtl/vrender0/vr0_video_regs.sv:116 packet completion (MAME pipeline_cb after process_packet)
rtl/vrender0/vr0_video_regs.sv:131 MAME processes a whole packet instantly (one per 1100 clocks), so its display list is always complete by vblank; this renderer draws pixel by pixel, so a flip also waits until the renderer has caught up with the list -- stopped at the flip-
README.md:37 | Game | MAME set | Year | Genre | Board | Status |
README.md:44 The protection microcontrollers of Top Blade V and Office Yeoin Cheonha are dumped (MAME), so the core runs their firmware on a PIC16 core of its own; The Cryst
README.md:52 | Game | MAME set | Year | Parent game | Status |
README.md:58 Each game uses MAME's input layout.
README.md:100 MAME's `crystal` driver (0.289) is the behavioural reference.
README.md:100 During development the core was compared against a C++ model of the MAME driver in simulation:
README.md:109 MAME's renderer finishes every display list instantly, so MAME can flip the frame at vblank no matter what.
README.md:139 Protection: the cartridge PIC has never been dumped, so the core applies the same small set of word substitutions MAME uses.
README.md:143 Sound: all 32 voices at MAME's 44.19 kHz sample rate, stereo, with an optional stereo mix.
README.md:158 The real CPU's per-instruction timing and the real renderer's speed are unknown; the core uses MAME's rates.
README.md:183 [MAME reference](docs/MAME_REFERENCE.md)
README.md:196 **MAME**: the `crystal` driver and VRender0 devices by ElSemi and Angelo Salese, the SE3208 CPU core by ElSemi and the DS1302 by Curt Coder are the behavioural
README.md:208 The reference model in `sim/reference` is derived from BSD-3-Clause MAME sources (see the file headers).

Says it matches, follows or was checked against MAME — 1

README.md:155 Sound matches MAME, which means the VRender0's reverb, ping-pong loops and sustain are not emulated (they are not documented anywhere).

Shares text with the MAME driver without saying so — 1

rtl/crystal/crystal_prot_overlay.sv:45 PUSH R7-R6-R5-R4-R3-R2 — shares text with misc/crystal.cpp:759

Galaga_TestBuild (RodimusFVC)#
Xevious, Bosconian - Star Destroyer, Dig Dug, Galaga …
RodimusFVC/Arcade-Galaga_MiSTer @ 5523eefe
MAME compared: namco/bosco.cpp, namco/digdug.cpp, namco/galaga.cpp, namco/xevious.cpp + 16 related file(s)
Read: 20 HDL files, 4,376 lines (Quartus project)

RodimusFVC
repository only

Both

medium

96%

Statements: 6 toward hardware, 94 toward MAME, 1 not counted

Cites hardware documentation that MAME's driver does not — 1

rtl/namco/namco_wsg3.sv:5 Per MAME sound/namco.cpp pacman_sound_w: 32 four-bit registers, voice 0 at 05 (waveform) / 10-14 (frequency, 20 bits) / 15 (volume), voice 1 at 0A / 16-19 / 1A, voice 2 at 0F / 1B-1E / 1F.

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/galaga_board.sv:424 Xevious planet map (MAME xevious_bb_r, schematic 9B): F000-F001 writes set BS0/BS1; reads return BB0/BB1 looked up through ROMs 2A (gfx4 0000), 2B (1000) and 2C (3000). — also in MAME: 9B namco/xevious.cpp:867, 2A namco/bosco.cpp:79, 2B namco/bosco.cpp:80, 2C namco/bosco.cpp:776

Ships hardware documentation files — 4

Notes where it differs from MAME — 1

rtl/cpu/mb88_sv/mb88_core.sv:31 NOT MODELLED — NONE are gaps (MAME doesn't model them for the default part, or no target device uses them): * STANDBY (stby_n pin): MAME has no standby/STOP state for mb88.

Cites MAME source — 84

Arcade-Galaga.sv:6 Built from MAME's galaga.cpp driver (Nicola Salmoria), with reference to Dar's (darfpga) Galaga core and the MiSTer arcade framework by Sorgelig
Arcade-Galaga.sv:243 MAME PORT_IMPULSE(2): a coin press is latched, then held for exactly two frames from the next vblank
Arcade-Galaga.sv:264 Rack Test cheat: held (MAME DIP with a key), or flipped on each press (MAME PORT_TOGGLE)
Arcade-Galaga.sv:303 Controls idle high (all active-low, MAME galaga.cpp) whatever the DIP bytes hold; only DIP switch bits come from them.
rtl/bosco_video.sv:6 Per MAME bosco.cpp (Nicola Salmoria).
rtl/bosco_video.sv:6 MAME's Bosconian screen is y 16-239, i.e. y = V counter; x 0-287 as the Galaga boards.
rtl/bosco_video.sv:30 video latch Q0 inverted (MAME): game flip
rtl/bosco_video.sv:59 MAME y (16-239)
rtl/bosco_video.sv:66 tile layers flip with the screen (MAME tilemap flip): fetch at the mirrored position
rtl/bosco_video.sv:162 Attribute: colour 5-0, bit 6 clear = flip x (MAME TILE_FLIPYX(attr >> 6) ^ TILE_FLIPX), bit 7 = flip y.
rtl/bosco_video.sv:276 Sprites (MAME draw_sprites): 6 entries, x = a[2n+1] - 2, y = 240 - b[2n], code = a[2n] >> 2, flips a[2n] bits 0 / 1, colour b[2n+1] & 3F, clipped to c < 224.
rtl/cpu/mb88_sv/mb88.sv:57 Generate it here: one ena_timer pulse per 32 `ena` machine-cycle enables — MAME mb88 burn_cycles /32 (full timer overflow = ÷8192 of `ena`).
rtl/cpu/mb88_sv/mb88_core.sv:6 Oracle: MAME cpu/mb88xx/mb88xx.cpp (opcode-for-opcode).
rtl/cpu/mb88_sv/mb88_core.sv:14 COMPLETE vs MAME mb88xx.cpp — opcode AND non-opcode.
rtl/cpu/mb88_sv/mb88_core.sv:16 OPCODES: all 256 bytes, verified byte-for-byte vs mb88xx.cpp execute_run() (0x00-2f individual; 0x30-3f sbit/rbit/tbit/rti/jpa/en/dis; 0x40-7f setD/ rstD/tstD/tba/xd/xyd/lxi/call/jpl/ai; 0x80-bf lyi/li/cyi/ci; 0xc0-ff jmp).
rtl/cpu/mb88_sv/mb88_core.sv:23 * Timer: internal (pio7, ÷32 prescale) OR external TC pin (pio6) per MAME increment_timer() (2026-07-11 + 2026-07-17 fixes).
rtl/cpu/mb88_sv/mb88_core.sv:29 * O-port PLA: 8-bit cf-nibble-select outO = MAME write_pla with pla_bits==8 (the device default; what the Namco 5xxx use).
rtl/cpu/mb88_sv/mb88_core.sv:34 * External-clock serial (pio 0x10/0x30): MAME fatalerror's it (unsupported).
rtl/cpu/mb88_sv/mb88_core.sv:40 0 = legacy 1-ce entry (51xx/52xx/53xx rely on it; the global MAME-exact change broke the 51xx and the main-CPU POST on 2026-09-19).
rtl/cpu/mb88_sv/mb88_core.sv:41 3 = MAME burn_cycles(3); the 54xx needs it or its IRQ handler reads the command latch before the 06xx byte lands (verilator/n54_cosim).
rtl/cpu/mb88_sv/mb88_core.sv:59 MAME's write_pla() ends with an unconditional `m_write_o(0, m_o_output, mask)` (mb88xx.cpp:373), so consumers that latch the O port (e.g. namco_51xx's shared mailbox = MAME m_portO) must re-latch on every write, not on a value change.
rtl/cpu/mb88_sv/mb88_core.sv:69 interrupt injection (harness drives from the MAME trace during bug hunt)
rtl/cpu/mb88_sv/mb88_core.sv:100 ---- SERIAL (2026-07-18; faithful to MAME mb88xx.cpp serial_timer()/pio_enable()) ---- 4-bit RECEIVE shift register clocked at clock()/SERIAL_PRESCALE(=6), armed when pio[5:4]==2'b10 (MAME's (m_pio & 0x30)==0x20 = internal serial clock).
rtl/cpu/mb88_sv/mb88_core.sv:104 sf blocks further shifting until tsts clears it; SBcount runaway-disables at THRESH (MAME anti-hang).
rtl/cpu/mb88_sv/mb88_core.sv:105 External-clock serial (pio 0x10/0x30) is unsupported by MAME (fatalerror) so we just don't tick.
rtl/cpu/mb88_sv/mb88_core.sv:106 SO/transmit is not modeled in MAME's mb88 either.
rtl/cpu/mb88_sv/mb88_core.sv:110 MAME SERIAL_DISABLE_THRESH
rtl/cpu/mb88_sv/mb88_core.sv:160 SP[] and ram[] intentionally NOT reset (MAME device_reset doesn't clear data RAM/stack; ROM inits RAM; Verilator zero-inits arrays).
rtl/cpu/mb88_sv/mb88_core.sv:166 MAME mb88xx.cpp: `if (m_ctr && !state && (m_pio & 0x40)) increment_timer(); m_ctr = state;` i.e. on a FALLING edge of the TC pin, if external-counter mode (pio bit6/0x40) is enabled, tick the SAME timer.
rtl/cpu/mb88_sv/mb88_core.sv:169 This drives the 51xx's per-frame timer, which MAME clocks from screen vblank (namco51.cpp vblank() -> MB88XX_TC_LINE).
rtl/cpu/mb88_sv/mb88_core.sv:174 Two mutually-exclusive sources feed the ONE counter (a chip uses internal OR external mode, never both): internal clock (ena_timer & pio7 = MAME 0x80), OR external TC falling edge (pio6 = MAME 0x40).
rtl/cpu/mb88_sv/mb88_core.sv:178 MCU-TIMER-FIX-2026-07-11: pio7 gate (MAME 0x80); TC-TIMER-FIX-2026-07-17: + external TC path (pio6/MAME 0x40)
rtl/cpu/mb88_sv/mb88_core.sv:185 ---- SERIAL receive engine (MAME serial_timer).
rtl/cpu/mb88_sv/mb88_core.sv:189 MAME SERIAL_PRESCALE=6 divides the MB88 PIN clock; `ce` is already pin/6 (MCU_CEN_DIV), so the /6 must not be applied twice.
rtl/cpu/mb88_sv/mb88_core.sv:197 MAME: SB = (SB>>1) | (si?8:0)
rtl/cpu/mb88_sv/mb88_core.sv:218 MAME clears all pending on take
rtl/cpu/mb88_sv/mb88_core.sv:226 outO: cf=1->oh, cf=0->ol (MAME write_pla 8-bit / VHDL).
rtl/galaga_board.sv:5 Memory maps, interrupt and custom-chip wiring per MAME galaga.cpp (Nicola Salmoria); video counters after Dar's (darfpga) Galaga core.
rtl/galaga_board.sv:58 Namco MCUs: 1.536 MHz pin clock, one machine cycle per 6 clocks (MAME MB8843 "internally divided by 6"), and mb88_core retires a cycle per enable -> 49.152 MHz / 192 = 256 kHz
rtl/galaga_board.sv:236 first vblank line is 240 (MAME line 224)
rtl/galaga_board.sv:307 address decode (galaga.cpp memory map; mirrors as in the CPU board decode table)
rtl/galaga_board.sv:409 Xevious CRTC (MAME xevious_vh_latch_w): register = A7-A4, value = A0 << 8 | data
rtl/galaga_board.sv:424 Xevious planet map (MAME xevious_bb_r, schematic 9B): F000-F001 writes set BS0/BS1; reads return BB0/BB1 looked up through ROMs 2A (gfx4 0000), 2B (1000) and 2C (3000).
rtl/galaga_board.sv:532 Dig Dug EAROM (ER2055, 64 x 8, per MAME er2055.cpp).
rtl/galaga_board.sv:589 sound CPU NMI: lines 64 and 192 (MAME), held for one CPU cycle while NMION (Q2) is low
rtl/galaga_board.sv:618 Xevious only: 06xx base tick anchored to MAME screen time 0 (raw x 0, y 0), so the per-frame 51xx poll ends before the main CPU's 50xx request.
rtl/galaga_board.sv:735 06xx clocked at MASTER / 6 / 512 (MAME: "should be hblank, but approx with 512"), NMI to the sub CPU; chip 0 = second 50xx, chip 1 = 52xx.
rtl/galaga_video.sv:5 Tile / sprite geometry and colour lookups per MAME galaga_v.cpp and digdug.cpp (Nicola Salmoria); counters after Dar's (darfpga) Galaga core.
rtl/galaga_video.sv:7 Coordinates below are MAME's raw (unrotated) screen: x 0-287, y 0-223.
rtl/galaga_video.sv:80 picture position for the sprite line buffer (OSD flip only) and for the tile layers (OSD flip XOR game flip: MAME flips tilemaps with the screen, but sprites only toggle their flip bits)
rtl/galaga_video.sv:193 Inside a tile: the game flip uses the hardware's x-flipped character set (code bit 7) instead of mirroring x (MAME: code | 0x80 with TILE_FLIPX); the Dig Dug playfield has no second set and simply mirrors.
rtl/galaga_video.sv:210 Galaga charlayout_2bpp: 16 bytes per char, x 0-3 in bytes 8-15, x 4-7 in bytes 0-7; plane 0 = bits 7-4, plane 1 = bits 3-0; codes 80-FF have the byte halves swapped (MAME init_galaga).
rtl/galaga_video.sv:280 resistor networks: R/G 1K, 470, 220; B 470, 220 (MAME galaga_palette).
rtl/galaga_video.sv:332 During each line the engine draws the NEXT line's sprites into the other half of the line buffer, in MAME's order (sprite 0 first, later sprites on top).
rtl/galaga_video.sv:357 MAME Galaga: sx = x - 40 + 256 * (xmsb & 3).
rtl/namco/namco_05xx.sv:5 Per MAME starfield_05xx.cpp (R. Hildinger): 16-bit Fibonacci LFSR (taps 16, 13, 11, 6), one step per pixel across a 256-pixel window of each of the 224 visible lines; a hit (state & FA14 == 7800) is a star of set {b10, b8} and colour ~{b4,
rtl/namco/namco_06xx.sv:5 Per MAME namco06.cpp.
rtl/namco/namco_06xx.sv:14 Control and data writes take effect one clock late, standing in for MAME's deferred (synchronized) writes.
rtl/namco/namco_06xx.sv:25 frame origin: puts the base tick on MAME's grid (ticks at screen time k / clock)
rtl/namco/namco_06xx.sv:36 R/W direction to chip 0 (MAME binds rw_callback<0> only)
rtl/namco/namco_06xx.sv:86 next timer edge at the next base tick (MAME ctrl_w_sync)
rtl/namco/namco_50xx.sv:5 Per MAME namco50.cpp.
rtl/namco/namco_51xx.sv:5 Per MAME namco51.cpp.
rtl/namco/namco_51xx.sv:5 The mailbox (MAME m_portO) is one byte written by both sides: a CPU write through the 06xx, or the MCU's own O-port output.
rtl/namco/namco_51xx.sv:26 R-port inputs (namco51.cpp input_callback<0..3>)
rtl/namco/namco_51xx.sv:85 MAME: TC asserted while not in vblank
rtl/namco/namco_52xx.sv:5 Per MAME namco52.cpp.
rtl/namco/namco_52xx_snd.sv:5 Per MAME galaga_a.cpp bosco_discrete CHANL4: the 52xx P0-P3 levels through a 4 V resistor DAC (100k / 47k / 22k / 10k), a 2nd-order 80 Hz high-pass (damping 1/0.3), a 2nd-order 2400 Hz low-pass (damping 1/0.9) and a gain of 0.25, at 48 kHz.
rtl/namco/namco_53xx.sv:5 Per MAME namco53.cpp.
rtl/namco/namco_54xx.sv:5 Per MAME namco54.cpp.
rtl/namco/namco_54xx.sv:58 MAME-exact interrupt entry timing, see mb88_core.sv
rtl/namco/namco_54xx_snd.sv:7 Per MAME galaga_a.cpp / polepos_a.cpp (DISCRETE_DAC_R1 -> DISCRETE_OP_AMP_FILTER BAND_PASS_1M), 48 kHz.
rtl/namco/namco_54xx_snd.sv:129 BOARD 0 output: 0.1 uF coupling into 100k (high-pass, MAME cAmp), then 40800 / 32768 * 0.90 per volt
rtl/namco/namco_54xx_snd.sv:167 clipped, as MAME
rtl/namco/namco_wsg3.sv:5 Per MAME sound/namco.cpp pacman_sound_w: 32 four-bit registers, voice 0 at 05 (waveform) / 10-14 (frequency, 20 bits) / 15 (volume), voice 1 at 0A / 16-19 / 1A, voice 2 at 0F / 1B-1E / 1F.
rtl/namco/namco_wsg3.sv:60 per 96 kHz sample: for each voice read its waveform at the current position, then advance the accumulator (only while its volume is non-zero, as MAME).
rtl/namco/namco_wsg3.sv:62 Sample = sum of (wave - 8) * volume; MAME scales by 1 / (128 * 3) and routes at 0.90 * 10 / 16 -> x 48 here.
rtl/namco/namco_wsg3.sv:84 MAME skips silent voices
rtl/xevious_video.sv:5 Per MAME xevious.cpp (Nicola Salmoria): background (2bpp, colour lookup), sprites (3bpp, colour lookup, drawn over the background), foreground text (1bpp, on top); palette = three 4-bit colour PROMs.
rtl/xevious_video.sv:7 Coordinates are MAME's raw screen: x 0-287, y 0-223.
rtl/xevious_video.sv:17 bootleg ROM bit order (MAME init_xevios)
rtl/xevious_video.sv:172 MAME tilemap scroll: source = screen + scroll - dx; background dx -20 / dy -16, foreground dx -32 / dy -18
rtl/xevious_video.sv:267 MAME draw_sprites: for each of 64 entries at 780 + 2n with sr3[1] bit 6 clear: code = sr3[0] (or (sr3[0] & 3F) + 100 when sr2[0] bit 7), colour = sr3[1] & 7F, flips sr2[0] bits 2 (x) / 3 (y), sx = sr1[1] - 40 + 256 * sr2[1] bit 0, sy = 223
rtl/xevious_video.sv:347 spritelayout_xevious: planes {plane-2 half + 4, 0, 4}; plane 2 for codes 80-FF is the high nibble of the stored byte (MAME init_xevious), codes 100-13F have none

Says it matches, follows or was checked against MAME — 4

rtl/cpu/mb88_sv/mb88_core.sv:75 PC of the executing instruction (matches MAME)
rtl/cpu/mb88_sv/mb88_core.sv:221 executing instruction's own PC (matches MAME)
rtl/cpu/mb88_sv/mb88_core.sv:305 jmp within page (INCPC-then-override, matches MAME)
rtl/ram_rom/rom_loader.sv:3 Galaga / Bosconian / Xevious / Dig Dug ROM loader ROM layout matched to MAME galaga.cpp regions

Shares text with the MAME driver without saying so — 6

rtl/bosco_video.sv:163 bit 6 clear = flip x (MAME TILE_FLIPYX(attr >> 6) ^ TILE_FLIPX), bit 7 = flip y. — shares text with namco/bosco.cpp:536
rtl/galaga_board.sv:735 06xx clocked at MASTER / 6 / 512 (MAME: "should be hblank, but approx with 512"), NMI to the sub CPU; — shares text with namco/bosco.cpp:379
rtl/galaga_video.sv:188 tilemap_scan: row += 2, col -= 2; cols 0-1 and 34-35 come from the side columns — shares text with namco/digdug.cpp:531
rtl/namco/namco_05xx.sv:8 {b10, b8} and colour ~{b4, b1, b0, b7, b6, b5} (BBGGRR). The rest of each — shares text with namco/starfield_05xx.cpp:264
rtl/namco/namco_05xx.sv:60 X speed: 4 + (0, 1, 2, 3, -4, -3, -2, -1) — shares text with namco/starfield_05xx.cpp:504
rtl/xevious_video.sv:60 bitswap<8>(v, 1,3,5,7,0,2,4,6) — shares text with namco/xevious.cpp:1095

Galaxian_TestBuild (RodimusFVC)#
Turtles, Mariner, Amidar, Anteater …
RodimusFVC/Arcade-Galaxian_MiSTer @ 9c080320
MAME compared: galaxian/galaxian.cpp, galaxian/galaxold.cpp, galaxian/scobra.cpp, galaxian/scramble.cpp + 13 related file(s)
Read: 50 HDL files, 17,022 lines (Quartus project)

RodimusFVC
repository only

Both

medium

43%

Statements: 8 toward hardware, 88 toward MAME, 7 not counted

Cites hardware documentation that MAME's driver does not — 2

rtl/galaxian_board.sv:90 [1] ROM 8000-87FF = ROM 4000-47FF (guttangts3_map), [2] Moon War dials on IN0 bits 4-0 (74LS161 count + direction, PPI 0 PC4 = 0 selects player 2), [3] Moon Shuttle (mshuttle_map latches A000-A007 / A800 / B000, opcode decryption, AY on I/O
rtl/galaxian_sound.sv:3 Galaxian / Moon Cresta discrete sound (Midway schematic page 22)

Cites hardware references or measurements that MAME's driver also gives — 7

rtl/galaxian_board.sv:486 Rack + Roll: extended I/O 20-3F = column tile banks; SN76489 at 1D (or on the data port) — also in MAME: 3F galaxian/galaxian.cpp:11356, 1D galaxian/galaxian.cpp:254
rtl/galaxian_board.sv:1212 Moon War (MAME dial_r): a 74LS161 per dial counts bars either way; bit 4 holds the last direction — also in MAME: 74LS161 galaxian/galaxian.cpp:180
rtl/galaxian_board.sv:1238 Scramble / The End protection (MAME theend_protection_w / _r, a PAL at 6J): nibbles written to PPI 1 port C shift through a 12-bit state; the low nibble is the operation. — also in MAME: 6J galaxian/galaxian.cpp:978
rtl/galaxian_kbsnd.sv:3 King & Balloon speech board (MAME kingball_sound_map / _portmap): Z80 at 2.5 MHz, 8K ROM at 0000-1FFF (A15-A14 ignored, 2000-3FFF open), no IRQs; any I/O read returns the command latch, any I/O write drives a 4-bit DAC from D7-D4. — also in MAME: 8K galaxian/galaxian.cpp:15590
rtl/galaxian_konami_snd.sv:6 Maps, timer and filter control per MAME galaxian.cpp (frogger_sound_map, konami_sound_map, konami_sound_timer_r, konami_sound_filter_w) and the nl_konami netlist (1K / 0.22uF / 0.047uF). — also in MAME: 1K galaxian/galaxian.cpp:9770, 0.047 galaxian/galaxian.cpp:924
rtl/galaxian_sound.sv:5 Noise is the star LFSR's N3A latched by 2V (7474 at 2D), as on the schematic; R40 at its schematic 2.2k. — also in MAME: 2V galaxian/galaxian_a.cpp:370, 2D galaxian/galaxian.cpp:14039
rtl/galaxian_video.sv:84 star LFSR N3A: the sound noise source (7474 at 2D) — also in MAME: 2D galaxian/galaxian.cpp:14039

Ships hardware documentation files — 6

Cites MAME source — 85

Arcade-Galaxian.sv:327 MAME PORT_IMPULSE(2): a coin press is latched, then held for exactly two frames from the next vblank
Arcade-Galaxian.sv:359 55-48 DIP byte 4 (MAME fake IN4 lines, Strategy X coinage)
Arcade-Galaxian.sv:360 47-40 DIP byte 3 (MAME FAKE port lines)
rtl/galaxian_board.sv:6 Memory maps per MAME galaxian.cpp.
rtl/galaxian_board.sv:56 [2] sound ROM 0000-2FFF (scramble.cpp), [3] Mariner protection reads (9008 = 03, B401 = 07, MAME init_mariner), [4] New Sinbad 7 on the Mars map (IRQ at VBLANK instead of NMI, ROM A000-AFFF, PPI 0 at C100, PPI 1 also C200), [5] flip latches
rtl/galaxian_board.sv:61 [0] program A3-A0 scrambled (MAME init_devilfsh), [1] 6801 = NMI enable (Mr.
rtl/galaxian_board.sv:62 Kougar), [2] PPI 1 port C reads 00, [3] no sound mute on control bit 4, [4] Hot Shocker ROM patch (2EF9 = RET, MAME init_hotshock), [5] Cavelon ROM banking (any 8000-FFFF access toggles 0000-1FFF), [6] AY on Z80 I/O 00 data / 01 address and
rtl/galaxian_board.sv:66 [0] Super Cobra (E) program XOR (MAME init_scobrae), [1] Super Bond (decode_superbon),
rtl/galaxian_board.sv:71 [0] Victory program decode (MAME decode_victoryc), [1] RAM 8000-87FF (Victory),
rtl/galaxian_board.sv:72 [2] Crazy Mazey program decode (MAME init_crazym), [3] Mighty Monkey program XOR (MAME init_mimonkey, table by A2-A0 and D7 / D2-D0), [4] Crazy Kong 256-byte block remap (MAME init_ckonggx), [5] opcodes 0000-0FFF from ROM 4000 (Lady Bug lad
rtl/galaxian_board.sv:79 [1] S2650 on a Scramble board (scramble.cpp hunchbks_map; INT and SENSE from VBLANK), [3:2] S2650 clock 0 = 1.536, 1 = 3.072, 2 = 0.768 MHz, [4] extended port 00 reads 1 at PC 002B / 0A27 (MAME hncholms_prot_r), [5] Driving Force (drivfrcg_
rtl/galaxian_board.sv:193 Galaxian (MAME galaxian_map): ROM, 4000 RAM (1K mirrored, 2K with bflags[1]), 5000 video RAM, 5800 object RAM, 6000/6800/7000 inputs, 7800 watchdog; latches on A2-A0 above 6000.
rtl/galaxian_board.sv:218 Kougar (scramble.cpp mars_map / mrkougar_map): the Scramble map with latches 6800-680F on A3-A0, PPIs 8100 / 8200 (port on A3, A1).
rtl/galaxian_board.sv:227 Stern type 2 (scobra.cpp type2_map): ROM 0000-7FFF, RAM 8000, objects 8800, video 9000, watchdog 9800, PPI 0 A000, PPI 1 A800 (port on A3-A2; Tazz-Mania 3 A1-A0), latches B000 on A3-A1 (Tazz-Mania 3 A3-A0).
rtl/galaxian_board.sv:433 S2650 plug-in board (MAME hunchbkg): one access per ack (every 12 pixels, 1.536 MHz / 3), replayed on the Z80 bus with its address moved onto the Galaxian map: ROM pages 0000 / 2000 / 4000 / 6000 (4K) -> 0000-3FFF, 1C00 RAM -> 4000, 1800 vi
rtl/galaxian_board.sv:447 INT latched at VBLANK, SENSE = VBLANK (inverted on Rack + Roll) // the NMI flip-flop's Q also drives INT (MAME hunchbkg: line 0, cleared by INTACK)
rtl/galaxian_board.sv:541 BMX Stunts: a 6502 at 1.536 MHz (MAME bmxstunts), each bus cycle replayed with the address moved onto the Galaxian map (0000-3FFF + 4000, ROM C000-FFFF = 0000-3FFF with A0 inverted, 8000 kept for the SN76489A); IRQ from VBLANK
rtl/galaxian_board.sv:586 MAME PCs 002E / 0297, as this core reports them
rtl/galaxian_board.sv:589 data port (REDD / WRTD) reads, keyed on the PC (MAME hexpoola / bullsdrtg_data_port_r)
rtl/galaxian_board.sv:818 NMI flip-flop: set at VBLANK, held clear while the enable latch is 0; watchdog = 8 frames (MAME)
rtl/galaxian_board.sv:826 New Sinbad 7 (MAME irq0_line_hold): IRQ from VBLANK until acknowledged
rtl/galaxian_board.sv:848 Fantastic (MAME init_fantastc): 1K block i of 0000-7FFF comes from 4K block lut[i], quarter i & 3
rtl/galaxian_board.sv:862 Zig Zag swaps ROMs 2000 / 3000 with the 7002 latch Cavelon (MAME init_cavelon): every access to 8000-FFFF flips the bank; bank 1 (power-on) = ROM 4000-5FFF at 0000
rtl/galaxian_board.sv:887 Crazy Kong encrypted bootlegs (MAME init_ckonggx): 256-byte blocks of 0000-57FF moved
rtl/galaxian_board.sv:911 Moon Shuttle opcodes (MAME mshuttle_decode): D7/D5/D3/D1 kept; table by {set, A0, D1, D7} and D6/D4/D2/D0
rtl/galaxian_board.sv:960 Moon Cresta program decryption (MAME decode_mooncrst): all of 0000-3FFF, or opcode fetches only (Moon Quasar)
rtl/galaxian_board.sv:983 Mighty Monkey (MAME init_mimonkey): rows 8-15 of the table repeat rows 0-7, so A9 drops out
rtl/galaxian_board.sv:1095 Victory (MAME decode_victoryc): XOR by A7 / A5 / A2 / A0, then D6 D3 D5 D4 D2 D7 D1 D0
rtl/galaxian_board.sv:1104 Crazy Mazey (MAME init_crazym): XOR chosen by D5-D3 of the stored byte and A0
rtl/galaxian_board.sv:1123 Super Cobra (E) (MAME init_scobrae): XOR by the low address bits (A6-A0, mirrored when A7), then inverted
rtl/galaxian_board.sv:1141 Jump Bug protection reads (MAME jumpbug_protection_r)
rtl/galaxian_board.sv:1153 Check Man (Japan) protection (MAME checkmaj_protection_r, keyed on the PC after the LD A,(3800) operand) and Dingo
rtl/galaxian_board.sv:1173 Check Man program decryption (MAME decode_checkman): per A2-A0, up to two data bits XORed with others
rtl/galaxian_board.sv:1192 PC-keyed protection reads (MAME pc() = the address after the instruction): an I/O read follows the instruction's last memory read, a memory read follows the one before it
rtl/galaxian_board.sv:1204 Scramble bootleg on Galaxian I/O (MAME scramblb_protection_1_r / _2_r)
rtl/galaxian_board.sv:1208 Triple Punch (MAME triplep_pip_r / _pap_r)
rtl/galaxian_board.sv:1212 Moon War (MAME dial_r): a 74LS161 per dial counts bars either way; bit 4 holds the last direction
rtl/galaxian_board.sv:1238 Scramble / The End protection (MAME theend_protection_w / _r, a PAL at 6J): nibbles written to PPI 1 port C shift through a 12-bit state; the low nibble is the operation.
rtl/galaxian_board.sv:1271 Scorpion (MAME zac_scorpion protection_r / _w): port C reads the bit count of state & CE29; a write with bit 5 low clears the state, with bit 4 low shifts in the inverted count's low bit
rtl/galaxian_board.sv:1314 Hustler / Billiard (MAME init_hustler / init_billiard): 0000-3FFF XOR-masked from A7-A0 (Billiard also shuffled)
rtl/galaxian_board.sv:1672 AC coupling approximated by the DC remover (as the Crazy Climber core); two AYs at half weight each (MAME 0.25)
rtl/galaxian_board.sv:1733 BMX Stunts SN76489A at 3.072 MHz, written with the data bits reversed (MAME snsnd_w)
rtl/galaxian_cclimb_snd.sv:4 Per MAME cclimber_a.cpp: a rising trigger starts at the AY port A address x 64, a 70 byte jumps to the port B address x 64, and each step lasts (256 - rate) ticks of the AY clock / 2 (256 kHz).
rtl/galaxian_dial.sv:3 Dial steps for Moon War (MAME IPT_DIAL, KEYDELTA 4): one pulse per quadrature bar, the direction held with it.
rtl/galaxian_dial.sv:36 D-pad: a step every third tick = 250 bars / s (MAME: 4 per frame)
rtl/galaxian_digitalker.sv:3 National Semiconductor MM54104 Digitalker (Scorpion), per MAME digitalk.cpp (Olivier Galibert, from Kevin Horton's analysis).
rtl/galaxian_digitalker.sv:10 The control flow follows MAME step for step; mode 3 addresses the ROM with the full 14 bits (MAME truncates its local address to 8 bits).
rtl/galaxian_digitalker.sv:37 MAME pcm_levels[v][i]
rtl/galaxian_digitalker.sv:165 MAME digitalker_control_w: cs, then cms, then wr
rtl/galaxian_kbsnd.sv:3 King & Balloon speech board (MAME kingball_sound_map / _portmap): Z80 at 2.5 MHz, 8K ROM at 0000-1FFF (A15-A14 ignored, 2000-3FFF open), no IRQs; any I/O read returns the command latch, any I/O write drives a 4-bit DAC from D7-D4.
rtl/galaxian_kbsnd.sv:6 The RAM MAME maps under the ROM is never readable.
rtl/galaxian_konami_snd.sv:6 Maps, timer and filter control per MAME galaxian.cpp (frogger_sound_map, konami_sound_map, konami_sound_timer_r, konami_sound_filter_w) and the nl_konami netlist (1K / 0.22uF / 0.047uF).
rtl/galaxian_konami_snd.sv:22 ROM 0000-2FFF (scramble.cpp scramble_sound_map), else 0000-1FFF
rtl/galaxian_konami_snd.sv:142 timer (MAME konami_sound_timer_r): the chain runs at 8x the CPU clock, period 40960
rtl/galaxian_konami_snd.sv:228 mute (control bit 4) and the inverting output amplifier Digitalker pins follow AY #3's port registers as written (MAME calls them from the port write callbacks)
rtl/galaxian_konami_snd.sv:260 Scorpion's third AY: unfiltered, at MAME's 0.25 against the board AYs' 0.33
rtl/galaxian_konami_snd.sv:268 the Digitalker (MAME 0.16) joins after the board's amplifier
rtl/galaxian_sbsound.sv:3 Space Battle (Hoei) discrete sound: MAME galaxian_a.cpp sbhoei_discrete
rtl/galaxian_sbsound.sv:5 The Galaxian pitch counter and fire circuit (as rtl/galaxian_sound.sv), three noise channels - the star LFSR's N3A latched on 2V (noise 3), 64H (noise 1, MAME's "128H" rate) and 4V (noise 2, "4V+8V") - each gated by an RC discharge into an
rtl/galaxian_sbsound.sv:262 noise channel k (s_noise / s_en bit k): RCDISC5 then the 1M band-pass (MAME biquad), clipped to the rails
rtl/galaxian_sbspeech.sv:3 Space Battle (Hoei) speech board, per MAME galaxian.cpp sbhoei_state: an 8039 at 4 MHz with a 2K program ROM, an SP0250 at 3.12 MHz.
rtl/galaxian_sndcpu.sv:5 Memory maps and interrupts per MAME galaxian.cpp (checkman_sound_map, checkmaj_sound_map).
rtl/galaxian_sound.sv:5 Circuit model and values from MAME galaxian_a.cpp (Couriersud).
rtl/galaxian_video.sv:5 Line buffer / tile merge logic from "FPGA GALAXIAN" by Katsumi Degawa (c) 2004; timing per the MAME galaxian_v.cpp hardware notes (Aaron Giles).
rtl/galaxian_video.sv:26 4 upper sprites (Kong), 5 Batman Part 2, 6 Moon Shuttle sprites, 7 Jump Bug, 8 sprites from the upper half of the planes (separate sprite ROM, Zig Zag), 9 Mighty Monkey (banks 0 / 2 above the tile and sprite codes), 10 Bagman (bank 0 = tile
rtl/galaxian_video.sv:43 Stern (MAME galaxold_v): [0] Rescue blue gradient background, [1] Minefield
rtl/galaxian_video.sv:49 galaxian.cpp: [0] Lost Tomb gfx address scramble, [1] Anteater gfx address
rtl/galaxian_video.sv:50 scramble (both undone on reads), [2] Anteater background (blue left of 56, right of 200 flipped, on bg_en), [3] Calipso sprites (8-bit code, no flips), [4] Moon Shuttle bullets (purple where H6 = 1, else a colour per 4 pixels), [5] tile / s
rtl/galaxian_video.sv:80 Bulls Eye Darts (MAME init_bullsdrtg): plane 0 bytes 0000-0007, 1000-10D7,
rtl/galaxian_video.sv:91 MAME resistor weights (1K/470/220 with 470 pull-down, RGB_MAXIMUM 224); stars at 150/100 ohm
rtl/galaxian_video.sv:133 Rescue / Minefield (MAME init_rescue / init_minefld): the ROM holds tile byte j at position i; read i -> fetch j
rtl/galaxian_video.sv:144 MAME decode_losttomb_gfx
rtl/galaxian_video.sv:150 MAME decode_anteater_gfx
rtl/galaxian_video.sv:166 Kougar (MAME mrkougar_charlayout / _spritelayout): a row is two bytes 8 apart, the byte at +8 holds pixels 0-3 (plane 0 in D7-D4, plane 1 in D3-D0) and the other pixels 4-7; store 0 fetches the +8 byte, store 1 the other
rtl/galaxian_video.sv:261 tile code extensions (MAME *_extend_tile_info); attr = the column's colour byte
rtl/galaxian_video.sv:347 sprite code extensions (MAME *_extend_sprite_info); attr = the sprite's colour byte
rtl/galaxian_video.sv:373 sprite RAM page (Time Fighter: MAME sprites_base = 40 | ((vpos + 16) << 2 & 300)) and the shell base
rtl/galaxian_video.sv:526 Scramble (MAME scramble_draw_stars): the field restarts every frame (no scroll) and a 555 (0.83 s) steps a blink state: 0 colour bit 5 only, 1 colour bit 3 only, 2 only when 2V, 3 all
rtl/galaxian_video.sv:551 tile / sprite merge through the same gates as the line buffer write (Degawa W_VID / W_COL) the second generator is drawn over the first and the tiles (MAME renders it last)
rtl/galaxian_video.sv:563 MAME mshuttle_draw_bullet colours 0-7 (entry 0 in the low bits)
rtl/galaxian_video.sv:575 Frogger river: blue left of H = 128 (right of it when flipped), per MAME frogger_draw_background
rtl/galaxian_video.sv:578 Stern backgrounds (MAME galaxold_v): gradients per column when enabled, Strategy X PROM x latches per 8 columns
rtl/galaxian_video.sv:585 Mariner (MAME mariner_draw_background / mariner_palette): column c shows user1[c + 1] (flipped [20 + 30 - c]), the last column 0; four bits of blue through 4.7K / 2.2K / 1K / 470
rtl/galaxian_video.sv:612 the Eagle harness sits on the monitor lines, so it swaps stars and shells as well (MAME swaps the palette only)
README.md:13 The goal is every set in MAME's Galaxian family of drivers.

Says it matches, follows or was checked against MAME — 1

rtl/ram_rom/rom_loader.sv:3 Galaxian ROM loader ROM layout matched to MAME galaxian.cpp regions

Says it was translated, ported or taken from MAME — 2

rtl/galaxian_sbspeech.sv:5 main CPU write: P1 bits 6-0 = D6-D0, INT asserted while D7 is set main CPU read: the 8039's P1 output latch P1 bit 7 in: the 8039's own P1 bit 7 P2 out: bank {P2.5, P2.2-0} of the 4K data ROM (256 bytes each, read by MOVX);
README.md:58 DIP switches for every set, taken from MAME

HardDrivin_cockpit (retrogarage)#
Hard Drivin'
retrogarage/harddrivin-mister @ ae9fe0d6
MAME compared: atari/harddriv.cpp + 12 related file(s)
Read: 62 HDL files, 26,231 lines (all HDL files: no Quartus project found)

retrogarage
repository only

Both

low

49%

Statements: 22 toward hardware, 44 toward MAME

Cites hardware documentation that MAME's driver does not — 22

rtl/harddrivin_milestone.sv:536 SP-327 sheet 8 low switch byte.
rtl/harddrivin_milestone.sv:1891 SP-327 sheet 3 divides the 32 MHz master by 16 four times and then toggles a 74LS74, producing the periodic 68010 IRQ at 244.140625 Hz.
rtl/harddrivin_milestone.sv:1912 Populated Compact-board priorities from the 74S148 encoder: periodic IRQ=5, GSP HINT=3, MSP HINT=1.
rtl/harddrivin_milestone.sv:2201 Atari ADSP board: 68010 window 0x800000-0x83ffff, ADSP-2100 core, data memory, sequential input EPROMs, double-buffered output memory, and the GINT interrupt to the 68010 (level 2 on the 74S148).
rtl/harddrivin_main_bus.sv:3 In addition to ROM and RAM, this implements the SP-327 NBUS control decoder and the direct GSP/MSP host windows.
rtl/harddrivin_main_bus.sv:5 The 74LS259 is unusual: A3:A1 select an output and A4 is the data bit, so its state is controlled entirely by the write address.
rtl/harddrivin_main_bus.sv:77 ADSP board window 0x800000-0x83ffff (sheet 1 decoder: A23:A18 = 100000).
rtl/harddrivin_main_bus.sv:212 SP-327 sheet 4: A23:A21=011 selects NBUS.
rtl/harddrivin_main_bus.sv:252 MAME hd68k_zram_w and SP-327 sheet 4 agree: the battery-backed zero RAM is writable only with ZP1 low and ZP2 high.
rtl/harddrivin_sound_board.sv:2 Hard Drivin' "driver sound" board (Atari 136052-1150 family).
rtl/harddrivin_sound_board.sv:10 Register semantics follow the schematics as documented by MAME's harddriv_a.cpp; everything runs on the 48 MHz core clock.
rtl/harddrivin_adsp_board.sv:6 68010 window 0x800000-0x83ffff (sheet 1 decoder 7B on A17:A15): 000 /PROGMEM 0x800000 8Kx24 program RAM, one 24-bit word per 32-bit longword (upper word carries bits 23:16) 001 /DATAMEM 0x808000 8Kx16 data memory, word address A13:A
rtl/harddrivin_adsp_board.sv:18 ADSP data-memory ports (sheet 2 decoders 7J/5K, DMA13=1, DMA2:0): 0x2000 read /SIMBUF sequential input EPROM word, counter post-increments 0x2001 write /SIMLD load the 16-bit sequential input counter 0x2002 write /SOMD sequential out
rtl/harddrivin_adsp_board.sv:25 The first RTL had 0x2001/0x2002 swapped, which left the polygon buffer empty -> BAD POLY BUFF ERROR.) 0x2003 write /SOMLD load the sequential output counter 0x2005 write /XOUT XFLAG <= DMD0 0x2006 write /GINT set DIRQ (68010 interru
rtl/harddrivin_adsp_board.sv:77 ---- Control latch (74LS259 7K), cleared by power-on reset ----
rtl/tms34010/tms34010_pkg.sv:355 On-chip I/O register file (1988 User's Guide Figure 6-1, page 6-3).
rtl/tms34010/tms34010_pkg.sv:453 FFFFFEE0h") and HSTCTLH (page 5507/4322).
rtl/tms34010/io/tms34010_io_regs.sv:6 Per the 1988 User's Guide Figure 6-1 (page 6-3), the GSP has 32 internal 16-bit registers occupying the bit-address range 0xC0000000-0xC00001FF.
rtl/tms34010/io/tms34010_io_regs.sv:54 Spec source: third_party/TMS34010_Info/docs/ti-official/1988_TI_TMS34010_Users_Guide.pdf Figure 6-1 (I/O Register Memory Map), §6 "I/O Registers".
rtl/tms34010/io/tms34010_io_regs.sv:654 Figure 6-1 reserves these locations.
rtl/tms34010/core/tms34010_decode.sv:112 This is the only MOVE that crosses register files (e.g. MOVE A0,B1 = 0x4E01, the object code in Figure 12-3).
rtl/tms34010/video/tms34010_display_addr.sv:87 User's Guide Figure 9-14 is explicit that the stored DPYADR field is decremented for both ORG values.

Cites MAME source — 44

HardDrivin.sv:99 ---- controls: MAME racedrivc port layout (the Compact set uses it) ---- MRA buttons (joystick_0 bits 4..11): Gas, Brake, Clutch, Abort, Gear down, Gear up, Key (start), Coin; bits 12..15 select gears 1..4.
HardDrivin.sv:155 bit 7 = SW1:1, 1 = off, MAME's port 0 high byte), byte 1 bit 0 = the DIAGN jumper (1 = off).
HardDrivin.sv:278 MAME declares the cabinet Key as momentary START1, without PORT_TOGGLE.
HardDrivin.sv:467 The force-brake transducer (8-bit ADC channel 6) reads 0xf0 released and falls to 0x20 under full pressure (MAME racedrivc 8BADC.6: MINMAX 0x20..0xf0, reversed, rest 0xf0 - the values MAME's saved calibration expects).
HardDrivin.sv:482 harddrivc uses MAME's racedrivc map: its ADC0809 channels 2..5 are physically unused; ordinary gear selection is the maintained digital port below.
HardDrivin.sv:516 MAME racedrivc a80000: bit 0 Abort, bit 1 Key, bit 2 aux coin, bits 8..11 gears 1st..4th (all active low); bit 14 = wheel edge (the bus).
rtl/harddrivin_compact_scanout.sv:98 MAME renders each line at its programmed HEBLNK inside one fixed frame viewport.
rtl/harddrivin_compact_scanout.sv:220 Exact MAME get_display_params + scanline_driver formula, in bytes: row=(effective DPYADR >> 4), col=((DPYADR & 0x7c)<<4)|DPYTAP.
rtl/harddrivin_cockpit_expander.sv:3 MAME hdgsp_vram_1bpp_w: each source bit enables one of sixteen bytes.
rtl/harddrivin_milestone.sv:292 MAME: L5 ~244/s from ~1.3 s, L1/L4 ~80/s from 2.7 s, L2 0.
rtl/harddrivin_milestone.sv:296 Page A7 65: the first seven HSTCTL values the 68010 READS from the MSP after the HLT release (MAME: 3800 3890 3810 3880 ...).
rtl/harddrivin_milestone.sv:297 Page A7 66: the first seven HSTCTLL values the MSP itself WRITES after release (MAME: 0090 0080 0000 ...).
rtl/harddrivin_milestone.sv:844 Reset only with the domain (rst_msp): the 68010 pulses the MSP core reset mid-download, which used to clear these counters (page 57 then showed only the post-pulse tail: 34723 words, exactly MAME's tail count).
rtl/harddrivin_milestone.sv:883 Page 66: the first seven CHANGES of the live HSTCTLL register value after release (either side may write it; MAME sequence 0090 0080 0000 0090 ...
rtl/harddrivin_milestone.sv:964 Three wait states per MSP RAM access: calibrated against MAME with the full 68010 host stream (tests/tb_harddrivin_msp_cosim.sv): the MSP's message hold time (HSTCTLL 0x0090 -> 0x0080) is 796 us with 3, 529 us with 0; MAME/real board ~790 u
rtl/harddrivin_milestone.sv:1109 The Compact ROM/MAME oracle writes F720/FFF5 here, forming PC=FFF5F720.
rtl/harddrivin_milestone.sv:1923 With an enable every 6 clocks (8 MHz) the boot timeline ran ~2.7x ahead of the real machine (MAME: first periodic tick 1.3 s, MSP release 2.70 s, GSP release 2.93 s; ours 0.60 / 1.00 / 1.06 s) and the game's bounded waits shrank accordingly
rtl/harddrivin_milestone.sv:1928 An enable every 16 clocks (3 MHz) brings the timeline to MAME's within ~5 %.
rtl/harddrivin_milestone.sv:2036 ADSP sequential-input EPROMs: MAME's user1 region is 16_BE with 10h at even bytes, so the ADSP sees (10h << 8) | 10k (index 0x41 = 0x0714).
rtl/harddrivin_main_bus.sv:195 The status word mirrors the board/MAME hd68k_snd_status_r: {mainflag, soundflag, 14'h1fff}.
rtl/harddrivin_main_bus.sv:234 MC68681 DUART at 0xff0000-0xff001f on the upper byte lane (MAME umask 0xff00).
rtl/harddrivin_main_bus.sv:240 Driver sound board latches (MAME harddriv_sound_board_device): 0x840000 data (main<->sound), 0x844000 status, 0x84c000 sound reset.
rtl/harddrivin_main_bus.sv:252 MAME hd68k_zram_w and SP-327 sheet 4 agree: the battery-backed zero RAM is writable only with ZP1 low and ZP2 high.
rtl/harddrivin_main_bus.sv:543 Movement that the game has not read remains invisible, exactly as on the board/MAME.
rtl/harddrivin_main_bus.sv:684 MAME hd68k_adc12_r returns the selected byte with ZEROS in the unused bits (the handler is mapped 16 bits wide).
rtl/harddrivin_main_bus.sv:754 MAME COMBINE_DATA: an upper-lane write does not replace the ADC control bits in the low byte on the cockpit board.
rtl/harddrivin_sound_board.sv:10 Register semantics follow the schematics as documented by MAME's harddriv_a.cpp; everything runs on the 48 MHz core clock.
rtl/harddrivin_adsp_board.sv:18 ADSP data-memory ports (sheet 2 decoders 7J/5K, DMA13=1, DMA2:0): 0x2000 read /SIMBUF sequential input EPROM word, counter post-increments 0x2001 write /SIMLD load the 16-bit sequential input counter 0x2002 write /SOMD sequential out
rtl/harddrivin_adsp_board.sv:36 MAC rounding rule of the ADSP-2100 core: 0 = manual 2.3.2.6 (default), 1 = MAME's variant (replay benches only, to stay word-exact with the oracle).
rtl/harddrivin_gsp_memory.sv:115 Ordinary VRAM accesses that fall inside the range covered by queued copies wait until the queue has drained, so the memory image is always the one MAME's immediate copies produce.
rtl/harddrivin_gsp_memory.sv:385 The Compact board (MAME harddriv_v.cpp hdgsp_write_to_shiftreg / hdgsp_read_from_shiftreg) uses them as whole-block copies: an MTR latches the source block, an RTM copies the block to the destination when the SHIFTREG latch (f4800000/f48000
rtl/harddrivin_gsp_memory.sv:401 MAME's m_gsp_vram is a 16-bit array (vram_mask = words - 1): normal VRAM block = word ((a - ff800000) >> 4) & ~255 = {a[21:12], 8'b0}, 256 words.
rtl/harddrivin_gsp_memory.sv:984 (posted writes captured before the RTM drain first so the copy lands after them, as MAME's immediate copy did).
rtl/harddrivin_gsp_memory.sv:1224 The ALS574 captures the DATA bus LAD3:0 on the SCROLL rising edge (MAME: finescroll = data & 7 on the MultiSync board).
rtl/adsp2100_core.sv:9 MAME was used only as a behavioral replay oracle.
rtl/adsp2100_core.sv:25 1: MAME-compatible variant (midpoint test on the shifted product only) used by the replay testbench to stay in lock-step with the oracle.
rtl/adsp2100_core.sv:29 1: MAME still pops the loop, PC and counter stacks when the termination condition is true (replay oracle behaviour, kept only for lock-step verification).
rtl/adsp2100_core.sv:357 MAME tests the midpoint on the shifted product and clears bit 16 of the rounded result (fitted to 400 recorded samples).
rtl/adsp2100_core.sv:795 MAME-compatibility only: pop the stacks on a true termination even though the explicit branch is taken.
rtl/tms34010/tms34010_system.sv:23 0: no DRAM refresh cycles on the local bus (a controller that refreshes its own memory, e.g. SDRAM, does not need them; MAME charges none)
rtl/tms34010/core/tms34010_decode.sv:2500 K is stored as its 1s complement: bit = 31 - K (SPVU001A 12-46; MAME BTST_K)
tests/tb_harddrivin_gsp_memory.sv:187 LAD is the multiplexed address/data bus and the latch changes during the data phase, so the register captures the write DATA (MAME: finescroll = data & 7); the address nibble is irrelevant.
tests/tb_harddrivin_gsp_memory.sv:433 inside block 3: the write waited for block 3's copy and landed after it (MAME order: RTM then write)
README.md:76 MAME was used as a behavioral reference during development.

HeavySmash (yaguboo)#
Heavy Smash
yaguboo/Arcade-HeavySmash_MiSTer @ 25d30f58
MAME compared: dataeast/hvysmsh.cpp + 6 related file(s)
Read: 28 HDL files, 8,197 lines (all HDL files: no Quartus project found)

yaguboo
repository only

Mostly MAME

medium

39%

Statements: 95 toward MAME

Cites MAME source — 85

third_party/cpu/amber_a23/a23_register_bank.v:85 Real silicon powers up with garbage and the game does not care (it saves and restores registers it has never written), but a golden comparison does: MAME starts them at 0, and the boot's first context save at 0x3B4B0 stored deadbeef where M
third_party/cpu/amber_a23/a23_register_bank.v:89 Zero here = deterministic on the board and byte-comparable against MAME.
projects/dataeast/heavy_smash/rtl/hs_top.sv:307 ---------------------------------------------------------------- sprite DMA The real DE-0385-2 latches the sprite list: the game writes spriteram throughout the first quarter of the frame, pokes 0x1D0000, then polls 0x1D0010 for completion
projects/dataeast/heavy_smash/rtl/hs_top.sv:325 MAME's frame-end snapshot sees the same bytes: writes after the first 25 % of the frame measured ZERO.
projects/dataeast/heavy_smash/rtl/hs_top.sv:351 The PCB copies ON the poke; the game polls 0x1D0010 for it, so the transfer is long enough to be worth waiting for, and MAME implements neither.
projects/dataeast/heavy_smash/rtl/hs_top.sv:357 A PCB would not show those; this and MAME both do.
projects/dataeast/heavy_smash/rtl/hs_top.sv:470 MAME shows the game reading 0xFFFFFFFF here (all inputs released, DO=1) -- tools/eepdump.lua.
projects/dataeast/heavy_smash/rtl/hs_top.sv:472 A BLANK 93C46 reads all ones, and that is the state the game expects to find on a fresh board: MAME fills an absent dump with ~0 (eeprom.cpp:216) and hvysmsh's dump is commented out.
projects/dataeast/heavy_smash/rtl/hs_top.sv:518 ---- bring-up liveness, second byte: the write/read strobes MAME's healthy boot produces in order (D1: ctl_w=18 by f3, vram_w=3840 by f3, oki0_r=1/frame).
projects/dataeast/heavy_smash/rtl/memory/hs_sdram.sv:71 The DE156's program ROM is 32 bits wide on the real board -- two 16-bit mask ROMs in parallel (hvysmsh.cpp's ROM_LOAD32_WORD pair) -- so an instruction there costs one ROM access.
projects/dataeast/heavy_smash/rtl/cpu/hs_de156.sv:4 This is the transform of references/upstream/mame/src/mame/dataeast/ deco156.cpp:43-124, factored so it can sit in the CPU fetch path.
projects/dataeast/heavy_smash/rtl/cpu/hs_de156.sv:24 deco156.cpp:47 -- addr = (a & 0xff0000) | 0x92c6; the index's bits 17:16 pass STRAIGHT THROUGH to the source address, only the low 16 bits are XOR-chained.
projects/dataeast/heavy_smash/rtl/cpu/hs_de156.sv:70 bitswap<32>(v ^ const, b31..b0) from deco156.cpp:90-119, result bit i = v'[b_i].
projects/dataeast/heavy_smash/rtl/cpu/hs_a23_mem.sv:14 Acking it performs the access twice -- the bench caught it on the second store of the boot: MAME writes 0x180000 then 0x120000, Amber-over-Wishbone wrote 0x180000 twice (sim/tb_amber_boot.sv, DEBUG_LOG D12).
projects/dataeast/heavy_smash/rtl/cpu/hs_bus.sv:2 Heavy Smash -- ARM bus decode (hvysmsh_map, hvysmsh.cpp:164-179)
projects/dataeast/heavy_smash/rtl/cpu/hs_bus.sv:9 Alignment rules follow MAME's mem_mask behaviour exactly: - 16-bit device areas (vram/rowscroll/spriteram/control) take the LOW halfword of a word or halfword write at offset +0 only; anything at +2 is dropped (mask &= 0x0000ffff makes it a
projects/dataeast/heavy_smash/rtl/cpu/hs_bus.sv:75 The game writes 0x1D0000 once a frame and then polls 0x1D0010 for completion -- hvysmsh.cpp maps the poll as nopr and calls it "Check for DMA complete?", and MAME implements no DMA at all, drawing instead from a frame-end snapshot of sprite
projects/dataeast/heavy_smash/rtl/cpu/hs_bus.sv:218 ---- CPU-side addresses for the shared BRAMs (combinational) --------------- Sizes are MAME's map, each window holding ONE 16-bit value per 32-bit slot (hvysmsh.cpp:155-162, :178): PF vram +0x10000-0x11FFF = 0x2000 bytes -> 0x800 words
projects/dataeast/heavy_smash/rtl/cpu/hs_bus.sv:239 MAME at the title screen has {_,_,_,_,_,8080,0080,0001}; we had {0080,0,...}.
projects/dataeast/heavy_smash/rtl/cpu/hs_bus.sv:241 Same fault as hs_video's rd_x, found the same way -- by diffing our tilegen state against MAME's (sim/tb_frame.sv write_vram vs tools/vramdump.lua).
projects/dataeast/heavy_smash/rtl/cpu/hs_arm2.sv:4 MAME instantiates it as `de156_cpu_device : arm2_cpu_device` with ARCHFLAG_MODE26 | ARCHFLAG_ONLY26 (arm7.h:638, arm7.cpp:2000) and FBNeo runs it on its 26-bit ARM2 core.
projects/dataeast/heavy_smash/rtl/video/hs_deco141.sv:4 hvysmsh config (hvysmsh.cpp:360-372): both layers 64x32, colour banks 0x00 (PF1 fg) / 0x10 (PF2 bg), colour mask 0xf, tile bank = (bankval & 0x70) << 8, 8x8 and 16x16 gfx share the ROM.
projects/dataeast/heavy_smash/rtl/video/hs_deco141.sv:8 Per line, per playfield, following deco16ic.cpp custom_tilemap_draw (:321-432), which covers plain / row-scroll / simultaneous row+col: src_y = (ly + scrolly) & hmask xbase = scrollx + rowscroll[src_y / row_type] per tile col: src_x = (xbas
projects/dataeast/heavy_smash/rtl/video/hs_deco141.sv:15 Tile word: code = w & 0xfff | bank; colour = w >> 12; bit 15 with ctl1[0]/[1] gives x/y flip and cuts colour to 3 bits (deco16ic.cpp:279-308).
projects/dataeast/heavy_smash/rtl/video/hs_deco141.sv:86 These cannot change inside a line anyway: MAME's control_w calls update_partial, and a tap over the whole attract shows every control write landing in the first 10% of a frame.
projects/dataeast/heavy_smash/rtl/video/hs_deco141.sv:103 hvysmsh.cpp bank_callback: (bank & 0x70) << 8, i.e. bankval[6:4] << 12.
projects/dataeast/heavy_smash/rtl/video/hs_deco141.sv:160 ---- logical ROM word for the fetch in flight ----------------------------- MAME's gfx_element does `code %= elements()`: the 16x16 decode has RGN_FRAC(1,2)/64 = 16384 elements and the 8x8 one 65536, so the 16x16 path keeps 14 bits of code
projects/dataeast/heavy_smash/rtl/video/hs_deco141.sv:210 ---- pixel nibble ------------------------------------------------------------- Derived from MAME's gfx_layout, not from prose (hvysmsh.cpp:285-304):
projects/dataeast/heavy_smash/rtl/video/hs_deco141.sv:289 ---- VRAM index ---------------------------------------------------------- The two tilemaps of a playfield are created with DIFFERENT mappers (deco16ic.cpp:229-233): the 16x16 one with deco16ic_device::scan_rows (:273-277) and the 8x8 one w
projects/dataeast/heavy_smash/rtl/video/hs_deco141.sv:418 PF2 is drawn with TILEMAP_DRAW_OPAQUE and PF1 without (hvysmsh.cpp:111-116), so PF2's pen 0 is a REAL colour -- colour*16 + 0 of its bank -- and not a hole.
projects/dataeast/heavy_smash/rtl/video/hs_deco141.sv:420 Writing it as 0 put palette entry 0 (black) under the whole screen: 51658 of 76800 pixels at the title screen, 67% of the picture, where MAME has 0x100/0x110/0x120.
projects/dataeast/heavy_smash/rtl/video/hs_deco141.sv:424 A disabled layer (control0 bit 7, deco16ic.cpp:585-600) draws nothing at all, and under PF2 that leaves bitmap.fill(0) showing: index 0 either way.
projects/dataeast/heavy_smash/rtl/video/hs_deco56.sv:4 decocrpt.cpp deco_decrypt, on the fly per 16-bit ROM word: phys_word = (i & ~0x7ff) | address_table[i & 0x7ff] word = bitswap16(sdram[phys] ^ xor_masks[xor_table[phys & 0x7ff]], swap_patterns[swap_table[i & 0x7ff]]) Table lookup takes
projects/dataeast/heavy_smash/rtl/video/hs_decospr.sv:4 Reference: MAME src/mame/shared/decospr.cpp, draw_sprites_common, the !m_alt_format path.
projects/dataeast/heavy_smash/rtl/video/hs_decospr.sv:5 That file is NOT in this factory's sparse MAME checkout by default -- src/mame/shared was missing, which is why the first version of this module was written without it.
projects/dataeast/heavy_smash/rtl/video/hs_decospr.sv:7 Add it with git -C references/upstream/mame sparse-checkout add src/mame/shared
projects/dataeast/heavy_smash/rtl/video/hs_decospr.sv:10 hvysmsh specifics (hvysmsh.cpp:104-118, 328-339): - pri_cb IS set, so MAME walks the list 0x7FC DOWN to 0 and draws through prio_transpen.
projects/dataeast/heavy_smash/rtl/video/hs_decospr.sv:26 prio_transpen sets `pmask |= 1 << 31` (drawgfx.cpp:933, "high bit of the mask is implicitly on") and its pixel op writes `priority = 31` for every non-transparent pixel (drawgfxt.ipp:216-226), so the next sprite over that pixel is dropped.
projects/dataeast/heavy_smash/rtl/video/hs_decospr.sv:30 The first entry of MAME's descending walk -- the HIGHEST spriteram offset -- keeps the pixel.
projects/dataeast/heavy_smash/rtl/video/hs_decospr.sv:112 MAME's own gate (ypos <= cliprect.bottom() && ypos >= cliprect.top()-16) is implied once the line is inside the stack AND visible, so it is not repeated.
projects/dataeast/heavy_smash/rtl/video/hs_decospr.sv:128 decospr.cpp:296-304.
projects/dataeast/heavy_smash/rtl/video/hs_decospr.sv:143 decospr.cpp:345: the double-wing partner is (sprite - m*inc) - mult2
projects/dataeast/heavy_smash/rtl/video/hs_decospr.sv:148 MAME's gfx has 65536 elements because RGN_FRAC(1,2) of the 8 MB region is 0x400000 bytes, but the upper half of each plane is the ROM_REGION gap and reads as zero -- a blank tile.
projects/dataeast/heavy_smash/rtl/video/hs_decospr.sv:159 ---- pixel nibble -------------------------------------------------------- Same gfx_layout as the tiles (hvysmsh.cpp:285-304, gfx_hvysmsh_spr uses tilelayout): planeoffset { half+8, half, 8, 0 } with planeoffset[0] as the MSB, xoffset { STE
projects/dataeast/heavy_smash/rtl/video/hs_video.sv:4 320x240 visible inside a 396x272 frame at 6.25 MHz pixel clock (100 MHz / 16) = 58.05 Hz refresh (MAME: 58 Hz, PCB note :467).
projects/dataeast/heavy_smash/rtl/video/hs_video.sv:6 MAME visarea is (0..319, 8..247); visible line = vcount - 8.
projects/dataeast/heavy_smash/rtl/video/hs_video.sv:13 Composition order (hvysmsh.cpp:104-118): PF2 opaque, sprites, PF1 transparent.
projects/dataeast/heavy_smash/rtl/video/hs_video.sv:95 IRQ: HOLD for the first 8 lines of blanking (~2 x MAME's 529 us, safe side), CLEAR at vcount 256 (hvysmsh.cpp:318-321 vblank_interrupt).
projects/dataeast/heavy_smash/rtl/video/hs_video.sv:102 MAME's screen is 320x256 with set_visarea(0, 319, 8, 247) (hvysmsh.cpp:350-353): the tilemap and the sprites are drawn into that 256-line bitmap and only rows 8..247 are shown, so the first visible line reads tilemap row 8 + scrolly, not sc
projects/dataeast/heavy_smash/rtl/video/hs_video.sv:106 Handing the renderers 0..239 put the whole picture 8 lines down; a (dx,dy) alignment search against MAME's own frame picked dy=-8 at every dx (77.2% at dx=-16 vs 69.1% at 0,0).
README.md:32 MAME 의 표준 ROM 세트를 그대로 읽습니다.
README.md:36 | MAME 세트 | 공식 명칭 | 상태 |
README.md:45 같은 MAME 드라이버 파일에 들어 있는 **World Cup Volley '95** (`wcvol95`, `wcvol95j`, `wcvol95x`) 는 지원하지 않습니다.
README.md:61 직접 마련한 MAME ROM 세트 zip 을 SD 카드의 `/games/mame/` 에 넣습니다.
README.md:63 zip 은 MAME 세트 이름 그대로 두고, 압축을 풀지 않습니다.
README.md:115 MAME 드라이버(`hvysmsh.cpp`)와 그것이 부르는 장치 소스(`deco16ic.cpp`, `decospr.cpp`, `deco156.cpp`, `decocrpt.cpp`, OKI, EEPROM, ARM 코어)를 먼저 옮겨 적고, 메모리 맵·클럭·인터럽트·화면·ROM 배치를 표
README.md:120 두 복호화 엔진은 실제 ROM 덤프를 MAME 의 변환과 대조해 확인했습니다 (복호 결과 0 번지가 ARM 부트 코드 `EA00000D`).
README.md:131 **2026-09-21 — CPU 교체, 그리고 MAME 와 같은 그림**
README.md:133 실기에서 CPU 가 이상하게 죽는 원인을 추적하다가, DE156 이 ARM7TDMI 가 아니라 **26 비트 ARM2** 라는 것을 확인했습니다 (MAME 는 `de156_cpu_device` 를 `arm2_cpu_device` 로, 26 비트 전용 플래그와 함께 만듭니다).
README.md:141 CPU+버스+EEPROM 이 부팅·초기화 전체에서 MAME 의 쓰기 스트림과 **172,594 건 전부** 순서·주소·데이터·폭까지 일치했습니다.
README.md:143 렌더러를 MAME 그림과 픽셀 단위로 대조하는 시뮬레이션을 만들어 결함 여러 개를 고쳤고, 어트랙트 6 프레임이 모두 **76,800/76,800 픽셀 일치**했습니다.
README.md:145 실기 화면도 MAME 프레임과 대조해 같은 그림임을 확인했습니다.
README.md:146 OKI 샘플 ROM 주소(두 번째 칩의 비트 회전 방향, 뱅크 크기)를 MAME 와 대조해 바로잡았습니다.
README.md:153 실기에서 게임이 MAME 의 약 0.55 배 속도로 돌았습니다.
README.md:162 BGM 이 MAME 와 다르게 들리던 원인은 볼륨이 아니라, 두 OKI 가 서로 다른 샘플레이트로 돌아 계단파의 재구성 이미지가 칩마다 30 배 차이 났던 것이었습니다.
README.md:164 칩별 선형 보간과 약한 프리엠퍼시스를 넣어 대역별 에너지 분포를 MAME 에 3.5 배 가깝게 맞췄습니다.
README.md:182 먼저 **MAME 팀**에 깊이 감사드립니다.
README.md:182 이 코어의 거의 모든 동작 — 메모리 맵, 두 단계의 암호화, 타일·스프라이트 포맷, 사운드 배선 — 은 MAME 개발자들이 수십 년에 걸쳐 분석하고 소스로 남겨 둔 지식 위에 서 있습니다.
README.md:184 실제 기판을 대신해 "정답 그림"과 "정답 쓰기 순서"를 내어 준 것도 MAME 였습니다.
README.md:188 https://github.com/mamedev/mame
README.md:202 jt6295 는 MAME 의 OKI 모델과 샘플 단위로 거의 완전히 일치했고, jt9346 은 그대로 끼워 넣기만 하면 됐습니다.
README.md:209 DE156·DECO 56 복호화의 상수와 표 (`deco56_*.hex`)는 MAME 소스의 데이터를 옮긴 것입니다.
README.md:212 참고한 MAME 소스
README.md:214 | MAME 파일 | 라이선스 | copyright-holders | 참고한 내용 |
README.md:216 | `src/mame/dataeast/hvysmsh.cpp` | BSD-3-Clause | Bryan McPhail | 드라이버 전체: 메모리 맵, 클럭, 인터럽트, 화면, 입력·EEPROM 포트, OKI 뱅크·사운드 게인, ROM 배치 |
README.md:217 | `src/mame/dataeast/deco156.cpp` | BSD-3-Clause | Bryan McPhail | DE156 프로그램 ROM 복호화 (주소 XOR 체인, 데이터 XOR·비트 순열) |
README.md:218 | `src/mame/dataeast/decocrpt.cpp` | BSD-3-Clause | Nicola Salmoria | DECO 56 그래픽 복호화 표 (주소·XOR·스왑) |
README.md:219 | `src/mame/dataeast/deco16ic.cpp` | BSD-3-Clause | Bryan McPhail | DECO 141 타일 생성기: 제어 레지스터, 타일 크기, 뱅크, 행·열 스크롤 |
README.md:220 | `src/mame/shared/decospr.cpp` | BSD-3-Clause | Bryan McPhail, David Haywood | DECO 52 스프라이트 리스트 포맷, 순회 순서, 우선순위 |
README.md:221 | `src/emu/drawgfx.cpp` | BSD-3-Clause | Nicola Salmoria, Aaron Giles | 투명 픽셀·플립 처리 규칙 |
README.md:223 | `src/devices/cpu/arm7/arm7.cpp` | BSD-3-Clause | Steve Ellenoff,R. Belmont,Ryan Holtz | DE156 의 아키텍처 플래그와 동작 차이 |
README.md:225 | `src/devices/machine/eeprom.cpp` | BSD-3-Clause | Aaron Giles | EEPROM 초기 상태와 동작 |
README.md:227 **FBNeo** (`d_deco156.cpp` 등) 는 MAME 에서 읽은 사실을 독립적으로 교차 확인하는 용도로만 읽었습니다 — 인터럽트 시점, 스프라이트 우선순위, 팔레트, 사운드 샘플 주소 처리 등.
README.md:252 메인 CPU 는 25 MHz 로 돕니다 (MAME 가 쓰는 28 MHz 의 약 89 %).
README.md:258 사운드 재구성(선형 보간 + 프리엠퍼시스)과 VBlank 스프라이트 복사는 MAME 의 결과에 맞춘 구현이며, 실제 기판의 회로를 그대로 옮긴 것은 아닙니다.

Says it matches, follows or was checked against MAME — 4

projects/dataeast/heavy_smash/rtl/hs_top.sv:252 Amber a23 + our memory front end; 40000 boot stores match MAME exactly (sim/tb_amber_boot.sv).
projects/dataeast/heavy_smash/rtl/hs_top.sv:345 It also matches MAME more closely, not less: MAME draws from a frame-END snapshot (screen_update), which is exactly what a vblank copy captures.
projects/dataeast/heavy_smash/rtl/hs_top.sv:349 EMULATION_DERIVED Matches MAME hvysmsh.cpp screen_update -- required for bring-up.
projects/dataeast/heavy_smash/rtl/video/hs_deco141.sv:105 Invisible until the attract reaches a screen that banks: frame 1800 (control 7 = 0x1101) matched 8.74% of MAME's picture with it and 100% without.

Shares text with the MAME driver without saying so — 6

projects/dataeast/heavy_smash/rtl/video/hs_deco141.sv:13 yy = (src_y + colscroll[0x200 + (src_x&0x1ff)/col_type]) & hmask — shares text with dataeast/deco16ic.cpp:390
projects/dataeast/heavy_smash/rtl/video/hs_deco141.sv:213 tilelayout planeoffset { RGN_FRAC(1,2)+8, RGN_FRAC(1,2), 8, 0 } — shares text with dataeast/hvysmsh.cpp:289
projects/dataeast/heavy_smash/rtl/video/hs_deco141.sv:214 xoffset { STEP8(8*2*16,1), STEP8(0,1) } — shares text with dataeast/hvysmsh.cpp:301
projects/dataeast/heavy_smash/rtl/video/hs_deco56.sv:5 phys_word = (i & ~0x7ff) | address_table[i & 0x7ff] — shares text with dataeast/decocrpt.cpp:618
projects/dataeast/heavy_smash/rtl/video/hs_decospr.sv:13 - set_flip_screen(true): "sprites are flipped relative to tilemaps". — shares text with dataeast/hvysmsh.cpp:106
projects/dataeast/heavy_smash/rtl/video/hs_decospr.sv:162 the MSB, xoffset { STEP8(8*2*16,1), STEP8(0,1) } so x=8..15 live in the — shares text with dataeast/hvysmsh.cpp:301

jtnslasher (blahm1dplays)#
Night Slashers
blahm1dplays/Arcade-NightSlashers_MiSTer @ 5ab3c06d
MAME compared: dataeast/fghthist.cpp + 14 related file(s)
Read: 144 HDL files, 26,950 lines (all HDL files: no Quartus project found)

blahm1dplays
repository only

Mostly MAME

medium

17%

Statements: 2 toward hardware, 90 toward MAME

Cites hardware documentation that MAME's driver does not — 2

source/cores/nslasher/hdl/jtnslasher_snd.v:21 Z80 sound map (nslasher_sound): 0000-7FFF ROM (audiocpu region, 64 KB) 8000-87FF RAM (2 KB, bundled in jtframe_sysz80, RAM_AW=11) A000-A001 YM2151 B000 OKI #1 C000 OKI #2 D000 sound latch read (also clears
source/cores/nslasher/hdl/jtnslasher_snd.v:97 8000-87FF RAM (jtframe_sysz80 internal)

Cites MAME source — 77

source/cores/nslasher/hdl/jtnslasher_vmem.v:50 runtime obj1 (gfx4 shadow) palette base bank (0x164008), MAME sprite2_color_bank_w
source/cores/nslasher/hdl/jtnslasher_vmem.v:76 ---------------- deco_ace RAM (alpha control 0x00-0x1f, fade regs 0x20-0x26) ---------------- MAME deco_ace.cpp: obj alpha = ace[0x00-0x05] via get_alpha(); fade = ace[0x20-0x26] (Build B).
source/cores/nslasher/hdl/jtnslasher_vmem.v:92 ===== RUNTIME COLOUR-BANK REGISTERS (0x164000/4/8) — deco32_v.cpp:56-70 ===== MAME implements these as LIVE registers (the 2009-era driver wrongly NOP'd them as "constants", which is why an attract capture looked static).
source/cores/nslasher/hdl/jtnslasher_vmem.v:215 MAME nslasher_draw_sprites reads buffered_spriteram (doc/mame_deco32.c:1582), a snapshot the hardware DMA-copies from live spriteram ONLY on the CPU write to 0x174010 (spr0) / 0x17c010 (spr1) (doc/deco32.c:886,891).
source/cores/nslasher/hdl/jtnslasher_vmem.v:279 FIX B: in JOINT-8bpp mode (pri[1]) MAME samples BOTH nibble sources at PF3's scroll (doc/mame_deco16ic.c custom_tilemap_draw:1014-1016 — one src_x/src_y for src0 and src1), so PF4's engine follows PF3's scroll registers while the mode is ac
source/cores/nslasher/hdl/jtnslasher_game.v:37 CANVAS REALIGN: MAME nslasher visible area = y[8..247] (MDRV_SCREEN_VISIBLE_AREA(0,319, 8,247)); ours was [0..239] = 8 lines too high -> top border shown, bottom credits clipped.
source/cores/nslasher/hdl/jtnslasher_game.v:83 nslasher has NO dipswitches (MAME nslasher input = EEPROM-configured); all game settings (coinage/difficulty/lives/demo sound) are set in the operator SERVICE MENU entered via the TEST switch.
source/cores/nslasher/hdl/jtnslasher_game.v:154 Full dec.bin RE + MAME count_exec proved the BOOT SIGNATURE: the attract engine arms ONCE at boot via routine 0x2150 (a start-gate).
source/cores/nslasher/hdl/jtnslasher_game.v:157 MAME golden exec: 2150=1, gate(0x21A8)=1, WAIT(0x21C8)=0, armRtn (0x21E4)=1, arm(0x48E4)=1.
source/cores/nslasher/hdl/jtnslasher_game.v:163 FLOOD_ROOT_CAUSE.md: the ARM re-runs reset (`b 0x50`@0xA48) ~once/frame because work-RAM 0x100014 bit3 reads SET on the cab where MAME keeps it 0.
source/cores/nslasher/hdl/jtnslasher_game.v:170 MAME GOLDEN = 0 for the whole nibble (w100014.txt: 0x100014 written twice, value 0x00000000, bit3 never set).
source/cores/nslasher/hdl/jtnslasher_game.v:243 **MAME GOLDEN = "F F 0 F F"** (reached gate, wait-loop NOT taken, armed).
source/cores/nslasher/hdl/jtnslasher_game.v:251 **MAME GOLDEN = 0.** Read the cab: row3 == 000000 -> 0x100014 edge byte stays 0 (HEALTHY; flood is elsewhere — recheck).
source/cores/nslasher/hdl/jtnslasher_game.v:364 Show the LIVE values of the three colour-bank registers (0x164000/4/8) that MAME uses for the tilemap + sprite palette bases and our RTL hardcoded.
source/cores/nslasher/hdl/jtnslasher_deco156.v:44 ---- BITSWAP32: result MSB-first = v[arg0..arg31] (MAME BITSWAP32 order) ----
source/cores/nslasher/hdl/jtnslasher_colmix.v:1 Composites 4 playfields + 2 sprite layers into 24-bit RGB per VIDEO_UPDATE(nslasher) (deco32_v.cpp mix_nslasher + deco_ace.cpp).
source/cores/nslasher/hdl/jtnslasher_colmix.v:102 deco_ace get_alpha (deco_ace.cpp:208-224): >0x20 -> 0x80 special ; else 255-(v<<3) clamp>=0
source/cores/nslasher/hdl/jtnslasher_colmix.v:111 mixAlphaTilemap flag (deco32_v.cpp:470-471): ace[0x17]!=0 && (m_pri&3).
source/cores/nslasher/hdl/jtnslasher_colmix.v:111 In JOINT-8bpp mode (pri[1], deco32_v.cpp:491-495) the alpha-tilemap BITMAP is never drawn — the combined PF3/4 layer + PF2-on-top replace the whole plain stack — so the mist blend and the front-PF holdout must NOT fire there.
source/cores/nslasher/hdl/jtnslasher_colmix.v:114 The raw flag still drives the obj0-pri2 on-top rule (mix_nslasher:363), which MAME applies in both modes (the empty alpha bitmap makes its blend a no-op, not the flag).
source/cores/nslasher/hdl/jtnslasher_colmix.v:134 ---- FIX B: JOINT-8bpp combined PF3/4 (pri[1]; deco32_v.cpp:491-495) ---- mix_callback (deco32.cpp:936-939): pen = ((p&0x70f) + (((p&0x30)|(p2&0x0f))<<4)) & 0x7ff with p/p2 = {colour_bank, colour, pen} of PF3/PF4 (runtime tm_bank0/1 <<8 — s
source/cores/nslasher/hdl/jtnslasher_colmix.v:140 OFFLINE GATE PASSED: ver/gfx/bio_render.py replays the captured Jake-bio frame (vancaps f03000; pri=6 there per the attract_pri.txt COMPLETE 0x150000 write log) through this exact formula -> 0/76800 vs MAME's own snapshot; the plain path re
source/cores/nslasher/hdl/jtnslasher_colmix.v:154 backdrop = pen 0x300 (deco32_v.cpp:476; was 0x200 = the green left line)
source/cores/nslasher/hdl/jtnslasher_colmix.v:157 PF2 on top (tag4, deco32_v.cpp:494)
source/cores/nslasher/hdl/jtnslasher_colmix.v:172 F3: MAME (deco32_v.cpp:364) draws obj0-pri2 ON TOP when mixAlphaTilemap, so the alpha foliage blends OVER the character (see-through), instead of the front PF dropping it.
source/cores/nslasher/hdl/jtnslasher_colmix.v:180 alpha1 (deco32_v.cpp:348)
source/cores/nslasher/hdl/jtnslasher_colmix.v:182 RUNTIME reg (0x164008, MAME sprite2_color_bank_w); hardcoding 3'h6 was the warm-shadow bug (base moves in-game)
source/cores/nslasher/hdl/jtnslasher_colmix.v:185 FIX C (mechanism G): obj1 ALPHA pri1 0/1 tilemap-side suppression (deco32_v.cpp:410-418).
source/cores/nslasher/hdl/jtnslasher_colmix.v:191 Shadows under foreground scenery (front PF) are now hidden exactly as MAME hides them.
source/cores/nslasher/hdl/jtnslasher_colmix.v:200 --- deco_ace obj alpha: aidx from obj1 colour, get_alpha LUT, gate by alpha1/alpha2 (deco32_v.cpp:390) ---
source/cores/nslasher/hdl/jtnslasher_colmix.v:220 ---- raw/faded select (deco_ace coloffs): sprite -> raw when pri[2]==0 ; PF -> faded ---- obj0 coloffs (deco32_v.cpp:352) = ~pri[2].
source/cores/nslasher/hdl/jtnslasher_colmix.v:221 obj1 coloffs (deco32_v.cpp:387) = ~pri[2] & sprite1_drawn, where sprite1_drawn = "obj0 drew at this pixel" = o0draw.
source/cores/nslasher/hdl/jtnslasher_colmix.v:227 MAME 0284 decodes the 8x8 chars at colorbase 0x800 (deco32.cpp:1884) and deco_ace maps pens 0x800-0xfff to the raw palette (deco_ace.cpp:181) -> PF1 is never touched by the ACE fade.
source/cores/nslasher/hdl/jtnslasher_colmix.v:229 The old "PF always read faded" premise was 2009-driver descent; visible on door-fades/scene fades where MAME keeps text full-colour.
source/cores/nslasher/hdl/jtnslasher_colmix.v:235 Front PF (pri tag4) alpha-blended last (deco32_v.cpp:443-456): p=frontpen ; alpha=get_alpha(0x17 + (front_colour>>1)) ; coloffs = obj1's ; gated by sprite pri.
source/cores/nslasher/hdl/jtnslasher_colmix.v:239 F2-FIX (nf14): MAME mist pen = pal2[coloffs | p].
source/cores/nslasher/hdl/jtnslasher_colmix.v:248 MAME: the alpha-tilemap/mist is drawn from tilegen[1]->tilemap_1_draw = PF3 (deco32_v.cpp:503) when pri[0]=1, and PF3 carries the runtime colour bank set_tilemap_colour_bank(0,(data&7)<<4) (=tm_bank0).
source/cores/nslasher/hdl/jtnslasher_colmix.v:260 FIX C (mechanism G) mist pen, 0284-faithful (deco32_v.cpp:443-456): p = alphaTilemap[x] is the front-PF PIXMAP value, which INCLUDES the tilemap colour bank — (tm_bank0<<8) for PF3 (runtime set_tilemap_colour_bank, boot-static =2) / 0x100 f
source/cores/nslasher/hdl/jtnslasher_colmix.v:264 The nf22-vs-nf12/nf18 foliage conflict is ARBITRATED (A3): the complete attract 0x164000 write log (mame-dump/vancaps/attract_pri.txt) shows tm_bank0 is written ONCE at boot (=2) and never moves -> MAME's foliage mist pen base IS 0x200; the
source/cores/nslasher/hdl/jtnslasher_colmix.v:267 Special moves were confirmed MAME-accurate at this pen shape on nf22.
source/cores/nslasher/hdl/jtnslasher_colmix.v:276 obj0 absent or low pri (deco32_v.cpp:450)
source/cores/nslasher/hdl/jtnslasher_colmix.v:278 FIX C (mechanism G): & ~pf1on — MAME mixes the alpha tilemap BEFORE drawing PF1 (deco32_v.cpp:517-519), so text renders OVER the fog and is never tinted by it.
source/cores/nslasher/hdl/jtnslasher_colmix.v:449 3rd read: mist pen (MAME pal2 base, F2)
source/cores/nslasher/hdl/jtnslasher_colmix.v:471 - If shadow + dialog now render DARK/correct on the cab => the entire fade FSM (pal_B/freeze/ resync/faded RAM) is the culprit (stale / never-runs / RAM-inference garbage on HW) => the fix is to DELETE it and fade INLINE on read (as MAME do
source/cores/nslasher/hdl/jtnslasher_dwnld.v:20 Proven END-TO-END by ver/gfx/verify_fold8_gateB.py (real .mra -> big-endian mra2rom -> this remap -> single-read model == MAME golden, 1495296/1495296 px) on top of the HW-proven nf4-dense identity model (raw lane-select p4, byte-exact on t
source/cores/nslasher/hdl/jtnslasher_snd.v:19 Z80B @ 3.58 MHz + YM2151 + 2x OKI M6295 (per MAME deco32.c).
source/cores/nslasher/hdl/jtnslasher_snd.v:107 IO-SPACE ROM WINDOW (audio-loop fix, 2026-06-09): MAME nslasher_io_sound maps the FULL 64 KB audiocpu ROM into the Z80 IO space (deco32.c:1016 `AM_RANGE(0x0000,0xffff) AM_ROM`).
source/cores/nslasher/hdl/jtnslasher_obj_fix.v:108 per-line sprite cap: MAME
source/cores/nslasher/hdl/jtnslasher_obj_fix.v:120 ---- effective tile + row from veff (vertical multi) ---- MAME: raw fx/fy (y&0x2000/0x4000) select the multi-tile order; the PIXEL flip passed to the draw is INVERTED (`if(fx)fx=0;else fx=1;`).
source/cores/nslasher/hdl/jtnslasher_obj.v:124 per-line sprite cap: MAME
source/cores/nslasher/hdl/jtnslasher_obj.v:136 ---- effective tile + row from veff (vertical multi) ---- MAME: raw fx/fy (y&0x2000/0x4000) select the multi-tile order; the PIXEL flip passed to the draw is INVERTED (`if(fx)fx=0;else fx=1;`).
source/cores/nslasher/hdl/jtnslasher_sdram.v:96 Byte-exact vs MAME spritelayout_5bpp per ver/gfx/verify_fold8_gateA.py (packing math) + verify_fold8_gateB.py (REAL loader: .mra -> big-endian mra2rom -> dwnld remap -> this read model).
source/cores/nslasher/hdl/jtnslasher_sdram.v:147 The old "no hwswap, proven 800/800" claim came from check_obj1_unpack.py whose golden used a WRONG region model (16-bit interleaved, 2009-driver style); pinned mame0284 loads gfx4 PLAIN SEQUENTIAL (deco32.cpp:3861) with tilelayout planeoff
source/cores/nslasher/hdl/jtnslasher_sdram.v:149 Without hwswap16 every pen's bit-pairs swap: pen -> ((pen&3)<<2)|(pen>>2), so shadow tiles 8/9/A (single-pen 0xE) drew pen 0xB -> pal[0x60B]=00a6c3db = the EXACT warm tan (DB,C3,A6) the diag6 cab probe measured; the correct pal[0x60E] is BL
source/cores/nslasher/hdl/jtnslasher_main.v:63 bit2 (the m_pri&4 raw/faded coloffs, deco32_v.cpp:352) FORCED 0 — nslasher's ONLY pri write is nslasher_eeprom_w=deco32_pri_w(data&0x3) (deco32.c:650; full nslasher_map verified, NO other pri write), so m_pri&4 is structurally always 0 -> o
source/cores/nslasher/hdl/jtnslasher_main.v:119 ---- 93C46 EEPROM (jt9346) — bit-banged via the 0x150000 write (nslasher_eeprom_w) ---- POWER-UP PRELOAD (2026-06-09): the synthesized jt9346 RAM powers up BLANK (M10K init = 0; the all-1s fill is sim-only), and the dump/NVRAM port was tied
source/cores/nslasher/hdl/jtnslasher_main.v:123 Preload the MAME golden image (mame-dump/nvram/nslashers/eeprom -> eeprom_golden.hex, 64x16 big-endian words) through the dump port once at power-up (64 clks, runs during reset; the done bit survives soft resets so in-session service-menu w
source/cores/nslasher/hdl/jtnslasher_main.v:410 soundlatch: 32-bit write to 0x200700, command in bits [23:16] (MAME data>>16)
source/cores/nslasher/hdl/jtnslasher_main.v:424 0x40: MAME eeprom_set_cs_line((data&0x40)?CLEAR:ASSERT).
source/cores/nslasher/hdl/jtnslasher_main.v:424 In the old MAME eeprom device CS is a reset-when-ASSERT line: the chip is ACTIVE when the line is CLEAR, i.e. selected when data&0x40 is SET.
source/cores/nslasher/ver/gfx/tb_colmix_bufferfade.v:7 The confirmed bug: the RTL computed faded[i]=fade(LIVE pal[i]); MAME computes faded[i]=fade(BUFFERED pal[i]) — a DMA-frozen snapshot.
source/cores/nslasher/ver/gfx/tb_colmix_bufferfade.v:18 The golden tf_faded.hex = fade(B0) computed INDEPENDENTLY from deco_ace.cpp by gen_bufferfade_test.py — never derived from this RTL.
source/cores/nslasher/ver/gfx/tb_colmix_bio.v:3 FIX B gate: drive jtnslasher_colmix with the captured Jake-bio frame (vancaps f03000, pri=6 = JOINT-8bpp mode, ground truth attract_pri.txt) and compare RGB against the bio_render.py golden, which is itself 0/76800 vs MAME's own snapshot of
source/cores/nslasher/ver/gfx/tb_torn_NEW.v:7 Checks: (1)+(2) faded[] must be bit-exact fade(B0) for all 2048 entries -- NOT a torn mix (the bug this fix targets), verified against an INDEPENDENT golden (tf_faded.hex, generated straight from the MAME palette_update formula, never deriv
source/cores/nslasher/ver/gfx/tb_colmix_livelock.v:13 The golden is MAME-atomic: after the game programs fade F_NEW, MAME's palette_update() recomputes ALL faded pens instantly, so faded[] MUST equal fade_NEW(pal).
source/cores/nslasher/ver/gfx/tb_obj_f2700_latexact.v:3 BYTE-EXACT-UNDER-LATENCY gate for the PIPELINED draw FSM (comb fix stage-B): render in-game frame f2700 through the REAL engine with a `LAT-clock rom_cs->rom_ok fetch model (same injector as tb_obj_f2700_lat.v) and byte-compare against the
source/cores/nslasher/ver/gfx/tb_flip.v:2 FIX C2 / task #9 gate: per-tile FLIP + colour&7 in jtnslasher_tilemap vs the gen_flip_test.py golden (derived from the MAME get_pfN_tile_info semantics + the reshuffle layout spec, NOT the RTL).
source/cores/nslasher/ver/gfx/tb_layer.v:3 gen_layer.py writes layer_cfg.vh (TILE8/BANK/SCRX/SCRY + PFFILE/GFXFILE for the captured MAME frame) and golden_pxl.hex.
source/cores/nslasher/ver/gfx/tb_colmix_sel.v:3 the obj1 sprite1_drawn term (deco32_v.cpp:352/387).
source/cores/nslasher/ver/sdram_main/jtnslasher_sdram_dense_ref.v:90 Byte-exact vs MAME spritelayout_5bpp per ver/gfx/verify_fold_dense.py (the proven nf4 model).
source/cores/nslasher/ver/game/tb_sndsub.v:3 Boots jtnslasher_snd (Z80 + jt51 + 2x jt6295) standalone with the REAL sndprg ROM, sends the boot soundlatch cmd 0x01, and logs the sound-bus conversation for diff against the MAME golden (mame-dump/snd_golden/SND_GOLDEN_REPORT.md): GOLDEN:
source/cores/nslasher/ver/game/tb_snd_golden.v:2 Z80 + jt51 + 2x jt6295) and traces the SOUND path so it can be diffed against the MAME golden (mame-dump/snd_golden/): MAME golden: 1 soundlatch cmd (0x01) @boot; Z80 reads D000 exactly TWICE; ~5x OKI write 0x78 (stop); YM init burst then O
source/cores/nslasher/ver/arm/tb_boot.v:186 scs=~d[6] per MAME nslasher_eeprom_w.
README.md:19 You still supply the ROMs yourself: `nslasher` / `nslasherj` / `nslashers` (MAME set 0.284) in `/media/fat/games/mame/`.
README.md:73 **Rebalanced audio mix** — music (YM2151) brought down, voice (OKI1 speech) up, SFX (OKI2) adjusted, after diffing each channel against MAME.
README.md:104 ROMs (MAME set 0.284: `nslasher` / `nslasherj` / `nslashers`) go in `/media/fat/games/mame/`
README.md:137 Reference: MAME 0.284 `deco32` driver.

Says it matches, follows or was checked against MAME — 6

source/cores/nslasher/hdl/jtnslasher_game.v:153 0x100014 branch var = 0 (matches MAME golden).
source/cores/nslasher/hdl/jtnslasher_game.v:359 If shadowSrc is instead LIGHT/bright, that's the bug -- the shadow's source pen itself is wrong, not the blend math (confirmed bit-exact to MAME) or the alpha (also confirmed bit-exact).
source/cores/nslasher/hdl/jtnslasher_snd.v:35 Matches the MAME sound_bankswitch_w handler that the original YM2151 interface installs.
source/cores/nslasher/hdl/jtnslasher_main.v:428 nslasher_eeprom_w = deco32_pri_w(data&0x3) (deco32.c:650); bit2 forced 0 (NOT from the shared EEPROM byte) -> obj0 always RAW/full-colour, matching MAME (m_pri&4 never set)
source/cores/nslasher/ver/gfx/tb_colmix_livelock.v:14 The fade formula (additive min(c+ps,255)) is the independently-verified MAME deco_ace formula, NOT read back from the RTL -- the discrimination here is the STIMULUS (continuous-write livelock), not the arithmetic.
source/cores/nslasher/ver/deco156/tb_deco156.v:2 Bit-exact unit test for jtnslasher_deco156 vs the MAME golden (gold.py).

Says it was translated, ported or taken from MAME — 1

source/cores/nslasher/hdl/jtnslasher_deco156.v:2 Faithful RTL port of MAME machine/deco156.c decrypt() (static transform).

Shares text with the MAME driver without saying so — 6

source/cores/nslasher/hdl/jtnslasher_vmem.v:100 0x164000 : tilemap BG2/3 bank -> set_tilemap_colour_bank(0,(data&7)<<4), (1,((data>>3)&7)<<4) — shares text with dataeast/fghthist_v.cpp:46
source/cores/nslasher/hdl/jtnslasher_colmix.v:135 mix_callback (deco32.cpp:936-939): pen = ((p&0x70f) + (((p&0x30)|(p2&0x0f))<<4)) & 0x7ff with — shares text with dataeast/fghthist.cpp:417
source/cores/nslasher/hdl/jtnslasher_colmix.v:186 pri1==0 outer gate: (m_pri&1)==0 || tilemapPri[x]<4 || (mixAlphaTilemap && alphaTilemap-pen==0) — shares text with dataeast/fghthist_v.cpp:246
source/cores/nslasher/hdl/jtnslasher_colmix.v:189 pri1==1 gates: ((m_pri&1)==0 || tilemapPri[x]<4) AND the pri0 term relaxes to allow — shares text with dataeast/fghthist_v.cpp:246
source/cores/nslasher/hdl/jtnslasher_colmix.v:247 colour base baked in): pal2 = gfx[(m_pri&1)?1:2].colorbase (GFXDECODE nslasher: gfx1=0x000/gfx2=0x200). — shares text with dataeast/fghthist_v.cpp:156
source/cores/nslasher/hdl/jtnslasher_colmix.v:250 bank set_tilemap_colour_bank(0,(data&7)<<4) (=tm_bank0). deco16ic adds that bank to the tile COLOUR, — shares text with dataeast/fghthist_v.cpp:46

KonamiGX (yaguboo)#
Taisen Puzzle-dama, Daisu-Kiss, Dragoon Might, Gokujou Parodius: Kako no Eikou o Motomete …
yaguboo/Arcade-KonamiGX_MiSTer @ b07f9469
MAME compared: konami/konamigx.cpp + 15 related file(s)
Read: 29 HDL files, 13,378 lines (all HDL files: no Quartus project found)

yaguboo
repository only

Mostly MAME

high

90%

Statements: 17 toward hardware, 340 toward MAME

Cites hardware documentation that MAME's driver does not — 10

projects/konami/konami_gx/rtl/gx_main.sv:469 Two seeds of two netlists failed on the decode between the slice and a 96 MHz consumer:
projects/konami/konami_gx/rtl/gx_top.sv:1105 So 16 = VBP+1 + 1 and X 24 - (48 - HBP) = HBP+1 - 25 read as "the K056832 counts from the END of sync, plus a fixed pipeline"; the fixed parts (+1, -25) are inside the K056832, whose netlist is not on disk (jt05415x/doc is the 054156/054157
projects/konami/konami_gx/rtl/gx_top.sv:1122 Read 2026-10-06 (MEASUREMENTS 181): the 054157 netlist's per-layer H-offset block (page 7, hofsa/b/c/d) adds each layer's latched fine scroll to hcnt[2:0]; the four latches are clocked at four phases of a 4-dot cycle (B 0, A 1, C 2, D 3), w
projects/konami/konami_gx/rtl/gx_top.sv:2072 Consistent, not proven: no K055673 netlist on disk and every set writes the same V setting.
projects/konami/konami_gx/rtl/memory/gx_memarb.sv:78 Why: `dq_in` (the I/O cell) -> gx_sdram's `dout` mux -> this arbiter -> every client's register was one shared node between fixed pads and sinks spread over the chip, and each netlist re-solved it: -0.816 ns on 1fa6167, +0.370 on 9bb55d2 wi
projects/konami/konami_gx/rtl/memory/gx_sdram.sv:193 So a burst's SECOND word had a pad-to-register delay that changed with every netlist, on the input path the .sdc already says does not close at 96 MHz (D3).
projects/konami/konami_gx/rtl/video/gx_xoffs.sv:36 The two formulas are exactly those two distances: spr_hoffset = 11 - (8*(HSW+1) + HBP + 1) -> the sprite chip counts from the H load (NHLD) tile_dx_adj = 49 - (HBP + 1) -> the tile chip counts from the end of HSYNC so the regi
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:687 Two different diagnostic netlists failed at -0.208 and -0.201 ns on the same path family:
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:694 Snapshotting the group coordinate split that path and produced a passing +0.783 ns build, but the next diagnostic netlist exposed the remaining predecode path at -0.490 ns:
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:743 (For a 3-page-tall layer MAME's `(unsigned)dy % 768` differs from this for a negative scroll; gokuparo uses 2 pages, and span 3 is the same approximation the tile address already makes -- mod3 above.) jt05415x's silicon netlist has the lin

Says it was checked against the original PCB — 1

projects/konami/konami_gx/rtl/video/gx_ccu.sv:21 ---- checked against the silicon, 2026-10-06 (MEASUREMENTS 181) ---------- sim/tb_gx_ccu_053252.v runs Furrtek's silicon reconstruction of the 053252 (jtcores cores/rungun/doc/053252.v, read from references/, not copied) beside this module,

Reports a measurement taken on the original PCB — 4

projects/konami/konami_gx/rtl/gx_top.sv:1101 2026-10-06 (MEASUREMENTS 181), what the 053252 silicon reconstruction says and does not say: in the CCU the first active dot is 8*(HSW+1) + HBP + 1 dots after the H load (sync start) and the first active line is (VSW+1) + (VBP+1) = 23 lines
projects/konami/konami_gx/rtl/gx_top.sv:2069 2026-10-06 (MEASUREMENTS 181): MAME's dy = -23 is exactly the silicon 053252's distance from the V load (vsync start) to the first active line, (VSW+1) + (VBP+1) = 8 + 15, so VOFFSET 39 = 16 + 23 reads as "the sprite chip counts lines from
projects/konami/konami_gx/rtl/video/gx_xoffs.sv:31 WHAT THE SILICON SAYS (2026-10-06, MEASUREMENTS 181).
projects/konami/konami_gx/rtl/video/gx_ccu.sv:21 ---- checked against the silicon, 2026-10-06 (MEASUREMENTS 181) ---------- sim/tb_gx_ccu_053252.v runs Furrtek's silicon reconstruction of the 053252 (jtcores cores/rungun/doc/053252.v, read from references/, not copied) beside this module,

Notes where it differs from MAME — 2

projects/konami/konami_gx/rtl/video/gx_tilemap.sv:18 ---- one MAME comment is wrong and it matters ----------------------------- MAME's header says the layer grid registers are at byte offsets "10-13" and "14-17", one byte per layer.
projects/konami/konami_gx/rtl/video/gx_ccu.sv:282 MAME does not model that timer; its GX driver substitutes scanline 48.

Cites MAME source — 297

projects/konami/konami_gx/integration/gx_download.sv:19 The MRA does the 32-bit word interleave for the main program (MAME ROM_LOAD32_WORD_SWAP) and the 16-bit one for the sound program; the two conventions meet exactly here.
projects/konami/konami_gx/integration/gx_download.sv:27 ---- the second stream: the EEPROM's default contents --------------------- `<rom index="2">` in the .mra carries gokuparo.nv, the 128-byte default 93C46 image MAME calls "default eeprom to prevent game booting with error" (konamigx.cpp:216
projects/konami/konami_gx/integration/gx_download.sv:37 The pairing is the SAME big-endian rule as the ROM stream above, and that is not a coincidence: MAME's region is ROM_REGION16_BE, so file byte 2W is the high half of EEPROM word W.
projects/konami/konami_gx/rtl/gx_main.sv:4 Memory map transcribed in docs/SOURCE_AUDIT.md section 4 from konamigx.cpp:1040 (gx_base_memmap) + :1092 (gx_type2_map).
projects/konami/konami_gx/rtl/gx_main.sv:34 Several devices are 8 bits wide and MAME maps them `umask32(0xff00ff00)`: the CCU, the K056800 and the K055555.
projects/konami/konami_gx/rtl/gx_main.sv:123 --- the fantjour DMA device (rtl/gx_fjdma.sv), DECISIONS D19 ------------ MAME installs a write handler at 0xdb0000 for special 9 only (konamigx.cpp:4054-4055, konamigx_m.cpp:489-538), so the whole path is gated by the set.
projects/konami/konami_gx/rtl/gx_main.sv:138 winspike's type 4 Xilinx protection (gx_xprot, special 7): the opcode latched from cc0004, run on the falling edge of cc0000 bit 9 (bit 25 of the long, konamigx.cpp:893).
projects/konami/konami_gx/rtl/gx_main.sv:193 MAME raises IRQ4 with HOLD_LINE (konamigx.cpp:447): asserted until the CPU acknowledges it.
projects/konami/konami_gx/rtl/gx_main.sv:197 IRQ3 (object DMA end), 2026-09-30: MAME HOLD_LINE too (konamigx.cpp dmaend callback), so the same latch shape -- set by gx_top when the DMA ends with WRPORT1_1 bits 7 and 2 set, cleared by the level-3 IACK.
projects/konami/konami_gx/rtl/gx_main.sv:541 Decoded so a write there is absorbed rather than falling through to open bus, which is what MAME does.
projects/konami/konami_gx/rtl/gx_main.sv:556 The data ROM socket answers 0x400000-0x5fffff on every set (MAME maps 0x400000-0x7fffff .rom() in the one Type 2 map, konamigx.cpp:1044).
projects/konami/konami_gx/rtl/gx_main.sv:560 Until 2026-10-06 the window was gated to dragoonj by machine number; MEASUREMENTS 180: in 9,000 frames of MAME (attract, coin, start, play) no other set reads 0x400000-0x7fffff even once, so the gate changed nothing.
projects/konami/konami_gx/rtl/gx_main.sv:649 MAME returns the bus value; returning 0xffff here makes an unintended fetch decode as a trap-generating opcode rather than as a plausible NOP.
projects/konami/konami_gx/rtl/gx_main.sv:661 MAME calls esc_w once for the long (konamigx.cpp:380), and every write the game makes there is a long from one PC (dist/esctap_b/esc_calls.txt), so a lone word to cc0002 is not modelled.
projects/konami/konami_gx/rtl/gx_main.sv:683 MAME m_last_prot_op starts at -1
projects/konami/konami_gx/rtl/gx_main.sv:697 A run is asked for by a write touching the TOP BYTE of long 0 (konamigx_m.cpp:501, `!offset && ACCESSING_BITS_24_31`), which on this 16-bit bus is the high byte of word 0.
projects/konami/konami_gx/rtl/gx_main.sv:699 `mode` and `sz2` are both in that word, so the trigger carries everything the run reads out of long 0; `sz1`, in the long's low word, is unused in MAME as well (:511).
projects/konami/konami_gx/rtl/gx_main.sv:703 With it low nothing here happens and 0xdb0000 stays unmapped, which is what MAME's map is for every set but these two.
projects/konami/konami_gx/rtl/gx_xprot.sv:11 What MAME does, and so what this does: the long at cc0004 latches an opcode (bits 31-16); the long at cc0000 carries a clock in bit 25 (bit 9 of its high word), and on that clock's FALLING edge the latched opcode runs.
projects/konami/konami_gx/rtl/gx_xprot.sv:14 Winning Spike uses two opcodes (MAME's table, :899-904):
projects/konami/konami_gx/rtl/gx_xprot.sv:22 gx_main recognises the edge, freezes the 68EC020 on that write and lends this module the slice through the ESC / fjdma seam (D18, D19), so the copy is done before the game's next instruction -- MAME's handler runs inside the write.
projects/konami/konami_gx/rtl/gx_ctrl.sv:14 Transcribed from docs/SOURCE_AUDIT.md section 7, which is itself konamigx.cpp:472, :498, :520 and the PORT_START blocks at :1219 and :1264.
projects/konami/konami_gx/rtl/gx_ctrl.sv:37 Everything except the EEPROM data line is ACTIVE LOW (konamigx.cpp:1229 onwards).
projects/konami/konami_gx/rtl/gx_ctrl.sv:67 MAME's comment calls it "reset graphics chips" and MAME's CODE never reads it -- konamigx.cpp:537 resets the K056832 from bit 22, the SOUND reset, instead.
projects/konami/konami_gx/rtl/gx_ctrl.sv:125 konamigx.cpp:515-516: a write with the master bit ORs the source bits into m_gx_syncen.
projects/konami/konami_gx/rtl/gx_ctrl.sv:154 "The enable test is (m_gx_wrport1_1 & 0x8N) == 0x8N -- master bit AND the per-source bit." konamigx.cpp:498, SOURCE_AUDIT section 6.
projects/konami/konami_gx/rtl/gx_ctrl.sv:160 IRQ4 is the exception, and it is not a slip from the pattern above: esc_w tests `m_gx_wrport1_1 & 0x10` with NO master bit (konamigx.cpp:444) and clears rdport1_3 bit 3 inside the same test (:446).
projects/konami/konami_gx/rtl/gx_ctrl.sv:177 The EEPROM data line is bit 0 of the long, NOT the top of the byte: konamigx.cpp:1272 gives it mask 0x00000001 and hands bits 7-1 to gx_rdport1_3_r, which returns `m_gx_rdport1_3 >> 1` (:469).
projects/konami/konami_gx/rtl/gx_ctrl.sv:192 d5a002 bits 15-8: coin 4-1 and service 4-1, the layout at konamigx.cpp:1274.
projects/konami/konami_gx/rtl/gx_ctrl.sv:196 coin[3:2] are decoded by MAME's port map but Gokujou Parodius is a two-slot game, so this module reads only coin[1:0].
projects/konami/konami_gx/rtl/gx_int1arm.sv:4 INFERRED from the programs: one mechanism where MAME has two.
projects/konami/konami_gx/rtl/gx_int1arm.sv:7 MAME fires IRQ1 at vblank on (enable & 0x81) == 0x81 OR m_gx_syncen bit 0 (konamigx.cpp:514-516, :651-653).
projects/konami/konami_gx/rtl/gx_top.sv:11 68EC020 main 24 MHz / 4 MASTER_CLOCK, gx.cpp:117
projects/konami/konami_gx/rtl/gx_top.sv:12 68000 sound 8 MHz / 12 SUB_CLOCK/2, gx.cpp:1723
projects/konami/konami_gx/rtl/gx_top.sv:16 12 MHz / 8 } (gx.cpp:520-527)
projects/konami/konami_gx/rtl/gx_top.sv:37 EEPROM 93C46 yes -- jt9346 object DMA: MAME's vblank snapshot yes -- EMULATION_DERIVED DMA busy bit (the game waits on it) yes -- EMULATION_DERIVED, U10
projects/konami/konami_gx/rtl/gx_top.sv:75 docs/DECISIONS.md D5 ------ 0 = tilemap palette index is colour_code * 32 (this board's choice) 1 = colour_code * 16 (MAME's).
projects/konami/konami_gx/rtl/gx_top.sv:131 MAME gives each set one `special` case in init_konamigx (:4120-4166) and the cases are mutually exclusive by construction -- gx_esc and gx_fjdma already share one bus port on exactly that ground.
projects/konami/konami_gx/rtl/gx_top.sv:151 crzcross / puzldama / tokkae are `special 0` in MAME, but their PCBs carry an ESC and the games LOAD a program into it and poll the packet (crzcross 205590 / 2055D2) -- MAME's esc_w completes any packet with no callback, so the sets run the
projects/konami/konami_gx/rtl/gx_top.sv:237 The three constants below are the whole of what SOURCE_AUDIT section 19 found the A2 shelf needs: MAME's own gate says the sets differ from the two we run in the ESC call, the sprite X offset and their ROMs -- no new memory map, handler, re
projects/konami/konami_gx/rtl/gx_top.sv:251 special 0, gokuparo machine + an ESC MAME does not run
projects/konami/konami_gx/rtl/gx_top.sv:252 special 7, konamigx.cpp:2023
projects/konami/konami_gx/rtl/gx_top.sv:263 winspike (konamigx.cpp:2023): K056832_BPP_8 tiles, K055673_LAYOUT_LE2 sprites, and special 7's type 4 Xilinx protection at cc0000 in place of the ESC
projects/konami/konami_gx/rtl/gx_top.sv:266 the konamigx_6bpp machine (konamigx.cpp:1860): 6 bpp tiles in salmndr2's ROM layout, GX 5bpp sprites with an 8 MB 4bpp area (k055673 region 0xa00000)
projects/konami/konami_gx/rtl/gx_top.sv:273 the sprite ROM format (MAME set_config: K055673_LAYOUT_GX / GX6 / RNG) -- gx_sprfetch, gx_objdraw, gx_sprite and gx_prio read it.
projects/konami/konami_gx/rtl/gx_top.sv:279 the tile ROM format (MAME k056832 set_config): 0 5 bpp with a byte-a-row plane-4 ROM, 1 salmndr2's 6 bpp with a word-a-row plane-4/5 ROM (charlayout6), 2 dragoonj's 5 bpp with no plane-4 ROM at all (ROMREGION_ERASE00: plane 4 is 0)
projects/konami/konami_gx/rtl/gx_top.sv:307 The other three are implemented from gx.cpp:527's table and are UNVERIFIED -- UPSTREAM_TODO U2.
projects/konami/konami_gx/rtl/gx_top.sv:323 At the PCB's 24 MHz this core reaches the sound self-test's deadline in 203 frames where MAME's 68EC020 takes 245, and 227 frames of sound work then do not fit (defect B, MEASUREMENTS 68/71).
projects/konami/konami_gx/rtl/gx_top.sv:343 6/9 = 2/3 -- MAME's number is the chip's own ratio for this loop.
projects/konami/konami_gx/rtl/gx_top.sv:348 MAME's per-set list is where the timeout was noticed, not where the PCB is slow.
projects/konami/konami_gx/rtl/gx_top.sv:444 ---- INT1 ARM (DECISIONS D26, MEASUREMENTS 164) -------------------------------- INFERRED from the programs -- one mechanism where MAME has two.
projects/konami/konami_gx/rtl/gx_top.sv:446 MAME fires IRQ1 at vblank on (enable & 0x81) == 0x81 OR m_gx_syncen bit 0 (konamigx.cpp:514-516, :651-653).
projects/konami/konami_gx/rtl/gx_top.sv:479 With `esc_mode` 0 a run would still complete -- status byte, IRQ4 if enabled -- and build no sprites (gx_esc S_SUB), which is what MAME's esc_w does with no callback.
projects/konami/konami_gx/rtl/gx_top.sv:510 rdport1_3 bit 3: reset 1 (0xfc, konamigx.cpp:3985)
projects/konami/konami_gx/rtl/gx_top.sv:583 MAME installs the ESC callback for sexyparo (special 4) and this device for fantjour and fantjoura (special 9); sexyparo never writes 0xdb0000, Fantastic Journey never writes 0xcc0000, and gokuparo writes neither (MEASURED, MEASUREMENTS 49
projects/konami/konami_gx/rtl/gx_top.sv:761 MEASURED, tools/gx_readtap.lua against MAME, 700 frames:
projects/konami/konami_gx/rtl/gx_top.sv:811 It used to be gated to those two machines; MEASUREMENTS 180 ran all nineteen sets in MAME for 9,000 frames (attract, coin, start, play) and only sexyparo / sexyparoa / daiskiss ever write it 1, so the gate changed nothing.
projects/konami/konami_gx/rtl/gx_top.sv:885 93C46, active high and taken straight from the part -- konamigx.cpp:1272 reads it with IP_ACTIVE_HIGH through do_read().
projects/konami/konami_gx/rtl/gx_top.sv:888 gx_rdport1_3 reset value is 0xfc (gx.cpp:3983); bit 0 of the byte is the EEPROM line, so the seven status bits above it are all 1 = idle -- except bit 1, DMA busy, which gx_sprite drives (gx.cpp:599, :618).
projects/konami/konami_gx/rtl/gx_top.sv:901 IRQ3, object DMA end -- MAME konamigx.cpp dmaend_callback: if ((wrport1_1 & 0x84) == 0x84 || (syncen & 4)) { syncen &= ~4; rdport1_3 &= ~0x80; IRQ3 HOLD_LINE } Dragoon Might's main loop waits for it (2026-09-30: PC stuck at 0x203042, its le
projects/konami/konami_gx/rtl/gx_top.sv:907 OBJINT-REQ (the status byte's bit 7) falls with the first IRQ3 and nothing in MAME raises it again.
projects/konami/konami_gx/rtl/gx_top.sv:910 WHEN: MAME calls dmaend_callback from the DMA-delay timer that EVERY vblank starts (dmastart_callback runs whatever DMAEN says), the same moment it drops the busy flag.
projects/konami/konami_gx/rtl/gx_top.sv:927 konamigx.cpp:1740 and :2047 configure EEPROM_93C46_16BIT.
projects/konami/konami_gx/rtl/gx_top.sv:934 bit 2 clk bit 1 cs bit 0 di (konamigx.cpp:485-487)
projects/konami/konami_gx/rtl/gx_top.sv:938 MAME's own comment on the region is "default eeprom to prevent game booting with error" (konamigx.cpp:2163), so gokuparo.nv is delivered over nvs_* before the CPU is let go.
projects/konami/konami_gx/rtl/gx_top.sv:958 Dragoon Might's memory check reads all 64 words in one frame with the start bit on the FIRST clock after CS rises, and the previous read's data phase often left DI = 1 -- so every such read was missed and the check printed 22D/M BAD (the EE
projects/konami/konami_gx/rtl/gx_top.sv:965 sim/tb_gx_eestart.sv replays MAME's trace.
projects/konami/konami_gx/rtl/gx_top.sv:1051 MEASURED, afa0806 on the board against MAME memory rebuilt into pixels: once the tilemap's sub-tile scroll term is taken out (gx_tilemap, "sub-tile X scroll"), all four layers are a uniform +3 px right.
projects/konami/konami_gx/rtl/gx_top.sv:1096 EMULATION_DERIVED MAME's GX screen is a 288x224 visible crop at (24,16) of the CCU's 384x264 raster.
projects/konami/konami_gx/rtl/gx_top.sv:1259 From MAME's own VRAM, in this FSM's order, the eight most recently INSERTED plane-4 bytes of a layer already hold the next request 91.8 % of the time on the battleship, 81.9 % on the boss and 87-90 % in the city (tools/gx_tile1census.py, by
projects/konami/konami_gx/rtl/gx_top.sv:1536 PCM streaming has a real deadline and Power Spikes paid to learn what a missed one sounds like (its DEBUG_LOG O13: fifteen wrong-nibble output steps in one frame against MAME's zero in 2.16 M samples).
projects/konami/konami_gx/rtl/gx_top.sv:1910 ---- AND THE NEXT WORD KEPT, 2026-09-15 ------------------------------------- MEASURED (docs/MEASUREMENTS.md 38): in the demo stages the CPU is frozen on ROM reads for 79 % of a frame, two thirds of it waiting for tile groups, and 89 % of t
projects/konami/konami_gx/rtl/gx_top.sv:1925 ---- AND A CACHE IN FRONT OF IT ALL, 2026-09-15 ------------------------------ MEASURED on the board (docs/MEASUREMENTS.md 41): the look-ahead took the city demo from 61 % to 82 % of MAME's pace and left the battleship at 48.5 %, whose work
projects/konami/konami_gx/rtl/gx_top.sv:2005 MAME's fill_backcolor starts pal_ptr at base + cliprect.min_y (k054338.cpp:134), and cliprect is in bitmap coordinates whose visible area begins at y = 16.
projects/konami/konami_gx/rtl/gx_top.sv:2007 MEASURED 2026-09-14 on MAME frame 3000: its snapshot's backdrop column matches base + vpos + 16 on 98 % of 164 sampled rows and base + vpos on none.
projects/konami/konami_gx/rtl/gx_top.sv:2039 gx_objscan puts a sprite at w3 - (xoffset - HOFFSET) in line-buffer dots and at vline + w2 + yoffset + VOFFSET in its own rows, and MAME's gxcore puts it at w3 + dx - offx in bitmap X and w2 - dy - offy in bitmap Y, whose visible area start
projects/konami/konami_gx/rtl/gx_top.sv:2050 MAME's -42 (sexyparo) and -26 (A2 shelf) compensated for its ESC HLE, which did not add the offset the chips' programs add to x (+4, and +0x10 first for tbyahhoo / daiskiss).
projects/konami/konami_gx/rtl/gx_top.sv:2055 The mame-src build with the programs uses -46 for all of them.
projects/konami/konami_gx/rtl/gx_top.sv:2069 2026-10-06 (MEASUREMENTS 181): MAME's dy = -23 is exactly the silicon 053252's distance from the V load (vsync start) to the first active line, (VSW+1) + (VBP+1) = 8 + 15, so VOFFSET 39 = 16 + 23 reads as "the sprite chip counts lines from
projects/konami/konami_gx/rtl/gx_top.sv:2076 MEASURED, tb_gx_busmix on the demo stages' consecutive MAME frames (docs/MEASUREMENTS.md 35): two buffers leave 43 / 21 late lines a frame, four and eight none, plane 100 %; a cold row cache (a scene change) leaves 69 / 84 with four and 43
projects/konami/konami_gx/rtl/gx_top.sv:2149 MEASURED in tb_gx_busmix on MAME frames (docs/MEASUREMENTS.md 21): late sprite lines 144 -> 16 on frame 1850 with the CPU idle, and 32 -> 0 on 910; the busiest line of the attract (2240) keeps 144 and is not this fix.
projects/konami/konami_gx/rtl/gx_top.sv:2345 Layer A was innocent -- MAME settled it.
projects/konami/konami_gx/rtl/gx_top.sv:2390 MAME measures the running reply as 0x00..0x0F, with the high nibble always zero.
projects/konami/konami_gx/rtl/gx_top.sv:2638 low nibble 0xE -- the main CPU sends 0xFE, the same command MAME sends at frame 163 -- and rung 4 says it pulsed the sound interrupt too.
projects/konami/konami_gx/rtl/gx_top.sv:2731 MEASURED, dist/sndcomm_mame.csv: the only commands MAME's main CPU ever sends are 0xFE at frame 163 and 0xFB at frame 660.
projects/konami/konami_gx/rtl/gx_top.sv:2737 R G G G 0x_E the boot command 0xFE MAME sends this at f163
projects/konami/konami_gx/rtl/gx_top.sv:2738 G G R G 0x_B the second command 0xFB MAME sends this at f660
projects/konami/konami_gx/rtl/gx_top.sv:2740 Anything else is a command MAME never sends, and THAT would be the finding: the simulator can then be given the same byte and the halt reproduced in a minute instead of a build.
projects/konami/konami_gx/rtl/gx_top.sv:2744 k056800.cpp drops the interrupt pulse when the sound CPU has interrupts disabled, so "the host pulsed" and "the sound CPU was interrupted" are different facts.
projects/konami/konami_gx/rtl/gx_top.sv:2756 Rung 4 is sticky from the first pulse, which MAME puts at frame 163.
projects/konami/konami_gx/rtl/gx_top.sv:2812 Rung 6 is sticky from the first host write, which MAME puts at frame 4.
projects/konami/konami_gx/rtl/gx_top.sv:2843 * the host's SECOND command: MAME sends 0xFB and 360 volume writes at frame 660.
projects/konami/konami_gx/rtl/gx_top.sv:3109 MAME ruled out four candidates (MEASUREMENTS 148); one address tells the rest apart.
projects/konami/konami_gx/rtl/gx_top.sv:3221 gx.cpp:1056.
projects/konami/konami_gx/rtl/gx_decode.sv:11 Every range below is a line-for-line transcription of gx_type2_map (konamigx.cpp:1092) plus gx_base_memmap (:1040), listed in the same order as docs/SOURCE_AUDIT.md section 4 so the two can be diffed by eye.
projects/konami/konami_gx/rtl/gx_decode.sv:50 Not in gx_type2_map: MAME installs a handler here for fantjour and fantjoura only (special 9, konamigx.cpp:4054-4055, :4162 -> konamigx_m.cpp:489-538).
projects/konami/konami_gx/rtl/gx_decode.sv:52 gx_main gates it by the set, so for every other set this select does nothing and the range stays unmapped, as it is in MAME's map.
projects/konami/konami_gx/rtl/gx_decode.sv:94 0xdb0000 >> 5 = 0x6D800; the window is 0x20 bytes (konamigx_m.cpp:493).
projects/konami/konami_gx/rtl/gx_fjdma.sv:8 The actual PCB part that performs this is NOT verified; MAME's own name for it is a "dma" and nothing upstream says which chip it is.
projects/konami/konami_gx/rtl/gx_fjdma.sv:13 ---- why it is not optional (docs/MEASUREMENTS.md 57, 58) -------------------- MEASURED in MAME, 14,000 frames: fantjour and fantjoura write this register file 200,196 times and trigger 16,683 runs, of which 15,397 change memory -- 13,246 f
projects/konami/konami_gx/rtl/gx_fjdma.sv:17 With the writes dropped, which is what this core did until now, MAME's own picture goes black at the same frames the board did (tools/gx_fjdrop.lua).
projects/konami/konami_gx/rtl/gx_fjdma.sv:21 ---- what it does, in MAME's order ------------------------------------------ Eight longs at 0xdb0000-0xdb001f, written with byte enables (COMBINE_DATA).
projects/konami/konami_gx/rtl/gx_fjdma.sv:26 mode = long0[31:24] sz2 = long0[23:16] sz1 (long0[15:8]) is unused, as in MAME
projects/konami/konami_gx/rtl/gx_fjdma.sv:37 sa and da are NOT reset between rows -- MAME's loops carry them -- so a run is one flat sequence of (sz2 + 1) * ceil(db / 4) longs.
projects/konami/konami_gx/rtl/gx_fjdma.sv:51 ---- a bound MAME does not have --------------------------------------------- db is a 32-bit byte count and sz2 a byte, so a corrupt register file could ask for 2^30 longs with the CPU frozen for all of them -- a hang with a still picture,
projects/konami/konami_gx/rtl/gx_fjdma.sv:88 konamigx_m.cpp:518
projects/konami/konami_gx/rtl/gx_fjdma.sv:171 MAME's two loops.
projects/konami/konami_gx/rtl/memory/gx_romcache.sv:9 docs/DECISIONS.md D10 sizes this board's sound CPU from `tools/gx_sndcpu.lua`, over MAME frames 163-660 -- the window in which the main CPU is stuck waiting for it:
projects/konami/konami_gx/rtl/memory/gx_memarb.sv:107 A byte that arrives after the slot has moved on is a WRONG NIBBLE, and jt10_acc amplifies ADPCM-A by 7.25x on its way into the mix, so one wrong nibble becomes an output step that correct audio never makes: measured at 15 jumps over 2048 in
projects/konami/konami_gx/rtl/memory/gx_cpucache.sv:4 MEASURED on the board (docs/MEASUREMENTS.md 41): with the look-ahead the battleship demo runs at 48.5 % of MAME's pace, and a frame-quantised model of MAME's own ROM reads says that stage needs ~29 k words a frame against ~23.5 k delivered.
projects/konami/konami_gx/rtl/cpu/gx_m68k.sv:21 8 MHz is SUB_CLOCK/2, gx.cpp:1723, transcribed in docs/SOURCE_AUDIT.md section 3.
projects/konami/konami_gx/rtl/cpu/gx_m68k.sv:25 ---- autovector, and the source that says so ------------------------------- gx.cpp wires both of the sound CPU's interrupts with `set_input_line` (K056800's int_callback -> M68K_IRQ_1 at gx.cpp:1786, and k054539_1's timer -> IRQ2 at gx.cpp
projects/konami/konami_gx/rtl/cpu/gx_m68k.sv:41 96 MHz / 12 = 8.000 MHz, the sound CPU's rate at gx.cpp:1723.
projects/konami/konami_gx/rtl/video/gx_xoffs.sv:4 These used to be per-set constants in gx_top, chosen by the set's name: tile_dx_adj 0 for the GX sets, -15 dragoonj spr_hoffset 954 GX / 952 salmndr2 / 931 dragoonj -- MAME's per-machine k053252 set_offsets (crop), K055673 set_config dx
projects/konami/konami_gx/rtl/video/gx_xoffs.sv:8 MEASUREMENTS 174 measured the CCU values 16 sets write (gx_lane/gx_vidregs.lua) and found each of MAME's offsets is one formula of the back porch and the hsync width:
projects/konami/konami_gx/rtl/video/gx_xoffs.sv:26 The constants 48 and 1034 are pipeline offsets that make MAME's numbers come out; the PCB's source of them is NOT verified.
projects/konami/konami_gx/rtl/video/gx_objdraw.sv:15 spritelayout (k053246_k053247_k055673.cpp:621) is 5 bpp and the fifth plane is a separate ROM region; the fetch returns both.
projects/konami/konami_gx/rtl/video/gx_objdraw.sv:31 SHADOW pens go out on their own port, `buf_shd_we` / `buf_shd`, and not into the solid buffer: pen 31 when the sprite has a shadow code (MAME drawmode 1 draws the solid pens, drawmode 4 the shadow pen, zdrawgfxzoom32GP, shdpen = granularity
projects/konami/konami_gx/rtl/video/gx_objdraw.sv:42 ZOOM IS MAME'S, ONE TILE AT A TIME (2026-09-14).
projects/konami/konami_gx/rtl/video/gx_objdraw.sv:44 MAME rounds each tile's start and width on its own (draw_yxloop_gx) and picks the source column of dot x as (x * ((16 << 19) / width)) >> 19 (zdrawgfxzoom32GP).
projects/konami/konami_gx/rtl/video/gx_objdraw.sv:50 MEASURED before: MAME frame 4480 95.2 %, gameplay 3700 96.96 %.
projects/konami/konami_gx/rtl/video/gx_objdraw.sv:172 MAME flips by 15 - x
projects/konami/konami_gx/rtl/video/gx_objdraw.sv:188 the shadow pen is the format's last pen: MAME shdpen = granularity - 1 (k053246_k053247_k055673.cpp), 31 / 63 / 15 / 255.
projects/konami/konami_gx/rtl/video/gx_objdraw.sv:295 A tile rounded to no width draws nothing and fetches nothing, as in MAME (a zero-width destination returns before any pixel).
projects/konami/konami_gx/rtl/video/gx_objdraw.sv:339 A zero-width staged tile fetches nothing, as MAME draws nothing.
projects/konami/konami_gx/rtl/video/gx_prio.sv:10 All the behaviour lives in konamigx_v.cpp as a std::vector of up to 518 objects, std::stable_sort'ed on a packed 32-bit key and drawn back-to-front through a z-buffer.
projects/konami/konami_gx/rtl/video/gx_prio.sv:15 The chip's own header (k055555.cpp:5-22) describes what it actually is:
projects/konami/konami_gx/rtl/video/gx_prio.sv:28 What IS ported literally is the colour-index assembly -- K055555GX_decode_vmixcolor (gxv.cpp:165), K055555GX_decode_osmixcolor (:194), K055555GX_decode_objcolor (:78) and K055555GX_decode_inpri (:90).
projects/konami/konami_gx/rtl/video/gx_prio.sv:37 * konamigx_v.cpp:610 sorts the object pool DESCENDING by a key whose top byte is the priority, and draws in that order.
projects/konami/konami_gx/rtl/video/gx_prio.sv:44 MAME has that line commented out with "not used by any GX game?" -- implemented here because it is one XOR and leaving it out would be a silent difference.
projects/konami/konami_gx/rtl/video/gx_prio.sv:49 For the four tilemap planes MAME's pre-sort (gxv.cpp:437) uses `if (layerpri[j] <= layerpri[i]) swap`, so on a tie the LATER letter ends up drawn first, i.e. behind.
projects/konami/konami_gx/rtl/video/gx_prio.sv:55 Where OBJ and SUB1-3 sit in that order is NOT established by any source we have -- in MAME sprites are separate objects whose tie-break is decided by emulator bookkeeping (insertion order and a std::reverse), which is not evidence about sil
projects/konami/konami_gx/rtl/video/gx_prio.sv:64 MAME gets this for free by drawing into a bitmap in order; we have to be explicit.
projects/konami/konami_gx/rtl/video/gx_prio.sv:67 ---- the palette index --------------------------------------------------- MAME overrides the K056832 tile granularity to 16, but the decoded tile pen is still five bits wide:
projects/konami/konami_gx/rtl/video/gx_prio.sv:79 The remaining bug was that the experimental x16 path had been implemented as truncation instead of MAME's arithmetic.
projects/konami/konami_gx/rtl/video/gx_prio.sv:85 Gokujou Parodius writes 0x11 to all four, i.e. every input gets code 1, and MAME never reads them at all.
projects/konami/konami_gx/rtl/video/gx_prio.sv:105 fill_backcolor indexes base + the BITMAP coordinate (k054338.cpp:134-150), whose visible area starts at (24,16), while hpos/vpos here start at 0.
projects/konami/konami_gx/rtl/video/gx_prio.sv:135 That is the same axis as UPSTREAM_TODO U5/U6 -- MAME covers the GX raster with hardcoded offsets (-2,0,2,3) that this core deliberately does not port -- so the alignment is an open P4 question either way and this is one more known term in i
projects/konami/konami_gx/rtl/video/gx_prio.sv:143 K055555_long_w (k055555.cpp:79) puts register 2n in bits 31-24 of long n and register 2n+1 in bits 15-8, so on the 16-bit port the register index IS the word address and the data is always D[15:8].
projects/konami/konami_gx/rtl/video/gx_prio.sv:152 --- D5: how the tilemap palette index is scaled ------------------------- 0 = colour_code * 32 + pixel[4:0] what this board has always done 1 = colour_code * 16 + pixel[4:0] what MAME does
projects/konami/konami_gx/rtl/video/gx_prio.sv:169 --- backdrop source select --------------------------------------------- eeprom_w bit 29 = m_gx_wrport1_0 & 0x20 (gxv.cpp:345): 0 -> the K054338's own solid background colour registers 1 -> the unified 338/5^5 fill, which indexes the palett
projects/konami/konami_gx/rtl/video/gx_prio.sv:186 --- sprite input ------------------------------------------------------- c18 is the K053247 side of the split (K053247GX_combine_c18, gxv.cpp:66, "see p.46"); the sprite chip owns that arithmetic because it needs OPSET and OBJSET2.
projects/konami/konami_gx/rtl/video/gx_prio.sv:192 It picks MAME's colour granularity (1 << bpp: index = colour % (8192 >> bpp) * granularity + pen, konami_helper.cpp / k053246_k053247_k055673.cpp) and the set's sprite priority callback: 0 type2_sprite_callback decode_inpri(c18) 1 salmn
projects/konami/konami_gx/rtl/video/gx_prio.sv:198 4 : attr >> 4 & 0xf (konamigx_v.cpp), each then (pri & ~OINPRI_ON) | (OBJ_PRI & OINPRI_ON).
projects/konami/konami_gx/rtl/video/gx_prio.sv:246 The chip decodes 128 bytes; 46 are named (k055555.cpp:57).
projects/konami/konami_gx/rtl/video/gx_prio.sv:350 colour-index assembly -- K055555GX_decode_vmixcolor, gxv.cpp:165 ("see p.62 7.2.6 and p.27 3.3")
projects/konami/konami_gx/rtl/video/gx_prio.sv:364 MAME reaches the same place by two different routes -- decode_vmixcolor above, and gx_draw_basic_tilemaps (gxv.cpp:695) which splits internal (VINMIX & VINMIX_ON) from external (tile attribute bits 6-7 & ~VINMIX_ON).
projects/konami/konami_gx/rtl/video/gx_prio.sv:376 vcb = PALBASE << 6 (gxv.cpp:169) is the colour code's bits 8:6 into an 8,192-entry palette (konamigx.cpp:1755), so PALBASE bit 2 is palette bit 12.
projects/konami/konami_gx/rtl/video/gx_prio.sv:378 MEASURED: during the explosion flash the game sets PALBASE_A = 0x07; MAME indexes 0x1C1E (black), the board 0x0C1E (the blue double line at y 8-12, shot 6302: board == this function's old output on every pixel of the box).
projects/konami/konami_gx/rtl/video/gx_prio.sv:397 K055555GX_decode_objcolor (gxv.cpp:78, "see p.59 7.2.2"): opon = (OINPRI_ON << 8) | 0xff objcolor = ((((OBJ_PALBASE & 7) << 10) & ~opon) | (c18 & opon)) >> shift
projects/konami/konami_gx/rtl/video/gx_prio.sv:401 K055555GX_decode_inpri (gxv.cpp:90): inpri = ((c18 >> 8) & ~OINPRI_ON) | (OBJ_PRI & OINPRI_ON)
projects/konami/konami_gx/rtl/video/gx_prio.sv:460 Sprites take the layer==0 branch of decode_osmixcolor (gxv.cpp:218), which has no external bits at all: "layer 0 is the sprite layer with different attributes decode; detail on p.49 (missing)" and MAME hardcodes emx = 0.
projects/konami/konami_gx/rtl/video/gx_prio.sv:468 V BRI is two bits per tilemap plane (set_brightness, gxv.cpp:253).
projects/konami/konami_gx/rtl/video/gx_prio.sv:469 OS INBRI / OS INBRI ON are the obj/sub equivalent; MAME caches them and never reads them, so the gating below is this port's reading of the register names, not a transcription.
projects/konami/konami_gx/rtl/video/gx_prio.sv:473 MAME uses them to pick one of the '338's three brightness registers and applies it as a SCALAR contrast to every channel, which cannot be right -- those three registers are the R, G and B of one triple (k054338.h:9, "11-12: brightness R/G/B
projects/konami/konami_gx/rtl/video/gx_prio.sv:525 fill_backcolor (k054338.cpp:118) is a joint 338/5^5 function, "Unified k054338/K055555 BG color fill (see p.67)".
projects/konami/konami_gx/rtl/video/gx_prio.sv:545 MAME advances pal_ptr from `base + cliprect.min_y` once per line (k054338.cpp:134-143), and cliprect.min_y is a BITMAP coordinate: the visible area starts at y = 16 (x = 24 for the horizontal mode).
projects/konami/konami_gx/rtl/video/gx_prio.sv:550 MEASURED 2026-09-14 against MAME frame 3000: base + vpos + 16 matched its backdrop and base + vpos matched none of it.
projects/konami/konami_gx/rtl/video/gx_prio.sv:563 Its priority is its own if OPSET bit 5 (SDSEL) is set, otherwise SHDPRI[code] -- gxv.cpp:566, "see p.51 OPSET SDSEL".
projects/konami/konami_gx/rtl/video/gx_prio.sv:570 MAME implements neither: it forces all three shadowon[] to 0 and then turns them back on only if the '338's RGB delta exceeds +/-7 (gxv.cpp:420).
projects/konami/konami_gx/rtl/video/gx_prio.sv:582 WHERE A SHADOW LANDS ON A TIE, from MAME's sort (gxv.cpp:470-610): objects are drawn in descending key order and a shadow darkens what is already in the bitmap.
projects/konami/konami_gx/rtl/video/gx_prio.sv:597 MAME tests each 2-bit field only for non-zero ("filters shadows by different priority comparison methods (UNIMPLEMENTED, see detail on p.66)", gxv.cpp:405).
projects/konami/konami_gx/rtl/video/gx_prio.sv:605 behind (MAME's rule) C 33,885 px the CURTAINS go black
projects/konami/konami_gx/rtl/video/gx_prio.sv:655 MAME draws a later shadow over an earlier one only at a strictly LOWER priority (k053246_k053247_k055673.cpp:570), so codes that land at the same key count once -- the lowest code is kept.
projects/konami/konami_gx/rtl/video/gx_prio.sv:659 APPROXIMATION: MAME also requires the later shadow to be nearer-or-equal in z, and which of two equal-key shadows survives depends on z too; the per-code buffers do not carry z. TODO(HARDWAREIZE): U13/U14, how the chip stacks.
projects/konami/konami_gx/rtl/video/gx_prio.sv:676 That is how MAME's five-bit gfx element behaves after set_granularity(16), and it is deliberately written as two 13-bit addends so pixel[4] cannot vanish in an implicit-width conversion.
projects/konami/konami_gx/rtl/video/gx_prio.sv:680 The x16 sum is 13 bits and wraps at 8,192, as MAME's palette does.
projects/konami/konami_gx/rtl/video/gx_prio.sv:685 OBJ: MAME's granularity is 1 << bpp
projects/konami/konami_gx/rtl/video/gx_palette.sv:4 konamigx.cpp:1754 for the map, :1755 for the format: map(0xd90000, 0xd97fff).ram().w(palette, write32).share("palette") PALETTE(config, m_palette).set_format(palette_device::xRGB_888, 8192) m_palette->enable_shadows(); m_palette->enable_hi
projects/konami/konami_gx/rtl/video/gx_palette.sv:80 xRGB_888 in MAME's palette_device is (x << 24) | (R << 16) | (G << 8) | B,
projects/konami/konami_gx/rtl/video/gx_palette.sv:204 That the chip select does NOT drop between the two halves is read out of the kernel, which is where a "when is it valid" question is answered (root CLAUDE.md 5.1 -- MAME has no clocks and cannot answer it):
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:6 MAME k054156_k054157_k056832.cpp -- register map, page grid, tile encoding, linescroll.
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:9 Its doc/register_map.md corrects MAME in four places and is cited below where it does.
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:20 MAME's own CODE uses `offset >= 0x10/2 && offset <= 0x16/2` -- word-spaced registers at byte 0x10, 0x12, 0x14, 0x16 and 0x18, 0x1a, 0x1c, 0x1e.
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:44 ---- page addressing ------------------------------------------------------ MAME: page_idx = (((rowstart + r) & 3) << 2) + ((colstart + c) & 3), a 4x4 grid of 64x32-tile pages, each 512x256 pixels.
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:80 Per-layer horizontal displacement in MAME's set_layer_offs convention: positive moves the layer RIGHT, so vx = x + SCREEN_X_OFFSET + scroll - LAYER_DX.
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:107 MAME maps 16 KB to the same handler because the window is mirrored, not because two pages are visible.
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:147 Per-set horizontal adjustment folded into every layer's displacement (MAME set_layer_offs and the k053252 crop origin): dragoonj's layers sit one dot further right (VIDEO_START dragoonj) and its visible area starts 16 dots later (set_offset
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:212 Named accessors, word indices exactly as MAME indexes m_regs.
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:219 The .mra DIP default was FD -- Flip Screen ON -- so the game wrote regs[0] = 0x0134 (reproduced by a MAME run with Flip Screen forced On) and this module's in-place flip rotated each tile.
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:222 With the DIP at FE the game writes 0x0104, and MAME's code is the map (k054156_k054157_k056832.cpp):
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:234 The renderer does not read that page: MAME draws from `scrollbank` unless a game sets m_use_ext_linescroll (:1333), and konamigx never does.
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:239 byte 0x0a, two bits per layer -- register 0x05: 0 = per-line, 1 = unknown (U23; MAME draws it as XY, :1392), 2 = per-8-lines, 3 = xy scroll.
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:288 external tile bank table (GX-specific, 0xd44000) gxv.cpp:1600 -- eight 16-bit entries, packed two per long.
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:297 konamigx_tilebank_w (gxv.cpp:1600) indexes the table by BYTE: m_gx_tilebanks[offset*4 + lane].
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:302 MAME maps 16 bytes here and would index up to 15 into an 8-entry array; addresses with bit 3 set are ignored rather than wrapped, because a wrap would corrupt a live bank.
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:385 The seventeenth is the K056832 external linescroll page; MAME allocates PAGE_COUNT+1 for it and konamigx never sets m_use_ext_linescroll, and **553 VRAM dumps across every dump directory in this lane have it entirely zero**.
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:632 MEASURED, afa0806 on the board against MAME's memory rebuilt into pixels: layers right by A 9, B 3, C 5, D 6.
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:639 B, C and D had LOOKED like MAME because the game's scrolls are -24 plus MAME's per-layer offsets (-2, 0, +2, +3): the dropped bits happened to cancel those offsets for the three layers where they are non-negative.
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:723 MEASURED: the sea stage (MAME frames 14220-15680) writes word 5 = 0x00CF, layer C in mode 0, and its table on scrollbank page 15 holds six different X scrolls down the screen -- the horizon and water band.
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:730 WHAT MAME DOES, k054156_k054157_k056832.cpp tilemap_draw_common: scrollbank = ((word 0x18 >> 1) & 0xc) | (word 0x18 & 3) :1330
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:743 (For a 3-page-tall layer MAME's `(unsigned)dy % 768` differs from this for a negative scroll; gokuparo uses 2 pages, and span 3 is the same approximation the tile address already makes -- mod3 above.) jt05415x's silicon netlist has the lin
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:823 Word 1 (MAME m_regs[1], :618, "tile-flip override ...
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:830 GX external bank table, gxv.cpp:1036
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:1089 alpha_tile_callback, gxv.cpp:1059
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:1116 Bit 7 of each plane byte is the leftmost pixel (MAME's readbit is MSB-first), so no swizzle is needed.
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:1132 charlayout8 {56,24,40,8,48,16,32,0} (k054156_k054157_k056832.cpp:234): pen bits 7..0 from bytes 7,3,5,1,6,2,4,0; bytes 4-7 are rom1's.
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:1243 MAME's frame-300 text, the MAME VRAM tap and dist/gokuparo.bin agree on a deterministic end-to-end oracle.
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:1269 Still open: mode 1 (UPSTREAM_TODO U23, drawn as XY as MAME does), the flip-Y table walk (:1400, :1576-1577) -- global flip is only the in-place flip here anyway, see the flip TODO below.
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:1277 The game writes them and MAME reads neither -- U15.
projects/konami/konami_gx/rtl/video/gx_sprite.sv:6 MAME k053246_k053247_k055673.cpp/.h -- registers, sprite RAM format, the GX draw (gxcore, yxloop_gx, zdrawgfxzoom32GP); konamigx_v.cpp:23-110 and :491-610 -- which entries are drawn, the z rule, c18.
projects/konami/konami_gx/rtl/video/gx_sprite.sv:13 MEASURED tools/gx_objstat.py over 535 attract frames of MAME sprite RAM (docs/MEASUREMENTS.md 18).
projects/konami/konami_gx/rtl/video/gx_sprite.sv:21 ---- WHY ONE SPRITE PIXEL PER DOT IS ENOUGH FOR THE K055555 -------------- MAME draws sprites and layers back to front in (priority, zcode) order, but the sprites also share a z-buffer that the layers never touch, and a sprite pixel is draw
projects/konami/konami_gx/rtl/video/gx_sprite.sv:41 MAME loses none: its key is `pri << 24 | zcode << 16 | offs << 5 | mode << 4`
projects/konami/konami_gx/rtl/video/gx_sprite.sv:42 (konamigx_v.cpp:598), so position breaks the tie, and the pool is drawn back to front in descending order -- at equal zcode the HIGHER offset is drawn first and ends up BEHIND.
projects/konami/konami_gx/rtl/video/gx_sprite.sv:51 pass 1 histogram: how many active entries land on each slot_of pass 2 prefix sum -> a per-bucket pointer at the bucket's LAST slot pass 3 capture, walking entries in ASCENDING offset and taking the pointer DOWNWARD, so the lowest offs
projects/konami/konami_gx/rtl/video/gx_sprite.sv:64 ---- the draw order comes from OPSET, not from a parameter ---------------- MAME inverts the zcode when OPSET bit 4 is set (konamigx_v.cpp:503, "see p.51 OPSET PRI"), and jt053246's K55673_DESC_SORT parameter is the same bit frozen per game
projects/konami/konami_gx/rtl/video/gx_sprite.sv:97 control_w bit 18 (gx.cpp:533)
projects/konami/konami_gx/rtl/video/gx_sprite.sv:170 MAME reads the offsets as 16-bit signed; the scan works modulo 1024, which is the wrap MAME applies when OPSET bit 6 is clear (h:193, gokuparo OPSET = 0x0001).
projects/konami/konami_gx/rtl/video/gx_sprite.sv:180 OBJSET2 (konamigx_v.cpp:30-45)
projects/konami/konami_gx/rtl/video/gx_sprite.sv:202 MAME itself never copies for GX (U30: konamigx_mixer_init(screen, 0)); its mixer reads the live sprite RAM at vblank END (VIDEO_UPDATE_AFTER_VBLANK, konamigx.cpp:1744).
projects/konami/konami_gx/rtl/video/gx_sprite.sv:210 The program clears DMAEN at line 230 and rewrites the sprite list after it, so in a lag frame the list is still being written: the gate keeps the previous frame's sprites where MAME draws the half-written RAM.
projects/konami/konami_gx/rtl/video/gx_sprite.sv:216 That csv's line 0 is vblank END -- MAME's frame notifier moves there with VIDEO_UPDATE_AFTER_VBLANK -- so vblank begins at its line 224 and those rises at lines 1-60 precede it.
projects/konami/konami_gx/rtl/video/gx_sprite.sv:646 ---- the shadow line buffer, 2026-09-14 ------------------------------------- MAME draws a sprite's shadow as its own object with its own z-buffer (gx_shdzbuf) and priority (SHDPRI, or the sprite's own under OPSET SDSEL), so a shadow pixel
projects/konami/konami_gx/rtl/video/gx_sprite.sv:652 Two shadows at one dot do not stack here; MAME stacks them only when their priorities differ (UNVERIFIED on this game, which puts one shadow-coded entry up at a time in 535 attract frames and at most two in its gameplay dump).
projects/konami/konami_gx/rtl/video/gx_sprite.sv:661 tbyahhoo's demo explanation screens darken the whole screen with a code-2 shadow AND the 1P panel with a code-3 one, and MAME draws both (k053246_k053247_k055673.cpp:570: a later shadow lands when it is nearer-or-equal in z AND strictly low
projects/konami/konami_gx/rtl/video/gx_sprite.sv:685 ---- which of the two was drawn last at each dot, 2026-09-14 -------------- MAME sorts a shadow object and a solid sprite by `pri << 24 | zcode << 16` (konamigx_v.cpp:600, :607), and a shadow darkens only what is already in the bitmap.
projects/konami/konami_gx/rtl/video/gx_sprite.sv:693 MEASURED on MAME memory (docs/MEASUREMENTS.md 37): the attract's curtain flash is a full-screen shadow (pri 12, z 15-16) behind the framed picture (pri 12, z 14-15) and MAME darkens none of the picture's 15,906 dots; the demo's explosion fl
projects/konami/konami_gx/rtl/video/gx_sprite.sv:749 type2_sprite_callback (konamigx_v.cpp:106): the top two code bits select a 4-bit bank from OBJSET2 words 4 and 5.
projects/konami/konami_gx/rtl/video/gx_sprite.sv:764 A GX set with an 8 MB 4bpp area (tokkae, tkmmpzdm: k055673 region 0xa00000, the GX layout's 4bpp part (region / 5) * 4, k053246_k053247_k055673.cpp:685) holds 65536, two bits.
projects/konami/konami_gx/rtl/video/gx_sprite.sv:807 the dot-rate output: c18, K053247GX_combine_c18 (konamigx_v.cpp:66, p.46)
projects/konami/konami_gx/rtl/video/gx_objscan.sv:33 MIRROR FOLLOWS MAME, k053246_k053247_k055673.h:164 and :180-181: mirror x forces flipx = 0, and screen flip X does not toggle it; mirror y leaves flipy alone, and screen flip Y does not toggle it.
projects/konami/konami_gx/rtl/video/gx_objscan.sv:44 ZOOM ROUNDS EACH TILE, as MAME's draw_yxloop_gx does, not the whole sprite as one stream (see `recx`).
projects/konami/konami_gx/rtl/video/gx_objscan.sv:111 Change 5: under X mirror MAME forces flipx = 0 and the screen flip does not reach it, so the flip of each tile is exactly "is this the right half".
projects/konami/konami_gx/rtl/video/gx_objscan.sv:178 ---- change 10: MAME's per-tile zoom --------------------------------------- k053246_k053247_k055673.h:146-157 and :316-322, zdrawgfxzoom32GP :464:
projects/konami/konami_gx/rtl/video/gx_objscan.sv:181 centre = (zoom * size) >> 13 tile k at (zoom * k + 0x800) >> 12, size = next tile's start - its own source = (offset * ((16 << 19) / size)) >> 19 (gx_zstride) Upstream multiplied the whole sprite's row by one zoom and cut tiles out of
projects/konami/konami_gx/rtl/video/gx_objscan.sv:291 change 5: MAME keeps flipy under Y mirror and does not apply the screen flip to it (h:180-181).
projects/konami/konami_gx/rtl/video/gx_objscan.sv:414 change 10: this tile's first dot and width, rounded on their own as MAME rounds them
projects/konami/konami_gx/rtl/video/gx_ccu.sv:4 Register map from references/upstream/mame/src/devices/machine/k053252.cpp (LGPL-2.1+, Angelo Salese, from notes by Olivier Galibert), transcribed in docs/SOURCE_AUDIT.md section 3.
projects/konami/konami_gx/rtl/video/gx_ccu.sv:16 jtk053252.v was read for structure and is cited where it settled something MAME's comments left open.
projects/konami/konami_gx/rtl/video/gx_ccu.sv:26 Per line and per frame the active, blank, sync and porch lengths are IDENTICAL -- including k053252.cpp's "+1 on VBP only" (the silicon's V back porch is VBP+1 lines; its H back porch is HBP+1 too, but its front porch is HFP-1, so the H act
projects/konami/konami_gx/rtl/video/gx_ccu.sv:31 So the formulas in this file are the silicon's, not just MAME's.
projects/konami/konami_gx/rtl/video/gx_ccu.sv:40 No set reads VCT (regs e/f; MAME read tap, 11 sets, 3,000 frames: zero reads).
projects/konami/konami_gx/rtl/video/gx_ccu.sv:46 Same raster, easier to read against the MAME formulas, and the counters are not observable from outside the chip.
projects/konami/konami_gx/rtl/video/gx_ccu.sv:62 This CONTRADICTS konamigx.cpp:1745, which claims 8 MHz and htotal 512 under the comment "These parameters are actual value written to the CCU".
projects/konami/konami_gx/rtl/video/gx_ccu.sv:63 It agrees with the set_visarea() that MAME immediately applies on top.
projects/konami/konami_gx/rtl/video/gx_ccu.sv:116 That is the real acknowledge path on this board: konamigx.cpp:1732 wires the CCU's ack callbacks to CLEAR_LINE on the CPU, so the game acknowledges the interrupt by writing the CCU, not by touching the CPU.
projects/konami/konami_gx/rtl/video/gx_ccu.sv:141 k053252.cpp: "Read-only: e-f: bits 8-0: VCT", and it notes that viostorm and dbz read the port purely as a side effect of acknowledging the interrupt.
projects/konami/konami_gx/rtl/video/gx_ccu.sv:159 k053252.cpp states the visible sizes as Hres ~ (HC+1) - HFP - HBP - 8*(HSW+1) Vres ~ (VC+1) - VFP - (VBP+1) - (VSW+1) and notes "according to p.14-15 both HBP and VBP have +1 added, but to get correct visible areas you have to add it only t
projects/konami/konami_gx/rtl/video/gx_ccu.sv:276 MAME's old register-map names for 6/7 as INT1EN/INT2EN are not the silicon semantics; its GX driver also leaves those callbacks unbound and gates IRQ1 only with D56001.
projects/konami/konami_gx/rtl/video/gx_ccu.sv:320 MAME's equivalent (vblank_irq_ack_w) is unconditional.
projects/konami/konami_gx/rtl/video/gx_colmix.sv:12 Root CLAUDE.md section 1.2 shelf 2: MAME's k054338.cpp says of itself "this is just a register-handling shell", so there is no behaviour to port from it -- only a map, and that map already exists in a core people play.
projects/konami/konami_gx/rtl/video/gx_colmix.sv:17 It was checked field by field against k054338.cpp before adoption and they agree everywhere, including the one selection nobody would guess:
projects/konami/konami_gx/rtl/video/gx_colmix.sv:24 MAME writes that as `regs[13 + (pblend>>1 & 1)] >> (~pblend << 3 & 8)`.
projects/konami/konami_gx/rtl/video/gx_colmix.sv:30 System GX sets alpha_invert(1) (konamigx.cpp:1768, and again at gxv.cpp:319), which turns 0x1f into 0 -- fully transparent.
projects/konami/konami_gx/rtl/video/gx_colmix.sv:32 MAME's set_alpha_level returns 255 for pblend == 0 before it reads any register at all.
projects/konami/konami_gx/rtl/video/gx_colmix.sv:42 ---- what MAME did not implement ----------------------------------------- Additive blending.
projects/konami/konami_gx/rtl/video/gx_colmix.sv:43 k054338.cpp:150 says "addition blending unimplemented (requires major changes to drawgfx and tilemap.cpp)" and gxv.cpp:730 papers over it: "FIXME: implement mixpri and additive -- hack: mask out mixpri bit.
projects/konami/konami_gx/rtl/video/gx_colmix.sv:52 MAME masks it out and says so; we do not know what it selects either.
projects/konami/konami_gx/rtl/video/gx_colmix.sv:59 MAME appears to disagree -- konamigx_mixer fills the backdrop BEFORE testing KILL and returns after, leaving the backdrop visible.
projects/konami/konami_gx/rtl/video/gx_colmix.sv:161 MIXPRI is U28 -- MAME masks it out and says so, and we do not know what it selects either.
projects/konami/konami_gx/rtl/video/gx_colmix.sv:162 SHDPRI is MAME's own "demote shadows by one layer when this bit is set???
projects/konami/konami_gx/rtl/video/gx_colmix.sv:186 word 11 bits 7-0 preset 1 (bri_r) konamigx_v.cpp:59-61, which
projects/konami/konami_gx/rtl/video/gx_colmix.sv:209 MAME drops the code-2 object and the code-3 one lands.
projects/konami/konami_gx/rtl/video/gx_colmix.sv:261 MAME's update_all_shadows sign-extends regs[SHAD*] & 0x1ff the same way (k054338.cpp:82) and jt054338 hands it over already sign-extended.
projects/konami/konami_gx/rtl/video/gx_colmix.sv:299 Clamping is the documented behaviour ("The hardware clamps at black or white as necessary: see the Graphics Test in many System GX games", k054338.cpp:16); CLIPSL turning that off is this port's reading of the bit's name.
projects/konami/konami_gx/rtl/video/gx_colmix.sv:325 MAME reaches the same order for a different reason -- it applies both as palette adjustments (set_pen_contrast, set_shadow_dRGB32) and blends when drawing.
projects/konami/konami_gx/rtl/video/gx_colmix.sv:365 MAME applies the presets one after another, each clamped; for shadows (all deltas <= 0) and clamping the sum is the same answer.
projects/konami/konami_gx/rtl/video/gx_colmix.sv:418 The upstream-defect workaround: pblend 0 is opaque (MAME set_alpha_level).
projects/konami/konami_gx/rtl/video/gx_colmix.sv:426 MAME konamigx_v.cpp:59-61 and :251-263 (set_brightness: m_brightness[bri_mode - 1] -> set_pen_contrast).
projects/konami/konami_gx/rtl/video/gx_colmix.sv:427 This module used to read k054338.cpp:21's "11-12: brightness R/G/B" literally, but the next line calls 13-14 "alpha blend R/G/B" too, and 13-14 are three presets picked by a two-bit code in jt054338 and in MAME alike.
projects/konami/konami_gx/rtl/video/gx_colmix.sv:431 MEASURED (MEASUREMENTS 161): dragoonj's ranking screen, VBRI 0x50, presets A0/FF/FF -- the board dimmed red alone (teal picture, 91 % of the backdrop pixels = D x (0.627, 1, 1)), MAME dims all three.
projects/konami/konami_gx/rtl/video/gx_colmix.sv:435 The RUNNER-UP gets its own preset too (bri1), before it meets the blend: MAME dims every layer as it draws it (set_brightness per layer), so the back of a blend is already dimmed.
projects/konami/konami_gx/rtl/video/gx_colmix.sv:440 EMULATION_DERIVED -- TODO(HARDWAREIZE): whether the K054338 applies brightness to its second input at all is not known; MAME's frame-buffer drawing makes it so.
projects/konami/konami_gx/rtl/video/gx_colmix.sv:462 MEASURED on the board (MEASUREMENTS 95, 96): on sexyparo's demo stage B the whole of layer B disappears and the runner-up shows through untouched -- 17,615 pixels, 99.5 % of that frame's board-vs-MAME difference.
projects/konami/konami_gx/rtl/video/gx_colmix.sv:477 k054338.cpp:150 "addition blending unimplemented" gxv.cpp:730 when the additive bit is set MAME forces alpha to 0 and DOES NOT DRAW THE PASS.
projects/konami/konami_gx/rtl/video/gx_colmix.sv:479 So MAME never reads the additive level at all and is no authority on it jt054338 carries ALPHA_INV as a parameter and applies it to every code alike; Mystic Warriors, which it was written for, calls invert_alpha(0) (mystwarr_v.cpp:
projects/konami/konami_gx/rtl/video/gx_colmix.sv:486 So: ALPHA_INV applies to the BLEND level, which MAME does use and which the verified band agrees on, and NOT to the ADDITIVE level.
README.md:28 같은 장면을 MAME 화면과 픽셀 단위로 비교해 남은 차이는 원인별로 분류해 두었고, 그 내용은 "알려진 제한사항"에 정리했습니다.
README.md:31 | MAME 세트 | 공식 명칭 | ESC | 상태 |
README.md:77 직접 마련한 MAME ROM 세트 zip 을 SD 카드의 `/games/mame/` 에 넣습니다.
README.md:79 zip 은 MAME 세트 이름 그대로 두고, 압축을 풀지 않습니다.
README.md:162 TMS57002는 MAME의 명령어 정의를 따라 RTL로 옮긴 뒤 MAME 코드를 그대로 컴파일한 모델과 샘플 단위로 대조했습니다.
README.md:171 스프라이트 테이블을 zcode 계수 정렬로 바꾸고 그림자 우선순위를 PCB 영상에 맞춘 뒤, MAME 대조 16장이 모두 일치했습니다.
README.md:202 바꾸기 전에 MAME 로 19개 세트를 모두 돌려 결과가 같다는 것을 확인했습니다.
README.md:209 이 코어는 **MAME 팀** 덕분에 만들 수 있었습니다.
README.md:211 오랜 세월 아케이드 하드웨어를 기록하고 보존해 온 모든 MAME 기여자께 깊이 감사드립니다.
README.md:213 — <https://www.mamedev.org/> · <https://github.com/mamedev/mame>
README.md:255 MAME 참고 파일
README.md:257 MAME 소스 기준 커밋은 `446356f29ee59b4f2dad4f93408b1aaa33fae926`입니다.
README.md:257 RTL 주석에서 `konamigx.cpp`를 `gx.cpp`로, `konamigx_v.cpp`를 `gxv.cpp`로 줄여 쓴 곳이 있습니다.
README.md:261 | MAME 파일 | 라이선스 | copyright-holders | 참고한 내용 |
README.md:263 | `src/mame/konami/konamigx.cpp` | BSD-3-Clause | R. Belmont, Acho A. Tang, Phil Stroffolino, Olivier Galibert | 메인·사운드 CPU 메모리 맵, 클럭(XTAL과 분주), 인터럽트, 화면 파라미터,
README.md:264 | `src/mame/konami/konamigx_v.cpp` | BSD-3-Clause | R. Belmont, Acho A. Tang, Phil Stroffolino, Olivier Galibert | 레이어 합성 순서, K055555 / K053247 색 결합, 그림자, 알파 반전
README.md:265 | `src/mame/konami/konamigx_m.cpp` | BSD-3-Clause | R. Belmont, Acho A. Tang, Phil Stroffolino, Olivier Galibert | Fantastic Journey의 0xDB0000 DMA 장치 |
README.md:266 | `src/mame/konami/k054156_k054157_k056832.cpp` | BSD-3-Clause | David Haywood | 타일맵 레지스터, VRAM 창, 스크롤, 라인 스크롤 |
README.md:267 | `src/mame/konami/k053246_k053247_k055673.cpp`, `.h` | BSD-3-Clause | David Haywood | 스프라이트 속성 해석, 확대·축소 연산(`zdrawgfxzoom32GP`), 그림자 |
README.md:268 | `src/mame/konami/k055555.cpp` | BSD-3-Clause | David Haywood | 우선순위 인코더 레지스터와 동작 |
README.md:269 | `src/mame/konami/k054338.cpp`, `.h` | BSD-3-Clause | David Haywood | 믹서 레지스터, 밝기와 블렌드 |
README.md:270 | `src/mame/konami/konami_helper.cpp` | BSD-3-Clause | David Haywood | 스프라이트 색 단위와 펜 처리 |
README.md:271 | `src/mame/konami/mystwarr_v.cpp` | BSD-3-Clause | R. Belmont, Phil Stroffolino, Acho A. Tang, Nicola Salmoria | 알파 반전 설정 비교 (System GX와의 차이 확인) |
README.md:272 | `src/devices/machine/k053252.cpp` | LGPL-2.1+ | Angelo Salese | CCU 레지스터 맵 |
README.md:273 | `src/devices/sound/k054539.cpp`, `.h` | BSD-3-Clause | Olivier Galibert | PCM 엔진, 볼륨·팬 테이블, 타이머, 리버브 |
README.md:274 | `src/devices/sound/k056800.cpp`, `.h` | BSD-3-Clause | Ville Linde | 사운드 메일박스 레지스터와 인터럽트 |
README.md:275 | `src/devices/cpu/tms57002/tms57002.cpp`, `.h`, `tms57kdec.cpp`, `tmsinstr.lst`, `tmsmake.py` | BSD-3-Clause | Olivier Galibert | TMS57002 명령어 정의, 디코드 순서, 호스트
README.md:276 | `src/emu/diexec.cpp` | BSD-3-Clause | Aaron Giles | 리셋 중 실행 정지(suspend) 동작 |
README.md:310 **MAME 대조에서 남은 차이가 있습니다.** 원인은 분류되어 있습니다.

Says it matches, follows or was checked against MAME — 12

projects/konami/konami_gx/rtl/gx_xprot.sv:4 EMULATION_DERIVED Matches MAME konamigx.cpp:878-930 (`type4_prot_w`), installed at 0xcc0000-0xcc0007 for winspike by init_konamigx special 7 (:4155) in place of the ESC.
projects/konami/konami_gx/rtl/gx_top.sv:1112 EMULATION_DERIVED Matches MAME konamigx_v.cpp:1136-1144, set_layer_offs(-2, 0, +2, +3) for every non-flipped Type 2 game ("+ve values move layers to the right") -- required for bring-up.
projects/konami/konami_gx/rtl/gx_top.sv:1348 Rebuilding MAME frame 3000 from its VRAM, registers and palette: with that permutation the board's text layer matched 100.0 % and its landscape 90.7 %; with MAME's plane order 45 % and 4.5 %.
projects/konami/konami_gx/rtl/gx_top.sv:2035 EMULATION_DERIVED GOKUPARO-SPECIFIC Matches MAME gx.cpp:1815, set_config(K055673_LAYOUT_GX, -46, -23) for gokuparo (the base konamigx() machine says -26; sexyparo -42) -- required for bring-up.
projects/konami/konami_gx/rtl/gx_top.sv:2061 U6's caveat stands for this value as it does for the other two: gokuparo and sexyparo write IDENTICAL OBJSET1 offsets while MAME gives them different dx, so at most one of the three is the board's. tb_gx_sprite checks that correspondence ag
projects/konami/konami_gx/rtl/gx_fjdma.sv:4 EMULATION_DERIVED Matches MAME konamigx_m.cpp:489-538 (`fantjour_dma_install`, `fantjour_dma_w`), installed for fantjour and fantjoura by `special = 9` (konamigx.cpp:4054-4055, :4162) -- required for those two sets to draw anything at all.
projects/konami/konami_gx/rtl/esc/esc_cpu.sv:6 Semantics: D:/FPGATools/esc/escemu.py step(), which matches MAME on every byte of the sprite page (ESC_FINAL_REPORT section 11).
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:186 Bit 0 pulses when layer A fetches code 0x52 row 7 (ROM index 0x297); bit 1 pulses when the 40 returned ROM bits do NOT match the local ROM/MAME oracle.
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:1246 Rebuilding the whole 13-character mask with this module's address and plane equations matches MAME 561/561 pixels, while the board currently draws only 311 and many wrong colours.
projects/konami/konami_gx/rtl/video/gx_sprite.sv:199 EMULATION_DERIVED Matches MAME konamigx.cpp:620-625, "begin transfer if DMAEN(bit4 of OBJSET1) is set (see p.48)" -- MAME's code quoting the manual, evaluated at vblank begin.
projects/konami/konami_gx/rtl/video/gx_sprite.sv:448 EMULATION_DERIVED Matches MAME konamigx.cpp:612-633 -- raised at vblank begin whatever DMAEN says, dropped 342+42 us later (256+32 when control_w bit 16 selects 8 MHz).
projects/konami/konami_gx/rtl/video/gx_colmix.sv:202 EMULATION_DERIVED Matches MAME konamigx_v.cpp:421-426: a shadow code whose preset (regs 2-4, 5-7, 8-10, each a sign-extended 9-bit delta) is within +/-7 on all three channels is not drawn at all -- not even as an invisible shadow.

Says it was translated, ported or taken from MAME — 1

projects/konami/konami_gx/rtl/video/gx_prio.sv:7 ---- why this is not a port of MAME --------------------------------------- MAME's k055555.cpp is 160 lines of which none are priority logic: a 128-byte register file, a byte write decode and two accessors.

Keeps a MAME approximation — 5

projects/konami/konami_gx/rtl/gx_top.sv:82 OSD "Voice boost": the sound gains MAME's [HACK] gives Dragoon Might (gx_sound, MEASUREMENTS 162), for every set -- no per-game gate (user, 2026-10-02).
projects/konami/konami_gx/rtl/gx_top.sv:336 Was MAME's init_posthack (konamigx.cpp:4013-4022: the 68020 at 2/3 for 12 s on tbyahhoo/mtwinbee and dragoonj/dragoona only).
projects/konami/konami_gx/rtl/video/gx_xoffs.sv:24 EMULATION_DERIVED Fitted to MAME's tuned per-set offsets (k053252.cpp TODO: "the offset x/y hack").
projects/konami/konami_gx/rtl/video/gx_sprite.sv:47 The table has 256 slots and there are at most 256 active entries, so a stable sort always fits, and it reproduces MAME's order exactly rather than approximately.
README.md:283 이런 부분은 MAME의 동작을 그대로 따르며, RTL 주석에 `EMULATION_DERIVED` 또는 `APPROXIMATION`으로 표시해 두었습니다.

Shares text with the MAME driver without saying so — 25

projects/konami/konami_gx/integration/gx_download.sv:29 93C46 image MAME calls "default eeprom to prevent game booting with error" — shares text with konami/konamigx.cpp:2169
projects/konami/konami_gx/rtl/gx_top.sv:939 "default eeprom to prevent game booting with error" (konamigx.cpp:2163), so — shares text with konami/konamigx.cpp:2169
projects/konami/konami_gx/rtl/gx_top.sv:1114 for every non-flipped Type 2 game ("+ve values move layers to the — shares text with konami/konamigx_v.cpp:1202
projects/konami/konami_gx/rtl/gx_top.sv:2037 Matches MAME gx.cpp:1815, set_config(K055673_LAYOUT_GX, -46, -23) for — shares text with konami/konamigx.cpp:1818
projects/konami/konami_gx/rtl/gx_fjdma.sv:31 mode 0x93 for i1 in 0..sz2: for (i2 = 0; i2 < db; i2 += 4) — shares text with konami/konamigx_m.cpp:521
projects/konami/konami_gx/rtl/gx_fjdma.sv:32 *da = *sa ^ x; da += 4; sa += 4 — shares text with konami/konamigx_m.cpp:523
projects/konami/konami_gx/rtl/gx_fjdma.sv:33 mode 0x8F for i1 in 0..sz2: for (i2 = 0; i2 < db; i2 += 4) — shares text with konami/konamigx_m.cpp:521
projects/konami/konami_gx/rtl/video/gx_palette.sv:6 PALETTE(config, m_palette).set_format(palette_device::xRGB_888, 8192) — shares text with konami/konamigx.cpp:1758
projects/konami/konami_gx/rtl/video/gx_palette.sv:7 m_palette->enable_shadows(); m_palette->enable_highlights(); — shares text with konami/konamigx.cpp:1759
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:21 `offset >= 0x10/2 && offset <= 0x16/2` -- word-spaced registers at byte — shares text with konami/k054156_k054157_k056832.cpp:1148
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:45 MAME: page_idx = (((rowstart + r) & 3) << 2) + ((colstart + c) & 3), a 4x4 — shares text with konami/k054156_k054157_k056832.cpp:571
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:228 FBITS m_regs[3] >> 6 & 3 :617 — shares text with konami/k054156_k054157_k056832.cpp:617
projects/konami/konami_gx/rtl/video/gx_tilemap.sv:1131 charlayout6 {40,32,24,8,16,0} is charlayout5 with byte 5 on top. — shares text with konami/k054156_k054157_k056832.cpp:260
projects/konami/konami_gx/rtl/video/gx_sprite.sv:200 Matches MAME konamigx.cpp:620-625, "begin transfer if DMAEN(bit4 of — shares text with konami/konamigx.cpp:622
projects/konami/konami_gx/rtl/video/gx_sprite.sv:201 OBJSET1) is set (see p.48)" -- MAME's code quoting the manual, evaluated — shares text with konami/konamigx.cpp:622
projects/konami/konami_gx/rtl/video/gx_ccu.sv:63 the comment "These parameters are actual value written to the CCU". It — shares text with konami/konamigx.cpp:1749
projects/konami/konami_gx/rtl/video/gx_colmix.sv:13 2: MAME's k054338.cpp says of itself "this is just a register-handling — shares text with konami/k054338.cpp:26
projects/konami/konami_gx/rtl/video/gx_colmix.sv:24 MAME writes that as `regs[13 + (pblend>>1 & 1)] >> (~pblend << 3 & 8)`. — shares text with konami/k054338.cpp:171
projects/konami/konami_gx/rtl/video/gx_colmix.sv:44 (requires major changes to drawgfx and tilemap.cpp)" and gxv.cpp:730 papers — shares text with konami/k054338.cpp:161
projects/konami/konami_gx/rtl/video/gx_colmix.sv:56 K338_CTL_KILL, control bit 0, "0 = no video output, 1 = enable". Taken — shares text with konami/k054338.h:18
projects/konami/konami_gx/rtl/video/gx_colmix.sv:163 is MAME's own "demote shadows by one layer when this bit is set??? (see — shares text with konami/konamigx_v.cpp:360
projects/konami/konami_gx/rtl/video/gx_colmix.sv:300 behaviour ("The hardware clamps at black or white as necessary: see the — shares text with konami/k054338.cpp:17
projects/konami/konami_gx/rtl/video/gx_colmix.sv:301 Graphics Test in many System GX games", k054338.cpp:16); CLIPSL turning that — shares text with konami/k054338.cpp:17
projects/konami/konami_gx/rtl/video/gx_colmix.sv:428 module used to read k054338.cpp:21's "11-12: brightness R/G/B" literally, — shares text with konami/k054338.cpp:21
projects/konami/konami_gx/rtl/video/gx_colmix.sv:429 but the next line calls 13-14 "alpha blend R/G/B" too, and 13-14 are three — shares text with konami/k054338.cpp:23

mcatadv (decoryah)#
Magical Cat Adventure, Nostradamus
decoryah/Arcade-MagicalCatAdventure_Nostradamus_MiSTer @ e5f616f1
MAME compared: misc/mcatadv.cpp
Read: 16 HDL files, 2,196 lines (Quartus project)

decoryah
repository only

Mostly MAME

low

74%

Statements: 1 toward hardware, 46 toward MAME

Says it was checked on “real hardware” — 1

README.md:98 The Pocket core is a working alpha, tested on hardware; its README lists what it could not do.

Cites MAME source — 44

MCatAdv.sv:6 Written for MiSTer from MAME's driver (src/mame/misc/mcatadv.cpp, tmap038.cpp), after the Analogue Pocket core of finner (https://github.com/finner/openFPGA-Wintechno): the CPUs (fx68k, tv80), the YM2610 (jt10, Jose Tejada) and the memory m
MCatAdv.sv:60 Nostradamus (cfg_game from the ROM image) is a vertical game, MAME's ROT270: the scaler shows its 320x224 raster rotated a quarter turn counter-clockwise.
MCatAdv.sv:161 keyboard: 1/2 start, 5/6 coin, 9 service, F2 test (MAME's defaults)
MCatAdv.sv:173 F2: the service switch, a toggle as in MAME
MCatAdv.sv:189 the board's inputs, active low (MAME's INPUT_PORTS mcatadv, nost): P1: bit 0 up, 1 down, 2 left, 3 right, 4 button 1 (fire), 5 button 2 (jump), 6 button 3, 7 start 1, 8 coin 1, Nostradamus also 9 "test 3" (buttons 2, 3 and test 3 are used i
MCatAdv.sv:198 DIP switches: the MRA's <switches> arrive as ioctl index 254, byte 0 = DSW1 bits 15:8 and byte 1 = DSW2 bits 15:8 as MAME's ports hold them (a 1 is MAME's default).
rtl/mcatadv_main.sv:3 The 68000 (fx68k, 16 MHz), its memory map (MAME src/mame/misc/mcatadv.cpp, mcatadv_state::main_map), the RAMs the video chips read, the inputs, the sound latches and the watchdog.
rtl/mcatadv_main.sv:26 clocks without a kick before the reset: 3 s (MAME's time) = 288000000 at 96 MHz
rtl/mcatadv_main.sv:81 level 1 interrupt, held until acknowledged (MAME: irq1_line_hold)
rtl/mcatadv_main.sv:184 ------------------------------------------------------------------ watchdog (MAME: 3 s) A cold start, with no signature in the RAM, ends in a wait for this reset (the game writes "MASICAL CAT ADVENTURE" into its RAM and spins until the watc
rtl/mcatadv_main.sv:186 A boot that goes on kicks the watchdog for the first time about 95 ms after the reset, so until the first kick the limit is an eighth of the full one (0.375 s for MAME's 3 s): the cold start's wait is shorter and no boot that goes on is hit
rtl/mcatadv_main.sv:188 The short limit is for the start after a hard reset only: once the watchdog has expired or been kicked (Nostradamus' first kick comes later than 0.375 s) the limit is MAME's.
rtl/mcatadv_main.sv:228 MAME: mcatadv_wd_r
rtl/mcatadv_sound.sv:3 MAME (mcatadv_sound_map / mcatadv_sound_io_map, and the Nostradamus pair nost_sound_map / nost_sound_io_map):
rtl/mcatadv_sound.sv:13 The bank is 1 when a ROM is loaded (MAME sets it in machine_start only; a reset leaves it).
rtl/mcatadv_sound.sv:95 ---------------------------------------------------------------- program ROM and bank (MAME sets the bank once, in machine_start: a reset leaves it as the program last wrote it)
rtl/mcatadv_sound.sv:170 MAME's unmapped read
rtl/mcatadv_sound.sv:181 ---------------------------------------------------------------- mix: MAME's YM2610 routes into one speaker MAME: the SSG (ymfm: (a + b + c) * 2/3, channel levels 0..16382) with 1.0 for Magical Cat Adventure and 0.6 for Nostradamus, the FM
rtl/mcatadv_spr.sv:3 MAME (mcatadv_state::draw_sprites): the sprite RAM holds 2048 entries of four words per half (B00004 picks the half).
rtl/mcatadv_spr.sv:10 MAME draws the entries from the last to the first and a pixel that is non-zero in a sprite hides the ones under it, so the highest entry number wins: drawn here from the first to the last, each over the last.
rtl/mcatadv_spr.sv:12 An entry whose w3 equals its w0 is skipped (MAME: "don't draw sprites while it's testing the RAM").
rtl/mcatadv_spr.sv:51 5 MB of sprite ROM; MAME's region is FF past it
rtl/mcatadv_sprbuf.sv:1 MAME draws the sprites from a copy of the sprite RAM made at the start of vertical blanking (buffered_spriteram16 on a vblank rising edge); the registers at B00000/B00002 (the sprite offset) are read live, B00004 (the buffer half) is copied
rtl/mcatadv_tmap.sv:3 MAME (mcatadv_state::draw_tilemap_part and tilemap038_device): scrollx = (reg0 & 1FF) - 194, scrolly = (reg1 & 1FF) - 1DF row select (reg1 bit 14): scrolly = lineram[((line + scrolly) & 1FF) * 2 + 1] - line row scroll (reg0 bit 14): scrollx
rtl/mcatadv_tmap.sv:17 Screen flip (reg0 / reg1 bit 15 = 0 flips X / Y), as MAME's draw_tilemap_part and tilemap_t do it: the scroll is lowered by 19 / 141 (hex) and the whole 512 x 512 map is mirrored, so that screen pixel (x, y) shows map pixel X flip: (scroll
rtl/mcatadv_tmap.sv:20 The sprites are not flipped (the part of MAME's driver that would is disabled).
rtl/mcatadv_tmap.sv:86 ---------------------------------------------------------------- tile code -> ROM tile MAME wraps a tile code modulo the number of tiles in the ROM.
rtl/mcatadv_video.sv:4 MAME gives 60 Hz and a 320 x 224 visible area; the totals are the usual 15 kHz arcade ones.
rtl/mcatadv_video.sv:13 The mix is MAME's screen_update: tile layer 1 over layer 0 unless layer 0's tile has the higher priority; a sprite over the tiles when its priority is higher than the tile's (or there is no tile); the background is palette entry 0x3F0.
README.md:7 It started from the Analogue Pocket core by **finner** ([openFPGA-Wintechno](https://github.com/finner/openFPGA-Wintechno)): the board's memory map, the choice
README.md:10 The video chips, the memory system, the raster, the clocks and the platform layer are new, written for MiSTer from MAME's driver (`src/mame/misc/mcatadv.cpp`, `
README.md:27 The video, against a reference renderer (`tools/refrender.py`) that is MAME's `screen_update` written out literally: RAM states of the real programs (title scre
README.md:31 The 68000 side: the real programs boot, pass their RAM and ROM tests, write the power-on signature, wait for the watchdog as MAME's driver comments say they sho
README.md:53 **A cold start shows a black screen for a moment** (about 0.4 s): the game writes a signature into its RAM and waits for the watchdog to reset it, as on the boa
README.md:67 | Orientation | Game default, Horizontal, Rotate CCW, Rotate CW | Nostradamus is a vertical game (MAME's ROT270): its default is the scaler rotating the picture
README.md:74 **Nostradamus plays with one button** (Shot); on both boards the extra buttons exist for the test mode only (MAME's driver notes): button 3 (Magical Cat Adventu
README.md:78 Entering the test mode: the "Service Mode" DIP switch (OSD, then Reset) or F2 (a toggle, as in MAME; if the game does not react at once, press Reset).
README.md:85 The mix follows MAME's routes into one speaker: the SSG with 1.0 (0.6 on Nostradamus), the FM and ADPCM-A left and right 0.5 each.
README.md:100 The MiSTer FPGA has room for MAME's behaviour, so this core implements it:
README.md:104 both tilemaps with row scroll and row select (the title screen uses them), per-tile priority, the palette bank, MAME's tile/sprite priority comparison and sprit
README.md:106 sprites from the vblank-buffered copy of the sprite RAM, with MAME's flip, size and clipping rules;
README.md:115 Screen flip (the Flip Screen DIP switch; the game then sets bit 15 of the tilemap registers to 0) mirrors the two tilemaps as MAME's `draw_tilemap_part` does (c
README.md:117 The sprites are not flipped: the part of MAME's driver that would is disabled (`#if 0`), and the driver carries the flag MACHINE_NO_COCKTAIL.
README.md:168 MAME (Paul Priest, David Haywood, Luca Elia; BSD-3-Clause): `mcatadv.cpp`, `tmap038.cpp`.

Keeps a MAME approximation — 1

README.md:113 MAME's 3 s watchdog instead of a per-boot hack.

Shares text with the MAME driver without saying so — 1

rtl/mcatadv_spr.sv:13 its w0 is skipped (MAME: "don't draw sprites while it's testing the RAM"). — shares text with misc/mcatadv.cpp:276

metamorphicforce (decoryah)#
Metamorphic Force
decoryah/Arcade-MetamorphicForce_MiSTer @ 565ee11f
MAME compared: konami/mystwarr.cpp + 19 related file(s)
Read: 20 HDL files, 5,092 lines (Quartus project)

decoryah
repository only

Mostly MAME

medium

91%

Statements: 73 toward MAME, 1 not counted

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/mf_main.sv:213 -------------------------------------------------------- memories work RAM 32K x 16, byte lanes — also in MAME: 32K konami/konamigx.cpp:89

Cites MAME source — 61

MetamorphicForce.sv:5 The machine (rtl/) descends from the Monster Maulers core for MiSTer, itself from the Gaiapolis core written for the Analogue Pocket by plasticbugs (https://github.com/plasticbugs/analogue-pocket-gaiapolis): Gaiapolis, Monster Maulers and M
MetamorphicForce.sv:161 keyboard: 1-4 start, 5-8 coin, F2 test (MAME's defaults)
MetamorphicForce.sv:187 a player's byte as the board's input words carry it, active low (MAME's KONAMI16_LSB / MSB): bit0 left, 1 right, 2 up, 3 down, 4-6 buttons 1-3, 7 start
rtl/er5911.sv:2 ER5911 serial EEPROM, 128 x 8, as MAME's eeprom_serial_er5911_device models it (eepromser.cpp): a start bit, a 2-bit opcode and a 9-bit address field (only the low 7 bits select a cell) on rising CLK while CS is high; READ shifts data out M
rtl/er5911.sv:8 the Pocket repository's tools/eeprom_replay.py checks this protocol against MAME's pin traffic.
rtl/er5911.sv:98 a 1 on DI at a rising clock is the start bit (edges that coincide with CS rising are ignored, as MAME does)
rtl/k053247_draw.sv:29 MAME's absolute coordinates of the picture's first pixel ...
rtl/k053250_lvc.sv:4 Semantics are MAME's k053250.cpp (k053250_device::draw / pdraw_scanline32 / dma), which is the spec the benches compare with (sim/tb_lvc.cpp carries a transcription of it).
rtl/k053250_lvc.sv:25 One pixel is evaluated as (MAME: src_fx = HALF - flip + k * (zoom << 10), idx = src_fx >> 16, folded to 6-bit fractions): clip (source clipping on): k = pos' + scroll, drawn while k >= 0 and (k + 1) * zoom <= (clipmask + 1) << 6 (zoom 0:
rtl/k053250_lvc.sv:41 MAME's absolute x of the first visible pixel (cliprect.min_x)
rtl/k054321.sv:6 MAME models the gain as 2^((volume - 40) / 10) with 40 as "normal"; mf_core applies it.
rtl/k054539.sv:3 Modelled on MAME's k054539.cpp.
rtl/k054539.sv:16 Rendering follows sound_stream_update: per 48 kHz sample, each keyed channel steps its 16.16 position by the 24-bit delta, fetching 8-bit PCM, 16-bit PCM or 4-bit DPCM from the ROM (looping at the end marker if reg 0x201 bit 0 is set, else
rtl/k054539.sv:25 While 0x22f bit 0 is set (MAME's UPDATE_AT_KEYON, its default) a write to a channel's position registers is held in a latch and only copied into the registers by that channel's key-on.
rtl/k054539.sv:28 Volumes are Q2.14 tables from tools/gen_k054539_tables.py; the per-channel gain MAME applies at reset for this game (chip 1 channels 4-7 x2.0, the "voice" channels) comes in through GAIN_Q14.
rtl/k054539.sv:78 UPDATE_AT_KEYON (MAME's default for every game, k054539.cpp): while the chip is enabled (0x22f bit 0) a write to a channel's position registers (0x0c-0x0e of its 0x20 block) is held in a latch and the register keeps its value; the key-on wr
rtl/k054539.sv:260 Every position step fetches a sample, as MAME does, so a pitch above 1.0 costs one ROM read per step; DPCM depends on that.
rtl/k054539.sv:309 the Q2.14 fraction bits of the product are dropped, as MAME does
rtl/k054539.sv:353 16-bit samples are read as two bytes at cur_pos and cur_pos + 1, whatever the alignment (MAME: read_byte(pos) | read_byte(pos + 1) << 8); an odd start address is common in this game's music
rtl/k054539.sv:430 a 16-bit sample steps two bytes (MAME: pdelta <<= 1)
rtl/k054539.sv:475 MAME adds the ring position twice: rdelta = (delay + pos) & 0x3fff, then the entry is rbase[(rdelta + pos) & 0x1fff].
rtl/k054539.sv:483 the ring holds int16; MAME truncates the scaled sample the same way
rtl/k056832_tilemap.sv:7 A pen is the palette entry itself, ((layer colour base | tile colour) * 16) + pixel, with the tile colour taken as `color >> 2 & 0xf` (MAME's viostorm_tile_callback).
rtl/k056832_tilemap.sv:46 raster line of a picture row minus MAME's absolute y of it (17 - 15)
rtl/k056832_tilemap.sv:100 metamrph per-layer pixel offsets (mystwarr_v.cpp, VIDEO_START metamrph: set_layer_offs(0, -2+4, 0), (1, 0+4, 0), (2, 2+4, 0), (3, 3+4, 0))
rtl/k056832_tilemap.sv:105 Y is supported (this game runs with it set: its data are stored "software Y-flipped"): MAME flips every page's tilemap, so a page's rows come out mirrored, its scroll is taken around the visible area's centre and the K056832's register 0x1e
rtl/k056832_tilemap.sv:111 MAME's absolute y of the row being rendered (cliprect.min_y is 15 here)
rtl/k056832_tilemap.sv:237 whatever dy is: MAME's override for the "software flipped" games) row scroll (mode 2), unflipped: e = (dy + y) & ~7, one entry for eight lines row scroll, Y flipped: e = 248 - 8 * ((y + (dy & 7)) >> 3) with y the absolute row a
rtl/mf_core.sv:21 raster line at which the sprite list and the K053250's buffer are taken: MAME's update (vpos 253) is 2 lines earlier than this raster
rtl/mf_core.sv:22 MAME line 24: the picture here sits 2 lines lower
rtl/mf_core.sv:23 MAME line 248
rtl/mf_core.sv:139 the instants of the frame, from the raster: MAME's scantimer fires at pixel 0 of a line
rtl/mf_core.sv:147 the vblank's start: MAME's frame number counts here
rtl/mf_core.sv:268 The sprite table the renderers work from is a copy of the sprite RAM taken at OBJ_BUILD_LINE, as MAME's list is taken at its update: the game writes its table during the visible frame as well, and a renderer reading the live RAM line by lin
rtl/mf_main.sv:4 Address decode follows docs/hardware.md section 3 (MAME's metamrph_map in mystwarr.cpp).
rtl/mf_main.sv:5 The CPU is TG68K.C, paced by a token bucket the way the S.T.U.N. Runner core paces its 68010 -- STEP_COST_BUS/STEP_COST_INT/STEP_GAIN set the step rate; the values are calibrated against MAME's frame timing.
rtl/mf_main.sv:183 --------------------------------------------------------- decode (MAME's metamrph_map)
rtl/mf_main.sv:291 The bank is the low byte of regs[0x1a] | regs[0x1b] << 16 (MAME takes it modulo the region's 640 banks; only the first 256 hold ROM).
rtl/mf_main.sv:309 MAME's eeprom_r: a low-byte access reads IN1 (its bits 1:0 the EEPROM's DO and READY), otherwise 0
rtl/mf_main.sv:371 IRQ6 at the first scanline (MAME line 24), IRQ5 at line 248 if the K053246 enables it: each is asserted and held until the kernel's interrupt-acknowledge cycle (MAME's HOLD_LINE)
rtl/mf_main.sv:398 a byte of the K053250's ROM at 0x80000 * regs[6] + 0x800 * regs[7] + offset / 2 (regs[6] != 0 is beyond the ROM: MAME reads past its region there; this reads 0)
rtl/mf_sound.sv:199 MAME routes each chip's output 0 to the right speaker and output 1 to the left ("stereo channels are inverted", mystwarr.cpp), which a comparison of this core's audio with MAME's confirms (the pan balance of the two correlates -0.76 without
rtl/mf_video.sv:14 MAME's raster agrees (set_raw(6 MHz, 384, ..., 264)); its picture sits at y 15 of the frame there (a driver choice, K053252 offsets (24, 15)) where this one has it at 17 as the chip's registers place it, so MAME's line numbers are these min
rtl/mf_video.sv:28 (A frame rendered by the machine against MAME's of the same state is the check: sim/tb_mm.cpp with DUMPSTATE, see tools/cmp_state.py.
README.md:5 The machine descends from the Monster Maulers core for MiSTer, which descends from the Gaiapolis core that **plasticbugs** wrote for the Analogue Pocket ([analo
README.md:22 Everything else below is simulation and the Quartus tool flow, against MAME 0.289 (the reference for every comparison; MAME marks these sets `MACHINE_IMPERFECT_
README.md:25 **Video, frame for frame.** `sim/tb_frame*`: a frozen MAME machine state (the Lua probes in `tools/lua/` dump the video chips' registers and RAMs) is rendered t
README.md:30 For 13 of them MAME was run again with each layer set enabled alone: the tile layers and the K053250 alone are pixel-identical in every one, and the differences
README.md:35 **K053250.** `sim/tb_lvc*`: the plane's renderer against a transcription of MAME's `k053250_device::draw` on random line RAM, registers, ROM and frame timing, i
README.md:41 **ROM path.** `tools/make_mra.py`, `tools/mf_rom.py` and `tools/mra_build.py` rebuild MAME's memory regions from the zip and `tools/check_regions.py` compares t
README.md:49 The only differences are two registers that the bench reads at another instant of the frame than MAME's dump.
README.md:50 Over 5.5 s of the attract mode's sound the two channels follow MAME's within 1 dB per half second and 0.1 dB overall, envelopes correlating at 0.90.
README.md:125 | picture | 288 x 224, MAME visarea y 17 | the same raster; MAME's visarea starts at line 15 (the benches account for the 2 lines) |
README.md:131 | interrupts | IRQ5 at vblank | IRQ6 at MAME line 24, IRQ5 at line 248 (if the K053246's sprite IRQ is enabled) |
README.md:138 Known differences from MAME
README.md:140 Both are cases where MAME's software mixer does something one pixel at a time that the chips' pipeline cannot; the frame bench's single-layer renders (below) sh
README.md:144 **Overlapping translucent sprites.** MAME blends sprite by sprite in turn (each blended onto what is there, including an earlier translucent sprite); this core'
README.md:149 **A pixel shadowed twice.** The renderer keeps one shadow flag per pixel; MAME's mixer darkens a pixel once for every shadow sprite that covers it.
README.md:150 4 frames of the corpus have such pixels (28 to 543 of them, each one shadow step darker in MAME).
README.md:153 **The 68000's pace.** The kernel is TG68K.C paced by a token bucket calibrated against MAME's frame timing; state dumps of the video chips' registers and RAMs a
README.md:191 **plasticbugs** -- the Gaiapolis core for the Analogue Pocket, the machine this one is built on (`rtl/`, the SDRAM controller `target/mister/sdram_ctrl.sv` and

Says it matches, follows or was checked against MAME — 4

rtl/k056832_tilemap.sv:16 Semantics follow the Pocket repository's tools/render_model.py, which is pixel-exact against MAME across the frozen-state corpus; see docs/hardware.md section 6.
README.md:28 **101 of the 115 are pixel-identical.** The other 14 differ only where MAME's software mixer does what the chips' pipeline cannot (see "Known differences"): 10
README.md:45 With the power-on tests and two splash delays cut (the same patch applied to MAME's run), the machine reaches the game's main loop within 8 frames and at frames
README.md:52 **The power-on tests.** The same bench with no shortcut, 830 frames from reset: the game's own RAM tests (work RAM, K053250 RAM, sprite RAM and the 12 KB of pla

Shares text with the MAME driver without saying so — 8

rtl/k053247_draw.sv:35 k055673 set_config(K055673_LAYOUT_RNG, -51, -24) for metamrph — shares text with konami/mystwarr.cpp:1039
rtl/k053247_objlist.sv:25 metamrph_sprite_callback: priority_mask = (color & 0xe0) >> 2, and a shadow code of 3 sets — shares text with konami/mystwarr_v.cpp:97
rtl/k056832_tilemap.sv:12 separate blend level only through the K055555's V_INMIX_ON, which the game sets — shares text with konami/mystwarr_v.cpp:61
rtl/k056832_tilemap.sv:101 set_layer_offs(0, -2+4, 0), (1, 0+4, 0), (2, 2+4, 0), (3, 3+4, 0)) — shares text with konami/mystwarr_v.cpp:191
rtl/mf_core.sv:231 mystwarr_state::screen_update_metamrph: K055555_get_palette_index(4) << 4 — shares text with konami/mystwarr_v.cpp:288
rtl/mf_main.sv:291 K056832 readback (k056832_device::mw_rom_word_r). The bank is the low byte — shares text with konami/k054156_k054157_k056832.cpp:818
rtl/mf_mixer.sv:129 drawn without any alpha (gx_draw_basic_extended_tilemaps_1 computes one but k053250_device::draw takes — shares text with konami/konamigx.h:157
rtl/mf_sound.sv:159 MACHINE_RESET metamrph: "boost voice (chip 0 channel 4-7) and soften other channels": chip 1 channels — shares text with konami/mystwarr.cpp:922

monstermaulers (decoryah)#
Kyukyoku Sentai Dadandarn
decoryah/Arcade-MonsterMaulers_MiSTer @ 5796d4aa
MAME compared: konami/mystwarr.cpp + 19 related file(s)
Read: 20 HDL files, 5,121 lines (Quartus project)

decoryah
repository only

Mostly MAME

medium

79%

Statements: 1 toward hardware, 61 toward MAME, 1 not counted

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/mm_main.sv:226 -------------------------------------------------------- memories work RAM 32K x 16, byte lanes — also in MAME: 32K konami/konamigx.cpp:89

Notes where it differs from MAME — 1

rtl/k053936_roz.sv:33 Deliberate divergence from MAME: K053936GP_copyroz32clip advances its destination row before the loop body, so MAME paints raster row N with the transform for row N-1 and never writes the first visible row.

Cites MAME source — 52

MonsterMaulers.sv:5 The machine (rtl/) descends from the Gaiapolis core written for the Analogue Pocket by plasticbugs (https://github.com/plasticbugs/analogue-pocket-gaiapolis), as carried to MiSTer in gaiapolis-mister: Gaiapolis and Monster Maulers are board
MonsterMaulers.sv:154 keyboard: 1/2 start, 5/6 coin, F2 test (MAME's defaults)
MonsterMaulers.sv:179 the board's inputs, active low (docs/hardware.md section 8; MAME's dadandrn ports): IN0_P1: bit0 L, 1 R, 2 U, 3 D, 4-6 buttons 1-3, 7 start1, 8 coin1, 9 coin2, 11 test switch P2: the same low byte IN1: bit3 test (low = on), bit4 mono (0 = s
rtl/er5911.sv:2 ER5911 serial EEPROM, 128 x 8, as MAME's eeprom_serial_er5911_device models it (eepromser.cpp): a start bit, a 2-bit opcode and a 9-bit address field (only the low 7 bits select a cell) on rising CLK while CS is high; READ shifts data out M
rtl/er5911.sv:8 the Pocket repository's tools/eeprom_replay.py checks this protocol against MAME's pin traffic.
rtl/er5911.sv:98 a 1 on DI at a rising clock is the start bit (edges that coincide with CS rising are ignored, as MAME does)
rtl/k053936_roz.sv:14 MAME draws the transform of raster row N-1 at row N and never writes the first row (its blitter advances its destination row before the loop body); MAME_SHIFT=1 does the same, which is what the frame bench's pixel-for-pixel comparison again
rtl/k053936_roz.sv:52 draw row N with the transform of row N-1, row 0 blank (as MAME does)
rtl/k053936_roz.sv:111 16.16, wraps as uint32 like MAME
rtl/k053936_roz.sv:239 MAME draws the transform of row N-1 at row N, and nothing at row 0
rtl/k054321.sv:6 MAME models the gain as 2^((volume - 40) / 10) with 40 as "normal"; mm_core applies it.
rtl/k054539.sv:3 Modelled on MAME's k054539.cpp.
rtl/k054539.sv:16 Rendering follows sound_stream_update: per 48 kHz sample, each keyed channel steps its 16.16 position by the 24-bit delta, fetching 8-bit PCM, 16-bit PCM or 4-bit DPCM from the ROM (looping at the end marker if reg 0x201 bit 0 is set, else
rtl/k054539.sv:25 While 0x22f bit 0 is set (MAME's UPDATE_AT_KEYON, its default) a write to a channel's position registers is held in a latch and only copied into the registers by that channel's key-on.
rtl/k054539.sv:28 Volumes are Q2.14 tables from tools/gen_k054539_tables.py; the per-channel gain MAME applies at reset for this game (chip 1 channels 4-7 x2.0, the "voice" channels) comes in through GAIN_Q14.
rtl/k054539.sv:78 UPDATE_AT_KEYON (MAME's default for every game, k054539.cpp): while the chip is enabled (0x22f bit 0) a write to a channel's position registers (0x0c-0x0e of its 0x20 block) is held in a latch and the register keeps its value; the key-on wr
rtl/k054539.sv:260 Every position step fetches a sample, as MAME does, so a pitch above 1.0 costs one ROM read per step; DPCM depends on that.
rtl/k054539.sv:309 the Q2.14 fraction bits of the product are dropped, as MAME does
rtl/k054539.sv:353 16-bit samples are read as two bytes at cur_pos and cur_pos + 1, whatever the alignment (MAME: read_byte(pos) | read_byte(pos + 1) << 8); an odd start address is common in this game's music
rtl/k054539.sv:430 a 16-bit sample steps two bytes (MAME: pdelta <<= 1)
rtl/k054539.sv:475 MAME adds the ring position twice: rdelta = (delay + pos) & 0x3fff, then the entry is rbase[(rdelta + pos) & 0x1fff].
rtl/k054539.sv:483 the ring holds int16; MAME truncates the scaled sample the same way
rtl/k056832_tilemap.sv:93 dadandrn per-layer pixel offsets (mystwarr_v.cpp, VIDEO_START dadandrn: set_layer_offs(0, -2+4, 0), (1, 0+4, 0), (2, 2+4, 0), (3, 3+4, 0))
rtl/mm_core.sv:269 The sprite table the renderers work from is a copy of the sprite RAM taken at the first blanking line, as the K053246's DMA into the K053247 does and as MAME's list is taken: the game writes its table during the visible frame as well, and a
rtl/mm_main.sv:4 Address decode follows docs/hardware.md section 3 (MAME's dadandrn_map in mystwarr.cpp).
rtl/mm_main.sv:5 The CPU is TG68K.C, paced by a token bucket the way the S.T.U.N. Runner core paces its 68010 -- STEP_COST_BUS/STEP_COST_INT/STEP_GAIN set the step rate; the values are calibrated against MAME's frame timing.
rtl/mm_main.sv:278 MAME's test is (word offset & 0x78) == 0, i.e. A[7:4] all clear -- four bits, not three.
rtl/mm_main.sv:309 The bank is the low byte of regs[0x1a] | regs[0x1b] << 16 (MAME takes it modulo the 768 banks of the region; only the first 256 hold ROM).
rtl/mm_main.sv:329 MAME's dddeeprom_r: an access that includes the high byte returns IN1 there with a zero low byte; only a low-byte access reads P2
rtl/mm_main.sv:367 MAME does it in zero time at the write; the board's chip masters the bus, so here the CPU is held for the word-a-clock the fill takes.
rtl/mm_main.sv:410 IRQ5 is asserted at vblank and held until the kernel's interrupt-acknowledge cycle -- a *read* with FC = 111, which TG68K performs even with IPL_autovector (MAME's HOLD_LINE).
rtl/mm_main.sv:486 the u16s just above them are the fifth plane area, as MAME's flat region has it
rtl/mm_sound.sv:197 MAME routes each chip's output 0 to the right speaker and output 1 to the left ("stereo channels are inverted", mystwarr.cpp), which a comparison of this core's audio with MAME's confirms (the pan balance of the two correlates -0.76 without
rtl/mm_video.sv:12 That is MAME's raster for this driver too (set_raw(6 MHz, 384, ..., 264)); unlike Gaiapolis there is nothing to choose between.
rtl/mm_video.sv:25 (A frame rendered by the machine against MAME's of the same state is the check: sim/tb_mm.cpp with DUMPSTATE, see tools/cmp_state.py.
README.md:6 The machine descends from the Gaiapolis core that **plasticbugs** wrote for the Analogue Pocket ([analogue-pocket-gaiapolis](https://github.com/plasticbugs/anal
README.md:24 What was checked besides, in simulation and in the Quartus tool flow, against MAME 0.289 (the reference for every comparison; MAME marks these sets `MACHINE_IMP
README.md:27 **Video, frame for frame.** `sim/tb_frame*`: a frozen MAME machine state (the Lua probes in `tools/lua/` dump the video chips' registers and RAMs) is rendered t
README.md:37 **ROM path.** `tools/make_mra.py`, `tools/mra_build.py` and `tools/mm_rom.py` rebuild MAME's memory regions from the zip and `tools/check_regions.py` compares t
README.md:44 The game runs one to three frames behind MAME's (see "Known differences"), and state dumps of the video chips' registers and RAMs agree with MAME's register for
README.md:59 **Audio.** The first 5.5 s of the game's sound (`tools/cmp_audio.py`, same boot shortcut in MAME): the two channels follow MAME's in level within about 1-2 dB p
README.md:61 That is a check of the whole chain (the Z80 program, both K054539s, the K054321's volume and channel enables), not of the chips sample by sample (the next bulle
README.md:73 **K054539 against MAME, chip level** (`sim/run_k539.sh`): the Z80's register writes to both chips are logged from MAME (USA set, `tools/lua/k539_log.lua`), repl
README.md:109 *Weak, crackling music.* Three differences from MAME's `k054539.cpp` in `rtl/k054539.sv`: 16-bit PCM stepped one byte a sample and was forced to word alignment
README.md:112 The sum of the two chips also saturates now, as MAME's does, instead of wrapping.
README.md:171 | picture | 376 x 224, ROT90, 8 MHz / 508 x 263 | 288 x 224, ROT0, 6 MHz / 384 x 264 = 59.1856 Hz (the board and MAME agree) |
README.md:183 Known differences from MAME
README.md:185 **A pixel shadowed twice.** The renderer keeps one shadow flag per pixel; MAME's software mixer darkens a pixel once for every shadow sprite that covers it.
README.md:188 **The K055550 takes time.** MAME performs the memset of command 0x97 in zero time at the register write; this core's engine masters the bus for the word-a-few-c
README.md:189 The game uses it to clear all sixteen tile RAM pages (128 KB) at start-up and again before the attract mode, a quarter of a frame each time, so the game's own t
README.md:193 The power-on memory check runs for about 1,300 frames (22 s) as in MAME; the Diagnostic overlay shows progress.
README.md:230 **plasticbugs** -- the Gaiapolis core for the Analogue Pocket, the machine this one is built on (`rtl/`, the SDRAM controller `target/mister/sdram_ctrl.sv` and

Says it matches, follows or was checked against MAME — 5

rtl/k056832_tilemap.sv:11 Semantics follow the Pocket repository's tools/render_model.py, which is pixel-exact against MAME across the frozen-state corpus; see docs/hardware.md section 6.
README.md:29 39 of the 40 frames in the corpus (attract mode, the ROZ stages, fades, alpha blends, shadows) are **pixel-identical**; the other has 10 pixels (of 64,512) wher
README.md:40 With the power-on memory check and the boot's software delay shortcut (as MAME is run for the comparison) and MAME's scripted inputs (coin, start, buttons) appl
README.md:51 Every word of the image is where the ports read it (11,141,120 compared with the chips' arrays), the raster is 384 x 264 x 16 clocks = 59.1856 Hz in every frame
README.md:84 Fixed in three parts, all checked against MAME's frames in simulation and then on the board:

Shares text with the MAME driver without saying so — 4

rtl/k053247_draw.sv:31 k055673 set_config(K055673_LAYOUT_GX, -42, -22) for dadandrn — shares text with konami/mystwarr.cpp:990
rtl/k053936_roz.sv:48 K053936GP_set_offset(0, -8, 0) for dadandrn (a laser attack's offset) — shares text with konami/mystwarr_v.cpp:197
rtl/k056832_tilemap.sv:94 set_layer_offs(0, -2+4, 0), (1, 0+4, 0), (2, 2+4, 0), (3, 3+4, 0)) — shares text with konami/mystwarr_v.cpp:191
rtl/mm_main.sv:309 K056832 readback (k056832_device::mw_rom_word_r). The bank is the low byte — shares text with konami/k054156_k054157_k056832.cpp:818

Namco_NA1_NA2 (kyledlester)#
Bakuretsu Quiz Ma-Q Dai Bouken, Cosmo Gang the Puzzle, Emeraldia, Exvania …
kyledlester/Namco_NA1_NA2_MiSTer @ f36b06dd
MAME compared: namco/namcona1.cpp + 4 related file(s)
Read: 53 HDL files, 7,887 lines (Quartus project)

kyledlester
repository only

Mostly MAME

medium

76%

Statements: 3 toward hardware, 163 toward MAME, 1 not counted

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/na1/na1_c69.sv:5 MCU address map [MAME-CONFIRMED] (m37702m2_device::map + namcona1_mcu_map): $000000-$00007F SFRs $000800-$000FFF mailbox (slot = addr[3:1]) $000080-$00027F internal RAM $001000-$001FFF C219 (byte offset & $1FF, reg = offset ^ — also in MAME: 32K namco/namcona1.cpp:114

Notes where it differs from MAME — 3

rtl/na1/na1_mcu_fa_helper.sv:7 This scheduling differs from MAME.
rtl/na1/na1_renderer.sv:73 M33 GAME FLIP ($EFFF98, the operator FLIP setting; MAME does not implement it).
rtl/na1/na1_rom_board_io.sv:24 MSM6242 model = MAME's msm6242_device, not a datasheet superset: * time registers S1..W are READ-ONLY (MAME ignores writes to them) and come from MiSTer's RTC (hps_io `RTC`, MSM6242B layout: BCD sec/min/hour/date/ month/year, weekday 0 = Su

Cites MAME source — 154

NA1.sv:121 M22: F/A has no game DIPs (settings live in EEPROM via its own service menu, [MAME-CONFIRMED] docs/M18_IMPLEMENTATION.md); only the hardware control-panel bit that opens that menu is exposed.
NA1.sv:381 M18: raw active-low input bytes exactly as the C69 reads them through its P7 multiplexer (MAME namcona1_joy: b7 Start, b6 Button 3, b5 Bomb, b4 Shot, b3 Up, b2 Down, b1 Left, b0 Right; DSW b7 Service 1, b6 service-mode switch, b5..b2 Coin 1
NA1.sv:399 The line-224 event feeds C69 IRQ1 and the [MAME-CONFIRMED] simulate_mcu $F60 shim (docs/M20B_IMPLEMENTATION.md section 6).
NA1.sv:427 DSW b5..b2 are Coin 1..4 `[MAME-CONFIRMED]`; M29 wires lanes 3/4 from the third and fourth MiSTer joysticks (previously tied inactive).
NA1.sv:436 M32: the MCU's IRQ1 and the $F60 shim follow the 68000's IRQ4 to the end of the visible window (frame_event), keeping MAME's MCU/68000 phase.
NA1.sv:505 Only the CPU's ROM reads pass through it -- blitter sources still read ROM, exactly as MAME's blit() reads m_prgrom.
NA1.sv:515 CPU ROM read cache: resident program/mask-ROM words complete in the 68000's minimum four-clock bus cycle, as MAME's NA-1 does; SDRAM misses keep the shared path.
NA1.sv:795 F/A is MAME ROT90; rotate_ccw=0 (matching the published 1942 MiSTer core, also ROT90) was the initial guess and is now [HW-CONFIRMED] correct (owner, DE10-Nano, 2026-09-21): rotating with rotate_ccw=0 produces the intended portrait presenta
NA1.sv:860 M20A: Namco C219 PCM engine [MAME-CONFIRMED contract] at MAME's 44.1 kHz cadence [IMPLEMENTATION; physical rate UNKNOWN], reading its samples from the shared work RAM in SDRAM.
rtl/na1/na1.sv:1 Machine boundary: FX68K plus replaceable MAME-compatible interrupt timing.
rtl/na1/na1_audio_tick.sv:3 Default 44,100 Hz = MAME's C219 clock; the physical NA-1 rate is [UNKNOWN].
rtl/na1/na1_blitter.sv:1 M13 MAME-compatible sequential u16 copy.
rtl/na1/na1_blitter.sv:6 That is not what the hardware does, and it is not what MAME models: `transfer_dword()` logs "bad blt src/dest" and returns -1, and `blit()` then simply `return`s -- the transfer is ABANDONED and the 68000 carries on.
rtl/na1/na1_blitter.sv:12 Super World Court does exactly this: 24 times in a 31-second MAME run it issues a blit with source base $000000 and a NON-zero length (e.g. bank=$0003 src1=$00F1 n=$0080 from PC $C007B4).
rtl/na1/na1_blitter.sv:14 MAME abandons those; we hung.
rtl/na1/na1_blitter.sv:21 MAME's default arms compute `(64 - (format >> n)) << k`, which is <= 0 for large formats; its loop then advances a row per word, because `offset(2) >= bytes_per_row` is immediately true.
rtl/na1/na1_blitter.sv:38 Sticky for the duration of one request: this blit hit an address MAME would have logged as bad and abandoned.
rtl/na1/na1_blitter.sv:59 MAME: (64 - (format>>2)) << 3.
rtl/na1/na1_blitter.sv:69 MAME: (64 - (format>>5)) << 6, with the same <= 0 degeneracy.
rtl/na1/na1_blitter.sv:98 M29.1: ACK on completion whether or not the blit was abandoned, exactly as MAME's blit() returns to the CPU either way.
rtl/na1/na1_blitter.sv:118 MAME "bad blt src": abandon the transfer, complete the request.
rtl/na1/na1_blitter.sv:122 MAME "bad blit dest": abandon the transfer, complete the request.
rtl/na1/na1_board_presentation.sv:10 The NA-1 raster is the same on every board; what differs is how the monitor is mounted in the cabinet, which is exactly what MAME records as ROT90 vs ROT0.
rtl/na1/na1_board_presentation.sv:34 The emulated port-bit semantics are untouched: the quiz panel drives exactly the bits MAME's namcona1_quiz declares.
rtl/na1/na1_board_presentation.sv:88 Quiz panel (Bakuretsu): MAME's :P1 declares Button 1..4 on bits 3..0 and Start on bit 7, with bits 6..4 unconnected.
rtl/na1/na1_board_presentation.sv:89 `[MAME-CONFIRMED]` port dump.
rtl/na1/na1_c219.sv:3 Behavioural contract [MAME-CONFIRMED] = MAME 0.289 src/devices/sound/c140.cpp (c219_device).
rtl/na1/na1_c219.sv:4 Everything not marked otherwise reproduces that model exactly; physical C219 behaviour is [UNKNOWN] beyond what MAME encodes.
rtl/na1/na1_c219.sv:18 Byte addresses outside $00000-$7FFFF read as 0 (MAME's unmapped sample space).
rtl/na1/na1_c219.sv:21 Cadence: sample_tick (44.1 kHz [IMPLEMENTATION], MAME's C219 clock; physical rate [UNKNOWN]) starts one output sample: voices 0..15 are processed in order (sample-major; MAME renders voice-major per stream chunk — identical except for the s
rtl/na1/na1_c219.sv:28 Output routing [MAME-CONFIRMED]: the mix scaled by register +0 (MAME's "volume_right") drives the LEFT speaker and +1 ("volume_left") the RIGHT (namcona1.cpp add_route(0 -> speaker 1, 1 -> speaker 0)); MAME's stream clamp (mix/4096) equals
rtl/na1/na1_c219.sv:57 Mirror-adjusted write offset: odd $1F8+ writes land 8 lower [MAME-CONFIRMED].
rtl/na1/na1_c219.sv:72 16-bit wrapping mixers [MAME-CONFIRMED s16 buffers]
rtl/na1/na1_c219.sv:80 ---------------------------------------------------------------- tables Volume scaling (vol*32)/24 [MAME-CONFIRMED]; 0..340 fits 9 bits.
rtl/na1/na1_c219.sv:89 mu-law decode = MAME pcmtbl[i] >> 5 [MAME-CONFIRMED]: cumulative step table (steps 1/2/4/8/16 over 0-15/16-23/24-47/48-99/100-127); the negative half (~pcmtbl[i-128] & $FFE0) >> 5 equals -j-1.
rtl/na1/na1_c219.sv:236 byte address = group*$20000 + bank<<16 + start + pos [MAME-CONFIRMED find_sample]
rtl/na1/na1_c69.sv:5 MCU address map [MAME-CONFIRMED] (m37702m2_device::map + namcona1_mcu_map): $000000-$00007F SFRs $000800-$000FFF mailbox (slot = addr[3:1]) $000080-$00027F internal RAM $001000-$001FFF C219 (byte offset & $1FF, reg = offset ^
rtl/na1/na1_c69.sv:15 A 16-bit MCU access to the C219 becomes two 8-bit register accesses, lane 0 first, as MAME's memory system splits it onto c219_le_w.
rtl/na1/na1_c69.sv:17 Board glue [MAME-CONFIRMED] namcona1.cpp: P4 bit 3 rising edge releases the 68000 (maincpu_release pulse); P5 reads back its written bits with bit 0 := bit 1; P6 input 0; P7 = {P4, DSW, P1, P2}[P6[7:5]] while P6 bit 7 = 0 else $FF; P8 reads
rtl/na1/na1_c69.sv:79 [IMPLEMENTATION] MAME's RAM is zero-initialised; the physical power-up contents are [UNKNOWN].
rtl/na1/na1_c69.sv:113 `[MAME-CONFIRMED]` namcona1.cpp wires an<N>_cb to portana_r<Bit>, which returns $FFFF when the P3 bit is SET (not pressed) and $0000 when it is clear (pressed): channel 0->bit 6, 1->bit 5, 2->bit 4, 3->bit 0, channel 4->bit 1, 5->bit 2, 6->
rtl/na1/na1_c69.sv:128 MAME driver state written by the port callbacks (data & dir)
rtl/na1/na1_c69_input_service.sv:6 Evidence (docs/M18_IMPLEMENTATION.md): MAME 0.289 executing the real C69 firmware with F/A, Lua memory/port taps and input injection, plus ablation.
rtl/na1/na1_c69_input_service.sv:8 [MAME-CONFIRMED] Once per ~16.7 ms the firmware rewrites, in 68000 view: $FC0.hi <- $80 (update-in-progress flag) ...
rtl/na1/na1_c69_sfr.sv:6 Behavioural contract [MAME-CONFIRMED] = MAME 0.289 m37710.cpp (m37702m2_device::map, port_r/w, get_port_reg/set_port_reg, count_start_w, m37710_recalc_timer, m37710_timer_cb, ad_control_w, ad_timer_cb, uart*_w, set_int_control, m37710_set_i
rtl/na1/na1_c69_sfr.sv:10 Reproduced MAME properties that differ from the datasheet (deliberately, see docs/M20B_IMPLEMENTATION.md sections 2-3): a started timer never stops; timer registers read back the written reload value; interrupt-control bit 3 is a register i
rtl/na1/na1_c69_sfr.sv:17 Timing [IMPLEMENTATION]: MAME schedules timer/A-D starts at the time of the register write, which is the end of the writing instruction's cycle budget; the core signals that boundary with instr_commit and the starts are applied there.
rtl/na1/na1_c69_sfr.sv:20 Periods count ce_mcu ticks (MAME clocks_to_attotime in input clocks).
rtl/na1/na1_c69_sfr.sv:21 MAME_EARLY=1 reproduces a MAME arithmetic artefact [MAME-CONFIRMED by the f140 trace, docs/M20B_IMPLEMENTATION.md section 7]: 2*floor(1e18/12528250) as is one attosecond less than floor(1e18/6264125), so every expiry lands just below a CPU-
rtl/na1/na1_c69_sfr.sv:36 ports: inputs as the board drives them (MAME p*_in_cb; unbound ports read $FF)
rtl/na1/na1_c69_sfr.sv:40 A-D inputs (MAME analog callbacks)
rtl/na1/na1_c69_sfr.sv:52 MAME line numbers
rtl/na1/na1_c69_sfr.sv:63 timers: MAME timer objects
rtl/na1/na1_c69_sfr.sv:75 ------------------------------------------------------------ helpers port index for byte address $02-$14 (MAME port_r<0>/<1> layout), -1 = none
rtl/na1/na1_c69_sfr.sv:100 MAME get_port_reg
rtl/na1/na1_c69_sfr.sv:104 byte read of the SFR space (MAME handlers; unmapped -> 0)
rtl/na1/na1_c69_sfr.sv:128 one byte write (side effects handled by the caller where MAME has them)
rtl/na1/na1_c69_sfr.sv:158 MAME timer period: tscales[mode>>6] * (reg + 1) = (reg + 1) << {1,4,6,9}; 0 = no timer
rtl/na1/na1_c69_sfr.sv:163 not timer mode: no MAME timer
rtl/na1/na1_c69_sfr.sv:178 ------------------------------------------------------------ interrupt resolver (m37710i_update_irqs) MAME scans the lines from 19 down to 0 and takes each one whose priority is strictly above both the CPU's ipl and the best seen so far: th
rtl/na1/na1_c69_sfr.sv:236 ---- instruction boundary: apply MAME's time-of-write side effects
rtl/na1/na1_c69_sfr.sv:246 ---- timers and A-D on the MAME clock
rtl/na1/na1_c69_startup.sv:6 [MAME-CONFIRMED] (docs/FA_HARDWARE_SPEC.md, "C69 BIOS") machine reset holds the 68000; the BIOS stores the immediate vector words so that 68000-visible $000000-$000007 read 0000 0400 00C0 0000 (SSP $00000400, PC $00C00000), then writes $0C
rtl/na1/na1_config.sv:15 byte 0 KEYCUS_MODE (0 = no KEYCUS fitted, 1 = ID + changing value) byte 1 KEYCUS_ID low byte 2 KEYCUS_ID high byte 3 KEYCUS_ID_OFFSET in [2:0]; [7:3] must be written 0 (ignored here) byte 4 VIDEO_BASE_FLIP [0] 1 = the board'
rtl/na1/na1_eeprom.sv:1 M6: MAME-compatible NA-1 lower-lane EEPROM transport, $E00000-$E00FFF.
rtl/na1/na1_eeprom.sv:61 The unconnected upper lane is zero in MAME's NA-1 map.
rtl/na1/na1_eeprom_storage.sv:23 That is a genuine hardware mismatch, not a simulation convenience, and it is exactly the state MAME's driver warns about for several NA-1 titles: "when their EEPROM area is uninitialized, the game software automatically writes these values
rtl/na1/na1_gfx.sv:52 MAME's stored-window zero read / ignored write.
rtl/na1/na1_interrupts.sv:5 VBLANK_AT_LINE224=1 is MAME's placement (IRQ4 on the line-224 event), kept for the M11 unit benches.
rtl/na1/na1_interrupts.sv:7 MAME can place it at 224 only because it draws each frame after the fact; every game does its per-frame sprite/scroll/VRAM/register work in this handler, and a line-by-line renderer (like the real board) would show lines 225-255 half- updat
rtl/na1/na1_interrupts.sv:11 [INFERRED] from the games themselves: Emeraldia's posirq split (IRQ4 sets the upper configuration, IRQ3 at line 240 the lower one) only renders MAME's image if IRQ4 precedes the visible window.
rtl/na1/na1_keycus.sv:10 cfg_mode semantics (docs/M28A1_VIDEO_COMPAT.md section 7.2): 8'h00 no KEYCUS fitted -- every read returns 0 (MAME: default 0) 8'h01 constant ID at cfg_id_offset, changing value at every other offset 8'h02 constant ID at cfg_id_off
rtl/na1/na1_keycus.sv:15 `[MAME-CONFIRMED]` custom_key_r NAMCO_TINKLPIT: offset cfg_id_offset (=7) -> cfg_id offset 4 -> resets the 32-bit state to 0, and still answers with the changing value offset 3 -> bitswap<16>(state, 22,26,31,23,1
rtl/na1/na1_keycus.sv:32 That is an [IMPLEMENTATION] compatibility profile -- MAME returns host randomness and the physical generator of every C3xx part remains [UNKNOWN].
rtl/na1/na1_keycus.sv:54 MAME leaves m_keyval uninitialised; `[MAME-CONFIRMED]` Tinkle Pit reads offset 4 first, which forces it to 0, so the cold value is unobservable in practice.
rtl/na1/na1_keycus.sv:87 The changing value advances on EVERY committed read, including ID reads, exactly as MAME advances m_count at the top of custom_key_r before dispatching.
rtl/na1/na1_keycus.sv:103 Writes (including partial lanes/nonzero data) deliberately have no effect -- MAME's custom_key_w is empty for every NA-1/NA-2 game [MAME-CONFIRMED].
rtl/na1/na1_m37702.sv:3 Behavioural contract [MAME-CONFIRMED] = MAME 0.289 src/devices/cpu/m37710/ (m37710op.h opcode macros, m37710il.h EA/stack helpers, m37710.cpp interrupt entry / reset).
rtl/na1/na1_m37702.sv:5 No physical M37702 behaviour has been measured; where MAME is known to deviate from the datasheet (see docs/M20B_IMPLEMENTATION.md section 2) the MAME behaviour is reproduced deliberately, because the F/A BIOS is proven to run on it and the
rtl/na1/na1_m37702.sv:10 Microarchitecture [IMPLEMENTATION]: microsequenced 16-bit core on clk_sys, single little-endian 16-bit bus (byte lanes; a 16-bit access at an odd address is two byte accesses in address order), data accesses issued in MAME's order (push hig
rtl/na1/na1_m37702.sv:14 Every instruction is padded to MAME's CLK cycle count in ce_mcu ticks (static part from na1_m37702_decode, dynamic extras added here) so timers/interrupts stay lock-step with MAME; bus wait states add on top.
rtl/na1/na1_m37702.sv:17 MAME's M37710 executes one CPU cycle per two input clocks (execute_clocks_to_cycles), while timer/A-D periods count input clocks; the core therefore spends one cycle per two ce_mcu ticks and the SFR block counts every tick.
rtl/na1/na1_m37702.sv:26 instr_commit pulses at each instruction boundary (before the interrupt decision): SFR side effects that MAME time-stamps at the end of the writing instruction (timer / A-D starts) are applied there.
rtl/na1/na1_m37702.sv:33 MCU input clock tick (12.528 MHz); one MAME CPU cycle = 2 ticks
rtl/na1/na1_m37702.sv:45 MAME cycles elapsed since reset (2 ce_mcu ticks each)
rtl/na1/na1_m37702.sv:56 MAME index-register view: only the low byte participates when X=1.
rtl/na1/na1_m37702.sv:119 ------------------------------------------------------------ ALU (MAME OP_* semantics) Decimal ADC/SBC low byte (MAME's nibble rule: correct the low nibble of the 8-bit sum when > 9, then the high nibble of the corrected value when > 9), co
rtl/na1/na1_m37702.sv:172 MAME VFLAG_ADD_16(SRC, REG_A, FLAG_C) with FLAG_C holding only the high-byte partial sum: bit 15 of (src^bh)&(acc^bh) = src[15]&acc[15]
rtl/na1/na1_m37702.sv:224 branch condition (MAME COND_*; fz=1 means zero)
rtl/na1/na1_m37702.sv:229 MAME's page-cross test for AX, AY and DIY: (base ^ (base + X)) & 0xff00
rtl/na1/na1_m37702.sv:295 MAME tests the page with X
rtl/na1/na1_m37702.sv:370 TXA/TYA (TXB/TYB): source is MAME's index view (8-bit value when X=1)
rtl/na1/na1_m37702.sv:415 MAME stores N as 0/1 and tests it with &0x80: always clear
rtl/na1/na1_m37702.sv:615 MAME: V = C = quotient (or remainder) does not fit; N cleared when no overflow
rtl/na1/na1_m37702.sv:667 MAME: the CPU sleeps until an interrupt is actually taken
rtl/na1/na1_m37702_decode.sv:1 GENERATED by scripts/m20b-decode.py from the MAME 0.289 m37710op.h opcode tables (TABLE_OPCODES / $42 B-accumulator prefix / $89 MPY-DIV prefix) and CLK_* accounting.
rtl/na1/na1_m3_transport.sv:58 MAME tests full offset==4, not mirrored slot index==4.
rtl/na1/na1_mcu_fa_helper.sv:2 [MAME-CONFIRMED] simulate_mcu clears the whole CPU-visible F60 word at scanline 224.
rtl/na1/na1_mcu_interface.sv:19 The only non-firmware write on the MCU port in this mode is the explicit $F60 compatibility shim: [MAME-CONFIRMED] namcona1's scanline_interrupt() at line 224 asserts MCU IRQ1 and then simulate_mcu() stores 0 into 68000 word $F60 (the "MCU
rtl/na1/na1_mcu_interface.sv:132 M30 version-info shim ([MAME-COMPAT], not a hardware claim).
rtl/na1/na1_mcu_interface.sv:132 Every NA-1/NA-2 game posts its MCU commands in shared byte $F72 (bit 7 = pending) and rings the slot-4 doorbell; [MAME-CONFIRMED] the BIOS IRQ0 handler only runs its $F72 dispatcher when mailbox slot 2 bits 7:6 are set, which no 68000 code
rtl/na1/na1_mcu_interface.sv:137 Knuckle Heads and Numan Athletics additionally issue command 7 and then require the BIOS header ("NSA-BIOS ver1.31") at shared $1000-$100F; MAME papers over this with write_version_info() on a doorbell while $F72's high byte is 7.
rtl/na1/na1_mcu_interface.sv:145 Measured inert for every other target: F/A, Bakuretsu, Exvania, Super World Court, Tinkle Pit and X-Day 2 never ring the doorbell with $F72 = 7; Emeraldia does once, and injecting the header there is byte-for-byte harmless in MAME (identica
rtl/na1/na1_renderer.sv:1 M15B/M19 production F/A renderer: normal 8-bpp tile layers 0..3 and the M19 sprite subset, with MAME's executed NA-1 semantics (docs/M14_RESEARCH.md, docs/M19_IMPLEMENTATION.md), rendered one line ahead of the M15A MAME_COMPAT beam into a d
rtl/na1/na1_renderer.sv:8 replay the per-layer scroll commands of lines 0..L from the current scroll RAM (MAME re-evaluates the whole command list at every partial update; evaluating at raster time from line 0 reproduces that for any store state and needs no write s
rtl/na1/na1_renderer.sv:16 MAME fills its whole bitmap with the backdrop pen, which shows as a coloured border (F/A maroon, Exvania light blue; windows x 9..294 / 8..294).
rtl/na1/na1_renderer.sv:20 Inside the window the backdrop still shows, also with $EFFF8E = 0, as in MAME; 4.
rtl/na1/na1_renderer.sv:22 if $EFFF8E != 0 and the window is valid, draw layers in MAME order (priority 0..7, and layer 3 down to 0 inside one priority; a later layer overwrites and records its priority in the priority map): for each 8-pixel tile row the walker reads
rtl/na1/na1_renderer.sv:30 M19 sprite pass (MAME draw_sprites/pdraw_tile): scan the 256 entries of the bank selected by $EFFF22[0] in index order; for every entry whose 1..8 tile rows cover line L, every visible 1..4 tile column is fetched like a layer row (tile = co
rtl/na1/na1_renderer.sv:39 The output side reads the line buffer on pixel_ce, looks the 12-bit index up in palette port B, expands RGB555 to RGB888 and darkens shadowed pixels by MAME's 0.6 shadow factor ((c*615)>>10 is exact for RGB555 expansions), three clocks behi
rtl/na1/na1_renderer.sv:44 M29 completes the MAME screen_update feature set, generically (no game identity anywhere -- every one of these is selected by NA-1 register state the software writes): * 4-BPP NORMAL TILE LAYERS ($EFFFBC bits 0..3, and bit 4 for ROZ).
rtl/na1/na1_renderer.sv:54 A shadow-flagged sprite whose colour is NOT the special pen is drawn through MAME's second palette interpretation of the same RAM word (RRRGGGBB | RRRGGGBB averaged 1:2), not through RGB555.
rtl/na1/na1_renderer.sv:59 Drawn per pixel with MAME's 16.16 incxx/incxy/incyx/incyy transform and draw_roz_core's cliprect pre-advance, clipped to the 512x512 map (wraparound is off), first within its priority.
rtl/na1/na1_renderer.sv:63 A normal layer whose x-scroll word for the line is exactly $C001 is not drawn from its tilemap on that line: MAME draw_pixel_line (namcona1_v.cpp) takes 152 video-RAM words starting at word ydata+25 (ydata = the layer's line-select word for
rtl/na1/na1_renderer.sv:71 MAME itself calls the $C001 trigger a simplification; this reproduces MAME exactly.
rtl/na1/na1_renderer.sv:90 Games rewrite the register block in their IRQ handlers with longword stores that straddle register pairs, so for ~1-2 us a register can hold a transient half-written value ([MAME-CONFIRMED] Exvania's IRQ4 handler at line 225: $EFFF82 = 0000
rtl/na1/na1_renderer.sv:93 MAME only samples the registers at its screen-update points, never mid-burst; a SNAP that caught the transient invalidated the window for one whole line and drew it as fill (the hardware-observed Exvania blue line).
rtl/na1/na1_renderer.sv:131 MAME priority $FF: above every sprite
rtl/na1/na1_renderer.sv:164 CRTC window programmed and non-empty (MAME screen_enabled)
rtl/na1/na1_renderer.sv:175 [11:0] is the palette index as before; [12] selects MAME's alternate "+$1000" palette interpretation for that pixel.
rtl/na1/na1_renderer.sv:203 M30: 4 bits so the direct-pixel line's MAME priority $FF (PMAP_TOP) can outrank every sprite priority 0..7; every other writer zero-extends.
rtl/na1/na1_renderer.sv:215 MAME's alternate palette pens ($1000..$1FFF) reinterpret the SAME RAM word as two RRRGGGBB bytes and average them 1:2, scaling to 0..255: r = ((w>>5 & 7) + 2*(w>>13 & 7)) * 255 / 21 (g likewise from bits 4..2) b = ((w & 3) + 2*(w>>8 &
rtl/na1/na1_renderer.sv:270 Anything that could make that differ falls back to the full replay: * a scroll RAM write to a line <= target since the last full replay (the full replay would re-read it; MAME re-evaluates from line 0); * a change of the ROZ context (rc0..r
rtl/na1/na1_renderer.sv:296 MAME draw order iteration (4 = ROZ)
rtl/na1/na1_renderer.sv:318 MAME palbase: 4-bpp = {colour[7:4], colour[11:8]} (8 bits, x16 entries), 8-bpp = colour[7:4] (x256).
rtl/na1/na1_renderer.sv:380 One composition rule for both depths (MAME tile_pixel: the 4-bpp planes are bit offsets 4..7, i.e. the low nibble of the same byte).
rtl/na1/na1_renderer.sv:389 ---- ROZ layer 4 ----------------------------------------------------------- MAME draw_roz_core with wraparound off.
rtl/na1/na1_renderer.sv:471 CRTC blank: outside the display window (or with no window programmed) the board outputs black, not the backdrop pen MAME fills its whole bitmap with.
rtl/na1/na1_renderer.sv:529 Scroll command replay, MAME order: lines 0..target ascending, layers 0..3, X then Y. One read per cycle; data is applied one cycle later.
rtl/na1/na1_renderer.sv:532 ROZ line start: seeded on the fourth replay cycle of line 0 (the pipelined z_basex/z_basey above are valid from there) and advanced by incyx/incyy once per replayed line, so it lands on exactly MAME's startx/starty for `target` with no per-
rtl/na1/na1_renderer.sv:562 MAME draw order: priority 0..7, and within one priority ROZ(4) first, then layers 3..0 (a later draw overwrites and owns the priority map).
rtl/na1/na1_renderer.sv:627 M30: the target line's own words decide direct-pixel mode (MAME tests xdata == $C001 on the line being drawn, after applying its scroll).
rtl/na1/na1_renderer.sv:633 We previously implemented only the load half (inherited from MAME's namcona1_v.cpp:491-495, which implements accumulate for X but not for Y), so F/A's service-menu FLIP rendered as corruption: with FLIP on the table is 42ff followed by 255
rtl/na1/na1_rom_board_io.sv:5 X-Day 2's M112 ROM board is the one known instance ([MAME-CONFIRMED] namcona1.cpp xday2_main_map, 0.289 / master):
rtl/na1/na1_rom_board_io.sv:8 $D00000, $D40000 lamp/flash writes -> nopw in MAME.
rtl/na1/na1_rom_board_io.sv:20 Every other address in $C00000-$DFFFFF stays program ROM, exactly as MAME's base map declares, and blitter reads never see this module (MAME's blitter reads m_prgrom directly).
rtl/na1/na1_rom_board_io.sv:30 [IMPLEMENTATION] * hours follow CF bit 2 (1 = 24-hour); in 12-hour mode MAME returns 1..12 with PM in H10 bit 2.
rtl/na1/na1_rom_board_io.sv:33 * W returns the weekday 0..6 (MAME day_of_week - 1, Sunday = 0).
rtl/na1/na1_rom_board_io.sv:34 * CD = (data & 9) on write, BUSY/IRQ-flag read 0 (the IRQ output is not connected on this board and X-Day 2 never unmasks it); CE = data & $F; CF follows MAME's RESET 1->0 rule for the 24/12 bit.
rtl/na1/na1_rom_board_io.sv:36 Power-on/reset values CD=0, CE=6, CF=4 as MAME's device_start.
rtl/na1/na1_rom_board_io.sv:97 ---- read side -------------------------------------------------------------------- 12-hour conversion exactly as MAME (hour from the BCD register).
rtl/na1/na1_rom_cache.sv:4 Why: MAME's NA-1 68000 completes every ROM/work-RAM bus cycle in the minimum four clocks.
rtl/na1/na1_rom_sdram_bridge.sv:4 M29: the mask-ROM backing grew from 4 MiB to the FULL 8 MiB the 68000 window and MAME's own `maskrom` ROM_REGION16_BE declare, because Tinkle Pit really reads past 4 MiB (M28A.1: 252,836 accesses at or above +$400000, max $600A3E).
rtl/na1/na1_rom_sdram_bridge.sv:7 The old `populated` clamp -- which answered $0000 for rom_word_addr[21] -- is therefore gone: every mask word is now backed by SDRAM and the MRA guarantees its contents, padding the unpopulated tail with 00 exactly as MAME's region does.
rtl/na1/na1_scanline_events.sv:1 Replaceable MAME compatibility timebase: 256 lines/frame at 60 Hz.
rtl/na1/na1_sdram_memory.sv:4 M29 widened the mask-ROM backing from 4 MiB to the full 8 MiB of the 68000 window and MAME's `maskrom` region, and relocated the writable regions above it (docs/M28A_RESEARCH.md section 3.2): $000000-$0FFFFF program ROM (bytes $000000-$1
rtl/na1/na1_video_registers.sv:49 M29.4 [HW-CONFIRMED]: system reset is the game's power-on, so IRQ delivery stays off until its first $EFFF1A write (MAME: enable flag 0 until that write).
rtl/na1/na1_video_timing.sv:8 This is MAME's logical screen and is unchanged from M15A: the renderer and na1_interrupts consume only this contract.
README.md:20 Put the MAME ROM zips (MAME 0.289 sets) in **`/media/fat/games/mame/`**.
README.md:30 | Game | MAME set | Year | Genre | Board | Status |
README.md:48 | Game | MAME set | Year | Parent game | Status |
README.md:97 Black borders outside the game's display window, as on the arcade board (MAME fills them with the background colour, e.g. F/A's maroon and Exvania's light-blue
README.md:100 The game's own service-menu FLIP setting works (a true 180° rotation), which does not work in MAME.
README.md:109 MAME's `namcona1` driver (0.289) is the behavioural reference.

Says it matches, follows or was checked against MAME — 4

rtl/na1/na1_blitter.sv:17 Two changes, both making us match MAME exactly: 1.
rtl/na1/na1_board_presentation.sv:28 The NA-1 port BITS are identical for every game (`[MAME-CONFIRMED]`: namcona1_joy and namcona1_quiz differ only in labels), but the CABINET differs -- a joystick panel versus a four-button quiz panel -- and MiSTer maps its own joystick bits
rtl/na1/na1_board_presentation.sv:37 Every NA-1 board wires four identical 8-bit player ports (`[MAME-CONFIRMED]`: :P1/:P2/:P3/:P4 all declare Right/Left/Down/Up + Button 1..3 + Start on the same bits), so the panel mapping below is applied to all four identically and P3/P4 ne
rtl/na1/na1_eeprom_storage.sv:20 Verified against MAME this session: a blank NA-1 EEPROM reads FF for all 2048 bytes.

Keeps a MAME approximation — 1

rtl/na1/na1_c69_sfr.sv:164 MAME's 8 MHz hack: ignored

Shares text with the MAME driver without saying so — 4

rtl/na1/na1_eeprom_storage.sv:25 "when their EEPROM area is uninitialized, the game software automatically — shares text with namco/namcona1.cpp:28
rtl/na1/na1_eeprom_storage.sv:26 writes these values there, but then hangs" (cgangpzl, cgangpzlj, exvania, — shares text with namco/namcona1.cpp:29
rtl/na1/na1_keycus.sv:19 offset 3 -> bitswap<16>(state, 22,26,31,23,18,20, — shares text with namco/namcona1.cpp:283
rtl/na1/na1_keycus.sv:20 16,30,24,21,25,19,17,29,28,27), THEN — shares text with namco/namcona1.cpp:283

NamcoNA2 (yaguboo)#
Bakuretsu Quiz Ma-Q Dai Bouken, Cosmo Gang the Puzzle, Emeraldia, Exvania …
yaguboo/Arcade-NamcoNA2_MiSTer @ afeed270
MAME compared: namco/namcona1.cpp + 4 related file(s)
Read: 24 HDL files, 12,380 lines (all HDL files: no Quartus project found)

yaguboo
repository only

Mostly MAME

high

94%

Statements: 5 toward hardware, 330 toward MAME

Cites hardware documentation that MAME's driver does not — 1

projects/namco/na1_na2/rtl/video/na2_cgmem.sv:501 WRITE_QUEUE=0 resolves every signal here back to the expression it replaced, so that configuration is the shipped netlist unchanged -- and it has to be, because it is the control every sweep is read against.

Notes where it differs from MAME — 4

projects/namco/na1_na2/rtl/na2_top.sv:1062 The board shows 0x24, its own level -- so the board ramps this channel where MAME never does.
projects/namco/na1_na2/rtl/mcu/na2_c70.sv:447 The C70 BIOS's power-on register test depends on it -- with a plain write-through shadow the RTL diverged from MAME at instruction 2,377, taking a branch the real BIOS does not (docs/c70_rtl_boot.md section 5.3).
projects/namco/na1_na2/rtl/mcu/na2_c70_hle.sv:53 This is the piece MAME gets wrong.
projects/namco/na1_na2/rtl/memory/na2_eeprom.sv:29 MAME does not model it either, and the game's own loop above tolerates an instant write.

Cites MAME source — 288

projects/namco/na1_na2/rtl/na2_top.sv:124 Which raw scanline raises the 68000's vblank interrupt: 0 = 224 (MAME), 1 = 240 (FBNeo), 2 = 256 (end of active display).
projects/namco/na1_na2/rtl/na2_top.sv:193 fix/na12-accuracy: 1 = a palette write while graphics are disabled does not change the backdrop colour until graphics come back on, as MAME (rtl/video/na2_bgpal_hold.sv).
projects/namco/na1_na2/rtl/na2_top.sv:590 namcona1.cpp:526 calls blit() from inside vreg_w, so the whole transfer -- every transfer_dword, every gfxram_w, and every read of m_vreg[0x0c/2] inside it -- completes before the CPU's write to the trigger register returns.
projects/namco/na1_na2/rtl/na2_top.sv:593 $0C therefore cannot change part way through a MAME blit: it is frozen by construction.
projects/namco/na1_na2/rtl/na2_top.sv:606 The 68000's own writes to the CG/shape window keep following $0C live, exactly as MAME's gfxram_w does for a CPU write.
projects/namco/na1_na2/rtl/na2_top.sv:618 Measured offline against MAME's captured write stream: on 4,400 attract frames, EVERY one of the 96 256-word shape blits has $0C move 3 -> 2 part way through (207 words each, which then land in CG RAM rather than shape RAM), and 77 of 384 5
projects/namco/na1_na2/rtl/na2_top.sv:733 Work RAM holds 68000 words big-endian, so the byte at an even address is the high half -- the same convention na2_membus loads the download with, and the one MAME's C219 reads through (ENDIANNESS_BIG).
projects/namco/na1_na2/rtl/na2_top.sv:828 the blitter uses the bank its trigger captured; the 68000 uses the live register, as MAME's gfxram_w does for a CPU write
projects/namco/na1_na2/rtl/na2_top.sv:918 na2_video runs the scanline: per-line scroll, backdrop clear, then the tilemap layers in MAME's priority order, into a double-buffered line buffer that is scanned out one pixel ahead.
projects/namco/na1_na2/rtl/na2_top.sv:981 Blitter only, because a 68000 write into the CG/shape window with $0C set to neither 2 nor 3 is discarded by MAME's gfxram_w in exactly the same way -- that is the reference behaviour, not a fault, and putting it on a fault strip would ligh
projects/namco/na1_na2/rtl/na2_top.sv:1004 MAME never exercises that loop.
projects/namco/na1_na2/rtl/na2_top.sv:1004 namcona1.cpp's simulate_mcu() forces m_workram[0xf60/2] = 0 at EVERY vblank, with a FIXME saying it should not be necessary, and it does it even though the real M37710 is running.
projects/namco/na1_na2/rtl/na2_top.sv:1006 So in MAME every handshake succeeds immediately no matter what the MCU did -- which means MAME's captured C219 register stream, the thing this whole investigation has used as ground truth for "what the driver does", comes from a machine whe
projects/namco/na1_na2/rtl/na2_top.sv:1013 In MAME the answer would be one or two per command.
projects/namco/na1_na2/rtl/na2_top.sv:1052 MAME's trace of the scene where the melody is missing has A=0x46BC and B=0x0043 at the next instruction (0x00E253); the board reads A=0x2468 B=0x000A on the same note, at the same sample address and the same pitch.
projects/namco/na1_na2/rtl/na2_top.sv:1060 MAME's settled channel shows 0x46, the channel base the caller loaded; MAME's RAMPING channel 0x5320 shows 0x03, which is its own level.
projects/namco/na1_na2/rtl/na2_top.sv:1071 MAME's trace: X = 0x4600 here, and a few instructions later `LDX $da` makes it 0x1000, voice 0's register base.
projects/namco/na1_na2/rtl/na2_top.sv:1368 44100 is MAME's rate for this chip and the rate everything here is checked against; c140.cpp's own notes say the 219's base pitch is the C352's 42667 Hz.
projects/namco/na1_na2/rtl/na2_top.sv:1441 The board crosses the chip's outputs on the way to the speakers (MAME_VERIFIED, namcona1.cpp: add_route(0, "speaker", 1.00, 1) and add_route(1, "speaker", 1.00, 0)).
projects/namco/na1_na2/rtl/na2_top.sv:1443 Whether that is the PCB's wiring or MAME compensating for something else is UNKNOWN; it is reproduced because it is what the audio this core is checked against does.
projects/namco/na1_na2/rtl/na2_top.sv:1452 The backdrop colour while graphics are off: MAME holds palette writes until graphics return (rtl/video/na2_bgpal_hold.sv).
projects/namco/na1_na2/rtl/na2_top.sv:1548 The game-level timing tools/mame/na12_golden.lua measures in MAME, measured here the same way so the two can be compared number for number (docs/NA12_TIMING_AUDIT.md).
projects/namco/na1_na2/rtl/na2_top.sv:1920 This compared nine bits, so a game that parked a value with bit 8 set would never take the raster interrupt here and would take it in MAME.
projects/namco/na1_na2/rtl/na2_top.sv:1963 Measured in MAME: during an event the game re-triggers every 400 system clocks with 16 or 32 words in flight and never polls a status bit -- that allows 12.5 clocks per word, and this blitter needs about 14, so 555 of 1,521 kicks (36.5 %) w
projects/namco/na1_na2/rtl/na2_top.sv:1997 Measured in MAME (tools/d7_origin.lua): `jsr $c20000.l` at 0xC00028 pushes 0x00C0002E with SP = 0x0007FFFC, and the routine pops it back at
projects/namco/na1_na2/rtl/na2_top.sv:2073 Quiztou's vector table (tools/vectors.lua, read out of MAME at frame 1200) installs nothing: vectors 2-15 and the spurious-interrupt vector 24 are all 0x00000000, and only autovectors 3 and 4 have handlers.
projects/namco/na1_na2/rtl/na2_top.sv:2171 MAME writes D7 exactly twice in that whole block -- 0x00000000 at 0xC22600 and 0x00C0002E at the pop at 0xC2263A -- and never again before the jump (tools/d7_track.lua).
projects/namco/na1_na2/rtl/na2_top.sv:2173 So our core writes it somewhere MAME does not, and nothing outside the CPU can see a register.
projects/namco/na1_na2/rtl/na2_top.sv:2207 C2074A movem.l (sp)+, d0-d7/a0-a6 MAME runs the pair and D7 comes back.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:6 In one line: this is the only open-source 7700-series core that exists, it is production code in a released MiSTer core (Namco System 11's C76, the same m37702m2_device MAME uses for our C70), and it was measured executing our own c70.bin f
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:31 Found by instruction-diffing this core against MAME running the same c70.bin; see docs/c70_rtl_boot.md.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:36 Upstream never needed it because the System 11 BIOS does not use those opcodes -- and the survey that measured "none of the missing opcodes appear in reachable code" was measuring a MAME trace in which command 7 is never serviced, so this c
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:55 d. TAD / TBD set N and Z; MAME's OP_TAD sets no flag.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:56 e. MPY set N from the product's top bit; MAME always clears it.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:57 f. DIV set N from the quotient; MAME clears it (and leaves it alone on overflow).
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:64 The check is sim/tb_na2_m37702_ops.sv + sim/run_ops.sh (9,324 directed vectors, oracle tools/ops_model.py, mutation test tools/ops_mutants.py -- 31 of 31 seeded faults caught); docs/m37702_ops_check.md has the reference semantics, the evide
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:69 the long-indirect addressing modes added -- [dp] and [dp],Y. Upstream had no 24-bit-pointer effective-address plumbing on any page, so 07/17/27/37/47/57/67/77/87/97/A7/B7/C7/D7/E7/F7 on the base page, the same sixteen on the 0x42 page (MAM
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:88 [dp],Y adds Y to the whole 24-bit address with carry into the bank, because MAME's EA_DLIY() (m37710il.h:202) adds REG_Y to a uint32_t and masks nothing.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:133 Timer A2 tick (1-cycle pulse); vector 0xFFEA -- NA2: was 0xFFF0 in the comment; the code arms 0xFFEA, which is what MAME says
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:166 The sound driver computes a voice's volume as `MPY $30,X` at 0x00E250, and MAME's own trace of the scene where the melody is missing has A=0x46BC B=0x0043 immediately afterwards while the board plays that note at a volume of 1.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:203 HOLD_LINE semantics for the EXTERNAL INT0/INT1/INT2 pins: MAME asserts these via set_input_line(HOLD_LINE) from 60 Hz timers and the line stays asserted until the CPU ACKNOWLEDGES (takes) the IRQ.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:234 For [dp],Y the Y index is added to the whole 24-bit address and carries into the bank: MAME m37710il.h:202 EA_DLIY() = OPER_24_D() + REG_Y, no masking.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:291 Dividend B:A is left-aligned in div_num and shifted into the partial remainder; div_quot accumulates the FULL 2w-bit quotient (needed for MAME's overflow test).
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:477 Timer A2 (MAME m37710_irq_vectors)
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:546 Full MAME 89-page dispatch (m37710op.h OP(201..21f)): dxi,s,d,dli,imm,a,al,diy,di,siy,dx,dliy,ay,ax,alx.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:548 NA2 modification 6 added dli(07)/dliy(17), so every mode MAME lists is now dispatched here and the 89 page has no halt arm left.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:568 DIV (unsigned): B:A / SRC -> quotient A, remainder B. MAME 89-page dispatch (m37710op.h OP(22x/23x)): dxi,s,d,dli,imm,a,al, diy,di,siy,dx,dliy,ay,ax,alx.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:570 NA2 modification 6 added dli(27)/dliy(37); every mode MAME lists is dispatched here now.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:572 NOTE: MAME's 89 page has NO signed DIVS — MPYS/DIVS are 7750-block opcodes (28x-2bx) that MAME leaves unimplemented; unsigned only.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:592 MAME's OP_XAB with FLAG_SET_M swaps m_a with m_ba only, so in 8-bit mode the two HIGH bytes stay where they are: A=0x1234 B=0x5678 becomes A=0x1278 B=0x5634, not A=0x5678 B=0x1234.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:633 MAME splits each accumulator into m_a/m_b and each index into m_x/m_xh, so in 8-bit mode a transfer moves ONE BYTE and leaves the other half of the destination alone (m37710op.h OP_TAX / OP_TBX / OP_TXA / OP_TXB, all four M/X variants).
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:637 sim/tb_na2_m37702_ops.sv measured the difference: TXA with M=1, A=0x1234, X=0x0010 gave A=0x0010 here and A=0x1210 in MAME.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:656 NA2: TAD/TBD set N and Z here and MAME's OP_TAD/OP_TBD set no flag at all.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:708 (MAME OP_PHP/OP_PLP push/pull two bytes unconditionally.) A 1-byte PLP left the C76's TB1-ISR stack off by one (LDA #imm16/PHA/PLP idiom) -> RTI derailed -> the mailbox was never serviced.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:933 The 0x42 page re-decodes through this same case with use_b='1', which is what gives MAME's ORB/ANDB/EORB/ ADCB/STB/LDB/CMPB/SBCB dli+dliy (OP 107..1f7).
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:1051 [dp] and [dp],Y form the pointer address exactly as (dp) does -- MAME EA_DLI() is OPER_24_D(), and OPER_24_D()'s address is EA_D(), the same one (dp) uses.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:1118 ea still holds the direct-page pointer address here, so +2 is that address, not the target -- same arithmetic MAME does in m37710i_read_24_direct (address, address+1, address+2).
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:1136 For [dp],Y the index is added to the full 24-bit address and is allowed to carry out of the bank, because MAME's EA_DLIY() adds REG_Y to a uint32_t with no mask.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:1180 M37710 JMP/JSR (abs,X): pointer table lives at PG:(abs+X) — MAME read_16_AXI(REG_PG | u16(abs + REG_X)).
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:1187 Caught by diffing this core against MAME running the same c70.bin: at the C70's interrupt dispatcher JSR ($8160,X), X=0x1A, MAME read [0x817A] = 0xD8C8 and this core read [0x8194] = 0xCFD5.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:1243 MAME m37710 OP_RLA rotates REG_A only and does NOT touch any flags (N/Z/C unchanged) — so NO set_nz here (corrupting flags caused a mis-branch -> derail to the 0xC000 BIOS string).
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:1327 1 : 0` and m37710il.h reads N back as `FLAG_N & 0x80`, so that 1 can never set it: MAME's MPY always leaves N clear.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:1329 It is visible in MAME's own attract trace -- 5 of 321 multiplies produce a product with bit 15 set and N is clear after every one of them.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:1332 MAME is the reference of record here AND is the only implementation measured to play this game's in-game music, so matching it is the safe direction.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:1345 (89-page) unsigned divide, per MAME OP_DIV (m37710op.h): m=0: (B<<16|A) / SRC16 ; m=1: ((B&FF)<<8|(A&FF)) / SRC8 quotient -> A (truncated to w), remainder -> B; V=C=1 on quotient overflow (N then unchanged), Z from truncated quot.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:1351 zero divide: MAME m37710i_interrupt_software(0xfffc) pushes PG, PC (past the operand), IPL, PS, sets I, PG=0, PC=[FFFC].
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:1353 (Shared entry path also clears D and re-loads IPL; MAME's software trap leaves both alone, so pass the current IPL.)
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:1394 synthesis translate_on writeback per MAME OP_DIV; remainder is exact (< divisor), quotient is the full 2w-bit value truncated to w for A. NA2: on a non-overflowing divide N is CLEARED, for the same reason as MPY above -- OP_DIV writes `FLAG
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:1400 On overflow MAME skips the assignment altogether, so N keeps its previous value; both branches below already do that.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:1631 X and Y need no such care: MAME's debugger reports m_x, which an 8-bit pull leaves in 0x00..0xFF, and that is what operand holds.
projects/namco/na1_na2/rtl/mcu/na2_c70.sv:27 RESEARCH.md section 2 records an LH5168 (8K x 8) on the PCB, but MAME maps 32 KiB and the game's own mailbox command 3 uploads a block to 0x8A00, which is past the end of 8 KiB.
projects/namco/na1_na2/rtl/mcu/na2_c70.sv:40 This is the same swap tools/c219_ref.py applies to the captured MAME writes that rtl/sound/na2_c219.sv was verified against.
projects/namco/na1_na2/rtl/mcu/na2_c70.sv:58 MAME_VERIFIED, and the units matter: namcona1.cpp instantiates the C70 at MASTER_CLOCK/4, and m37710.h:209 then divides that by two before executing anything, so instructions run at 6.2641 MHz.
projects/namco/na1_na2/rtl/mcu/na2_c70.sv:64 Timers are the part that has to be right, and MAME counts them off the UNDIVIDED XIN (m37710.cpp:520,547 use clocks_to_attotime).
projects/namco/na1_na2/rtl/mcu/na2_c70.sv:65 `mcu_ce` is therefore XIN here and na2_m37702_periph counts timers on it, which puts the sound driver's Timer A0 at 64 * 0x65B = 104128 clocks = 120.31 Hz, MAME's own number.
projects/namco/na1_na2/rtl/mcu/na2_c70.sv:125 $08,X 0x4608 the channel is alive MAME 0x80 $12,X 0x4612 envelope program pointer, 16 MAME 0x040A (into 68000 RAM) $14,X 0x4614 envelope fraction MAME 0x50 $15,X 0x4615 envelope LEVEL MAME 0xFF,
projects/namco/na1_na2/rtl/mcu/na2_c70.sv:135 The board plays the melody at a sixth of MAME's level; these taps say whether the level is being ramped to a different TARGET or is failing to reach the same one.
projects/namco/na1_na2/rtl/mcu/na2_c70.sv:143 The ramp was cleared: our core executes all thirteen of its instructions exactly as MAME does (54/54, tools/bgm_ramp_gen.py), yet the board holds the level at 0x24 for nineteen seconds in a state where MAME would move it to 0x1A.
projects/namco/na1_na2/rtl/mcu/na2_c70.sv:158 esram[0x6420] -- list head, MAME 0x4600
projects/namco/na1_na2/rtl/mcu/na2_c70.sv:159 iram[0x0120] -- dispatch, MAME 0xE1AA
projects/namco/na1_na2/rtl/mcu/na2_c70.sv:162 00DBC3 LDA $06,X ; the fade control, esram[0x4006] MAME 0x80
projects/namco/na1_na2/rtl/mcu/na2_c70.sv:164 00DBC7 BEQ 00dbef ; zero -> clear the attenuation MAME's path
projects/namco/na1_na2/rtl/mcu/na2_c70.sv:168 MAME never reaches 0x00DBCC in any of five captures.
projects/namco/na1_na2/rtl/mcu/na2_c70.sv:176 Why it is defensible rather than a patch over ignorance: the cause is known in full (section 21), and MAME reaches the instruction that installs that attenuation, 0x00DBCC, in NONE of five captures while its melody voice stays audible 99.3
projects/namco/na1_na2/rtl/mcu/na2_c70.sv:269 MAME implements one uniform swapped rule and that is exactly why its C70 "never responds to the version string command": with the words swapped, command 7 reads src=0x00C0 len=0x1000 dst=0x0010 instead of src=0xC000 len=0x0010 dst=0x1000.
projects/namco/na1_na2/rtl/mcu/na2_c70.sv:279 The page has now been OBSERVED, in MAME, both ways round in the same frame (tools/bgm_lane.lua): a 16-bit MCU read at 0x2840 yields 0x2820 where the 68000's own bytes at 0x0840/41 are 0x20 0x28.
projects/namco/na1_na2/rtl/mcu/na2_c70.sv:292 Flipping gave 0x2028 instead of 0x2820, so the driver read its fade byte out of the wrong block: 0x85 where MAME reads 0x80, whose low bits put it into a fade, whose attenuation of 0x50 turned every melody volume into silence.
projects/namco/na1_na2/rtl/mcu/na2_c70.sv:386 MAME 0xE1AA.
projects/namco/na1_na2/rtl/mcu/na2_c70.sv:409 Little-endian, MAME 0x4600.
projects/namco/na1_na2/rtl/mcu/na2_c70.sv:446 MAME_VERIFIED, c140.cpp: data = (v.key ?
projects/namco/na1_na2/rtl/mcu/na2_c70.sv:498 MAME models the mailbox as eight symmetric 16-bit slots, reads 0x0000 here, and therefore never services a single command -- which is what its own FIXME in mcu_mailbox_w_68k is describing.
projects/namco/na1_na2/rtl/mcu/na2_c70.sv:540 See the long note in that file; in short, a board that cannot do this needs a canned EEPROM for every set that programs its own, which is exactly the list in MAME's To-Do.
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:36 P8 0x12/0x14 dir=0xBB at C06A; bit 5 toggled at C13F/C143, C16B, C18E, C277, C534, C5BC, C5F7 (MAME: "watchdog?").
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:80 The registers read back; no interrupt is ever generated, which is what MAME does too.
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:88 Modelled exactly as MAME does: the registers hold their values, the receive buffer reads 0, and no UART interrupt is ever raised.
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:90 MAME runs the game this way, so the BIOS does not depend on a transmit-empty flag -- but that is MAME_VERIFIED, not HW_CONFIRMED, and it is the most likely place for this module to hang if it ever does.
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:96 No watchdog reset is generated (MAME does not either) -- a watchdog that never fires cannot hang the BIOS, one that fires early can.
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:127 MAME_VERIFIED (namcona1.cpp port6_w / port7_r) and independently ROM_DISASM_CONFIRMED from the BIOS's own polling routine at 0x00D26E (RESEARCH.md section 13 quotes it in full):
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:142 Two independent sources agreeing on the same four select values is unusually good evidence, so this is the one part of this file that is not "MAME says so".
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:165 The scramble and the read order are inverses of each other, which is what a reassembly routine has to look like, so both are now confirmed from the ROM as well as from MAME.
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:180 That was never really unknown: MAME runs the same M37702 on the same c70.bin and player 3 works there, so the BIOS does the reassembly (it is ROM_DISASM_CONFIRMED at 0xD202-0xD23A below) and puts the result somewhere the game finds.
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:194 If the real BIOS ever polls that flag on a path MAME does not take, this block will spin there.
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:248 --- I/O ports P0-P8 ---------------------------------------------------- MAME_VERIFIED (m37710.cpp m37702m2_device::map): the port registers live at 0x02-0x15 on even bytes for P0/P2/P4/P6/P8 and 0x03-0x11 on odd bytes for P1/P3/P5/P7, data
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:252 In m37710.cpp's own terms: p = (offset & ~1) + Base, and BIT(offset,0) selects the direction register.
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:260 last byte written, raw (m37710.cpp m_port_regs)
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:263 The board-side latches namcona1.cpp keeps for the pins it drives.
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:263 MAME only calls the out callback when the direction register is non-zero and masks the data with it (set_port_reg), so a write while the port is still all-inputs never reaches the pin.
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:284 din & p_dir[p_idx], what MAME hands the callback
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:286 --- A-D converter ------------------------------------------------------ MAME_VERIFIED (m37710.cpp ad_register_map / ad_control_w / ad_timer_cb): 0x1E ad_control b7 clock (0 = f2/4, 1 = f2/2), b6 start/busy, b4 sweep, b3 repeat, b2:0 chann
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:314 --- timers ------------------------------------------------------------- MAME_VERIFIED (m37710.cpp timer_register_map, m37710_recalc_timer, m37710_timer_cb): 0x40 count start bit i enables timer i 0x42 one-shot start (write only) 0x44 up/
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:341 --- interrupt controller ---------------------------------------------- MAME_VERIFIED (m37710.cpp int_control_r/w and m37710i_update_irqs): one byte per source, bits 2:0 priority, bit 3 request, and for the three external INT lines bit 4 po
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:344 Indexed here by the M37710_LINE_* number (reference/mame/m37710.h), because the CPU core derives its vector from that number: vector = 0xFFCE + 2 * line.
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:427 MAME_VERIFIED (namcona1.cpp c70() an0_cb..an7_cb -> portana_r<Bit>) and ROM_DISASM_CONFIRMED by the reassembly order at 0xD202-0xD23A: AN0<-bit6 AN1<-bit5 AN2<-bit4 AN3<-bit0 AN4<-bit1 AN5<-bit2 AN6<-bit3 AN7<-bit7 portana_r returns 0xFFFF
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:448 MAME_VERIFIED (namcona1.cpp port7_r): if ((m_mcu_port6 & 0x80) == 0) return m_muxed_inputs[m_mcu_port6>>5]; else return 0xff; with m_muxed_inputs = { P4, DSW, P1, P2 }.
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:464 The "pin" side of each port, i.e. what MAME's in callback returns.
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:489 MAME_VERIFIED (namcona1.cpp machine_reset): m_mcu_port4 = 0 and m_mcu_port5 = 1.
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:503 MAME_VERIFIED (m37710.cpp set_port_reg): the out callback fires only when the direction register is non-zero, and it is handed (data & dir), not data.
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:508 MAME_VERIFIED (namcona1.cpp port4_w).
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:515 MAME_VERIFIED (namcona1.cpp port5_w): m_mcu_port5 = data; m_mcu_port5 &= 0xfe; m_mcu_port5 |= ((m_mcu_port5 & 0x2) >> 1); MAME's own comment is "not sure yet, but MCU code requires this interaction at least", so this is MAME_VERIFIED and no
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:528 MAME_VERIFIED (namcona1.cpp port8_w).
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:543 MAME_VERIFIED (m37710.cpp ad_control_w and ad_timer_cb).
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:663 MAME latches the whole period when the timer is started (m_reload[timer]) and never looks at the register again; the real part reloads the counter from the register at every underflow.
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:704 MAME_VERIFIED: proc_mode_r returns the register masked with 0xF7; watchdog_timer_w (0x60) is a kick with no timer behind it in MAME either, and watchdog_freq (0x61) is a plain register.
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:711 It was NOT true of this register, and that omission is what makes seven sets in this family need a canned EEPROM in MAME.
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:721 MEASURED in MAME, quiztou, 1800 frames, blank 28C16 against factory image (tools/procmode.lua, tools/deadman.lua):
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:730 So the game finishes programming a blank EEPROM -- byte-for-byte the image MAME ships, cmp reports no differences -- and then deliberately stops feeding the switch to ask for a reset.
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:734 0x15 is the normal mode and 0x1D is 0x15 with bit 3 set, and MAME's own proc_mode_r masks that bit off on read (`& 0xf7`, m37710.cpp:879), which is what a write-only self-clearing reset bit looks like.
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:736 MAME latches the byte and does nothing (m37710.cpp:882-886), so its board never resets and the game sits on the NOTICE screen forever -- which is the whole reason for "Canned EEPROM data ...
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:742 Three things agree meanwhile: the BIOS writes exactly this value at exactly this moment, MAME masks exactly this bit on read, and a machine reset applied at that moment makes the game boot (tools/watchdog_test.lua -- attract mode, INSERT CO
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:827 namcona1.cpp never calls set_input_line(M37710_LINE_IRQ2), although c70.bin does give 0x7F a priority of 4 at 0xC0E7 and clears its request bit at 0xC0EA, so the pin may well be wired to something not yet identified.
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:890 m37710.cpp keeps the pending set in LINE_IRQ and its int_control_w touches neither direction, so in MAME a write can neither set nor clear a request; the readable bit 3 just goes stale.
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:905 MAME_VERIFIED (namcona1.cpp): a 68000 write to mailbox slot 4 raises M37710_LINE_IRQ0 (= line 19) and vblank raises M37710_LINE_IRQ1 (= 18).
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:947 write-only in MAME; we read back
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:959 write-only in MAME
projects/namco/na1_na2/rtl/mcu/na2_c70_hle.sv:12 c70.bin at 0x00C62E, with the data bank register set to $20 (the shared work RAM window): LDM #$0000, $0000 LDM #$0004, $0002 LDM #$C000, $0004 LDM #$0000, $0006 then at 0x00C646 "LDM #$0C,$0A" sets port P4 bit 3, which MAME's port4
projects/namco/na1_na2/rtl/mcu/na2_c70_hle.sv:53 MAME's simulate_mcu() writes workram[0x0F60] = 0 once per frame and its own comment says "FIXME: These two functions shouldn't be necessary?".
projects/namco/na1_na2/rtl/mcu/na2_c70_hle.sv:395 MAME raises MCU IRQ1 at vblank and the BIOS polling routine at 0x00D26E is the obvious consumer, but the call site has not been traced yet, so the *rate* is an assumption even though the addresses are confirmed.
projects/namco/na1_na2/rtl/memory/na2_eeprom.sv:5 MAME_VERIFIED: namcona1.cpp namcona1_main_map has map(0xe00000, 0xe00fff).rw("eeprom", ...).umask16(0x00ff); and the machine config instantiates EEPROM_2816.
projects/namco/na1_na2/rtl/memory/na2_eeprom.sv:36 A real erased 28C16 reads 0xFF everywhere, and numanath ships no default EEPROM image in MAME (unlike Cosmo Gang the Puzzle and others, which ship one "otherwise game would lock up on 1st boot").
projects/namco/na1_na2/rtl/memory/na2_eeprom.sv:52 MAME_VERIFIED, measured this session and not read out of a source file: starting numanath in MAME with no nvram file at all, the 2 KiB behind 0xE00001 has become byte-for-byte identical to nvram/numanath/eeprom by frame 200 (0 differing byt
projects/namco/na1_na2/rtl/memory/na2_eeprom.sv:63 The bytes are not invented -- they are exactly what this game writes into a blank part on its own, captured from a local MAME run (see LICENSE_NOTES.md), so the machine state after the first frames is the same either way.
projects/namco/na1_na2/rtl/memory/na2_eeprom.sv:191 The rest of the word is not driven by anything, and MAME hands back zero for it.
projects/namco/na1_na2/rtl/keycus/na2_keycus.sv:21 MAME_VERIFIED: namcona1.cpp custom_key_r is, for every set in this family, two rules and nothing else -- offset == the set's identity offset -> the identity word anything else -> machine().rand() (the switch return
projects/namco/na1_na2/rtl/keycus/na2_keycus.sv:44 Running MAME's algorithm reproduces FBNeo's table exactly, 32 of 32, so the shift order, the bitswap order and the feedback condition are all confirmed twice over.
projects/namco/na1_na2/rtl/keycus/na2_keycus.sv:54 MAME uses the host RNG and additionally forces two consecutive reads to differ; FBNeo uses its own "guaranteed_rand".
projects/namco/na1_na2/rtl/keycus/na2_keycus.sv:78 Chosen because it never repeats a value on consecutive reads, which is the only property MAME's implementation actually guarantees.
projects/namco/na1_na2/rtl/keycus/na2_keycus.sv:96 The order matters and is MAME's: the value handed back is computed from the register BEFORE the step, and the feedback test looks at the register AFTER it.
projects/namco/na1_na2/rtl/keycus/na2_keycus.sv:129 The identity wins, as it does in MAME's switch: Tinkle Pit's identity is at offset 7 and its algorithm at offset 3, so the two never collide.
projects/namco/na1_na2/rtl/cpu/na2_m68k.sv:65 MAME models no wait states, and nothing on the NA-2 PCB is known to insert them (UNKNOWN -- PCB_VERIFICATION_NEEDED), so the game lost that time only here: Numan Athletics' main loop overran frames MAME finishes, and on those frames its vbl
projects/namco/na1_na2/rtl/cpu/na2_m68k.sv:108 Autovector every interrupt: the NA-1/NA-2 68000 has no vector generator, MAME raises levels 3 and 4 with HOLD_LINE which is autovectored.
projects/namco/na1_na2/rtl/video/na2_palette.sv:4 Each entry is read two ways (MAME_VERIFIED: namcona1_state::update_palette in namcona1_v.cpp, FBNEO_CROSSCHECK: palette_update_entry in d_namcona1.cpp -- identical arithmetic):
projects/namco/na1_na2/rtl/video/na2_palette.sv:12 MAME builds both interpretations into one 8192-entry pen table: pens 0x0000-0x0FFF are the normal reading and 0x1000-0x1FFF the alternate one.
projects/namco/na1_na2/rtl/video/na2_palette.sv:16 MAME says the alternate form is used in-game by Emeraldia; it costs almost nothing to support, so it is here.
projects/namco/na1_na2/rtl/video/na2_palette.sv:41 What is established is that MAME does, and that this game leans on the path -- the attract mode keeps sprites with colour word 0x7FFE on screen for seconds at a time.
projects/namco/na1_na2/rtl/video/na2_palette.sv:44 MAME's own TODO says "non-shadow pixels for sprites flagged to enable shadows have bad colors", so the corner is not settled upstream either.
projects/namco/na1_na2/rtl/video/na2_palette.sv:95 MAME truncates: n * 0xff / (0x3*3), integer division.
projects/namco/na1_na2/rtl/video/na2_sprite.sv:4 Runs after every tilemap for the line, exactly where MAME's screen_update() calls draw_sprites().
projects/namco/na1_na2/rtl/video/na2_sprite.sv:52 64 dropped sprites in five shipped sets (KNOWN_ISSUES RISK-9); Emeraldia's high-score table lost visible text against MAME.
projects/namco/na1_na2/rtl/video/na2_sprite.sv:76 UNKNOWN: whether the real hardware darkens by MAME's 0.6.
projects/namco/na1_na2/rtl/video/na2_sprite.sv:76 What is measured is that MAME does -- a frame of the attract mode disagreed with this renderer on 422 pixels, every one of them on a sprite with colour word 0x7FFE, until this was implemented (tools/mame_check.sh).
projects/namco/na1_na2/rtl/video/na2_sprite.sv:196 Measured: ten frames of the Turbo Dash event across four MAME runs, 731 differing pixels each, all of them on opaque sprites carrying the shadow bit -- 0 with this one line.
projects/namco/na1_na2/rtl/video/na2_sprite.sv:208 code = (tile + (row << 6) + col) & 0xFFF, which is MAME's `code % gfx->elements()`: CG RAM holds exactly 0x1000 cells of 64 bytes.
projects/namco/na1_na2/rtl/video/na2_sprite.sv:218 MAME: tile-word bit 15 forces an opaque cell, which this folds in.
projects/namco/na1_na2/rtl/video/na2_sprite.sv:223 MAME: sx = (xpos & 0x1ff) - 10 + delta*8, then ((sx + 16) & 0x1ff) - 8.
projects/namco/na1_na2/rtl/video/na2_sprite.sv:290 MAME's draw_sprites() does `source += 0x400` on a u16*, i.e. the bank selects a 0x400-WORD half of object RAM, not 0x200.
projects/namco/na1_na2/rtl/video/na2_sprite.sv:291 With the shift one place short, sprite n in bank 1 read MAME's sprite n-128 and MAME's sprites 128-255 were never read at all.
projects/namco/na1_na2/rtl/video/na2_sprite.sv:344 Measured 2026-08-30 on a real MAME frame through the Pocket CG path: sprite starts 448, busy 0 cycles, sp_cg_stall high for all 896 cycles of the window, peak sprites 0.
projects/namco/na1_na2/rtl/video/na2_crtc.sv:16 Line numbering follows MAME's `m_screen->vpos()` so that the posirq comparison against vreg $8A means the same thing here as there.
projects/namco/na1_na2/rtl/video/na2_crtc.sv:21 FBNEO_CROSSCHECK: d_namcona1.cpp draw_layer() iterates raw y 0..255 and writes `pTransDraw + (y - 32) * nScreenWidth`, i.e. raw line 32 is the first visible line.
projects/namco/na1_na2/rtl/video/na2_crtc.sv:35 MAME gets away with 224 because it draws everything above the posirq line in one pass AT scanline 240, after the handler has run; a scanline renderer cannot.
projects/namco/na1_na2/rtl/video/na2_crtc.sv:68 This is an open question, not a setting: MAME uses 224 and FBNeo 240, both of which land inside the visible region (raw 32..255), and neither has any hardware backing.
projects/namco/na1_na2/rtl/video/na2_crtc.sv:77 0 = 256 (end of active display, the measured answer) 1 = 224 (MAME) 2 = 240 (FBNeo)
projects/namco/na1_na2/rtl/video/na2_video.sv:8 Written from reference/mame/namcona1_v.cpp screen_update()/draw_background() and reference/fbneo/d_namcona1.cpp DrvDrawTo()/draw_layer(), read directly rather than from a paraphrase.
projects/namco/na1_na2/rtl/video/na2_video.sv:23 MAME wraps the scrollx update in `if (xdata)`; FBNeo does not.
projects/namco/na1_na2/rtl/video/na2_video.sv:23 The two are the same function: when xdata is 0 the 0x4000 branch cannot be taken and `xdata & 0x1ff` is 0, so MAME's guard changes nothing.
projects/namco/na1_na2/rtl/video/na2_video.sv:27 A layer whose per-line scroll word is exactly 0xC001 does not draw its tilemap at all: that scanline comes straight out of video RAM as packed 8-bit pixels (`na2_pixline`, MAME's draw_pixel_line()).
projects/namco/na1_na2/rtl/video/na2_video.sv:29 It replaces that layer's turn in the priority loop and nothing else, except that it declares every pixel of the line off-limits to sprites -- MAME writes 0xff into the priority buffer across the whole width, which here is "set every occupan
projects/namco/na1_na2/rtl/video/na2_video.sv:33 MAME calls the trigger condition itself unproven; keep the UNKNOWN.
projects/namco/na1_na2/rtl/video/na2_video.sv:46 The ROZ sampling point is accumulated per line the same way the tilemap scroll is, and for the same reason -- MAME evaluates `startx + x*incxx + y*incyx` for absolute screen coordinates, so a per-line adder reproduces it exactly and costs n
projects/namco/na1_na2/rtl/video/na2_video.sv:49 The base is reloaded at the frame wrap, which is where MAME's screen_update() reads the registers.
projects/namco/na1_na2/rtl/video/na2_video.sv:72 The display window (MAME `display_rect`, FBNeo `clip`) is x from vreg[$80]-0x48 to vreg[$82]-0x48-1 y from max(vreg[$84], 32) to min(vreg[$86]-1, 255) and nothing is drawn at all if it is empty or starts negative (MAME screen_enabled(), FBN
projects/namco/na1_na2/rtl/video/na2_video.sv:230 The frame's last line wraps round to raw line 0 and resets the scroll accumulators, exactly where MAME's `for (line = 0; ...)` starts over.
projects/namco/na1_na2/rtl/video/na2_video.sv:245 MAME draws a whole frame (or a posirq half) from one snapshot, so a register the game changes part way down the picture is invisible to any frame-by-frame comparison -- by construction, no matter how far apart the two pictures really are.
projects/namco/na1_na2/rtl/video/na2_video.sv:310 MAME reads that bit once, when it draws the frame.
projects/namco/na1_na2/rtl/video/na2_video.sv:322 0 = live (what this core has always done, and what MAME's source reads literally) 1 = latched at the top of the frame
projects/namco/na1_na2/rtl/video/na2_video.sv:393 MAME_VERIFIED / FBNEO_CROSSCHECK, both identical: inc* = (s16)reg << 8, start = (offset << 12) + incxx*46 - incyx*8 46 and -8 are MAME's `dx` and `dy` screen adjustments.
projects/namco/na1_na2/rtl/video/na2_video.sv:620 Sprites deliberately do not update it: occupancy already blocks every later sprite, and MAME's 0xff is not a priority value anything compares against afterwards.
projects/namco/na1_na2/rtl/video/na2_video.sv:675 MAME writes 0xff across the whole width of a pixel line, which is the value sprites refuse to draw over
projects/namco/na1_na2/rtl/video/na2_video.sv:753 MAME checks the raw scroll word for 0xC001 *after* letting it through the scrollx accumulator, so the accumulation below is unchanged; only the draw for this layer is replaced.
projects/namco/na1_na2/rtl/video/na2_video.sv:765 MAME fills the backdrop over the whole cliprect and only then restricts drawing to display_rect, so a line outside the window shows the backdrop -- not, as this used to, whatever the line buffer happened to hold from two lines ago.
projects/namco/na1_na2/rtl/video/na2_video.sv:787 ---- layers, in MAME's order ---------------------------------
projects/namco/na1_na2/rtl/video/na2_video.sv:830 ---- sprites, after every tilemap, as MAME does ---------------
projects/namco/na1_na2/rtl/video/na2_cgmem.sv:149 That is not a defect -- the CPU and the video hardware are not synchronised on real hardware either, and MAME draws the frame-end snapshot -- but it does mean the old gate cannot judge this.
projects/namco/na1_na2/rtl/video/na2_bgpal_hold.sv:8 While graphics are off MAME draws nothing but the backdrop pen, (vreg[0xBA] & 0xF) << 8 (namcona1_v.cpp:559-561), so the only colours that can be seen held are those sixteen entries.
projects/namco/na1_na2/rtl/video/na2_bgpal_hold.sv:13 FBNeo updates the colour immediately (d_namcona1.cpp:445-456), which is what this core did before.
projects/namco/na1_na2/rtl/video/na2_bgpal_hold.sv:16 TODO(HARDWAREIZE): does the board transfer palette RAM to the DAC only while the display is enabled, or is this MAME's own economy?
projects/namco/na1_na2/rtl/video/na2_bgpal_hold.sv:19 Why it is here: Numan Athletics, during a scene load with graphics off, writes 0xE7E7 and 0.3 ms later 0x0000 to entry 0xF00 -- the backdrop (C11C22 / C11C34, MEASURED(MAME) frames 4200, 4204, 7548, 7551).
projects/namco/na1_na2/rtl/video/na2_bgpal_hold.sv:25 Not reproduced: MAME rebuilds only when graphics are enabled AND the display window is non-empty (namcona1_v.cpp:561).
projects/namco/na1_na2/rtl/video/na2_bgpal_hold.sv:27 While graphics are enabled palette writes are shown immediately in both, so the difference is confined to a frame whose window is empty -- where the backdrop is all there is and MAME would show the held colour a frame longer.
projects/namco/na1_na2/rtl/video/na2_bgpal_hold.sv:47 what MAME's palette device holds for them
projects/namco/na1_na2/rtl/video/na2_bgpal_hold.sv:69 graphics just came on: MAME's rebuild of the whole palette.
projects/namco/na1_na2/rtl/video/na2_blitter.sv:66 MAME blit_setup(): "bytes per row" and "pitch" for a format word.
projects/namco/na1_na2/rtl/video/na2_blitter.sv:69 The `default` rows are `(64 - (format >> n)) << m` in MAME, computed in `int`.
projects/namco/na1_na2/rtl/video/na2_blitter.sv:110 MAME transfer_dword() accepts exactly these ranges and aborts the whole blit on anything else.
projects/namco/na1_na2/rtl/video/na2_blitter.sv:124 namcona1.cpp:355 also accepts `dest >= 0xf00000*2 && dest < 0xf02000*2` -- 0x1E00000-0x1E03FFF -- which its own comment calls an assumed palette mirror for xday2, and it TRANSLATES that address back to palette RAM before writing.
projects/namco/na1_na2/rtl/video/na2_blitter.sv:169 MAME folds a destination below 0xF00000 up into the gfx window once, before the loop.
projects/namco/na1_na2/rtl/video/na2_linebuf.sv:5 Each entry carries the pen and the priority value that wrote it, which is what MAME keeps in its separate `screen.priority()` bitmap: layers are drawn in increasing priority order and each stamps its own priority, then sprites draw over a p
projects/namco/na1_na2/rtl/video/na2_dbg.sv:48 MAME 0xFFFF in the scene where the board plays it too quietly.
projects/namco/na1_na2/rtl/video/na2_dbg.sv:51 MAME 0x040A, into the 68000's work RAM at 0x270000.
projects/namco/na1_na2/rtl/video/na2_dbg.sv:89 Row 29 (4 px) the melody channel's {alive flag ($08,X, MAME 0x80), frames until its envelope advances again ($2D,X)}.
projects/namco/na1_na2/rtl/video/na2_dbg.sv:92 MAME 0x4600 -- the melody channel is the FIRST one, so a truncated list cannot skip it and anything else here is the list itself being wrong.
projects/namco/na1_na2/rtl/video/na2_dbg.sv:96 MAME's high byte is 0x80 and its low two bits are what 0x00DBC5 tests: zero means no fade and the attenuation is cleared, which is the only path MAME ever takes.
projects/namco/na1_na2/rtl/video/na2_dbg.sv:233 All seven have answered: every voice is keyed, at the address, pitch and mode MAME uses, on banks MAME uses, and the beat is loud.
projects/namco/na1_na2/rtl/video/na2_dbg.sv:235 What is NOT known is why the melody channel's envelope level sits at 0x24 where MAME's sits at 0xFF, so those rows carry the envelope instead.
projects/namco/na1_na2/rtl/video/na2_dbg.sv:370 RISK-10: Quiztou draws its notice screen and then executes in upper work RAM, while MAME's 68000 spends 1718 of 1800 frames in program ROM and every one of its work-RAM frames in page 0x000000.
projects/namco/na1_na2/rtl/video/na2_dbg.sv:390 It is not: MAME's 68000 reads PC=0 only while the C70 still holds it in reset, and from the frame it is released it never fetches outside program ROM again.
projects/namco/na1_na2/rtl/video/na2_pixline.sv:9 MAME_VERIFIED (draw_pixel_line() in namcona1_v.cpp), FBNEO_CROSSCHECK (d_namcona1.cpp has the same special case, and MAME's own comment says this is "a simplification, but produces the correct behavior for the only game that uses this featu
projects/namco/na1_na2/rtl/video/na2_pixline.sv:24 MAME's comment next to it says this breaks colours in the VS Express event and that the palette bank may live somewhere else in this mode, so the arrangement is `UNKNOWN`, not settled.
projects/namco/na1_na2/rtl/video/na2_pixline.sv:33 A later tilemap layer still draws over this one: MAME's tilemap draw writes its pixels and its priority unconditionally, and only sprites test what is already there.
projects/namco/na1_na2/rtl/video/na2_roz.sv:4 The fifth background layer, `which == 4` in MAME's priority loop.
projects/namco/na1_na2/rtl/video/na2_roz.sv:9 MAME_VERIFIED (namcona1_v.cpp roz_get_info() and draw_background()'s which == 4 branch, plus tilemap_t::draw_roz), FBNEO_CROSSCHECK (d_namcona1.cpp predraw_roz()/draw_roz(), which agrees on every field -- see the one place it does not, belo
projects/namco/na1_na2/rtl/video/na2_roz.sv:33 The `& 0xFBF` drops bit 6 of the tile number; MAME's comment calls it a patch for Emeraldia Japan and does not explain it, so it is copied and tagged rather than justified.
projects/namco/na1_na2/rtl/video/na2_roz.sv:45 MAME/FBNeo difference, recorded rather than split: MAME's draw_roz advances the start point by cliprect.min_x * incxx before the first pixel, so (startx, starty) belongs to screen pixel (0,0).
projects/namco/na1_na2/rtl/video/na2_roz.sv:152 Measured 2026-08-30 on a real MAME frame through the Pocket CG path: sprite starts 448, busy 0 cycles, sp_cg_stall high for all 896 cycles of the window, peak sprites 0.
projects/namco/na1_na2/rtl/video/na2_tilemap.sv:7 Reference (MAME_VERIFIED + FBNEO_CROSSCHECK -- the two agree pixel for pixel; MAME namcona1_v.cpp draw_background()/tilemap_get_info(), FBNeo d_namcona1.cpp draw_layer()):
projects/namco/na1_na2/rtl/video/na2_tilemap.sv:26 MAME's gfx_layout has planeoffset {0..7} and xoffset {0,8,16,...}, and MAME reads bits MSB-first, so plane p lands on byte bit (7-p) and is placed at pen bit (7-p) -- an identity mapping.
projects/namco/na1_na2/rtl/video/na2_tilemap.sv:182 Measured 2026-08-30 on a real MAME frame through the Pocket CG path: sprite starts 448, busy 0 cycles, sp_cg_stall high for all 896 cycles of the window, peak sprites 0.
projects/namco/na1_na2/rtl/video/na2_tilemap.sv:236 MAME: tile-word bit 15 forces an opaque tile (TILE_FORCE_LAYER0), which `shape_byte` already folds in
projects/namco/na1_na2/rtl/video/na2_vram.sv:31 FBNEO_CROSSCHECK: d_namcona1.cpp bankswitch() maps DrvShapeRAM over 0xF40000-0xF47FFF for bank 3 and DrvGfxRAM over the full window for bank 2, which independently confirms the 32 KiB shape-RAM extent.
projects/namco/na1_na2/rtl/video/na2_vram.sv:238 MAME's gfxram_w does the same thing, so this is not a bug by itself -- but a blitter write that lands here is a graphic that never arrives, and that is worth counting rather than assuming.
README.md:36 아래 표의 "MAME 픽셀 일치" 는 이전 검증에서 실기 스크린샷이 MAME 0.289 가 그린 같은 장면과 68,096 픽셀 중 0 픽셀 차이였다는 뜻입니다 (세트당 최소 한 프레임).
README.md:39 | MAME set | 공식 명칭 | MCU | 상태 |
README.md:41 | `bkrtmaq` | Bakuretsu Quiz Ma-Q Dai Bouken (Japan) | C69 | 실기 동작, MAME 픽셀 일치 |
README.md:42 | `cgangpzl` | Cosmo Gang the Puzzle (US) | C69 | 실기 동작, MAME 픽셀 일치 |
README.md:43 | `cgangpzlj` | Cosmo Gang the Puzzle (Japan) | C69 | 실기 동작, MAME 픽셀 일치 |
README.md:44 | `exvania` | Exvania (World) | C69 | 실기 동작, MAME 픽셀 일치 |
README.md:45 | `exvaniaj` | Exvania (Japan) | C69 | 실기 동작, MAME 픽셀 일치 |
README.md:46 | `fghtatck` | Fighter & Attacker (US) | C69 | 실기 동작, MAME 픽셀 일치 |
README.md:47 | `fa` | F/A (Japan) | C69 | 실기 동작, MAME 픽셀 일치 |
README.md:48 | `swcourt` | Super World Court (World) | C69 | 실기 동작, MAME 픽셀 일치 |
README.md:49 | `swcourtj` | Super World Court (Japan) | C69 | 실기 동작, MAME 픽셀 일치 |
README.md:50 | `swcourtb` | Super World Court (World, bootleg) | C69 | 실기 동작, MAME 픽셀 일치 |
README.md:51 | `emeraldaj` | Emeraldia (Japan) | C69 | 실기 동작, MAME 픽셀 일치 |
README.md:52 | `emeraldajb` | Emeraldia (Japan Version B) | C69 | 실기 동작, MAME 픽셀 일치 |
README.md:53 | `tinklpit` | Tinkle Pit (Japan) | C69 | 실기 동작, MAME 픽셀 일치, 게임 플레이 확인 |
README.md:54 | `numanath` | Numan Athletics (World) | C70 | 실기 동작, MAME 픽셀 일치, 게임 플레이 확인 |
README.md:55 | `numanathj` | Numan Athletics (Japan) | C70 | 실기 동작, MAME 픽셀 일치, 게임 플레이 확인 |
README.md:57 | `knckheadj` | Knuckle Heads (Japan) | C70 | 실기 동작, MAME 픽셀 일치 |
README.md:58 | `knckheadjp` | Knuckle Heads (Japan, Prototype?) | C70 | 실기 동작, MAME 픽셀 일치 |
README.md:59 | `emeralda` | Emeraldia (World) | C70 | 실기 동작, MAME 픽셀 일치 |
README.md:60 | `emeraldajd` | Emeraldia (Japan Version D) | C70 | 실기 동작, MAME 픽셀 일치 |
README.md:61 | `quiztou` | Nettou! Gekitou! Quiztou!! (Japan) | C70 | 실기 동작, MAME 픽셀 일치 |
README.md:63 사운드는 21개 세트 전부 실기에서 voice 가 MAME 와 같은 패턴으로 발음되는 것을 계측했고, `numanath` 는 사람이 직접 BGM·효과음을 들어 확인했습니다.
README.md:70 `zelos` / `zelost` / `bbbingo` / `bbbingot` 은 별도 구성(KEYCUS 없음)이며 MAME 에서도 `MACHINE_NOT_WORKING` 입니다.
README.md:86 직접 마련한 MAME ROM 세트 zip 을 SD 카드의 `/games/mame/` 에 넣습니다.
README.md:88 zip 은 MAME 세트 이름 그대로 두고, 압축을 풀지 않습니다.
README.md:155 새 MAME 픽셀 대조나 오디오 파형 대조를 수행했다는 뜻은 아닙니다.
README.md:174 **2026-08-23** — Emeraldia·Knuckle Heads 를 MAME 와 프레임 단위로 대조.
README.md:177 **2026-08-24** — Quiztou 가 빈 EEPROM 에서 첫 부팅 시 ADDRESS ERROR 로 죽는 원인 규명: 코어가 아니라 **게임 ROM 자체의 버그**(서브루틴이 D7 을 보존하지 않음)이며 MAME 도 진짜 빈 EEPROM 에서는 똑같이 죽음.
README.md:180 **2026-08-26** — NA-1 (C69) 13개 세트 전부 실기 동작, 전부 MAME 와 픽셀 일치.
README.md:191 SDRAM 지연 때문에 거의 모든 버스 사이클에 wait state 가 붙어 실효 속도가 66~78 % 로 떨어지고 있었고, 그 결과 lag 프레임이 MAME 의 1.4~1.8 배, 어트랙트의 페이드 단계가 빠지는 현상이 있었습니다.
README.md:193 DTACK 가 늦을 때 CPU 위상을 멈췄다가 멈춘 만큼만 되갚는 방식으로 고쳐 lag 비율이 MAME 대비 0.96~1.07 배가 됐습니다.
README.md:200 같은 BIOS 를 MAME 와 나란히 돌려 **144,534 명령어를 레지스터 단위까지 대조해 불일치 0** 입니다.
README.md:202 **68000 ↔ MCU 메일박스** — MCU 가 명령 7 에 응답하려면 메일박스 슬롯 2 의 doorbell 비트가 필요하고, 공유 RAM 창의 16비트 접근은 MAME 의 모델과 바이트 순서가 다릅니다.
README.md:207 `c140.cpp` 를 읽은 해석이 아니라 MAME 가 실제로 낸 어트랙트 오디오와 대조해 차이 0 (모듈 머리말 기준 219,619 샘플).
README.md:210 **비디오** — 블리터, 타일맵, 스프라이트(셰도 테이블 포함), ROZ, 픽셀 라인 모드를 각각 MAME 동작의 골든 모델과 대조하고 결함을 일부러 심어 테스트벤치가 잡는지(뮤테이션 테스트) 확인했습니다.
README.md:212 그다음 실행 중인 MAME 의 비디오 메모리를 꺼내 실제 RTL 로 렌더링해 MAME 의 그림과 RGB 로 비교했습니다.
README.md:213 그래픽이 꺼진 동안 게임이 배경색에 잠깐 쓰는 값 때문에 연두색 띠가 번쩍이던 현상은 MAME 처럼 배경색을 유지하도록 고쳤습니다.
README.md:215 MAME 의 `machine().rand()` 자리에는 LFSR 을 넣었습니다.
README.md:216 Tinkle Pit 의 C367 은 알고리즘으로 답하며, MAME 의 알고리즘과 FBNeo 의 32개 출력 표가 서로 일치하는 것을 확인한 뒤 구현했습니다.
README.md:227 MAME 메모리로 돌린 시뮬레이션에서 잘리던 Emeraldia·Tinkle Pit 장면이 MAME 와 픽셀 단위로 같아졌습니다.
README.md:233 이 코어는 **MAME 팀**의 수십 년에 걸친 작업 없이는 불가능했습니다.
README.md:233 NA-1/NA-2 드라이버와 M37710 CPU, C140/C219 사운드 코어에 담긴 지식이 이 RTL 의 사양서였고, 실행 중인 MAME 의 화면·오디오·명령어 흐름이 모든 검증의 기준이었습니다.
README.md:236 — https://www.mamedev.org/ · https://github.com/mamedev/mame
README.md:254 참고한 MAME 소스
README.md:256 MAME 코드는 RTL 에 복사하지 않았습니다.
README.md:256 동작을 읽고 MAME 를 돌려 비교한 뒤 독립적으로 구현했으며, 아래 파일 이름과 줄 번호를 RTL 주석에 근거로 남겼습니다.
README.md:259 | MAME 파일 | 라이선스 | copyright-holders | 참고한 내용 |
README.md:261 | `src/mame/namco/namcona1.cpp` | BSD-3-Clause | Phil Stroffolino | 메모리 맵, 블리터, KEYCUS, 메일박스, MCU 포트, ROM 정의, 기판 메모 |
README.md:262 | `src/mame/namco/namcona1_v.cpp` | BSD-3-Clause | Phil Stroffolino | 타일맵·스프라이트·ROZ·팔레트·우선순위, 비디오 레지스터 맵 |
README.md:263 | `src/devices/cpu/m37710/m37710.cpp`, `m37710.h` | BSD-3-Clause | R. Belmont, Karl Stenerud | M37702M2 내부 레지스터 맵, 인터럽트 벡터 |
README.md:265 | `src/devices/sound/c140.cpp` | BSD-3-Clause | R. Belmont | C219 레지스터, 키온, 뱅킹, mu-law, 믹서 |
README.md:266 | `src/emu/tilemap.cpp` | BSD-3-Clause | Aaron Giles | ROZ 샘플링(`draw_roz`)과 스크롤 의미 |
README.md:268 **FinalBurn Neo** (`d_namcona1.cpp`) 는 사실 확인용 교차 대조로만 읽었습니다 — 예를 들어 ROZ 필드 해석과 Tinkle Pit KEYCUS 출력 표.
README.md:277 참고한 MAME 파일은 모두 BSD-3-Clause 이며 위 표에 출처를 밝혔습니다.
README.md:278 해당 조건·면책 전문은 [`LICENSES/MAME-BSD-3-Clause.txt`](LICENSES/MAME-BSD-3-Clause.txt)에 함께 제공합니다.
README.md:294 MAME 는 이 문자열을 하드코딩해 통과합니다.
README.md:303 MAME 대조는 MAME 0.289 기준입니다.

Says it matches, follows or was checked against MAME — 20

projects/namco/na1_na2/rtl/na2_top.sv:1120 Every other link in ROM -> blitter -> CG/shape RAM -> renderer -> pixel is now verified against MAME's own data, so if the spark is still wrong on the board it is one of these three, and one screenshot during the event names it.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:16 MAME_VERIFIED vectors from m37710_irq_vectors (reference/mame/m37710.cpp:393): TA0 0xFFEE, TA1 0xFFEC, TA4 0xFFE6, TB2 0xFFE0.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:41 stale vector numbers in the port comments corrected to match the code and MAME (the code was already right; only the comments were wrong).
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:43 the 0x42 (B accumulator) and 0x89 (multiply/divide) prefix pages checked opcode by opcode against MAME's own m37710op.h and eight defects fixed.
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:447 IPL-masked priority interrupt acceptance (matches MAME m37710i_update_irqs): take the highest-priority PENDING source whose IC priority STRICTLY exceeds the current IPL (I-flag clear), and raise IPL to it on entry (RTI restores IPL).
projects/namco/na1_na2/rtl/mcu/na2_m37702_cpu.vhd:1190 5 of 5 RTL sites matched abs+2X and 14 of 14 MAME sites matched abs+X. docs/c70_rtl_boot.md.
projects/namco/na1_na2/rtl/mcu/na2_c70.sv:15 Address map, MAME_VERIFIED from namcona1_mcu_map (reference/mame/ namcona1.cpp) and the internal map in reference/mame/m37710.cpp:
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:11 Register addresses are MAME_VERIFIED from the M37702M2 internal map in reference/mame/m37710.cpp (BSD-3-Clause), and the board-level behaviour of ports P4-P8 is MAME_VERIFIED from reference/mame/namcona1.cpp.
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:192 MAME never sets bit 3 of the UART control register 0 and never raises a UART interrupt, and the game runs, so this follows MAME.
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:595 UARTs -- MAME_VERIFIED, and modelled exactly as far as MAME models them (which is: they hold their registers and never do anything).
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:779 MAME_VERIFIED, the M37710_LINE_* numbering (reference/mame/m37710.h) and the vectors (m37710_irq_vectors, m37710.cpp):
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:897 Honouring the clear and ignoring the set satisfies both, and matches what MAME effectively does for the set.
projects/namco/na1_na2/rtl/keycus/na2_keycus.sv:41 MAME_VERIFIED + FBNEO_CROSSCHECK, and the two are independent: MAME (namcona1.cpp, NAMCO_TINKLPIT) runs the algorithm, while FBNeo (d_namcona1.cpp tinklpit_keycus_read) hard-codes the first 32 outputs as a table -- somebody there ran it onc
projects/namco/na1_na2/rtl/video/na2_palette.sv:35 MAME_VERIFIED, and against MAME's *output* rather than its source: the rule is floor(channel * 0.6), on the 8-bit channel after decode.
projects/namco/na1_na2/rtl/video/na2_crtc.sv:32 With the interrupt at 224 the board drew the dolphin ONLY in raw lines 227..240 -- the band between the two handlers, the 227 being interrupt latency -- and with it at 256 the picture matches MAME.
projects/namco/na1_na2/rtl/video/na2_video.sv:460 MEASURED 2026-08-26: with this defined the four .mame/dump-emeralda-sea frames render pixel-exact against MAME -- 1289, 1476, 1367 and 1231 differing pixels all go to zero -- with no change to any rule in this renderer.
projects/namco/na1_na2/rtl/video/na2_bgpal_hold.sv:4 EMULATION_DERIVED Matches MAME namcona1_v.cpp:131-143 and 564-572: a palette write while vreg[0x8E] (GFX enable) is zero is stored in palette RAM but not shown; the palette device is rebuilt from RAM at the next draw with graphics enabled.
projects/namco/na1_na2/rtl/video/na2_blitter.sv:9 Registers (MAME_VERIFIED: blit() in src/mame/namco/namcona1.cpp, FBNEO_CROSSCHECK: blit() in d_namcona1.cpp -- identical) vreg[0x1] source format selector vreg[0x4] destination format selector vreg[0x6] gfx bank; 3 selects t
projects/namco/na1_na2/rtl/video/na2_dbg.sv:221 All three answered their question -- no voice leaves work RAM, and the PCM matches MAME's sets -- so they carry the volume registers instead.
projects/namco/na1_na2/rtl/video/na2_roz.sv:50 MAME's convention is the one every other ROZ driver uses, and `dx = 46` was tuned against it, so this follows MAME.

Says it was translated, ported or taken from MAME — 1

projects/namco/na1_na2/rtl/video/na2_sprite.sv:5 Written from the pseudocode in RESEARCH.md section 10b, which is transcribed from MAME draw_sprites() / pdraw_tile().

Keeps a MAME approximation — 2

projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:528 MAME's comment says bit 5 toggles and guesses "watchdog?"; nothing acts on it.
projects/namco/na1_na2/rtl/mcu/na2_c70_hle.sv:68 That removes MAME's per-frame hack entirely (a Level 10 item done early) and is faster and more faithful: the real MCU answers in microseconds, not on the next vblank.

Shares text with the MAME driver without saying so — 19

projects/namco/na1_na2/rtl/na2_top.sv:1442 (MAME_VERIFIED, namcona1.cpp: add_route(0, "speaker", 1.00, 1) and — shares text with namco/namcona1.cpp:1079
projects/namco/na1_na2/rtl/na2_top.sv:1443 add_route(1, "speaker", 1.00, 0)). Whether that is the PCB's wiring or — shares text with namco/namcona1.cpp:1080
projects/namco/na1_na2/rtl/mcu/na2_c70.sv:270 that is exactly why its C70 "never responds to the version string — shares text with namco/namcona1.cpp:574
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:449 if ((m_mcu_port6 & 0x80) == 0) return m_muxed_inputs[m_mcu_port6>>5]; — shares text with namco/namcona1.cpp:733
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:510 if ((data & 0x08) && !(m_mcu_port4 & 0x08)) ... CLEAR_LINE — shares text with namco/namcona1.cpp:695
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:518 m_mcu_port5 |= ((m_mcu_port5 & 0x2) >> 1); — shares text with namco/namcona1.cpp:718
projects/namco/na1_na2/rtl/mcu/na2_m37702_periph.sv:519 MAME's own comment is "not sure yet, but MCU code requires this — shares text with namco/namcona1.cpp:706
projects/namco/na1_na2/rtl/mcu/na2_c70_hle.sv:55 "FIXME: These two functions shouldn't be necessary?". FBNeo does the same — shares text with namco/namcona1.cpp:191
projects/namco/na1_na2/rtl/memory/na2_eeprom.sv:38 one "otherwise game would lock up on 1st boot"). So a blank part is the — shares text with namco/namcona1.cpp:1183
projects/namco/na1_na2/rtl/keycus/na2_keycus.sv:122 bitswap<16>(keyval, 22,26,31,23,18,20,16,30,24,21,25,19,17,29,28,27): — shares text with namco/namcona1.cpp:283
projects/namco/na1_na2/rtl/video/na2_palette.sv:44 MAME's own TODO says "non-shadow pixels for sprites flagged to enable — shares text with namco/namcona1_v.cpp:13
projects/namco/na1_na2/rtl/video/na2_crtc.sv:20 MAME_VERIFIED: set_visarea(0, 38*8-1, 4*8, 32*8-1) over a 320x256 bitmap. — shares text with namco/namcona1.cpp:1066
projects/namco/na1_na2/rtl/video/na2_blitter.sv:125 accepts `dest >= 0xf00000*2 && dest < 0xf02000*2` -- 0x1E00000-0x1E03FFF — shares text with namco/namcona1.cpp:356
projects/namco/na1_na2/rtl/video/na2_blitter.sv:152 "dest and source are provided as dword offsets": byte address = 2 * value, — shares text with namco/namcona1.cpp:453
projects/namco/na1_na2/rtl/video/na2_linebuf.sv:37 (MAME_VERIFIED: pdraw_tile, `dest[x] = palette_shadow_table[dest[x]]`) — shares text with namco/namcona1_v.cpp:330
projects/namco/na1_na2/rtl/video/na2_pixline.sv:11 is "a simplification, but produces the correct behavior for the only game — shares text with namco/namcona1_v.cpp:502
projects/namco/na1_na2/rtl/video/na2_pixline.sv:18 pDest[x+1] = paldata[data & 0xff]; — shares text with namco/namcona1_v.cpp:438
projects/namco/na1_na2/rtl/video/na2_roz.sv:18 startx = (xoffset << 12) + incxx*dx + incyx*dy — shares text with namco/namcona1_v.cpp:455
projects/namco/na1_na2/rtl/video/na2_roz.sv:19 starty = (yoffset << 12) + incxy*dx + incyy*dy — shares text with namco/namcona1_v.cpp:456

NeratteChu (kyledlester)#
Neratte Chu
kyledlester/MiSTer_Neratte_Chu @ 078e9e2c
MAME compared: seta/simple_st0016.cpp + 2 related file(s)
Read: 20 HDL files, 3,510 lines (Quartus project)

kyledlester
repository only

Mostly MAME

medium

58%

Statements: 1 toward hardware, 41 toward MAME

Notes where it differs from MAME — 1

rtl/nrc/nrc_core.sv:225 Flip Screen (DIP SW2:7): the game sets CRT register $74 and draws normally (MAME ignores the register and shows it upright), so the PCB flips in hardware; here the displayed framebuffer is read rotated 180 degrees.

Cites MAME source — 36

rtl/nrc/nrc_clocks.sv:6 tick8 : nominal 8 MHz CPU time base = 48 MHz / 6 (MAME), fractional: 176/2205 of clk_sys.
rtl/nrc/nrc_clocks.sv:7 ce_snd : tick8 / 128 = 62.5 kHz (MAME st0016 stream rate = clock / 128), from the nominal time base so the sample rate never jitters with CPU stalls.
rtl/nrc/nrc_core.sv:101 DIP switches: MRA <switches>, ioctl index 254, byte 0 = DSW1, byte 1 = DSW2 (MAME values)
rtl/nrc/nrc_cpu.sv:6 The wrapper exists to expose IntE (IFF1, needed for MAME's IFF1-gated NMI) and the register file (PC/SP for diagnostics), which T80s does not export.
rtl/nrc/nrc_framebuffer.sv:4 Two 320 x 240 x 11-bit buffers (pen 0..1023, bit 10 = MAME UNUSED_PEN).
rtl/nrc/nrc_inputs.sv:4 MAME simple_st0016.cpp, INPUT_PORTS_START(st0016) + (nratechu).
rtl/nrc/nrc_inputs.sv:13 active-low DIP bytes as MAME defines them
rtl/nrc/nrc_irq.sv:4 MAME simple_st0016.cpp st0016_state::interrupt (384-line fictitious screen, 60 Hz): line 240 : IRQ0, HOLD_LINE (asserted until the CPU acknowledges it) lines 0,64,..,320 : NMI pulse, but only if IFF1 = 1 at that moment ("dirty ha
rtl/nrc/nrc_irq.sv:9 FPGA mapping [APPROXIMATION, MAME-compatible, all constants here]: IRQ at `irq_event` = start of vblank (line 256 of the 262-line raster) - the frame render instant.
rtl/nrc/nrc_irq.sv:11 NMI k (k = 0..5) at IRQ + (16 + 64k) / 384 of a frame, i.e. MAME lines 256, 320, 0, 64, 128, 192 keep their phase relative to the IRQ.
rtl/nrc/nrc_loader.sv:4 ioctl index 0 (hps_io WIDE=1): the MRA delivers the ST-0016 external ROM image in MAME region order, stream offset == extrom byte address (MRA: sx012-01 @0, 512 KiB zero pad, sx012-02 @100000).
rtl/nrc/nrc_loader.sv:12 After the download finishes the loader zero-fills - extrom from the end of the stream up to 0x3FFFFF (MAME ROMREGION_ERASE00: U33/U34 unpopulated), - character RAM (SDRAM 0x800000-0x9FFFFF; MAME starts it zeroed), then raises rom_ready.
rtl/nrc/nrc_palette.sv:4 Live palette: 2 KiB = 1024 colours x 16 bit little-endian (MAME m_paletteram), CPU window EA00-EBFF through the E5 bank register (512 bytes per bank).
rtl/nrc/nrc_palette.sv:6 MAME converts pens to colours at the moment it renders the frame (vblank IRQ).
rtl/nrc/nrc_palette.sv:12 Display reads (buffer, pen) -> RGB888 with MAME pal5bit expansion; pen 1024 (UNUSED_PEN) shows colour 0.
rtl/nrc/nrc_render.sv:7 Tilemaps (MAME 0.289 draw_bgmap; Neratte Chu uses one only in its service mode): per slot with reg1 != 0, 64x32 tiles column-major at sprite RAM (reg1 & 15) * 0x1000, 4 bytes each (code.w, colour, attr), no scroll, tile (x, y) at (x*8 + spr
rtl/nrc/nrc_render.sv:9 Phase order as MAME draw_screen: priority-0 layers (reg3 != $FF: sprite pixel rule, merge if reg7 == $12), sprites, priority-1 layers (plain transparency: pen 0 not drawn).
rtl/nrc/nrc_render.sv:18 per 8x8 tile: compute which of its 8 destination columns / rows fall inside the clip (exactly MAME's u16 arithmetic, x wrap "-512 if > 327"); a tile with no visible pixel is skipped without fetching; otherwise fetch its 32 bytes (4 x 8-byte
rtl/nrc/nrc_sound.sv:4 Behavioural reference: MAME master src/devices/sound/st0016.cpp (commit dcca0e9b), which adds PCB-fitted non-linear decoding, linear interpolation and an exponential volume law to MAME 0.289.
rtl/nrc/nrc_sound.sv:8 For each of the 8 voices whose flags have bit 1 or 2 set: fetch the sample bytes at pos and next_pos(pos) from character RAM (SDRAM; one cached 8-byte group per voice), decode (linear or non-linear, voice 7 reg $1F bit 1), interpolate with
rtl/nrc/nrc_sound.sv:39 ------------------------------------------------------------ tables volume byte -> gain x256 (MAME master m_voltab; bit 7 ignored); regenerate with scripts/gen_sound_tables.py
rtl/nrc/nrc_sound.sv:118 sample byte -> s16 (MAME master m_linear / m_nonlinear)
rtl/nrc/nrc_sound.sv:134 MAME master voice_t::next_pos
rtl/nrc/nrc_sound.sv:188 CPU register writes; key-on per MAME voice_t::reg_w (compare with the live flags)
rtl/nrc/nrc_sound.sv:275 write back unless the CPU wrote this voice's flags while it was processed (MAME: a register write follows the stream update, so the write wins)
rtl/nrc/nrc_spriteram.sv:10 Snapshot protocol (docs/ARCHITECTURE.md "Video architecture"): snap pulse at the MAME render instant (vblank IRQ).
rtl/nrc/nrc_spriteram.sv:12 From then until render_done, `render` is frozen: it equals `live` at the snap instant (MAME semantics).
rtl/nrc/nrc_st0016.sv:4 Behavioural contract: MAME 0.289 st0016_cpu_device (cpu_internal_map / cpu_internal_io_map, vregs_r/w, bank handlers) plus the board glue of simple_st0016.cpp (st0016_mem, st0016_io, mux).
rtl/nrc/nrc_st0016.sv:331 MAME vregs_w: byte copy extrom -> charram while src < 4 MiB and dst < 2 MiB
rtl/nrc/nrc_video_timing.sv:7 Vertical: active lines 16..255 ($6A = $10 visible start, $6C = $100 visible end), vsync from line 1 ($68 = 1) [GAME-PROGRAMMED; register meanings from MAME comments].
rtl/nrc/nrc_video_timing.sv:9 Horizontal: 320 active dots (MAME visible width for nratechu); the placement of sync inside the 135-dot blank is [MISTER-COMPATIBLE], centred like a standard NTSC active window (see docs/ST0016_VIDEO.md "Timing").
rtl/nrc/nrc_video_timing.sv:13 ST-0016 bitmap x = x + 8 (MAME nratechu visible area 8..327), bitmap y = y.
README.md:23 | Game | MAME set | Year | Genre | Board | Status |
README.md:47 The game's Flip Screen DIP switch works (a true 180° rotation), which does not work in MAME.
README.md:48 The service menu (DIP "Service Mode") works with readable text; MAME draws its text upside down.
README.md:57 The picture is one frame later than on the original board (a constant 16.7 ms), because the core draws each frame into a framebuffer as MAME does.

Says it matches, follows or was checked against MAME — 2

rtl/nrc/nrc_render.sv:6 Golden model: scripts/research/st0016_ref.py (pixel-identical to MAME snapshots).
README.md:43 MAME's ST-0016 drivers (0.289, sound from MAME's current PCB-fitted model) are the behavioural reference; video was verified pixel-for-pixel against MAME.

Says it was translated, ported or taken from MAME — 1

rtl/nrc/nrc_render.sv:4 Hardware port of MAME 0.289 st0016_cpu_device::draw_sprites() for game_flag 1 (nratechu): spr_dx = 0, spr_dy = 8, clip x 8..327 / y 0..239, bitmap pre-filled with UNUSED_PEN (1024).

Keeps a MAME approximation — 1

README.md:59 A few undocumented ST-0016 behaviours follow MAME's approximations (the chip's timer/raster counter, the timing of the sound-sequencer interrupts, the sound chi

Shares text with the MAME driver without saying so — 1

rtl/nrc/nrc_st0016.sv:4 Behavioural contract: MAME 0.289 st0016_cpu_device (cpu_internal_map / cpu_internal_io_map, — shares text with seta/st0016.cpp:16

Nostradamus (kyledlester)#
Magical Cat Adventure, Nostradamus
kyledlester/Nostradamus_Magical_Cat_Adventure_MiSTer @ cd466c02
MAME compared: misc/mcatadv.cpp
Read: 85 HDL files, 12,958 lines (Quartus project)

kyledlester
repository only

Mostly MAME

medium

28%

Statements: 3 toward hardware, 71 toward MAME

Cites hardware documentation that MAME's driver does not — 3

rtl/vendor/jt10/jt12_exprom.v:19 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.
rtl/vendor/jt10/jt12_logsin.v:17 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.
rtl/vendor/jt10/jt12_op.v:19 Based on Sauraen VHDL version of OPN/OPN2, which is based on die shots.

Cites MAME source — 65

Nostradamus.sv:23 Nostradamus is vertical (MAME ROT270): HDMI uses the framework screen_rotate (DDR3 framebuffer, counter-clockwise); native/analog output is the unrotated 15 kHz raster for a rotated CRT.
Nostradamus.sv:57 The labels say what is done to the board's 320x224 raster: Horizontal raster as is (Magical Cat on a landscape screen; Nostradamus on a TATE / rotated monitor or CRT) Vertical CCW HDMI scaler rotates it 90 degrees counter-clockwise (Nos
rtl/nost/nost_clocks.sv:7 phi1/phi2: FX68K phase enables, alternating on tick32 -> 68000 at 16 MHz (MAME XTAL 16 MHz).
rtl/nost/nost_core.sv:9 nost_video -> 038 x2 tilemaps, sprites, mixer nost_sound -> Z80, YM2610 nost_sdram_arb -> SDRAM channel 1 (loader > 68000 ROM > ADPCM-A > Z80 ROM > tiles > sprites) Game select (MRA ioctl index 1 byte): 0 = Nostradamus (MAME no
rtl/nost/nost_core.sv:12 Same board in MAME (mcatadv.cpp); differences: Z80 memory/I/O map and SSG level (nost_sound), inputs and unused DIP/input bits (below), tile ROM sizes (code wrap in the tilemap engines) and the screen orientation (top level).
rtl/nost/nost_core.sv:74 ------------------------------------------------------------------ DIP switches (index 254) byte 0 = SW1 (MAME DSW1 bits 15-8), byte 1 = SW2 (DSW2 bits 15-8); MAME port values
rtl/nost/nost_core.sv:89 ------------------------------------------------------------------ inputs (MAME active low) MiSTer joystick: 0 right, 1 left, 2 down, 3 up, 4-6 buttons 1-3, 7 start, 8 coin, 9 service, 10 pause (CONF_STR J1).
rtl/nost/nost_core.sv:92 MAME INPUT_PORTS_START( nost ): P1/P2 bit 0 up, 1 down, 2 left, 3 right, 4 button 1, 5/6 "unknown" (buttons 2/3 in test mode only), 7 start, 8 coin; P2 bit 9 = SERVICE1.
rtl/nost/nost_core.sv:94 P1 bit 11 is active high and must read 0 (MAME: "Must be LOW or startup freezes"; the boot code at 0x184 waits for it).
rtl/nost/nost_core.sv:96 MAME INPUT_PORTS_START( mcatadv ): the same bits (button 2 = jump; P1 button 3 used by the test mode only; P2 bit 6 unknown = 1); all other bits read 1 (no bit 11 rule); DSW1/DSW2 bits 7-0 are IPT_UNKNOWN active low (read 1; nost does not d
rtl/nost/nost_core.sv:176 Magical Cat's Z80 writes 01 while it takes a command and 00 otherwise (MAME trace), and the 68000 waits for 00 before each command.
rtl/nost/nost_loader.sv:5 Every stream word goes to SDRAM: 000000-0FFFFF maincpu -> 0x0000000 + a (68000 words as delivered) 100000-13FFFF soundcpu -> 0x0100000 + a' ({byte 2k+1, byte 2k}); 100000-107FFF also to the Z80's block-RAM copy of 0000-7FFF (nost_sound)
rtl/nost/nost_main.sv:4 MAME 0.289 mcatadv_state::main_map (docs/MEMORY_MAP.md): FX68K at 16 MHz (phi1/phi2 enables).
rtl/nost/nost_main.sv:5 000000-0FFFFF program ROM: SDRAM through a direct-mapped cache (nost_rom_cache) 100000-10FFFF work RAM 200000-200005 / 300000-300005 038 #0 / #1 registers 400000-401FFF / 500000-501FFF 038 #0 / #1 RAM (tile map 000-FFF, line RAM
rtl/nost/nost_main.sv:15 Unmapped reads return 0 (MAME unmap value); unmapped writes are ignored.
rtl/nost/nost_main.sv:22 Sprite buffer: at vblank start the half selected by vidregs word 2 (MAME: == 1 -> second half) is copied (2048 clocks, 4 words per clock) to the display buffer read by the sprite engine, which is MAME's buffered_spriteram16 copy + buffered
rtl/nost/nost_main.sv:265 unmapped: MAME unmap value 0
rtl/nost/nost_rom_cache.sv:4 A direct-mapped cache of 2^IW lines of 8 bytes (one 4-word SDRAM burst) answers hits with the same latency as block RAM, so hits cost the 68000 no wait states; a miss fetches the line (the CPU waits; MAME has no wait states at all, docs/KNO
rtl/nost/nost_rom_cache.sv:55 simulation only: zero-wait program ROM (MAME timing) for the bus-trace comparison bench
rtl/nost/nost_sound.sv:4 mcat = 1: MAME 0.289 mcatadv_sound_map / mcatadv_sound_io_map (Magical Cat Adventure): 0000-3FFF ROM, 4000-BFFF ROM bank window (32 KB from bank * 0x4000 of the 128 KB ROM), C000-DFFF RAM, E000-E003 RW YM2610, F000 W bank; I/O 80 R sound la
rtl/nost/nost_sound.sv:8 mcat = 0 (Nostradamus): MAME 0.289 mcatadv_state::nost_sound_map / nost_sound_io_map (docs/AUDIO.md): Z80 (T80s) at 4 MHz: 0000-7FFF ROM, 8000-BFFF ROM bank (16 KB pages of the 256 KB ROM, bank register = port 40, MAME's initial page 1, not
rtl/nost/nost_sound.sv:13 NMI = sound latch pending (set by a 68000 write, cleared by the Z80 read: MAME generic_latch_8 data_pending -> INPUT_LINE_NMI); INT = YM2610 IRQ (the program runs IM 1 with a bare RETI).
rtl/nost/nost_sound.sv:16 Mono mix as MAME's nost routes: SSG (ymfm: (a+b+c) * 2/3, channel amplitudes 0..16382) x 0.6 + FM/ADPCM left x 0.5 + right x 0.5, saturated to 16 bits.
rtl/nost/nost_sound.sv:21 The Z80 program ROM and the ADPCM-A ROM are in SDRAM (clk_sys) behind small caches in this domain with a level handshake per line fill; a Z80 cache miss holds WAIT_n (MAME has no waits).
rtl/nost/nost_sound.sv:150 MAME machine_start: set_entry(1); kept across resets
rtl/nost/nost_sound.sv:181 Next-line prefetch: while the Z80 reads a line that hits, the following line is fetched if it is not present, so sequential code and data (e.g. the boot-time ROM checksum) do not stall the Z80 (the board's ROM has no wait states; MAME neith
rtl/nost/nost_sound.sv:354 MAME unmapped read value
rtl/nost/nost_sound.sv:363 ------------------------------------------------------------------ mix (clk_snd), output (clk) ymfm SSG amplitude ~ jt49 8-bit level * 64.25; MAME: ssg * 2/3 * 0.6 + (l + r) * 0.5 = (A + B + C) * 25.7 + (L + R) / 2 -> integer: ((A+B+C) *
rtl/nost/nost_sprites.sv:4 Hardware form of MAME 0.289 mcatadv_state::draw_sprites (docs/VIDEO.md, scripts/refrender.py).
rtl/nost/nost_sprites.sv:8 Pixels: nibble address tile*256 + row*width + column (low nibble of a byte first) in the 8 MB sprite region; the populated 5 MB are in SDRAM, the erased rest reads 0xF (MAME ROMREGION_ERASEFF).
rtl/nost/nost_sprites.sv:12 MAME draws the last entry first and a sprite pixel masks every later one (priority bitmap bit 4), whatever its priority against the tiles; so the visible sprite pixel is the opaque pixel of the highest-numbered entry.
rtl/nost/nost_sprites.sv:47 global offsets as MAME ints: global = vidreg - 0x184 / 0x1F1 (17-bit signed is plenty)
rtl/nost/nost_sprites.sv:75 data row: MAME consumes rows in drawing order, so with flipy row k of the data is drawn at screen row height - 1 - k
rtl/nost/nost_tilemap.sv:4 Hardware form of MAME 0.289 tmap038 (16x16 tile RAM only, as mapped for nost) + mcatadv_state::draw_tilemap_part, per render line y (0..223), layer 0 then layer 1 (docs/VIDEO.md, scripts/refrender.py tile_layer()): scrollx = (reg0 & 1FF) -
rtl/nost/nost_tilemap.sv:19 Line RAM, tile RAM and registers are read live while the line is rendered (the game updates them in vblank: docs/MAME_REFERENCE.md), which equals MAME's render-at-vblank-start state.
rtl/nost/nost_tilemap.sv:55 16-bit two's complement, as MAME's int (9 bits matter)
rtl/nost/nost_tilemap.sv:67 MAME draws 8x8 element code * 4 + q modulo the region's element count (gfx_element get_data): 16x16 code % (region bytes / 128).
rtl/nost/nost_tilemap_cave.sv:9 319 it presents the position, waits until the module's addresses are stable, reads tile RAM / line RAM (16-bit board RAM, two words per 32-bit read) and the tile-ROM word (SDRAM, MAME byte order copy of the region, 8 bytes = two 8-pixel row
rtl/nost/nost_tilemap_cave.sv:14 Board adaptation (inputs only, nothing inside the Cave module changed): * scroll origin: the module computes x + scroll - spriteOffset - layerOffset (0x12 for 16x16); spriteOffset_x = 0x194 - 0x12 and spriteOffset_y = 0x1DF - 0x1EE give MAM
rtl/nost/nost_tilemap_cave.sv:24 0: line RAM entries indexed as on this board (MAME mcatadv): row select at the scrolled line, row scroll at the selected line.
rtl/nost/nost_tilemap_cave.sv:71 MAME drawline + scrolly
rtl/nost/nost_tilemap_cave.sv:97 MAME draws 8x8 element code * 4 + q modulo the region's element count (gfx_element get_data): 16x16 code % (region bytes / 128).
rtl/nost/nost_tilemap_cave.sv:112 ROM byte address: {code[15:0], y3, half, pair, 3'b000} (= MAME's 8x8 element code*4+q, row pair); code wrapped as MAME
rtl/nost/nost_tilemap_cave.sv:165 MAME applies the flip after row select (scrolly = rowselect - line, then flipped: source row 223 + scrolly - 0x141 - line); the module uses the row-select value as the tile row directly, so flipped it gets rowselect - 2*line + 0x19E.
rtl/nost/nost_tilemap_cave.sv:189 0x1200000 : 0x1000000) + rom_byte (MAME byte order copy)
rtl/nost/nost_video.sv:6 Mixer = MAME mcatadv screen_update: background pen 0x3F0; the two 038 layers are drawn by category 0..3, layer 0 then layer 1 within a category, so the visible tile pixel is the opaque one with the highest (category, layer); the priority bi
rtl/nost/nost_video.sv:10 Palette xGRB_555 (MAME palette_device::xGRB_555) read live from the 68000 board's palette RAM; 5-bit channels expanded as MAME's pal5bit (x << 3 | x >> 2).
rtl/nost/nost_video_timing.sv:4 MAME logical raster (mcatadv.cpp): set_size(320, 256), visarea 0..319 x 0..223, 60 Hz, set_vblank_time(0): vblank = lines 224..255.
rtl/nost/nost_video_timing.sv:5 MAME's raster has no horizontal blanking; this core uses a 456-dot line at 7.004160 MHz (dots 0..319 visible) so that lines run at MAME's 15.360 kHz and frames at 60.000 Hz.
rtl/nost/nost_video_timing.sv:7 hcount/vcount: vcount is MAME's vpos; hcount 0..319 is MAME's hpos.
rtl/nost/nost_video_timing.sv:12 Reset phase: MAME starts its screen at vblank begin (screen.cpp m_vblank_start_time = 0), i.e. the beam is at line 224, dot 0 at time 0 (measured: the 3.0 s watchdog reset lands on line 224 dot 0).
rtl/nost/nost_video_timing.sv:14 The raster leaves reset at the same position so CPU time and the vblank interrupt keep MAME's phase.
rtl/vendor/jt10/jt12_lfo.v:78 same values as in MAME
README.md:9 Hardware: 68000 @ 16 MHz, Z80 @ 4 MHz, YMF286-K (YM2610 compatible) @ 8 MHz, two 038 tilemap chips and the FX1037 sprite custom (MAME driver `misc/mcatadv.cpp`)
README.md:30 Use MAME 0.289 sets (`mame -verifyroms <set>` = good; `catt` reports "best available" because MAME lacks two PLD dumps the game does not need).
README.md:40 Copy the ROM zips to `/media/fat/games/mame/`.
README.md:46 **Expect a black screen for about 3 seconds at power-on.** Both programs write a signature to RAM on a cold start and wait for the board's watchdog to reset the
README.md:81 Use *Flipped* rather than the games' own *Flip Screen* DIP: that DIP behaves as in MAME, which only flips the backgrounds (the drivers are marked "no cocktail")
README.md:84 **Tilemap engine** — *Cave 038* (default) uses the 038 layer processor from the [Arcade-Cave](https://github.com/MiSTer-devel/Arcade-Cave_MiSTer) core, adapted
README.md:96 320 x 224 visible, 456 x 256 total, 7.004 MHz dot clock: **15.36 kHz / 60.00 Hz**, MAME's raster for both games (the PCB's exact timing has not been measured).
README.md:98 Sound: Z80 + YM2610 (jt10), mono, mixed with MAME's per-game levels.
README.md:102 In short: the watchdog period (3 s), raster timing and sprite/tile priority follow MAME where the PCB is unmeasured; the YM2610 is jotego's jt10 rather than MAM
README.md:127 ROM-derived images come from `python scripts/romtool.py --game <set> regions|stream|images` and MAME captures from `scripts/mame/*.lua` (via `scripts/mame/run.s
README.md:132 Documentation: [architecture](docs/ARCHITECTURE.md), [memory map](docs/MEMORY_MAP.md), [ROM layout](docs/ROM_LAYOUT.md), [video](docs/VIDEO.md), [audio](docs/AU
README.md:139 MAME driver `mcatadv.cpp` (Paul Priest, David Haywood) and `tmap038` — the behavioural reference for this core (no MAME code is included).

Says it matches, follows or was checked against MAME — 2

README.md:16 Every set was checked in simulation against MAME 0.289 (ROM loading, CPU bus traffic, video frame by frame, sound chip writes and audio).
README.md:86 Both produce pixel-identical pictures to MAME on every frame tested; the option exists for comparison and as a fallback.

Keeps a MAME approximation — 2

rtl/nost/nost_main.sv:17 Watchdog (MAME: 3 s, "a guess, and certainly wrong"): 96,000,000 ticks of the 32 MHz time base without a write to B00018 (or read of B0001E) soft-resets the 68000 and the sound board (MAME schedule_soft_reset: CPUs and devices reset, RAM ke
rtl/nost/nost_main.sv:27 watchdog period in 32 MHz ticks (3.0 s, MAME's guess)

Shares text with the MAME driver without saying so — 2

rtl/nost/nost_core.sv:94 P1 bit 11 is active high and must read 0 (MAME: "Must be LOW or startup freezes"; the boot — shares text with misc/mcatadv.cpp:620
rtl/nost/nost_sprites.sv:7 Entries with w3 == w0 are skipped ("don't draw sprites while it's testing the RAM"). — shares text with misc/mcatadv.cpp:276

ohmygod (decoryah)#
Naname de Magic!, Oh My God!
decoryah/Arcade-OhMyGod_MiSTer @ 8ebc9e7d
MAME compared: atlus/ohmygod.cpp
Read: 13 HDL files, 2,015 lines (Quartus project)

decoryah
repository only

Mostly MAME

low

56%

Statements: 1 toward hardware, 33 toward MAME

Notes where it differs from MAME — 1

README.md:60 On MAME's own states (`tools/omg_bank_effect.py`) *At vblank* differs from MAME's picture in 18 of 60 sampled frames of Oh My God!

Cites MAME source — 30

OhMyGod.sv:3 Atlus "Oh My God!" (1993) and "Naname de Magic!" (1994) -- MAME's atlus/ohmygod.cpp -- for MiSTer.
OhMyGod.sv:5 Written for MiSTer from MAME 0.289's driver (src/mame/atlus/ohmygod.cpp).
OhMyGod.sv:137 ioctl index 254: byte 0 = the high byte of MAME's DSW1 port, byte 1 = the high byte of DSW2; a 1 is MAME's default.
OhMyGod.sv:147 keyboard: 1/2 start, 5/6 coin, 9 service (MAME's defaults)
OhMyGod.sv:171 the board's inputs, active low (MAME's INPUT_PORTS ohmygod, naname): P1: bit 0 up, 1 down, 2 left, 3 right, 4 button 1, 7 start 1, 8 coin 1, 9 service (no toggle) P2: the same, bit 7 start 2, 8 coin 2, 9 service 1
OhMyGod.sv:242 MAME's output is exactly 16 times jt6295's 14-bit sum of the OKI's voices (measured on MAME's own recording of the same OKI writes: envelope correlation 1.000 at lag 0, a constant -24.0 dB), clipped to 16 bits as MAME does: "Normal" is that
rtl/omg_core.sv:117 A chip that reads the flag live shows the old list above the flip and the new one below it; MAME, drawing the frame at its end, shows the new one throughout.
rtl/omg_main.sv:3 The 68000 (fx68k, 12 MHz), its memory map (MAME src/mame/atlus/ohmygod.cpp, ohmygod_state::main_map), the RAMs the video reads, the inputs, the OKI M6295 port, the registers and the watchdog.
rtl/omg_main.sv:19 Unmapped addresses read as 0 and swallow writes (MAME's defaults).
rtl/omg_main.sv:26 clocks without a kick before the reset: 3 s (MAME's time) = 288000000 at 96 MHz
rtl/omg_main.sv:81 level 1 interrupt, held until acknowledged (MAME: irq1_line_hold)
rtl/omg_main.sv:178 ------------------------------------------------------------------ registers (the driver's COMBINE_DATA on the scroll words; the sprite bank is bit 15 of a write that reaches the high byte; the control word's low byte holds the OKI bank) Th
rtl/omg_render.sv:1 Line renderer: MAME's ohmygod_state::screen_update for one line (the one after the line being shown).
rtl/omg_render.sv:10 The picture's window is x 96..415 of MAME's 512-dot bitmap; tile scroll: source x = x + 96 + (scrollx - 0x81ec), y + (scrolly - 0x81ef).
rtl/omg_sound.sv:2 Its sample ROM is the 2 MB in SDRAM: the chip's 18-bit address space is a fixed 128 KB (0..1FFFF) and a window (20000..3FFFF) onto one of 16 banks of 128 KB, chosen by the control register (MAME: oki_map / m_okibank).
rtl/omg_sound.sv:6 The output is MAME's level (OKIM6295 route 1.0: the sum of up to four 12-bit voices, here already scaled the same by jt6295: 14 bit).
rtl/omg_video.sv:4 MAME gives the board's picture as 320 x 240 at 60 Hz (a 512 x 256 total); the totals here are the usual 15 kHz arcade ones.
README.md:3 Atlus' **Oh My God!** (1993) and **Naname de Magic!** (1994), the two games of MAME's `atlus/ohmygod.cpp` driver (68000 at 12 MHz, one OKI M6295, one 64 x 64 ti
README.md:6 Written for MiSTer from MAME 0.289's driver.
README.md:18 What was checked besides, in simulation and in the Quartus tool flow, against MAME 0.289 (details and numbers in `docs/status.md`):
README.md:26 The whole machine from reset (68000, cache, SDRAM controller, cold-start watchdog reset) with MAME's inputs replayed: frames 230 and 280 of both games pixel-ide
README.md:28 The sound path against MAME's own OKI samples: same samples, MAME's level (x16), residual 0.01 %.
README.md:36 **A cold start shows a grid-patterned / black screen for 3 seconds** before the ATLUS logo: the game fills its RAM, writes a signature and waits for the watchdo
README.md:53 **Volume**: Normal is MAME's level (the OKI's output is exactly 16 times jt6295's 14-bit sum of voices, clipped to 16 bits; fitted against MAME's own samples, r
README.md:59 MAME, drawing a frame at its end, shows the new list throughout.
README.md:69 MAME's own totals are 512 x 256 at exactly 60 Hz; the board's real timing is not known.
README.md:79 sim/run.sh <image> <frames> <out> +state=<MAME state prefix> +first=2 # one frozen state, vs MAME's pixels sim/run.sh <image> <frames> <out> +inputs=<r
README.md:82 `tools/lua/dump_state.lua` makes the states and the replay inputs with MAME 0.289 (see its header); `tools/omg_ref.py`, `tools/omg_diff.py`, `tools/omg_corpus.p
README.md:88 They expect a scratch folder `work/` next to the repository (MAME's dumps and the ROM images; never committed).
README.md:99 fx68k (Jorge Cwik), jt6295 (Jose Tejada), MiSTer-CRT-Adjust (rmonic79), the Pocket Gaiapolis core's SDRAM controller (plasticbugs), the MiSTer framework (Sorgel

Says it matches, follows or was checked against MAME — 2

README.md:21 The ROM path: both sets' images are byte-identical to the regions MAME loaded (`tools/omg_rom.py check`), and the MRAs assemble to the same images (`tools/mra_b
README.md:23 The video, against a reference renderer (`tools/omg_ref.py`) that is MAME's `screen_update` written out literally: pixel-exact on 120 MAME frames of scripted pl

Keeps a MAME approximation — 1

rtl/omg_main.sv:205 ------------------------------------------------------------------ watchdog (MAME: 3 s, "a guess, and certainly wrong")

PolyPlay (Niels3RT)#
Poly Play, Poly Play 2, Poly Play 2c
Niels3RT/PolyPlay_MiSTer @ 9fe8f9b2
MAME driver: not found
Read: 14 HDL files, 2,324 lines (Quartus project)

Niels3RT
repository only

Not enough evidence in the code

insufficient

Statements: 2 toward MAME

Cites MAME source — 2

rtl/periph/ctc_channel.vhd:163 now behaves like mame???
README.md:5 All information taken from [mame/polyplay.cpp](https://github.com/mamedev/mame/blob/master/src/mame/drivers/polyplay.cpp).

PowerIns (yaguboo)#
Gouketsuji Ichizoku
yaguboo/Arcade-PowerInstinct_MiSTer @ 585ccd15
MAME compared: nmk/nmk16.cpp + 10 related file(s)
Read: 18 HDL files, 3,149 lines (all HDL files: no Quartus project found)

yaguboo
repository only

Mostly MAME

medium

85%

Statements: 4 toward hardware, 82 toward MAME, 3 not counted

Cites hardware references or measurements that MAME's driver also gives — 3

projects/atlus/powerins/rtl/video/pi_timing.sv:7 ---- horizontal: 20.u54, 82S129, 256 x 4 -------------------------------- An 8-bit counter from 0x20 to 0xFF, one step per two pixels (448 px): — also in MAME: 82S129 nmk/nmk16.cpp:4272
projects/atlus/powerins/rtl/video/pi_timing.sv:11 ---- vertical: 21.u71, 82S135, 256 x 8 ---------------------------------- An 8-bit counter from 0x75 to 0xFF, one step per two lines (278 lines), clocked by /LINE-END: bit0 /SPR-DMA bit1 /VSYNC bit2 /VBLANK bit6:4 IPL bit7 /TRIG Frame l — also in MAME: 82S135 nmk/nmk16.cpp:4317
projects/atlus/powerins/rtl/video/pi_colmix.sv:4 22.u81 (82S123, 32 x 8) is loaded from the ROM set and does the mixing, as it does on the PCB. — also in MAME: 82S123 nmk/nmk16.cpp:7325

Says it was checked against the original PCB — 2

projects/atlus/powerins/rtl/pi_cen.sv:10 M6295 4.000 MHz 48 / 12 cen_oki :5766 "verified on PCB"
projects/atlus/powerins/rtl/video/pi_sprrend.sv:5 The evidence: * MAME's sprite limit is a clock budget of one frame's length (448 x 263, nmk16.cpp set_screen_midres) -- a drawing-time limit, not a per-line one * MAME draws the list from TWO DMA copies back ("2 buffers confirmed on PCB"),

Says it was checked on “real hardware” — 1

projects/atlus/powerins/rtl/cpu/pi_m68k.sv:4 From projects/dataeast/stadium_hero/rtl/cpu/sh_m68k.sv, which is from Power Spikes and NA-1/NA-2 before it -- verified on hardware in four lanes (root CLAUDE.md 1.3).

Notes where it differs from MAME — 1

projects/atlus/powerins/rtl/pi_main.sv:231 TODO(HARDWAREIZE) T-DTACK-1: the PCB's own wait states are not known (its PALs are undumped; MAME models none).

Cites MAME source — 76

projects/atlus/powerins/rtl/pi_top.sv:252 The 68000 never reads the sound side back (the latch is the only path, nmk16.cpp:1203).
projects/atlus/powerins/rtl/pi_top.sv:317 MAME's speaker is mono (nmk16.cpp:5754); both channels carry it.
projects/atlus/powerins/rtl/pi_main.sv:4 Map: powerins_map, nmk16.cpp:1193-1209 (docs/MEMORY_MAP.md 1)
projects/atlus/powerins/rtl/pi_main.sv:10 (MAME nopw -- T-MAP-2) 100019 W BG tile bank 10001f W sound latch 120000-120fff RW palette 130001/3/5/7 RW scroll bytes 140000-143fff RW BG VRAM 170000-171fff RW text VRAM (0x171000 mirrors 0x170000) 180000-18ff
projects/atlus/powerins/rtl/pi_main.sv:19 EMULATION_DERIVED T-MAP-1: exactly MAME's decode.
projects/atlus/powerins/rtl/pi_main.sv:32 Two IRQ4s a frame; the handler's text writes doubled (20 a frame against MAME's 10) and the attract never reached the FBI screen.
projects/atlus/powerins/rtl/pi_main.sv:36 MAME uses a HOLD_LINE per level; with levels 1-3 masked and vectoring to RTE (0x1A0, ROM_MEASURED) both give one IRQ4 a frame.
projects/atlus/powerins/rtl/pi_main.sv:157 ------------------------------------------------------------------------ I/O EMULATION_DERIVED T-IO-1: the undefined high byte of SYSTEM and the DSWs reads 0, as in MAME.
projects/atlus/powerins/rtl/pi_main.sv:171 Writes land on the LOW byte lane: MAME's byte handlers sit at the odd addresses, and the game writes these as words (the reset code's MOVE.W #$00FF,$10001E -- ROM_MEASURED; FBNeo's byte handler ignores them and the game still runs, EMULATOR
projects/atlus/powerins/rtl/pi_cen.sv:7 68000 12.000 MHz 48 / 4 in pi_m68k (CLK_DIV) nmk16.cpp:5735
projects/atlus/powerins/rtl/memory/pi_romcache.sv:8 WHY, on this board (docs/VALIDATION.md V1, V3, V4): * the program ROM is in SDRAM behind pi_romarb; in simulation a pending ROM read covered about a third of all clocks * the boot RAM check has NO interrupts (MAME frames 1-228, pi_wr.lua),
projects/atlus/powerins/rtl/memory/pi_romarb.sv:32 Worst measured load in MAME's attract, 7,314 visible tile rows = 14,628 fetches a frame (docs/SPRITE_ANALYSIS.md 6) -- about 205k clocks of a frame's 854k.
projects/atlus/powerins/rtl/memory/pi_romarb.sv:44 Chip 0 reads MAME region "oki1" and chip 1 "oki2" (nmk112 set_rom0_tag / set_rom1_tag, nmk16.cpp:5764-5765).
projects/atlus/powerins/rtl/cpu/pi_m68k.sv:9 Different here: * CLK_DIV = 4: 48 MHz / 4 = 12.000 MHz, XTAL(12'000'000) nmk16.cpp:5735.
projects/atlus/powerins/rtl/video/pi_bg.sv:4 From MAME (docs/SOURCE_EVIDENCE.md "tilemap 0", "scrolling", "tile banking"): VRAM 0x140000-0x143fff, 0x2000 words (nmk16.cpp:1206) index = { row[4], col[7:0], row[3:0] } (tilemap_scan_pages nmk16_v.cpp:34-37) 256 x 32 tiles = 4096 x 512 p
projects/atlus/powerins/rtl/video/pi_bg.sv:9 colour = { attr[11], attr[15:12] } -> palette 0x000 / 0x100 via 22.u81 opaque, no transparent pen scroll X = {reg0, reg1}, Y = {reg2, reg3}, bytes at 0x130001/3/5/7 tilemap_x = screen_x - 32 + scrollx, tilemap_y = frame_line + scrolly
projects/atlus/powerins/rtl/video/pi_bg.sv:61 ------------------------------------------------------------ scroll register MAME maps 0x130000-7 as RAM with umask 0x00ff: four readable bytes on the LOW data lane, high byte reads 0.
projects/atlus/powerins/rtl/video/pi_tx.sv:4 What it is, from MAME (docs/SOURCE_EVIDENCE.md "tilemap 1"): VRAM 0x170000-0x170fff, mirror 0x171000 (nmk16.cpp:1207) TILEMAP_SCAN_COLS, 64 x 32 tiles: index = col*32 + row (nmk16_v.cpp:200) [15:12] colour, [11:0] code (:46-50) pen 15 trans
projects/atlus/powerins/rtl/video/pi_tx.sv:12 FG ROM tile 0 is all 0xFF (ROM_MEASURED), so FBNeo skipping code 0 and MAME drawing it give the same picture (EMULATOR_DIFF D5).
projects/atlus/powerins/rtl/video/pi_timing.sv:4 Not MAME's screen parameters: the PCB's own counters and PROMs (docs/VIDEO_TIMING.md, docs/PLD_PROM_ANALYSIS.md 1-2, DECISIONS D4).
projects/atlus/powerins/rtl/video/pi_sprlist.sv:4 What the list is (MAME nmk16spr.cpp:15-30, get_flip_extcode_powerins nmk16_v.cpp:355-359; FBNeo d_powerins.cpp:1310-1335 agrees field by field): work RAM 0x188000-0x188fff, 256 entries x 8 words w0 bit0 visible w1 bit12 flip X, bit8 code
projects/atlus/powerins/rtl/video/pi_sprlist.sv:14 The hardware manual's timing chart (quoted in nmk16.cpp:4478-4497) says "CPU is stopped during DMA", 694 us.
projects/atlus/powerins/rtl/video/pi_sprlist.sv:15 Here the 68000 is held (cpu_hold) for the copy's own length, 2049 clocks = 43 us: that keeps the copy atomic, as MAME's memcpy is, without the full 694 us.
projects/atlus/powerins/rtl/video/pi_sprlist.sv:24 Tile order rows-then-columns, code + row*(columns) + column, and flip X places the columns right to left (MAME; FBNeo is column-first, EMULATOR_DIFF D3 -- every sprite this game shows is one column wide, so the two agree).
projects/atlus/powerins/rtl/video/pi_sprlist.sv:28 Screen position, 10-bit arithmetic with wrap: X = (w4 + 32) & 0x3ff Y = (w6 - 16) & 0x3ff EMULATION_DERIVED T-SPR-XY: MAME's videoshift 92 = HBLANK end 60 + 32, and its cliprect starting at frame line 16; FBNeo's +32 / -16.
projects/atlus/powerins/rtl/video/pi_sprrend.sv:5 The evidence: * MAME's sprite limit is a clock budget of one frame's length (448 x 263, nmk16.cpp set_screen_midres) -- a drawing-time limit, not a per-line one * MAME draws the list from TWO DMA copies back ("2 buffers confirmed on PCB"),
projects/atlus/powerins/rtl/video/pi_sprrend.sv:11 The visible timing it produces is MAME's: the list copied at DMA k is on screen in frame k+2.
projects/atlus/powerins/rtl/video/pi_sprrend.sv:20 ---- a tile ------------------------------------------------------------------- sprites ROM is gfx_8x8x4_col_2x2_group_packed_msb after WORD_SWAP (MAME gfx_powerins, generic.cpp:180): a tile is 128 bytes, column 0-7 rows 0-15 then column 8-
projects/atlus/powerins/rtl/video/pi_video.sv:129 From MAME: tilemap.cpp effective_row/colscroll with xextent 440 / yextent 256 and scrolldx 92 both ways (nmk16_v.cpp VIDEO_START powerins), nmk16spr.cpp sx = 440-16-sx, sy = 256-16-sy with the unit order and flip X reversed.
projects/atlus/powerins/rtl/video/pi_colmix.sv:5 MAME loads it as "color" and never reads it; the decode is in docs/PLD_PROM_ANALYSIS.md 3:
projects/atlus/powerins/rtl/video/pi_colmix.sv:13 The PROM's contents are consistent with it and with three independent MAME colour bases (TX 0x200, sprites 0x400 x 64, BG 0x000 x 32), and inconsistent with the opposite polarity (a clear TX pen would cover the screen).
projects/atlus/powerins/rtl/video/pi_colmix.sv:18 Palette 0x120000-0x120fff, 2048 x RRRRGGGGBBBBRGBx (nmk16.cpp:5750): R5 = {w[15:12], w[3]} G5 = {w[11:8], w[2]} B5 = {w[7:4], w[1]} expanded {x5, x5[4:2]} as MAME's pal5bit and FBNeo's CalcCol both do.
README.md:24 이 코어는 MAME 의 동작을 FPGA 로 옮기는 데서 멈추지 않고, **원래 기판이 그 동작을 어떻게 만들었는지를 하드웨어 구조로 다시 세우는 것**을 목표로 했습니다.
README.md:25 예를 들어 비디오 타이밍, 인터럽트, 스프라이트 DMA 시점, 레이어 믹싱은 MAME 의 상수를 박아 넣은 것이 아니라 ROM 세트에 들어 있는 PROM 세 개 (`20.u54`, `21.u71`, `22.u81`) 를 FPGA 안에서 실제로 읽어 만들어 냅니다.
README.md:31 | MAME 세트 | 공식 명칭 | 상태 |
README.md:33 | `powerins` | Power Instinct (USA) | 실기에서 플레이 가능. 부팅·어트랙트·대전·P1/P2 입력·flip screen·사운드 확인. 실기 캡처 대부분이 MAME 와 픽셀 단위로 동일 |
README.md:56 직접 마련한 MAME ROM 세트 zip 을 SD 카드의 `/games/mame/` 에 넣습니다.
README.md:58 zip 은 MAME 세트 이름 그대로 두고, 압축을 풀지 않습니다.
README.md:118 | 2026-09-15 | MAME / FBNeo 소스 조사, 메모리 맵·클럭·PROM 해석, 첫 RTL. 시뮬레이션에서 부팅 RAM CHECK 화면이 MAME 와 일치 |
README.md:119 | 2026-09-15 | IRQ 래치 구조 수정 (프레임당 IRQ4 한 번). **실기 첫 화면** — WARNING·FBI 화면이 MAME 와 동일 |
README.md:120 | 2026-09-15 | 68000 프로그램 ROM 캐시. 시뮬레이션의 부팅 타이밍이 MAME 와 맞음 |
README.md:121 | 2026-09-15 | 스프라이트 (DMA, 리스트 순회, 2 페이지 프레임 저장). ATLUS 로고와 어트랙트 대전 장면이 실기에서 MAME 와 픽셀 동일 |
README.md:126 | 2026-09-16 | 실기 검증: flip screen (캡처 30 장 전부 MAME 와 같은 그림), P1 입력 전부, P2 입력, 30 분 연속 어트랙트 (멈춤 없음, 27 분 시점 프레임이 MAME 와 픽셀 동일) |
README.md:127 | 2026-09-16 | 시뮬레이션에 실제 Z80 을 붙여 사운드 프로그램이 MAME 와 같은 버스 트래픽을 내는 것을 확인. 소스별 음량을 MAME 와 측정 비교해 믹스 보정 |
README.md:132 메모리 맵은 MAME `powerins_map` 을 그대로 따랐고, 미매핑 읽기는 MAME 와 같이 0 을 돌려줍니다.
README.md:141 **레이어 믹서 (`22.u81`)** — MAME 는 이 PROM 을 로드만 하고 우선순위는 코드로 정합니다.
README.md:143 PROM 32 바이트의 모양 (출력 enable 3 비트 중 정확히 하나만 0) 에서 주소 핀 배선을 역으로 추론했고, 이 해석으로 만든 골든 모델이 MAME 91 프레임과 픽셀 단위로 일치했습니다.
README.md:150 실기에서 MAME 와 같은 그림이 나오는 것을 확인했습니다.
README.md:152 **사운드** — T80 Z80 @ 6 MHz (두 위상의 클럭 enable 로 정확히), jt03 YM2203 @ 1.5 MHz, jt6295 ×2 @ 4 MHz (PIN7 low), NMK112 뱅크 스위치 (MAME 의 장치 동작을 새 RTL 로 작성).
README.md:155 **믹스** — 각 칩의 출력 스케일을 하나의 기준으로 맞춘 뒤 MAME 의 라우팅 게인 (YM2203 2.0, M6295 각 0.15, 모노) 을 적용합니다.
README.md:156 이 비율은 시뮬레이션에서 소스별 RMS 를 MAME 렌더와 비교해 보정했고, 보정 후 FM −0.03 dB, SSG +0.01 dB, M6295 +0.00 dB, 전체 +0.01 dB 차이로 맞췄습니다.
README.md:163 **MAME 의 IRQ4 위상.** MAME 의 인덱싱 식은 주석과 달리 IRQ4 를 화면 라인 28 에서 냅니다 (계산과 MAME 실행 측정이 66 라인 차이로 정확히 일치).
README.md:165 **게임 진행의 분기.** 시뮬레이션과 MAME 의 게임 진행이 갈라지는 원인을 추적해 보니, 스타트 버튼을 누를 때 IRQ4 카운터 값을 난수로 쓰는 루틴이었습니다.
README.md:166 입력 위상만 맞추면 코인 → 캐릭터 선택 → 월드맵 → 대전까지 난수 호출과 사운드 명령이 MAME 와 하나도 다르지 않게 진행됩니다.
README.md:172 남는 차이 1–2 장은 HUD 를 표시 도중에 쓰는 프레임으로, 원판·MAME 의 그리기 시점 차이입니다.
README.md:173 **팔레트·스크롤 레지스터 셀프 테스트, YM2203 I/O 포트** 등 소스만으로 애매한 부분은 MAME 를 실행해 실제 접근 횟수를 세어 판단했습니다.
README.md:178 먼저 **MAME 팀**에 깊이 감사드립니다.
README.md:178 이 코어의 메모리 맵, 클럭, 입력·DIP 정의, 스프라이트·타일 포맷, 사운드 라우팅, NMK112 의 동작, 그리고 기판 레이아웃 노트까지 모두 MAME 소스에서 배웠습니다.
README.md:179 MAME 를 직접 실행해 얻은 화면·소리·버스 트래픽이 이 코어를 검증하는 골든 레퍼런스였습니다.
README.md:183 MAME: <https://www.mamedev.org/> · <https://github.com/mamedev/mame>
README.md:203 참고한 MAME 소스
README.md:205 MAME 소스는 사실 확인과 동작 이해에 사용했고, RTL 주석에 파일과 줄 번호로 인용해 두었습니다 (기준 커밋 `446356f29ee59b4f2dad4f93408b1aaa33fae926`).
README.md:206 NMK112 는 MAME 장치 구현을 읽고 같은 동작을 새 RTL 로 작성했습니다.
README.md:209 | MAME 파일 | 라이선스 | copyright-holders | 참고한 내용 |
README.md:211 | `src/mame/nmk/nmk16.cpp` | BSD-3-Clause | Mirko Buffoni, Nicola Salmoria, Bryan McPhail, David Haywood, R. Belmont, Alex Marshall, Angelo Salese, Luca Elia |
README.md:212 | `src/mame/nmk/nmk16_v.cpp` | BSD-3-Clause | (위와 같음) | 타일맵 스캔 방식, 스크롤 오프셋, powerins 스프라이트 속성 디코드 |
README.md:213 | `src/mame/nmk/nmk16spr.cpp` | BSD-3-Clause | (위와 같음) | 스프라이트 리스트 포맷, flip 시 좌표 |
README.md:214 | `src/mame/nmk/nmk_irq.cpp` | BSD-3-Clause | Sergio Galiano | H/V 카운터 범위와 타이밍 PROM 인덱싱 (비디오 타이밍 설계 문서에서 참고) |
README.md:215 | `src/devices/machine/nmk112.cpp` | BSD-3-Clause | Alex W. Jackson | NMK112 레지스터, 리셋값, 뱅크 마스크, 테이블 영역 페이징 |
README.md:216 | `src/emu/video/generic.cpp` | BSD-3-Clause | Nicola Salmoria | 스프라이트 타일 그래픽 레이아웃 |
README.md:217 | `src/emu/drawgfx.cpp` | BSD-3-Clause | Nicola Salmoria, Aaron Giles | 스프라이트끼리의 우선순위 (뒤 엔트리가 위) |
README.md:218 | `src/emu/tilemap.cpp` | BSD-3-Clause | Aaron Giles | flip 시 스크롤 계산 |
README.md:222 **FBNeo** (<https://github.com/finalburnneo/FBNeo>, `d_powerins.cpp`, `nmk112.cpp`) — MAME 와 독립적으로 같은 하드웨어 사실을 말하는지 교차 확인하는 데만 썼습니다.
README.md:237 MAME 소스에서 인용한 사실은 MAME 의 BSD-3-Clause 에 따라 출처를 밝혔습니다.
README.md:247 HUD 를 표시 도중에 쓰는 일부 프레임에서 MAME 와 한 프레임 위상 차이가 납니다.
README.md:248 **하드웨어 근거가 아직 없는 부분.** flip screen 의 좌표 변환, DMA 동안 68000 정지 여부, 팔레트 5→8 비트 확장, 미디코드 주소의 읽기값, 사운드 믹스 비율 (원판 DAC·앰프 대신 MAME 균형에 맞춤) 은 MAME 동작을 따른 것이며, 실제 기판 측정으로

Says it matches, follows or was checked against MAME — 3

projects/atlus/powerins/rtl/video/pi_sprlist.sv:18 HYPOTHESIS T-SPR-3 -- neither the stop mechanism (BR/BG?) nor the duration is verified; MAME leaves its CPU stop commented out.
projects/atlus/powerins/rtl/video/pi_sprlist.sv:36 MAME's prio_transpen reaches the same result (reverse order, first write wins, drawgfx.cpp pmask |= 1<<31), FBNeo draws in order; the golden model matched MAME on 91/91 frames with this rule (docs/SPRITE_ANALYSIS.md).
projects/atlus/powerins/rtl/video/pi_video.sv:132 pi_goldmodel.py, rendering unflipped and turning the picture, matches all 91 frames of a MAME run with the Flip Screen DIP on.

Says it was translated, ported or taken from MAME — 1

projects/atlus/powerins/rtl/video/pi_sprlist.sv:11 ---- DMA ------------------------------------------------------------------- At the rising edge of 21.u71's /SPR-DMA (line 242, docs/PLD_PROM_ANALYSIS.md 2) the whole 0x1000-byte list is copied into the list buffer, as MAME's sprite_dma() d

Shares text with the MAME driver without saying so — 2

projects/atlus/powerins/rtl/video/pi_bg.sv:15 The ROM is gfx_8x8x4_col_2x2_group_packed_msb: a tile is four 8x8 blocks — shares text with nmk/nmk16.cpp:4184
projects/atlus/powerins/rtl/video/pi_sprrend.sv:21 sprites ROM is gfx_8x8x4_col_2x2_group_packed_msb after WORD_SWAP (MAME — shares text with nmk/nmk16.cpp:4184

PowerSpikes (yaguboo)#
Super Volley '91
yaguboo/Arcade-PowerSpikes_MiSTer @ 44a3fe0a
MAME compared: vsystem/pspikes.cpp + 4 related file(s)
Read: 12 HDL files, 4,411 lines (all HDL files: no Quartus project found)

yaguboo
repository only

Mostly MAME

medium

93%

Statements: 1 toward hardware, 104 toward MAME

Cites hardware documentation that MAME's driver does not — 1

projects/vsystem/power_spikes/rtl/memory/ps_memarb.sv:50 MAME's YM2610 was dumped and read its ADPCM-A ROM ~9 300 times a second against this board's 655 000, which was written up as a seventyfold over-fetch.

Cites MAME source — 92

projects/vsystem/power_spikes/integration/ps_download.sv:14 tools/build_rom.py has already byteswapped the 68000 region relative to the file on disk (MAME's ROM_LOAD16_WORD_SWAP), so the two conventions meet exactly here.
projects/vsystem/power_spikes/rtl/ps_main.sv:113 irq1_line_hold in MAME: asserted at vblank, released when the CPU acknowledges.
projects/vsystem/power_spikes/rtl/ps_main.sv:145 Decoded exactly as MAME lists the ranges.
projects/vsystem/power_spikes/rtl/ps_top.sv:103 docs/HARDWARE.md section 3 says Power Spikes writes 0x57 and 0x77 there; reading them back off real hardware turns that from a MAME comment into a measurement.
projects/vsystem/power_spikes/rtl/ps_top.sv:280 Sprite RAM is write-only from the CPU (MAME maps it .writeonly()), so its A-port read is unused; the sprite engine reads it on the B port.
projects/vsystem/power_spikes/rtl/ps_top.sv:344 MAME uses `irq1_line_hold`, and HOLD_LINE means held until the CPU ACKNOWLEDGES it -- MAME clears it in its IRQ callback.
projects/vsystem/power_spikes/rtl/ps_top.sv:768 MAME cannot answer this: it renders a whole frame from one snapshot at screen_update time and never sees the race.
projects/vsystem/power_spikes/rtl/ps_top.sv:778 The first version ORed sprite, tilemap, raster and palette writes and remembered the last of them -- and the same mistake, made first in the MAME lua, is what produced a "burst width" of p99 33.9 lines that turned out to be a sparse VRAM tr
projects/vsystem/power_spikes/rtl/ps_top.sv:782 Asked per region, MAME says raster and palette always finish inside blanking and only sprite and tilemap ever run past it.
projects/vsystem/power_spikes/rtl/ps_top.sv:786 MAME measured the same quantity on the same game, with an unobstructed 68000: sprite median 7.6 lines, p99 34.2, max 89.0, and tilemap present on only 24 frames of 539 and past line 16 on every one of them.
projects/vsystem/power_spikes/rtl/ps_top.sv:803 ...and where the burst STARTS, which is what separates the two explanations for it ending at line 23-25 where MAME's ends at 7.6.
projects/vsystem/power_spikes/rtl/ps_top.sv:806 starts near line 0 -> the burst is ~23 lines wide against MAME's ~7, so this core's 68000 really is that much slower starts near line 16 -> the burst is the SAME width as MAME's and simply begins 16 lines late, which is an interrupt-phas
projects/vsystem/power_spikes/rtl/ps_top.sv:812 Worth measuring rather than reasoning about, because the ROM-throughput counters say this CPU is only 1.33x slower than MAME's, and 1.33 does not produce 3.1.
projects/vsystem/power_spikes/rtl/ps_top.sv:815 ...and HOW MANY sprite words the frame writes, because "the burst is wider than MAME's" is only a statement about speed if the work is the same.
projects/vsystem/power_spikes/rtl/ps_top.sv:817 MAME, over the whole 57-second attract loop, writes 65+ words on 2268 of 3479 frames and finishes those by line 10.2 (p90 16.4, max 18.2); this board finishes at 24.
projects/vsystem/power_spikes/rtl/ps_top.sv:819 If the board is writing far more words than any MAME frame, the difference is the scene, not the core.
projects/vsystem/power_spikes/rtl/memory/ps_romcache.sv:20 Its whole per-frame video update runs in one burst inside vertical blanking, and MAME -- the same game, an unobstructed 68000 -- finishes that burst at line 16.1 where this core's blanking ends at 16.
projects/vsystem/power_spikes/rtl/memory/ps_memarb.sv:34 MAME's own sprite load makes the same prediction: 14 tile-rows on the busiest line of the demo match is about 756 clocks, and 756 clocks is 135 pixels of a 352-pixel line.
projects/vsystem/power_spikes/rtl/memory/ps_memarb.sv:50 MAME's YM2610 was dumped and read its ADPCM-A ROM ~9 300 times a second against this board's 655 000, which was written up as a seventyfold over-fetch.
projects/vsystem/power_spikes/rtl/memory/ps_memarb.sv:52 It is not: MAME's device model counts the bytes its decoder consumed, while jt10 -- like the real chip -- reads its ROM pins once per 666 kHz slot across six interleaved channels.
projects/vsystem/power_spikes/rtl/memory/ps_memarb.sv:87 A byte that arrives after the slot has moved on is a WRONG NIBBLE, and jt10_acc amplifies ADPCM-A by 7.25x on its way into the mix, so one wrong nibble becomes an output step that correct audio never makes: measured at 15 jumps over 2048 in
projects/vsystem/power_spikes/rtl/cpu/ps_m68k.sv:79 MAME: irq1_line_hold, and its comment says "all irq vectors are the same", so the board has no vector generator.
projects/vsystem/power_spikes/rtl/video/ps_tilemap.sv:18 tile_x = (bitmap_x + rasterram[screen_y]) & 0x1FF tile_y = (bitmap_y + scrolly) & 0x0FF bitmap_x = screen_x + 4 (MAME visarea starts at x = 4)
projects/vsystem/power_spikes/rtl/video/ps_tilemap.sv:25 ---- pixel order -------------------------------------------------------- gfx_8x8x4_packed_lsb, from src/emu/video/generic.cpp: x order { 1*4, 0*4, 3*4, 2*4, ...
projects/vsystem/power_spikes/rtl/video/ps_tilemap.sv:101 MAME's own raster RAM holds 0x1FE7 (mod 512 = 487) for EVERY line from 0 to 183, so the message row and the court share one scroll value there -- yet on the board the message row lands 2 character cells (16 px) right of MAME's while the cou
projects/vsystem/power_spikes/rtl/video/ps_tilemap.sv:131 MAME has no pipeline -- it draws each row with that row's own scrollx -- so the two disagree in exactly the leftmost tile, which is what a board-vs-MAME comparison measured: the leftmost 8 columns differ on every frame, 1010-1225 pixels of
projects/vsystem/power_spikes/rtl/video/ps_tilemap.sv:160 H_FETCH_LEAD = MAME's visarea offset (4) plus the pipeline lead, and the TOTAL was calibrated against MAME rather than reasoned about.
projects/vsystem/power_spikes/rtl/video/ps_tilemap.sv:161 Sweeping the background band of a board screenshot against MAME's own frame gave
projects/vsystem/power_spikes/rtl/video/ps_tilemap.sv:182 Measured: with the early scroll alone the leftmost 8 columns still differed from MAME on 805-1054 of 1920 pixels, and the colours were another tile's, not a shifted version of the right one.
projects/vsystem/power_spikes/rtl/video/ps_tilemap.sv:229 Using vcnt alone left exactly eight pixels wrong in the whole frame: row 0, columns 0-7, black where MAME had tile colour.
projects/vsystem/power_spikes/rtl/video/ps_video.sv:4 Layer order on this board (MAME screen_update_pspikes): tilemap -> sprites priority 1 -> sprites priority 0 The tilemap is the bottom layer, it is OPAQUE (no transparent pen), and there is nothing under it -- so palette entry 0 is never
projects/vsystem/power_spikes/rtl/video/ps_video.sv:13 Palette: 2048 entries of xRGB555 = xRRRRRGGGGGBBBBB (MAME emupal.h).
projects/vsystem/power_spikes/rtl/video/ps_video.sv:136 Power Spikes is a cocktail-capable board and MAME marks its cocktail support "preliminary", so this is the least-trustworthy part of the file.
projects/vsystem/power_spikes/rtl/video/ps_video.sv:166 The sprite engine runs on RAW hcnt/vcnt, not the flipped coordinates: it renders into a line buffer indexed by the sprite's own X, and MAME applies flip_screen inside the sprite maths (ox -> 308-ox, and the flip bits invert).
projects/vsystem/power_spikes/rtl/video/ps_sprite.sv:22 MAME advances the index once per tile and then applies a correction per row (handle_xsize_map_inc): +1 for xsize 2, +3 for 4, +2 for 5, +1 for 6.
projects/vsystem/power_spikes/rtl/video/ps_sprite.sv:29 The hardware lays sprite tiles out in power-of-2 blocks; MAME's four special cases are that one fact written as a table.
projects/vsystem/power_spikes/rtl/video/ps_sprite.sv:41 MAME's own header says the zoom is "probably not 100% accurate" and that pspikes' zooming attract-mode text "is horrible", so this is the first place a pixel comparison should be expected to disagree.
projects/vsystem/power_spikes/rtl/video/ps_sprite.sv:45 ---- layering ----------------------------------------------------------- MAME draws pri==1 sprites, then pri==0, both over the tilemap, each pass walking the list from `first` UP to the end, and later writes winning -- which is the same pi
projects/vsystem/power_spikes/rtl/video/ps_sprite.sv:119 The arithmetic for the screen that flickers -- 29 list entries, six 1x1 unzoomed hits -- comes to about 476 clocks of non-ROM work against a 2549-clock line, so either the time went into S_ROM waiting on SDRAM, or the list the FPGA walks is
projects/vsystem/power_spikes/rtl/video/ps_sprite.sv:142 --- The board's attract is never at the same instant as MAME's, so absolute positions cannot be compared.
projects/vsystem/power_spikes/rtl/video/ps_sprite.sv:144 map_base and the tile_no it resolves to CAN be: the sprite lookup RAM is a character table and is largely static, so `does lut[map_base] here equal lut[map_base] in MAME` is a fair question at any moment.
projects/vsystem/power_spikes/rtl/video/ps_sprite.sv:157 tile_no is known, so these four words can be compared against roms/pspikes.bin directly with no board-vs-MAME timing question.
projects/vsystem/power_spikes/rtl/video/ps_sprite.sv:302 MAME mirrors the sprite's ORIGIN and negates the per-tile offsets, on top of inverting the flip bits:
projects/vsystem/power_spikes/rtl/video/ps_sprite.sv:308 (vsystem_spr2.cpp).
projects/vsystem/power_spikes/rtl/video/ps_sprite.sv:379 Computed signed and masked afterwards, the way MAME's int arithmetic does it.
projects/vsystem/power_spikes/rtl/video/ps_sprite.sv:585 MAME walks 0x1f8 DOWN to `first`, twice, pri==1 then pri==0 -- and it is FIRST-WRITE-WINS, not last.
projects/vsystem/power_spikes/rtl/video/ps_sprite.sv:586 `prio_zoom_transpen` adds priority bit 31 to its mask, writes a non-transparent pixel only where the existing priority is unmasked, and then stamps that pixel 31, so no later sprite can replace it (drawgfx.cpp:1225, drawgfxt.ipp:216).
projects/vsystem/power_spikes/rtl/video/ps_sprite.sv:605 MAME: for (attr = 0x1F8; attr != first-4; attr -= 4).
projects/vsystem/power_spikes/rtl/video/ps_sprite.sv:681 Every text line on that screen measures 16 px right of MAME's while the background measures 0, the same offset the message line shows.
projects/vsystem/power_spikes/rtl/video/ps_sprite.sv:692 sx is MAME's ox + zoomx*cx/2, wrapped; this module then blits at sx-4.
projects/vsystem/power_spikes/rtl/video/ps_sprite.sv:697 ox, sx and blit_x now all land on overlay page 2, so one screenshot carries the whole chain: ox -> sx (MAME's formula) -> blit_x (sx-4) -> tile_w pixels
projects/vsystem/power_spikes/rtl/video/ps_dbg.sv:43 Reading them back off real hardware turns a MAME comment into a measurement, and is the first step towards decoding the GGA's timing registers.
projects/vsystem/power_spikes/rtl/video/ps_dbg.sv:112 Row 36 full 16-bit max-held peak |snd_l| MAME reaches 1350-4059 Row 37 full 16-bit max-held peak |snd_r| in its own attract, so a working chip must show four figures here.
projects/vsystem/power_spikes/rtl/video/ps_dbg.sv:117 Row 38 ADPCM-A key-on writes (bank 1 register 00) MAME: 230 in 8 s Row 39 FM key-on writes (bank 0 register 28) MAME: 76 in 8 s These shadow jt12's own address latch, so they count writes that reached a REGISTER, not writes that r
projects/vsystem/power_spikes/rtl/video/ps_dbg.sv:125 MAME does 10-18 k/s of these against 500 writes, so a board that does far fewer is not polling the chip the way the real driver does.
projects/vsystem/power_spikes/rtl/video/ps_dbg.sv:128 Row 42 last {register, data} written to bank 1 -- a spot check that the values arriving are the values MAME writes.
projects/vsystem/power_spikes/rtl/video/ps_dbg.sv:133 MAME writes it 932 times in 8 s = 116/s, once per timer service, and each service is what advances the music.
projects/vsystem/power_spikes/rtl/video/ps_crtc.sv:11 The game writes twelve GGA registers once, in the first ~100 us after reset, and never again (MAME tap, tools/mame/ps_gga.lua; all four sets write the identical values).
projects/vsystem/power_spikes/rtl/video/ps_crtc.sv:21 the written values land exactly on three numbers that were established independently of them: MAME's visarea width 352, the 240 visible lines the game itself declares through raster RAM (HARDWARE.md section 2), and the 456 x 256 totals that
README.md:27 어트랙트 화면은 MAME 가 그린 프레임과 픽셀 단위로 비교했고, 일치하는 장면 14 장 중 5 장은 84,480 픽셀 전부가 MAME 와 같았습니다.
README.md:34 | MAME 세트 | 공식 명칭 | 상태 |
README.md:36 | `pspikes` | Power Spikes (World) | **실기에서 플레이 확인.** 1인·2인 플레이, 사운드, 화면 반전, MAME 픽셀 대조까지 확인 |
README.md:37 | `pspikesk` | Power Spikes (Korea) | ROM 구성이 MAME 의 CRC 와 일치함을 확인. 부모 세트와 68000 프로그램 ROM 만 다르며, 실기 플레이는 별도로 기록되지 않음 |
README.md:56 직접 마련한 MAME ROM 세트 zip 을 SD 카드의 `/games/mame/` 에 넣습니다.
README.md:58 zip 은 MAME 세트 이름 그대로 두고, 압축을 풀지 않습니다.
README.md:116 주소 디코드와 메모리 맵은 MAME 의 `pspikes_map` 을 그대로 옮기고 FBNeo 로 교차확인했습니다.
README.md:117 수직 귀선 인터럽트는 MAME 의 `irq1_line_hold` 와 같이 **CPU 가 응답(IACK)할 때까지 유지**되며, 응답은 fx68k 의 FC=111 버스 사이클에서 직접 끌어냅니다.
README.md:120 128 KB 프로그램 ROM 은 블록 RAM 에 두어 대기 없이 읽히게 했고, 사운드 래치는 MAME 처럼 응답을 분리한 양방향 래치 + NMI 입니다.
README.md:122 포트 맵은 같은 드라이버 안의 비슷한 맵이 아니라 `spinlbrk_sound_portmap` 이 맞다는 것을 MAME 와 FBNeo 양쪽에서 확인했습니다.
README.md:126 다음 줄을 미리 그리는 블리터를 페치와 분리해 한 줄 안에 일을 끝내고, 확대·축소와 화면 반전 시의 원점 미러링, 겹침 순서는 MAME 의 `vsystem_spr2` 와 `drawgfx` 규칙을 따릅니다.
README.md:129 라인 단위 스크롤의 부호 규칙은 MAME 의 `tilemap.cpp` 에서 확인했습니다.
README.md:140 DIP 표 12 항목은 MAME 와 자동으로 대조하는 검사기로 확인했습니다.
README.md:167 각 줄의 첫 타일을 가져오지 않던 문제와, 줄 왼쪽 끝이 이전 줄의 스크롤 값을 쓰던 문제를 고쳐 MAME 와의 차이를 3,333 픽셀에서 0 으로 줄였습니다.
README.md:182 보드 프레임 20 장을 MAME 와 대조해 14 장이 같은 장면으로 매칭됐고 그 중 5 장은 픽셀 차이 0 이었습니다.
README.md:196 무엇보다 **MAME 팀**에 깊이 감사드립니다.
README.md:196 수십 년에 걸쳐 아케이드 기판을 분석하고 기록해 온 MAME 가 없었다면 이 기판의 메모리 맵, 클럭, ROM 구성, 그래픽 형식, 스프라이트 규칙을 알아낼 방법이 없었을 것입니다.
README.md:198 이 코어의 동작이 맞는지 판단하는 기준도 언제나 MAME 였습니다.
README.md:199 — https://www.mamedev.org/ , https://github.com/mamedev/mame
README.md:216 참고한 MAME 소스
README.md:218 MAME 소스는 하드웨어 사실(메모리 맵, 클럭, ROM 구성, 비트 배치, 동작 규칙)을 확인하는 데 읽었으며, MAME 의 C++ 코드를 RTL 로 옮겨 적지는 않았습니다.
README.md:219 MAME 는 프레임 단위로 그리는 구조라 이 코어의 스캔라인 페치·라인 버퍼·중재기 구조는 MAME 에 대응하는 부분이 없습니다.
README.md:221 참고한 MAME 커밋: `446356f29ee59b4f2dad4f93408b1aaa33fae926`.
README.md:223 | MAME 파일 | 라이선스 | copyright-holders | 참고한 내용 |
README.md:225 | `src/mame/vsystem/pspikes.cpp` | BSD-3-Clause | Nicola Salmoria | 드라이버 전체: 68000·Z80 메모리 맵(`pspikes_map`, `spinlbrk_sound_portmap`), 클럭, `irq1_line_hold` 인터럽트
README.md:226 | `src/mame/vsystem/vsystem_spr2.cpp` | BSD-3-Clause | Nicola Salmoria, David Haywood | 스프라이트 속성 디코드, 순회 순서, 확대·축소, 화면 반전 시 원점 미러링 |
README.md:227 | `src/emu/drawgfx.cpp`, `src/emu/drawgfxt.ipp` | BSD-3-Clause | Nicola Salmoria, Aaron Giles | 스프라이트 확대·축소 시 픽셀 샘플링 규칙과 겹침 처리 |
README.md:228 | `src/emu/tilemap.cpp` | BSD-3-Clause | Aaron Giles | 타일맵 스크롤 값의 부호 규칙 |
README.md:229 | `src/emu/video/generic.cpp` | BSD-3-Clause | Nicola Salmoria | `gfx_8x8x4_packed_lsb` 타일 그래픽 비트 배치 |
README.md:232 **FBNeo** (`src/burn/drv/pst90s/d_aerofgt.cpp`, 커밋 `da70e8799370ad64a44f9e79e0c5114b4f6dda92`) 는 MAME 에서 확인한 사실을 독립적으로 교차확인하는 용도로만 읽었습니다 (예: Z80 포트 맵).
README.md:255 사운드는 귀와 출력 레벨(MAME 대비 약 94 %)로 확인했으며, YM2610 레지스터 쓰기를 MAME 와 하나하나 대조하지는 않았습니다.
README.md:261 MAME 자체도 어트랙트의 확대 글자 표현이 완벽하지 않다고 적고 있어, 그 장면은 MAME 와 정확히 일치하지 않을 수 있습니다.
README.md:263 수직 귀선 중 게임의 비디오 갱신이 MAME 보다 약 한 줄 늦게 끝나는 경우가 있습니다(16 줄 귀선 대비 최대 17 번째 줄).

Says it matches, follows or was checked against MAME — 5

projects/vsystem/power_spikes/rtl/ps_top.sv:199 ~50 s at 61.31 Hz lands in the demo match, which MAME's own dump shows carrying 71 active sprites against 7 on the title screens.
projects/vsystem/power_spikes/rtl/video/ps_video.sv:136 NOT YET VERIFIED against hardware or MAME pixels.
projects/vsystem/power_spikes/rtl/video/ps_sprite.sv:155 ox, sx and blit_x are all confirmed identical to MAME, so position is not the fault; this says whether the DATA is.
projects/vsystem/power_spikes/rtl/video/ps_sprite.sv:672 The overlay agreed with the bug: it latched the CURRENT map_base beside the STALE lut_data, so the two numbers it showed came from different transactions and matched MAME individually.
projects/vsystem/power_spikes/rtl/video/ps_dbg.sv:169 54 rows at 4 px would cover 216 of 240 lines and leave nothing of the game to match a MAME frame against.

Says it was translated, ported or taken from MAME — 2

projects/vsystem/power_spikes/rtl/ps_main.sv:4 Every address here comes from docs/HARDWARE.md section 4, which is taken from MAME's pspikes_map and cross-checked against FBNeo.
projects/vsystem/power_spikes/rtl/video/ps_tilemap.sv:6 ---- scroll semantics --------------------------------------------------- Taken from MAME's tilemap.cpp, not guessed: the sign is easy to get backwards and a backwards scroll still looks plausible.

Keeps a MAME approximation — 1

projects/vsystem/power_spikes/rtl/video/ps_tilemap.sv:6 ---- scroll semantics --------------------------------------------------- Taken from MAME's tilemap.cpp, not guessed: the sign is easy to get backwards and a backwards scroll still looks plausible.

Shares text with the MAME driver without saying so — 4

projects/vsystem/power_spikes/rtl/cpu/ps_m68k.sv:80 "all irq vectors are the same", so the board has no vector generator. — shares text with vsystem/pspikes.cpp:2291
projects/vsystem/power_spikes/rtl/video/ps_sprite.sv:26 xsize 0 1 2 3 4 5 6 7 (tiles across = xsize+1) — shares text with vsystem/pspikes.cpp:2145
projects/vsystem/power_spikes/rtl/video/ps_sprite.sv:41 MAME's own header says the zoom is "probably not 100% accurate" and that — shares text with vsystem/pspikes.cpp:17
projects/vsystem/power_spikes/rtl/video/ps_sprite.sv:306 sx = ((ox + zoomx * (flip_screen ? -cx : cx) / 2 + 16) & 0x1ff) - 16 — shares text with vsystem/vsystem_spr2.cpp:192

Propcycle (spacestate1)#
Prop Cycle
spacestate1/Arcade_namco22_MiSTer @ 7b1324a7
MAME compared: namco/namcos22.cpp + 6 related file(s)
Read: 37 HDL files, 15,788 lines (Quartus project)

spacestate1
repository only

Mostly MAME

medium

51%

Statements: 3 toward hardware, 78 toward MAME

Cites hardware documentation that MAME's driver does not — 2

Propcycle.sv:2000 Kept in the history, not in the netlist -- a dead signal that still LOOKS meaningful is how this project manufactured a four-build phantom video freeze.
rtl/propcycle_main.sv:486 The CPU then never reaches its per-frame C00000 clear, the master DSP spins at 45DD polling for it, every INT0 is dropped (c25_missed saturates at 65535) and the 3D goes black for good.

Says it was checked on “real hardware” — 1

Propcycle.sv:1102 Live, the renderer walks from geo_head = 0x300 as soon as vblanks arrive, so it DREW THE TEST FRAME -- verified on hardware 2026-08-24 against sim/dumps/snap3d/propcycl/0001.png, visible ~30 s. Zero the array once the BIST verdict is latche

Cites MAME source — 69

Propcycle.sv:4 TG68K.C (020 mode, write-stream proven vs MAME on hardware) runs the full 4 MB program from SDRAM through the bench-proven pc_prog_bus; syscon vblank IRQ, factory- preloaded EEPROM, and protocol-spec DSP/MCU stubs take the boot toward POST;
Propcycle.sv:203 Layer isolation, the hardware equivalent of MAME's mixer byte 0x82401f.
Propcycle.sv:616 {text, sprites, poly} -- MAME 0x82401f bit order
Propcycle.sv:656 Signed8 +-127 -> +-317 around 0x1FF = 0xC2..0x33C, inside MAME's 0xBF..0x33F ADC range.
Propcycle.sv:657 MAME's ADC.0 (X) is PORT_REVERSE.
Propcycle.sv:734 MCU input words (encoding from the MAME differential, RESEARCH "inputs").
Propcycle.sv:735 Handlebar: left-analog scaled x2.5 around neutral 0x1FF (signed8 +-127 -> +-317, inside MAME's 0xBF..0x33F range); X is PORT_REVERSE in MAME, so negate.
Propcycle.sv:1167 master_enable / dsp_irq_enabled: syscon byte 0x1A on SS22 (namcos22.cpp syscon_dspcontrol) -- 0 disables, 1 enables both, 0xFF is upload mode (master runs, no interrupt).
Propcycle.sv:1410 MAME hardcodes nothing: pdp_handle_commands dispatches nine command codes, each consuming a different number of words, so the prologue length is DATA.
Propcycle.sv:1418 The record's payload[k] lives at 0x0306+k, and MAME parses src[6] as camera_zoom, src[7..a] as vr/vl/vu/vd.
Propcycle.sv:1427 payload[6] ZOOM (MAME f2400: 294548)
Propcycle.sv:1911 MAME gets this for free -- draw_sprites runs at a defined point in the frame -- so anchor to the same place.
Propcycle.sv:2170 MAME's attract header word 0 is 0x00060000, so slot 63 must read exactly that.
Propcycle.sv:2173 Word 0 already proved correct on hardware (0x00060000, exactly MAME's attract value), and the open question is word 2: the blitter computes num = word[2] - base + 1 and gets 1 on every attract frame, while MAME's own list is 5, 3, 9 and 6 a
Propcycle.sv:2388 This core is natively 640x480 progressive at 31.45 kHz (ce_pix 25.6 MHz, HTOTAL 814, VTOTAL 525 -- MAME's exact namcos22 timing, namcos22.cpp:1104-1112).
rtl/pc_c25.sv:10 Every semantic mirrors tools/pc_tms_interp.py (the executable spec, locksteppable against MAME's core).
rtl/pc_c25.sv:14 Memory map, now MAME's exactly (namcos22.cpp master_dsp_program / master_dsp_data): data 0x0000-0x3FFF RAM.
rtl/pc_c25.sv:16 MAME maps only 0x1000-0x3FFF plus the chip's internal blocks, but modelling the whole range as flat RAM matches the interpreter (which the core is gated against) and costs one BRAM.
rtl/pc_c25.sv:55 Preloading extram with the program MAME's master ends up running, plus the two pieces of state the boot leaves behind, reproduces the post-upload machine exactly and lets the per-frame transformation run for real.
rtl/pc_c25.sv:69 The whole machine is now captured from MAME at its idle loop (tools/pc_dump_mstate.lua) -- 16K words of data RAM plus ACC, all eight ARs and both status words -- and the interpreter seeded that way runs 60 frames and 24 M instructions clean
rtl/pc_c25.sv:157 BLKP source pointer (MAME's m_PFC).
rtl/pc_c25.sv:664 MAME tms32025.cpp subc(): oldacc = ACC; GETDATA(15, SXM); ACC -= ALU; if (oldacc >= ALU) ACC = ACC<<1 | 1; // UNSIGNED else ACC = oldacc<<1; and GETDATA sign-extends to 32 bits per SXM BEFORE the shift.
rtl/pc_c25.sv:674 The master's float routine at 0x473F runs it fourteen times in a banz loop, so a wrong SUBC gives a wrong mantissa, which is the viewport zoom reading 0x320000 instead of MAME's 0x294548 (37x over-scaling).
rtl/pc_c25.sv:713 MAME dispatch row /*58*/ is tblr tblw sqrs lts, and row /*38*/ is mpy SQRA mpya mpys.
rtl/pc_c25.sv:722 MAME tblr(): PFC = ACC.w.l; ALU = program[PFC]; PUTDATA(ALU); PFC++ ea was already computed in F_ADDR and is the DESTINATION; the source is program memory, which set_pm_ra selects between the c71 BIOS and extram exactly as a fetch does.
rtl/pc_c25.sv:828 SFR: LOGICAL shift right, sign replicated only when SXM is set (MAME sfr()).
rtl/pc_c25.sv:862 MAME tms32025.cpp norm(): if (ACC != 0 && (int32)(ACC ^ (ACC<<1)) >= 0) { CLR1(TC); ACC <<= 1; MODIFY_AR_ARP(); } else SET1(TC); The ACC==0 guard is not cosmetic: the master's float routine runs RPTK 0Fh + NORM *-, so with ACC zero this dec
rtl/pc_c25.sv:916 BV (0xF0) is still a loud halt -- it needs the OV latch and has an out-of-program target; validate against MAME before adding.
rtl/pc_c25.sv:934 MAME dispatch row /*F8*/ is bbz bbnz bioz banz BLKP blkd call br, so 0xFC is BLKP and BNV is 0xF7 -- HANDOFF recorded FC80 as "likely BNV" and that guess was wrong.
rtl/pc_geo.sv:4 Implements tools/pc_geo_fixed.py EXACTLY (the validated fixed-point re-model of MAME's simulate_slavedsp chain): record walk from polygonram 0x304 -> camera/view/object handlers -> blit_polyobject -> blit_quads -> per-quad Q15 transform, cu
rtl/pc_geo.sv:307 The real head is polygonram[0x7FFF] (the value the master writes every frame, MAME pdp_begin_r), plus the FFFE prologue that sits in front of the first record: the walk starts at ptr+4 because the list opens {FFFE, arg, code, ...} and the r
rtl/pc_live_regs.sv:6 MAME's own dumps at the title-logo frame (480) and the gameplay frame (2400) differ in exactly two things beyond the text palette: czattr[4] (per-bank fog enable) is 0x0000 in the sky scenes and 0x4444 in the canyon, and the mixer's fog col
rtl/pc_live_regs.sv:16 WHAT IT DOES: shadows the eight czattr words and mixer bytes 0x00-0x1F off the exported video write bus, and derives what MAME derives (namcos22_v.cpp namcos22s update_mixer, ~line 2445):
rtl/pc_live_regs.sv:30 The shadows themselves start at zero, MAME's reset state; the game writes the whole mixer block during boot init (slot 13 counts ~93k mixer writes), so by the time a live frame is rendered every byte has been written.
rtl/pc_live_regs.sv:35 Byte-lane convention copied from pc_video_s22's mixer decode: mixer byte n lives in 16-bit word n>>1, even n on the upper (uds) lane, odd n on the lower (lds) lane -- MAME's nthbyte() order for a big-endian CPU.
rtl/pc_live_regs.sv:38 czattr word k is at 0x810000 + 2k (MAME: u16 handler, offset = word).
rtl/pc_live_regs.sv:74 Sprite alpha keying (namcos22_v.cpp update_mixer): the FACTOR is per-sprite (src[3] >> 8 & 0xff), not a mixer byte -- only the two key bytes live here.
rtl/pc_live_regs.sv:124 ---- derive (MAME update_mixer) ----------------------------------------
rtl/pc_pdp.sv:4 Kicked by the master's IN PA$2 (pdp_begin); walks the command list at polygonram[polygonram[0x7FFF] & 0x7FFF] with MAME's pdp_handle_commands semantics (reference/mame/namcos22.cpp:2122): FFF0 nop; FFF5 point-RAM write (dropped, point RAM i
rtl/pc_pdp.sv:131 record code: MAME returns
rtl/pc_pixel.sv:26 The ayx swizzle is NOT a memory: MAME builds the table from a pure flip/swap of the coordinates (init_tables), so it is computed combinationally here.
rtl/pc_pixel.sv:372 ayx swizzle (MAME init_tables): flips by attr[2]/attr[1], then swap by attr[3]; value = (iy<<4)|ix AFTER the swap
rtl/pc_poly.sv:19 * C25 -- the dspram window, MAME namcos22_dspram16_r/w semantics: bank 0 = low half, bank 1 = high half, bank 2 = low half while latching the high half (that latch is what the next bank-2 write puts back), bank 3 = reads 0 / writes dropped
rtl/pc_sprite.sv:9 Why this subset: the attract title logo was decoded from MAME at frame 480 before a line of this was written, and it is the simplest case the model supports --
rtl/pc_sprite.sv:19 Building the zoom and alpha paths first would have been work with nothing on screen to show for it, and the model still owes MAME a fixed-point extent walker for the zoom case (its own note) -- that has to be settled in the MODEL before RTL
rtl/pc_sprite.sv:75 ---- sprite ALPHA ----------------------------------------------------- namcos22_v.cpp renderscanline_sprite: alphafactor = extra.alpha (the queue already stored 0xff - sprite.alpha), applied when alphafactor != 0xff && (alpha_enabled || pe
rtl/pc_sprite.sv:286 src[3] = {sw[6], sw[7]}, so MAME's (src[3] >> 8) & 0xff is sw[7][15:8].
rtl/pc_text_layer.sv:10 Geometry (namcos22_v.cpp, vendored copy): - 64x64 tiles of 16x16 px, TILEMAP_SCAN_ROWS - tile word [15:12] palette [11] flipy [10] flipx [9:0] code - char row = 8 bytes = 16 packed 4bpp pixels, even pixel in the high nibble (CPU byte ord
rtl/pc_video_s22.sv:3 3D and sprites come later; the background is the mixer's background color, exactly what MAME shows when only the text layer draws.
rtl/pc_video_s22.sv:7 Timing (namcos22.cpp): pixel 25.6 MHz (doubled progressive for the interlaced 640x480), HTOTAL 814 (visible 0..639), VTOTAL 525 (visible 0..479) -> 59.90 Hz.
rtl/pc_video_s22.sv:54 LAYER ENABLES, in MAME's own bit order for the mixer byte 0x82401f: bit0 poly/3D, bit1 sprites, bit2 text.
rtl/pc_video_s22.sv:383 NOTE: measured against MAME's text-only render, our frame sits 2 px right and 1 line down (shifting it back gives a 100.00% EXACT pixel match, so the CONTENT is bit-perfect).
rtl/pc_video_s22.sv:574 MAME's tilemap is SPACE-filled at every frame sampled from 1800 to 9000 -- ~3900-4070 cells of 0x0020 out of 4096 and EXACTLY ZERO cells of 0x0000, ever.
rtl/propcycle_main.sv:4 TG68K.C in 020 mode (write-stream proven against MAME, see RESEARCH.md "GO" verdict) on the full namcos22s memory map: 4 MB program via pc_prog_bus/SDRAM (bench-proven), 256 KB work RAM, syscon with the vblank interrupt, EEPROM preloaded wi
rtl/propcycle_main.sv:86 Found by differential against MAME: holding the SERVICE switch changes exactly ONE stable byte in COM RAM, A0BD01 00 -> 80 -- the same MCU status byte this stub already drives for the boot ack.
rtl/propcycle_main.sv:89 Bit 7 there unlocks the game's built-in diagnostics (namcos22.cpp:80 lists them: MD-DOWNLOAD, MD-EXTERNAL-RAM, C-RAM CHECK BY MD, PDP LOOP TEST, PDP BLOCK MOVE, POINT RAM, SD ROM-PRG, SD EXTERNAL-RAM, DATA FLOW 1/2, POINT ROM).
rtl/propcycle_main.sv:95 MCU input words, fully formed by the top level (encoding learned by MAME differential, RESEARCH "inputs"): BD02 buttons (bit0 coin, bit8 coin-activity, bit10 service, bit11 test), BD04 start (bit8), BD0A/BD0C handlebar X/Y (10-bit, neutral
rtl/propcycle_main.sv:114 wrcount AT the derail -> MAME op index
rtl/propcycle_main.sv:125 Only FOUR such writes exist in the entire MAME trace, so four entries hold the whole story: either they landed with the right data/lanes and something else zeroed the register (a reset pulse -- see the top-level rstcnt), or a fifth, clobber
rtl/propcycle_main.sv:455 EEPROM: byte device on the UPPER lane of each word (umask32 ff00ff00); preloaded from the download stream with MAME's factory image
rtl/propcycle_main.sv:479 eeprom_wait_write_cycle @ 0x01992C is the game's EEPROM write-cycle delay: it reads 0x8A000A as a SCANLINE counter and 0x8A000E as a frame parity, and spins until the line has advanced by 0x184 (388 lines, ~6.4 ms) across at most one parity
rtl/propcycle_main.sv:484 With ANY constant it never exits: MAME's 0x8000 gives -32768 < -32380 forever, our old default 0 gave 0 < 388 forever.
rtl/propcycle_main.sv:766 MAME's ss22_syscon_w has it at case 0x1a, but the pc-reverse decompile of the actual game (dsp_init @ 0x22C7E) writes 0x70001C=0 / 0x70001C=1 around the polygonram init -- and PC_live1's telemetry agreed: dsp_ctrl read from 0x1A stayed 00 f
rtl/propcycle_main.sv:780 DSW at 0x440000: SW4:1-8 live in bits 23:16 of the 32-bit word (MAME propcycl "DSW", all documented Unknown, active low); every other bit reads 1.
rtl/propcycle_main.sv:798 keycus (RNG in MAME; 0 here)
rtl/propcycle_main.sv:801 idles HIGH -- MAME trace R 450008 = 0x0001 @2246E
rtl/propcycle_main.sv:815 Three things are frozen at the derail so the capture describes the crime rather than the aftermath: dbg_lastgood/dbg_firstbad the transition itself dbg_wrfreeze the write count AT that moment, which indexes straight into MAME
README.md:60 MAME is the oracle: dumps come from the Lua scripts in `tools/`, the same inputs go to the RTL under Verilator, and the two are compared exactly — a pass is 0 m
README.md:77 `reference/mame/` — MAME sources used as the specification (`namcos22.cpp`, `namcos22_v.cpp`, `c352.cpp`, `namco_dsp.cpp`, `namcomcu.cpp`, `poly.h`), BSD-3-Clau

Says it matches, follows or was checked against MAME — 5

Propcycle.sv:1416 The list HEAD is now proven identical to MAME's capture (FFFE,0 / FFFE,400 / FFFD,21 / bb0003), so pc_geo's +4 prologue skip is CORRECT and is NOT the over-scaling.
rtl/pc_text_layer.sv:4 The reference is tools/render_text.py, itself proven 100.00% pixel-exact against MAME's own rendering of the propcycl title and attract screens (2026-08-10).
rtl/pc_video_s22.sv:18 Pixel-exact reference: tools/render_text.py, 100.00% vs MAME twice over.
rtl/propcycle_main.sv:498 Bit 15 is held at 1 to match MAME's 0x8000 for anything that tests it ("dirtdash has slowdowns if high bit is clear").
README.md:17 **Text layer** 100.00% pixel-exact vs MAME.

Says it was translated, ported or taken from MAME — 1

rtl/pc_sprite.sv:4 Executable spec: tools/pc_sprite_model.py (a port of MAME's draw_sprites -> draw_sprite_group -> render_sprite -> renderscanline_sprite), which is pixel-exact on both canonical frames.

Shares text with the MAME driver without saying so — 3

rtl/pc_pixel.sv:9 texel to = (ty<<4 & 0xfff00) | tx>>4; — shares text with namco/namcos22_v.cpp:88
rtl/pc_pixel.sv:444 to = (ty<<4 & 0xfff00) | tx>>4 (ty = {bank, ty_lo}) — shares text with namco/namcos22_v.cpp:88
rtl/propcycle_main.sv:500 ("dirtdash has slowdowns if high bit is clear"). — shares text with namco/namcos22_v.cpp:1977

Raiden2 (spacestate1)#
Raiden II, Raiden DX
spacestate1/Arcade-Raiden2_MiSTer @ 27021027
MAME compared: seibu/raiden2.cpp + 12 related file(s)
Read: 33 HDL files, 15,297 lines (Quartus project)

spacestate1
repository only

Mostly MAME

high

54%

Statements: 6 toward hardware, 138 toward MAME, 1 not counted

Cites hardware references or measurements that MAME's driver also gives — 1

rtl/raiden2_video_timing.sv:8 Measured on a real PCB: VSync 55.4859 Hz, HSync 15.5586 kHz. — also in MAME: 55.4859 seibu/raiden2.cpp:80, 15.5586 seibu/raiden2.cpp:81

Says it was checked on “real hardware” — 3

rtl/raiden2_seibu_latch.sv:12 Confirmed on real hardware by a 2025 repair log (Oguz, Museum of the Game): a Raiden II with every graphics fault fixed and a perfect picture still would not take a coin; the fault was a dead sound RAM, and replacing it made coins work.
README.md:231 The exact zips this core was verified against on hardware:
README.md:432 Every chip checked this way worked on real hardware the first time.

Notes where it differs from MAME — 3

rtl/nec_core/alu.sv:128 TODO - MAME doesn't update these flags, but documentation says it should flags.AC = ta[3:0] > 4'd0 ?
rtl/raiden2_cop_cmd.sv:65 Raiden II also uploads 0x1905, 0x9100 and 0x9900, which MAME's dispatch does not handle at all.
rtl/raiden2_uart_stream.sv:126 But the second insert is a consequence: our core also writes 9F4E from 98A75 / 98AAD / 9AAB3 / 9AB9E, four sites MAME never executes at all.

Cites MAME source — 99

Raiden2.sv:6 The Seibu-specific RTL is ours; MAME's seibu driver sources (LGPL-2.1+, Olivier Galibert, Angelo Salese, David Haywood, Tomasz Slanina et al.) are the behavioural reference throughout.
Raiden2.sv:220 0x0205 is the object position-update the plasma beam's segments ride on; MAME issues it ~2.6x more often than we do.
Raiden2.sv:221 Per-FRAME counts so the board's rate is directly comparable with MAME's, rather than a cumulative total that saturates and tells us nothing (the FFE4 mistake).
Raiden2.sv:282 Vertical monitor (MAME ROT270), so the native picture is 240x320.
Raiden2.sv:284 MAME runs this game ROT270, which is a CCW (TATE) rotation.
Raiden2.sv:1006 The handler runs its full path with interrupts enabled (sti at A1AC9) and relies on the B166 guard to make a nested vblank harmless; MAME's reference never nests at all (HANDOFF 7d).
Raiden2.sv:1050 The ROM image is little-endian 16-bit words, but MAME's gfx bit numbering is MSB-first across the 4 bytes of a tile row, so the 32-bit word has to be byte-swapped into big-endian before sei0200 indexes it.
Raiden2.sv:1061 With the ROM little-endian, the bytes in address order are dout[7:0], [15:8], [23:16], [31:24]; the swap below therefore puts the LOWEST address in the most significant position, which is MAME's MSB-first tile-row bit numbering.
Raiden2.sv:1110 Layout follows the arcade convention MAME uses, so muscle memory carries over: arrows move, Ctrl fires, Alt drops a bomb, 5 inserts a coin, 1 starts.
Raiden2.sv:1190 P1_P2 layout is MAME's: P1 in bits 6:0 and P2 in 14:8, with bits 7 and 15 unused.
Raiden2.sv:1227 DSW bit 15 is the board's TEST MODE switch, SW2:8 -- MAME raiden2: PORT_SERVICE( 0x8000, IP_ACTIVE_LOW ) PORT_DIPLOCATION("SW2:!8") and raidendx inherits it through PORT_INCLUDE.
Raiden2.sv:1283 Hardware shows 0x9EC6 -- the seconds counter it rolls into -- is NEVER written, while MAME writes it every 60 frames.
Raiden2.sv:1288 MAME never writes this flag at all through a full coin+start, so the first write caught here IS the anomaly.
Raiden2.sv:1414 MAME draws each frame with a single scroll value, and so should we.
Raiden2.sv:1627 MAME uses alpha_blend_r32(dst, src, 0x7f) for the blended entries, i.e. an even mix of the pixel and whatever is behind it.
Raiden2.sv:1692 MAME's map hands the lambda a word index and the lambda shifts it again -- so main_r/main_w see offsets 0..7 across 32 bytes.
rtl/raiden2_addr_decode.sv:68 (MAME raidendx_mem) The "???" is now answered: the CPU stores the foreground tile-bank byte here and COP command 0x7e05 reads it back (cop_regs[4] = 0x4D0 on every observed trigger) to write it into 0x470.
rtl/raiden2_addr_decode.sv:86 Raiden DX rearranges this completely (MAME raidendx_mem): map(0x20000, 0x2ffff).bankr(m_mainbank); 64K window map(0x30000, 0xfffff).rom().region(..0x30000) fixed from 0x30000 with configure_entries(0, 0x10, base + 0x100000, 0x10000) --
rtl/raiden2_addr_decode.sv:129 dx_scratch excluded here too: MAME's .ram() overlay at 0x4D0-0x4D7 overrides the COP device range it sits inside, so on DX those eight bytes must decode as RAM and nothing else.
rtl/raiden2_addr_decode.sv:135 MAME maps 0x6CC as a single BYTE (tile_bank_01_w takes a u8), so only the even address decodes -- a byte write to 0x6CD is not it.
rtl/raiden2_cop_cmd.sv:14 IMPORTANT -- what MAME's COP actually is:
rtl/raiden2_cop_cmd.sv:16 MAME is a high-level SIMULATION.
rtl/raiden2_cop_cmd.sv:38 Note MAME maps only SEVEN of the eight pointer registers (0x4A0-0x4AD is 14 bytes).
rtl/raiden2_cop_cmd.sv:55 Every one of these is diffed against MAME by sim/tb_cop_cmd.cpp.
rtl/raiden2_cop_cmd.sv:55 The trig ops are the interesting case: MAME computes them in C doubles, so the RTL has to reproduce a truncated double exactly.
rtl/raiden2_cop_cmd.sv:97 ---- COP 0x7e05, Raiden DX only ---------------------------------- MAME (seibucop_cmd.ipp, tagged "raidendx"): write_byte(0x470, read_byte(cop_regs[4])) 0x470 is the tile bank register, and on DX its low bits select the FOREGROUND bank.
rtl/raiden2_cop_cmd.sv:112 MAME issues 0x0205 ~2.6x more often than we do, measured over the same gameplay -- these strobes let the board say so directly.
rtl/raiden2_cop_cmd.sv:136 0x41C angle target, 0x41E angle step (both for the 0x6200 macro) 0x444 scale -- MAME masks it to 2 bits, so (5 - cop_scale) is 2..5 and the shift below can never go negative.
rtl/raiden2_cop_cmd.sv:309 trunc(atan(t)*128/pi) is the largest k with tan(k*pi/128) <= t, so the whole op reduces to comparisons -- no divide, and exact against MAME's double over 200k random and 90k swept operand pairs.
rtl/raiden2_cop_cmd.sv:367 amp = (65536 >> 5) * amp8, doubled at one specific angle per op -- a quirk MAME carries because the bootleg does it too.
rtl/raiden2_cop_cmd.sv:466 The overlap test compares BOTH slots, and MAME runs it with the slot under test already updated -- so that slot reads from the combinational box above while the other reads from its stored one.
rtl/raiden2_cop_cmd.sv:483 That is MAME's polarity and the game depends on it.
rtl/raiden2_cop_cmd.sv:534 MAME reads a WORD and writes a DWORD at both destinations, so the upper half is the carry-out of a 16-bit add rather than a preserved value.
rtl/raiden2_cop_cmd.sv:631 MAME computes the sqrt in double, but the argument is an exact integer, so floor(sqrt(n)) is exactly the integer square root and an iterative unit matches it bit for bit.
rtl/raiden2_cop_cmd.sv:743 Both differences are taken at full width and only then shifted down by 16, exactly as MAME does.
rtl/raiden2_cop_cmd.sv:833 Proven against 906 real-MAME gameplay vectors (make vec-run).
rtl/raiden2_cop_cmd.sv:862 MAME: &= 3
rtl/raiden2_cop_cmd.sv:870 MAME clears the top status bit on every command.
rtl/raiden2_cop_cmd.sv:988 MAME writes 0 and flags status bit 15 instead of dividing; it does NOT set status to 7 here.
rtl/raiden2_cop_cmd.sv:1018 MAME sign-extends both halves before subtracting, but only the low 16 bits are ever stored, and those are identical either way.
rtl/raiden2_cop_cmd.sv:1075 The FULL dword difference, not the >>16 form the sqrt op uses: MAME subtracts whole dwords here.
rtl/raiden2_cop_dma.sv:21 The other modes MAME implements (fill, palette fade 0x80-0x87, word copy 0x09/0x0E, z-sort) are used by other Seibu games, not by this one; they are deliberately not implemented, and an unrecognised mode raises dma_unknown rather than silen
rtl/raiden2_cop_dma.sv:31 MAME rewrites it to 0xD000.
rtl/raiden2_cop_dma.sv:31 Note that reading the dst register as SIGNED (0xFFFE = -2) makes MAME's general size formula ((size<<5) - (dst<<6) + 0x20) evaluate to exactly 0x2800, which supports the "it also sets up odd size / dest regs, they probably counteract this"
rtl/raiden2_cop_dma.sv:42 MAME performs the whole transfer instantaneously mid-instruction; this block instead holds the CPU off the bus for the duration, which is the conservative choice.
rtl/raiden2_cop_dma.sv:107 0x118-0x11F all map to MAME's dma_fill().
rtl/raiden2_cop_dma.sv:121 Modes MAME actually implements.
rtl/raiden2_cop_dma.sv:127 Flagging the latter produced a false COP MODES KNOWN failure on hardware reporting mode 0x000: the game triggers 0x6FC without having selected a channel, MAME ignores it, and so should we.
rtl/raiden2_cop_dma.sv:140 Length the game ACTUALLY asked for, in words: MAME's size convention is (size+1) * 32 bytes = (size+1) << 4 words -- the same formula the fill path below already uses.
rtl/raiden2_cop_dma.sv:148 Measured against MAME through gameplay (tools/oracle_dmaparm.lua) the game issues 26 distinct parameter sets, walking src 0x301->0x30B+ while size SHRINKS 0x7D->0x69 -- a fade repainting an ever-smaller tail of the palette.
rtl/raiden2_cop_dma.sv:333 MAME's dma_fill() silently returns when dst is non-zero, so that is a no-op and NOT an unknown mode.
rtl/raiden2_cop_itoa.sv:13 MAME: val = cop_itoa; digits = 9 for i in 0..8: if (!val && i) d[i] = (mode == 3) ?
rtl/raiden2_cop_itoa.sv:19 Note MAME's comment about mode applies to cop_itoa_MODE, not to itoa: a full attract run reads the digit results 120 times, so the score display really does go through the COP on this title.
rtl/raiden2_cop_itoa.sv:26 The leading-blank rule is then equivalent to "blank every digit above the most significant non-zero one, except digit 0, which is always shown" -- which is what MAME's `!val && i` test computes as it divides down.
rtl/raiden2_cop_itoa.sv:83 Gating them on !busy silently dropped the second of two back-to-back writes -- which is exactly what the game does when it sets 0x422 then 0x420 -- and MAME's bcd_update() is instantaneous, so every write must take effect.
rtl/raiden2_diag.sv:20 8 frames (0.14 s) is fine for events that happen every frame, but the boot-entry window is touched ONCE, early, and only after the game has got going: a MAME read tap (tools/, 2026-08-10) puts Raiden DX's first access to 0x98000-0x98010 at
rtl/raiden2_main.sv:38 reg_be is {upper lane, lower lane}, which several registers need: MAME reaches them through umask16() or a u8 handler, and 0x470 only updates the FG bank when the high byte is written.
rtl/raiden2_main.sv:127 Real COP timing has never been measured; MAME does the whole transfer instantaneously mid-instruction.
rtl/raiden2_main.sv:338 ---- work RAM clear on reset -------------------------------------- MAME zero-fills work RAM; FPGA block RAM zeroes only on configuration, so a warm reset leaves stale contents.
rtl/raiden2_main.sv:540 Unclaimed reads return 0, which is what MAME's unmapped handler gives for this space -- note the Seibu sound window is an exception and returns 0xFF once it exists.
rtl/raiden2_main.sv:555 MAME src/mame/seibu/raiden2.cpp: map(0x006c6, 0x006c7).w(sprite_prot_dst1_w); // m_dst1 = data map(0x00762, 0x00763).r(sprite_prot_dst1_r); // return m_dst1
rtl/raiden2_main.sv:569 NOTE: MAME also does `m_dst1 += 8` per sprite inside the sprite-prot DMA, which this core does not implement at all.
rtl/raiden2_main.sv:583 0x6C0 / 0x6C2 / 0x6DC are r/w in MAME; the rest is write-only.
rtl/raiden2_main.sv:596 INTACK supplies the interrupt vector externally: MAME's vector_r() returns 0xc0/4 = 0x30, so the handler pointer is at 0xC0.
rtl/raiden2_sei360.sv:4 GENERATED blend table (from MAME raiden2.cpp raiden_blended_colors[]); the logic below is hand-written.
rtl/raiden2_seibu_latch.sv:44 Interrupt arbitration, which the header of seibusound.cpp warns about: int = (rst10_irq & ~rst10_service) | (rst18_irq & ~rst18_service) and on an IM 0 vector fetch, RST18 wins: rst18 pending -> acknowledge, return 0xDF rst10 pending -> ack
rtl/raiden2_sound.sv:4 Z80 + YM2151 + two OKI6295, wired to the mailbox in raiden2_seibu_latch.sv (which is diffed against MAME's seibu_sound device by sim/tb_seibu_latch).
rtl/raiden2_sound.sv:324 MAME routes the YM at 0.50 and each OKI at 0.40; the gains below are 4.4 fixed point, so 0x10 is unity.
rtl/raiden2_sound.sv:361 Now it is directly comparable with MAME (~1579 per 300 frames, tools/oracle_z80.lua).
rtl/raiden2_sprprot.sv:10 0x6C4/5 -- constant, nopw in MAME
rtl/raiden2_sprprot.sv:41 Real COP latency has never been measured; MAME does the whole thing instantaneously.
rtl/raiden2_sprprot.sv:85 MAME computes in `int`: x/y are int16 promoted, w/h are small positives.
rtl/raiden2_uart_stream.sv:116 The fade worker (B18AB, called from the handler full path every frame once 9F4E >= 2) makes an indirect far call through [node+0x4C]; MAME shows the nodes at fixed pool slots 0830/09F0/0BB0 holding A270:F58E / B93F:0D52.
rtl/raiden2_uart_stream.sv:123 MAME (tools/nodetrace.lua, 8000 frames) constructs and inserts node 0830 exactly ONCE, on frame 36, and never touches it again.
rtl/raiden2_uart_stream.sv:128 MAME arms its second fade on frame 86 and leaves 9F4E = 0002 pending for the whole run; ours clears it and walks on into the next attract stage, which respawns the fade task.
rtl/raiden2_uart_stream.sv:132 So the question is no longer "why do we insert twice" but "why do we leave a state MAME stays in".
rtl/raiden2_uart_stream.sv:135 9D20 head slot for node 0830's list -- shows insert AND removal, so we can see whether anything ever unlinks it (MAME: no) 9FBA the per-vblank frame counter, so our frame numbers line up with MAME's trace line for line 9F4E fade mode: wh
rtl/raiden2_uart_stream.sv:311 ---- full-path entries per frame ---------------------------------- The fade wedges because a list node is inserted twice (MAME: once).
rtl/raiden2_uart_stream.sv:342 MAME runs this TWICE: at boot and again on frame 1230, and its second run is what makes the second insert of node 0830 safe (old head 0).
rtl/raiden2_uart_stream.sv:423 MAME never nests, so on real hardware this is always well under one frame (1,066,666 clocks at 64 MHz).
rtl/raiden2_video_regs.sv:77 MAME's COMBINE_DATA: merge only the lanes this cycle is driving.
rtl/raiden2_video_regs.sv:90 full width, like MAME's m_tilemap_enable
rtl/raiden2_video_regs.sv:91 Raiden DX (and Sky Smasher) swap CRTC registers [0x10] and [0x20], which MAME implements as read_alt/write_alt: read_word(bitswap<16>(offset, ...,5,3,4,2,1,0)) CAREFUL: that bitswap runs on the WORD offset (u16 handlers), so its bits 4 and
rtl/raiden2_video_timing.sv:33 Sync POSITION centres the picture; MAME's set_raw only fixes the totals and the active area, so these were ours to choose and were not centred.
rtl/sei0200.sv:371 MAME draws it with TILEMAP_DRAW_OPAQUE, and the evidence is visual: BG tiles are 55% pen-15, so if it were transparent over half the foliage would be holes.
rtl/sei0200.sv:374 MAME's output has none, while ours showed "large blocks of black in the centre of the trees".
rtl/sei252.sv:32 MAME gets that by drawing BACK TO FRONT (last entry first) and letting later draws overwrite; this walks the list FRONT TO BACK with first-writer-wins instead -- identical output on any line that completes (first opaque pixel front-to-back
rtl/sei252.sv:53 Real hardware has them, they are undocumented, and MAME ignores them too.
rtl/sei252.sv:117 9-bit coordinates, sign-extended at 0x180 as MAME does.
README.md:64 That was disproved by measurement: the palette was compared word-for-word against MAME across 1,016 attract frames — 2,080,768 comparisons including the flash-a
README.md:195 tools/check_files.py --roms /path/to/your/mame/roms
README.md:253 tools/check_files.py --roms /path/to/your/mame/roms
README.md:415 For each chip on the arcade board, a reference model was written from the MAME source **first**, and the FPGA code is then compared against it — signal by signa
README.md:425 | Seibu COP (protection/maths) | `tb_cop_cmd.cpp` vs MAME | all 58 commands match |
README.md:430 | Sound latch | `tb_seibu_latch.cpp` vs MAME | 36 of 36 cases match |
README.md:519 Hardware behaviour was derived from the MAME source for the Seibu drivers:
README.md:521 `r2crypt.cpp` (BSD-3-Clause) — Andreas Naive, Olivier Galibert
README.md:522 `sei25x_rise1x_spr.cpp`, `seibusound.cpp` (BSD-3-Clause)
README.md:523 `raiden2.cpp`, `raiden2_v.cpp`, `seibucop.cpp`, `seibu_crtc.cpp` (LGPL-2.1+) — Olivier Galibert, Angelo Salese, David Haywood, Tomasz Slanina and others

Says it matches, follows or was checked against MAME — 24

Raiden2.sv:1004 nested vblanks 1 0 <- matches MAME
rtl/raiden2_addr_decode.sv:4 Ground truth: MAME src/mame/seibu/raiden2.cpp, raiden2_mem() / raiden2_cop_mem() (LGPL-2.1+, Olivier Galibert, David Haywood, Angelo Salese et al.)
rtl/raiden2_addr_decode.sv:102 --- register window sub-decode -------------------------------------- Decoded most-specific-first, matching MAME's later-map()-wins ordering: 0x68E sits inside the SEI252 range, and 0x6CA/0x6CB/0x6CC sit inside the sprite-prot range.
rtl/raiden2_addr_decode.sv:125 The ordering is the same as MAME's later-map()-wins: the specific addresses must be tested before the ranges that contain them (0x68E sits inside the SEI252 range; 0x6CA/0x6CB/0x6CC sit inside the sprite-prot range).
rtl/raiden2_cop_cmd.sv:11 Ground truth: MAME src/mame/seibu/seibucop.cpp + seibucop_cmd.ipp (LGPL-2.1+, Olivier Galibert, Angelo Salese, David Haywood, Tomasz Slanina).
rtl/raiden2_cop_cmd.sv:183 Dwords are little-endian pairs, matching the V30 and MAME's read_dword/write_dword.
rtl/raiden2_cop_cmd.sv:236 30 fractional bits is not arbitrary: an exhaustive sweep of all 256 angles x 256 amplitudes showed 8 exact mismatches against MAME's double at 28 bits and none at 30.
rtl/raiden2_cop_cmd.sv:451 All arithmetic is int16, matching MAME's colinfo.
rtl/raiden2_cop_cmd.sv:750 Widening the operands makes the product 32 bits, which also matches the int overflow behaviour of MAME's C.
rtl/raiden2_cop_dma.sv:9 Ground truth: MAME src/mame/seibu/seibucop.cpp + seibucop_dma.ipp (LGPL-2.1+, Olivier Galibert, Angelo Salese, David Haywood, Tomasz Slanina).
rtl/raiden2_cop_dma.sv:35 Until that is confirmed on hardware we follow MAME: fix up the address, use the fixed length.
rtl/raiden2_cop_itoa.sv:4 Ground truth: MAME src/mame/seibu/seibucop.cpp, raiden2cop_device:: bcd_update() / cop_itoa_* (LGPL-2.1+).
rtl/raiden2_main.sv:14 Memory map ground truth: MAME src/mame/seibu/raiden2.cpp (LGPL-2.1+).
rtl/raiden2_main.sv:300 Verified against a C model of MAME's sprite_prot_src_w by `make sprprot-run` (6/6).
rtl/raiden2_seibu_latch.sv:20 Ground truth: MAME src/mame/shared/seibusound.cpp (BSD-3-Clause) and the raiden2_sound_map in src/mame/seibu/raiden2.cpp (LGPL-2.1+).
rtl/raiden2_sound.sv:11 Ground truth: MAME src/mame/seibu/seibusound.cpp and the raiden2_sound_map in raiden2.cpp: 0x0000-0x1FFF ROM, fixed 0x2000-0x27FF RAM, 2 KB
rtl/raiden2_sprprot.sv:4 Ground truth: MAME src/mame/seibu/raiden2.cpp, xsedae_state:: sprite_prot_* (LGPL-2.1+, Olivier Galibert, Angelo Salese, David Haywood).
rtl/raiden2_video_regs.sv:9 Ground truth: MAME src/mame/seibu/seibu_crtc.cpp (register offsets) and raiden2_v.cpp (tile_scroll_w, tilemap_enable_w, tile_bank_01_w, cop_tile_bank_2_w), LGPL-2.1+.
rtl/raiden2_video_regs.sv:95 The first implementation swapped byte bits 4/3 and every DX scroll write (raw 0x10-0x1A, verified with a MAME write tap against a Raiden II control run) landed on undecoded offsets and was dropped -- the background then only moved in the 16
rtl/raiden2_video_timing.sv:9 Our H rate is 8e6/512 = 15.625 kHz, about 0.4% fast against that measurement -- MAME's raw numbers are what we model, and the discrepancy is left documented rather than fudged, since nothing here has been verified against hardware.
rtl/sei0200.sv:7 Ground truth: MAME src/mame/seibu/raiden2.cpp (gfx layouts) and raiden2_v.cpp (layer order, palette bases, tile banking), LGPL-2.1+.
rtl/sei252.sv:7 Ground truth: MAME src/mame/seibu/sei25x_rise1x_spr.cpp (BSD-3-Clause) and the Raiden II configuration in raiden2.cpp.
rtl/sei252.sv:46 Output encoding matches MAME's draw_raw, which is what the SEI360 mixer consumes: {opaque, priority[1:0], colour[5:0], pen[3:0]}.
README.md:30 | Seibu COP (protection and maths chip) | Working — all 58 known commands match MAME, plus DX's own 0x7E05 |

Says it was translated, ported or taken from MAME — 5

rtl/raiden2_cop_dma.sv:27 Two quirks carried over from MAME, both of which our capture reproduces:
rtl/raiden2_main.sv:321 Conversion is 32 clocks (double dabble); busy joins cop_holds_bus so the CPU cannot read half-converted digits -- MAME's bcd_update() is instantaneous.
rtl/raiden2_r2crypt.sv:5 Produced by tools/make_r2crypt_rtl.py from tools/r2crypt.py, which is itself a port of MAME src/mame/seibu/r2crypt.cpp (Andreas Naive, Olivier Galibert, BSD-3-Clause) and the seibu_partial_carry_sum helper from src/mame/seibu/seibu_helper.c
rtl/raiden2_sprprot.sv:19 MAME's engine, verbatim:
rtl/raiden2_video_timing.sv:4 From MAME src/mame/seibu/raiden2.cpp: screen.set_raw(32MHz/4, 512, 0, 320, 282, 0, 240) // ROT270

Shares text with the MAME driver without saying so — 10

Raiden2.sv:7 sources (LGPL-2.1+, Olivier Galibert, Angelo Salese, David Haywood, — shares text with seibu/r2crypt.h:2
rtl/raiden2_addr_decode.sv:87 map(0x20000, 0x2ffff).bankr(m_mainbank); 64K window — shares text with seibu/raiden2.cpp:658
rtl/raiden2_cop_cmd.sv:12 (LGPL-2.1+, Olivier Galibert, Angelo Salese, David Haywood, Tomasz Slanina). — shares text with seibu/r2crypt.h:2
rtl/raiden2_cop_cmd.sv:46 0x5205 / 0x5a05 dword copy cop_regs[0] -> cop_regs[1] — shares text with seibu/seibucop.cpp:1155
rtl/raiden2_cop_cmd.sv:47 0xf205 dword copy cop_regs[0]+4 -> cop_regs[2] — shares text with seibu/seibucop.cpp:1166
rtl/raiden2_video_regs.sv:30 Reset values are MACHINE_RESET_MEMBER(raiden2_state,raiden2)'s — shares text with seibu/raiden2.cpp:409
rtl/raiden2_video_regs.sv:31 bank_reset(0,6,1,0): bg 0, fg 6, mid 1, tx 0. Note fg starts at 6 and only — shares text with seibu/raiden2.cpp:411
rtl/raiden2_video_regs.sv:93 read_word(bitswap<16>(offset, ...,5,3,4,2,1,0)) — shares text with seibu/seibu_crtc.cpp:338
rtl/raiden2_video_regs.sv:122 bank_reset(0,6,1,0) — shares text with seibu/raiden2.cpp:411
rtl/sei0200.sv:24 (planeoffset {8,12,0,4}, xoffset {3,2,1,0,19,18,17,16}). Working that — shares text with seibu/raiden2.cpp:1030

Rayforce (spacestate1)#
Arabian Magic, Arkanoid Returns, Bubble Memories: The Story Of Bubble Bobble III, Bubble Bobble II …
spacestate1/Arcade-taitoF3_MiSTer @ dc799be0
MAME compared: taito/taito_f3.cpp + 4 related file(s)
Read: 30 HDL files, 13,121 lines (Quartus project)

spacestate1
repository only

Mostly MAME

medium

72%

Statements: 122 toward MAME

Cites MAME source — 106

Rayforce.sv:8 What this build is: the real F3 main board (rf_main.sv) -- the full taito_f3.cpp memory map with every video RAM present, the vblank and timer interrupts delivered, inputs and EEPROM wired -- driving a diagnostic page instead of a renderer.
Rayforce.sv:14 Nothing in the pixel pipeline can be developed, let alone diffed against MAME, until the program is actually running its frame loop.
Rayforce.sv:196 Ray Force is MAME ROT270 but its flipscreen inverts the raster, so the upright rotation is CW (see rotate_ccw below); that is the default.
Rayforce.sv:414 Ray Force is MAME ROT270 but runs with the F3 flipscreen ON (its graphics are stored flipped and the chipset draws them flipped), so the raster the core outputs is already inverted: rotating it CW puts it upright, and that is the default (2
Rayforce.sv:761 Ensoniq grew 4 MB -> 8 MB for Puzzle Bobble 3/4, whose sample region is 16 MB in MAME against Ray Force's 8.
Rayforce.sv:773 The Taito F3 board is one chipset running 35 different games, and MAME's per-game differences are small enough to be data rather than RTL: the visible-raster crop (four variants), the playfield "extend" bit, and the sprite lag.
Rayforce.sv:781 bit [1:0] visarea: 0 = f3_224a (Ray Force), 1 = f3_224b, 2 = f3_224c, 3 = f3 bit [2] NON-extend (1 = eight 32x32 playfields, MAME's extend=0: Puzzle Bobble 2/3/4, Darius Gaiden, Cleopatra Fortune, Grid Seeker, Space Invaders '95, Gekiri
Rayforce.sv:786 0 = four 64x32, which is Ray Force, Elevator Action Returns and both Bubble Bobble games.) Note the inverted sense against MAME's own "extend" naming: a 0 byte has to keep meaning what every MRA written before this bit went live meant.
Rayforce.sv:791 bit [4:3] sprite lag in frames (reserved; the engine does 1 today, MAME does 2 for both of these games)
Rayforce.sv:807 All 35 parent sets were tabulated from MAME's GAME() lines, its init_ functions and f3_config_table (see F3-LIBRARY.md); these are every per-game parameter they need:
Rayforce.sv:818 MAME's table wants 2 for 8 sets, 1 for 22 and 0 for 3, so this is the one per-game parameter the core cannot yet express -- the field is here so the MRAs can carry it the day the engine can.
Rayforce.sv:910 Compute the ROM-derived ones with tools/rf_stream_sum.py; the write hash comes from the MAME write-stream oracle.
Rayforce.sv:921 The first four come from tools/rf_stream_sum.py over the MRA; the write hash comes from tools/oracle_f3writes.lua, and the board already reports exactly it -- so the 68020 executes this game's first 4096 bus writes the same way MAME does.
Rayforce.sv:997 The board ALREADY REPORTS exactly this value, so Darius Gaiden's 68020 executes its first 4096 bus writes the way MAME does.
Rayforce.sv:1025 ---- otisbank mask, per game ---------------------------------------- The Taito EN board banks the sample ROM with its own register, not the ES5505's, and MAME masks what the game writes there with
Rayforce.sv:1062 MAME switches on the GAME to decide (taito_f3_v.cpp palette_24bit_w), and its own TODO there says the real chip may select it per line through 0x6400 -- unimplemented there too, so a per-game flag is exactly as correct as the reference.
Rayforce.sv:1089 ---- SDRAM MAP PROFILE ---------------------------------------------- Fourteen F3 sets do not fit the 18.5 MB map, and measuring their REAL ROM bytes (not MAME's declared region sizes, which overstate it) shows what actually blocks them:
Rayforce.sv:1121 The sizing came from a script whose regex was `ROM_LOAD\w*\(`, and MAME writes a plain load as `ROM_LOAD (` with alignment spaces before the paren -- so EVERY sprites_hi and tilemap_hi in the library measured as zero.
Rayforce.sv:1254 Stage 1 of Phase 3: the chips only answer; their register writes go to the write ring (UART Debug = Sound Ring) for the comparison against MAME's stream, and to the es_*/bk_*/vl_* ports the sampler will take in stage 2.
Rayforce.sv:1309 The sample clock: master 15.238 MHz / (16 x (ACT + 1)), the integer division MAME makes, as a fractional divider of clk_sys.
Rayforce.sv:1432 Mix: the pump sends pair 0 straight out and pairs 1-3 through the ESP, which is a dry sum here (ROADMAP Phase 3, stage 3 is the volume chip); four 20-bit pairs summed and scaled to 16 bits, MAME's route gains (0.18 x 0.5 x the MB87078 at 0
Rayforce.sv:1445 MAME's own level, pre-boost
Rayforce.sv:1454 ---- AUDIO BOOST ------------------------------------------------------- The chain above reproduces MAME's gain structure exactly, and MAME's gain structure for this board is very quiet.
Rayforce.sv:1456 rf_mb87078's 0 dB coefficient is 576 against a >>> 15, i.e. 576/32768 -- which is precisely taito_en's x3.125 at 0 dB, times MAME's 0.18 route gain, times the ES5506 pump's 0.5, times the 20-bit -> 16-bit 1/16.
Rayforce.sv:1467 The boost is a saturating left shift on the finished 16-bit sample, defaulting to 8x (+18 dB, peak -15.4 dBFS on that capture); 16x is there for quiet amplifiers and 1x reproduces MAME's own level for anyone comparing.
Rayforce.sv:1475 1x -- MAME's level
Rayforce.sv:1780 the index counts every output sample since the sound CPU was released, so a capture is placed on the model's timeline (the model's t = 0 is MAME's reset, ~2 s before the release)
rtl/rayforce_video.sv:4 Timing is the real machine's, from MAME taito_f3.cpp: set_raw(26.686 MHz / 4, 432, 46, 320+46, 262, 24, 232+24) pixel clock 6.6715 MHz = clk_sys / 8 (clk_sys = 53.372 MHz) => 58.94 Hz, which the OSD reporting that number is part of the test
rtl/rayforce_video.sv:11 Line RAM is indexed by the raw raster line (MAME's scanline_draw walks screen_y 0..255 and indexes line ram with it), so vcnt IS the line-RAM index and the visible window is a crop of it.
rtl/rayforce_video.sv:18 vbl_rise is the main CPU's vblank interrupt: MAME schedules it at visarea.max_y + 1, so line 255.
rtl/rayforce_video.sv:28 This is the first thing the game generates that can be compared against MAME directly: same screenshot, same colours, or the palette write path is wrong.
rtl/rayforce_video.sv:64 Native is 262 lines = 58.94 Hz (MAME: 58.97); 60Hz trims the vertical blank to 257 lines = 60.08 Hz, H rate unchanged, so the game runs 1.9% fast in exchange for a picture every 60 Hz display holds without judder.
rtl/rayforce_video.sv:93 The crop is the ONE thing that differs between the four Taito F3 machine configurations in MAME, and every F3 game uses one of them (taito_f3.cpp: the base f3 set_raw is 432x262 for all of them, and f3_224a/b/c only override set_visarea):
rtl/rf_eeprom_93c46.sv:4 The F3 board wires one of these to the control port at 0x4a0010: the CPU drives CS/CLK/DI through the low byte there and reads DO back in bit 0 of every control-port longword (taito_f3.cpp EEPROMOUT / EEPROMIN).
rtl/rf_eeprom_93c46.sv:88 A READ answers with a dummy 0 on the clock after the last address bit, THEN the 16 data bits MSB first (93C46 datasheet, and eepromser.cpp).
rtl/rf_es5505.sv:2 ES5505 -- the Ensoniq 32-voice sampler, as MAME computes it.
rtl/rf_es5505.sv:4 This is the RTL of tools/es5505_model.py (itself an exact port of es5506.cpp's ES5505 paths), and it is checked against that model sample for sample (sim/es5505_tb.cpp, make -C sim es5505).
rtl/rf_es5505.sv:6 Every arithmetic step keeps MAME's integer semantics, including C's truncating division in the filters, so the diff is exact, not "close".
rtl/rf_es5505.sv:31 MAME keeps the accumulator in 20.11 with the 5505's 20.9 registers shifted up 2; the low 2 bits are always 0 (every quantity is a multiple of 4), so this works in 20.9 directly: accum, start, end are 29 bits, the step is the FC register's b
rtl/rf_es5505.sv:39 THREE bank bits, not two: the Taito EN board's otisbank register is masked by MAME with (ensoniq_region_bytes / 0x200000) - 1, which is 3 for Ray Force's 8 MB region but 7 for Puzzle Bobble 3/4's 16 MB one.
rtl/rf_es5505.sv:63 per-game otisbank mask, MAME's m_bankmask (3 = 8 MB region, 7 = 16 MB)
rtl/rf_es5505.sv:97 ---- control bits (es5506.cpp, 5505 placements) ----------------------
rtl/rf_es5505.sv:336 ---- loop end handling (V_END), MAME's check_for_end_* for the 5505 -----
rtl/rf_es5510_host.sv:7 If those reads do not answer as MAME's es5510.cpp does, the driver loops forever on the presence check (build 27230527 did exactly that, on a stub that aliased the select commands onto latch 0).
rtl/rf_es5510_host.sv:12 So this is es5510.cpp's host_r/host_w, read_reg/write_reg, with real storage for the GPR file (0xC0 x 24 bits), the instruction memory (0xA0 x 48 bits) and the special registers 0xEA-0xFF -- and NO execution: the DSP program never runs, the
rtl/rf_gfx_bus.sv:5 MAME merges them at load time (tile_decode: pixel = (low & 0x0f) | (hi & 0x30)); the real board has no merge pass, it simply reads both planes in parallel.
rtl/rf_main.sv:10 Phase 2 needs the program actually running, so this is the real map from taito_f3.cpp f3_map, plus the two interrupts and the control port:
rtl/rf_main.sv:31 Interrupts, from taito_f3.cpp: level 2 vblank, HOLD_LINE level 3 10000 68020 cycles (625 us at 16 MHz) after the vblank IRQ.
rtl/rf_main.sv:43 The write-stream capture from the spike is kept verbatim -- same ring, same rotl1+add fold -- because it is still the regression oracle against MAME's rf_acc.tr.
rtl/rf_main.sv:124 Neither MAME (which reads sprite RAM atomically) nor the bench (which feeds it a static snapshot) can ever produce that, which is why the picture is right in both and wrong on the board.
rtl/rf_main.sv:143 Ray Force's new-game init (ROM 0x004810) stores the constant 1 into the zone word at 0x402312 and the stage loader consumes it in the SAME frame, so nothing that writes RAM once a frame can change it -- proved in MAME: holding the byte ever
rtl/rf_main.sv:174 C80100 asserts the sound CPU's reset, C80000 releases it; held from boot (taito_f3.cpp machine_reset asserts it)
rtl/rf_main.sv:180 The ring is circular, so it always holds the last 2048 writes -- but the UART needs ~2.5 s to read 2048 entries out and this CPU refills the ring far faster than that, so a live read-out is TORN: the head of the dump and its tail come from
rtl/rf_main.sv:364 KIRAMEKI STAR ROAD ONLY: it is the only F3 game that banks its sound ROM, and MAME's handler is guarded by `if (m_game == KIRAMEKI)` with every other game logging "Sound bankswitch in unsupported game".
rtl/rf_main.sv:413 ---- watchdog (TC0640FIO) ------------------------------------------- The F3 has one, MAME configures it (WATCHDOG_TIMER in taito_f3.cpp) and the games USE it: Elevator Action Returns' boot deliberately runs into a `BRA.S *` with interrupts
rtl/rf_main.sv:417 Traced in MAME: it sits at PC 0x01016E for about two seconds, resets, re-runs POST and then reaches its main loop.
rtl/rf_main.sv:759 ---- write-stream capture (unchanged -- the MAME oracle) ------------- The main write ring used to FREEZE at the 4096th write, which was right for Phase 0/1 (capture the boot stream, compare with MAME) and is now actively misleading: the WR
rtl/rf_main.sv:768 ...but the write COUNT and HASH must still stop at 4096: that pair is the Phase 1 proof, compared against a fixed number from MAME, and a hash that keeps folding is just a moving target.
rtl/rf_main.sv:857 Halving it frees 12 and still holds a 2048-write comparison against MAME and a 69 ms audio capture, both far more than any check has needed.
rtl/rf_main.sv:901 MEASURED IN MAME: 764 reads, min 761 max 765, identical in attract and in game.
rtl/rf_main.sv:947 ---- KIRAMEKI sound-ROM bank ----------------------------------------- taito_f3.cpp sound_bankswitch_w, verbatim:
rtl/rf_main.sv:966 MAME sets the three sound-CPU windows with set_entry(i % max) for i = 0,1,2, so cpubank2 -- the C20000 window this index drives -- starts on ENTRY 1.
rtl/rf_mb87078.sv:2 MB87078 -- the volume control on the EN board, as taito_en.cpp uses it.
rtl/rf_mb87078.sv:6 mb87077.cpp: gain index = 65 (mute) if EN=0, 64 (-32 dB) if C32, 0 (0 dB) if C0, else ~data & 0x3f, in 0.5 dB steps.
rtl/rf_selftest.sv:111 Phase 0/1 established every one of these against MAME or against tools/rf_stream_sum.py; they are constants here so the board says PASS or FAIL by itself instead of handing back a number to compare.
rtl/rf_smp_bus.sv:11 THREE bank bits since Puzzle Bobble 3/4: their ensoniq region is 16 MB in MAME, so the otisbank mask is 7 rather than Ray Force's 3, and the sample space is 8 MB rather than 4.
rtl/rf_sound_main.sv:5 A second TG68K.C, in 68000 mode, running the sound program from SDRAM through its own rf_prog_bus line cache (SDRAM ch5), with the map from taito_en.cpp:
rtl/rf_sound_main.sv:16 Three windows in MAME (cpubank1/2/3 at C00000, C20000, C40000), fixed at reset to a LINEAR mapping, which is what this maps by default.
rtl/rf_sound_main.sv:18 Only Kirameki Star Road ever moves one: taito_f3.cpp's sound_bankswitch_w calls set_bank(1, idx) -- cpubank2, the C20000 window -- and no other game reaches that code at all.
rtl/rf_sound_main.sv:33 The proof for this stage is the ring against MAME's stream (tools/rf_snd_ring_check.py, from tools/oracle_en_dump.lua): if the FPGA's 68000 runs the sound program correctly it writes the same things in the same order.
rtl/rf_spr_gfx_bus.sv:6 Two differences, both from the sprite gfx layouts in taito_f3.cpp: - the regions: sprites at byte 0x180000, sprites_hi at 0x380000.
rtl/rf_spr_gfx_bus.sv:18 MAME merges them at load time (tile_decode: pixel = (low & 0x0f) | (hi & 0x30)); the real board has no merge pass, it simply reads both planes in parallel.
rtl/rf_video_line.sv:6 All of that lives in 64 KB of line RAM, reached through two levels of indirection, and it is most of what taito_f3_v.cpp does.
rtl/rf_video_line.sv:10 This is a direct port of read_line_ram() from tools/f3_render.py, which reproduces MAME's own frames pixel-exact and is therefore the spec.
rtl/rf_video_line.sv:83 FIX_Y: the y zooms of playfields 2 and 4 are stored where you would expect the other's to be (taito_f3_v.cpp says so, and the model agrees).
rtl/rf_video_mix.sv:6 sim/mix_tb.cpp runs this end to end -- real line decode, real playfield build, real SDRAM tile fetch, this mixer -- and diffs the output against the MAME-identical frame (make -C sim mix).
rtl/rf_video_mix.sv:36 This equals MAME's calc_clip for any single plane and for combinations of normal planes.
rtl/rf_video_mix.sv:37 MAME's handling of several INVERTED planes at once produces duplicate ranges that re-run the layer over the same pixels (which changes destination-tie results); that is not reproduced.
rtl/rf_video_mix.sv:95 and MAME scales each nibble by 16 (taito_f3_v.cpp palette_24bit_w), which is exactly {nibble, 4'd0}.
rtl/rf_video_mix.sv:96 MAME selects this by GAME rather than by register -- its own comment there wonders whether the real chip picks it per line through 0x6400, but it does not implement that, so following the per-game flag matches the reference exactly.
rtl/rf_video_mix.sv:125 The COORDINATE is the point: an earlier packing reported the output green/blue instead, and a reading could not be pinned to a pixel, so it could not be compared against MAME.
rtl/rf_video_mix.sv:127 With (x,y) the board's own screenshot supplies the output colour and a MAME dump supplies the correct index and colour for the same pixel.
rtl/rf_video_mix.sv:132 The two flag bits compress the weights to the only question that matters here, since MAME renders this scene 100 % opaque.
rtl/rf_video_mix.sv:179 layer_enable: bit 13, and the blend mode that means "off" differs -- 3 for tilemaps and the pivot, 0 for sprites -- then MAME's row-usage test on top
rtl/rf_video_mix.sv:206 3'b1xx = no source yet (MAME's 0xff)
rtl/rf_video_pf.sv:4 Port of PlayfieldInf / build_playfields / x_index / y_index from tools/f3_render.py, which reproduces MAME's frames pixel-exact and is the spec.
rtl/rf_video_pf.sv:13 MAME's row-usage skip: a tilemap row whose 64 tile codes are all 0 draws NOTHING, even though tile 0 in this ROM is opaque.
rtl/rf_video_pf.sv:27 Flipscreen -- which Ray Force runs with permanently -- mirrors the whole tilemap in both axes (MAME set_flip_all), THEN each tile's own flip bits apply.
rtl/rf_video_pf.sv:70 MAME: "[.ttt yyyy yxxx xxa|h] non-extend / [.tty yyyy xxxx xxa|h] extend" in taito_f3_v.cpp pf_ram_w().
rtl/rf_video_pf.sv:410 MAME's row-usage test: any nonzero code word in tilemap row ty.
rtl/rf_video_pf.sv:443 extend=0 wraps x at 512, not 1024: MAME's m_width_mask
rtl/rf_video_pipe.sv:55 The live value comes from the sprite command word via the sprite engine (`flip_eff` below) -- MAME takes m_flipscreen from exactly that bit, and it must follow the game: Ray Force sets it permanently, Elevator Action Returns does not, and t
rtl/rf_video_pipe.sv:283 "extend" (1024x512 playfields) comes from MAME's per-game config table, not from control word 15, and so it comes from the MRA's game config byte here rather than from anything the game writes.
rtl/rf_video_pivot.sv:24 The per-line "used" flag (MAME skips the layer on a line whose text-RAM row is all zero codes) is a 64-word scan of that row before the pixel pass; the pixel layer is always used.
rtl/rf_video_spr.sv:47 So sprites lag the playfields by one frame here; MAME's sprite_lag for gunlock is 2 -- close, tuned on hardware if it reads wrong, the same way the raster timing was.
rtl/rf_video_spr.sv:135 The flipscreen bit, straight from the sprite command word (word 5 bit 13) -- the same place MAME takes m_flipscreen from.
rtl/rf_video_spr.sv:253 rf_video_spr_list already produces all seventeen ({w[5][0], w[0]}, the same field MAME reads) and this stored only fifteen, which reaches 2^15 * 128 = 4 MB of sprite ROM.
rtl/rf_video_spr.sv:338 The heavy MAME frame added the same night (dump/rf_heavy, 344 sprite rows) still only reaches 2190 records -- a fifth of what the boss needs.
rtl/rf_video_spr_list.sv:14 All of that is the F3 sprite chip, reproduced from MAME via the model.
rtl/rf_video_spr_list.sv:46 MAME's pen mask is (extra_planes << 4) | 0x0F with extra_planes 0..3, so it reaches 0x3F -- and F3 sprite graphics are 6bpp, 64 pens.
README.md:70 The dry mix correlates 0.95–0.99 with MAME, so the difference is small.
README.md:100 Put the MAME ROM zips in `/media/fat/games/mame/`.
README.md:189 8x is the default; 1x is MAME's own level.
README.md:245 make -C sim pipe # the raster pipeline against MAME's frames make -C sim spr-all spr-line-all # the sprite engine make -C sim es5505
README.md:251 They compare against data produced from MAME by the Lua scripts in `tools/`; those dumps are not in the repository.
README.md:271 **MAME** — the reference for everything here (`taito_f3`, `taito_en`, ES5505/ES5510).

Says it matches, follows or was checked against MAME — 10

Rayforce.sv:541 Measured on frame 2930, the frame the board was caught getting wrong: the picture stays identical to MAME up to a sprite-fetch round trip of 135 ram clocks instead of 70, and at a modelled 90-clock round trip the longest line falls from 660
Rayforce.sv:1553 Every block in it is verified pixel-exact against MAME in Verilator (sim/), sprites included; the ch4 sharing runs inside the pipe bench (sim/pipe_top.sv) so the arbitration meets the regression too.
Rayforce.sv:1617 extend=0 is implemented and verified end to end -- the model against MAME (Puzzle Bobble 2 frame 1800 pixel-identical) and the RTL against the model (all seven bench suites at baseline pixel counts) -- but it costs ~1158 ALMs / ~116 LABs an
Rayforce.sv:1770 Tapped PRE-BOOST, deliberately: this ring exists to prove the board plays what the model computes, and tools/rf_audio_match.py reports the amplitude ratio against MAME's own mix.
rtl/rf_gfx_bus.sv:11 Layout, taken from the gfx_layouts in taito_f3.cpp and cross-checked against tools/f3_gfx.py (which renders MAME's own frames pixel-exact, so it is the authority on this byte order, not a guess):
rtl/rf_spr_gfx_bus.sv:24 Layout, taken from the gfx_layouts in taito_f3.cpp and cross-checked against tools/f3_gfx.py (which renders MAME's own frames pixel-exact, so it is the authority on this byte order, not a guess):
rtl/rf_video_mix.sv:4 Port of scanline_draw / calc_clip / mix_line / render_line from tools/f3_render.py (which is MAME's taito_f3_v.cpp, verified pixel-exact against MAME's own frames).
rtl/rf_video_mix.sv:129 One reading then splits three ways: src_pal matches MAME's and the pixel is opaque but wrong -> the palette read; src_pal differs -> the pen/graphics upstream; not opaque -> the blend weights from the line-RAM decode.
README.md:7 Checked against MAME, not by eye: video pixel-identical over 15 consecutive frames, sound sample-exact over 1.15 million samples.
README.md:26 | *Elevator Action Returns* | Plays. Ten frames match MAME pixel for pixel. Sound not yet checked. |

Keeps a MAME approximation — 1

rtl/rf_video_pivot.sv:12 It has no tile words of its own: palette and flips are borrowed from the text RAM tile at [row (+32 when the scroll puts the cell in the lower half), col] -- MAME's get_tile_info_pixel hack, reproduced so the two agree even where both are o

Shares text with the MAME driver without saying so — 5

rtl/rayforce_video.sv:5 set_raw(26.686 MHz / 4, 432, 46, 320+46, 262, 24, 232+24) — shares text with taito/taito_f3.cpp:451
rtl/rf_main.sv:950 idx = (offset << 1) & 0x1e; if (ACCESSING_BITS_0_15) idx += 1; — shares text with taito/taito_f3.cpp:112
rtl/rf_main.sv:951 if (idx >= 8) idx -= 8; m_taito_en->set_bank(1, idx); — shares text with taito/taito_f3.cpp:121
rtl/rf_video_pf.sv:70 for. MAME: "[.ttt yyyy yxxx xxa|h] non-extend / [.tty yyyy xxxx xxa|h] — shares text with taito/taito_f3_v.cpp:557
rtl/rf_video_pf.sv:322 the mosaic counter resets 2 px from the right edge (x_count wraps at 432) — shares text with taito/taito_f3_v.cpp:951

SegaG80 (RodimusFVC)#
005, Astro Blaster, Eliminator, Monster Bash …
RodimusFVC/Arcade-SegaG80_MiSTer @ a534826d
MAME compared: sega/segag80r.cpp, sega/segag80v.cpp + 24 related file(s)
Read: 16 HDL files, 3,590 lines (Quartus project)

RodimusFVC
repository only

Mostly MAME

medium

91%

Statements: 9 toward hardware, 100 toward MAME, 2 not counted

Cites hardware documentation that MAME's driver does not — 2

rtl/SegaG80.sv:573 005 discrete sound board (Sega 834-0130) — melody chain plus seven effect voices, all synthesized from the schematic.
rtl/SegaG80_CPU.sv:62 Monster Bash $0E latch -> uPD7751

Cites hardware references or measurements that MAME's driver also gives — 2

rtl/SegaG80.sv:530 Monster Bash music — TMS3617 + the pr1512.u31 82S123 at ioctl index 4. — also in MAME: 82S123 sega/segag80r_a.cpp:232
rtl/SegaG80_CPU.sv:491 Monster Bash PPI port A ($0C) write — sound_a_w: TMS3617 note in the low nibble, 82S123 voice-mask address in the high nibble. — also in MAME: 82S123 sega/segag80r_a.cpp:232

Ships hardware documentation files — 6

Notes where it differs from MAME — 1

rtl/segag80_5028.sv:10 Opcode fetches and data reads use different halves of the table, so this is a pure combinational function - no decrypted ROM copy is needed, unlike MAME which pre-expands into a second buffer.

Cites MAME source — 85

Arcade-SegaG80.sv:175 outclk_0 = 15.468480 MHz (MAME segag80r.cpp:130 VIDEO_CLOCK).
Arcade-SegaG80.sv:273 9 = SERVICE1 credit (MAME default key)
Arcade-SegaG80.sv:274 F2 = CPU-board self-test switch (MAME default key)
Arcade-SegaG80.sv:330 SELFTEST-SPLIT-2026-08-11: separate input, matching the real cabinet's red CPU-board switch (AstroBlaster manual p.14) and MAME's SERVICESW port.
Arcade-SegaG80.sv:349 Active-LOW per MAME
Arcade-SegaG80.sv:389 Astro Blaster is ROT270 in MAME (monitor rotated 90° CCW from landscape).
Arcade-SegaG80.sv:415 MAME: segag80r.cpp / segag80v.cpp.
Arcade-SegaG80.sv:416 Inputs are raw active-HIGH from the MiSTer controls; the G-80 port mangling (segag80r.cpp:443 demangle) happens inside SegaG80_CPU.
Arcade-SegaG80.sv:451 DIP banks (active-LOW, MAME convention)
rtl/SegaG80.sv:19 15.468480 MHz (MAME VIDEO_CLOCK)
rtl/SegaG80.sv:35 MAME models them as two separate ports: segag80r.cpp:643 IPT_SERVICE1 (a port bit, MAME default key 9) and segag80r.cpp:708 SERVICESW / PORT_SERVICE_NO_TOGGLE (NMI, MAME key F2, never read as a port).
rtl/SegaG80.sv:43 DIP banks (active-LOW per MAME)
rtl/SegaG80.sv:454 LEVEL FIX 2026-08-09 — the old comment ("speech at half gain per MAME vol balance") misread MAME.
rtl/SegaG80.sv:455 segag80r.cpp:1085-86 is: ASTRO_BLASTER_AUDIO(...).add_route(ALL_OUTPUTS, "speech", 1.0, 1); SEGA_SPEECH_BOARD(...).add_route(ALL_OUTPUTS, "speaker", 0.5); The sound board does NOT route to the speaker -- it routes INTO the speech board at g
rtl/SegaG80.sv:460 Speech itself is 1.0 internally (segaspeech.cpp:207/218).
rtl/SegaG80.sv:477 master 0.5 on the SUM, per MAME
rtl/SegaG80.sv:531 MAME routes music and the voice DAC at 0.5 each; level here is by ear, like the other boards.
rtl/SegaG80_CPU.sv:115 Clock enables — MAME segag80r.cpp:1059/132 ce_cpu = CLK_SYS / 4 (Z80 clock) ce_pix = CLK_SYS / 3 (pixel clock, consumed by T1.4)
rtl/SegaG80_CPU.sv:129 MAME (segag80r.cpp:129-132, 1059): VIDEO_CLOCK = 15.46848 MHz (= our clk_sys) PIXEL_CLOCK = VIDEO_CLOCK/3 = 5.1562 MHz
rtl/SegaG80_CPU.sv:141 HW-corroborated 2026-07-26: MAME plays noticeably FASTER than the core, which is what a 45-vs-60 Hz frame rate looks like.
rtl/SegaG80_CPU.sv:159 Wait-state shim — Sega G-80 holds MREQ for ~2 extra cycles per access (segag80r.cpp:145 WAIT_STATES = 2).
rtl/SegaG80_CPU.sv:169 WAITSTATE-FIX-2026-07-26 — we were charging wait states on things MAME doesn't. MAME installs taps on AS_PROGRAM read, AS_PROGRAM write and AS_OPCODES read only (segag80r.cpp init_waitstates) — i.e. real MEMORY accesses.
rtl/SegaG80_CPU.sv:171 There is NO iospace tap, and a Z80 M1 REFRESH cycle asserts MREQ but is a DRAM refresh, not a memory access, so MAME charges nothing for either.
rtl/SegaG80_CPU.sv:175 MEASURED before the fix (verilator/scramble/wait_main.cpp, real ROM, 40M clks): ours 2,072,429 charges vs MAME-equivalent 1,349,139 = 1.54x excess = 722,800 M1 refresh cycles + 490 I/O accesses => ~35% of Z80 time burned on waits MAME neve
rtl/SegaG80_CPU.sv:182 Matches the HW report of a hard slowdown from mid-wave-3 onward that MAME does not exhibit.
rtl/SegaG80_CPU.sv:210 NMI from service switch — edge-triggered pulse MAME segag80r.cpp:375 INPUT_CHANGED_MEMBER(service_switch) pulse_input_line(NMI)
rtl/SegaG80_CPU.sv:244 IRQ — MAME segag80r_v.cpp:42-56 vblank_start: if (video_control & 0x04) ASSERT_LINE /INT IRQ_CALLBACK: CLEAR_LINE /INT, return 0xFF (vectorless → RST 38h)
rtl/SegaG80_CPU.sv:311 Scrambled-write PC latch — MAME segag80r.cpp:400-410 (g80r_opcode_r) On every M1 opcode fetch: latch PC if the fetched byte is 0x32 (LD (nn),A), otherwise set sentinel 0xFFFF.
rtl/SegaG80_CPU.sv:316 The old comment here claimed "MAME ...
rtl/SegaG80_CPU.sv:316 never clears it after the write — it is simply overwritten by the next opcode fetch." **That is wrong.** MAME clears it inside decrypt_offset (segag80r.cpp:412-421): offs_t pc = m_scrambled_write_pc; m_scrambled_write_pc = 0xffff; <--
rtl/SegaG80_CPU.sv:340 (Faithfulness note: MAME consumes only on RAM/VRAM writes — decrypt_offset is called from mainram_w/vidram_w/usb_ram_w — so the consume is gated to the same address ranges rather than any memory write.)
rtl/SegaG80_CPU.sv:347 One-shot consume, gated to the ranges MAME routes through decrypt_offset.
rtl/SegaG80_CPU.sv:368 consumed, per MAME decrypt_offset
rtl/SegaG80_CPU.sv:382 confirmed via MAME's init_pignewt())
rtl/SegaG80_CPU.sv:398 Address decode — segag80r.cpp:552-559
rtl/SegaG80_CPU.sv:409 USB shared program RAM — MAME init_pignewt installs this over $D000-$DFFF, a window no other G-80 raster game decodes.
rtl/SegaG80_CPU.sv:414 Port decode — segag80r.cpp:576-583 0xBE/0xBF : video port r/w 0xF8-0xFB : mangled ports (read) 0xF9 : coin counter write (mirror 0xFD) 0xFC : direct FC port (read)
rtl/SegaG80_CPU.sv:423 Sindbad Mystery has its own I/O map (MAME sindbadm_portmap): $40 = IRQ acknowledge, $41 = background control, $42/$43 = video ports (NOT $BE/$BF), $80-$83 = i8255 PPI, $F8-$FB = mangled ports, and no $FC at all.
rtl/SegaG80_CPU.sv:436 $F9 and mirror $FD are coin-counter writes (MAME segag80r.cpp:513-517).
rtl/SegaG80_CPU.sv:442 Astro Blaster audio ($3E/$3F) — MAME segag80r.cpp:1894
rtl/SegaG80_CPU.sv:445 Speech board ($38 data, $3B control) — MAME segag80r.cpp:1889-1891.
rtl/SegaG80_CPU.sv:449 Background board ($B8-$BD) — MAME segag80r.cpp:1997-1999 (init_pignewt).
rtl/SegaG80_CPU.sv:458 Space Odyssey background board ($08-$0F) — MAME segag80r.cpp:1926-1929.
rtl/SegaG80_CPU.sv:463 Monster Bash i8255 PPI ($0C-$0F) — MAME main_ppi8255_portmap + monsterb().
rtl/SegaG80_CPU.sv:555 Video port $BE/$BF (MAME segag80r_v.cpp:287-324)
rtl/SegaG80_CPU.sv:597 Background board registers — MAME segag80r_v.cpp pignewt_back_port_w.
rtl/SegaG80_CPU.sv:598 $B8 scroll X low $B9 scroll X high (d1..d0) + enable (d7) $BA scroll Y low $BB scroll Y high (d1..d0) $BC character bank — MAME remaps to (d&0x09)|((d>>2)&2)|((d<<2)&4), i.e. only d3 and d0 survive, as {d3,d0,d3,d0} $BD not connected
rtl/SegaG80_CPU.sv:662 Logical port assembly — MAME segag80r.cpp g80r_generic + per-game PORT_MODIFY overrides.
rtl/SegaG80_CPU.sv:663 All bits are ACTIVE-LOW unless noted (IP_ACTIVE_LOW is the MAME default).
rtl/SegaG80_CPU.sv:739 demangle — MAME segag80r.cpp:443-449
rtl/SegaG80_CPU.sv:755 Mangled port read — MAME segag80r.cpp:452-465 shift = port_addr & 3; each logical byte is right-shifted by shift.
rtl/SegaG80_CPU.sv:759 Space Odyssey cabinet shuffle — MAME spaceod_mangled_ports_r (468-495) and spaceod_port_fc_r (496-509).
rtl/SegaG80_CPU.sv:767 $FC as MAME codes it for spaceod: PLAYER 1, ACTIVE-HIGH.
rtl/SegaG80_CPU.sv:791 FC direct port — ACTIVE-HIGH per MAME astrob layout (cocktail side)
rtl/SegaG80_CPU.sv:802 Coin counter write ($F9) — MAME segag80r.cpp:513-517.
rtl/SegaG80_CPU.sv:849 Universal Sound Board bus (MAME segag80r.cpp:2003-2006, init_pignewt).
rtl/SegaG80_CPU.sv:868 Space Odyssey background board bus (MAME segag80r.cpp:1926-1929).
rtl/SegaG80_CPU.sv:873 Sindbad Mystery sound board (MAME sindbadm_portmap + sindbadm_misc_w).
rtl/SegaG80_CPU.sv:888 005 sound board bus (MAME sega005_sound_board: out_pa = effects, out_pb = melody).
rtl/SegaG80_CPU.sv:893 Speech board strobes (MAME segag80r.cpp:1890-1891)
rtl/ram_rom/speech_data_rom.sv:48 MAME declares `ROM_REGION(0x4000, "speech:data")` and loads only 0x2000 (segag80r.cpp astrob), so 0x2000-0x3FFF reads back as ZERO there.
rtl/segag80_5028.sv:8 Only the $0000-$7FFF window is encrypted (MAME m_decode_size = 0x8000); $8000+ is plaintext.
rtl/segag80_5028.sv:29 MAME: if (src & 0x80) { col = 3 - col; xorval = 0xa8; }
rtl/segag80_bg.sv:21 MAME expands gfx1 into 16 banks with monsterb_expand_gfx, but the expansion is pure address arithmetic, so the two raw 8 KB ROMs are addressed directly instead: dest[0x0000 + i*0x800] = src[0x0000 + (i & 3)*0x800] plane 0 dest[0x8000 + i*
rtl/segag80_bg.sv:53 Pixel out — palette index is {1'b1, bg_color, bg_pix} (MAME color base 64)
rtl/segag80_decrypt.sv:3 Sega G-80 security chip decryption MAME segag80_m.cpp:16-314
rtl/segag80_spaceod_bg.sv:19 They are uint16_t in MAME even though the flip XOR is only 8 bits wide.
rtl/segag80_spaceod_bg.sv:34 MAME: 0xfe | bg_detect
rtl/segag80_spaceod_bg.sv:49 MAME displays when m_bg_enable == 0
rtl/segag80_spaceod_bg.sv:138 MAME: effy = (y + vcounter + 22) ^ flipmask.
rtl/segag80_spaceod_bg.sv:142 MAME: effx = ((x + hcounter) ^ flipmask) + xoffset — xoffset is added AFTER the flip, not before.
rtl/segag80_spaceod_bg.sv:203 MAME's gfx_8x8x6_planar lists planeoffset MSB-first, so RGN_FRAC(5,6) (ROM index 5) is pixel bit 5.
rtl/segag80_video.sv:3 Sega G-80 raster video — VRAM + palette + tilemap scanout MAME segag80r_v.cpp (videoram_w, draw_videoram, g80_set_palette_entry)
rtl/segag80_video.sv:50 Palette-write decode MAME: offset&0x1000 && video_control&0x02 → paletteram pignewt_videoram_w takes offsets 0x1040-0x107F first and routes them to the background bank (paloffs | 0x40); without that intercept they fall through with offset &
rtl/segag80_video.sv:61 monsterb_videoram_w gates the background-palette intercept on video_control[6], not [1], and does NOT return afterwards — MAME: "since the background board is not integrated with the main board, writes here also write through to regular vid
rtl/segag80_video.sv:90 128-entry palette RAM — 0x00-0x3F foreground, 0x40-0x7F background MAME: paletteram offset = cpu_addr & 0x3F, background bank | 0x40 Byte format: bits[2:0]=R, bits[5:3]=G, bits[7:6]=B
rtl/segag80_video.sv:104 MAME combine_weights with 4700/2400/1200+220.
rtl/segag80_video.sv:146 Scanout pipeline — G80R character bitmap (MAME charlayout at segag80r.cpp:1021; videoram_w map at segag80r_v.cpp:260-277; draw_videoram at segag80r_v.cpp:632).
rtl/segag80_video.sv:161 bit_sel = 7 - x (MAME xbits {0..7} = MSB first;
rtl/segag80_video.sv:220 Plane base offsets per MAME segag80r_v.cpp videoram_w (mark_dirty on offset & 0x800).
rtl/segag80_video.sv:262 MAME charlayout xbits = {0,1,..,7}: leftmost pixel (pix_col=0) takes bit-offset 0, which per MAME's gfxdecode extraction is the byte's MSB (bit 7).
rtl/segag80_video.sv:269 MAME screen_update_segag80r: a background board makes foreground pen 0 transparent (transparent_pens = 1); with no background board the foreground is fully opaque.
rtl/segag80_video.sv:281 Space Odyssey draws the foreground OPAQUE and then lets the background through wherever the foreground's COLOUR is black — MAME tests the palette RAM contents (m_paletteram[dst[x]]), not the pen index.
rtl/segag80_vtg.sv:3 Sega G-80 raster video timing generator MAME segag80r.cpp:132-140, 1071 HTOTAL=328, HBSTART=256, VTOTAL=262, VBSTART=224
rtl/segag80_vtg.sv:38 HTOTAL and HBSTART come from MAME (segag80r.cpp:134-136) and give 72 counts / 13.96 us of blanking, but MAME's set_raw says nothing about where sync sits inside that, so the placement was invented:

Says it matches, follows or was checked against MAME — 5

rtl/SegaG80_CPU.sv:228 NOTE (verified 2026-08-11, T80.vhd:1236-1242): T80's NMI edge detector sits OUTSIDE its `if CEN = '1'` block -- it samples NMI_n on every clk_sys edge and latches NMI_s until the NMI is serviced, matching a real Z80's internal latch and MAM
rtl/SegaG80_CPU.sv:333 MEASURED (verilator/scramble, real T80s via GHDL + this latch + real segag80_decrypt, vs MAME's rule): 149 interrupts, 298 stack writes, **92 mismatches** e.g. push raw=C9FF -> ours C9DF, MAME C9FF.
rtl/SegaG80_CPU.sv:373 Stays valid from the 0x32 M1 fetch until the next opcode fetch, matching MAME's m_scrambled_write_pc lifecycle.
rtl/SegaG80_CPU.sv:666 Per-game control mapping — verified against segag80r.cpp INPUT_PORTS_START(<game>) PORT_MODIFY overrides on top of g80r_generic, one case arm per game_id, matching MAME's source 1:1.
rtl/ram_rom/speech_data_rom.sv:2 CPU-side address is 14 bits; upper 8 KB (cpu_addr[13]=1) returns 0x00, matching MAME's zero-filled 0x4000 "speech:data" region.

Says it was translated, ported or taken from MAME — 6

rtl/SegaG80.sv:3 Sega G-80 top-level module Copyright (C) 2026 Rodimus Based on MAME segag80r.cpp / segag80r_v.cpp / segag80_m.cpp
rtl/SegaG80_CPU.sv:3 Sega G-80 CPU board Copyright (C) 2026 Rodimus Based on MAME segag80r.cpp:552-583 (memory + port maps), 1059 (clock)
rtl/SegaG80_CPU.sv:666 Per-game control mapping — verified against segag80r.cpp INPUT_PORTS_START(<game>) PORT_MODIFY overrides on top of g80r_generic, one case arm per game_id, matching MAME's source 1:1.
rtl/segag80_5028.sv:3 Sega 315-5028 encrypted Z80 - opcode/data decryption Ported 1:1 from MAME src/devices/machine/segacrpt_device.cpp (sega_315_5028_device::decrypt convtable + the shared decode() routine).
rtl/segag80_bg.sv:3 Sega G-80 raster background board — "full scroll" variant Copyright (C) 2026 Rodimus Based on MAME segag80r_v.cpp (bg_get_tile_info, draw_background_full_scroll, pignewt_back_port_w) and segag80r.cpp (monsterb_expand_gfx, gfx_monsterb).
rtl/segag80_spaceod_bg.sv:3 Sega G-80 raster background board — Space Odyssey variant Copyright (C) 2026 Rodimus Based on MAME segag80r_v.cpp (spaceod_get_tile_info, spaceod_scan_rows, spaceod_back_port_r/w, draw_background_spaceod, spaceod_bg_init_palette) and segag8

Shares text with the MAME driver without saying so — 4

Arcade-SegaG80.sv:98 "P3O36,H Center,0,-1,-2,-3,-4,-5,-6,-7,+7,+6,+5,+4,+3,+2,+1;", — shares text with sega/segag80r.cpp:541
Arcade-SegaG80.sv:99 "P3O7A,V Center,0,-1,-2,-3,-4,-5,-6,-7,-8,-9,-10,-11,-12;", — shares text with sega/segag80r.cpp:541
rtl/segag80_video.sv:63 the background board is not integrated with the main board, writes here — shares text with sega/segag80r_v.cpp:432
rtl/segag80_video.sv:64 also write through to regular videoram". Leaving pal_write/vram_write — shares text with sega/segag80r_v.cpp:433

SegaSys1+2 (TheJesusFish)#
Brain, Choplifter, DakkoChan House, Gardia …
TheJesusFish/Arcade-SegaSys1-2_MiSTer @ 04134550
MAME compared: sega/system1.cpp + 2 related file(s)
Read: 19 HDL files, 4,397 lines (Quartus project)

TheJesusFish
repository only

Not enough evidence in the code

insufficient

28%

Statements: 4 toward MAME

Cites MAME source — 3

Arcade-SEGASYS1.sv:222 MAME sources mention 20MHz, 8MHz crystals and 5Mhz pixel clock.
rtl/sn76489/sn76489_noise.vhd:199 Tapped bits according to MAME's sn76496.c, implemented in function lfsr_tapped_f.
README.md:79 copy ROM zip files to /media/fat/\_Arcade/mame

Says it was translated, ported or taken from MAME — 1

rtl/MC8123.v:1 Copyright 2021 by blackwine decryption algorithm based on MAME sources

SeibuSPI (zakk4223)#
Senkyu, E Jong High School, Raiden Fighters, Raiden Fighters 2 - Operation Hell Dive …
zakk4223/Arcade-SeibuSPI_MiSTer @ 37e5fdbb
MAME compared: seibu/seibuspi.cpp + 10 related file(s)
Read: 59 HDL files, 35,981 lines (Quartus project)

zakk4223
repository only

Mostly MAME

medium

51%

Statements: 4 toward hardware, 186 toward MAME

Cites hardware documentation that MAME's driver does not — 3

rtl/z386/z386.sv:3106 Call gate: set SIGMA for CS write at 2F3 (gates jump to FARJUMP2 which skips PASS at 2ED)
rtl/z386/z386.sv:3752 Workaround for call gates: FARJUMP2 (2F0-2F3) skips PASS at 2ED, so SIGMA isn't set from COUNTR At 2F3, if SIGMA=0 but COUNTR!=0, use COUNTR (set by gate_detect for call gates)
rtl/z386/z386.sv:4021 IN+= latches the delta like IN=+: PUSHA latches -1 at 089 (IN=+) then +WORDSZ at 08B (IN+=) for the 08E IN+D loop.

Says it was checked on “real hardware” — 1

rtl/spi_video_timing.sv:12 The CRTC register (0x408) nominally says vblank starts at 253, but the real board only displays 240 lines -- confirmed on hardware: turning the monitor's height down does NOT reveal lines 240..252, so they are blanked, not overscanned.

Cites MAME source — 173

SeibuSPI.sv:284 The MRAs are named after the games now, not the sets, and rdfts is a clone of rdft in MAME so it sits under _alternatives.
SeibuSPI.sv:733 It is joystick bit 11, the eighth name in the MRA's <buttons> list, and NOT button 3: four of the seven sets are MAME's spi_3button and use that as a game button.
SeibuSPI.sv:1236 Bit 12 has NO default in the MRA's `default=` list and that is not an oversight: Main only accepts the eight base pad names there (A B X Y L R Start Select, joymapping.cpp:72) and the first eight buttons have taken all of them.
SeibuSPI.sv:1253 Bit 15 is NOT: it is a DIPSWITCH field in MAME, which does not take the port's IP_ACTIVE_LOW inversion, and its Off state is the bit CLEAR.
SeibuSPI.sv:1295 MAME's sxx2c port: bits [1:0] = 0x3 "Update", 0x0 "Normal"; bits [7:2] are unused IP_ACTIVE_LOW and read as 1.
SeibuSPI.sv:1310 Leaving it in update mode does NOT make a programmed cartridge reflash: the game skips the updater on a matching stamp whatever the jumper says, which is what section 0 measured under MAME's own default of Update.
rtl/ddr_rom_reader.sv:8 rom_loader does not copy bytes, it TRANSFORMS them: a 14-part scatter with ten destination modes, the BPE+DPCM decoder for rdft2's and rfjet's sample flash, and MAME's sprite_reorder swizzle folded into the destination address.
rtl/rom_loader.sv:4 ROM loader: streams the MRA's concatenated ROM image from ioctl into SDRAM, performing the MAME ROM_LOAD24_* / ROM_LOAD32_* scatter in hardware.
rtl/rom_loader.sv:12 NOTE on the 24-bit word mode: MAME's ROM_GROUPWORD swaps the two bytes of each source word when the destination is a plain ROM_REGION, as "chars" and "tiles" are.
rtl/rom_loader.sv:15 This was verified by comparing tools/build_sdram_image.py's output against MAME's own :maincpu region (byte exact) and against its decrypted :chars and :tiles regions (exact after decryption).
rtl/rom_loader.sv:98 LINEAR, plus MAME's sprite_reorder() rotated into the destination: within each 64-byte group the 32 words are permuted so that output word 2j comes from input word j and output word 2j+1 from input word j+16.
rtl/rom_loader.sv:125 M_SPR_ILV_R is the same with MAME's sprite_reorder() applied to the source index first, for the RISE10 sets.
rtl/rom_loader.sv:177 The order in each must match the <part> order in the MRA, and tools/check_mra.py checks exactly that against MAME's driver -- nothing at runtime can, because the MRA carries no scatter information.
rtl/rom_loader.sv:248 The authentic tail is in MAME's OWN region order -- sound01's two ROMs, then soundflash1's blank -- because that is the order an MRA has to send them in for check_mra.py to hold each one against the ROM_START entry it claims to be.
rtl/rom_loader.sv:251 That check compares the comment to MAME's ROM name exactly, so these say the name and nothing else: 14 and 15 are the updater's two sources, 16 is the blank it programs.
rtl/rom_loader.sv:265 Differences from rdft, all read off MAME's ROM_START(rdft2): * twice the tiles (12 MB), so the second bg group sits at +6 MB * text lanes come in the order fix0(1), fix1(0), fixp(2) * 18 MB of sprites as three 6 MB plane-pair chunks, one lo
rtl/rom_loader.sv:280 Stored PACKED, one byte per 386 dword; the window's other three byte lanes are zero in MAME's region too.
rtl/rom_loader.sv:300 Authentic: the two sound01 ROMs and then a blank flash, in MAME's own region order, in place of the two slices of a derived image.
rtl/rom_loader.sv:318 The same shape as rdft2 -- same board, same updater generation, same three text lanes in the same order -- with four differences, all read off MAME's ROM_START(rfjet): * 9 MB of tiles, not 12.
rtl/rom_loader.sv:325 * 24 MB of sprites as three 8 MB chunks, and here MAME's file order IS the numeric one: obj-1 at region 0, obj-2 at 8 MB, obj-3 at 16.
rtl/rom_loader.sv:373 Same decryption as rdft -- MAME's init_viprp1 is init_sei252, so the text, tile and sprite keys and the 4 MB sprite chunk are the ones already wired for the SEI252 sets.
rtl/rom_loader.sv:407 Part 0 is the zero fill for the half of the program region MAME leaves empty.
rtl/rom_loader.sv:431 A mahjong game: the flash, video and sound work, but its controls are a custom encoding (MAME's ejanhs_encode) that this core does not decode.
rtl/seibu_partial_add.sv:4 The primitive under every Seibu Kaihatsu graphics encryption (mame/src/mame/seibu/seibu_helper.cpp): an adder whose carry only propagates from bit i to bit i+1 where carry_mask[i] is set, and whose carry out of the top bit wraps around to f
rtl/spi_cpu.sv:6 Address map (sxx2e_map, seibuspi.cpp:1004,1077):
rtl/spi_cpu.sv:17 The sound01 window (MAME maps the whole region at 00A0_0000-013F_FFFF) is where the cartridge sets that have a second sound ROM keep their Z80 program.
rtl/spi_cpu.sv:29 Everything else in the sound01 window keeps falling through to S_NULL, which is what MAME's ERASE00 region reads as anyway, and so do the three dead lanes of every dword in this one.
rtl/spi_cpu.sv:35 The rest of MAME's sound01 region is the cartridge's 2 MB PCM ROM, and the game's own sample-flash updater reads it from there a byte at a time to program the flash (PLAN.md 17.2).
rtl/spi_cpu.sv:38 It is loaded ROM_LOAD32_WORD, so it occupies TWO byte lanes of every dword -- 1 MB of ROM per 2 MB of window -- and MAME's ROM_CONTINUE(base + 0x400000) puts the second megabyte 2 MB further up, which is the skip the 386's own fetcher walks
rtl/spi_cpu.sv:355 MAME drives IRQ0 with HOLD_LINE on vblank and the acknowledge callback unconditionally returns vector 0x20 -- there is no PIC on this board.
rtl/spi_cpu.sv:415 The two can coincide -- the toggle crosses from clk_sys and is true for one clk_cpu cycle, and the retire is one cycle a frame -- and MAME's HOLD_LINE re-asserts on a vblank that arrives during the acknowledge rather than dropping it.
rtl/spi_cpu.sv:1009 MAME performs each video DMA atomically inside the trigger write, so no instruction can run between the trigger and the copy.
rtl/spi_cpu.sv:1017 This is a correctness fix for tearing, NOT the cause of the empty sprite list: MAME's capture shows the game does not clear the buffer after triggering (main RAM at 0x37000 still holds the list at end of frame).
rtl/spi_cpu.sv:1181 The board decodes no I/O ports; MAME's map has none.
rtl/spi_cpu.sv:1256 sound01 answers one packed byte in lane 0 and zeroes above, which is what MAME's ROM_LOAD32_BYTE region holds there; the PCM source answers two, ROM_LOAD32_WORD.
rtl/spi_cpu.sv:1258 The dead lanes are zero in MAME's region too, not don't-care -- the region is ERASE00 and the updater's fetcher reads whole dwords.
rtl/spi_dma.sv:4 Video DMA engines (seibuspi_v.cpp:238,327,351).
rtl/spi_dma.sv:25 That is what MAME does, and the renderer reads them back from 0x200 / 0x600 / 0xA00 for back / midl / fore respectively.
rtl/spi_dma.sv:47 MAME asserts DWORD_ALIGNED on this register, so the low two bits are always zero and are not carried here.
rtl/spi_dma.sv:180 MAME performs each DMA instantaneously inside the trigger write, so it always uses the video_dma_address current at that instant.
rtl/spi_ds2404.sv:8 The real DS2404 speaks 1-Wire, and the board does not: the SEI600 presents it to the 386 as four byte ports, and MAME's ds2404.cpp models THAT view rather than the chip's own protocol (its header says so, at length).
rtl/spi_ds2404.sv:11 So the thing to be faithful to is MAME's device, which is what the game has always been talking to:
rtl/spi_ds2404.sv:21 MAME calls anything else a fatal error; hardware cannot, so an unknown byte is ignored and the machine stays where it is.
rtl/spi_ds2404.sv:42 The RTC is NOT part of the save file, because it is not part of MAME's either -- ds2404_device::nvram_write stores m_sram and nothing else.
rtl/spi_ds2404.sv:43 MAME seeds the counter from the host clock against a 1995-01-01 reference; there is no clock here, so it starts at zero and counts from power-on, the way a board whose battery has gone would.
rtl/spi_ds2404.sv:51 MAME ticks the counter at 256 Hz, so this is 114.545455 MHz / 256.
rtl/spi_ds2404.sv:129 MAME's state stack.
rtl/spi_ds2404.sv:143 MAME has a read-scratchpad state and no command that reaches it: cmd() decodes 0x0F, 0x55 and 0xF0 only.
rtl/spi_ds2404.sv:159 Six bits, not five: MAME's m_offset walks 0..32 and the write is guarded on `< 0x20`, so a 33rd scratchpad byte is DROPPED rather than wrapping back over the first.
rtl/spi_ds2404.sv:164 five bytes, low first, as MAME orders them
rtl/spi_ds2404.sv:199 MAME's loop runs `for (i = 0; i <= end_offset; i++)` over a 32-byte scratchpad, so a game asking for more than 32 reads past it there; here the index wraps, which is at least defined.
rtl/spi_ds2404.sv:260 nvram_default(): the SRAM comes up ZEROED, not erased, so a set with no save file yet sees what MAME's first boot sees.
rtl/spi_ds2404.sv:290 MAME's data_w() writes m_state[] and m_a2 and then reads them back within the same call, and steps the pointer twice, so all of it has to be visible here rather than a cycle late -- which is what these are for, and why they are the one plac
rtl/spi_ds2404.sv:343 ---- the RTC, 40 bits at 256 Hz ------------------------------ A tick landing on the same cycle as a copy into the counter's bytes leaves the incremented value with that byte replaced, where MAME's scheduler would give one or the other whol
rtl/spi_ds2404.sv:369 ---- 0x6DC --------------------------------------------------- Reading it has no side effect in any reachable state: MAME advances the pointer on the CLOCK write, not on the read.
rtl/spi_ds2404.sv:456 MAME calls this fatal
rtl/spi_ds2404.sv:470 MAME acts on it in the same call; here it is NAMED now and set up next cycle, which is what keeps the decode and the arithmetic out of one another's path.
rtl/spi_io.sv:5 (sxx2e_map / base_map, seibuspi.cpp:1004,1077; seibu_crtc.cpp)
rtl/spi_io.sv:7 MAME reaches it through seibu_crtc_device::write(offset, data), which then writes word `offset` of the CRTC's own 16-bit space -- so a CRTC register documented at internal byte address N is simply CPU byte address 0x400 + N. The registers t
rtl/spi_io.sv:45 MAME's own CRTC map documents it (seibu_crtc.cpp:34, "---x Flip Screen") but seibuspi_v.cpp decodes only bits 15 and 11, so MAME never flips -- the real board does.
rtl/spi_io.sv:101 Everything at or above it is SDRAM nobody has filled, and `spi_sound` reads it back as MAME's zero padding instead.
rtl/spi_io.sv:170 Read/write storage behind the whole CRTC window (0x400-0x44F, 20 dwords), mirroring MAME's `map(0x0000, 0x004f).ram()`.
rtl/spi_io.sv:207 MAME does the same: COMBINE_DATA into m_layer_bank, then BIT(m_layer_bank, 15).
rtl/spi_io.sv:217 Measured on rdfts -- the ONLY register bits that move when the DIP is toggled are this one and layer_scroll_base (0x42C-0x438), which neither MAME nor this core implements.
rtl/spi_io.sv:260 MAME video_start: 0 = all layers enabled
rtl/spi_io.sv:293 Every CRTC register is merged PER BYTE, which is what MAME's COMBINE_DATA does: bytes outside mem_mask keep their old value.
rtl/spi_io.sv:372 MAME drops writes past the end of the region and stops advancing, so do the same.
rtl/spi_io.sv:414 Both are the ACTIVE LOW pins: MAME's ff_r()/ef_r() return the negated internal flags, so d0 reads 1 when there is room to send and d1 reads 0 while nothing has come back.
rtl/spi_io.sv:424 MAME backs the whole Seibu CRTC window with `map(0x0000, 0x004f).ram()` and overlays the register handlers on top, so a read returns whatever was last written -- reg_1a even has an explicit reg_1a_r().
rtl/spi_io.sv:451 0x6DC is the DS2404's data byte and 0x6DD is the three bits the game waits to see clear -- the same dword, so one entry covers both, and MAME's spi_ds2404_unknown_r returns zero for the second.
rtl/spi_layers.sv:11 Layer geometry (seibuspi_v.cpp:591):
rtl/spi_layers.sv:19 Tile word decode (seibuspi_v.cpp:511):
rtl/spi_layers.sv:29 Within a decrypted group v (v[23] is the MSB of the first byte), MAME's gfx_layout puts entry k of planeoffset[] at bit offset 4k, pixel p at a further (3-p), and bit offset n reads as v[23-n].
rtl/spi_layers.sv:70 The fore layer's tile base, which depends on the SIZE of the tile region (seibuspi_v.cpp:585): 0x2000 up to 3 MB, 0x4000 up to 6 MB, 0x8000 beyond.
rtl/spi_layers.sv:76 Per GAME, not per board, and the same triple serves both layers -- MAME's text_decrypt and bg_decrypt take the same three constants.
rtl/spi_layers.sv:185 Rowscroll tables, when enabled (seibuspi_v.cpp:437).
rtl/spi_layers.sv:208 MAME indexes the table with (y + 19) & 511; the adder is presumably a CRTC value rather than a true constant, but every SPI game uses the same one.
rtl/spi_layers.sv:229 Rowscroll follows the MIRRORED row, because MAME indexes this table by SCREEN row while the tilemap source row is the scrolled one (seibuspi_v.cpp:405-420: rowscroll[(y+19)] against pix(y+sy)).
rtl/spi_layers.sv:366 MAME reads a group as w = (b0 << 16) | (b1 << 8) | b2, so the first byte becomes the MSB.
rtl/spi_mixer.sv:4 Layer mixer (screen_update_spi, seibuspi_v.cpp:434).
rtl/spi_mixer.sv:6 MAME composites in this exact order, and the odd bits matter:
rtl/spi_mixer.sv:20 The "back layer again" step is MAME's `(m_layer_enable & 0x15) == 0`, i.e. back, fore and sprites all on.
rtl/spi_mixer.sv:23 Sprites arrive as a single pixel per column carrying its priority, because that is how MAME works: every sprite is rendered into one buffer tagged with its priority, so sprite-versus-sprite occlusion is decided purely by list order and a hi
rtl/spi_mixer.sv:29 Alpha blending is MAME's alpha_blend_r32(dest, pen, 0x7f) -- (src*127 + dst*129) >> 8, not a 50/50 mix -- applied to a hand-picked set of pens.
rtl/spi_mixer.sv:179 Alpha table (seibuspi_v.cpp:603)
rtl/spi_mixer.sv:181 MAME sets these ranges and explicitly leaves the commented-out ones alone because they break specific games.
rtl/spi_mixer.sv:208 BGR555 is expanded to 8 bits per channel the way MAME's pal5bit does: x << 3 | x >> 2.
rtl/spi_mixer.sv:217 MAME's alpha_blend_r32(dest, pen, 0x7f), exactly:
rtl/spi_mixer.sv:260 MAME: (layer_enable & 0x15) == 0 => back, fore and sprites all enabled
rtl/spi_mixer.sv:296 MAME's ten composite steps, spread over five clk_sys cycles instead of crammed into one.
rtl/spi_mixer.sv:336 With the back layer disabled MAME does `bitmap.fill(0, cliprect)` (seibuspi_v.cpp:452), which writes the raw RGB value 0 into a bitmap_rgb32 -- hard black.
rtl/spi_nvram.sv:32 The 512-byte tail is byte-for-byte MAME's own `ds2404` nvram file.
rtl/spi_rise10_decrypt.sv:4 seibuspi_rise10_sprite_decrypt(), seibuspi_m.cpp.
rtl/spi_rise10_decrypt.sv:19 MAME writes both back as chunk0 = {plane5, plane4} chunk1 = {plane3, plane2} chunk2 = {plane1, plane0} and pixel j of plane n is bit j of that byte.
rtl/spi_rise11_decrypt.sv:4 seibuspi_rise11_sprite_decrypt(), seibuspi_m.cpp.
rtl/spi_rise11_decrypt.sv:15 `i` is MAME's loop variable, which is the index BEFORE sprite_reorder().
rtl/spi_rise11_decrypt.sv:25 MAME writes the planes back as chunk0 = {plane5, plane4} chunk1 = {plane3, plane2} chunk2 = {plane1, plane0} which is the same byte-to-plane map RISE10 uses; only the way the six planes are grouped into sums differs (543 / 210 here, 54 /
rtl/spi_rise11_decrypt.sv:39 MAME's `i`: the word's index within one plane-pair chunk, BEFORE sprite_reorder.
rtl/spi_rise11_decrypt.sv:64 MAME's plane543 line calls the 32-bit form, but every operand is 24 bits and R11_MASK543 cannot carry out of bit 23, so a 24-bit adder gives the same answer -- the generator refuses to emit constants for which that is not true.
rtl/spi_snd_window.sv:2 SeibuSPI - the 386's view of MAME's `sound01` region
rtl/spi_snd_window.sv:4 MAME gives the SXX2C cartridge a 10 MB `sound01` region mapped at 386 address 0x00A0_0000, holding two ROMs that the loader stores PACKED in SDRAM and that this decode unpacks on the fly.
rtl/spi_snd_window.sv:10 tools/check_snd01_window.py transcribes THIS file, and sim/tb_snd_window.cpp checks it against a model built from MAME's region layout.
rtl/spi_snd_window.sv:31 Generation B loads it ROM_LOAD32_WORD, so it occupies TWO byte lanes of every dword -- 1 MB of ROM per 2 MB of window -- and MAME's ROM_CONTINUE(base + 0x400000) puts the second megabyte 2 MB further up.
rtl/spi_snd_window.sv:48 Leaving the window enabled for a set with nothing behind it made the 386 read 0xFF where MAME reads 0x00 on all 512 K dwords, which is why `snd01_en` and `pcmsrc_en` are separate: check_snd01_window.py caught that before it reached hardware
rtl/spi_snd_window.sv:92 Stating the addresses whole and letting the unused bits go is what keeps the comments above readable in MAME's own byte addresses instead of in dword indices.
rtl/spi_sound.sv:5 (sxx2e_soundmap, seibuspi.cpp:1171)
rtl/spi_sound.sv:354 The region is 256 KB (MAME's :audiocpu region is 0x40000, eight 32 KB bank entries) and how much of it holds a program is per set.
rtl/spi_sound.sv:361 The pad still has to read as MAME's zeros rather than as whatever SDRAM held at power-on, so the bound is what was actually written -- the 386's download high-water on a cartridge, and the 128 KB ROM part on SXX2E.
rtl/spi_sound.sv:881 SXX2C only; MAME leaves it a TODO
rtl/spi_soundflash.sv:16 COMMANDS, from that trace plus MAME's intelfsh:
rtl/spi_soundflash.sv:29 Byte programming costs one write, and like MAME's intelfsh we charge no program time: the ritual then takes as long as the 386/FIFO/Z80 round trip makes it, which is tens of seconds rather than the minutes real flash needs (PLAN.md 16.6).
rtl/spi_soundflash.sv:37 The updater's actual sequence, logged out of MAME by tools/mame_flash_port.lua (PLAN.md 17.14):
rtl/spi_soundflash.sv:55 The updater erases everything first and MAME does the same thing, so nothing observable depends on it.
rtl/spi_soundflash.sv:108 ---- the watch (PLAN.md 19.11) ------------------------------------ rdft2's flash comes out with byte 0x29FE erased where MAME holds 0xFE: one byte in two megabytes, reproducibly, on two builds.
rtl/spi_soundflash.sv:169 A QUEUE, not a single block: the updater sends all sixteen block-erase pairs of a chip back to back without waiting, because MAME's intelfsh erases instantly and only its STATUS is slow (a 1-second timer).
rtl/spi_spr_decrypt.sv:4 mame/src/mame/seibu/seibuspi_m.cpp:115 (seibuspi_sprite_decrypt).
rtl/spi_spr_decrypt.sv:7 MAME writes the result back as six plane bytes and lets the gfx decoder unpack them; we skip the round trip and emit pixels directly.
rtl/spi_spr_decrypt.sv:12 gfx plane p of pixel x reads byte p of the row at bit x, and the decrypt stores plane5..plane0 into chunk0.b0, chunk0.b1, chunk1.b0, chunk1.b1, chunk2.b0, chunk2.b1 -- so gfx plane 0 (the pixel's LSB) comes from MAME's `plane5` variable, an
rtl/spi_spr_decrypt.sv:57 Bit 15 is deliberately unused -- MAME notes "Bit 15 is still unknown" and never reads it either.
rtl/spi_spr_decrypt.sv:72 key_table[], the y3 permutation and the four bit gathers (s1_in, add1_in, s2_in, add2_in) are machine generated from MAME.
rtl/spi_sprite.sv:4 Sprite engine (sei25x_rise1x_spr.cpp).
rtl/spi_sprite.sv:21 MAME walks the list BACKWARDS (last entry first), so entry 0 is drawn last and ends up on top.
rtl/spi_sprite.sv:31 The RISE "extra bank" bit -- word 2 bit 12, which becomes tile code bit 16 -- is applied only when the gfx region holds MORE than 0x10000 tiles, which is MAME's own gfxbank_callback rule (seibuspi_v.cpp:370).
rtl/spi_sprite.sv:61 It is no longer an address stride, because the chunks are interleaved rather than laid end to end; it survives because MAME's extra-bank rule is stated in terms of it (elements = chunk / 64).
rtl/spi_sprite.sv:107 Exposed so the golden test can decode the same tile row straight out of the sprite ROM with MAME's decryptor and compare pixel for pixel.
rtl/spi_sprite.sv:185 MAME: gfxbank_callback adds 0x10000 only when elements > 0x10000, and elements is the chunk size over 64 bytes per tile.
rtl/spi_sprite.sv:330 RISE11's plane210 sum takes MAME's loop variable `i` as its addend, so the index has to be reconstructed here -- and it is the index BEFORE sprite_reorder, which is not the position the word was read from.
rtl/spi_sprite.sv:343 Get this wrong and the pens are silently wrong -- there is nothing downstream that could notice -- so tb_rise11_decrypt walks the words in exactly this order and checks them against MAME's final image.
rtl/spi_sprite.sv:376 spi_spr_decrypt emits the pen BIT REVERSED: its bit p is MAME's plane(5-p), i.e. bit 0 carries plane5 which is the pen's MSB.
rtl/spi_sprite.sv:449 FIFO order is list order, so MAME's "later entry drawn on top" still falls out of the write order exactly as before.
rtl/spi_sprite.sv:562 MAME skips code 0 (`code % elements == 0`).
rtl/spi_tile_decrypt.sv:4 mame/src/mame/seibu/seibuspi_v.cpp:42
rtl/spi_tile_decrypt.sv:12 The `tileno` term is what makes this cheap enough to do at fetch time rather than in a boot-time pass over the whole ROM: MAME derives it from the ROM address, but that collapses to the tile code.
rtl/spi_tile_decrypt.sv:16 chars: each 8x8 tile is 48 bytes = 16 groups, MAME uses group_index >> 4, so tileno = char code.
rtl/spi_tile_decrypt.sv:18 tiles: decryption restarts every 0xC0000 bytes; within a block each 16x16 tile is 192 bytes = 64 groups and MAME uses group_index >> 6, so tileno = tile_code & 0xFFF.
rtl/spi_tile_decrypt.sv:35 MAME: bitswap<24>(val, 18,19,9,5, 10,17,16,20, 21,22,6,11, 15,14,4,23, 0,1,7,8, 13,12,3,2) The first source index becomes the result's MSB.
rtl/spi_top.sv:332 Leaving the window on for it made the 386 read the unwritten SDRAM there as 0xFF where MAME reads 0x00, on all 512 K dwords of it -- caught by tools/check_snd01_window.py before it ever reached hardware.
rtl/spi_top.sv:424 layer_enable is active LOW per MAME (0 = layer shown).
rtl/spi_top.sv:979 bg_fore_pos is the fore layer's tile base and it follows the SIZE of the tile region (seibuspi_v.cpp:585): 0x2000 up to 3 MB, 0x4000 up to 6 MB, 0x8000 beyond.
rtl/spi_top.sv:986 The same triple does text and background -- MAME's text_decrypt and bg_decrypt take the same three constants -- so one selection covers both layers.
rtl/spi_top.sv:1081 The chunk size is no longer an address stride -- the loader interleaves the chunks -- it is what MAME's extra-bank rule counts tiles with.
rtl/spi_video_timing.sv:6 The Seibu CRTC is programmable, but every SPI game writes essentially the same values, and MAME hardcodes the resulting raster (seibuspi.cpp:898):
rtl/spi_video_timing.sv:15 MAME blanks at 240 for the same reason.
rtl/ymf271.sv:4 Even offsets latch an address, odd offsets deliver the data to one of four FM register banks, the PCM bank, or the timer/control bank (ymf271_device::write, ymf271.cpp:1446).
rtl/ymf271.sv:148 ext_latch is a read-ahead: a read returns it and only then advances the address and refetches, which is MAME's structure and the reason the first read after setting an address is a dummy.
rtl/ymf271.sv:375 MAME's ymf271 read() has the same shape -- ext_read() is called once per advance and its result is what the next read returns -- and doing it at the mux instead would answer from the address the port has moved on to, which shows up as the w
rtl/ymf271.sv:417 MAME contradicts it deliberately -- the split matches the other Yamaha FM chips -- and the timer is this board's sound heartbeat, so follow MAME.
rtl/ymf271.sv:425 A timer only ever starts here: MAME reaches the "stop" branch only when the enable bit is already set, so it can never be taken.
rtl/ymf271.sv:558 It returns the LATCHED byte and only then advances, so the first read after setting an address is a dummy and the data stream starts at address+1 -- MAME's read() does exactly this.
rtl/ymf271.sv:567 With the direction bit clear the port reads 0xFF either way, which is what MAME does and what the existing test pins down.
rtl/ymf271_synth.sv:4 MAME's sound_stream_update / op / eg_tick / pcm_sample / env_mul / pan (ymf271.cpp, the OPX rewrite 03761e46766), re-expressed as one serial pass over 48 slots per 44100 Hz sample.
rtl/ymf271_synth.sv:8 This replaced a port of MAME's OLD core, which worked in linear gains: a 6 x 1024 signed waveform ROM multiplied by an envelope volume.
rtl/ymf271_synth.sv:13 Detune, Acc On, EN/EXT Out, PCM interpolation and the external-waveform key code all arrived with it; PLAN.md 14.5 listed every one of them as unimplementable because MAME did not implement them either.
rtl/ymf271_synth.sv:34 MAME's comment says so outright -- "modulators with a lower slot number are taken from the current frame, higher-numbered ones from the previous".
rtl/ymf271_synth.sv:62 tools/check_ymf271_math.py sweeps phase_inc, pcm_step and the envelope increment against MAME's unbounded integers, 2.5 M combinations, and fails if any of them is a bit short.
rtl/ymf271_synth.sv:82 The cartridge board wires chip output 0 to the left speaker and 1 to the right (MAME's spi(): add_route(0,"speaker",1.0,0) and (1,...,1)); the single board sums ALL of them into one (sxx2e(): ALL_OUTPUTS -> "mono").
rtl/ymf271_synth.sv:161 W_OUT is 18 rather than the operator's 14 because waveform 6 is not an operator output: it is a DC half-scale level plus the modulation input stretched by 64, which reaches about 2.5x the range of every other waveform (MAME 783e8a2efc2).
rtl/ymf271_synth.sv:483 Both heads are reached before any slot that needs the value, so this is never stale within a sample -- which is what MAME's rebuild_group() achieves by rebuilding the whole group's connection cache up front.
rtl/ymf271_synth.sv:561 Detune, Acc On, Src Note and Src B were already stored -- they sat in bytes nothing extracted, because MAME's old core dropped them.
rtl/ymf271_synth.sv:596 Only the twelve slots of groups 0/4/8 -- slot % 4 == 0 -- can fetch external data; a wave-7 select anywhere else is silence, which is what MAME does and what the old core had to special-case because its update_pcm() called fatalerror() on t
rtl/ymf271_synth.sv:610 For an internal waveform MAME clamps the octave at 0 instead of letting the manual's 4*Block wrap up to octave 7.
rtl/ymf271_synth.sv:624 ---- envelope state transitions --------------------------------------- MAME checks these BEFORE picking the rate, and the D1L test runs on the state the attack test may just have changed.
rtl/ymf271_synth.sv:717 The tables are MAME's alg4 / alg3 / alg2, packed.
rtl/ymf271_synth.sv:883 Every width here is swept against MAME's int64 by tools/check_ymf271_math.py; the accumulator TRUNCATES to 32 bits, which is how increments above fs/2 alias (the hi-hat carriers of the Seibu titles are fed by such a modulator).
rtl/ymf271_synth.sv:911 The Fs divide happens on the full product, before the 32-bit truncation, which is the order MAME uses and the order the sweep checks.
rtl/ymf271_synth.sv:1025 MAME writes this as `eg_att += ((~eg_att) * inc) >> 4` on a SIGNED int32, where ~att is -(att+1) and the shift floors toward -infinity -- so the step is ceil((att+1) * inc / 16) subtracted, not floor((1023 - att) * inc / 16) added.
rtl/ymf271_synth.sv:1094 Mono sums every channel MAME routes, which is now all eight -- see the note on `stereo` at the top.
rtl/ymf271_synth.sv:1136 Real hardware has nothing above the ROM either; MAME reads 0 there because its region is ERASE00.
rtl/ymf271_synth.sv:1458 A slot in EG_OFF writes nothing: MAME's `continue` skips the history update along with the output, so a released operator leaves the head's loop holding its last real samples rather than pushing zeros through it.
rtl/ymf271_synth.sv:1463 A slot in EG_OFF hands over nothing: MAME's `continue` skips the history update along with the output.
rtl/ymf271_synth.sv:1546 MAME's device_reset() puts all 48 slots in EG_OFF, and a core that did not would come out of reset playing whatever it was playing when it went in.
README.md:17 As the kids say, this is an AI Slop mame core.
README.md:37 It is functional but 'mame quality' which still clearly has some issues.

Says it matches, follows or was checked against MAME — 5

rtl/ddr_rom_reader.sv:11 All of that is verified byte-exact against MAME (PLAN.md section 12) and none of it wants reimplementing against a different source.
rtl/rom_loader.sv:153 Both put their program in the UPPER half of the 2 MB region -- four 256 KB ROMs at offset 0x100000 -- so part 0 is a megabyte of zeroes that nothing reads but that makes the region match MAME's rather than hold whatever the last core left i
rtl/spi_sound.sv:221 The sound path is matched against MAME over two minutes of rdft2 attract (PLAN.md 14) and that measurement, not a compile, is what says this swap is sound -- so the thing it replaced should still be there to go back to.
rtl/spi_soundflash.sv:110 Everything the counters above can see says the write happened -- `dbg_progs` counts at ISSUE and matches MAME's command total exactly, `dbg_drops` is zero -- and replaying the updater's real writes through this module reproduces MAME byte f
rtl/ymf271_synth.sv:90 This matches MAME; it is not independently confirmed.

Says it was translated, ported or taken from MAME — 1

README.md:17 It was built based on mame seibuspi.cpp and some reference documentation/datasheets of the OPX sound chip.

Keeps a MAME approximation — 1

rtl/spi_mixer.sv:31 MAME's own table is an approximation (its TODO says as much); we reproduce it exactly rather than inventing something different.

Shares text with the MAME driver without saying so — 6

rtl/spi_layers.sv:37 16x16, planes {0,4,8,12,16,20}: pixel p = {v[20+p], v[16+p], ... v[p]} — shares text with seibu/seibuspi.cpp:1494
rtl/spi_spr_decrypt.sv:51 key(t, addr) = bit(key_table[addr & 0xFF] >> 4, t) — shares text with seibu/seibuspi_m.cpp:111
rtl/spi_tile_decrypt.sv:35 MAME: bitswap<24>(val, 18,19,9,5, 10,17,16,20, 21,22,6,11, — shares text with seibu/seibuspi_v.cpp:44
rtl/spi_tile_decrypt.sv:36 15,14,4,23, 0,1,7,8, 13,12,3,2) — shares text with seibu/seibuspi_v.cpp:44
rtl/ymf271_synth.sv:83 right (MAME's spi(): add_route(0,"speaker",1.0,0) and (1,...,1)); the — shares text with seibu/seibuspi.cpp:1837
rtl/z386/z386.sv:106 Bits: 31..22 21 20 19 18 17 16 15..14 13..12 11 10 9 8 7 6 5 4 3 2 1 0 — shares text with seibu/seibu_crtc.cpp:338

ShadowForce (yaguboo)#
Shadow Force - Henshin Ninja
yaguboo/Arcade-ShadowForce_MiSTer @ 761c048d
MAME compared: technos/shadfrce.cpp
Read: 14 HDL files, 6,220 lines (all HDL files: no Quartus project found)

yaguboo
repository only

Mostly MAME

medium

81%

Statements: 2 toward hardware, 136 toward MAME

Says it was checked against the original PCB — 2

README.md:28 MAME 드라이버가 모든 클럭에 "verified on PCB" 를 달아 두었고 세 크리스털의 실측 주파수까지 기록해 두어서, 처음부터 타이밍 근거가 아주 튼튼한 기판이었습니다.
README.md:186 이 코어는 MAME 의 `shadfrce` 드라이버와 그 주석에 남겨진 기판 정보 — 클럭마다 붙은 "verified on PCB", 크리스털 실측값, 메모리 맵, 그래픽 디코드, ROM 구성 — 위에서 시작했습니다.

Cites MAME source — 116

projects/technos/shadow_force/integration/sf_download.sv:54 A .mra is an assembly INSTRUCTION SHEET -- <part name="32j4-0.12"/> and friends, concatenated by MiSTer out of the zip -- so it can express MAME's even/odd interleave and nothing else.
projects/technos/shadow_force/rtl/sf_main.sv:25 MAME raises the polled vblank flag at line 247 with the comment "-1 is an hack needed to avoid deadlocks", while raising the vblank *interrupt* at 248.
projects/technos/shadow_force/rtl/sf_main.sv:154 Decoded exactly as MAME lists the ranges.
projects/technos/shadow_force/rtl/sf_main.sv:225 MAME clears `offset ^ 3`, so the word at 1D0000 acks level 3 and the word at 1D0004 acks level 1.
projects/technos/shadow_force/rtl/sf_main.sv:330 1C0008 / 1C000C: MAME
projects/technos/shadow_force/rtl/sf_main.sv:349 MAME *assigns* rather than ORs, so the bits it never writes read as 0, not as 1.
projects/technos/shadow_force/rtl/sf_top.sv:40 Nothing has been compared against MAME.
projects/technos/shadow_force/rtl/sf_top.sv:279 **MEASURED, and it is not benign for every layer.** MAME says the game writes bg map RAM 97.6 % of the time during ACTIVE DISPLAY and sprite RAM 99.8 % (docs/HARDWARE.md 12b).
projects/technos/shadow_force/rtl/sf_top.sv:327 MAME models this with buffered_spriteram16 wired to screen_vblank.
projects/technos/shadow_force/rtl/sf_top.sv:342 The write trails the read by one, so stopping at 0xFFF wrote through 0xFFE and left word 0xFFF holding whatever the previous frame put there -- entry 511's last word, and entry 511 is the sprite MAME draws on top.
projects/technos/shadow_force/rtl/sf_top.sv:456 Building it needs one number neither reference supplies: MAME writes WATCHDOG_TIMER(config, "watchdog") with no time at all, and the PCB's period is an RC value nobody has measured.
projects/technos/shadow_force/rtl/sf_top.sv:461 Root CLAUDE.md 5.1: that is a "얼마나 자주인가" question, so it was answered by running MAME (tools/mame_watchdog_gap.lua, 178 s, 1,198,951 pets):
projects/technos/shadow_force/rtl/sf_top.sv:480 It was 256 -- 4.5 s -- chosen because MAME's worst gap between pets was 25 frames and 256 was ten times that.
projects/technos/shadow_force/rtl/sf_top.sv:483 MAME was the wrong ruler.
projects/technos/shadow_force/rtl/sf_top.sv:485 The board's 68000 waits on SDRAM that three tile layers and the sprite engine are already saturating, so it is far slower through the same code than MAME is -- and "ten times the MAME number" was ten times a number measured on a machine wit
projects/technos/shadow_force/rtl/sf_top.sv:536 Two readings of one fact (project CLAUDE.md 1.4): the low byte is what MAME measured as 25 frames, read back off the board by a different mechanism, and the high byte is the thing that must never move.
projects/technos/shadow_force/rtl/sf_top.sv:859 The 1K direct-mapped sf_romcache that stood here missed ~7,100 times a frame in the Tengu demo and held the 68000 to ~70 % of MAME's reads (DEBUG_LOG O-TENGU); the header of sf_romcache4 has the replay numbers.
projects/technos/shadow_force/rtl/sf_top.sv:884 Rendering the SAME phrase from the SAME sample ROM through our jt6295 in Verilator -- with an IDEAL ROM, one clock and always valid -- and through MAME's okim6295 gives output the player could not tell apart.
projects/technos/shadow_force/rtl/sf_top.sv:954 MAME says the Z80 touches 9 KB of its 64 KB ROM and 77 % of its reads land in one 1 KB page, so 1024 words hold the working set: 7,524 SDRAM reads a frame become 29.
projects/technos/shadow_force/rtl/memory/sf_romcache4.sv:10 Board row 5 read 34-36 k CPU reads a frame there against MAME's ~50 k (the same instrument read 56,863 = 56,863 at boot).
projects/technos/shadow_force/rtl/memory/sf_romcache4.sv:11 MAME's own ROM address stream for that scene (tools: session lua, 300 frames, 11.5 M reads) touches ~4,700 distinct words a frame, and the 1,024-word direct-mapped cache that stood here missed **~7,100 times a frame**, each miss waiting beh
projects/technos/shadow_force/rtl/cpu/sf_m68k.sv:16 Power Spikes has one interrupt and MAME autovectors it.
projects/technos/shadow_force/rtl/cpu/sf_m68k.sv:17 This board has three (raster, 16-line, vblank) at levels 1..3, and MAME's `set_input_line(n, ...)` on a plain M68000 with no vector callback is also autovectored -- so VPAn is asserted during an interrupt acknowledge here too, and the level
projects/technos/shadow_force/rtl/cpu/sf_m68k.sv:85 MAME drives the three IRQ lines with plain set_input_line() and installs no vector callback, so the 68000 takes the autovector for the level it sees -- 0x64, 0x68, 0x6C for levels 1, 2, 3, which is exactly the table in the driver header.
projects/technos/shadow_force/rtl/cpu/sf_m68k.sv:88 Those vectors were also read straight out of the ROM by tools/build_rom.py's sibling check, so this is not an assumption about what MAME meant.
projects/technos/shadow_force/rtl/video/sf_video.sv:4 Layer order, from docs/HARDWARE.md section 10 (MAME's screen_update):
projects/technos/shadow_force/rtl/video/sf_video.sv:28 MAME implements it by rewriting all 0x4000 palette entries' contrast; on hardware it is one register feeding the DACs, so it is a multiply on the way out.
projects/technos/shadow_force/rtl/video/sf_video.sv:48 Flip screen -- 1C000A bit 0, `flip_screen_set(data & 0x01)` in MAME.
projects/technos/shadow_force/rtl/video/sf_video.sv:51 This one does -- shadfrce.cpp:697, SW1:6 -- so it is built.
projects/technos/shadow_force/rtl/video/sf_video.sv:55 Neither reference does that: MAME's helper flips the three tilemaps and `draw_sprites` never consults it, so its sprites stay put; FBNeo's `case 0x1C000B:` holds a comment and nothing else.
projects/technos/shadow_force/rtl/video/sf_video.sv:183 backmost one and MAME draws it opaque
projects/technos/shadow_force/rtl/video/sf_video.sv:285 MAME's order is bg1 (opaque), bg0, sprites, fg (on top).
projects/technos/shadow_force/rtl/video/sf_video.sv:289 MAME: bg1 (opaque) -> bg0 (trans) -> sprites -> fg (trans, on top).
projects/technos/shadow_force/rtl/video/sf_video.sv:291 MAME: bg1 (opaque) -> bg0 -> sprites -> fg on top, with a sprite whose w4[6] is set hidden wherever bg0 drew.
projects/technos/shadow_force/rtl/video/sf_video.sv:292 That last clause is why the line buffer carries the priority bit instead of resolving it at blit time: a suppressed sprite still CLAIMS its pixel in MAME (PRIORITY = 31 is written on the not-drawn path too), so the decision has to happen he
projects/technos/shadow_force/rtl/video/sf_video.sv:335 MAME computes `pen * (data / 255.0)`.
projects/technos/shadow_force/rtl/video/sf_video.sv:335 The obvious hardware form, `(pen * data) >> 8`, is `pen * data / 256` -- so at data = 255 it gives 254 where MAME gives 255, and EVERY colour is 0.4 % dark on every frame.
projects/technos/shadow_force/rtl/video/sf_video.sv:342 MAME is trunc(pen * float(data/255)), which is floor(pen*data/255) on all 8,192 pairs (checked exhaustively), and floor(x/255) == (x + (x>>8) + 1) >> 8 for every x <= 65025 (also checked exhaustively).
projects/technos/shadow_force/rtl/video/sf_video.sv:353 MAME fills the frame with the black pen when it is clear, so a core that ignores it shows a frame the real board would have blanked.
projects/technos/shadow_force/rtl/video/sf_crtc.sv:17 **vcnt counts raw screen lines 0..271, and the visible window starts at line 8.** That is deliberate and load-bearing: MAME's scanline timer, its vblank flag and its raster compare all use this same numbering, so keeping it means the inter
projects/technos/shadow_force/rtl/video/sf_dbg.sv:91 The low byte is the margin against WD_FRAMES = 256, and it is the second reading of a number MAME already gave as 25 frames.
projects/technos/shadow_force/rtl/video/sf_dbg.sv:201 Historical note, do not reinstate half the screen is still the game and a MAME frame can be matched.
projects/technos/shadow_force/rtl/video/sf_dbg.sv:535 The ROM contains both moves -- `andi.w #$FFFE` then `move.w d0,$1D0006` clears it, `ori.w #$0001` sets it -- which is MAME's "set/unset inside every trap instruction" (shadfrce.cpp:511).
projects/technos/shadow_force/rtl/video/sf_dbg.sv:685 MAME, MEASURED ON PLAY 2026-09-04 (the old 1888/10656 pair was rendered over 45 s of ATTRACT and is not this game's loud case): row 28 worst |delta| max 2006, and ZERO deltas over 2048 row 29 per-frame peak median 2363 p90 4073 p99 517
projects/technos/shadow_force/rtl/video/sf_dbg.sv:689 worst |delta| /frame (MAME max 2006)
projects/technos/shadow_force/rtl/video/sf_dbg.sv:690 peak |snd_l| /frame (MAME med 2363)
projects/technos/shadow_force/rtl/video/sf_dbg.sv:697 The low byte is the same quantity MAME measured as 25 frames, read back by a different mechanism, and it is the margin: near FF and the timeout is spent.
projects/technos/shadow_force/rtl/video/sf_dbg.sv:717 The music alone keeps this in the hundreds; MAME measures 522/s over the attract loop.
projects/technos/shadow_force/rtl/video/sf_dbg.sv:729 MAME over 57 s: 766 writes, 306 starts.
projects/technos/shadow_force/rtl/video/sf_dbg.sv:744 MAME, 3103 frames of real play, same definition:
projects/technos/shadow_force/rtl/video/sf_dbg.sv:753 Row 36 counts them on cen_p, and a Z80 write cycle spans two or three cen_p pulses -- if 42 is about half of 36 then 36 has been double counting and MAME's 522 was never the number to compare it with.
projects/technos/shadow_force/rtl/video/sf_dbg.sv:757 What these should read, from MAME rendered three times over the same 45 s of play -- once whole, once with the OKI's start commands swallowed, once with every key-on turned into a key-off.
projects/technos/shadow_force/rtl/video/sf_dbg.sv:759 MAME's wavs are the MIX, so they are HALF of what 39 and 40 carry: these are already doubled to the pre->>1 scale the rows publish.
projects/technos/shadow_force/rtl/video/sf_dbg.sv:766 The OKI is above 128 in 85.5 % of MAME's frames of play, so row 40 reading 0 on most frames is not "a quiet moment", it is absence.
projects/technos/shadow_force/rtl/video/sf_dbg.sv:809 ---- rows 46-47: is the mix clipping, HERE, not in MAME ------------ Row 46 samples clamped by sat16 this frame Row 47 worst |mix| BEFORE the clamp, saturating at FFFF
projects/technos/shadow_force/rtl/video/sf_dbg.sv:813 The clipping numbers in sf_sound's mix block were rendered in MAME.
projects/technos/shadow_force/rtl/video/sf_dbg.sv:832 ---- row 48: OKI voices held, the one number MAME and the board can be compared on directly ------------------------------- High byte most voices held at once during the frame Low nibble the mask at the frame boundary
projects/technos/shadow_force/rtl/video/sf_dbg.sv:837 MAME, 69 853 frames -- twenty minutes of real play, tools/mame_av_frame.lua:
projects/technos/shadow_force/rtl/video/sf_dbg.sv:843 MAME and FBNeo drop those; jt6295 restarts instead.
projects/technos/shadow_force/rtl/video/sf_sprite.sv:8 ---- the entry, from MAME ------------------------------------------------
projects/technos/shadow_force/rtl/video/sf_sprite.sv:10 `shadfrce.cpp:317-361`, every field cross-checked in docs/MAME_AUDIT.md section 4b.
projects/technos/shadow_force/rtl/video/sf_sprite.sv:34 MAME's plane list is MSB first, so entry 0 -- RGN_FRAC(4,5) -- is pen bit 4.
projects/technos/shadow_force/rtl/video/sf_sprite.sv:47 `prio_transpen` sets `pmask |= 1 << 31` (emu/drawgfx.cpp:933) before its pixel loop, so the FIRST sprite to touch a pixel blocks every later one, and MAME's loop runs 511 down to 0.
projects/technos/shadow_force/rtl/video/sf_sprite.sv:52 A sprite hidden behind bg0 STILL CLAIMS its pixel -- MAME writes `PRIORITY = 31` on the not-drawn path too -- so the buffer carries the priority bit and sf_video applies the bg0 test at mix time.
projects/technos/shadow_force/rtl/video/sf_sprite.sv:79 Both axes are 9-bit and wrap at 512, which is exactly MAME's four draws at `x`, `x-0x200`, `y+0x200` and both, without drawing anything four times.
projects/technos/shadow_force/rtl/video/sf_sprite.sv:95 MAME, coined up and played, reaches **156** enabled entries and wants more than 128 on **1.89 %** of frames (tools/mame_spr_enabled_play.lua, 7,353 frames).
projects/technos/shadow_force/rtl/video/sf_sprite.sv:100 MAME walks entry 511 DOWN TO 0 with first-write- wins, so the high-numbered entries are the ones drawn ON TOP; this prescan fills from entry 0 upward and stops, so what it throws away is exactly what should have been in front.
projects/technos/shadow_force/rtl/video/sf_sprite.sv:229 It put the whole sprite layer ONE PIXEL LEFT of the tilemaps: golden comparison (sim/golden, MAME state into this RTL) had 5,447 of 5,813 differing pixels at FPGA(x)==MAME(x+1), and 0 differing on seven frames after this line changed (DEBUG
projects/technos/shadow_force/rtl/video/sf_sprite.sv:263 The offline checks against MAME could not see it because they tested the arithmetic, not the FSM that feeds it.
projects/technos/shadow_force/rtl/video/sf_sprite.sv:495 n_act = 0 has two possible causes and they need opposite fixes: the buffer holds nothing (the copy or the CPU write path), or it holds data whose enable bit is not where this code looks (bit 2, MAME shadfrce.cpp:341 `source[0] & 0x0004`).
projects/technos/shadow_force/rtl/video/sf_sprite.sv:589 The "skip hole" fold and the +1 on X are MAME's and move here unchanged from S_T4/S_T5 -- see MAME_AUDIT.
projects/technos/shadow_force/rtl/video/sf_sprite.sv:593 It is the X position's high bit -- shadfrce.cpp:320 draws word 4 as | ---- ---- -pCc cccX | and takes the colour as `source[4] & 0x003e`, bits 5..1, with bit 0 MASKED OUT.
projects/technos/shadow_force/rtl/video/sf_tilemap.sv:15 MAME's layout is
projects/technos/shadow_force/rtl/video/sf_tilemap.sv:163 MAME's tilemaps draw into the SCREEN BITMAP, whose coordinates are raw scanlines: shadfrce.cpp:812 is set_raw(XTAL(28'000'000)/4, 448, 0, 320, 272, 8, 248) so the visible window is raw 8..247 and a tilemap with scrolly = 0 puts map row 0 at
projects/technos/shadow_force/rtl/video/sf_tilemap.sv:176 Measured 2026-09-04 against MAME's own PLAYER SELECT, from a screenshot taken while somebody played: the orange portrait frames -- tilemap -- sat at y 46/126/136 on the board against 38/118/129 in MAME, exactly +8 on all three, while their
projects/technos/shadow_force/rtl/video/sf_tilemap.sv:217 MAME says a bg0 line draws 3.4 distinct tiles of 21 and a bg1 line 9.5 -- so most of this layer's 126 words a line are the same six re-read.
projects/technos/shadow_force/rtl/video/sf_tilemap.sv:288 Within a word: [15:8] is the byte MAME places at plane 4-2f and [7:0] the byte at plane 5-2f, MSB first in x -- so bit (7-xs) of the low byte is w[k][7-xs] and the same bit of the high byte is w[k][8 + (7-xs)].
projects/technos/shadow_force/rtl/video/sf_tilemap.sv:388 "skip hole": MAME does `if (colour & 0x10) colour ^= 0x30`, which folds the used ranges around a gap in the palette.
projects/technos/shadow_force/rtl/video/sf_fgmap.sv:21 MAME's layout is
projects/technos/shadow_force/rtl/video/sf_fgmap.sv:123 MAME's tilemaps draw into the SCREEN BITMAP, whose coordinates are raw scanlines: shadfrce.cpp:812 is set_raw(XTAL(28'000'000)/4, 448, 0, 320, 272, 8, 248) so the visible window is raw 8..247 and a tilemap with scrolly = 0 puts map row 0 at
projects/technos/shadow_force/rtl/video/sf_fgmap.sv:136 Measured 2026-09-04 against MAME's own PLAYER SELECT, from a screenshot taken while somebody played: the orange portrait frames -- tilemap -- sat at y 46/126/136 on the board against 38/118/129 in MAME, exactly +8 on all three, while their
projects/technos/shadow_force/rtl/video/sf_fgmap.sv:168 These are keyed on the tile NUMBER and serve this one, because MAME says a line draws 1.6 distinct fg tiles of 40.
projects/technos/shadow_force/rtl/video/sf_fgmap.sv:240 That pairing comes straight from MAME's fg8x8x4_layout, whose y offsets are {0*8 ..
README.md:28 MAME 드라이버가 모든 클럭에 "verified on PCB" 를 달아 두었고 세 크리스털의 실측 주파수까지 기록해 두어서, 처음부터 타이밍 근거가 아주 튼튼한 기판이었습니다.
README.md:30 이 코어의 모든 비율(픽셀 클럭, 프레임 주기, YM 클럭, OKI 샘플레이트, 프레임당 OKI 샘플 수)은 MAME 와 0.0000 % 차이로 일치합니다.
README.md:38 | MAME 세트 | 공식 명칭 | 상태 |
README.md:60 직접 마련한 MAME ROM 세트 zip 을 SD 카드의 `/games/mame/` 에 넣습니다.
README.md:62 zip 은 MAME 세트 이름 그대로 두고, 압축을 풀지 않습니다.
README.md:114 MAME·FBNeo 와 같게 매 라인으로 바꿨고, 실기 로고가 MAME 와 픽셀 위치까지 같습니다.
README.md:115 16K 워드 4-way, 4워드 라인 캐시로 바꿔 실기 CPU 읽기가 프레임당 34k 에서 49~51k(MAME ~50k)로 돌아왔습니다.
README.md:116 **스프라이트 1픽셀 어긋남, 페이드 중 밝기 1단계.** MAME 상태를 RTL 에 넣는 시뮬레이션 대조에서 코요테·파란 스테이지 7프레임이 전부 76,800 픽셀 일치합니다(폭포 구간 510 프레임도 일치).
README.md:123 | 2026-09-01 | MAME 드라이버 전수 조사 후 RTL 착수. 같은 날 합성·fit 통과, 실기에서 68000 부팅 확인 |
README.md:136 인터럽트는 MAME 와 같은 비율(프레임당 레벨 2 17회 + vblank 1회)로 실기에서 측정됐습니다.
README.md:147 OKI 앞에 샘플 캐시를 두고, BGM(YM2151)과 효과음(M6295) 음량을 OSD 에서 각각 조절할 수 있습니다(기본값 MAME ×1).
README.md:151 워치독 주기는 두 레퍼런스 어디에도 없어서 MAME 를 178초 돌려 게임의 실제 워치독 갱신 간격(최악 25프레임)을 재고 그보다 넉넉하게 잡았습니다.
README.md:153 **화면 반전** — MAME 는 타일맵만 뒤집고 FBNeo 는 구현하지 않아 두 레퍼런스가 갈라집니다.
README.md:164 MAME 의 VRAM 덤프와 대조해 원인을 특정하고 고쳤습니다.
README.md:168 **타일맵 좌표계.** MAME 의 타일맵은 화면 행이 아니라 원래 라인 번호 기준이라, 첫 표시 라인이 맵의 8번째 행을 보여 줘야 합니다.
README.md:173 OKI 디코더 출력은 MAME 의 `okiadpcm.cpp` 와 16,478 샘플 중 16,477 개가 비트 단위로 일치합니다.
README.md:176 미국판은 MAME 의 `PORT_MODIFY("DSW2")` 대로 자체 DIP 기본값을 갖습니다.
README.md:179 MAME 와 FBNeo 가 여기서 갈라졌고, 실기에서 World 가 펀치+킥으로 빙의하는 것을 확인해 MAME 쪽을 따랐습니다.
README.md:186 먼저 **MAME 팀**에 깊이 감사드립니다.
README.md:186 이 코어는 MAME 의 `shadfrce` 드라이버와 그 주석에 남겨진 기판 정보 — 클럭마다 붙은 "verified on PCB", 크리스털 실측값, 메모리 맵, 그래픽 디코드, ROM 구성 — 위에서 시작했습니다.
README.md:192 https://github.com/mamedev/mame
README.md:209 특히 JT6295 는 MAME 와 비트 단위로 대조할 수 있을 만큼 정확했습니다.
README.md:213 참고한 MAME 소스
README.md:215 MAME 소스는 하드웨어 사실을 확인하는 참고 자료로 읽었고, **코드는 옮겨 오지 않았습니다.** RTL 주석에서 인용한 파일은 다음과 같습니다.
README.md:218 | MAME 파일 | 라이선스 | copyright-holders | 참고한 내용 |
README.md:220 | `src/mame/technos/shadfrce.cpp` | BSD-3-Clause | David Haywood | 메모리 맵, 클럭, 인터럽트, 화면 타이밍, 그래픽 디코드, 스프라이트 속성, ROM 구성, 입력 포트와 DIP 기본값, 사운드 라우팅 |
README.md:221 | `src/devices/sound/okim6295.cpp` | BSD-3-Clause | Mirko Buffoni, Aaron Giles | M6295 명령 처리와 출력 스케일 |
README.md:222 | `src/emu/drawgfx.cpp` | BSD-3-Clause | Nicola Salmoria, Aaron Giles | 스프라이트 우선순위 마스크(`prio_transpen`)의 동작 |
README.md:224 이 밖에 `src/devices/sound/okiadpcm.cpp` 는 시뮬레이션에서 OKI 디코더 출력을 비교하는 기준으로만 사용했습니다(배포 RTL 에는 포함되지 않음).
README.md:229 [FinalBurn Neo](https://github.com/finalburnneo/FBNeo) 의 `d_shadfrce.cpp` 를 **사실 교차확인용으로만** 읽었습니다(스프라이트 디코드, OKI 재시작 규칙, 버튼 구성, 화면 반전 처리 등).
README.md:252 **OKI M6295 재시작 규칙.** 이미 재생 중인 보이스에 들어온 시작 명령은 원래 칩에서 무시되어야 하지만(MAME·FBNeo 공통), 현재 코어는 재시작합니다.
README.md:258 **최종 믹싱 게인**은 MAME 의 `add_route` 값을 따른 것이며, 실제 기판의 합산 회로는 조사하지 않았습니다.
README.md:260 **화면 반전**은 기판 동작을 추정해 구현한 것으로, MAME 와 직접 대조할 수 없습니다.

Says it matches, follows or was checked against MAME — 4

projects/technos/shadow_force/rtl/sf_main.sv:231 EMULATION_DERIVED Matches MAME shadfrce.cpp:552-556 and FBNeo d_shadfrce.cpp:777-779 -- the two references agree, and the GAME needs it: the title's "FORCE" is in bg0 map rows 16-31 only and reaches the screen solely because the level-1 han
projects/technos/shadow_force/rtl/video/sf_sprite.sv:72 **MAME does the full walk every frame and never notices, because it has no scanline budget at all.** That is the one thing comparing against MAME cannot show, and it is why the algorithm was pixel-exact against MAME (MAME_AUDIT section 8)
projects/technos/shadow_force/rtl/video/sf_tilemap.sv:32 **This derivation was checked against MAME's own layout arrays** by decoding eight tiles both ways from the real ROM: 2048 pixels, 1568 of them non-zero, zero mismatches.
projects/technos/shadow_force/rtl/video/sf_fgmap.sv:36 It now matches MAME's own arrays on real ROM bytes: 384 pixels, 192 non-zero, 0 mismatches.

Says it was translated, ported or taken from MAME — 1

projects/technos/shadow_force/rtl/sf_main.sv:4 Every address here comes from docs/HARDWARE.md section 3, which is taken from MAME's shadfrce main_map.

Keeps a MAME approximation — 2

projects/technos/shadow_force/rtl/video/sf_crtc.sv:12 MAME calls the two totals "guessed".
projects/technos/shadow_force/rtl/video/sf_dbg.sv:86 Expected to stay 0 until the game arms it by writing 1D0006 bit 2, and MAME's own handling of this one is an approximation -- docs/MAME_NOTES.md section 1.1.

Shares text with the MAME driver without saying so — 13

projects/technos/shadow_force/rtl/video/sf_dbg.sv:537 #$0001` sets it -- which is MAME's "set/unset inside every trap — shares text with technos/shadfrce.cpp:511
projects/technos/shadow_force/rtl/video/sf_sprite.sv:29 sp16x16x5 = { 16,16, RGN_FRAC(1,5), 5, — shares text with technos/shadfrce.cpp:772
projects/technos/shadow_force/rtl/video/sf_sprite.sv:30 { RGN_FRAC(4,5), RGN_FRAC(3,5), RGN_FRAC(2,5), RGN_FRAC(1,5), — shares text with technos/shadfrce.cpp:775
projects/technos/shadow_force/rtl/video/sf_sprite.sv:32 { STEP8(0,1), STEP8(16*8,1) }, { STEP16(0,8) }, 16*16 } — shares text with technos/shadfrce.cpp:776
projects/technos/shadow_force/rtl/video/sf_tilemap.sv:17 bg16x16x6 = { 16,16, RGN_FRAC(1,3), 6, — shares text with technos/shadfrce.cpp:783
projects/technos/shadow_force/rtl/video/sf_tilemap.sv:18 { RGN_FRAC(0,3)+8, RGN_FRAC(0,3), RGN_FRAC(1,3)+8, RGN_FRAC(1,3), — shares text with technos/shadfrce.cpp:786
projects/technos/shadow_force/rtl/video/sf_tilemap.sv:19 RGN_FRAC(2,3)+8, RGN_FRAC(2,3) }, — shares text with technos/shadfrce.cpp:786
projects/technos/shadow_force/rtl/video/sf_tilemap.sv:20 { STEP8(0,1), STEP8(16*16,1) }, { STEP16(0,16) }, 2*16*16 } — shares text with technos/shadfrce.cpp:787
projects/technos/shadow_force/rtl/video/sf_tilemap.sv:165 set_raw(XTAL(28'000'000)/4, 448, 0, 320, 272, 8, 248) — shares text with technos/shadfrce.cpp:812
projects/technos/shadow_force/rtl/video/sf_fgmap.sv:23 fg8x8x4 = { 8,8, RGN_FRAC(1,1), 4, — shares text with technos/shadfrce.cpp:761
projects/technos/shadow_force/rtl/video/sf_fgmap.sv:25 { 1, 0, 8*8+1, 8*8+0, 16*8+1, 16*8+0, 24*8+1, 24*8+0 }, — shares text with technos/shadfrce.cpp:765
projects/technos/shadow_force/rtl/video/sf_fgmap.sv:26 { 0*8, 1*8, ... 7*8 }, 4*8*8 } — shares text with technos/shadfrce.cpp:766
projects/technos/shadow_force/rtl/video/sf_fgmap.sv:125 set_raw(XTAL(28'000'000)/4, 448, 0, 320, 272, 8, 248) — shares text with technos/shadfrce.cpp:812

SpaceInvaders_TestBuild (RodimusFVC)#
280-ZZZAP, Space Invaders / Space Invaders M, Astropal, Attack Force …
RodimusFVC/Arcade-SpaceInvaders_MiSTer @ cc1f12bb
MAME compared: midw8080/8080bw.cpp, midw8080/mw8080bw.cpp, zaccaria/zac1b1120.cpp + 12 related file(s)
Read: 17 HDL files, 6,867 lines (Quartus project)

RodimusFVC
repository only

Both

medium

67%

Statements: 23 toward hardware, 56 toward MAME

Cites hardware documentation that MAME's driver does not — 3

rtl/invaders_sound.sv:6 Circuit model after MAME invaders_discrete (Derrick Renaud) and the MAME SN76477 (Zsolt Vasvari), component values from the Midway schematic (tools/snd_consts.py).
rtl/mw8080_board.sv:31 variant (MRA index 1 byte 0): 0 invaders (MB14241 shifter on port 3), 1 no shifter (port 3 open), 2 invasion (port 3 = IN3), 3 spcewars (port 3 bit 4 = 1-bit tune speaker, no sound enable, no watchdog), 4 yosakdon (no shifter, own sound bit
rtl/zac_snd.sv:6 Circuit from the Zaccaria sound board schematic ("The Invaders"); SN76477 behaviour (rate formulas, thresholds, noise generator, output gain tables) follows MAME devices/sound/sn76477.cpp (Zsolt Vasvari, Derrick Renaud).

Ships hardware documentation files — 20

Cites MAME source — 55

Arcade-SpaceInvaders.sv:336 55-48 DIP byte 4 (MAME fake port lines)
Arcade-SpaceInvaders.sv:337 47-40 DIP byte 3 (MAME fake port lines)
Arcade-SpaceInvaders.sv:358 Each MRA descriptor turns a channel into a port field: linear between min / max (optionally reversed) or N positions through a MAME remap table.
Arcade-SpaceInvaders.sv:362 P1 vertical (spcenctr thrust: MAME default position 19 of 20)
rtl/cpu/jt680x/jt680x_alu.v:38 MC6800 / 6802 microcode (6800 cycle counts, MAME cycles_6800)
rtl/cpu/jt680x/jt680x_ctrl.v:59 MC6800 / 6802 microcode (6800 cycle counts, MAME cycles_6800)
rtl/cpu/jt680x/jt680x_regs.v:50 MC6800 / 6802 microcode (6800 cycle counts, MAME cycles_6800)
rtl/dsnd_engine.sv:206 MAME SN76477 / discrete 31-bit noise taps
rtl/eeprom_93c46.sv:6 Behaviour follows MAME eepromser.cpp / eeprom.cpp (eeprom_serial_93cxx_device): start bit, 2 opcode + 7 address bits, READ = dummy 0 then 8 data bits, WRITE / ERASE / ERAL / WRAL refused while locked (EWDS state at reset), WRAL ANDs into th
rtl/invaders_sound.sv:6 Circuit model after MAME invaders_discrete (Derrick Renaud) and the MAME SN76477 (Zsolt Vasvari), component values from the Midway schematic (tools/snd_consts.py).
rtl/mw8080_board.sv:9 Memory map, I/O map and shifter follow MAME mw8080bw.cpp / 8080bw.cpp.
rtl/mw8080_board.sv:30 Picture = MAME's 260 x 224: 4 black pixels, then the 256 bitmap pixels.
rtl/mw8080_board.sv:31 variant (MRA index 1 byte 0): 0 invaders (MB14241 shifter on port 3), 1 no shifter (port 3 open), 2 invasion (port 3 = IN3), 3 spcewars (port 3 bit 4 = 1-bit tune speaker, no sound enable, no watchdog), 4 yosakdon (no shifter, own sound bit
rtl/mw8080_board.sv:203 sflush: MC6800 (jt680x, 6800 microcode) at E = 1.5 MHz as MAME, cen = 4 x E = 6 MHz (39.936 MHz x 375 / 2496).
rtl/mw8080_board.sv:319 sflush IRQ: held from each interrupt point until the program reads 800B (MAME sflush_in0_r)
rtl/mw8080_board.sv:373 MRA index 0 is stored as loaded (up to 128K); every set reads its CPU windows at their own offsets, invmulti reads its bank through MAME init_invmulti's address / data scramble.
rtl/mw8080_board.sv:435 claybust light gun (MAME claybust_state): the trigger latches ((x >> 3) | (y << 5)) + 2 with y = V 0x20-0xFF, "gun on" holds for 250 ms, the trigger bit is a 2-frame pulse
rtl/mw8080_board.sv:482 upright: MAME polaris_port00_r
rtl/mw8080_board.sv:483 MAME indianbt_r: keyed on the IN's PC
rtl/mw8080_board.sv:485 upright: MAME schasercv_02_r
rtl/mw8080_board.sv:507 no shifter: open (MAME unmapped)
rtl/mw8080_board.sv:539 MAME keeps the bank across a watchdog reset
rtl/mw8080_board.sv:557 data in: INTA -> RST vector, INP -> ports, video RAM -> RAM register, work RAM, EEPROM, else ROM sflush (MAME sflush_map): 0000 work RAM, 4000 video RAM, 8008 paddle, 8009 shifter, 800A IN2 (bit 7 = MAME vpos bit 7: V >= 160 or VBLANK), 800
rtl/mw8080_board.sv:585 MAME unmapped
rtl/mw8080_board.sv:597 spcenctr (MAME spcenctr_state::io_w): A2-A0 0 /BRITE (D3), 1 sound P1 / P2 / P3 by A4 A3 (A6 low), 3 trench slope [A7 A6 A4 A3], 4 trench centre, 7 trench width
rtl/mw8080_board.sv:775 ---------------------------------------------------------------- family 3 colour (MAME 8080bw_v.cpp)
rtl/mw8080_board.sv:908 ---------------------------------------------------------------- sync / blank (MAME framing)
rtl/mw8080_board.sv:910 Registered outputs show one count after their edge: bitmap pixel d is on screen at hx = d + 5, so the visible window hx 1-260 = 4 black pixels + 256 bitmap pixels; HSYNC = MAME H 272-287, VSYNC = V 236-239.
rtl/mw8080_board.sv:933 ---------------------------------------------------------------- colour overlay (MAME layout rectangles)
rtl/mw8080_board.sv:969 polaris clouds: a 16 x 64 pattern drawn on background pixels where the PROM allows it, moving down one line every 4 frames (MAME screen_update_polaris / polaris_60hz_w).
rtl/mw8080_board.sv:988 phantom2 clouds (MAME screen_update_phantom2): row counter = frame start + picture row, 0xE0B-0xFFF, advanced 262 rows per frame from 0; a pixel x uses PROM byte {counter[7:1], ((x - 16) >> 4)}, bit ((x - 16) >> 1) & 7; pixels 0-15 still sh
rtl/mw8080_board.sv:991 MAME machine_start: 0, then wraps 0x1000 -> 0xE0B
rtl/mw8080_board.sv:1007 spcenctr trench (MAME spcenctr_state::screen_update): width / floor width start the frame at the width register and step +1 / -1 per pixel by bit 7 of a counter running from the centre register; at the end of a line the line's last byte (co
rtl/mw8080_board.sv:1063 pens -> RGB: RBG_3BIT (b0 R, b1 B, b2 G), RGB_3BIT (b0 R, b1 G, b2 B), rollingc 16 pens (b3 intensity, pens 5 / 6 pink / orange as MAME)
rtl/mw8080_board.sv:1069 MAME sflush_palette: pen 0 bright blue
rtl/mw8080_board.sv:1079 vortex: red / green from the next byte's bit 0, blue on source columns 4-7 of every 8 (MAME screen_update_vortex)
rtl/mw8080_board.sv:1085 spcenctr cabinet lamp / strobe reflected on the screen (MAME layout_spcenctr, additive): lamp = P3 D3 at (0.5, 0.125, 0.05); strobe = 9 Hz 555 lit 5 % of each period, enabled by P3 D2 at the start of the flash (0.7 grey)
rtl/mw8080_board.sv:1107 The sample-driven bootlegs' sound bits (MAME 8080bw_a.cpp handlers) remapped onto the board's inputs: p1 [0] saucer [1] missile [2] explosion [3] invader hit [4] bonus [5] sound on; p2 [3:0] fleet [4] saucer hit
rtl/mw8080_board.sv:1117 attackfc / claybust: no sound in MAME, silent
rtl/mw8080_board.sv:1122 family 3: MAME's sample handlers mapped onto the board's voices (invaders samples: 0 missile, 1 explosion, 2 invader hit, 3 saucer hit, 4-7 fleet, 8 bonus)
rtl/mw8080_board.sv:1140 shuttlei FE sound codes (MAME sh_port_2_w): 23 hit, 2B shoot, A3 UFO hit, AB death -> ~10 ms trigger pulses sh_pulse: [0] UFO hit, [1] invader hit, [2] explosion, [3] missile
rtl/zac1b1120_board.sv:6 Memory map, inputs and object placement follow MAME zaccaria/zac1b1120.cpp (Mike Coates); the S2636 PVI object logic follows MAME devices/machine/s2636.cpp (Vas Crabb).
rtl/zac1b1120_board.sv:27 A fractional enable gives the board's master clock (15.625 MHz, Dodgem 14.318 MHz) on average; one output pixel per master clock: 908 x 312 total, 720 x 256 visible (MAME set_raw).
rtl/zac1b1120_board.sv:52 colour overlay (MAME layout rectangles, raw x 0-719 / line 0-255)
rtl/zac1b1120_board.sv:129 MAME: sense = !VBLANK
rtl/zac1b1120_board.sv:233 S2650 I/O space: nothing mapped (MAME reads 0)
rtl/zac1b1120_board.sv:238 MAME: frame's object collisions
rtl/zac1b1120_board.sv:295 Per line (MAME s2636_device::render_next_line): count lines to each object, then show its 10 rows (scaled), then its duplicate VCB + 1 lines later at HCB.
rtl/zac1b1120_board.sv:296 Placement as MAME zac1b1120: x = 4 * HC - 22 master clocks, first line VC + 1 (the counters latch one line before the first visible line).
rtl/zac1b1120_board.sv:365 collisions, latched for the frame at the end of the visible area (MAME draw_sprites per frame)
rtl/zac_snd.sv:6 Circuit from the Zaccaria sound board schematic ("The Invaders"); SN76477 behaviour (rate formulas, thresholds, noise generator, output gain tables) follows MAME devices/sound/sn76477.cpp (Zsolt Vasvari, Derrick Renaud).
rtl/zac_snd.sv:256 noise generator (MAME generate_next_real_noise_bit), clocked at kr[KO_NOISE_FREQ]
rtl/zac_snd.sv:280 output (MAME: enabled and the VCO not saturated); mixer B (latch bit 7) = noise, else VCO
README.md:3 One core for the MAME `mw8080bw.cpp` / `8080bw.cpp` / `rotaryf.cpp` sets, rewritten in SystemVerilog.
README.md:4 MRAs are generated from MAME by `tools/gen_mra.py`.

Says it matches, follows or was checked against MAME — 1

rtl/mw8080_board.sv:723 Flip (cocktail / CRT Flip): the bitmap is scanned from the other corner so the picture matches MAME's flipped 260 x 224 image.

TaitoAir_1.0 (retrogarage)#
Top Landing
retrogarage/tas-mister @ e4669cc7
MAME compared: taito/taitoair.cpp + 11 related file(s)
Read: 23 HDL files, 12,375 lines (Quartus project)

retrogarage
repository only

Not enough evidence in the code

insufficient

22%

Statements: 7 toward MAME

Cites MAME source — 7

rtl/tas_flight_controls.sv:2 This module follows MAME's taitoio_yoke device for the counter format and digital dynamics, but calibrates physical travel from Top Landing's original 68000 program.
rtl/tas_flight_controls.sv:26 MAME's default frontend normalizes the physical axis after a 0.15 dead zone and reaches full output at 0.85 travel.
rtl/tas_flight_controls.sv:347 MAME absolute analog values override the keyboard-style fallback.
rtl/tas_flight_controls.sv:397 MAME's KEYDELTA(40) is an output-port delta (sensitivity is inverse-applied before the final read), so Buttons mode deliberately uses 40.
rtl/tas_video.sv:692 MAME's STEP4(0,1) plane layout numbers bits from the LSB, so screen-left starts at the low nibble of byte seven in the aligned DDR row.
rtl/tas_video.sv:889 The current device model lacks an equivalent window, which is why a smaller form of the leak is visible in MAME too.
rtl/tas_video.sv:1215 The PCB/MAME decoder takes red from the low nibble and green from bits 8:5.

taitol (decoryah)#
Cachat, Champion Wrestler, Cuby Bop, Evil Stone …
decoryah/Arcade-TaitoLSystem_MiSTer @ 365b39aa
MAME compared: taito/taito_l.cpp + 3 related file(s)
Read: 24 HDL files, 3,272 lines (Quartus project)

decoryah
repository only

Mostly MAME

medium

84%

Statements: 3 toward hardware, 68 toward MAME

Cites hardware documentation that MAME's driver does not — 1

rtl/taitol_board.sv:5 The DIP switches and the inputs are read through its two I/O ports: two 74LS157 multiplexers (DSWA|DSWB into port A, IN0|IN1 into port B) whose select line is bit 1 of the address of the last read of A000-A003 (MAME: extport_select_and_ym22

Says it was checked on “real hardware” — 1

rtl/taitol_board.sv:209 MAME (ymfm) into one speaker: SSG route 0.75 of (a + b + c) * 2/3 (a jt49 level is 64.25 ymfm steps: 42.8 per unit of psg_snd) and the left and right FM + ADPCM at 1.0 each, jt10's units being ymfm's (the same figures as the owner's MCatAdv

Notes where it differs from MAME — 1

rtl/taitol_video.sv:4 MAME does not model the blanking (its screen is "60 Hz, 320 x 256, visible 320 x 224 from line 16"), so the totals are a choice: 424 x 262 is exactly 60.000 Hz at this pixel clock.

Cites MAME source — 65

TaitoL.sv:5 Written for MiSTer from MAME's driver (src/mame/taito/taito_l.cpp, src/devices/machine/tc009xlvc.cpp).
TaitoL.sv:160 MAME's defaults until the MRA sends its own
TaitoL.sv:167 keyboard: 1/2 start, 5/6 coin, 9 service (MAME's defaults)
TaitoL.sv:192 Which bit of the board's input ports carries what is per game, and comes from MAME through the ROM image's configuration block (tools/inputmap.py); taitol_ctrl builds IN0..IN2 from these signals.
TaitoL.sv:201 In MAME the chip's X counter is the analog port AN0 = trackball Y (reversed) and its Y counter AN1 = trackball X, so the mouse's vertical movement (PS/2: up is positive) feeds X and its horizontal movement feeds Y. [17:16] inverts either if
TaitoL.sv:384 ROT90 / ROT270 sets (Play Girls, American Horseshoes, Fighting Hawk, Evil Stone ...: the ROM image carries MAME's rotation) are turned in a DDR3 frame buffer (Sorgelig's screen_rotate: it takes arcade_video's output; MAME's ROT270 = the pic
rtl/taitol_bg.sv:3 MAME (tc0090lvc_device::screen_update + tilemap_t::effective_rowscroll), single scroll value per layer: dx = scroll register (16 bit), with the global flip: ((dx & fffc) | ((dx - 3) & 3)) ^ f x scroll = KN + dx (mod 512)
rtl/taitol_bg.sv:13 A row of 4 bytes b0..b3 holds 8 pixels: pixels 0-3 from (b0, b1), 4-7 from (b2, b3), and pixel u of a half is {B1[4+u], B1[u], B0[4+u], B0[u]} (MAME's gfx_layout {8,12,0,4} / {3,2,1,0, 19..16}).
rtl/taitol_bm.sv:1 The chip's 8 bit bitmap mode (video register 4 [2:0] == 7): the screen is the bitmap RAM (512 bytes a row, 256 rows), each byte a palette index, and nothing else is drawn: no tiles, no text, no sprites (MAME: tc0090lvc_device::screen_update
rtl/taitol_board.sv:1 The board around the TC0090LVC: everything the chip maps into 8000-BFFF, per game family (MAME: taitol_1cpu_state and friends).
rtl/taitol_board.sv:5 The DIP switches and the inputs are read through its two I/O ports: two 74LS157 multiplexers (DSWA|DSWB into port A, IN0|IN1 into port B) whose select line is bit 1 of the address of the last read of A000-A003 (MAME: extport_select_and_ym22
rtl/taitol_board.sv:14 Puzznic's family (board 2 = the three bootlegs without the MCU, 1 = the original with it) is the same board with A800 read: watchdog (nothing), B801 read: the MCU control port, which MAME answers with a constant 1, BC00 write: ignored; an
rtl/taitol_board.sv:52 controls, active low (MAME's INPUT_PORTS bit order)
rtl/taitol_board.sv:171 FM and ADPCM come out left and right (snd_left / snd_right include the SSG, psg << 5, which is taken out again below); MAME's routes into one speaker: the SSG 0.75, the left and the right 1.0 each.
rtl/taitol_board.sv:202 jt03 sums the FM section and the SSG (psg << 5); on the board the two reach the amplifier through different resistors (MAME: SSG channels 0.20, FM 0.80).
rtl/taitol_board.sv:203 Measured against MAME's own output (Kuri Kinton music, Plotting: tools/audiocmp.py, docs/status.md): with the FM section at the core's gain the SSG wants 10.4 per raw unit, i.e. 3.125 per unit before it.
rtl/taitol_board.sv:209 MAME (ymfm) into one speaker: SSG route 0.75 of (a + b + c) * 2/3 (a jt49 level is 64.25 ymfm steps: 42.8 per unit of psg_snd) and the left and right FM + ADPCM at 1.0 each, jt10's units being ymfm's (the same figures as the owner's MCatAdv
rtl/taitol_cen.sv:3 The TC0090LVC runs from the board's 13.33056 MHz oscillator / 2 = 6.66528 MHz (MAME: "verified freq on pin122"), the 1-CPU boards' YM2203 from the same oscillator / 4 = 3.33264 MHz.
rtl/taitol_core.sv:157 jt03's mix is 10.5 dB (x3.33) below MAME's for the same register writes: measured in simulation on the real program (tools/audiocmp.py on 5 s of Plotting's coin sound and music: the energy ratio is the same -10 dB in every frequency band, S
rtl/taitol_ctrl.sv:1 Generic controls: builds the board's input ports IN0..IN2 from the player's controls using the per-game wiring in the ROM image's configuration block (tools/inputmap.py reads it from MAME).
rtl/taitol_ctrl.sv:8 A mapped bit reads the complement of its idle bit while its signal is pressed; an unmapped bit reads its idle bit (MAME gives bits without a declared field whatever its port default is: e.g. 0 on some of Evil Stone's).
rtl/taitol_i8255.sv:1 The Palamedes family's input chip, an 8255 (TMP8255AP-5; Cachat and the later games: an NEC D70155C, the same): mode 0 only, as MAME's i8255 does it for these boards (the three ports are IN0, IN1, IN2; the output callbacks are not connected
rtl/taitol_main.sv:1 The TC0090LVC's CPU half: a Z80 (tv80) with the chip's own registers and memory map, and the external bus for the board (MAME: tc0090lvc_device::cpu_map + taitol_state::common_banks_map).
rtl/taitol_main.sv:12 Three levels, fired at raster lines 120 (level 0), 0 (level 1) and 240 (level 2, vblank) when the level's enable bit is set (MAME does the same from a scanline timer; the real sources of 0 and 1 are unknown).
rtl/taitol_main.sv:15 As in MAME, nothing fires while the Z80 is not in IM 2 (Play Girls enables interrupts before it selects the mode).
rtl/taitol_main.sv:29 the program ROM holds bit-reversed bytes (plottinga: MAME's init_plottinga)
rtl/taitol_main.sv:127 MAME's "kludge to make plgirls boot": no interrupt while the Z80 is not in IM 2
rtl/taitol_mcu.sv:1 Puzznic's MC68705P3 and its interface to the main Z80, after MAME (src/devices/cpu/m6805/m68705.cpp: the P3 peripherals; src/mame/shared/taito68705.cpp: arkanoid_68705p3_device, the "Arkanoid MC68705P3 Interface").
rtl/taitol_spr.sv:3 125 entries of 8 bytes (MAME: tc0090lvc_device::draw_sprites):
rtl/taitol_spr.sv:9 MAME draws the entries in order, and a sprite pixel claims its screen pixel *whether or not it is visible* (the priority bitmap goes to 31, which every later sprite's mask rejects): the first sprite wins.
rtl/taitol_sub.sv:1 MAME: kurikint_2_map / evilston_2_map and the "audiocpu" of kurikint() / evilston().
rtl/taitol_sub.sv:9 The interrupt is MAME's irq0_line_hold at the start of vblank: held until acknowledged; the acknowledge cycle supplies FF (RST 38 / IM 1).
rtl/taitol_sub.sv:11 Evil Stone only (MAME: dpram.intl_callback -> the sound CPU's NMI): the MB8421's left interrupt.
rtl/taitol_syt.sv:1 Taito's sound communication chip, PC060HA (Champion Wrestler, Fighting Hawk) and TC0140SYT (Raimais): one behaviour, after MAME's src/mame/shared/taitosnd.cpp (tc0140syt_device).
rtl/taitol_tri.sv:2 MAME: fhawk_2_map / fhawk_3_map, champwr_2_map / champwr_3_map, raimais_2_map / raimais_3_map.
rtl/taitol_tri.sv:51 and its ADPCM-B, which reads the same ROM (MAME: no ADPCM-B region, so the ADPCM-A one)
rtl/taitol_tri.sv:232 MAME: entry 1 at machine reset (a reset by the comm chip leaves it)
rtl/taitol_tri.sv:287 the chip has taken `nib`; line up the next one (MAME: msm5205_vck)
rtl/taitol_tri.sv:326 MAME: the MSM5205 output is its 12 bit signal x 16, route 0.80, and the volume (data / 255); the board's sum is followed by the core's x3.33, so the signal x 16 x 0.8 / 3.33 = x 3.84; the first measurement against MAME's output found the vo
rtl/taitol_tri.sv:334 x2.25: measured +4.5 dB hot at x3.875 against MAME
rtl/taitol_tx.sv:1 The text layer of the TC0090LVC: a fixed 64 x 32 map of 8 x 8 tiles whose graphics are RAM characters: MAME decodes the whole 64 KB VRAM as 8x8 4bpp tiles, tile code N reading bytes N*32 ..
rtl/taitol_upd4701.sv:1 The NEC uPD4701A trackball counter as American Horseshoes wires it (MAME: src/devices/machine/upd4701.cpp, and horshoes_map in taito_l.cpp): the chip is read through the bus,
rtl/taitol_upd4701.sv:7 Movement arrives as signed deltas (the mouse; MAME adds the analog port once a frame).
rtl/taitol_video.sv:5 The raster line counter is MAME's bitmap line: 0..261, visible lines 16..239; the CPU's interrupt levels are tied to those numbers (taitol_main).
rtl/taitol_video.sv:141 palette entry: xBGRBBBBGGGGRRRR, 5 bits a channel with the low bits in bits 12..14 (MAME's xBGRBBBBGGGGRRRR_bit0)
rtl/taitol_vmem.sv:1 The TC0090LVC's video memories and the CPU's window onto them (MAME: tc0090lvc_device::vram_map).
rtl/taitol_vmem.sv:3 v_addr is the 20-bit address in the chip's VRAM space (the CPU's C000-FDFF window, bank-translated): 010000-01FFFF VRAM, 64 KB (writes below 014000 are ignored, as in MAME: the first tiles stay blank) 080000-080FFF palette RAM, 256 entrie
README.md:5 Thirty-five MAME sets of thirteen titles run: Plotting, Puzznic, Palamedes, Tube-It (with Cachat), Cuby Bop, Play Girls, Play Girls 2, American Horseshoes, Kuri
README.md:10 It is written for MiSTer from MAME's driver and device sources (`taito_l.cpp`, `tc009xlvc`, `taitosnd`, `taitoio`, the MC68705 and MB8421 models), which are als
README.md:23 **In simulation** (Verilator, the real programs through the SDRAM controller and a behavioural chip), against MAME 0.289's dumps and snapshots: Plotting, Puzzni
README.md:48 Tube-It is the title of the Cachat group (MAME's parent, Cachat (Japan), is its alternative).
README.md:89 `tools/make_mra.py` writes these MRAs (`HOMEBREW` table) and `tools/mra_verify.py` checks that each builds the program and graphics regions MAME loads from the
README.md:98 | Vertical games | Rotated, As is | the vertical sets are turned by the scaler (`screen_rotate`, ROT270 counter-clockwise as in MAME); hidden with Direct Video,
README.md:106 Controls: joystick, Button 1, Button 2, Start, Coin (the games' own button use differs; the wiring of each set comes from MAME's driver).
README.md:108 The Service Mode DIP switch (OSD, then Reset) opens a game's test mode (Cuby Bop, a location test, has none: its screen stays black in MAME too).
README.md:116 The vertical sets (Play Girls, Play Girls 2, LA Girl, American Horseshoes, Evil Stone, Fighting Hawk) come out as MAME's ROT270 says: the picture's bottom on th
README.md:129 The second and third Z80s have their own ROMs and the boards' communication chips (MB8421 dual-port RAM, PC060HA, TC0040IOC, TC0510NIO, TC0220IOC) are modelled
README.md:143 `tools/make_mra.py` writes the MRAs from MAME's definitions.
README.md:147 Needs Verilator 5 (the OSS CAD Suite, in WSL) and Python 3, and for the comparison MAME 0.289 (the executable in `tools/mame/` and its source tree in `ref/mame`
README.md:151 # whole-machine runs with MAME's default DIP switches, compared with MAME's dumps (tools/cmprtl.py) tools/mamedump.py <set> ...
README.md:152 # MAME's reference dumps and snapshots with the same scripted inputs tools/dipcheck.py <set> ...
README.md:153 # Service Mode / Flip Screen / Cabinet on, RTL against MAME tools/ymcmp.py mame.log rtl.log # the sound CPU's writes to the sound chip, MAME against the RTL (t
README.md:179 MAME's source, which this work follows, is BSD-3-Clause (`tc009xlvc` is LGPL-2.1+); no MAME code is copied into the RTL.
README.md:184 **MAME** (the taito_l driver by Olivier Galibert and contributors, BSD-3-Clause; `tc009xlvc` by Angelo Salese, LGPL-2.1+; `taitosnd` by Philip Bennett; `taito68
README.md:192 **Guru** for the measured Puzznic PCB timings quoted in MAME's source, on which the raster totals rest.

Says it matches, follows or was checked against MAME — 2

README.md:26 The picture is pixel-identical to MAME wherever the machine states agree.
README.md:128 Output levels follow MAME's mix: the FM with one gain, the SSG and the ADPCM with their own (matched against MAME's recorded output).

Says it was translated, ported or taken from MAME — 1

README.md:159 `docs/status.md` has every result and the command behind it; `docs/hardware.md` is the hardware map taken from MAME's source.

TMNT (furrtek)#
M.I.A.: Missing in Action, Teenage Mutant Ninja Turtles
furrtek/Arcade-TMNT_MiSTer @ 4f6f86e3
MAME compared: konami/tmnt.cpp + 5 related file(s)
Read: 68 HDL files, 9,530 lines (Quartus project)

furrtek
repository only

Both

low

33%

Statements: 4 toward hardware, 5 toward MAME

Cites hardware documentation that MAME's driver does not — 4

rtl/k051937.v:272 ROOT SHEET 3
rtl/k051937.v:347 ROOT SHEET 7
rtl/k051937.v:405 ROOT SHEET 8
rtl/k051960.v:360 ROOT SHEET 2

Cites MAME source — 2

TMNT.sv:288 The schematics have a missing page but MAME saved the day.
rtl/audio.v:380 Theme rom data YM floating point format convertion to integer, see logic in k053260 or MAME's ymfm.h comments TODO: Simplify

Says it matches, follows or was checked against MAME — 1

TMNT.sv:106 RTS at 114A pops wrong return address 100010 (from 60AFC, which matches MAME) instead of 10A2 Correct address 10A2 is pushed to 60AFC by the BSR at 109E, so 60AFC must be corrupt by the called routine.

Shares text with the MAME driver without saying so — 2

TMNT.sv:540 0 1 2 3 4 5 6 — shares text with konami/k051960.cpp:85
rtl/k052109.v:281 REG1C00_D[1:0]: Regs RWE0 RWE1 VCS0 VCS1 RWE2 00 A~B 6~7 8~9 Reset state 01 8~9 4~5 6~7 10 6~7 2~3 4~5 11 4~5 0~1 2~3 TMNT setting — shares text with konami/k052109.cpp:84

Universal_TestBuild (RodimusFVC)#
American Soccer, Cosmic Avenger, Mr. Do! vs. Unicorns, Dorodon …
RodimusFVC/Arcade-Universal_MiSTer @ 3c3f24fb
MAME compared: universal/docastle.cpp, universal/ladybug.cpp, universal/mrdo.cpp, universal/sraider.cpp + 6 related file(s)
Read: 29 HDL files, 7,823 lines (Quartus project)

RodimusFVC
repository only

Both

medium

55%

Statements: 10 toward hardware, 61 toward MAME, 2 not counted

Cites hardware documentation that MAME's driver does not — 6

rtl/docastle/docastle_board.sv:19 idsoccer (MAME idsoccer_state): main 0000-3FFF / 6000-9FFF ROM, 4000-57FF RAM, 5800-59FF sprites, A000 latch, B000/B800 video RAM, B400/BC00 colour RAM, C000 ADPCM status / control, E000 sub NMI; sub as docastle; sprite layout with tile bit
rtl/ladybug/ladybug_video_timing.sv:314 From the schematics, it is the same as /VBL (just buffered).
rtl/ladybug/sraider_sub.sv:6 From MAME sraider.cpp (Frank Palazzolo) cpu2_map / cpu2_io_map: 0000-5FFF ROM (H6, J6, L6) 6000-63FF RAM, mirrored at 6400 (2x 2114) 8000 read sound latch low (P6) A000 read sound latch high (R6) C000 read 556 outputs on D1-D0
rtl/ladybug/ttl_393.sv:3 TTL 74LS393 - Dual 4-Bit Binary Counter
rtl/mrdo/mrdo_board.sv:18 prot_mode: 0 mrdo (PAL with feedback: Darren Olafson's state model, clocked by fg RAM writes), 1 Taito PAL (MAME mrdot_state jedutil equations), 2 none (mrlo).
rtl/mrdo/mrdo_board.sv:227 MAME mrdot_state::protection_w (jedutil equations): i9 = D0 ...

Cites hardware references or measurements that MAME's driver also gives — 2

rtl/docastle/docastle_board.sv:11 map_mode 0 (MAME docastle_state): main 0000-7FFF ROM, 8000-97FF RAM, 9800-99FF sprites, A000-A7FF latch, B000/B800 video RAM, B400/BC00 colour RAM, E000 sub NMI; sub 0000-3FFF ROM, 8000-87FF RAM, A000-A7FF latch, C000-C007(+C080) inputs / — also in MAME: 97FF universal/docastle.cpp:9, 99FF universal/docastle.cpp:10, 87FF universal/docastle.cpp:24
rtl/docastle/docastle_board.sv:15 map_mode 1 (MAME dorunrun_state): main 0000-1FFF ROM, 2000-37FF RAM, 3800-39FF sprites, 4000-9FFF ROM, A000-A7FF latch, B000 video RAM, B400 colour RAM, B800 sub NMI; sub 0000-3FFF ROM, 8000-87FF RAM, A000/A400/A800/AC00 SN76489A, C000 in — also in MAME: 37FF universal/docastle.cpp:75, 39FF universal/docastle.cpp:76, 87FF universal/docastle.cpp:24

Ships hardware documentation files — 4

Cites MAME source — 56

Arcade-Universal.sv:261 MAME PORT_IMPULSE(2): a coin press is latched, then held for exactly two frames from the next vblank
Arcade-Universal.sv:282 Rack Test cheat: held (MAME DIP with a key), or flipped on each press (MAME PORT_TOGGLE)
rtl/docastle/docastle_board.sv:6 From MAME docastle.cpp (Brad Oliver) and the Mr.
rtl/docastle/docastle_board.sv:11 map_mode 0 (MAME docastle_state): main 0000-7FFF ROM, 8000-97FF RAM, 9800-99FF sprites, A000-A7FF latch, B000/B800 video RAM, B400/BC00 colour RAM, E000 sub NMI; sub 0000-3FFF ROM, 8000-87FF RAM, A000-A7FF latch, C000-C007(+C080) inputs /
rtl/docastle/docastle_board.sv:15 map_mode 1 (MAME dorunrun_state): main 0000-1FFF ROM, 2000-37FF RAM, 3800-39FF sprites, 4000-9FFF ROM, A000-A7FF latch, B000 video RAM, B400 colour RAM, B800 sub NMI; sub 0000-3FFF ROM, 8000-87FF RAM, A000/A400/A800/AC00 SN76489A, C000 in
rtl/docastle/docastle_board.sv:19 idsoccer (MAME idsoccer_state): main 0000-3FFF / 6000-9FFF ROM, 4000-57FF RAM, 5800-59FF sprites, A000 latch, B000/B800 video RAM, B400/BC00 colour RAM, C000 ADPCM status / control, E000 sub NMI; sub as docastle; sprite layout with tile bit
rtl/docastle/docastle_board.sv:25 Main <-> sub: one bidirectional latch; a main access holds main WAIT until the sub CPU accesses the latch (MAME main_from_sub_r / main_to_sub_w).
rtl/docastle/docastle_board.sv:27 IRQs (as MAME): main IRQ = CRTC VSYNC; sub IRQ on HSYNC when MA6 rises, held until acknowledged; sub WAIT = any SN76489A not READY.
rtl/docastle/docastle_board.sv:29 The sprite CPU (pass-through to the CF37201 sprite chip) is not modelled: as in MAME, the main CPU's sprite writes go straight to sprite RAM.
rtl/docastle/docastle_board.sv:225 unconnected port inputs read 0 (MAME default)
rtl/docastle/docastle_board.sv:259 ------------------------------------------------------------------ Indoor Soccer ADPCM (MAME idsoccer_state) 384 kHz / 48 = 8 kHz VCK = 19.656 MHz / 2457.
rtl/docastle/docastle_board.sv:299 decoder runs after the callback, as in MAME
rtl/docastle/docastle_board.sv:310 mix: 4x SN76489A at 0.25, MSM5205 at 0.40 (MAME routes) SN: jt89 channel +/-255 x4 = MAME 0x7fff/4 x 0.25 per channel; MSM: MAME 2047/4096 x 0.40 of full scale = x3.2
rtl/docastle/docastle_board.sv:329 main IRQ follows VSYNC (MAME set_inputline); sub IRQ on HSYNC when MA6 rises (MAME docastle_tint)
rtl/docastle/docastle_board.sv:391 MAME visible area: x 8-247 of that window, y 0-191.
rtl/docastle/docastle_board.sv:416 logical (MAME) coordinates of the pixel at stage 0
rtl/docastle/docastle_board.sv:419 tilemap flip (MAME flip_screen_set: X and Y)
rtl/docastle/docastle_board.sv:421 MAME set_scrolldy(-32)
rtl/docastle/docastle_board.sv:425 ------------------------------------------------------------------ sprite line buffer (built one line ahead) MAME draw_sprites: offs 0x1FC down to 0; the first sprite to cover a pixel wins (priority 31); pens 8-14 draw, pen 15 draws nothing
rtl/docastle/docastle_board.sv:452 logical (MAME) line being built
rtl/docastle/docastle_board.sv:463 MAME sprite position (non-Indoor-Soccer layout), flip screen applied as in draw_sprites
rtl/docastle/docastle_board.sv:573 MAME set_transmask: layer-0 pens drawn over sprites
rtl/docastle/docastle_board.sv:576 MAME visarea 8..247 of the 256-pixel window (horizontal)
rtl/docastle/docastle_board.sv:599 MAME palette: R 0x23/0x4b/0x91 on bits 5-7, G on bits 2-4, B 0x52/0xad on bits 0-1
rtl/ladybug/ladybug_cpu_unit.sv:11 Dorodon: opcode fetches (M1) go through the bp3/bp4 PROM pair (MAME init_dorodon); every other set fetches opcodes undecoded.
rtl/ladybug/ladybug_cpu_unit.sv:14 Dynamite, MAME sraider.cpp cpu1_map): 8000-9FFF I/O (x0-x3 IN0/IN1/DSW0/DSW1, x5 PAL protection 0x3E, x6/x7 sound latches low/high), no flip latch / sound chips at A000-CFFF, IRQ on vblank held until acknowledged (MAME irq0_line_hold), no c
rtl/ladybug/ladybug_cpu_unit.sv:41 NMI (MAME coin 1)
rtl/ladybug/ladybug_cpu_unit.sv:42 IRQ (MAME coin 2)
rtl/ladybug/ladybug_cpu_unit.sv:186 PAL K2: must read X011111X (MAME protection_r)
rtl/ladybug/ladybug_machine.sv:7 Input ports follow MAME ladybug.cpp: IN0 9000, IN1 9001 (bits 7-5 from the video timing), DSW0 9002, DSW1 9003, IN2 E000 (bits 1-0); coin 1 -> NMI chute, coin 2 -> IRQ chute.
rtl/ladybug/ladybug_machine.sv:11 Dynamite, MAME sraider.cpp): same video, main CPU I/O at 8000, a second Z80 with five SN76489, and the palette PROM wired to the DACs differently (mrsdyna_palette).
rtl/ladybug/ladybug_machine.sv:23 MAME ladybug_p2_control_r: upright cabinet reads P1 controls for P2
rtl/ladybug/ladybug_machine.sv:114 E000-E003 read bit pairs {extra[7-n], extra[3-n]}; only E000 carries inputs (MAME IN2 bits 1-0)
rtl/ladybug/ladybug_machine.sv:227 8203 palette PROM to DAC wiring (MAME mrsdyna_palette): {220 ohm, 470 ohm} = R {D0, D3}, G {D4, D5}, B {D6, D7}
rtl/ladybug/ladybug_sound_unit.sv:52 Equal mix (MAME routes both at 0.5)
rtl/ladybug/sraider_overlay.sv:6 From MAME sraider.cpp / zerohour_stars.cpp (Frank Palazzolo): - stars: 17-bit LFSR stepped once per slot of a 256x256 raster starting at (offset & 0xFF, offset >> 8); a star where (state & 0xFF) == 0xFF and the feedback bit is 0, on pixels
rtl/ladybug/sraider_overlay.sv:16 Output is a colour code (so the CRT Flip frame buffer stays 8 bits wide): {2'b00, r[1:0], g[1:0], b[1:0]} Lady Bug pixel (2-bit DAC levels) {2'b01, 3'b000, r, g, b} grid (full on / off per gun) {2'b10, 1'b0, colour[4:0]} star
rtl/ladybug/sraider_overlay.sv:21 The overlay runs one pixel behind the Lady Bug output and tracks MAME screen coordinates (visible x 8-247, y 32-223) of the pixel it holds.
rtl/ladybug/sraider_overlay.sv:81 MAME: set_speed((data & 7) - 1, 7)
rtl/ladybug/sraider_overlay.sv:97 MAME set_enable: rising edge resets the offset
rtl/ladybug/sraider_sub.sv:6 From MAME sraider.cpp (Frank Palazzolo) cpu2_map / cpu2_io_map: 0000-5FFF ROM (H6, J6, L6) 6000-63FF RAM, mirrored at 6400 (2x 2114) 8000 read sound latch low (P6) A000 read sound latch high (R6) C000 read 556 outputs on D1-D0
rtl/ladybug/sraider_sub.sv:93 556 dual timer on D1-D0: MAME returns random bits; a free-running LFSR stands in
rtl/mrdo/mrdo_board.sv:6 From MAME mrdo.cpp / mrdo_v.cpp (Nicola Salmoria), with the U001 PAL behaviour from Darren Olafson's Mr.
rtl/mrdo/mrdo_board.sv:14 A000-A003 P1, P2, DSW1, DSW2 E000-EFFF RAM F000-F7FF bg scroll x F800-FFFF bg scroll y IRQ at vblank, held until acknowledged (MAME irq0_line_hold).
rtl/mrdo/mrdo_board.sv:18 prot_mode: 0 mrdo (PAL with feedback: Darren Olafson's state model, clocked by fg RAM writes), 1 Taito PAL (MAME mrdot_state jedutil equations), 2 none (mrlo).
rtl/mrdo/mrdo_board.sv:59 MAME proms region 0x00-0x7F
rtl/mrdo/mrdo_board.sv:213 Do!, as MAME)
rtl/mrdo/mrdo_board.sv:227 MAME mrdot_state::protection_w (jedutil equations): i9 = D0 ...
rtl/mrdo/mrdo_board.sv:237 MAME machine_reset: outputs high
rtl/mrdo/mrdo_board.sv:464 ------------------------------------------------------------------ palette (MAME palette_init)
rtl/universal_board.sv:6 Variant 0: Lady Bug board (MAME ladybug.cpp: ladybug, snapjack, cavenger, dorodon) Variant 1: Space Raider (8203 board + star board, MAME sraider.cpp sraider) Variant 2: Mrs.
rtl/universal_board.sv:8 Dynamite (8203 board, MAME sraider.cpp mrsdyna) Variant 3: Mr.
rtl/universal_board.sv:17 ioctl index 0 (MRA), images stored as dumped, MAME region order: 0x00000 - 0x05FFF maincpu 0x08000 - 0x09FFF gfx1 (chars: 0x8000 plane 0 = low byte, 0x9000 plane 1 = high byte) 0x0A000 - 0x0BFFF gfx2 (sprites: 0xA000 low byte, 0xB000
rtl/universal_board.sv:42 [0] P2 controls follow P1 in upright (MAME ladybug_p2_control_r)
rtl/universal_board.sv:313 2-bit DAC per gun, MAME ladybug_palette weights (470 / 220 ohm, 470 ohm pull-down)
rtl/universal_board.sv:365 colour code -> RGB (see sraider_overlay.sv); star colours from MAME sraider_palette

Shares text with the MAME driver without saying so — 5

rtl/docastle/docastle_board.sv:11 map_mode 0 (MAME docastle_state): main 0000-7FFF ROM, 8000-97FF RAM, 9800-99FF sprites, — shares text with universal/docastle.cpp:8
rtl/docastle/docastle_board.sv:13 sub 0000-3FFF ROM, 8000-87FF RAM, A000-A7FF latch, C000-C007(+C080) inputs / flip, — shares text with universal/docastle.cpp:23
rtl/docastle/docastle_board.sv:15 map_mode 1 (MAME dorunrun_state): main 0000-1FFF ROM, 2000-37FF RAM, 3800-39FF sprites, — shares text with universal/docastle.cpp:74
rtl/docastle/docastle_board.sv:17 sub 0000-3FFF ROM, 8000-87FF RAM, A000/A400/A800/AC00 SN76489A, C000 inputs / flip, — shares text with universal/docastle.cpp:23
rtl/ladybug/ladybug_machine.sv:23 MAME ladybug_p2_control_r: upright cabinet reads P1 controls for P2 — shares text with universal/ladybug.cpp:275

Coin-Op Collection also publishes open-source components (x6502, x65c02, x68705, x76489, x8910, each with datasheets and a test bench). Which of its closed cores use them is not published, so they are not attached to any core above.

How the needle is placed

Each comment (or readme sentence) is classified by the rules below. Within a module a rule adds its points × log2(1 + times it fired), so repetition counts for less than variety. A module's position is (hardware points + 1) / (all points + 2), from MAME at 0 to hardware at 100. A core's needle is the size-weighted average over modules that contain statements; the readme and the shipped documentation files each count like a quarter of the code. Modules with no statements are left out and reported as coverage. See RULES.md for the reasoning behind each rule.

Not counted: ROM file names (MiSTer uses MAME's ROM sets by design) and memory addresses (a correct core must share them with any correct emulator). Quoted comments remain under their authors' licenses; this analysis is published under CC BY 4.0.

Statement	Points	Side	Includes
Cites hardware documentation that MAME's driver does not	+0.5	hardware	schematic sheet, part number, chip location, dumped PAL, decap — only when MAME's driver for the game does not already give it
Cites hardware references or measurements that MAME's driver also gives	0	neither	not counted: copying them from MAME would look the same
Says it was checked against the original PCB	+2	hardware	explicitly the original board, PCB or arcade hardware
Reports a measurement taken on the original PCB	+3	hardware	states a value; measurements of the MiSTer itself (e.g. SignalTap) do not count
Says it was checked on “real hardware”	+1	hardware	may mean the MiSTer board itself rather than the original PCB, so it counts less
Ships hardware documentation files	+2	hardware	schematic sheets, schematic PDFs, PAL equations in the core's own folder
Notes where it differs from MAME	+3	hardware	a stated difference implies another reference
Cites MAME source	−0.5	MAME	a MAME file, function or line
Says it matches, follows or was checked against MAME	−2	MAME	includes “ground truth: MAME”
Says it was translated, ported or taken from MAME	−3	MAME
Keeps a MAME approximation	−1	MAME	where MAME itself notes a guess or stand-in
Shares text with the MAME driver without saying so	−1	MAME	a 6-word run in a comment

FPGA cores: verified against hardware or MAME?

How the needle is placed