Action52 cartridge analysis

As Active Enterprises wanted to stay totally independent from Nintendo to avoid eventual lawsuits and paying them royalties, they made their own cartridge, PCB and unique mapper chip using a simple PAL instead of the common MMC1 mapper. One could always program a similar PAL to mimic the behavior of their custom mapper, but that would imply making a custom circuit board from scratch and having the appropriate programming device. Expensive and complicated...

They also had to come up with a solution to defeat the famous CIC chip, which is in charge of locking out unlicensed or region-locked games. They went the Tengen way, by giving it a large negative voltage slap hoping it will crash and make it stop resetting the NES.

Some people had suggested that each level had its own engine, because the bugs (what a reference...) and controls acted differently in different levels of the same game. Those people were right.
Cheetahmen II has 6 levels, each one having its own engine and bank of code in the PRG ROM. Now that's some serious space optimization. So in 1992, ordering a bunch of 512KB mask ROMs instead of good programmers was considered cost-efficient ?

The entire game is like having 6 slightly different cartridges plugged into your NES. Completing each levels runs the next one, losing all your lives gets you back to the first.

For such a crude game, one would expect to find only 3 or 4 kBytes of code at most. But if you look at the PRG ROM banks in a graphics editor like Tile Layer, you'll see that they're packed ! I'm not sure if all the code is used or if some of it is actually garbage, noise or copy-pasting accidents. The music patterns seem to start at the 3rd quarter of bank 0.

The funny thing is that even though the PRG ROM banks are switched in whole 32K blocks (all of what can be seen by the NES CPU at once), the music still plays without glitching. It wouldn't surprise me if the music player routine was copied at the exact same position in every PRG bank...

The big axial capacitors used to stun the CIC visibly took a dip in the solder wave during manufacture.

I dumped my cartridge's ROMs to see if the hashes were known. They were, no surprise.

Schematic (may be some errors, click for larger size):

About the PLD

The PLD used is a GAL16V8, which is compatible with a bunch of PAL types with registers and complex feedback.
Reading the datasheet, we can see that it is actually used in "simple mode" in the cartridge.
In registered mode, pin 11 would be used as an input (output enable). On the schematic, it isn't.
In complex mode, the same pin 11 would be used as a dedicated input. On the schematic, it isn't either.
We can then safely deduce that the logic in the PLD is only combinational and probably quite simple.

On the schematic, IN7 is PRG A15 instead of A14 ? Or is A15 on another pin like IN1 ?

• IN0 is latched PRG ROM low bit
• IN2 is CPU R/W
• IN3 is latched CPU A13 (mirroring mode)
• IN4 is latched CPU A6 (PRG bank lower bit)
• IN5 is latched CPU A5 (PRG bank mode)
• IN6 is latched PRG ROM high bit
• IN7 is CPU A14
• IN8 is PPU A10 (for nametable mirroring)
• IN9 is PPU A11 (for nametable mirroring)

 

Pin 19 (I/O0) is an output to latch the configuration data from address and data lines.
Guessed logic: OUT0 = IN7 & ~IN2

Pin 18 (I/O1) is an output to select PRG ROM 3 (U7).
Guessed logic: OUT1 = ~(IN6 & IN0)

Pin 17 (I/O2) is an output to select PRG ROM 1 (U6).
Guessed logic: OUT2 = IN6 | ~IN0

Pin 15 (I/O4) is an output to select PRG ROM 0 (U5).
Guessed logic: OUT4 = IN6 | IN0

Pin 16 (I/O3) is an output to enable data output on the PRG bus.
Guessed logic: OUT3 = ~(IN7 & IN2)

Pin 14 (I/O5) is an output to split PRG banks.
Guessed logic: OUT5 = (IN_A14 & ~IN5MODE) | (IN5MODE & IN4BNK)

Making your own Action52 repro

So, you're tired of emulators and you want to experience playing Cheetahmen II on your NES, but you can't afford the real cartridge ? No problem, make your own !

It would be way easier if all the NES games were based on the same type of cartridge ("easy" is relative of course, I'm aware that not anyone can or has the time to do such modifications).

Cheetahmen II's mapper and the MMC1 being functionally different, the game can't be burned to some EEPROMs and dropped in a SLROM board for example. The MMC1 won't understand a thing and the game won't work. That's what we have to work on: modifying the Cheetahmen II ROM to make it compatible with the MMC1 mapper.

First of all, we need to see what fails. We can use the very handy No$NES emulator, which has a great debugger with breakpoints and memory editing capabilities.