16 replies to this topic

[k3v]

So there a limit on how much data you can declare... But why doesnt it count if its in a function or if its declared straight after int AddIn_main(int isAppli, unsigned short OptionNum)? And whats the difference? How can the "limitless" data be used compared with data declared outside normally...?

[Andreas B]

There are limits on local data too, but because they are stored on the stack and 'lost' when the function they were declared in, returns, the memory is freed. The static variables are moved to their own area in RAM (.data and .bss section), before the AddIn_main() is called, and have to stay there for the programs execution time. The area of ram an add-in is allowed to use/address for its static variables is predifined by the OS.
When the stack grows too much (it does when functions use it for variables, and call new functions etc..), it could start overwriting other things in ram, which is not good.

I think that using static variables produces less machine code, as each variable points to a specific point in ram, while local variables are located at an address relative to the stack pointer. Local variables are more efficient space-wise. In all cases will the compiler try to hold the variables in registers, which is as quick as it gets.

There term for how long a variable lives is called 'scope', which I'm sure you can read up on yourself (keywords: c variable scope)

[k3v]

Thanks, i understand more now

So are my attempts to exploit the memory "limit" not a good idea? Is the compiler limit the safe maximum, or could i use more? What is the absolute limit? Ive seen a few addin games that include many large two dimensional arrays in one function that would never fit normally so it cant be that bad?

[Andreas B]

What sort of sizes are you thinking about?
The limit for the static data is probably set in the OS (and enforced by the linker) because the OS has set off a specified 'safe' area to use.
You could exploit SaveDisp() and RestorDisp() to get 2-3k more storage, if you don't want to use files. Just use the vram as a 1024 byte buffer.

[kucalc]

If you want to know the exact limitations, look here on page 4: http://edu.casio.com...rters_guide.pdf

[k3v]

In terms of my wanting more memory is just for more sprites/graphics. The four buffers for greyscales take up quite a lot so yeah...

From the starters guide {thanks Kucalc }, 32kb seem way more then enough so i guess its not too bad if i "exploit" the stack memory? Heh, its not going to "thrash" my calculator if i use like 1~2kb extra?

[Andreas B]

4k for four buffers is not _that_ much
It might become unstable, or crash and need a reset. Probably no permanent damage, but if it seems to work ok, it could crash on another OS version, or appear as a bug when you run the code.
I'm thinking that 32k + 48k should be enough for most apps. 4 screen buffers takes only 4k.

[k3v]

Im a bit confused now... Isnt it 8kb (static) + 32kb (stack)?

Well from what kucalc said and my experience, the 4 buffers take up half the static memory {can only declare 8kb}. I need one [24][40] array for level data, the rest can just be called in a function, then the rest of it is various int variables and a number of sprites which each need two arrays each for greyscale function. And less importantly, im using 16x16 arrays and functions to draw 12x12 sprites because theres no smaller functions in rev-fx so i guess theres a small loss per sprite. And ive hit the limit with not as much as i would like to have...

Ive got 2 fx-9860 so if i "thrash" one it wont matter as much... But i dont think i should hit any serious problems.

[2072]

sorry for the intrusion but if this calc works a little bit like the AFX does, the amount of static data you can use depends on the executable size (code takes memory).
On the AFX, the executable couldn't be bigger than 64Kb. So we cracked the RAM storage of the afx (where the calc stores basic files, lists, etc...) (I was the one who did it ), I created a library that allows to access those "memory zone" as if you were accessing files...
This library also allowed the use of this memory as buffers so the amount of ram you have to play with on the AFX is about 150Kb instead of 64Kb

Maybe one of you could adapt my library to this calc? It's pure C code : http://www.2072produ...prog_source.php

[Fez]

As Kucalc is probably one of the few that would likely be the ones that would do this, I say Kucalc, our hopes and dreams and everything else that does not include money go with you XD

And if you do complete it, you can have a candy treat or something of equal or greater value. At the expense of old Johnny Howard of course

[k3v]

I highly doubt that this is the case for the fx-9860. I would struggle to make a program so small {8kb} So i highly doubt that the static memory is limited by the size of the addin.

[Fez]

I agree.
i mean if my conversion from bytes to kilobytes is accurate, MLC is around 64.13kb which I have a slight feeling is a little bit over 8kb

[kucalc]

The AFX is very different from the fx-9860G. If we wanted to compare, the ClassPad is more related to the fx-9860G.

The memzones library contains some inline x86 assembly code, which will probably be most likely impossible to port over to the SH3 processor on the fx-9860G.

[k3v]

Initial signs are good. First i stupidly declared all the data at the beginning of the graphics function and it resulted in slow motion... Hehe cant declare data continously. Now i just declare it at the beginning of main() and it works fine, my calc hasnt begun smoking yet Just a pain to rewrite all my functions to no longer be functions because the data isnt declared till main() and would result in compile errors...

[2072]

the asm code contained in memzone is just here to move memory blocks faster than the default C memory management functions, so it's easy to addapt for any CPU. You can even replace it by standard C code, it'll just be slower...

[kucalc]

sorry for the intrusion but if this calc works a little bit like the AFX does, the amount of static data you can use depends on the executable size (code takes memory).

Oh yeah, I remember doing something similar like that before now. Playing around, I managed to get a whoppin 48KB buffer. In fact, I could get a buffer the size of almost 498KB (before reaching the max addin size). The buffer was stored in the same section of memory as the program: code section. The problem though, is since the buffer is stored in the code section, you cannot write/modify the buffer since the code section is not writeable. It's good for storing lots of pics to be read later on, but for variables and such it's not...

The fx-9860G normally loads the program into the code section, and there is a separate section of memory that is writable and readable dedicated to variables/data.

the asm code contained in memzone is just here to move memory blocks faster than the default C memory management functions, so it's easy to addapt for any CPU. You can even replace it by standard C code, it'll just be slower...

Ok, I'll look into it.

[Andreas B]

Oh yeah, I remember doing something similar like that before now. Playing around, I managed to get a whoppin 48KB buffer. In fact, I could get a buffer the size of almost 498KB (before reaching the max addin size). The buffer was stored in the same section of memory as the program: code section. The problem though, is since the buffer is stored in the code section, you cannot write/modify the buffer since the code section is not writeable. It's good for storing lots of pics to be read later on, but for variables and such it's not...

Using GCC, it is enough to declare the variables const (which I think many people forget or don't know about). I don't know about the Hitachi compiler, but it should leave const data in 'rom' (.rodata by GCC).

edit: Tested it, const variables are put next to the code sections, as they should.