Burger Time (arcade) — ROM port

Data East's Burger Time (1982), translated into JavaScript instruction for instruction from the arcade ROMs, both the main program and the sound program, and checked against the real ROMs frame by frame, which in turn are checked against MAME. Play it at https://plicerin.github.io/burgertime-rom-port/.

How it works

The board has two 6502s. The main CPU is Data East's CPU-7, whose opcode fetches are bit-swapped (76543210 → 65342710) right after a memory write when the opcode's address matches xxxx xxx1 xxxx x1xx. The sound CPU drives two AY-3-8910s. Both programs are translated:

• src/btimeMainRecomp.mjs, src/btimeSoundRecomp.mjs: the programs, one case per instruction with its cycle count, grouped into small block functions. Main CPU instructions are keyed by address and whether the CPU-7 fetches them unscrambled (marked *), since the same address can decode two ways. Generated by tools/recompile.mjs from what the oracle executed (tools/trace.mjs, tools/trace-sound.mjs), a static walk of the branches it didn't take, and the programs' jump tables.
• src/btimeMainData.mjs, src/btimeSoundData.mjs: the ROM bytes the programs read as data: everything no executed instruction occupies, plus every byte an indexed ROM read can reach. The game does read its own code as data; the coin handler checks the credit limit with CMP $D064,Y and whatever Y the interrupted code left. src/btimeGfxData.mjs: the character, sprite and background ROMs.
• src/btimeBus.mjs, src/btimeVideo.mjs: the main board's memory map (with the X/Y-swapped video RAM port) and the video: 32×32 characters, 8 sprites kept in video RAM, the background layer, the RAM palette. src/btimeSound.mjs: the sound board's map and timing (the command latch IRQ, the NMI from the screen's 8-line counter).
• src/ay8910.mjs, src/btimeMixer.mjs: the AY-3-8910 (ported from MAME) and the sound board's mixing network: five channels mixed directly, AY #2 channel A through its op-amp band pass, the output high passes.
• src/cpu6502.mjs: 6502 registers, arithmetic and interrupt timing (shared with the oracle).
• src/btimeMachine.mjs: the translated programs on the boards, a frame per runFrame(). src/btimePlayer.mjs: canvas, keyboard, gamepad, touch and the sound worklet (src/btimeSound.worklet.js). index.html: the site, with the game embedded. game.html: the game on its own.
• img/: the poster, screens, cast plates and icons, rendered from the translated game by tools/gen-images.mjs.

The ROMs are not included.

Run locally

python -m http.server 5196 --bind 127.0.0.1

Then open http://127.0.0.1:5196/. ES modules need a server; opening the file directly won't work.

Controls: 5 or C inserts a coin, 1 and 2 start a one or two player game (Enter does coin and start), arrows or WASD move and climb, Space, Z or X throws pepper, P pauses, M mutes. Gamepads work too (Start = coin and start, Back = pause), and phones get touch buttons. The factory DIP settings are used: 3 lives, bonus at 20000, 4 enemies, end-of-level pepper.

Verify

Needs MAME's btime set unpacked in rom/ (git-ignored, never committed; mame -verifyroms btime should report it good) and, for the MAME checks, MAME 0.287 with btime.zip in its rompath.

node tools/compare-mame.mjs <dump.bin> [inputs.txt]       # oracle vs MAME: RAM, palette, video and colour RAM every frame
node tools/compare-snaps.mjs <snapdir> <frames> [inputs]  # oracle renders vs MAME screenshots, pixel for pixel
node tools/compare-mame-sound.mjs <sound.bin> [inputs]    # sound CPU vs MAME: sound RAM and every AY write
node tools/trace.mjs && node tools/trace-sound.mjs        # what the oracle executes over the test scenarios
node tools/recompile.mjs main && node tools/recompile.mjs sound
node tools/verify-recomp.mjs 20000 <scenarios>            # main translation vs the oracle, every frame
node tools/verify-sound.mjs 20000 <scenarios>             # sound translation vs the oracle, every frame
node tools/render-audio.mjs <frames> <out.wav> [inputs]   # the port's sound, for tools/compare-wav.mjs against MAME's -wavwrite

MAME recordings come from tools/record-mame.mjs, which runs MAME headless with tools/mame/dump.lua (frame dumps, screenshots, sound CPU state and AY writes, and the same input script and RAM pokes).

What has been checked:

• Oracle vs MAME. 3,000 attract frames and 6,000 played frames have identical main RAM, palette, video and colour RAM at every frame. Renders match MAME screenshots pixel for pixel. Over 3,000 played frames the sound CPU makes the same 15,970 AY writes in the same order as MAME's. Getting there took modelling MAME's 6502 interrupt sampling (inputs are sampled on every bus cycle except the opcode fetch and a taken same-page branch's last; CLI/SEI/PLP change I after the poll) and an 8-cycle reset.
• Translations vs the oracle. verify-recomp runs the real ROMs on the interpreter next to the translation and requires identical RAM, video, palette, sound commands (with their cycles), registers, cycle counts and next instruction after every frame. The test scenarios (tools/scenarios.mjs) are seeded random play plus RAM pokes that start at later levels, make a stage clear on the next piece that lands on a plate, give a score that makes the high score table, play two players, or keep lives from running out. The pokes go to both machines, and to MAME as well. On seeds the traces never saw, 18 scenarios × 20,000 frames of the main program and 7 × 20,000 of the sound program show no differences.
• Sound vs MAME. Rendered through the mixer, a 26-second played session has the same loudness envelope as MAME's -wavwrite output. The magnitude spectrum of every second correlates at 0.993 or better, and the energy per band agrees within 6% (MAME is uniformly about 4% louder).

What isn't exact: MAME's CPUs stop mid-instruction at a frame boundary, so the tools compare MAME's state against the oracle's with the boundary instruction's writes undone. The sound CPU still sits a few cycles away from MAME's at some boundaries. That shows up in 20 of 3,000 frame snapshots: a delay loop's counter one step apart, a subroutine return on the other side of the boundary, or an AY write counted in the neighbouring frame. The AY write stream itself is identical.

Credits

Burger Time is © 1982 Data East Corporation. This is an unofficial preservation project, not affiliated with Data East or its successors. Hardware details follow MAME's btime driver (Zsolt Vasvari, Couriersud, Nicola Salmoria), deco_cpu7, m6502 and ay8910 devices.