Hardware EZ Flash IV - Client problems, looking for alternatives

[don_luca]

Hi everyone,

I've just got my EZ Flash IV MicroSDHC and I'm planning on dumping in it my entire GBA set.

So far, I've trimmed all the ROMS and deleted all those which I know I will never play (kids and sports games) and was ready to transfer them to the SD when I realized there is one major problem.

I have ~1600 roms to copy over, but EZ Client (last 2014 version) will only allow me to copy 25 ROMS at time. Which is kinda fine since the process is quite fast but there's another big problem: ROMS, for some reason, get renamed and some just become a .gba file which gets overwritten everytime.
Again, the .gba file wouldn't be much a hassle if only the damn software didn't rename the ROMS (I could quickly look up what ROM is missing and fix it, but nope! Roms are renamed and this makes the search much more complicated).

Right now I'm looking for alternatives, mainly to SRAM patch those 1600 files.
It should be obvious that tools like GBATA is not a solution as I should manually load the roms one by one and patch them: I need something either working from command line (so I can write a script to automate the process) or with an option for batch converting.

If anyone has any idea or suggestion, please feel free to tell me.

I'm a Java developer and if someone is willing to tell me how the process of patching the rom and creating the .sav file is done, I can make a software to do it.

Thanks for your time! ^^

 

[FAST6191]

The basic GBA patching process is simple enough. I forget the specifics but trolleydave pulled them all apart for his program. The general process was do an ASCII search across the ROM for SRAM, EEPROM or Flash. You also want the version number that follows that (also in ASCII).
There will then be two patched sections, said sections are usually the same patch but may be a different distance from the ASCII sections and each other. There really is nothing major to it, however doing an ASCII search on the GBA (all 16Mhz ARM7 and 256Kbytes of RAM) takes forever and nobody got around to doing a lookup database or something.

This will save patch ROMs, the only ones that then will trouble you are the ones in the following list
http://gbatemp.net/threads/buying-a-gba-flash-cart-in-2013.341203/page-18#post-4756995

Soft reset, sleep and whatever else is harder but they are not needed for things to work.

As for the ROM naming. Grab a copy of romname.lst from http://filetrip.net/nds-downloads/flashcart-files/download-ez4-client-2009-04-03-f31119.html and overwrite the one is whatever you are using. It should cover most ROMs, maybe a handful of beta and hacked ones might be troubled but scene style stuff should work.

 

[don_luca]

Yeah, I've found trolleydave's blog but unfortunately his batchGBA software is no longer available.

Tried scouring in google cache and through web archive but no luck. I've sent him an email hoping he still has v0.13 somewhere. That would solve all my problems.

I'm not really interested in soft reset and sleep, I can just switch on and off the console to get back to the main menu, no problem.

I'll look into that list you've posted and manually patch those roms (for completion sake).

Also, I've downloaded the EZ4Client you linked but failed to find the romname.lst.
I've only found romlistds.txt (which I suppose is a list of DS only roms).
Besides, I took a look in the last EZ client program folder and failed to find either a sysbin folder or a romname.lst file.

 

[FAST6191]

There was a bit http://gbatemp.net/threads/reverse-engineering-gba-patching.60168/

For the most part it should not be too hard to do a binary compare for a couple of each type and figure out what goes.

It should be in the language folder of that download. You could also try that version. I am not sure what the latest thing changed but all the ROMs I patched with that version still work on every version of the EZ4 I have here.

 

[don_luca]

Found the romname.lst

I'll try using that client and see if it works for me.

It seems that trolleydave got it all figured out. I'm still waiting for him to reply to my mail. Not sure why he hosted his files at the lynnr-papercrafts.co.uk website, maybe he couldn't on his wordpress installation? Too bad they were never indexed and now I'm unable to retrieve the files, sigh.

Anyway... let me see if I got it right:

To SRAM patch a game you first have to look for the values written in that thread. When you find them, you've basically found what kind of save the game is used.
Then you basically swap that code for the patched one.
Is that all?

I've still have to understand the %XX part.

Also, how do I find what's the size of the save file for each game? It's needed to create the .sav file for the EZ Flash IV.

By the way, thanks for your reply and helpful insight!

EDIT: the romname.lst provided is still partially incomplete
I was moving 20 roms at time and I had 3 roms overwrite each other to .gba.

I think I'll wait for Trolleydave response and see if I can get his BatchGBA software to do this. I'll leave writing my own software as a last resort.

 

[don_luca]

Dave replied today and said he doesn't have the files of BatchGBA anymore
Does any of you still have the batchGBA program?

 

[codezer0]

Yea, I'm looking for an alternative to the EZ Client as well. I would even go through the trouble of getting a 32gig micro for the EZ4, and have likely sourced a fresh battery for my SP, if I could just get the *expletive* client to work. In its current state it is utterly broken, which is depressing because of the considerable amount of work that the team has put into the cart's firmware. I'm going crazy trying to figure out how because the goal was to have the complete rom set on a single flash cart, and I clearly can't do that when it wants to fuss to the point that I literally have to do it one at a time so it'll actually do the files at all.

 

[don_luca]

We're on the same boat. Dave is being really really kind to me and is helping me to find the lost BatchGBA software. If I manage to get it back I'd say our problems are solved.

If that fails... well, when I'm done with my exams at university I'll probably write it from scratch.

 

[migles]

We're on the same boat. Dave is being really really kind to me and is helping me to find the lost BatchGBA software. If I manage to get it back I'd say our problems are solved.

If that fails... well, when I'm done with my exams at university I'll probably write it from scratch.

i would also love an alternative client that works better than the current ez client
but will you code it in java?

 

[don_luca]

That's the coding language I'm most comfortable with. It means it will also work on Mac, Linux and any other OS which supports the Java Virtual Machine.

 

[FAST6191]

I forgot to say if you want to try your hand at decoding the ez4patch.DLL it is not very well protected/obfuscated (though it is C++). You might even try contacting the EZTeam themselves -- they did once release the API for the DS patching side of things (EZ4client+ by moledj if you want to go searching).

On Java I think it was more https://gbatemp.net/threads/how-many-of-you-still-have-java-installed.333429/

 

[don_luca]

I have friends who have coded a lot in C++ and I'm sure they'd have no problem making a command line program to use functions inside the dll.

On a side note, I've found DSFCC, another program written by Dave which handles batch SRAM patching of GBA ROMS, but I'm having some issues with it.

You can find it here: http://filetrip.net/nds-downloads/utilities/download-dsfcc-0-35a-f12558.html

It doesn't output the .sav files needed for the EZ Flash IV card and sometimes it just hangs.
I’ve already told Dave about it, hopefully he’ll help me out to fix these problems.

I'll keep you updated with it.

 

[ploum]

Hi,

I had the same problem and shell scripting did the trick. You need gnu/linux terminal or similar; If you don't have one you can make one using a cd-rw and a slitaz image on slitaz.org. Look, it's the DIY way so that's it.

The trick is to make a new romname.lst. It's the file Ezclient uses to rename rom and it associates the rom name from rom header with the chineese and english complete name. The code generate a new one associating our actual rom names with the rom header name so at the end our roms keep the same name.

On 230 roms it fails on one so I got a file named '.gba' and had to look for the missing rom. It was quickly done using pagedown scrolling thru both the original and patched rom directories and check where things doesn't match.

Ok so the code now.

cd 'PATH_TO_THE_ROM_DIRECTORY'
header_name(){ hexdump -C "$1" | head -11 | tail -1 | sed -e "s/.*|\(.*\)|.*/\1/" -e "s/\./ /g"; }
romname_lst(){ for rom in "$@"; do echo "$(header_name "$rom")| - |${rom%.gba}"; done; }
romname_lst *.gba > romname.lst

So you paste this in your terminal. Of course you replace PATH_TO_THE_ROM_DIRECTORY by the actual address of the dir. You'll get a file named romname.lst in this directory. Go back to Windows, open ezclient/language/romname.lst file and put the new content in it then save and it's done. Note that newlines doesn't use the same code in linux and windows it's why I did open the file, put the new datas in there and save.

Hopefully some python skilled programmer will make a nice & simple portable tool from this hack.

I hope this helps.

 

[don_luca]

Nice! Thanks for your contribution, let me see if I get how this works:

the header_name() function takes the ROM file and reads the header and through a regular expression you put the title of the rom in a readable format.

the romname_lst() function uses the previous function to get the header name and slams it into the new romname_lst in a way that's comprehensible to the ez flash software.

last part applies the previous functions to all the ROMs.

Got it right?

 

[codezer0]

If anything there needs to be a way to address a couple of bugs... in particular:
I noticed that if I just click/drag/imported the different GBA versions of Pokemon (R/S/E/Fr/Lg) in, and try the different roms, they keep having errors of corrupted save data... I quickly realized that what was going on was that they were actively trying to read and write to the same .sav file.

The other suggestion, for the rom naming algorithm there, is to have a fallback, so that if the header comes up blank for any reason, it instead can like, just copy the file name, since that is usually more 'unique' than what the header would usually give.

 

[ploum]

don_luca: you got it well, except that romname_lst() doesn't put the data's in the romname.lst file. It only outputs the list for the rom(s) in argument. The last part put it in the file, because of the '> romname.lst'

I'm glad you understand all this. It means you can solve this now

codezer0: This code actually just copy the filename. The reason I got one empty name is a real mystery...

 

[don_luca]

I've been messing with bash scripting for a while, so I know more or less what's going on

The empty name is probably due to header_name() returning an empty value, meaning that the ROM has no header.
We should put a check there and if the header name returns an empty value, we should do something about it.
This is probably due to a prototype or beta ROM where they didn't put the ROM title, or maybe they put a title in a foreign charset and the regular expression failed deleting all the content.

By the way, here's a proper script:

#!/bin/bash
clear
DIR="$( cd "$( dirname "$0" )" && pwd )"
cd "${DIR}"

header_name()
{
    hexdump -C "$1" | head -11 | tail -1 | sed -e "s/.*|\(.*\)|.*/\1/" -e "s/\./ /g"
}

romname_lst()
{
    for rom in "$@";
    do
    echo "$(header_name "$rom")| - |${rom%.gba}"
    done;
}

romname_lst *.gba > romname_lst

Save that code as "romname_lst" (without the quotes) and chmod +x it to make it executable.
Put it in your ROMs folder, cd to it and run

./romname_lst

It will output a romname.lst in the same folder.

I still have to try this out, will report later.

 

[don_luca]

Just as I thought... there are some ROMs which have the header empty.

Some examples:

                | - |Xploder Advance (Europe) (Alt 1) (Unl)
                | - |Xploder Advance (Europe) (Unl)
                | - |X-Terminator Advance (Japan) (Unl)
                | - |[BIOS] Game Boy Advance (World) (TS2)
                | - |WWF - Road to WrestleMania (USA) (Beta)
                | - |Spirit - Der Wilde Mustang - Auf der Suche nach Homeland (Germany) (Beta)
                | - |SpongeBob SquarePants Movie, The (USA) (Beta)

We need a fallback for these.

There's also another problem, and that's Revisions of games:

SPYRO ORANGEBSTE| - |Spyro Orange - The Cortex Conspiracy (USA) (Rev 1)
SPYRO ORANGEBSTE| - |Spyro Orange - The Cortex Conspiracy (USA)

SUPER MARIODAX4J| - |Super Mario Advance 4 - Super Mario 3 + Mario Brothers (Japan) (Rev 1)
SUPER MARIODAX4J| - |Super Mario Advance 4 - Super Mario 3 + Mario Brothers (Japan) (Rev 2)
SUPER MARIODAX4J| - |Super Mario Advance 4 - Super Mario 3 + Mario Brothers (Japan)

TETRISWORLDSATWJ| - |Tetris Worlds (Japan) (Rev 1)
TETRISWORLDSATWJ| - |Tetris Worlds (Japan)

We need to find a solution for these too, otherwise they're gonna be treated as the same ROM and overwritten.

Our problem here is that the header is the ROM identifier. As such it must be unique.

One way to solve this is to modify the ROM header to add the missing information, so that

SUPER MARIODAX4J| - |Super Mario Advance 4 - Super Mario 3 + Mario Brothers (Japan) -> OK
SMA4SM3MBJREV2  | - |Super Mario Advance 4 - Super Mario 3 + Mario Brothers (Japan) (Rev 2) -> Modded
SMA4SM3MBJREV1  | - |Super Mario Advance 4 - Super Mario 3 + Mario Brothers (Japan) (Rev 1) -> Modded

XAEA1U            | - |Xploder Advance (Europe) (Alt 1) (Unl) -> Modded
SDWMADSNHGB     | - |Spirit - Der Wilde Mustang - Auf der Suche nach Homeland (Germany) (Beta)

By the way, the script I've posted works fine for me.
For those stuck with windows here's a romname.lst file updated with the latest no-intro set roms.

 

[don_luca]

Also, why the hell did ez flash decide to use something as unreliable as the ROM header instead of something like MD5 hashes? Ugh. (sorry for triple posting + rant )

If I provide them an updated romname.lst with MD5 hashes and ROM names, will they update their flasher to support MD5 and solve this problem? Or are they likely to just ignore me?

 

[FAST6191]

They moved up to crc32 for the DS. The header stuff rather than a straight hash tends to work better for ROM hacks, trimmed ROMs, trainers and whatever else. Betas and revisions was less of a concern as they would still be doing an ASCII search anyway, and unlicensed is always a fun game anyway as you never know quite what is going to happen (most we have are fairly late stage but not all).

Also I should mention there is a name limit for display (which might also trouble saves). When I was doing the romname.lst stuff it tended to only be the 2 and 3 in 1 titles that hit it but I think it was something like 53 characters.
Likewise there might still be a bug in the loader and the super mario titles might want to be named in 8:3 format.