
Link’s Awakening disassembly progress report – week 5 - kemenaran
https://kemenaran.winosx.com/posts/links-awakening-disassembly-progress-report-week-5/
======
anyfoo
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.

~~~
kmm
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.

~~~
CobrastanJorji
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.

~~~
dingu
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.

~~~
galangalalgol
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.

------
deathanatos
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!

~~~
wgjordan
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/](https://www.romhacking.net/utilities/59/)

~~~
kemenaran
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...](https://retrocomputing.stackexchange.com/questions/11476/how-
did-satoru-iwata-compress-pokemon-gs-to-fit-two-regions-on-a-single-cartridg)

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

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

------
leafeewick
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.

~~~
shasheene
> 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](https://www.youtube.com/watch?v=_U-_XfDGgDw)

