Current status
RGen is working under Windows, with four game profiles, asset maps and direct-memory saves. Development and compatibility testing are ongoing.
Four games
Golden Axe, Herzog Zwei, Sonic the Hedgehog and Streets of Rage. Each requires the exact matching ROM revision, size and CRC in its game profile.
Asset maps for all four
Builds package art.bin, sound.bin, gamedata.bin and assets.idx using precomputed maps. No game window launches to trace assets during the build, and generated game folders do not need rom.bin.
Direct memory — not replay
Save and restore CPU, RAM, video, machine state and suspended execution directly. Save/load measured about 0.3–0.5 seconds in the latest Wine tests. Fresh-process loads matched 60 of 60 continuation frames per game. Rebuilds can invalidate old saves: create new saves after updating.
Build 17134 startup fixed
The execution backend now handles the absent shadow-stack policy query on older Windows 10 correctly. Security settings are not disabled. Genuine initialization failures stop with an explicit error rather than a silent blank screen.
Gameplay, input and saves
All four freshly extracted builds passed automated active gameplay tests under Wine. Packed assets reconstructed the exact source ROM; packed-versus-original framebuffers and saved-state digests matched. Same-process and restart/load tests passed, with changing scenes and response to new controls.
INSTALL: EXTRACT INTO A NEW FOLDER → ADD YOUR OWN MATCHING ROM → REBUILD EACH GAME → CREATE NEW SAVES.
Asset maps preserve all cartridge bytes; their art/sound labels follow observed coverage, not exhaustive semantic extraction. Some compressed sound-driver data remains in gamedata.bin.
The pipeline
Four stages turn a 1990 cartridge dump into a modern executable. Pick a stage to read what actually happens inside it — then run the simulated build below it.
Start with a dump of your own cartridge
RGen reads the ROM image, checks the header, and loads the game's RAM layout profile — a small per-game map of where the game's mode flag, VBlank counters, and stack live in the Genesis's 64 KB work RAM. That profile is what lets translated code run interrupts and the stack exactly where the original hardware expected them. Herzog Zwei's profile, for example, places its stacks at $FFF780.
INPUT: backup copy of a cartridge you personally own. No cartridge ROMs or extracted cartridge payloads are included; third-party code retains its own licenses.
68000 code becomes C
The recompiler translates Motorola 68000 instructions into C. A Genesis runtime supplies video, sound, input and timing, with Z80 sound-CPU support and runtime interpretation where required. Static recompilation is the main execution path; it is not a claim that every processor or instruction is fully translated ahead of time.
STATIC TRANSLATION: SUPPORTED 68000 CODE IS COMPILED AHEAD OF TIME; HARDWARE AND CPU-SUPPORT RUNTIMES REMAIN.
A portable toolchain builds the .exe
The generated C is compiled with the Tiny C Compiler that ships inside the RGen folder and linked against prebuilt runtime libraries (SDL2 for window/input/audio, ymfm for FM synthesis). The result is a self-contained game folder: one executable plus its art, sound, and game-data files extracted from your ROM at build time.
NO CMAKE. NO VISUAL STUDIO. NO INSTALLS. UNZIP, BUILD, PLAY.
The game runs as itself
What launches is a native Windows program executing the game's own logic as compiled code — the same speed-and-sound parity bar RGen is developed against. A one-time Personal Use Notice appears on first launch of every generated game; after that, it's just the game, at 60 fps, with its original FM soundtrack.
TO RUN: the complete locally built game folder. NO RGEN INSTALLATION OR ROM.BIN REQUIRED.
Not an emulator
An emulator pretends to be a Genesis, every frame, forever. A recompiler does the pretending once, at build time — then gets out of the way.
| Emulator | RGen recompiled game | |
|---|---|---|
| How the game runs | A program interprets 68000 and Z80 instructions one at a time, every frame | The game's code is translated to C once and compiled to native machine code |
| What you install | The emulator; every game depends on it | Nothing — each built game is a standalone .exe |
| Who needs the tool | Every player | Only the person building the game; players just run it |
| Hardware accuracy | One-size-fits-all chip emulation | Per-game RAM layout profile + chip runtimes (VDP, YM2612, PSG, Z80) |
| Speed ceiling | Interpreter overhead on every instruction | Native code — the parity target is the reference emulator's speed and sound |
Spec sheet
What's under the hood. Every component exists because a real Genesis subsystem demanded it — usually discovered the hard way, mid-boot.
68000 → C recompiler
Static translation of the main Motorola 68000 code into C, with interrupt and stack behavior driven by each game's RAM layout profile.
Genesis VDP runtime
Tile planes, sprites with hardware priority ordering, and backdrop handling modeled on the real video display processor.
YM2612 & SN76489
FM synthesis via the ymfm core and the PSG's square-wave channels, mixed to SDL2 audio — the soundtrack is generated, never recorded.
Z80 sound-CPU runtime
The sound CPU is supported by a Z80 runtime with bus and timing integration. YM2612 FM and SN76489 PSG chip models generate the audio. This is hardware/runtime support, not a promise of fully static Z80 translation.
Portable TCC build
Tiny C Compiler, import libraries, and a response-file link step ship in the folder. No compiler installation is required — no Visual Studio, no CMake.
RAM layout profiles
Each supported game carries a profile (mode flag, VBlank counters, stack addresses) derived from ROM analysis — e.g. Herzog Zwei: mode $FFF924, stacks $FFF780.
Two ways in
RGen draws a hard line between the person who builds a game and the person who plays it.
Build a game with RGen
- Unzip the portable package — RGen, the TCC toolchain, and per-game folders, ready to go.
- Pick a game and drop in your ROM — a backup dump of a cartridge you own.
- Set options and hit Build — RGen recompiles and links a standalone game folder.
- Keep the complete folder for personal use — the .exe, DLLs and extracted data files. Do not distribute generated games or cartridge-derived assets.
Just play
- Get a built game folder — one .exe and its supporting data files.
- Keep the locally generated asset files and DLLs beside the EXE. The completed package does not need rom.bin.
- Read the one-time Personal Use Notice, confirm you own the original cartridge.
- Play — native speed, original FM soundtrack, standard controller support.
Use
Notice
The rule baked into every build
RGen is for use with backup copies of Sega Genesis cartridges you personally own. Every generated game shows a one-time notice on first launch: personal use only, original-cartridge ownership required, and no distribution of the game or its data files. RGen ships no game code and no ROMs — what you build comes entirely from the cartridge already on your shelf.
Questions
Is RGen an emulator?
No. An emulator interprets the game's 68000 and Z80 instructions at runtime. RGen statically recompiles supported 68000 code into a native Windows program. Hardware runtimes and CPU-support interpretation still exist; it is not an all-instructions, all-CPUs static translation claim. Chip behavior (VDP, YM2612, PSG, Z80) is still modeled in the runtime for the translated code to interact with.
Do players need RGen installed?
Never. RGen is the builder's tool. A finished game is a folder with an .exe and its data files; players run their locally built game directly, with its packaged assets and DLLs.
Does it need Visual Studio or an installer?
No. The portable package carries its own Tiny C Compiler toolchain and libraries. Unzip it and build — that's the entire setup.
Is this legal?
RGen contains no game code and is designed for backup copies of cartridges you personally own; every generated game enforces that with a first-launch Personal Use Notice and a no-distribution rule. If you don't own the cartridge, don't build the game.
Who makes RGen?
Jason Meehan — who also wrote the VGen emulator back in 1998. RGen is the sibling project: same love of the Genesis, opposite technique, twenty-eight years later.