Update third-party repositories to use the latest version

[Rangi42]

hardware.inc tends to be vendored, and then rarely updated. Some users (like pret) have defined their own constants for some missing pieces (even when subsequent hardware.inc releases have added them). I'd like to PR these projects to get them up-to-date (or their owners can do it):

• gbdev:
  • gb-asm-tutorial (two copies)
• pret (@Rangi42, @mid-kid, @dannye):
  • pokered (needs to replace some of pret's invented names)
  • pokecrystal (needs to replace some of pret's invented names)
• LADX-Disassembly
• @ISSOtm:
  • gb-boilerplate
  • gb-starter-kit (submodule)
  • gb-bootroms (submodule)
  • gb-vwf-demo (submodule)
  • fortISSimO
  • fortISSimO-demo (submodule)
  • driverboy-demo (submodule)
• @AntonioND:
  • ucity
  • geometrix
• @pinobatch:
  • libbet
  • numism
  • 240p-test-mini
  • little-things-gb (many copies, might want to consolidate into common/src/)
• @LIJI32:
  • SameBoy
• @SuperDisk:
  • hUGEDriver
• @evie-calico:
  • esprit

[ISSOtm]

Note that hUGEDriver isn't mine, it's only a fork for PRs.

[AntonioND]

Is this really useful for completed projects, though? Updating repositories under active development makes sense (including the disassemblies, I guess), but updating the header file for projects that are finished doesn't make much sense in my opinion.

[Rangi42]

Some of these, like pokecrystal and libbet and ucity, are part of rgbds's test suite, so it's nice for them to be up-to-date.

Others, like gb-bootroms and gb-bootroms, are meant as references, so it's nice for their source code to be readable (which includes using the same hardware.inc people would be downloading themselves).

And a few, like geometrix and numism, are technically "finished" projects that could be left alone. I tried not to list projects that looked too old, where the RGBDS version would need updating too. But it's also useful to demonstrate that they could upgrade hardware.inc without any issues.

[Rangi42]

(I'd compare it to maintaining those projects by updating their syntax to build with latest RGBDS.)

[AntonioND]

(I'd compare it to maintaining those projects by updating their syntax to build with latest RGBDS.)

I disagree with this. Updating the syntax of projects makes sense because if not they just won't build. However, this is just a list of defines with a few numbers. Updating the header doesn't fix anything. If hardware.inc never changes for the rest of time, nothing bad will happen with the code of a project using that header.

I think it's great to have reference projects for beginners, but the ecosystem of every other language has programs with older styles and newer styles and people don't try to update everything to match the last "right way" of doing things.

[avivace]

I agree with @AntonioND here. Given also our limited bandwidth I don't necessarily see any advantage in wanting to update hardware.inc everywhere, like - what does it accomplish? It's not a dependency in a 'traditional' sense...

[Rangi42]

I had opened this myself so I remember to PR these. Would that be alright / accepted?

[pinobatch]

Libbet and the Magic Floor

No errors found.

144p Test Suite

Addition of TILE_X broke the Overscan activity of 144p Test Suite, which had TILE_P and TILE_X for the tile IDs of glyphs 'p' and 'x' (which spell "px", used as an abbreviation for "pixels"). I had to rename them to TILE_PI and TILE_XELS.

little things

Two projects do not use RGBDS: ca83 and nosuchthing. In other projects, I've consolidated all copies into common/src.

Numism

I've consolidated all copies of hardware.inc into gameboy/src.

[AntonioND]

The thing is that updating this header is more of a code style issue than anything else. It's equivalent to creating a PR to comply with the guidelines from here: https://gbdev.io/guides/asmstyle.html

Some more examples:

• You recommend using rgbfix to set ROM header values, but I prefer to leave them in the code: https://github.com/AntonioND/ucity/blob/04cdda3dda35e62501cf9543b73343935039ee4d/source/engine/init.asm#L143-L163
• I have a super simple Makefile that is nothing like what your starter kit uses.
• I have lots of GBTD and GBMB project files in the repository because that's what I used, and I don't really see any point in migrating that to rgbgfx.
• I like to indent inner loop code more than the rest of the code https://github.com/AntonioND/ucity/blob/master/source/simulation/simulation_traffic_trip.asm#L310-L333 (and sometimes I even consider "push/pop" pairs deserve their own indentation for clarity). You guys don't do it https://github.com/ISSOtm/gb-starter-kit/blob/a154fbe0a7ffd4076aa717e15f8a093f300f1a87/src/lib/crash_handler.asm#L153-L174 And I'm also quite inconsistent, I only do it in some places when I feel like it helps me.

Normally updating a library achieves useful things like fixing bugs. In this case it's just a list of values. I found it online and I thought it was kinda useful, but I never really considered it a library, just a shortcut to not write things down myself (even though it would have taken me less than an hour). I'm not really interested in receiving PRs to update hardware.inc "just because" whenever there are updates to it.

[Rangi42]

Okay, never mind.