8 replies to this topic

[tschak909]

All things considered, once a game is actually loaded, and it takes over the whole machine.... how much zero-page space do I actually have for my own use? I know I can use $CC-$CF.. and $D5-$FF for my own use (especially since I am very much against using any floating point routines for a game.) Is there any other ranges I can use? I'm trying to put together a detailed memory map of what spaces I can use.

Also, is there a reason to use the atari floating point package in the OS rom? it seems awfully slow, is there a reason to use this at all? or can I stick to integer maths for pretty much everything???

and, is all I have to do to switch banks on a 130XE just write the appropriate bit mask on port B?

-Thom

[Rybags]

By default, the area $80-$D3 is free for applications and users.

There's no reason at all to use the FP Package, so throw $D4-$FF in as well.

For most games the only FP work you would want is converting a binary number to something displayable, or doing simple BCD addition - something you can easily do yourself with a few dozen bytes of code.

The OS has $00-$7F but if you're careful you can use a good part of it.

Note: all values below are hex addresses.
00-14 best left alone since powerup/restart and VBI uses them. However it would probably be safe to use locations 4-8.

15-41 used by SIO, CIO and tape handler. If they are not in use, you would be OK to use these addresses.

42 CRITIC flag. Don't touch, affects OS VB routines.
43-4B used by SIO and PBI - probably OK to use.
4C-4F used by VBI - best left alone
50-5F used by E: and S: handlers. OK to use if those devices aren't needed
60-61 FKDEF - funtion key mapping. Best left alone
62 PALNTS - best left alone
63-78 - used by E:, S: - OK to use if devices not needed.
79-7A KEYDEF - points to the key definition map. Best left well alone.
7B-7F used by E:, S: - OK to use if devices not needed.

Note that locations $00-$7F will either be altered or cleared on a warmstart.

On the 130XE, you just have to write the appropriate bank into bits 2 and 3 of PORTB, then set bit 4 and 5 depending on if you want the CPU and/or ANTIC to address the banks for $4000-$7FFF.

For maximum compatibility, it is always best to use AND/OR - don't store discrete values there.

Edited by Rybags, Mon Jun 5, 2006 2:04 AM.

[tschak909]

Based on the information Rybags replied back with, I have made a set of documents for my own use so that I can print them out, and scribble on them, so I can keep track of which zero page registers I am using.

I figured this might be of use to other people as well, so I have saved the document in every format imaginable (the native document format is OpenDocument ODT), if there are any corrections, whatever, reply back and attach the corrected document so we all can share.

Thanks guys,
-Thom

 zero_page_memory_map.zip   64.5K   51 downloads

[Gury]

Thanks for sharing tschak909

I like the quote "BEST LEFT THE HELL ALONE!"

[Bryan]

Of course, if you stop the OS from running by taking over the interrupt vectors you can use all of page 0 (& all of RAM for that matter), but then your program can't use the OS (usually fine for games, since the OS will just steal CPU time) and can never exit unless you store page 0 and the old vectors somewhere.

-Bry

[Rybags]

For the sake of turning off the OS and surviving the user pressing RESET, you could use every location except 0,1,9,A,B,E,F.

You would have to initialise DOSVEC ($0A) to point to your warmstart address.

Store 0 in 9, so that no initialisation of disk/cass software is attempted.

But, not forgetting that the OS clears locations $10-$7F.


Addition to first post: it's best not to tamper with APPMHI ($E,$F). The OS uses it when opening a screen and that operation will fail if there is insufficient memory. The pre-XL OS would hang after reset if it couldn't open the screen, the XL has logic in the OS to recover from the bug.

Edited by Rybags, Mon Jun 5, 2006 6:28 AM.

[drac030]

The FP package is indeed not very useful for simple calculations most programs need to do, and it is too slow for time-critical stuff. But, when time is not critical, and you need the fractional part of the result, the FP package can be very useful.

Stepping on the memory area reserved for the OS is always a bad idea IMHO, especially that you have plenty of the place anywhere else to store variables. If you use pointers, it is convenient to store them on the ZP, but I never saw a program which would need to maintain 64 pointers at a time thus requiring more than it is available at $80-$FF.

Edited by drac030, Mon Jun 5, 2006 7:11 AM.

[analmux]

drac030, on Mon Jun 5, 2006 3:10 PM, said:

....but I never saw a program which would need to maintain 64 pointers at a time thus requiring more than it is available at $80-$FF.

...true, but if you code an optimalized program, the usage of ZP-registers reduces needed cpu-time a lot. (for ZP-access always 1 cycle less every instruction).....f.e. for my mario clone programm ZP usage is nearly 128 bytes (in-game).

...not mentioning self-modifying code stored in the ZP area, which is a lot faster than self-modifying code outside the ZP-area.

[drac030]

analmux, on Mon Jun 5, 2006 5:32 PM, said:

...true, but if you code an optimalized program, the usage of ZP-registers reduces needed cpu-time a lot. (for ZP-access always 1 cycle less every instruction).....f.e. for my mario clone programm ZP usage is nearly 128 bytes (in-game).

This is what I mean, i.e. it is hard to exceed that amount even in a highly optimized program, and even a highly optimized program is rarely 100% time/space critical so much that one extra cycle or one extra byte might matter.

Everything obviously depends on circumstances (there are 256 B or 1k intros, for instance), but for starters I'd say that if someone ran out of the user area of the ZP, then most of the time his program is over-optimized.

As for the code stored on the ZP - point taken. If you use the ZP to store code, then you obviously run out of free space rather quickly