Core contributions to MiSTer

https://github.com/MiSTer-devel/Main_MiSTer/wiki

Moderators: Mug UK, Zorro 2, spiny, Greenious, Sorgelig, Moderator Team

paulofduarte
Retro freak
Retro freak
Posts: 13
Joined: Fri Jul 13, 2018 10:10 pm

Core contributions to MiSTer

Postby paulofduarte » Fri Aug 17, 2018 7:26 am

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
Last edited by paulofduarte on Fri Aug 17, 2018 1:23 pm, edited 5 times in total.

paulofduarte
Retro freak
Retro freak
Posts: 13
Joined: Fri Jul 13, 2018 10:10 pm

Re: Core contributions to MiSTer

Postby paulofduarte » Fri Aug 17, 2018 7:36 am

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.
Last edited by paulofduarte on Fri Aug 17, 2018 5:15 pm, edited 2 times in total.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2863
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core contributions to MiSTer

Postby Sorgelig » Fri Aug 17, 2018 7:48 am

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.

User avatar
alexh
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2704
Joined: Wed Oct 20, 2004 1:52 pm
Location: UK - Oxford
Contact:

Re: Core contributions to MiSTer

Postby alexh » Fri Aug 17, 2018 9:17 am

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

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 ?

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

paulofduarte
Retro freak
Retro freak
Posts: 13
Joined: Fri Jul 13, 2018 10:10 pm

Re: Core contributions to MiSTer

Postby paulofduarte » Fri Aug 17, 2018 11:49 am

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.


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.

alexh wrote:
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 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.

alexh wrote:
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 ?

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
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2863
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core contributions to MiSTer

Postby Sorgelig » Fri Aug 17, 2018 2:33 pm

ao486 still has a lot of free BRAM.

paulofduarte
Retro freak
Retro freak
Posts: 13
Joined: Fri Jul 13, 2018 10:10 pm

Re: Core contributions to MiSTer

Postby paulofduarte » Fri Aug 17, 2018 2:39 pm

Sorgelig wrote:ao486 still has a lot of free BRAM.


Great.

paulofduarte
Retro freak
Retro freak
Posts: 13
Joined: Fri Jul 13, 2018 10:10 pm

Re: Core contributions to MiSTer

Postby paulofduarte » Fri Aug 17, 2018 5:10 pm

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


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
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2863
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core contributions to MiSTer

Postby Sorgelig » Fri Aug 17, 2018 5:22 pm

paulofduarte wrote:it seems very well written by the way

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

User avatar
alexh
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2704
Joined: Wed Oct 20, 2004 1:52 pm
Location: UK - Oxford
Contact:

Re: Core contributions to MiSTer

Postby alexh » Fri Aug 17, 2018 7:48 pm

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
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2863
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core contributions to MiSTer

Postby Sorgelig » Fri Aug 17, 2018 7:53 pm

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

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2863
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core contributions to MiSTer

Postby Sorgelig » Fri Aug 17, 2018 8:12 pm

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

User avatar
alexh
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2704
Joined: Wed Oct 20, 2004 1:52 pm
Location: UK - Oxford
Contact:

Re: Core contributions to MiSTer

Postby alexh » Fri Aug 17, 2018 10:43 pm

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

User avatar
Newsdee
Atari God
Atari God
Posts: 1200
Joined: Fri Sep 19, 2014 8:40 am

Re: Core contributions to MiSTer

Postby Newsdee » Sat Aug 18, 2018 10:25 am

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
Atari maniac
Atari maniac
Posts: 78
Joined: Fri Mar 16, 2018 9:10 am

Re: Core contributions to MiSTer

Postby PhantombrainM » Sat Aug 18, 2018 1:19 pm

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.

glaucon1984
Retro freak
Retro freak
Posts: 15
Joined: Fri Aug 04, 2017 12:23 pm

Re: Core contributions to MiSTer

Postby glaucon1984 » Mon Aug 20, 2018 12:33 am

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

User avatar
alexh
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2704
Joined: Wed Oct 20, 2004 1:52 pm
Location: UK - Oxford
Contact:

Re: Core contributions to MiSTer

Postby alexh » Mon Aug 20, 2018 9:01 am

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

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
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2863
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core contributions to MiSTer

Postby Sorgelig » Mon Aug 20, 2018 2:01 pm

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


Return to “MiSTer”

Who is online

Users browsing this forum: Kintaro, TillDawn and 7 guests