EZ-Flash USA Forum

I think I know how Windirt has done it Mbmax.

First you have to understand how the GBA memory works.
Everything (including the game itself and more importantly the save memory) has an address you can look it up at
http://nocash.emubase.de/gbatek.htm#gbamemorymap

The save memory of the game is hardcoded at the given address.

However there are multiple types of save which write to the memory in a different way. GBA carts (namely your 3 in 1) only have SRAM which means when a game tries to read/write something like EEPROM it fails (and the rom may then crash or even realise it is an emulator/flash cart running it). This is why patching is necessary (as an aside the original save list for the EZ5 worked by telling the EZ5 which save type to emulate for a given game so it did not need patching).

The GBA roms have a small ASCII type for the save inside them but it is not in the header or some easy to find place so you have to search for it. This is detailed in the other post I made.

Back to the memory though the SRAM is located at 0E000000-0E00FFFF and games generally expecting there to only be one game there start at the start of this section. You try getting multiple games in there and they are going to mess up the save for the other games and it would be a mess. This is why the patch is fairly "unique" for each game in the multirom system.

Well what I understand is that we can't have multi-rom on the nor and psram loading at the same time, I personally would prefer psram patching but why drop all that work? Why not simply let us choose in the configuration menu what we want to use? Single mode with psram loading and gba link or multimode without those other features.

the 3in1 has 4Mb sram to store game saver.
for example. you have 4 game to write
A game is 256Kb sram
B game is 64k eepram
C game is 512K flash
D game is 1Mb flash

now you write the game to 3in1 card in order ABCD,
the program load the A game to NOR, patching it, know the save type is 256Kb sram, it allcate the first 256K sram for A game.
the program load the B game to NOR, patching it, know the save type is 64Kb eeprom, it allcate the 64k sram follow the first 256K sram for B game.
then the 512Kb sram begin at the 320Kb(256+64) for C game, the 1024kb sram begin at the 832kb(512+256+64) for D game.

the patching process is the way to know the game to occupy how many sram. must be done every time when you do the multi-rom write.

if you abandon multi-rom request. we will try do the patched data write back to the GBA rom on microsd, then the patch process only needs 1 time.

but I like the multi-rom function. because EZ 3in1 Plus needs it. it has 512Mb nor flash to store several gba games.

I fail to see why the rom has to be identical.
No hack I have seen touches the header in a way that prevents you from identifying the rom (like you do for the GBA list on the EZ4 with the internal name and part of the serial although I would use a bit more than that as some roms of the same game but from different regions appear the same for that method) and nobody ever changes all the offsets in the rom as it breaks the GBA games.

As a quick aside perhaps the "shotgun method" loading part of the rom could be combined with a library of data on where the patch type is, 3000 entries (all the GBA library) with only a few bytes for each entry saying where the save type string is located and the rom name-serial thing (my GBA list of all the roms available for the EZ4 is only a few hundred kilobytes and that has the serial, the chinese name and the "English" name in it) surely could speed things up and keep space demands down.

No place in the GBA rom to set a tag that remind the size to allocate or drop an ini file on the microSD ?


windirt i'm just a simple user of this product.
Just do what you think it's better. multi-rom or not i love the ez 3in1.
If i want multi-rom i can also use my old pal ez-flash II


I was talking to a friend something like that : "i'm pretty sure the ez 3in1 will be improved and a new unit released soon ..."
Great news.

Hello, Windirt,

Congratulations!

You did a great job, i and several friends love multi-rom, some other people who have others flashcard are interested in buying an EZ-V because of it.

Please do not leave this great idea!

One more time: congratulations!

EDIT: EZ3in1PLUS! Yeah!!!!!!!!!!

Well then you really can't drop multi-rom then, and with 512mb I can see how multi-rom starts becoming more attractive over psram loading. Wish you would have told us of this sooner, at least in my view it puts a different perspective on things.

Windirt,
I think I kind of understand now, NOR is not available for use during multirom because it is being used for the patching. PSRAM obviously cannot be used as it is the main memory for the multirom. And I kind of see some of FAST's technical stuff.

PLEASE do not remove the multirom feature. It is a unique feature, and that is what the EZV needs, unique features. If done right, you might even start selling EZ Flash 3 in 1s with extra memory.

At the moment, I feel that I have multiboot, I have cheats, if I want the quick loading, I still have Rudolph's tools. So please, don't throw a feature down the drain.

Although there is one thing I don't understand. I can see that multirom and PSRAM load can't be done at the same time (no duh), but why do you have to remove one feature to implement the other? Can't you simply have another toggle or option to turn one off when the other is on?

It is very good work windirt I know at least two people now not counting others in this thread who can't seem to express their appreciation of the multi load enough (and will miss it greatly if it dies early.) Well, my 2 cents on the whole thing...

I don't know what all these complaints about speed are, the DS only has 4M of memory (around 1-2.5M of which are in use already by the main app itself), and thus it can only work in little bits and pieces - also, finding a place for non-SRAM patches to fit into a GBA ROM and inserting them there can be quite difficult to do quickly on a slow processor with very limited memory. Add to that, the DS has a fairly slow processor and SD card speeds through the DS slot bus will never be 80Mb/s+ like a HDD - I think it's pretty darned fast, considering.

As for "usefulness" - to me both multi and patching are very useful, though there should still be the option to turn both off (perhaps a header mod is already done by the 3in1 PC patcher that can be easily detected?) especially for those that will complain about a beta no matter what you do or will want to insist on using 3in1 tool - and there is something to the idea of performing the patch on the file instead, that way it is not performed every time the ROM is loaded (so later loads come faster.)

Certain folks fail to see that a beta is meant to gather bugs and input on current ideas (or work in progress) and are quick to ignore that and will judge unsoundly because it isn't "what I want nooooow!"

windirt:
how about using a block or two of NOR for save swapping instead of complex SRAM only patching? It would really slow down a multi load menu though, especially in GBA mode.

Couldn't PSRAM be used to accelerate patching to the file on SD? (though extra work would be needed for >16M files, of course.)

Either way, instead of throwing out the current patching code (and the time spent working on it), perhaps it could at least be used for PSRAM loading? Patching speed would improve and the dual save conflict could be more easily avoided... but that doesn't really help if the idea is a new product either.

To launch a GBA game of 16MB into PSRAM with GBA exploader takes 12~16 seconds (patch included). GBA Exploader doesn't use DMA mode because this is not supported by many linkers. If EZ5 uses DMA mode, it would be faster.

Because launch a small GBA game into PSRAM may be really fast, I think the multi-ROM mode is needless.

This option will never be availbale on M3 GBA RAM expansion pack because of the hardware used, so the EZ 3in1 could have a joker in his hand with the NOR multi-rom.
I hope a ez 3in1 Plus GBA sized version will be available because definitively the multi-rom feature takes sense with that. I wonder if RTC will be to the party ...

If ez team want to touch all players specialy those who want to play at once a game on their 3in1, then PSRAM mode must be added too.

I know it's a hard work but as cory1492 said, patch routine in NOR could be used for this mode because PSRAM is faster. No time wasted !

Save detect size and patching process for the NOR/PSRAM could be optimized if i's done on the microSD. Just once the first time we launch the game and a tag could say (or a string used by ez4 client) "no i'm already patched don't touch me"
Even more, PSRAM could provide extra RAM like cory1492 said for this process to boost this.
For the allocated memory in SRAM (multi-rom), size detected could be written somewhere on the microSD or inside the GBA rom or somewhere else ?

Many possibilities but i'm not a coder so perhaps it's just un-feasible ?

I don't know you guys understand or not.
the psram load mode still needs the patching time as long as nor patching time every time when you do a psram load. unless remove the multi-rom mode completely. so we can write back the patched data to gbarom on microsd and the patching will only do one time. no rapidly psram-load speed if the multi-rom exist. because multi-rom needs the gba-rom untouched to search save point and allocate sram address.

and psram only works under single nor rom mode. it will mess up the game's saver if run psram-load with multi-rom mode.

well I understand the overall situation but it remains one question.

What about gba games patched with trainers.

I almost patched every gba game I play with trainers, could I play these with the multi rom writing function or not?

thanks for all ezteam, you're doing such a great task!

I think I'll buy an ez5+ soon (maybe when 3in1+ will be out)

GBAExploader creates a save file with extension of .sgn that contains patch informations for each games.
Maybe EZ5 kernel can do the same to increase the loading speed?

Multirom feature is a nice one that I can say it's worth taking of, but PSRAM writing is almost same as if you are loading an NDS ROM file. (Or slightely slower)
If it is given to choose from PSRAM writing and multirom feature, I would give a hand to PSRAM only if you can make the speed same as GBAExploader.

First of all, thanks windirt for all your hard work and support over time.

I really dont know how patch is made or how ez3in1 really works. I've seen all the info in this post, and more than anything, how desperating is windirt to try to make us understand his point.

So I'm not gonna make statements of anything, neither gonna ask for some modes or any other thing. If you think, windirt, that multirom is the future of ez3in1, then go with it, all that work cant be thrown to trash, just because some people keep with their annoying "slow speed" thingy.

As far as i see, i think you need to get on something like "we are gonna implement this or that, if you like it, fine we appreciate that, if not, go search another option on your own". You just simply cant satisfy every single request the users made (some of those are crazy and hard to get).

Even after your holidays, in no time there was a new kernel out there. So if any got lost somewhere on this post, I'm just saying, that before any request or comparison on windirt's and the ez team work, or the modes they're working on, why dont you simply be happy with their work?

I really appreciate all your work, all your patience with us "the unhappy customers", and i will say it again, if you think that multirom is the best, just keep working on making that function works on full capacity.