Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature request/proposal] Hardware layout description files (custom mapper support) #524

Open
aaaaaa123456789 opened this issue Jun 11, 2020 · 3 comments
Labels
enhancement Typically new features; lesser priority than bugs rgbasm This affects RGBASM rgblink This affects RGBLINK

Comments

@aaaaaa123456789
Copy link
Member

(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.

@ISSOtm ISSOtm added enhancement Typically new features; lesser priority than bugs rgbasm This affects RGBASM rgblink This affects RGBLINK labels Jun 21, 2020
@rondnelson99
Copy link
Contributor

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
Copy link
Member Author

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
Copy link
Contributor

Yeah, aliasall works for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Typically new features; lesser priority than bugs rgbasm This affects RGBASM rgblink This affects RGBLINK
Projects
None yet
Development

No branches or pull requests

4 participants