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

Reorg KERNAL use of $0100-$15FF so KERNAL-specific vars are grouped in a documented region #196

Closed
dansanderson opened this issue Feb 14, 2025 · 1 comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request

Comments

@dansanderson
Copy link
Collaborator

Is your feature request related to a problem? Please describe.
Today, the KERNAL API contract says that the KERNAL reserves all memory $0000-$15FF. We intend to document that $0002-$008F are only used by BASIC, such that programs that don't return to BASIC (or knowingly return to BASIC) can use some ZP without changing B (as many Commodore-targeting C cross-compilers do). We also intend to document that $00FB-$00FF are free for program use always. $0100-$01FF will always be CPU stack.

This is sufficient for machine code programs that use both the screen terminal and KERNAL I/O routines. For machine code programs that don't use the screen terminal but do use the KERNAL I/O routines, we could do better, by declaring KERNAL-specific use of $0200-15FF in the contract. However, right now we have a mix of screen terminal, BASIC, and KERNAL variables in this space, and no way to know about future needs. ML programs that only use the KERNAL for I/O can reclaim the unused RAM in this region.

Describe the solution you'd like
At some point (maybe once KERNAL bugs and features are settled), let's cash in on how the contract currently reserves $0200-$15FF as an opportunity to reorg the space, such that KERNAL-specific variables all live together near the top of the space. Reserve some wiggle room for future KERNAL needs, dedicate the rest to the screen terminal (e.g. screen memory at $0800) and BASIC, and demarcate these regions in the API contract.

Describe alternatives you've considered
Do nothing. It's only a small savings. Too specific an API contract ties up future use of reserved variable memory.

@dansanderson dansanderson added documentation Improvements or additions to documentation enhancement New feature or request labels Feb 14, 2025
@dansanderson
Copy link
Collaborator Author

probably not enough gain, wnf

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant