Accurately reflect which registers are actually available

[SonoSooS]

Trying to deal with #525.

Preview available at https://sonosoos.github.io/pandocs/Power_Up_Sequence.html#hardware-registers

Definitely more work is needed, as I think now these values need a proper re-test now, and also a new column for CGB/AGB in DMG mode, instead of this weird "X or Y" with a footnote thing.

This PR is just to get the ball rolling, I wouldn't merge this as-is. Definitely needs some edits, whether the values are correct or not, as I think there are better ways to display the initial regs.

As for the suggestion in #525, I do think that the triple dashes look good both on-page and in the source file, so I think that's what we should go with instead of N/A.

Observations:

• Does it really make sense that P1 would be anything but $CF outside of SGB/SGB2?
• Are OBP0 and OBP1 truly uninitialized? Don't have all the boys to test, but pretty sure it should be always $00, like every other reg.
• Feels like whoever did this test, they've ran the test in DMG mode on CGB/AGB. I think it needs a separate column for that, especially since there should be actual differences between real DMG and DMG mode.
• Shouldn't SC be $7C on CGB/AGB instead of $7F?
• I assume RP would also gated when in DMG mode, it wouldn't make sense for it to be enabled by default, so I'm changing it to what I think should be default ($3E).

[ISSOtm]

Looks mostly good to me, thanks! I'd just phrase differently the way CGB-only regs are visible in Non-CGB Mode.

[ISSOtm]

Definitely more work is needed, as I think now these values need a proper re-test now, and also a new column for CGB/AGB in DMG mode, instead of this weird "X or Y" with a footnote thing.

In which table? AFAICT the initial values don't differ between CGB and AGB.

• Does it really make sense that P1 would be anything but $CF outside of SGB/SGB2?

On CGB? The boot ROM polls player inputs for the manual palette override, so I'd say it does make sense.

• Are OBP0 and OBP1 truly uninitialized? Don't have all the boys to test, but pretty sure it should be always $00, like every other reg.

The fact that it's uninit'd means we can't be sure, and it also means that e.g. a quick reset and/or a flashcart menu could leave non-zero values in there. Hence the footnote's recommendation to avoid relying on anything there.

• Feels like whoever did this test, they've ran the test in DMG mode on CGB/AGB. I think it needs a separate column for that, especially since there should be actual differences between real DMG and DMG mode.

Yes, according to #525 (comment), that's what happened. Not sure about the mode differences, but I don't have the energy to test myself.

• Shouldn't SC be $7C on CGB/AGB instead of $7F?

Could be, if we assume that these values were taken from DMG Mode. That's a likely explanation, but further testing is required.

• I assume RP would also gated when in DMG mode, it wouldn't make sense for it to be enabled by default, so I'm changing it to what I think should be default ($3E).

Likewise.

[SonoSooS]

In which table? AFAICT the initial values don't differ between CGB and AGB.

I meant CGB/AGB in DMG mode compared to CGB/AGB in CGB mode, afaik there are some minor differences, although there may be none in initial values.

On CGB? The boot ROM polls player inputs for the manual palette override, so I'd say it does make sense.

Oh oops, I read it as $FF (no button selected), that's why I was confused.

I think it should be still $CF though, why would one of the buttons be pressed without pressing it?

And if one button is pressed (I presume A), why would it not be the same for other systems as well (except SGB) ?

The fact that it's uninit'd means we can't be sure, and it also means that e.g. a quick reset and/or a flashcart menu could leave non-zero values in there. Hence the footnote's recommendation to avoid relying on anything there.

Oh, I meant to provide a default value on "unmodified" hardware from coldboot with a basic ROM flashcart, so we could have a real value as if it were a commercial game, but still keep the footnote to not rely on it as too many things influence it.

Yes, according to #525 (comment), that's what happened. Not sure about the mode differences, but I don't have the energy to test myself.

Could be, if we assume that these values were taken from DMG Mode. That's a likely explanation, but further testing is required.

Likewise.

Cool, I'll keep my best guesses there then, and correct them if they end up being something else upon re-testing.

[ISSOtm]

I think it should be still $CF though, why would one of the buttons be pressed without pressing it?

I don't know, but I'm sure official software doesn't leave both bits selected... so those values are probably bogus. Again, research is required.

And if one button is pressed (I presume A), why would it not be the same for other systems as well (except SGB) ?

Because none of the lines are ever selected?

Oh, I meant to provide a default value on "unmodified" hardware from coldboot with a basic ROM flashcart, so we could have a real value as if it were a commercial game, but still keep the footnote to not rely on it as too many things influence it.

No: the values we provide are reliable; those aren't. Measuring on a single model never meshes well with uninit'd memory. So we'll keep treating it as all uninitialized memory: "don't touch". If someone wants to rely on the value their particular setup provides, they'll still be able to.

[SonoSooS]

I don't know, but I'm sure official software doesn't leave both bits selected... so those values are probably bogus. Again, research is required.

But what I meant is is that bootrom does leave them selected, but assuming the user doesn't press a button, why else would the lower nybble be not $F ?

Also my bad, $C7 would be START, not A. If it were A, it would be $CE.

I think that it's just a testing error from someone using a flashcart with a menu to run these tests.

Because none of the lines are ever selected?

They are selected though. $Cx means both lines selected, unselected would be $Fx instead.

No: the values we provide are reliable; those aren't. Measuring on a single model never meshes well with uninit'd memory. So we'll keep treating it as all uninitialized memory: "don't touch". If someone wants to rely on the value their particular setup provides, they'll still be able to.

I see.

I just meant that it could be possible to provide a real value (pretty sure OBP0 and OBP1 are also initialized to $00 on coldboot instead of fully uninitialized), but saying that this is guaranteed to be modified by external factors and not rely on it.

I guess I'm just being pedantic, as technically it's not a truly uninitialized value, it's just influenced by too many other things pre-execution.

[ISSOtm]

But what I meant is is that bootrom does leave them selected, but assuming the user doesn't press a button, why else would the lower nybble be not $F ?

Good point; I lack an explanation for this. Investigation is needed, as usual!

They are selected though. $Cx means both lines selected, unselected would be $Fx instead.

Woops, my bad, forgot about the active-low business. Good catch.

I guess I'm just being pedantic, as technically it's not a truly uninitialized value, it's just influenced by too many other things pre-execution.

That is exactly why I think, in practical terms, there's nothing of value to document there; it's preferable, at least for the goal that Pan Docs is aiming for, to discard such as too volatile to be "reliable initial values".

[avivace]

Let's get this merged and (possibly) continue in another PR. Thanks a lot @SonoSooS and @ISSOtm for the work here!

[ISSOtm]

Fair enough. We should gather what corrections are left to research, and open a follow-up issue listing them.

Off the top of my head:

• Researching if there are differences between DMG and Non-CGB Mode
• RP's default value has not been researched, the current value is only an assumption
• P1's default values that aren't $FF seem dubious, and need to be checked further.

[SonoSooS]

• P1's default values that aren't $FF seem dubious, and need to be checked further.

It should be $CF, as basically (most if not) all IO regs are reset to 0 after reset.

The only regs known not reset are BC, DE, HL, AF, and SP (so basically CPU regs sans PC and IME). And perhaps Wave RAM on pre-AGB (on AGB and AGS, the first bank of Wave RAM is shared with the CGB CPU, so it can be influenced).

I couldn't determine whether these are always reset on reset, or only 0 on coldboot (pulling /RESET on my AGS makes it execute the AGB bootrom instead of the CGB bootrom, so I'm not sure if it can be trusted to not accidentally RegisterRamReset some vital registers for this test to be accurate):

• All PPU regs ($FF4x) sans LCDC (and thus LY too)
• IE
• BCPS and OBPS

Also here are corrections for CGB/AGB which were not done in this PR (tested on my AGS):

• P1 is $CF
• SC is $7C
• OBP0 and OBP1 are $00 (though we agreed to keep it as ??, just still mentioning here)
• RP is $3E
• BCPS and OBPS are $40 (though it may be left as ?? for similar reasons OBP0/OBP1 are)

I'm unsure about this one, but HDMA5 might be $80 on boot. I've had an old capture, but not sure if it's fully trustable for this reg in particular.

[ISSOtm]

Are we talking about post-boot ROM values?

It does appear that the CGB boot ROM only polls the joypad in DMG mode, which would explain why it's still $CF in CGB Mode.

Regs that aren't initialised (e.g. OBPS) or otherwise relied upon by the boot ROM (e.g. SCX/Y), I'd prefer if they were noted as ?? until we have proof that CPU reset does reset them (likely from schematics). I think it's preferable to leave info up in the air and then adding precisions, rather than trying to backpedal on something that turns out to be wrong.

[SonoSooS]

Are we talking about post-boot ROM values?

My bad, these are pre-bootrom.

However RP and SC are not touched, and the rest can be verified in an emulator if using the initial values I've provided (basically all zeroes, except bit7 of HDMA5 which is set).