search

cvghivebrain / s1disasm

Sonic the Hedgehog (Mega Drive) Hivebrain 2022 disassembly
41 stars 8 forks source link

Use rs lists over equates whenever possible #2

Closed Awuwunya closed 2 years ago

Awuwunya commented 2 years ago

A major issue with equates when it comes to things like RAM mappings, ost definitions or sound driver RAM offsets is that you lose the ability to rearrange them dynamically depending on use. You could for example need to add a new array into RAM, but the difficulty is finding the appropriate amount of space. If you use an equate list, you will have to rearrange a lot of them, and you are likely to slot RAM addresses you want to move just anywhere they fit, rather than to keep the structure intact. Similar problems occur when you are trying to remove RAM addresses that are no longer necessary.

This is where rs tables come in handy. They provide the ability to rather than define a strict address, they rather allow you to use a size, and have the assembler resolve addresses automatically. They still do the same thing, but allow for insertion or deletion of items, and also are by definition showing the size of the array, so there is no confusion on that front either. It also provides automatic alignment with the instruction size parameter as well.

Here is an example of how I have used them in AMPS.

Brainulator9 commented 2 years ago

At the same time, I find it easier to work with things when I can easily tell what address a given RAM equate goes to, especially when it seems that certain addresses are aligned to certain boundaries (e.g. the sound driver is allotted $600 bytes starting at $FFF000, background positioning is at $FFF700, $FFFE00 is the initial stack pointer).

I also wonder: when it comes to addresses that currently do not have names, would a construction like "unk_FFFF" be recommendable under these circumstances? It seems like there's an effort to name all RAM addresses at some point, but RS-ing everything forces all RAM variables, used or not, to have names, and I worry this might be putting the cart before the horse.

Awuwunya commented 2 years ago

you can always use the listings file to find addresses, even though that could sacrifice alignment. Unknown addresses should be documented, but really just using unk_xxxx would work temporarily

cvghivebrain commented 2 years ago

I've started using rs for variables I've already checked and documented. The rest will be done as I go through the RAM. Unused space has been labelled "unused_xxxx". Hopefully there won't be any unknown addresses by the time I'm done, but until then I've just left them blank or equ with whatever label they had before.

Brainulator9 commented 2 years ago

Eh, I'll live. I do wonder if it would be worth it to put in the comments what the RAM address equates to in an unmodified ROM.

cvghivebrain commented 2 years ago

I forgot to mention, the original addresses are still there as comments.

Awuwunya commented 2 years ago

btw need help with this (or anything else for that matter)? been working on this a while ago (including updating the wiki) and certainly know Sonic 1 as a whole, so I think I can chip in some help, just if I knew what to do :P