Discussion about software development for the old-school Gameboys, ranging from the "Gray brick" to Gameboy Color
(Launched in 2008)
You are not logged in.
CasualPokePlayer wrote:
0x1E-0x1F -> Always 0xE 0x1 ???
I suspect this is actually the IO index. It would then make sense why it's seemingly stuck at 0xE 0x1 (0x1E has 0xE and 0x1F has 0x1, matching up with their addresses)
Offline
CasualPokePlayer wrote:
0x08-0x09 -> Always 0x0 0x1 ???
0x8-0x9 appear to just be the mode B register. Register 8 is the lower 4 bits, and register 9 is likely just the upper 3 bits (with bit 3 not normally settable / stuck at 0?), although in practice you can only see 1 bit change. Register 8 happened to be 0 in my tests since I wasn't setting the lower 4 bits for the read command (since they don't do anything), but if they're set then register 8 will directly correspond to such. Register 9 can in practice only have 2 values seen, 0 and 1, depending on if the read command (0x0?) or read+increment command (0x1?) is used.
Last edited by CasualPokePlayer (2024-12-18 00:22:37)
Offline
Register 7's bit 0 allows for alarms to trigger over time (as said before). This interestingly does not affect the semaphore directly, it will stay as 1, and thus allows for executing a command while the alarm is playing. This doesn't really lead to anything interesting, the command just gets delayed until the alarm finishes playing. This also means if you try to play another alarm while an automatic alarm is playing, it'll just be delayed until the current alarm is done playing.
Register 7 also appears to have another meaning: bit 1 will be set upon the first extended 0xE command (i.e. the first of the two alarm commands to trigger an immediate alarm). This bit gets cleared after any command it seems, which also thus means after doing a read, thus allowing this state to be visible. It doesn't appear to interfere with the set alarm command (which does care about bit 0).
Last edited by CasualPokePlayer (Today 07:10:21)
Offline