gbdev / rgbds

Rednex Game Boy Development System - An assembly toolchain for the Nintendo Game Boy and Game Boy Color
https://rgbds.gbdev.io
MIT License
1.33k stars 175 forks source link

Unionizing ROM0 and ROMX bank 1 (pseudo "tiny ROM mode" for banked ROMs) #1134

Closed tobiasvl closed 1 year ago

tobiasvl commented 1 year ago

It'd be useful if there was a command line flag which "unionized" banks 0 and 1 of ROM, basically like tiny ROM mode does, but with additional ROM banks that it doesn't touch. Basically, make it so that ROM0 can range from $0000 to $7FFF (as in tiny mode) while still allowing additional ROMX banks > 1 (ROMX bank 1 could maybe be an alias for ROM0 like in tiny mode though).

My use case is this: I have disassembled an MBC-less (tiny) ROM that I'm hacking and improving. I want to make minimal changes to the original code, in order to produce a patch that is as small as possible (and containing as few original, copyright-infringing bytes as possible). I've added an MBC to the game, so there are now multiple ROM banks, and I'm adding my additional code/data to banks 2 and up. The problem is that the original code spans banks 0 and 1, using it as if they're one bank (which they originally were). I obviously make sure my new code in bank 2 is only called from bank 0, but there's no good way to assemble the code that makes up banks 0 and 1.

Other solutions and their drawbacks:

Rangi42 commented 1 year ago

that could potentially split code in the middle of an instruction, or data in the middle of a table/whatever, and also it's obviously a pain if I move stuff around

That seems like an appropriate solution to me—you want to know exactly what is split between ROM0 and ROMX 1, and it would encourage invalidly-split ROMs if there were a flag to "unionize" those two banks when an MBC is needed to access ROMX 1, 2, 3, etc.

ISSOtm commented 1 year ago

To sum up what has been said in a chat room; tl;dr this is too niche a feature to warrant RGBDS support.

As soon as the ROM becomes banked, ROM1 is no longer special. While physically it is contiguous to ROM0, logically it is not, not any more than any other ROMX bank. Therefore, I don't think giving ROM1 special preference is the way to go for generalisation.

And besides, this really wouldn't play nice with RGBDS' inherent assumption that no two memory regions overlap.

Therefore, rejecting the request; at least, I don't want to implement and maintain its complexity, but if someone else volunteers for those, then please feel free!

tobiasvl commented 1 year ago

That seems like an appropriate solution to me—you want to know exactly what is split between ROM0 and ROMX 1, and it would encourage invalidly-split ROMs if there were a flag to "unionize" those two banks when an MBC is needed to access ROMX 1, 2, 3, etc.

I want to know roughly where the split is, of course (to make sure I don't call into bank 1 from bank 2), but I don't need/want to know exactly where it is, and manually recalculate it if it moves a few bytes up or down. (That would mean I'd had to manually merge the split instruction/data, and then "re-split" it somewhere else, work I feel like the assembler could be able to do.)

To sum up what has been said in a chat room; tl;dr this is too niche a feature to warrant RGBDS support.

Fair enough!

aaaaaa123456789 commented 1 year ago

This is basically a special case of #524 anyway.