Keep Zero Page Empty (as much as possible)

[SerErris 70]

Hi, I was hyped about the fact that much of the ZP is actually empty and not used by the system. I found this allways a huge limitation of C64 that actually most of it is occupied by the System and Basic and you could barely find 10 bytes unused. 

Now in the progress of the project I can see first signs of getting it filled by the system again (now bytes $00-$21 are in use). 

Of the 126 bytes, that were available before, are now only 93 left. This is not to bad still, but shows a tendancy.

Can you please consider to make it a design goal to have as much as free space in the precious ZP? 

ZP is becoming in the enhanced instruction set of 65c02 even more precious, so I would love to be able to use it.

One way to achieve it would be a way to easily save and reload the parts that users might not need (e.g. Basic).
Yes I know you can work in a "don't care" mode and simply assume that the user need to reset after using your program. However that is in no way a modern approach and I like to leave a clean environment. So if you run my program from basic, I like to return to basic and find it intact (no hidden time bombs left, because something overwritten). 

Also calling the basic initialize routing might not be the best, as it also clears the basic memory (overwrites what was in there in terms of sys calls or whatever).

What I am asking for is: Either reserve some of the really precious ZP space for us programmers, or create a basic/kernal routine to restore the space without deleting any other part of the ram.
Last point of  consideration: Of cause If I write into areas used by basic, those data will be gone after calling basic initialize, but the basic ram should not be overwritten. I can then put temporary data into the memory section in questions and that keeps my program intact to get rerun. 

Edited August 9, 2020 by SerErris

[SlithyMatt 423]

Technically, $02-$21 are only used by the expanded Kernal routines for their user interface. If you don't use those routines, you can use them all you want. If you don't need them to be persistent, you can use them in between those Kernal calls, too.

[SerErris 70]

I agree, but the more the ZP is occupied by Kernal functions the more the programmer needs to carefully consider what to overwrite at what time. So you spend more time juggling around, than actually programming the stuff you want.

[TomXP411 234]

And more to the point... if kernel variables get scattered around, it gets harder to keep them straight. While I was super happy to see ZP usage get cut in half, what made me even happier was that the kernel variables were placed at the END of Zero Page, so programmers would know they always have a contiguous chunk free for "whatever." 

I'm less worried about losing another 32 bytes than I am in seeing Zero Page carved back up into small pieces. If those 32 bytes are necessary, at least place them at the end of the free space, rather than the beginning, so up around $70 or so. 

 

[SerErris 70]

On 8/10/2020 at 9:48 PM, TomXP411 said:

And more to the point... if kernel variables get scattered around, it gets harder to keep them straight. While I was super happy to see ZP usage get cut in half, what made me even happier was that the kernel variables were placed at the END of Zero Page, so programmers would know they always have a contiguous chunk free for "whatever." 

I'm less worried about losing another 32 bytes than I am in seeing Zero Page carved back up into small pieces. If those 32 bytes are necessary, at least place them at the end of the free space, rather than the beginning, so up around $70 or so. 

 

There is a benefit at having them at the end and in the beginning. Starting at 0x80 and then continue to 0xFF - wrap and continue on... you can then address all of the block in one indexing approach with the ZP wrap around mechanism. 

6502 wraps around on ZP with indexing. So if you do LDA $80,X and X is 85, you will end up loading from $05. So you can with LDA $80,X address all of the data in a single block. 

However I agree, have it a single block and not scattered with free addresses in between is also very important.

[rje 166]

Agreed with the “single block of free ZP addresses” theory.

Related to that, I’m not worried about $02-$21 workspace used by the 16-bit KERNAL... as long as pseudo registers like these don’t get scattered all about.

[Ender 54]

Just as a little bit of background, those pseudo registers are ones used by GEOS.  When Michael was designing the graphics API he basically ripped code from GEOS for it, and so they use those same registers.  I don't think they're going to be expanded on or anything like that. 

[BruceMcF 185]

On 8/11/2020 at 3:48 AM, TomXP411 said:

And more to the point... if kernel variables get scattered around, it gets harder to keep them straight. While I was super happy to see ZP usage get cut in half, what made me even happier was that the kernel variables were placed at the END of Zero Page, so programmers would know they always have a contiguous chunk free for "whatever." 

I'm less worried about losing another 32 bytes than I am in seeing Zero Page carved back up into small pieces. If those 32 bytes are necessary, at least place them at the end of the free space, rather than the beginning, so up around $70 or so.

It's already too late for that with the magic locations for the memory banking at $00/$01 ... I've been growing xForth zero page usage down from $7F, but if I implement a zero page return stack to make use of the JMP (a,X) instruction, all but four bytes of my working space can go into the transient parts of the ABI space, and leave enough for an ANS compliant return stack ... whereas 126 bytes is already squeezing what I would like on an ANS Forth data stack of 64+ cells.

Edit: Also, to make Sweet16 work with embedded Kernel calls including for the "New API", I am going to have to use $22/$25 to save the Sweet16 stack and instruction pointer registers. So including the two Shadow Registers that makes it Sweet18.

Edited September 3, 2020 by BruceMcF