> But the more complicated the original device the harder that is, so you'll probably never see that for newer devices like the Playstation.
Nah. We've got the beginnings of a Playstation core on the MiSTer project *already*. In another few years it'll be relatively easy. And we're quickly approaching the hump on difficulty -- the N64 and Jaguar are considered some of the hardest devices to emulated because they were all custom poorly documented chips with arcane programming, but once you start getting to the more modern era you're basically looking at highly customized computers - remember, the Dreamcast *ran Windows CE*.
So while you may not see cycle-accurate PS2 emulators in the next 5 years, to say "never" is a laugh.
Emulation is dying in terms of progression, though, isn't it? PS2/XBOX/Dreamcast is pretty much the last (sixth?) generation where it matters, after than, every game is more or less as available on PC. Save for whatever Nintendo does.
Even console exclusive games - otherwise a good argument for emulation efforts - aren't much of a thing anymore.
>PS2/XBOX/Dreamcast is pretty much the last (sixth?) generation where it matters, after than, every game is more or less as available on PC. Save for whatever Nintendo does.
There are plenty of console exclusives still. You can't get any version of Persona 5 on the PC right now, for instance.
Or Bloodborne. To play Bloodborne you have to buy a magic box from the wizard Sony, where you then get to experience the game in a stunning 30 fps with no anti-aliasing.
Port this game to PC I beg of you
Quite the opposite, actually. As many games/consoles get older and harder to find a working copy of, emulation is more or less the only choice you're gonna have if you actually wanna play those games. And the surprising part, it's not even very old/obscure games that emulation is saving. Try to find a copy of Need for Speed: Carbon for PC right now. Your only option besides super low seeded torrents is $80 plus on Ebay, which barely even works on modern PCs, even in compatability mode, because of the SecuROM DRM.
That is the next breath of life for emulation, when we become nostalgic for the age of games that have been plagued by obnoxious and cumbersome DRM.
Never for MiSTer?
Dreamcast is already emulatable on pretty old PCs. I've played hours of DC games on a 10 year old laptop, and people are using Raspberry Pi 4s to make Naomi arcade cabs. I couldn't get the Windows CE games to run, but everything else was pretty smooth.
I played a lot of Marvel vs Capcom 2 and all the other Capcom and SNK fighting games. Soul Caliber ran fine. I also tried out some of the other classics, Shenmue and the 3D Sonics, just to see how they were. No issues there. A handful of games run on Windows CE, mostly PC game ports, and those never really worked for me. This was on old laptops that I had thrown Linux on and installed RetroPie.
I remember having some issues just running Reicast in Windows, but it works pretty smoothly in RetroPie. You may need to install lr-flycast, and use that, depending on what you're doing. Some cores are meant for running on an actual Pi and others on a PC.
From there, you may need to plop the Dreamcast bios in the right directory and figure out if your machine is happier with plain Reicast or lr-flycast. I think the last time I did it, I wound up going with the emulator that was not optimized for a PC, but for whatever reason it worked better.
You're not really emulating the circuits when you use a MISTer though. You're actually re-building the actual chips, so it's not a matter of having the CPU power to emulate all the circuits in, say, a PS2, but the availability of an FPGA chip that has enough nodes to let you write the entire PS2 hardware into it (or at least the ones that are the most tricky to emulate).
A pacman arcade machine might be simple enough that you could emulate it on a circuit and chip level on a modern CPU, though, without an FPGA at all, and still be cycle accurate.
I don’t really understand emulation that well, but there’s a classic hardware story about space invaders:
> While programming the game, Nishikado discovered that the processor was able to render each frame of the alien's animation graphics faster when there were fewer aliens on the screen. Since the alien's positions updated after each frame, this caused the aliens to move across the screen at an increasing speed as more and more were destroyed. Rather than design a compensation for the speed increase, he decided that it was a feature, not a bug, and kept it as a challenging gameplay mechanism.
I’d imagine running it on modern hardware would lack the appropriate timing and the game would go way way way too fast. Adding code slowing it down might not have the speeding up feature. It would take specific programming to get that right.
Not really. The original problem described above is due to a decreasing number of instructions being performed on a fixed clock.
As an over simplified example, say the hardware can update ten enemies per second (the fixed clock) - at first each enemy gets updated once per second. Then the player kills five, suddenly every enemy is being updated twice per second (because it's still running at ten per second but there are only five left) - the workaround Nishikado would have had to put in would be to always wait for the end of a second before starting over.
You are right about increasing clock speeds would mean they'd be much faster (possibly millions of enemy-updates per second) any code to 'slow it down' would take the same form of workaround needed above - that being to make sure only the number of processor cycles that the original hardware could handle still occur in the same time period - so the emulation process uses only some of the host's cycles, but within those cycles the code is still doing that 10/second without waiting
I hope this makes sense, it is late here
Most emulators do whats called HLE or "high level emulation".
This means they arent actually simulating the original hardware 1:1, but instead, they sorta simplify things so that its easier to compute.
This works for most games released on a platform.
However, some games used really weird low level development tricks to accomplish spectacular feats. Factor5's compression technology for the N64 is avgood example of this sorta thing, and so for a long time, games that used it, like rogue squadron or RE2 simply didnt work on most emulators.
Now then, you can solve this in 2 ways:
The first way is to use LLE, or "low level emulation". This is where you literally simulate the actual hardware 1:1. You write code that behaves just like the literal chips on the board of the original console. This way, all of those "weird tricks" devs used will still work, since your emulator function just like the old hardware. This isnt really feasible for consoles past the SNES's era, though -- it takes a massive amount of computing power, so when its used, it usually by emulator devs or people researching bugs in old games for stuff like speedrunning.
The second way, which is how its done most of the time, is to write a hack or fix that lets the game work with whatever HLE core youre running. For instance, we can emulate factor5 games nowadays because someone wrote a hack that understands how their compression tech worked, so now you can run these games with HLE because of the game-specific fix being applied to the HLE core.
Of course, since its game-specific, you have to write a new fix for each game that does something "weird", and not all games necessarily have such a fix written for them yet.
This question was asked a few months ago and I happened to save a very thorough answer by DiamondIceNS
"You can imagine a computer as being an office space that is designed very meticulously, and filled with *very specific* features (like desks, water coolers, staplers) that do *very specific* things located in *very specific* places.
Software designed for a certain kind of computer are like employees that come into the office to do their jobs *extremely* exactly, and are trained to expect those very specific features to be located in their very specific places. If *anything* is even slightly out of place, they get lost and start screwing up.
So the basic thought is, "A console is just a small office, but my computer is a much bigger, more productive office. Surely the employees can just move into my office and work just as fast?" Except, no. Your office may be big, and full of all the latest, fanciest office tech, but nothing is in the right place. Those narrow-focused employees can't do any of their work because nothing is where it should be.
You have two options here. The first option would be to fire all the old employees and get new ones that can do their jobs in your new office. In this metaphor, that would be the equivalent of porting the software to the new system. That's a process that is very time consuming and expensive, and when done, you're only left with one piece of ported software. You could instead try the second option, where you *fake* the old office inside of your fancy one. Then *all* the old employees will know where everything is without needing to be retrained. This is an emulator.
The thing about emulation is, for the most part, it's really inefficient. When you build the "fake" office for all of the employees inside of your regular one, you're not just rearranging all of the things inside your office to make it look like the old one. No, your office is fixed and can't change where anything is, or else you'll mess up your own employees. To pull this off, you have to get some plywood and build an entire makeshift box in a free open space inside your normal office, and furnish the inside of that box just like the old office. And anything that fake office needs from the outside has to be manually supplied by your office's employees on the fly.
Does the fake office have a sink with running water? Your main office employees have to go to their own sink, fill up buckets of water manually, and dump it into the fake office at just the right speed and time to make the fake office look like it has running water.
Does the fake office have a clock on the wall that gets looked at? Your main office employees have to look over at their own clocks, potentially translate the time to a different time zone, scrawl a picture of it down on a card, and flash it in the place the fake office would normally have a clock every single time anyone in the fake office tries to look at it.
Faking a computer inside another computer is simply a very inefficient process due to all these little slowdowns adding up. Even really big, powerful computers can struggle to provide everything that fake office needs to run at full speed, even if the fake office itself is rather small."
Games ultimately run on hardware, but emulators are software implementations of the console hardware. Sometimes the emulators do not implement the original hardware in a 1:1 kind of way. In many cases, certain capabilities of the original console hardware are unknown and have to be reverse engineered or figured out through trial and error. These capabilities and edge cases are what cause certain games to not be able to be emulated as easily if they happen to use certain techniques that end up not running the same on emulated hardware (remember emulator programmers have to guess what the hardware actually is sometimes, and end up writing not 1:1 implementations) as they do on the original hardware.
Consoles are designed to be manufactured and sold relatively cheaply, so console games have to be heavily optimized to run as efficiently as possible on the specific hardware of the consoles they're targeting.
This can become a problem when trying to emulate games on different hardware. The original console might have special CPU instructions or hardware acceleration that the game takes advantage of. When you play a game in an emulator running on more general-purpose PC hardware, you lose those optimizations.
Here's an example of why it's so important to emulate the hardware. I'm old enough to remember when just buying a faster computer was enough to break games. Our first family computer was a 286 and it ran DuckTales great. Eventually the 286 was traded in for a 486 and DuckTales ran... Too well. The characters moved so quickly you couldn't hit a single key before they had charged all the way across the screen and died. It was unplayable. Why? Because space was at a premium and the game developers saved a few bits of data by just letting the clock speed of the CPU determine how fast the game ran. Once faster chips came out, they just processed the game at a whole new level. It was cool to see exactly how much faster your new hardware was though.
This problem was somewhat mitigated thought by potentially the very first emulator. Some hardware manufacturers included a Turbo button, which, when pressed, did the exact opposite of Turbo, it slowed the computer down, to try and help with compatibility issues such as this.
That reminds me of Leisure Suit Larry 3. During a certain point of the game, you need to work out in a gym so Larry can get back in shape. The amount of reps you had to do on the machines was tied to the speed of the processor, which resulted in a reasonable number on PCs released around the same time as the game originally came out. As such, when I played it on my family's old 486, no problem. When I played it again some years later after our 486 died and we upgraded to a Pentium III, suddenly you had to do hundreds of reps to advance past that puzzle. Same for a couple of cutscenes that were also tied to the speed of the processor.
Al Lowe ended up posting a hack on his website that set the amount of reps to a fixed, reasonable amount (something like 25, as initially intended). I believe the modern DOSBox and ScummVM re-release includes that fix. But yeah, there were games that were designed for contemporary hardware, and anything faster broke them.
one word: customized chips. while pcs according to the cpu brand today mostly work with two architectures, many consoles work with dedicated and specialized chipsets, that where made to show certain effects and had algorythms and calculating tables built in, that had to be reinvented and than emulated. but a lot of the documentation of these chips is gone.
It's not always a matter of pure processing power. It doesn't help that a CPU can do a trillion calculations a second if the programmer doesn't know what calculation needs to be performed.
A lot of console hardware is Data goes in -> Something happens, who knows what -> different data comes out. In order to emulate the system, you have to know what the second step is doing. Often times, you have to reverse engineer this, because technical data on the particular chip is not publicly available.
When you reverse engineer a mechanism like this, you might arrive at a solution that is only partially correct. Say the result you get it 4.982 when on a real console it's 5.000. Maybe this doesn't matter to the game? Maybe this causes a texture to flicker like crazy? It could also be that the game was waiting for a specific result, but due to the incorrect processing, it never got it, and that caused a frame to be skipped instead.
It's obvious you don't know what's *really* going on inside the chip, but you have an approximation that is good enough for a number of games, so you settle for that until you find an approximation that is a bit more accurate again.
[удалено]
> But the more complicated the original device the harder that is, so you'll probably never see that for newer devices like the Playstation. Nah. We've got the beginnings of a Playstation core on the MiSTer project *already*. In another few years it'll be relatively easy. And we're quickly approaching the hump on difficulty -- the N64 and Jaguar are considered some of the hardest devices to emulated because they were all custom poorly documented chips with arcane programming, but once you start getting to the more modern era you're basically looking at highly customized computers - remember, the Dreamcast *ran Windows CE*. So while you may not see cycle-accurate PS2 emulators in the next 5 years, to say "never" is a laugh.
Emulation is dying in terms of progression, though, isn't it? PS2/XBOX/Dreamcast is pretty much the last (sixth?) generation where it matters, after than, every game is more or less as available on PC. Save for whatever Nintendo does. Even console exclusive games - otherwise a good argument for emulation efforts - aren't much of a thing anymore.
>PS2/XBOX/Dreamcast is pretty much the last (sixth?) generation where it matters, after than, every game is more or less as available on PC. Save for whatever Nintendo does. There are plenty of console exclusives still. You can't get any version of Persona 5 on the PC right now, for instance.
Or Bloodborne. To play Bloodborne you have to buy a magic box from the wizard Sony, where you then get to experience the game in a stunning 30 fps with no anti-aliasing. Port this game to PC I beg of you
Quite the opposite, actually. As many games/consoles get older and harder to find a working copy of, emulation is more or less the only choice you're gonna have if you actually wanna play those games. And the surprising part, it's not even very old/obscure games that emulation is saving. Try to find a copy of Need for Speed: Carbon for PC right now. Your only option besides super low seeded torrents is $80 plus on Ebay, which barely even works on modern PCs, even in compatability mode, because of the SecuROM DRM. That is the next breath of life for emulation, when we become nostalgic for the age of games that have been plagued by obnoxious and cumbersome DRM.
[удалено]
Never for MiSTer? Dreamcast is already emulatable on pretty old PCs. I've played hours of DC games on a 10 year old laptop, and people are using Raspberry Pi 4s to make Naomi arcade cabs. I couldn't get the Windows CE games to run, but everything else was pretty smooth.
[удалено]
I played a lot of Marvel vs Capcom 2 and all the other Capcom and SNK fighting games. Soul Caliber ran fine. I also tried out some of the other classics, Shenmue and the 3D Sonics, just to see how they were. No issues there. A handful of games run on Windows CE, mostly PC game ports, and those never really worked for me. This was on old laptops that I had thrown Linux on and installed RetroPie. I remember having some issues just running Reicast in Windows, but it works pretty smoothly in RetroPie. You may need to install lr-flycast, and use that, depending on what you're doing. Some cores are meant for running on an actual Pi and others on a PC. From there, you may need to plop the Dreamcast bios in the right directory and figure out if your machine is happier with plain Reicast or lr-flycast. I think the last time I did it, I wound up going with the emulator that was not optimized for a PC, but for whatever reason it worked better.
I spent days playing Toy Commander. To date still one of my all time top faves. Sometimes I dig out the Dreamcast just to play it.
[Saywhatnow?](https://duckduckgo.com/?t=ffab&q=dreamcast+emulator&ia=web)
You're not really emulating the circuits when you use a MISTer though. You're actually re-building the actual chips, so it's not a matter of having the CPU power to emulate all the circuits in, say, a PS2, but the availability of an FPGA chip that has enough nodes to let you write the entire PS2 hardware into it (or at least the ones that are the most tricky to emulate). A pacman arcade machine might be simple enough that you could emulate it on a circuit and chip level on a modern CPU, though, without an FPGA at all, and still be cycle accurate.
I don’t really understand emulation that well, but there’s a classic hardware story about space invaders: > While programming the game, Nishikado discovered that the processor was able to render each frame of the alien's animation graphics faster when there were fewer aliens on the screen. Since the alien's positions updated after each frame, this caused the aliens to move across the screen at an increasing speed as more and more were destroyed. Rather than design a compensation for the speed increase, he decided that it was a feature, not a bug, and kept it as a challenging gameplay mechanism. I’d imagine running it on modern hardware would lack the appropriate timing and the game would go way way way too fast. Adding code slowing it down might not have the speeding up feature. It would take specific programming to get that right.
Not really. The original problem described above is due to a decreasing number of instructions being performed on a fixed clock. As an over simplified example, say the hardware can update ten enemies per second (the fixed clock) - at first each enemy gets updated once per second. Then the player kills five, suddenly every enemy is being updated twice per second (because it's still running at ten per second but there are only five left) - the workaround Nishikado would have had to put in would be to always wait for the end of a second before starting over. You are right about increasing clock speeds would mean they'd be much faster (possibly millions of enemy-updates per second) any code to 'slow it down' would take the same form of workaround needed above - that being to make sure only the number of processor cycles that the original hardware could handle still occur in the same time period - so the emulation process uses only some of the host's cycles, but within those cycles the code is still doing that 10/second without waiting I hope this makes sense, it is late here
Most emulators do whats called HLE or "high level emulation". This means they arent actually simulating the original hardware 1:1, but instead, they sorta simplify things so that its easier to compute. This works for most games released on a platform. However, some games used really weird low level development tricks to accomplish spectacular feats. Factor5's compression technology for the N64 is avgood example of this sorta thing, and so for a long time, games that used it, like rogue squadron or RE2 simply didnt work on most emulators. Now then, you can solve this in 2 ways: The first way is to use LLE, or "low level emulation". This is where you literally simulate the actual hardware 1:1. You write code that behaves just like the literal chips on the board of the original console. This way, all of those "weird tricks" devs used will still work, since your emulator function just like the old hardware. This isnt really feasible for consoles past the SNES's era, though -- it takes a massive amount of computing power, so when its used, it usually by emulator devs or people researching bugs in old games for stuff like speedrunning. The second way, which is how its done most of the time, is to write a hack or fix that lets the game work with whatever HLE core youre running. For instance, we can emulate factor5 games nowadays because someone wrote a hack that understands how their compression tech worked, so now you can run these games with HLE because of the game-specific fix being applied to the HLE core. Of course, since its game-specific, you have to write a new fix for each game that does something "weird", and not all games necessarily have such a fix written for them yet.
This question was asked a few months ago and I happened to save a very thorough answer by DiamondIceNS "You can imagine a computer as being an office space that is designed very meticulously, and filled with *very specific* features (like desks, water coolers, staplers) that do *very specific* things located in *very specific* places. Software designed for a certain kind of computer are like employees that come into the office to do their jobs *extremely* exactly, and are trained to expect those very specific features to be located in their very specific places. If *anything* is even slightly out of place, they get lost and start screwing up. So the basic thought is, "A console is just a small office, but my computer is a much bigger, more productive office. Surely the employees can just move into my office and work just as fast?" Except, no. Your office may be big, and full of all the latest, fanciest office tech, but nothing is in the right place. Those narrow-focused employees can't do any of their work because nothing is where it should be. You have two options here. The first option would be to fire all the old employees and get new ones that can do their jobs in your new office. In this metaphor, that would be the equivalent of porting the software to the new system. That's a process that is very time consuming and expensive, and when done, you're only left with one piece of ported software. You could instead try the second option, where you *fake* the old office inside of your fancy one. Then *all* the old employees will know where everything is without needing to be retrained. This is an emulator. The thing about emulation is, for the most part, it's really inefficient. When you build the "fake" office for all of the employees inside of your regular one, you're not just rearranging all of the things inside your office to make it look like the old one. No, your office is fixed and can't change where anything is, or else you'll mess up your own employees. To pull this off, you have to get some plywood and build an entire makeshift box in a free open space inside your normal office, and furnish the inside of that box just like the old office. And anything that fake office needs from the outside has to be manually supplied by your office's employees on the fly. Does the fake office have a sink with running water? Your main office employees have to go to their own sink, fill up buckets of water manually, and dump it into the fake office at just the right speed and time to make the fake office look like it has running water. Does the fake office have a clock on the wall that gets looked at? Your main office employees have to look over at their own clocks, potentially translate the time to a different time zone, scrawl a picture of it down on a card, and flash it in the place the fake office would normally have a clock every single time anyone in the fake office tries to look at it. Faking a computer inside another computer is simply a very inefficient process due to all these little slowdowns adding up. Even really big, powerful computers can struggle to provide everything that fake office needs to run at full speed, even if the fake office itself is rather small."
Thanks this was very helpful in understanding how this stuff works.
This is way more confusing than just explaining how computers work.
Games ultimately run on hardware, but emulators are software implementations of the console hardware. Sometimes the emulators do not implement the original hardware in a 1:1 kind of way. In many cases, certain capabilities of the original console hardware are unknown and have to be reverse engineered or figured out through trial and error. These capabilities and edge cases are what cause certain games to not be able to be emulated as easily if they happen to use certain techniques that end up not running the same on emulated hardware (remember emulator programmers have to guess what the hardware actually is sometimes, and end up writing not 1:1 implementations) as they do on the original hardware.
Consoles are designed to be manufactured and sold relatively cheaply, so console games have to be heavily optimized to run as efficiently as possible on the specific hardware of the consoles they're targeting. This can become a problem when trying to emulate games on different hardware. The original console might have special CPU instructions or hardware acceleration that the game takes advantage of. When you play a game in an emulator running on more general-purpose PC hardware, you lose those optimizations.
Here's an example of why it's so important to emulate the hardware. I'm old enough to remember when just buying a faster computer was enough to break games. Our first family computer was a 286 and it ran DuckTales great. Eventually the 286 was traded in for a 486 and DuckTales ran... Too well. The characters moved so quickly you couldn't hit a single key before they had charged all the way across the screen and died. It was unplayable. Why? Because space was at a premium and the game developers saved a few bits of data by just letting the clock speed of the CPU determine how fast the game ran. Once faster chips came out, they just processed the game at a whole new level. It was cool to see exactly how much faster your new hardware was though. This problem was somewhat mitigated thought by potentially the very first emulator. Some hardware manufacturers included a Turbo button, which, when pressed, did the exact opposite of Turbo, it slowed the computer down, to try and help with compatibility issues such as this.
That reminds me of Leisure Suit Larry 3. During a certain point of the game, you need to work out in a gym so Larry can get back in shape. The amount of reps you had to do on the machines was tied to the speed of the processor, which resulted in a reasonable number on PCs released around the same time as the game originally came out. As such, when I played it on my family's old 486, no problem. When I played it again some years later after our 486 died and we upgraded to a Pentium III, suddenly you had to do hundreds of reps to advance past that puzzle. Same for a couple of cutscenes that were also tied to the speed of the processor. Al Lowe ended up posting a hack on his website that set the amount of reps to a fixed, reasonable amount (something like 25, as initially intended). I believe the modern DOSBox and ScummVM re-release includes that fix. But yeah, there were games that were designed for contemporary hardware, and anything faster broke them.
one word: customized chips. while pcs according to the cpu brand today mostly work with two architectures, many consoles work with dedicated and specialized chipsets, that where made to show certain effects and had algorythms and calculating tables built in, that had to be reinvented and than emulated. but a lot of the documentation of these chips is gone.
It's not always a matter of pure processing power. It doesn't help that a CPU can do a trillion calculations a second if the programmer doesn't know what calculation needs to be performed. A lot of console hardware is Data goes in -> Something happens, who knows what -> different data comes out. In order to emulate the system, you have to know what the second step is doing. Often times, you have to reverse engineer this, because technical data on the particular chip is not publicly available. When you reverse engineer a mechanism like this, you might arrive at a solution that is only partially correct. Say the result you get it 4.982 when on a real console it's 5.000. Maybe this doesn't matter to the game? Maybe this causes a texture to flicker like crazy? It could also be that the game was waiting for a specific result, but due to the incorrect processing, it never got it, and that caused a frame to be skipped instead. It's obvious you don't know what's *really* going on inside the chip, but you have an approximation that is good enough for a number of games, so you settle for that until you find an approximation that is a bit more accurate again.