Skeetendo

’Cause all games were better on the GBC

You are not logged in.

  • Index
  • → Help/Question
  • → [pokered] Shifting data in WRAM causing game-breaking oddities

#1 2018-11-08 09:04:45

KeiTaRo
Member
Registered: 2015-12-05
Post 53/56
Website

[pokered] Shifting data in WRAM causing game-breaking oddities

Hello all! I seem to have ran in to a rather weird issue that I'm unsure of how to tackle. I recently made [wWarpEntries] obsolete by simply making the game read warp data directly from the map's object data rather than memory. In doing so, I only needed two bytes of memory, which freed up a whopping 126 bytes at this location! (if you're ever running low on WRAM space, try this one out)

That worked perfectly fine with no complications. I then decided, however, that I wanted to move these free bytes to an earlier part of the RAM map, so that I could consolidate it with some other free space I had and organize it closer to WRAM locations that it related to. Herein is where things got a little weird.

the [wWarpEntries] label is located in the 0xD000 range of WRAM, aka Bank 1. I attempted to move the empty space directly before the "Sprite State Data" section, normally 0xC100 near the beginning of Bank 0. Because this and the "OAM Buffer" section are hardcoded to fixed values and therefor at fixed lengths, I had to change the address at which they started, as well as make Bank 1 start 126 bytes sooner than it normally would, to compensate for having the space removed from there. This also worked perfectly fine and compiled A-OK. The data is currently not being used, and to my knowledge no other addresses are overflowing in to one another as a result of the data shift.

The part that's weird, however, is when I load the game now, all OAM data seems to be completely broken. Nidorino doesn't show up in the intro, Red doesn't show up on the title, and the game all but completely locks up after the name entry intro. From what I can tell, nothing is being written to the OAM addresses starting at $FE00, despite [wOAMBuffer] seeming to receive the correct data as it normally would. Only thing I can possibly think of is that there's some sort of hardcoded value who's toes I might have stepped on by moving the start position of all of the WRAM sections? The RAM addresses themselves all seem to be receiving data as they should........ Any insight on this would be excellent, and please let me know if I'm not explaining this well so I can try and clarify.

TL;DR: moved the start positions of WRAM sections, OAM is broken?


EDIT: ....I don't suppose the fact that [rDMA] means the Gameboy can only load OAM data from an address ending in 00 would have anything to do with it? :| will have to screw with this later.

Last edited by KeiTaRo (2018-11-08 09:27:29)

Offline

#2 2018-11-08 22:21:36

KeiTaRo
Member
Registered: 2015-12-05
Post 54/56
Website

Re: [pokered] Shifting data in WRAM causing game-breaking oddities

Aha!! That WAS the culprit after all. Every single function which passes the address of wOAMBuffer to the appropriate registers does so by dividing it by 100. In doing so, you're essentially only left with the high byte (which, in a vanilla game, would be $C3) ... this is done because [rDMA] only takes a single byte, meaning is assumes any address referenced is $xx00, which in other words would give you an address of $C300 in this case.

Because I had offset wOAMBuffer to $C3C2, the math was still leaving us with $C3. The Gameboy therefor was still expecting to transfer OAM from $C300, where it no longer was. I shifted a few more things around to further offset it by another $3E bytes and made it so wOAMBuffer now begins at $C400. This fixed it immediately. Woohoo! The Game Boy sure is a particular little beast...

Offline

  • Index
  • → Help/Question
  • → [pokered] Shifting data in WRAM causing game-breaking oddities

Board footer

Powered by FluxBB