I'm not really concerned about the terms, but the marketer seemed to be, in as much that he claimed that Everdrive GBA x5 was actual 'hardware', and that Ezflash is "emulation".... and that is why Everdrive was 'so much better'.... despite having less capabilities...
My point is are they really any "functionaly" different or are they very different than how they go about running GBA games? Or is he just exaggerating one to try to make it sound "better" than the other? And they do roughly the same thing using FPGA to run original cartridge code?
All flash cartridges on the GBA for GBA stuff (again see the oddity for GB/GBC games, and actual GB/GBC flash cartridges with what those work with of course) work by sitting on the GBA cart pins, when the GBA code forms a request for a given section of code it responds with the corresponding section from the ROM.
Some did this slower than was ideal (see supercard and clones thereof), some took other paths to do it (NOR and PSRAM being the big two traditional options, the Omega on up and everdrives seemingly going for faster RAM still) and said other paths have quirks at times (slow to write NOR, expensive NOR so sometimes smaller, first in last out of NOR...).
The differences come in the saves and extras.
The GBA hardware is quite basic. Traditionally there were also means to expand cartridge based consoles by stapling more chips onto the cartridge itself; NES mappers, SNES special chips, arguably the N64 main chips but it also saw real time clock, megadrive had extra control ports at times and today has fun things with flash carts and what they can do as far as mimicking hardware expansions, gameboy memory bank controllers/mbcs, DS bluetooth, DS pokewalker IR, DS ismart MM/supercard dstwo/iplayer/dsx to a lesser extent/various flash cart DLDI write speed boosts, various things that went in the DS GBA slot, DSserial...
This is vastly more limited in scope on the GBA and is pretty much
https://gbatemp.net/threads/buying-a-gba-flash-cart-in-2013.341203/page-18#post-4756995 or indeed
http://problemkaputt.de/gbatek.htm#gbacartridges
Aka real time clock for pokemon and a couple of others, ereader, solar sensor for boktai, tilt sensor for warioware and yoshi and all the rest of those things that connected to carts or maybe the link port (technically a different matter). The closest to any kind of expansion as per traditional NES and GB/GBC bankswitching came very late in the day in those handful of GBA carts that featured whole films (as opposed to most GBA videos that were 30 minutes of cartoon stuffed into 32 megs of ROM)
https://mgba.io/2015/10/20/dumping-the-undumped/ for more on that, and actually
https://mgba.io/tag/debugging/ has some really good articles on a few of the rest of tricky things.
Saves also fall into this. The traditional GBA flash cart instead of mimicking what the original save did instead patched the ROM to speak the same type of save as the GBA flash cart itself (usually a type of SRAM). This was trivially done on PC (you literally search for an ASCII string, depending upon which of three types and a few sub types you change two small sections of code that are the same each time really. Earlier versions of VBA stopped at the three ASCII strings point which is why you might have had to set a save type for pokemon at one point), later done on the console itself (see the updates to the EZ4 that came way after the fact for that one).
The Omega and Everdrive (not 100% on that) took a different path. Here much like the ROM stuff from several paragraphs ago they instead mimic the save type at protocol level in their programmable chips. That is to say the games speak their original SRAM/Flash/EEPROM protocol and the cart responds accordingly. If we are going way into the weeds then it is noted some of the reproduction games have saves stored effectively inside a writeable area of the ROM as it works out easier for the chips they used. This would be a type of emulation, but not one that counts in the normal emulation or hardware debate like we see for say PC emulators vs mod chip/flash cart sporting consoles where PC emulators might be missing aspects or stuff like
https://arstechnica.com/gaming/2011...-3ghz-quest-to-build-a-perfect-snes-emulator/
Extra features beyond this are also software tricks and any flash cart (aside from rumble that needs a physical motor) or emulator user could hack it into things if they wanted, give or take some issues with savestates and no place to store it. Savestates are a dump of memory so halt the game, pour the contents of RAM and registers into a file (say a chunk of save or extra memory the flash cart provides) and restore it later, soft reset is much the same as cheats, cheats are fairly classic in this,
Emulation on hardware itself also gets blurry around the edges. You met GB/GBC on the GBA which technically has the hardware to do it onboard (though inaccessible for many purposes), but it gets more fun on the likes of the Wii with the various means of running gamecube code there as you are technically running on hardware, but also not and have some perks because of that. Similar story for some of the DS ROMs on DSi and 3ds stuff hence the little perks like cheats and widescreen. The supercard DSTwo/ISMM/iplayer running GBA on DS cartridges would be another different aspect in this.
I believe I am also obliged to say FPGAs are not magic. You can cut corners writing FPGA code if you like and suffer the same issues as emulation, or gain some perks of it if you want to go that way (see various emulator only hacks for SNES games). It allows you the potential to make a bug for bug compatible recreation down at transistor level far more easily than the absolute system grinder that is that 6502 emulator talk I linked in the previous post. If you want to go further in that world probably start with Spice, as in the electrical engineering simulation method.
TL
R.
https://gbatemp.net/threads/buying-a-gba-flash-cart-in-2013.341203/page-18#post-4756995
That was my 2013 list of fixes usually years older still (typically around the time of the game launch bar a few notable exceptions and later superior alternatives) for those handful of games that trouble GBA flash carts. Any flash cart that is not a supercard and can fit the game or hack you want* will run it as it would have run coming out of the factory.
*amusingly the rumble patches we were discussing in other threads would be an exception here in being things designed not to work on original hardware, and I did technically see a hack in progress once that did something wrong with compression and only booted on some emulators but no flash carts or accurate emulators, sorted by using the proper compression. Nothing like the ZNES only patches, or N64 texture replacement stuff though at present.
