System software/VERA forward compatibility date?

[encw]

When will everything be locked in with the system software/VERA, so that changes that break compatibility with existing code will be off the table completely? I want to make sure that I don't consider something done and tested BEFORE things are locked in place, only to get a nasty surprise.

I assume it will be before the February release of the 1000 board run, but I really don't know. Sorry if this is an announcement that I missed.

[Wavicle]

Regarding VERA: new features may show up, but the compatibility breaking changes ship sailed long ago. The only exception being that if a serious bug is found in the core functionality and there are not enough LUTs left to fix it, then features like FX may have a partial roll back to free up resources.

This is an unlikely outcome because the bitstream has been heavily tested for over a year now.

[MooingLemur]

The arrangement of RAM (ZP $80-$FF, system RAM $200-$3FF, and RAM Bank 0) is not "locked in" and are not guaranteed to be static. New features will probably continue to be added from time to time and bug fixes applied. We do have some ideas for mitigating the missing access to certain kernal vars with a stable extended API but that's not been put into practice yet.

With the exception of software that reads or changes kernal variables directly, I would generally consider R43 to be the low watermark for forward compatibility. We changed the keyboard encoding scheme for that release, and we nailed down most of the memory locations depended upon by cc65's C compiler. Software that works with R43 should generally work on future versions and there are no plans to break compat from this point.

[encw]

The arrangement of RAM (ZP $80-$FF, system RAM $200-$3FF, and RAM Bank 0) is not "locked in" and are not guaranteed to be static. New features will probably continue to be added from time to time and bug fixes applied. We do have some ideas for mitigating the missing access to certain kernal vars with a stable extended API but that's not been put into practice yet.

With the exception of software that reads or changes kernal variables directly, I would generally consider R43 to be the low watermark for forward compatibility. We changed the keyboard encoding scheme for that release, and we nailed down most of the memory locations depended upon by cc65's C compiler. Software that works with R43 should generally work on future versions and there are no plans to break compat from this point.

Just to make sure I understand you, are you saying that there is no plan to finalize a memory map that application developers can depend on? I thought that the plan was eventually an ecosystem of commercial software on cartridges. One can't ask customers to open carts and reflash ROM. There must be some plan to eventually finalize the memory map and the kernel APIs (other than bug fixes)??

[MooingLemur]

Memory map in terms of documented APIs, yes, that should be finalized. Undocumented KERNAL memory has no such guarantees. I cannot recommend having cartridge software depend on the specific layout of the internals of the kernal that is not exposed via an API.

[encw]

I think I understand now.

So as long as I stay within $0022-$007F, $0400-$9EFF, and RAM banks other than bank 0, I should be safe from having anything clobbered if I use a kernel procedure. I hope I've got that right. And that is final and can be depended upon?

[MooingLemur]

I think I understand now.

So as long as I stay within $0022-$007F, $0400-$9EFF, and RAM banks other than bank 0, I should be safe from having anything clobbered if I use a kernel procedure. I hope I've got that right. And that is final and can be depended upon?

Yup, that memory should be untouched and is for user programs. Also, the API for any existing calls ($FEB1-$FFF3) should also be fixed in regard to its documented inputs and outputs. For example, no new behaviors for functions based on the carry flag if the function ignores the carry flag now.

[ahenry3068]

With the exception of software that reads or changes kernal variables directly, I would generally consider R43 to be the low watermark for forward compatibility. We changed the keyboard encoding scheme for that release, and we nailed down most of the memory locations depended upon by cc65's C compiler. Software that works with R43 should generally work on future versions and there are no plans to break compat from this point.

The ZSMKIT Binary doesn't work on R43, Only R44+ . (and yes I know it is your code.)

[MooingLemur]

The ZSMKIT Binary doesn't work on R43, Only R44+ . (and yes I know it is your code.)

This thread is about forward compatibility (things written for R43 that work properly on R43 continuing to work on later releases), not for things that require new features or fixed bugs to work. ZSMKit requires R44 or later due to bugs in R43, but ZSMKit-enabled projects should continue to work in R47, R48, and so on.

[Ed Minchau]

This has been a big thing for me. I write a lot of code for this machine. The r42 changes, particularly the need to prepend @: to filenames when overwriting, broke all of my software. It took me a month to get the META/L editor working properly again, and weeks more to get Asteroid Commander running. It's what brought a halt to that project, though I'll restart it once my 3d game engine is working to my satisfaction. But another breaking change like that will set me back several months this time; I haven't even downloaded r46 yet for that reason, still on r44.