As I recently discussed with my other article about FPGAs. When will High-Performance FPGA come?
Youtube channel RTL Engineering has been working on an FPGA upgrade that will succeed the current MiSTer FPGA platform to run game console from the '90s to the early 2000s. This is obviously a hard task since those consoles have very unique hardware. Someone is currently working on a PlayStation 1 FPGA, so far it has impressive results.
RTL Engineering has made a graph for the potential candidates for the FPGA implementations.
Green is for the current MiSTer FPGA
Red is too fast for the current FPGA and impossible to run.
Blue are good candidates for a High-Performance FPGA
Orange is for candidates for an exclusive FPGA on there own since they have more complicated hardware.
I was looking at an Open System-on-Chip (SoC) called the MIPS Creator CI20 that has a MIPS32 1.2 GHz dual-core CPU and MIPS is now open source through it's MIPS Open initiative.
I asked RTL Engineering,
Would a MIPS powered FPGA work better for PS1, PS2, and N64? Since all 3 systems, we're from MIPS Architectures. MIPS is open-source now.
RTL responded,
"That would depend. First of all, I'm not sure what you mean by a "MIPS powered FPGA". Do you mean an SoC based FPGA, with a MIPS CPU coupled to FPGA logic? If so, such a thing does not currently exist, and to create such a thing would require an investment of a couple hundred Million USD. As for MIPS being open-source. As far as I am aware, MIPS has never been, and never will be "open source". MIPS is effectively an alternative to ARM and is treated and sold the same way (MIPS is actually more expensive than ARM). There was an "Open MIPS" core at one point for academic use, however, MIPS has since discontinued it, and it was always a stripped-down and crippled version.
As for being able to run PS1, PS2, and N64 code on a MIPS CPU, that might work, but it's not guaranteed to work correctly. The problem is that MIPS works with the idea of specialized co-processors. Where there are specific instructions to access those co-processors. The PS1 attached the GTE (which did the 3D math) to co-processor 2, and all of the instructions were executed via co-processor 2 instructions. Unless the MIPS CPU has a GTE in the co-processor 2 slot, then those instructions would either end up causing an exception or unintended behavior. The same thing goes for the PS2, where it attached one of the VPUs (a 4-element vector processor, once again for 3D math) to co-processor 2. The N64 code is the only one that relied on a more typical off-the-shelf MIPS CPU, however, it had its own quirks, and the N64 code was highly coupled to the timing and execution of the CPU. And that leads to the second problem, which would be execution latency. Even if the PS1/PS2/N64 code could run on a MIPS processor in general, the time it takes to execute the code could be longer or shorter in an unpredictable way, and could very likely make any game unplayable as a result. In reality, the only way to successfully implement hardware solutions for those platforms is to try to reproduce the hardware 1:1.
Hopefully, that answers your question."
I was really confused that he said that MIPS had discontinued its an open-source program, but it still has news and updates on the official website. So, unless he doesn't know yet or something else.
Then I said:
Ah, I understand. I just thought it would be "easier" to run MIPS native games smoother on MIPS than ARM. Mimicking the original EE/GS hardware.
This device is why I brought up the question, it's not a PDGA but an SoC. https://elinux.org/MIPS_Creator_CI20
RTL replied again:
"Sadly that SoC only contains a CPU. While software emulation has its drawbacks, if you had to run part of the system on an ARM processor, you would be better off running a CPU emulator than a GPU emulator, since the CPU execution is more tolerant to timing differences (that's the idea behind hybrid emulation if you didn't know). Unfortunately, you would still have problems with the PS2, due to the tightly coupled vector unit in the Emotion Engine (I'm not sure how the current PS2 emulators solved that problem).
A few places where having a CPU with the original architecture could be very helpful, would be in the original Xbox and in the GameCube / Wii. In both cases, the CPUs were attached via a front-side bus (very similar to the N64 architecture), and therefore as long as the native CPU is compatible, it would effectively act as a black box. As I recall, IBM still produces PowerPC chips with a front-side bus, however, Intel stopped doing so when they phased out their Z5XX Atoms (I did look into using one of those - which is why I proposed a socket for a 486 in the video). Similarly, you could, in theory, do the same thing with one of the CPUs from the MIPS Creator boards for the N64, however, the N64 was slow enough that you would end up with timing issues as stated before. 93 MHz was slow enough that you could in practice couple your code to IRQs and the internal MIPS timer. The Xbox and GameCube, on the other hand, were ~700 MHz and 450 MHz, respectively, which would be impractical to time so precisely, and therefore both relied on a kernel (a small OS - as I recall, the Xbox actually used a stripped-down version of Windows), which abstracted away the processor details.
If you really wanted to, however, with a CPU socket like proposed, one could build an adapter board and attach any CPU with a front-side bus to that FPGA setup (including a MIPS CPU - though it couldn't be an SoC)."
The Playstation 1 and 2 are one of my favorite systems and I would love to see an open-source fork of it with high accuracy, but it will be a long awhile before that happens.
I have discovered MIPS FPGAs but probably not for gaming, but who knows.
Comments