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?


2 Answers 2


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. :)

  • 12
    An FPGA doesn't simulate hardware, it recreates hardware, and does it much more accurately than a software simulation. Commented Sep 20, 2020 at 3:05
  • 3
    Cranky: Become rich, and pay to get the Super FX and its comrades decapped and analysed so that perfect software and hardware implementations can be written. :)
    – knol
    Commented Sep 20, 2020 at 3:15
  • 19
    @CrankyKong - If the emulation is so close to perfect that you haven't noticed so far - do you even care? This sounds like some kind of obsession. :/
    – Vilx-
    Commented Sep 20, 2020 at 16:29
  • 4
    @snips-n-snails it's kinda both, when you put an AND gate on an FPGA, it doesn't actually create an AND gate, it reconfigures a LUT to act like an AND gate. It is sensible to say that the LUT emulates the gate. Commented Sep 21, 2020 at 8:08
  • 3
    @snips-n-snails: And further to what user253751 said, its accuracy is (as with a software emulation) limited by the understanding of whoever's programming it: at the end of the day, the HDL that determines the FPGA's behaviour is software, just as an emulator is. (Which is not to say it's pointless - an FPGA can emulate things perfectly, including timing, glitches etc that software may struggle with in some circumstances - just that its accuracy always depends on how it's programmed...)
    – psmears
    Commented Sep 21, 2020 at 10:52

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.

  • Well, I tried the best NES emulators in existence recently and they all ran "High Speed" (pinball game) in a very glitchy manner, for one. And the NTSC filter, while really cool, falls short since my games are all PAL. The NTSC filter stretches the image and there was no PAL filter. Also, every single other filter makes the games look completely wrong. Commented Sep 20, 2020 at 3:44
  • 4
    @CrankyKong The speed issue sounds like your emulator is set to NTSC mode rather than PAL mode (you have to specify it manually, since ROM files generally don't include region information). I'm not sure whether that will fix the filtering issue or not; unfortunately there doesn't seem to have been nearly as much development effort spent on PAL filtering.
    – NobodyNada
    Commented Sep 20, 2020 at 5:58
  • 1
    PAL is always going to be a pain to emulate on current PC systems because modern PCs usually run their displays at 60Hz but PAL runs at 50Hz. Commented Oct 4, 2020 at 23:48
  • @PeterGreen: When did PCs go back to "usually" running their displays at 60Hz? Prior to the VGA era, they did, but the VGA changed frame rates based upon resolution. Later monitors and display cards dropped the strong relationship between frame rates and resolution, but allowed users to select among a range of frame rates that would vary with resolution (on CRTs, the highest resolution would often only be available as interlaced at about 100 fields/50 frames/second, while lower resolutions could be shown at frame rates up to 100 frames/second).
    – supercat
    Commented Oct 21, 2020 at 15:35
  • IIRC it was around the time of the move from CRTs to LCDs. Commented Oct 21, 2020 at 15:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .