Why Is GBA Flashing Software So Flaky?

Discussion in 'GBA - Flashing Hardware and Software' started by Pedro_Lambrini, Feb 25, 2012.

Feb 25, 2012
  1. Pedro_Lambrini
    OP

    Member Pedro_Lambrini Gēmu Bōi Adobansu

    Joined:
    Feb 25, 2004
    Messages:
    293
    Country:
    United Kingdom
    I have an EZ-Flash IV, an M3 Lite and two EZFA's. The hardware seems pretty solid on all three designs so why is it that the software is so unstable for all three??

    I have used the software for all three cards on lots of PC's over the years and have never once had the software install and run without it randomly crashing or corrupting game ROM's during transfer.

    I don't even use the M3 Lite anymore as I was just so tired of the buggy software ruining my experience and the only way I can transfer games onto my EZ-Flash IV is one game at a time. The software crashes pretty much after every game transfer!

    So, my question for the experts is, as the title asks; Why is the software so bad? And I have a bonus question; How come nobody has made replacement software for at least one of these (at one time) high profile cards? I mean, there are a million and one ROM managers out there but nobody seems to have integrated file transfer into them let alone a stand-alone piece of stable transfer software...

    Any answers or suppositions welcome! :)
     
  2. FAST6191

    Reporter FAST6191 Techromancer

    pip
    Joined:
    Nov 21, 2005
    Messages:
    21,705
    Country:
    United Kingdom
    Although I would never call the software well written you seem to be having a worse time than most.

    What follows is largely opinion from pulling things apart and little snippets I have managed to gather over the years (being GBAtemp staff and being tied to a few things I have been tied to over the years opens a few doors) although I do not think you will find many that disagree.

    The early ones- they were little more than crude wrappers for the drivers to get it all done. Now I hate to speak ill of some of the coders as their efforts have provided me with a lot of enjoyment over the last many years but well ask Normmatt, smiths and co about the early acekard source releases vis a vis code quality (function declarations anywhere and everywhere, same with includes and other such things) and/or look up rants by programmers and such against self taught and outsourced programming as they often ring true here (do a DLL function export (they have nice names) on some of the EZ patching DLL files in general or better across versions or have a look at some of the hacks done to the programs over the years) as well as notice that the flash cart teams also suffered loss of staff (ability to manage/understand legacy code applies here as well). Also embedded ARM programming, embedded device programming (flash carts are fairly low level devices with interesting chips- most have a FPGA or CPLD and various types of memory chip that are all tied back to GBA code), low level driver programming and (good) GUI programming are quite different skills even if they do fall into the general umbrella of programming.

    The later ones- often they were built from the earlier software (EZ4client and EZManager (the EZ3 software) and EZClient (the EZ1/2 software) share so much in common it is not funny) and often had to manage some very crude hacks (see several of the earlier release threads- "works on M3 if you disable DMA, set y to ?, .......") and with GBA kind of an afterthought/no attention paid to any regressions that might have come about (and owing to the hackjob nature of things they did happen a bit).

    Replacements- there kind of was for some. Littlewriter is probably the most prominent but there were a handful of others (to say nothing of the efforts that went on for the GBAMP/M3 stuff by Chishm and co) and today there is also FAS1. The EZTeam once released the DS patching API for their patching DLL for the EZ4 to a person in one of the homebrew contests but it was never made truly public.

    Equally the basic GBA patching has been reverse engineered at least as far as making generic patches* (Trolleydave did a lot and integrated it into one of his programs- http://gbatemp.net/t...g-gba-patching/ has some base discussion) and implemented in a few other programs as well- for the ones made back when they were more or less done and left when the GBA still had a few things happening (EEPROM v126) and did not get updated to match. The trouble is you either make a wrapper for the DLL files or reverse engineer the GBA USB drivers and/or protocols which is a bit of a pain (made even more of a pain by the programmers then doing something resembling obfuscation in addition to the stuff above to it all to lessen the chances of clone makers).
    I have considered it on occasion and even fiddled with a few but I am not a great PC programmer as far as reverse engineering hardware interfaces go and frankly those that really care can usually set up a VM or something to run the software with far less effort than reverse engineering something (not to mention that once you learn the quirks you can usually do OK).

    *the GBA is pretty much capable of having this done (you find the nice string saying what it is and patch in a known distance from it) but finding someone that can run through what each opcode change means might be trickier.

    What I sometimes suspect is people are kind of waiting (even if they do not know it) for something like we see today in the n64 (and maybe some of the stuff in the 16 bit cards although there the mappers and extra chips situation changes things a bit) where the legacy stuff from "back in the day" is more or less forgotten in favour of modern chips doing all that modern chips can do (and frankly I would love to see a savelist style GBA cart a la the original EZ5 or maybe current supercards for DS stuff where they physically emulate the save types rather than patch them to use SRAM as nearly all GBA carts do). However with the GB/GBC a prime target we have not seen that much (most that is made being for little sound DJ and thus lacking proper save and rom handling which I admit is quite tricky to do properly) and aside from a few GBA cards made way back when we have not seen much there either. Floating around some of the Chinese cart maker sides of things there have been rumblings of just this (or at least a modern revisit) happening but nothing much has pushed forward (the EZTeam did a very small run of new EZ4s a year or so back and did ponder some source code but nothing truly new).

    Edit- confused littlewriter and little sound DJ in the last paragraph.
     
    1 person likes this.
  3. Pedro_Lambrini
    OP

    Member Pedro_Lambrini Gēmu Bōi Adobansu

    Joined:
    Feb 25, 2004
    Messages:
    293
    Country:
    United Kingdom
    Thanks for the full and informative reply. :) I really appreciate it.

    So, basically, the software tends to just be a collections of hacks and kludges...

    It's a damn shame that solid and user friendly (drag'n'drop) software wasn't possible but at least the hardware's good. :)

    I wonder if someone will get around to making a new cart sometime soon. It does seem like there's something in the air. What with the K-1 team and all the Ever Drive carts for loads of other systems floating around... *crosses fingers...*
     
  4. FAST6191

    Reporter FAST6191 Techromancer

    pip
    Joined:
    Nov 21, 2005
    Messages:
    21,705
    Country:
    United Kingdom
    First in the last paragraph I said littlewriter when I meant little sound DJ- http://www.littlesounddj.com/lsd/ (it is a very well liked audio Sequencer, sample player and such that emulators sometimes have trouble with) so apologies for that.

    I am probably confusing several things but I believe there was a cart that tapped into explorer via an extension and allowed you some semblance of drag and drop but it was no better than the clients and I am sure very bad things have happened when people done less silly things (install a random badly coded explorer extension/hook into arguably the main program used on a PC that has all the resilience of a wet biscuit at the best of times... yeah). Certainly no true drag and drop though.

    As for new cards I was very tempted to try my hand at such a thing and some of the discussions we had with EZFlash when they were playing with the 3 in 1 for multirom support ( http://ezflash.sosuke.com/viewtopic.php?f=16&t=12903 ) got me quite curious and Chinese electronics manufacturers doing small batches are getting better by the month but when it comes to electronics you could probably experience my best fish impression inside five minutes if you wanted. Still http://www.brolinembedded.se/projects/flashcart/ , http://www.dl9sec.de/gbacart/gbacart.htm and http://www.ziegler.desaign.de/GBA/gba.htm#homebrew%20flash%20cart as well as the usual http://nocash.emubase.de/gbatek.htm for those that rate their electronics skills higher than I rate mine.
     

Share This Page