EZ-Flash USA Forum

It's a lot to ask, but any chance you could try with Minish Cap and a completely fresh save? It is a game I have which I know for a fact EZ's internal bankswitching code does not go to the page 16 (where the pokemon I tried earlier does so even from the GBA menu on the prototype cart, when apparently it should not). So basically if I run it with the -16 version I gave you, I will enter an entirely different save than if I use the GBA menu or R4's boot menu (just like it does with my EZV currently).

Wonder how many of the prototypes went out to people who are going to be using them... it would be nice if there was a simple way to tell the difference.

Tested it. Made a fresh save (starting via gbaldr menu), the save could be seen from R4's menu and DS's menu as well. Works great.

Prototype unit? arg, well that explains the goofy saves I was reporting with copytest and I'm still getting them with gbaldr (haven't tried beta 2 yet, just woke up) I'll be happy to also test any special versions as well to get it worked out. Oh and yes, my _system_ folder is hidden, I use DSO somewhat regularly and I got tired of seeing it.

Also, glad I could help with tracking down bugs and thanks for the mention on the version history, if it wasn't for the hard work people like you and bigboss put into projects like this, who knows where we'd be.

Thank you cory1492 and BigBoss for bringing us this great program. And thanks to the EZ-Flash team for making this terrific product.

Is there any possibility that you will present us a link to the "beta3-16" version of this program? I'm having the same saving issue. My save initially only showed up if I used the GBALdr program to boot into GBA mode, but after I reached a new save point it seems the new save is only showing up if I boot to GBA mode through the DS menu or through R4DS' menu. Booting via the GBALdr program leaves me with my first save.

I assume I have the same production sample as your Cory, seeing as we received the triple-pack at the same time.

Yell out if you need any third-party testing done.

beta 3 uploaded on the first post, I wrote a routine which should detect whether you have a prototype or not and adjust automatically for it. It envolves backing up 8 bytes of SRAM, writing test data to it, and then switching it to see where the test data is, and restoring the original data once it is found.

It worked reliably for my unit, but as I don't have the retail version here to try on... at any rate, a special debug version is also included (with only this release) which will tell you the results of the check (regular debug version doesn't check for 3in1 and should never write to 3in1 at all) but most other functionality is disabled besides SRAM init and the prototype check.

Let me know if the fix works properly for the retail units (it should now always boot to the proper save area, and retail units should also be directly compatible with EZV now). Note also the change in the readme, if you are importing saves and have a retail unit, you should try 64k first.

There shouldn't be many who have and will be using the prototypes, so if it finds a retail unit I will slim down the backup save file size to 256K and remove the import dialog. It's on the to do list at any rate (you will be able to use it to convert 320K saves to 256K as well, simply by loading the save and directly writing it back to the same file).

Ok turns out I have a retail unit, and beta 3 fixes all of the save wackiness that I was having, confirmed with fresh save files on FF6, Metroid ZM, and Minish Cap. Awesome job! I was happy with just copytest and using the workaround, but things just keep getting better and better beyond my expectations and I'm glad I went with the 3in1 over more expensive options. Keep up the great work!

Hey ! that's why my pcb was a little different then pictures taken by scrawl.


It seems that there is crossed leg on left Altera MAX II chip



Will try protochek to see if it correctly detect my retail 3in1 ...

EDIT : Ok. Mine is a retail but that's not a surprise

EDIT 2 : So here is my first attempt on GBALdr 01beta3
URBZ of course (32mB), and as copytest the game does not have sprites
I noticed an error at the end of sram copy on touch screen a red text told that 3in1 is not found ?!
But all process seems to go fine.
The same game flashed with ev 5 kernel has sprites, that's very strange no ?

My old EZ4 saves seem to work perfectly if I import them at 64k. Thank you cory!

This might be a stupid question, but if I want a GBA save in the size it originally was for use with VBA or something, I just take the 320 kB savefile and, for example if the save originally was 32 kB, extract the 64-96 kB part of the file?

It appears I have the prototype unit. PCB rev. EZ5C1 to be precise.

If anyone is willing to purchase this historic piece of DS memorabilia, it's yours for the bargain sum of $100.

Seriously though, I wonder if the difference lies in the soft-hardware or physical hardware. When/if a firmware update is released for the triple-pack, they might all become the same.

Here's a pedantic request for a future release: When highlighting a folder, could the "select bar" extend all the way across the screen, similar to highlighting a file? I know, I can't help it, I'm a Graphic Designer

other: you got it exactly. So long as you don't have a prototype, that is where your save will be. If you do have a prototype, it seems game dependent as to where the save will wind up (sometimes 0k, sometimes 64k).

scrawl: I suppose you want it under the icons too... I just did it the way I like it, so it only highlights areas with possibly relevant information (though I agree, it does kinda look crappy). I was actually considering putting a selected line bitmap instead of the hilight bar... but it was something I was waiting to work out once I got to putting a side scroll bar in there (for future touchscreen stuff as well, hopefully). How about font shadow? I was considering a 1 over 1 down shadow of the text as well, though this stuff is all essentially cosmetic.

BTW: technically there is no way to update the 3in1 to retail version, at least not without some keys and an external programmer... and even then they may have blown fuses at the factory to prevent just that. So the difference lies in the FPGA programming (sorta software).

Mbmax: sounds like a buffer overflowed, I will have to check carefully for the problem. If I can reproduce it (urbz) I'll see what I can do to fix it.
edit:/ reproduced the problem exactly, did dumps from EZ5 and from GBALdr writes, gbaldr is writing 4 bytes incorrectly, 2 at offset 0x0AAA and 2 at offset 0x2AAA

Nothing fancy, but this will dump 32MB data directly from the GBA cart to SD card (:/DUMP.GBA) without using any EZ commands, to give something to rawly hex compare to original file with. It simply prints a '.' onscreen every 512 bytes; it takes less than 30sec to dump entire 3in1 32MB for me.
gbadump.zip
I suspect every game has the same values borked... I will see a bit later.

Well if someone hate sprites in URBZ, that's the way to disabled them
Nice find cory1492


Ok, i've just tested flashing 8MB and 16MB games with GBALdr. GBAdumped them (i love this tool ) and hex compared with games on microSD. They are identical.
Will try another 32MB game than URBZ to see if corruption arrives just with 32MB games ...

EDIT : Well with Happy feet, Hexcmp find me 3 differences : 2 at offset 0x0AAA, 2 at offset 0x2AAA and 2 at 0x1FE0000
So it may confirm that this bug appear just when we write 32MB game to 3in1.

I believe consistency is the key to good aesthetics in a UI. I didn't notice the highlight bar missing under the icons because it was consistently missing. I felt the highlighted folders just felt a little incomplete with the highlight bar ending 3/4 before the end.

For one pixel text, I'm personally not a fan of drop shadows. They reduce legibility, especially on condensed fonts. I don't think anyone will miss it.

As you say, this is all cosmetic - personally I would prefer you to get some sleep than make the change

In regards to all the comments about prototype vs retail triple-packs, I'm not 100% following the differences. With the prototype, GBA saves are stored at different offsets in RAM, hence the reason you backup the whole chip while with retail, you only backup 0-250k? But beta3 GBALdr will handle all of this automatically now?

The retail unit has SRAM set to page 16 (64k) at bootup, where the prototype has it set to page 0 (0k). It's not a big deal, it is simply that the some games will stow their saves at 0k and some at 64k depending on the patch (seems certain types of memory patches swap to page 16 off the get go, most smaller and SRAM ones don't seem to). At any rate, it was a critical bit of info to make the prototype and retail units both work the same from both the DS menu and GBALdr - and to resolve the conflicting information I was reading with copyTest. (edit:/ previous to beta 4, all units backed up 64k + 256k, on retail units this meant the file was padded by 64k of unused data)

Any rate, I had a good sleep... the cosmetic change you wanted took about 6 minutes (including testing and extending the hilight to under the icon as well), the flash writing issue for Urbz is now fixed (I found the problem), not to mention I integrated gbadumper so you can dump 3in1 (and possibly other cards, but it will always try to dump 32M) if you (quickly) hold R while after hitting go in whatever cards menu you launched from, and retail units *should* now only backup 256K for the save files (again, I don't have one yet to test with to be certain it is working properly). Just have to pack it and upload, so I should be updating the first post with Beta4 in a few minutes.

Thanks for all your help everyone - there are some things it just doesn't occur to me to test

The saves on my retail unit with beta 4 are coming out as only 192k, they still work fine though.

Oh and something minor, but sticks out on a few of my skins, the progress bar has no color setting in the ini for it's boarder, it stays white no matter what I change. It's not a big thing but just looks a little weird when one thing doesn't match. It's not important to get fixed soon anyway.