EZ-Flash USA Forum

Edit by FAST6191, kuwanger kindly updated the most commonly used emulators to support the EZ4 properly are available in this thread:
viewtopic.php?f=12&t=12660
(also stickied at in the EZ4 section).
This thread will remain for the more obscure emulators that could get caught up in this and for those interested.

------------- Original post---------------------------
Hi, i'm new here, i've had a ezf2 with no problems but i recently got a 4 lite deluxe, and i seem to be having problems with the saving features of these emulators (goomba, goomba color, SMS, and nes) they all seem to be only saving the first 32kb instead of the whole 64kb. I already tried sending them through the newest client and just putting them on my sd card. and it still doesnt work, any suggestions would be appreciated.

i noticed that too, i don't think it can be helped..

just split your goomba color into two roms so that your saves don't end up overwriting themselves.

that's not really the issue, i even tried splitting all my gameboy mono games into seperate files, but when i turn it off, the saves disappear because it seems in goomba, the emulator writes the data at the last 32kb rather than the first 32kb.

Its a known problem. You can either use the .nds and prepend the version of the ndsloader.bin I posted a while back or you can look here (instead of running it through ezclient).

http://sosuke.com/ezflash/viewtopic.php?p=10914
show the hidden part.

There is a NDS version of goomba color??

Anyhow, there's a whole topic about this in "Off Topic". We didn't figure anything out.

My bad, but the same info still applies. You have to change the code in the GBA header just like ds.gba homebrew, and provide a properly named 64k save file.

Try this:
- grab this patcher I just "whipped" up : EZ4-64-1.zip
- instead of running it through EZ client, drop it on the EXE from that zip
* use a tool like gbata to fix the header after you get the out file (don't think this is necessary in the current GBA kernel as it doesnt hard reset, though I'll look into fixing the complement automagically)
- rename the save and bin according to your preference
- place the save and bin on your SD and let me know if it works for you.

Thanks cory1492, it works great, it saves the full 64k, but i keep getting this mildly annoying message "Cheat error! continue=a return=b" i just simply hit a and it works. If you can remove it that'd be great, but otherwise, it works.

edit: i used your patcher and returned the first 3 bits to 00 00 00, and it stopped giving me the message, but i don't know if it'll cause any problems, so can you give it a test to see if it'll cause any problems? or find out what those 3 bits do. thanks.

Hmm, doesn't work for the EZ3. I just get a yellow screen. Any chance you could look into getting it to work on the EZ3? I'd be eternally thankful!

markedsword: I am assuming that because I grabbed the hex code from a 64K FLASH type GBA game that those first 3 are designed to give an address to jump to either save patch code or cheat code. Putting them to 00 will probably work fine, so long as it has the correct size

8000h is the size of a 32K file, 10000h is the size of a 64K file - considering the endianess of the DS and the fact that it is on a 16 bit bus I would assume the second set of bytes designates the save size. If you like I will recompile the code to 00 the first three bytes. Still havent figured out how to get a proper checksum though (every tool I have tried so far gives me a different one and I have no idea which is correct, though I have code in place that should be making a correct sum).

Jonny9797:
I dont have an EZ3, but I know at least with my EZ1 and EZ2 there is a way to change the save size after adding a ROM and before burning it. It should be set to 256Kbit after you add it and before you commit it to the flash (if there is a way to change it in the EZ3 client).

Cool, it'd be great if you can your code for the first 3 bytes, i coudn't find the copy of param.h you were using, so i couldnt do it myself.
I was just wondering what the other bytes outside the save size information do, if they do anything at all. I did a comparison of the sonic 2 hex where you made the change between 3 types of patches, (no patch, save patch, and save + reset patch) the only difference i saw was that in the save and save+reset, the first 3 bytes are different. So i guess that's what they do. Thanks for helping me out, along with alot of other people trying to get goomba and other homebrew to work.

It lets me add a save patch, but none of the possible combinations will make a 64kbyte save. It always saves as 32kb and I lose my save.

Oh well, thanks anyway. If you don't have an EZ3 I will keep trying to figure it out myself.

-Jonny9797

Jonny9797: good luck tracking down your problem. I know with the EZ4 patcher, it doesnt care what you set the save size to either.

markedsword: sorry it took so long, lost of stuff has been happening this last week. Most of it lousy
param.h is from msys/mingw32

Doesn't change the first 3 bytes, and tries to correct the checksum. Everything I know says this should be generating a correct checksum, but as I said before I cant find any tool that agrees with me.
EZ4-64-2.zip

Thanks for the rewrite and recompile.

Jonny9797, from what cory1492 has posted it seems the EZ4 patcher have overwritten a section of the so called reserved area (an area of the header typically 00 filled) and it appears to act as some sort of flag or something to tell the EZ4 to grab the SRAM contents and write them.
If you could write some roms (preferably large save size ones) to your EZ3 and then read them back off it may be possible to figure out a way for the EZ3 to do it as well, I would try but I only have an EZ4l and EZ2 with me right now (the rest are with friends and family all over the country and are likely to be for the next few months).

FAST: the problem being in that case, the client will modify the header again when you go to burn it.