Why Doesn’t the Lion King Run Well on the AO486 Core?

[Neocaron]

I think the best approach for the ao486 to get better is to offload some of it on the arm. That's a case where hybrid makes sense, even if it seems to trigger the purist.
But there's still a lot of problem with the minimig hybrid that seem very hard to resolve, especially if the kernel overclock never gets approved.

[dmckean]

The current core could implement a better CPU without resorting to recreating the i486 at the transistor level.

[Caldor]

But PCem is also open source, and there are other emulators as well that are, and many FPGA cores were built based on emulators.

So that ought to help create a new 486 core if someone did take on such a project?

[Malor]

Software implementations don't translate to FPGA implementations. They're in different domains. What they're useful for is documentation, and frequently testing, because you can see what *should* happen, while you scratch your head as to why your FPGA circuit isn't doing that.

In effect, it's like looking at a python script to resize an image and saying, "see? now a hardware scaler is easy!" The script is useful for comparison purposes to see if your hardware scaler is doing what it should, but that's about all.

[Caldor]

Pretty sure a large part of the AO486 core was actually auto-translated from an emulator, and that was part of why they had to spend a pretty long time optimizing that code, because the logic was quite messy because of it.

[FPGA64]

It came from Bochs emulator originally. Heavily updated since then

[throAU]

One big issue there is that the only open-source 486 core for the FPGA is the eponymous AO486. Doing one from scratch that had similar timings to the original would be an enormous undertaking. This is a guess, but I suspect a lot of the reason the AO486 core is slow is because it's using things like microcode to save FPGA space, so a proper 486 with correct timings might be a lot larger, and size is the biggest problem with the current core already.

This is an opinion from an amateur, and should be discarded if anyone with actual expertise opines otherwise, but it seems like we'd need an FPGA at least twice the size of the Cyclone V to do a 486 really well, plus a hell of a lot of development effort.

edit to add: a real 486 has between 1.2 and 1.6 million transistors. Duplicating that accurately would be a gigantic project.

What is a “proper 486 with correct timings”?

The “486” era spanned: FPM vs. EDO memory in different speeds, ISA, MCA, VESA, EISA buses (potentially clocked at different speeds based on CPU speed). 8/16/32 bit video card buses. CPU clocks from 16-120mhz. Bus vs. CPU clock ratio of 1x-3x. Hard disk standards varying between MFM/RLL/IDE/SCSI - with or without DMA. Varying levels of both internal and external CPU cache. Different levels of video card speed/memory bandwidth. Different amounts of video memory.

Any of these components could be combined with a combination of other components.

The notion of a “timing accurate” 486 (or any other PC really) simply doesn’t exist. Unless you’re planning to emulate a specific model of IBM PC perhaps with fixed CPU/bus/memrory/add in cards, etc. As mentioned above the PC platform is nowhere near as timing specific as the other platforms either.

IMHO ao486 is what it is. I enjoy what’s there. If there are performance issues maybe the specific issue could be worked on but as far as I’m concerned expecting it to behave like “a real 486” is unrealistic, because even different 486 machines of the time could behave wildly differently (as above, “obscure off brand cpu” is a pretty accurate description but there’s also the same behaviour for the other simulated components).

Maybe “early 90s PC compatible” would be a more accurate name for the core but that isn’t as catchy.

[Caldor]

What is a “proper 486 with correct timings”?

I think the issue is that AO486 is not timing accurate to any 486 computer from the 90ies, because part of it relies on caches and such based on DDR3 RAM and other things based on the FPGA timings I think, and it just adds up to AO486 having some pretty strange timings compared to real hardware.

The bottlenecks, or lack of them, just makes it difficult to hit the correct timing of the AO486 core. Some things being too fast is obviously not a great thing. Does it have to be fixed? Well... it does not seem like a big problem in general. Most games run great I would argue, especially with all the different updates that have come over time. The timing accuracy was mainly relevant in older games I think, and so far the PCXT core is doing quite well for those I think.

"The Lion King" not running very well I do not think has to do with timing issues though. Its a bit strange that it seems to be the only game with this issue. To better debug it, it would help with more examples, because overall I do not think it needs a new core build from scratch to solve it, although it probably would solve it if that was done... maybe 12-16 months from now if there is a very good and dedicated FPGA developer or two working on it. I just do not think that will happen.

Other bugs have been figured out by diving into it so far over the years, like some IDE fixes, mouse fixes, memory management fixes and more that has helped make the core more stable and gotten more games to run.

[throAU]

What is a “proper 486 with correct timings”?

I think the issue is that AO486 is not timing accurate to any 486 computer from the 90ies, because part of it relies on caches and such based on DDR3 RAM and other things based on the FPGA timings I think, and it just adds up to AO486 having some pretty strange timings compared to real hardware.

I get that, but my point is that even period hardware had massively different timings between different make/model of processor, ram speed, bus speed, display adapter, etc.

I agree ao486 is "Strange" but by the same token, even if it was period correct there's still a huge amount of variability. As above, thinking of it as some weird off brand PC compatible is probably more accurate than thinking of it as any form of 486. In some ways its way faster than my old intel 486dx-33 was, in others... not.

My non-FPGA oriented guess is that it's likely more to do with the FPGA implementation of the CPU than anything to do with the DDR3 RAM (or VGA, other peripheral timings); DDR3 probably is more than fast enough (even in terms of actual latency) vs. the garbage we were using in 386/486 PCs back in the day (which was 100-150+ ns). I mean, EMS/XMS was also a thing, and that was terribly slow. 486 era machines were mostly either doing EMS or XMS for almost all software (outside of protected mode stuff which was quite late) and both memory access types were slow/crap. The stuff that wasn't using extended/expanded memory was mostly aimed at the 286.

[dmckean]

The CPU is really weird in ao486 as some instructions execute way faster than a real 486 (of any type) and others execute significantly slower. On a real i486 I can get Lion King to run perfectly using slowdown programs but I can't get the same results on ao486. I gave up after I spent about 45 minutes with it with no results.

There are people around this project that are more talented than me though at getting programs to run. There could still be a combination of settings that work.

[Caldor]

The CPU is really weird in ao486 as some instructions execute way faster than a real 486 (of any type) and others execute significantly slower. On a real i486 I can get Lion King to run perfectly using slowdown programs but I can't get the same results on ao486. I gave up after I spent about 45 minutes with it with no results.

There are people around this project that are more talented than me though at getting programs to run. There could still be a combination of settings that work.

Exactly... there might have been varying 486 CPU speeds, RAM speeds and so on, but all of that was generally accounted for in apps for the 486 computers, because those varying speeds were accounted for. AO486 does things that usually would be impossible in 486 CPUs. 286 and 386 machines also had varying speeds, but as you point out in AO486 it might be specific instructions in the AO486 core that run a whole lot faster than they should f.ex.

With real 486 computers, the different speeds were that sometimes one machine had double or triple the RAM speed I guess, or a CPU that was 2-10 times as fast, but that is not comparable to AO486 and its timing issues, because the problem with it is that it makes games and apps unable to know when it suddenly does something very fast, much faster than any real 486.

Looking over the issues that have come up with the PSX core you hear about what strange ways some PSX games had done things, relying sometimes on very specific timings and such. Like assuming an cutscene to last a specific amount of time, or waiting for specific signals in the PSX that were not supposed to be used that way. The same way 486 games could probably rely on measuring the speed of the CPU and expecting certain operations to be relative to its speed.

Point being, these other 486 CPUs did not have timing issues. It was not something that ought to affect games or apps, unless it was simply too slow for those games or apps. Except maybe some off cases.

[held]

Didn't someone started a hybrid for the Amiga, could something like that be done for AO486?
eg: porting DOSBOX and offload graphics,sound or other parts to the FPGA? or something like that.

[Caldor]

Didn't someone started a hybrid for the Amiga, could something like that be done for AO486?
eg: porting DOSBOX and offload graphics,sound or other parts to the FPGA? or something like that.

Yeah, I have been hoping to see this happen. The Hybrid Amiga core never got very stable though, or rather I think the real problem was that it had problem with slow memory, some bottleneck between the CHIP RAM and CPU I think. But what I would hope to see is something like the PiStorm but for the MiSTer. An expansion for the MiSTer that could maybe do what PiMIDI does but at the same time run CPU emulation for cores that might need it.

A lot of the AO486 logic space right now is the CPU afaik. With a solution like this, I think it could probably end up running a Pentium level CPU through a Pi 4 or Pi4 Compute Module.

But such a solution would probably have its own bottleneck issues.

[suverman]

Just tested running Lion King at 90mhz inside Win95 - initial stutters aside the game runs full speed. Crashes when running in dos mode.

[Caldor]

Just tested running Lion King at 90mhz inside Win95 - initial stutters aside the game runs full speed. Crashes when running in dos mode.

Interesting. Is this with or without lvl 2 CPU cache enabled?

Maybe I should experiment with some different memory managers, this suggests it could be because Win95 has some memory protection. DPMI or something like that.

[suverman]

Just tested running Lion King at 90mhz inside Win95 - initial stutters aside the game runs full speed. Crashes when running in dos mode.

Interesting. Is this with or without lvl 2 CPU cache enabled?

Maybe I should experiment with some different memory managers, this suggests it could be because Win95 has some memory protection. DPMI or something like that.

L1,L2 enabled.

[throAU]

Just tested running Lion King at 90mhz inside Win95 - initial stutters aside the game runs full speed. Crashes when running in dos mode.

Interesting. Is this with or without lvl 2 CPU cache enabled?

Maybe I should experiment with some different memory managers, this suggests it could be because Win95 has some memory protection. DPMI or something like that.

Could be onto something here. In real x86 land accessing extended memory was (originally?) super slow because if i recall it involved (i shit you not - on the 286 at least) basically a full CPU reset to switch in and out of protected mode to access XMS.

I'm not exactly sure how Win95 deals with DOS games running inside of it other than (if i recall) it spins up some sort of virtual x86 mode environment (whilst staying in protected mode - unlike DOS+XMS memory manager) which could alter the way this particular game is accessing memory and therefore sidestep some of the "wierdness" this game hits with ao486 running a plain DOS memory manager - i think Windows 95 stays running in protected mode and the virtual x86 environment the game sees when running under Windows 95 is likely quite different to what it sees running with DOS and XMS/EMM386/QEMM etc.

Maybe the way that ao486 emulates the cpu switching in and out of protected mode for XMS (or emulated EMS via XMS+EMM386) access is causing this game some issues.


edit:
essentially i'd be looking into how ao486 handles protected mode vs. unreal mode

https://en.wikipedia.org/wiki/Unreal_mode

[Malor]

I bet it's probably the bugs in the high memory handling on AO486; something is wrong with what the core is doing, and those bugs have gone unfixed for a long time. DOS4GW games blow up quite frequently.

Win95 substitutes its own driver, which I'll bet doesn't trigger the AO486's bad memory handling.

[Caldor]

I remember earlier in the AO486 development Warcraft 2 would not run in DOS but you could run it in Windows 95. But then, I suspect the fix for that was DOS32A, the DOS4GW replacement. But that does not seem to be enough for The Lion King.

[Caldor]

I did some tests, tried under Windows 95 and 98, could not get Lion King to run. Maybe it was a special Windows version of the game? I did not try to do anything special to run it, just did not seem to get anywhere. Might be that it just takes a few minutes to start I guess.

[suverman]

I did some tests, tried under Windows 95 and 98, could not get Lion King to run. Maybe it was a special Windows version of the game? I did not try to do anything special to run it, just did not seem to get anywhere. Might be that it just takes a few minutes to start I guess.

I just used the exodos zip file, extracted in a folder on c drive and ran it. Do you have all drivers installed in Win 95? Not sure if that makes any difference.

[Caldor]

Okay, I will try the Exodos version of the game, might not be the version I used.