Standardize sys folder

[addisonElliott]

I noticed that the sys folder has some inconsistencies between core to core. For example, I was playing around with the menu core and noticed that the pattern generator in lite mode for HDMI is random noise while in the FpgaGen core it is a checkered display.

I think that would make it more organized for porting cores if each project is using the same system files.

My idea would be to have no sys folder in each of the cores but rather a script that pulls the sys folder from a Github repository. Yes, if you edit the sys folder, then it could break compatibility for some cores but I think that would be a way of keeping each core up to sync with the latest sys folder.

So if changes were made to the sys folder, it would propagate to each of the cores. Also, updating the cores would be a breeze by simply pulling from the sys repository again.

As a newcomer to MiSTer, it is difficult to be able to understand and create/port a core when each example core has slight variations in the sys folder.

@sorgelig What are your thoughts on this?

[sorgelig]

Sys folder is already standardized and it's easy to see that i'm trying to keep it as-is among most cores. Unfortunately some cores need special support and require changes. HDL has no inheritance like C++ and you cannot simply extend/change behavior. There are cores using generic sys folder - i use them as a donors. Sometimes i update sys with new functions - that's why it may look differently in old cores.

[addisonElliott]

Well HDL doesn't have inheritance but it does support macros which could be of use. If you need "special support", why not have one standard sys that has different macros that can be set for special support. This would be ideal for cases where there are a minimal number of changes in the sys folder.

I understand that you're trying to keep the sys folder standardized but with the amount of cores supported, I can definitely see it is difficult to maintain that. I'm suggesting that creating one repository for the sys folder (or multiple if you deem it necessary) is better than copying the sys folder for each of the cores.

As an example, I believe 5 days ago you added a commit for HDMI support in Lite for ZX Spectrum but I don't believe it was updated for any of the other cores. Also, some of the emu cores have HDMI signals and some don't. This can be confusing to newcomers such as me.

I was thinking, this could be implemented using Git submodules. You could just link each core to the sys submodule and have it download that.

[sorgelig]

Only arcade cores have separate HDMI and VGA signals because they require screen rotation. It's pure arcade feature and won't require for normal cores. So, i don't see a reason to move it into standard sys feature. I'm against flood of macros and conditional compilation as it quickly become hard to read and hard to maintain.

Currently, i'm the only who maintain all MiSTer cores. So, i'm free to choose how to do this. There are the only hard standard is the pin definition. Everything else is up to developer of the core. I've created a framework(sys) primarily for myself for easier porting of the cores from other platforms. Do you want to take some cores and maintain them? Do you want to improve the cores? You can take some and create standardized framework between them. Don't tell me you are simply passing by stranger who decided to give an advice for newbie.

[addisonElliott]

Oh okay, that makes sense regarding the arcade cores and screen rotation.

I definitely don't have the expertise to manage the cores. In addition, much like you I don't have that much time to work on the cores or MiSTer. I'm a master's student in Electrical Engineering and I discovered this project for a class of mine (High Performance Architectures II). We were playing around with the DE10 Nano and I found this to be interesting.

I wouldn't say I'm giving advice to a 'newbie'. It's more like a suggestion. Also, I wanted to get your feedback before I attempted to standardize the sys folder. I wouldn't want to submit a PR that would be rejected immediately.

[sorgelig]

You don't need submit all your changes to my repository. Of course if you will refactor the code a lot, PR won't be accepted since PR is not designed for such cases. PR is rather for small changes than big re-design. New framework cannot be proven on a single core. It should be proven on several non-similar cores to make sure it can fit into cores with different functions. Make a fork of several cores you want to improve or want to make some standardization and implement what you want. It can be merged to my repositories later if i will like the result. The main advantage of open source is ability to fork and make what you want.