Link’s Awakening disassembly progress report – week 5 | Hacker News Reader

Link’s Awakening disassembly progress report – week 5

kemenaran.winosx.com

193 pointskemenaran19 comments

That you can apparently see where designers changed their mind when building a room, because items have sometimes been "painted over" with other items, is absolutely amazing. That is some kind of computer/game archeology that you have to be very lucky to be able to do.

I do wonder however if that's certain... in the example where bushes have been overlaid with flower titles, are we certain this does not change some property of the tiles in meaningful ways? In the same room, you can also see how the cave entry is painted over with the statue, and in this case that cave entrance is something that gets revealed later in the game.

In any case, a great series. This is exactly the type of content I come to HN for.

The flowers can also be cut as if they're bushes, making it a reasonably hypothesis that the bushes serve to make the tile "cuttable", and the flowers then just change the look.

I too enjoy the traces of development decisions that must have been made decades ago. As an example, when making a toy Gameboy emulator, I discovered Tetris writes to a memory address that is normally used for bank switching, yet the game has no memory bank controller. Given that it just barely fits in 32K, with 60 bytes or so to spare, I presume they were using such a controller during development and then maybe spent some time cramming it into 32K to spare the cost of the part.

There are a plethora of really neat design choices made to get the most performance out of consoles & handhelds. The only downside is it can make writing emulators or porting said code to another platform quite difficult.

A documented disassembly followed by a reimplementation seems to be a viable way to get games ported to other platforms.

Its definitely a way to go about porting games, but its laborious and sometimes hard to fully document the program's existing behavior, especially with uncommented assembly.

Yeah, and reimplementation is, arguably, more difficult than tweaking source code and recompiling. 8)

Way back in the day, I was working on a project to extract your score from a bunch of old ROMs across various platforms. Developers picked some insane ways of storing even something as simple as a score. The very worst I recall was some old game about, I think, catching falling pots or something. Instead of just storing a 4 digit number, they stored the score as 4 pointers to the location where that digit was stored in memory. They'd increase your score by adding a multiple of the images' size to that location, and they handled overflow manually. I assume the idea here was screen rendering performance, but it didn't seem like it could possibly be worth it.

Having written a fair share of deeply embedded assembly.. if you're used to writing this close to the metal on a small system, that may have actually have been the most straight-foward way. Since ultimately the score must be rendered to the screen, and that might be its only purpose, there was probably little point in holding a "raw" intermediate value. Adding a constant and a few instructions for rollover don't sound too bad in the grand scheme of things.

figuring out tricks like that looks so fun. my "embedded" experience has been hard real time but usually on things with decent amounts of rom and ram. so tricks like that weren't needed.

I never noticed Tetris trying to bankswitch before (I have also written a Gameboy emulator.) That's amusing.

The rooms' data compression remind me of the Pokémon sprites during battles in Pokémon Gen I/II (Red/Blue(/green) and G/S/Y). As I remember it, the in-battle sprites (which are fairly large) are "compressed" using a custom algorithm. IIRC, it does RLE, and has some facilities for doing dithering, which was used in a lot of the sprites to give the impression of more color depth than there actually was. And they were only 4-bit (white, black, and two colors) in G/S/Y!

That brings back memories! I actually reverse-engineered that exact sprite compression (at least the G/S variant) back in 2001, when I was involved in the early ROM hacking community [1]. I stared at disassembled Z80 machine code for many, many hours to figure out and document the various quirks. I wrote a decompression program in (terrible, self-taught) QBasic, the only programming environment I had access to / knowledge of back then.

[1] https://www.romhacking.net/utilities/59/

Oh, nice!

The compression algorithm is said to have been written by Satoru Iwata himself, giving a hand to the overloaded GameFreak team when the development of Pokémon G/S was hitting size limits pretty badly [1].

There is a readable version of the decompression routines in the Pokémon G/S disassembly repo [2]. As the code was originally written in assembly, it is not decompiled–only re-documented.

Which means the code we read is the actual code Iwata wrote it 20 years ago.

I really like seeing the traces of actual human beings in a disassembly. Noticing different coding styles; seeing where routines were written, then patched over later… We read code, but we see people.

[1] https://retrocomputing.stackexchange.com/questions/11476/how...

[2] https://github.com/pret/pokered/blob/10289bf/home/pic.asm

I think you mean 2-bit. 4-bit is 16 colors.

Oh, yes, you are correct!

That map image reminds me how big this game was by Game Boy standards. Impressive!

wow. Great way to understand how the games were created back then with the low storage space. It would be great if this game can be remade to play on the browser. I remember playing this from my older brother's console but never got through it because at the time, it was well before my time and the graphics just didn't work for me. Older now, and I feel like I can appreciate this game now and overlook the old graphics... I know emulators exists, but never understood how to set it up.

http://emulator.online/gameboy/

And lots of other sites that come up when I type “game boy browser emulator” into DuckDuckGo.

> it was well before my time and the graphics just didn't work for me. Older now, and I feel like I can appreciate this game now and overlook the old graphics

As mentioned on the featured article, Zelda: Link's Awakening is being released on the Nintendo Switch in a few months. You may be interested to see the graphics and art style: https://www.youtube.com/watch?v=_U-_XfDGgDw

Reply on news.ycombinator.com