MiSTer FPGA Forum

Goingdown wrote: ↑Fri Aug 28, 2020 3:42 pm
amd had SX processors at least to 66MHz speed.
Interesting fact is that Norton Utilities sysinfo detects the CPU as Cyrix 486.
it is pretty fair to call Mister implementation "486 SX compatible CPU".

Yes, as a long time AMD fan (after Pentium II, I learned about AMD and never looked back with any new builds), I cringed after my initial post seemed to imply Intel was the only CPU in existence to base from.

That is also interesting about Norton Utilities. I need more time with the core to discover such things. I am trying to learn how to make VHDs to mess with.

I like the idea of "486 SX compatible CPU" which locks in a class or Family and Model but perhaps a hypothetical model of a clock speed of 90mhz (100mhz experimental).

Can someone explain and differentiate the claim of being partial FPGA being 'helped' by emulation'? ScummVM and PRDoom may run off of Linux on the ARM core, bypassing FPGA altogether (which is fine IMO in these cases), but is this core running some optimization by utilizing non FPGA hardware on the DE10 Nano that some might feel is 'cheating' or partial emulation? I suppose it's subjective, but playing to the strengths of the Nano's hardware that is not unlike using an ODE on original hardware I take no issue with. Where is the fine line that some people are concerned with in this core? I don't know enough about the technical details yet.

The only things involving ao486 that run off-core are UART and MIDI.

I'll have to look up what UART is but MIDI being outside the sandbox is no problem for me. Considering that many had no Roland MT-32 or Sound Canvas back then, it kind of feels natural to have MIDI in this way unless I am totally missing the boat.

UART is the software modem emulation stuff,, eg it emulates an old-school HAYES modem but works over the internet, for people who like to connect to modern BBSs and two player games that required a modem to connect them (you use an ip address instead of a phone number
(eg ATDT www.google.com)

There have been some interesting news about the Minimig core... some developer, I think the one who worked on the TC64 core, might be going to work on a core for the MiSTer where he takes the full CPU and emulates on the ARM instead. I am guessing that might also make it easier to get FPU support. If that ends up working, it might be something to consider for this core.

Personally, I think the complexity of a low-MHz (relatively speaking) 68020 is a lot more achievable in ARM than a high-speed 80486...hell, there isn't much more to the MiSTer core _besides_ the CPU (and a strapped-on Soundblaster). If that's desired, just use Bochs (or DOSBox).

rhester72 wrote: ↑Fri Aug 28, 2020 5:59 pm Personally, I think the complexity of a low-MHz (relatively speaking) 68020 is a lot more achievable in ARM than a high-speed 80486...hell, there isn't much more to the MiSTer core _besides_ the CPU (and a strapped-on Soundblaster). If that's desired, just use Bochs (or DOSBox).

The problem with emulation has often been said to be that in the CPU you cannot make things run parallel. So having to only emulate the CPU and do the rest with FPGA, that would leave a lot more to the CPU emulation and the CPU already has FPU, so if it uses a mix of virtualization and emulation it could end up being quite effective I think.

We will have to wait and see, but I am pretty sure an 800MHz ARM CPU can do more than a 020 CPU. Especially since the trouble with Amiga emulation is emulating the full chipset more than its a problem with the CPU itself. I would argue its probably the same with AO486.

As already mentioned in this thread, its not like its a perfect 486 anyway, so it is likely to end up being better and more accurate this way.

Still, it would be a project so big that I doubt it will happen.

That's kind of the point - it makes sense for Minimig because the custom chips are where the complexity is. There are no custom chips in a PC - the most complex thing besides the CPU is the Soundblaster which isn't very complex at all. There's no real opportunity for a win.

Caldor wrote: ↑Fri Aug 28, 2020 5:50 pm There have been some interesting news about the Minimig core... some developer, I think the one who worked on the TC64 core, might be going to work on a core for the MiSTer where he takes the full CPU and emulates on the ARM instead. I am guessing that might also make it easier to get FPU support. If that ends up working, it might be something to consider for this core.

The ARM-CPU on the MiSTer is nowhere fast enough to emulate a 486 at a descent speed.

seastalker wrote: ↑Fri Aug 28, 2020 4:53 pm I'll have to look up what UART is but MIDI being outside the sandbox is no problem for me. Considering that many had no Roland MT-32 or Sound Canvas back then, it kind of feels natural to have MIDI in this way unless I am totally missing the boat.

Well, if you have a real MT-32, SC-55, SC-88, or any other Midi device for that matter the MIDI works over real hardware.

Nonetheless, being able to use MUNT is appreciated for those that don't have the real deal.

flynnsbit wrote: ↑Wed Aug 12, 2020 6:19 pm open the mounting screen for it and then hit backspace. It probably needs a hint on that screen to hit backspace to unmount. Let me see what I can do.

One of the latest commits implements this same thing we were discussing. Did you have any input in this, flynnsbit?
https://github.com/MiSTer-devel/Main_Mi ... 08499448cc

tlaloc wrote: ↑Sat Nov 14, 2020 5:53 pm

flynnsbit wrote: ↑Wed Aug 12, 2020 6:19 pm open the mounting screen for it and then hit backspace. It probably needs a hint on that screen to hit backspace to unmount. Let me see what I can do.

One of the latest commits implements this same thing we were discussing. Did you have any input in this, flynnsbit?
https://github.com/MiSTer-devel/Main_Mi ... 08499448cc

I did

https://github.com/MiSTer-devel/ao486_MiSTer/issues/50

flynnsbit wrote: ↑Sat Nov 14, 2020 6:01 pm

tlaloc wrote: ↑Sat Nov 14, 2020 5:53 pm

flynnsbit wrote: ↑Wed Aug 12, 2020 6:19 pm open the mounting screen for it and then hit backspace. It probably needs a hint on that screen to hit backspace to unmount. Let me see what I can do.

One of the latest commits implements this same thing we were discussing. Did you have any input in this, flynnsbit?
https://github.com/MiSTer-devel/Main_Mi ... 08499448cc

I did

https://github.com/MiSTer-devel/ao486_MiSTer/issues/50

That’s rad. Three months later... but still rad.
...I regret ever thinking you were being sarcastic when you said you’d see what you can do. You are a living sentient being of your word, and I thank you here now for it.

I had it on my list to request it, but was heads deep in the other stuff so finally came up for some air now that the pack is out.

Chris23235 wrote: ↑Fri Aug 28, 2020 8:56 pm

Caldor wrote: ↑Fri Aug 28, 2020 5:50 pm There have been some interesting news about the Minimig core... some developer, I think the one who worked on the TC64 core, might be going to work on a core for the MiSTer where he takes the full CPU and emulates on the ARM instead. I am guessing that might also make it easier to get FPU support. If that ends up working, it might be something to consider for this core.

The ARM-CPU on the MiSTer is nowhere fast enough to emulate a 486 at a descent speed.

Very true, I was suggesting to just use the ARMs FPU. Not to use it for emulation. This would be more like what WINE does for Linux, so take calls from the AO486 core, have some API that translate them into whatever the ARM FPU uses, and then the API converts the responses back into AO486 FPU responses, and the AO486 should effectively have an FPU with accuracy and speed that would outperform a Pentium.

We would still have a bigger problem though... that any game that requires FPU also seems to require a CPU that is faster than the AO486 core. So while it would become possible to run more games, they would probably be slideshows.

flynnsbit wrote: ↑Sat Nov 14, 2020 6:17 pm I had it on my list to request it, but was heads deep in the other stuff so finally came up for some air now that the pack is out.

Ahh yes, awesome to see this having been implemented I was thinking about making a request for it on the Git but never got around to it. I had not realized you already had.