Sounds right, you've pretty much listed any steps that are needed - just make sure your games are clean and if exploader or AIO can patch them it will when it loads them. For gbaldr you must patch before using it on them, ez4 client or gbata if that doesn't work, there are a lot of options if you get one of the non hw update packs and set up the ini but it isn't required and is mostly cosmetic in nature. Generally, a white screen at a gba launch is because of a bad save patch, it tries to verify save data before the logo screens and gets stuck somewhere in the patch - or possibly a corrupted GBA card header (on gba this would freeze at the end of the GBA logo presentation.)
When I say "don't mix patches" I also mean don't expect to be able to load a game in PSRAM with exploader, then load a game with AIO to NOR, then load a game with chuckstudios psram loader and then still expect your PSRAM save to be there later. Pick one, stick to it or know what you are getting into when switching off. Which, btw, is why gbaldr backs up SRAM to a file when you first run it - so it doesn't completely erase whatever save data you had on there before.
There is always the possibility of a hardware fault, too. Unless you are talking about the 360, a 3-5% failure rate is pretty much expected within warranty periods for almost anything manufactured and complex.
Some basic education on EZ3in1, so you can have a better idea where the problems come from when you meet them face to face. The design ideas of the 3in1 is the same as EZ4 and EZ3 (in fact I can share code between most of the EZ gba carts), except both of those have a booting "OS" and media that is not NOR/SRAM/PSRAM to deal with save data between game loads - meaning one game at a time is kept in save SRAM and patching is done once when initially loading games to the media card; 3in1 was not really designed initially to use PSRAM for games, and in fact it has to be tricked a little to do so.
By default, when 3in1 first gets power (ie: if you were using it in a GBA) NOR appears at gba bus address (if a game is flashed and has a valid header a good ol' GBA will start it direct, same as GBA mode from DS' main menu) and SRAM is offset to page 0x10 (see code box below, location is same as "SAVE area for NOR", the start of the second 64k 'bank') - so technically once you flash a game to NOR with any of the tools you should have no problems with it, even if you boot GBA mode from somewhere else.
What exploader tries to do in addition to this is to patch games as they are used so that the save in SRAM from the NOR game and the save in SRAM from the PSRAM loaded game don't overlap - the patching still has bugs and afaik the author has abandoned the program as-is. From the readme:
CODE
ÂÂSRAM capacity is 512KB (4Mbit) and you can use it by 8KB(64Kbits) paging.
ÂÂSave area for NOR is stored from offset 64KB like this:
64KBÂÂÂÂÂÂÂÂUNUSED
128KBÂÂÂÂÂÂÂÂSAVE area for NOR
8KBÂÂÂÂÂÂÂÂSAVE management area
128KBÂÂÂÂÂÂÂÂSAVE are for PSRAM
Rest of spaceÂÂÂÂUNUSEDI've never been able to get the exploader to work consistently, it's done some pretty wacko things along the way for me and since it had no english support I left it well enough alone...
What gbaldr does, is rely on ez4 client to do the patching - meaning all games will save at the same spot (64k offset) in SRAM. One game at a time, always in NOR. For my own purposes this is plenty enough, despite the slowish flashing time - though I've been putting it off for at least a year I've always wanted a way to switch to PSRAM mode without repatching anything (corrupt NOR on purpose so GBA mode launch from anything else won't work.)
What AIO does with save areas I have no clue. I use it with my f2a occasionally, but have never analyzed exactly what it is doing with PSRAM/NOR/SRAM.
Hope the mud isn't too thick in all that.
