Puyo Puyo Tsu/Hardware Platforms
Puyo Puyo Tsu runs on various hardware platforms. When analyzing game ROMs from those systems, one must keep in mind intricate details about the platform. Indeed, game routines depend on the platform architecture, how external devices are connected (for instance, how gamepad input is managed), as well as the different processor types which will directly impact the assembly language to be analyzed.
Puyo Puyo Tsu is available on multiple platforms: Arcade, Super Famicom, Sega Saturn, PlayStation, PlayStation 2, Mega Drive, Game Gear, Game Boy, PC, Virtual Console, NEC PC-9801, Macintosh, PC Engine, Neo-Geo Pocket, Wonderswan.
Current reverse engineering efforts focus on the Mega Drive/Genesis version of the game, for various reasons:
- it still runs on available mainstream and inexpensive hardware;
- this version can be legitimately purchased somewhat easily, which grants reversers a more protective legal framework, depending on local regulations;
- the Genesis version is almost an arcade-perfect conversion, with only minor adjustments as the hardware platform is mostly the same. Only minor differences impact very few gameplay-related routines.
The next sections describe both of these platforms as well as discuss various hardware considerations and generalities, so that everyone knows what's required to understand the reverse engineering efforts.
Contents
Hardware considerations and generalities
The process of reverse engineering programs mainly involves reading bytecode, assembly language, and debugging a running instance of the program to inspect the state of the machine at some specific moments. A few concepts shall be understood on how a computer/console works.
The main CPU communicates with various hardware processors and memories to perform calculations. In our case, the Genesis CPU communicates with game controllers, a sound processor to handle music and sound effects, and a video processor to render frames and display them on the screen. It also talks to the ROM (static memory) in the cartridge to read the content of the game program and data (sprites, backgrounds, sounds...), and has some RAM (volatile) memory. The last type of memory resides inside the CPU itself, in multiple small chunks called registers, which are the fastest type of memory, in terms of access delay.
The main CPU is connected to the external processors and memories through a communication bus: it can send read and write orders on that bus, along with some data and the address they should occur at, be sent to or read from.
Old hardware handles all those surrounding memories and processors quite simply: a "virtual" address space is indexed sequentially at the byte (8 bits) level: address 0x0 is the byte value located at the first storage byte of the address space, while address 0xFF is byte the 256th byte of the memory. On the genesis, the address space is 24-bits wide, which means addresses range from 0 to 0xFFFFFF, 16 MB of available memory. For convenience and as the CPU registers are 32-bit wide themselves, addresses are mostly expressed as a 32-bit value, with their most significant byte being set zero. The full address space then ranges from 0x00000000 to 0x00FFFFFF.
ROMs are way smaller than that available addressing space, so the virtual addressing space is split up, and each portion is assigned to a designated peripheral: for instance, addresses 0 through 0x003FFFFF are mapped to the ROM inside the cartridge, while 0x00FF0000 through 0x00FFFFFF are assigned to the volatile RAM. External CPUs or game controllers are mapped in the same way, and communicating with them is as simple as reading and writing to their designated addresses. Seeing which keys are pressed is almost as simple as reading a value somewhere in the virtual address space.
CPU registers are a very small memory that resides inside the main CPU, usually 32-bits wide, 64-bits wide in current PC hardware. They are used to store intermediate values during calculations, values that are fetched from or stored to the ROM, RAM or external peripherals.
Some very special registers are important:
- Program Counter (PC) / Instruction Pointer (IP/EIP): it's a registers that always holds an address pointing somewhere in the virtual address space. More importantly, that address points to the next instruction (command) the CPU will execute. In our case, this almost always points to an address located in the cartridge ROM, so that the CPU executes the game code stored there.
- Stack Pointer (SP/ESP): this is also an address but points to the RAM section. Its value slowly grows up or down as the program saves values by pushing/popping them onto/from a stack of values. The address points to the top of that stack. This is a fundamental mechanic on how program functions store variables.
- Status register (SR): this registers holds bits which will each have some significance with regards to the most recently executed instruction: is the result negative? did we generate a carry/borrow while adding/subtracting stuff? etc.
The other general purpose registers are used to hold data or addresses.
Hardware architecture
The Genesis console (Mega Drive in EU and JP) was released as the household device everyone know, but also declined into arcade cabinet boards known as "System C" and "System C-2", which share the main hardware architecture while providing several enhancements (mainly performance-wise).
These platforms are based on various main components:
- Main CPU: Motorola 68K, clocked higher on the C-2 hardware, which runs the main program of the games. It has 8 dedicated data registers (D0-D7) and 8 address registers (A0-A7) on top of PC, SP and SR;
- Sound CPU: Zilog Z80, which is absent of C-2 hardware (since the higher clock speed allowed for the main CPU to handle all that). The main CPU feeds it with sound samples and Z80 code excerpts to handle the playback;
- Video CPU (VDP): this CPU will actually build each frame but putting together sprites and backgrounds. The main CPU feeds it with sprite IDs and position through various data and control registers, and this CPU gets its graphic data from the ROM.
Genesis
See segaretro.org/Sega_Mega_Drive at segaretro (link filtered by anti-spam).
System C-2 / Arcade
See segaretro.org/Sega_System_C at segaretro (link filtered by anti-spam).
When reading or writing at specific addresses, the CPU can communicate with the cartridge, the RAM, the sound CPU, etc. This sums up where everything goes:
| Address range | Description |
|---|---|
| 0x000000 - 0x3FFFFF | main ROM cartridge |
| 0xA00000 - 0xA0FFFF | Z80 sound processor memory, used to send sound samples |
| 0xA10000 - 0xA10FFF | System registers, some of which hold game controller status |
| 0xA11000 - 0xA11FFF | Z80 control registers, used to send play commands |
| 0xC00000 - 0xDFFFFF | VDP memory and control registers, used to send both data and display commands |
| 0xE00000 - 0xFFFFFF | main RAM, with most games (including Tsuu) using only 0xFF0000 through 0xFFFFFF |
(this list is not 100% accurate)
The System C-2 uses very similar mappings, most importantly for the main CPU ROM and RAM sections. Sound CPU mappings are different though.
