Analogue Pocket SNES Core Developer Rejects 50,000-Line AI Submission

The appeal of retro-game preservation and enhancement often comes down to community effort: developers build tools, enthusiasts test them, and maintainers decide what is safe and useful enough to merge. That collaborative model depends on a less glamorous resource than technical ambition: somebody’s time to understand every change.

That tension has surfaced around the Super NES core for Analogue Pocket’s openFPGA environment. A contributor using the name nasonliu submitted an experimental MSU-1 streaming feature, an idea that the core’s Analogue Pocket porter, agg23, said was potentially exciting in principle. But agg23 rejected the manner of the contribution, describing it as an unsolicited, nearly 50,000-line change produced entirely with a large language model, or LLM.

The complaint was not that a proposed MSU-1 feature could never be useful. It was that the proposed implementation transferred an enormous verification burden to the project’s maintainer.

“If it works, that’s pretty cool; I didn’t think I would ever see this implemented,” agg23 said, before criticizing the scale and origin of the change. “You sent me a nearly 50k line diff, unasked for, completely LLM built, and you somehow expect me to review it.”

For players, the dispute may sound like an argument over code etiquette. In practice, it goes to the reliability of the tools used to run classic games and fan-made projects. Emulator and FPGA-core contributors are not simply adding a menu button or changing a visual theme. They may be affecting timing, audio behavior, file handling and compatibility across a broad catalog of software. A patch that cannot be clearly explained or efficiently reviewed is difficult to trust, even if it appears to work in one narrow scenario.

What the Pocket’s openFPGA setup is—and why a core matters

Analogue Pocket supports openFPGA, a platform for open-source and homebrew cores. A core is the component that recreates the behavior of a particular machine or hardware environment. In this case, the subject is a Super NES core adapted for the Pocket.

FPGA stands for field-programmable gate array. It refers to programmable hardware that developers can configure to model electronic logic. In retro-gaming discussions, FPGA projects are often distinguished from conventional software emulation because they aim to reproduce hardware behavior through configurable logic rather than only through a program running on a general-purpose processor. That distinction does not make maintenance simpler. It makes careful design and review especially important, because a change can alter how the recreated system behaves.

OpenFPGA’s value is its ability to support an array of community-made systems and experiments. It also means the health of a core depends on people who are prepared to maintain it over time. A flashy feature request is only the beginning: it must be readable, scoped appropriately, tested by people who understand it, and manageable when future users uncover a problem.

That is why the phrase diff matters in this story. A diff is a record of what a code contribution changes relative to the project’s existing version. A 50,000-line diff is not automatically bad; a large feature may genuinely require extensive work. But its size makes a review substantially more demanding, particularly when the maintainer says much of it is unrelated “garbage.” Unrelated changes make it harder to determine what the submission actually does and whether it introduces regressions elsewhere.

MSU-1: a fictional chip with real use in fan projects

The proposed feature concerns MSU-1 streaming. Despite the chip-like name, MSU-1 was never an actual Super NES enhancement chip. It is a convention devised by emulator developers, enabling Super NES ROM hacks to use additions such as CD-quality audio and similar upgrades.

That makes MSU-1 an unusual but meaningful corner of the Super NES scene. It is not an attempt to preserve an original cartridge feature that shipped in the console’s era. Instead, it is a shared target that lets creators expand what a modified game can present when played through compatible software or hardware projects. The technical possibility is appealing because it can allow fan developers to pursue audio and presentation ideas beyond the original machine’s standard format.

Streaming support for that standard could therefore be valuable to people interested in enhanced ROM hacks. Yet a desirable result does not settle the question of whether a particular patch belongs in a core. The maintainer has to assess whether the implementation is correct, whether it interacts safely with existing behavior, and whether the project can support it later. The submission’s stated experimental status further underscores that it was not a routine, finished change ready to be accepted without scrutiny.

agg23’s reaction captures the split cleanly: the prospect of the feature was described as cool, while the method of delivering it was deemed unacceptable. Those are separate judgments, and treating them as one would miss the point. A project can welcome an idea while declining code that arrives without a comprehensible basis for review.

The real objection: review work is work

AI-assisted coding is often discussed in terms of whether a tool can generate code quickly. This dispute instead highlights the work that follows generation. Before maintainers accept a contribution, they need to know what it changes, why each piece is necessary, how it behaves under edge cases, and who can fix it if it breaks.

agg23 said the contributor was “infringing on the time and brainpower” of maintainers by submitting content in which little or none of the submitter’s own reasoning had gone into the work. The criticism is pointed, but its practical meaning is straightforward: a contributor who cannot explain a patch leaves the person reviewing it to reconstruct the reasoning from scratch.

That is a poor fit for volunteer-driven technical communities. An LLM can produce a huge volume of text or code faster than a human can inspect it. But speed at the generation stage does not prove correctness, maintainability or relevance. If a 50,000-line submission requires a human maintainer to untangle broad unrelated changes before they can even evaluate its central feature, the tool has shifted effort rather than eliminated it.

In emulator and FPGA development, this can be particularly costly. Compatibility work often concerns subtle behavior. A feature may perform as expected in one game or one hack while causing an unexpected fault elsewhere. A reviewer needs a contribution with a clear purpose, limited scope and intelligible design in order to identify those risks. Sending a massive output dump provides none of those assurances merely by producing an apparent result.

“Vibe coding” and the accountability gap

The debate also involves the increasingly common label vibe coding. In this context, it describes someone directing an AI tool to produce software without fully understanding the resulting code. The term is deliberately dismissive, but it identifies an accountability problem: if the submitter cannot explain the work from top to bottom, they are not well positioned to answer review questions or maintain it after merging.

That does not establish that all AI use is unwelcome in emulator communities. The PS3 emulator project RPCS3 has voiced a similar concern about AI-generated submissions, while not banning contributors from using AI outright. Its stated expectation is that submitters understand their code completely before offering it to the project.

That distinction is important. A project policy centered on comprehension is not necessarily a blanket judgment on which tools a programmer may use privately. It is a standard for contribution quality and responsibility. A developer who uses assistance but can account for every part of a small, focused patch is presenting maintainers with something fundamentally different from an unexplained mountain of generated output.

For potential contributors, the practical lesson is not that an ambitious feature idea must be abandoned. It is that a contribution should start with communication and ownership. Explain the goal, ask whether a maintainer wants the feature, separate unrelated cleanup from the main work, and be ready to explain each significant decision. If an AI tool was involved, the contributor still needs to validate and understand what is being submitted. The responsibility does not move to the maintainer simply because a tool produced the first draft.

Why this matters beyond one Pocket core

Classic-gaming projects regularly rely on expertise that is hard to replace: people who understand old hardware behavior, software compatibility and the quirks of fan-created formats. Their available time is finite. When that time is spent triaging unrequested, oversized generated patches, it is time not spent on intentional improvements, bug fixes or documentation.

The dispute is also a reminder that open collaboration is not synonymous with an obligation to merge every unsolicited contribution. Maintainers are stewards of the codebase and of the expectations that users place on it. They must be able to reject work that is too broad, too opaque or too expensive to assess. Saying no to a particular submission is not necessarily saying no to MSU-1 support, future experimentation or contributors using modern tools responsibly.

There is a cultural stake as well. Projects that make old games newly playable and expandable are sustained by shared technical knowledge. A healthy contribution process encourages people to learn the system they are changing, document their reasoning and participate in long-term upkeep. A process flooded by unexamined generated code risks turning experienced maintainers into unpaid cleanup crews.

Retro development continues to produce unexpected possibilities, from hardware recreations to new ways of revisiting older software. Recent projects show that the scene still makes room for unusual platforms and experiments, including a new version of Skool Daze for Commodore Plus/4. But possibility is only half of the equation. For a feature to become a dependable part of a maintained project, somebody has to be able to understand it, review it and stand behind it.

In the Analogue Pocket SNES-core dispute, agg23’s answer was emphatic: an AI-generated 50,000-line submission without that human ownership has no place in the project. The proposed MSU-1 functionality may remain an intriguing technical prospect. The episode, however, makes clear that maintainers will judge the route to that prospect as closely as the destination.