Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

safe Zero Page locations

808 views
Skip to first unread message

ST6...@siucvmb.bitnet

unread,
Nov 12, 1990, 9:02:43 PM11/12/90
to
>Date: Mon, 12 Nov 90 18:20:53 GMT
>From: Andy Tefft <psuvm!art...@PSUVAX1.CS.PSU.EDU>
>Subject: safe 0-page addresses

>I can never keep track of what 0-page addresses are used by
>what program and I need about 7 of them (3 pairs plus one)
>that won't be used by applesoft, basic.system, or prodos.
>Does anyone have any 0-page maps (with actual meanings
>rather than just saying which ones are used)? I only have
>monitor locations now.


From the Apple II Prodos Technical Reference manual:

Appendix A-4:Zero Page-
"Figure A-3 is a memory map that shows the locations by the
Monitor, Applesoft, the Device Drivers, and the ProDOS MLI.
The owner of each location is shown by a letter: M,A,D, or P."

Figure A-3. Zero Page Memory Map
____________________________________________________________________________
Use by the Monitor (M), Applesoft (A), Disk Drivers (D), and the ProDOS MLI
(P) is shown.

Decimal---0 1 2 3 4 5 6 7 8 9 0 11 12 13 14 15
, Hex---$0 $1 $2 $3 $4 $5 $6 $7 $8 $9 $A $B $C $D $E $F
----------------------------------------------------------------------------
0 $00 | DA DA A A A A A A A A A A
16 $10 | A A A A A A A A A A? A? A? A? A? *M
32 $20 | M M M M M M A?M A?M M M M M A?M A?M M A?M
48 $30 | A?M M A?M A?M M M M M M M PMD PMD A?PMD A?PMD A?PMDA?DM
64 $40 | PMD PMD PMD PMD PMD PMD PMD PM PM PM P P P P PM M
80 $50 | MA MA MA MA MA MA A A A A A A A A A A
96 $60 | A A A A A A A A A A A A A A A A
112 $70 | A A A A A A A A A A A A A A A A
128 $80 | A A A A A A A A A A A A A A A A
144 $90 | A A A A A A A A A A A A A A A A
160 $A0 | A A A A A A A A A A A A A A A A
176 $B0 | A A A A A A A A A A A A A A A A
192 $C0 | A A A A A A A A A A A A A A
208 $D0 | A A A A A A A? A A A A A A A A
224 $E0 | A A A A A A A A A A
240 $F0 | A A A A A A A A A A A?

* Byte used in original Apple IIe ROMs, now free.
? Discrepency between ProDOS Technical Reference Manual and the Apple IIe
--------------------------------- ---------
Technical Reference Manual. Published by Addison-Wesley Publishing Company
-------------------------- Copyright 1986 Apple Computer Inc.

Dagen Brock

unread,
May 11, 2014, 7:32:11 PM5/11/14
to
Are there any documents or articles available that cover best practices for zero page usage?

I have a ProDOS 8 application (game) that I am writing in 6502 assembly, so I need a lot of zero page pointers. I saw this csa2 post referencing the P8 manual about available locations. So far I have limited myself to 5 pointers, $00, $02, $04, $FA, $FC.
The ProDOS ref (quoted in the post above) indicates many more available spaces, especially if I don't care about AppleSoft ZP/DP usage (I don't).
My question is this. Is there any reason for me to not use all the Zero Page address that I can in order to optimize my code? I could cut out a lot of pointer copying if I give myself another 3 or 4 addresses, but I don't know if there's anything improper about using more locations. The reference is only a memory map and doesn't really describe best practices on usage.

David Schmidt

unread,
May 11, 2014, 8:23:16 PM5/11/14
to
On 5/11/2014 7:32 PM, Dagen Brock wrote:
> Are there any documents or articles available that cover best practices for zero page usage?

Best practices? Use it. It's the moral equivalent of 256 registers.
Things only get tricky when you want to have other software running in
the system that _also_ uses it...

There are maps around that talk about DOS 3.3, ProDOS, Applesoft, and
Monitor usage of zero page. The Apple II Reference book has maps of
Monitor and DOS, for example. It's got little dots showing which
locations are used. What other software you're going to rely on and
when will govern what's available to you.

Of course, if you're going to tightly gate when any of those other
elements is active, you could copy the existing page zero out, use it to
your hearts' content, then copy it back in when you're ready to use
ProDOS or whatever. But if your game is going to rely on services
continuously, then you get to navigate carefully around what they
already use.

Dagen Brock

unread,
May 11, 2014, 8:37:30 PM5/11/14
to
Thanks David,

Those are all the assumptions I've kind of had. Yet I've been scared of using it for some reason. However this is for a 60 FPS (hopefully) game where it would save me a lot if i had another 3 or 4 pointers for my drawing routines, versus recalculating them each frame. And being a game, there's no P8 MLI calls or any external activity until the game exits. Obviously, I'd still stay away from addresses used by ProDOS.

Thank you. I will begin refactoring tonight and hopefully I will finally be done with optimization!

Bill Buckels

unread,
May 11, 2014, 9:07:31 PM5/11/14
to
Dagen Brock wrote:
> Are there any documents or articles available that cover best
> practices for zero page usage?

You should take a look at how Aztec C and cc65 use zero page. Since you are
not writing for DOS 3.3 you don't need to worry about rwts...

Also know this... Aztec C65 uses zero page for floating point as well as for
its own "soft" registers and for user "soft" registers. Here is the Aztec
C65 Zero Page map:

*
* Copyright (c) 1982 by Manx Software Systems
* Copyright (c) 1982 by Jim Goodnow II
*
* Comparison to ZPAGE.H From Aztec C 3.2b
* Copyright (C) Bill Buckels 2013. All Rights Reserved.
*

*
* The following EQU's are stored directly in the .A65 source.
*
* Comments for porting DOS 3.3 A65 routines from Aztec C65 3.2b.
*

* missing - STK EQU $00 ; 8 byte stack area (same offset as VAL)
VAL EQU 0 ; same (from blockmv.a65) = STK - 8 byte stack area
SP EQU 2 ; same (from blockmv.a65)
AFRAME EQU 4 ; same (from OV65.A65)
FRAME EQU 4 ; same (from blockmv.a65)
LFRAME EQU 6 ; same (from OV65.A65)
PC EQU 6 ; same (from blockmv.a65)

* missing - TREGS EQU $08 ; 24 byte tmp register area (same offset as R0)
R0 EQU 8 ; same (from blockmv.a65) = TREGS - 4 byte tmp register area
R1 EQU 12 ; same (from blockmv.a65)
R2 EQU 16 ; same (from blockmv.a65)
* missing - R3 EQU TREGS+12 (same offset as ACC)
* missing - R4 EQU TREGS+16 (same offset as SEC)

ACC EQU 20 ; different (from blockmv.a65) = R3 3.2b
SEC EQU 22 ; different (from blockmv.a65) = R4 3.2b

* different ACC EQU TREGS+20 = ACC+8 (to allow R3 and R4 in 3.2b)
* different SEC EQU TREGS+22 = SEC+8 (to allow R3 and R4 in 3.2b)

REGS EQU $80 ; same (from OV65.A65) 16 byte user register area

* missing - TMP EQU $40 ;4 byte zero page temporary area


As you can see liberal use is made of zero page. I mentioned DOS 3.3 RWTS.
This is a good example of how Zero Page is shared between the OS and the
application. Consider the 2 calls in the following assembly code module:

* TrackSector I/O
* tsio.a65
* Copyright (c) 2013 by Bill Buckels
* the following 2 helper functions are called from
* the Aztec C65 3.2b DOS 3.3 function rwts()
* riob() - get IO buf address
* return IO buf address
* tsio() - track sector IO
* return 0 if success
* return -1 if error
R0 EQU 8
IOB EQU $48

riob_ cseg
public riob_
clc
jsr $3e3 ; get address of RWTS IOB
sta IOB+1 ; IOB address in Y/A)
sty IOB
sta R0+1
sty R0
rts

tsio_ cseg
public tsio_
clc
jsr $3e3 ; get address of RWTS IOB
jsr $3d9 ; call RWTS
ldy #0
bcc .1
dey
.1 sty R0
sty R0+1
rts

Unlike cc65 Aztec C places its returns in Zero Page... Calling this looks
like the following in C:

int rwts(tr, se, buf, cmd, sl, dr, vol)
unsigned tr,se,cmd,sl,dr,vol;
char *buf;
{
struct rwts_iob *r;
unsigned val;

/* read IOB - initialize structure */
val = riob();

/* load variant fields of IOB */
r = (struct rwts_iob *) val;

r->slot = (sl * 16);
r->drive = dr;
r->volume = vol;
r->track = tr;
r->sector = se;
r->buf_addr = (unsigned)&buf[0];

/* Portion of Sector to read
(to read all 256 bytes set to 0) */
r->sect_cnt = 0;
r->cmd_code = cmd;

/* call track sector IO */
val = tsio();

return val;
}

Other 6502 platforms like the Commdore 64 and the Atari require different
zero page maps but there is still room to do the same thing... lots of room:

*
* Copyright (c) 1983 by Manx Software Systems, Inc.
*

* These are set up for the Commodore 64

BASE EQU $02 ;32 byte register area
VAL EQU BASE
SP EQU BASE+2
AFRAME EQU BASE+4
FRAME EQU BASE+4
LFRAME EQU BASE+6
PC EQU BASE+6
R0 EQU BASE+8
R1 EQU BASE+12
R2 EQU BASE+16
R3 EQU BASE+20
R4 EQU BASE+24
*
ACC EQU BASE+28
SEC EQU BASE+30
*
TMP EQU $24 ;4 byte temporary area
*
REGS EQU $30 ;16 byte register area
*

That's Aztec C65. The cc65 links for zero page usage are as follows:

https://github.com/cc65/cc65/blob/master/asminc/zeropage.inc
https://github.com/cc65/cc65/blob/master/libsrc/runtime/zeropage.s

Click-on raw for a readable listing.

Bill





Bill Buckels

unread,
May 11, 2014, 9:14:33 PM5/11/14
to
Dagen Brock wrote:
> Thanks David,

Yes always nice to hear some confidence:)

> Those are all the assumptions I've kind of had. Yet I've been scared
> of using it for some reason.

Don't feel bad about that fear. I obviously had somewhat the same fear to
have gone to the such great lengths that I posted earlier in your thread.

Having said that, we don't need to be scared:) Just careful as usual.

Bill


David Schmidt

unread,
May 11, 2014, 10:18:09 PM5/11/14
to
On 5/11/2014 8:37 PM, Dagen Brock wrote:
> Thanks David,
>
> Those are all the assumptions I've kind of had. Yet I've been scared of using it for some reason. However this is for a 60 FPS (hopefully) game where it would save me a lot if i had another 3 or 4 pointers for my drawing routines, versus recalculating them each frame.

Yep, you'll want to keep a keen eye on what goes on in your loops, and
zero page will cut down on cycle times. Here's a good consolidated map
of zero page usage by all typical system chunks - feel free to ignore
those chunks you won't be relying on:
http://apple2.org.za/gswv/a2zine/faqs/csa2pfaq.html#017

> Thank you. I will begin refactoring tonight and hopefully I will finally be done with optimization!

You're welcome. Good luck! I'll be happy to see the final product.

Don Bruder

unread,
May 11, 2014, 11:52:15 PM5/11/14
to
In article <7af4ff1f-7684-433e...@googlegroups.com>,
Dagen Brock <Dagen...@gmail.com> wrote:

> Are there any documents or articles available that cover best practices for
> zero page usage?

Other than "don't use locations marked as reserved", there really isn't
any such thing.

> I have a ProDOS 8 application (game) that I am writing in 6502 assembly, so I
> need a lot of zero page pointers. I saw this csa2 post referencing the P8
> manual about available locations. So far I have limited myself to 5 pointers,
> $00, $02, $04, $FA, $FC.
> The ProDOS ref (quoted in the post above) indicates many more available
> spaces, especially if I don't care about AppleSoft ZP/DP usage (I don't).
> My question is this. Is there any reason for me to not use all the Zero Page
> address that I can in order to optimize my code?

No reason at all.

> I could cut out a lot of pointer copying if I give myself another 3
> or 4 addresses, but I don't know if there's anything improper about
> using more locations.

Absolutely nothing. That's what they're there for.

> The reference is only a memory map and doesn't really describe best
> practices on usage.

Because there really isn't any. Lots of folks use $08/09 and $0a/$0b as
pointer-pairs, but that's just "lots of people do it" - nothing even
remotely like "holy writ". Basically, since you say you're not using
AppleSoft, if you don't touch anything marked as used by/reserved for
ROM, slots, or ProDOS, you'll be just fine. Everything else is fair game
for whatever use you want to put it to. Use it like ya own it! :)

--
Security provided by Mssrs Smith and/or Wesson. Brought to you by the letter Q

mmphosis

unread,
May 12, 2014, 11:13:52 AM5/12/14
to

LDX #$00
savezp:
LDA $00,X
STA $1F00,X
INX
BNE savezp

; your code that takes over the entire 256 bytes of the zero page goes here.

LDX #$00
restorzp:
LDA $1F00,X
STA $00,X
INX
BNE restorzp



Antoine Vignau

unread,
May 12, 2014, 11:53:35 PM5/12/14
to
From the P8 source code:

* zero page stuff

par equ $40
device equ par+2
dhpcmd equ device
unitnum equ device+1
dbufpl equ device+2
dbufph equ dbufpl+1
bloknml equ device+4
bloknmh equ bloknml+1

intcmd equ dhpcmd

ztemps equ par+8
tpath equ ztemps
drbufpl equ ztemps
drbufph equ drbufpl+1
tindx equ ztemps
datptr equ ztemps+2
posptr equ ztemps+4
usrbuf equ ztemps+6

========================

So, consider the $4x area as being used.
Some calls used the $FA.. area but save and restore values there, so it is safe to use,
av
0 new messages