EZ-Flash USA Forum

Sorry windirt if i'm boring you because my knowledge in coding things is very poor, but ...
Common point of all mode ?
Needs to know the save size and type. This process needs to scan the entire ROM witch it could be very long. Right ? and is needed every time if the ROM stay untouched on the microSD, right ?
The goal i'm thinking is what i told you. Modify the ROM on microSD so it's just done one time. But when it's done, isn't it possible to store somewhere the save size to allocate in SRAM for this ROM ? and perhaps the offset where something must be modified (SRAM start adress according to the position (1st, 2nd ...) the rom is flashed like you explain me ?) so this small process can be done in NOR when the rom is used in multi-rom mode ?


When we switch between PSRAM mode and NOR multi-rom, isn't it possible to backup all saves in SRAM to the microSD before doing anything else so the saves are not lost ?

BTW, thanks for the time you spend with us, i appreciate it.

thanks for everyone's advices, our programmers made a conference and got the solution. please look the thread. viewtopic.php?f=16&t=12918

Ok, many people like the multi-ROM.

My bug report :

• The icon "close Window" is improperly placed.
  
• I can't launch a ROM from multi-rom mode without EZ5.
  
• 1st test : write 2 ROM
  
  0985 Rayman 3 => Works but I can't save.
  0639 Dragon ball Z => Run but I get this message:
  
  
  
• 2nd test : Add 0997 Castlevania
  
  The multi-rom mode becomes crazy.
  
  

Welcome abord flastosh.
As far as i know, the legacy of goku needs an ips to work properly so perhaps it could be something to add.
BTW, did you try classics NES series ? Those titles will probably not run.
I know that rudolph has made an update to his GBA exploader specialy for those games ...

When could temperature on skins be implemented?

This is already something I considered when planning gbaldr... I spent a few days (approx. 36 hours or work time) looking at patching and SRAM management in the time before EZ5_3in1_GBA/3in1_ExpPack_Tool/exploader was released - and I'm giving you the suggestions I came up with as they are ideas worth considering. But hey, I'd not be amazed by EZ if I was ignored entirely as my time on it was already wasted.

Load ROM to PSRAM -> do patch routine there (it is faster to read through PSRAM than load chunks from SD as needed) -> do patch -> diff can be saved to file (as you seem to have decided on already) or even kept in memory for NOR write. Speeds up the patching process (hopefully), as files up to 16M can be analyzed and patch data created in one go (2 go for > 16M).

Part of the problem has been complex SRAM based saves, using a block or three of NOR could make patching less complex - meaning the files can be generically patched as the save data would be copied off to NOR before being corrupted by the next game loaded. This could also solve size limit of SRAM for number of files allowed in multi mode...? Also there is the problem of many that the 3in1 battery dies - keeping ALL saves in SRAM becomes impossible. I have been contacted directly by too many people with dead batteries in their 3in1, who are always wondering why GBAldr or exploader can not keep save data - the only solution is quick power reset, before SRAM dies internally

To top it off, there will be many users who will update and wonder why their 3in1 tool patched games are not working. If there is a header change that can be seen, this should be a message in the loader "you have already patched this with 3in1 tool, get the clean one instead."

And what you said before I replied - multi mode would be trashed: if so most would use PSRAM load, in that case those could still be patched (simplify current patcher to do so) - but since it will not be trashed...

Don't know if it matters much I have had success with this beta, well at least the one part that I used that was new, I was able to patch and run two gba games with the multi-rom feature, with and without using the ez5 cart to launch it. No problems saving/loading and was actually able to save faster than the original gba carts. I have a NYE that has not had one issue ever.

@Cory : sounds great to use NOR instead of SRAM to do the job. But if you take some block, then the biggest game will not fit into the NOR any more, no ?

And i'm agree with you concerning the fact that some 3in1 battery dies to quickly.

returning from the sea

best update of ever
MultiRom is beautifull

BUGREPORT
the NDS game name don't fill perfectly
There isn't a GBA Cheatcode Collection; would be better with a CRC Rom identification than with tha name

What do you think is done to put the multi rom menu in there? It is only a block that is taken (the loader is currently 19,928 bytes), but it is still used. Any rate, a block (the amount that is erased per go) is 0x40000 bytes (262,144). The thing that actually makes it somewhat unacceptable is - the erase cycle is slow so each time you'd change a save out to NOR there is a 3-4s+ delay (the blocks towards the end of NOR seem to erase faster than the first one...), and it would likely be even slower in GBA mode.

Could it be possible for the 3in1 plus to use some non-volatile memory for it's saves?

I was talking about the simple mode rom. If you plan to use NOR instead of SRAM you plan to use it for both mode i think (save patch done once on the gba game).

I don't know if that has been done before. I don't really know much in slot 2 flashcarts ...

Mbmax: There's always trimming. Most 32MB games should be able to fit after a bit of trimming, although some (e.g. Riviera, maybe Mother 3) don't trim at all.

Mother 3 uses the entire rom (one of the reasons hacking it was such a pain) but Riviera (and I think Bleach too) have a bit of junk right at the end of the rom that you can delete with a hex editor and then trim normally (I think I even have a xdelta patch on my site (called rivieratrim or something). They do not quite make the 16 meg mark though (I know Riviera is quite a bit less than a meg off) and rom ripping for the GBA is damn hard.
This being said the Japanese Riviera release is 16 megs so maybe something could happen there (I am not a great fan and taking a break from translation for a while so probably not from me).

A problem I see arising is the rise of GBA rom hacking; now the GBA is dead it seems the hackers are coming out of the woodwork and given there is a whole 16 megs "unused" (and most good hacking candidates clock 16 megabytes) it is too good to pass up......

B-chan: that is part of what I am trying to get across. Either they could expand current SRAM (but it is still battery based) or add a secondary chip to hold savers when they aren't in use... who knows how far along they are in making 3in1p though, perhaps it is already set in stone and the only change will be bigger NOR (I'd prefer bigger RAM.)

And I'm not talking about in game saves, those would still go to the generic location in SRAM (while psram loading wouldn't be disabled as it would patch to use one higher than the max save size for all GBA.)

Part of the multi problem seems to be the fact that each game has to be patched to use a different save "slot" in SRAM, taking extra time and giving no standard to follow as you could delete them all and re-order them at will, but they'd get patched yet again.

If you take that problem away by transferring the save to NOR when you switch games in the multi menu it not only frees up SRAM for PSRAM only use, but it doesn't limit how many games you can have in NOR based on their SRAM save size equivalent (I mean for example, if you pack a bunch of individual nes games into their own packages and load a few of them, you will hit the SRAM limit for how many 32 or 64kbit saves you can have before you fill NOR) - and it could also give a quick power cycle option via the gba multi menu. Less complex save patching, but more complex save management. Again, the problem becomes that anything running in GBA mode is going to much more painfully slow than stuff in DS mode.