4

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?

5
  • 3
    It would be a lot easier for us if you stuck with one account. You can contact Stack Exchange to merge your accounts using the [contact] link at the bottom of the page. (This won't stop you changing your username, but it will add a once-every-30-days limit.) – wizzwizz4 Oct 20 '20 at 6:15
  • 7
    I'm voting to leave this open because it is not opinion based. – OmarL Oct 20 '20 at 9:48
  • 3
    While I don't find this a particularly relevant question, it has attracted a very good answer. It is also short and to the point. – Mark Williams Oct 20 '20 at 19:38
  • 2
    @OmarLI'm voting to close because something that hasn't been made yet can't possibly be retro by definition. – scruss Oct 21 '20 at 14:04
  • 1
    @scruss on the contrary, something that hasn't been made can't be modern, so the only remaining focus of the question must be the difference between ROM cartridges and cheat devices, in so far as they pertain to a hypothetical emulation device. – Mark Williams Oct 27 '20 at 9:34
15

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.

3
  • A fancy Linux box with quite limited memory, I'd say... – UncleBod Oct 20 '20 at 5:24
  • 2
    @UncleBod For a single-purpose emulator console, 2GB is a surprisingly large amount of memory. You need gigabytes of memory for a general-purpose computer that can run a dozen browser tabs, several messaging programs, and a game simultaneously -- but if your hardware is designed only for a single purpose, the memory requirements are significantly less. – NobodyNada Oct 24 '20 at 17:19
  • 1
    Modern game consoles have ~6-8 GB of CPU memory, for running high-end AAA games (they have an additional ~10 GB of video memory, but emulators don't need or use much VRAM). Nintendo's SNES Classic only has 256 MB, and the Wii (which is more than powerful enough to emulate retro consoles) only has 24 MB of CPU memory. – NobodyNada Oct 24 '20 at 17:21
4

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.

2
  • 6
    Most likely, it wouldn't work. Many NES-imitator game consoles require the ability to read out the contents of a cart before they start trying to run the code thereon. Something like an Everdrive, however, would change what cartridge content is visible to the NES based upon a user's menu choices. If the console doesn't understand what factors may cause cart accesses made at different times to see different data, it would have no way of knowing when accesses would need to fetch data from an actual cartridge and which ones could simply yield a value cached from an earlier read. – supercat Oct 20 '20 at 17:34
  • 1
    Fair enough; I don't know these systems, so if it won't even "work" the "support" point is moot. I was addressing the general point, it being one to which I am professionally sensitive. – another-dave Oct 20 '20 at 22:28
2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.