This was supposed to fix a bowling game.

The original problem

Why The Simpsons Bowling?

The Simpsons Bowling has been playable in MAME for years, but one of its most noticeable problems has been its audio—particularly the streamed character and announcer voices.

And in this particular game, that matters a lot. The cabinet used the actual Simpsons voice cast, with characters reacting to throws, talking between turns, insulting each other, and generally providing most of the personality of the game. The announcer calls strikes, doubles, turkeys, and other events throughout play.

MAME Testers documents the long-standing issue directly: after the first voice/sample is loaded from the CD, later streamed dialogue can fail to load. The result is missing character speech and missing calls such as “Strike,” “Double,” and “Turkey,” with some screens lingering longer while the game waits on audio that never plays.

Then there was the Arcade1Up version. Arcade1Up's Simpsons cabinet used a modified version of DuckStation forThe Simpsons Bowling. That implementation demonstrated a practical route to running the game with its specialized arcade hardware and, importantly, without accepting the missing-dialogue experience as normal.

Can we get that working properly on a normal Windows PC?

That was the beginning of ArcadeDuck. We just didn't know it yet.

Milestone one

First, make Homer talk.

The initial goal was not to create another PlayStation emulator. DuckStation already existed, and creating a new PS1 emulator from scratch because Homer Simpson refused to announce a turkey would have been excessive even by our standards.

Instead, the goal was to understand the arcade-specific work that had already been done around The Simpsons Bowling and make it practical on Windows.

The game runs on Konami GV, a PlayStation-derived arcade platform, but its cabinet includes hardware that an ordinary consumer PlayStation emulator has absolutely no reason to care about: SCSI storage, EEPROM, flash memory, trackball hardware, cabinet inputs, arcade-specific boot behavior, and a dedicated daughterboard.

In other words, everything required to turn “it's basically a PlayStation” into “why the hell isn't this register responding?”

The first real milestone was getting all of that working reliably while preserving the thing that started the whole project:the voices worked.

Mission accomplished. Project over. Obviously.

Scope control

Then we noticed there were other games.

Once The Simpsons Bowling was working, something inconvenient became apparent: we had not merely fixed one game. We had implemented a substantial amount of Konami GV.

What about the rest of the GV library?

That meant standard joystick games, trackball games, two-player trackball games, independent lightguns, specialized control hardware, EEPROM and flash persistence, game-specific hardware configurations, more accurate SCSI behavior, operator controls, Test and Service modes, and all the other things that make an arcade machine an arcade machine instead of a PlayStation wearing a very expensive wooden costume.

Eventually, supporting the entire Konami GV family became the goal. Then GV worked. That would have been an excellent place to stop.

What began with Konami GV has expanded through Konami GQ, Namco System 11, and Sony ZN-1. Work has continued into later and more complicated PlayStation-derived platforms including ZN-2, Taito G-Net, Namco System 12, and additional hardware families.

Because apparently two guns were insufficient.

We remain disappointed by this failure of scope control.

Audited source provenance

Where the current ArcadeDuck source actually comes from.

ArcadeDuck is built on DuckStation source. The current lineage is not inferred from dates, similar files, or old project descriptions. It was reconstructed directly from the repository's Git graph during an extensive provenance audit.

The first ArcadeDuck commit,53f4ae558af0d569143d7ef7698f1328b71cdec7, has exactly one parent:25bc8a64803df7e702db66e0f11d7b7d0fdc99f2. That establishes the active project's inherited DuckStation boundary directly from repository history.

The following historical DuckStation commit,9ca6b5430fb358b39f21ce0b2fc0268de954dd23, changed the project's source licensing. The audit therefore treats25bc8a6 as the Git-graph boundary — not as a blanket claim that every individual file at that revision carried the same license.

The five-file exception

The boundary had five file-level exceptions.

The repository-level license at the inherited boundary was GPLv3, but the audit identified five source files that already carried PolyForm-Strict-1.0.0-only SPDX headers before the broader project licensing change.

That is why ArcadeDuck does not describe 25bc8a6 as simply "the last GPL version." It is the correct Git boundary, but those five file-level exceptions required separate treatment.

Apparently even the clean boundary had a boundary condition.

Historical cleanup

The five exceptions were removed or restored before the first public release.

That commit removed the separate PolyForm-era software rasterizer and restored the older software-rendering path. The two audio files were substantially restored to the earlier implementation that carried a GPL licensing alternative, then continued forward with ArcadeDuck's own audio changes.

The provenance audit compared the restored source against both the older implementation and the intervening PolyForm rewrite. Its normalized comparison found zero retained lines unique to the PolyForm rewrite in the compared current audio/backend implementations, while hundreds of meaningful lines matched the older implementation.

The audited source contained noPolyForm-Strict-1.0.0-only orCC-BY-NC-ND-4.0-only SPDX declarations in the scanned current text headers.

Earlier proof of concept

Arcade1Up and t-dollaz are part of the history, not the current Git ancestry.

ArcadeDuck's earliest proof-of-concept work used the Arcade1Up Simpsons Bowling DuckStation fork and the later t-dollaz desktop continuation. Those projects were important references for understanding the cabinet-specific hardware and getting the original Simpsons Bowling experiment moving.

The provenance audit confirmed that the older proof-of-concept is a separate snapshot history. It is not an ancestor of the current ArcadeDuck dev lineage.

They remain credited because they are genuinely part of ArcadeDuck's history. They are simply no longer presented as the Git ancestry of the source tree being released today.

Repository-wide review

Provenance was checked, not assumed.

The provenance review enumerated all 2,145 tracked files in the audited checkout and scanned tracked text for SPDX identifiers, copyright notices, license text, and upstream/reference markers.

Reachable history, branch tips, historical license changes, candidate upstream matches, third-party notices, source attribution, and the identified file-level licensing exceptions were then reviewed in detail.

Even minor or possible findings were remediated before the public repository was created. The public repository was then started from the verified clean source snapshot instead of publishing the old forensic development history.

Trust is useful. Reproducible commit hashes are considerably more useful.

Project direction

Why not just submit all of this upstream?

Because this is ultimately a choice about what an emulator should be built to do.

Console emulators should emulate console games. Arcade emulators should emulate arcade games.

DuckStation is an excellent PlayStation emulator, and ArcadeDuck would not exist without the work that came before it. But the farther this project developed, the clearer it became that arcade hardware has different priorities: coin inputs, Test and Service controls, lightguns, trackballs, cabinet I/O, external outputs, EEPROM and flash, SCSI devices, board-specific storage, unusual peripherals, dedicated sound hardware, networking, and operator behavior that has little or nothing to do with emulating a consumer PlayStation.

Those features could theoretically be developed as patches against a console emulator. That is simply not the direction I want to take. ArcadeDuck is intentionally built around the arcade machine first, rather than asking a console emulator to accommodate an increasingly large arcade subsystem.

That decision is not about fame. It is not about money. It is not about pretending the PlayStation emulation underneath ArcadeDuck was created here, and it is certainly not about taking credit away from the people whose work made this project possible.

It is a personal development choice: keep the console emulator focused on consoles, keep the arcade emulator focused on arcade machines, and give each project the freedom to make decisions around its own goals.

Same family tree. Different cabinet.

Hardware research

Arcade hardware is weird.

The farther ArcadeDuck gets from the basic PlayStation architecture, the less helpful the phrase “it's basically a PS1” becomes.

Yes, many of these machines begin with familiar PlayStation-derived components. Then the arcade manufacturer adds a SCSI controller, a hard disk, four flash chips, another CPU, a dedicated sound subsystem, protection hardware, networking, EEPROM, custom cabinet I/O, a trackball daughterboard, three lightguns, or some combination of the above.

And suddenly the PlayStation portion is the easy part.

Standing on excellent documentation

MAME deserves a lot of credit.

ArcadeDuck exists partly because we wanted a different result for games such as The Simpsons Bowling. That should not be interpreted as “MAME is bad.” Quite the opposite.

MAME is one of the most important technical preservation projects in the history of arcade hardware. Its developers and contributors have spent decades documenting boards, CPUs, custom chips, ROM layouts, storage devices, protection hardware, cabinet I/O, sound systems, obscure peripherals, and machines whose surviving manufacturer documentation ranges from excellent to “someone uploaded a blurry photograph of the PCB in 2004. Good luck.”

MAME's hardware research has been an invaluable reference throughout ArcadeDuck development. The fact that ArcadeDuck sometimes implements a device differently, approaches a problem from another direction, or exists because we wanted to improve behavior in a particular game does not diminish that contribution.

Independent implementations are useful. MAME has broad preservation goals across an almost absurd number of machines. ArcadeDuck has the luxury of obsessing over a much narrower collection of hardware.

We can spend an unreasonable amount of time on one SCSI timing problem. We know this because we have. Repeatedly.

More homework

Other projects and documentation.

MAME is not the only technical reference ArcadeDuck uses. MiSTer and other FPGA projects can provide valuable independent implementations of the same arcade hardware. Original service manuals and schematics are used whenever they survive. Chip datasheets are extremely useful. PCB photographs can answer questions documentation does not. Other emulator implementations can provide clues about undocumented behavior.

Sometimes all of those sources agree. Sometimes they don't. Sometimes the manual says one thing, another implementation does something else, the real game expects a third thing, and you end the evening reading a 30-year-old NCR SCSI datasheet for entertainment.

We use the word “entertainment” loosely.

Different priorities

MAME wasn't wrong. We just wanted something different.

MAME's mission is enormous. ArcadeDuck's is deliberately narrow. That allows ArcadeDuck to make decisions specifically around these machines and the way people actually use arcade cabinets.

• Per-game arcade control profiles
• Lightguns as first-class devices
• Multiple independent trackballs and pointer devices
• Test, Service, Coin, and Start controls built around cabinet use
• Board-specific EEPROM, flash, ROM, CHD, and BIOS behavior
• An arcade game database rather than a retail PlayStation catalog

And yes, we can spend a stupid amount of time investigating why Homer Simpson isn't talking. Different projects can have different priorities. That's a good thing.

Acknowledgements

Credit where it belongs.

ArcadeDuck exists because a lot of talented people did difficult work before this project existed. That deserves more than a line hidden somewhere in the source tree.

We blame t-dollaz accordingly. Respectfully.

Today

What ArcadeDuck is now.

ArcadeDuck has moved well beyond being a PlayStation emulator with a few arcade games attached to it. It is an arcade emulator focused specifically on hardware derived from PlayStation technology.

That means the machine matters as much as the CPU and GPU. ArcadeDuck models the things that actually made these systems arcade hardware: board-specific BIOS behavior, ROM and CHD layouts, SCSI devices, EEPROM and flash storage, cabinet inputs, Test and Service controls, lightguns, trackballs, specialized I/O, dedicated sound hardware, external outputs, and the strange daughterboards manufacturers added because apparently the base hardware was not complicated enough.

The interface, game database, control system, storage handling, and machine configuration are all being built around arcade hardware rather than around the assumptions of a consumer PlayStation.

What began with Konami GV has expanded through Konami GQ, Namco System 11, andSony ZN-1. Work has continued into later and more complicated PlayStation-derived platforms includingZN-2, Taito G-Net,Namco System 12, and additional hardware families.

Some of those later systems remain experimental while their hardware, timing, audio, protection, peripherals, and game-specific behavior are researched and validated.

How far does this eventually go?

That is still an excellent question. We are still deliberately not asking it.