madsim

The MAD-65 simulator · version 1.0.5

madsim is a whole MAD-65 in a program: both 65C02 processors, the video circuit, the two SN76489 PSGs and the YM2413 FM chip, and both joystick ports. It runs the real firmware ROMs and real cartridge images, so software that runs here runs on the hardware.

The simulation is paced to the console's true frame rate of 60.317 Hz, independent of your monitor. That is the point of the machine, so it is not something the simulator was going to fake.

Running it

1. Unpack the ZIP anywhere.
2. Run madsim.exe from the unpacked folder.

No installer, no dependencies, nothing written outside the folder. It finds the roms\ folder next to itself and loads the firmware automatically. With no cartridge it boots the console's diagnostic demo — if that runs, your setup is correct.

To play a game, drop its cartridge image next to madsim.exe as cart.bin, or point at it: madsim.exe --cart mygame.bin. The C.E.T.A.S. download comes with madsim already bundled, so it needs none of this.

Controls

MAD-65 was designed to be seen on a CRT — that is what the F8 filters are for. On a flat panel they are the closest you will get to the picture as it was intended.

Gamepads

A USB gamepad is picked up automatically — no configuration and no flags. The first pad connected drives joystick port 1, a second one port 2. Unplug a pad and its port falls back to the keyboard; both sources work at once, and hot-plugging works while the simulator is running.

The D-pad and the left stick steer. The two vertically opposed face buttons are fire, the two horizontally opposed ones are second fire — each line is wired to both buttons of its pair, so it does not matter which one your thumb finds. The right stick is deliberately ignored.

A PS1/PS2-to-USB adapter has to be in analogue mode (press ANALOG, LED on). In digital mode the pad reports its right stick as the face buttons and its D-pad as the left stick, and nothing downstream can tell those apart from real presses — so the right stick appears to fire.

A pad with motors also rumbles when a game asks it to: LED7 of the CPU's diagnostic LEDs shakes the pad on port 1, LED6 the pad on port 2. The real MAD-65 has no rumble — on the console those bits just light LEDs — so this is a simulator-only extra.

The utilization meter

F3 shows how much of each frame CPU1 and the GPU actually used, and how much of that went on wait states. For anyone writing a game it is the quickest answer to the only question that matters on this machine: is there still room in the frame?

Its FPS row reads emulated/shown: how many frames the machine ran per second, and how many of them reached your screen. It should say 60/60. A lower second figure means the PC cannot put frames on the screen fast enough — the game still runs at full speed, but the picture drops frames. Start madsim from a command prompt and look at the DISPLAY line it prints: “Microsoft Basic Render Driver” means Windows is drawing in software, and the graphics driver is missing. madsim.exe --bench 600 measures what a frame costs on your PC; a Pentium J3710 needs about 6 ms of the 16.6 ms a frame lasts, even with both processors flat out.

What it does not do

Video is a snapshot taken once per frame at VSYNC — which is exactly what a frame is, and right for writing games. madsim does not model what the video circuit is doing mid-scanline, so raster tricks inside a frame need the gate-level Verilator simulator that lives in the MAD-65 sources instead.

The frame model is per frame: CPU1 and the GPU each run a whole frame, then the buffers swap. That is faithful rather than approximate, because the two processors only ever talk through the ping-pong shared RAM, and that swaps at the frame boundary anyway — which is also why madsim can run them on two threads at once and get exactly the same result.

Release notes

Short notes. The full changelog is in the download.