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

Enhancement: An elegant and effective way to leverage the S-BASIC 65 rom *in conjunction with* the MEGA65 core rom #856

Closed
tonedef71 opened this issue Jan 16, 2025 · 3 comments
Labels
new New report, not classified yet

Comments

@tonedef71
Copy link

Is your feature request related to a problem? Please describe.

Looking for better interoperability between the super-cool S-BASIC 65 rom from @snoopy-f64 and the latest nifty MEGA65 official core rom. It would be nice to have a way to run software written for S-BASIC 65 without having to reboot the MEGA65 into a different rom. It would be even more convenient if S-BASIC 65 was refactored to be modular extensions to the MEGA65's existing BASIC and kernal (which might make syncing up fixes and enhancements between the two roms less of a chore).
 
The MEGA65 rom is the default ROM for everything MEGA65. Currently, the S-BASIC 65 rom is a complete, mutually-exclusive replacement rom for the MEGA65 core rom (i.e. it replaces the kernal as well as the BASIC interpreter). However, it would be wonderful to be able to use S-BASIC 65 as an alternative or a superset to BASIC65, while still running the default MEGA65 rom.

If I understand correctly, the S-BASIC 65 rom was derived from the 920300 release of the MEGA65 rom. Since that release, there have been some bug fixes and enhancements (e.g. the MEGA65's new 80x50 text mode) which might be great to use with S-BASIC 65.

Describe the solution you'd like
I'm not sure if the existing S-BASIC 65 could be reworked to be a module that carefully installs over the BASIC65 rom, sort of like plugging a daughterboard onto a main board. Perhaps this might be done by segmenting the new functionality into a separate region of memory and updating internal jump tables as necessary???

Perhaps the S-BASIC rom could be repackaged like a cartridge rom (maybe something akin to the COMAL 80 rev 2.01 cartridge for the C64)? S-BASIC 65 rev 2.01? ;-)

Describe alternatives you've considered
A mechanism like a boot-loader to dynamically install the S-BASIC 65 rom and then load and run software inside of the dynamically loaded rom has been proposed, but it is unclear if it is actually doable and/or how that might be done.

Additional context
S-BASIC 65 official site

I envision this enhancement request submission to initially serve as a dedicated space to collaborate on ideas and foster discussion.

@tonedef71 tonedef71 added the new New report, not classified yet label Jan 16, 2025
@dansanderson
Copy link
Collaborator

Any of these options would require effort by Snoopy to change S-BASIC, and there's very little to be done on the MEGA65 side.

To bootstrap a program into an alternate ROM, the alternate ROM needs a stable entry point for this purpose. Both the ROM and the program can be loaded into MEGA65 memory by a bootstrap program. Then the bootstrap can call the entry point to reset the new ROM and execute the loaded program. This is possible without changes to the MEGA65 ROM or core, and should be relatively straightforward to implement in S-BASIC (or as a monkeypatch to S-BASIC).

S-BASIC could be packaged as a cartridge, with appropriate boot routines in the cartridge memory locations. There is a MEGA65 cartridge protocol for this purpose. Snoopy would need to adapt S-BASIC for a cartridge. This is also possible without changes to the MEGA65 ROM or core, and I suspect this too would be a fun and straightforward project.

MEGA65/mega65-rom-public#135 proposes a stable supported extension API for adding new keywords to BASIC 65 with third-party software, without monkeypatching a specific ROM version. We'd have to formalize and document substantial parts of the parser, so new commands can suitably parse arguments, and add routines for extending the lookup tables. Given such a mechanism, parts of S-BASIC could be rewritten as a collection of new keywords. I don't know what of the 920300 ROM that S-BASIC changes, so I don't know if this is a complete solution.

Resolving this ticket in favor of this last option, which is already being considered, and is the only option to extend the MEGA65 ROM at runtime. You'll have to follow up with Snoopy about the other options.

@tonedef71
Copy link
Author

You'll have to follow up with Snoopy about the other options.

I opened this issue to initially serve as a dedicated space to collaborate on ideas and foster discussion, and so @snoopy-f64 would have been able to follow up here. With this issue now closed, folks will probably be turned off from sharing anything here.

@dansanderson
Copy link
Collaborator

You're describing a use case for extending BASIC 65 with new keywords, so I reconciled that with an existing open issue on that topic: MEGA65/mega65-rom-public#135 We can continue that discussion there. I don't yet see a broader topic that would be out of scope for the existing issue, but if we find one we can create another issue.

The other options you mention (alt ROM disk bootstrap, alt ROM cartridge) are already possible without changes to either the ROM or the core, and would simply be feature requests for S-BASIC. You should ask Snoopy what forum he'd like to use to discuss such requests. (From what I gather, Forum64.de is the preferred place for that.) If that discussion ends up identifying needs for other changes to the MEGA65 ROM or core, we can open new issues to discuss those changes.

(In general, expect issues filed in Github to get aggressively relocated, narrowed, categorized, reconciled, and triaged. Issues need to progress into a state where they are actionable, either fixed with a change to the project or decided as not to be fixed with such a change. I don't mind starting an issue in mega65-core if you're not sure where it goes, but expect it to get bounced around and reconciled as an early step in the triage process.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new New report, not classified yet
Projects
None yet
Development

No branches or pull requests

2 participants