I'm reading here: https://polymega.com/faq/
WILL EVERDRIVES, GAME GENIES AND MULTI-GAME CARTS WORK WITH POLYMEGA™?
Polymega™ does not support Game Genies or Everdrives.
How is that possible? What's there to "support"? An Everdrive is just a cartridge which looks to the console just like any cartridge, is it not? Is it actively (somehow) detecting this and blocking it, or what do they mean?
You're asking us to speculate about something that hasn't been released yet.
However, looking at the FAQ, it's clear that this is just a fancy Linux box with some emulators on it.
Processor: Intel Coffee Lake S Series Processor
Memory: 2GB DDR4 RAM
Polymega’s Modules use top tier emulators with low latency controller inputs.
Emulators: Legally licensed versions of Mednafen, Mesen, Kega Fusion, and MAME with additional bug fixes, CD BIOS development, and replaced YM2610 for Neo Geo CD from Playmaji.
From their marketing text and FAQ, it's clear they want you to copy your cartridges into the internal storage (or buy them from whatever partner they've rustled up) and play them from there.
It's a faster Ouya, in other words.
So how would it 'support' existing cartridges?
To play existing cartridges in an emulator, they first have to be dumped into RAM. To do this, the makers have to devise an interface that's compatible with the cartridges only to the extent that the contents of their ROM can be read. For Genesis games, this can be as simple as reading the mask ROM in one linear block. For Game Boy and Master System games, this involves negotiation with the mapper chip. This stage can be implemented relatively easily for most consoles.
To the end user, they put in a cart and then play the game. It's transparent to them: it feels like a console, and so they'd be satisfied. The cartridge slot is almost certainly not used at all during regular gameplay on this system.*
The important distinction is that the reading interface doesn't have to be particularly fast. To run a game directly from a cartridge requires accessing the data and acting upon it in real-time. To dump a cartridge can be done leisurely.
* Reading and writing the save RAM on a cart could be somewhat straightforward, though would need to be tested on a game-by-game basis since it's not homogeneous (at least on Genesis). Impressive if they bother. :)
How does being an emulator 'stop' Game Genies and Everdrives working?
Everdrives, Game Raccoons, etc. interface with external hardware like (micro/)SD cards themselves, and have quirks beyond the standard Nintendo/Sega interface that aren't emulated in most emulators - Flash memory bankswitching, etc. If makers of this Linux console haven't programmed support in for these, it doesn't exist. It doesn't come for free. And support in this case would be some kind of bidirectional software passthrough from the emulated Everdrive menu to the real cart...? Why bother?
If this was a hardware-based console, using FPGA or real chips, it could reproduce the exact bus interface and timing, you'd have compatibility with save RAM, enhancement chips, Game Boy Camera, real-time clocks and the like through that interface. The situation is very similar to "How does the Everdrive handle all the special chips and stuff that were put in cartridges?", except reversed: the ersatz console would have to correctly talk to all the real enhancement chips.
There'd be little reason for the makers of that Linux emulator-based console to support any of this, given their stated monetising approach.
It's much more likely they'll support a simulated Game Genie on their emulated console, since cheat support will come as standard in the emulator set they've taken, but that's all.
You seen to be confusing the concept of "works" and "supports".
"Supported" generally means that the vendor is willing to address any problems that arise.
Code I write may appear to "work" in certain situations, but that doesn't mean I must "support" those situations - generally because I lack the capacity to reproduce any problems that you may encounter, or haven't adequately tested that environment, and thus I cannot possibly say I "support" them.
Many NES-recreation consoles work by reading the entire contents of a cartridge on startup and then playing the copied data in an emulator, except that if the emulator recognizes actions which are supposed to write to non-volatile storage on a cartridge it may use the hardware to update the contents of the physically-installed cartridge.
A major limitation of this approach, and with software-based emulation in general, is that while a modern processor like an ARM can on average emulate 6502 instructions much faster than an actual 6502 could run them, it cannot achieve such performance with every individual operation. Generally, emulators will process a sequence of instructions that don't involve any display or sound updates much faster than a 6502, but then have to spend some time processing display updates without executing any instructions. This is fine if the emulator doesn't have to interact with actual hardware while this is going on, but not when using actual cartridges "live".
If the software on a cartridge would expect to send a command to the cartridge which would then allow the CPU to fetch and execute 59,552 bytes/frame of content that hasn't been read from the cartridge previously, the only way that would happen would be if the hardware can access bytes from the cartridge every 139.6 nanoseconds. If the emulator knew what data the cartridge would report, it might be able to process that data faster on average, and thus process all 59,552 bytes within a frame time even if it sometimes busy for a millisecond or so processing graphics or sound without emulating any instructions. If the emulator doesn't have the data available, however, its peak speed will be limited to the the 139ns/byte rate that cartridges are designed to support.
Some NES-recreation consoles use a different kind of chip called an FPGA. An FPGA ("field programmable gate array") is a device that overlaps two functional layers of circuitry: a collection of logic elements which are connected by grids of wires connected by switches, and some "programming" hardware which can selectively close the switches at various connection points. Unlike a CPU which one task (or, for a multi-core CPU, a few tasks) at a time, all parts of an FPGA can operate simultaneously. As a result, an FPGA-based recreation of the NES would be able to perform all individual operations at precisely the same speed as a real NES.
Although the Everdrive is a cartridge rather than a console, it uses an FPGA to recreate the behavior of a wide range of game cartridges with timings that match the original. Further, if there is a cartridge whose behavior isn't understood by the Everdrive today, its FPGA can be reconfigured to behave like the original by feeding it a different "fusemap" [set of information about which configuration switches to open and close]. Although it might be possible to design an emulator-based (non-FPGA) console to work with an Everdrive to load games whose physical behavior the emulator understands, it would have no way to accommodate a game whose cartridge behavior it didn't understand, but for which the Everdrive had a fuse map.
The Polymega works by dumping the cartridge into memory then running it from there. Everdrives have a menu system where you pick a game which then gets loaded from the SD card, then the Everdrive triggers a soft reset to the console which then starts the game. The Polymega can't work around that because all it ends up doing is dumping the Everdrive menu system into memory and it doesn't have a way to load the game from the SD card in the Everdrive.
If you can get hold of one of the original Bung Multi-Game Doctors that used flash cartridges where you can load up one game at a time into a flash cart, those work on the PolyMega.
https://picclick.com/BUNG-MAKKO-MGD2-Multi-Game-Doctor-2-I-O-Cable-Rare-132963582356.html
