Clone is a bad choice of words I suppose, I know that some of the main parts used in making the Carts are out of production, but that shouldn't mean there isn't a way around it. Im more then positive that there is a solution to the GBA Flash cart problem, the whole world doesn't stop trying to make something people want just because one freaking part is out of production. I'm sure demand has been low for these for quite some time and thats why no new GBA Carts have been bade. Therefore a new solution with no actual intention of making hardly any money, should do just fine. Even if it costs too much to be a marketable product, I'll still release all of the information I find, learn, and create.
Clone is a bad choice of words I suppose, I know that some of the main parts used in making the Carts are out of production, but that shouldn't mean there isn't a way around it. Im more then positive that there is a solution to the GBA Flash cart problem, the whole world doesn't stop trying to make something people want just because one freaking part is out of production. I'm sure demand has been low for these for quite some time and thats why no new GBA Carts have been bade. Therefore a new solution with no actual intention of making hardly any money, should do just fine. Even if it costs too much to be a marketable product, I'll still release all of the information I find, learn, and create.
Ok...however you want to call it. We have tried to find someone who would be able to redesign the EZ-IV with pcb, chips etc. - first single prototype card (without software, drivers etc) ~10.000 Euro - minimum production of 1.000 pcs to have a price about ~100 Euro....so nothing we could give to company in europe and i guess nothing for a chinese company to make a cheap clone. If they could do so, we would have EZ-IV clones already.
All the gba flashcards with internal memory like EZF-Advance, Flash2Advance (Ultra), EZ-Flash-II and III and all the other cards have been discontinued because parts were no longer available or too expensive.
If you can find a similar or better solution...ok...try it....
PS: you can be sure the EZ Team is not satisfied about the situation. They know that they still could sell a lot EZ-IV cards, if they were able to.....
I wish people would stop getting off the EZ-Flash IV. That thing easily is the worst flash cartridge I have ever used. That patching tool is a bad joke, if I got a dime every time that piece of shit software crashed on me during the last few days since I got mine I could buy a couple of GBA games now. Supercard may have slowdowns in a few games, but at least its tool could patch a couple of dozen ROMs without choking.
Well...please notice...the EZ-IV was released in 2005/2006 (now ~8 years ago) and was the last remaining card for the GBA/GBM/SP/DS. So if there would be a alternative, no one would talk about the ez-iv (maybe) but there is no alternative and Supercard was never a alternative. I'v sold this card too....for a long time...and it was bought like the "R4" cards, knowing the name....not able to play mario cart or any other game with a little bit of action because of (a lot) slowdowns. So what should i do with a good patch software and a bad card....that's my oppinion....at the moment we have no single gba card....don't know if this will change...
I have had some interesting conversations with those looking to clone EZ4s. It looks like we find ourselves at the start of when programmable chips and such like were starting to be protected. Not half the trouble it might be to clone a modern chip (early protection was not the best) but not a trivial matter either. Add this on top of difficulties in sourcing chips (the EZ4, despite being one of the last designs out there, is still now some 7 years old and was not exactly built with the latest parts back then) and I am not sure straight cloning is the way forward. Doubly so considering if you do clone you will likely be operating with a binary blob of CPLD code.
I have also long been contemplating a project to make a GBA flash cart as well -- unlike most other consoles there was nothing truly exotic* added to GBA carts if you ignore the RTC and tilt sensors ( http://nocash.emubase.de/gbatek.htm#gbacartridges or http://nocash.emubase.de/gbatek.htm#gbacartrealtimeclockrtc and keep scrolling).
*NES has mappers, SNES has extra chips, the GB/GBC has fairly extensive bankswitching setups aka MBC/memory bank controllers, the megadrive had a few things though was not as bad as the others mentioned (some bankswitching for a small handful of games and there was the multiple ports in stuff like micromachines), the N64 had the whole CIC thing and it kind of goes on. The only problem is the GBA cart is memory mapped and requires high speed memory (read basically not NAND, even modern NAND) but that problem is largely solved (use NOR or RAM of some form).
Basic homebrew NOR carts have been made
http://www.ziegler.desaign.de/GBA/gba.htm details a few and a bit more besides.
Multirom on NOR, assuming you can crack the save issue*, is just multiple pages and a reset command. I imagine it is not all that different for NAND-NOR and NAND-PSRAM arrangements (load, point and shoot).
*assuming you are patching to SRAM then the same page setting method you use for the NOR would work, however in practice I have seen various groups patch games to use a different location in the SRAM (it addresses quite a bit if it has to) and have them all nest.
I am not nearly a good enough electrical engineer to jump right into making a full on "EZ4 and then some" level flash cart though. To that end I would probably have to start with a basic single ROM NOR cart and iterate many times.
My one deviation from that would be that I do consider it almost vital to move away from SRAM patching and into emulation (FPGA driven most likely) of the save type -- it was already done by the early DS slot flash carts so doing it in 2013 would be even nicer. Whether you really want to emulate RTC or not I will leave for others to debate.
More curiously though I saw a thread where people were using the 3 in 1 (which is somewhat similar to the EZ4 which in turn is similar to the EZ3 before it) where they were cannibalising them for parts (more specifically the PSRAM). It might just have been someone seeking a pin for pin/protocol compatible thing but I do want to note it.
That said I am willing to help design cases, fiddle with software (I know GBA patching, GBA AP (ish or at least enough assembly to make myself useful) and the GBA hardware) and will offer to critique PCB designs if you want.
For an added bonus the GBA cart is visible in DS memory (you can access it from DS homebrew) and as long as you have something cable of multiboot (which is to say just find a GBA or an SP) then you also have the multiboot protocol to help develop things.
I have also long been contemplating a project to make a GBA flash cart as well -- unlike most other consoles there was nothing truly exotic* added to GBA carts if you ignore the RTC and tilt sensors ( http://nocash.emubase.de/gbatek.htm#gbacartridges or http://nocash.emubase.de/gbatek.htm#gbacartrealtimeclockrtc and keep scrolling).
*NES has mappers, SNES has extra chips, the GB/GBC has fairly extensive bankswitching setups aka MBC/memory bank controllers, the megadrive had a few things though was not as bad as the others mentioned (some bankswitching for a small handful of games and there was the multiple ports in stuff like micromachines), the N64 had the whole CIC thing and it kind of goes on. The only problem is the GBA cart is memory mapped and requires high speed memory (read basically not NAND, even modern NAND) but that problem is largely solved (use NOR or RAM of some form).
Basic homebrew NOR carts have been made
http://www.ziegler.desaign.de/GBA/gba.htm details a few and a bit more besides.
Multirom on NOR, assuming you can crack the save issue*, is just multiple pages and a reset command. I imagine it is not all that different for NAND-NOR and NAND-PSRAM arrangements (load, point and shoot).
*assuming you are patching to SRAM then the same page setting method you use for the NOR would work, however in practice I have seen various groups patch games to use a different location in the SRAM (it addresses quite a bit if it has to) and have them all nest.
I am not nearly a good enough electrical engineer to jump right into making a full on "EZ4 and then some" level flash cart though. To that end I would probably have to start with a basic single ROM NOR cart and iterate many times.
My one deviation from that would be that I do consider it almost vital to move away from SRAM patching and into emulation (FPGA driven most likely) of the save type -- it was already done by the early DS slot flash carts so doing it in 2013 would be even nicer. Whether you really want to emulate RTC or not I will leave for others to debate.
More curiously though I saw a thread where people were using the 3 in 1 (which is somewhat similar to the EZ4 which in turn is similar to the EZ3 before it) where they were cannibalising them for parts (more specifically the PSRAM). It might just have been someone seeking a pin for pin/protocol compatible thing but I do want to note it.
That said I am willing to help design cases, fiddle with software (I know GBA patching, GBA AP (ish or at least enough assembly to make myself useful) and the GBA hardware) and will offer to critique PCB designs if you want.
For an added bonus the GBA cart is visible in DS memory (you can access it from DS homebrew) and as long as you have something cable of multiboot (which is to say just find a GBA or an SP) then you also have the multiboot protocol to help develop things.
Doesn't change the fact that it's plain *bad*. There were much better flash cartridges during the lifetime of the GBA, but it looks like this trashbag of a cart will be remembered as the GBA flashcart to have when you read through this forum. Yes, it's a damn travesty that no GBA flashcartridge is being manufactured anymore, but for this cartridge I can only say good riddance.
I'm just a bit bitter that I bought into the current hype even though I should've known better. And, btw, everyone whining about not getting this cart anymore: there's plenty of supply on AliExpress.
For what it is worth as long as you are not seeking soft reset patches or trying to use the cheats the basic save stuff was reverse engineered quite some time ago.
That said though there are certainly things I avoid doing with the EZ4 software (alter soft reset keys by hand, best to feed it uncompressed ROM images, best to have some RAM on the machine you are using if you are patching DS games, have something mapped to the D drive, max 80 games per folder on the EZ4), I have never had that many problems actually getting things done. Still basic SRAM patches were reverse engineered (though they are not complex things) and implemented elsewhere, http://gbatemp.net/threads/dsfcc-flashcart-manager-for-windows.106054/ probably being one of the more notable here.
No argument the EZ4 is but a shadow of better things we had in the GBA era (give or take the option to use removable memory) but the hardware is there and it works. Coax the software properly and you can do what you need for all but those two games (give or take how you view RTC patching and tilt patching, in that case it works for all but about 10 games).
- Joined
- Nov 6, 2005
- Messages
- 3,100
- Trophies
- 0
- Age
- 35
- Location
- Foggy California
- Website
- heranbago.com
- XP
- 1,187
- Country
EZ 3-in-1s were also popular for a bit for making reproduction cartridges. Of course it's not a real repro but functionally identical.
Interesting, do you know if some kind of public documentation on those EZ-Flash SRAM patches exists?
EDIT:
I assume they're different from regular EEPROM -> SRAM patches?
The ones to do multi games on the NOR might be different (from earlier on rather than set pages all the time they would just add things to addresses -- the data is still the same, it just reads and writes from somewhere further away) and the instructions they ultimately use might differ a tiny bit they are compatible both with the likes of GBATA patching and their patches work for games outside the EZ line.
Generally though the patches went roughly like
Do a search in the game for SRAM, EEPROM or Flash (all in ASCII) and if it finds one of those you have your type of save. Following that (and where the likes of VBA stumbled and thus saw you set save types manually) is a number to indicate the sub type from there. There is no header value or simple assembly trick to find this sadly.
From here two reasonably short (probably less than 20 bytes each) sections were patched. There are differences between the sub types as to where these two patches fall but the patches themselves were identical for the types.
Being a solved problem and easily implemented where necessary I have thus far not bothered to truly document the patches at instruction level though being so short and with http://nocash.emubase.de/gbatek.htm#gbacartbackupids I doubt it would take awfully long*.
Certain groups had ceased support of their devices by the time some of the later save types came into play (Eeprom v126 probably being the most notable of these events and also the last) but they should all be able to work with everything if you can force through a patched game. All save the supercards and their clones which tended to need speed patches and other things.
*others reading and continuing on from the "what if we were to build our own flash cart" conversation from earlier this searching for the ASCII type marker is hard on the little 16MHz GBA ARM7 hence why most things are patched on PC first. No ROM hack should ever touch it (the GBA is all memory mapped with no file system so it should not be moved either) or the header* so a complete lookup table driven by the header/serials might work well.
*a few very early releases touched the header for reasons unknown. This should not be a problem as those ROMs I doubt you could even find today. I do not doubt some would be hacker in the future might change the header for some reason but that is a problem solved easily enough.
Generally though the patches went roughly like
Do a search in the game for SRAM, EEPROM or Flash (all in ASCII) and if it finds one of those you have your type of save. Following that (and where the likes of VBA stumbled and thus saw you set save types manually) is a number to indicate the sub type from there. There is no header value or simple assembly trick to find this sadly.
From here two reasonably short (probably less than 20 bytes each) sections were patched. There are differences between the sub types as to where these two patches fall but the patches themselves were identical for the types.
Being a solved problem and easily implemented where necessary I have thus far not bothered to truly document the patches at instruction level though being so short and with http://nocash.emubase.de/gbatek.htm#gbacartbackupids I doubt it would take awfully long*.
Certain groups had ceased support of their devices by the time some of the later save types came into play (Eeprom v126 probably being the most notable of these events and also the last) but they should all be able to work with everything if you can force through a patched game. All save the supercards and their clones which tended to need speed patches and other things.
*others reading and continuing on from the "what if we were to build our own flash cart" conversation from earlier this searching for the ASCII type marker is hard on the little 16MHz GBA ARM7 hence why most things are patched on PC first. No ROM hack should ever touch it (the GBA is all memory mapped with no file system so it should not be moved either) or the header* so a complete lookup table driven by the header/serials might work well.
*a few very early releases touched the header for reasons unknown. This should not be a problem as those ROMs I doubt you could even find today. I do not doubt some would be hacker in the future might change the header for some reason but that is a problem solved easily enough.
Oh, in case I need them I assume I have them on HDD somewhere.
Thanks for the explanation, I just thought maybe the magic bytes for the EZ-Flash patches were documented somewhere, like most EEPROM patches are documented in the Ucon64 source. You don't have anything handy there, do you?
I posted this before but:
The epm240T100C5n CPLD chip inside is still being made, along with the Mitsubishi m6mgt321 nor flash chip. The fuijitsu 84SF6H6H6L2-70 MCP flash chip on the other hand, i seem to have alot of trouble finding available quantities.
Pretty much all the parts for the Ez-flash IV are out there, but 1 of these chips is no longer being made and there is no stock available for em.
Oh, in case I need them I assume I have them on HDD somewhere.
The releases I speak of were some not that well distributed Japanese releases, indeed I have having a hard time finding them on the few releases databases that still remain.
I believe it is functionally identical to one or more of the types of SRAM actually used in the console (there are a handful of SRAM games you can run unpatched should you provide the save file for the loader to deal with, though I still suggest patching unless you know you do not need to). To that end patching is usually just a matter of having the correct write enable bytes (hence the relatively small and relatively simple patches). For that reason I have not bothered to go in depth here but you might find something in some of the work that was done to dodge issues with homebrew saving, Kuwanger's python script from http://ezflash.sosuke.com/viewtopic.php?f=12&t=12660 maybe doing something here.
I am not sure what good it might do either but you may also like the old EZ3 SDK* though it was more concerned with everything that is not SRAM ( http://ezflash.sosuke.com/viewtopic.php?f=2&t=150 though the direct link will be something like http://ezflash.sosuke.com/files/sdkv1.1.zip , I should have stuck it up on filetrip somewhere as well).
*it is a less than brilliant SDK as far as such things go -- built for the old AGB toolchains and containing many a binary blob to include.
Had we full sources then absolutely. As you would first have to dump and crack/decrypt the CPLD code you are then faced with a binary blob from the CPLD (not a type of assembly, such as it can be deemed, that many know). You might be able to find one of identical protocol (pin for pin might be better but worked around easily enough) or add further logic to translate reads (something I might have cause to worry about the latency of) but to use an expression of my grandmother it is liking robbing Peter to pay Paul.
This is some good information, some of it I didn't know. Im not truly an electrical engineer yet, I just have all the math classes associated with one, hold for physics III, Im taking that next semester. But I was hoping with some help from http://www.dl9sec.de/gbacart/gbacart.htm, and the few GBA flashcarts I have bought recently, that maybe I could rig something together with other students around campus.
D
Deleted-236924
Guest
I wish at least the EZ-Flash III was still available somewhere.
But what I wanted the most was an EFA-Linker or an EZF-Advance.
As far as I'm aware, those three supported RTC and all three save types (SRAM, EEPROM and Flash), so they're fuctionally similar.
The advantage of the EZ-Flash IV over those three is that it uses removable storage; you aren't limited to 256Mb or 512Mb or anything, you can have up to 2GB (with a capital B) of storage which is very large considering the largest GBA roms are 32MB.
It sadly doesn't natively support every save type, but from experience, the SRAM patching worked perfectly and was only a very small nuisance and it would even read save files from non-SRAM patched roms properly.
It doesn't support RTC or any of the special hardware, and nothing can really replace that; but it is only a problem if you plan on playing many games that rely on such hardware.
The cartridge relying on battery-backed SRAM to save is annoying as well, but the in-game Soft Reset to menu button combination lets you reset to the flashcard's main menu, which would automatically copy the save file from SRAM to memory card, so you would still be able to save and not lose your save files even if the internal battery had run dry. (This is the reason why I prefer the EZ-Flash over every other flashcart that was still available.)
As far as I am aware no GBA flash cart emulated the save types a la the likes of the earlier EZ5s on the DS and all were patched to SRAM.
D
Deleted-236924
Guest
At the time all that would have meant is the sub types which had new ones that occasionally cropped up were supported in software. If you go to something like http://bubbz.pocketheaven.com/?system=gba§ion=patch you will see a lot of the patches that were made for the unsupported cards. Today the Boktai, Pokemon, any that say "Motion Sensor Fix" and Dragon Ball Z ones are the only ones that are useful at all in the patches section.
Similar threads
-
Xdqwerty
what are you looking at?
-
-
-
-
-
-
-
-
A @ Aglae Pheryl:Is anyone familiar with former forum opg.life ? I missed the transition to the new forum over the week end (was scuba diving in the sticks with no internet connection). If anyone in touch with any members please pm me.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@
AncientBoi:
And a part of my immediate family passed also. Sending my good suit to the cleaners for the funeral Saturday -
-
-
(
