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.

Instead, Crypt Killer happened. Crypt Killer runs onKonami GQ, another PlayStation-derived Konami arcade platform with expanded memory, SCSI hard-disk storage, dedicated sound hardware, and three-player lightgun support.

Because apparently two guns were insufficient.

So GQ followed GV. Then attention turned toNamco System 11. At some point it became difficult to continue describing ArcadeDuck as “that Simpsons Bowling thing.”

We remain disappointed by this failure of scope control.

Source provenance

Where ArcadeDuck came from.

ArcadeDuck was not written from scratch. That matters, and we have no interest in pretending otherwise.

At the foundation is DuckStation, created by Connor McLaughlin (stenzek) and developed with contributions from many other people. DuckStation provided the enormous amount of PlayStation emulation work underneath ArcadeDuck: CPU emulation, recompilers, GPU and SPU emulation, timing, rendering backends, input infrastructure, frontend architecture, and countless other pieces we did not have to reinvent.

ArcadeDuck's contribution is not “we invented PlayStation emulation.” That would be impressive. It would also be bullshit.

Arcade1Up later created its modified duckstation-sbimplementation specifically for The Simpsons Bowling on its Android-based arcade cabinet. Its published source identifies the special Simpsons Bowling media and flash requirements and creditsDatapower Development for additional code.

t-dollaz subsequently continued that work insimpsons-bowling-baby-phoenix-duckstation, adapting and extending the Arcade1Up-derived implementation for desktop use. That repository became the immediate starting point from which ArcadeDuck grew.

ArcadeDuck has since migrated, replaced, refactored, or rewritten substantial parts of that code as the project expanded beyond one game and one hardware configuration. None of that changes where it came from. Good open-source projects should make their lineage clear. Pretending you appeared fully formed from the void is generally frowned upon.

Modernizing the foundation

Then we had to deal with the DuckStation underneath it.

The Simpsons Bowling code we inherited was valuable. The DuckStation underneath it was also old.

The Arcade1Up/t-dollaz lineage was based around a DuckStation tree from approximately the 2021 Qt 5 era. t-dollaz's own repository describes it as a years-old snapshot that had diverged from modern DuckStation architecture.

That left ArcadeDuck with an awkward combination: a working implementation of obscure arcade hardware sitting on top of a PlayStation emulator foundation that was several years behind the project it originally came from.

Keeping that old base would have been easier in the short term. It also would have meant deliberately building a new emulator project on years-old infrastructure when a much newer compatible foundation was available.

So ArcadeDuck undertook a much larger migration: preserve and understand the working arcade hardware implementation while moving everything onto the last upstream DuckStation revision immediately before its source licensing changed away from the prior GPL-compatible tree.

Why this revision?

Why the last GPL-era DuckStation baseline?

This is another question ArcadeDuck will probably get forever:Why are you using an older version of DuckStation instead of the latest one?

Because the version number is not the important part. The licensing boundary is.

DuckStation commit 25bc8a6 is the direct parent of commit9ca6b54, where the project changed source-file SPDX headers from the previous (GPL-3.0 OR CC-BY-NC-ND-4.0) licensing toPolyForm-Strict-1.0.0 and updated the project license text.

That made 25bc8a6 the natural upstream boundary for ArcadeDuck: it gave us years of newer DuckStation development compared with the roughly 2021 codebase we inherited, while keeping the project on the source lineage we could continue developing under ArcadeDuck's GPL licensing.

The migration brought forward a substantially more modern emulator foundation: newer rendering infrastructure, newer CPU and recompiler work, input improvements, years of bug fixes, frontend changes, refactoring, and performance work.

It was not a random old build somebody found behind the couch. It was a deliberate boundary.

The inevitable follow-up

Why not just update to current DuckStation anyway?

Because at this point “update DuckStation” no longer means what it sounds like.

ArcadeDuck has diverged substantially from the assumptions of a consumer PlayStation emulator. The project now contains arcade-specific ROM and CHD handling, board BIOS profiles, machine dispatch, SCSI devices, EEPROM and flash persistence, cabinet controls, coin/test/ service behavior, multiple independent lightguns, trackballs, specialized controllers, game-specific hardware profiles, an arcade database, and frontend behavior designed around cabinets.

A current DuckStation release cannot simply be dropped underneath all of that like updating a package dependency. Doing so would mean manually porting and revalidating a significant amount of ArcadeDuck against a codebase that has continued evolving independently.

Newer DuckStation source is also beyond the licensing boundary ArcadeDuck deliberately selected. ArcadeDuck does not solve licensing questions by pretending they aren't there.

So the project continues from its final GPL-era upstream baseline, modernizing and replacing code as needed from our tree. The objective is to make arcade games work better, not to win a competition for the highest upstream commit number.

A revolutionary software-development concept, apparently.

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 is no longer intended to be a PlayStation emulator with some arcade games bolted onto it. It is becoming anarcade emulator whose supported hardware happens to descend from PlayStation technology.

That distinction guides the project.

We do not need memory cards simply because the PlayStation had memory cards. We need EEPROM and flash because the arcade hardware had EEPROM and flash. We do not need every consumer controller Sony ever released. We need the controls the cabinet actually had.

The interface should feel like it belongs to an arcade emulator. The game database should describe arcade sets. The control system should describe arcade controls. The storage system should understand arcade storage. The emulator should know what machine it is actually emulating.

Konami GV was the beginning. Konami GQ followed. Namco System 11 is underway. More PlayStation-derived arcade hardware is planned after that.

How far does this eventually go?

That is an excellent question. We have intentionally stopped asking it.