Graphical issues and removal of OPL PLL

[gtaylormb]

I'm a bit dubious of https://github.com/MiSTer-devel/ao486_MiSTer/commit/1b1580985a3bfaa1a800c1d187ebdbdbd32ee632

My inclination is graphical issues and HDMI timing are more largely affected by the build seed, as people are experiencing graphical issues even with this new change and the latest release: https://misterfpga.org/viewtopic.php?p=87043#p87043 and https://misterfpga.org/viewtopic.php?t=8001

In my own experience doing lots of builds recently, timing varies quite a bit from build to build (i.e. changing the build seed). The HDMI clock will occasionally have failing timing paths. The main system clock always fails by quite a bit so difficult to say if this also factors in. Did you happen to save the timing reports from your latest release build 20240528?

[sorgelig]

I didn't save that report. But this core is known to have instability from build to build. With additional dedicated OPL3 PLL it was way beyond acceptable stability. So removing that PLL bring core back to its "normal" instability at least. SEED can be tweaked with every build (or some meaningless change in code like i do) to find a better build.

[sorgelig]

Generally speaking, this core needs a faster fabric for timing closure.

[gtaylormb]

Gotcha. A few weeks ago I dug into the failing paths on the system clock a little bit. All the worst paths were going through the TLB. I took a look at that code and I can see why--massive amounts of combinational logic stacked up in a single cycle. Have you or anyone tried to optimize that module for timing? I imagine it might be quite an undertaking.

[sorgelig]

It's extremely hard to fix as many operations with wide bus must be done in one cycle. CPU is originally designed such way. As far as i understood, originally it was just a concept "is it possible to implement i486?". Also you may find kind of scripts in comment. So it seems part of CPU is auto-generated from higher level script/language. Some systems like this would be better to implement as a hybrid emulation where CPU is emulated in software while the rest of system is implemented in FPGA. CPU is basically a black box with sequential input/output so there won't be any downside from software emulation. But advantages are obvious - faster x86 such as Pentium with FPU. So i hope newer Altera SOC FPGA will allow such implementation - it has more HPS CPU cores, so at least one CPU core can be dedicated for CPU emulation.

[gtaylormb]

Yeah, that architecture does seem to be the way to go--emulating the CPU using SW.

I'm pretty new to MiSTer--what all is running on those cores right now? Are both being used? Can core developers modify the code running on the CPU? Based on my very limited knowledge of the SW thus far there appears to be some lightweight version of Linux running. Some people have expressed desire for Retrowave OPL3 support but that is implementing real USB so I believe the easiest route would have to go through the CPU. I might take a stab at that someday, though with the FPGA implementation being pretty darn accurate at this point it lessens the need. Would just be cool though.

While we're on the subject, where do you see MiSTer heading, hardware-wise? Like what boards are being considered? Is this being discussed anywhere? I'd like to check out any discussion.

[sorgelig]

Hybrid emulation isn't implemented in MiSTer yet. Current FPGA SOC has not enough CPU cores and speed. So this feature is for future FPGAs like Agilex 5 or similar. Another way is to connect RPi zero 2 instead of analog board and let it run CPU emulation, but considering bad availability (and crazy prices) of RPi in recent years, this option doesn't look viable anymore.

About Retrowave OPL3: this option looks redundant and not worth to implement since we already have OPL3 implemented. If there is something missing then it's better to improve implementation. There are so many USB devices you can connect - it doesn't mean everything must be supported. It has to be maintained too. Also adding such streaming device will require additional polling of data between FPGA and HPS which may affect other functions due to limited bandwidth. It will require additional driver for linux, etc, etc.. Just because subtle difference in sound in some games.

There is USER I/O port where it's possible to add an option to connect external OPL3, similar to MIDI. Of course it won't be USB and will require either special board with compatible interface or converter from user i/o to USB.

[gtaylormb]

I hear you about Retrowave OPL3--it's not necessary and would be a pain to implement and maintain. If people find any more test cases in which there's an audible difference I'll fix in OPL3_FPGA.