Dwedit's Board

Shinrai

Member

Registered: 2017-12-17

Posts: 12

Saving configurations to the SRAM

Hey, I've been starting to use this emulator.  It works amazingly well, I didn't even know this was possible to do on a GBA.  I do have a question about it though.  I'm not able to save the emulator's configuration (palette settings, display settings, gamma, etc.).

I've taken a look at the source code, and there are functions for reading and writing data to and from the SRAM.  So saving the config is possible, but I guess I'm doing something wrong.  Can I get some help with this?

Dwedit

Administrator

From: Chicago

Registered: 2004-12-12

Posts: 1,023

Website

Re: Saving configurations to the SRAM

Hello.  You haven't mentioned which emulator it was (Goomba Color, PocketNES, SMSAdvance, etc...), or which flash cartridge you have.

The emulators are programmed to assume you have a flash cartridge that provides a flat 64K size battery-backed save, and will assume that launching the emulator will provide the same 64K again.  Obviously, not all of them do that, hence problems.

---

"We are merely sprites that dance at the beck and call of our button pressing overlord."

Shinrai

Member

Registered: 2017-12-17

Posts: 12

Re: Saving configurations to the SRAM

Thanks for the reply.  I'm using Goomba Color, but I was completely unaware about the assumed 64k saves, so I was just testing it using the VBA emulator.  I'm waiting on an EZ Flash Reform, would it save fine with the 2.04 client?

Dwedit

Administrator

From: Chicago

Registered: 2004-12-12

Posts: 1,023

Website

Re: Saving configurations to the SRAM

Oh yeah, for Goomba Color, I never got around to putting many settings into the configuration file, or doing per-game configuration.  Most settings will reset the next time you run it.

I know that the settings people really want to save are pretty much which palette gets used for which GB game, whether to use SGB mode or not, and possibly speedhack settings.

With the newer version, the "Wario Blast" palette pretty much became the default palette for every game upon startup, since that's what a real GBC would use if the GBC wouldn't give that game another palette.

---

"We are merely sprites that dance at the beck and call of our button pressing overlord."

Shinrai

Member

Registered: 2017-12-17

Posts: 12

Re: Saving configurations to the SRAM

Ah ok.  Would it be possible for me to change some default settings in the source code and try to recompile from that?

Dwedit

Administrator

From: Chicago

Registered: 2004-12-12

Posts: 1,023

Website

Re: Saving configurations to the SRAM

Which settings are you interested in?  Disabling Palette detection for GB games that picks Wario Blast?  Disabling SGB mode?

---

"We are merely sprites that dance at the beck and call of our button pressing overlord."

Shinrai

Member

Registered: 2017-12-17

Posts: 12

Re: Saving configurations to the SRAM

Both actually.  I'm guessing that it's just not a basic variable change right?  Do you think you can give me some pointers as to what I should be changing and how I can compile it?  I have some experience with C and know the basic workarounds of assembly, but I have no idea how a GBA rom is compiled.

Edit: I figured out how to get the source compiled.  Just need to figure out what needs to be changed.

Last edited by Shinrai (2017-12-18 2:14:01 pm)

Dwedit

Administrator

From: Chicago

Registered: 2004-12-12

Posts: 1,023

Website

Re: Saving configurations to the SRAM

some snippets:

lcd.s:

@----------------------------------------------------------------------------
GFX_reset:	@called with CPU reset
@----------------------------------------------------------------------------
	stmfd sp!,{r3,addy,lr}

	ldrb_ r0,gbcmode
	movs r0,r0
	bne 1f
	
	@get GBC palette
	ldr_ r0,memmap_tbl
	blx_long GetGbcPaletteNumber
	@if zero, pick Wario Blast palette
	cmp r0,#0
	moveq r0,#74
	ldr r1,=palettebank
	strb r0,[r1]
	bl paletteinit
1:

Function it calls is defined in gbcgamedetect.c.

If you want to always pick a specific palette, you can comment out the call to blx_long GetGbcPaletteNumber, and the cmp and moveq instructions, then just use "mov r0, #SOME_NUMBER" instead.

Or if you remove the strb r0,[r1] instruction, it will simply not change the palette when a rom is loaded.

---

"We are merely sprites that dance at the beck and call of our button pressing overlord."

Shinrai

Member

Registered: 2017-12-17

Posts: 12

Re: Saving configurations to the SRAM

Awesome, that works great!  Turns out changing whether the SGB border is on is a pretty simple change as well.

sgb.s

auto_border:
	.byte 1	@autoborder
_autoborderstate:
	.byte 0	@autoborderstate
	.byte 0	@borderpartsadded

Changing auto_border from 1 to 0 seemed to do the trick.  Thanks again for all your help on this.

Floob

Member

From: UK

Registered: 2016-09-03

Posts: 3

Re: Saving configurations to the SRAM

Is it possible to provide a compiled file where .gb games on Goomba Colour default to Grayscale?

karl_oz

Guest

Re: Saving configurations to the SRAM

Is it possible to provide a compiled file where .gb games on Goomba Colour default to Grayscale?

I second this. Grayscale as a default for non-color games would be way better than the "Wario Blast" palette. Could this be done? Maybe as an optional second release or so?

sgb

Guest

Re: Saving configurations to the SRAM

Changing auto_border to 0 doesn't work here, it does work to make the option default to OFF in the settings, but regardless of whether the option is on or off, the sgb border always shows up for games that support it. I have to set the games to GB mode to get rid of the border.

On a related note, would it be possible to have options for gb mode that take SGB out of the equation entirely? The coloring in SGB mode doesn't work properly, so I don't want to run games in SGB mode ever. So it would be useful if there could be options to "Prefer GB over GBC" and "Prefer GBC over GB", that way games would run in either GB or GBC mode depending on preference, and never pick SGB mode.

This would be useful, because I changed the default to GB mode so I could avoid SGB, but when it's set up that way, games that require gbc mode require me to go into the settings and change it to one of the GBC modes, then hit Restart, whenever I play them. It's not that much of a hassle, it takes 5 seconds and it works, but it would be really useful to have the option so it'd do it automatically.

autosleep

Guest

Re: Saving configurations to the SRAM

Also, correct me if I'm wrong, but... is it possible that the reason why autosleep settings don't save correctly, is because only the stime variable gets saved to the config in sram, while the sleeptime variable doesn't?

According to the code, in ui.c, scrolling through the autosleep settings between 5min-10min-30min-OFF in the menu updates the stime and sleeptime variables together. stime being used by ui.c to figure out which text string to display, and sleeptime being used by timeout.s to know how much time has to pass without any input before putting the game in sleep mode. So when you change the settings, the changes work fine, while you still have the game running.

Then when you update the config in sram, the stime variable gets stored, and when you turn off the system, come back later, and load the emulator again, the stime variable gets loaded, so the menu remembers it and it appears like it saved fine. But the sleeptime variable isn't saved, so that doesn't get restored, and in the end it defaults to 5*60*60 as defined by timeout.s, until you go in the menu and scroll through the autosleep setting to force it to re-update.

Fairly certain this is the cause, though... I've added extra code to readconfig() which sets the value of sleeptime according to the value of stime that was loaded from config, using an if/else statement just like ui.c does, and this totally solved my issue. Maybe not the most efficient way of doing it, but I'm not knowledgeable enough about how C works to add sleeptime directly to the saved config, and this works, so eh.

Moonfall_Prince

Guest

Re: Saving configurations to the SRAM

Noob question: is it possible to permanently set the GoombaColor settings to always default to GBC+SGB mode?

Dwedit

Administrator

From: Chicago

Registered: 2004-12-12

Posts: 1,023

Website

Re: Saving configurations to the SRAM

GBC+SGB is a weird hybrid mode that doesn't reflect any real hardware.  Prefer GBC over SGB with Initial SGB Border is a better idea most of the time.

There are very few games that can use GBC+SGB mode without glitches, but when they work, they will have full color, and will change the SGB border.

---

"We are merely sprites that dance at the beck and call of our button pressing overlord."

Moonfall_Prince

Guest

Re: Saving configurations to the SRAM

GBC+SGB is a weird hybrid mode that doesn't reflect any real hardware.  Prefer GBC over SGB with Initial SGB Border is a better idea most of the time.

There are very few games that can use GBC+SGB mode without glitches, but when they work, they will have full color, and will change the SGB border.

Ah, gotcha. That makes sense. I wasn't sure if one was better for what I was trying to go for.

Even though the SGB color palettes aren't 100% accurate, I love the novelty of having the borders and additional colors on my GBA.

Thanks for the reply and for the awesome emulator!

SweaterFishDeluxe

Member

Registered: 2023-07-13

Posts: 3

Re: Saving configurations to the SRAM

Is saving and loading of an alternate palette supposed to work in the 2019 release?

It seems the palette setting is saved, but then not loaded when booting. Instead it just goes back to the default, either Wario Blast or a game default.

I am running Goomba Color from open_agb_firm on a 2ds and only 32kB is available for SRAM saves, not 64kB like is apparently expected. The other savable settings (gamma, autoload savestate, and sleep timeout) still work fine, though, as do game saves and savestates. It seems to be only the palette setting that isn't working.

If I use the "save32" version of the 2008 release, loading the saved palette DOES work correctly, but this version does not have as many palettes and doesn't have working savestates.

What's going on here? Or is this just the expected behavior? Why is the custom palette saved but not loaded?

Dwedit

Administrator

From: Chicago

Registered: 2004-12-12

Posts: 1,023

Website

Re: Saving configurations to the SRAM

I think it's just re-detecting the palette every time.

---

"We are merely sprites that dance at the beck and call of our button pressing overlord."

SweaterFishDeluxe

Member

Registered: 2023-07-13

Posts: 3

Re: Saving configurations to the SRAM

Are these two lines from the section of lcd.s you posted above responsible for that?

    ldr r1,=palettebank
    strb r0,[r1]

In sram.c, palettebank does seem to be read from the save, but if I understand these lines, they're overwriting that memory location with r0, which the preceding lines had loaded the default palette into.

I can't compile right now and don't know assembly at all, but I may try building a version for myself that does use the saved palette if you think this is the place to look. Thanks and sorry if I've totally misunderstood the ASM here.

Dwedit

Administrator

From: Chicago

Registered: 2004-12-12

Posts: 1,023

Website

Re: Saving configurations to the SRAM

It's the act of making it run the GBC palette detector that's responsible, not that.

---

"We are merely sprites that dance at the beck and call of our button pressing overlord."

SweaterFishDeluxe

Member

Registered: 2023-07-13

Posts: 3

Re: Saving configurations to the SRAM

I was able to set up the environment and compile it today afterall. I was worried it would be complicated, but it was easy once I found your updated Github repo.

Commenting out

strb r0,[r1]

does allow the palette that's saved in the SRAM to get used. It breaks the whole GBC palette detector, though, which is obvious now that I think about it. I tried adding

cmp r1,#0

before that line thinking that this might make it only do the strb if no palette is stored in palettebank because it's the first time the game was booted. It doesn't work, either because I have no idea how to do conditionals in ASM (I don't!) or because palettebank is occupied even the first time a game is booted. It does seem to default to B&W when the GBC palette detection isn't done.

Anyway, I'm very satisfied with defaulting to B&W, but saving and loading a prefered palette. I see now that the palette saved is not per game, but per save file, so this wouldn't be such a good solution for people who append multiple ROMs and use the menu, but I always just do one ROM per file anyway, so it's perfect.

Last edited by SweaterFishDeluxe (2023-07-14 1:35:36 pm)

puerto_rigo

Member

Registered: 2024-04-27

Posts: 1

Re: Saving configurations to the SRAM

Hi guys,

I made some changes to the jagoombacolor for of goombacolor that seem to successfully retrieve saved palette settings.

Here is my pull request: https://github.com/EvilJagaGenius/jagoombacolor/pull/41

Is there anything wrong at all with using register r2? It doesn't seem to be used at all when we branch to paletteinit.

See my below:

@----------------------------------------------------------------------------
GFX_reset:	@called with CPU reset
@----------------------------------------------------------------------------
	stmfd sp!,{r3,addy,lr}

	ldrb_ r0,gbcmode
	movs r0,r0
	bne 1f
	
	@get GBC palette
	ldr_ r0,memmap_tbl
	blx_long GetGbcPaletteNumber
	@if no GBC palette saved, pick greyscale
	ldr r1,=palettebank
	ldr r2,[r1]
	cmp r1,#0
	moveq r2,#01
	@if no GBC palette detected, use saved or greyscale
	cmp r0,#0
	moveq r0,r2
	strb r0,[r1]
	bl paletteinit

Dwedit

Administrator

From: Chicago

Registered: 2004-12-12

Posts: 1,023

Website

Re: Saving configurations to the SRAM

I think you're free to use 'r0,r1,r2,r3,addy (r12), lr' without any additional register saves.  r10 is the base register used by the ldr_/str_ psuedoinstructions.

If in doubt, search for that register in the code and look for what the register is next used for.

If register is getting overwritten, then you don't need to preserve its old value.
If register is being written somewhere or used in an expression as a source value, then you do need to preserve its old value.

---

"We are merely sprites that dance at the beck and call of our button pressing overlord."