FPGA as NES emulation

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
FPGA as NES emulation
by on (#128683)
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?
Re: FPGA as NES emulation
by on (#128684)
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.
Re: FPGA as NES emulation
by on (#128686)
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.
Re: FPGA as NES emulation
by on (#128689)
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.
Re: FPGA as NES emulation
by on (#128690)
Quote:
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

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...
Re: FPGA as NES emulation
by on (#128698)
Bregalad wrote:
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

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.
Re: FPGA as NES emulation
by on (#128703)
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.
Re: FPGA as NES emulation
by on (#128708)
Quote:
Running Kirby's Adventure without lag would require speeding up the CPU, which in turn would require speeding up mask ROM and SRAM access.

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.
Re: FPGA as NES emulation
by on (#128722)
Bregalad wrote:
because an hardware clone is definitely no emulator, until it's an hidden PC running an emu or something

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.
Re: FPGA as NES emulation
by on (#128723)
tepples wrote:
I don't know what mappers switch on CPU read,
Only one I've found so far was Maxi 15 (m234).
Re: FPGA as NES emulation
by on (#128724)
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.)
Re: FPGA as NES emulation
by on (#128742)
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.
Re: FPGA as NES emulation
by on (#128743)
MottZilla wrote:
adding some extra scanlines into the frame somewhere just for CPU time.
Like, say, a Dendy famiclone? ;)
Re: FPGA as NES emulation
by on (#128745)
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.

Quote:
Like, say, a Dendy famiclone? ;)

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.
Re: FPGA as NES emulation
by on (#128747)
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.