BASIC memory management

I’m trying to understand how to make my BASIC programs frugal with their memory usage, and running up against the limits of my understanding. Can anyone explain what’s happening in this scenario?

I’ve got a program that reserves memory for its own sprites as it initialises. In the !Run file I set a WimpSlot of 128K to cater for the largest possible sprite file (plus all the other resources and objects), and everything runs fine. However, the difference between the largest spritefile used (‘Sprites11’ 180×180dpi with a 256-colour palette) and the smallest (‘Sprites’, in Mode 15) is pretty big – about 47K – so it would be nice to release that memory if it’s not going to be used. Looking at some of the other BASIC sources in CVS, I adapted my function that loads the sprites with an extra final line:

END = END + &8000

Now here’s where I get confused. As my program is structured, after I load the sprites I go on to reserve space for a whole set of other resources: menu definitions, templates, global variables and arrays, etc. These are all variable assignments or DIMs. As I understand it, these should all go on the BASIC heap, and therefore push up the total memory needed. Indeed, if I move the line with the ‘END =’ command so it occurs after everything’s been set-up, then my program (according to the Task Manager) takes up a lot more room – 124K with ‘Sprites22’ loaded. When ‘Sprites11’ is loaded, it takes up 156K, which is bigger than the max WimpSlot set in the !Run file.

In all cases the program runs fine – I’m just confused as to why it does. To me, it looks like in the ‘Sprites22’ case my program actually needs 124K to run, and yet functions perfectly happily in 96K. Have I misunderstood something here?

END = END + &8000

This is not doing what you think, but adding at least 32k to the user memory that will later accomodate the extensions to the BASIC heap. That is because the END function returns the address of the current end of the heap (FSA) and that already includes the &8000 of the address of the start of the WimpSlot. I say “at least”, because memory is allocated in pages, 4k in anything after RO 3.6.

If you actually know how much memory you want in the WimpSlot you would indeed do:

END = SlotSize% + &8000

If you were to attempt do what you have described, using:

END = END

your program would crash, because the current stack would be moved to overwite the heap, but also BASIC would be very confused with its stack pointer and FSA checks. ;-)

I think you could achieve your object with:

END = END + size%

where size% is the expected heap extension for menus etc, plus an allowance for the creation of variables and cached PROC/FN and a very generous allowance for the stack and its growth.

I cannot let this pass without mentioning that with Basalt you can DIM memory from a dynamic heap above HIMEM so that you do not have to concern yourself with managing the slot size this way. ;-)

Many thanks, Steve – that’s great. It was the &8000 that threw me :)