How does the Everdrive handle all the special chips and stuff that were put in cartridges?

Question

An "Everdrive" is like a cartridge that looks just like a NES/SNES/N64/whatever cartridge, and is put into a real, original console. So you need the original hardware for it to work. And there is no emulation whatsoever. The cartridge actually contains a modern, large memory into which you can put ROM images, and then the NES (for example) is "fed" one of the ROMs that you pick from a menu, and from that point on, it's identical to having the actual cartridge; the NES thinks it's a real cartridge and the exact same electrons beam out from the TV, with zero artifacts of any kind since it's not being emulated, but rather "run for real".

At least, that's my understanding.

What I don't understand is how it the Everdrive handles all the special chips and stuff that they often/frequently put into the cartridges to extend them in various ways. And it's not just a small few games that did this. Many of the classics actually were extended internally with special hardware. Does it really have every single chip that any game ever used as hardware inside the Everdrive? Or does it actually emulate them somehow?

Answer 1

Does it really have every single chip that any game ever used as hardware inside the Everdrive? Or does it actually emulate them somehow?

The latter.

In the Super Everdrive and SD2SNES cartridges, the majority of the logic of the cartridge is performed by an FPGA. In photos of the boards, these will be usually labeled 'Altera' or 'Xilinx'.

By the term 'logic', I refer to receiving bus signals from the console, decoding these, and activating the appropriate ICs on the flashcart board to give the right response. It can also provide the menu, SD card I/O and other things.

An FPGA is a kind of reprogrammable chip that can take on almost any role (it can be a processor, a video chip, a sound chip, glue logic, or any combination of these). The function of the FPGA is defined by the 'firmware' you load into it. If the board is set up to do so, and the FPGA has the capacity, there's no reason why the FPGA can't be used to also simulate an expansion chipset.

On June 19 2018, an update was released for the SD2SNES that included Super FX chip emulation into its FPGA firmware.

This means that somebody has determined the range of possible inputs to the Super FX chip and the correct (or correct enough) outputs it would provide, and programmed this in a hardware description language. That description was then included in the SD2SNES FPGA firmware so that within the FPGA there is a 'virtual Super FX chip' that's performing the same calculations as a physical chip would and responding in the same way. A thorough description would include things like internal RAM, counters, buffers, timing, etc.

It would be possible to have a 2nd FPGA that's solely dedicated to the task of 'being' a Super FX chip, but I believe that the single FPGA on the SD2SNES board performs all the cartridge logic and Super FX simulation all 'wired up' appropriately within itself.

This means that, just like software emulation, if the author's understanding of the chip is not 100% correct, there may be slightly miscalculated polygon positions in Star Fox for example, sorry. :)

Answer 2

Most flashcarts (including the Everdrive) use an FPGA to emulate mappers, which is essentially a programmable ASIC -- a developer writes code in a hardware description language specifying the behavior of the chip. So yes, the mapper is emulated -- but at a lower level than if the entire NES was being emulated through software, since it can't "cheat" in ways that a software emulator can. For example, an FPGA implementing scanline interrupts on the NES must watch the VRAM bus for specific access patterns just like a real mapper would, whereas a software emulator can just directly read the internal state of the PPU to achieve the same effect.

Just like with a pure-software emulator, an FPGA implementation of a mapper can still have bugs, or other differences from the original hardware. However, emulating just a mapper is a lot easier than emulating an entire system. Most mappers are quite simple and well-documented, so there's not really a lot that could go wrong (besides maybe an occasional minute difference in timing, which would result in symptoms like "the glitchy line at the top of the status bar in SMB3 is one pixel shorter")

---

As a side note: I'm wondering what, specifically, have you found to be inaccurate with emulators? I don't have much experience with SNES or N64 emulation, but the best NES emulators are...just about perfect at this point. The CPU and PPU have been decapped, scanned, and reverse-engineered, and nearly every quirk of the hardware -- even really obscure ones -- is documented and implemented in emulators. If you use a high-quality emulator, the only difference you are likely to encounter is that pixels might look sharp instead of blurry -- but you can fix that with an NTSC filter.