Breakthrough for the ao486 core announced - Cache

[tlaloc]

But how did I get the "overclock" option then? Did I activate debug mode somehow maybe? I have been wondering how to do that, but have not found anything about it.

I noticed that as well, almost as though it ‘took time’ for that option to ‘kick in’. Perhaps it was a fluke from testing all of those dev cores for the past three months

[seastalker]

With the amazing ao486 core getting updates, is the github information page up to date? Specifically the 486DX33 performance CPU (no-FPU)?

With foggy memory of post-1980s computers before my first Windows 98 one, the 9min mark of Lon.tv's 25th anniversary of Windows 95 video gave some perspective. Next, looking at the Intel family line to re-learn the approximately 1989-1994 line up:

32-bit processors: the 80486 range: 80486DX, 80486DX2, 80486DX4

In technical terms, what makes the core's current status more like an 'overclocked' DX and not a DX2 or DX4 if splitting hairs? [Even without FPU implemented, I'm not calling it some hypothetical 80486SX model which was a DX with a disabled math processor].

Does anyone have an example of a retail 1990s computer make/model I could look up that would be closest in spec (capable of L1 and L2 cache)? Obviously 8GB hard drives would be Compact Flash solutions in 2020 as well as ram, etc.

The successor to the 80486 family is P5 micro-architecture: This is Pentium 1 territory, so I presume I would of heard someone on Youtube mention this if the Mister core could handle this [and... the core is called ao486 for a good reason].

Is the development ceiling or ultimate scope of this core to be the most stable and accurate overclocked 80486DX4?

[rhester72]

The core as it stands now is an essentially unoptimized direct port of Bochs to FPGA, that then had a L1 cache-break bug fixed and a ton of other cache thrown at the problem (along with some minor tweaks). It targets the 486 'architecture' only in that it supports the 80486 instruction set (because Bochs does), but it shares next to nothing in terms of low-level architecture with the actual 80406 (nor was that a goal).

Thus, any comparisons with DX2/4 processors is moot as the architectural changes they introduced to achieve higher performance simply don't apply. This is more akin to software-emulation-atop-hardware.

It's pretty well understood that we're probably at or beyond the 80% maximum possible performance threshold, the biggest limiting factor now being sheer transistor state switching speeds in the FPGA itself. Clocks above 90MHz (internally) are not stable.

In terms of performance, yes, the current iteration of the core has a MIPS rating that approximates a 486SX/33, but that isn't because of any architectural similarities...it's simply because that's the approximate throughput of the fake semi-but-not-really-486 implementation in ao486. Remember, before the cache work, this same 486-instruction-set-compatible 'processor' pumped out blazing 80286 levels of performance.

[NightShadowPT]

In terms of performance, yes, the current iteration of the core has a MIPS rating that approximates a 486SX/33, but that isn't because of any architectural similarities...it's simply because that's the approximate throughput of the fake semi-but-not-really-486 implementation in ao486. Remember, before the cache work, this same 486-instruction-set-compatible 'processor' pumped out blazing 80286 levels of performance.

You're being too strict.

Before the cache improvements, the speed was closer to a 386SX/20 or 386SX/25.
You may be confusing it with the first port of ao486 where the CPU was not overclocked.

Now, the performance level (depending on the application) is close to a 486DX50.

[Goingdown]

In technical terms, what makes the core's current status more like an 'overclocked' DX and not a DX2 or DX4 if splitting hairs? [Even without FPU implemented, I'm not calling it some hypothetical 80486SX model which was a DX with a disabled math processor].

Well, to be fair there was quite a many 486SX processors with higher than 33MHz frequency - but not from intel. Cyrix had at least 40MHz version and amd had SX processors at least to 66MHz speed. So nothing hypothetical here I would say.

Interesting fact is that Norton Utilities sysinfo detects the CPU as Cyrix 486.

IMHO because only difference between 486 SX and DX cpu was FPU, it is pretty fair to call Mister implementation "486 SX compatible CPU".

[seastalker]

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.

[rhester72]

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

[seastalker]

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.

[ericgus09]

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)

[Caldor]

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.

[rhester72]

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).

[Caldor]

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.

[rhester72]

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.

[Chris23235]

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.

[NightShadowPT]

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.

[tlaloc]

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

[flynnsbit]

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

[tlaloc]

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.

[flynnsbit]

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.

[Caldor]

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.

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.