Region locks and licensing restrictions. Nintendo’s are famous; we’ve talked about Sega’s already. But what about everyone’s favorite third-place winner, NEC/Hudson’s PC Engine/TurboGrafx? Well, the short answer is, there aren’t any for the CD, and HuCards are incompatible. But stay tuned for the long answer…
We’ll start out with the HuCards. These credit-card sized cards contain a tiny PCB on them, just hidden by a plastic shell, and epoxied in. I can’t bring myself to destroy any of mine to confirm, though… But essentially, though they may not look like it, they’re just cartridges.
As far as licensing restrictions go, there are none. Every released PC Engine and TurboGrafx console will at least try to run whatever HuCard you put into it. They can do nothing else; they either don’t have a ROM, or only use that ROM for the built-in CD drive (the Duo systems). A computer with a ROM chip connected into its data and address buses will boot from that ROM.
It’s possible that Hudson Soft thought that the difficulty of making HuCards (it is more complicated than putting a standard PCB in a plastic shell, like most cartridges) was enough to deter other manufacturers from avoiding the licensing process, but if so, they were disappointed. Unlicensed HuCards existed in Japan during the consoles’ life, and new ones are still made today, too.
Hudson came up with a clever solution to region protection on the PC Engine’s North American release, the TurboGrafx-16. The only difference is that the data bus lines are reversed; the eight physical lines are wired in the opposite order. This has some nice properties; it makes using cartridges across regions impossible, but means that no changes are needed to HuCard manufacturing. (I’ve read, but can’t confirm, that HuCards for the US used the same wiring, but the ROM chips themselves had the opposite data order written to them)
It does, however, mean that ROMs are not interchangeable. You might remember from the Sega post that Mystic Defender and Kujaku Oh 2 are the same physical ROM, with the same data in different regions. The data bus reversal, though, means that PC Engine developers can’t do that. Consoles from different regions can’t read ROMs from different regions. Therefore, there’s no need for software running on the system to be able to tell what region it’s on; in theory, it should always know.
You need only a passive adapter to change between regions. And there’s an interesting property here; a cartridge converter from US to Japanese consoles can also work in the opposite directions; if you reverse the bits twice, you just get back what you started with.
You might wonder how built-in region mods work; these use a set of electrically controlled switches, and physically break the console’s data bus. It’s a clever solution and cleaner than an external adapter, but be very careful! You want to make sure you don’t draw too much power from the HuCard slot, and you also want to keep your wires as short as possible, or you might screw up the electrical signal timing. The 7.1MHz signals of the PC Engine aren’t as forgiving as the 1.7MHz signals of the NES.
That being said, my PC Engine Duo R does have a region mod, done by a reputable modder, and it works great.
Wait a minute!
I said the following things in the sections above:
- Every released PC Engine and TurboGrafx console will run whatever HuCard you put into it, as long as it can read the data
- The only difference between North American and Japanese consoles is that the data bus lines are reversed
- Software running on the system isn’t able to tell what region it’s on
- You need only a passive adapter to change between regions.
The last point is particularly suspect; the adapter I showed a picture of, the dbElectronics Turbo PC-Henshin, has a big chip right on it. And people who have watched videos of modding a Japanese console, or who have done so themselves, might object to the other points as well. What’s going on here?
I said that software running on the TurboGrafx-16 can’t tell what region it’s in. But if you look at chibiakuma’s excellent tutorial on reading the PC Engine joystick, you’ll notice that he lists a bit of the joystick port as being a region detect. But why would that be on the joystick, anyway?
To answer that, we need to talk about the HuC6280. It has eight-bit input and output ports; you might compare these to the general-purpose input/output (GPIO) ports on something like a Raspberry Pi, but these aren’t general purpose. You have eight wires that are always inputs, and eight that are always outputs. On the PC Engine these are used for the joystick ports; you can send some signals out to the joystick, but only four bits are used that you can read back. You need to do multiple reads to get all eight buttons, but that’s totally fine– the NES can only read one bit at a time, so this is four times as fast! (The SNES uses the same serial method as the NES, as does your USB controller, so don’t worry too much about it)
But that leaves four input lines unused. On this TurboGrafx 16 schematic, the input port are listed as K0 through K7. Two of them, K4 and K5, are outright not connected. One, K7, goes to the port in the rear, where it is used to detect when something is plugged into the expansion ports. (On Duo consoles with a built-in CD-ROM drive, this pin is just set up to always be connected)
And finally, one, K6, is set to 1 on all released US consoles, and 0 on Japanese consoles. (You can see that it’s connected to ground through a resistor on this schematic) Why? What’s my problem, claiming this isn’t a region pin?
Software region detection
On the Sega article, I talked about Virtua Racing. Like many later Genesis games, it detects whether the console is in the correct region, and gives you a message complaining if it’s not.
From the console’s perspective, this isn’t a region lock, because the code is running fine. From the gamer’s perspective, that’s not very helpful. And indeed, if you run an American game in a Japanese console with a pin reverser that doesn’t do anything else, well, you might get something like this:
No message. So what’s going on here?
Digging into the code
Nearly every single US game has the following code:
lda #$FF ; Load the IO bank tam0 lda $1000 ; The input port and #%01000000 ; Check bit #6 (region detect pin) beq label ; Jump to label if check succeeds, otherwise continue lda #$90 ; Map bank #90 into memory region tam2 jmp #$4000 ; Jump to the memory we just mapped .db " NEC" ; Not code, just a string of bytes ; corresponding to ASCII " NEC" label: ; The rest of the game continues from here
Hopefully you can get the gist of what’s going on from the assembly instructions, I tried to comment as best I could.
tam is a special instruction to map the value of the “accumulator” (which
lda loads a value into) to the Hu6280’s memory map; remember, while it has access to a much larger external address space, it can only have 64kB available to its internal memory, because its CPU is, at its core, a 6502 much like the NES.
The thing is, there’s nothing at bank 0x90! So it basically maps in nothing, and then jumps to it. It’s not surprising that this wouldn’t work. (Special thanks to the PC Engine Software Bible Forums for their documentation work here, it’s invaluable)
So I guess you could think of this as a region lock. But it’s a pretty weird one. No equivalent checks exists on any Japanese games, so most region mods (including on my Duo R) will just set that pin to 1. The chip on the converter I showed has to be a little smarter than that to work externally; it looks for the region check code above, and overwrites the branch instruction.
What follows here is speculation, and I don’t have a TurboGrafx-16 to confirm. However, Wikimedia Commons user Evan-Amos does, and they were kind enough to share its motherboard to the world.
You might see the two lines of pins labeled “CN102”. These are the HuCard slot (or is it a TurboChip slot?); we’re looking on the opposite side here. On the left, you see a bunch of through-holes filled with solder labeled “IC107”, and on the right, a square of copper surface-mount pads labeled “IC108”. These are both unpopulated chips; they’re a huge part of the TurboGrafx motherboard that differs significantly from the Japanese equivalent, and no one ever bothered to install the chips!
IC107 was likely a boot ROM; the 23c1000 is a common NEC mask ROM code. (I’m struggling to find a pinout) IC108 is marked uPD65006, which appears to be an NEC code for a gate array; a gate array is a specialized processor whose purpose is burned into it after production. (You can compare to a “field-programmable” gate array, or FPGA, a general-purpose set of gates whose arrangement can be changed multiple times) So what its exact purpose isn’t known, but it likely just handled glue logic for the BIOS ROM, and maybe whatever restriction was implemented. If I had a TurboGrafx, I’d consider tracing out the pins.
My speculation here is that NEC and Hudson were leaving an opening that they failed to do in Japan. If anyone produced unlicensed games in the US, they could have included the parts and locked them out. But it was cheaper to leave off the extra ROM. All developers were told in Hudson’s documentation that they had to include this code, and if they ever decided to add a licensing check, they could add a ROM and change the value at the pin. That’s why I don’t think it’s a region pin– I think it’s a “boot ROM present” pin, but only on US consoles. The boot ROM may have looked for the “NEC” string to decide whether to allow access to the video hardware.
Consider TMSS on the Genesis. If companies like EA and Accolade hadn’t gone around Sega’s licensing, they probably would never have bothered to release consoles with it present; even tiny ROMs add extra cost when you’re making consoles at scale. And then we’d be writing blog posts wondering why all these games are writing “SEGA” to a magic address for no reason.
The TurboGrafx-16 was, rather infamously, not as successful as NEC and Hudson had hoped. Unlike in Japan, no one ever bothered releasing unlicensed games on this side of the Atlantic. So they never had any reason to add a boot ROM. In Japan, where it was more successful, they didn’t leave these provisions, so they couldn’t add a license check there either.
It’s common knowledge that the TurboGrafx-CD and PC Engine CD have no region protection (games can be interchanged between regions at will), and no protection against using CD-Rs, except for worn out CD lasers potentially having trouble reading them. So, end of blog post, right?
But if that’s the case, why does this exist? This is a Japanese unlicensed game, CD Bishoujo Pachinko. (You can probably guess what sort of game it is) And it comes with a special CD-ROM system card!
And no, it doesn’t boot without it.
So why does it need a separate card, if the CD consoles are unprotected? And why does this game claim that it only works on the Duo consoles?
Before we go into that, an aside on the Games Express card. You might wonder what happens if you try to use this BIOS to run a legally licensed CD-ROM game. It doesn’t work; in fact, the Games Express BIOS errors, so it may be checking for its own special code. In any case, most if not all licensed games use functions in the official BIOS, so I doubt this could ever work.
Licensing strikes again
So, I’m working on a TurboGrafx-CD game, Space Ava 201. Unfortunately, Nicole Express is a tiny operation and we aren’t able to get official licenses from NEC. I hear they might have “exited the video game business over twenty years ago” anyway. And my unlicensed game works just fine without needing a special unlicensed HuCard to boot. Am I just a better coder than Games Express?
No. It’s just that CD Bishoujo Pachinko was released in Japan in January 1995, and Space Ava 201 is being developed in 2020 in the United States. Let’s dig into the data track using a hex display.
See? Space Ava 201 contains quite a lot of NEC credits, claiming that it’s licensed by NEC Home “Electoronics”. Sure, in the US that could probably be considered to be legal even in 1995, thanks to Sega v. Accolade, as that’s necessary for interoperability. But that’s American law, not Japanese. (And honestly, NEC isn’t going to sue me in 2020, when they don’t even have a console licensing business) Trademark-based checks still had a lot of teeth in Japan, where Games Express was based and sold its wares, and in Taiwan, where Games Express had its games manufactured.
So you won’t find that string in CD Bishoujo Pachinko. In fact, at the start of the data track, you won’t find much of anything.
And as for why it only works on Duo consoles? It’s actually pretty simple. This is a Super CD-ROM2 game. Apparently Games Express felt that sexy pachinko really needed that extra 192kB of work RAM. But on a pre-Duo console, you needed the Super System Card to provide that RAM. You can only have one HuCard in at a time, so it’s only on the Duo systems that Games Express’ CD card can activate the RAM. Japanese HuCards have no licensing protection, so there wasn’t anything NEC could do about this.
There’s one interesting possibility that occurred to me. The Turbo Everdrive 2 uses onboard RAM to map HuCards into; people have found this allows it to be used as a Super System Card, which also maps RAM into HuCard space. So, does a Turbo Everdrive 2 with the Games Express BIOS allow you to run CD Bishoujo Pachinko on an original CD-ROM2 interface unit? (I’ll be testing on a SuperGrafx, but of course this game has no special features for it)
Nope. It may be possible to patch either the system card or the game, but given that it’s not really that worth playing…
Games Express could’ve produced their own clone of the Super System Card, but that would’ve made their games even more expensive. CD Bishoujo Pachinko came out in 1995 for ¥8,900. In 2020, that’s be ¥9,313; $88.65 in 2020 US dollars. Not cheap even by 90’s standards, but actually pretty good for both a HuCard and a CD combined.
And one more exception…
This is A III: Take the “A” Train. It’s a railroad simulation game; the Windows 95 version was released in the US by Maxis, because it fit well alongside their other simulators like SimCity. It’s also very complicated, it’s a double-width box just because of how thick the manual is.
But let’s say that you didn’t like Maxis’ release, and decided to import this game to the US to play on your Turbo Duo. Maybe you just really love playing in-depth simulation games with the controller. Well, there’s a little slip of paper in the box…
Oh, sorry, hopefully a monopoly search engine can translate that for me.
It’s not perfect, but I think you can get the gist. Not supported overseas? I’m not sure what that could mean, probably just the typical Japanese developed game warning, right? We should consider ourselves lucky that they aren’t threatening to prosecute us to the full extent of the jam.
So, boot it up on your TurboDuo, and…
Is this a region lock? It plays fine on my PC Engine Duo R!
Well, if that’s true, Artdink didn’t just want to lock out Americans. They wanted to lock out LaserActive owners too (but who can blame them). And yes, this is a Japanese PAC N-1. (Apologies for the stretched video, I’m trying out a new way to upscale composite video after my Framemeister failed so poorly with my Genesis 1, and it seems I don’t have all the settings dialed in)
There are a few games like this, that have varying crashes on the Turbo Duo, but work fine on Japanese consoles– as long as they aren’t the LaserActive. And it turns out there’s a very simple reason why.
There were a number of releases of the CD-ROM2 BIOSes for the standard 64kB CD-ROM2 system with different version numbers. For example, above is version 2.1, which happens to be the only one to get a separate boxed release. But once they reached the Super System Card with BIOS 3.0, they never updated it again. The same BIOS is used on the Super System Card, the Duo consoles, and even the Arcade Card Pro. The only updates were the following special cases:
- The American version, BIOS 3.1 internally (but 3.0 on the title screen), used on both the American Super System Card and the Turbo Duo
- The Pioneer LaserActive
A III: Take the “A” Train just happens to assume that it will only ever be run with Japanese BIOS 3.0, and jumps into its code directly. It crashes on any other system; but since the vast majority of Japanese Super CD-ROM2 capable consoles use the 3.0 BIOS, it seems they never caught it. There are a few games of that sort, but A III is the only one that involves trains. Unfortunately, the only way to play them on US consoles is to use a Japanese BIOS; you can use a modded one on the Turbo EverDrive (dumping it yourself from a HuCard you own, of course), or use a region converter. Say, with an Arcade Card Pro.
I assume I could get it to work on the LaserActive similarly, but as it turns out, the Arcade Card Pro doesn’t fit in the slot. Oops. In any case it’s not really a region lock. It’s just a bug.
To drive it home, Altered Beast on the PC Engine, if played on any system card other than the Japanese 1.0 version, will famously just stop working when you get to your powered up form. The level will not go forward. It’d actually be pretty funny if it was meant as a deliberate lockout. But it’s almost certainly not; it’s just poor programming practice. Software that assumed ROM BIOSes would never change was a very common problem on updated models of home computers, so I suppose NEC Avenue just put the “PC” in “PC Engine”.
The TurboGrafx-16 / PC Engine was far more popular in Japan than anywhere else in the world. So the fact that its region locks are relatively simple to circumvent is a blessing; American software or consoles can often be hard to come by.
I find the region protection code remnants on the TurboGrafx-16 really interesting, though, even if they do break compatibility with Japanese consoles; I imagine if they had thought to include those on the PC Engine from launch, we would’ve seen later consoles take a more aggressive approach with a boot ROM or some other checks about unlicensed HuCards, thanks to companies like Games Express. But thankfully, that didn’t happen.