Skeetendo

’Cause all games were better on the GBC

You are not logged in.

#1 2011-01-18 19:23:59

Sawakita
Administrator
Registered: 2010-10-16
Post 80/364

Stack range?

Since here we have some of the long-experience hackers, I think some of you can safely hazard a guess about  how deeply Stack averagely goes in GB games. For example in Red/Blue, Stack is initialized at RAM:[$DFFF], and the lowest value I've seen it reaching was about $DF93.

So what are your experiences about the "Stack Affair"? Do you know about some rule that programmers follow to control how much RAM will their programs require for the Stack?
They must be aware of it, so they can be sure that RAM variables they used for various temporary data don't get overwritten by the stack, while it's pushing/popping stuff.

Offline

#2 2011-01-18 20:15:16

Tauwasser
Member
Registered: 2010-10-16
Post 82/448

Re: Stack range?

In all actuality, many games just plan a straight 0x1000 for it and leave it be. You could even determine this during compile time and account for it, since it is the maximum number of stuff pushed at any time plus whatever might interrupt and put data on top of it. In all actuality, it will most likely be okay with 0x500 tops, since that allows for all kinds of calls and variable passing.

Your 0x6D is a little bit too small. Some games tend to push lots of stuff to stack. I myself like to do so as well, because it is usually fast and I don't have save ram registers to write to... Also, sometimes when you build a string or something, you will not be granted with whatever variable length you need of free buffer, so one usually might just allot the bytes from stack for the time being, write stuff there, print it to screen (or do something else with it) and then be good.
Also, notice how I said variable passing in the first paragraph. Some games, especially when coded in c, don't like to fill available registers or have temporary memory stores in RAM, so they might just push all arguments to the stack before a certain call, so it will grab arguments in a defined fashion from the stack when needed. The games tend to use a little more ram, however, since most of it is temporary, I'd argue 0x500 is still pretty safe.

cYa,

Tauwasser

P.S.: You signature should read "Wir sind gewohnt, dass die Menschen verhöhnen was sie nicht verstehen."

Offline

#3 2011-01-18 20:54:01

Sawakita
Administrator
Registered: 2010-10-16
Post 81/364

Re: Stack range?

I see what you're saying. In fact as a conferm to it, Pokemon Blue doesn't seem to exceed RAM location $DBFF(wrong hypothesis) (for example $DA42-$DA45 used for "elapsed time"). Although, when loading data from SRAM1  (for the saved game file) it writes it till $DEE2. I don't know if it actually holds relevant data since it looks like those random bytes, typical of uninitialized RAM of GameBoy..



Tauwasser wrote:

P.S.: You signature should read "Wir sind gewohnt, dass die Menschen verhöhnen was sie nicht verstehen."

haha, Danke schön!

Last edited by Sawakita (2011-03-21 14:20:42)

Offline

#4 2011-05-08 16:44:22

192/700

Re: Stack range?

Tauwasser wrote:

You could even determine this during compile time and account for it, since it is the maximum number of stuff pushed at any time plus whatever might interrupt and put data on top of it.

Can it really be determined at compile time? I don’t see how you could do it without actually executing the code, especially with the possibility of recursive calls.

#5 2011-05-08 18:28:31

Tauwasser
Member
Registered: 2010-10-16
Post 135/448

Re: Stack range?

Well, you're right. It will probably fall back to the general halting problem. However, you can make pretty good estimates about stack size once you're inside the main loop and know just about how many menus or scripts can be executed in a row. The last one you can obviously guess and be either right or wrong about it. It's the same with the window backup mechanism. You never know how many menus will be called recursively, but you can estimate it to a certain number of tiles and make the backup space big enough.
Although, it probably is fair to say that you could break it down even further at compile time by supplying additional info in your code, like Java does for exceptions for instance. You could just tag a recursion to last for a maximum of x times etc.

cYa,

Tauwasser

Offline

Board footer

Powered by FluxBB