Forums

sverx wrote

tibone wrote

In the wiki, it says all you need to do is access the unsign char array SMS_SRAM[], so.. i did this:
[...]
But it doesnt really work [...]

I should change the wording in the wiki, it's not very clear indeed.
What I meant is that SRAM is mapped as an array of chars - of course you can cast that to whatever you need.
Here is a simple example of how to map your own struct definition onto SRAM.

Another approach could be to have your struct/data in RAM and simply memcpy() that to SRAM when you want to save.
Or you could copy every single variable from RAM to SRAM using a separate write operation but it probably would get messy pretty quickly (and still you have to cast every variable that is not an unsigned char...)

Out of interest as maybe another example for you @tibone, here's how I just did this for Land on my Base: source.

As sverx suggests, I've taken the approach here of keeping the game config in working RAM (it's passed into these functions by reference), and then at the point of loading from / saving to SRAM, which is very infrequently, I do a memcpy operation of the entire structure. Because the level code is part of the structure and because it has an inherent checksum component, it's also possible to use this to effectively detect whether SRAM is present, since valid SRAM data must have a valid checksum. If SRAM is not present, the write operations will not modify the memory in slot 2, so the save will silently fail.

(N.B. I'm not sure why I hand wrote my own memcpys here instead of using the standard library - I really should have used the library, maybe I was just playing around with stuff and forgot to come back and tidy up)

void game_save_config(game_config_t *config)
{
SMS_enableSRAM();
// cast:
game_config_t *save_config = (game_config_t *)SMS_SRAM;
// memcpy:
for (int i = 0; i < sizeof(game_config_t); i++)
save_config[i] = config[i];
SMS_disableSRAM();
}

bool game_load_config(game_config_t *config)
{
// default settings (in case no SRAM data)
for (int i = 0; i < sizeof(config->level_code); i++)
config->level_code[i] = DEFAULT_START_LEVEL[i];
config->difficulty = 1;
config->invert_controls = false;

SMS_enableSRAM();
// cast
game_config_t *save_config = (game_config_t *)SMS_SRAM;
// check if SRAM data exists and has valid checksum
bool loaded = random_deserialize_seed(save_config->level_code);
if (loaded)
{
// memcpy
for (int i = 0; i < sizeof(game_config_t); i++)
config[i] = save_config[i];
}
SMS_disableSRAM();
return loaded;
}

Hey sverx, trying to get back into the swing of things. I think the meta sprite tool was the last thing I was working on. I'm getting around to outputting c code, but I may have missed a thing or two since coming back.

Below is sample output (Tall sprite) from the Konami sprite I have done previously:

// Your MetaSpriteBaseTile offset is 317
unsigned char const konami_star_00[] = { 0, 0, 0, 8, 0, 2, METASPRITE_END };
unsigned char const konami_star_01[] = { 0, 0, 4, 8, 0, 6, METASPRITE_END };
unsigned char const konami_star_02[] = { 0, 0, 8, 8, 0, 10, METASPRITE_END };
unsigned char const konami_star_03[] = { 0, 0, 12, 8, 0, 14, METASPRITE_END };
unsigned char const *konami_star_frames[] = { konami_star_00, konami_star_01, konami_star_02, konami_star_03 };

How is the tile id offset applied? I have the tiles for the sprite loaded at tile 317. Since that value is larger than 256, I would imagine it couldn't be simply added as the sprite base tile id. The tool does have the option to define your tile id offset.

Also, having potential negative values for the x and y. Would that not trigger a compiler warning? Thanks in advance.

Sprite tile IDs are always 8 bit, as you can only have sprites in the first OR in the second half of VRAM - so your 317 becomes 317-256.
But you can use 317 as base and ignore the warning, as you would ignore them anyway if you use negative values for x and y - or you could used signed char const arrays, and have warnings each time your tile ID is 128 or more.
Really, it's quite hard to avoid warnings as you can't easily have an array in C where some are signed and some are unsigned, you should have structs for that but here it would complicate matters too much with no real gain.

Padding the rom to 64KB and casting the value of my hiscore variable to a char seemed to have worked. :)

Thanks sverx and willbritton

I did something a lot simpler than your examples, but it seems it worked correctly, on my first test.

I'll check everything and probably update my rom today or tomorrow.

Thanks for the help!

Author	Message
willbritton Joined: 06 Mar 2022 Posts: 672 Location: London, UK	Posted: Fri Apr 05, 2024 9:09 am
	sverx wrote tibone wrote In the wiki, it says all you need to do is access the unsign char array SMS_SRAM[], so.. i did this: [...] But it doesnt really work [...] I should change the wording in the wiki, it's not very clear indeed. What I meant is that SRAM is mapped as an array of chars - of course you can cast that to whatever you need. Here is a simple example of how to map your own struct definition onto SRAM. Another approach could be to have your struct/data in RAM and simply memcpy() that to SRAM when you want to save. Or you could copy every single variable from RAM to SRAM using a separate write operation but it probably would get messy pretty quickly (and still you have to cast every variable that is not an unsigned char...) Out of interest as maybe another example for you @tibone, here's how I just did this for Land on my Base: source. As sverx suggests, I've taken the approach here of keeping the game config in working RAM (it's passed into these functions by reference), and then at the point of loading from / saving to SRAM, which is very infrequently, I do a memcpy operation of the entire structure. Because the level code is part of the structure and because it has an inherent checksum component, it's also possible to use this to effectively detect whether SRAM is present, since valid SRAM data must have a valid checksum. If SRAM is not present, the write operations will not modify the memory in slot 2, so the save will silently fail. (N.B. I'm not sure why I hand wrote my own memcpys here instead of using the standard library - I really should have used the library, maybe I was just playing around with stuff and forgot to come back and tidy up) void game_save_config(game_config_t config) { SMS_enableSRAM(); // cast: game_config_t save_config = (game_config_t )SMS_SRAM; // memcpy: for (int i = 0; i < sizeof(game_config_t); i++) save_config[i] = config[i]; SMS_disableSRAM(); } bool game_load_config(game_config_t config) { // default settings (in case no SRAM data) for (int i = 0; i < sizeof(config->level_code); i++) config->level_code[i] = DEFAULT_START_LEVEL[i]; config->difficulty = 1; config->invert_controls = false; SMS_enableSRAM(); // cast game_config_t save_config = (game_config_t )SMS_SRAM; // check if SRAM data exists and has valid checksum bool loaded = random_deserialize_seed(save_config->level_code); if (loaded) { // memcpy for (int i = 0; i < sizeof(game_config_t); i++) config[i] = save_config[i]; } SMS_disableSRAM(); return loaded; }

xfixium Joined: 18 Jul 2020 Posts: 378	Posted: Mon Apr 08, 2024 2:46 am
xfixium Joined: 18 Jul 2020 Posts: 378	Hey sverx, trying to get back into the swing of things. I think the meta sprite tool was the last thing I was working on. I'm getting around to outputting c code, but I may have missed a thing or two since coming back. Below is sample output (Tall sprite) from the Konami sprite I have done previously: // Your MetaSpriteBaseTile offset is 317 unsigned char const konami_star_00[] = { 0, 0, 0, 8, 0, 2, METASPRITE_END }; unsigned char const konami_star_01[] = { 0, 0, 4, 8, 0, 6, METASPRITE_END }; unsigned char const konami_star_02[] = { 0, 0, 8, 8, 0, 10, METASPRITE_END }; unsigned char const konami_star_03[] = { 0, 0, 12, 8, 0, 14, METASPRITE_END }; unsigned char const *konami_star_frames[] = { konami_star_00, konami_star_01, konami_star_02, konami_star_03 }; How is the tile id offset applied? I have the tiles for the sprite loaded at tile 317. Since that value is larger than 256, I would imagine it couldn't be simply added as the sprite base tile id. The tool does have the option to define your tile id offset. Also, having potential negative values for the x and y. Would that not trigger a compiler warning? Thanks in advance.

sverx Joined: 05 Sep 2013 Posts: 3829 Location: Stockholm, Sweden	Posted: Mon Apr 08, 2024 9:07 am
	Sprite tile IDs are always 8 bit, as you can only have sprites in the first OR in the second half of VRAM - so your 317 becomes 317-256. But you can use 317 as base and ignore the warning, as you would ignore them anyway if you use negative values for x and y - or you could used signed char const arrays, and have warnings each time your tile ID is 128 or more. Really, it's quite hard to avoid warnings as you can't easily have an array in C where some are signed and some are unsigned, you should have structs for that but here it would complicate matters too much with no real gain.

tibone Joined: 30 Mar 2009 Posts: 296	Posted: Mon Apr 08, 2024 1:20 pm
tibone Joined: 30 Mar 2009 Posts: 296	Padding the rom to 64KB and casting the value of my hiscore variable to a char seemed to have worked. :) Thanks sverx and willbritton I did something a lot simpler than your examples, but it seems it worked correctly, on my first test. I'll check everything and probably update my rom today or tomorrow. Thanks for the help!

Forums

View topic - devkitSMS - develop your homebrew in C