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

KERNAL API: BASIC and MATH jump table #134

Open
dansanderson opened this issue Jun 11, 2024 · 1 comment
Open

KERNAL API: BASIC and MATH jump table #134

dansanderson opened this issue Jun 11, 2024 · 1 comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request release-1.0 Considered important for the 1.0 platform release

Comments

@dansanderson
Copy link
Collaborator

Traditionally, Commodore BASIC makes its library of math routines available to ML programs via a jump table. This table also includes limited API access to the BASIC interpreter, for use by extensions. BASIC 65 has a similar jump table, but this is currently undocumented. We should formalize, test, and document this API.

Important note: Accessing BASIC routines requires that the BASIC CPU MAP be active, which hides most RAM from the CPU. At minimum, we need to document requirements for accessing BASIC from ML, including the MAP settings. For example, an ML program at $2014 that calls the cosine math routine would need to install a dispatch routine at $1600 that changes MAP, calls cos, then restores MAP, while preserving input and output arguments. This might be well served by a new KERNAL helper routine in $E000-$FFFF that can encapsulate the KERNAL MAP definitions.

See b65.src starting at $7f00.

@dansanderson dansanderson added documentation Improvements or additions to documentation enhancement New feature or request release-1.0 Considered important for the 1.0 platform release labels Jun 11, 2024
@dansanderson
Copy link
Collaborator Author

Many of these routines use the BASIC floating point accumulator (FACC) registers. There are actually accessors for these in the jump table (fetch_fac, movmf, et al.). Maybe that's sufficient. We should write some test code to find out.

A couple of calls for rendering or parsing between numbers and strings use formats, which is 16 bytes of scratch space that BASIC uses for assembling short strings. This happens to be located at the cleanly numbered address $0100. Maybe we just document this location for this purpose.

Some of these call paths emit BASIC errors. That's not a deal breaker if the ierror vector is also documented, i.e. a third-party caller can intercept errors before they reach BASIC. It's not necessarily wrong for a third-party extension to emit a BASIC error indirectly.

We may not want to document the "interpreter" and "parser" sections of the table. These APIs likely depend on internal parser variables that aren't worth documenting. We should weigh this against some high-value use cases for the parser extension vectors. I'd be very curious to know how much needs to be exposed to add a keyword to BASIC with a third-party extension. It may be implausible without heavy revision.

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 release-1.0 Considered important for the 1.0 platform release
Projects
None yet
Development

No branches or pull requests

1 participant