The "Everdrive" is very intriguing to me. Having been continuously disappointed -- not to say appalled -- by every single emulator I have ever tried, for every single console, I've given up on emulators ever properly running the games. I'd rather sit and remember them than butcher them through emulators. That's truly how much I consider them to ruin the games.

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 which you can put ROMs on, 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. Does it really have every single chip that any game ever used as hardware inside the Everdrive? Or does it -- shudder -- emulate them somehow?

And it's not just a small few games that did this. Many of the classics actually were extended internally with special hardware.

This is something which makes me anxious to think about. At first, Everdrive seemed like the perfect solution. But if it only has "partial" support due to those "cartridge chips" found in so many games, it immediately becomes a major problem for me. If they are "approximated" or even software-powered, we are back to the same damn problem with emulation being so inaccurate and whatnot.

Perhaps I'm missing something and you can straighten this out for me.

  • 13
    Rant against emulation disguised as question. Should remove everything except question. – Nobody Sep 21 '20 at 6:26
  • The rant provides context for how the question ought to be (and was) answered. – knol Sep 21 '20 at 17:54
  • 3
    "Appalled" - well I'm sure all those people who put all those hours of their spare time into creating emulators (one of the most difficult tasks in development) so that the world can preserve and play classic games for free are just disgusted with themselves that they've disappointed you. Think you can do better? Break out your C++ tools, otherwise dry your eyes. – Alan B Sep 22 '20 at 16:18

Does it really have every single chip that any game ever used as hardware inside the Everdrive? Or does it -- shudder -- 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. :)

  • 10
    An FPGA doesn't simulate hardware, it recreates hardware, and does it much more accurately than a software simulation. – snips-n-snails Sep 20 '20 at 3:05
  • 1
    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 Sep 20 '20 at 3:15
  • 15
    @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- Sep 20 '20 at 16:29
  • 1
    @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. – user253751 Sep 21 '20 at 8:08
  • 1
    @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 Sep 21 '20 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. – Cranky Kong Sep 20 '20 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 Sep 20 '20 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. – Peter Green Oct 4 '20 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 Oct 21 '20 at 15:35
  • IIRC it was around the time of the move from CRTs to LCDs. – Peter Green Oct 21 '20 at 15:37

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.