MiSTer FPGA Forum

Hi all,

First, thanks to Alexey, the idea to recreate a fully working DOS computer with the hardware you can buy and maintain today is amazing.


This week I will be receiving my MiSTer and I plan to make an exhaustive benchmarking over a catalog of 192 DOS games and software (from 1986 to 1996) on this core. A quite wide test from "Livingston Supongo", "La abadía del crimen" to other more modern games like "HOMM II".

I know this core performance was between a 286-386 a year ago (https://www.youtube.com/watch?v=-NkXthbbA-M) and we will always have other insurmountable limitations like the lack of FPU.

But I wonder if someone has an idea of the potential of the Terasic board in general (documents and other studies about fpga for complex processors are quite optimistic https://www.stuffedcow.net/files/henry-thesis-phd.pdf) and the ao486 core in particular to become a reliable ~486sx computer. Perhaps we could share some common bottlenecks, like the memory access https://github.com/alfikpl/ao486/issues/4, to help the community explore some solutions.

At the current state I think this is probably the best solution to have a fully working standalone DOS system today (not just game emulation on a PI) but with a little improvement MiSTer could cover the most part of the greatest era of the computer gaming history.

Is there margin to improve?. What would be the theoretical limit compared to a commercial late 80s, early 90s processor?.


Best,

I'm sure i486DX-40/50 is quite possible. And FPU too.
But it needs self-motivated knowledged dev to re-write the CPU. Current CPU is kind of script-generated, so it's not optimized.

I've been playing with this a lot of the last week or so, and only found a few glitches. I think, aside from the missing FPU, to make this a viable DOS box for anything past 1990, it really needs SVGA support. Being locked in at 640x480 for 'newer' games from the mid-90s would be kind of a drag.

Although SVGA would be nice to have, that would be opening a whole can of worms.

At this point I am not even sure we have enough logic gates available to implement a SVGA card as this core is already huge.

Currently the core runs somewhere between a 386DX25 and a 486SX25 and a great deal of games are compatible with it. The ones that are the most challenging are the older ones, so a Speed selector (to decrease the speed) in the core would also be nice.

But as Sorgelig has mentioned, this core needs a self-motivated knowledged dev, and I don't think we have any at the moment dedicating time to this core. I may be wrong though.

My first step would be to reduce the amount of logic used by the sound card, which has about the same logic size as the processor and i don't really see why.
The core is just too large in the current status to add many improvements.

Did someone ever got a simulation of the core running?
We could probably find some improvements then.

But in the end, i would not expect too much performance. X86 is not an easy architecture, so anything above 50Mhz real performance is probably very hard to reach.

40MHz for i486DX is awesome performance. It's probably 5 times faster than current implementation.
Sound card can be left as-is. Currently it's smallest implementation of OPL3 (using softCPU core). Did you look into MiSTer port or original ao486 core? Original ao486 includes monstrous very buggy OPL2 core (about 4 times bigger than OPL3 used in MiSTer version).
For debug purpose the whole OPL3 can be omitted. And even the whole soundblaster is not required for PC. And when CPU will be re-created, then sound card can be added back. Anyway, sound card has nothing to do with core performance.

I only tried with the original DE2-115, haven't build it for Mister yet.
Didn't know the sound already improved that much. So forget what i said above.

Thank you for making such a wonerful core!

I am just wondering, if it is possible to modularize all these components, and have them as options in Mister's Core Setup UP? like how we toggle devices in BIOS. Then have a Logic Element counter for user to manage which devices to choose like computer parts, or give up certain ones given the LE budget

The menu would be like

Logic Element Left .. [ 11,000 ]
CPU Generation ..... [386, 486, 586, ..]
CPU Frequency ....... [33, 66, 90, 100, ..]MHZ
CPU FPU .............. [off, 386DX, 486DX, MMX]
Resolution ............ [CGA, VGA, XGA]
Color Depth .......... [2, 4, 8, 16, 24, 32]bit
GPU ................... [none, trident, riva, 3dfx]
Audio Chip ........... [none, SB, AWE32, Roland, ...]

the advantages of this modularize approach is
1. allow the community to focus on adding individual devices like a mini-core without worrying too much about overall performance
2. then the rest of the community can help to optimize each devices
3. This module approach might be very future proof, as next generation of MiSTer might allow us to have more LE,

For me, strong 486DX would be just fine, this kind of machine should be easily able to run games from, as OP correctly says, the greatest era of gaming history. According to reports, most of them already work just fine.

Unfortunately, speaking as a strictly-CRT user, the VGA display problems are a great turn off. It'd be awesome if somebody attempted to fix it (if possible).

CRT can work, but only with scaling and such. It can also work without scaling, but from what I have found, then it only works for one resolution. So it might work with 320x200, but if it changes to 320x240 it stops working.

I am guessing this is possible to fix, just not sure what it takes to fix. Right now the setup for a non-scaled CRT output seems to be only one resolution unless I am mistaken, and anything else then has errors.

When it comes to the logic elements left, I doubt there will be room for MMX or 3DFX. Might be room for FPU. I have been looking into whether anyone made an open source FPGA implementation of FPU, but cannot find any, so I do not really have any idea how much logic elements would be needed for FPU. One thing is sure, FPU is not just FPU. Some FPUs supports floats, some support doubles. A double is two floats. I do not think those are needed for DOS and Windows 98 stuff, but... on the other hand I am pretty sure even the early Pentium FPUs did support double. I think that is also tied to how accurate they are, they have variable degrees of bit accuracy.

So it might be possible to implement one of the more limited FPUs I guess? I was hoping we could maybe pass through the ARM chips FPU, but the MiSTer now uses both the ARM cores, so that might not be possible. I looked it up and the ARM cores should have fully capable FPUs... just not sure they can easily be used the same way. I do not know how FPUs work or how they are used, but I suspect an FPU is expected to have certain methods or calls and that if the ARM FPU is to be used, the x86 FPU calls might need to be mapped to ARM FPU calls, and maybe the same has to happen with the responses, that probably ends up adding some overhead.

All in all... I think if its possible it would require a pretty dedicated developer with the time to do add a working FPU solution, for it to be implemented. But even then there might just not be enough space left for it.

Games from 1995 onwards could benefit from an FPU co-pocessor. I found two open cores for FPU co-processors:

• https://opencores.org/projects/fpu100
• https://opencores.org/projects/fpu

As written in another thread, there are FPU emulators that can run on the ao486 CPU. However, since they run on the ao486 CPU, they are not as fast as a real FPU. Therefore only few games are faster with the FPU emulator. The main purpose of these FPU emulators is to run games or applications that refuse to run without an FPU.

From what I've read in these threads:
viewtopic.php?f=13&t=970
viewtopic.php?f=13&t=367

...VGA only works through the scaler (or the image does not sync, is unstable or does not display at all). And the scaler produces artifacts.

Yeah, FPU emulation is very slow. I think one of the FPU emulators for DOS was even made using assembly and also it used lookup tables for the calculations where that was possible. But still it was I think more than 10 times slower than even a 386 with FPU, for FPU stuff.

But those cores you found look interesting. If I ever figure out how to make some simple FPGA core, I hope I can try to implement that and FPU core and play around with it a bit.

this looks like a fpga fpu https://opencores.org/projects/fpu100

Please correct me if I am wrong, but wouldn't you need an x87 compatible FPU, not just any old FPU? That being said, I still think an FPU isn't going to provide any tangible benefit to games for a 486 as most games that need one are going to run too slowly anyway.

SuperBabyHix wrote: ↑Tue Aug 25, 2020 4:32 pm Please correct me if I am wrong, but wouldn't you need an x87 compatible FPU, not just any old FPU? That being said, I still think an FPU isn't going to provide any tangible benefit to games for a 486 as most games that need one are going to run too slowly anyway.

Yup... it would get Quake to run, but... not playable. With an FPU emulator it would run at 1fps or less... with "hardware" FPU, it would probably still be below 5 fps, and might even still be 1 fps. But there are quite a few games that require FPU, and Windows 98 seems to probably use it for... something. Several versions of DirectX, that is everything above DirectX 8 wont install without FPU.

So it might help make more software possible to use. There were 386 CPUs with FPU, so I suspect there is something useful to do with it.

I also touched it in my post a bit, that its probably not enough for an FPU to be an FPU. Amiga and PC FPUs are most likely not the same, but I am pretty sure its mainly about mapping the input and output a bit. They should not be too different I think.

Yeah, some of the DOS CAD software do require FPU, or 387 modules to run

I was just wondering would modularization help community more freedom to develop modules like without worrying about how much LE each module take, and not worry about making the ao486 core bloated, worst comes worst, people just not use the core. Also modules can be developed first, and wait for future platform. It gives more flexibility, and welcome people to contribute to the development of ao486.

I am totally clueless about how these thing work, it is just like magic to me. so if I sound like I am talking out of my butt, please excuse me

This one looks interesting too...

http://flopoco.gforge.inria.fr/

I haven't seen a core that implements all operators the x87 has. These include sin, cos, tan, atan2, y*log2(x), y*log2(x)-1 and others. And all operations must be performed with 80-bit IEEE floats.

pgimeno wrote: ↑Thu Aug 27, 2020 12:48 am I haven't seen a core that implements all operators the x87 has. These include sin, cos, tan, atan2, y*log2(x), y*log2(x)-1 and others. And all operations must be performed with 80-bit IEEE floats.

Oh, that is good to know. I thought maybe it was only the Pentium ones that would require all of that.

Caldor wrote: ↑Tue Aug 25, 2020 7:53 pm

SuperBabyHix wrote: ↑Tue Aug 25, 2020 4:32 pm Please correct me if I am wrong, but wouldn't you need an x87 compatible FPU, not just any old FPU? That being said, I still think an FPU isn't going to provide any tangible benefit to games for a 486 as most games that need one are going to run too slowly anyway.

Yup... it would get Quake to run, but... not playable. With an FPU emulator it would run at 1fps or less... with "hardware" FPU, it would probably still be below 5 fps, and might even still be 1 fps. But there are quite a few games that require FPU, and Windows 98 seems to probably use it for... something. Several versions of DirectX, that is everything above DirectX 8 wont install without FPU.

So it might help make more software possible to use. There were 386 CPUs with FPU, so I suspect there is something useful to do with it.

I also touched it in my post a bit, that its probably not enough for an FPU to be an FPU. Amiga and PC FPUs are most likely not the same, but I am pretty sure its mainly about mapping the input and output a bit. They should not be too different I think.

Quake doesn’t just need an fpu. It needs a pipelined fpu that can do fused multiplication and add.

Pentium and up can do that. 486dx can not.

I had a 486dx and quake was nowhere near playable on it.

It really needs a Pentium to run playable.

And yeah that’s the case for a lot of games that need an fpu. They really need a Pentium based fpu not just an x87 compatible one. Because the fused multiply add is critical for performance on the calculations involved in 3D software rendering in quake and similar era engines. Quake was optimised heavily for the Pentium fpu.

Prior to Pentium all an fpu is useful for really is cad or other serious software.

Oh and the high fidelity flight model in falcon 3.0, but….

Yeah, Quake was a heavy game. I still think using the hybrid trick that the Amiga core is having some experiments with could really give the AO486 core a big performance leap. I suspect it might be able to run as a 486DX 66Mhz. Which ought to be a lot better than 486SX 33Mhz. A lot of games have 486DX 66Mhz as their minimum requirement.

Its been a while since I tested SVGA, I know it can run in 640x480, but I am pretty sure it can also run in 800x600. The main problem for SVGA graphics as it is now, is the CPU cannot keep up. Duke 3D is a good example, it goes from being somewhat playable to being a laggy mess when switching from 320x240 to 640x480