Add sgb.inc

[dmitry-shechtman]

Closes #76

[Rangi42]

Oh, thanks! Good idea to make this a third .inc file, given all those super-specific but official SGB values (SGB_SOUND_A_LASER_SMALL, really? lol).

It will need comments briefly mentioning what all these things are, like hardware.inc's heading/subheading/description structure, and to follow the formatting conventions (e.g. lowercase def equ).

Also, B_* bit constants are appropriate for Boolean values stored in single bits. I don't think they really make sense for things like SGB_SOUND_A_PITCH, a two-bit value. We have examples of how to handle multi-bit flag values, e.g. rSYS's modes.

Anyway, this is good reference to expand off of!

[dmitry-shechtman]

It will need comments briefly mentioning what all these things are, like hardware.inc's heading/subheading/description structure, and to follow the formatting conventions (e.g. lowercase def equ).

Sure thing, I just had to get something out there quickly.

Also, B_* bit constants are appropriate for Boolean values stored in single bits. I don't think they really make sense for things like SGB_SOUND_A_PITCH, a two-bit value. We have examples of how to handle multi-bit flag values, e.g. rSYS's modes.

I'll have a look.

Also, I just noticed that the actual MLT_REQ constants are missing. Will add them later on.

[dmitry-shechtman]

Having seen the SYS_MODE constants, I am of the opinion that the method suggested herein is more robust.

I'm OK with changing the names, but not with hardcoding the values in binary form.

[dmitry-shechtman]

I'm OK with changing the names, but not with hardcoding the values in binary form.

May I suggest S_ to indicate shift amount? This would also apply to e.g. colours in rBGP.

[Rangi42]

Sounds like a good compromise; I could accept an S_ constant.

[dmitry-shechtman]

I understand the convention of using the A suffix for addresses, e.g. OAMA_Y.

I am wondering whether SGB_SOUNDA_A won't look ridiculous.

[dmitry-shechtman]

Again, turning it into a prefix seems appropriate:

• A_SGB_SOUND_A
• A_SGB_MLT_REQ_PLAYERS
• A_SGB_MASK_EN_MASK

[nitro2k01]

As said in #76

I don't like the name JOYP_SGB_MLT_REQ for this constant. Unless there's precedent for using this name that would warrant keeping it, I'd suggest a different name. The reason is the REQ at the end. REQ is the verb for the SGB command: request multiplayer access. What you do with rJOYP at this point strictly has nothing to do with the SGB command MLT_REQ. MLT_REQ was instead used to change a setting and the command has already finished at this point. The name, as is, also doesn't doesn't explain what the purpose of the constant is, just that it's related to MLT_REQ somehow.

I also have some issues with the semantics how things are used in pokered.

	and JOYP_SGB_MLT_REQ
	cp JOYP_SGB_MLT_REQ

These constants actually have different meanings, despite being the same value. The first one is a mask to isolate the two lowest bits. The second is the ID for player 1. What the code does is to check if the player ID ever changes from the value for player 1, which also (by design) happens to be the same value that a non-SGB would return when no buttons are selected.

	ld a, JOYP_SGB_ZERO
	ldh [rJOYP], a
...
	ld a, JOYP_SGB_FINISH
	ldh [rJOYP], a
...
	ld a, JOYP_SGB_ONE
	ldh [rJOYP], a

This does not actually represent what that code is doing. It's not sending the SGB data at this point, but rather doing a "regular" read of the joypad, which also increments the player index at some stage, maybe when the selected button group changes from JOYP_GET_BUTTONS to JOYP_GET_NONE. (I forgot when exactly this event happens.)

Using the data transfer constants is obscuring what the code actually does. (The added delays also obscure what the code does. They shouldn't be needed, although that's Nintendo's fault and a disassembly can't do much about that.) I'd suggest using the regular JOYP_GET_BUTTONS/JOYP_GET_CTRL_PAD/JOYP_GET_NONE constants in that routine in pokered, as that better represents what the code does.

For hardware.inc, I'd suggest constants with names along these lines:

DEF JOYP_SGB_MLT_MASK EQU %000000_11
DEF JOYP_SGB_MLT_P1 EQU %000000_11
DEF JOYP_SGB_MLT_P2 EQU %000000_10
DEF JOYP_SGB_MLT_P3 EQU %000000_01
DEF JOYP_SGB_MLT_P4 EQU %000000_00