Page 1 of 2
System software/VERA forward compatibility date?
Posted: Thu Dec 28, 2023 8:26 pm
by 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.
Re: System software/VERA forward compatibility date?
Posted: Fri Dec 29, 2023 2:01 am
by 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.
Re: System software/VERA forward compatibility date?
Posted: Fri Dec 29, 2023 3:16 am
by 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.
Re: System software/VERA forward compatibility date?
Posted: Fri Dec 29, 2023 5:28 am
by encw
MooingLemur wrote: ↑Fri Dec 29, 2023 3:16 am
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)??
Re: System software/VERA forward compatibility date?
Posted: Fri Dec 29, 2023 5:32 am
by 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.
Re: System software/VERA forward compatibility date?
Posted: Fri Dec 29, 2023 5:49 am
by 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?
Re: System software/VERA forward compatibility date?
Posted: Fri Dec 29, 2023 6:27 am
by MooingLemur
encw wrote: ↑Fri Dec 29, 2023 5:49 am
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.
Re: System software/VERA forward compatibility date?
Posted: Fri Dec 29, 2023 7:00 am
by ahenry3068
MooingLemur wrote: ↑Fri Dec 29, 2023 3:16 am
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.)
Re: System software/VERA forward compatibility date?
Posted: Fri Dec 29, 2023 7:10 am
by MooingLemur
ahenry3068 wrote: ↑Fri Dec 29, 2023 7:00 am
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.
Re: System software/VERA forward compatibility date?
Posted: Sat Dec 30, 2023 6:22 pm
by 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.