SpritesMind.Net

Hi,

Is there a way to estimate how much ram is being used by my game? Without having to count every variable in my code, that is.

Also, how can I tell how large my game rom is without the padding?

(as usual, I'm using SGDK)

Thanks!
DJCC

First, set your makefile to generate a link map.
That will tell you the address and size of nearly everything. Second, make padding the rom a separate step with a different name than the binary. That way you can see what size the binary alone was.
Notice that making the elf file uses the flag that produces the link map. Then making the bin file makes the bin under a set name (temp.bin), and THEN pads it out to the desired size/multiple with the final name for the binary.

It's why I use Ucon for padding
it tells you what is the size w/o padding

I'm not sure 'dd' is available on SGDK, no ?

I think you already have memory managements methods in last version of SGDK so you should have which returns the number if free bytes.
Basically you have 64 KB of memory so 64 KB - MEM_getFree() will return you the consumed memory

Stef wrote:I think you already have memory managements methods in last version of SGDK so you should have

Code: Select all

u32 MEM_getFree()

which returns the number if free bytes.
Basically you have 64 KB of memory so 64 KB - MEM_getFree() will return you the consumed memory

Heh! I didn't even know there was a memory manager. I just have a whole bunch of static global variables at the moment.

KanedaFr wrote:It's why I use Ucon for padding
it tells you what is the size w/o padding

I'm not sure 'dd' is available on SGDK, no ?

It's a default part of EVERY *nix system out, and an installable part of cygwin and mingw. Ucon is great as well, but not a default thing, nor in any repo - you have to go get it from sourceforge. It's also a bit overkill for just padding a rom.

One of the reasons I like dd is that it's very flexible... if the blocksize is smaller than the filesize, it makes it the next multiple of the blocksize. If it's bigger than the filesize, it pads it to the blocksize. So if you just want the rom to be a multiple of 8K, you just use bs=8K (or bs=8192).

djcouchycouch wrote: Heh! I didn't even know there was a memory manager. I just have a whole bunch of static global variables at the moment.

The memory manager was introduced in the last SGDK version so it is not surprising you didn't know about it

One year later...

I've figured out how to generated a map file, but I'm having a bit of trouble interpreting it.

I posted Propeller's map file here: http://pastebin.com/R9yVam4J

Does line 264 (the one with __DYNAMIC = 0x0) indicate where the data stored in ROM starts? "playerSprite" is an import from genres, so I think so.

Does line 891 (first instance of .data) indicate where variables mapped to RAM starts? The .bss section seems related.

The linker script (ld) file sets things like where the rom and ram are. The map shows them like this (line 225):
Things like "__DYNAMIC = 0x0" are symbols set by the linker script and only make sense to the code that uses said symbols.

Starting at line 267 you get a list of the files that contributed to the .text section, at line 800 you get other sections that go into rom, at line 891 you get the .data section list, at line 975 you get the .bss section list, and at line 1086 you get all the common vars that wind up in the bss.

Line 1201 gives you this:
That is the end of ram usage by the program. Line 889 gives you this:
That is the end of rom usage by the program.