Gamer, writer and super-dad Mike Mika recently hacked the NES version of Donkey Kong so his three-year-old daughter could play as Pauline, instead of the original Mario/Jumpman protagonist. Now, Mario was the one that needed rescue, and Pauline smashed barrels and scaled ladders to save the day!
Ground Kontrol co-owner Clay Cowgill loved Donkey Kong: Pauline Edition so much, he had to bring it to the original arcade version! This was no simple task – but sometimes having fun is the best reason to take on a new challenge. In “Behind the Barrels”, Clay will explain how he hacked Donkey Kong’s arcade board to seamlessly update it to Pauline Edition!
The first problem to overcome: an arcade Donkey Kong machine is virtually nothing like an NES! They use entirely different processors and have different methods of implementing graphics, so the task would not be as simple as replacing some graphics and calling it good.
Starting with the “Pauline” version of the NES the first step was to get a look at the graphics. The NES uses moveable objects (“sprites”) that are 8×8 pixel squares. Using a ROM hacking tool called “YY-CHR” the memory of the NES ‘cartridge’ was examined. While the graphics were visible, it was pretty hard to tell what was what.
Using the NES Emulator NESTen, the NES game was played and NESTen’s ‘palette console’ was used to see the correct colors in action. Pauline’s palette was #4 and Mario’s was #5. Using the values from the palette console a correct color map was built to make the graphics easier to interpret.
Another ROM tool named “TilEd 2002” was used to explore the Pauline graphics to determine how they are arranged in the NES cartridge memory. A bit of trial and error revealed that a single 16×16 Pauline sprite is composited from four sequential 8×8 tiles arranged as:
With the layout in hand, a quick trip back to “YY-CHR” with the correct palette allowed small bitmaps of the cartridge memory to be saved to hard disk. These images were then loaded in to Photoshop and the individual tiles were extracted and assembled in to 16×16 sprite images necessary for the arcade game version.
It was time to pay attention to the arcade game graphics. “Turaco” is an old DOS program used to modify arcade game graphics. After getting Turaco working again on a modern OS (thanks to DOSBox!) the original Donkey Kong graphics were examined.
The original Donkey Kong hardware used images that were mirror images compared to the NES, so the Pauline sprites were all flipped in Photoshop and saved as .PCX files. Using Turaco’s PCX import capability each Pauline sprite was individually imported and hand-matched to the corresponding Donkey Kong Arcade sprite.
The arcade version has some additional sprites that are not present in the NES conversion, so those ‘missing’ graphics were hand drawn in Turaco and saved as a modified set of ‘ROMs’ for the arcade game.
With the graphics converted, the Multi Arcade Machine Emulator (MAME) was used to check progress. The graphic shapes looked correct, but the colors were not. The arcade game system of color palettes is different from the NES, so more in depth investigation of the game code would be required.
Using a ‘debug’ version of MAME, a disassembly (a conversion process that takes the binary ‘machine’ language of the original game and converts it to human readable text) of Donkey Kong was created for reference. (At this point, this discussion will by necessity become fairly technical!)
The MAME debugger was used to run the original Donkey Kong code and using the basic memory map of the machine (from the MAME source code) the code operation was observed. Using a combination of memory display windows and debugger watchpoints (which stop the program when a particular byte in memory is changed) the memory locations used for the sprite colors of various characters and portions of the screen were determined.
For example, the player’s character shape, color, and position are stored in four bytes of memory located starting at address 0x694C (sixteen bit hexadecimal notation).
0x694C = horizontal position of player
0x694D = sprite shape of player
0x694E = sprite ‘attribute’ of player (which colors to draw it in)
0x694F = vertical position of player
Armed with knowing where the program had to change those values and by using MAME’s watchpoints along with the text disassembly and a knowledge of the Z80 CPU used by the game, it was quickly determined that a routine at 0x0054 was copying the ‘Mario’ shape to the screen from a table of values at address 0x388C. one of those values was setting the player to use the Mario color scheme– changing one byte in the table pointed the colors to Pauline’s color set. One problem down!
In the arcade game, Kong’s ‘hostage’ at the top of the screen is two 16×16 sprites tall vs. the single 16×16 character in the NES version. Through some clever positioning of two sprites the ‘Mario’ shape replaced Pauline, but again the colors were incorrect. Another round of debug with breakpoints (which stop the program when a particular instruction in memory is executed) and watchpoints found that code at 0x0B24 was placing the hostage at the top of the screen using a table at 0x3884 in memory. Patching a few more bytes in memory fixed the color scheme to allow “Mario” colors up top.
At this point a new problem was observed– the player ‘lives’ were shown on screen were little Mario shapes! That simply won’t do for Pauline, so further investigation was in order. This turned out to be a difficult problem to address because unlike the NES, the arcade game was “hard wired” to show certain colors on that portion of the screen– it was not possible to make ‘Pauline’ colors appear there. A simple compromise was made by replacing the tiny ‘Mario’ shape with a heart to signify a player life. Excellent!
With all these changes the game was actually looking and playing pretty nice! But something else was missing…
In Part 2, we’ll explore adding new prizes to the game, tracking down more quirks, and why the game doesn’t want you to change the title screen!
Read on: Behind the Barrels – Part 2