Extend GBA memory map to include non-mapped ranges

[Drakmyth]

While RAM digging a GBA game, I came across a number of values that looked suspiciously like pointers except that they began with 0x04 and 0x08 prefixes, but as this documentation suggested I would only see 0x02, 0x03, and 0x0e prefixes I was confused about what I was seeing. A helpful soul on the RA discord kindly provided me with a more detailed memory map that explained I was seeing pointers to I/O and ROM.

Although such pointers can't be accessed by achievements, having these ranges documented so developers can understand what they are seeing is extremely helpful.

[wescopeland]

cc @Jamiras I feel unqualified to review this. Maybe you have some thoughts?

[wescopeland]

cc @televandalist Maybe you have thoughts on this one?

[Jamiras]

Per https://problemkaputt.de/gbatek-gba-memory-map.htm and https://gbadev.net/gbadoc/memory.html:

• Addresses in the 0x08 range are ROM data
• Addresses in the 0x04 range are I/O registers.

ROM data is immutable, and therefore there's no reason we'd need to watch it for changes.

I/O registers control graphics, sound, DMA, and other features. I don't see how they would be useful for achievements. I'm also skeptical that any game would have pointers to them.

The user is effectively asking us to duplicate the documents I linked above. Perhaps it would be sufficient to link to them instead?

[Drakmyth]

I/O registers control graphics, sound, DMA, and other features. I don't see how they would be useful for achievements. I'm also skeptical that any game would have pointers to them.

I came across pointers into I/O Registers while digging Space Twins. It's not so much that they are useful for achievements, rather that I was having a difficult time understanding what the memory I was digging into was doing. I assumed they weren't pointers because the RA Docs didn't mention those ranges but they also weren't behaving like normal values when I tried to modify and freeze them. It wasn't until I asked on Discord and got linked the full memory map that I was able to make sense of what I was seeing.

The user is effectively asking us to duplicate the documents I linked above. Perhaps it would be sufficient to link to them instead?

I suppose that's true. My preference would be to not have to jump to an external site (which may or may not continue to be available) particularly when the information being documented isn't going to change, but I'll leave the logistics of the best way to make the information discoverable to RA devs up to you all.

[redwizard42]

I suppose that's true. My preference would be to not have to jump to an external site (which may or may not continue to be available) particularly when the information being documented isn't going to change, but I'll leave the logistics of the best way to make the information discoverable to RA devs up to you all.

Most platforms here have a more expansive memory map than we define in either the docs or in the code that handles how it is exposed to the developer. I built a habit of searching online for "platformName memory map" so I know what things like pointers to RAM may look like. There's maybe some benefit to knowing something is, say, a pointer to I/O registers or a pointer to the loaded ROM data, but we can't really use those, and I think it's arguably better to not overwhelm.

[Drakmyth]

I built a habit of searching online for "platformName memory map" so I know what things like pointers to RAM may look like. There's maybe some benefit to knowing something is, say, a pointer to I/O registers or a pointer to the loaded ROM data, but we can't really use those, and I think it's arguably better to not overwhelm.

Perhaps that guidance should be documented somewhere then? My ultimate point is just that, operating under the assumption that most junior devs do not have prior software development experience, there is currently no RA-specific documentation or guidance on memory maps that I've been able to find (outside of the console-specific tips page, which lists partial memory maps for a small selection of consoles) and requiring junior devs to look up external documentation and dig through the implementation of rcheevos to understand which ranges have been mapped and how to interpret the memory they are digging through seems like a strange barrier to put before them and one that is easily made more approachable.

[redwizard42]

I built a habit of searching online for "platformName memory map" so I know what things like pointers to RAM may look like. There's maybe some benefit to knowing something is, say, a pointer to I/O registers or a pointer to the loaded ROM data, but we can't really use those, and I think it's arguably better to not overwhelm.

Perhaps that guidance should be documented somewhere then? My ultimate point is just that, operating under the assumption that most junior devs do not have prior software development experience, there is currently no RA-specific documentation or guidance on memory maps that I've been able to find (outside of the console-specific tips page, which lists partial memory maps for a small selection of consoles) and requiring junior devs to look up external documentation and dig through the implementation of rcheevos to understand which ranges have been mapped and how to interpret the memory they are digging through seems like a strange barrier to put before them and one that is easily made more approachable.

My experience is that devs rarely need to know this information (though I do find it helpful); the people usually getting mad about it are people with previous reverse-engineering experience. I did type up a bit about RA addressing scheme and some information regarding how to find information, but I'm not sure console-specific-tips is the right page for it, so I haven't done anything with it yet.