Specifications

Compatibility

Consoles

The Conversion – PC Engine to Turbografx-16

Connector issues solved, the conversion to allow PC Engine games to run on Turbografx-16 is quite simple. All that need to be done is to reverse the pin order of the databus. Ignore the CPLD for now, the CPLD is not even soldered on for PC Engine to Turbografx-16 conversion.

PC Henshin Schematic

The Conversion – Turbografx-16 to PC Engine

The conversion process to allow Turbografx-16 games to run on PC Engine is more complex because Turbografx-16 games (most of them) check which region hardware they are running on. Therefore, you can’t simply reverse the pin order of the databus – you actually have to trick the game into thinking it is running on Turbografx-16 hardware.

Region Check Code

My good friend, Ishiyakazuo, wrote a scanning tool which analyzed all Turbografx-16 roms in the goodset to identify similar biinary data – our hope was that similar data could indicate boiler plate region check code handed down by NEC to Turbografx-16 developers. One would assume that whatever code is performing the region check, even without being familiar with TG-16’s CPU, would look a little something like this:

test regionBit
beq gameCode
bra infiniteLoop

As luck would have it, we found the following code in ALL roms:

0x78 0x54 0xA9 0xFF 0x53 0x01 0xAD 0x00 0x10 0x29 0x80

I’ll leave it to the reader to figure it out as an exercise in HuC6280 assembly. But essentially, you can draw the following conclusions from disassembling this code and analyzing all ROMs:

We only need to detect the first 7 bytes of the pattern since this pattern exists NOWHERE else in any game

To fool the region check, we can simply replace the final 0x80 by a 0x00

Method

Ishikazuo, with a bit of assistance from myself, wrote a VHDL state machine which looks for the 7 byte pattern discussed aboved. The console’s #OE signal is routed through a CPLD, when the 7 byte pattern is detected, the state machine counts the bytes until we reach where the 0x80 should be. At that point, we simply prevent #OE from reaching the HuCard and instead we drive 0x00 on the databus. Sounds pretty straightforward – and really, it’s basically a glorified Game Genie with only 1 function.

One Hurdle

The only hurdle we encountered is that the HuC6280 does a bit of prefetching on certain opcodes. Therefore, this slightly modified the byte pattern we were looking for.

#TODO remember which damn signal is #OE

Instead of hard-coding which bytes would be repeated we simply changed the VHDL state machine to allow most of the byte pattern to have repeated bytes without losing track of the pattern. It’s just better programming that way!