MACROS Optimizing RAM space by overlay macros

[Thomas Jentzsch]

RAM is always pretty scarce on the 2600, so when developing something a bit more complex, you eventually find yourself running out of RAM space. To overcome this, people have defined versatile temporary variable areas or gave the same RAM address different labels. This is not very convenient and error-prone.

 

To overcome this, for Boulder Dash, Andrew Davie had developed some DASM macros, which allowed using a shared RAM overlay section for multiple purposes. During a current project I have reworked those macros and made them easier to use and much more versatile.

 

These macros allow you define as many different overlay sections as you need. Also you can nest other overlay sections into an overlay section. And all this with just two simple macros, BEGIN_OVERLAY and END_OVERLAY. Those will take care of the memory requirements, output them and also help verifying that you use them correctly.

 

Example: Imagine you write a game which consists out of two different scenarios. Both scenarios need their own variables for display and processing. Then you use the same overlay section twice, one for the 1st and one for the 2nd scenario. For both scenarios you can then define your variables freely inside the scenario's section. You just have to make sure that the labels are still unique (local namespaces would be cool, maybe later...).

 

Also, in one scenario, you may have variables which are local to the kernel or to processing outside the kernel. Then you can define two nested overlays inside the overlay for that scenario, one for the kernel and one for processing. And so on...

 

The macro code looks pretty complicated, but you do not have to understand it at all . Just have a look at the example at the end of the file. Then everything should become pretty clear (I hope).

 

If you have any requests or ideas how to make RAM variable handling even more convenient (like namespaces) then please post your ideas here.

 

 

overlay.zip

[ZackAttack]

This is a great idea. A lot better than my approach of adding the comment ";This is a bad idea..."

 

I think you'll get a better adoption rate if the example were a little more practical though. It's not really clear what Level1 and "level 1a" are supposed to represent. If you had a small demo project that consumed overlay.h and used actual variable names to accomplish a small display task it would be a lot easier to understand the intended use of this.

 

Thanks for releasing this to the public forum.

[Thomas Jentzsch]

My problem is to explain something which is absolutely clear to me. Maybe the terminology could be improved too, English is not my first language.

 

And I think I should explain what I mean in my example and you tell me what was unclear:

• Level1 is the label of the outer overlay section. Whenever you want to reuse that section, you have to provide that label to the macros.
• "level 1a" and "level 1b" are the names of the two instances which use that outer overlay section (sharing their space)
• Level2 is the label of a nested section inside Level1.
• "level2a" and "level 2b" are the names of the two instances which use that inner overlay section (sharing their space)

Maybe I should rename the labels and names too?

[ZackAttack]

You write better English than a lot of people I've dealt with here in the states.

 

If I understand what this macro is for, you have created a rough equivalent of variable scope. Normal dasm variables are global and overlay variables can have local scopes which allow non-overlapping scopes to share the same location in memory.

 

So assuming that's what you've done here. I think it would be good to have an example with at least 2 separate functions which rely on both global and local memory in order to demonstrate how the overlay would enhance that. Maybe a display algorithm and an AI algorithm for a very basic demo/game. I'm sure you'd have some meaningful labels and names at that point which would make things that much clearer.

[Mr SQL]

Boulder Dash is incredible but I don't see how you optimised RAM space - you used more RAM than two VIC-20's!

[Thomas Jentzsch]

Zeropage RAM of course.

 

Else the game would have become quite a lot slower and even more complex to develop.

[Mr SQL]

Zeropage RAM of course.

 

Else the game would have become quite a lot slower and even more complex to develop.

Now I see where you are comming from with your optimiser The 6502 lacks a direct page function; can't change the zero page like on the 6809.

[+Andrew Davie]

Overlays are the bee's knees, and don't worry Thomas your English is hunky dory.

Cheers

A

[+Andrew Davie]

Here's an explanation. Say you have this great game, and you have an even greater title screen. But to program the title screen, you need 40 bytes of RAM. And to program the game, you need 90 bytes of RAM. It's a mammoth game, but guess what -- you only have (roughly) 120 bytes of RAM available. To put them both together you need (40+90) = 130 bytes. No can do. So one option is to have a massive temporary buffer, and assign those 90 bytes to locations within that buffer, and those 40 bytes to within the same buffer. They are never used at the same time, so you can share the locations. It's workable but a pain to have to assign locations manually so that they share. Well, you don't have to - the overlay macros do that all for you. Wherever you have RAM needs for variables, and you are certain that two pieces of code never need that particular RAM/variable at the same time as another piece of RAM/variable, then you can effectively use the same memory location for both, and free up RAM for other uses. It's like having a car with room for 4 passengers and having to take 10 people somwhere. It works fine (they can use the same seat) provided you never have to carry them all at the same time. The overlay macro allocates a seat to a person, even if that seat is also allocated to another person at some other state. All you have to do is make sure that those allocations don't clash (i.e., don't allocate the same seat to two people who have to travel at the same time).

[Omegamatrix]

I've never really had a problem with managing ram, but I can see that these macros would be quite useful. Thanks for sharing.

[Mikes360]

This is a very nice idea, I like anything like this that can be used as a level of abstraction from counting bytes to ensure things are lined up properly.

 

If one where to use these overlays would you define each overlay as you need it or define them all in one block?

[Thomas Jentzsch]

I think one should do it in one block at least for all overlays which use the same section. Else you loose control over the variables to easy.

 

I am currently using two sections (both including several nested sections) which I am defining in one block.