Open aaaaaa123456789 opened 4 years ago
rondnelson99
commented
2 years ago As mentioned in #982, I think it would be useful to have a section type that declares a section in all banks of another section type. I think this could use a similar syntax as the alias declaration, like the following:
ROM0: duplicate ROMX
This could potentially be expanded with options to only duplicate within a range of banks, but I'm not sure whether there would be enough value in that.
aaaaaa123456789
commented
2 years ago What you're looking for is essentially the same as alias, but with "broadcast to all banks" semantics. The syntax would most likely be the same, except for the keyword; there's no reason to make it look different when the semantics ("alias this chunk of addressing space under another name") are identical.
However, I'd advocate for something a lot more explicit than duplicate (which, as a word, has the same meaning as alias in this context, really). Perhaps aliasall?
rondnelson99
commented
2 years ago Yeah, aliasall works for me.
(Note: I'm well aware that this is a complicated, long term feature that won't see the light of day for a long time. "This is very complicated to implement" and "don't expect it anytime soon" are base assumptions.)
As of right now, the tool chain assumes a specific hardware layout. While this does match the GB/GBC, matching non-standard mappers is harder, and often not possible at all.
Therefore, my proposal consists of a hardware layout file, which would describe the addressing space and the binary ROM layouts. Custom and unusual mappers can be handled this way, as well as unusual configurations (e.g., using echo RAM). This layout file would be given as an input to the assembler and/or the linker (preferrably the latter), which would then be used as an input for the section allocation process (being similar to linker scripts in this regard).
I've written up a proposal in specification form. This is mostly because it's a format I'm used to, and therefore it is the best way I can explain a feature proposal as complex as this one; I'm not intending to set a format in stone this way, and I'll be happy to update the proposal document if we reach some consensus — I assume that the developer perspective of something like this would be very different from mine.
Proposed spec: https://gist.github.com/aaaaaa123456789/9ede2447ffde027f0fac1c54589d2ed4 Sample files: https://gist.github.com/aaaaaa123456789/9ede2447ffde027f0fac1c54589d2ed4#file-samples-md (it's the same gist, but I'm linking it here for convenience)
The sample files cover the current layout, as well as a few mappers that aren't properly supported right now by the tool chain, like MBC1 and MBC6.
Please let me know what you think. I don't expect this to be implemented within any reasonable timeframe, but I figured that some proposal is better than no proposal.