More human-friendly names for some constants

[ISSOtm]

Taking inspiration from pokecrystal's constants, for example. This would allow them to use hardware.inc, as well. (cc @Rangi42)

[rawr51919]

While not impossible, it required a good chunk of constant names to be rewritten to make pokecrystal work under hardware.inc as it exists now

[rawr51919]

Taking inspiration from pokecrystal's constants, for example. This would allow them to use hardware.inc, as well. (cc Rangi42)

PR #32 shows what a hardware.inc with those constants would look like, to me it seems kinda cluttery since a lot of the same constants are more concise as they are. Yet it's there in case others want to weigh in on this.

[Rangi42]

The least human-friendly registers are the numeric ones. We already had aliases for some of those:

• rNRxx -> rAUD*
• rKEY1 -> rSPD
• rBCPS -> rBGPI
• rOCPS -> rOBPI

And version 4.10 added more:

• rP1 -> rJOYP (which had been commented but not yet defined)
• rHDMAx -> rVDMA_*
• rSVBK -> rWBK

Version 4.11 also added:

• rKEY0 -> rSYS

@ISSOtm Is that sufficient to consider this issue closed based on your original concept when opening it in 2022?

[ISSOtm]

Ehh... maybe? I feel like https://github.com/Rangi42/hardware2.inc achieves that goal more.

[Rangi42]

Yeah, good point. I also consider the REGB_FIELD and REGF_FIELD infix convention to be "unfriendly" (easy to look at it and wonder "which register is 'REGB'?"), so BIT_ and MASK_ prefixes would be an improvement.

[Rangi42]

Previous breaking changes in hardware.inc (removals, not deprecations):

• Version 3.0:
  • Renamed _HW to _IO
  • Renamed STATF_HB and STATF_VB to STATF_HBL and STATF_VBL
  • Renamed BOOTUP_B_OTHER to BOOTUP_B_AGB
  • Removed the o-prefixed "offset" constants from version 2.9 (e.g. oLCDC EQU $40 and then rLCDC EQU (_HW + oLCDC))
• Version 4.0:
  • Renamed CART_ROM_*K to CART_ROM_*KB (e.g. CART_ROM_32K to CART_ROM_32KB)
  • Switched to RGBDS DEF syntax

[Rangi42]

Although pret's names for many constants are more "human-friendly", we're likely switching to hardware.inc for the sake of consistency with other GB dev projects, and because hardware.inc now defines constants for every register's bit flags.

The old constants would be preserved in legacy.asm for backwards compatibility. Comparing the names, I think some are clear improvements (e.g. spelling out "PRIORITY" instead of "PRI", or "SCREEN" instead of "SCRN", "*_SIZE" instead of "*_B" -- just because the official instruction and register names are vowel-phobic doesn't mean user-defined identifiers have to be :P ), which is the main reason I'm still not certain about entirely switching. (That, and the REGB_NAME/REGF_NAME infix convention is so bad.)

[Rangi42]

So, how likely is it for a backwards-incompatible hardware.inc 5.0 release that changes the REGB_NAME/REGF_NAME convention to something else (e.g. BIT_REG_NAME/MASK_REG_NAME, or B_REG_NAME/F_REG_NAME, or REG_NAME_BIT/REG_NAME, or so on)? Unlike the official rNVWL (no-vowel) register names, the constant naming convention is just an invention from the 90s, and could be changed.

[Rangi42]

As @AntonioND pointed out, something like this was done for the Nintendo DS: the community started using new REG_-prefixed names (after considering other options), some of which were also changed for legibility (e.g. DISP_SR becoming REG_DISPSTAT, or SOUND_MASTER_VOL becoming REG_MASTER_VOLUME), and created registers_alt.h for backwards compatibility.

I'm proposing basically the same thing: change the infix B/F convention to some prefix/suffix (I'm not picky about what), expand a few overly-abbreviated names that aren't tied to official documentation (like PRI becoming PRIORITY), and provide a hardware_alt.inc file for complete back-compat. Call the whole thing version 5.0.