General A8 Memory Configuration Question

[Schlortt]

What is the standard practice when configuring memory for programs written in assembly on the Atari 8bit? I can think of three ways to do it:

Static definition, macro driven and allocation at run time.

-The first two are akin to hardcoding and would still have to be compiled for a specific memory size. For example, if you had a game that could fit in 16k, you would just set your RAMTOP, Screen Memory, Player memory, etc accordingly and it should run on any Atari 400, 800, XL, XE that had 16k or more memory. Is this correct?

 

-Would there be any advantage, in terms of compatibility, to using the third (runtime allocation)? In assembly, I see this as a slight disadvantage because references to screen memory, player location, etc. become more difficult or add cycles using indirect indexing.

[Rybags]

For games and demos, static is the usual. In terms of CPU use and program space it's usually the most efficient. If you let your screen address be at the mercy of the OS then you'd likely be doing same with PMG addresses.

 

In cases where extended Ram banks are used there is a lot more flexibility to be had at little effort though because the addresses you deal with are still the same, the bank numbers rather than dealing in absolutes can be stored in a table of allowable banks. The reason some demos have select screen to choose which banks to use is to allow the user to preserve Ramdisk contents when it's being used for that.

 

The problem with doing things "by the book" - you then may as well cater for any possible Dos footprint.

Which means $700 - $3000 or greater in low memory goes untouched. Memory under the OS might be used by Dos, as well as extended Ram banks @ $4000.

Since any Ram outside 48K of the original 800 wasn't in the original specs there's no official provision for allocating it or flagging it as being in use. It's a case of use at your own risk of stomping or being stomped.

But that's the nature of 6502. Very simple memory management, no Ram virtualisation or protection facility, single shared stack space, and assumed single-tasking with coldstart between old/new tasks.

 

Good programming practice these days is to either coldstart when the user presses Reset or to allow your program to terminate and return to a usable Dos if it was present beforehand.

If you're doing some hardcore game or demo that uses a lot of resources though, that isn't necessarily practical. But it is nice that some programs and games are being done that way.

To do it that way though you either have to save/restore a bunch of memory or not touch it at all. In the least, any semi-complex game or demo will need a decent slice of Page 0 Ram, but save/restore of that is trivial.