Kernal/BASIC-ROM maturity

[EgonOlsen]

Hi,

a few years ago, I added x16 support to my MOSpeed BASIC cross Compiler but I stopped adapting to new Kernal releases after r38, because it was just a pain to make things work again when the ROM addresses that I need to call from within the compiled code as well as the memory mapping constantly changed.
However, I would like to support the x16 fully again once and if the ROM is stable. What are the plans in this regard? Will there be a final ROM release that programs that have to make direct calls can rely on? Or will it be changing constantly (in which case I'm out, because I can't be bothered to deal with this...)?

[TomXP411]

The ROM should be pretty stable, at this point. In fact, MooingLemur just added some checks to the code to fix certain API entry points, because the CC65 libraries have been referencing private API addresses, which violates the guidelines called out in the PRG.

According to the Programmer's Reference Guide, you should only rely on the public APIs as documented in the guide. Those have always been stable, and routines like CHROUT, File I/O, and so on have been static for a long time (certainly pre-38.) If you need a private API, you can ask one of the developers (here or on the Discord) to stabilize the API and publish it. I don't know how many entries are left on the jump table, but that would be a better route than jumping into private APIs that can move around.

As to VERA: the layout changed, but the underlying registers that determine the layout are still the same. So you can, for example, determine the base address of the screen by reading the screen registers.

If you have specific concerns about private APIs', feel free to go into detail here, and we'll see what's been stabilized and whether we can add public entry points for what's left.

[EgonOlsen]

Thanks for the reply. IIRC, it was mostly about memory locations in the (extended) zeropage changing with almost every release.
In addition, I have to call quite a lot of functions that are most likely not going to make it into the jump table like conversions between ints/floats/strings and similar things. I had a semi-automated approach in place that devived most of these addresses from the symbol table though.
I guess, I'm going to give it a go again when I find the time and see how it turns out. Which is the most recent ROM release btw? Just to be sure that I'm not going to pick the wrong one...

[TomXP411]

Thanks for the reply. IIRC, it was mostly about memory locations in the (extended) zeropage changing with almost every release.
In addition, I have to call quite a lot of functions that are most likely not going to make it into the jump table like conversions between ints/floats/strings and similar things. I had a semi-automated approach in place that derived most of these addresses from the symbol table though.
I guess, I'm going to give it a go again when I find the time and see how it turns out. Which is the most recent ROM release btw? Just to be sure that I'm not going to pick the wrong one...

The latest official release is the one on the public Github repository.

https://github.com/X16Community/x16-rom ... es/tag/r42

However, it's helpful to log in and hit the list of PRs and Actions to see if anything has changed.

As to things like data conversion - yes, that's the kind of thing that is valuable to have as a public API. Maybe post an Issue with the things you rely on, so we can look into creating a jump table, or something.

I also want to do some BASIC tooling, and I also need certain things to remain stable. So that's a discussion worth having.

[kelli217]

There's a set of 16-bit pseudoregisters in zero page, staring from location $02 and up through $21, labeled r0 through r15. They're used for a few KERNAL routines, but they aren't general storage like some ZP locations. They should be safe enough to use on the same kind of temporary basis as the KERNAL routines use them... and they've stayed stable since the RAM and ROM banking system was moved to $00 and $01, so several releases now.

[mobluse]

It would be good if some addresses to useful things that are not machine code were stored in fixed places in the ROM. E.g. where the fonts start, where the keywords start, and where the character layouts are stored.

This program reads the fonts from the ROM in order to draw huge characters:
https://github.com/mobluse/chargen-make ... /chars.bas

This program reads the commands and functions and trains you in shortcuts for the keywords:
https://github.com/mobluse/chargen-make ... DSABBR.BAS
In this case I search for where the keywords start, but if this was stored in ROM at a fixed address I could use that and I would not need to update for every release.

I plan to make a keyboard training program for different layouts and then it would be useful if the program could read a fixed address of where they are.

In these cases the useful objects could be stored in different ROM banks, thus bank number would also have to be stored.