psakhis / Groovy_MiSTer

Groovy nogpu
GNU General Public License v2.0
103 stars 4 forks source link

Horizontal jittering and color channel rotation (was: Red screen) #5

Closed luxocrates closed 3 months ago

luxocrates commented 4 months ago

I can run the core and see the bouncing red, green, blue sprite. But when I connect to it from GroovyMAME (0.261 on a Mac), I just get a solid red screen. Until I quit MAME, at which point the bouncing sprite returns.

If I try use the MiSTer file and RBF from the test-builds, I see a black screen with a few red pixels at the top-left, slightly jittery. When I then connect I see a burst of color noise, then a black screen.

luxocrates commented 4 months ago

FWIW, logging at verbose level 3 shows a whole lot of lines like:

[00.040][GET_STATUS][DDR px=0 fr=0 bl=0][GPU vc=172 fr=2 fskip=0 vb=0 fd=0][VRAM px=0 queue=0 sync=0 free=1 eof=0]

luxocrates commented 3 months ago

I now have a Windows host (0.263, official release). Same result: the moment it connects, it's a solid red screen on the MiSTer.

luxocrates commented 3 months ago

With latest builds, and current stable, the red screen is gone. I do now get an image, but it's twitching badly, with about a third of frames showing the whole screen horizontally offset, roughly 180 degrees out of phase.

psakhis commented 3 months ago

Test 20240401, all of it.

luxocrates commented 3 months ago

Similar results. For mame, the twitching is now very high frequency (mostly alternate 60Hz frames, but not stable), and the frames that are offset horizontally also have their RGB channels rotated.

MiSTerCast worked much better. If there's no motion, the image is stable and correct, except for about one frame every second. If there's motion, corruption is frequent, and not the predictable offset-H offset-channels that mame had.

https://github.com/psakhis/Groovy_MiSTer/assets/3223304/29f48659-d1db-4c41-9c60-c3ce4700c059

psakhis commented 3 months ago

Hi! For diagnose it i need some files. 1) attach mame.ini (i understand you have all options on it without passing other args) 2) set verbose 1 on core settings (save settings and restart core) 3) attach /tmp/groovy.log (with 20 or 30 seconds of emulation) 4) be sure your ping is less than 1ms and using 20240401 last build (core, mister and last groovymame)

luxocrates commented 3 months ago

So the ping turned out to be everything. I was seldom getting <1ms. Usually 1ms and often 2ms.

This was using good, new, short Ethernet cables going direct from the PC to the MiSTer. I then tried using an external USB-to-Ethernet transceiver instead and everything worked great!

I'm surprised the built-in Ethernet on the PC (an Intel NUC) was that much worse than a cheap external one, but super glad to have gotten this working. Thank you so much for your support and for developing this project! It's a really great way to enjoy 15kHz games on real CRTs.

luxocrates commented 3 months ago

I'll add one last comment, in case anyone else is reading this in future: the video I posted earlier wasn't using the -mister_compression lz4 switch. With it, I would get much less coherent corruption, as you can imagine. The same as I was seeing with MiSTerCast.

psakhis commented 3 months ago

Some users reports on Win11 needs disable power save options on ethernet controller to work with.

As you say, lz4 compression reduces bandwith requeriments, but ping it's a really important factor here.

luxocrates commented 3 months ago

You're right, the power save options seem to make a difference. Specifically, I needed to change 'Idle power down restriction' to 'Enabled' for my 'Intel(R) Ethernet Controller I226-V' to stream smoothly

image

I'm guessing it's similar to this random reddit post