Core contributions to MiSTer

[paulofduarte]

I couldn't find any similar topic so I decided to create one.

The idea of this topic is for everyone who's interested in contributing with core development/porting/improvement to post their intentions to avoid multiple people working towards similar goals without coordination. Feedbacks from non developers with suggestions are also welcome. Core specific discussions should be done under its own topic.

I'll keep this leading post updated with summaries and links. If I forget something please PM me.

paulofduarte:
- Working on improving ao486 CPU performance. Early stages - No roadmap defined - post

[paulofduarte]

EDITED - Applied suggestions from Sorgelig and Alexh

I'm looking for working towards the following goals in my free time, in this particular order.

Amiga:
- IPF image support. IPF contains all the copy protection data and would allow unmodified games to run.

ao486
- Improve CPU performance. Review the instruction and data caches currently implemented in the core and try to reduce the impact of the memory bottleneck. If necessary, in a later stage look for using the SDRAM to implement a bigger level 2 cache. After that if still interested maybe try to identify and improve some specific instructions.
- CD-ROM images support. I intend to work first with the bin/cue images and later with iso.
- SVGA support. I don't know if it's achievable but I want to try.

[Sorgelig]

IPF support - a lot of work with little gain. Most games are already de-protected. It's not a platform where new games are developed. So, there is no much reason to do it. Well, unless you have a lot of free time and just want to add it anyway. Even in Amiga core there are many other things to improve and get more from result.

What will be really really useful - is your intention to improve the CPU performance of ao486. Without this, both SVGA and CD aren't so useful.
So, i suggest to start from i486 CPU improvements.

[alexh]

ao486 I want to first do some measurements of how many cycles each instruction takes with core comparing to the original 80486 specs

I don't think this is something worth doing. It is unlikely that the 486 HDL designer tried to match the cycle accuracy of the original 486, the wide range of 486 parts and speed grades and different manufacturers meant that the games programmers rarely (never?) wrote effects which relied on cycle accuracy (unlike other closed systems).

The 486 HDL designer, FPGA size / timing permitting, probably made as many instructions as possible single cycle. If coded well the FPGA synthesis tool will identify arithmetic components (adders, multipliers, dividers, and map them to dedicated FPGA hardware rather than synthesizing them using logic gates.

I remember that on avarage the ao486 performs most of the x86 instructions in more than 10 cycles. The execution stages are pipelined, but the memory accesses are not. It simply takes a long time to prepare the memory access operations in the core. Perhaps the instruction fetch is also too slow ?

The original designer hints that memory access is the bottle neck and that should be the part of the design looked at first.

[paulofduarte]

IPF support - a lot of work with little gain. Most games are already de-protected. It's not a platform where new games are developed. So, there is no much reason to do it. Well, unless you have a lot of free time and just want to add it anyway. Even in Amiga core there are many other things to improve and get more from result.

I don't have that much free time, maybe I had underestimated the task as I thought would be an easy one to get started. I see your point and agree it won't be that useful, I just tend to prefer to run things as they were initially designed to. But that's not a good reason enough to spend that much time on a task. I think my time can be better used.

ao486 I want to first do some measurements of how many cycles each instruction takes with core comparing to the original 80486 specs

I don't think this is something worth doing. It is unlikely that the 486 HDL designer tried to match the cycle accuracy of the original 486, the wide range of 486 parts and speed grades and different manufacturers meant that the games programmers rarely (never?) wrote effects which relied on cycle accuracy (unlike other closed systems).

My intention is not try to achieve cycle accuracy, I just want to identify which are the worst case instructions and see if I can improve the HDL to make they require less cycles. But as your next quote suggests the original designer already identified the memory as the biggest bottleneck.

I remember that on avarage the ao486 performs most of the x86 instructions in more than 10 cycles. The execution stages are pipelined, but the memory accesses are not. It simply takes a long time to prepare the memory access operations in the core. Perhaps the instruction fetch is also too slow ?

The original designer hints that memory access is the bottle neck and that should be the part of the design looked at first.

I missed that comment from him. I guessed there wasn't any pipeline as he had ported the cpu from Bochs.

OK so it seems that improving instruction fetch times would bring the most immediate benefit. So I think I'll first start looking to implement a small Level 1 instruction cache using some Memory Blocks in the FPGA (if any available). If I get it right it should improve the performance on fetching most sequential instructions until a branch is hit and the cache needs to be invalidated. But this was the expected behaviour in a 486, no branch-prediction.

[Sorgelig]

ao486 still has a lot of free BRAM.

[paulofduarte]

ao486 still has a lot of free BRAM.

Great.

[paulofduarte]

OK so it seems that improving instruction fetch times would bring the most immediate benefit. So I think I'll first start looking to implement a small Level 1 instruction cache using some Memory Blocks in the FPGA (if any available). If I get it right it should improve the performance on fetching most sequential instructions until a branch is hit and the cache needs to be invalidated. But this was the expected behaviour in a 486, no branch-prediction.

After 20 years as a software developer I should have learned to pay closer attention to the documentation and take a look at the code before speculating what I'm going to change. But I didn't

The core already implements instruction and data cache and their dimensions look correct to me. So I'm going to investigate why the cache is not being as effective as it should and see what I can do to improve it. Now it's time for me to dig into this big core (it seems very well written by the way).

[Sorgelig]

it seems very well written by the way

Except the CPU It's total mess of manual writing and converted from some scripts.

[alexh]

Not sure if it is any info you didn't already have but there is a i586 (Pentium) open source implementation

https://github.com/lmEshoo/sp-i586

[Sorgelig]

I think i saw it. But i forgot why i refused it to use...

[Sorgelig]

Ah, i remember now..
The whole 586 core is in a single verilog file of 7MB!
It's machine generated verilog. If something is not working - then you won't be able to fix it. It's non maintainable source.
The status of the core is also unclear..

Some playroom for paulofduarte

[alexh]

Ah yes. It's been obfuscated. Probably already synthesised to GTECH or an equivalent

[Newsdee]

What I could offer as suggestion / idea is to improve some console cores such as the PC Engine. It's already working well, but the missing games are worth the effort. CD support is probably too much work, but that also has many good games such as Neo Geo ports.

[PhantombrainM]

Oh yes, the PCengine is great! Blazing Lazers!!! (not working at the moment). Lots of cool games. Underated.Insider's tip! (here in Germany).

[glaucon1984]

If I may suggest, an issue present with the ao486 emulator is that its BIOS it's not fully compatible. It somehow maps things in the 640KB-1MB area in a different way than what most machines at the time used to, and this presents incompatibility issues for software that intends to use the upper memory area (from emm386 to Ultima VII).

I'm not sure if this is something related to the Bosch BIOS or more speciffic to the ao486 implementation. In any case, if it was the BIOS, there is always the option to use a real AMI/Award BIOS like the ones used for PCem. I did some tests and I even managed to see Mister+ao486 POST an AMI BIOS with the "American Megatrends" logo in the top-left and the green "Energy" logo in the top-right part of the screen, with an "ERROR: Press DEL to enter SETUP" message, but the keyboard didn't respond.

It wouldn't be that crazy to load a real BIOS, the Amiga core uses the kickstart ROM, although I understand the benefits of using an open source BIOS like Bosch's.

I'm sure this is probably a very different challenge that optimising the x86 performance, but a slow 386 that is accurate seems more useful than a fast 486 without SVGA/CD-ROM.

Don't get me wrong, I would be grateful for progress in any of those parts as well, just leaving this suggestion here in case somebody wants to add it to the list...

[alexh]

use a real AMI/Award BIOS like the ones used for PCem. I did some tests and I even managed to see Mister+ao486 POST an AMI BIOS with the "American Megatrends" logo in the top-left and the green "Energy" logo in the top-right part of the screen. It wouldn't be that crazy to load a real BIOS, the Amiga core uses the kickstart ROM

I imagine it is just copyright reasons they don't do this. Kickstart ROM is copyrighted and you cannot distribute and use without a license. In the same way I imagine the AMI BIOS is the same.

[Sorgelig]

BIOSes have been compiled to specific hardware. You cannot use just random BIOS with ao486 because there are many incompatible undocumented registers.