MAME Netlists: Modeling and Validating Analog Arcade Circuits

MAME’s netlist subsystem can represent analog and mixed-signal hardware as connected circuit models rather than as a collection of prerecorded effects. That distinction is useful when an arcade board generated sound through discrete components, op-amps, logic, or a mixture of analog stages and digital control. A netlist makes those relationships explicit, but it does not automatically make a reconstruction accurate: component values, topology, device models, timing assumptions, and the source evidence all matter.

Treat a netlist as a testable hardware hypothesis. Preserve the schematic or board observations that justify each component and connection, keep solver choices traceable, and compare the model’s output under a repeatable input sequence. A plausible waveform is not proof that the modeled circuit matches the original board.

A circuit model is not a sample library

MAME’s netlist code is a mixed-signal circuit simulation library used within the emulator. The project describes it as an advanced implementation of the existing discrete sound subsystem. It allows modeled components to connect through nets, and it distinguishes analog and logic devices. Where a direct analog-to-logic or logic-to-analog connection is needed, the system inserts proxy behavior rather than treating both domains as one undifferentiated signal.

This differs from sound-chip emulation and sample playback. A PSG or FM chip has its own digital architecture and register behavior; a netlist models electrical behavior of a circuit around or instead of such a device. A sample can reproduce one recording, but it cannot independently express how a control voltage, resistor, capacitor, logic transition, or oscillator changes the output. Conversely, a netlist is not a recording of a cabinet speaker, room, amplifier aging, or every tolerance in a production run unless those elements are modeled from evidence.

The first design question is therefore not “which solver setting sounds best?” It is “what is the circuit boundary?” Decide which board signals enter the model, which parts belong to a separate emulated device, and what output the circuit is expected to produce. Record those boundaries in the driver notes so another maintainer can tell whether an upstream sound chip is being emulated directly, feeding resistor values into a netlist, or feeding an analog input.

Translate source evidence into connected nets

Start from a schematic, service manual, measured board, or a clearly identified combination of evidence. Record component designators, values, pin mappings, supply rails, and any uncertain or substituted parts. A schematic exported from EDA software can be a useful starting point, but exported node names still need to be checked against the board and the model’s declared devices. A cleanly parsed schematic can still describe the wrong board revision.

MAME netlist definitions use named components and explicit connections. The current upstream congo_bongo.cpp example shows component macros such as RES, CAP, and NET_C, and it separates circuit blocks into named netlist definitions. A resistor or capacitor name in that source is a model identifier, not a promise that the original component has no tolerance or parasitic effects. Use aliases and subcircuits to make repeated stages readable, but preserve a path from every modeled value back to evidence.

Keep logic and analog interfaces deliberate. If a digital sound device drives an analog mixing network, document the amplitude and impedance assumptions at that boundary. If a logic net drives an analog input, verify polarity, voltage range, and transition timing. An automatically inserted proxy enables connections between domains; it does not establish that the chosen electrical level or loading is historically correct.

When the source is incomplete, label uncertainty instead of inventing precision. A generic transistor or op-amp model may be a practical approximation, but the model should name its limitations. Upstream netlist documentation and FAQ examples discuss cases where simplified models and solver-friendly assumptions are intentional. The correct engineering response is to measure whether that approximation materially changes the behavior being preserved, not to describe it as a verified component model.

What the solver is solving

At a high level, the analog portion is constrained by current balance at circuit nets. MAME’s netlist documentation expresses this as a conductance-matrix problem over unknown net voltages and injected currents, then describes an iterative solution. Two-terminal models can express a branch using an effective resistance, voltage source, and current source. Capacitors, inductors, diodes, and active devices need their own model behavior; they are not all interchangeable ideal resistors.

The iterative solver makes convergence a practical concern. Strong feedback, a wide range of impedances, an unrealistic device model, or a missing reference path can make a circuit difficult to solve or can produce behavior that changes under parameter adjustments. A simulation error is not fixed by increasing iteration counts blindly. First verify connectivity, rails, component units, model parameters, and any unintentionally floating nets. Then establish a stable baseline before exploring solver controls.

An upstream example demonstrates solver parameters in context:

PARAM(Solver.RELTOL, 1e-2)
PARAM(Solver.VNTOL, 1e-6)
PARAM(Solver.NR_LOOPS, 30)
SOLVER(Solver, 48000)

These lines come from a specific MAME example and are not a universal preset. Relative tolerance, voltage tolerance, iteration limit, and the solver rate trade work and convergence behavior differently for different circuits. The example also contains build-branch-specific dynamic-timestep settings. Copying those values into another model without comparing output and runtime is not a validation strategy.

Optimize topology only when the assumptions hold

Large analog graphs can cost significant CPU time. The netlist FAQ describes frontiers as a way to partition a circuit into smaller solver regions, and says they work best at a low-impedance to high-impedance transition. It also states the key assumption: there should be little or no feedback from the output side to the input side of the frontier. That makes a frontier a circuit-topology decision, not a generic switch to enable in every design.

Before adding one, draw the signal path and check for feedback, shared nodes, and loading effects across the proposed boundary. Compare the partitioned result with the unpartitioned baseline using identical inputs. If output changes, investigate whether the frontier assumption is violated before changing tolerances. If the circuit contains meaningful feedback across the boundary, the partition may be physically or numerically inappropriate even if it runs faster.

Keep performance evidence separate from fidelity evidence. Record wall-clock emulation speed, solver warnings, and output comparisons for the same system, MAME build, state, and inputs. A model that only sustains a fraction of real-time speed may be unsuitable for normal play even if its offline waveform looks plausible. On the other hand, a fast model that omits a board stage is not faithful because it reaches full speed.

Validate the model in layers

Use a staged review rather than relying on one listening test:

Confirm that component values, pins, supplies, and signal names match the cited board revision or schematic.
Check that the netlist parses and that the expected devices and outputs are present.
Run the same known input sequence from a clean machine start and capture the output using the same MAME build and audio path.
Compare stable characteristics such as oscillation frequency, envelope timing, relative level, and behavior when a control changes. Keep the capture settings and analysis method with the test evidence.
Change one uncertain component or solver setting at a time, then compare against both the baseline and available hardware measurements.
Repeat the test after save/load or a fresh launch only if those states are part of the intended use case.

Do not claim sample-for-sample equivalence to a real board unless the capture path, clocking, board revision, component tolerances, and test conditions support that claim. A frequency-domain match may be useful evidence for a tone or oscillator while leaving attack timing, distortion, noise, or control response wrong. Record what was measured and what remains unknown.

Keep model provenance with the emulation

Store source schematics, board photographs, component substitutions, measurement notes, and test captures as separate evidence from the executable ROM set. Identify the driver, MAME revision, netlist source file, solver parameters, input script or control sequence, and expected output features. If a value changes after a hardware measurement, record why instead of leaving only the latest constant in source control.

The netlist is valuable because it exposes a circuit explanation that can be inspected and revised. That is also its limitation: it preserves the model and evidence you actually encoded, not the original circuit by magic. A production-quality contribution is one another maintainer can audit, run, compare, and improve without confusing a convenient approximation with a verified board fact.

Related:

Sources: