GroovyArcade live-CD 2020

[cools]

Thank you. I'm not going to mess around much with what the monitor can and cannot do (I've broken chassis in the past that had to be binned due to custom bits failing specifically because of doing this, not fun), although it does ignore frequencies it doesn't like. The Tosh appears to have three presets as well (15k, 25k, 31k) but sizing 480p to full screen also sizes 512p to full screen (400p is smaller) which is neat for 256 line horizontal games and 256 wide vertical games - Raiden rotated and scaled with fake scanlines running horizontally is very wrong, but looks fantastic. I've not checked what it does in 15k with 256p though, perhaps I should.

Back on topic, I'll have time this weekend to work on some stuff. I'd like to package up switchres for Arch as well but the source needs to be in a place that it can be downloaded from without requiring authentication - if you'd be okay with having it packaged up would you be able to update the Google Code repository with the latest version?

[cools]

Great job, Cools!

Question, since I'm not able to test on a high res system - does GroovyMAME *require* the patched Kernel, SDL, and Xorg drivers, or are they only required for low resolution use? And regarding Xorg, is that only required if switchres / modeline_generation is enabled or not?

(IIRC)

Right, I think the dependencies are sorted now: https://aur.archlinux.org/packages/groovyume/

[NightSprinter]

Question: will this branch in the AUR be usable with any variant of Arch (not just Groovy Arcade)?  Also, look to the upcoming 3.16 kernel for significant speed improvements to the open-source nvidia driver for those that also like to use 3D games of any kind with their setup.

[Calamity]

I'd like to package up switchres for Arch as well but the source needs to be in a place that it can be downloaded from without requiring authentication - if you'd be okay with having it packaged up would you be able to update the Google Code repository with the latest version?

Done: https://code.google.com/p/groovyarcade/source/browse/?repo=switchres

[cools]

Question: will this branch in the AUR be usable with any variant of Arch (not just Groovy Arcade)?  Also, look to the upcoming 3.16 kernel for significant speed improvements to the open-source nvidia driver for those that also like to use 3D games of any kind with their setup.

I'm building packages on top of Arch standard, so yes provided the patches are kept up to date for xorg drivers and crucially - SDL. Thanks to Calamity pointing out the EDID trick I'm using a stock kernel, and I've had to do no Groovy specific configuration work bar setting up that bit and generating a correct ume.INI file.

Having never used Arch before I absolutely adore the packaging system, its extremely neat, flexible and easy to hack about with.

[cools]

I'm all out of ideas. I don't particularly feel like dissecting the GA beta to see if 15khz works with the intel driver there, but I'm stumped getting it working here.

[Calamity]

Maybe simply the Intel driver is not up to the level of the radeon or even the nouveau drivers. Or they have different layers of range checking that we're missing.

For older ATI models we need the ati9200_pllfix-3.12.diff. This is because pre ATOM-bios GPUs are programmed through a different code path inside the radeon driver (combios). Some relevant information as the dotclock min/max values are hardcoded in the bios of those card and the drivers read them from there, so additional patching is necessary to make low resolutions possible.

Just mentioning this as it came to my mind... this can be quite complex to achieve. At the time when the ATI patches were figured out, Chris Kennedy was in contact with Alex Deucher from ATI who helped us solving several problems. IIRC some dotclock issues found by Chris were fixed at the time and actually got incorporated to the main branch of the radeon driver.

[cools]

Way beyond me then

Switchres package is done. The kernel needs an updated package, just validating it compiles okay then it'll be uploaded.

[NightSprinter]

This may seem like the wrong place, but has anyone tested DOSbox at all?  I know that DOS was known for some funky resolutions, and some games used custom modes/timings (like JROK's rather superb clones of Pac-Man and Ms. Pac-Man, which actually had the original 288x224 as a feature for cards and monitors that could support it).

[NightSprinter]

So far nearly everything is working beautifully in Manjaro Linux (a fork of Arch) from the live distro.  I've noticed a small issue on some games (primarily vertical/TATE mode ones), in that it remains at the game's resolution instead of switching back to the previous one (which I think cools might've reported as well).  In fact, it's virtually the same for any game that goes below a horizontal resolution of 320 seems to do so (meaning that the patched X.Org drivers are in fact required to switch back properly).  Not so much a bug, but something for users to keep in mind.

[Calamity]

I've moved the custom EDID messages (by Cools, Doozer, Elvis, etc.) to a separate thread, so they can be found more easily in the future:

http://forum.arcadecontrols.com/index.php/topic,140215.msg1447520.html#msg1447520

[Calamity]

Just adding a note here in case anyone is interested.

A couple of weeks ago I was doing some extensive tests with GroovyMAME running in Arch Linux (GroovyArcade), specifically measuring input lag with a camera. I tried all sort of modifications to the OpenGL part to remove the existing lag, including rendering directly to the front buffer to discard any flipping and the possibility of a hidden frame queue. I just got a very modest improvement as compared to the default situation, and in the best case 2 or 3 frames behind what you get with Windows XP.

I thought this was interesting enough to note because the only explanation I can think of is that Linux is significantly slower when it comes to deliver input events than Windows XP. Then I came across this:

https://github.com/ValveSoftware/steam-for-linux/issues/2547
https://wiki.archlinux.org/index.php/Pro_Audio

Which suggests that using a low latency kernel might be the answer to the problem. So if anyone wants to experiment it could be interesting to build one of these kernels with the Groovy patches and try.

[cools]

I can probably find some time this weekend for that, albeit it'll be by feel rather than anything scientific

[Calamity]

I can probably find some time this weekend for that, albeit it'll be by feel rather than anything scientific

That would be great. If you make it available I'll be testing it with my camera here.

[cools]

Sure thing, I can make the package available or just the AUR build so you can compile it yourself? The latter would be quicker

[Calamity]

Sure thing, I can make the package available or just the AUR build so you can compile it yourself? The latter would be quicker

I think I should be able to compile it myself if you pass me the AUR build. I'll ask your help in case I have difficulties installing, etc. (it should install over my existing Groovy kernel shouldn't it?)

[cools]

I'll build it so it has the same name as the GroovyArcade one, depending on whether that conflicts with AUR or not I'll probably just upload a package somewhere for you.

[cools]

Linux-rt source package with Ansa89 patches for building with makepkg and overwriting the stock GroovyArcade kernel. Basic instructions.

Code: [Select]

unzip linux-3.14[TAB]
tar xzf linux-3.14[TAB]
cd linux-3.14[TAB]
makepkg -s
sudo pacman -U linux-3.14.tar.xz

Currently compiling it - it may not complete but I've no reason to doubt it will as the patches all apply fine.

[Calamity]

I'll build it so it has the same name as the GroovyArcade one, depending on whether that conflicts with AUR or not I'll probably just upload a package somewhere for you.

If you mean a conflict with an existing AUR package I don't believe there's any apart from yours. In fact Ves told me you could rename your kernel packages as "groovyarcade" to make them more "official" (it's up to you).

[Calamity]

Linux-rt source package with Ansa89 patches for building with makepkg and overwriting the stock GroovyArcade kernel. Basic instructions.

Awesome! Thanks!

My understanding is that I need an internet connection to build it, that's a bit of a problem... my cabinet is not connected and I don't have an Arch x64 install, I use Mint in VirtualBox for compiling, which uses a different package system, anyway I'll see what can be done.

[cools]

The kernel in GroovyArcade is the "standard" Arch file name - i.e. using it requires no bootloader changes. The linux-groovy kernel uses its own file name so requires an additional bootloader entry, but this means the standard kernel can be switched to at any point if necessary.

This one is the standard.

Once it's compiled and I've checked it works I'll upload a binary package for you.

[cools]

https://drive.google.com/folderview?id=0BxaCVgxhLwHFZlFmczVYcWpiM28&usp=sharing

[Calamity]

I'm going to try it, will post later...

EDIT:
Thanks a lot for the files!

Ok so I've just tested this kernel, the installation was absolutely smooth and everything working perfectly. Unfortunately I see no improvement in input responsiveness as compared to the normal kernel. The best results I got with this kernel have been with the experimental GM build that renders on the front buffer. Recording at high speed shows it is roughly 2 frames behind my results with XP in the same computer. It is not a frame queue and this kernel should be highly optimized to minimize lag so I'm out of ideas.

[cools]

Hmm
http://ck.kolivas.org/patches/bfs/bfs-faq.txt

[cools]

Further reading suggests linux-rt requires specific development against to use properly, its not simply a silver bullet

http://stackoverflow.com/questions/9374653/real-time-scheduling-in-linux
http://askubuntu.com/questions/51283/how-to-run-a-program-with-sched-rr-policy-from-command-line

[cools]

I've spent an hour messing around with the -rt kernel and assigning realtime priority (chrt) to various things (X, Groovy) along with higher priority in general on I/O (ionice). Not noticed a jot of difference, except for a headache as X isn't rotated and it's my vertical cab.

[cools]

I'm going to have a go with linux-ck when I get the chance. I've a feeling it might be X causing it rather than the kernel though, the lag wasn't the problem when using AdvanceMAME...

[cools]

https://drive.google.com/folderview?id=0BxaCVgxhLwHFZlFmczVYcWpiM28&usp=sharing

Now has Linux-ck kernel Arch package with 15khz patches as well.

This one will require you to update Grub or Syslinux.cfg for the new filename, I didn't want to waste time checking through the PKGBUILD for this one.

(It feels far more responsive than stock or -rt in the VM I'm using for compilation, fwiw)

[Calamity]

Hi cools,

Thanks a lot for the new kernel (-ck). I managed to install it and created a new entry in syslinux.cfg in order to use it (this was surprisingly easy).

Then I tested GroovyMAME again, and unfortunately I'm getting the same results regarding lag. When recording at 120 Hz, this means I have a frame count of 6 to 8, from the moment the led lights up until the action happens (Terra Cresta), being 6 frames very rare and 8 the most usual value. This translates into 3-4 real frames, as compared to 1.5-2 of XP.

Maybe I should have run some command to assign a higher priority to the GM process?

(Due to my incompetence I managed to destroy my Groovy pendrive installation by taking it out from the usb too early so I'll have reinstall it tonight. These usb installations are incredibly delicate).

I'm going to have a go with linux-ck when I get the chance. I've a feeling it might be X causing it rather than the kernel though, the lag wasn't the problem when using AdvanceMAME...

Yes, it might be X causing the lag... but the same lag was present in the tests done by Vicosku, using Retroarch in KMS mode (no X).

It looks like the Windows raw input method beats anything we've seen by now.

[cools]

Seems like we need to start testing specific areas and eliminate things. I'm not sure how the more complex bits can be checked other than with a specific tool to do so - GM has a bunch of dependencies that make it difficult to pin down what's causing the bottleneck.

I don't think it's anything to do with scheduling priority.

Does the X driver using KMS use much of the kernel? Is it sane to think there's a flip queue or similar actually in the kernel radeon module?

Kernel > text mode console.
Kernel > framebuffer console.
Kernel > Xorg (VESA/ATI etc)
Etc

[Calamity]

Does the X driver using KMS use much of the kernel? Is it sane to think there's a flip queue or similar actually in the kernel radeon module?

My first thought was that a flip queue was the culprit, but I'm almost certain that the GM build I'm using should bypass it if it existed. Tonight I'll upload a diff. Basically I've modified it so I perform the wait for vsync directly through drm and I force OpenGL to draw to the front buffer (no flip at all). This causes all sort of glitches but at least I can discard any flip queue.

There are also evidences that there's no such flip queue here.

That's why I'm more open to believe it has to do with lag in the input events themselves.

[cools]

Okay, have you tried recording footage external to GM ? I.e. using the LED and Advmenu, or the LED and Xterm, or even just the raw framebuffer console in GASetup? Also "sudo cat /dev/input/event2" (assuming event2 is your keyboard, you can find out using sudo evtestlist)

My web searches are drawing a blank regarding keyboard input response in evdev. Plenty about the mouse though.

http://www.freedesktop.org/software/libevdev/doc/0.5/

[Calamity]

Okay, have you tried recording footage external to GM

Not yet. Great idea.

[MonkeyJug]

Guys, I need help!

I just upgraded my cabinet hardware to:

G3258
ASrock Z97 Pro3
8GB 2400Mhz RAM

Now when I install the latest beta live CD (24/04/2013), it messes up the sound.  it's an ALC892 onboard chip.  The sound is really distorted, and crackles and echoes.  It's made the whole thing unplayable as I need sound.  I have chosen the right sound card in audio options. The only other option is my ATI HD4300 graphics card, but I am connecting my speakers via the green 3.5mm socket...

How can I fix this?

[MonkeyJug]

seems like there is an issue with Z97 chipsets and audio:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1321421

[MonkeyJug]

could someone please test Deathsmiles for me and see if it runs at a constant 100% on their setup please?

the speed of this game was fluctuating between ~94-104% on my old AMD setup, and i expected it to be perfect after upgrading to a much better intel setup...

[Whipon]

Hello.
Has anyone any video issues with the game Violent Storm?.
I have an strange issue with this game, the video shakes unless I rotate the screen or use cocktail mode.
Any ideas?.
Regards .

[sean_sk]

could someone please test Deathsmiles for me and see if it runs at a constant 100% on their setup please?

the speed of this game was fluctuating between ~94-104% on my old AMD setup, and i expected it to be perfect after upgrading to a much better intel setup...

What is your current CPU and what is it clocked at? I found that I had to overclock my Intel i7 960 CPU to at least a minimum of 4.0GHz to obtain 100 percent speed for games like Deathsmiles and Muchi Muchi Pork. It's default is 3.2GHz and it's certainly no slouch of a CPU. At default clock speeds I was getting the same results as you.
You could try messing around with blitter settings but I found it did nothing for me. Cave emulation at the moment is barely adequate, but it needs to improve.

[MonkeyJug]

it's:

G3258 (OC'd from 3.2 to 4.4)
ASrock Z97 Pro3
8GB 2400Mhz RAM

is your 100% speed constant? does it even fluctuate at all?  like briefly down to 94% and back up again?  what about the sound warbling?

have you made any changes at all to the mame.ini file, or are you using default install settings?

[Stathman]

I was struggling to get my hantarex arcade monitor to work with windows xp with no luck.

Soft15khz, drivers, compatible cards, settings, quickres, etc...

The best i could get, was a shaking picture.

I changed the V.Freq. potentiometer three times. I was despair. I was about to give up.

And then i accidentally found this holy thread.

In about an hour, my monitor was reliving its glorious days.

Retina display my @ss!!!

Thanks a lot guys.