Hybrid AO486 core?

[german_user]

With Minimig, it really depends on what you want to do. The vampire cards show what CPU speed would be possible in the FGPA. With the AO486 core, the CPU speed is actually sufficient, what would be missing would be a Voodo 1 card. Then most games would be much easier to play directly.

[dmckean]

Is something like a 286 so much more complex than an 68000 that it'd take an epic genius to implement? I'd guess it would be mostly pointless to create an exact clone of such a CPU in FPGA because hardly any software would rely on exact instruction timing for these platforms anyway. This is quite different from things like the 6502 where entire software ecosystems were built around one exact version of a CPU. In PC-land that simply didn't happen past the XT era.

The 286 is not much more complex that the 68000 (if at all), but it needs to be remembered that we still don't have a perfect 68000 implementation on FPGA yet. The 386 gets much more complex though.

[H6rdc0re]

We need better x86 CPU in FPGA and not some flaky hybrid CPU solutions
Connecting Pi to Mi? Why not connect monitor and input devices to Pi directly and enjoy superior performance right away?

Better buy a very expensive FPGA board then because the Cyclone V in the DE-10 Nano might only emulate a first generation Pentium. By doing hybrid emulation we might get a solution to do some early Glide games with playable framerates. This would be big in the retro PC market. Imagine all those retro PC gamers not having to buy and maintain old and flaky hardware.

With Minimig, it really depends on what you want to do. The vampire cards show what CPU speed would be possible in the FGPA. With the AO486 core, the CPU speed is actually sufficient, what would be missing would be a Voodo 1 card. Then most games would be much easier to play directly.

Old graphics accelerators like the Voodoo 1 rely on CPU for performance. A 486SX33 would be a very big bottleneck to a Voodoo 1. For a Voodoo 1 you’ll need at least a Pentium 60MHz but a Pentium 133 MHz MMX would be recommended.

[kalach.x]

With Minimig, it really depends on what you want to do. The vampire cards show what CPU speed would be possible in the FGPA. With the AO486 core, the CPU speed is actually sufficient, what would be missing would be a Voodo 1 card. Then most games would be much easier to play directly.

Voodoo with 486 class CPU makes absolutely zero sense. MAybe if it ran at speeds of DX4 133MHz then yeah kinda, 3dfx Voodoo would be cool.
Glide games also most probably require FPU so even if this core had Voodoo you could not use it

[kalach.x]

Better buy a very expensive FPGA board then because the Cyclone V in the DE-10 Nano might only emulate a first generation Pentium. By doing hybrid emulation we might get a solution to do some early Glide games with playable framerates. This would be big in the retro PC market. Imagine all those retro PC gamers not having to buy and maintain old and flaky hardware.

Maybe hybrid emulation could do that but maybe it cannot.
So far no one even proved that X86 can be emulated with high enough performance on De10 nano ARM to beat Ao486.

[akeley]

Better buy a very expensive FPGA board then because the Cyclone V in the DE-10 Nano might only emulate a first generation Pentium. By doing hybrid emulation we might get a solution to do some early Glide games with playable framerates. This would be big in the retro PC market. Imagine all those retro PC gamers not having to buy and maintain old and flaky hardware.

PC enthusiasts don't maintain retro hardware because they need to, but because they enjoy it. Besides, for the Voodoo era you can just get any old, common as muck P2-P4, which will run most anything, without having to worry about speed issues or "maintenance" (or simply use Dosbox). It's the pre-3D MS DOS era which can be really problematic and often requires period machines or arcane slowing program manipulation.

Overall, I don't have anything against this hybrid idea per se, and there are some interesting points in this thread. It's just I'd really much rather have some solid foundation sorted out first - and it doesn't have to be a 100% cycle accurate and perfect utopian core. Just so the main issues are ironed out with ao486, if possible - eg, the lack of proper VGA, the accursed "crazy mouse" bug, joystick support, game compatibility on a case by case basis, etc...

Theoretically, yes, working on one thing does not exclude another, but I don't think the dev pool of people who are capable and willing of taking on a rather complex core like this one is that big either.

[dalingrin]

Folks seem to really obsess over the lack of FPU in AO486 but there are almost no games in the 486 era that make use of an FPU. The FPU didn't really get used in gaming until Pentium era games and they wouldn't run well on AO486. It didn't make sense for game developers to target the FPU until they became ubiquitous with the Pentium. The 486 FPU isn't even that fast to begin with.

[Mr. Encyclopedia]

If someone is going to seriously consider a hybrid 486/586 core I think it would make more sense to attempt to build a core specific to the DE-10 Nano first. The port of ao486 is impressive, and a lot of work has gone into optimizing it, but new builds for it routinely fail and it never meets its timings (which, thankfully, are largely unimportant). A fresh PC core built from scratch would probably be less work than building a hybrid core, or worse attempting to make ao486 into a hybrid core, and be likely to do more with less FPGA utilization than the current ao486.

[Caldor]

Better buy a very expensive FPGA board then because the Cyclone V in the DE-10 Nano might only emulate a first generation Pentium. By doing hybrid emulation we might get a solution to do some early Glide games with playable framerates. This would be big in the retro PC market. Imagine all those retro PC gamers not having to buy and maintain old and flaky hardware.

PC enthusiasts don't maintain retro hardware because they need to, but because they enjoy it. Besides, for the Voodoo era you can just get any old, common as muck P2-P4, which will run most anything, without having to worry about speed issues or "maintenance" (or simply use Dosbox). It's the pre-3D MS DOS era which can be really problematic and often requires period machines or arcane slowing program manipulation.

Overall, I don't have anything against this hybrid idea per se, and there are some interesting points in this thread. It's just I'd really much rather have some solid foundation sorted out first - and it doesn't have to be a 100% cycle accurate and perfect utopian core. Just so the main issues are ironed out with ao486, if possible - eg, the lack of proper VGA, the accursed "crazy mouse" bug, joystick support, game compatibility on a case by case basis, etc...

Theoretically, yes, working on one thing does not exclude another, but I don't think the dev pool of people who are capable and willing of taking on a rather complex core like this one is that big either.

For all we know, such issues might actually go away with the a hybrid core on top of giving a better performance.

The DE-10 Nanto runs like a 33mhz 486, in some cases maybe as a 48mhz 486, my tests so far just seems to put it around a 33mhz 486. Even DOSBox emulating a full system can do a 50mhz 486 and add FPU on top. That is without trying to run it all as a hybrid solution.

And yes... when it comes tro PC retro hardware, the DOS / PC stuff is by far the most annoying. You can hunt down those 10 different parts to make some "perfect system" and then one of the parts dies on you. I have 4 old systems where none of the motherboards boots anymore. I am focusing my collection on Amiga hardware. And while it is nice to run Amiga CD32, CDTV, Vampire and 1260 cards, its only the Vampire among them that is close to being able to run all Amiga software. So even without the extra CPU power, the MiSTers Minimig core to me makes for the best Amiga, since it has RTG and can easily be configured to run 68000, 68020, swap kickstarts without any issues and boot from HDF files. My main gribe is actually that it lacks support for floppy disks or at least copy protected images like IPF or SCP.

The Amiga 1200 with a Vampire card is highly compatible, but for some reason it only supports running as 68080 and while I think its impressive how compatible it is, but its also annoying that the v2 cannot do RTG to through the native output and native Amiga video through the HDMI. The V4 should fix that, but still does not seem to support switching between 68000, 020 and 080 CPU types for added compatibility.

All of that mess is also why I would rather do a 486 on FPGA with a hybrid setup. Setting up a real harddisk takes such a long time. While its fun to tinker, I also like to have stuff that just works. The MiSTer makes it even simpler than emulation while making it more true to the original systems, and often better and more compatible than emulators in many cases. AO486 currently not being one of those cases, but in many ways it is impressive.

I also do wish it did not f.ex. have that annoying mouse issue, but with the hybrid AO486, then we would be able to see if that issue comes from the FPGA based CPU implementation, because there are several ways to emulate 486 CPUs and I suspect many of them might be with less issues than the current AO486, although I do think it is good.

It could also give us several options, it might be the GPU we tried to emulate on an external Pi to get 3dfx, but... as already pointed out, with the current speed of AO486, 3DFx games would not run in any playable way anyway. Generally those games require at least a Pentium CPU.

Better buy a very expensive FPGA board then because the Cyclone V in the DE-10 Nano might only emulate a first generation Pentium. By doing hybrid emulation we might get a solution to do some early Glide games with playable framerates. This would be big in the retro PC market. Imagine all those retro PC gamers not having to buy and maintain old and flaky hardware.

Maybe hybrid emulation could do that but maybe it cannot.
So far no one even proved that X86 can be emulated with high enough performance on De10 nano ARM to beat Ao486.

Which is why its relevant to test I think. But as Bbond has shown, DOSBox running on the MiSTer directly seems to be capable of running DOS better than the AO486 core and that is without focusing on just the CPU part of the computer and without JIT.

[kalach.x]

Ao486 does in 3dbench score of 43.8
It is the same benchmark as one with giant Superscape and score in small box in bottom right.
In this benchmark the faster the PC the higher the score.

Dosbox is known not to be very fast and provided benchmarks only confirm that. I wouldn't dismiss idea of using hybrid emulation based on that but to me this idea is inherently flawed. It is better to focus on things which just work and not things which give high I/O latency. Though it might be fun to listen to MIDI music with such hybrid CPU should anyone made it their project. I have Via C3 terminal which is obviously having some issues with I/O latency and it so bad it worth running it from to time to see how bad it plays

[Bas]

If I remember correctly, 3dfx relied immensely on the CPU for geometry calculations. So while I would love to have a neat Pentium MMX/Voodoo combi in a box, I'm not going to hold my breath waiting for MiSTer to become that box. Software emulation of the whole thing on a Pi4 feels more likely to me. It has more and bigger CPU cores and no MiSTer binary hogging one of those for housekeeping, as well as a GPU to help with the 3D bits, while at the same time the emulated PC doesn't need the timing exactness that our beloved FPGA is so good at.

[Caldor]

If I remember correctly, 3dfx relied immensely on the CPU for geometry calculations. So while I would love to have a neat Pentium MMX/Voodoo combi in a box, I'm not going to hold my breath waiting for MiSTer to become that box. Software emulation of the whole thing on a Pi4 feels more likely to me. It has more and bigger CPU cores and no MiSTer binary hogging one of those for housekeeping, as well as a GPU to help with the 3D bits, while at the same time the emulated PC doesn't need the timing exactness that our beloved FPGA is so good at.

Yes, the goal here is just 486DX-66mhz performance. That would allow for a lot more games because a lot of games had this as their minimum requirement.

[bbond007]

The DE-10 Nanto runs like a 33mhz 486, in some cases maybe as a 48mhz 486, my tests so far just seems to put it around a 33mhz 486. Even DOSBox emulating a full system can do a 50mhz 486 and add FPU on top. That is without trying to run it all as a hybrid solution.

While I do think the raw CPU benchmarks are somewhat encouraging, especially without JIT, I do want to clarify that the full DosBOX system is not running like a 486 at all...

The actual real world performance is pretty close with ao486 prior to FPGAzumSpass's cache enhancements.

Ao486 does in 3dbench score of 43.8
It is the same benchmark as one with giant Superscape and score in small box in bottom right.
In this benchmark the faster the PC the higher the score.

I originally thought it was a bad idea to include the 3DBench screenshot - as its not at all relevant as it tests the entire system and not just raw CPU speed.

However, I decided to include it anyway to minimize the chance of incorrect conclusions concerning the overall speed of DOSBox on the HPS.

Folks seem to really obsess over the lack of FPU in AO486 but there are almost no games in the 486 era that make use of an FPU. The FPU didn't really get used in gaming until Pentium era games and they wouldn't run well on AO486. It didn't make sense for game developers to target the FPU until they became ubiquitous with the Pentium. The 486 FPU isn't even that fast to begin with.

The same is often said concerning the 68882 FPU on Amiga/Minimig, however not everybody is into these computer platforms specifically just for games...

On the Amiga, raytracing programs (like Sculpt 3D, Lightwave, Real3D), Landscape generators (like VistaPro) and other creativity/productivity software all benefit from having a FPU present.

Maybe similarly someone is into Lotus 123 or ancient AutoCAD on the PC?

I wanted to run Autodesk 3D Studio Max on ao486:

80x87_required.png (6.76 KiB) Viewed 8774 times

[Bas]

Oh I'd love for the AO486 to get an FPU but for that to be really useful it would also need a SCSI controller for storage, or a fully compatible IDE one so more picky OS'es like OS/2 or old x86 UNIX like Xenix can run on it. Just like I would like Minimig to emulate a fully decked-out A3000.

[Caldor]

The DE-10 Nanto runs like a 33mhz 486, in some cases maybe as a 48mhz 486, my tests so far just seems to put it around a 33mhz 486. Even DOSBox emulating a full system can do a 50mhz 486 and add FPU on top. That is without trying to run it all as a hybrid solution.

While I do think the raw CPU benchmarks are somewhat encouraging, especially without JIT, I do want to clarify that the full DosBOX system is not running like a 486 at all...

The actual real world performance is pretty close with ao486 prior to FPGAzumSpass's cache enhancements.

Ao486 does in 3dbench score of 43.8
It is the same benchmark as one with giant Superscape and score in small box in bottom right.
In this benchmark the faster the PC the higher the score.

I originally thought it was a bad idea to include the 3DBench screenshot - as its not at all relevant as it tests the entire system and not just raw CPU speed.

However, I decided to include it anyway to minimize the chance of incorrect conclusions concerning the overall speed of DOSBox on the HPS.

Folks seem to really obsess over the lack of FPU in AO486 but there are almost no games in the 486 era that make use of an FPU. The FPU didn't really get used in gaming until Pentium era games and they wouldn't run well on AO486. It didn't make sense for game developers to target the FPU until they became ubiquitous with the Pentium. The 486 FPU isn't even that fast to begin with.

The same is often said concerning the 68882 FPU on Amiga/Minimig, however not everybody is into these computer platforms specifically just for games...

On the Amiga, raytracing programs (like Sculpt 3D, Lightwave, Real3D), Landscape generators (like VistaPro) and other creativity/productivity software all benefit from having a FPU present.

Maybe similarly someone is into Lotus 123 or ancient AutoCAD on the PC?

I wanted to run Autodesk 3D Studio Max on ao486:
80x87_required.png

Good to know. You seem to know the Linux side of the MiSTer quite well. After the many updates the Linux backend got recently, I have had trouble getting LXDE to run, that Linux pack for the MiSTer. I cannot figure out how to install stuff on the Linux side. I keep being unsure what type of Linux it is actually running. I am guessing it must be some type of Debian since LXDE seems to be Ubuntu based?

I wanted to try to install DOSBox myself, and yeah, I never expected DOSBox to perform well, it runs almost full emulation unlike f.ex. QEMM. I had a QEMM build on a Pi 4 running Windows 98, and that was pretty impressive, but even with the Pi 4 clocked as high as possible, it was only barely running Starcraft and Diablo. Better than the MiSTer runs those games, but not by much.

So I find it very hard to tell whether a Pi powered MiSTer would run DOS or Windows better than a Pi on its own, or a hybrid AO486 core just based on one ARM core would be better than AO486 on its own. But I am very curious and hopeful that its worth looking into.

If I can just figure out how to install stuff, or get LXDE running again, I could begin to try to test a few more things and do some benchmarks like you did with DOSBox.

You know about software FPU emulation, and... well that its not really much of an option as the performance is really bad and it would only really be useful if the CPU was maybe at... well 300mhz or more maybe. And even then its probably unlikely that it could run Quake 1 at 10fps. But it might at least handle something like AutoCAD.

I also do think more performance could very likely be pushed out of the MiSTer for a DOS core if PC core was built from scrap, but PC I suspect might actually be more complicated than the PSX core, at least when you go beyond 286. I am also unsure how much performance might be gained, but there are certainly some things that could get better. They might also be made better just in AO486. But it would also require a very experienced FPGA developer I think, and its a task that would likely take more than 6 months I think.

[thorr]

Just saw this thread for the first time, and due to current time constraints, I haven't read every post yet. I have an electrical engineering degree specializing in computer engineering back in the mid 90's and from what I have learned long ago, here are my random and somewhat repetitive thoughts (my terminology might be a bit off since I don't do CPU design for a living, I just have the degree and my memory is foggy):

- To start with, I think hybrid is not necessary to get great improvements, and WAY too early at this point to even consider it given the current state of the ao486 core.
- I think a new FPGA CPU could be designed from the ground up, just like what Intel and AMD keep doing today. There are many well known and documented techniques that could be used to improve the speed. The things that immediately come to mind are pipelining, branch prediction, and caching. The main thing is the CPU needs to be 100% compatible with the CPU instruction set, registers, etc. How it gets there can be solved in infinite ways.
- I had a 386 DX computer with a separate math co-processor chip, so the FPU does not need to be inside the CPU.
- Given the huge amount of logic cells in the FPGA, instead of throwing tons of cache at a subpar CPU implementation, the CPU could be redesigned with pipelining and branch prediction and appropriately sized caches tailored to the MiSTer's FPGA. If you need an FPU, a separate core could be designed that includes one with maybe less pipelines and/or cache.
- Instructions can be broken down into smaller things that can run at higher clock speeds and use branch prediction, pipelining and parallelism to make them faster which is where the cache comes in. The Pentium really started making things faster by implementing cool new techniques that could be employed in the MiSTer CPU.
- There are other compatibility issues with the current core. For example, I really wish a real video card could be emulated to solve things like the side of the screen glitches when running Second Reality and things are scrolling during the first part of the demo.
- I like the idea of having different cores that attempt to emulate real CPU's from each generation (XT, 286, 386, 486SX, 486DX). Can't we look at the CPU's under a microscope and recreate them?
- Where's the Tandy sound compatibility? We need this.
- Bottom line, I don't know how much space the current huge caches take up on the ao486, but what I am suggesting is to use those logic cells for CPU improvements rather than caches. It may not be a Pentium, but it can be better than what we have.

[Caldor]

Just saw this thread for the first time, and due to current time constraints, I haven't read every post yet. I have an electrical engineering degree specializing in computer engineering back in the mid 90's and from what I have learned long ago, here are my random and somewhat repetitive thoughts (my terminology might be a bit off since I don't do CPU design for a living, I just have the degree and my memory is foggy):

- To start with, I think hybrid is not necessary to get great improvements, and WAY too early at this point to even consider it given the current state of the ao486 core.
- I think a new FPGA CPU could be designed from the ground up, just like what Intel and AMD keep doing today. There are many well known and documented techniques that could be used to improve the speed. The things that immediately come to mind are pipelining, branch prediction, and caching. The main thing is the CPU needs to be 100% compatible with the CPU instruction set, registers, etc. How it gets there can be solved in infinite ways.

Yes, several have argued this. My counter argument though is that its not really happening, while we have wanted something like that to happen for a while. The hybrid solution though, should be much simpler to do and would if nothing else, add FPU. But it seems likely that it could get the performance up to a 486DX-66mhz I think. Maybe even better if JIT is used.

I would consider this an interesting parallel path for this core to have and I also think its likely that even if a new PC core is developed from scratch, that this solution would still end up being relevant.

Thing is, it might solve several of the issues AO486 has currently. Either way though, it would require a developer capable of making it happen. After that, then like with the hybrid Minimig core it should be possible for a lot of people to compile different CPUs for QEMU or other emulators and test that with the hybrid core to try out different things.

But many here seem to think one solution would somehow exclude the other. At the moment though, neither seems to be happening, so my thinking was this might help start something. Maybe at some point Foft who did has worked on the Minimig Hybrid core so far, might try to do the same here.

The AO486 core already got rewritten a LOT when the level 1 and 2 cache was implemented. They optimized the code a lot as it was otherwise out of space. It was a somewhat simple process from what I understand because what they had was code that had been autotranslated from Bochs source code to FPGA code and that always creates a lot of garbage code that is there because it is easy to generate and make work, but it much of that code is not really needed. A bit like the old Frontpage app from Microsoft Office back in the day, it create a lot of unnecessary HTML code. But it made it possible for people who did not understand HTML to make webpages. In this case it was not so much about a lack of understanding I think, but more that it was a fast way to make it work. I think a lot of cores start out this way.

[ToothbrushThreepwood]

Just saw this thread for the first time, and due to current time constraints, I haven't read every post yet. I have an electrical engineering degree specializing in computer engineering back in the mid 90's and from what I have learned long ago, here are my random and somewhat repetitive thoughts (my terminology might be a bit off since I don't do CPU design for a living, I just have the degree and my memory is foggy):

- To start with, I think hybrid is not necessary to get great improvements, and WAY too early at this point to even consider it given the current state of the ao486 core.
- I think a new FPGA CPU could be designed from the ground up, just like what Intel and AMD keep doing today. There are many well known and documented techniques that could be used to improve the speed. The things that immediately come to mind are pipelining, branch prediction, and caching. The main thing is the CPU needs to be 100% compatible with the CPU instruction set, registers, etc. How it gets there can be solved in infinite ways.
- I had a 386 DX computer with a separate math co-processor chip, so the FPU does not need to be inside the CPU.
- Given the huge amount of logic cells in the FPGA, instead of throwing tons of cache at a subpar CPU implementation, the CPU could be redesigned with pipelining and branch prediction and appropriately sized caches tailored to the MiSTer's FPGA. If you need an FPU, a separate core could be designed that includes one with maybe less pipelines and/or cache.
- Instructions can be broken down into smaller things that can run at higher clock speeds and use branch prediction, pipelining and parallelism to make them faster which is where the cache comes in. The Pentium really started making things faster by implementing cool new techniques that could be employed in the MiSTer CPU.
- There are other compatibility issues with the current core. For example, I really wish a real video card could be emulated to solve things like the side of the screen glitches when running Second Reality and things are scrolling during the first part of the demo.
- I like the idea of having different cores that attempt to emulate real CPU's from each generation (XT, 286, 386, 486SX, 486DX). Can't we look at the CPU's under a microscope and recreate them?
- Where's the Tandy sound compatibility? We need this.
- Bottom line, I don't know how much space the current huge caches take up on the ao486, but what I am suggesting is to use those logic cells for CPU improvements rather than caches. It may not be a Pentium, but it can be better than what we have.

As a person with professional experience with FPGA systems, how much of an impact on performance do you think AI-optimization tools like InTime (https://www.plunify.com/en/fpga-timing- ... -learning/) could have on a non-optimized core such as the Bochs-CPU we’re using?

And does anyone know of open/free alternatives? I presume InTime is astronomically expensive given it’s targetted audience and lack of price listings.

[cursedverses]

Out of interest, would taking something like PCem as a basis for a PC stack prove to be better than using Bochs? Given PCem allows for chopping/changing of components, an experienced developer could pick a basic stack (e.g. SB16 sound, ET4000 graphics, NE2000 network, 486SX processor and a relevant chipset) and build a core from those components.

Assuming that's doable, there'd be scope to see what space was left for expanding/replacing components in the build?


PCem: https://pcem-emulator.co.uk/status.html
PCem on Wikipedia: https://en.wikipedia.org/wiki/PCem

[Neocaron]

As a person with professional experience with FPGA systems, how much of an impact on performance do you think AI-optimization tools like InTime (https://www.plunify.com/en/fpga-timing- ... -learning/) could have on a non-optimized core such as the Bochs-CPU we’re using?

And does anyone know of open/free alternatives? I presume InTime is astronomically expensive given it’s targetted audience and lack of price listings.

I actually shared an articles about using Github Copilot A.I to help create and optimize code, and wondered if it could help, but the responses were not very positive.
viewtopic.php?f=29&t=2972&p=30192#p30192

I still think it could be very helpful for optimization purpose.

[Caldor]

As a person with professional experience with FPGA systems, how much of an impact on performance do you think AI-optimization tools like InTime (https://www.plunify.com/en/fpga-timing- ... -learning/) could have on a non-optimized core such as the Bochs-CPU we’re using?

And does anyone know of open/free alternatives? I presume InTime is astronomically expensive given it’s targetted audience and lack of price listings.

I actually shared an articles about using Github Copilot A.I to help create and optimize code, and wondered if it could help, but the responses were not very positive.
viewtopic.php?f=29&t=2972&p=30192#p30192

I still think it could be very helpful for optimization purpose.

Is it made to work for FPGA stuff? Because I usually stuff like this targets very specific types of code and FPGA code is probably quite different from f.ex. the Bochs source code, and the problem comes after converting that source code because of the automatic translation process, and they already went over the translated code. If it can then possibly optimize some of the FPGA code, then that could be interesting, but I am guessing even with AI tricks that the FPGA developers we have had working on AO486 are probably better than what the AI optimization stuff can do. But might have been very helpful back before the code had been cleaned.

Out of interest, would taking something like PCem as a basis for a PC stack prove to be better than using Bochs? Given PCem allows for chopping/changing of components, an experienced developer could pick a basic stack (e.g. SB16 sound, ET4000 graphics, NE2000 network, 486SX processor and a relevant chipset) and build a core from those components.

Assuming that's doable, there'd be scope to see what space was left for expanding/replacing components in the build?


PCem: https://pcem-emulator.co.uk/status.html
PCem on Wikipedia: https://en.wikipedia.org/wiki/PCem

Bochs was used because it is open source and I am pretty sure PCem is not open source. Also I do not think it is possible to port PCem to Linux / ARM. I guess that might not be an issue if it is to be made into FPGA code anyway though.

[thorr]

As a person with professional experience with FPGA systems, how much of an impact on performance do you think AI-optimization tools like InTime (https://www.plunify.com/en/fpga-timing- ... -learning/) could have on a non-optimized core such as the Bochs-CPU we’re using?

And does anyone know of open/free alternatives? I presume InTime is astronomically expensive given it’s targetted audience and lack of price listings.

I don't know, but I think they have a free trial, so if someone wanted to try it, they could. I do know there are definitely ways to optimize logic, such as using Karnaugh maps. This does not change the behavior of the logic like what I am suggesting by redesigning the CPU.

[thorr]

Yes, several have argued this. My counter argument though is that its not really happening, while we have wanted something like that to happen for a while. The hybrid solution though, should be much simpler to do and would if nothing else, add FPU. But it seems likely that it could get the performance up to a 486DX-66mhz I think. Maybe even better if JIT is used.
(snip)

Rather than quote everything, I will just say I agree with most of what you are saying. We already have 486 DX2-66 performance in some things. I have seen it in some of the demo-scene stuff. I used to have a DX2-66 and watched these demos a million times. Getting an FPU will not open the door to tons of new applications capable of running on the MiSTer, but it would be nice to have for things like Windows 98. In my opinion, it is too early to do the parallel path of hybrid because it is sort of like polishing a turd at this point. It can be done, because I saw it on Mythbusters. I would rather see the time initially spent on making ao486 100% compatible with speed improvements and optimizations. Then when we see what we have, we can improve it with other ideas like hybrid in places where it makes sense given any limitations at that time. This is just my opinion of course. Also, I sort of feel like the hybrid approach is not much different than just using DOSbox. I get excited about FPGA, and less excited about software emulators. I can already do that on my PC.

[Caldor]

Yes, several have argued this. My counter argument though is that its not really happening, while we have wanted something like that to happen for a while. The hybrid solution though, should be much simpler to do and would if nothing else, add FPU. But it seems likely that it could get the performance up to a 486DX-66mhz I think. Maybe even better if JIT is used.
(snip)

Rather than quote everything, I will just say I agree with most of what you are saying. We already have 486 DX2-66 performance in some things. I have seen it in some of the demo-scene stuff. I used to have a DX2-66 and watched these demos a million times. Getting an FPU will not open the door to tons of new applications capable of running on the MiSTer, but it would be nice to have for things like Windows 98. In my opinion, it is too early to do the parallel path of hybrid because it is sort of like polishing a turd at this point. It can be done, because I saw it on Mythbusters. I would rather see the time initially spent on making ao486 100% compatible with speed improvements and optimizations.(snip)

My response is still the same. We are NOT seeing anyone optimizing this core, making it more compatible or starting a new DOS core from scratch. Even IF we ever will see this, its probably going to take 6 months or more.

Again and again people make a "I would rather see" as if its one or the other. But the two paths are so different though, that its pretty unlikely that a developer who normally would do such CPU tweaks in the FPGA would be doing the work to implement a hybrid CPU solution.

The software needed for the hybrid stuff is largely already here. The faults in the core as it is, might be solved by going the hybrid path. Something that could work now within a month or two, rather than something that we might not even see 6 months from now in any sort of way.

[dmckean]

The faults in the core are not going to be solved with the hybrid path. The faults in the core would need to be cleaned up before work even started.

[akeley]

6 months or a year in MiSTer universe is not really that bad a timeline. Watching this scene quite closely fo the last year or so I did learn to be patient and have also seen some very unexpected - and very pleasant - surprises. There might be some unknown whiz reading this thread right now and thinking, "Well, I could have a go at this...", or one of the old hands finding themselves with some spare time and a need for challenge. Basically, you never know. And, after all we don't really needit right now, because a) there are other solutions for retro PCs b) a lot of stuff actually does work in ao486, so that's quite fun too.

Obvioulsy, if in the meantime somebody whips up a hybrid solution which offers at least some improvements, then that would be great too, sure. And I do appreciate that you're trying to make it happen. But it's still important to talk about the, ahem, core problems with this core.

[thorr]

I agree with the above, and just to throw out another idea, it would be cool if someone got DOSBox running on the Arm. Now, THAT should be quick and easy and provide instant results. I even think I might be able to do that myself, but not right now because of my schedule.

[bbond007]

I agree with the above, and just to throw out another idea, it would be cool if someone got DOSBox running on the Arm. Now, THAT should be quick and easy and provide instant results. I even think I might be able to do that myself, but not right now because of my schedule.

viewtopic.php?p=41981#p41981

[thorr]

LOL, well what are you waiting for?

Also, since the source code of DOSBox is available, it probably could eventually be used for portions of the hybrid idea.

[cursedverses]

Bochs was used because it is open source and I am pretty sure PCem is not open source. Also I do not think it is possible to port PCem to Linux / ARM. I guess that might not be an issue if it is to be made into FPGA code anyway though.

I'm not sure about the past, but the previous maintainer posted sources onto github under GPL 2 - https://github.com/sarah-walker-pcem/pcem

Maybe it wasn't picked due to it's dependency on various firmware/BIOS files?