EZ-Flash USA Forum

This may be a dumb question, but is it possible to enable the rumble feature of the 3-in-1 in GBA games that have a rumble feature? For example, Drill Dozer. Perhaps that is what you've been talking about, but I wasn't sure. I'd love to have the rumble feature in Drill Dozer working when running it from the 3-in-1.

Okay maybe dumb question.

How do you backup your save from the SRAM without copying another app into the NOR?

Heh, Rudolph just released a new version of his program. He got the fonts working, so now the program is in Japanese. From now on, all the versions will be released only in Japanese, as I see. Well, I guess he really dislikes you guys to do such a thing, now the program will be useful only to people, who understand Japanese. And you even thought that he would cooperate with you, Cory. But it's his program, he can do whatever he wishes to do with it, I guess.

My ezflash came in today tried this out, and it works great!
Thank you so much for your time in making this app cory, it's much appreciated!

edit: oh yeah, anyone happen to know if you can run gbc games on this? perhaps if you rename them to .gba?

edit again: found a very minor bug, but just thought it'd be worth reporting anyways: If I have a rom that has something other than the basic letters in it, it would not show it, and cut off the rest of the word.

for example I put pokemon on it, if it was named Pokémon - Fire Red.gba all that would show up is Pok, but if I put a regular e, it would show up fine.

Again, very minor but I thought I'd mention it anyways

Cory did some great work with GBALdr, no doubt.



Well, not quite like that. You can use Goomba Color to handle the GBC emulation though. I'm almost done with Zelda OoA right now playing it from my 3in1 written with GBALdr.

Thanks BigBoss
Actually, I only made the offer as I did not know what his intentions were but saw exactly how closely his front end mirrored mine (kind of a knockoff of the filter stuff using console font instead, if you ask me). I figured it was worth a shot, but definitely didn't go so far as to ask directly aside from my post here. Later reading of some of his blog comments badly translated let me to believe that if he hasn't released it yet, he's not going to.

AFAIK, he decrypted the .dat file on R4 to get the soft reset stuff and likely doesn't want to share that information with the possibility of damaging R4, or quite possibly thinks I am posting this stuff on an official EZ forum as a direct representative of EZ (which is definitely not the case). It's hard to understand the exact reasoning from his english post, which is exactly what I expected from previous communications with him regarding the EZ4 driver.

I am actually about 1/2 of the way with what I knew before with memory dumps I took (R4 patches the in memory header with a reserved area 3 byte diff at 0x18 (0x27FFE18), this is also what rudolph checks for to see that R4 patch is enabled), I just need to figure out exactly what else it is patching in. It most certainly won't be a problem to extend the interface with a "fake" directory listing to add options. As soon as I can sit for more than a few minutes at a time (3 day old medical problem which results in a literal pain in the arse) I'll start on 0.2 and begin adding such promised new features.


Use a program like notepad to create an empty file, rename it to "gamname.sav" where gamename is whatever thame you want, basically. In the GBALdr menu, select the .sav file you created and press A to bring up the menu, then select write to file.

crunchy2: putting it in rumble mode does not seem to allow access to NOR. As with the DS rumble cart, any accesses to the GBA bus causes a rumble, so not likely (I don't think it is meant to emulate a GBA rumble cart).

Haruk: thanks much. I was kind of wondering when someone would notice I didn't allow extended ascii text yet (it should have just skipped the é when displaying the name though... thats concerning, going to have to write a better filter I think). I have the stuff pretty much ready to add in up to 0x96 in characters, but didn't have any text to test with (thanks again ). Can you confirm whether it or not it currently writes the save file name properly even though it won't show it in gbaldr?

it does write it correctly, when I saw my memory card from a computer, it showed up right

0.2 should have the full ascii text set as well then, thanks again Haruk (you saved me some pre-testing to be certain libfat supported those chars).

Interesting. A save game run from a PSRAM game does not conflict with a save game from a NOR game. Don't both programs keep their saves in SRAM?

When running a game from PSRAM, Rudolph's app set's the SRAM to page 50 (I think, it's 204,800 bytes into the SRAM). This apparently works just fine for every save type except 128KB flash.

Does anyone know if there are any issues with using GBAldr to flash the NOR and the other app to flash the PSRAM at the same time. I mean more in terms of SRAM conflicts. Like if I had a game that uses Flash 1 Mbit save type in NOR and then flashed a game to PSRAM and played from there, would either of the saves be overwritten?

AWESOME.

good work cory and bigboss.

Thanks for your continued support. I will definitely test this when I get my stuff!!!

BTW a little off topic.

Where did u learn this stuff cory???

I am also a C and java programmer but not a good programmer!!! lol

The games won't overwrite each other's saves, but GBALdr will overwrite the file info from the other app and the save from the game in PSRAM when it writes a save to the SRAM. Rudolph's app won't touch GBALdr's file info, and it will only overwrite the save for the game in NOR if you use it to write another game to NOR.

If you want to run games from PSRAM you should use Rudolph's app to write games to NOR as well, that way you won't run into those conflicts.

Arrgh, and to think just a couple days ago I was blissfully unaware of what a perianal abscess could possibly feel like... at any rate, if this makes little sense, sorry... that happens with morphine derivatives I'm told.
I am definitely Pro choice, and I for one like Rudolph's app

Rudolph went to some trouble to be certain that his app would not interfere with GBALdr (I have no doubt he is reading here as much as I am reading his blog, too), and I must thank him for it. There are probably a few cases where this does not help, but... GBALdr can and will definitely be improved to work around his app (now that I know about it) so no conflict occurs in the meantime. As I said before, 256K is just too big, there are no GBA games I have been able to find that actually use that much SRAM, it requires a bit more investigation for the answer to the one thing that is bugging me about reducing the save size to a max of 128K - why does EZV itself always backup 256k from 3in1. My line of thought so far has been simply "make sure no one loses their save games while using this initial version".


I applied the 3 R's... reading, reading, and more reading - and then I tried some stuff. Good place to start is gbadev.org. 98% self taught also means likely a lot of bad habits (I have only had an introduction to programming languages course 4hrs/week for 3 months... back in 1993), and have simply been paying attention to this DS hoopla since before DS was entirely hacked (though I am far more skilled now than then, many of even the 13y.o. sized coders working with DS still eclipse my own capability - for some reason I just don't think I have the time they do). BTW: gbaldr itself is coded in C

kewl.


Me also will learn this stuff. Very interesting indeed