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

commodore family targets shouldn't both clobber BASIC ZP and return to BASIC #341

Closed
mysterymath opened this issue Jun 25, 2024 · 2 comments
Assignees
Labels
bug Something isn't working p1

Comments

@mysterymath
Copy link
Member

This came up in #315, and it's discussed more thoroughly in the tail end of that discussion.

Summary:
I think there's three aspects of the commodore family targets that come into conflict:

  • That the only real execution environment that loads programs is BASIC
  • That they exit by returning (from the above, always to BASIC)
  • That they clobber BASIC ZP.
    If any of the above weren't true, there'd be a way to use the resulting PRG files such that they cleanly returned, but as is it feels like one of the second two points should change. We may want to either split the commodore targets into BASIC and no-BASIC variants, or if it's possible, provide a link-time configuration symbol for this. Whatever the default ends up being, it should infinite loop if it isn't safe to return to BASIC; that at least may let one inspect the output.

The easiest change we could make to make this consistent would be to change the commodore targets to exit-loop instead of exit-return; that's one line of CMake. It looks like cc65 doesn't use the BASIC ZP at all and returns. That's one possible configuration. Another is to save and restore BASIC ZP on entry/exit and use it, and another is to clobber it and never return. Ideally there would be a simple way to spell each of these for each commodore target in the SDK, and hopefully, without too much monkeying around in linker scripts. That's the part that needs designing; we've built out a huge degree of this kind of configuration in the NES targets, so it may be possible, but it can be tricky.

@mysterymath mysterymath self-assigned this Jun 25, 2024
@mysterymath mysterymath added bug Something isn't working p1 labels Jun 25, 2024
@mysterymath
Copy link
Member Author

mysterymath commented Jun 25, 2024

I think saving and restoring BASIC ZP makes sense as a library actually. We already have symbolic names for the BASIC ZP area, so we could register actions in early init/late fini to save and restore to a buffer. The buffer would need to be defined in a .s file per target (different sizes), but that's no major issue either.

So, for now I'm going to do the exit-loop change; it's easy, and it provides a safer version of what the SDK does already. I do think it's a good default; BASIC uses a ton of ZP, and doing something extra to save/restore seems largely better than disallowing use. I think some symbol work could make the ZP range used configurable, so we may need to just make sure that it's possible to link against -lexit-return directly (I think it should be?)

@mysterymath
Copy link
Member Author

Closing this out with #342 and #343.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working p1
Projects
None yet
Development

No branches or pull requests

1 participant