| |
Mr SQL
Registered: Feb 2023
Posts: 116 |
Do you maximize Zero Page usage?
I like to use as much of the Zero Page as possible.
The zero page is effectively fast RAM, many cycles are saved that add up with frequent access for a faster codebase.
I had good habits maximizing zero page usage on the Atari and also via the 6809 in the Color Computer which had a great feature of a movable zero page window (immediate/direct page) that can slide anywhere in memory. I've been reading about a similar feature on the C128.
There's all kinds of stuff crowding the Zero Page on the C64 including a Tape I/O routine that is there because it needs to be fast.
Aside from locations 0 and 1 nearly all of the zero page can be freed by locking out the BASIC ROM and Kernel. |
|
... 4 posts hidden. Click here to view all posts....
|
| |
Frostbyte
Registered: Aug 2003
Posts: 174 |
I don't really maximise its use, but rather use it when appropriate. If, for example, I have a variable which is accessed from many places in the code, zp makes sense. But if I have a variable which is stored rarely but needed often in a single place in code, it's worth storing it directly as the value in e.g. lda #imm. |
| |
Jetboy
Registered: Jul 2006
Posts: 228 |
Maximizing zeropage usage is waste of time if it is not required. |
| |
Martin Piper
Registered: Nov 2007
Posts: 645 |
Most of the library routines I write have the option of moving some or all of their working memory to defined addresses, which can be in zeropage, or using inline storage which is often (but not always) in other RAM. |
| |
chancer
Registered: Apr 2003
Posts: 346 |
i think the term "selective usage" is fair to say, like anything there are pros and cons.
I remember finding a life counter for a game.. and next door to it was the energy counter.. which someone , much to the amazement of a far far better coding person that will remain nameless didn't check :D
still sticks in my memory many moons later |
| |
TBH
Registered: Mar 2010
Posts: 21 |
When it makes sense, such as when moving frequently-used variables to ZP reduces the code size, and where globally-accessed variables are used in tight fast loops. Also, small code loops get located in ZP if it shaves off a few more cycles.
I assign ZP labels to successive locations in defined ranges to avoid clashes, like:
zBase = $80
zBase_Current = zBase + 0
; General Storage
zwStore_0 = zBase_Current
zwStore_1 = zwStore_0 + 2
zb_Store_0 = zwStore_1 + 2
zBase_Current = zb_Store_0 + 1
...
; Graphics Lib
zPenColour = zBase_Current
zPaperColour = zPenColour + 1
zBase_Current = zPaperColour + 1
...
If the ROMs will be used, the ZP ranges being clobbered have to be stored-restored in some way. |
| |
cadaver
Registered: Feb 2002
Posts: 1154 |
You can use most of the zeropage even with Kernal IO routines without storing / restoring. Assuming Kernal disk load/save will be used, I've gotten used to using (in a game scenario)
$02-$8f
$91-$93
$9c-$a2
$a6-$b6
$bd-$ff |
| |
serato
Registered: Feb 2021
Posts: 7 |
Quoting TBHI assign ZP labels to successive locations in defined ranges to avoid clashes
Good assemblers have a feature to do this for you. I used to use ACME with a macro to automate, now I use 64tass which has it built in, e.g.
* = $20
atemp .byte ?
xtemp .byte ?
ytemp .byte ?
zarray .fill 10
|
| |
ChristopherJam
Registered: Aug 2004
Posts: 1381 |
Yes, that's what ca65's segments are for.
Cool thing is if you use different segment names for different groups of variables you can move entire groups into or out of zero page just with a change to mem.cfg, if you start running low on space in zp and want to see which groups are most important to have fast access to :)
(obviously you have to be careful about zp pointers, but for more general state this is excellent)
.segment "SONGSTATE"
note: .byte 0
phrase: .byte 0
.segment "DECRUNCHPTRS"
zpsp: .word 0
zpdp: .word 0
.segment "CODE"
play:
ldx#14
voiceloop:
|
| |
Bitbreaker
Registered: Oct 2002
Posts: 501 |
Zeropage is nice to store variables there, also nice to place code there to suplement indirect indexed addressing. Variables can be written to immidiate values with self modifying code. Overall, if you have code that is heavily modified, it is placed well in the zeropage. Some illegals (SAX $xx,y) are there for zeropage adressing too, what is nice.
Zeropage is often crammed, if code does not fit, it can easily extend into stack or accessed in a loop from $ffxx, as you can also branch into ZP from there upon the wrapping of the PC.
If it is about saving codesize, it is also okay to place data structures in the ZP, as lda/sta (even indexed) is 2 bytes only.
I never struggle about sharing ZP with floppy ROM, Kernal, Basic, as all that is disabled and not used by me. |
| |
HBH.ZTH
Registered: Jul 2006
Posts: 10 |
Quote: I’m using zero page memory for time-critical applications like a sorting sprite multiplexer or whenever I need a (zp),y indirect addressing. Other than that, I’m rather trying to avoid it because the zeropage can also be a minefield, especially when you use some Kernal functions in your code or, even worse, the floating point routines (luckily, I sparsely need them).
So if it is not necessary to save that one cycle for handling a variable, I avoid putting it in zeropage. In many cases, using self-modifying code is equally fast.
If it turn into a minefield: Turn off the kernal. Do your own kernal routines if you need them. Get The Whole Memory Map by Melbourne House (large book), it has all the memory locations from $0000-$FFFF. Incl. basic + kernal memory, listed as code with comments, so it's easy to know what each jump vector does or goes to. If it communicate with IO devices, soft-reset, does legwork for basic commands, etc. |
| Previous - 1 | 2 - Next |
