A while back I was going through Dolphin’s issues page out of sheer boredom.
I don’t know anything about coding to fix any of this stuff, but I do like to test really old issues sometimes to see if the hundreds of changes made over the years has produced any change or potentially even fixed some of the issues. After a few pages, I eventually came across issue 726 – Gamma setting has no effect. Out of curiosity, I clicked.
This is a great story about a very obscure and technical bug in the Dolphin GameCube emulator.
How much accuracy you expect from your emulator also affects the resources required, and possibly the emulation speed.
Things about intricacies of memory architectures or video frame-buffers come along often.
For example, this too could be a fun afternoon read:
https://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-mans…
sukru,
That’s a very interesting link. Clock cycle perfect CPU emulation is extremely inefficient in software. I think better solution, from a technical point of view, would be to use an FPGA to emulate the original CPU/accelerator circuits as they were. These could accurately emulate each clock cycle of the original hardware, and do so quickly.
I think this could be one of many innovative uses for FPGAs, but until they become cheaper and more widespread, it’s likely a no-go for the retro gaming crowd who tend to use cheap hardware like raspberry-pi.
Depend on the value you put on “cheap”. Look at the MiST or Minimig…
Kochise,
These are all 16bit targets, right? It seems expensive to me given that it’s in the same price range as an xbox. Maybe for someone who really values accurate emulation might find that price acceptable, however they’d have to accept that it’s a work in progress and that higher accuracy may not be possible on entry level FPGAs.
Edited 2018-06-28 08:24 UTC
Looking at the links on that page, I’m not at all surprised that it’s offered through DragonBox.de.
https://www.dragonbox.de/en/364-mist-fpga-13-plus-midi-consoles-4260…
EvilDragon is a great guy and very dedicated.
(eg. He also took over responsibility for producing the Retrode when its creator wanted to bow out and is the dependable member of the original OpenPandora pair who is now near the end of the process to produce its successor, the DragonBox Pyra.)
Edited 2018-06-28 10:44 UTC
That list of computers/consoles? Nope. A large proportion of them are 8bit z80 or 6502 (family, as the c64 wasn’t exactly a 6502.)
henderson101,
Yeah, that’s what I said in my other post. Obviously if 16bit is supported, 8bit is also. My question was really regarding numbers greater than 16bit, like 32bit.
pmyteh mentioned the Archimedes being 32bit. I wonder if this FPGA will execute it as efficiently as a 16bit processor or if it takes a performance hit to emulate 32bit. It depends on what the FPGA was designed to do. It’s like how a 32bit processor can easily do 16bit (or 8bit) math, but the opposite will require more cycles.
If they emulate the Amiga 1200 then they must be emulating a Motorola 68020, which is a 32bit CPU.
Vanders,
Yes, but I think everyone’s missing the crux of my question. Their own documentation says it was designed for “16bit” at various points in documentation, it’s not me saying it but them. So I’m not sure if there’s any kind of performance loss for 32bit. Saying “it supports X, which is 32bit” doesn’t answer my question.
Doing a bit more digging…
According to this link, the memory bus is only 16bits wide, so that alone could half the performance for 32bit access versus 16bit access.
https://github.com/mist-devel/mist-board/wiki/TheBoard
According to this spec sheet for the Altera Cyclone EP3C25 FPGA used by Mist, it appears that it uses 18bit multipliers.
https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/lite…
So I’m satisfied this explains why the MIST hardware configuration is “designed for 16 bit” rather than 32bit. Various hardware limitations will require 32bits to be computed in multiple passes. However these factors probably don’t matter for this application given how much faster the FPGA solution & ram can be clocked compared to the original processors: 200-500MHZ versus 10-25MHZ.
https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/lite…
http://www.cpu-world.com/CPUs/68020/
Edited 2018-06-30 19:01 UTC
MAME also strives for accuracy, seemingly without too huge hw requirements.. Too bad there doesn’t seem to be such PlayStation 1 emu, popular ones all focus on “enhanced” visuals (turning textures into soap…); but I like the original PS1 ~rough look… there’s only old Connectix Virtual Game Station, or its hacked version Emuraiden, that aims for quite accurate visuals (with very low hw requirements), but it’s kinda hard to get working on current OS.
Anyway, is the approach with FPGAs really “emulation”? “Simulation” maybe? “Re-creation”?
Edited 2018-06-30 21:26 UTC
zima,
In theory every logic gate of the original processor could be implemented in an FPGA, is that emulation or recreation? I doesn’t bother me what people want to call it, as long as we understand each other. Let the semantics police figure that one out. Actually you seem to do a pretty good job of it(*), I nominate you for this position, haha
* http://www.osnews.com/thread?657671
It doesn’t count as a re-creation unless the thing being re-created aims to be as close to identical to the original as possible from outside.
(An FPGA isn’t pin-compatible with the original chip, so it doesn’t count as a re-creation. However, an Altair 8800 re-creation may use an FPGA inside it, as long as, when it’s closed up, it aims to look and acts like the original device.)
As for emulation vs. simulation, replicating the original chips in an FPGA blurs the line, but this would probably count as emulation based on the goal.
Historically:
– Emulation meant replicating the observed behaviour, no matter how many under-the-hood tricks were necessary.
– Simulation meant being accurate to the original’s internal function to a degree of accuracy suitable for training and/or hypothesis testing, regardless of how slow it had to run to achieve that.
Hence, traditionally, we’ve had game emulators and circuit simulators.
Edited 2018-07-01 21:18 UTC
ssokolow,
Yea, I can see it both ways. One problem with (high speed) emulators is that they translate the code but loose cycle accuracy compared to the original. Ideally we’d have the original processor’s exact opcode timing specs and create a modern processor/FPGA to execute the exact same logic without any tricks to run the exact same computation cycles.
Edited 2018-07-01 23:24 UTC
*nod* Hence my point about emulation vs. simulation being defined by priorities/goals rather than how they’re accomplished.
Edited 2018-07-02 14:16 UTC
Words can and do change meanings… perhaps “re-creation” should include FPGA machines; at the very least they seem somewhat different from more traditional emulators (because they – wait for it – sort of re-create whole old computer or console in an FPGA)
MIST has a 486 PC core which is definitely a 32-bit target. Unfortunately the 486 core does not have an FPU yet which is pretty critical for a lot of games and was what made the 486 CPU such a popular upgrade beyond the 286/386 PCs that preceded it.
Darkmage,
Yes, I’m glad it got posted here as I had never heard of it before. FPGAs are certainly a good choice for accurate execution of older software on new hardware. Here’s a very good overview about it for anyone who wants to learn more:
https://github.com/mist-devel/mist-board/wiki/WhatIsThis
The Acorn Archimedes is a 32-bit architecture (and it looks like they have the ARM2a core in beta at least) so it seems it’s not limited to 16-bit by design.