EZ-Flash USA Forum

Absolutly.
My english is sooooo bad.

But we olso have a save problem on Flash 1024kb games.
Save names seems to be strange. I must keep a eye on this.
I think old 3in1 saves from previous kernel are not named the same way ...

Well at this time i'm not sure we can continue to beta test this OB2 because we don't know if windirt will continue with this.
It could be a waste of time, so i prefer wait his reponse to know if multi-rom will stay alive or not.

i also hardly explain it with english.

the patching speed is the key of the on-console patch. there are several posts blamed it. you can looking for it.
I said it before. the gba rom on the microsd. the EZ5 and the DS don't know the save type. until the program search the save type point and patch it. then the multi-rom loader can allocate the saver space on the sram. no patch process. no save type recognize.

the speed loss is the price of leave PC side 3in1 tools.

psram load aslo conflict with multi rom mode, reason please check page 2 my post.


if you want slightly patch speed. please use PC side 3in1 tools.

if you want psram load. please use multi-rom write. it only works with single rom mode.

But why patching into the NOR instead of the microSD where it could be done once for all modes ?

the problem is not that I am angry. I am just disappointed the users can't understand the working process of the hardware. they only know to compare the speed simply.

We give them the speed if they want the speed. other things can be ignored.

I know I lack a 3 in 1 and so can not say much on the subject but please leave the features you added.
There will always be some opposing change but what I am seeing (aside from some teething problems which is to be expected on such a massive change and it being the first beta release of it) are your regulars and those who support your cards other than you guys really liking the features. I suppose the thing to do would be to make the optional (like you did with the EZ1/2/3 patching where you could turn if off if you wanted to).
I will give links if you want but here, gbatemp, some of the Chinese forums, some of the French forums and a few of the other forums in various other languages are all really pleased at these features. Regarding the users who do not understand it takes a little while but it eventually sinks in (I lost count of how many times I explained something simple like DLDI and why it is necessary at first, nowadays if any company is foolish enough not to make a DLDI file they are the first ones to pull them up on it)
If you do have to remove them could you at least consider making a "module" of sorts.

For everyone else GBA patching works as follows.
The GBA rom is searched for ASCII text indicating the save type. Broadly there are 3 types: flash, sram and EEPROM and each has their own set of subtypes (V124, V126 and whatnot) each with a "different" patch required (the actual patch code is the often the same but the place it is patched at is not). On a sidenote VBA occasionally does not work for saves (requiring a manual setting of save type) because it only does checks for the first string (EEPROM or whatever) and not the version type.
The key word in that is searching, computerised searching (especially for a small string in a relatively large file) is damn hard task (a lot of the upcoming SSE4 instruction set is geared towards it) and there is no way I know of that it can be done in any other way for GBA roms (there is no header value and no simple disassembly trick). Your machine has at least several hundred megabytes of memory (more than enough to store a rom in) and probably clocks at least 1GHz with decent search abilities (way more than the 4 megabytes and 66MHz basic instructions (ARM is advanced RISC machines after all) of the DS).

Don't know what to say windirt.
It's just that it's more simple to do the job one time than every time, no ?.
Patch on the microSD is not possible ?

yes. we think to patch the ROM on the microsd. but DS can't handle to open a 4MB file to search every byte. but on NOR flash search byte to byte is fast.

maybe you will say the M3DSREADL + GBA card can do the patch on-console, it do so, it load the rom to the SDRAM, then patch rom in SDRAM, also need 1x-3x second to patch(same as us).

or somebody build a whole save type table and the prepatched data table. yes, we can make a one, but who can ensure your rom 100% same as ours?

someone will say M3DSREAL can write back the patched data to the gba rom on microsd, next time no need to patch the rom again , yes it do so, because they only have SDRAM load mode( single mode), but we need the patch process in the multi-rom write to allocate saver space.

possible, but you will never meet the multi-rom again. you can get the single nor mode and psram load.

please choose.

Let the multi-save adress patch in the NOR when we load the rom
This process is quicker, no ?


Thanks FAST for your very detailled post on GBA saves.

thanks for the good explain. I hardly to say it in english.

No can do, the data to search is not fixed. they are not same in diffrent rom.
unless there is a all prepatched database. it can help patch speed slightly. who build it? who ensure the rom are same?

Massive GBA library of patches.
I agree it is far from an ideal option (and the existing one is better) but you say roms may not be the same.
I have hacked countless GBA roms and updated the name lists for all of them, aside from some header hacks (which do not change it as far as this is concerned) in the earlier roms I can see no reason.
This is further improved by the fact if you alter the file size inside a GBA rom you will break the rom (all pointers internal rather than the file system of the DS).

What I would consider though is that the save type is not always that far into the rom (or is generally around the same place) so you could do a sort of shotgun approach where you load only so much of the rom into the ram and try to find the save type string in the section. If it fails then you can fall back to the method you are using now.

I would be happy to donate CPU time (and maybe even write an application to find out) to finding out where the patch data is on average in the roms.

wrong word used. please replace the "slightly" with "rapidly" in my all posts in this thread

ho ! perhaps i don't understand how multi-rom saves works like you said.
I was thinking the first process was to find the save type (it could be done on microSD) and the second to give the adress to point the right place in sram (done in NOR).
This value is never in the same place is that you mean ?

our ideal is build a database to store every gba rom prepatched data and offset. it looks simple and foolish but it very fast on load and patch in our test process.
but the veracity of the rom is very important. it must be 100% same to each rom in user's hand with our rom. it is hardly to be realized.