Stored in rom at 0x9B2C. $00 30 is the dark blue that the game was released with.
This value gets stored to offset $ ???? in sram (the .srm file that stores savegame data) and this location is where the ram loads it from when a saved game is resumed. To quote chillfeez: “ the immediate next op stores that value in the custom window background portion of SRAM.” So it sounds like the window color in sram is available soon after it’s declared at game start… in the asm function starting at 0x9B2E…
Ideally, the Bestiary would load its window color from this srm offset too, so it would align with the player’s color choice and always be royal blue.
When I ID where the srm stores the window color, I can attempt to hack the Ultima Bestiary to inject the user’s color choice from srm, versus the hardcoded royal blue color. This color may or may not be _____ based on a calculation from a screencap.
The rom stores palette data for all the map sprites in a list of values. There are only 4 possible color palettes for all the playable characters in FF4, and those data live at:
$0AB2FA
in a rom without the leading header bytes.
The 4 possible map sprite palettes will show up as values 00, 01, 02, or 03.
Here’s how it looks by default— the characters are in the exact same order that they appear in the ff6tools site, so Dark Knight Cecil is first, then Kain, then Child Rydia, etc.
The final value of 05 is unique to FF4 Ultima because chillyfeez hacked in a custom palette for the new playable character (Golbez). It corresponds exactly to the Blue Dwarves in the underworld!
So if you’re editing the map sprites and have changed them in ff6tools, you need to adjust them in this array as well. Regardless of the palettes of the png files you upload for the map sprites, this array of values controls which colors get used by the game, and unfortunately these values aren’t changed directly by the ff6tools webapp.
See this page for more info and context on this topic:
Detailed Notes on Editing FF4 Map Sprite Palettes