Pushing ao486 core to its limits: Diablo II, Age of Empires, Simcity 3000, Starcraft -Win98SE

[Caldor]

@SuperBabyHix nailed it. The existing core already struggles to hit 100MHz of _internal_ speed due to this, and that nets about a 33MHz real-world equivalent. The idea of getting to Pentium 90 levels, even with hand-crafted optimal code, on the DE10-Nano is pure fantasy.

I don't understand why we can't appreciate the beauty of a thing for what it is without having to pretend it's also made of rainbows and unicorn poop. :/

Then what speed on the Cyclone V SE is it that limits it from running as a Pentium 90mhz while a Virtex-4 LX200 can? The LX200 is top of its class, while the Cyclone V SE of the DE10-Nano is at the middle and maybe even below middle of its class of FPGA, but the Cyclone V is about a decade after the LX200, and even when the LX200 was running as a 75hz Pentium Pro, it was not even using half its ressources. Then they optimized that and got it to run even better.
https://www.researchgate.net/publicatio ... top_system

I must say I did think the DE10-Nano was 14nm or better rather than 28nm, but it is a bit old and FPGA development is not exactly moving as fast as ARM or x86 development. But what is this speed limitation you keep referring, referred to as?

[rhester72]

@Caldor - #irony, mate. I seriously think you need to re-read that article, with assistance from a hardware-minded friend if necessary. It does not even remotely say what you think it does.

[Caldor]

Because my mind literally wobbled at the thought, I actually bothered to look up the Pentium FPGA thing:

https://www.researchgate.net/publicatio ... top_system

So...someone did indeed implement a Pentium core at 25MHz on a $900 (US) Xilinx Virtex-4 FPGA in a lab setting with heavy-duty cooling. They go on to say that if manufactured in silicon with a 90nm process, you could extrapolate and say it's the equivalent of a 760MHz Pentium...which is like saying that if you could scale an ant up to human scale, they could carry 750,000 lbs of weight. It's true - at human scale. The trouble is, ants aren't human scale, and the Virtex-4 isn't anywhere in the same ballpark as 90nm silicon fabrication.

So the moral of the story, such as it were, is that if you had a FPGA three times faster than the Cyclone V, you could achieve 25 MHz Pentium performance, which I fully believe.

Ahh yes, I had missed that they had clocked it that low. That does explain a bit. Still wondering how you argue that FPGA is three times faster than the Cyclone V?

[rhester72]

I must say I did think the DE10-Nano was 14nm or better rather than 28nm, but it is a bit old and FPGA development is not exactly moving as fast as ARM or x86 development. But what is this speed limitation you keep referring, referred to as?

Switching speed, measured in MHz. It's how many state changes one gate can reliably execute per quanta, and it does vary fairly widely between FPGAs (and obviously with price). The fastest FPGA gates on the planet right now remain orders of magnitude behind the switching speed of processor dies from a decade ago because of their very nature.

[rhester72]

Ahh yes, I had missed that they had clocked it that low. That does explain a bit. Still wondering how you argue that FPGA is three times faster than the Cyclone V?

I read the product sheet from Xilinx.

[Caldor]

Ahh yes, I had missed that they had clocked it that low. That does explain a bit. Still wondering how you argue that FPGA is three times faster than the Cyclone V?

I read the product sheet from Xilinx.

Then.... answer the question maybe? I read that as well, I am asking how its defined. What numbers are you looking at to come to such a conclusion, vs the numbers of the specs of the Cyclone V?

[rhester72]

Please compare the Xilinx speed grade of -12 (one of the fastest ever created) of the researcher's sky-is-the-limit-money-is-no-object university-research-grant FPGA to the I7 speed grade of the DE10-Nano used in introduction-to-FPGA-for-beginners, not-fast-enough-for-industrial-automotive-automation FPGAs.

[To put things in Xilinx terms, speed grades are separated by about a 15% switching speed. Roughly speaking, Altera-nee-Intel's I7 is somewhere in the neighborhood of Xilinx's -4. -4 to -12 is 8 steps, and if you call -4 100% performance, adding 15% 8 times gets you 305.9%, or just a hair over three times faster.]

I can't (and won't) turn the forum into a class on FPGA 101, but everything you want to know is literally available for the reading. It sounds like you're interested in learning (and certainly very enthusiastic!), and you literally couldn't have picked a better platform to do it on...the DE10-Nano is EXCELLENT (for what it is), particularly in terms of LU count available.

What I will strongly caution you against is making wild claims on forums about current and theoretical performance, because others who are also not terribly familiar with FPGA architecture will read them and make gross assumptions about things that simply aren't even close to true that will cause their expectations to exceed anything remotely possible...and then bug the hell out of developers wanting to know why they can't have a PS4 core on their $400 MiSTer setup RIGHT NAOW.

Read, learn, understand, and if you still have questions, please come back and ask...sincerely.

(Edited because I forgot to show my math.)

[Caldor]

Sometimes I make the wild claims to see what bounces back. If I am completely off the mark, as it seems I was here, I would hope something would bounce back and it did. Because I have been working under the theory that there was not actually a speed limit to the logic gates, that they would be configured and then the limit of their speed would mainly be well, the number of resources on the FPGA. I know some of these FPGAs cost 10k dollars, some probably cost more, and I already mentioned that the DE10 Nano is not top of the line.

But I was hoping that with the other FPGA used in that research being from 2005 and the FPGA we are using here being from 2013, that it would end up being faster. But these are the two main competitors when it comes to FPGAs, and they describer their FPGAs quite differently, so it is hard to see any direct way of comparing the two.

But thank you for answering. I appreciate it.

Testing and debugging the releases becomes easier if you know what you are testing for I think. I do have to agree that I cannot find much that indicates the core is faster, or at least not much faster, than a 33MHz 486. I had hoped Descent might have indicated it was, but Descent has 33Mhz 486 DX2 as its recommended specs.

I have noticed level 1 cache is still disabled in the core and I am wondering if that might be causing some of the issues we are seeing, where only having level 2 cache might improve the speed in some games and benchmarks, but I would find it odd, if there were not also downsides to doing it. So I think I will try to make a build that does include level 1 cache again to see how that affects games and benchmarks. I thought level 1 cache had been added back again, but if it was, I guess it was also removed again.
Edit: Seems lvl 1 cache is activated again. Not sure what it was that made me think it was still not active. Pretty sure I saw something while using AO486, but according to the source-code, it is active, and has been worked on even in the update 12 hours ago that I have been testing Descent with.

[Caldor]

I found another report on an FPGA, that seems to accomplish performance comparable to a 200mhz Pentium. There is a LOT of detail about how they got to get to this performance and some comparisons to earlier work, and some of that earlier work seems to be the report we already looked at from 2005. The FPGA used in 2005 was a 90nm FPGA, the research in this report was done using a 40nm FPGA from what I can read. I might have been overlooking something again though.

HenryThesis.png (127.95 KiB) Viewed 8966 times

HenryThesis2.png (96.58 KiB) Viewed 8966 times

He does implement FPU emulation in his core, but writes this about it:
"Floating-point unit While our current design uses FPU emulation to provide the functionality of a
x87 floating-point unit, the performance overhead is so high that it is impractical for any workload that
uses on the order of 1% or more of floating-point instructions. The emulation mechanism (described in
Appendix A) also complicates the design of the integer portion of the processor. A hardware floatingpoint unit is essential."

So... FPU done within the FPGA does not seem like its viable as it is now. Hardware FPU is essential he says... could be nice if it would somehow be possible to use the FPU in the ARM... but I am guessing that would probably add latency also... but I guess any hardware solution would add latency.

But as far as I can tell, it really seems he has achieved performance that is comparable to maybe even a 233Mhz Pentium Pro.

HenryThesis3.png (97.07 KiB) Viewed 8966 times

Here is the full report:
https://www.stuffedcow.net/files/henry-thesis-phd.pdf

Even if this might not be possible to do on the Cyclone V, I am thinking there must be something to learn from this paper at least. But the core developers might already know about it.

[R4mbo]

Dosbox has a lot of performance issues.And weird.speed changes along the game.

486dx runs games much better than dosbox

I get almost all old games run perfectly in DosBox. Like, over 90%.
It mostly depends on setting the Cycles correct in the config file.
I give you a few examples from my config file for "The 11th hour" which is really ressource hungry. For most games you need to put Cycles down to 20k, 8k or even less.

---
machine=svga_s3
captures=capture
memsize=32
---
fullscreen=true
fulldouble=false
fullresolution=original
windowresolution=original
output=surface (This will give you fullscreen on Windows Machines)
---
core=normal
cputype=pentium_slow
cycles=40000
cycleup=10
cycledown=20
---
Thats the most important settings.

Bonus:
[autoexec]
# Lines in this section will be run at startup.
# You can put your MOUNT lines here.
mount c Festplatte (<- This is a directory)
imgmount D CD\1.cue -t iso -fs iso
c:
GO
exit

[Caldor]

I get almost all old games run perfectly in DosBox. Like, over 90%.
It mostly depends on setting the Cycles correct in the config file.
I give you a few examples from my config file for "The 11th hour" which is really ressource hungry. For most games you need to put Cycles down to 20k, 8k or even less.

This is my experience as well... I remember having some games that seemed impossible to run on my Raspberry Pi 3B+ but then I found some settings that would make them run great. The Pi 4 is even better so but I have not tried seeing how much it might have improved and what extra performance there was to be gained for DOS games, because instead I was looking into running Windows 98 on it and Windows 98 games. Which also works quite well, but its by using QEMU instead of DOSBox.

That said, there might still be some timing issues, its just hard to know when its down to something that can be fixed with a better configuration and when its some actual limit or problem with DOSBox or the hardware.

[R4mbo]

I get almost all old games run perfectly in DosBox. Like, over 90%.
It mostly depends on setting the Cycles correct in the config file.
I give you a few examples from my config file for "The 11th hour" which is really ressource hungry. For most games you need to put Cycles down to 20k, 8k or even less.

This is my experience as well... I remember having some games that seemed impossible to run on my Raspberry Pi 3B+ but then I found some settings that would make them run great. The Pi 4 is even better so but I have not tried seeing how much it might have improved and what extra performance there was to be gained for DOS games, because instead I was looking into running Windows 98 on it and Windows 98 games. Which also works quite well, but its by using QEMU instead of DOSBox.

That said, there might still be some timing issues, its just hard to know when its down to something that can be fixed with a better configuration and when its some actual limit or problem with DOSBox or the hardware.

Ye, I use my GamingPC to run Dosbox. The Pi might get in Trouble running 40k Dosbox Cycles. At some point if they are to high everything will slow down again.

[R4mbo]

I still would prefer a nice X86 Core on the Mister, one thing I anticipate the most would be working network function. You can use NE2000 Adapter in Dosbox, but its complicated and not portable and relies on external services.

Would be insane to link 2 Misters some day and play Duke3D over IPX

[Caldor]

I still would prefer a nice X86 Core on the Mister, one thing I anticipate the most would be working network function. You can use NE2000 Adapter in Dosbox, but its complicated and not portable and relies on external services.

Would be insane to link 2 Misters some day and play Duke3D over IPX

That would be pretty awesome... there is already support for Internet over modem though, and... f.ex. Duke should support using a modem, but, not sure it works in a way where it would works with the modem play feature.

[rhester72]

Not sure why it wouldn't - anything that used a modem should be usable on ao486, it's a _very_ generic implementation.

[SuperBabyHix]

Hardware FPU is essential he says... could be nice if it would somehow be possible to use the FPU in the ARM...

Talking about what-ifs is fun and all, but I just want to make sure people have realistic notions. I've said this before, an FPU is not going to have any worthwhile impact on the gaming performance of the core. With few exceptions, pre-1996 DOS games just didn't take advantage of it. Falcon 3.0, Sim City, and maybe a few others did. By the time you get to the era where many games took advantage of an FPU a 486 is already too slow to run them playably. Quake, on the fastest 486 I've ever heard of (an overclocked AMD 486 running at 200Mhz) gets 18fps. A DX2-66 gets all of 8 FPS. Not really playable. Duke Nukem 3D apparently only uses the FPU for slopes (https://fabiensanglard.net/duke3d/build ... ernals.php). I just don't want people to think an FPU would be some huge game changer, pardon the pun. In my opinion, it would be a lot of work for devs with very little payoff.

[Caldor]

Hardware FPU is essential he says... could be nice if it would somehow be possible to use the FPU in the ARM...

Talking about what-ifs is fun and all, but I just want to make sure people have realistic notions. I've said this before, an FPU is not going to have any worthwhile impact on the gaming performance of the core. With few exceptions, pre-1996 DOS games just didn't take advantage of it. Falcon 3.0, Sim City, and maybe a few others did. By the time you get to the era where many games took advantage of an FPU a 486 is already too slow to run them playably. Quake, on the fastest 486 I've ever heard of (an overclocked AMD 486 running at 200Mhz) gets 18fps. A DX2-66 gets all of 8 FPS. Not really playable. Duke Nukem 3D apparently only uses the FPU for slopes (https://fabiensanglard.net/duke3d/build ... ernals.php). I just don't want people to think an FPU would be some huge game changer, pardon the pun. In my opinion, it would be a lot of work for devs with very little payoff.

FPU is a pretty small part of this report, and it seems to suggest overall that FPU is pretty unlikely to happen for this core.... well the core he was working on. But still, what is interesting is that he used the same amount of FPGA logic space that the MiSTer to make the FPGA run as a 200Mhz Pentium. I think he mainly gave it FPU to be able to benchmark it a bit more broadly. The FPGA he used was probably faster than the DE10-Nano though, but the report still has a LOT of interesting information about his process and discoveries as he made this core and tested it.

Not sure why it wouldn't - anything that used a modem should be usable on ao486, it's a _very_ generic implementation.

That could be pretty nice to try. Its just that I think these games relied on the modem to be used by the game to call the phonenumber of the modem the of the other player. Not sure how that would work with this, but I do think something similar has been done on the Amiga where a modem addon was made that gives the Amiga Internet access through regular LAN routing, so that it would use WiFi or a LAN cable, but the Amiga would see it as a dial up Modem connection if I am not mistaken.

[Lisko]

Not sure why it wouldn't - anything that used a modem should be usable on ao486, it's a _very_ generic implementation.

That could be pretty nice to try. Its just that I think these games relied on the modem to be used by the game to call the phonenumber of the modem the of the other player. Not sure how that would work with this, but I do think something similar has been done on the Amiga where a modem addon was made that gives the Amiga Internet access through regular LAN routing, so that it would use WiFi or a LAN cable, but the Amiga would see it as a dial up Modem connection if I am not mistaken.

Mister midilink also implements this when you set uart to midi/remote/tcp and is working well. [*]The problem is that that the dial-up is emulated in a way where you call an ip instead of a phone number, usually to connect to a bbs. The problem with gaming is that in its current state the modem is able only to "call" but not to answer if another modem calls you because it was intended for bbses which are hosted on their own daemons. So in its current state it isn't suitable for multi-player gaming, a daemon needs to be implemented so that the two modems can talk together.
EDIT: I was very wrong. When uart is in midi/tcp or udp mode also a full featured daemon for incoming calls is running. You could have two misters doing modem multi-player by simply calling their ip or via null-modem using udp mode and the ip set in midilink.ini

[Caldor]

Mister midilink also implements this when you set uart to midi/remote/tcp and is working well. The problem is that that the dial-up is emulated in a way where you call an ip instead of a phone number, usually to connect to a bbs. The problem with gaming is that in its current state the modem is able only to "call" but not to answer if another modem calls you because it was intended for bbses which are hosted on their own daemons. So in its current state it isn't suitable for multi-player gaming, a daemon needs to be implemented so that the two modems can talk together.

That is pretty awesome. These old games usually played quite well with just this type of connection anyway.

[bbond007]

The problem with gaming is that in its current state the modem is able only to "call" but not to answer if another modem calls you because it was intended for bbses which are hosted on their own daemons. So in its current state it isn't suitable for multi-player gaming, a daemon needs to be implemented so that the two modems can talk together.

This is absolutely NOT true! Where did you get this info?
From over 1.5 years ago:
https://youtu.be/lVhUU7xzhrE
https://youtu.be/TH1GDu2Da9A

The Remote/TCP(Modem) mode answers on port 23 by default but this can be changed in "/media/fat/linux/MidiLink.INI"

Code: Select all

TCP_SERVER_PORT = 23

Multi-player can also be done with the Remote/UDP option.
This method works like a null-modem connection meaning you forgo the need for Dialing...

In this example I have 2 MiSTers, hostnames MrA1200 & MrCD32. If you don't have unique host-names, you can use IP addr.

"/media/fat/linux/MidiLink.INI" on MrCD32

Code: Select all

UDP_SERVER = MrA1200

on MrA1200:

"/media/fat/linux/MidiLink.INI" on MrA1200

Code: Select all

UDP_SERVER = MrCD32

[Caldor]

Oh... I completely misread that post before... I read it as it DID support multi-player. But I guess its just TCP multi-player it wont support, but UDP works?

[lroby74]

I prefer a lot PCem rather than DosBox, at least you can emulate old real PCs (8088 - Pentium 1) and games like Aladdin plays very better

[Lisko]

The problem with gaming is that in its current state the modem is able only to "call" but not to answer if another modem calls you because it was intended for bbses which are hosted on their own daemons. So in its current state it isn't suitable for multi-player gaming, a daemon needs to be implemented so that the two modems can talk together.

This is absolutely NOT true! Where did you get this info?
From over 1.5 years ago:
https://youtu.be/lVhUU7xzhrE
https://youtu.be/TH1GDu2Da9A

The Remote/TCP(Modem) mode answers on port 23 by default but this can be changed in "/media/fat/linux/MidiLink.INI"

Code: Select all

TCP_SERVER_PORT = 23

Multi-player can also be done with the Remote/UDP option.
This method works like a null-modem connection meaning you forgo the need for Dialing...

In this example I have 2 MiSTers, hostnames MrA1200 & MrCD32. If you don't have unique host-names, you can use IP addr.

"/media/fat/linux/MidiLink.INI" on MrCD32

Code: Select all

UDP_SERVER = MrA1200

on MrA1200:

"/media/fat/linux/MidiLink.INI" on MrA1200

Code: Select all

UDP_SERVER = MrCD32

Oh sorry my fault! I always thought that tcp and udp server options were only for midi... This is really awesome and surely needs more highlighting in readme and wiki!

[Caldor]

I prefer a lot PCem rather than DosBox, at least you can emulate old real PCs (8088 - Pentium 1) and games like Aladdin plays very better

PCem is certainly awesome, but also pretty demanding. Even brings the most high end PCs to its knees when trying to emulate a system with more than 266Mhz I think it is. I think with less than 3ghz, you should probably only expect to be able to run a Pentium 100.

It is pretty awesome how it emulates all the hardware, so you even get to setup the bios, install the correct drivers and so on. I also found that it actually does support VHD disks instead of just IMG, its just not especially obvious that it does. VHDs are just much easier to work with, but I used IMGs for the most part. It even has support for 3DFX, just not sure how good it is.

But the MiSTer is an FPGA, and it is already possible to connect it some to real hardware like MIDI, and as this thread just got into, it also has network support so that two MiSTers could play against each other. Although... that might also be possible with PCem, not sure.