Jump to content

Photo

How many of you are emulation converts?


95 replies to this topic

#76 mr_me OFFLINE  

mr_me

    River Patroller

  • 2,748 posts
  • Location:Ontario

Posted Sat Jun 9, 2018 7:51 AM

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 by mr_me, Sat Jun 9, 2018 7:54 AM.


#77 Keatah OFFLINE  

Keatah

    Missile Commander

  • Topic Starter
  • 20,568 posts

Posted Sat Jun 9, 2018 4:14 PM

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.



#78 mr_me OFFLINE  

mr_me

    River Patroller

  • 2,748 posts
  • Location:Ontario

Posted Tue Jun 12, 2018 5:48 PM

...

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.

#79 Trebor OFFLINE  

Trebor

    River Patroller

  • 4,489 posts

Posted Tue Jun 12, 2018 7:44 PM

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!"


#80 Keatah OFFLINE  

Keatah

    Missile Commander

  • Topic Starter
  • 20,568 posts

Posted Tue Jun 12, 2018 11:24 PM

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.

#81 mr_me OFFLINE  

mr_me

    River Patroller

  • 2,748 posts
  • Location:Ontario

Posted Wed Jun 13, 2018 2:10 AM

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 by mr_me, Wed Jun 13, 2018 2:18 AM.


#82 Keatah OFFLINE  

Keatah

    Missile Commander

  • Topic Starter
  • 20,568 posts

Posted Wed Jun 13, 2018 2:53 AM

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.



#83 mr_me OFFLINE  

mr_me

    River Patroller

  • 2,748 posts
  • Location:Ontario

Posted Wed Jun 13, 2018 4:42 AM

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 by mr_me, Wed Jun 13, 2018 5:22 AM.


#84 Gamemoose OFFLINE  

Gamemoose

    Moonsweeper

  • 495 posts

Posted Wed Jun 13, 2018 8:56 AM

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?

#85 mr_me OFFLINE  

mr_me

    River Patroller

  • 2,748 posts
  • Location:Ontario

Posted Wed Jun 13, 2018 10:54 AM

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.

#86 Keatah OFFLINE  

Keatah

    Missile Commander

  • Topic Starter
  • 20,568 posts

Posted Wed Jun 13, 2018 11:02 AM

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:

inverter.png

 

FPGA is this:

truthtable.png

 

---


Edited by Keatah, Wed Jun 13, 2018 11:04 AM.


#87 Keatah OFFLINE  

Keatah

    Missile Commander

  • Topic Starter
  • 20,568 posts

Posted Wed Jun 13, 2018 12:02 PM

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 by Keatah, Wed Jun 13, 2018 12:53 PM.


#88 derFunkenstein OFFLINE  

derFunkenstein

    Moonsweeper

  • 419 posts
  • Location:Pekin, IL

Posted Wed Jun 13, 2018 8:44 PM

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. 



#89 mr_me OFFLINE  

mr_me

    River Patroller

  • 2,748 posts
  • Location:Ontario

Posted Thu Jun 14, 2018 5:53 AM

 
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 by mr_me, Thu Jun 14, 2018 5:55 AM.


#90 Keatah OFFLINE  

Keatah

    Missile Commander

  • Topic Starter
  • 20,568 posts

Posted Thu Jun 14, 2018 10:51 AM

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.c...mmies_ebook.pdf



#91 Place Logo Here OFFLINE  

Place Logo Here

    Chopper Commander

  • 214 posts

Posted Mon Jun 18, 2018 10:19 AM

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.

#92 Flojomojo OFFLINE  

Flojomojo

    ANGRY TACO

  • 12,595 posts

Posted Mon Jun 18, 2018 11:03 AM

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



#93 Mr SQL OFFLINE  

Mr SQL

    Stargunner

  • 1,890 posts

Posted Mon Jun 18, 2018 12:03 PM

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....ginal-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/...PDRIVE_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://relationalfra...RPDRIVE_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.



#94 Keatah OFFLINE  

Keatah

    Missile Commander

  • Topic Starter
  • 20,568 posts

Posted Mon Jun 18, 2018 12:34 PM

 

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!



#95 mr_me OFFLINE  

mr_me

    River Patroller

  • 2,748 posts
  • Location:Ontario

Posted Mon Jun 18, 2018 5:29 PM

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 by mr_me, Mon Jun 18, 2018 5:32 PM.


#96 phoenixdownita OFFLINE  

phoenixdownita

    River Patroller

  • 3,050 posts

Posted Mon Jun 18, 2018 5:50 PM

 

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:

attachicon.gifinverter.png

 

FPGA is this:

attachicon.giftruthtable.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).






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users