Dwedit's Board

Enjoy the board

You are not logged in.

Announcement

Welcome, fellow visitors from other websites!
Whenever you download a file, I'd appreciate it if you posted a nice "Thank You" message, then tell me which site you came from. Thanks.
- Dwedit

#1 2009-09-13 11:04:06 am

xXToYeDXx
Member
Registered: 2009-09-13
Posts: 2

Possible workaround/temp solution to Goomba Color saving issue.

First off, I know nothing about coding anything. This is just something I stumbled upon by chance, and it works. Also, I'm posting this because I have not seen it anywhere before, so if someone else has posted it, my apologies for the post.

It seems Goomba Color saves the front 32kb just fine, but has trouble saving the back 32.

This is not Jaffa's workaround, it does not involve deleting the SRAM.

This has also ONLY been tested on copies of Goomba Color with only 1 GB/C rom. I keep all my GB/C roms on seperate emulators on my EZFlash4. I have no idea whether or not this works with multiple GB/C roms on the same emulator compile.

1) Save your game as normal using the in game save feature.

2) Open the Goomba menu by pressing L+R

3) Highlight "Restart" in the menu and hit A


Restarting the emulator seems to commit the full 64kb save data, thus saving your game progress.


Any thoughts? Discuss.

EDIT: I was thinking, and I may have found the reason Goomba Color doesn't save. It's not really an issue with the emulator, but more of an issue where the hardware recognises the GBA flash cart rather than the GB/C game you're playing. I figure the reason this works is restarting the emulator after saving is just like turning off a GBC/GBA while running the official GB/C cartridge. Half the save gets committed while shutting the hardware down. While the GBA flash cart is inserted, ie. EZ FlashIV, the GBA/DS recognises it as a GBA game, and treats it like such, thus saving a GB/C game doesn't work while shutting down. However this is just a thought, I'm no expert on the matter, but it seems like solid logic, at least at first glance. If any experts here have any other ideas, please feel free to post.

EDIT 2: I see there are 50+ views and no responses. I'll take this time to ask that if you've tested this on multi rom compiles, leave feedback about it. I'd like to know if this works with all roms on a multi rom compile, or if it just saves the last game played and deletes all save info for other games in the compile. I'll be testing this myself, so I will be adding to this again. But I think it's essential that everyone interested in having saves work natively, try to find as many working workarounds as possible, even if it doesn't involve touching the source code. I think our feedback will really help Dwedit in finding a proper fix, and possibly a permanent solution. The more info he has, the better.

Last edited by xXToYeDXx (2009-09-28 8:50:14 am)

Offline

#2 2009-09-28 9:20:42 am

xXToYeDXx
Member
Registered: 2009-09-13
Posts: 2

Re: Possible workaround/temp solution to Goomba Color saving issue.

Ok, so I'm run some tests on mutli rom compiles, and it seems the save method does still work, at least so far.

My testing parameters.

-An EZ Flash 4 GBA sized cartridge with a 1 GB micro SD card
-A Mutli Rom compile Goomba Color gba rom
  -games on the compile are
    -Zelda: Link's Awakening DX
    -Pokemon Blue
    -Pokemon Crystal
    -Pokemon Yellow
    -Zelda Oracle of Seasons
-A Grey GBA SP unit, model number AGS-001


Step 1-3

Compile all GB/C games listed into one compile named TestMulti.gba. Loaded the compiled rom into the 1GB Micro SD card using EZ4Client, creating a 256K SRAM for GBA saving. Put the Micro SD card back into the EZ Flash 4 Cart, and started up the GBA SP.

Step 4-end

Loaded the compile TestMulti.gba, and first ran Links Awakening DX. Played through until I got the shield, exited the starting house, and saved normally, using A+B+Select+Start. Pressed L+R and restarted the emulator, which promptly brought back the rom selection screen. Checked to see if the save was still there, and it was. L+R again to restart, then turned the unit off and back on. Loaded the TestMulti.gba compile, and check Link's Awakening to see if the save was commited properly. Save was still there. L+R again to restart. Loaded Pokemon Blue. Played through until the first battle with Gary. Saved the game using the in game menu. L+R to restart the emulator, bringing back the rom menu. Checked Link's Awakening DX, save was still there. L+R to restart the emulator, loaded Pokemon Blue, save was still there. Turned the unit off, and back on. Loaded the rom compile. Checked both games, saves were still there. Repeated for Pokemon Crystal, and Oracle of Seasons, saving at appropriate times, soft restart and hard restart. All saves were still there.

More testing to be done, but so far so good.

Offline

#3 2009-09-28 11:55:11 pm

Kuwanger
Guest

Re: Possible workaround/temp solution to Goomba Color saving issue.

A few things.  Among other things, Goomba Color doesn't write the GBC SRAM (aka save ram) to the GBA's SRAM until L+R is pressed.  This is mainly done because some games, like Pokemon, for the GBC have upwards of 32KB of SRAM.  So, that means either (a) reserving 32KB of GBA SRAM for emulated GBC saves to be able to constantly write to, (b) compressing the GBC SRAM every few bytes written to GBC SRAM or quite regularly and storing that in GBA SRAM, or (c) delaying saves to the GBA SRAM until some user action requests it.  Option a is very bad, since that'd be half of the 64KB SRAM.  Option b is difficult to write well, especially on a slow system like a GBA.  Option c was the option went with.

Second, the reason you seem to have problems with the top 32KB of SRAM not saving is because you're setting the EZClient to only save 256kbits (aka 32KB) of SRAM.  Simply choosing 512kbit SRAM (aka 64KB SRAM) will mean that should Goomba Color actually use more than 32KB for saves, it'll continue to work between other roms require 64KB or more SRAM.  Just be sure to make your current .sav files (TestMulti.sav, for example) are made to be 64KB big.  The simplest way to do that is something like "copy /b TestMulti.sav+TestMulti.sav temp.sav" and "move temp.sav TestMulti.sav"--ie, double the size of the file with effective junk.  However, if Goomba Color is already using more than 32KB (Manage SRAM should tell you)...you probably really need to start over with that save file.

#4 2009-10-08 12:06:43 pm

Aspall
Guest

Re: Possible workaround/temp solution to Goomba Color saving issue.

Tried Kuwanger's method for the EZ4, and it works! Had successful on all games I saved on my compilation.

Here's what I did:

Compiled the .gba as normal.

Added to SD through EZClient, choosing SRAM save type and 512kb. Sent all OK.

Tried it out on:

Warioland 2, Zelda: LA, Mario Golf, Metroid 2 DX (a colorization hack)

Let the game save as it does naturally through ingame methods (ie Zelda's press A+B+SEL+ST), and restarted goomba color after each save.

Turned off GBA SP, put it back on. Wrote the sav, tested. Still there!

note: Used goomba color 3-31-08
-

I'm no programmer, but I thought my experiences may help better this already superb emulator.

#5 2010-05-11 11:37:20 pm

SKInnyCartMAN
Guest

Re: Possible workaround/temp solution to Goomba Color saving issue.

Thank u sir i had given up on gbc games for my micro.

#6 2010-05-18 12:35:58 am

SKInnyCartMAN
Guest

Re: Possible workaround/temp solution to Goomba Color saving issue.

Been a couple weeks using this method and no problems monkey puncher kicks ass :D

#7 2013-05-03 1:39:39 pm

tielur
Member
Registered: 2013-05-03
Posts: 1

Re: Possible workaround/temp solution to Goomba Color saving issue.

this just made my day thanks :)

Offline

#8 2016-08-08 12:54:33 am

niel
Guest

Re: Possible workaround/temp solution to Goomba Color saving issue.

Awesome! Still useful reading... 7 years later. :D

Registered users online in this topic: 0, guests: 1
[Bot] claudebot

Board footer

Powered by FluxBB
Modified by Visman