two dimension char array

[matteus]

I think I've hit a limit but wanted someone to confirm it!

what is the biggest static char array I can declare?

Code: Select all

char Conversation[8][300];

[r57shell]

if it's unchangable array (with const modifier), then it will be inside of ROM, so up to 4 megabytes in size (subtract your code size (size of assembly)) ROM limit is 4 megabytes.
if it's changable array (without const modifier), then it will be inside of RAM, so up to 64 kilobytes. 0x10000 bytes. But all other variables taking size too. Also, SGDK has its own core variables. So, limit will be strictly lower than 64 kilobytes.

[MintyTheCat]

if it's unchangable array (with const modifier), then it will be inside of ROM, so up to 4 megabytes in size (subtract your code size (size of assembly)) ROM limit is 4 megabytes.
if it's changable array (without const modifier), then it will be inside of RAM, so up to 64 kilobytes. 0x10000 bytes. But all other variables taking size too. Also, SGDK has its own core variables. So, limit will be strictly lower than 64 kilobytes.

Yes, SGDK is actually pretty much a hog resource wise: Stef, please look at a more flexible linking per module approach as used in many embedded systems. I only used SGDK three years ago and I only used the text to string functions so it is a complete waste of limited Work-RAM to put the entire SGDK library's variables into that RAM - and not to mention the space that the library occupies in ROM. This may be fine for absolute beginners and people not pushing the machine but falls very short for people a little further on.

If you do not know how to do this send and you want to leave a smaller resource footprint for most users, me a PM.

Cheers,

Minty.

[MintyTheCat]

I think I've hit a limit but wanted someone to confirm it!

what is the biggest static char array I can declare?

Code: Select all

char Conversation[8][300];

What is the size of your ROM's sections?

You want to know the size of data, text and bss.

Look here for an explanation of the sections:

https://en.wikipedia.org/wiki/Data_segment

You get a lot more data and text with bss being only the WRAM ~ 64KB.

It looks like you want to modify the array so find out how filled your WRAM is and where you are placing your variables in WRAM.
Where possible put the data in ROM.
Also keep in mind that your stack is set to a certain size and as you use more and more WRAM you run a real risk of trampling over your Stack.

On a standard MD cart with nothing else in memory you have: ROM-size = variables + not-used + stack-size. So you have: variables = (ROM-size - not-used + stack-size). Do some analysis, modify your stack-size to something realistic for your needs and that will tell you how much space you have left after variables and then your array. As it is you are consuming 2400 Bytes out of the WRAM's 65536 or approximately ~ 3.66% of the WRAM before you add in the stack's allocated space.

[cero]

Yes, SGDK is actually pretty much a hog resource wise: Stef, please look at a more flexible linking per module approach as used in many embedded systems. I only used SGDK three years ago and I only used the text to string functions so it is a complete waste of limited Work-RAM to put the entire SGDK library's variables into that RAM - and not to mention the space that the library occupies in ROM. This may be fine for absolute beginners and people not pushing the machine but falls very short for people a little further on.

This is possible right now, since I contributed a patch for gc-sections support a while back. You do need a newer gcc, which you get from gendev by default if you're on linux or os x. The 3.4 version shipped in sgdk windows is far too old for that.

To take advantage of it, build sgdk with -ffunction-sections -fdata-sections, and add -Wl,-gc-sections to your project's LDFLAGS. I don't think LTO will work on such a niche platform, but gc-sections will remove unused variables like you want.

What you advocate, putting everything in separate files, is not nice for development when the compiler can handle it for you.

[MintyTheCat]

Yes, SGDK is actually pretty much a hog resource wise: Stef, please look at a more flexible linking per module approach as used in many embedded systems. I only used SGDK three years ago and I only used the text to string functions so it is a complete waste of limited Work-RAM to put the entire SGDK library's variables into that RAM - and not to mention the space that the library occupies in ROM. This may be fine for absolute beginners and people not pushing the machine but falls very short for people a little further on.

This is possible right now, since I contributed a patch for gc-sections support a while back. You do need a newer gcc, which you get from gendev by default if you're on linux or os x. The 3.4 version shipped in sgdk windows is far too old for that.

To take advantage of it, build sgdk with -ffunction-sections -fdata-sections, and add -Wl,-gc-sections to your project's LDFLAGS. I don't think LTO will work on such a niche platform, but gc-sections will remove unused variables like you want.

Very good - that will help.

What you advocate, putting everything in separate files, is not nice for development when the compiler can handle it for you.

Sorry, I write in Assembly on the MD and I was thinking at the Assembly level and more over of a way to solve the 'put the entire library into WRAM and ROM problem' I was not, if you look up, advocating putting everything into separate files - but rather the objects themselves being more granular - which is what we achieve with --gc-sections. It is a matter of 'how' once it has been determined that the library contains superfluous matter solution wise - why would someone put each function in its own source file when all we care about is the resultant sections for .data, .bss and .text? That sounds a bit art school to me.

[Stef]

Yes, SGDK is actually pretty much a hog resource wise: Stef, please look at a more flexible linking per module approach as used in many embedded systems. I only used SGDK three years ago and I only used the text to string functions so it is a complete waste of limited Work-RAM to put the entire SGDK library's variables into that RAM - and not to mention the space that the library occupies in ROM. This may be fine for absolute beginners and people not pushing the machine but falls very short for people a little further on.

If you do not know how to do this send and you want to leave a smaller resource footprint for most users, me a PM.

Cheers,

Minty.

Hi Minty,

Do you speak about the RAM usage or just the ROM space ? Because for RAM usage, i'm trying to lower it by using dynamic memory allocation for large buffer and only use static variables for small amount of memory (i should monitor that to really know how much RAM SGDK uses by default).
About rom usage, indeed it would be nice than linker automatically discard unesed methods so the SGDK ROM usage remains limited when you use only few methods. The new md.ld file provided by cero should indeed improve that (you require a newer GCC that the one packed in SGDK though).

[MintyTheCat]

Yes, SGDK is actually pretty much a hog resource wise: Stef, please look at a more flexible linking per module approach as used in many embedded systems. I only used SGDK three years ago and I only used the text to string functions so it is a complete waste of limited Work-RAM to put the entire SGDK library's variables into that RAM - and not to mention the space that the library occupies in ROM. This may be fine for absolute beginners and people not pushing the machine but falls very short for people a little further on.

If you do not know how to do this send and you want to leave a smaller resource footprint for most users, me a PM.

Cheers,

Minty.

Hi Minty,

Do you speak about the RAM usage or just the ROM space ? Because for RAM usage, i'm trying to lower it by using dynamic memory allocation for large buffer and only use static variables for small amount of memory (i should monitor that to really know how much RAM SGDK uses by default).
About rom usage, indeed it would be nice than linker automatically discard unesed methods so the SGDK ROM usage remains limited when you use only few methods. The new md.ld file provided by cero should indeed improve that (you require a newer GCC that the one packed in SGDK though).

I was referring to both ROM and RAM space.

I do not actually use SGDK or C for Megadrive development but it is an improvement to make the library less costly in space that will help beginners using SGDK and the MD.

[Stef]

I agree, I try to keep the SGDK footprint small enough. The ram is IMO not really a problem, but the ROM is... definitely

[MintyTheCat]

I agree, I try to keep the SGDK footprint small enough. The ram is IMO not really a problem, but the ROM is... definitely

I used SGDK way back about three years ago but quickly gave up on it in part due to its size; how much ROM does SGDK occupy now?

[Stef]

I agree, I try to keep the SGDK footprint small enough. The ram is IMO not really a problem, but the ROM is... definitely

I used SGDK way back about three years ago but quickly gave up on it in part due to its size; how much ROM does SGDK occupy now?

I think it eats between 100 KB and 150 KB of ROM, but i you use later GCC it should eat only part you use, so much less !

[matteus]

I just wanted to confirm I now put this in rom by declaring it static. In fairness I hadn't noticed in code that I wasn't!

I'm using the array to store conversation. There is a fair bit of wastage as not every piece of discussion populates it's full allocation

[cero]

@MintyTheCat

You're making me curious. You say you code in asm, and didn't use sgdk because it took 150kb (out of possible 4mb). Assets obviously take space, but you have many options to increase compression. Care to elaborate about your project?

[MintyTheCat]

@MintyTheCat

You're making me curious. You say you code in asm, and didn't use sgdk because it took 150kb (out of possible 4mb). Assets obviously take space, but you have many options to increase compression. Care to elaborate about your project?

I have a number of Megadrive projects with two being game projects. Indeed, I compress data in ROM which is decompressed as the game executes.
The most crucial thing is to be able to add in exactly what you need and remove the rest, e.g. in my library (to be made public one day) I have lite versions of some routines and then fully-fledged version with the idea being that certain things accept commands and codes in place being generally meaningful but take up substantially less space.

There is no way I could lose 150KB in ROM or any space in WRAM to library code and data that the game does not require. The thing to keep in mind is that you have to either throw a lot of resources as decompression which is not always possible or you strategically position when you decompress to ensure that you have the original in WRAM/VRAM/etc. when you need it.

Aim to keep things as lean as you can then work out the bottle-necks later by usually spending ROM/WRAM as you resolve the issues. If you start out with less space you cannot easily adapt further down the line when you need to