Introduction

Upfront disclaimer: This page is strictly about the vintage P1 ROM from the 90s! I did NOT do any datamining on the remakes and this information MAY NOT be valid for them!

I spent around 1-2 months in 2023 analyzing the P1 ROM (this used to be available on the Internet Archive, not sure if it still is). I specifically wanted to figure out how the P1's growth chart works. Ultimately, I want to perform the same analysis on other models, for some future time that their ROMs become available. To that end, I shipped some Mothras, some Angelgotchis, and some Tamaotchs to a guy who can decap and image the ROM -- this is still a work in progress.

Anyway, I want to write down what I did so that I can help jog my memory later... this is very much a quick-and-dirty page and I assume a lot of prior knowledge. Maybe someday I'll flesh it out, but for now I just want to capture the main points of what I did.

Analysis process

I have never reverse engineered anything before -- not a professional programmer or electrical engineer, I'm just some donkus with hobbyist interest in those fields. But most of the hard work has already been done, since the P1 ROM has already been dumped and we know what kind of CPU the P1 uses (Epson E0C6S46). So I started by getting the datasheets for the P1 CPU and the programming guide -- I don't think there any issues if I share those files, so here they are:

• E0C6S46 datasheet -- this isn't that useful, mostly just a high-level description of the CPU. I'm only including it for completeness.
• E0C6200/6200A Core CPU Manual -- this describes the high-level architecture of the family of CPUs that includes the E0C6S46. The CPUs all have some common qualities, which are described in this manual. The instruction set architecture is also described here, which is critical to understanding how the code works.
• E0C6S46 Technical Manual -- describes specifically the E0C6S46 used by the P1. Things that are specific to this chip -- I/O ports, how output to the screen works, etc. are described here.

With the datasheets in hand, I opened the P1 ROM in Ghidra. This is a reverse engineering tool that you can use to open a binary file and look at the code contained within; it has extensible parsing capabilities that allow it to figure out and display the code in the file.

Now, Ghidra does not natively know how to parse the binary format used by the P1 ROM. But fortunately, there is an existing Github project with parsers for the E0C6S46 format. I fixed up the parsers and submitted a pull request that was accepted, so the project should be usable for anybody at this point. Install it in Ghidra (should just be able to create a folder 'E0C6S46' in Ghidra build location/Ghidra/Processors and copy the contents of the repo into there) and you are ready to go.

My first approach was just to read the P1 code, starting from where the program begins. Per the technical manual (4.1.5), I know that the Tama program starts at address 0x00, page 0x1, bank 0x0. In Ghidra, this appears as address 0x0100 as shown below (note that the interrupt vector is also stored here -- I have it annotated in the screenshot)

For reference, here is the layout of the ROM as described by the technical manual:

The ROM addresses as shown in Ghidra reflect this -- first digit is bank, 2nd digit is page, and the last 2 digits are the address within the page.

So at first, I simply followed the code as it proceeded from startup, initializing registers and I/O, etc. Eventually I realized this is extremely inefficient and I probably would never get anywhere doing this. At this point I started looking for a way to run the P1 code and follow how it worked -- ultimately I landed on MAME which has support for the P1 ROM and good debugging capabilities. You can inspect memory, pause execution, set breakpoints, etc. (go here for the full documentation) There are tools out there specifically for running the P1 ROM, but they didn't have the debugging capabilites I was interested in.

To open not in full-screen mode and to enable debug, I invoked mame on the command line as:

mame -window -debug

So basically what I did from this point was an extremely grueling, time-consuming process of watching what the code was doing, and how the contents of RAM were changing. I was able to annotate more and more of the ROM in Ghidra, leaving less and less unknown code. Eventually, I was able to figure out what I wanted -- how the P1 growth chart works.

I really wish I'd done this writeup earlier so I remembered better what I did. But anyway here were some general notes that I found useful:

• It's useful to identify loops in the code. The Tama program is basically a giant state machine, and depending on the state it's in, it will run some loop over and over until it meets the conditions to leave that state. For example there is a state for being an egg, a state after it hatches, etc. These loops are useful because they contain a lot of the 'business logic' -- you can see them checking whether to decrement hearts, become sick, die, etc. Once I identified the loop that is used after the Tama hatches, it was very easy to go from there to figure out how almost everything worked.
• It is somewhat useful to identify and figure out code that goes into decimal mode, because very few things in the Tama program are done in decimal mode. The Tama's weight and age, and the seconds and minutes of the clock, are in decimal for example. If you see something being done in decimal mode, you may be able to identify some piece of the business logic.
• In general, the name of the game is to figure out what memory locations are being used for and what changes them. If you get interested in a memory location, set a breakpoint for it in MAME when it gets read to or written so that you can see what code is setting it.
• You want to identify & label functions in the code, then see what calls them. Ghidra with the E0C6S46 processor I used often mislabeled code as a function when it shouldn't have, so there is a lot of manual correction & massaging required. It was very satisfying to see the number of unidentified functions go down over time.
• It was very useful to identify what code is responsible for drawing stuff to the screen and deciding what sprite to load. This was for a few reasons -- this code was often very close to real 'business logic' so if you saw a call to drawing code, you know something important is happening in the Tama code. But also this could be used as a shortcut, since if you saw that drawing code was being entered, you could basically just ignore what it was doing -- the state is set by that point and not changing so it's not that interesting. In fact, I never fully learned how the drawing code works.
• The timer interrupt handling code is useful to understand, because everything in these vintage Tamas is timer-based. The timer handling code will set flags that the main loop of the program will inspect when deciding to do something.

Results

So enough technical nerd stuff for a second. Did I learn anything cool about Tamas from all this? YES

• The biggest thing I got out of this was the 'oldie strat'. I actually found this by accident while I was playing the P2 (because my Sekitoritchi didn't die even though I'd left its hearts empty for a long time), and then confirmed the effect in the code. Basically, due to the way the code works, if the time to lose a hungry or happy heart becomes less than 15 minutes, the Tama program can no longer register care mistakes for that strat. Roughly, once an adult Tama first gets sick, it will start getting more needy every day after that until it dies. So once this happens, you can update the clock over and over (10 times is safe), putting the Tama to sleep and waking it up, causing it to age faster artifically, and drive the times down to below 15 minutes. If you do this, your adult Tama will be constantly calling for attention but it will never die from care mistakes. So it will stay around for the maximum time that it is programmed for, as long as you don't make other mistakes (i.e. be careful to clean up poop, cure sickness, and turn off the lights when it goes to sleep). The oldie strat makes the P1/P2 significantly more tolerable once the adult gets old.
• Tarakotchi is the worst character, but it actually lives longer than Nyorotchi.
• Kuchipatchi has a slightly higher chance to win the game than all the other characters. Maskutchi has a slightly lower chance to win the game.
• The number of bites a Tama takes when eating food, is actually a character-specific trait. Babytchi takes 4 bites for example, and the unhealthy characters tend to take more bites.

I'm going to attach a couple of the outputs from this process to this page.

• My notes that I gradually filled out with what different locations in memory are used for.
• Datamined stats for each character. This was generated by a script that directly read data out of the ROM. The hungry/happy vectors are the amount of time between hungry/happy heart decrements as the Tama ages -- e.g. Mametchi starts out losing 1 hungry heart every 81 minutes, but once it starts to get old, it goes to 61 minutes, all the way down to a minimum of 5 minutes.
• rip.py, utils.py, timeline.py, Python scripts that I used for doing various things with the ROM data -- rip sprites, generate the stats file, etc. rip.py does require the ROM file to work sorry (and the other files use it as a dependency). The timeline.py can be used to simulate all the events in a Tama's lifetime, from evolution, sickness, and discipline calls down to when it poops. It is very handy knowing when the Tama will call for discipline, because it means you don't have to constantly keep an eye on it. I found it very accurate, except during one P2 run where it got a discipline call wrong for some reason.
• Ripped sprites. This is NOT all the sprites I believe, some are hidden in other places in the code.

I wasn't sure if the Ghidra project with my annotations is anonymized so I refrained from uploading it... for now

Future Work

So with this project I pretty much assured myself that I can, given the ROM, figure out how the code works. But what I'm expecting from the decapping project is just an image of the ROM, so there are 2 extra steps before I can start looking at the ROM:

1. Extract the ROM from the image. I identified a few possible resources to do this:
• https://github.com/travisgoodspeed/gbrom-tutorial
• https://github.com/travisgoodspeed/maskromtool/
• https://github.com/JohnDMcMaster/zorrom
2. Make the ROM playable in MAME. Like I already mentioned, somebody already went to the trouble of making the P1 ROM playable in MAME. MAME is open source and it should be extensible to other Tama models -- and I would suspect that a lot of the code can be lifted directly. The only model I would expect probably would require a lot of extra work is the Osu/Mesu, since it has a larger screen and the serial interface for communication. Some useful links to bookmark here:
• https://github.com/mamedev/mame/blob/master/src/devices/cpu/e0c6200/e0c6s46.cpp
• https://github.com/mamedev/mame/blob/b205a9f0f266d1dbb96bc9249a0405689ebc3491/src/mame/bandai/tamag1.cpp
• https://docs.mamedev.org/techspecs/device_rom_interface.html?highlight=rom_region

The project to decap and image the Mothra/Angelgotch/Tamaotch is not complete yet, but a rough scan WAS made of the Mothra, and I surmised from it that the CPU model used by the Mothra is most likely a E0C6S48. This is basically the same thing as the E0C6S46 which gives me hope that, once a ROM is available, very little work will be required to get it working in MAME, so analysis will have a quick start for it. For future reference, the datasheet is here

Sleigh side notes

Although I eventually did find an existing parser on GitHub for the P1 CPU, I did have to do a lot of rework on it and I did have to scrounge around for resources on how to do that. (plus I originally tried to start from scratch).

The system used to write new parsers for Ghidra is called Sleigh. I found it kind of a nightmare to work with.

Unfortunately I no longer remember how I invoked sleigh to compile my in-progress parsers. It comes with the Ghidra builds (look in the 'support' folder). But basically I would just make a change to the parser, run Sleigh, install the updated files, then restart Ghidra and try to parse the ROM again. Once it output the results I wanted, I was happy.

In general, I think that due to the weird way the P1 CPU architecture works, Ghidra is able to do less static analysis on the ROM than it can for other architectures. So it basically never knows what the input to a function is unless you figure it out from using MAME or manual inspection, doesn't know the results of calculations, and can't build those cool looking code trees like you see in RE writeups that are better than this one. (and like I already mentioned, Ghidra tended to mess up the function definitons, so you have to manually remove a lot of the autogenerated labels and functions -- this was a satisfying activity though since you are reducing the overall number of functions you need to worry about for free...)

Sleigh links

The most important source for figuring out how to use Sleigh is, unfortunately, the Sleigh language specification. These come with Ghidra -- in my build, I found them in docs/languages/html. But they're kind of hard to decipher unless you have other Sleigh files to reference against.

Random stuff I looked at at various points, just figuring out where to look was kind of difficult, so I'd like to leave the breadcrumbs for all to see...

• https://trenchant.io/expanding-the-dragon-adding-an-isa-to-ghidra/
• https://reverseengineering.stackexchange.com/questions/25070/is-there-documentation-on-the-ghidra-9-1-sleighdevtools
• https://www.reddit.com/r/ghidra/comments/f5lk42/my_experience_writing_processor_modules/
• https://spinsel.dev/2020/06/17/ghidra-brainfuck-processor-1.html
• https://www.reddit.com/r/ghidra/comments/bhhrt0/quick_guide_to_creating_a_processor_in_ghidra/
• https://github.com/kylewlacy/GhidraNes (another example of a custom Ghidra processor module)
• https://github.com/NationalSecurityAgency/ghidra/issues/100
• https://swarm.ptsecurity.com/creating-a-ghidra-processor-module-in-sleigh-using-v8-bytecode-as-an-example/ (this site appears to have gone down since I used it -- it was just in one of my 10000 tabs -- so use the Wayback machine)
• https://reverseengineering.stackexchange.com/questions/22974/why-ghidra-doesnt-load-the-disassembly-correctly-while-radare2-does
• https://github.com/SamuelWAnderson45/ghidra-unSP (I think this architecture is actually used in some color Tamas?)

Further reading...