Add constants for the base addresses of all four audio channels

[Rangi42]

The four audio channels use registers NRxy, where the channel number x goes from 1 to 4 (as well as 5 for general-purpose audio control), and the register kind y goes from 0 to 4 (as described in Pan Docs). However, not every channel uses all 0-4 "slots". In particular, there is no "NR20" or "NR40".

Despite this, some people have channel-generic audio routines, e.g. "reset all of this channel's registers to 0". It's safe to write to the nonexistent "slots" of some channel, because every channel has all five NRx0-NRx4 addresses reserved for it, even though some are unused.

It would thus be convenient to have "start of channel" address constants:

• Channel 1 starts at NR10/AUD1SWEEP
• Channel 2 starts at NR21/AUD2LEN - 1
• Channel 3 starts at NR30/AUD3ENA
• Channel 4 starts at NR41/AUD4LEN - 1

To match the AUD3WAVERAM address constant, I propose:

• def AUD1RAM equ $FF10 ($FF10-$FF14)
• def AUD2RAM equ $FF15 ($FF15-$FF19)
• def AUD3RAM equ $FF1A ($FF1A-$FF1E)
• def AUD4RAM equ $FF1F ($FF1F-$FF23)
• def AUDRAM_SIZE equ 5

[aaaaaa123456789]

Wouldn't it be much simpler to define the missing NR20 and NR40?

[Rangi42]

That would be misleading -- there is no register NR20 or NR40. Every audio channel reserves 5 contiguous bytes for its registers, and two of those four have a NRx0 register at the beginning.

[aaaaaa123456789]

Either there isn't a register, or there is a register with zero usable bits. The space is clearly reserved for the register, so whether there's actually a register there or not is purely academic — the reason why you can safely write to those addresses is because space for the register exists.
And people writing to it as if it was there are clearly treating it as if it was there. A read of write of $FF15 is clearly attempting to access an NR20 register that may not exist or may exist with all bits pulled up. Semantically, it's behaving as an NR20 register. I'm not entirely convinced there is no hardware at all behind that address.

But all in all, the only reason anyone would ever attempt to use $FF15 or $FF1F as addresses would be to access the maybe empty, maybe missing NR20 and NR40 registers. Naming them as such is just showing the obvious intent of the writer.

[Rangi42]

Also none of the NRxx names are self-descriptive, which is why hardware.inc had provided aliases like AUD1SWEEP since before the very first commit in this repo. (It's not clear from the recorded history changelog just when they were added.) So in any case we would want names that say "this is the start of the channel" (nothing about "AUD1SWEEP" says it's the first channel-1 register).

[aaaaaa123456789]

The NRxx names are the standard names used by every bit of documentation about the console. They've been in use since the 80s and they will continue to be in use for as long as development for the console exists. The alternates are just that, community alternates.

[Rangi42]

And this is a proposal to add more "community" names for the starts of each channel's RAM region.

Adding names for any more of the register addresses currently commented "unused" should be a separate issue, if you want to open one with suggestions.

[aaaaaa123456789]

As far as I know, the rest of the unused addresses are just that, unused. There's nothing that would obviously fit there. Occasionally we've found debug registers hiding in the dark, but by far and large, there's nothing there. These addresses, on the other hand, are obvious reservations.

[Rangi42]

This is where I noticed these constants would be useful in pokecrystal:

-	ld hl, rAUD1SWEEP
+	ld hl, AUD1RAM
 	call ClearChannel

-	ld hl, rAUD2LEN - 1 ; there is no rNR20
+	ld hl, AUD2RAM
 	call ClearChannel

Even if someone else proposed+implemented+merged rNR20 and rNR40 constants in a separate issue, they wouldn't be used there.

[aaaaaa123456789]

...because you switched the constants in commit 4c540aa43b43. The regular constants were in use until a month ago.

[Rangi42]

4c540aa43b43 does not exist. Assuming you mean the fact that recent 4.x/5.0 updates defined more bit+mask constants associated with the community register aliases but didn't define corresponding ones for the original aliases (e.g. now we have B_AUDENA_ENABLE but no B_NR52_ENABLE), please don't relitigate your grievances with that in this unrelated small issue. (Especially since your use case for hardware.inc is to copy out the register constants you need and not even use the bit/mask ones, so hardware.inc choices regarding them don't affect you.)