The Machine Built in Two Commercial Languages
Neo Geo modding began with a contradiction in SNK’s own design. The AES sold arcade-quality games as premium home cartridges, while the MVS put related software into an arcade machine designed for operators, coin boxes and frequent game changes. Both belonged to the Neo Geo family, but they were never simply the same console in different cases. Their shared architecture made cross-pollination imaginable; their differing interfaces made it difficult.
At the center of both systems was a Motorola 68000 main processor, supported by a Z80 sound processor, Yamaha YM2610 audio hardware and SNK’s custom video circuitry. Much of the game’s identity lived outside the console in its cartridge: program code for the 68000, sound code and samples for the Z80 system, and the enormous graphics data that made Neo Geo games visually distinctive. A cartridge was therefore closer to a removable expansion board than to a small interchangeable game card.
The MVS treated that board as part of an arcade business model. Its service documentation describes cabinet wiring, coin and service inputs, operator settings, memory-card functions and, depending on the motherboard, multiple cartridge slots. SNK’s patent for a machine using plural memory cartridges reflects the same commercial logic: an operator could offer several games while retaining a common platform. The AES presented a cleaner domestic interface, but its motherboard still expected the same broad family of cartridge data and the same fast access to large ROM regions.
That shared software model encouraged the earliest technical curiosity. A developer or technician who understood one machine could recognize the other’s vocabulary—68000 program space, Z80 communication, sprite graphics and cartridge banking—even when the physical boards were different. Yet the edge connectors did not offer a universal plug-and-play standard. AES and MVS cartridges used different shells and contact assignments, and the surrounding system logic supplied different BIOS behavior. A cartridge adapter consequently had to translate an interface, not merely reshape plastic.
From Service Boards to Aftermarket Experiments
The earliest documented experiments are best understood through legitimate development and service hardware rather than through a single heroic origin story. SNK’s development materials describe programmable boards and cartridge-like equipment used to test software before mass production. EPROM development cartridges could hold changing program data while engineers worked on a title, and later flash-based arrangements reduced the need to replace fixed ROMs during iteration. These boards were production tools, not commercial releases, and an unusual daughterboard inside a surviving cartridge is not automatically evidence of a counterfeit.
That distinction matters because the Neo Geo’s physical cartridges invite misleading assumptions. A factory board might contain several ROM packages, custom logic and revisions that do not match a collector’s idea of a standard layout. An aftermarket conversion might use a donor shell, replacement memory or an altered board arrangement. A bootleg might reproduce commercial data on replacement ROMs. A multicart might add switching logic so that several software images appear through one cartridge interface. From the outside, these categories can look similar; electrically and historically, they are different.
A conversion is especially easy to misdescribe. It is not simply any cartridge that works in an AES or MVS. In the aftermarket sense, it generally means a reconstructed cartridge assembled from donor parts, replacement memory or altered boards, often using a legitimate cartridge shell. An adapter preserves the original cartridge boards and changes how they connect to the console. A clone reproduces commercial software on non-factory hardware. A homebrew cartridge contains newly authored software, even when the physical production method resembles that of a conversion. Keeping those terms separate prevents the history from treating every unusual board as the same kind of intervention.
The earliest practical barrier was therefore electrical and architectural. An AES cartridge could not be assumed to function in an MVS slot, or the reverse, because the connector assignments, cartridge shapes and system expectations differed. An adapter needed to route the appropriate signals while preserving the memory regions the game expected. Even then, physical compatibility did not guarantee behavioral compatibility. Arcade software could expect coin inputs, operator settings or MVS-specific BIOS services, while AES software could assume a domestic startup path and controller arrangement. The shared CPU and graphics hardware created an opportunity, not a complete solution.
Why “The Neo Geo Was Encrypted” Is Too Simple
Security arrived in layers and changed over the platform’s commercial life. Early Neo Geo cartridges used comparatively direct ROM arrangements, making the relationship between stored data and the machine’s address space easier to reason about. Later titles introduced more complicated banking, custom cartridge logic and title-specific protection. Describing the whole system as encrypted erases that chronology and implies a single security mechanism where the surviving hardware evidence shows several.
Some later cartridge families used custom devices associated with address selection, graphics handling or protection. The SMA family, CMC graphics and protection devices, and related logic did not all perform the same task. In one generation, custom circuitry could help select banks of program data; in another, graphics data might be transformed or stored in a way that required additional processing before the video hardware could use it. Other arrangements involved latches, serial behavior, checks or cartridge-specific responses. The purpose was not always to conceal every byte. It could be to make unauthorized board substitution, straightforward copying or incompatible reproduction more difficult.
Modern reverse engineering has made these distinctions clearer, but that record is a later reconstruction rather than an SNK security specification. Engineers studying surviving boards have traced address lines, compared data regions and documented how protection devices interact with the console. Their work can explain what a mechanism accomplishes without turning the article into a bypass manual. The important historical point is that SNK progressively made cartridges more like active hardware platforms: they did not merely store data, but could participate in banking, decoding and compatibility decisions.
AES and MVS versions also need to be kept apart. A game released for both systems might share substantial software and content while using different board arrangements or relying on different system-side behavior. Protection could live mainly on the cartridge, depend partly on the motherboard, or be organized differently between home and arcade versions. That is why a board transplant is not equivalent to copying a file. The replacement must reproduce the memory map, signal behavior and special logic expected by that particular software generation.
This growing complexity shaped the scene’s earliest experiments. A simple programmable ROM could demonstrate that code ran on the processor, but a complete cartridge had to provide graphics regions, sound data and any required banking or protection behavior. Developers working with legitimate test boards learned that the Neo Geo was not merely a large collection of read-only chips. It was a system whose cartridge architecture had become part of the platform’s security boundary.
The Arcade Home Divide in Practice
The MVS made experimentation attractive because its design assumed maintenance and replacement. Operators were expected to open cabinets, change games and configure machine behavior. Service manuals document motherboard revisions such as single-slot and multi-slot arrangements, with differences in wiring, controls and cabinet functions. A technician could therefore encounter several physical expressions of the same broad architecture without treating them as identical boards.
The AES’s domestic cartridges and the MVS’s operator-oriented distribution gave enthusiasts a practical reason to study compatibility. An owner with access to an MVS edition could want to play it through home hardware, even though its physical interface was different. Price and availability varied by title and market; the enduring technical question was how to bridge the formats without pretending they were identical.
An adapter is the cleaner technical answer. It retains the original MVS or AES boards and translates the physical connection so that the destination system can address them. The cartridge remains what it was, with its original memory organization and any protection components intact. A conversion takes a more invasive route, changing or rearranging hardware so that a title is presented in a different physical format. The result may be useful to a collector, but it is an aftermarket reconstruction rather than an original SNK release.
The difference also affects preservation. An adapter can preserve the evidence contained in an original board: chip markings, routing, custom devices and revision history. A conversion may preserve the software experience while sacrificing some of that physical evidence. Neither category is automatically superior, but they preserve different things. A factory AES cartridge, an original MVS cartridge used through an interface adapter and a converted aftermarket cartridge can all put the same title on a screen while telling three different hardware stories.
Even software identity could be complicated. MVS and AES releases sometimes differed in startup behavior, available settings or regional presentation. The BIOS determined part of that experience, and later replacement BIOS projects would make those distinctions more visible. But before enthusiasts could conveniently select modes from a menu, the differences were embedded in the relationship between cartridge, motherboard, controls and system firmware. Hardware compatibility was therefore inseparable from software configuration.
The CD Route Changes the Problem
When SNK moved the Neo Geo platform to CD-ROM, it solved one commercial problem by creating another technical one. Cartridge production was expensive because a game required a substantial collection of ROM chips and a specialized board. A disc could carry large amounts of data more cheaply, and SNK’s catalogues positioned the Neo Geo CD as a way to make software more affordable. But the CD system could no longer fetch program, graphics and sound data with the near-immediacy of cartridge ROM.
The Neo Geo CD retained the broad 68000-based family and much of the platform’s visual and musical identity, but added approximately 7 MiB of cartridge-like DRAM rather than one undifferentiated working-memory pool. That allocation comprised 2 MiB for 68000 program data, 4 MiB for sprite graphics and 1 MiB for ADPCM data, with additional RAM and PSRAM for FIX-layer tiles and the Z80 program. Data had to be loaded from the disc into those regions before the processor and video hardware could use it. Contemporary coverage emphasized the resulting waits, which could stretch into tens of seconds in larger games.
The problem was not simply that the disc spun slowly; software had been designed around a different storage path. A cartridge system could address its installed ROM regions as part of the normal execution environment. The CD system had to request data through a drive and stage it in specifically organized memory. Replacing the disc with solid-state storage is therefore an exercise in reproducing a protocol and its expected timing, not just copying files onto another medium.
The CD family itself was not uniform. Front-loading and top-loading machines used different physical arrangements, and the later CDZ revised the loading experience. SNK’s retrospective confirms that the CDZ was intended to load faster, while contemporary material also records discussion of a faster-drive revision. The exact mechanism remains less certain than the broad result. It is safest to call the CDZ a revised, faster-loading Japanese model rather than reduce it to an unquestioned “double-speed” specification. Surviving commentary has differed over the contribution of drive speed, caching and other system changes.
Memory storage also differed among the family members. The AES and some MVS cabinets support removable JEIDA memory cards, while Neo Geo CD machines had no external memory-card slot; instead, they incorporated an 8 KiB battery-backed SRAM area that served as a virtual card. Any modern replacement or emulator that mishandles CD saves, cartridge-system cards or CD audio reproduces only part of the original platform. Storage, execution, sound and user data were interdependent in SNK’s design.
New Software Proved the Platform Was Still a Target
A major middle-era development was the move from preserving old software to authoring new software. NGDEV, formerly NG:DEV.TEAM, provides a prominent documented commercial example. Its own account records a long sequence of projects for AES, MVS and Neo Geo CD, beginning with Last Hope and continuing through later releases such as Kraut Buster. That company history does not prove that NGDEV was the first group to create Neo Geo homebrew, or that its chronology represents the entire scene. It does show that new, professionally produced software could be designed and sold for a discontinued platform over many years.
These independent releases occupied several scales, from experiments to professionally released AES, MVS and Neo Geo CD products. NGDEV’s documented catalogue demonstrates sustained independent publishing, without establishing that one company originated the entire aftermarket scene. For players, the important change was tangible: a discontinued console could receive a newly authored game instead of only another reproduction of its old library.
Open development kits broadened that opportunity. Dciabrin’s ngdevkit provides a 68000 toolchain, C and C++ support, Z80 development facilities, graphics tools, an open test BIOS, emulator integration and source-level debugging. NGDK offers a separate development environment with its own build assumptions and examples. These projects expose the machine’s direct concerns: video RAM, palettes, sprites, fixed-layer tiles, interrupts, sound commands and the division of data into the platform’s familiar ROM regions.
That directness is both an advantage and a constraint. A developer gains control over the Neo Geo’s distinctive visual style, but must manage resources that modern engines normally organize automatically. Sprite counts, palette use, graphics conversion, sound-memory planning and timing remain part of the design. Emulator iteration can accelerate development, but a successful emulator build is not proof that a title behaves identically on every AES or MVS motherboard. A result should therefore be identified as emulated, run through a flash device, demonstrated on original hardware or manufactured as a physical release.
Small community projects reveal this learning process clearly. SeaFighter describes itself as a game-mode API intended to share handling across arcade and console contexts while acknowledging unfinished work. That repository is evidence of an active attempt to abstract recurring platform problems, not evidence of a completed universal framework. The scene advanced through partial libraries, test BIOSes, graphics utilities and emulator-assisted debugging as much as through finished games.
SNK’s Reaction Was Commercial and Corporate Before It Was Technical
SNK’s business model combined operator-replaceable MVS software with a separate premium home-cartridge channel. Seen in that light, the design offered flexibility within each market while preserving a physical divide between them. This is an interpretation of the two distribution models, rather than evidence of a single corporate policy toward every later modification.
Third-party adapters and conversions operated across that divide. They changed the route by which software reached home hardware, while accessories and branding raised their own commercial disputes.
The documented SNK v. Hori case concerned third-party controllers and the use of “NEO” and “GEO” branding. Its significance lies in the way SNK asserted intellectual-property and unfair-competition interests around accessories and platform identity, not in a judicial ruling on conversions or homebrew software. The later SNK/Playmore litigation involving Aruze dealt with ownership and use of SNK intellectual property after the company’s financial collapse. That corporate history helps explain why rights and branding became sensitive, but it does not create a general rule for every enthusiast modification.
Those cases should not be read as a general judicial approval or prohibition of MVS-to-AES conversions. Accessories, original software, copied game data and platform branding raise different questions.
Replacement BIOSes Became Research Instruments
UniBIOS remains one of the clearest examples of a modification whose importance extends beyond convenience. As a replacement system ROM, it operates before the game itself and exposes choices that the factory BIOS normally presents as fixed. Region selection, AES and MVS-style system modes, memory-card management, diagnostics, jukebox functions and game-specific options turn the BIOS from an invisible startup component into an instrument for examining the platform.
Its limits are just as important as its features. Selecting an MVS-style mode on an AES changes the software environment but does not add coin switches, a multi-slot motherboard or every arcade-specific input. Selecting AES-style behavior on an MVS does not remove the cabinet wiring or change the board’s physical identity. The mode is a BIOS-level configuration, not a universal hardware conversion. Some titles also depend on particular cartridge arrangements, system revisions or assumptions that a menu cannot resolve.
That makes UniBIOS valuable to preservationists even when they do not want its cheat or region features. It can expose settings, test memory and compare AES and MVS behavior on original hardware. At the same time, it should not be mistaken for an official SNK accessory or a neutral restoration. It is a later community intervention that adds a documented research and control layer to an aging machine.
Flash Cartridges Replace a Cartridge-Side Function
Modern flash cartridges are often described as storage devices, but the more capable examples do substantially more. An SD card supplies files; a controller and programmable logic interpret those files, prepare data and present the selected software through the Neo Geo cartridge interface. Once loaded into the cartridge’s flash or working memory, the game can behave much more like a conventional cartridge than like software continuously streamed from removable storage.
That design is necessary because Neo Geo cartridges were not uniform containers. Different generations used different program layouts, graphics arrangements, banking methods and custom protection devices. A universal replacement must therefore reproduce more than a collection of bytes. FPGA logic is useful because it can model several hardware arrangements rather than presenting one fixed ROM map.
Terraonion publishes a specific supported-title list for NeoSD Pro AES CD games. This is a cartridge-side implementation for a defined selection of titles, not the entire Neo Geo CD library or an automatic feature of the ordinary NeoSD, MVS products or every firmware version. It supplies an alternative execution route rather than retaining the original optical drive.
Darksoft’s NeoGeo Multi MVS/AES is a separate design using flash and DDR memory, with distinct AES and MVS physical versions. Its memory strategy, menu, update process and handling of unusual software are not interchangeable with NeoSD products. A multicart may use switching logic to select a defined set of images, while a development-oriented flash cartridge may accept new packages and implement several mapping strategies. Both provide multiple games through one physical cartridge, but they are not equivalent designs.
The BIOS and cartridge can form separate layers, but their division of control is model- and firmware-dependent. A product may provide its own launch menu while the installed BIOS determines some region, system-mode or startup behavior; another configuration may expose those choices differently. UniBIOS remains a system-ROM modification, whereas a flash cartridge remains a cartridge-side device. Neither should be treated as a universal substitute for the other.
Exact compatibility consequently needs qualification. Product manuals establish advertised features and documented limitations; they do not independently prove universal behavior across every console revision. A useful account identifies the product model, documentation or firmware generation, AES or MVS hardware and whether the result concerns original commercial software or newly authored work.
Neo Geo CD Loaders Replace the Optical Path
Replacing the Neo Geo CD drive presents a protocol problem. A loader design has to communicate with the console’s CD control system and supply data in a form the software expects. The SD card is only the storage medium; successful behavior depends on the implementation between that storage and the console.
Furrtek’s project was published as an SD-based replacement path for specified top-loading and front-loading Neo Geo CD hardware. Its repository establishes the design files, firmware, CPLD material, patches and intended hardware scope; it does not establish universal compatibility, CDZ support, identical performance or successful operation from every fabricated copy.
By replacing the original optical pathway, an internal loader can reduce dependence on worn mechanical components and may change loading behavior; the result must be limited to the documented hardware and firmware configuration. A repaired optical assembly makes a different preservation choice: it retains the mechanical system and its delays while depending on components that may be difficult to source or maintain. Neither approach is the single authentic answer.
CD audio and save behavior remain separate questions. A loader that supplies program data but mishandles audio tracks does not reproduce the complete software experience. Likewise, a setup that launches games but loses the CD system’s internal 8 KiB battery-backed virtual-card behavior preserves playability without preserving the original user-data system. These are distinct evaluation points, not assumptions that can be made from the presence of an SD card alone.
A Platform With Three Histories
The platform endured because its unusual commercial design created durable technical questions. AES, MVS and CD each solved one problem while creating another, and later developers answered those problems with adapters, firmware, cartridge logic, loaders, tools and new software. The result is not a single unlocked system, but a continuing history of three machines and the communities that learned to keep each one legible.
Explore more modding histories
Compare these experiments with our original PlayStation modding history, original Xbox modchip and homebrew history and Dreamcast boot discs and homebrew story. Find more long reads in Editorial Spotlight and explore our game walkthrough library.
