Saturn Pointers are Untenable #1046
Replies: 2 comments
-
See RetroAchievements/rcheevos#302 for why this occurs (and also why this is ultimately a detail in how existing cores emulate memory and how libretro is (arguably) incorrectly exposing that memory, and even not neccessarily what cores would do / won't apply for big endian systems). |
Beta Was this translation helpful? Give feedback.
-
Oh, well that explains why I didn't find anything about this in my search. Either way, it's not just Saturn for sure. Just more pronounced there than in Mega Drive. |
Beta Was this translation helpful? Give feedback.
-
So it seems that on every Sega system, the RAM exposed is byte flipped at a 16-bit level (each pair of bytes is reversed from the normal
big endian addressing of Sega ...as a sort of 16-bit psuedo little endian conversion?). This causes things like unaligned data (16bit or 32bit) being.. weird in RA space, but we can usually get around that via add source. Just makes RAM digging harder in those cases.
But it also means that on Saturn, the 32-bit pointers are in this order: 2143 instead of the expected 1234 (where 1 is the 'high' byte). I am lucky that the game I am working on has a pointer that I may need where the pointed-to data is always neatly within a 0x####0000-0x####ffff address range because I can treat it as a 16-bit pointer (until, inevitably it shifts outside that range for some player).
I think for ease-of-development, we need a way to handle this.
My observation is based on a debugging a Mega Drive game with an outsider debugger and noticing that the addressing was swapped this way, and then observing that it holds true for the other sega systems where I've worked with data of width greater than 8-bits. Either way televandalist and I have both witnessed the 2143 pointer byte order in Saturn specifically, which we can't really handle with existing sizes.
Beta Was this translation helpful? Give feedback.
All reactions