Allow a ROM to be built without RGBFIX
- Dominant language
- C++
- Stars
- 1.6k
- Forks
- 193
- Avg merge
- 1d 33m
- Merged PRs (30d)
- 23
Description
Some people have complained about RGBFIX making the build process a little awkward, and in practice it tends to be (if RGBLINK fails, you typically have a half-baked ROM, which build systems often handle incorrectly). I've also seen many people being confused as to why RGBLINK's output was incorrect, and it's much harder to blame them compared to expecting RGBASM's output to be correct, since that “proto-ROM” is *almost* the right shape.
Nonetheless, I think that we shouldn't try to shove all of RGBFIX's flags onto RGBLINK, so my proposal is to give it the only functionality that cannot be reasonably achieved through other means: computing the checksums. All of the header's other fields would be set at assembly time, helped by a `header.inc` defining all of the header constants; this also means that we'd drop the special header-setting functionality, punting that to the project's `header.asm` to handle however it wishes.
(I know this is me doing a 180° from previously arguing that the header should be maximally set via RGBFIX, but I have more hindsight now :)
Contributor guide
Research direction
Start by tracing how RGBFIX, RGBLINK, and RGBASM currently handle ROM headers and how header.inc and the project's header.asm would fit into that flow. Review the existing build path and related tests, if present. Done means a ROM can be built without RGBFIX, with header fields set at assembly time and checksum computation still supported.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- build-system, compilers, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100