The NEW Build Your Own Arcade Controls
Software Support => GroovyMAME => Topic started by: SteelRush on August 30, 2018, 05:55:28 pm
-
I am experiencing an issue on my K7000 that any resolutions below 60hz, have a weird ripple. It is not a line or very visible distortion, but the picture is waving slightly. I do not know how else to describe it, and my phone appears incapable of capturing it. I am running on a R7 240 with CRTEmudriver Beta 13, GroovyMame 0.196, and I have the same effect on Windows and GroovyArcade. Has anyone experienced this and knows how to resolve it?
-
Has anyone experienced this and knows how to resolve it?
Have you tried adjusting the V and H sync pots?
-
i'd like to say "interference?" but it's odd it only happens below 60hz
i'd like to say look at the diagram below, but again it's odd it only happens below 60hz
http://i261.photobucket.com/albums/ii66/Pietenpol_bucket/Flowchart-WellsGardnerK7000RandyFro.jpg (http://i261.photobucket.com/albums/ii66/Pietenpol_bucket/Flowchart-WellsGardnerK7000RandyFro.jpg)
i'd like to say "is your video cable ok" ...
-
Do you mean that the resolutions are like that all the time, or only when you run games with GM, GroovyArcade?
If the latter, my guess would be that something is wrong in your mame.ini, probably to do with sync. There are a few related options there like syncrefresh, waitvsync, triple buffer etc and in general they should be set to "0" as GM manages all that automatically. Keep autosync=1 as this gives GM control.
Or maybe try copying a fresh mame.ini from latest GM install over your old one, adjust rom folder setting as need.
If this is a problem with your K7000 monitor rather than the software, then that is another issue. Try asking on the Monitor/Video branch.
-
Has anyone experienced this and knows how to resolve it?
Have you tried adjusting the V and H sync pots?
I have. It happens on both of my K7000 monitors and my Hantarex 900/E below 60hz. All tried with crtemudriver on a j-pac. I tried removing the j-pac and just hooked the monitor directly to the pc with the same result. This is happening in multiple cabinets on different j-pacs, so I doubt it is a monitor issue.
Sub-60hz refresh rates also do this in arcade-osd. I tried grabbing the latest GM with stock config and it has the same issue.
-
go through mame.ini, check those sync & triplebuffer settings.
Delete everything in your cfg and ini folders too, just to be sure.
This seems def to be a software or at least graphics card issue.
EDIT: attach logs!
-
go through mame.ini, check those sync & triplebuffer settings.
Delete everything in your cfg and ini folders too, just to be sure.
This seems def to be a software or at least graphics card issue.
EDIT: attach logs!
I did clean up and verify that the settings are correct. I tried a stock GroovyArcade to see if perhaps it is an issue on Windows, and the same thing happens in Linux as well. My GPU is the R7 240 and same issue on R7 250. I have a stack of older GPUs so I will see if maybe it is the GPU.
What logs would be helpful?
-
I'm very new to GM but i think i have the exact same issue. I'm running a vertical setup with CRT Emudriver 2.0, GM 0.195, Win7, Radeon 4350 > JPAC > New Astro City with a Nanao MS929 monitor.
Being new to all this i just asumed my monitor is faulty, but maybe it's a software issue? I tested a variety of games and the ones below 60hz have this issue. It's like a ripple effect that's mostly visible when the screen is scrolling, but not the whole screen is affected. Lowering the focus knob on the monitor helps a bit, but it's not an optimal solution.
Please see attached log.
-
What logs would be helpful?
Logs from the emulators you've tried and had problems with. Not really for me to read, but Calamity will need them to make any sense out of it. You can see the command in Calamity's sig line. You'll need to run the game from command line eg:
groovymame64 fshark -ror -v > fshark.txt
There's also normally a log for VMMaker in the directory you run it from.
-
What logs would be helpful?
Logs from the emulators you've tried and had problems with. Not really for me to read, but Calamity will need them to make any sense out of it. You can see the command in Calamity's sig line. You'll need to run the game from command line eg:
groovymame64 fshark -ror -v > fshark.txt
There's also normally a log for VMMaker in the directory you run it from.
Thank you for the information. I will pull some logs tomorrow. Sublevel attached some logs with what seems to be the same issue, so perhaps they will help in the meantime. I appreciate everyone’s responses and help.
-
Here is my missing log. This GPU is a R5 220 running CRTEmuDriver Beta 13. Sorry about that.
This is BurgerTime running at 57hz.
-
There seems to be a lot of mode changing. I probably should have left the -ror out earlier, as GM should accommodate vertical games automatically anyway and including -ror might confuse it, e.g.:
Groovymame64 fshark -v > fshark.txt
I'm wondering whether arcade monitors in general might have problems with such 54hz and 57hz modes, although this doesn't seem likely (they would certainly be out of range for a normal TV and my Sony Profeel (which freaks out between 51.5 and 58.5). Although this seems like a compromise, until a better response comes from someone like Calamity (problem with drivers?) you could try limiting video mode creation in VMMaker to cut out the frequency ranges that cause the problem.
Sorry to not be more helpful.
Cheers, Zeb
-
There seems to be a lot of mode changing. I probably should have left the -ror out earlier, as GM should accommodate vertical games automatically anyway and including -ror might confuse it, e.g.:
Groovymame64 fshark -v > fshark.txt
I'm wondering whether arcade monitors in general might have problems with such 54hz and 57hz modes, although this doesn't seem likely (they would certainly be out of range for a normal TV and my Sony Profeel (which freaks out between 51.5 and 58.5). Although this seems like a compromise, until a better response comes from someone like Calamity (problem with drivers?) you could try limiting video mode creation in VMMaker to cut out the frequency ranges that cause the problem.
Sorry to not be more helpful.
Cheers, Zeb
I omitted the rotate command when I generated the log, so no worries there. I also have a real BurgerTime PCB and it plays flawlessly on the same monitor. K7000 was one of the most common arcade monitors there was, so I doubt it would be inherent to the monitor. Thanks for looking.
-
Steelrush, could you try Ibara and Ketsui and see if you get the ripple effect in those two games? Thanks.
-
Steelrush, could you try Ibara and Ketsui and see if you get the ripple effect in those two games? Thanks.
Not getting the ripple in Ibara, but Ketsui and DoDonPachi are rippling. The logs are attached.
-
Well, as i stated above i can get around this issue by altering the focus pot on the monitor but then the convergence is also affected. So instead i tried forcing bilinear filtering and that also completely removed the ripple effect at the cost of some blur. I did this by creating a new ini-file, vertical.ini, and added the string "filter 1". It's better than altering the focus pot at least.
-
On one of my cabinets, the ripple effect was eliminated when I created a custom monitor entry to better match the geometry of the arcade monitor. Both cabinets are running 19” K7000, running fine on real PCBs. But the second K7000 monitor is rippling even after the geometry adjustment.
I am working on about 5 cabinets all running J-Pacs and CRTEmuDriver, and my next cabinet is running a K7000 25”. I will see if it has the same issue. I also will be working on a D9200 and U3000.
-
Photos would be useful here as well as the logs.
-
I have been unsuccessful in getting it to show up in videos/pictures, but I will try again. I moved the logs throughout this post to my first post, so they are easier to find.
-
My phone cannot seem to capture the issue. I am going to try and locate my tripod, and hope perhaps a webcam can catch it. In the meantime, I found a video that shows the rippling I am talking about. Please note that the video goes crazy and shaky at the end which my setup is NOT doing:
https://m.youtube.com/watch?v=g0e--BZVg6o
The first few seconds show a ripple, which is very similar to what my monitors are doing.
The monitor is vertically mounted and this happens with any resolution about 58hz or below. I have tried static resolutions and super resolutions with the same result. Hopefully a visual aid can help you understand the issue.
-
Does the K7000 have a degauss button? What happens if you press it?
-
Does the K7000 have a degauss button? What happens if you press it?
No degauss button. I have a degauss ring I use for my arcade monitors if it gets bad.
There is a degauss circuit built into the K7000 that briefly activates when the monitor is turned on.
This issue only seems to be present on games that run below 60hz.
-
The normal pcbs you tried run also below 60 Hz?
-
The normal pcbs you tried run also below 60 Hz?
I have an original BurgerTime PCB which is 57hz.
-
So please clarify this to me, is this happening with different computers or you're always using the same pc in all your cabs?
-
So please clarify this to me, is this happening with different computers or you're always using the same pc in all your cabs?
In two different cabs I have Dell 790 SFF PCs running R5 220 GPUs. These are separate machines, they just are spec the same. Both cabinets are vertical.
-
Ok.
I asked you that just in case it could be an issue with the pc's power suppy. Bad power supplies can cause interferences on CRTs.
Basically none of my ideas fits here:
- An unstable dotclock: it can't be that if it fails for both normal and super resolutions.
- A faulty degaus circuit: it could be it doesn't cut the current completely, but the same in 2 monitors? And only below 60 Hz? No way
- Bad psu: in 2 computers? I don't think so.
- Bad timings: it could be that, but those timings work perfectly for hundreds of users. Also it's so odd that both the Hantarex and the K700 show the problem.
At this point I can't think of anything aside of some big engine being connected to your electric network or something like that.
-
Could a step-down converter cause this issue? I have the same issue as OP and i'm in Europe using a 240v-110v converter to power a Nanao MS9-29 monitor.
-
Could a step-down converter cause this issue? I have the same issue as OP and i'm in Europe using a 240v-110v converter to power a Nanao MS9-29 monitor.
It guess it might be possible.
But OP's issue doesn't happen with PCBs, so my guess is the issue lays on the PC, rather than the cabinet.
My debugging "algorithm" would be making 100% sure it's not a timing issue, by testing a 57 Hz sample mode in Arcade OSD and playing with all relevant geometry settings (horizontal). If that doesn't help, then try doing changes on the pc hardware, try with a spare psu, a different card, etc. If the cabinet has fluorescent lamps, try to turn them off, etc.
I currently have a similar issue with one of my cabinets, it started happening after a house move. But here it doesn't depend on the refresh, it happens with all modes, and it gets better for I while when I press the degauss button, so I suspect it has to do with the degauss circuit. It's hard to notice unless you look very close.
What you need to understand is this IS a hardware issue. Whether or not this can indirectly be fixed by software means is a different thing. What you're seeing is a horizontal sync pulse which length or position is not stable.
-
The issue might be as simple as your monitor's grounding - make sure that your monitor/CRT is grounded to the monitor chassis ONLY. Otherwise other components attached to the same ground (eg PC) can cause interference. This might be a good time to check that the grounding strap (often has a spring) at the back of the monitor's CRT is properly in place (ie pulled snug up with the aquadag/black paint on the back of the tube) and attached to the chassis too.
Keeping monitor ground away from other grounds is even more important if you are using an isolation/stepdown transformer (which makes your monitor an isolated circuit and effectively provides a local ground, safer), which I guess you probably are already.