Memory map including undocumented "safe" locations?

[Hobart]

Are there any memory maps that indicate, all of the memory locations (when BASIC isn't in use, but loading from disk but not using FMS) that are "safe" to use, outside of the range between MEMTOP and MEMLO ?

 

I understand this would be different for an 800 vs 800XL vs 130XE, just curious about scraping every last free byte of modifiable memory :-)

[Rybags]

Aside from those OSes there's also the 3rd party modified ones like Omniview and QMeg that might use locations otherwise thought free on XL.

 

The other problem is the free areas are scattered and not real large though the cassette buffer at 131 bytes is pretty handy.

Quick and dirty guide though can't guarantee accuracy or if the areas will be always as free as thought, working backwards:

 

$580-$5FF LBUFF - this area is normally used by Basic for accepting input and can in fact overflow to $67F so Page 6 isn't guaranteed 100% free. Also used by FP Rom. In the case of neither being used this area should be safe to use.

$480 -$57F Syntax Stack (Basic) - if Basic isn't present then this area should be free. In fact you could boot a large contiguous program starting here.

$3FD-$47F CASBUF - the first sector of a disk boot is read here so not really suited to boot a program here (though a boot sector routed to $400 would probably just be copied to itself) - this makes a handy area to copy small routines (in Basic too) so long as cassette IO isn't required.

$3E8-$3FC previously free, now contains system variables XL/later which if disturbed can cause undesired behaviour.

$3C0-$3E7 PRNBUF - printer buffer. As per tape buffer, fine to use for temp storage or to keep short routines.

$340-$3BF IOCBs - the IOCBs are an overlooked resource. The OS will use IOCB #0 for the text E: device. Basic will use #6 and #7. No reason not to use the Ram for some/all of them when you know they won't be needed. In the case an IOCB is needed in future just store $FF in the ICHID field so that CIO thinks it's unallocated.

 

$100-$1xx Stack space - in most cases the stack won't grow downwards much beyond 40 bytes. So long as your program doesn't inadvertantly create lots of stack entries e.g. from subs that don't return then you could use most of the stack for something else.

 

Z-page. Note that $10-$7F won't preserve contents across warmstarts.

$D4-$FF Floating Point work area. If the OS FP routines aren't in use then this area becomes free.

$CB-$D1 Basic free area.

$80-$D3 Basic pointers, flags, variables (except free area above). If Basic isn't in use then these all become free. Note that other languages will also have lots of top half z-page usage.

$15-$7F OS usage. If the owning component isn't in use then the location will probably be OK to use.

$00-$14 Mixed OS usage. Best left alone. Locations 0,1 generally only used during warmstart but some OS versions won't warmstart properly if 0, 1 modified.

 

 

Alternatively to all this, just switch out the OS, provide your own interrupt handlers e.g. in a game or demo. Set COLDST ($244) nonzero. Then use memory as you want, don't return to the OS. System will coldstart when the user presses Reset.

[phaeron]

If your program needs to call back into OS or DOS, it's best to stick to the documented locations: $80-FF for page zero and MEMLO+ for user. Custom OS or loader can change low memory usage, and in particular it is highly likely that whoever worked on the EXE loader or ATR emulator will have had the same ideas as you with regard to where to "borrow" OS memory for storage. Everyone seems to think that $0100-011F is unused.

 

If your program doesn't need to call back into OS or DOS and is taking over the machine, then you can use almost all memory. Absolute minimum for 800 with interrupts enabled is VIMIRQ, VVBLKI, and VDSLST; on an XL/XE machine you can use all memory if you swap out the OS and take over the processor IRQ and VBI routines directly. If you're that tight on memory, you're probably just as tight on cycles, and why waste cycles on the generic OS routines?

[Gury]

Thanks Rybags for very detailed explanation

 

So, $3FD to $6FF could be used as contiguous free RAM safely/freely when FP, cassette buffer, etc. are not used in any way. Printer buffer and IOCBs note is useful too.

 

I thought LBUFF is used in input entry operations in any low/high level language, not just BASIC.

[Rybags]

Yep, high chance another language or application using E: for the interface would have a 128 or 256 byte input buffer and probably the same area that Basic uses considering most/all would also support coexisting with a Dos so as a minimum in that case you'd want to leave the line buffer and IOCB #0 alone.

 

In the use of not having Dos or wanting IOCBs for E: or file processing and a near maximal memory usage you have most of $340-$3FF clear but annoyingly some locations that need to be left alone.

$3EB contains a cartridge checksum which should be left alone as if a cartridge is present and it changes, the warmstart (Reset) routine will think a cartridge swap has occurred and do a coldstart as a result.

$3F8 is the Basic enable flag, changing it to 0 then doing a warmstart will enable the onboard Basic.

$3FA is the cartridge interlock flag. Changing it can cause an immediate lockup or restart on XL/XE depending on OS revision.

[phaeron]

If you are not using BASIC, the math pack is the only module that will use LBUFF. Specifically, FASC will convert an FP number to ATASCII starting at somewhere between LBUFF-2 to LBUFF, and the polynomial based routines can use temporary storage near the end at $05E0-05EB. The other routines don't use LBUFF, including IFP which takes a buffer pointer in INBUFF instead. You aren't required to use LBUFF for an input buffer at all, either with E: or the math pack.

[Hobart]

If your program doesn't need to call back into OS or DOS and is taking over the machine, then you can use almost all memory. Absolute minimum for 800 with interrupts enabled is VIMIRQ, VVBLKI, and VDSLST; on an XL/XE machine you can use all memory if you swap out the OS and take over the processor IRQ and VBI routines directly. If you're that tight on memory, you're probably just as tight on cycles, and why waste cycles on the generic OS routines?

Are there RAM locations lost behind the locations hard-wired to POKEY and friends? Or are all of those mapped outside the actual 48K of RAM chips ?

[phaeron]

Are there RAM locations lost behind the locations hard-wired to POKEY and friends? Or are all of those mapped outside the actual 48K of RAM chips ?

 

On the XL/XE computers there is 2K of RAM hidden behind the hardware registers at $D000-D7FF that you can't get to. The only way you could access that memory is either through a hardware mod like MapRAM or one of the rarer extended memory mods that aliased the 64K of main RAM into extended memory (ugly).

[+therealbountybob]

In my latest game (Space Fortress Omega) bootable disk/ATR created from object code using BootMajster Utility on the Atari [game then boots directly, no dos etc], I've been trying to use everything I can find:

 

I have stuff on tabmap, prnbuf, top half of page 0, casbuf 03FD and right through to the top of RAM.

 

Also I've been using the Stack - I've absolutely minimised use of it in my code and have managed to use 235* bytes so far without problems! [*possibly slightly less will confirm]

 

I've also been re-using areas e.g. setup code for tables I've created dynamically in the game.

 

I've not yet studied any of the details posted above about about potential conflicts.

 

My previous game Ramp Rage also used most of this apart from the stack if that helps.

Edited June 9, 2017 by therealbountybob

[drac030]

There are no "undocumented safe" locations. It is an oxymoron.

 

The safe space below MEMLO is certainly $0600-$06FF and $0080-$00D3. There is also fairly safe space in $0400-$05FF, if you know what you are doing. Same about $00D4-$00FF. And about the printer buffer. Using the stack area is basically a hack. Same about using the IOCBs for anything else than communicating with the CIO. You are free do do that, but if it makes a problem in any environment, it is your fault.

 

The rest of the area, i.e. $0000-$007F and above $0200 is system's internal space and should not be used by applications in any way than the documented one.