First things first this is just an idea I have been toying with for a while and I have way to many projects on the go to devote much time to this right now. I just thought I might start some discussion and write up what I know/think. Background/introduction. The GBA is near enough dead and despite the greatness that is the DS the GBA library is not to be overlooked. Unknown 1.1 versions and 2 in 1 packs aside I doubt we will ever see another good game released and the rom hacking community has taken to the GBA is quite a big way too. Now GBA roms most people use either their own client (EZ4Client/M3/G6 stuff) or GBATA to patch roms, the main problem with some of these is the limited scope/ability (despite having stuff for RTC in the DLL responsible (which contains vast tracts of code seemingly copied and pasted from EZ1/2/3 patching routines for the curious) the EZ4 Client app does not touch it). Others advocate the use of stuff like GBATA in place of the "official" apps. From conversations with moleDJ (creator of the now defunct EZ4 Client plus: a .net rom manager with EZ4 patching capabilities) way back as well as my own testing I recall 90% of patching (as far as the EZ4 and now 3 in 1 is concerned) is merely a couple of bytes changed in the header and later in the binary (the stuff concerning the save). Rather than implement EZ4 Client's/GBATA's functions moleDJ remade them into what was essentially his own app. Sadly though the source was never obtained for this. the "tech" stuff. Not so much detail here right now as that is one of the things required. Some more detail the GBA uses 4 saving types: SRAM, Flash, EEPROM and, whilst not technically a save type, none/password. The changes made to roms being patched broadly fall into those 4 categories (the exceptions being stuff like EEPROM detection (examples: classic nes and dragon ball games), motion/light sensor (warioware and boktai, and RTC (pokemon)) with it being relatively simple stuff. The few minor variations that have an effect like EEPROM v124 (mainly 256Mbit titles) should not be difficult to take of. The project is probably easier to pull off in a "clean room" style reverse engineering project (patch files and binary compare) rather than busting out the disassemblers/emulators/bus monitors/memory viewers (save perhaps for the rom that has been patched and some confirmation is desired). As usual GBAtek is possibly the most useful document in existence (at least until this project is written up). http://nocash.emubase.de/gbatek.htm Some potential problems/points for discussion: should "odd" rom support be added (personally I favour "odd" patches being integrated into a DLL or similar) how might they be detected: hashing works but rom hacks and trimming screw that one up not to mention hashes probably need a separate list (which from experience I can tell you will get large especially as something better than CRC32 is needed: and will have to be generated (unless no-intro have a full md5 library). The GBA is effectively defunct though so a list could conceivably be a one time thing. Header detection: a suitable amount of header data will have to be used (the name/serial alone can mess up in the case of v1.1 titles (which a good number of popular games got)) and once again a list may be needed. Naming: input=output or similar is OK but potentially undesirable, the header does not contain anything good like it does on the DS and we are left with the list option again. What to code it in: I will not hide the fact that a cross platform (i.e. non windows) GBA patcher is sorely needed (WINE just about cuts it for some) and is one of the main reasons for suggesting this project. Performance is not really an issue (any language that takes more than 10 seconds to do a very minor bit of file i/o (not all can bear in mind) like this does not warrant my attention), the question then is do many binaries exist or are the users to be restricted to/bound by a framework (both have their merits and disadvantages: I feel a simple project like this could quite easily do both however). I would love a GBA/DS code patcher a la the recently released/ported DS code DLDI patcher (DLDI is for both GBA and DS remember) but that is getting well ahead of the game (the ultimate goal could even be GBA autopatching which some, perhaps unjustifiably, desire). GUI/input issues are somewhat of a when all is said and done thing: whatever happens command line parsing/input is a real must for me (I do more and more at batch file/command line level, it is also far easier to chain apps together (decompression mainly) this way and make a batch file). I however would like to consider myself a somewhat advanced computer user, others really prefer a GUI. Documentation: I tend to document all that I do and would like that to continue here, both the effects and any "lists" that are used. I doubt very much any potential contributors will have a problem with this but I am putting it up anyway (I would personally go for a public domain release of the source as well but we shall see there) Other patches/support: comes under my command line request but do PAR2 files get supported (I have been using a few of these lately rather than messing with "clean rom patches"), do IPS, BSdiff and XDelta get a look in as well? (all 4 items are extensively documented and/or have ports/source to most major operating systems). Are these DLL/external app based or built in? Maybe a subject for later releases but should in game reset be added (there are several tools and apps that be used to check), should sleep be added (Dwedit recently released an app for it) or even cheats (I dare say they are very much desired and mondayz created a nice base in GABSharky). It is now two in the morning so I am out. I may think of some more stuff and realise what a mess of typos this is in the morning but this is just to get it out there.