Feature Request: Kernel & Basic zero page usage "staying in their lanes" about x16-rom HOT 6 CLOSED

I have been reworking all this. Branch https://github.com/commanderx16/x16-rom/tree/basic_geos has the following (rough) zero page allocation:

• $00-$7F available to the user
• $80-$8D used by the KERNAL
• $8E-$9E used by CBDOS
• $9F-$FF used by BASIC

from x16-rom.

I am having similar problems with my porting of durexforth, still struggling to get the
kernel to run properly. It temporary reuses a few addresses in the zero page that ought not to cause problems for the machine if they work and are used as they were in a C64 :)

BASIC RND function seed value ($8B, $8C, $8D, $8E)
Tape Error Log ($9E, $9F)

from x16-rom.

It appears to be a fault in the build process (or it's already been corrected). The code overwriting $02 is in kernal/joystick.s, at the end, where it uses a zp location "j0tmp" which is allocated to segment "ZPKERNAL" which should be in the "lanes".

from x16-rom.

I have no idea how that segmenting system works ... whether it could possibly wrap around on overflow if they have overflowed $FF and there are locations that Basic hasn't put a claim on. Maybe declaring a 3 byte segment at $00-$02 ZPUSER could block such an overflow.

But there eventually needs to be a documented section of RAM that can be used by code called from Basic with SYS ... even if it is provided in a set of Basic locations that are not storing persistent data at the time of a SYS call ... and there needs to be SOME machine language routine ZP locations that can be used by userland interrupt routines no matter what the state of Basic may happen to be ... which is what $02 and $FB, $FC, $FD, $FE were for the C64.

from x16-rom.

I have no idea how that segmenting system works ... whether it could possibly wrap around on overflow if they have overflowed $FF, and there are locations that BASIC hasn't put a claim on.

The linker (ld65) doesn't wrap-around; and, it doesn't overflow. Instead, it complains that the memory area is too big.

from x16-rom.

That's lovely ... with that ZP allocation, I could have my Forth return stack on the zero page while still allowing it to cooperate with Basic ... which is a big dividing line for C64 Forth models.

from x16-rom.