PC Henshin

The PC-Henshin, a Turbografx-16 region converter, was designed in 2013 when I stumbled upon a Samtec connector (SIBF-20-F-S-AD) which I thought was "suitable" enough to jimmy into a Turbografx-16 edge connector.
<p style="padding-left: 30px;"><strong>UPDATE: I have found a source of brand new real HuCard connectors, production will resume on this product once the connector has been fully tested!</strong></p>
[toc]
<h1>The Connector</h1>
The SIBF-20-F-S-AD is a 20 position 0.050" spacing spring-loaded connector. The pin spacing is the same as the a HuCard but the pin count is different since a HuCard has 38 positions. I inquired to Samtec about a 38 position variant but they declined saying that their manufacturing would cause the connector to bow after about 30 positions. Therefore, I decided to use two 20 positions SIBF's side by side.
<a href="http://db-electronics.ca/wp-content/uploads/2016/02/SIBF-connector.png" rel="attachment wp-att-232"><img class="aligncenter size-full wp-image-232" src="http://db-electronics.ca/wp-content/uploads/2016/02/SIBF-connector.png" alt="SIBF-connector" width="326" height="238" /></a>
<h1>The Problem</h1>
When placing two 20 position SIBF's side by side, the problem arises that the pin spacing across the interface of the two connectors is not 0.050" because the edges are wider (see picture below). I had to sand down the inner edges of two connectors in order to maintain a consistent 0.050" spacing across the interface. Obviously, the two outer pins of my "custom" 40 pin connector assembly are useless for a 38 position HuCard but that doesn't really do any harm.
<table class=" aligncenter">
<tbody>
<tr>
<td><a href="http://db-electronics.ca/wp-content/uploads/2016/02/PCHenshin-SIBF.jpg" rel="attachment wp-att-233"><img class="aligncenter wp-image-233 " src="http://db-electronics.ca/wp-content/uploads/2016/02/PCHenshin-SIBF-300x169.jpg" alt="PCHenshin-SIBF" width="301" height="168" /></a></td>
<td><a href="http://db-electronics.ca/wp-content/uploads/2016/02/PCHenshin-Conn.jpg" rel="attachment wp-att-234"><img class="aligncenter wp-image-234 " src="http://db-electronics.ca/wp-content/uploads/2016/02/PCHenshin-Conn-300x169.jpg" alt="PCHenshin-Conn" width="300" height="170" /></a></td>
</tr>
</tbody>
</table>
<h1>The Conversion - PC Engine to Turbografx-16</h1>
<p style="text-align: left;">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.</p>
[caption id="attachment_472" align="aligncenter" width="800"]<a href="http://db-electronics.ca/wp-content/uploads/2016/02/PC-Henshin_1410A02.jpg"><img class="size-large wp-image-472" src="http://db-electronics.ca/wp-content/uploads/2016/02/PC-Henshin_1410A02-1024x663.jpg" alt="PC Henshin Schematic" width="800" height="518" /></a> PC Henshin Schematic[/caption]
<h1>The Conversion - Turbografx-16 to PC Engine</h1>
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.
<h2>Region Check Code</h2>
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:
<pre> test regionBit
beq gameCode
bra infiniteLoop</pre>
As luck would have it, we found the following code in ALL roms:
<p style="text-align: left;">0x78 0x54 0xA9 0xFF 0x53 0x01 0xAD 0x00 0x10 0x29 0x80</p>
<p style="text-align: left;">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:</p>
<ul>
<li style="text-align: left;">We only need to detect the first 7 bytes of the pattern since this pattern exists NOWHERE else in any game</li>
<li style="text-align: left;">To fool the region check, we can simply replace the final 0x80 by a 0x00</li>
</ul>
<h3>Method</h3>
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.
<a href="https://github.com/db-electronics/PCHenshin/blob/master/PCHenshin.vhd" target="_blank">PC Henshin VHDL on Github</a>
<h3>One Hurdle</h3>
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
<a href="http://db-electronics.ca/wp-content/uploads/2016/02/pc-henshin-debug2.png" rel="attachment wp-att-237"><img class="aligncenter size-large wp-image-237" src="http://db-electronics.ca/wp-content/uploads/2016/02/pc-henshin-debug2-1024x551.png" alt="pc-henshin-debug2" width="800" height="430" /></a>
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!
<h1>Design Files</h1>
PC Henshin is comprised of two boards, the main board has all of the components including the CPLD and the carrier board servers as a spacer to get the SIBF connectors at the right distance from the HuCard.
<h2>Gerbers</h2>
<a href="http://db-electronics.ca/wp-content/uploads/2016/02/CAM-for-TG16Converter-rev-e.zip">cam-for-tg16converter-rev-e</a>
<a href="http://db-electronics.ca/wp-content/uploads/2016/02/TG16Carrier_rev_d.zip">tg16carrier_rev_d</a>