You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: