Core contributions to MiSTer
Moderators: Mug UK, Zorro 2, spiny, Greenious, Sorgelig, Moderator Team
-
- Atariator
- Posts: 17
- Joined: Fri Jul 13, 2018 10:10 pm
Core contributions to MiSTer
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
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
Last edited by paulofduarte on Fri Aug 17, 2018 1:23 pm, edited 5 times in total.
-
- Atariator
- Posts: 17
- Joined: Fri Jul 13, 2018 10:10 pm
Re: Core contributions to MiSTer
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.
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.
Last edited by paulofduarte on Fri Aug 17, 2018 5:15 pm, edited 2 times in total.
Re: Core contributions to MiSTer
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.
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
- Fuji Shaped Bastard
- Posts: 2827
- Joined: Wed Oct 20, 2004 1:52 pm
- Location: UK - Oxford
- Contact:
Re: Core contributions to MiSTer
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).paulofduarte wrote:ao486 I want to first do some measurements of how many cycles each instruction takes with core comparing to the original 80486 specs
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.
The original designer hints that memory access is the bottle neck and that should be the part of the design looked at first.alfikpl wrote: 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 ?
-
- Atariator
- Posts: 17
- Joined: Fri Jul 13, 2018 10:10 pm
Re: Core contributions to MiSTer
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.Sorgelig wrote: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.
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.alexh wrote: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).paulofduarte wrote:ao486 I want to first do some measurements of how many cycles each instruction takes with core comparing to the original 80486 specs
I missed that comment from him. I guessed there wasn't any pipeline as he had ported the cpu from Bochs.alexh wrote:The original designer hints that memory access is the bottle neck and that should be the part of the design looked at first.alfikpl wrote: 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 ?
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.
Re: Core contributions to MiSTer
ao486 still has a lot of free BRAM.
-
- Atariator
- Posts: 17
- Joined: Fri Jul 13, 2018 10:10 pm
Re: Core contributions to MiSTer
Great.Sorgelig wrote:ao486 still has a lot of free BRAM.
-
- Atariator
- Posts: 17
- Joined: Fri Jul 13, 2018 10:10 pm
Re: Core contributions to MiSTer
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'tpaulofduarte wrote: 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.

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).
Re: Core contributions to MiSTer
Except the CPUpaulofduarte wrote:it seems very well written by the way

- alexh
- Fuji Shaped Bastard
- Posts: 2827
- Joined: Wed Oct 20, 2004 1:52 pm
- Location: UK - Oxford
- Contact:
Re: Core contributions to MiSTer
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
https://github.com/lmEshoo/sp-i586
Re: Core contributions to MiSTer
I think i saw it. But i forgot why i refused it to use...
Re: Core contributions to MiSTer
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
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
- Fuji Shaped Bastard
- Posts: 2827
- Joined: Wed Oct 20, 2004 1:52 pm
- Location: UK - Oxford
- Contact:
Re: Core contributions to MiSTer
Ah yes. It's been obfuscated. Probably already synthesised to GTECH or an equivalent
Re: Core contributions to MiSTer
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.
-
- Captain Atari
- Posts: 187
- Joined: Fri Mar 16, 2018 9:10 am
Re: Core contributions to MiSTer
Oh yes, the PCengine is great! Blazing Lazers!!! (not working at the moment). Lots of cool games. Underated.Insider's tip! (here in Germany).
Two beer or not two beer? - Shakesbeer.
-
- Atari User
- Posts: 36
- Joined: Fri Aug 04, 2017 12:23 pm
Re: Core contributions to MiSTer
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...
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
- Fuji Shaped Bastard
- Posts: 2827
- Joined: Wed Oct 20, 2004 1:52 pm
- Location: UK - Oxford
- Contact:
Re: Core contributions to MiSTer
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.glaucon1984 wrote: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
Re: Core contributions to MiSTer
BIOSes have been compiled to specific hardware. You cannot use just random BIOS with ao486 because there are many incompatible undocumented registers.