Pokémon Crystal disassembled source code | Hacker News Reader

Pokémon Crystal disassembled source code

github.com

106 pointsbeltex60 comments

Unlike a disassembly of code that is written in a higher-level language like C, these old NES and Gameboy games were written in the assembly language you're seeing disassembled. Obviously there are no comments and labels, but the actual logic and the intent of the original developer is clearly communicated.

This allows for a really special type of awesome when you're working on fan translations and ROM hacks. You actually have the opportunity to analyze the work of the developers you idolized when you were younger, and celebrate a their clever hacks or curse them for their spaghetti code, 15 to 25 years later. Furthermore, you can contribute your own clever hacks to the code base.

What's always amazed me about the 8-bit and 16-bit console days is the relatively high quality of the code. It might be ugly, but it's relatively defect free for the most part. My understanding is that Nintendo did significant QA testing before providing their "Seal of Approval" and allowing the game to be shipped.

I know there are a few glitches and bugs, but it's still amazing to me that I can't think of a single 8 or 16 bit game published on Nintendo or Sega's consoles that had game killing bugs during normal gameplay. They didn't lock-up, reboot the system, glitch out, etc. Even when monkeying around with the weird glitches, the games stayed pretty rock solid.

I know today's games are incredibly more complex, but I don't think they go through the rather rigorous gameplay testing of those old days.

(then again, it was every kid's dream to be a gameplay tester, until they found out it was a minimum wage job that involved following a specific script to test a sprite collision bug on level 5 of Yo! Noid for 8 hours straight)

> Gameboy games were written in the assembly language you're seeing disassembled. Obviously there are no comments and labels,

These look like labels and comments to me:

https://github.com/kanzure/pokecrystal/blob/master/engine/ti...

https://github.com/kanzure/pokecrystal/blob/master/battle/ai...

https://github.com/kanzure/pokecrystal/blob/master/home/deco...

https://github.com/kanzure/pokecrystal/blob/master/battle/hi...

They meant "obviously the comments and labels of the original programmers are not included."

Two interesting fun facts about Pokemon Crystal:

1) Pokemon Gold/Silver, the prior versions of Crystal, was programmed by four people. (http://en.wikipedia.org/wiki/Pokémon_Gold_and_Silver#Develop...)

2) Crystal is 1MB in size. Yes, one megabyte.

> Crystal is 1MB in size. Yes, one megabyte.

Is this notable because it's little or because it's a lot?

Zelda III for the SNES was 1MB. Pokemon Red and Blue was 512KB, which is also quite a lot for a Gameboy game.

That seems pretty small by today's mega sized binaries. But for an assembly program that seems very big. It is impressive that a large part of my childhood was written in assembly

Considering busybox (statically-linked ls, etc.) is 2MB, 1MB is pretty impressive.

There was an interesting talk on this at Linux.conf.au a couple of years ago, trying to figure out why modern binaries are so large. http://www.youtube.com/watch?v=Nbv9L-WIu0s

> Bloat: How and Why UNIX Grew Up (and Out) - Rusty Russell, Matt Evans

> The 'ls' binary on the original release of Unix (version 6) was 4920 bytes long. Thirty six years later, 'ls' on Ubuntu is 105776 bytes. Is this the laziness of modern coders? Increasing features? Does 'cat' really now do 313 times more stuff, or is there something else going on?

OT: I find it slightly disturbing to read people's Google+ conversations that were imported to extend the YouTube thread. I hope YouTube/Google isn't really buying Twitch, despite the return that would mean for the Twitch investors.

As the comment in https://news.ycombinator.com/item?id=7769456 notes, these games were written in Asm while busybox is C.

It depends on the exact proficiency of the programmers involved and the compiler/platform/etc., but it's not unusual to have an order of magnitude difference or more between the same application written in Asm vs. a high-level language like C.

People have tried to rewrite standard *nix utilities in Asm; one example is Asmutils[1][2] which certainly illustrates the "order of magnitude or more" size difference. If you're curious about extreme size optimisation there are many cool examples of that in the demoscene, like 96KB games[3] and all the 4k/64k intros.

[1] http://en.wikipedia.org/wiki/Asmutils

[2] http://asm.sourceforge.net/asmutils.html

[3] http://en.wikipedia.org/wiki/.kkrieger

Well, Pitfall! II on the 2600 is 4 KB, and run in 128 bytes of RAM, and has 256 different levels.

See http://www.youtube.com/watch?v=MBT1OK6VAIU

Does that include artwork, levels, sound, everything?

Must do, the art is all very compact. 2 bits per pixel - so 4 colour palette or 2-bit grayscale in the first game. All you need is black, dark grey, light grey and white and you have Pokemon Red! Music is also pretty small, as it's synthesised you don't need to store samples, you can loop repeated sections to save space and so on.

This is the entire overworld for Kanto, for instance.

http://socks-studio.com/img/blog/tumblr_lkshcyoNE81qhydr5o1_... (Red/Blue)

http://1morecastle.com/wp-content/uploads/2012/09/MQ2-612x49... (Crystal)

It's not as big as you remember it, I'll bet ;)

Even Johto isn't much bigger:

http://members.shaw.ca/dwarkentin/Webpage/graphics/mpics/joh...

And as the person below also mentioned.. No, the credits for Pokemon are extensive. There may only have been four coders, but there were level designers, sprite designers, etc, etc.

yeah, he's referencing the size of the flash rom dump that the cartridges came with.

edit: oh, I didn't notice your question can be answered two ways. For the other half, I am unsure if it was 4 people on the whole project.

This is certainly a thing of beauty. See, for instance, the way the trainers are defined:

https://github.com/kanzure/pokecrystal/blob/master/trainers/...

It almost looks like a high-level language.

This is a pretty commmon technique in video games generally referred to as "data driven design". Basically put as much of the runtime decisions that are made into a data value that can be tweaked by designers without having to ask an engineer to do it each time.

Final Fantasy for the NES seems to be designed the same way. A lot of the spells are actually "call function A with strength N, call function B with strength M and flag X". And with a large enough vocabulary of functions and flags, you get fire spells, healing spells, instant death spells, protection spells, etc.

It's also common in embedded systems since it makes for extremely compact code. The data basically gets used as "instructions" for an application-specific virtual machine/interpreter (which may or may not be Turing-complete - most usually aren't.)

It's... beautiful.

Repo owner here. Yes, it's a disassembly, but also it compiles back into the original ROM if you follow the README (it's not a "dump and flee").

Would you care to comment on what tools are popular for disassembling these ROMs? I think it's a pretty neat hobby, anywhere suggested to read more about it?

From looking at the docs

Assembler used: https://github.com/bentley/rgbds

RE tools used: https://github.com/kanzure/pokemon-reverse-engineering-tools

totally missed that, thanks.

This made me wonder if it's possible to automatically reverse engineer a small binary file into human readable (and understandable) source code. Assuming you know the language and compiler used (and all of its quirks and optimizations), and considering that human written programs aren't so random and their patterns are most likely predictable, I think it should be possible though not at all trivial. Are there any projects attempting this?

Labels and comments go a long way to making an assembly project readable. I don't know how an automatic tool could interpret the human intention behind a label.

It's not that difficult, but I think the main obstacle is gathering and representing the collection of knowledge in a useful form.

There was a disassembler called Sourcer that would annotate code with a set of predetermined comments based on its knowledge of the PC hardware. For example a sequence of instructions that enabled the interrupt controller by setting a specific bit in its register would be identified and get the comment "enable interrupt controller". I seem to remember IDA can do the same thing, although it's been a while since I last used it.

The Hex-Rays Decompiler attempts to do this for analysis purposes (that is, the resulting code is intended to be human-readable, but not necessarily compiled): https://www.hex-rays.com/products/decompiler

Unfortunately, I've not sprung for a license, so I can't comment on its efficacy.

This is fairly nonlegal, right? ...

Distribution of copyrighted stuff, yes. Decompiling itself (if the author kept it private), probably depends on where you live.

It's about as illegal as OpenTTD is; the initial version of OpenTTD was disassembled TTD extremely literally rewritten in C.

Same thing is being done for Rollercoaster Tycoon 2 right now, though it patches the original .exe to use a .dll file that override the original ASM addresses and calls with C functions. I really, really like the maintainers gradual replacement approach.

https://github.com/IntelOrca/OpenRCT2/

Wow, thank you so much for mentioning this project (never heard of it before). I absolutely loved RC2 when I was younger and if I can get this to run with the GOG version I will be certainly do my share to bring it back as open source.

Excessively so

To sad that so much work is likely to vanish within a few days. But they probably knew what was coming.

Many famous Nintendo games have been publicly disassembled before, and Nintendo is either unaware or turns a blind eye. The only different thing about this disassembly is that it is hosted on GitHub, where it is much more likely to be seen by people that aren't already interested in ROM hacking and retroprogramming.

Thankfully Github doesn't do preemptive DMCA removals, so it looks like it's safe for the time being.

Unless they come to my PC and delete the files from my HDD, it won't disappear.

Relevant: https://bitbucket.org/iimarckus/pokered

That link is, alas, outdated. pokered is now located here: http://github.com/iimarckus/pokered

Thanks! I didn't know.

Well, it looks like I can finally catch'em all (after fifteen years!)

    printf("You caught them all!\n");

I'm a winner!

any clue what language the original development took place in?

Originally the game was written in a variant of asm resembling z80.

I knew that the Gameboys were Zilog machines, but I never really put any thought into game development. I imagined they used a higher level language during actual development and ran the code through something that would result in the assembly for use in whatever. Pretty cool stuff.

General purpose high level languages[1] didn't become practical in commercial game development[2] for even what we would consider to be "non-critical" code until Doom, the PlayStation era for consoles, and the Game Boy Advance era for handhelds. Pretty much everything produced for the systems before them was done completely in assembly, and the practice remained relatively common for a while afterward.

This is partially because C compilers of the time weren't that great, partially because "everything is a critical section" when you're pushing the limits of extremely limited hardware, and partially because C's virtual machine model does not fit the average 8-bit CPU architecture at all, making pretty much impossible to this day to compile regular C code to (say) 6502 machine code that is anywhere close to optimal.[3]

[1] Ok, many games had custom bytecode interpreters, like SCUMM or the typical RPG's textbox language, but that's not quite the same thing. They could have used FORTH more (were there any games that used FORTH?), but I guess even in the days of HP calculators, people hated RPN.

[2] I guess I'm ignoring the many games done in BASIC for the 8-bit micros, but there's a clear difference in quality between these games and the average NES action game.

[3] There is a C compiler for various 8-bit architectures called cc65, but it chokes on anything resembling modern C. To get anywhere close to the performance of even naively written assembly, you have to hold its hand with machine-specific annotations (like "stick this variable in the zero page," or "make every variable static because the machine has no stack-relative address modes") to the point that it's easier to just write in assembly from the start.

Actually Pokémon Crystal itself, the rom we were discussing, has an extensive higher-level scripting language built-in for events, messages and movement. It still looks very much like assembly, but it is built up of Pokémon commands instead of machine code.

For example, this is the script to choose your starter pokemon: https://github.com/kanzure/pokecrystal/blob/master/maps/Elms...

Not truly zilog z80. The GB processor lack the IX/IY registers and associated addressing modes of the z80 and it added a few instructions. It's closer to the i8080. The GB did use the z80 assembler syntax (thankfully!).

Some people still do z80 development. The community around TI graphing calculators has lots of people still doing wild stuff in z80 assembly. It's a fun platform.

Wow, it looks like half a dozen people have been working on this for two years...

I flagged this story because I don't like to see blatant copyright violations on HN. Instead, I would have loved to seen a tool that automatically disassembles a user-provided ROM to the equivalent of this repo.

> Instead, I would have loved to seen a tool that automatically disassembles a user-provided ROM to the equivalent of this repo.

Well ain't you fancy.

Look at the commit log. Please. This stuff can't be "automatically disassembled" into the great looking codebase it's currently presented as.

Whatever though, I guess asking some people to think for more time than it takes them to click a link is a bit much these days.

I did see the commit log. I believe the project could instead check in symbol names, data structures, and comments that tag addresses in the ROM. You would also want to group those symbols into logical translation units. The copyright status on this repo may still be murky (are the comments and symbol names derived works?) but much better than the current situation where the copyrighted ROM can be rebuilt from from the repo.

Edit: I believe you can do something similar with IDA database dumps. The database doesn't contain the original executable image but instead contains a log of the IDA commands applied to the imported image. Another user can import their executable image and "replay" the IDA commands in the database.

Have you written a program that can do this?

These people put a lot of hard work into something people find interesting. I'm glad this is on hacker news because I'm interested in how these games were written and developed.

> Have you written a program that can do this?

Heavens no, it's much easier to complain and criticize other people's work.

I had a feeling "being useful" is something people like OP don't actually do, and checking his online presence only proved me right. This is making me abnormally furious.

I have not but other open source projects have similar issues when dealing with copyrighted files. OpenJailbreak, for example, downloads copyrighted firmwares and then applies patches locally. They did not want to host modified Apple binaries in their open source project. They even went the extra mile and developed a library that can partially extract zip files served over HTTP so the entire firmware would not be downloaded. [0]

I agree that a lot of hard work has gone into the ROM reversing. I also cannot dispute that it is fascinating! I just wish the developers could have gone about the project in a manner that would not besmirch the project with copyright concerns.

[0]: https://www.openjailbreak.org/projects/libpartialzip-1-0/rep...

Right, but all you're arguing for is a shift of legal responsibility on a project that's unlikely to be bothered legally, which will in-turn add another meta layer of development for the people involved(let's build a patcher).

It's illegal, yes.

It's also : 1) a massive PR blow to sue fans who have taken an interest 2) a legal money-sink on decades old property that isn't producing less profit as a result.

For all you know, this github could have generated revenue for Nintendo through the revitalization of interest in the franchise using nostalgia against current day software developers...

Agreed, dotting the Is and crossing the Ts isn't what the developers want to spend their time on. I've unflagged the article.

You are aware that anyone can just Google "pokemon crystal rom", click two links, and get a pirated copy, right?

Literally nobody has used this to pirate Crystal.

Reply on news.ycombinator.com