Writing out the in port will likely shorten this Tamagotchi’s lifespan. Oh well …

It would have been more convenient to dump the ROM via IR or the SPI ports at the top of the Tamagotchi, but unfortunately, I don’t have any information on how to write to those ports. There is an application note describing how to write to port A on the General Plus site, though.

I started by dumping the entire memory space, from 0×0000 to 0xffff, which included all mapped memory, such as ROM, RAM and ports. This only dumped some of the ROM, though, as the GPLB52x microcontroller supports paging outside of 6502 paging. The first 16 kilobytes of the ROM are always mapped to 0xc000-0xffff, and then the rest of the ROM is split into 19 pages that can be mapped to 0×4000-0xbfff as needed. To dump the entire ROM, I needed to figure out how to page.

Loading oxc000-0xffff into IDA, it became apparent how to page pretty quickly.

Tamagotchi startup code (0xcc00 is the reset vector)

The address 0×3000 was written to quite often before jumps, and there were several subroutines that pushed and restored this value before jumping to another subroutine. Trying this in my dumping code, I was able to dump the entire ROM!

Doing a quick analysis, pages 0 through 6 appear to be code, pages 7, 8 and 9 are empty, pages 11-18 contain image data, page 10 contains some image data and some other data and I’m not sure what 19 contains (if I had to guess it would probably be audio).

Decoding the image data, you can already find out some interesting things. For example, here’s some of the images from page 18:

Pictures from page 18 (click to see full size)

In blue are all the possible Tamagotchi characters you can get on the Tama-Go! And in red below are the images from the factory test program, one of which I’ve never seen before, suggesting that there’s features of this program that haven’t been found yet.

For the Tamagotchi fans in the room, I’ve posted all the images I dumped here. I’ll be posting the rest of the code as I make sense of it.

In the mean time, here are some of the cuter highlights of the ROM dump.

Hip hip hooray!!

I mentioned in an earlier post that I saw some ‘freezing’ behaviour in the figure game functionality. Game logic is controlled in its entirety by a single bit ‘game code’, which I suspected was the index of a jump table containing all Tamagotchi functionality, and invalid game codes, especially those in the middle of the 0-255 range cause the Tamagotchi to freeze, requiring reset.

Looking into how 6502 (the Tamagotchi microcontroller architecture) works, I thought this might be a sign that the microcontroller was veering off into unexpected code.  Memory in 6502 is mapped into a single address space, and there’s no MMU or other memory protection. If unmapped memory is accessed, it returns 0 or some other garbage value. Invalid instructions do not cause a reset, but execute undefined behaviour taking a non-deterministic amount of time. This meant that freezing was unlikely to be due to an error being detected by the microcontroller (of course, it was possible that an error was being detected by the code on the microcontroller, and it handled the error by going into a tight loop, but this struck me as unlikely, as the Tamagotchi tends to handle detected errors by resetting). It also meant that exploiting a bug in 6502 should be reasonably forgiving,  as  if the PC ends up somewhere before the intended address, it will likely execute any garbage instructions in sequence, and end up at the right address anyhow.

My first thought was that maybe the invalid “game codes” corresponded to indexes outside of the jump table, so the microcontroller was jumping to addresses that were actually other data. Since LCD RAM is the only memory that can be controlled by a figure, I was hoping that maybe one of these values would cause a jump into LCD RAM. So   I filled up my LCD with a NOP slide and shell code and hoped.

Shellcode works better when an annoying Tamagotchi doesn’t stand in front of it

I tried all 255 indexes, but none of them worked. I did notice two interesting things, though. First, the indexes in the middle of the range weren’t all invalid. Some of them showed valid screens, although these screens didn’t always work. This meant that I probably wasn’t jumping to an unintended address, but something else was happening to cause freezing, such as the stack wasn’t set up correctly for the jump. Secondly, the index 0xCC had some interesting behaviour. If bit 3 of the 68th byte in the LCD RAM was set, it played a repeated beeping, and would detect when the figure was removed, and return to the main screen. If this bit wasn’t set, it would play no sound, and freeze. Based on the sound, I guessed that this was the location the Tamagotchi jumps to when playing a sound when a key is pressed. So the logic would be “check if sound is enabled (probably based on an address on the stack), and if set play the sound and return to the address on the stack otherwise return to  a different address on the stack”. Except the stack was messed up, so it was checking the LCD RAM for the bit, and returning to the address where it started instead of the correct address.

I found this perplexing. Considering that this behavior confirmed that pointers to the LCD RAM were being put on the stack before the jump, I found it surprising that none of the  255 possibilities were causing code execution. Eventually, I suspected my shellcode might be wrong. Since I have no sample microcontroller to test code on, and don’t know the locations of the ports, I thought this was likely. My original code was supposed to flash the IR LED, but I moved to the less ambition jumping to reset (since practically nothing will reset a 6502 microcontroller, this would be a good indicator of code execution). I also checked my code with the SunPlus compiler. And found I was using entirely the wrong instruction set. With the right instruction to byte value mapping, the Tamagotchi reset on the third “game code” I tried, 0xd4.

Playing with different instructions, I found the code execution was very unreliable, especially when calling longer instructions like stores and loads. Eventually, I figured out that the Tamagotchi LCD does not use one contiguous piece of LCD RAM, but uses at least two separate pieces. Jumping to one of these locations immediately after starting execution made it much more reliable.

Below is an example of changing the LCD using stores and loads. The area circled in blue is the first code that gets executed, and the area circled in green is the code in the contiguous memory it jumps to. The white boxes (circled in red) are the contiguous pieces of memory, set to be white using STA. The entire row is part of the memory, but I only set one byte (four pixels) per row.

Yes, I’m aware this is the lamest POC ever

For people trying this at home, the LCD RAM locations so far are:

Rows 1-7: 0x10cc-0×1107

Rows 8-18: 0×1120-0x117C

Row 17: 0x10B4-0x10CB

Row 18-31: ???

Next step: chain this together to dump the code!

Any groups or individuals interested in participating should complete the simple application at http://makerfairewaterloo.com/ by the end of April.

It’s no secret that I’m not impressed with the current state of University education. I’ve spent a long time griping about the various issues, and pointing out ways I would do it differently. None of that makes any difference, however, until I actually do something about it.

While my issues are with post-secondary education generally, my primary expertise (especially of late) is in Computer Science and Software development. So, I developed a curriculum, found a community, and started teaching a class.

Teaching one class does not constitute a solution, but it does provide a learning experience for me. The class is over half done now, and in the rest of this post I will be examing things I have tried and what I have learned.

Hands-on Learning

Since my approach is focused entirely on education, I did not assign any exercizes early on. I provided students with the tools needed to play with the concepts on their own, and set them free to hack. This turned out to be too open-ended. When encountering a new concept for the first time, many students simply had no concept of what direction they should take their explorations in.

I am now providing some concrete exercizes to the students, but really I need to find a way to integrate more hands-on learning into the class itself. This is made more difficult because of the pacing I chose for this version.

Pacing

Probably the biggest experiment in this first version of the course is the pacing I am using. The class is an overview of Computer Science from both the perspective of functional abstractions and low-level machine implementation. It is designed to give students a flavour of what parts of Computer Science they might find interesting for further study. I am doing the whole thing in 8 weeks.

The amount of material I am covering would normally be covered in two or more semesters at a University. Why am I doing this? For two reasons: so that students have less time to get bogged down on individual details (since, as an overview course, this is not about depth), and also to find out how fast one can reasonably progress without hopelessly confusing students.

While I cannot be sure without more experiments, I am also beginning to suspect that the pacing increases student engagement (at least for the sorts of students I have solicited). New material every single class means that students do not have an opportunity to tune out because “we already talked about this”.

While the pacing is definitely hurting the students’ ability to deeply absorb the subject matter, I conduct informal experiments periodically to determine understanding. Students in general seem to be grasping concepts, and find themselves coming back up to speed on items they failed to retain quickly enough to demonstrate a level of penetration.

Students

For this course, primarily because of the pacing, I solicited students with prior knowledge of computer internals and programming. I started out with a good mix of students from various backgrounds, but certain students (about half of the 10 I started with) dropped the course fairly early on.

Students who stuck with the course were precisely those students who had both enough knowledge of computer internals to handle the pace, and enough of a deficiency in prior experience with Computer Science-related material to be interested in an overview. I hope to run both slower and more in-depth courses in the future in order to serve other sorts of students.

While prior knowledge of the basics seems to be helping the students’ ability to comprehend new material, it also occassionally poses a distraction, since I cannot present any idea as strictly new. I need to improve my ability to communicate an idea that is “new” in the context of a course, without speaking as though no one present has ever heard of it before.

From the Top and Bottom

The concept of my particular curriculum for this course is to start at the “most” abstract and “most” machine-specific concepts, and work inward. This is in stark contrast to most first-year Computer Science courses, which start out in practical programming, move on to machine specifics, and then later on do algorithms and (maybe) more abstract (actual) Computer Science.

Students have indeed struggled with the seemingly-abstract concepts, especially early on when they may not yet even have a basis on which to understand “why they care” about the abstractions that are possible. This is partly because of my failure to spur adequate hands-on learning, and partly because of the ordering. On the other hand, the juxtaposition of abstractions and related implementation details has already more than once resulted in realizations about the nature of the abstractions (“that product type is just like a struct!”)

Next Steps

I still have to finish teaching this class, and will report more at that time. Some of my students (and also other members of the Kwartzlab community) have expressed interest in an Operating Systems implementation course, based on my Writing a Simple OS Kernel series of posts. I hope to run this course mid-summer, and structure it purely as a project course. This should give me more experience with the ways that hands-on learning can be effectively brought directly into a class.

I am also excited about the idea of running other more in-depth courses, based on community interest. From a “Computer Science for Programmers” side I would like to run a course I’m calling “Advance Abstractions” (dealing with advanced concepts in control flow and data modelling) and also a non-course structured as various talks by various contributors on specific data structures and algorithms.

I would also like to run the “slow version” of this same course, targetted at complete beginners. The problem with this version is that it requires participants to have more time to dedicate to the course. We’ll see where that goes.

The Knowledge Integration eXhibit is running this week at the University of Waterloo. One of the exhibits, Satellite in the Shed, discusses the history and significance of the DIY movement and what it means for the resilience of our society.

The exhibit includes and interview by our own Robert “Gus” Gissing and photos of the works of Bernie Rohde.

It also includes other cool projects, like a a homemade exercise bike, a video game controller and a haptic rangefinder glove.

The exhibit only runs one more day, Wednesday, March 12, noon to 6pm.

Tamagotchi Sound

As I mentioned in my previous post, figure ‘items’ are implemented using byte code with six byte instructions. One particular instruction, starting with 0xFEFF controls sound.

The first two bytes of the instruction are always the same, and are likely used to identify it, while the last three bytes are always zero (I checked all the figure dumps I have so far to check this). This leaves one byte to identify the sound. I tried changing this value, and found that it cause the Tamagotchi to play different complete sounds. For example, one value caused the Tamagotchi to beep once, while another code caused it to play “Yankee Doodle” in it’s entirety. Values 0-0×30(ish) played sounds that the Tamagotchi normally plays while running, such as the reset noise and the call noise. Values 0×30-0×52 played a wealth of public-domain music, ranging from “Fur-Elise” to “La Cucaracha” to “The Turkey in the Straw”. After that, codes 0×53-0x5f played a C-major scale. These are all the notes that are available for custom sound.

This is problematic in two ways. First, there are no sharps or flats, so a Tamagotchi figure can only play music that is playable on a major scale. This means that Tamagotchis are unable to dance to many popular tunes, including “Gangnam Style” and “The Macarena”. This isn’t a hardware limitation, as these notes are used in some of the complete songs the figure can play, but the functionality hasn’t been built into the figure.

The other difficulty is timing. The sound instruction does not contain any timing information. Instead, sound timing relies on the delays in image instructions. A sound instruction will not play until the delay in the pre-ceding image instruction is complete, and it will play until the next sound instruction is encountered (there may be several image delays in the mean time). If the sound is not yet complete, it will be interrupted, and not finish playing. There is no other way to change the timing of the sound.

This also means that there is no way to ‘hold’ notes. I tried doing this by repeating notes with a very short delay, but there was no delay that would make the notes play cleanly without “buzzing” due to short breaks in the note. The sound is still reasonable, though. To decrease the delay, and get even better (but not perfect sound), I had the Tamagotchi load a one pixel image during delays, which reduced the inherent delay due to image loading, and the larger image was still visible, except in the one pixel.

This allowed me to create a music video starring my Tamagotchi, albeit one with limited notes and sound quality. A helpful member of pmdev suggested I do “Mad World”, as it can be played with only the notes available.

This song perfectly sums up the angst of being unable to dance “Gangnam Style”. All the more motivation to get code execution!

I took my Tamagotchi to see the statue of Lincoln. What did you do for your Tamagotchi today?

 Fortunately, the second wave of Tamagotchi figures contain flash, instead of mask ROM, so I was able to program a figure directly.

Ignore the wire, these can be reprogrammed without modification

I attached wires to a Tamagotchi case, and used my Arduino to reprogram the flash.

This made testing the figure ROM format much easier, as the flash was much less finicky than my flash-simulation rig, and I could use the figure on any Tamagotchi, not just one with the lines broken out.

After _much_ testing, I figured out that items are implemented using an interpreted byte code. Each ‘instruction’ is 6 bytes long. The format is as follows:

This isn’t comprehensive, there are still a few functions I am not sure how to do. For example, some items will give the Tamagotchi points or make them less hungry. There are likely different types for these. That said, this info was enough to make my Tamagotchi do the Harlem Shake:

The audio on the video is a bit off, though, and this is due to limitations on the audio capabilities of the bytecode format (but not that Tamagotchi hardware). I’ll explore this further in a future post.

The range has a hood, the hood has a range, and soon there will be cookies. Soon.
So what else it can do?

Maybe Taylor can elaborate what happened here

<blink>THE KITCHEN HAS WATER!</blink>

Thanks to Taylor, Rob, Ben, Mark, Steph, Ed, Cedric, Karl, Bob, Kevin, and countless others who made it happen, and are continuing to finish the buildout!

Five days until the grand opening…lots of work left to do!

The front room is still busy and cluttered, but stuff is slowly starting to get put away.

The clean shop is starting to look like a real work zone!  The laser cutter and soldering table is ready for setup, and venting has been routed.  Also, carpet!

Here’s the heavy equipment room.  Things are starting to find a home!

Heavy Lab, from the garage door. LOOK OUT COFFEE CUP, YOU’RE IN A SHIRT PRESS!

Upstairs is the clubhouse area. You’ll have to imagine the TV and couches, but they’re coming.

The kitchenette/cookie forge is coming along!  There’ll be a fridge to the left, and flooring underneath.

The storage area is assembled, and has allowed us to get a lot of bins & boxes off the floor & sorted!

And finally, the most exciting room of all, the newly-expanded bathroom!  Now with art!

Come on by and check it out for yourself next Tuesday night, because it’s changing day by day!

No one say ‘cross talk’ and maybe it won’t happen

I started by looking at the game functionality.  It turns out that the functionality is fairly simple, and a very limited amount of the game logic is controlled by data fetched from the figure. The majority of data is images. Near the beginning of the ROM is a pointer table which contains the locations of images used by games, shops, items and other figure functionality. The location of this table is in turn controlled by another pointer at the head of the ROM. The Tama-Go fetches images by first fetching an image pointer from the table, and then fetching the image.

When “GAME” is selected, the Tama-Go starts fetching the needed images from the figure as they are displayed. Interestingly, they are fetched exactly when they are show, and are fetched multiple times if they are displayed multiple times. This suggests that the Tama-Go does not store the images fetched from the figure, but writes them directly to the LCD.

Only two pieces of data appear to affect the logic behavior of the game. The first are the “commands” at  addresses 0×18 and 0×19 (note I’m using a Mametchi figure, this might differ for other figures). These appear to control what game logic the Tama-Go executes when the specific game is selected. It turns out that if these are altered, the Tama-Go can not only jump into different games, but any screen on the Tamagotchi, such as the meal screen, going to the park or taking a bath. If the back button (C) is pressed on any of these screens, the Tama-Go jumps back to the screen it would normally go back to after the current screen, not the figure screen. This suggests that essentially the Tamagotchi acts as a large switch statement or jump table, with no memory of where it has previously jumped to.

I went through some of the possible command values, and found that many of them caused the Tamagotchi to freeze up and require a reset. This is likely because the commands do not exist, or the device is not in the right state for them to work correctly. It might be possible to exploit one of these invalid commands to dump the code of the Tamagotchi, although the lack of debugging information would make it difficult.

Of course, these commands can be used to ‘cheat’ at Tamagotchi. The video below shows this functionality used to ‘evolve’ the Tamagotchi (make it get older).

There is also a series of bytes that gets read at the very end of the game. This seems to be related to how many points the Tamagotchi is awarded for playing the game. The Tama-Go appears to read more data the higher the game score is, so my guess is it’s some sort of cumulative algorithm for calculating the points awarded from the game score. Randomly tampering with these values caused my Tamagotchi to be awarded an extremely large number of points (which was useful in testing item functionality), but I’m still not clear how the values translate to points exactly.

83009250 points has got to be enough for any Tamagotchi

Next, I looked at the shop functionality of the figure. This was also quite simple. The entire store functionality appears to be in the Tama-Go’s internal ROM, and it just fetched the images. The only interesting value was the item price, which can be altered in the ROM. This would probably be more useful had I not just given my Tamagotchi infinite points.

Lastly, I tried using an item, and this was quite interesting. The Tama-Go fetches one byte of non-image data from the figure, from inside the expected segment before using an item, and then fetches more than 200 bytes of non-image data from near the end of the ROM (not the segment, the entire ROM) while the item is being used. This is so bizzare, I tested it several times to make sure it was actually what was happening, and I’m confident that it is.

What I suspect is happening is that the first byte is a command similar to the game commands, jumping to code that relies on both image data and other data from the figure, which it then fetches. I’m not sure what this “other data” is. It could be the location of the images on the screen, it could be audio data (items make sounds) or it could be some type of metadata related to the behavior of the item (for example, whether it gives points, or the probability of behaving a certain way for items that don’t do the same thing every time). As for why this information is at such a strange location, my only guess is that its used by all three characters in the figure, so it can’t be a part of any of their segments. But this is wild speculation.

A complete list of memory addresses I’ve identified is below:

And a list of game codes I’ve tried so far: