Neo Geo AES+: why the fears around the 68000 and the ASIC are probably exaggerated

Since the announcement of the Neo Geo AES+, the technical debate has quickly heated up. It’s almost inevitable: as soon as a manufacturer promises a faithful hardware reimplementation, the words ASIC, FPGA, cycle accuracy, and cartridge compatibility immediately come up. Part of the criticism has crystallized around a very specific, almost obsessive point: the reproduction of the Motorola 68000. The underlying idea is simple: if this CPU is not reproduced identically, everything else falls apart. It’s an appealing shortcut, but technically, it misses the essential point.

The most interesting thing in this matter is not so much the fear itself but its hierarchy. Yes, a fixed ASIC with an error can become a real problem. Yes, marketing communication that promises “silicon” fidelity necessarily calls for serious scrutiny. But no, the 68000 is probably not the riskiest area of the project. On Neo Geo, the sensitive point is not running a compatible 68k CPU. The sensitive point is to recover the overall behavior: the dialogue between CPU, video logic, VRAM, cartridge ROM, audio, interrupts, bus arbitration, and raster timings.

In other words, the right way to look at it is not “Does SNK know how to remake a 68000?”, but rather “Does SNK know how to industrialize a coherent Neo Geo architecture without breaking what makes the machine’s personality?”. That’s where the debate finally becomes useful, because it moves away from abstract fear to the real engineering question.

The false debate about the Motorola 68000

The Motorola 68000 is often described as the brain of the Neo Geo. That’s true, but it’s important to be precise about what that means. The 68000 executes the main program, manages game logic, controls registers, synchronizes critical tasks, and orchestrates exchanges with the rest of the system. However, it neither creates the machine’s visual signature nor, by itself, its “SNK arcade” feel. Just because a component is central doesn’t mean it’s mysterious, nor because it’s important that it constitutes the most difficult part to reproduce.

Official Motorola documentation exists; it is massive, detailed, and usable. The M68000 family reference manual explicitly describes the programming model, registers, program counter, status register, instructions, and their differences within the family. So, we are not talking about a component documented in fragments or through some obscure maintenance notes. We are talking about a CPU whose software specification has been known for decades and which has been dissected at a very fine level by several generations of developers, emulators, and hardware core designers.

Why the Motorola 68000 is one of the best-mastered CPUs in history

The 68000 benefits from a rare combination of favorable factors. It was widely distributed, it lived a long time, it was used in consumer and professional machines, it was studied by very active communities, and its ISA remains relatively readable. The M68000 family also left behind a huge amount of tooling: assemblers, debuggers, disassemblers, ROM tests, compatibility suites, instruction tracers, and reference cores. This is exactly the kind of ecosystem that turns an old CPU into a “solved problem.”

Moreover, the 68000 has the advantage of being at the crossroads of several worlds. It lived in consoles, in microcomputers, and in arcade. This diversity has a direct consequence: strange behaviors, edge cases, and gaps between theory and practice have had time to be encountered, corrected, cataloged, and revalidated. When a 68000 core fails on an old game, a synthetic benchmark, an Atari ST demo routine, an Amiga loader, or a Mega Drive diagnostic program, the community notices very quickly. This is the opposite of a rare coprocessor whose bugs sleep for years due to insufficient corpus.

This CPU can be found in families of machines, each of which has forced its understanding to a different level: Mega Drive on the console side, Amiga, Atari ST, and Macintosh on the micro side, not to mention a considerable number of 68k-based arcade boards. This cross-sectional presence counts for a lot. It means that the 68000 has not only been documented “in theory”; it has been observed in environments where it had to coexist with VDPs, custom chips, DMAs, banked ROMs, video interrupts, and very real real-time constraints.

• Consoles: Mega Drive and Neo Geo have widely exposed the 68k to the general public.
• Computers: Amiga, Atari ST, and Macintosh have pushed its software usage very far.
• Arcade: Capcom, Sega, and SNK used it in environments with strict timing.
• Documentation: the M68000 family has an unusually rich technical corpus.
• Validation: emulators, FPGA cores, and testing tools have multiplied cross-checks.

A processor already reproduced in countless contexts

Just look at the state of emulation and hardware implementations to understand how well mastered the 68000 is. On the software side, emulation cores have existed for a long time. On the precision side, several projects have explicitly set the goal of a cycle-accurate reproduction. On the FPGA or compatible logic side, there are also well-known implementations that have been confronted with game and test libraries. None of this proves that a Neo Geo integration is automatically perfect, but all of this proves that we are not starting from a technical black hole.

The important nuance is here: reproducing a CPU is not the same as reproducing a console. A faithful 68000 core already exists in several forms. What separates a “good 68k” from a “good Neo Geo” is the hardware environment in which this core is inserted: latencies, VRAM access, video signals, bus arbiters, interrupts, and constraints imposed by SNK chips. So it is not the difficulty of remaking the 68000 that should worry first, but the way it is connected to the rest.

Documentation, reverse engineering, and cycle-accurate emulation

The 68000 also has another decisive advantage: it lends itself very well to behavioral reverse engineering. Even without having the original Motorola masks, one can very precisely test its response to instruction sequences, its flags, exceptions, access timings, and interaction with the bus. This is exactly what has allowed modern projects to achieve very fine implementations. Fidelity does not come only from factory plans; it also comes from repeated empirical validation.

Conversely, there are retro blocks that are much more difficult to fully lock down: specialized DSPs, cartridge compression or decryption chips, additional coprocessors, very particular extensions, or hybrid logic mixing CPU, DMA, and exotic mapping. This is precisely why the reproduction of the 68000 ultimately inspires less fear than some intelligent cartridge architectures or additional subsystems like auxiliary processors in certain SNES cartridges. The 68000 is not trivial; it is above all known, bounded, and already well mapped out.

The conclusion that imposes itself is quite clear: the reproduction of the 68000 has not been the main bottleneck for a long time. Not in the sense that any clone would automatically be perfect, but in the sense that the problem is no longer experimental. We know how to document it, we know how to compare it, we know how to implement it, and above all, we know how to confront it with a mountain of historical software.

The Neo Geo is not legendary because of the 68000

The Neo Geo was never fascinating solely because it housed a 68000. Other machines already used it, sometimes with excellent results. What makes the Neo Geo immediately recognizable is the way SNK’s architecture transforms cartridge memory into display. Its personality lies in the density of its sprites, the size of its assets, the way its chips handle video lines, and the raw richness of its graphic ROMs. The CPU orchestrates; it does not create this massive rendering alone, very much like a “home arcade cabinet”.

This is where many debates derail. People think that replacing a CPU automatically transforms the machine into something else. In reality, on a Neo Geo, the system’s identity comes from the display pipeline, the data segmentation on the cartridge, the graphic chips, and the rendering timings far more than from any supposed internal magic of the 68000. The Neo Geo is not a “68000 first” machine. It is an SNK first machine.

Same CPU, radically different results

Comparing the Neo Geo to other 68k machines is instructive precisely because the comparison shows what the CPU does not explain. The Mega Drive, for example, clearly organizes its display around scrolling planes, tiles, and sprites via its VDP. The Neo Geo, on the other hand, relies on a much more straightforward logic: a fix layer and a gigantic sprite machinery that fetches its data directly from dedicated graphic ROMs. Even if both worlds can share a 68k, the rendering and constraints do not play in the same league.

The same can be said when comparing with the Amiga or the Atari ST. These machines also have a 68000, but their video architecture, auxiliary chips, memory handling, and software philosophy have nothing in common with the Neo Geo. The CPU is a common foundation. The visual result, the sense of bandwidth, and the rendering structure come from the rest.

The true heart of the Neo Geo: the graphic system

What makes the Neo Geo’s visual signature is its ability to push a huge number of large sprites with an immediate sense of richness. On this machine, sprites are not just simple small moving objects superimposed on a static background. They can be assembled to form vast vertical and horizontal structures, allowing for huge characters, multi-segment bosses, imposing vehicles, and extremely busy scenes.

Sprite pipeline: a machine designed scanline by scanline

The Neo Geo rendering logic is much more refined than one might think. The LSPC, at the heart of the video mechanism on cartridge systems, works with line buffers. The general idea is simple: while one line is sent to the video output, the next one is already being prepared. This permanent alternation allows managing a rich display without blocking the frame rate. This is a fundamental detail because it explains why the fidelity of video timings matters more than just CPU compatibility.

The simplified operation can be summarized as follows: the Neo Geo prepares the sprites needed for a given line, fills an active list, then renders that line at the right moment. Any error in this sequence can cause subtle artifacts: wrong priority, missing sprites on a line, occasional flickering, or an effect that does not appear exactly at the right time.

LSPC, scanlines, and sprite management

The role of the LSPC goes far beyond a simple conversion of data into pixels. It participates in selecting active sprites, processing them according to the current line, composing visible layers, and the final video output. It is a logic deeply tied to the display rhythm. It is also one of the reasons why a Neo Geo is not judged only by its ability to start a game, but by its ability to behave correctly at every moment, on every significant scanline.

The machine must constantly arbitrate which sprites deserve to be drawn, in what order, with what priorities, and within what time budget. On a light scene, this may seem trivial. On a Metal Slug or a Blazing Star in full visual chaos, it is quite the opposite. This is where the difference between a simply “functional” reproduction and a truly convincing reproduction is seen.

Separate cartridge buses and massive graphic ROMs

The Neo Geo cartridge architecture is crucial to understanding its rendering. The data is not gathered in a uniform block. The system separates the main program, the audio samples, the graphic data, the fix layer, and the sound code. This separation completely changes how the machine exploits the cartridges. The 68000 sees the program and controls everything, but it does not read the huge graphic banks like a classic linear memory. The video logic directly fetches what it needs from there.

It is precisely this decoupling that allows the Neo Geo to display massive amounts of detailed graphics without putting all the effort on the CPU. The 68000 commands. The specialized hardware executes the heaviest part of the image rendering. This logic also explains why the machine retains such a distinct identity despite using a CPU shared with other platforms.

Why does this rendering remain unique? Because the Neo Geo spends its bandwidth where the player immediately sees it: large sprites, abundant animations, huge cartridges, raw graphic data, and a video pipeline tailored for arcade. Where other systems rely more on sophisticated background layers, scrolling tricks, or memory compromises, the Neo Geo assumes an almost brutal strategy: load a huge amount of assets and push them to the screen consistently.

Why the Neo Geo looks neither like the SNES nor the Mega Drive

The comparison with the Super Nintendo and the Mega Drive is enlightening, provided one stays technical. The SNES largely relies on tilemaps, varied display modes, complex background layers, and a different orchestration of effects. The Mega Drive, on its side, relies on a more classic VDP in its philosophy, with well-identified scroll planes and sprites managed according to a different logic. The Neo Geo adopts a more direct path, more data-intensive, but fearsomely effective at producing a “premium arcade” rendering.

The player feels it intuitively: bigger sprites, more generous animation, an immediate impression of visual richness. The engineer reads it in the architecture: dedicated ROMs, omnipresent sprite logic, scanline pipeline designed for massive objects, bandwidth allocated to the essentials. The Neo Geo visual myth does not come from a 68000 more magical than another. It comes from a very coherent SNK architecture aligned with its goal.

The real challenge: timings, not the CPU

In a credible Neo Geo, the real challenge is less the MOVE or ADD instruction than the exact moment when everything happens. When can the CPU write? When does the video logic read the VRAM? When do the buffers switch? When does the audio logic see its data? When does a cartridge respond on the correct bus? The entire machine lives on very precise access windows, with fast and slow slots, concurrent accesses, and a rhythm imposed by line-by-line display.

A timing error can produce bugs that the general public will identify as “graphics” issues while their cause is deeper. A sprite may flicker, lose its priority, display a wrong tile for a single line, or trigger an effect with a minimal delay. A game can seem fine for hours and fail only on a boss, a transition, or a sequence saturated with animated objects.

Memory latency and CPU / video / audio synchronization

Memory latency is a critical point. If the VRAM or cartridge accesses respond a little too late, or a little too early, everything else can shift. Retro systems do not have the flexibility and abstraction layers of modern machines. They rely on stable behaviors, often tight, sometimes very close to bare hardware. A slight deviation can be enough to alter an animation, a sound effect, or a rendering priority.

Sound is no exception to this logic. The Neo Geo relies on a Z80 for sound management and on the YM2610 for synthesis and samples. Again, fidelity does not only depend on having “a compatible Z80” or “an audio chip that sounds almost the same.” It depends on how the 68k, the Z80, the interrupts, and the audio data synchronize without breaking the game’s rhythm or the expected sound triggers to the exact moment.

Concrete examples of possible problems

• Memory latency: a response that is too slow can break a sensitive display on a precise line.
• Bus arbitration: a poorly timed CPU access can disrupt video logic.
• Audio synchronization: a slight delay between 68k and Z80 can produce delayed sound effects.
• Cartridge access: an imperfect ROM response can cause erroneous data reading.
• Interrupts: a bad timing can misalign routines that expect a very precise moment.

This is exactly why the most serious question is not “does the CPU execute the right instructions?” but “does the entire machine breathe at the right rhythm?”. On Neo Geo, fidelity is as much a question of timing as it is a question of logic.

ASIC versus FPGA: a real risk, but to be put into perspective

The ASIC vs FPGA debate deserves more than a reflexive camp stance. An FPGA has a huge advantage: it can be updated. If a bug is discovered, the core can evolve. For a living project, for a preservation scene, or for an experimental platform, this is an immense asset. But the reverse reasoning — “ASIC therefore necessarily less faithful” — does not hold technically. An ASIC is not inherently a degraded version; it is a form of industrialization of a given logic.

What matters is not the final medium alone. What matters is the maturity of the logic before freezing. Etching an immature design is dangerous. Etching a design that has already been thoroughly verified, confronted with real games, and cleaned through successive iterations is a whole different story. The FPGA is therefore superior when exploring, when still correcting, when wanting to leave a door open to adjustment. The ASIC becomes coherent when the targeted behavior is already solidly locked down.

Real differences between FPGA and ASIC

On the logical level, both approaches can aim for the same functional result. On the practical level, they do not operate in the same way. The FPGA implements configurable logic in a programmable structure. The ASIC, on the other hand, implements this logic in a dedicated manner. This changes how one adjusts a design, how one fixes a bug, how one manages timing margins, and how one controls certain physical behaviors.

On the question of timing, an FPGA can sometimes require more care to ensure that the design behaves exactly as expected on a large scale, depending on the chosen target. An ASIC, once well designed, can offer better production stability. On the question of electrical behavior, the ASIC can also be more homogeneous, with more predictable power consumption and signal profiles. None of this automatically makes it a superior solution. It simply shows that the “bad ASIC / good FPGA” duel is far too simplistic.

Why ASIC is not necessarily less faithful

Fidelity is not a moral argument; it is a result. A well-designed ASIC can offer stable latency, clean integration, homogeneous production, and more consistent electrical behavior on a large scale. For a consumer product, this can even be a practical advantage. The relevant question is not “can we fix it afterward?”, but “how much was fixed before the fabrication?”. If the AES+ really relies on already very mature logic, the ASIC is no longer a roulette; it is a production step.

In which cases the FPGA remains superior

The FPGA retains an obvious advantage for anything related to edge cases: atypical flashcarts, finicky multicarts, aggressive homebrews, late validation tests, behavior variants discovered by the community. On this ground, reconfigurability is king. That is why an FPGA remains the ideal research tool and an ASIC can become the ideal distribution tool — provided that the former has well prepared the latter.

The role of Furrtek strongly changes the equation

The name Furrtek matters because it does not refer to a simple opinion speech. It refers to a long-term work on Neo Geo programming, memory mapping, the roles of ROMs, interfaces between subsystems, and, above all, an explicit willingness to transcribe the machine’s operation into logical definition. This is a crucial point because it entirely changes the nature of the risk.

We are not starting from zero. Even without going into the confidential details of a commercial project, the public ecosystem around the Neo Geo is already much more mature than on many other machines. Reverse engineering, card analyses, bus understanding, ROM documentation, rendering studies, FPGA experimentation: all of this already exists, publicly, and greatly reduces the risk of a “blind” reproduction.

Reverse engineering and field validation

Useful reverse engineering is not a mere archivist curiosity. It is work that allows comparing real behaviors, validating hypotheses, reconstructing logical chains, and testing these chains against the reality of the hardware. The more a design has been confronted with original cartridges, games known to cause problems, sensitive timings, and development tools, the more mature it becomes.

When a logic has already been tested on a real game library, with sensitive routines and picky users, it no longer has the same status. It ceases to be an elegant hypothesis to become a proven design. That is why the idea of a transition from FPGA to ASIC is not shocking in itself. What would be worrying is an early fabrication, without a solid foundation or prior validation. The current Neo Geo context does not look like that.

A mature core, not a disposable prototype

There is a huge difference between freezing a draft in ASIC and industrializing a core that has already been extensively tested. In the first case, you engrave approximations. In the second, you transform accumulated knowledge into a finished product. This is precisely what makes the current debate more nuanced than it seems: the chosen support matters, but the maturity of the design matters much more.

A limited catalog, therefore almost entirely testable

One reassuring point is mentioned too rarely: the Neo Geo catalog is finite, relatively contained, and therefore verifiable under realistic conditions. We are talking about a set of about 150 to 160 official games depending on how variants are counted. It is huge for a player, but perfectly manageable for a serious validation campaign. This completely changes the nature of the risk. We are not talking about an infinite, uncontrollable ecosystem, with thousands of cartridges with unpredictable behaviors.

Why this validation by the catalog is credible

Provided the testing is done intelligently. The right method is not just a quick launch on each game; you have to target sequences that really push the machine. The big SNK titles are not only famous: they also serve as natural stress tests. They heavily mobilize sprites, sound, cartridge bandwidth, and display timings.

• Metal Slug: explosions, huge sprites, abundance of objects, and saturated scenes.
• Blazing Star: multiple projectiles, high visual density, demanding scrolling.
• Pulstar: excellent indicator of graphical stability and temporal coherence.
• Garou: Mark of the Wolves: rich animation, large assets, and sensitive transitions.
• The Last Blade: refined visual effects, display rhythm to monitor.
• KOF 98 / KOF 2002: high animation volume and varied routines.
• Samurai Shodown II: large characters, impact effects, and rapid combos.

The benefit of a bounded catalog is simple: if the major critical games run cleanly, confidence rises very quickly. It is not a metaphysical guarantee, but it is a much stronger validation than on machines where the number of titles, mappers, or coprocessors makes exhaustiveness almost impossible.

One must also add a practical point: future games officially developed for the AES+ ecosystem will not be designed in a vacuum. They will be tested on the original AES and on the AES+. This naturally tends to smooth targeted behaviors and reduce the risk of modern creations that would depend on an exotic hardware case without real interest for the majority of players.

The real limits to keep in mind

Saying that fear of the 68000 is exaggerated does not mean denying the risk areas. They exist. They are simply elsewhere. The first is the fineness of timings. The second is the electrical compatibility with sometimes worn original cartridges, adapters, or atypical peripherals. The third is everything that goes beyond the main target: flashcarts, multicarts, conversions, aggressive homebrew, and other uses that test the corners of the system rather than its official core.

Flashcarts, multicarts, and homebrew

A modern multicart or flashcart can exploit behaviors that the original machine never had to handle in the same context. Some cards do bankswitching in a very specific way, others play with protections, others still expose less clean writing habits than official cartridges. This is precisely where an FPGA maintains superior flexibility and where an ASIC can face cases that are not a priority for the manufacturer.

Homebrew raises another question. A modern developer may deliberately seek to push an architecture to its limits, sometimes beyond what commercial games of the time actually did. This is not a problem in itself; it is even exciting. But this does not necessarily constitute the right main criterion for judging a console designed primarily to correctly reproduce the historical behavior of the official catalog.

Hardware edge cases and the real scope of the product

We must remain honest about the user scope. The core target of an AES+ is not necessarily the collector who plugs in three exotic converters, a borderline cartridge, and a thirty-year-old modified accessory. The core target is first and foremost the reliable playback of the official catalog and modern productions designed to aim for the broadest possible compatibility. Edge cases matter, but they alone do not define the success of the project.

In other words, an incompatibility with a dubious multicart or a marginal accessory would not carry the same weight as a problem with Garou, Metal Slug, or KOF 98. The machine must be judged first on its main field.

Why the fear of the 68000 distracts from the real issue

The problem with the current debate, fundamentally, is mostly methodological. It draws all attention to a component whose reproduction is already well established, while the real difficulty of a Neo Geo lies in its overall architecture. A Neo Geo is not “a 68000 with a video output.” It is a precise set: 68k, Z80, YM2610, VRAM, LSPC, active lists, separate cartridge buses, specialized ROMs, palettes, fix layer, line buffers, and tight timing arbitration.

In other words, the right question is not “Is the 68000 original?”. The right question is “Is the complete Neo Geo behavior there?”. If yes, then the AES+ can be extremely convincing even without unnecessary mythology around the CPU. If not, even a flawless 68000 will not be enough to save a too approximate reproduction of the SNK machine.

Conclusion: the real question is the SNK architecture, not the 68000

Concerns around the Neo Geo AES+ deserve to be taken seriously, but they must be put in the right order. No, the reproduction of the Motorola 68000 is probably not the weakest link. It is one of the best documented, most studied, and most reimplemented retro CPUs there is. The tools exist, the cores exist, the validation methods exist. On this precise point, we are far from a leap into the void.

Yes, the real challenge lies elsewhere: in the fidelity of the graphics system, the timings, the cartridge buses, the scanline rendering logic, and the overall synchronization between all SNK blocks. This is where the credibility of a hardware AES+ is at stake. But it is also where there are reasons to be less alarmist than some discourse suggests: the machine is well studied, its catalog is testable, and the public state of Neo Geo reverse engineering shows a maturity that is far from embryonic.

The most accurate statement today is probably this: the AES+ looks much more like an industrialization than an experiment. It is not a promise of absolute perfection. It is a healthier way to frame the debate. We can monitor timings, atypical cartridges, and edge cases without turning the 68000 into a false scarecrow.

Ultimately, the real question is not: “Can SNK reproduce a 68000?”

The real question is: “Does the Neo Geo AES+ faithfully reproduce the complete architecture that made the original machine strong?”

If the answer is yes, then the AES+ can be read for what it probably is: an industrialization of Neo Geo hardware already thoroughly understood, tested, and validated, not a risky experiment.

Technical FAQ on the Neo Geo AES+

Does the Neo Geo AES+ really need the original 68000 schematics?

Not necessarily. To achieve compatible behavior, one can rely on official documentation, behavioral reverse engineering, test suites, and existing implementations. The original masks would be a historical asset, not an essential condition to recreate an accurate 68k.

Why is it said that the 68000 is not the real issue?

Because the Neo Geo draws its personality from its video logic, its separate ROMs, the LSPC, and the timings. The main CPU orchestrates the system, but the Neo Geo “flavor” mainly comes from the sprite rendering and the overall behavior of the machine.

Is an ASIC necessarily worse than an FPGA for remaking a retro console?

No. An FPGA is better for fixing and iterating. An ASIC can be excellent if the logic has already been sufficiently validated before fabrication. The medium does not replace the quality of the design.

Which games would be the best compatibility tests?

Games heavily loaded with sprites and animation are the most revealing: Metal Slug, Blazing Star, Pulstar, Garou, or certain KOF titles. These expose issues with priority, bandwidth, or video timing the quickest.

Are flashcarts and multicarts a good indicator of fidelity?

Yes and no. They can reveal useful edge cases, but they do not always represent the main target of a commercial product. A machine can be excellent with the official catalog and more questionable with very atypical modern carts.

What does the already completed reverse engineering work around the Neo Geo concretely change?

It changes the starting level. A large part of the Neo Geo architecture has already been studied, described, and transformed into an exploitable logical base. This greatly reduces the risk of starting from a partial or approximate understanding.