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 (2024-12-21 07:10:21)
Offline
On cartridge reset (i.e. RESET pin being asserted), the mode B register appears to be set to 0x7F (all bits set), the mode C register appears to be unchanged (i.e. its lower 4 bits are the same as before), and the mode D register appears to have the semaphore set back to 1 (plus whatever active command is cancelled, at least with the immediate alarm command). The IO index also appears to be unchanged.
Last edited by CasualPokePlayer (2024-12-22 21:54:12)
Offline
sfiera wrote:
There’s also the behavior of repeating (daily) alarms. I seem to have had [$2B…$2D] = $4, $1, $9 in there when I set up a daily alarm but that value ($914 = 2324) doesn’t have an obvious interpretation. Could be another a case of a flag ([$2D] & $8) triggering behavior, though I don’t know what the remaining $114 would be
The behavior of these "daily alarms" seems to be activated with (day & 0x800) != 0, then (day & 0x700) >> 8 becomes the "increment" amount, increasing the day in the alarm each time the alarm time passes. $9xx means daily events, $Axx means events every 2 days, and so on until $Fxx which means weekly events (every 7 days). If the increment amount is 0, no increment is actually done (+= 0 is nothing), so it becomes (kind of) effectively as if the 0x800 bit was never set. Increments also only affect the lower 8 day bits, when it "overflows" it does not affect the upper 4 bits.
Note too that with these repeating alarms, the alarm day appears to be masked by 0xFF for both the alarm day and alarm RTC for comparision, i.e. only the lower 8 bits of the alarm day and RTC day is compared in this case. This means these alarms still function regardless of whatever upper 4 bits get set in RTC days. This also means having an increment of 0 sort of actually acts like an increment of 256 in a way (without actually doing any increment of course).
Another very interesting note is these repeating alarms do not work with the terminator alarm, for whatever reason. In fact having that 0x800 bit set in days just makes the terminator alarm completely nonfunctional as an alarm, unable to be triggered at all, regardless of the day (even setting the RTC day to 0x800 does not work). Not sure why this is even the case, the 0x800 bit in minutes appears to still be ignored (setting RTC minute to 0x800 doesn't make it trigger still), and without the 0x800 bit in days it appears to work just fine. Quite strange. All other alarms work fine with this repeating alarm anyways.
Offline
The alarm list terminator alarm appears to only actually be considered a terminator if the alarm tone is not $0x (so $10-$FF, i.e. some "valid" alarm tone selection).
Offline
Unsurprisingly, a non-repeating alarm with 0 minutes and 0 days can actually trigger, it just takes waiting for the day counter to overflow from 4095 to "4096" before that happens. Only by having $0x for the alarm tone does an alarm in the alarm list be properly disabled.
Offline
endrift wrote:
If you manually reprogram the time ahead 10 minutes, the alarm registers also advance by 10 minutes.
I can't seem to replicate this behavior at all. In fact, the closest I can even find such behavior appears to just be the game manually doing such, not the mapper automatically changing alarm times on RTC change.
Offline
CasualPokePlayer wrote:
For alarms from time passing, they will not appear to trigger if the alarm list is not properly terminated.
Looks like this was a faulty test, these alarms appear to trigger just fine. Not sure what happened before causing them to not trigger?
On this note, registers 0xE-0xF get updated on an immediate alarm trigger even if the alarm selection is $0x (i.e. no alarm).
Offline
CasualPokePlayer wrote:
If the increment amount is 0, no increment is actually done (+= 0 is nothing), so it becomes (kind of) effectively as if the 0x800 bit was never set.
This apparently was somewhat wrong. If the increment amount is 0, the alarm behaves extremely weirdly. It appears to become some sort of "extended" alarm, taking in the next 8 nybbles (and those next 8 nybbles no longer act as an independent alarm, including no longer able to act as a terminator alarm). Within the next 8 nybbles, the first 6 don't appear to do anything? The last 2, which would normally correspond to the alarm tone of the next alarm, end up affecting this "extended" alarm's behavior. Reading these 2 nybbles as LE for a byte, bit 4 acts as another "enable" bit for the alarm (for whatever reason). The day increment amount gets determined mostly by the lower 4 bits: 0-5 and 9-C increment by 0, 6 and D increments by 1, 7 increments by 2, 8 increments by 3, and E-F use the upper 4 bits of these 2 nybbles as the increment amount itself. The lower 4 bits of these 2 nybbles ends up getting modifed on the alarm trigger too, depending on the lower 4 bits again: 0-A and E set it to 0, B sets it to 6, C sets it to 7, D sets it to 8, and F sets it to A. The pattern here seems completely nonsensical, so perhaps this is just some bug, or maybe some scrapped feature (has this kind of alarm been observed to be set in any game?).
If this "extended alarm" is attempted to be set at 0xF7-0xFF, to try to extend to 0x0-0x7, it won't do anything particularly cool. Registers 0xA-0xB (i.e. pointer to end of the alarm list) end up getting set to 0xFF on the minute the alarm would be "triggered" (although of course the alarm is not trigger here). On any other minute increment, it ends up getting set to 0x0F, which is 8 more than the usual 0x07 on the alarm list not being terminated. Quite strange.
CasualPokePlayer wrote:
Another very interesting note is these repeating alarms do not work with the terminator alarm, for whatever reason. In fact having that 0x800 bit set in days just makes the terminator alarm completely nonfunctional as an alarm, unable to be triggered at all, regardless of the day (even setting the RTC day to 0x800 does not work). Not sure why this is even the case, the 0x800 bit in minutes appears to still be ignored (setting RTC minute to 0x800 doesn't make it trigger still), and without the 0x800 bit in days it appears to work just fine. Quite strange. All other alarms work fine with this repeating alarm anyways.
This is also wrong info, I was (I think) testing with an increment amount of 0, which caused issues here since this was the last alarm and thus the next alarms were nonsense or at the end of the register space, resulting in the alarm not triggering. Terminator alarms can be repeating alarms just fine (as long as it's not this weird extended alarm, which has to go with these additional rules; this weird extended alarm can act as a terminator alarm just fine anyways)
Last edited by CasualPokePlayer (Yesterday 09:32:31)
Offline
Repeating alarm with increment of 0 appears to be even more complex, the last of those first 6 nybbles seems to affect behavior too, kind of making a total of 3 nybbles at least (and maybe more?). It'll be a while to figure this out...
On a different note, I have another HuC3 cart now, with IR this time. The IR doesn't seem to be particularly special. Mode E is IR mode. Bit 1 appears to be always 0. Bit 0, when read, has the IR received. Bit 0, when written to (presumingly, based on game behavior), sets IR to be emitted. The IR emitted and receiver are separate, and the receiver appears to always be active, able to sense IR. It does not detect your own IR emission. None of the HuC3 I/O appear to change if IR is being emitted or if it's being received.
Offline