Raining glitch Minimig-AGA core

[Julitium]

Hi. In the latest version of the Minimig-AGA core (200923) glitch occurs on the screen (more similar to "raining") including the OSD. I use the mist at 15khz Scart and A500 ECS configuration. In the previous version it doesn't happen (checked).

Regards.

[robinsonb5]

Could you try the alternative build found in this related bug, please? https://github.com/mist-devel/mist-binaries/issues/90#event-3811062178

If that's no different, could you try to capture the effect in either a photo or video, please?

[gyurco]

Actually I also encountered some vertical glitching lines in the RTG cores. It can be mitigated by manually adjusting the pixel clock phase on the monitor (but then it'll happen some pixels later). The cause is the scaling of the analogue signal, however it wasn't that obvious on the old cores. Probably for the non-rtg modes, the 28 MHz clock could be used for the video output pipeline. I've done it on the MiSTery core, too, using the altclkctrl megafunction. It's really easy to use: https://github.com/gyurco/MiSTery/blob/master/mist/mist_top.sv#L106

[robinsonb5]

Yeah, the "jailbars" are more pronounced now, but I think that's because of the dithering, which was previously off by default. Merely reconnecting the dithering on/off control should mitigate this. (Thanks for the hint re altclkctrl - I don't think it's needed here though, since all pixel clocks, native and RTG, are currently derived from the 114MHz clock.)

It sounds as though Julitium's glitch is something different, though - it sounds like it's constantly moving? Vertically, or diagonally?

[Julitium]

Hi. Yes, it is dynamic ..... It is like a snow effect (random). It happens on the system screen and in the OSD. In photos or videos the camera does not pick it up well. It reminds me of the 128kb spectrum raining that was produced by bus collision (a bad GAL equation). In previous versions it does not happen, I have tried it. Greetings.

[gyurco]

I've tried the altclkctrl method, and helps with my monitor. It's in the big PR I've sent you. Picking up the signal from clk_28 in clk_114 in a specific phase (vga_strobe signal) still can be risky, I think. Here's a test build to see if it fixes the issue for Julitium. minimig_mist_test_issue91.zip

[Julitium]

Hi.

Thanks Gyurco, tested version and same results.

Greetings.

[gyurco]

Then robinsonb5 was right, it should be the dithering. What about applying the external dithering only to RTG, and leave the old method for chipset video?

[robinsonb5]

Reverting to old-style dithering is certainly a possibility for MiST (the other targets need better dithering because they only have 4 or 5 bits per gun intead of 6) - however, I think the default setting for the internal dithering is "off"? So just being able to disable the toplevel dither would be a start.

(I also think we should try to avoid dithering before the YPbPr conversion if we possibly can.)

Julitium, could you try the previous core, please, and let me know if you see any hint of this effect in any of the four dithering modes? (Off, Spatial, Temporal, Both)?

I believe the root cause of this is when the dither pushes a colour value from, say 6'b001111 to 6'b010000, the transition in the analogue signal is imperfect; the pins have different loadings due to the super-simple DAC (when I wrote that blog post years ago I never dreamed it would end up in an actual product!) so respond at slightly different rates. So if there's jitter on the monitor's sampling clock, it might randomly sample 6'b011111, or 6'b000000 or somewhere inbetween, depending on rise/fall times and exactly when the sampling happens. 28MHz is probably too fast to be dithering a non-scandoubled signal, too - 14 would be better since that would equate to high-res rather than super-high-res pixels.

[Julitium]

Hi.

No, in the previous version the dithering does not produce differences in any Mode (OFF, SPT, RND, S + R). I have also tried the rest of the options ... In the latest version the scanlines option does not work either.

Greetings.

[robinsonb5]

Useful to know - thanks.

[gyurco]

Here's another build - the chipset video should be the same as before. minimig_mist_test2_issue91.zip

[Julitium]

Hi. The result is the same but now the scanliner works (the fault is more evident with it on). Sorry. Thank you.

[gyurco]

And this one? minimig_mist_test3_issue91.zip

[Julitium]

Hi. It remains the same, I have tried all the possible combinations. The problem is elsewhere. Sorry. Thanks Gyurco.

[Julitium]

Hi. The new version continues with the same problem. This time if I change the mode to NTSC the problem disappears, unfortunately I am limited to the software that works in that mode.

Thank you very much.

Greetings.

[robinsonb5]

So it looks like it's related to the base clock, then. Did you try the alternative build I linked to earlier in the thread - I don't remember seeing your results? You can find it in this bug: https://github.com/mist-devel/mist-binaries/issues/90#event-3811062178

[Julitium]

Hi. Exactly, the bugfixed core works perfectly. I apologize if I made you work because of me. Is there any way to set it as a global option for future versions ??

Thank you very much Robinsonb5 and Gyurco.

Greetings.

[robinsonb5]

No need to apologise :) The core in the other thread isn't a bugfix as such.

The situation is that PAL and NTSC Amigas use a very slightly different base clock - the older MiST Minimig cores always use the NTSC base clock, even in PAL mode - and for some reason your monitor is happier with that. My cores use a PAL base clock (even in NTSC mode!) and your monitor doesn't like that for whatever reason.

The latest core switches base clock depending on the PAL/NTSC setting, which is why it works for you in NTSC mode. I think Gyurco added an option to mist.ini so you can force one clock or the other?

[gyurco]

Yes, you can force the use of the NTSC master clock even in PAL mode: https://github.com/mist-devel/mist-board/wiki/DocIni#clock_freq

[Julitium]

Hi.

I have updated the firmware and I have put the key to force the mode but it remains the same. I am doing something wrong??

Thank you very much.

[gyurco]

Should be good. The OSD switch still works?

[Julitium]

Hi.

Yes, the option in OSD works. I'm going to try everything well

Greetings.

[Julitium]

Hi.

I can't get it to work.

Fun fact, if I load the "NTSC fixed" core and then load the last core it works fine.

Greetings.

[Julitium]

Hi.

If I load the last core twice it works too. Maybe you need to lock the NTSC mode before?

Greetings.

[gyurco]

If you have a fixed setup in ini, then the OSD switch shouldn't change the clock. I'll investigate.

[gyurco]

Try the attached one, it's not tested at all by me minimig_mist_testntscswitch.zip (no MiST nearby).

[Julitium]

Hi. Core tested and same result. I have also tried deleting the configuration files without success. Sorry.

Thank you very much.

[gyurco]

Ok, I think the problem was in the firmware (sent the setting to the FPGA before parsed the ini). Can you try this update? firmware_test.zip

[Julitium]

Hi.

Tested !!! ..... Mist bricked !!!! LOL. It works perfectly. It is a success. It's not the first time you've gotten me out of trouble.

Thank you very much Gyurco and Robinsonb5.

[gyurco]

Hehe, you cannot scare me :) MiST is really hard to brick, and unbrickable via USB.

[Julitium]

Perfect for me.

Thank you very much.