EZ4 loader 1.76 released, some bug fixes.

[kuwanger]

Now I want to change the soft rest combination from A+B+Start+Select to L+Start+Select.

abstartselect inclues a patch_bin.py file, so I can change the soft reset combination. I have downloaded Python 2.7.9 already, but I have no ideia on how to use it and how to change the combination. As you can see, I have zero knowledge in programming.

What I really would like to do is to only use the soft reset part of the patch, that is, I don't want to include the sleep hack.

Would you help me?

For the former, in a cmd shell go to the abstartselect folder (easy way is to extract abstartselect to the root folder of a drive and then "cd \abstartselect") and run "python patch_bin.py L+Start+Select".

For the latter, the simplest way is to simply nop out the check for the sleep mode/jump to sleep mode. So, you can use hexalter from the abstartselect folder and run "hexalter patch.bin 0x50=00,00,0xa0,0xe1,00,00,0xa0,0xe1". You should only have to do this once.

Be sure to copy the patch.bin over to the sleephack folder. And then you should be fine.

 

[Donel]

For the former, in a cmd shell go to the abstartselect folder (easy way is to extract abstartselect to the root folder of a drive and then "cd \abstartselect") and run "python patch_bin.py L+Start+Select".

For the latter, the simplest way is to simply nop out the check for the sleep mode/jump to sleep mode. So, you can use hexalter from the abstartselect folder and run "hexalter patch.bin 0x50=00,00,0xa0,0xe1,00,00,0xa0,0xe1". You should only have to do this once.

Be sure to copy the patch.bin over to the sleephack folder. And then you should be fine.

That worked perfectly, thank you very much =)

 

[Yepi69]

OMG YES!!!!!!!!
OMG I AM SO GLAD AND HAPPY
24 hours masturbating celebration!


i have a mini sd version with this problem, and there was lot of people reporting it too, i get angry sad and angry that i would have to buy a new card to fix this

I AM SO HAPPY
GIVE ME EZ IV TEAM EMAIL FOR SEND NUDES!!!!

Dun have a heart attack, please my fellow portuguese
I'm just as glad as you.

 

[Testo90]

Hey Guys, I got a problem with my EZ Flash.. i got it today, patched a game (Golden Sun), uploaded the newest Kernel 1,76. The game starts normal and i save the game. But what do i have to do next that the savegame is written to the microSD? The method A+B+^+L doesn't work. When i reboot my GameBoy Micro a screen appears which says "writing goldensun.gba save.. but then the gbmicro freezes.

Sorry for my bad english.

 

[Donel]

It may take a while for the game to be saved to the MicroSD, it used to take 10-15 seconds on the older firmwares.

Are you using the 2013 MiniSD version with an MicroSD adapter? Some adapters are known for causing these kind of problems.

 

[Testo90]

It may take a while for the game to be saved to the MicroSD, it used to take 10-15 seconds on the older firmwares.

Are you using the 2013 MiniSD version with an MicroSD adapter? Some adapters are known for causing these kind of problems.

Got the 2015 MicroSD Version. I think the Problem is that there is no .sav in the SAVER Folder, do you know what i have to do that the file is created?

 

[FAST6191]

Got the 2015 MicroSD Version. I think the Problem is that there is no .sav in the SAVER Folder, do you know what i have to do that the file is created?

EZ4client would usually take care of that. The files themselves are nothing but files named the same as the ROM in the appropriate size (or bigger if you want to waste space), a few DS games wanted saves to be made before playing but GBA games have nothing like that which I am aware of (though I have some suspicions about some). If you have the save from another game and the size is right then I tend to just copy that and rename it.

Anyway it looks like I will have to look into a few things. The EZTeam are actively listening to bug reports so this could get good.

 

[Testo90]

EZ4client would usually take care of that. The files themselves are nothing but files named the same as the ROM in the appropriate size (or bigger if you want to waste space), a few DS games wanted saves to be made before playing but GBA games have nothing like that which I am aware of (though I have some suspicions about some). If you have the save from another game and the size is right then I tend to just copy that and rename it.

Anyway it looks like I will have to look into a few things. The EZTeam are actively listening to bug reports so this could get good.

Thank you, could anybody Upload a save file so i could just rename it? Otherwise i try it again with the program

 

[Testo90]

EZ4client would usually take care of that. The files themselves are nothing but files named the same as the ROM in the appropriate size (or bigger if you want to waste space), a few DS games wanted saves to be made before playing but GBA games have nothing like that which I am aware of (though I have some suspicions about some). If you have the save from another game and the size is right then I tend to just copy that and rename it.

Anyway it looks like I will have to look into a few things. The EZTeam are actively listening to bug reports so this could get good.

Right now i patched a other game and finaly got the .sav in the SAVER folder. But after ingame save>hard reset> the Screen freezes while *waiting writingZeldaMinis.sav 8kb... i dont know what to do

 

[Coto]

Yea, it's a known issue and gba sleep mode can be potentially patched to work depending on the game or you can use the above mentioned sleephack

I took this post from the site you posted earlier because I couldn't find the #PostIndex button so I could get the post link.

I'm having a small problem with the sleephack using up too much CPU time, and I was hoping someone could look into it. Specifically, I'm working with Organya Demo 1.2.

The base rom doesn't work with the patcher properly because it contains the following code:

Code:

80cf8bc: e3a0e403 mov lr, #50331648 ; 0x3000000
80cf8c0: e59fcd28 ldr ip, [pc, #3368] ; 0x80d05f0
80cf8c4: e3c29b01 bic r9, r2, #1024 ; 0x400
80cf8c8: e28e4c7f add r4, lr, #32512 ; 0x7f00
80cf8cc: e584c0fc str ip, [r4, #252]

What I see there is whatever ARM opcode/handler pointer (callback) [WORD] is at 0x080d05f0 (a WORD fetch from that offset on the GBA-ROM mapped area (being 0x000d05f0) is passed through IP (r11) and then stored at 0x03007ffc. This is the default IRQ offset where the CPU jumps as soon it is entered the IRQ mode.

The sequence for GBA IRQ mode is basically:

1. ARM CPU IRQ mode (0x00000000+0x18) (GBA BIOS read-only)

2.[handler code at GBA BIOS read-only that jumps to 0x03007ffc] (having the prefetch the lead of executing whatever is there.)

3.[do handler code]

4. [restore and exit back to (GBA BIOS read-only) by restoring LR from the stack]
5. [exit and continue game code by restoring SPSR from stack if CPU destroys the real SPSR when handling exceptions]

If you ask me, that is *mostly* [IRQ] handler installer code. Remember that every IF (Interrupt Acknowledge) bit must be anded with IE and then that bit must be set at IF. Otherwise the program flow will continue to execute the unattended IF bit. Note that the program is actually restored upon repeteadly jumping to it:

BL =IRQ_HANDLER_label_IF_BIT13 (if the callback does not swap ARM/THUMB modes) (BLX is armv5 so gba doesn't understand that opcode)
<continue>

(or)

MOV LR,PC ;
BX =IRQ_HANDLER_label_IF_BIT13; (if the callback does swap ARM/THUMB modes)
<continue>

I say extract whatever points at 0x080d05f0 (until a BX LR or pop {xxx,pc}), and add some code so the IF bit[13] (GamePAK IRQ) is cleared before returning from the extracted code. And patch back

edit:

ctrl+f "bios interrupt handling" @ http://problemkaputt.de/gbatek.htm

Also in my profile I have some code that says how the NDS9 executes an interrupt and how goes back. (pretty much the same as the GBA does (gba bios) )

 

[kuwanger]

I took this post from the site you posted earlier because I couldn't find the #PostIndex button so I could get the post link.

...

If you ask me, that is *mostly* [IRQ] handler installer code.

Yea, that was the point. Dwedit's patcher looks for a specific set of instructions for an IRQ handler installer and then overrides it with its own IRQ handler; ie, it turns it from "irq -> to be installed handler (in this case 0x080d05f0) -> return from irq" into "irq -> patch.bin's irq handler -> to be installed handler (in this case 0x080d05f0) -> return from irq". Like I said, instead of fiddling with Dwedit's patcher I just rewrote the code to follow the format his patcher looks for and then it went downhill from there...

I say extract whatever points at 0x080d05f0 (until a BX LR or pop {xxx,pc}), and add some code so the IF bit[13] (GamePAK IRQ) is cleared before returning from the extracted code. And patch back

Uh, yea, not really sure what you're trying to say here (been too long since I did gba IRQ stuff and honestly never fully understood it).

In any case, what you're quoting is a post made "Dec 11, 2008", so I don't even remember at all any of that stuff except, as I said in the post, some odd issue of having overly high CPU usage related to the patch.bin's IRQ handler being installed. So, perhaps it has something to do with the GamePAK IRQ or precisely how the patch.bin deals with interrupts. I never really got further into it because it wasn't worth the effort to me to figure out. :/ It just seemed odd because patch.bin, at the time, looked like it properly dealt with the interrupt demands it made or would readily just pass through to the underlying handler which worked fine alone.

But, again, as I said I never did fully understand the gba IRQ handler stuff. It's one reason my multiboot hexviewer is so crappy. Could never figure out why doing a keypad interrupt didn't work right. Maybe it had something to do with the arm/thumb switching you mentioned? *shrugs*

 

[Coto]

well GBA games use thumb code, and most cpu exceptions (as the default route of action of the CPU is to go idle through SWI wait for interrupt) a callback is triggered through the Interrupt Flags registers
precisely when:
(IME ==1)--> (IE&IF == 1)
-> execute related callback, then restore LR

point is replacing the handler can break the game code, so extracting the handler and force setting bit[13] at IF vector through a rop chain or something is something definitely doable.

Yea, that was the point. Dwedit's patcher looks for a specific set of instructions for an IRQ handler installer and then overrides it with its own IRQ handler; ie, it turns it from "irq -> to be installed handler (in this case 0x080d05f0) -> return from irq" into "irq -> patch.bin's irq handler -> to be installed handler (in this case 0x080d05f0) -> return from irq". Like I said, instead of fiddling with Dwedit's patcher I just rewrote the code to follow the format his patcher looks for and then it went downhill from there...



Uh, yea, not really sure what you're trying to say here (been too long since I did gba IRQ stuff and honestly never fully understood it).

In any case, what you're quoting is a post made "Dec 11, 2008", so I don't even remember at all any of that stuff except, as I said in the post, some odd issue of having overly high CPU usage related to the patch.bin's IRQ handler being installed. So, perhaps it has something to do with the GamePAK IRQ or precisely how the patch.bin deals with interrupts. I never really got further into it because it wasn't worth the effort to me to figure out. :/ It just seemed odd because patch.bin, at the time, looked like it properly dealt with the interrupt demands it made or would readily just pass through to the underlying handler which worked fine alone.

But, again, as I said I never did fully understand the gba IRQ handler stuff. It's one reason my multiboot hexviewer is so crappy. Could never figure out why doing a keypad interrupt didn't work right. Maybe it had something to do with the arm/thumb switching you mentioned? *shrugs*

I don't think any of your tools are crappy, they are useful. Last time we had a convo about the EZ kernel I didn't know that much about GBA Hardware tbh as well, but now I have some good experience about it. I have some code that actually injects whatever you compile (from GCC) and patchs by modifying the IRQ handler of pokemon sapphire. (so it calls a label before doing the IRQ routine). If you are interested, I can help through PM or something.

: D

 

[draxoon]

Here goes some good stuff .

I just couldn't stand how messed up is latest (1.76) EZ4 update. It fixes some bugs, which is great, but:
1. File names were hardly visible with that Mario background...
2. The skin was attached to the loader twice, so the file was much bigger for no reason! (...those Ez-Flash guys who built it...)
3. The loader came with unused English-Chinese dictionary only covering letter A (twice). It was propably meant for EZ-Word, whatever it is.

I took "Customize Pack" for 1.75 from http://www.ezflash.cn and replaced loader with the one from 1.76, so it is up to date as of now (RomBuildPro.rom). I also cleaned everything up heavily, so the loader is less than a half in size in comparison to the official one! Additionally I made some generic skin to replace ugly backgrounds. In the end, I replaced font and text with the ones from Clearlooks skin (thanks to the author!). These come as an IPS file (apply it to RomBuildPro.rom before building loader, or to ezfla_up.bin after building it). Moreover I include cleaned tools, so you can replace the skin and build your own clean (less than 1MB) EZ4 v1.76 loader!

Enjoy!

Edit:
Uploaded a new version!
- Updated the skin with new icons,
- Fixed displaying some saves as '8,192', they now show as '8 KB'.

Edit 2:
- Added 'TinyTextFix' IPS file, which corrects 'waiting to sd' to 'Writing to SD' in v2. Apply to 'ezfla_up.bin' or 'RomBuildPro.rom'.

 

[Donel]

Thanks for the custom loader, draxoon, I'm going to test it soon.

There's a really annoyng bug in the original loader, it shows the size of an 8 KB save file in bytes instead of showing it in KB, as it does for every other file. Could you fix that?

 

[draxoon]

Thanks for the custom loader, draxoon, I'm going to test it soon.

There's a really annoyng bug in the original loader, it shows the size of a 8 KB save file in bytes instead of showing it in KB, as it does for every other file. Could you fix this?

Fixed! Thanks for idea, it wasn't very hard to do. I replaced attachments in my previous post with a new version.

 

[Donel]

Thanks for the fast fix =)

I've attached an already compiled loader with Clearlooks fonts and Carbon Fiber skin.

 

[draxoon]

Nice, I'm glad it's useful .

 

[physicallyinsane]

Here goes some good stuff .

I just couldn't stand how messed up is latest (1.76) EZ4 update. It fixes some bugs, which is great, but:
1. File names were hardly visible with that Mario background...
2. The skin was attached to the loader twice, so the file was much bigger for no reason! (...those Ez-Flash guys who built it...)
3. The loader came with unused English-Chinese dictionary only covering letter A (twice). It was propably meant for EZ-Word, whatever it is.

I took "Customize Pack" for 1.75 from http://www.ezflash.cn and replaced loader with the one from 1.76, so it is up to date as of now (RomBuildPro.rom). I also cleaned everything up heavily, so the loader is less than a half in size in comparison to the official one! Additionally I made some generic skin to replace ugly backgrounds. In the end, I replaced font and text with the ones from Clearlooks skin (thanks to the author!). These come as an IPS file (apply it to RomBuildPro.rom before building loader, or to ezfla_up.bin after building it). Moreover I include cleaned tools, so you can replace the skin and build your own clean (less than 1MB) EZ4 v1.76 loader!

Enjoy!

Edit:
Uploaded a new version!
- Updated the skin with new icons,
- Fixed displaying some saves as '8,192', they now show as '8 KB'.

Edit 2:
- Added 'TinyTextFix' IPS file, which corrects 'waiting to sd' to 'Writing to SD' in v2. Apply to 'ezfla_up.bin' or 'RomBuildPro.rom'.

Could you possibly do a quick tutorial on building custom loaders with the programs you've uploaded? Or throw me a few links my way showing how to do it? I'm new to the flash cart scene and unless a README.txt comes with any program showing how to use it, I'm completely lost. I know a tutorial's a tall order on the spot so I'm in no rush on changing the skin on the 1.76 update.

 

[draxoon]

Could you possibly do a quick tutorial on building custom loaders with the programs you've uploaded? Or throw me a few links my way showing how to do it? I'm new to the flash cart scene and unless a README.txt comes with any program showing how to use it, I'm completely lost. I know a tutorial's a tall order on the spot so I'm in no rush on changing the skin on the 1.76 update.

Well... Just put your skin files (24bit bmp) or manually edit existing ones in '\Res\.shell\bmp\" and run 'Build.bat'. It will create 'ezfla_up.bin' file suitable for copying to SD card and updating Ez4. You can also apply 'Text+Font_Fix.ips' to 'ezfla_up.bin' using 'Lunar IPS' if you want. That's all.
More info at: http://ezflash.sosuke.com/viewforum.php?f=13.

 

[physicallyinsane]

Well... Just put your skin files (24bit bmp) or manually edit existing ones in '\Res\.shell\bmp\" and run 'Build.bat'. It will create 'ezfla_up.bin' file suitable for copying to SD card and updating Ez4. You can also apply 'Text+Font_Fix.ips' to 'ezfla_up.bin' using 'Lunar IPS' if you want. That's all.
More info at: http://ezflash.sosuke.com/viewforum.php?f=13.

Cool, thanks. I was able to compile the clear look skin but is there a way of changing the text in the help section so as to credit the author?