FPGA Based Videogame System

[Andromeda Stardust]

Your comment is valid but not relevant to the core discussion here - whether or not an FPGA implementation is an emulation. We're not focusing on performance.

I think performance would be a huge consideration. Wouldn't you rather have an implementation B that outperformed the traditional implementation A if you had the option? Suppose implementation B was the FPGA route? Would that impress you and convince you to change your mind?

 

Retron5 and Retro Freak are ARM-based software emulators that interface real carts by dumping them into memory and running them from RAM. They do not work with flash carts for any system or new homebrew NES games using flash mappers.

 

RetroUSB AVS is coming out soon and promises 720p video and 100% compatibility with all NES and Famicom games and accessories, past, present, and future, with the lone exception of light gun games which don't work on HD displays. It uses an FPGA to "emulate" the NES, as you so eloquently put it.

 

Imagine for a moment you had a choice between (A) the Retron/Freak or the (B) the AVS. Also assume the other cart ports on option (A) don't exist, and both were the same price (they aren't, but are kind of in the same ballpark costwise). The ARM system can only play known games whose CRC checksum matches a known database. Otherwise it has no way of knowing how to dump or emulate the mapper. The FPGA system plays everything, no ifs, ands, or buts.

 

Which would you choose? Which do you think has superior compatibility? Still think an FPGA is "just" emulation?

[tcdev]

I think performance would be a huge consideration.

Which would you choose? Which do you think has superior compatibility? Still think an FPGA is "just" emulation?

 

I don't understand where you're going with this - the one, single statement that I had issue with was a claim that FPGA implementations aren't emulations. That - and only that - is what I've been addressing until now.

 

Performance, accuracy, "which is best" etc are secondary and completely different discussions. I could debate this but quite frankly, we'd probably agree for the most part. I don't see the point.

[phoenixdownita]

I like the classification done on Wikipedia:

 

Emulator -> https://en.wikipedia.org/wiki/Emulator

Hardware emulation -> https://en.wikipedia.org/wiki/Hardware_emulation

 

SW or HW based emulation/simulation are one and the same in the end, the promise of FPGA is better accuracy, performance and packaging (I don't need a full PC setup ... albeit the recent SBC [RPi 3/Odroid C2 etc...] kind of make the last point moot).

If there's a breakthrough in CPU clocks that we can run at 300GHz (it is NOT going to happen) then SW emu can be as accurate as it needs to be, another breakthrough could be in parallel programming so we can use a 10K cores CPU at 2GHz and have SW do the right thing .... possible but we're not there yet.

 

Both SW and FPGA based re-implementations are only as good as the knowledge we have of the details of the architectures and their quirks, the promise of FPGAs is that all the pieces of the actual architecture can be run in parallel (like in the real deal) while to this day many SW emulators take little to no advantage of multi-cores due to the difficulty in coding efficiently for them so they limit themselves to use one core an call the code in a loop.

 

Anyways ... please keep getting at it. I'd love a small FPGA box for all my 8/16bits emu needs that can run real HW and new game as they are available (assuming it is economically viable to add the carts/joy/ports of the original hardware instead of resorting to virtualize them).

That's what the Z3K could be if it ever gets to the point of being more than a poll on AA.

[Andromeda Stardust]

 

I could debate this but quite frankly, we'd probably agree for the most part. I don't see the point.

Agreed. I am done too.

[bretthorror]

I know it's kind of counterproductive to an HDMI system, but given the scenario, I think composite out would be great just so people would have the options of hooking up their consoles to an old TV and run light gun games on it, unless you can buy HDMI to composite adapters that'd work flawlessly. Just seems like if you're gonna buy a lavish system like this that could in theory be all in one, it'd be great to be able to play the light gun games.

[Newsdee]

I was thinking these days that it might be simpler to think in terms of low/high levels of emulation.

 

Some emulators for machines after the N64 or PS were criticised for not emulating the internals but instead implementing higher-level APIs that games rely upon. This allows, for example, to make 3D games much higher resolution than originally intended, but did have its share of compatibility problems.

 

I suppose FPGAs might be the lowest level of emulation possible - replicating the specific chips at an electrical level. One level up of that would be combining several chips and circuits inside a SoaC device (which most FPGA based machines do).

[Keatah]

I still (but not for long) work on tech all day. So when I get home I strongly prefer to speak in layman's style - a shifting of the gears if you will. Forgive me if I gloss over the fine points.

 

I personally believe the best "emulation systems" or "emulators" are the ones that actually exist in the here and now and are fully playable. That means the likes of Mame, Stella, Vice, Altirra, AppleWin, WinUAE, and many others. While not 100% perfect (nothing ever is) they're damned good. Maybe FPGA rigs can offer more accuracy. But right now none exist that match the functionality and versatility of a comprehensive suite of software emulators.

 

From file management to savestates, from adjustable speed to working on modern displays to hosting reference material and debugging, software emulators are awesome tools in the classic gamer's arsenal.

 

Because software emulators exist I have whole series of virtualized classic computers and game consoles. And I can play them all cozied up in the loft or reading room. What more could I ever want?

[Keatah]

I would imagine schematics are definitely useful for emulator authors and FPGA programmers. Of course the real masterminds like Kevtris are poking around the internals with logic probes to see every high and low logic signal and what they are doing. The schematics only tell you which traces go where, not the signals they possess.

 

They are! And they tell you how those signals are generated. Duplicate that and you, well, have duplicated the target machine. Except FPGA's don't duplicate chips that way, they use logic blocks and LUTs.

 

[Keatah]

Assuming the "Final ASIC" is equivalent to the original console, if not from a logic gate level then at least from a functional standpoint, then who cares if the "Final ASIC" is implemented as discrete logic gates on a custom die, or an FPGA chip? You claim both are emulation, but the FPGA/ASIC is operating on the hardware level in a way that is equivalent to original chips. The software emulator tries to compute the logic of every part on a command/ASM level, by converting ASM from one CPU architecture to another. And the results of emulation are not realtime yet the results of logic gate emultaion via the FPGA, or an entire clone chip, are.

 

Surely you see the folly of using the blanket term "emulation" to describe both processes? I cannot imagine how the software emulation could possibly be superior to going the hardware route.

 

..and yet I can still play Demon Attack in realtime. "Real enough time" that it's 60FPS and looks and sounds like the real thing. A modern CPU can compute the frame of a VCS game nearly instantly and has time left over to do other things. Essentially you're waiting on VSYNC. So who cares if isn't realtime, it's faster than real time!

 

There is no folly, both processes are emulation through and through. And currently, right now, software emulators are outnumbering FPGA rigs by, ohh, about a million to one. Maybe in time FPGA rigs will become a standard "must have" piece in the gamer's tool chest. Maybe not. Only time will tell.

[Keatah]

^^ Did anyone fail to bring up the lag issues with traditional emulation? Many emulators lag badly. An FPGA implementation requires no screen buffer to render graphics to a display like a traditional CPU/GPU combo does. An FPGA can pump pixels out to the screen in real time, whether said display is a CRT beam or a 480p, 720p, 1080p, or even 4k display. Just the zero lag alone makes a huge difference to some gamers. 16ms of lag can mean the difference between defeat and victory in some games. No ARM or x86 implementation of a game console is going to be pumping pixels out to the sreeen in realtime. No way no how. and that is exactly what Kevtris intends to do with his Zimba 3000.

 

As far as I recall, lag in traditional software emulation hasn't been mentioned in this thread yet.

[Andromeda Stardust]

I was thinking these days that it might be simpler to think in terms of low/high levels of emulation.

 

Some emulators for machines after the N64 or PS were criticised for not emulating the internals but instead implementing higher-level APIs that games rely upon. This allows, for example, to make 3D games much higher resolution than originally intended, but did have its share of compatibility problems.

 

I suppose FPGAs might be the lowest level of emulation possible - replicating the specific chips at an electrical level. One level up of that would be combining several chips and circuits inside a SoaC device (which most FPGA based machines do).

Game Cube is amazing in 720p or higher! I swear Sunshine looks just as good as a typical Wii-U game!

[+Random Terrain]

Agreed. I am done too.

 

 

This one is prettier:

 

[KAZ]

This is really an awesome discussion, I'm learning a ton here

 

The emulator DICE is an exact 1 to 1 to the original machine. Should it be called an 'emulator' or is there a better term for how exact it is? If an emulation is 100% like the original, does it cease to be an emulation? What's the word we should use if something is EXACT. A clone?

 

There are no machine emulators for Atari 2600, correct? (to the accuracy of DICE) If eventually there is, should the term 'emulation' still be used? It doesn't seem descriptive enough to speak to the accuracy.

 

I heard of a game (Speedy Gonzales), that did not play correctly on many emulators, except on bsnes, because of timing issues.

Edited June 5, 2016 by KAZ

[Andromeda Stardust]

 

I heard of a game (Speedy Gonzales), that did not play correctly on many emulators, except on bsnes, because of timing issues.

I should pop that one in my Retro Freak...

[RupanIII]

Hmmm, pretty sure I have a copy of that around here and the Retro Freak currently is sitting in the middle of the living room waiting for a gaming session of cart tests tomorrow.
I'll let you know if I get to it. I haven't done any updates to the RF yet, so, i can say what Original Firmware is versus whatever you have loaded.
Sofar the thing is flawless.

 

I should pop that one in my Retro Freak...

[KAZ]

Here's an article that I've always loved reading, and the part about Speedy: http://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-build-a-perfect-snes-emulator/

 

"At first glance, it appears to run fine in any emulator. Yet once you reach stage 6-1, you can quickly spot the difference between an accurate emulator and a fast one: there is a switch, required to complete the level, where the game will deadlock if a rare hardware edge case is not emulated."

 

That way you know the place where you can see if it is emulated properly.

[KAZ]

Great, now my current perseveration is about how many horses die in racing.

 

http://www.nytimes.com/2012/03/25/us/death-and-disarray-at-americas-racetracks.html?pagewanted=all&_r=0

 

Horses really are abused, for real. Thanks for bringing the topic to my attention

[Newsdee]

DICE looks like a nice project to port to HDL.

[tcdev]

The emulator DICE is an exact 1 to 1 to the original machine. Should it be called an 'emulator' or is there a better term for how exact it is? If an emulation is 100% like the original, does it cease to be an emulation?

 

The term "emulation" does not itself imply anything about accuracy or lack thereof. Something is either an emulation, or not. Emulators may be very good (accurate) or not, or anything in between - either way they're all simply emulators.

[tcdev]

 

They are! And they tell you how those signals are generated. Duplicate that and you, well, have duplicated the target machine. Except FPGA's don't duplicate chips that way, they use logic blocks and LUTs.

 

 

At least someone gets it!

[tcdev]

Some emulators for machines after the N64 or PS were criticised for not emulating the internals but instead implementing higher-level APIs that games rely upon. This allows, for example, to make 3D games much higher resolution than originally intended, but did have its share of compatibility problems.

 

The main reason for this is the complexity of the designs - in particular the custom ICs used in the design. There is no easy way to reverse-engineer the workings of a custom IC, especially ones as complex as those used in modern consoles. The only feasible approach has been a black-box reverse engineering and/or so-called high-level emulation at a known (well-specified) level such as an OpenGL API layer. Compatibility issues arise due to bugs/nuances of the particular implementation being unknown to the emulator authors. Those that "criticise" such efforts are certainly unable to contribute anything useful to the process and rightly ignored. On the flip side there are some advantages to a high-level approach, such as being able to generate higher-resolution displays, at the expense of accuracy. At the very least, it's a stepping-stone towards more accurate implementations and shouldn't be discouraged. You only have to look at the progress of MAME to appreciate that.

 

You may be interested to know that portions of the N64 were implemented in Verilog. If one were to find themselves in the possession of the Verilog source, then perhaps we could start having the discussion about FPGA implementations not being emulations.

[narshe]

I still (but not for long) work on tech all day. So when I get home I strongly prefer to speak in layman's style - a shifting of the gears if you will. Forgive me if I gloss over the fine points.

 

I personally believe the best "emulation systems" or "emulators" are the ones that actually exist in the here and now and are fully playable. That means the likes of Mame, Stella, Vice, Altirra, AppleWin, WinUAE, and many others. While not 100% perfect (nothing ever is) they're damned good. Maybe FPGA rigs can offer more accuracy. But right now none exist that match the functionality and versatility of a comprehensive suite of software emulators.

 

From file management to savestates, from adjustable speed to working on modern displays to hosting reference material and debugging, software emulators are awesome tools in the classic gamer's arsenal.

 

Because software emulators exist I have whole series of virtualized classic computers and game consoles. And I can play them all cozied up in the loft or reading room. What more could I ever want?

 

I disagree with this. Software emulators have too many issues; one huge one being lag. I see the Z3K as being a 100% accurate hardware replacement for my old consoles. Those consoles will only last so long and then we need something to replace them. I want to hook it up to my old CRT TV and have a perfect experience as originally intended. Then in the future when CRTs can't be found, being able to use the HDMI out with 0 lag to an LCD and just worry about the processing lag of the LCD itself.

 

Having a 100% accurate recreating is big here. If not, we might as well all just get a retron or play emulators on our PC. I'm currently still buying old hardware. One day it would be nice to not have to do that.

[Keatah]

Software emulators are the best because there are in the here and now, today. Z3K does not exist yet. Hopefully it will in good time.

 

It'd kinda like saying New Horizons is the best way to travel across the solar system. It exists today and is currently doing so, whereas the Enterprise is off in some undefined future.

 

At any rate. A properly done Z3K with enough extras and menu options could be a viable console replacement. We're going to need one sooner or later. And I find it rather embarrassing, low-class, tedious, time-consuming, and annoying to be frequenting Craig's List sellers for videogame parts and needs.

 

You should see some of the ratbag infested junk piles I used to bring home.

[Keatah]

Regarding the outputs the z3k should have.. I still stand by my original suggestion of Composite and HDMI. Anything else really isn't needed. You can feed Composite into an RF modulator for use on old-school TVs. Or use Composite directly into 1084s type monitors. Both solutions will give the proper look and feel of yesterday.

 

And HDMI will pick up and cover all modern sets. All LCDs made in the past 10 years should sport HDMI. And you can get HDMI to VGA converters just like you can get RF Modulators.

 

Things like RGB, Component, and S-VIDEO are, I don't know, kinda blech..

[kevtris]

I don't really have much to add on how an FPGA simulation/emulation differs from a PC one, except in the following ways:

 

An FPGA will have no lag in the best case, and minimal lag in the worst case (i.e scaling to HDMI, etc). A software emulator, on the other hand, will have lots of sources of lag built in. There will be the controller interface aspect, the CPU/processing part, and then the video rendering portion. Some of these can be minimized possibly, but if there's an OS running underneath, I think lag will be unavoidable.

 

As a ferinstance, my NES core has a "real NES" video output mode where it recreates the exact same voltages and transitions using a DAC to recreate the video signal. There's no lag involved- it is generated in the same way a real system generates its video signal, complete with the same steps and transitions. I guess the lag, if you can call it that, will be a few nanoseconds for the data to propagate through the DAC and be presented on the output pin. My "real NES" video is an exact reproduction (well it looks like that on a scope and on a monitor using direct A/B testing) of what a real system outputs. You'll have trouble making a software emulator do this. As a bonus, I provide an S-video version of this signal too. Unlike a real NES which has composite video only, S-video is easily possible while maintaining everything else exactly the same.

 

I tried out a Retron 5 (there's a video about it actually... I will link it below) and it's total garbage. I didn't think I was very sensitive to lag in a videogame, but holy crap, that thing is useless. I tried to play Boulder Dash for NES on there and the lag was extremely terrible. I don't know how much it was but it has to be 4-5 frames at least. How anyone could play this, I don't know. Of course, lag issues CAN be minimized in software emulators, but I don't think they will ever be really conquered. One big issue is i.e. a PC has a fixed frame rate, and the system being emulated has a slightly different frame rate (i.e. 60Hz monitor refresh vs. 60.09Hz refresh for the NES) so there will be compromises made somewhere. Either by slowing the system down (what I do for HDMI) or by frame dropping/duplication.

 

Re: writing "code" for an FPGA, IMO writing HDL(hardware definition language... i.e. Verilog) isn't writing code. It may look like code and smell like code, but to me it's describing how a digital logic circuit is formed. It is basically a written implementation of a schematic. The big obvious difference is a piece of code executes sequentially, one instruction after another, while in HDL, every line of code "executes" at the same time.

 

Also, regarding if an FPGA implementation is an emulation or not, what about my 2600 and 7800? I basically reimplemented the chips used in these systems at the transistor level using the chip schematics, vs. actual black box reverse engineering. Since the chips are NMOS and use dynamic logic, some minor changes were made here and there to simulate this, because an FPGA cannot directly simulate dynamic logic.

 

The last thing about my FPGA cores is their accuracy. I strive for accuracy, and include many hours of my own research into this, involving making custom hardware and plenty of test fixtures, and logic analyzer time along with reams of custom code. Not many emulator writers can claim this. There's always going to be a "long tail" of bugs but I try to fix 'em all. Of course, software emulators can achieve this too, but that would require mucking around with hardware.

 

Whoops, forgot the youtube video:

 

Edited June 5, 2016 by kevtris