EZ-Flash USA Forum

Another skin to add to the collection - This one's called Gnome (Until recently, I've been a KDE kind of guy).

Also included is the Photoshop file should you wish to make your own additions. It might also prove useful as a template for creating a preview image.

Download here



@Cory: If you're interested, there are some custom-made icons for GBALdr included in the above download. Feel free to use them as you see fit.

Thanks scrawl, i love this one.

Cory1492: Do you think CRC checking can increase time from 30sec to 5min ? x10 that's enormous !

I'm not a specialist at all, but i think there's another thing around that ...

Thank you scrawl, that skin is great.

I didn't expect GBA to work from it... AFAIK the GBA bios tries writing to the GBA bus on startup, which is why previous EZ products that use PSRAM to boot GBA close the RAM while leaving it's refresh active. BTW: I had to revert to using 0x8000 block writes, it seems to have been the cause of the problem, though I now use a memset to make sure any extra data is not written to NOR (0xFF is not written)

Excellent skin scrawl

Mbmax: some SD cards do not support 4 bit transfer mode, so I assume 1 bit is used in the driver for compatibility (also semi-explains hybrid mode and slow SD card problems). On top of that, CRC calculations are not ultra fast on a DS unless assembled by hand. On top of that, every command sent when CRC is enabled also has to have a CRC7. So data and command are CRC'd. There also seems to be quite a few waits in there, along with some other stuff. Most of the R4 driver is automated by it's internal chip, so the driver isn't talking to the SD card but to the R4... where the EZ5 seems to give a direct interface to the SD card (which should be faster if the driver is constructed better). At any rate, I now have SDIO documentation (with plenty of "do not copy" notices embedded) from a google I did yesterday, it outlines everything one might want to know about SD cards... so I'll see what can be done between that and the work that was done on the EZ4 driver.

Great cory ! And Scooby snacks to my favorite hunting dog, google
I know that you are pretty busy on GBALdr and other stuff, but if you can find something to optimize ez flash V flashing process on 3in1, that would be very cool
Thanks a lot man.

New and improved beta 6 nearly ready to go... packing it up in a second.

ds.gba will now boot in NDS mode via a vram bootloader (and I'm posting the source and demo bin to it, not only because it is under GPL and that I want to share it, but someone should probably point R4 at it so they can possibly fix their ds.gba bootcode since I suspect it's problem is similar to the stuff I commented out in mine that was causing the same problem about 1/2 an hour ago). Heretic writes to and boots nicely from gbaldr now, though I don't know if other stuff will have a problem.

If nothing else big and buggy comes up with it, I will dig in on the driver stuff after the weekend.

BTW: I still haven't been able to get it to crash even when loading the default files from a hidden directory on R4. All my tests have shown that libfat doesn't have a problem with hidden files/folders at all.

Thanks a lot! Now I can play my favorite game on this nice peace of equipment.

Yes, R4's boot code seems to be messed up. I hope they fix it soon. But just in case, you'd better contact them.

Hum i don't know what happen but just after flashing the urbz with beta6 (4min57) got a error telling me that GBALdr cound not find directory on microSD. Before that i have dumped 3in1 game that was in 3in1 and it tooks 6min.
I have launched the game and the urbz works well.
Rebooting my ez flash V and shell was gone ...
Here is what it's on my microSD card now



As i don't know if it's the beta release 6 that has done that or if my microSD is corrupted, don't forget to backup your data and remember it's beta testing here
Will format my microSD and try again to see if it's a bug.

My Ez flash V isn't defective, my other microSD card works nicely.
To be continued ...

Your microSD card got corrupted, maybe you didn't have enough space for a dump, so the file system got fucked up. Just format it.

yeah ! it's probably that, so i will retry exactly what i have done once again but with empty spaces on my microSD

EDIT :
ok, all went well after re-formated my microSD. I think it's time for me to fill some empty spaces

You shouldn't worry about that bug I reported, I can't get it to happen again as well. It was probably just something stupid I did or my card is getting corrupted.

Here we are ! Thanks Tadashi for the diagnostic

After filling my microSD and let only 32MB space left, i have started GBALdr in gbadump mode and strated to dump 3in1 content. This thing tooks years to accomplish (12min18) !
And you know what ? my microSD get corrupted.
So be aware in using gbadumping mode that your microSD got enough space left to dump more than 32MB

Cory1492: Do you think it's possible de check left space on microSD before launching gbadump ?
I wonder if it's when dump.gba is closed that TOC get corrupted ...

best skin you've made so far! kudos

Mbmax: I will have to do some digging to see if there is a way to get the SD card to tell it's space allotments (afaik there is no simple way provided by libfat, I'll ask in the libfat thread though and see if chishm knows). I should probably also add an abort key and some warnings to the dumping routine, as I found corruption on my card (unlinked chunks of various sizes all part of the 3in1 ROM space) during a dump using EZ5 where I simply shut the thing off early.

Don't worry cory, just insert some warning text before launch gbadumping tool
Ho well ! 2h45 am
I think it's really time for me to go to sleep

Tomorrow is another day ...