Neo Geo core for TC64

This is a port of the SNK NeoGeo FPGA implementation by Furrtek

Ported to MiST by Gyorgy Szombathelyi

Ported to Turbo Chameleon 64 by A. M. Robinson

This is an experimental core, and while I do my utmost to make sure it works for everyone and will try to help solve any problems that arise, you run this core entirely at your own risk.

If you’d like to show your appreciation for this core, or motivate me to work on this and other cores in future, donations are welcome at or Anyone donating £20 or more via PayPal or sponsoring on Patreon at the second tier will be thanked by name in a “Core Supporters” shout-out page in subsequent releases.

Please note: it’s vitally important that you download the correct version of the core for your Chameleon.

NeoGeo for Chameleon V1 hardware: If you have a single mini-DIN socket on the left hand side of your Chameleon, to which a breakout cable attaches for the keyboard and mouse, then you have V1 hardware and need this version:

NeoGeo for Chameleon V2 hardware:  If you have three mini-DIN sockets on the left-hand side, with the keyboard and mouse plugging in directly, you have V2 hardware, and need this version:


The original Neo Geo system has big RAM/ROM memories, which don’t fit into the BRAM of the MiST’s FPGA. A new SDRAM controller was written, which can read one 64 bit and one 32 bit word simultaneously in just 12 cycles using bank interleaviMiSTng, and running at 120MHz. Later on, it was replaced by a 96MHz variant reading two 32 bit words in 8 cycles. Since the Turbo Chameleon 64 has just 32 megabytes of SDRAM, this version of the core supports ~6 MiB PROMS and 24 MiB CROM+VROMs (in any size combination)


Internal ROMs (System ROM, SFIX, LO ROM and SM1 ROM) can be created from MAME’s with the help of the MRA files.

TerraOnion .NEO file format was choosen as the supported cart format, as it conveniently merges all the various ROMs in one file. The following utilities can be used to create such files:

Original NeoBuilder tool

Darksoft to .neo conversion tool

MAME to .neo conversion tool – please note many MAME Neo Geo ROMs are encrypted, and these are not supported by the core, so it’s recommended to use the Darksoft collection instead.


The NeoGeo has four fire buttons, as well as start and select buttons – and in Arcade configurations there are coin buttons too. On the TC64 the PS/2 keyboard, C64 keyboard and CDTV control pad are all supported.

Gamepad 1

Gamepad buttonPS/2 keyboardC64 keyboardCDTV controller
ARight CtrlN / PeriodButton A
BRight AltB / SlashButton B
CRight WinCommaVol Up
DRight ShiftMVol Down
SelectSlashEqualsFast Fwd

Directions on the C64 keyboard are mapped to I, J, K, L and the cursor keys.

Gamepad 2

Gamepad buttonPS/2 keyboardC64 keyboardCDTV controller
ALeft CtrlCButton A
BLeft AltVButton B
CLeft WinZVol Up
DLeft ShiftXVol Down
SelectZRun/StopFast Fwd

Directions on the C64 keyboard are mapped to W, A, S and D.

Mouse (trackball) support for the game Irritating Maze can be selected in the OSD. Middle mouse button is Start. Note: this game requires its own system BIOS.

Memory Card

A 8K (8192 bytes) empty file can be used as a memory card. It can be loaded-unloaded and saved via the OSD (use a .SAV extension). Hint: rename it to NeoGeo.vhd and it’ll be auto-mounted. One memory card can store progress and high score information for a couple of games.

Sidenotes (from Gyorgy):

The upstream MiSTer core was inherently unstable. While Furrtek (Sean Gonsalves) did a very good and tedious job reverse-engineering and documenting the original Neo-Geo chipset, the resulting HDL is not very good for FPGAs. Probably MiSTer’s Cyclone V FPGA can deal with it better, as it’s built in a newer process, has smaller inner delays, has more clock networks, or the more recent Quartus tool is better synthesizing such code, but it still broken. Translating old ASIC designs 1-1 into FPGA won’t work, as there are dozens of generated signals (even with combinatorial output) used as clocks, which are glitching, the compiler cannot check if flip-flops clocked by these signals meet setup and hold times, resulting in very unstable cores.

At the end, the core’s HDL was converted into synchronous code, using a simulator to check if it still produces the same signals as before. Finally all latches were eliminated, and all generated clock usages were removed.

Thanks to all who supported this conversion!