How many of you are emulation converts?

[mr_me]

When it comes to arcade games, most of us have had no choice but to emulate regardless how you feel about it.

 

This new look-ahead roll-back emulation is great but it shows the one thing that bothers me about software emulation. And that's you need very powerfull processing to do something much simpler. And as newer video game technology becomes obsolete we'll need even more powerfull computers to emulate them.

 

That's what I like about fpga hardware emulation. Rather than having very powerfull computers behave like not so powerfull computers, you just replicate the not so powerful computer. Not sure which way is more energy efficient, if that matters; and software emulation will likely remain more convenient. Fpga is still in its infancy, compared to software emulation, but I'm interested in following how it develops.

Edited June 9, 2018 by mr_me

[Keatah]

Both FPGA and Software Emulation are niche aspects of videogames. And while SE may be a firehose, FPGA is but a drinking straw.. when it comes to pervasiveness.

 

Nearly everyone I talk with is under the misconception that FPGA replicates the original computer. It does not. And well-respected FPGA developers will agree.

 

FPGA is more power efficient. SE still continues to rely on brute-force MHz in the host. And this is because modern-day emulator programmers continue to use 1 core of a 6-core chip for example. Nor do they make use of the advanced instruction set available to them either. They will catch up in time.

 

---

 

As far as emulating newer hardware. It will require hybrid emulation. There's that ugly word again, hybrid emulation. The original term "hybrid emulation" means to use use a mix of emulated instructions and real instructions native in the host hardware. Think a mixture of Low-Level-Emulation and High-Level-Emulation.

 

---

 

As software emulation progresses, developers will be forced to embrace multiple cores and more virtualization tech built into newer processors.

[mr_me]

...

 

Nearly everyone I talk with is under the misconception that FPGA replicates the original computer. It does not. And well-respected FPGA developers will agree.

 

...

Why doesn't it? It's not that I doubt you. I'd just like to know more about it.

[Trebor]

byuu wrote up a good article regarding FPGA and software emulators. These statements perhaps help to drive home the point(s) being made:

 

"PGAs, or field-programmable gate arrays, are components that are programmed through code written in languages such as Verilog or VHDL. This code tells the component how to operate, in the same way that C++ instructs a general purpose CPU how to operate.

How these two differ behind the scenes (logic gates versus microcode) is irrelevant to the end result: replicating the original hardware experience. Setting efficiency aside, there is absolutely nothing an FPGA can do that cannot be done in software...

In both cases, emulator developers are transforming their knowledge of how the original [hardware] works into source code that attempts to mimic their operation. Given equal knowledge of the original hardware and absolutely masterful potential, an FPGA implementation and a PC software implementation will be equally accurate."

Another well-written follow-up article went into the matter further...

"The problem with claiming that FPGA devices programmed in Verilog are not emulators, is that it raises the bigger question, "well then, what are emulators??"...It's not just FPGA/Verilog versus CPU/C++. There's so many shades of gray...There is absolutely nothing inherent in the design of FPGAs that make them capable of more accuracy than code running on a PC...

There's no utility in arguing about which theoretically leads to better accuracy: that is going to be entirely dependent upon both the skill and knowledge of the people working on them. There can exist awful FPGA devices, and amazing software emulators - and vice versa!"

[Keatah]

For those reasons.

 

FPGA replicates the function of the original computer to the best of the developer's abilities. Some people even think there is magic silicon inside with wires that move around reconnect themselves. And parts that, somehow, morph into others - like transistors becoming resistors or diodes becoming capacitors. That simply isn't so.

[mr_me]

I understand the differences between fpga hardware emulation and software emulation. I understand that with a lot of work software emulation can be accurate. It was suggested that with fpga hardware emulation you can not replicate the original hardware. I haven't seen anything here to explain or support this.

 

When I asked the question, it didn't enter into my mind that the fpga work was completely automated. I don't doubt that there are people that have misconceptions with hardware or software emulation.

Edited June 13, 2018 by mr_me

[Keatah]

Mmm.. Why not look up some information on Logic Elements and their truth tables as they apply to fpga fabric. FPGA can replicate the logic activity of a given circuit. Just as software emulation can replicate the logic activity of a given circuit.

 

The FPGA doesn't rebuild the original circuit. Far from it.

 

Both methods achieve the same output, but through entirely different means, and both are different from the original circuit that's being emulated.

[mr_me]

Thanks, I now see that at a very low level, fpga logic gates depend on tables that may be implemented differently than a real logic gate. However, I don't know how a real logic gate is built nor would an electrical engineer necessarily, in order to build a circuit. My understanding is that an fpga can replicate the circuits similar to the real thing and the parallel nature of the circuits is one of the key things that makes it similar, something that software emulation does not do.

 

Edit:

The articles say that the differences between software and hardware emulation don't matter. To me it's the differences that makes it worthwhile paying attention to fpga hardware emulation.

Edited June 13, 2018 by mr_me

[Gamemoose]

Here's a question- is there a way to play a homebrew cartridge (say Halloween '85) on a PC in emulation if you had some sort of cartridge interface? Woukd it work or would it not read the cartridge, like a Retron 5 or other type of machine using emulation to read carts?

[mr_me]

As long as the hardware on the cartridge is also emulated in the software it can work. However, not all cartridge hardware is, and the emulator developer can't predict what hardware someone might put on a cartridge in the future. The rom might also have indirect access that gives the emulator and its rom dumper trouble. That's an advantage of fpga hardware emulation since it can interact with the cartridge more like the original hardware. I'm not familiar with the Halloween '85 cartridge.

[Keatah]

Thanks, I now see that at a very low level, fpga logic gates depend on tables that may be implemented differently than a real logic gate. However, I don't know how a real logic gate is built nor would an electrical engineer necessarily, in order to build a circuit. My understanding is that an fpga can replicate the circuits similar to the real thing and the parallel nature of the circuits is one of the key things that makes it similar, something that software emulation does not do.

 

Edit:

The articles say that the differences between software and hardware emulation don't matter. To me it's the differences that makes it worthwhile paying attention to fpga hardware emulation.

 

It is important to understand that an FPGA does not replicate the circuits. Not even similar. It only replicates their function. In considering a basic digital logic gate, an inverter..

 

Software emulation is this:

A = not A or perhaps A = ~A

 

Real hardware is this:

 

FPGA is this:

 

---

Edited June 13, 2018 by Keatah

[Keatah]

As long as the hardware on the cartridge is also emulated in the software it can work. However, not all cartridge hardware is, and the emulator developer can't predict what hardware someone might put on a cartridge in the future. The rom might also have indirect access that gives the emulator and its rom dumper trouble. That's an advantage of fpga hardware emulation since it can interact with the cartridge more like the original hardware.

That's pretty much right. A Software Emulator would need to be updated and be made aware of any "special trickery" a cartridge does outside of simply storing and retrieving the Game Program.

 

And that only makes sense. A Software Emulator only covers the hardware it was programmed to.. Once you add in DPC+ or extra co-processors or memory, that's new hardware that the emulator has to be made aware of. Thus it will need updating.

 

However, there's the case of bus stuffing. An FPGA won't have the same electrical characteristics as the chips made in the 1970's. And a cartridge that stuffs the vintage bus may not be able stuff the modern FPGA bus. It's a crapshoot there.

 

---

 

I'm not a big fan of "hybrid emulation". And in this context "hybrid emulation" = software emulators reading cartridges. I believe the overall experience is degraded by doing that. You end up with some stuff not working. A whole new and different way of doing things will need to be done for that to work the way a gamer expects.

 

I firmly believe that if you are operating in the physical domain then original hardware + original carts is the right way to go. FPGA + carts is also the right way to go.

 

If you are working in the digital domain, then, naturally, software emulation is the way to go. This means a host computer running emulation software + already dumped roms.

Edited June 13, 2018 by Keatah

[derFunkenstein]

I emulate CD systems that I don't have any other practical means to play. So PSX and Sega CD, for sure. I just feel that CD systems are a bad place to put money with mechanical failures (on top of solid-state ones) and my lack of repair skills. For systems with ODE I go that route. For cart-based systems, real hardware all the way.

[mr_me]

 

It is important to understand that an FPGA does not replicate the circuits. Not even similar. It only replicates their function. In considering a basic digital logic gate, an inverter..

 

Software emulation is this:

A = not A or perhaps A = ~A

 

Real hardware is this:

inverter.png

 

FPGA is this:

truthtable.png

 

---

I think the difference is that an fpga "not" table is part of a block representing the not gate that actually corresponds to the same not gate in the real hardware. Then fpga has interconnections between blocks. Do these interconnections not emulate the circuits in the real hardware? In software emulation, not operators don't correspond to anything. They are used in algorithms to simulate the output of larger components of real hardware rather than emulate the circuits at a low level. I enjoy these discussions and learning new things but is it wrong to say that fpga hardware can emulate the original circuits where software emulation does not. And that's not to say that software emulation can't have high accuracy and fpga emulation can't have flaws. Edited June 14, 2018 by mr_me

[Keatah]

Both FPGA and Software Emulation do their best to duplicate/emulate/simulate the end-result of original hardware. Though it's nice to imagine they do.

 

What is interesting is FPGAs that can reconfigure themselves or part of themselves on the fly without shutting down and reloading a core.

 

This might prove interesting reading.

https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/misc/fpgas_for_dummies_ebook.pdf

[Place Logo Here]

It has only been very recently that I have considered emulation as a possibility. Not looking to replace any of my consoles but want to be able to play arcade-realistic late 70s / early-to-mid 80s games with similar controllers to the original issue.

 

I know I am not going to find a Star Wars yoke and I could care less about light gun games, but trying to play Centipede or Marble Madness with anything but a trackball or Tempest with anything but a spinner is sacrilege to me.

 

My apologies if this has already been covered in another thread or in this (kinda lengthy) one, but what is the consensus for somebody like me who is a wiring/tech imbecile and who just wants to play arcade games on their tv with an arcade stick, trackball and spinner?

 

The videos I have watched so far have me thinking Canakit is my best option for the main device; however, looking at controller options (and the hacks required to make them work) started my head spinning faster than the one on the Tempest cab.

[Flojomojo]

My apologies if this has already been covered in another thread or in this (kinda lengthy) one, but what is the consensus for somebody like me who is a wiring/tech imbecile and who just wants to play arcade games on their tv with an arcade stick, trackball and spinner?

 

I think the simplest way would be to buy an X-Arcade setup. This will get you joysticks and a trackball. $150, or $130 if you want to wait for a refurb unit to ship.

 

Adding a spinner looks simple enough

[Mr SQL]

I think that more people like emulation (or are fascinated by it) then let on.

 

Additionally emulation can be migrated over time to new systems, Hyper-V and virtualizations and all that are also going to become important tools in the arsenal of preservation.

 

And further pushing the boundaries of what is possible and what shows up as new features and capabilities - emulators add value to old games. We all know about savesates and different resolutions and highly customizable controllers. And more. But how about this! Negative Lag - as I like to call it.

 

This is where the emulated game has faster-than-original-hardware response. It basically works by running the game ahead and then rolling it back and matching the controller response with where it should happen in the original game console, or sooner, or later, if you want to tweak it. Your call. It's a new feature and it should silence all those critics once and for all on how emulation is so laggy. It's all possible new because of new software techniques and entry-level processors running at 4GHz or more.

https://arstechnica.com/gaming/2018/04/better-than-reality-new-emulation-tech-lags-less-than-original-consoles/

 

Like the article says. There's going to be people even bitching about that! Because X amount of lag was/is intended.

 

Too many people confuse "intended" with "limit of tech at that time". Ohh well.. Exciting times ahead!

 

That's an intriguing concept, an emulated game with faster-than-original-hardware response - I'd like to see that put to the test against low latency original hardware like the VCS.

 

WARPDRIVE would be a great test candidate, requiring a 30th or 60th of a second reaction times to beat the game respectively with or without the WARPDRIVE engaged.

 

http://javatari.org/?ROM=http://relationalframework.com/WARPDRIVE_AFP.bin

 

I can beat it consistently at the 30th of a second reaction time setting with either Javatari, Flashback or Stella emulation, or a real Atari.

 

http://relationalframework.com/WARPDRIVE_AFP.bin

 

The latency differential becomes measurable at 60th of a second reaction time though:

 

At the 60th of a second reaction setting things change. I can't beat it, but I can score consistently higher with Stella than Javatari, and consistently higher with the real hardware than with Stella.

 

Some LCD Televisions have their only latency issues related to emulating classic Television.

[Keatah]

 

I think the simplest way would be to buy an X-Arcade setup. This will get you joysticks and a trackball. $150, or $130 if you want to wait for a refurb unit to ship.

 

Adding a spinner looks simple enough

 

Yes I was going to say that. X-Arcade is a good start. And don't be afraid to mod it!

[mr_me]

I know it's not the same but I like playing Missile Command with a mouse. Spinners are a problem, especially control panels like Tron. There's no easy option for a spinner, unless you make your own. I play Tempest with a keyboard, after turning up the controller speed; still not the same.

Edited June 18, 2018 by mr_me

[phoenixdownita]

 

It is important to understand that an FPGA does not replicate the circuits. Not even similar. It only replicates their function. In considering a basic digital logic gate, an inverter..

 

Software emulation is this:

A = not A or perhaps A = ~A

 

Real hardware is this:

inverter.png

 

FPGA is this:

truthtable.png

 

---

Ahem ... I somewhat disagree.

 

Your NOT instructions example is actually a good setup.

A CPU to execute a NOT has to load explicitly a memory location onto a register, perform the NOT, mask as needed and then write back to a memory location.

An FPGA just needs to connect a pin to one of the LE LUTs input, have the LUT be configured for a NOT and connect the output of that LE to an out pin .... given the right timing (FPGA are sync beast by far [and so are CPU for that matter], the NOT circuit you attached is an async TTL design which is hardly ever used stand alone btw) ... at the end I can take the FPGA with appropriate voltage converters if need be and replace the actual NOT circuit, for the SW version instead I need to find a way to map the actual input to some interface and the same for the output and hope I don't have to switch too fast (maybe a hundred Khz but hardly anything more than that).

 

Now take an FPGA with say 5K LEs, they can all perform NOT in parallel at once in sync with the clock say at 1MHz, take your SW implementation on a single core x86 at 5GHz, assuming the NOT + LOAD from Memory + STORE to Memory plus whatever is needed to map to a real HW interface (if you use IN/OUT instructions it's dog slower but ....) all takes a single clock cycle (it won't as memory accesses will be needed and because this is real world hardware caching is useless and actually counterproductive) ... anyhow even in the best of situations you'll have around the time to execute 5B of those instructions in 1 sec and that is around 5K 1Mhz NOTs ... so it looks like you're on par, but you'll be sequential on those (one will fire at the beginning and one at the end of the "Mhz", and also in the loop of 5K).

Now take a 35K LEs FPGA and have the NOT run at say 10Mhz and start accounting for real memory accesses and you'll see that the CPU instruction NOT is anything but what an FPGA is doing. You can throw at it even a 16 cores and still come up so short. you'll need a 70 cores at 15Ghz (assuming load and store each takes only 1 cycle) ...even if you try to add pipelining you'll end much slower as data will take a while to come from memory and again you cannot cache as you're dealing with an externally controlled signal.

 

So told you can simulate/emulate in SW what an FPGA would do for each clock cycle, it just won't be fast enough for real time videogame playing.

There's SW (like Spice/PSpice/HSpice) that simulate transistors at the physics level to run ... well ...simulations and it takes a long time to get results for any moderately complex circuits/netlists.

 

BTW the NOT circuit you chose to link is only one of dozens of possible designs (in specific a TTL, low speed, no Schottky diodes, totem pole output design) many of which are compatible with each other even if they do not have the same physical design or exact timing. The truth table is actually what matters (and the physical voltage levels) .... and it is so much so that if you look back at PALs (the grandfather of CPLD->FPGA) you'll see that that is actually how you'd program them binary math equations but it is the same.

 

... I personally think you're spending too much time and energy attempting to bend what an FPGA can/can't do to match your notion of SW emulation ... it's a waste of time, they do things very differently even if they attempt to achieve a similar goal, and a cycle exact emulation in SW (as of today) is still not possible in real time for anything but the slowest/oldest/simpler machines, while we can get bloody close with an FPGA for the 8bit and 16bit systems. The converse is also true, we have HLE for many advanced machines in SW, but FPGA cannot get there in any meaningful way for now.

Both of them can only be as accurate as our knowledge of the devices/experiences we're trying to replicate, no question about it.

FPGAs promise to achieve higher accuracy to the actual hardware at the cycle level (as in I can replace the old rig with an FPGA version and not notice [like flashcarts that simulate complex mappers do, it would be cheaper to slap a RPi in there and a few IO pins but it just won't work]) again depending on how much we know about the HW and it won't require tons of cores at very high speed either ... so in principle cheaper .... this is not the case as CPUs are so cheap presently due to volumes.

SW emulation can reach a high level of fidelity but it is bound by the max speed of the core it is using and how many it can really use in parallel (notice that many emulators can't really run in multi threaded fashion at their core).

[Keatah]

My only beef against FPGA is that it continues to remain rather obscure. And that there is a small base of developers that don't often team up to split the workload.

 

I would have hoped that with all the strengths they have, FPGAs would've been more widely adopted by now.

[phoenixdownita]

I don't think it's an FPGA issue but rather the fact that it requires new boards.

Either one needs to get one of those engineering sample development kits (Terasic and others) for example like MiSTER is doing or one needs to design its own board (the old MiST, but also CC64 or the Nt Mini, Super Nt and many others).

Given the barrier to entry it is inevitable in a way.

It's very similar to the "hackerboards" aka RPi class boards floating around. There's certainly more but still very few if you think about it and those at least get to use a fully fledged OS (Linux or Android) with relatively little investment.

Normal SW based EMU can rely on the fact that most of the population on the planet has available either a PC x86/x64 that may be running Windows, MacOS or Linux, OR an ARM based tablets running Linux or Android and those OSes do standardize a lot to the advantage of a whole class of SW based EMUs.

It is also a lot harder to work at the level of an FPGA as one needs to get a lot more right upfront than via a SW emu to get something even remotely acceptable: for example better get the HDMI modulation correct on an FPGA based board or there's no video at all, in a SW EMU that is a problem for the GPU and one can get away with double buffer to avoid tears if it cannot handle anything faster, same thing for polling joystick etc ... one has to take care of a horde of those things before even starting to build the part that matter .... c'mon even accessing an SDRAM module requires an IP block for an SDRAM controller in the FPGA .... that is a lot to take in all at once.

 

If Intel were to start bundling FPGA as cores in their CPUs accessible by the user code (say anything with around 50K LE) the game would be different as there would be many more people using them (as it happened to GPUs) within the boundary of a classic OS, and hence used as "accelerators" of sorts.

 

Time will tell what would be of these devices, as it is today I agree there's few capable of using them for the kind of gaming experience we want them to be and at that none of them would pass the "hit by a bus" test if their main/only engineer/miracle-man has an accident or leaves.

[Flojomojo]

My only beef against FPGA is that it continues to remain rather obscure. And that there is a small base of developers that don't often team up to split the workload.

 

I would have hoped that with all the strengths they have, FPGAs would've been more widely adopted by now.

I think it's still early. It seems likely to me that we'll see super-cheap boards, Raspberry Pi style, before too long. At least I hope so.

[Keatah]

It would be cool and all. But I wonder if the scarcity/lack doesn't have something to do with the versatile nature of how the inputs and outputs can be programmed (on the fpga chip). The varying nature of the tasks assigned to fpga chips screams "custom support circuitry".

 

Doing anything like videogame emulation will require supporting RAM and a small CPU and other little amenities.

Motor controllers might need a series of successively beefier control components and some sensors

And yet again a different set of parts for cryptocurrency mining, or network traffic monitoring/routing.

 

Seems the design of the off-chip companion circuit changes with each new task. Maybe any fpga board would need to be modular far more than hobbyists are accustomed to working with? Or maybe the fpga could be on a daughtercard that piggybacks on Pi..