FPGA as NES emulation

On #nesdev, oliveira said that an NES implemented via an FPGA solution is not emulation. I think it is a form of emulation. What do you think?

It's dependent on how you want to define emulation. I'd say yes, by my own use of the term, but I think this is a grey area. I can't imagine it not being clear what someone means by the context though. I can't really think of a situation where it would matter whether you'd define it to be an emulation or not.

The distinction I've usually heard made between simulation and emulation is whether one is simulating the physics/math of the original thing or instead executing a description of its function. Which leaves a lot of muddy room in the middle.

Alternatively, simulation is a bottom-up description, whereas emulation is top-down.

Ultimately, I don't think this point of pedantry exists outside of the groups that create and use emulators for hardware.

There's certainly a large gray area here, but my answer is closer to "no". As I see it, even the best emulator is only tricking the software it runs into thinking it's running on a particular machine, while FPGA consoles and the like are supposed to BE that machine. Sure, a person who's implementing an FPGA clone might do things differently than the original machine internally, but I don't know why someone would do that if they're aiming for accuracy. Ideally, the FPGA clone should behave identically to the original hardware, except for a few interface improvements (video, audio, controls, etc.) that are transparent to the software.

Well, you could make a FPGA clone that doesn't limit sprites to 8 per line, or that runs Kirby's Adventure without lagging for instance. However, of course doing that will also break other games, etc...

On the wiki years ago, I outlined a way to reorganize the NES PPU's sprite evaluation and fetch pattern to allow 15 sprites per line. Because I'm aware it would break a few games (MMC5, mapper 90, Micro Machines, and anything using the overdraw limit to hide things or time rasters), I tried to make only minimal changes so that the normal and enhanced patterns can run on the same silicon, switchable through DIP switches, some sort of configuration BIOS, or whatever.

Running Kirby's Adventure without lag would require speeding up the CPU, which in turn would require speeding up mask ROM and SRAM access. Adding a second master/8 divider (in addition to the master/12 divider, which would remain used for the APU and for OAM DMA) might work, but it would certainly need to be a switch because it would break cycle timing for raster effects, and it would break games that use mask ROMs slower than 200 ns.

If you are cloning the CPU and PPU (and the rest of the components) in a FPGA, it is not emulation. It's a hardware clone. That's the way I see it. Once you get away from having actual functional clones of the ICs you're taking about emulation.

Not necessary, there is plenty of dead cycles in the 6502 that can be removed, and by adding a cache you can remove even more cycles by not accessing the external ROM/SRAM when it needs to (making the CPU runs much faster once data is cached in the FPGA's internal SRAM). Of course that'd probably break things if you aren't careful enough, but this is an endless cycle.

I also didn't mention it but a FPGA clone could come with an upscaler and output higher resolution video or something like that. Actually I'm pretty sure some kind of clones does this, even if I never used any myself, I heard about it.

And, to answer the original question, I don't think the term "emulation" applies here, because an hardware clone is definitely no emulator, until it's an hidden PC running an emu or something, that a FPGA clone definitely isn't.

However, most of the drawbacks of emulation, that is, it's hard or near impossible to get 100% accuracy, still applies, which makes it understandable why people would vote "yes".

So the definite answer is "sort of", it's not emulation technically, but has the same shortfalls and drawbacks as emulation.

As Retron 5 is believed to be.

But the problem with caching is that you can't predict what will cause the mapper to bring in a new set of pages. Even reads can trigger bank switches. I don't know what mappers switch on CPU read, but plenty switch on PPU read: MMC2, MMC4, Oeka Kids, and FFVII.

Only one I've found so far was Maxi 15 (m234).

That's a good point. You could get around it by implementing a cache-flush instruction and inserting it into the game's bankswitching code. Then again, if you're willing to mess with the game's code it's probably just as easy to deal with overclocking.

I always liked the idea of being able to choose a scanline (per-game setting?) to insert extra CPU time to combat slowdown issues. Did anyone actually implement that in an NES emulator? (Edit: Aha! The way I just used "emulator" would exclude FPGA, since this solution wouldn't be simple at all on an FPGA.)

In my emulator I implemented altering the ratio of CPU to PPU clocks. It does indeed eliminate slowdowns in some infamous cases like Kirby and TMNT1. The same could be done by adding some extra scanlines into the frame somewhere just for CPU time.

Like, say, a Dendy famiclone?

Yeah, now I realize caching on a hardware clone would be pretty much impossible without doing mapper-specific cache flush conditions, and that'd kill the whole point of being able to (arbitrairly) insert any cartridge and play it. If the hardware clone works with iNES ROMs on a SD card or something instead (like the Power Pak) then it makes it possible (adapt the cache flushing logic depending on the mapper, reprogram the FPGA in live), but that is definitely a specific/weird case.

The best one could do to speed up the CPU without resorting to any kind of emulation is to remove dead 6502 cycles and have faster RAM at $000-$7ff, and modify the processor so that accesses to the faster RAM are actually faster than a slow access to the cartridge (it becomes SNES-GBA ish like). I/O access could be made faster too but it's probably too marginal to be worth the trouble.


As far I know they do it to keep both NTSC scanline timings and PAL 50Hz VBlank compatibility, something which is actually very clever (wonder why Nintendo didn't think of it when they developed the PAL NES, it would have fixed many of problems of poor game porting...). It's not for extra CPU time.

Nintendo cheaped out on the PAL NES CPU's clock divider because it wanted to keep the same Johnson counter structure as the NTSC CPU without exceeding the 6502 core's speed limit. A Johnson counter divides by an even number. Besides, we're dealing with the company that invented region coding. Not only was incompatibility with North American software encouraged, but Nintendo even manufactured incompatibility within Europe itself between the Mattel PAL NES and the mainland PAL NES.