Some Everdrive marketer is claiming EZflash ODE is 'emulation' and Everdrive is not...

Baggins

Well-Known Member
OP
Member
Joined
Jan 27, 2017
Messages
280
Trophies
0
Age
42
XP
257
Country
United States
Is there really that much of a difference? From my own research...

1. You can't emulate original hardware on the original hardware... That would be redundant, and take too much power that the original hardware doesn't have...

2. Both are using FPGA to hold the code needed to run the original cartridges as if they are those original cartridges, and represent all the original mappers.

3. The code used in FPGA is not terribly different in both flashcarts, and are based on original code from Nintendo and its companies, and some 3rd party game support.

4. the only emulation that happens in these is GBA/GBC emulation or NES emulation if one uses specific GBA coded emulators for example GOOMBA.
 

Titney

Well-Known Member
Member
Joined
Feb 1, 2014
Messages
116
Trophies
0
XP
1,090
Country
Might have just mixed it up with how GBA flashcards emulate GB/C games and GB/C carts run them natively, and then decided to run with it for marketing purposes.
 

Baggins

Well-Known Member
OP
Member
Joined
Jan 27, 2017
Messages
280
Trophies
0
Age
42
XP
257
Country
United States
Might have just mixed it up with how GBA flashcards emulate GB/C games and GB/C carts run them natively, and then decided to run with it for marketing purposes.
I was trying to explain that only NES, GBC, GB emulators, etc are 'emulated' not GBA, its redundant and impossible to emulate GBA within a GBA.... But he kept wanting to argue with me...

He also kept trying to claim that ODE had half the battery life on GBA... I explained I have both already, and that its not the case.... THat its more like a 2-3 hour difference between them but not half the time...

IT's the original omega that had half battery life compared to both...
 

EZ-Flash2

Official EZ-FLASH Stuff
Member
Joined
Jul 16, 2003
Messages
1,100
Trophies
0
XP
3,147
Country
China
That said, our RTC code is indeed emulated because the RTC chip used in the original GBA cassette has been discontinued and is not available, so we have to rely on software and another RTC chip to emulate its original protocol.
 
  • Like
Reactions: AkikoKumagara

Baggins

Well-Known Member
OP
Member
Joined
Jan 27, 2017
Messages
280
Trophies
0
Age
42
XP
257
Country
United States
That said, our RTC code is indeed emulated because the RTC chip used in the original GBA cassette has been discontinued and is not available, so we have to rely on software and another RTC chip to emulate its original protocol.

Do you mean 'emulated' in the sense of FPGA hardware "emulation" such as everdrive uses for each of the "mappers"? and by software do you mean the code being loaded into the FPGA?

Or is the Everdrive doing something 'different' that its not considered 'emulated'? Or is the reseller just trying to make Everdrive sound better than it actually is?

Do they function specifically differently?
 

FAST6191

Techromancer
Editorial Team
Joined
Nov 21, 2005
Messages
35,541
Trophies
2
Website
trastindustries.com
XP
25,463
Country
United Kingdom
Sounds like you are getting bogged down in terminology, and we could get further into the weeds if you want to and cover the emulation spectrum from simulation to hypervisors if really wanted to but I am not sure that would be too terribly helpful*.

On RTC (real time clock) then
Your basic RTC chip is nothing too terribly special. It will take power in (hence the need for its own battery for it is not always going to be in a GBA and does not get power when the GBA is off) and much like any other clock or watch add to a number stored within once per whatever timeframe it has. Upon being prodded properly the chip will spit out the current date (presumably by being programmed with an original date and then knowing how much has happened since then).
However you have the computing equivalent of year-month-day, day-month-year, dropped on a head as a baby month-day-year... plus the initial programming bit.
GBA games themselves would have handled this inside code so you are left with three options
1) Patch the game to speak a new RTC language (see also most GBA flash carts when it comes to saves)
2) Have something sit in the middle that will take in the original GBA commands and translate them to what the new chip expects, and translate its responses into the format the GBA games expect (if you are bored http://problemkaputt.de/gbatek.htm#gbacartrealtimeclockrtc ).
3) Recreate the chip (or at least something protocol compatible) in your FPGA but this is not going to happen for a flash cart (way too energy intensive to keep a FPGA burning power to mimic a RTC chip), might do for something with wall power though if you have another source of time like a network or is running on a PC (various emulators will pull the time from your PC to feed into the game).

On GB/GBC on GBA then if you wanted to get really technical there is a handful of carts that can use an even rarer device called the GB Bridge that will use the backwards compatible mode of the GBA, GBA SP and GB player to play GB/GBC games in their hardware backwards compatible mode.
https://www.gameboy-advance.net/flash_card/gb_bridge.htm

*though I will of course link two favourites in such discussions
https://trixter.oldskool.org/2015/04/07/8088-mph-we-break-all-your-emulators/
 
  • Like
Reactions: djedditt

Baggins

Well-Known Member
OP
Member
Joined
Jan 27, 2017
Messages
280
Trophies
0
Age
42
XP
257
Country
United States
Sounds like you are getting bogged down in terminology, and we could get further into the weeds if you want to and cover the emulation spectrum from simulation to hypervisors if really wanted to but I am not sure that would be too terribly helpful*.

On RTC (real time clock) then
Your basic RTC chip is nothing too terribly special. It will take power in (hence the need for its own battery for it is not always going to be in a GBA and does not get power when the GBA is off) and much like any other clock or watch add to a number stored within once per whatever timeframe it has. Upon being prodded properly the chip will spit out the current date (presumably by being programmed with an original date and then knowing how much has happened since then).
However you have the computing equivalent of year-month-day, day-month-year, dropped on a head as a baby month-day-year... plus the initial programming bit.
GBA games themselves would have handled this inside code so you are left with three options
1) Patch the game to speak a new RTC language (see also most GBA flash carts when it comes to saves)
2) Have something sit in the middle that will take in the original GBA commands and translate them to what the new chip expects, and translate its responses into the format the GBA games expect (if you are bored http://problemkaputt.de/gbatek.htm#gbacartrealtimeclockrtc ).
3) Recreate the chip (or at least something protocol compatible) in your FPGA but this is not going to happen for a flash cart (way too energy intensive to keep a FPGA burning power to mimic a RTC chip), might do for something with wall power though if you have another source of time like a network or is running on a PC (various emulators will pull the time from your PC to feed into the game).

On GB/GBC on GBA then if you wanted to get really technical there is a handful of carts that can use an even rarer device called the GB Bridge that will use the backwards compatible mode of the GBA, GBA SP and GB player to play GB/GBC games in their hardware backwards compatible mode.
https://www.gameboy-advance.net/flash_card/gb_bridge.htm

*though I will of course link two favourites in such discussions
https://trixter.oldskool.org/2015/04/07/8088-mph-we-break-all-your-emulators/


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?
 

zxr750j

Well-Known Member
Member
Joined
Sep 29, 2003
Messages
775
Trophies
0
Location
Utrecht
XP
2,236
Country
Netherlands
I think both companies have good solutions. I only have older EZ stuff but for me they work perfectly! In essence they are both emulating a game cartridge.

In my experience marketeers are the people who try to make their product sound better, they are not making a better product.
 

FAST6191

Techromancer
Editorial Team
Joined
Nov 21, 2005
Messages
35,541
Trophies
2
Website
trastindustries.com
XP
25,463
Country
United Kingdom
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:DR.
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.
 
  • Like
Reactions: hartleyshc

duwen

Old Man Yoshi
Member
Joined
Sep 6, 2013
Messages
2,761
Trophies
1
Location
Bullet Hell
Website
www.exophase.com
XP
3,365
Country
United Kingdom
In short; if you're playing the rom via any flashcart on the hardware it was intended for, it isn't being emulated (although extra features may be partial emulation via redirects, or flatout emulation in terms of running roms not native to the system).
 

Baggins

Well-Known Member
OP
Member
Joined
Jan 27, 2017
Messages
280
Trophies
0
Age
42
XP
257
Country
United States
In short; if you're playing the rom via any flashcart on the hardware it was intended for, it isn't being emulated (although extra features may be partial emulation via redirects, or flatout emulation in terms of running roms not native to the system).
Straight and to the point... Likely to please most players, and my understanding of things...

Not gonna fix those people who don't count "FPGA" as 'hardware', and want to just lump it all with, software vs hardware "Emulation" under the same category...

Like the people who claim "FPGA" on Analogue, Flashcarts, MISTER, etc, or for any use is "just emulation" without even acknowledging the differences between "emulating" 'software' (traditional emulators) vs "emulating" the physical 'hardware level'.... Which just conflating and confounding completely different methods into one confusing mess....
 
Last edited by Baggins,
General chit-chat
Help Users
  • No one is chatting at the moment.
    Psionic Roshambo @ Psionic Roshambo: Lol