Baby Pac-Man PinMAME

01 Project Overview

Baby Pac-Man (Bally, 1982) is a hybrid arcade/pinball machine — the upper half is a video game screen running the Pac-Man maze, and the lower half is a real pinball playfield with flippers, drop targets, saucers, and solenoids. This project replaces the original MPU board with a modern PC running the game ROM under PinMAME, while driving the original physical hardware through two USB boards.

Two Roles, Two Boards

Both boards connect via USB and are accessed through a single Windows DLL, pacdrive32.dll, which is loaded at runtime by the custom pacdrive.c hardware abstraction layer added to PinMAME.

02 System Architecture

The full signal path from ROM execution to physical hardware, running at 60 Hz:

Inputs (reverse direction)

03 Key Source Files

04 Startup & Configuration

rem babypac.bat
call setvol 80
pinmame babypac -ultimateio -joystick -dmd_only -scanlines -skip_gameinfo

Initialization Sequence

On exit, UnloadPacDrive() calls InitOutputs() (turns everything off), frees memory, then FreeLibrary(hio).

05 I-PAC Ultimate I/O Board

The I-PAC Ultimate I/O handles all 96 lamp outputs and accepts up to 48 switch inputs. It appears as a standard USB HID device — no special Windows driver needed.

How the LED command works

Every frame, UpdateOutputs() advances a per-lamp brightness (0–255) toward its ROM target, then pushes all 96 outputs to the board in one bulk USB transfer. Driving real brightness — not just on/off — is what produces the incandescent-style fade. See Incandescent Lamp Fade for the full model and the user-tunable controls.

// pacdrive.c: UpdateOutputs() — lamp section (Approach C)
for (int i = 0; i < 96; i++) {
    int target = Outputs[i] ? 255 : 0;   // ROM on / off
    // ease LedIntensity[i] toward target (exp / s / lin),
    // then map through the perceptual gamma table:
    pushBuf[i] = GammaLUT[LedIntensity[i]];
}
Pac64SetLEDIntensities(hw_id_ultimateio, pushBuf);  // all 96 in one call, ~30 Hz

The board's 256-level PWM per channel is what makes the fade possible. (Earlier builds sent pure on/off group states with Pac64SetLEDStates; the current build sends per-LED brightness with Pac64SetLEDIntensities.) The hw_id_ultimateio constant is 0 — the first device enumerated by the DLL.

Input side

The I-PAC's 48 inputs are wired to every physical switch on the cabinet and playfield. Using WinIPAC V2, each input is assigned a keyboard key or gamepad button. When a switch closes, the I-PAC sends that key to Windows, which PinMAME reads and routes to the switch matrix. See the Switch & Input Mapping section for the full table.

06 PAC-Drive Board

The PAC-Drive is a simple 16-channel output board used to fire the pinball solenoids — flippers, saucers, drop target reset, and the outhole kicker. Each channel is either on or off; the entire state is sent as a single 16-bit word.

How the solenoid command works

// pacdrive.c: UpdateOutputs() — solenoid section
unsigned short binary_short = 0;
binary_short |= Outputs[outputNum + 0]  << 0;   // bit 0  → PAC-Drive channel 1
// ... through ...
binary_short |= Outputs[outputNum + 15] << 15;  // bit 15 → PAC-Drive channel 16

if (OutputsSolenoidPrevious != binary_short) {
    OutputsSolenoidPrevious = binary_short;
    PacSetLEDStates(hw_id_pacdrive, binary_short);
}

The hw_id_pacdrive constant is 1 — it's the second device enumerated by the DLL after the Ultimate I/O.

Board Layout — Screw Terminals

The PAC-Drive uses screw terminals along both edges. Output channels are numbered 1–16. There is also a GND terminal. The board is powered entirely by USB — no external power connector for logic. When connecting an external high-voltage supply through the driver PCB, the external supply's ground must be tied back to the USB ground (see Build & Wiring Guide).

Ordering the Correct Version

Ultimarc sells several PAC-Drive variants. For this project you need the "ID #1 Special" version (also described as "ID #1 – outputs default OFF"). This version:

• Has its hardware board ID burned as 1, so the DLL assigns it hw_id = 1
• Defaults all outputs to OFF at power-up — essential for safety, so solenoids don't energize before PinMAME initializes

The standard PAC-Drive (ID #0) would conflict with the I-PAC Ultimate I/O, which also uses hw_id = 0. Do not substitute the standard version.

Wiring PAC-Drive to the Custom Driver PCB

Run individual signal wires from the PAC-Drive's numbered screw terminals to the JP1–JP4 header pins on the BabyPacDriver-v4 PCB. Also bring over a GND connection to JP9 pins 1 & 2, and a 5V source to JP9 pin 3 (see JP9 Power Connector table in Custom Driver PCB).

07 Custom Solenoid Driver PCB

The files in Solenoid Driver board schematics/ contain the design for a custom PCB (Eagle schematic + board layout + BOM) that sits between the PAC-Drive's 5V logic outputs and Baby Pac-Man's original high-voltage solenoid coils.

This PCB provides:

• Voltage level translation from PAC-Drive 5V logic to pinball coil voltage (24–50V)
• Per-channel flyback diode protection to absorb solenoid back-EMF
• Isolation between the USB logic side and the high-voltage coil side
• 12 driver channels (Q1–Q12), 9 of which are currently assigned to solenoids

Signal Path Through the PCB

Signals travel left to right through the board:

MOSFET Pinout — IRLZ34N (TO-220)

Each driver channel uses an IRLZ34N logic-level N-channel MOSFET in TO-220 package. With the flat face toward you and leads pointing down:

  Flat face →  ┌──────────────┐
               │  IRLZ34N     │
               │              │
               └──┬───┬───┬──┘
                  │   │   │
                Pin1 Pin2 Pin3
                Gate Drain Source
                      (tab)
                 ↑         ↑
               Left       Right

Power Connector — JP9

JP9 is a 3-pin screw terminal that supplies 5 V logic power to the inverter ICs (U1, U2). It must be connected before any signals are driven.

5V Power Source for JP9

JP9 VCC can be supplied from any of the following. All options require the 5V source's ground to be part of the common ground bus:

• USB 5V tap — a USB cable or hub port provides clean regulated 5V, shares USB ground automatically
• 5V from the same supply powering the PC — a 5V header or USB output from the PC's power distribution
• Separate 5V regulated supply — tie its GND to the common bus

The 5V does not need to come from the PAC-Drive itself — the PAC-Drive's screw terminals expose output channels and GND, but those output lines are open-drain (not a 5V source output). Use any 5V supply that shares the common ground.

Bench Testing the Driver Board

Use this procedure to verify each MOSFET channel before connecting any real solenoids. You need: a 5V supply, a multimeter, a 470 Ω resistor, and an LED.

PAC-Drive Signal Wiring — JP1–JP4

Run individual signal wires from the PAC-Drive's output connector to the 3-pin headers on the driver board. The table below shows the complete path from each header pin through to the solenoid output terminal. The Solenoid Assignment Table cross-references these hardware outputs to the software output numbers and game mechanisms.

08 pacdrive32.dll API

The DLL is Ultimarc's closed-source Windows library. It is loaded dynamically at startup using LoadLibrary(), and seven function pointers are resolved by name (pacdrive.h):

// pacdrive.h — function pointer typedefs
typedef int  (WINAPI *PACINITIALIZE)   (void);
typedef void (WINAPI *PACSHUTDOWN)     (void);
typedef int  (WINAPI *PAC64SETLEDSTATES) (int id, int group, char data);
typedef int  (WINAPI *PAC64SETLEDSTATE)  (int id, int group, int port, int state);
typedef int  (WINAPI *PACSETLEDSTATES)  (int id, short data);
typedef int  (WINAPI *PAC64SETLEDFADETIME)    (int id, int fadeTime);
typedef int  (WINAPI *PAC64SETLEDINTENSITIES) (int id, unsigned char *data);

Device IDs are positional: hw_id_ultimateio = 0 (first device), hw_id_pacdrive = 1 (second device). If you add a second PAC-Drive board, it would be id=2.

09 Output Array Layout

All output state is held in a single flat array Outputs[112] (1 byte per output, value 0 or 1). UpdateOutputs() reads this array and issues USB commands to the appropriate board.

10 Lamp Matrix Flow

Physical hardware

Baby Pac-Man uses 30 SCR (Silicon Controlled Rectifier) drivers labeled Q01–Q30 on the A3 Driver Board (Q10 and Q21 are unpopulated). Each SCR fires on one of two AC phases:

• Phase A — positive half of the AC cycle (Strobe 1 in the emulator)
• Phase B — negative half of the AC cycle (Strobe 2 in the emulator)

This gives 60 possible lamp positions (30 SCRs × 2 phases), of which 56 are wired. The remaining 4 positions (Q10A, Q10B, Q21A, Q21B) are available for custom additions.

Emulator representation

// core.c: update_hW() — lamp section
int outputNum = 1;
for (int i = 0; i < 8; i++) {
    update_hw_byte(outputNum, coreGlobals.lampMatrix[i]);
    outputNum += 8;   // advances 8 outputs per byte
}

// update_hw_byte() — unpacks one byte into 8 output slots
void update_hw_byte(int outputStart, unsigned char value) {
    PacDriveSetOutput(outputStart + 0, value >> 0 & 0x01);
    // ... through ...
    PacDriveSetOutput(outputStart + 7, value >> 7 & 0x01);
}

11 Solenoid Flow

From ROM to coil

12 Switch & Input Mapping

There are two independent layers. Getting a switch into the game requires both to be configured correctly.

Layer 1 — Physical pin → key (WinIPAC V2)

Each of the I-PAC's 48 physical input pins is assigned a keyboard key or gamepad button using the WinIPAC V2 utility. This is stored in the I-PAC's own flash memory. PinMAME never sees the physical wiring — it only sees keystrokes.

Layer 2 — Key → switch matrix position (PinMAME)

PinMAME maps each key to a position in coreGlobals.swMatrix[], which the emulated 6800 CPU reads when it scans the switch matrix. There are two sub-layers:

a) Hardcoded defaults — byvidpin.h:53

These are compiled in and apply on a fresh install. They cover the main cabinet controls:

b) User-configured mappings — cfg/babypac.cfg

All playfield switches (drop targets, saucers, rollovers, out hole, tilt bob, etc.) are configured through PinMAME's in-game Tab menu → "Input (this game)". Those assignments are stored in the binary cfg/babypac.cfg file. The file format is MAME's proprietary MAMECFG binary format and isn't human-readable, but the Tab menu provides a full visual editor.

13 Flipper Wiring & Signal Path

Flippers have a special path that bypasses the normal switch matrix and directly populates coreGlobals.solenoids2.

Signal flow

Game definition: FLIP_SWNO(0, 1)

From byvidgames.c:16: INITGAMEVP(babypac, ..., FLIP_SWNO(0,1), ...)

The macro FLIP_SWNO(l, r) encodes which playfield switch numbers the game ROM reads for flipper feedback:

• Left flipper (l=0): Switch number 0 = no playfield switch. The solenoid fires via solenoids2 only — the ROM does not get switch feedback for the left flipper.
• Right flipper (r=1): Switch number 1. core_setSw(1, ...) is called when Right Shift is pressed, so the ROM's switch scan does see the right flipper.

14 Full Lamp Reference

All 56 active lamps, verified against the official Bally A3 Driver Board schematics and lamp chart. This is the Version 2 mapping — see the corrections section below for errors found in the original mapping document.

Architecture

The lamp matrix uses 30 SCR (Silicon Controlled Rectifier) drivers labeled Q01–Q30 on the A3 Driver Board. Q10 and Q21 are unpopulated. Each SCR controls two lamps via AC phase multiplexing:

30 SCRs × 2 phases = 60 possible positions. 56 are wired; 4 positions (Q10A, Q10B, Q21A, Q21B) are unused and available for custom modifications.

Complete Mapping by SCR Position

This is the primary wiring reference — use this when tracing wires from the A3 board to the playfield.

I-PAC Ultimate I/O Pin Assignments

Physical connector pin → lamp mapping for the I-PAC Ultimate I/O board, as wired on this build. Strobe 1 (pins 1–32) and Strobe 2 (pins 33–65) are the two output connector groups.

Organized by Function

Same data, grouped by lamp purpose — useful for understanding game logic and testing lamp groups.

Technical Hardware Details

Wiring Notes

• Each lamp connects to one SCR driver through the phase control circuit
• Phase A lamps light during the positive half of the AC cycle
• Phase B lamps light during the negative half of the AC cycle
• The PinMAME emulator maps Phase A → Strobe 1 (lampMatrix[0..3]) and Phase B → Strobe 2 (lampMatrix[4..7])
• Unused positions Q10 and Q21 (both phases) are available for custom lamp additions
• Enable hardware output with the -ultimateio flag — 96 LED outputs cover all 30 SCRs × 2 phases

Corrections from the Original Mapping Document

The original BabyPacman-LampMapping.txt (v1) contained several errors, corrected in v2 against the official Bally schematics:

Verification Status

This mapping is authoritative and suitable for production hardware builds.

15 Solenoid Assignment Table

Software assignments defined in src/wpc/core.c:1733–1747 inside update_hW(). The PAC-Drive output number and driver board columns show the physical hardware path — see Custom Driver PCB for full wiring details.

16 Switch Matrix Quick Reference

Column 0 (swMatrix[0]) is the "cabinet" column — special switches handled directly by the SWITCH_UPDATE function. Columns 1+ are the playfield matrix scanned by the CPU.

17 How to Modify Assignments

18 Build & Wiring Guide

This section describes how to assemble the complete hardware system from scratch. It is intended for others who want to replicate this build on a real Baby Pac-Man cabinet.

Parts Required

Common Ground — Critical Wiring Requirement

All grounds in the system must be tied to a single common ground bus. Without this, solenoids may not fire, signals will be unreliable, and you risk damaging the hardware.

Step-by-Step Wiring Sequence

Flipper Coil Requirements

Because the PAC-Drive is strictly on/off (no PWM), flipper coils must be the original-style dual-winding type with a mechanical End-of-Stroke (EOS) switch:

• The coil has a power winding (low resistance, high current) and a hold winding (high resistance, low current)
• The EOS switch is wired in series with the power winding. When the flipper reaches full stroke, the EOS switch opens, removing the power winding from the circuit
• Only the hold winding remains energized — at lower current that won't overheat the coil
• This is the design Bally used originally. No software changes are needed

19 Troubleshooting

Lamps and solenoids are both completely dead

Flippers don't fire

• Open WinIPAC V2 and confirm the I-PAC input terminals for the left and right flipper buttons are assigned to Left Shift and Right Shift respectively. This is the most common cause — if the keys are unmapped or mapped to something else, PinMAME never sees the button press and the PAC-Drive outputs never fire.
• Verify the flipper coil power windings are connected to PAC-Drive terminals 1 (left) and 2 (right) via the driver board. In this build, flippers are driven through the PAC-Drive — not directly wired as in the original Bally machine.
• Note: the original Baby Pac-Man A3 driver board used a direct-wired circuit (button → K1 relay → coil power winding) with no MPU solenoid driver in the flipper path. This build replaces that with PAC-Drive outputs 97/98. If you wire the coils directly instead, outputs 97/98 become irrelevant for coil firing but the I-PAC key mapping is still needed for game logic.

Lamps work but solenoids don't fire

• Check that PAC-Drive terminal 1 is wired to driver board JP1 pin 1 (and so on for all channels)
• Verify common ground — Meanwell GND tied to PAC-Drive GND and driver board JP9 GND
• Enable the solenoid debug printf by uncommenting it in pacdrive.c:188. If you see Setting Solenoid HwID: 1 to value X in the console, the software side is working and the problem is hardware
• Run the driver board bench test (Stage 4: LED dummy load) to isolate whether a specific MOSFET channel is switching
• Verify hw_id_pacdrive = 1 in pacdrive.c. If it's 0, solenoid commands are being sent to the I-PAC instead of the PAC-Drive

Solenoids fire but lamps don't work

• Enable lamp debug printf in pacdrive.c:156. You should see Setting LED HwID: 0 Group: X to value Y changing on each frame
• Verify hw_id_ultimateio = 0 in pacdrive.c
• Check that -ultimateio flag is present in babypac.bat

PacInitialize() returns 0

• Both boards missing or not enumerated yet — ensure both are physically connected
• pacdrive32.dll missing or wrong version — must be in the same directory as pinmame.exe
• Wrong PAC-Drive version — must be "ID #1 Special", not the standard version

A specific solenoid fires on the wrong game event

The solenoid-to-bit mapping is defined in src/wpc/core.c:1733 inside update_hW(). Each PacDriveSetOutput(N, ...) call maps a specific bit of allSol to a PAC-Drive channel. See the Solenoid Assignment Table for the full mapping. Edit the relevant line in core.c and rebuild.

A lamp pin appears dead (always 0)

If a pin reads 0 no matter what the game does, check whether it is one of the five structurally dead pins: 16, 32, 48, 64, or 65. These are permanently 0 due to code-level filtering — they cannot be activated without modifying byVP_lampStrobe() and update_hW() in core.c. See the pin table in Full Lamp Reference for details on which real lamps those numbers were mistakenly associated with.

Enabling debug output

Two printf statements in pacdrive.c are commented out in normal builds to avoid console spam. Uncomment them to trace hardware commands in real time:

Rebuild after uncommenting. Commands only print when the state actually changes, so a solenoid that fires and releases will generate exactly two lines.

20 K1 Flipper Enable Relay

What K1 is

The original Baby Pac-Man machine has a relay on the A3 driver board called K1 — Flipper Enable. In the Bally self-test numbering it is solenoid #08 (continuous solenoid). The relay coil is powered from a dedicated supply rail labeled "FLIPPER RELAY +43" (J3 pin 8 on power supply schematic W-1284), distinct from the general solenoid bus at J3 pin 12 ("SOLENOID BUS +43"). The relay's normally-open contacts are wired in series with the +43V line feeding both flipper coils. When the ROM de-energizes K1, +43V is cut to the flippers even if the flipper buttons are held — this is how the machine disables the flippers during the video-game half of the game and during attract mode.

How K1 maps to software

In byvidpin.c, PIA 1 port B carries the continuous solenoids (K1–K4) as bits 6–9 of coreGlobals.solenoids. K1 lands at allSol bit 7. In core.c, there is already commented-out code at line 1740 that previously attempted to route K1 to PAC-Drive output 100:

// PacDriveSetOutput(100, allSol >>  7 & 0x01); // Flipper enable relay

Output 100 was later assigned to Left Maze Saucer. The K1 line has since been moved to output 106 (PAC-Drive terminal 10) and is active in this build.

The problem in this build

Software side implemented (2026-07): core.c now drives PacDriveSetOutput(106, allSol >> 7 & 0x01), so PAC-Drive terminal 10 tracks the K1 enable signal every VBLANK. The physical relay is not yet wired — until it is, that signal has no effect and the flippers still fire on any button press regardless of game phase (they are driven directly by PacDriveSetOutput(97/98, ...) from button state, bypassing the ROM gate). Wire the relay per Option 1 below to make K1 physically cut flipper power during the video-game half and attract mode.

Options for controlling flipper enable

Option 1 — Hardware K1 relay (full original behavior)

Wire a real relay (or the original K1 relay if salvaged) to PAC-Drive terminal 10, with its normally-open contacts in series with the +43V supply to both flipper coils. Then enable the software output:

Step 1 — Drive the K1 output in src/wpc/core.c — already done in this build (in update_hW(), right after the flipper outputs):

PacDriveSetOutput(106, allSol >>  7 & 0x01); // K1 Flipper Enable Relay

Step 2 — Hardware wiring:

• PAC-Drive terminal 10 → driver board JP4 pin 1 (signal input)
• Driver board JP4 output terminal → relay coil (+)
• Relay coil (−) → common ground
• Relay normally-open contact 1 → FLIPPER RELAY +43V supply
• Relay normally-open contact 2 → both flipper coil high-power winding supply wires
• Add a flyback diode across the relay coil (cathode to +, anode to −)

With this wired, when K1 is energized (ROM playing pinball phase), +43V reaches the flippers. When K1 is de-energized (video game or attract), the relay opens and no amount of button pressing will fire the coils.

Note on relay selection: The relay coil must be compatible with the driver board's MOSFET output (12V or 24V coil recommended, depending on your supply). The original Bally K1 relay ran on +43V — if you use the original relay, feed the FLIPPER RELAY +43V rail to the coil side as well, not through the MOSFET output. In that case wire the MOSFET output to a low-voltage relay that in turn switches the +43V to the coil.

Option 2 — Software gate (no extra hardware)

Keep K1 unwired, but add a software check in core.c that suppresses flipper output when K1 is not active. Replace lines 1733–1734 in update_hW():

// Before (current code):
PacDriveSetOutput(97, allSol >> 46 & 0x01); // left flipper
PacDriveSetOutput(98, allSol >> 44 & 0x01); // right flipper

// After (with software gate):
if (allSol >> 7 & 0x01) {
    PacDriveSetOutput(97, allSol >> 46 & 0x01);
    PacDriveSetOutput(98, allSol >> 44 & 0x01);
} else {
    PacDriveSetOutput(97, 0);
    PacDriveSetOutput(98, 0);
}

This respects the ROM's K1 enable signal in software without requiring any additional hardware. The coils simply do not receive drive current when the ROM has K1 off. Rebuild and test after this change.

Option 3 — Live with it (current approach)

Do nothing. K1 remains unwired, the software output remains commented out, and the flippers fire freely whenever the buttons are pressed. This is the current state of the build as of 2026-05-29. Because the ball is always in the out-hole during the video-game segment, this has no practical effect on gameplay.

21 Flipper Power PWM Adapter (optional / experimental — not used in the final build)

The PAC-Drive and the custom driver board are on/off only — there is no PWM, so flipper strength cannot be tuned in software. With the dual-winding EOS coils correctly wired the flippers are safe, but they can still feel too strong because the power winding fires at full 43 V during the stroke. This optional add-on inserts a small microcontroller between the driver board's logic output and the flipper MOSFET gates to PWM the gate drive, giving an adjustable fire strength via a single potentiometer — with no changes to PinMAME or the driver board's design.

How it works (and why it suits the EOS coil)

The AQ-25-500/34-4500 coil shares the MOSFET drain between both windings: the power winding runs through the EOS switch, the hold winding connects directly. The adapter exploits this:

• During the stroke (EOS closed) the power winding dominates — the adapter PWMs the gate at a pot-set duty, softening the snap.
• At end of stroke EOS opens and only the hold winding remains — the adapter switches the gate to 100 % solid-on for a firm, silent hold (no PWM whine, and the hold winding is rated continuous).

So the pot tunes fire strength while the hold stays firm. A naïve "PWM everything" approach would weaken the hold winding and make it droop and buzz — this timed fire-then-hold avoids that.

Controller board

This build uses a USB-C "Nano" board built around the ATmega328P (chip marked ATMEL MEGA328P U-KR) — a classic 328P, programmed over an onboard USB-serial bridge (no native USB). The PF1/PE0 silkscreen pins are 32U4 port names left over on this clone layout; they are vestigial and unused here. The functional pins (D2, D3, D9, D10, A0, +5V, GND) are all standard 328P pins.

Parts required

Pin connections (this board's silkscreen labels)

Potentiometer outer legs go to +5V and GND.

Where it splices in

Wiring sequence

Bring-up & test (coils safe first)

• Pull the 43 V flipper fuses (or disconnect the coils) so nothing can fire on first power-up.
• Load the sketch. With a meter on a gate vs GND: idle ≈ 0 V; hold a flipper button → a PWM average that rises with the pot, settling to ≈ 5 V after the ~80 ms fire window.
• If a flipper behaves inverted (fires when not pressed), set ENABLE_ACTIVE_HIGH = false and reflash.
• Restore fuses/coils. Start with the pot low, fire-test, and turn up until the strength feels right. If a flipper struggles to complete its stroke at low settings, raise FIRE_MIN or FIRE_MS slightly.

22 Incandescent Lamp Fade

The original Baby Pac-Man playfield lit with incandescent bulbs — they glow up and cool down instead of snapping on and off. LEDs switch instantly, which reads as harsh. This build simulates the bulb behavior in software, on top of the Ultimate I/O's 256-level PWM, and every part of it is tunable from babypac.bat without recompiling.

How it works

Each lamp keeps a brightness value 0–255. Every 60 Hz frame, UpdateOutputs() in pacdrive.c eases that value toward the ROM's target (255 = on, 0 = off), then the whole 96-output board is pushed with a single Pac64SetLEDIntensities() bulk transfer. Because that bulk command needs ~20 ms before the next one, the push runs every other frame (~30 Hz) — still smooth, and the update cost is fixed no matter how many lamps are fading at once.

The three curve shapes

Fade-in and fade-out each pick an easing curve independently:

• exp — fast off the mark, then tapers (ease-out). Snappy start, long lingering tail. The default.
• s — smoothstep: slow at both ends, fastest in the middle. Soft launch and soft landing.
• lin — constant speed the whole way. A straight ramp.

Perceptual gamma

LED PWM is linear in duty cycle, but the eye is not. A gamma curve (default 2.2) is applied to the output so the fade reads as smooth and even and the dim glow lingers naturally. Toward 1.0 gives the raw, punchier linear look; higher than 2.2 is punchier still with a longer low tail. Gamma is set independently for rise and fall.

Configuration — babypac.bat

All values are read once at launch and clamped to sane ranges. Speeds are 1–255 (higher = faster). The plain BABYPAC_FADE_CURVE / BABYPAC_FADE_GAMMA set both directions; the _RISE / _FALL variants override.

A "real bulb" starting point — a quick exponential warm-up in, a slow constant fade-out with a long perceptual tail:

rem babypac.bat
call setvol 80
set BABYPAC_FADE_CURVE_RISE=exp
set BABYPAC_FADE_CURVE_FALL=lin
set BABYPAC_FADE_GAMMA_RISE=1.6
set BABYPAC_FADE_GAMMA_FALL=2.6
set BABYPAC_FADE_RISE=40
set BABYPAC_FADE_FALL=18
pinmame babypac -ultimateio -joystick -dmd_only -scanlines -skip_gameinfo

On startup the console prints the active values — Lamp fade: RISE speed=… curve=… gamma=… | FALL speed=… curve=… gamma=… — so you can confirm what took effect.

23 Input HW → Switch Function Map

Running with -ultimateio, this build does not use the normal named switch inputs. Instead core.c reads 64 generic inputs — "Input HW1" … "Input HW64" — directly into the switch matrix. You rebind those "Input HW" entries in Input (general) — they override the named "Slam Tilt", "Coin", etc. entries in Input (this game), which is why editing those has no effect. This table says what each "Input HW" controls.

Relabeled inputs (from PinMAME Tab Menu re-mappings.csv)

The 28 mapped inputs, and the exact label each one now carries in the Input (general) menu in this build (the "Menu label" column is what was applied to src/inptport.c):

Cabinet & control switches (exact)

These are defined in src/wpc/byvidpin.h / byvidpin.c, so the mapping is definitive. The "source default key" is the compiled-in default; in this build the actual key comes from the I-PAC programming and cfg/babypac.cfg.

Playfield switches

The playfield switches fill the strobe columns (roughly Input HW9–HW56), per the Baby Pac-Man switch matrix in the operator's manual (drawing W-1280). The complete set of named switches:

• Flippers: Left Flipper, Right Flipper (Right Flipper = Input HW9)
• Drop Targets: #1 (Left), #2, #3 (Center), #4, #5 (Right)
• Saucers: Left Maze Saucer, Right Maze Saucer, Outhole Saucer, Top-Left Saucer, Top-Right Saucer
• Spinners: Left Spinner, Right Spinner
• Top Center Loop: Left, Right
• Lanes / outlanes: Left Inside Outlane, Right Inside Outlane, Tunnel Outlane, Fruits Outlane
• Rebound: 10-Point Rebound