Wisdom Tree banking support

[rondnelson99]

The simplest cartridges use 32KB banks to reduce mapper complexity and thus, cost. Wisdom tree did this back in the day and InsideGadgets is doing it now. By halving their size, it is feasible to convert an RGBDS game to work with Wisdom Tree by duplicating ROM0 throughout the bottom half of each bank. However, this method is wasteful and prevents using any of the additional flexibility offered by 32KB banks. It would be beneficial to have a dedicated mode in the linker to take better advantage of these features.

I see this being a flag to RGBLINK that does the following when passed:

1. Make the size of ROM0 dynamic. The linker could pack in all the ROM0 sections, and then shrink the total size of ROM0 down to the space used. ROMX can then grow to occupy the remaining space. This way, if a programmer was to only use half of ROM0, every single bank of ROMX can become 1.5 times as large, drastically increasing effective storage. Also, if ROM0 exceeds 16KB, compilation would not need to fail; storage efficiency would only be reduced.

2. Make bank 0 of ROMX separate from ROM0. This is simpler in concept. With 32KB banks, the top half of bank 0 is not the same thing as the common bottom half of the banks. This could be used to add one bank of extra storage to the programmer.

3. Appropriately duplicate ROM0 throughout each bank so that the outputted ROM can be properly formatted for 32KB banks.

A practically similar way of implementing 1 would be to make each bank of ROMX and ROM0 32KB, but copy and reserve the ROM0 sections in every bank of ROMX before placing ROMX sections. This would be more flexible to the programmer since ROM0 would not need to be contiguous. With this method, some RST handlers could be bank-specific and "holes" made by aligned or fixed ROM0 sections could be filled in by ROMX sections. The practical differences between these methods are minor, but I don't know which one would be easier to implement.

If 1 was implemented, an option to duplicate the extra parts of an oversized ROM0 for regular MBC games would become a potentially low-hanging fruit. This way, if a programmer was almost done with their game but was running out of ROM0, they could just throw a little more storage at the problem rather than potentially having to refactor large parts of code.

A goal when writing this request was to make the new features fairly transparent to the programmer. The concepts of ROM0 and ROMX are not abandoned, just optimised to play better with 32KB banks. This way, a programmer could take their existing MBC game and only need to change the bank-switching code to make a Wisdom Tree build and run on those $15 2MB carts. Potentially large amounts of space could be freed up in the process. Likewise, a programmer making a game for Wisdom Tree or another cart with 32KB banks could simply flip a compilation switch to make an MBC version of their game.

I understand that this is a large request with perhaps a small audience. If there is no interest in such a feature, that is totally understandable.

[ISSOtm]

Isn't this a subset of #524?

[rondnelson99]

Well, at first glance it would seem so, but it seems like the two main parts of my proposal are not covered by #524. My proposal centres around ROM0 being resized at runtime and also duplicating ROM0 throughout each bank. The dynamic sizing is mainly what makes my proposal especially useful, although I could see it being maybe hard to implement? Maybe I'm missing something in ax6's spec, but I didn't see any option to declare a section type that gets duplicated many times throughout the output file. If the layout file were to allow a section type that basically declares a section in all banks of the output file, then my alternate method of making goal 1 work would be possible.

Perhaps this would be better spun into a comment within #524. I can see how if RGBDS were to support another mapper, it may make more sense to go the extra mile and support all mappers using ax6's proposal.

[ISSOtm]

Okay, I just read the full OP: I initially assumed #524 would cover a request for supporting a specific mapper. I'm also not sure why you keep referring to #1, being a very old bug report about RGBDS crashing on OpenBSD.

I'm vetoing dynamically resizing memory regions until at least #524 is implemented, since it is known to be more useful, and I do not want its already daunting complexity to be further increased by committing to compatibility with this flag, should it be added first.

[aaaaaa123456789]

Dynamic resizing would be easy to add to #524 (just allow a single-bank alias to cover multiple banks, so ROM0 would alias all ROMX banks), but I agree that dynamic resizing is probably adding to the complexity, and implementing #524 as it stands would already allow fine control of the boundary quite easily.

[rondnelson99]

My bad about the # 1 thing. I was referencing my bullet points of the original issue, and I never intended them to reference another issue. I'll change those now. It does seem that a multi-bank alias in #524 would be the way to go here.