The NEW Build Your Own Arcade Controls

Software Support => GroovyMAME => Topic started by: Substring on April 09, 2019, 07:21:58 am

Title: Collaborative effort for GroovyArcade
Post by: Substring on April 09, 2019, 07:21:58 am
Hi everyone,

Here is an attemps of going a little more open source for GA. I've set up a gitlab group gitlab repo (https://gitlab.com/groovyarcade) showing all projects I'm working on regarding GroovyArcade.

So the aim of this repo is to:

DISCLAIMER
This is does not build a usable GA yet ! The ISO is bootable, you can launch X, even GM, but it's a real bare Arch linux ISO with GM and a few other emulators. The kernel is not even patched with 15kHz (despite the 15kHz is packaged). The repo is more a proof of concept that much can be automatically done to build the final iso.

What needs to be done
Well, still much in fact (this list is not complete, just showing major steps):

For curious people

Final word
I hope we can make it grow in a real GroovyArcade build system!

Credits and thanks go to Calamity, ves and doozer for their respective work on groovymame, groovyarcade, linux 15kHz patches and help on questions I've been asking them.

Edit: well, all that was written months ago, erad the thread for more news. But if you want to go straight to the main stuff (download an iso and test) :
ISO DOWNLOAD LINK : https://github.com/substring/os/releases
Prefer releases in the YYYY-MM format, any other is a testing branch and will be deleted. Unless you wanna debug with me :angel:
Title: Re: Collaborative effort for GroovyArcade
Post by: keilmillerjr on April 09, 2019, 03:24:39 pm
So long as there become a well documented readme and still an option at boot to select display, im all for no gasetup. Will check it out soon and hopefully can contribute in some way even if small.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 10, 2019, 07:22:26 am
So long as there become a well documented readme and still an option at boot to select display, im all for no gasetup. Will check it out soon and hopefully can contribute in some way even if small.
I've written a wiki at https://gitlab.com/substring45/test/wikis/local-build (https://gitlab.com/substring45/test/wikis/local-build), it should have all the info to locally build, but I may have missed some parts/pre-requisites
Title: Re: Collaborative effort for GroovyArcade
Post by: cools on April 11, 2019, 03:52:38 am
Is there a reason not to use the central AUR?

I had packages there for Groovy a couple of years ago, just don't have the time to maintain anymore.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 11, 2019, 05:00:11 am
Is there a reason not to use the central AUR?

I had packages there for Groovy a couple of years ago, just don't have the time to maintain anymore.

Good question! I considered for a moment submitting packages to AUR. But haven't done it yet for a few reasons:
- as for now, I feel it easier to handle packages on my side. It's just 2 of them : groovymame and the 15khz kernel
- I feel it's better for now if people want to contribute to the repo, and not lock AUR packages to me only
- keeping it up with the linux package that updates every 5 days is too demanding for now

But that's something I could definitely consider in a near future. Or if someone wants to take the task, that's a good thing.

Which packages had you added to AUR ? Feel like resurrrecting them ?
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on April 11, 2019, 06:45:40 am
Hi substring,

I'll look into your repo as soon as I have time. Thanks for your work.

Hopefully I can get the Switchres library updated. Currently it's a mess.

@keilmillerjr, if you remove GA, how would people do the required setup? Most users can't even manage command line.
Title: Re: Collaborative effort for GroovyArcade
Post by: keilmillerjr on April 11, 2019, 08:41:36 am
Hi substring,

I'll look into your repo as soon as I have time. Thanks for your work.

Hopefully I can get the Switchres library updated. Currently it's a mess.

@keilmillerjr, if you remove GA, how would people do the required setup? Most users can't even manage command line.

Gasetup was filled with things that didnt work, and most likely had to configure by editing the files directly anyways. I guess broken items and lacl of documentarion leads me against it. Honestly, id be happy if i can get it 15khz kernel patched, and groovymame working with switchres.
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on April 11, 2019, 10:32:53 am
Gasetup was filled with things that didnt work, and most likely had to configure by editing the files directly anyways. I guess broken items and lacl of documentarion leads me against it. Honestly, id be happy if i can get it 15khz kernel patched, and groovymame working with switchres.

Well if that's the case, I think it'd be better to do a thorough cleanup and remove deprecated parts or fix what doesn't work. I really like the old school text menu system rather than a GUI setup, but that's me. But I do believe you need a setup system, otherwise you're restricting GA to users already familiar with Linux, which probably don't really need GA after all.

With regards to 15 kHz kernel patches, I think we should move away from hardcoded patches and adopt EDID emulation if possible. I like to think about custom video in general rather than "15 kHz" because there are many types of monitors you can use for emulation, and Switchres/GroovyMAME supports any possible configuration, so by restricting it to 15/31 kHz you're loosing a lot of flexibility.

In my view, the problem we currently have, as I've been discussing with Ves, is that modern video cards have lots of heads, and GA boot menu can't target the required one anymore. It was designed for older cards that were 2-head most of the times, so we had prefixed boot optios for VGA-1-15kHz, VGA-2-15kHz, etc. That doesn't work anymore, so I've been stuck lately from testing new GA releases because my working systems are all multi-headed, so unless I rewire my monitors the way GA expects I can't launch it on the monitor I want, and that's not good. We'd need something more flexible for the boot menu, but I doubt you can implement any complex logic in there (specially one that can poll the outputs).

Once in X, we also have the problem that multi-headed configurations are not handled properly. This is fixable, but it requires changes both to Switchres/GM and to the scripts that make the X configuration.

So if I had to improvise a list of things that need to be done, this is mine:

- Move Switchres to a library (not GA specific task).
- Move GA kernel mode setting to use EDID emulation instead of fixed kernel patches.
- Handle multi-head systems properly (both in boot menu and in X).

Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 11, 2019, 01:25:41 pm
Well if that's the case, I think it'd be better to do a thorough cleanup and remove deprecated parts or fix what doesn't work. I really like the old school text menu system rather than a GUI setup, but that's me. But I do believe you need a setup system, otherwise you're restricting GA to users already familiar with Linux, which probably don't really need GA after all.
Whether gasetup is perfect ror not, it's still much more advanced than anything else to configure GA. So if it needs some fixes, the best way is to make a gasetup repo and let people report issues and contribute :)
Quote
With regards to 15 kHz kernel patches, I think we should move away from hardcoded patches and adopt EDID emulation if possible. I like to think about custom video in general rather than "15 kHz" because there are many types of monitors you can use for emulation, and Switchres/GroovyMAME supports any possible configuration, so by restricting it to 15/31 kHz you're loosing a lot of flexibility.

In my view, the problem we currently have, as I've been discussing with Ves, is that modern video cards have lots of heads, and GA boot menu can't target the required one anymore. It was designed for older cards that were 2-head most of the times, so we had prefixed boot optios for VGA-1-15kHz, VGA-2-15kHz, etc. That doesn't work anymore, so I've been stuck lately from testing new GA releases because my working systems are all multi-headed, so unless I rewire my monitors the way GA expects I can't launch it on the monitor I want, and that's not good. We'd need something more flexible for the boot menu, but I doubt you can implement any complex logic in there (specially one that can poll the outputs).

Once in X, we also have the problem that multi-headed configurations are not handled properly. This is fixable, but it requires changes both to Switchres/GM and to the scripts that make the X configuration.
now we hit a wall, and i have quite a few questions regarding the EDID way + the good arch linux documentation at https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes_and_EDID (https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes_and_EDID):
- seems like EDID can be "forced" to all connectors, not a specific one. So I guess we could have 2 EDIDs : one for 15kHz, one for 25kHz, as I suppose 31kHz screens wouldn't need a specific EDID. Now the question is : how to generate these EDIDs ? The old switchres standalone can generate some, are they reliable ? Or should we patch the kernel as suggested in the arch doc ? or just use some prebuilt ones (link ?) ?
- regarding X: could you go in more details regarding the problems with multihead ? can't ge things the way you want with just xrandr ?

Quote
So if I had to improvise a list of things that need to be done, this is mine:

- Move Switchres to a library (not GA specific task).
- Move GA kernel mode setting to use EDID emulation instead of fixed kernel patches.
- Handle multi-head systems properly (both in boot menu and in X).
I wish Ves had a little more time to give a hand on how he customized Arch to make the magic work, reverse-engineering GA is not a funny task.

Anyway, you are all free to submit issues on the gitlab repo so that I can organize my work. Beside a few things here and there regarding CI, error handling and other minor stuff, my first goal is to have the build boot X and launch GM (FEs will come later), and script some testings in virtual box to ease my pain.
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on April 11, 2019, 01:52:20 pm
now we hit a wall, and i have quite a few questions regarding the EDID way + the good arch linux documentation at https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes_and_EDID (https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes_and_EDID):
- seems like EDID can be "forced" to all connectors, not a specific one. So I guess we could have 2 EDIDs : one for 15kHz, one for 25kHz, as I suppose 31kHz screens wouldn't need a specific EDID. Now the question is : how to generate these EDIDs ? The old switchres standalone can generate some, are they reliable ? Or should we patch the kernel as suggested in the arch doc ? or just use some prebuilt ones (link ?) ?
- regarding X: could you go in more details regarding the problems with multihead ? can't ge things the way you want with just xrandr ?

Check this thread: http://forum.arcadecontrols.com/index.php?topic=140215.0

The target head can be a specific one, here for example VGA-1:

Code: [Select]
drm_kms_helper.edid_firmware=VGA-1:edid/edid-15khz.bin
The actual wall is how to know which outputs (VGA-1, VGA-2, etc.) your card has in order to create a practical boot menu.

Old standalone Switchres can create the edid files just fine, the new one will be better of course, anyway there was a bug with AMD's EDID code affecting interlaced modes that forced us to code a workaround in old Switchres to handle interlace properly. Now, instead of that I'd rather report the bug to AMD so they fix it and keep our Switchres code correct, so it can be used for Intel and Nvidia too.

The issue in X can be fixed with xrandr, or just from X conf files I guess, so multi head setups work as extended desktops rather than cloned displays. But GM also needs a fix, so the -screen option in mame.ini is honored.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 11, 2019, 02:03:29 pm
Not specifying an output would probably force the EDID to all outputs, wihch seems a good option to me, instead of listing VGA-n/DVI-n. But this would probablykill setups having a second LCD monitor for usual config.

A dirty trick could be:
- find connected outputs
- if a connected output can't give an EDID, then it's probably the CRT one, so adapt grub with it.

But this requires at least 1 boot cycle.

Is switchres64 the old switchres standalone found at https://github.com/Ansa89/switchres (https://github.com/Ansa89/switchres) ? If yes, I'll write a small PKGBUILD and have it compiled with GA.
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on April 11, 2019, 02:18:30 pm
Not specifying an output would probably force the EDID to all outputs, wihch seems a good option to me, instead of listing VGA-n/DVI-n. But this would probablykill setups having a second LCD monitor for usual config.

That's the exact issue I want to prevent. All my systems except my cabinet are dual-head these days, a decent system must allow you to choose the desired output.

Quote
A dirty trick could be:
- find connected outputs
- if a connected output can't give an EDID, then it's probably the CRT one, so adapt grub with it.

But this requires at least 1 boot cycle.

That wouldn't work if you have a PC CRT monitor, because those have EDID. Here on the other desk I have a system with 2 heads, one PC CRT (31-kHz) and a BVM (15-kHz). I'd like to be able to decide which head to boot the system on.

Quote
Is switchres64 the old switchres standalone found at https://github.com/Ansa89/switchres (https://github.com/Ansa89/switchres) ? If yes, I'll write a small PKGBUILD and have it compiled with GA.

Last version posted by me was this one (http://forum.arcadecontrols.com/index.php/topic,106405.msg1438711.html#msg1438711). IIRC Ansa took that one and fixed some bugs, etc., not sure.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 12, 2019, 06:10:59 am
Wouldn't it be better to have EDIDs generated with the kernel ? It's just some .S files to add in https://github.com/torvalds/linux/tree/master/Documentation/EDID (https://github.com/torvalds/linux/tree/master/Documentation/EDID). It looks rather easy
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on April 12, 2019, 07:12:09 am
Wouldn't it be better to have EDIDs generated with the kernel ? It's just some .S files to add in https://github.com/torvalds/linux/tree/master/Documentation/EDID (https://github.com/torvalds/linux/tree/master/Documentation/EDID). It looks rather easy

That code does not support interlace unfortunately.

The good thing about having the EDIDs created by Switchres is you can control the geometry also out of X. Even if no one ever will use that, I prefer that conceptually over having the EDIDs hardcoded with the kernel. If the later results to be more practical, then it's ok as long as we can add EDIDs for all the existing GM presets (e.g., ntsc, pal, arcade_15, arcade_31, etc.).
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 12, 2019, 05:21:53 pm
Wouldn't it be better to have EDIDs generated with the kernel ? It's just some .S files to add in https://github.com/torvalds/linux/tree/master/Documentation/EDID (https://github.com/torvalds/linux/tree/master/Documentation/EDID). It looks rather easy

That code does not support interlace unfortunately.

The good thing about having the EDIDs created by Switchres is you can control the geometry also out of X. Even if no one ever will use that, I prefer that conceptually over having the EDIDs hardcoded with the kernel. If the later results to be more practical, then it's ok as long as we can add EDIDs for all the existing GM presets (e.g., ntsc, pal, arcade_15, arcade_31, etc.).
Doesn't suppoer interlace ? mmhhhhh ... reading the EDID.S, it seems a bit sets interlace, but never mind, let's not waste time on this yet.

Anyway, the real problem is to set an EDID post kernel boot if you want to get rid of those VGA-n DVI-n options on grub ... except probing connectors and respective EDIDs and make a dirty assumption "this output is connected but has no edid" means "apply the edid on it, i have no idea how to make that easy. And even : edid is a kernel parameter, so it's set at boot. Unless using kexec (which is a bad idea still), i'm clueless ...
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on April 13, 2019, 01:59:29 pm
Doesn't suppoer interlace ? mmhhhhh ... reading the EDID.S, it seems a bit sets interlace, but never mind, let's not waste time on this yet.

If you look at the "features" byte, bit 7 is never used. I know this because I used that code as a base for my implementation.

Quote
Anyway, the real problem is to set an EDID post kernel boot if you want to get rid of those VGA-n DVI-n options on grub ... except probing connectors and respective EDIDs and make a dirty assumption "this output is connected but has no edid" means "apply the edid on it, i have no idea how to make that easy. And even : edid is a kernel parameter, so it's set at boot. Unless using kexec (which is a bad idea still), i'm clueless ...

I'm thinking probing the outputs before launching the menu is not feasible. Just wondering if there's a way to use nested menus instead of the long list we use now. GA was create when everything we cared about was VGA and DVI ports. Now we should also consider HDMI at least, as it's the only way we can get RGB from with newer cards. Anyway, maybe it's more clever to just have standard 15/25/31 kHz EDIDs built with the kernel so they're available for setting things up, the if someone wants to refine the boot picture a better EDID may be added later. IIRC the only difficulty is you need to add those EDID binaries to the initramfs later so they're available during boot.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 14, 2019, 11:13:37 am
If you look at the "features" byte, bit 7 is never used. I know this because I used that code as a base for my implementation.
OK, so i gave a try to https://github.com/akatrevorjay/edid-generator wchich bascally looks like the kernel code for EDIDs + some script around to convert a X modeline to a .S file (needs zsh). Patched the edid.S to allow external configuration of the whole byte that has the interlace bit.

So i fed the zsh modeline2edid with the result modeline of a parse-edid from a 480i 15kHz edid generated by switchres, edited the .S to enable interlace, and compiled the EDID. parse-edid gives the following result :

Code: [Select]
Checksum Correct

Section "Monitor"
Identifier "480i_15khz"
ModelName "480i_15khz"
VendorName "LNX"
# Monitor Manufactured week 5 of 2012
# EDID version 1.3
# Analog Display
DisplaySize 160 120
Gamma 2.20
Option "DPMS" "true"
Horizsync 14-16
VertRefresh 59-61
# Maximum pixel clock is 20MHz
#Not giving standard mode: 640x480, 60Hz
Modeline "Mode 0" 13.00 640 664 728 832 480 482 488 521 +hsync +vsync interlace
EndSection

Not such a bad start! I'm surprised that th epolarities are inverted, frequency ranges changed too, but it means that patching the kernel to build EDIDs can be done very easily.

By the way, the did.S patch:
Code: [Select]
--- a/edid.S
+++ b/edid.S
@@ -237,7 +237,7 @@ y_border:   .byte   0
    Bit 1       If analog sync: Sync on all 3 RGB lines (else green only)
    Digital: HSync polarity (1=positive)
    Bit 0       2-way line-interleaved stereo, if bits 4-3 are not 00. */
-features:      .byte   0x18+(VSYNC_POL<<2)+(HSYNC_POL<<1)
+features:      .byte   FEATURES+(VSYNC_POL<<2)+(HSYNC_POL<<1)
 
 descriptor2:   .byte   0,0     /* Not a detailed timing descriptor */
                .byte   0       /* Must be zero */
And in .S file, you just set
Code: [Select]
#define FEATURES 0x18 + 1<<7and voil ! May need a little tweaking still, but it looks promising.

Quote
I'm thinking probing the outputs before launching the menu is not feasible. Just wondering if there's a way to use nested menus instead of the long list we use now. GA was create when everything we cared about was VGA and DVI ports. Now we should also consider HDMI at least, as it's the only way we can get RGB from with newer cards. Anyway, maybe it's more clever to just have standard 15/25/31 kHz EDIDs built with the kernel so they're available for setting things up, the if someone wants to refine the boot picture a better EDID may be added later. IIRC the only difficulty is you need to add those EDID binaries to the initramfs later so they're available during boot.
I'm not sure i've correctly explained what I mean. What I'm talking about is to "autoconfigure monitors" based on a simple choice : 15/25/31kHz at grub boot, no matter which outputs you're using. We can probe connected outputs using /sys/class/drm/*/status (see arch linux wiki https://wiki.archlinux.org/index.php/Kernel_mode_setting at the very end).

I naively thought "if an output is connected but has no edid, then it's the arcade monitor". But most probably not : I'm not sure a DVI2VGA would say the output is connected, and some HDMI2VGA report dummy EDID (when some do query the monitor hopefully).
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on April 14, 2019, 01:03:55 pm
I'm not sure i've correctly explained what I mean. What I'm talking about is to "autoconfigure monitors" based on a simple choice : 15/25/31kHz at grub boot, no matter which outputs you're using. We can probe connected outputs using /sys/class/drm/*/status (see arch linux wiki https://wiki.archlinux.org/index.php/Kernel_mode_setting at the very end).

I naively thought "if an output is connected but has no edid, then it's the arcade monitor". But most probably not : I'm not sure a DVI2VGA would say the output is connected, and some HDMI2VGA report dummy EDID (when some do query the monitor hopefully).

Hi Substring,

This was a nice pointer!

So do you think this could be scripted somehow to build the grub menu?

Code: [Select]
$ for p in /sys/class/drm/*/status; do con=${p%/status}; echo -n "${con#*/card?-}: "; cat $p; done
DVI-I-1: connected
HDMI-A-1: disconnected
VGA-1: disconnected

I don't care about the connected/disconnected status. Arcade monitors will often fail to get discovered by the gpu for not having the expected impedance, so we'll need to forcely enable the connection. But having the real *list* of connectors at boot time can be gold.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 14, 2019, 01:21:00 pm
I'm afraid we can't list connectors as the script uses some kernel info. And when we're on the grub menu, the kernel is not yet loaded. So we could eventually dive in the grub source direction, or any other bootloader. But gosh, that's some work.

edit1: by "So do you think this could be scripted somehow to build the grub menu?" did you mean adding generated EDIDs and auto-script a grub menu with them ? yes, probably, just give me details of what you'd expect.

edit2: grub can just read VESA modes from GPU, nothing more. So the boot menu can't be dynamic. If arcade screens are not detected by the GPU, why should we bother ? Let's just force the Horizontal frequency selected at boot (but this is once kernel is loaded, not at grub boot). The only risky case would be having 2 CRT monitors with different Hfreq (which i guess hardly ever happens)
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on April 15, 2019, 03:53:06 am
Hi Substring,

I'm afraid we can't list connectors as the script uses some kernel info. And when we're on the grub menu, the kernel is not yet loaded. So we could eventually dive in the grub source direction, or any other bootloader. But gosh, that's some work.

Ok, definitely, no kernel calls before kernel is loaded :) I agree, the other direction is one I don't feel like to go through, it involves a lot of work, probably real mode x86 asm, uncertain chances of success and it's not worth the effort.

Quote
edit1: by "So do you think this could be scripted somehow to build the grub menu?" did you mean adding generated EDIDs and auto-script a grub menu with them ? yes, probably, just give me details of what you'd expect.

No, I meant the dynamic menu thing, so since it's not possible we don't need to bother. I'd just make the raw .bin EDID files available to the kernel, one for each 15/25/31 kHz ranges, that's all.

Quote
edit2: grub can just read VESA modes from GPU, nothing more. So the boot menu can't be dynamic. If arcade screens are not detected by the GPU, why should we bother ? Let's just force the Horizontal frequency selected at boot (but this is once kernel is loaded, not at grub boot). The only risky case would be having 2 CRT monitors with different Hfreq (which i guess hardly ever happens)

That's exactly what I have here. I need GA to only force a certain frequency through the output I ask it for. This is not a whim of mine, it's a guideline I strongly believe the project should follow. Not only this project but all emulation software. Unfortunately we have 99% of emulators making poor assuptions about user's display setups. I suspect most emulator coders don't run multi-monitor setups themselves so they don't care or can't even test it.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 15, 2019, 04:35:53 am
Hey Calamity,

That's exactly what I have here. I need GA to only force a certain frequency through the output I ask it for. This is not a whim of mine, it's a guideline I strongly believe the project should follow. Not only this project but all emulation software. Unfortunately we have 99% of emulators making poor assuptions about user's display setups. I suspect most emulator coders don't run multi-monitor setups themselves so they don't care or can't even test it.

Well, most emulators don't need to care about screen settings as they don't need to go in depths of how the screen works. They rely on SDL2 which outputs on anything you'd wish (OpenGLES, OpenGL through X, KMS/DRM). Even SDL2 (opposite to SDL1) doesn't fool around with resolutions anymore. It's all a matter of "get the proper emulation speed" rather than "get the real video output". And emulators choice is the one for less effort with maximum result : don't care about screen resolution, just let the backend handle stretching, as long as you can have a constant FPS matching the original hardware. CRT addicts are on a whole different level ;)

Now back to the initial configuration stuff : we can't do anything at grub level, we may eventually do something with early KMS in the initramfs. But still : the EDID is already loaded, I haven't found a way to reload it once the system has booted up. Just found a virtual KMS (vkms) in the kernel doc that allows to change the EDID, but it's in the TODO ... meh ... So we're stuck with xrandr and other linux tools, no magic plug and play at boot. There is a massive Pi community that just begs for proper CRT display ;)

Side note regarding your "libswitchres" : May I suggest you consider a "fixed pixel clock" setting ? The reason is that the Raspberry Pi can generate analog signals through its GPIO (or  even HDMI), but you can't set the pixel clock you wish, It's locked to either 4.8, 6.4, 9.6, 19.2 MHz (or beyond 31MHz). Write this demand somewhere for the next years!
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on April 15, 2019, 05:17:52 am
Well, most emulators don't need to care about screen settings as they don't need to go in depths of how the screen works. They rely on SDL2 which outputs on anything you'd wish (OpenGLES, OpenGL through X, KMS/DRM). Even SDL2 (opposite to SDL1) doesn't fool around with resolutions anymore. It's all a matter of "get the proper emulation speed" rather than "get the real video output". And emulators choice is the one for less effort with maximum result : don't care about screen resolution, just let the backend handle stretching, as long as you can have a constant FPS matching the original hardware. CRT addicts are on a whole different level ;)

I'm not even asking coders to care about resolutions :) I'm just saying that many of us use multi-monitor setups. And just defaulting everything to run on the primary display is poor design. This is valid for LCD too.

Quote
Now back to the initial configuration stuff : we can't do anything at grub level, we may eventually do something with early KMS in the initramfs. But still : the EDID is already loaded, I haven't found a way to reload it once the system has booted up. Just found a virtual KMS (vkms) in the kernel doc that allows to change the EDID, but it's in the TODO ... meh ... So we're stuck with xrandr and other linux tools, no magic plug and play at boot. There is a massive Pi community that just begs for proper CRT display ;)

I'll try to clarify what I intend to have:

1.- We need grub to have options that can map a certain EDID to a certain output.
2.- Once the EDID is selected, it won't be changed later. It just applies to kernel mode setting (boot process and GAsetup).
3.- In X, we'll use the current xrandr implementation (this is why we need a dual video configuration, for both kernel and X independently).

We already have all this, except that #1 is currently is achieved by kernel patches (hardcaded modelines) while I'm advocating for doint it through EDID emulation instead of patches as I think it's more elegant (and while suggesting this I wondered about the possibility of having a dynamic boot menu so we could avoid the absurdly long boot menu we have now, and this is definitely not possible as you have shown).

Quote
Side note regarding your "libswitchres" : May I suggest you consider a "fixed pixel clock" setting ? The reason is that the Raspberry Pi can generate analog signals through its GPIO (or  even HDMI), but you can't set the pixel clock you wish, It's locked to either 4.8, 6.4, 9.6, 19.2 MHz (or beyond 31MHz). Write this demand somewhere for the next years!

I'll consider your suggestion, but can't promise it'll be possible since the whole modeline calculation is based on the assumption that the pixel clock is fully programmable (like it's the case on usual GPUs.) So it would involve an important rewrite of things. The Pi is a terrible platform for emulation, and to top it all off the pixel clock is limited to discrete values. Lots of wasted development hours in the wrong direction IMHO.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 15, 2019, 09:04:51 am
I'll try to clarify what I intend to have:

1.- We need grub to have options that can map a certain EDID to a certain output.
2.- Once the EDID is selected, it won't be changed later. It just applies to kernel mode setting (boot process and GAsetup).
3.- In X, we'll use the current xrandr implementation (this is why we need a dual video configuration, for both kernel and X independently).

We already have all this, except that #1 is currently is achieved by kernel patches (hardcaded modelines) while I'm advocating for doint it through EDID emulation instead of patches as I think it's more elegant (and while suggesting this I wondered about the possibility of having a dynamic boot menu so we could avoid the absurdly long boot menu we have now, and this is definitely not possible as you have shown).

OK, i'll focus on grub using EDID for now then. One step after another !
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 15, 2019, 09:26:21 am
For curious people, just found https://www.kraxel.org/blog/2019/03/edid-support-for-qemu/ -> qemu will support EDID, which is great for testing
Title: Re: Collaborative effort for GroovyArcade
Post by: cools on April 16, 2019, 07:49:53 am
Why not just have the initial boot be 15k on everything, then have a tool to configure outputs + grub menu proper?

And an alternate ISO for LCD/31k boot. Heck, make an image with a FAT partition that when written to USB can have alternate boot configs swapped in.

Of course, I'm assuming installation on writable storage, not static boot from CD/DVD.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 16, 2019, 11:52:33 am
Why not just have the initial boot be 15k on everything, then have a tool to configure outputs + grub menu proper?
Sooner or later, this is what should happen + need a panic button/combo at boot to boot with default settings. But I'm still far from that for now.

Quote
And an alternate ISO for LCD/31k boot. Heck, make an image with a FAT partition that when written to USB can have alternate boot configs swapped in.
Why not!

Quote
Of course, I'm assuming installation on writable storage, not static boot from CD/DVD.

I really wonder who is still using DVDs today. I plan on adding some .img sooner or later, so you could just burn a USB stick with it
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on April 16, 2019, 12:32:04 pm
Why not just have the initial boot be 15k on everything, then have a tool to configure outputs + grub menu proper?
Sooner or later, this is what should happen + need a panic button/combo at boot to boot with default settings. But I'm still far from that for now.

I hate this strongly but I'm afraid it's the only way to do it. Maybe have a timeout at boot (I'm talking about the live-cd, not the installed system), so if you let it alone it'll just boot at 15 kHz through all outputs. Since boot menu is at 31 kHz, choosing an option has always been problematic on a 15 kHz monitor anyway. Optionally, you can press any key and select another boot option. This would make the 31 kHz distro unnecessary.

What needs to be checked is whether selecting an EDID without specifying an output actually enables all of them, even the ones that are NOT detected like those connected to arcade monitors through a JPAC. We might find out there was a good reason to force specific outputs on boot back in the day.

Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 16, 2019, 02:45:24 pm
Hey Calamity,

Do you have news from ves ? I haven't seen him around for a while on the forum, we do need him.

By the way : seems like we can make grub boot in 320x200, 320x240 or any VESA mode that the GPU would support. So cools' idea to have different grubs configured for various resolutions on a FAT32 boot partition is something that could be done on a .img people would burn to a USB key.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 23, 2019, 07:59:55 am
Just a small update : I hope i'll be able to be on par with groovyarcade soon. For now the FE won't start due to some permission problems, shouldn't be that complicated to solve. Will then need to make sure gasetup works as before + will also have to use GA's default for syslinux bootloader.
Title: Re: Collaborative effort for GroovyArcade
Post by: keilmillerjr on May 21, 2019, 11:51:34 am
Free bump for awesome project!
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on May 21, 2019, 04:22:20 pm
haha thanks for the bump @keilmillerjr

Time to give some news about the project :
- i could setup github releases to be a pacman repo, so it's fairly easy now to update the linux kernel or other packages. The kernel is patched with Doozer's patches : usual arcadevga/ati + custom resolutions for 15and 25 kHz + some patches he made for I don't remember what regarding cathode tracing position
- more frontends are available as packages, despite they are not configured yet (retrofe, mehstation, attract mode was updated), some need a little tinkering. I still have to make a package of that old advmenuPlus
- plymouth is done
- HDD installation works as before
- having some problems with X : for i don't know which reason, X is started as root in ves' groovyarcade (despite some sudo here and there). But on my build, it won't just work that way. Put in other words : it doesn't work from gasetup, but works fine from shell. This one bothers me quite much
- after some talk with calamity, i'm exploring the EDID path to set some default resolution rather using the patched ones. Haven't had much luck yet, despite it has worked for some people ...

Sooner or later, I'll have to split the project in 2 : the arch linux packages repo which will then mostly live on its own unless some update breaks everything (automatic builds, automatic deploy to the pacman repo for easy updates), and the iso repo which would be dedicated to the .iso for now (which boots on a USB key now by the way), and probably a .img sooner or later (DVD is so 90s :D)

Once I'm on par with ves' GA, i'll start reworking the gasetup scripts : clean, rewrite, enhance, new features.

Curious people can check https://gitlab.com/substring45/test/issues (also check closed issues) to see what I've been working on, what I plan to do. Sooner or later I'll have to rename that repo I guess :D
Title: Re: Collaborative effort for GroovyArcade
Post by: Doozer on June 03, 2019, 02:18:25 pm

Hi,

On the X startup issue you are experiencing, I can perhaps help you out to get it working. Let me know what you try to achieve.

Xorg is always started as root for driver access, then user space Xorg is used for individual user sessions. Attention must be given to gdm (or other) started on top or multi user and using dedicated instance for displayng initial graphical login screen.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on June 04, 2019, 09:11:16 am

Hi,

On the X startup issue you are experiencing, I can perhaps help you out to get it working. Let me know what you try to achieve.

Xorg is always started as root for driver access, then user space Xorg is used for individual user sessions. Attention must be given to gdm (or other) started on top or multi user and using dedicated instance for displayng initial graphical login screen.
Hey !

Well the problem is quite simple : X (through startx) will start perfect through autologin with the arcade user, but it won't start if launched from gasetup. gasetup is launched in sudo, then uses something like su -c arcade startx which fails with X being unable to switch VT.

The real thing would be to not start gasetup with sudo and wrap root commands in sudo, but this means breaking the logic in gasetup, and that's not what I want to achieve now.

There is no GDM or such, X is started with a minimalistic window manager and simply launches 1 app (usually the front end).
Title: Re: Collaborative effort for GroovyArcade
Post by: Doozer on June 05, 2019, 12:49:41 pm
Hi.

Not sure I understand the issue, I can start X for a user without issue from root account with the following command:

Code: [Select]
su - arcade startx

If you have a VM drive you can share I can work on the issue and provide better guidance.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on June 05, 2019, 01:22:00 pm
The real command is su arcade -c startx -- vt7. I've attached the xorg log
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on June 05, 2019, 03:38:33 pm
AT LAST I've found : was missing the /etc/X11/Xwrapper.config file ! It's not added by default in arch
Title: Re: Collaborative effort for GroovyArcade
Post by: ves on June 05, 2019, 04:34:29 pm
Good job!!
I want to be able to help as soon as possible.
You dont install vbox video driver.

Test to configure etc/X11/Xwrapper.config

"needs_root_rights = yes"
 
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on June 05, 2019, 05:58:13 pm
Good job!!
I want to be able to help as soon as possible.
You dont install vbox video driver.

Test to configure etc/X11/Xwrapper.config

"needs_root_rights = yes"

oh glad you join the fun :) The more the merrier
The vbox video driver is because i test 99.9% on Virtual Box, also sometimes QEMU, it's so much easier than burning the ISO on a key, swapping room, and test ;)

Time to give some news then :
- released today a new iso + arch packages for GA at https://github.com/substring/test/releases/tag/2019-06 (https://github.com/substring/test/releases/tag/2019-06). It's still pretty much alpha, but things are slowly getting in shape
- EDID boot has been added, need to fix a few things here and there, some part will involve gasetup which I don't want to mess around with for now
- gotta fix some samba permissions
- GM recognizes the coin key, but for God knows which reason, coins are almost never inserted
- I'm kind of embarassed with the default frontend : the config files are not for mainline advancemame's advancemenu, and my last try with advancemenuplus still requires some work. Have added other FE, most of them need a proper configuration (when they work).

Those are the main steps before reaching beta stage. I should also update the dev wiki, there were a few improvements here and there that are worth explaining.

Still have a few big ideas in mind (like a wrapper that can configure any FE, some fun with EDID, rewriting the iso process, write an img rather than a iso ... So many ideas, so little free time). And, sooner or later, i'll have to setup a definitive pacman repo for GA, the github release thing was more of a proof of concept, it can't stand daily updates once I'll set this up. Will need 1 or 2 servers to build GA and host the GA pacman repo. But that's in a distant future !

Summer is coming as well as holidays, will probably have a break during that time ;)

As usual, curious people can check https://gitlab.com/substring45/test (issues, merge requests, wiki and CI, I never commit straight to master)
Title: Re: Collaborative effort for GroovyArcade
Post by: keilmillerjr on June 16, 2019, 05:05:56 pm
Thank you for the iso. Will test soon. Interesting coun issue with groovymame.
Title: Re: Collaborative effort for GroovyArcade
Post by: keilmillerjr on July 05, 2019, 02:07:17 pm
Thank you substring for the update on the iso. It now works in virtual box.

Some help for others to download on mac. Linux should be the same to download. Windows, you would have to download curl. I then used archiver app for mac to unpack. The default app (archive utility) on newer os10 subversions should work.
Code: [Select]
curl -r 0-199999999 -L -o groovyarcade_2019-07.iso.xz.part1 https://github.com/substring/test/releases/download/2019-07/groovyarcade_2019-07.iso.xz
curl -r 200000000-399999999 -L -o groovyarcade_2019-07.iso.xz.part2 https://github.com/substring/test/releases/download/2019-07/groovyarcade_2019-07.iso.xz
curl -r 400000000-599999999 -L -o groovyarcade_2019-07.iso.xz.part3 https://github.com/substring/test/releases/download/2019-07/groovyarcade_2019-07.iso.xz
curl -r 600000000-799999999 -L -o groovyarcade_2019-07.iso.xz.part4 https://github.com/substring/test/releases/download/2019-07/groovyarcade_2019-07.iso.xz
curl -r 800000000-999999999 -L -o groovyarcade_2019-07.iso.xz.part5 https://github.com/substring/test/releases/download/2019-07/groovyarcade_2019-07.iso.xz
curl -r 1000000000-1199999999 -L -o groovyarcade_2019-07.iso.xz.part6 https://github.com/substring/test/releases/download/2019-07/groovyarcade_2019-07.iso.xz
curl -r 1200000000-1399999999 -L -o groovyarcade_2019-07.iso.xz.part7 https://github.com/substring/test/releases/download/2019-07/groovyarcade_2019-07.iso.xz
curl -r 1400000000-1599999999 -L -o groovyarcade_2019-07.iso.xz.part8 https://github.com/substring/test/releases/download/2019-07/groovyarcade_2019-07.iso.xz

cat groovyarcade_2019-07.iso.xz.part? > groovyarcade_2019-07.iso.xz

I was able to boot from iso within virtual box. Boot menu has new options. There is no option for just plain LCD. I picked DVI-1 15khz and it worked. I plan on using this with my mvs using a k7000 and a separate machine with an lcd (for a friend, I dont do that taboo). Not sure what would be the proper thing to do for the latter case.

Thank you substring. Keep the updates going!
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on July 06, 2019, 12:26:03 pm
Thank you for testing !

There is a lcd setting that you can choose at boot, it's aoubd the 9th position i think, you must scroll down :)

Still much work to do on it, but first, i need to split the repo in 2 : one for building packages and deploying them (need to find a solution to host them). I'd like to have a testing/unstable repo + a stable repo. The other result of the split would be to solely build the iso. And i need to totally rewrite that part.

Won't spend much time on it during july though, need a well deserved holidays break ^^
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on July 13, 2019, 07:17:35 am
So, little news before holidays break !

The way I made the whole process was too monolithic. Building packages was tied to building the iso, so there was no way to build arch packages on their own. Things are solved now and available at http://https://github.com/substring/packages/releases (https://github.com/substring/packages/releases)

You'll notice a stable and a testing release. Testing is built everyday, to match as closely as possible any updates that would happen on packages that I've included. This means for example that a kernel update would be available within 24h after the official update on Arch linux side (if no patching is implied). The idea is to let that part live on its own as much as possible. Well sometimes I may need to patch here and there, but at least, it's as much "rolling release" as possible with the few server resources I have at disposal.

The next step will be to rewrite the iso building part. As for now it's just remastering the Arch linux iso, but I'm cyrrently rewriting that part to use the archiso utility. Things are going fine so far, I hope to have a working iso by the end of August.

Then, the biggest part will come : improve gasetup ! I have quite a few ideas, I'll give some news here anyway.

And finally : documentation !!! Most of the interesting ideas are summed up in http://forum.arcadecontrols.com/index.php/topic,160440.0.html so i'll setup a repo and let others easily contribute, this must be a community effort.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on August 17, 2019, 04:49:49 am
Time for some news !

So, been working on it lately, things are in good shape for the September release:
- split packages building and iso building in 2 different repos, so 2 different CI
- I'm almost done with CI stuff and so
- UEFI boot works with the ISO, but it's definitely useless : it bypassses the boot menu, so no video configuration. This just sucks so stick to legacy BIOS boot method
- need to spend again some time with EDID at boot, it's not working as it should yet
- fixes here and there, like applying the good mame.dat file at every groovymame upgrade. This makes advancemenu+ terribly slow to load, i'm thinking about switching to attract mode for good
- add a small web server that helps user to set volumes in alsa (the audio part). This is just a pain to be done in console, abd absolutely not user friendly

At this point, I will now focus on 2 things:
- user experience through gasetup. I'm working on adding a easygashgui backend so the very same menu would work the very same way in console or desktop environment. Less effort to maintain all that, easier configuration
- have the boot menu work in 15kHz straight away. This won't be easy, it's meant to run at 61kHz no matter what, but the code looks flexible enough to allow some patching. This part will be pretty "fun" to code/patch/test/add to GA

Also need to write some basc dics for users and contributers ...

Now the important links :
- https://gitlab.com/groovyarcade for all the dev stuff
- https://github.com/substring/packages/releases for arch linux packages
- https://github.com/substring/os/releases for OS releases. Don't bother with anything else than GroovyArcade 2019.XX releases, others are made for testing, labels sometimes get messed up

Feedback is welcome
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on November 02, 2019, 01:50:58 pm
Time to give some news hehehe

I'm still actively working on my "fork". Been focusing on EDID stuff and see how to make things as much "plug'n'play" as possible. Have an interesting result to share : I can boot GroovyArcade without any specific kernel setting (no forced resolution, which means linux 15kHz patches are useless in that case), without any Xorg configuration, and I do get 15kHz on my setup ! There is a trick of course : I'm using a EDID dongle that has a switchres-generated EDID inside. This EDID has a good old 640x480i custom resolution inside. The kernel reads it and applies the modeline without a problem. So does Xorg ! I may post a video if people ask. The only downside of it : only works with ATI/AMD cards. I could get it working with NVidia but it requires a kernel patch. I sadly had some teearing that I never had when using ATI. Intel i915 is probably not going to make it.

So, appart from usual maintenance when Arch Linux changes things here and there, or manual package bumps required, I am now focusing on making GA as configurationless as possibe. I plan to add a web UI to set up volume (quite useful when you're allergic to linux console tools), got much work to do on gasetup to split modules (system, video, network etc ...), change the bootloader handling or khow kernel parameters are processed etc ... I also want to "modernize" things, and run some code checking tools on gasetup. Devs call that "lint". This will mean that I will have to correct really many small mistakes here and there, give more consistency on bash syntax etc ...

One last thing : every day, the testing repo is rebuilt. Most of times, kernel changes are automatically built. Can't be the same for GroovyMAME as I must wait for the official release of the groovy patch + suppression patch. Most tools do rebuild fine when they are bumped and I hardly need to put my hands in it. Anf from time to time, I update the stable branch with the testing one. That's a manual step, can't launch packages in the wild just because they built fine  :laugh:
Title: Re: Collaborative effort for GroovyArcade
Post by: keilmillerjr on November 02, 2019, 04:47:27 pm
Im excited for the progress.
Title: Re: Collaborative effort for GroovyArcade
Post by: b4nd1t0 on November 04, 2019, 07:03:56 am
Great work!!! :cheers:
Time to give some news hehehe

I'm still actively working on my "fork". Been focusing on EDID stuff and see how to make things as much "plug'n'play" as possible. Have an interesting result to share : I can boot GroovyArcade without any specific kernel setting (no forced resolution, which means linux 15kHz patches are useless in that case), without any Xorg configuration, and I do get 15kHz on my setup ! There is a trick of course : I'm using a EDID dongle that has a switchres-generated EDID inside. This EDID has a good old 640x480i custom resolution inside. The kernel reads it and applies the modeline without a problem. So does Xorg ! I may post a video if people ask. The only downside of it : only works with ATI/AMD cards. I could get it working with NVidia but it requires a kernel patch. I sadly had some teearing that I never had when using ATI. Intel i915 is probably not going to make it.

So, appart from usual maintenance when Arch Linux changes things here and there, or manual package bumps required, I am now focusing on making GA as configurationless as possibe. I plan to add a web UI to set up volume (quite useful when you're allergic to linux console tools), got much work to do on gasetup to split modules (system, video, network etc ...), change the bootloader handling or khow kernel parameters are processed etc ... I also want to "modernize" things, and run some code checking tools on gasetup. Devs call that "lint". This will mean that I will have to correct really many small mistakes here and there, give more consistency on bash syntax etc ...

One last thing : every day, the testing repo is rebuilt. Most of times, kernel changes are automatically built. Can't be the same for GroovyMAME as I must wait for the official release of the groovy patch + suppression patch. Most tools do rebuild fine when they are bumped and I hardly need to put my hands in it. Anf from time to time, I update the stable branch with the testing one. That's a manual step, can't launch packages in the wild just because they built fine  :laugh:
im testing your iso on an LCD and works great, now i've compiled the last 215 of groovy with nonag, tonight i think i can try on the cab with the arcade monitor and the ati R5-230, what should i expect, the correct resolutions will be generated or it is still not complete?
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on November 04, 2019, 04:51:11 pm
Well happy tester :) I'm very happy you decided to give a go to this version :)

For GM 0.215, it's already available in the testing repo https://github.com/substring/packages/releases/tag/testing Just uncomment the lines in /etc/pacman.d/groovy-ux-repo.conf, then you can manually update to it pacman -Sy groovymame. Or you can manually download it and then run pacman -U groovymame-0.215-1-x86_64.pkg.tar.xz in the download folder.

For arcade monitor + r250, we'll face a small issue : using gasetup will force the radeon driver, which will fail with your GPU that requires amdgpu. But fear not ! If you're ready to get your hands down in the motor, you can make it almost configuration-less, and it should be working amazingly great :
- EDID is the way to go, so you should edit /boot/syslinux/syslinux.cfg, remove everything that is vga= video= (well, video= is a different story, depends if your monitor is detected or not byt the GFX card) and append drm.edid_firmware=edid/arcade_15.bin which uses the Arcade 15kHz preset from switchres. If you feel unsure, you can test this EDID by booting with the ISO, and select the very first entry in the boot menu ! If it boots, then you're safe !
- you'd need to manually add monitor      arcade_15 (if it's indeed arcade 15 you're using) to mame.ini

In the case your go the old traditionnal GroovyArcade way :
- make the usual configuration in gasetup
- before launching the frontend, edit /etc/X11/xorg.conf and change the radeon driver to amdgpu. I guess it should work fine after.

One last thing : if you use AdvanceMENU rather than Attract, you will complain about slow front end start. Which is normal : it parses the mame 0.215 .xml file which is more than 200MB, so it takes a little time ;)

Going the EDID way is just awesome, because you don't even need a xorg.conf ! X will detect the monitor EDID, and use the preferred resolution from it.

Sorry for the trouble, booting on EDID is not yet ready in gasetup ...

Don't hesitate to ask questions, tell about bugs, give feedback, good or bad critics, I'll gladly answer :)
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on November 04, 2019, 05:01:42 pm
Forgot to say : I'll release a new iso this week, as soon as testing packages are confirmed working fine.

Anyay, I'd appreciate you test booting with EDID your arcade monitor. For reference, here is the 1st page of the boot screen, if you're in the dark.

One more question : which connectors does your GFX card have ? Is the VGA a real genuine or it's over DP ? You can get some intereting info is you run ls -l /sys/class/drm
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on November 06, 2019, 02:37:39 am
Great job Substring!

One question: will you release an actual, ready to burn iso?
Title: Re: Collaborative effort for GroovyArcade
Post by: b4nd1t0 on November 06, 2019, 03:15:29 am
Ok, i did just a few tests, the iso works great, I couldn't boot using the edid or i have a black screen, the only way to get everything started is by selecting DVI-1 15Khz, i found only one " problem "with attractmode, i see it out of sync but iI may have to adjust the vertical sync, in fact i started World Rally and everything works fine with the correct resolution switch.
I think i'll add more roms to test the switch of other resolutions. The only thing that could create problems for those who are less expert is the total lack of links in lxde if you wanted to make some changes manually for some configuration, however feasible if you know the commands.
I forgot, I used an HD 4350.
So it's ok for me, great job!  :applaud:
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on November 06, 2019, 03:24:31 am
Great job Substring!

One question: will you release an actual, ready to burn iso?

Of course I'm not letting anyone use my fork, no iso given away  :lol

All releases are at https://github.com/substring/os/releases
Looks like I'm not properly setting "latest release", but prefer the YYYY-DD releases, others are testing branches. I'll release 2019-11 this week, when I find time and make sure kernel 5.3.8 works.

And for people who just want to give it a try but have no DVD : the ISO can be burnt on a USB pen. In both cases, boot in legacy BIOS, not UEFI (still much work to do to have a syslinux boot menu in UEFI, which is definitely not my priority).

For IT curious people : I'm mainly using Gitlab, and use their integrated CI/CD to create arch linux packages and the Groovy isos. Releases are automatically pushed to github.I use github as a mirror, and people are more familiar with github I think.
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on November 06, 2019, 03:32:02 am
Thanks Substring, forgive me, I'm so used to the bare ftp directory style  :D

Consider adding that link to the first post in this thread.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on November 06, 2019, 03:34:17 am
Ok, i did just a few tests, the iso works great, I couldn't boot using the edid or i have a black screen, the only way to get everything started is by selecting DVI-1 15Khz, i found only one " problem "with attractmode, i see it out of sync but iI may have to adjust the vertical sync, in fact i started World Rally and everything works fine with the correct resolution switch.
Thank you very much for your testing, it's very valuable :notworthy: Have you tested the default EDID at boot menu ? If you manually edited the syslinux.cfg file, then try adding video=DVI-I:e to force the output to enabled. Using EDID or not, you must get the splash screen.
For attract, I'm surprised, I should compare timings between arcade_15 and the 640x480i set in EDID.
Quote
The only thing that could create problems for those who are less expert is the total lack of links in lxde if you wanted to make some changes manually for some configuration, however feasible if you know the commands.
I forgot, I used an HD 4350.
So it's ok for me, great job!  :applaud:
For the LXDE thing, noticed it too, haven't tried to solve that yet, but indeed I should take a look at it. Eventually try a sudo chmod -R arcade:arcade /home/arcade. I must admit I'm a keyboard guy, I hardly go into a window manager.
By the way, what's your arcade monitor ? Could you give me a short description of your GFX card -> monitor chain ? like are you using a j-pac ? or any other kind of device ? I'd like to understand why Linux didn't find your monitor.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on November 06, 2019, 03:44:47 am
Consider adding that link to the first post in this thread.
Done :)
Title: Re: Collaborative effort for GroovyArcade
Post by: b4nd1t0 on November 06, 2019, 04:25:05 am
Have you tested the default EDID at boot menu ? If you manually edited the syslinux.cfg file, then try adding video=DVI-I:e to force the output to enabled. Using EDID or not, you must get the splash screen.
For attract, I'm surprised, I should compare timings between arcade_15 and the 640x480i set in EDID.

For the LXDE thing, noticed it too, haven't tried to solve that yet, but indeed I should take a look at it. Eventually try a sudo chmod -R arcade:arcade /home/arcade. I must admit I'm a keyboard guy, I hardly go into a window manager.
By the way, what's your arcade monitor ? Could you give me a short description of your GFX card -> monitor chain ? like are you using a j-pac ? or any other kind of device ? I'd like to understand why Linux didn't find your monitor.
the, gfx card to monitor is a simple vga connector to jamma (RGB+V and H sync) and jamma to monitor, nothing special, my video card is flashed with Atom-15, and the electronic is an Hantarex Polo28.
I think, to use edid i need to apply some resistances to the connector, i have read about this some years a go but never made it, if it works, is ok for me  :D
I've tried the default EDID at boot menu, but i have black screen and no, i don't have edited the syslinux.cfg, you mean the one in \boot\syslinux\ ?
The problem in attract is strange, i have my usual hdd with groovy and it work fine, menu and games, with your iso only attract is out of sync
Title: Re: Collaborative effort for GroovyArcade
Post by: Doozer on November 06, 2019, 04:32:25 am
Going the EDID way is just awesome, because you don't even need a xorg.conf ! X will detect the monitor EDID, and use the preferred resolution from it.

Xorg configuration might get a little tweak with the compositor layer being not used. This COULD lead to 1 frame lag gain (someone with high speed camera or lag tester must confirm this, some windows manager like openbox do not use composition). Page flipping and shadowing options might also give some boost when vblank is properly synced (internal buffer reduction to 1 page, drawing must be synced to vblank like GM does).

Code: [Select]
Section "Extensions"
   Option  "Composite" "Disable"
EndSection

The X layer over Mir has recently received massive updates and some reports claim that X over Mir has reached the same latency as standalone X. To be investigated ....
Title: Re: Collaborative effort for GroovyArcade
Post by: Doozer on November 06, 2019, 04:39:32 am

@substring, please consider adding "mitigations=off" to the kernel parameters, it will give a little non-negligible boost by not mitigating CPU vulnerabilities (spectre and other). I do not think that some has sensitive or confidential data to protect on their cabinet.

Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on November 06, 2019, 05:18:35 am
Going the EDID way is just awesome, because you don't even need a xorg.conf ! X will detect the monitor EDID, and use the preferred resolution from it.

Xorg configuration might get a little tweak with the compositor layer being not used. This COULD lead to 1 frame lag gain (someone with high speed camera or lag tester must confirm this, some windows manager like openbox do not use composition). Page flipping and shadowing options might also give some boost when vblank is properly synced (internal buffer reduction to 1 page, drawing must be synced to vblank like GM does).

Code: [Select]
Section "Extensions"
   Option  "Composite" "Disable"
EndSection

The X layer over Mir has recently received massive updates and some reports claim that X over Mir has reached the same latency as standalone X. To be investigated ....

Already added (https://gitlab.com/groovyarcade/os/blob/master/overlay/groovyarcade/usr/share/X11/xorg.conf.d/10-no-composiiton.conf)  ;) Although i made a typo in the filename (which doesn't prevent X from loading the file). And Xorg.log reports fine that composition is disabled


@substring, please consider adding "mitigations=off" to the kernel parameters, it will give a little non-negligible boost by not mitigating CPU vulnerabilities (spectre and other). I do not think that some has sensitive or confidential data to protect on their cabinet.
We share the same mind, I thought about adding this. Just wanted to refactor the syslinux.cfg file ... but sadly, syslinux globals just don't work the way I'd expect. So will have to add it to each entry ...

BTW, I sent you a PM for a kernel patch for Nvidia cards, please read and reply :) I tried the same for i915, but this isn't enough to get 640x480i working with EDID. I'm not sure it works with patched kernel resolutions, will try some day.
Title: Re: Collaborative effort for GroovyArcade
Post by: Doozer on November 06, 2019, 06:13:27 am
BTW, I sent you a PM for a kernel patch for Nvidia cards, please read and reply :) I tried the same for i915, but this isn't enough to get 640x480i working with EDID. I'm not sure it works with patched kernel resolutions, will try some day.

I replied to it from the email. I assume my answer did not reach you.

To sum-up, I have an Intel and Nvidia patch sets but I am looking at making this more agnostic to the card drivers and just touching the drm helper or pruning function. Such patch must be tested against several chips and setup references to ensure that no collateral effects could arise from such modifications.

Stock kernel shows different behaviors with respect to EDID and the last kernel drm refactoring brought a lot to unify and normalize the calls. Nevertheless, ATI EDI do not check low dot clock the same way Nouveau does inside their respective driver branch.

Again, totally avoiding kernel patching might not be possible. E.g. without patching the ATI vblank interrupt, using any interlaced resolution under GM will be cap to 50% game speed.

It might be necessary to have a staging version which would have under development features. Personally, I do not own enough different configurations to confirm good working conditions in relation to non ATI hardware. Even for the ATI portion I am mostly using the 5000 generation chipset. I am also looking forward to getting in touch with the AMDGPU to see if newer generation can bring some good setup (i.e. Ryzen)

Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on November 06, 2019, 07:56:09 am
the, gfx card to monitor is a simple vga connector to jamma (RGB+V and H sync) and jamma to monitor, nothing special, my video card is flashed with Atom-15, and the electronic is an Hantarex Polo28.
I think, to use edid i need to apply some resistances to the connector, i have read about this some years a go but never made it, if it works, is ok for me  :D
I've tried the default EDID at boot menu, but i have black screen and no, i don't have edited the syslinux.cfg, you mean the one in \boot\syslinux\ ?
The problem in attract is strange, i have my usual hdd with groovy and it work fine, menu and games, with your iso only attract is out of sync

OK, reading your setup, your Polo 28 doesn't have an input impedance that allows the GFX card to detect if a monitor is connected. That's why the resistors trick could do the job. It has a small downsize though : birghtness is (a bit) lower. Just for info, Here is the EDID VGA dongle (https://www.amazon.fr/gp/product/B07BDLB6D3/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8&psc=1) I bought and flashed with a switchres EDID. It does have the required resistors. They are 150 Ohms each. Here (https://www.geeks3d.com/20091230/vga-hack-how-to-make-a-vga-dummy-plug/) is a little article that describes the resistors hack.

Anyway, by tweaking your /boot/syslinux/syslinux.cfg file, you could use EDID by forcing the DVI-I to be enabled, as described earlier.

Now for the Attract problem, I need a little more details :
- do you have a nice splash boot screen with the progress bar before reaching attract ? (this means the resolution chosen works fine, X is not yet loaded)
- which monitor have you chosen in gasetup ? (to have a clue of X resolution)
- If you're OK with SSH and your cab has network, can you remotely login to your cab and give me the output of DISPLAY=:0 xrandr ? (to know which resolution was set)
- You mentionned LXDE : was it displaying fine even if menus are empty ? (to make sure that it's only an attract issue, LXDE and attract share the same X config)
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on November 07, 2019, 10:20:32 am
So, 2019.11 is released, catch it here (https://github.com/substring/os/releases/tag/2019.11). The changelog on this release page is now automatically built using the git commits that happened since the previous release. Most notable changes are groovymame 0.215 and attract mode 2.6.0.

The "no menu in LXDE" should be fixed, though I haven't had time to test it in the release. The cause has been identified : building the ISO changes many files' owner to root, including those that should belong to the arcade user. issing a sudo chown -R arcade:arcade /home/arcade fixes the problem.

It might be necessary to have a staging version which would have under development features. Personally, I do not own enough different configurations to confirm good working conditions in relation to non ATI hardware. Even for the ATI portion I am mostly using the 5000 generation chipset. I am also looking forward to getting in touch with the AMDGPU to see if newer generation can bring some good setup (i.e. Ryzen)

Technically speaking, with how I've setup the CI on my fork, it's pretty easy to have a new Arch repo where we can (manually) build the kernel and make it available easily. Just need to add a new repo to the pacman.conf which must be before the testing and stable repos to avoid conflicts on packages. My linux-15kHz package is just the arch PKGBUILD version which is patched with sed (in case a .patch file would not work) and a .patch file for some more static parts of the PKGBUILD. This way it's pretty robust to upstream minor changes (like linux version bump). The only thing is that this kernel must be manually triggered in the CI (as of now, this can be changed). I can give you rights to full around with this. Only downside as of today : if the CI triggers the build on my PC (which is not always on), you're a lucky guy. If not, it will be built on a atom Z8350, so expect 10h of build (can't even use ccache because of some damn timestamps in headers)
Title: Re: Collaborative effort for GroovyArcade
Post by: b4nd1t0 on November 07, 2019, 12:04:48 pm
i've downloaded the last release and i can test it,
... try adding video=DVI-I:e to force the output to enabled. Using EDID or not, you must get the splash screen.
where should I put video=DVI-I:e? I didn't understand, sorry.
This is the content of syslinux.cfg
Code: [Select]
UI vesamenu.c32
PROMPT 0
TIMEOUT 3000


MENU BACKGROUND splash.png
menu clear
menu margin 0
menu rows 10
menu vshift 9
menu tabmsgrow 15
menu cmdlinerow 16
menu helpmsgrow 16
menu helpmsgendrow 29


# Refer to http://syslinux.zytor.com/wiki/index.php/Doc/menu

menu color border * #00000000 #00000000 none
menu color title 0 #ffffffff #00000000 none
MENU COLOR sel   7;37;40 #e0ffffff #20ffffff all
menu color unsel 0 #ffffffff #00000000 none
menu color help 0 #ffffffff #00000000 none
menu color timeout 0 #ffffffff #00000000 none
menu color timeout_msg 0 #ffffffff #00000000 none
menu color tabmsg * #ffffffff #00000000 none
menu color cmdmark 0 #ffffffff #00000000 none
menu color cmdline 0 #ffffffff #00000000 none
#---------------------

LABEL [EDID 15khz]
MENU LABEL [EDID 15khz]
LINUX /groovyarcade/boot/x86_64/vmlinuz-linux-15khz quiet rd.udev.log-priority=3 splash drm.edid_firmware=edid/arcade_15.bin
INITRD /groovyarcade/boot/x86_64/initramfs-linux-15khz.img
APPEND archisobasedir=groovyarcade archisolabel=GA_2019_11 root=/dev/disk/by-label/GA_2019.11

LABEL [EDID 25khz]
MENU LABEL [EDID 25khz]
LINUX /groovyarcade/boot/x86_64/vmlinuz-linux-15khz quiet rd.udev.log-priority=3 splash drm.edid_firmware=edid/arcade_25.bin
INITRD /groovyarcade/boot/x86_64/initramfs-linux-15khz.img
APPEND archisobasedir=groovyarcade archisolabel=GA_2019_11 root=/dev/disk/by-label/GA_2019.11

LABEL [EDID 31khz]
MENU LABEL [EDID 31khz]
LINUX /groovyarcade/boot/x86_64/vmlinuz-linux-15khz quiet rd.udev.log-priority=3 splash drm.edid_firmware=edid/arcade_31.bin
INITRD /groovyarcade/boot/x86_64/initramfs-linux-15khz.img
APPEND archisobasedir=groovyarcade archisolabel=GA_2019_11 root=/dev/disk/by-label/GA_2019.11

LABEL [DVI-1 15khz]
MENU LABEL [DVI-1 15khz]
LINUX /groovyarcade/boot/x86_64/vmlinuz-linux-15khz quiet rd.udev.log-priority=3 splash vga=0x311 video=DVI-I-1:640x480ec
INITRD /groovyarcade/boot/x86_64/initramfs-linux-15khz.img
APPEND archisobasedir=groovyarcade archisolabel=GA_2019_11

LABEL [VGA-1 15khz]
MENU LABEL [VGA-1 15khz]
LINUX /groovyarcade/boot/x86_64/vmlinuz-linux-15khz quiet rd.udev.log-priority=3 splash vga=0x311 video=VGA-1:640x480ec
INITRD /groovyarcade/boot/x86_64/initramfs-linux-15khz.img
APPEND archisobasedir=groovyarcade archisolabel=GA_2019_11

LABEL [DVI-2 15khz]
MENU LABEL [DVI-2 15khz]
LINUX /groovyarcade/boot/x86_64/vmlinuz-linux-15khz quiet rd.udev.log-priority=3 splash vga=0x311 video=DVI-I-2:640x480ec
INITRD /groovyarcade/boot/x86_64/initramfs-linux-15khz.img
APPEND archisobasedir=groovyarcade archisolabel=GA_2019_11

LABEL [VGA-2 15khz]
MENU LABEL [VGA-2 15khz]
LINUX /groovyarcade/boot/x86_64/vmlinuz-linux-15khz quiet rd.udev.log-priority=3 splash vga=0x311 video=VGA-2:640x480ec
INITRD /groovyarcade/boot/x86_64/initramfs-linux-15khz.img
APPEND archisobasedir=groovyarcade archisolabel=GA_2019_11

LABEL [NTSC DVI-1 15khz]
MENU LABEL [NTSC DVI-1 15khz]
LINUX /groovyarcade/boot/x86_64/vmlinuz-linux-15khz quiet rd.udev.log-priority=3 splash vga=0x311 video=DVI-I-1:720x480ec
INITRD /groovyarcade/boot/x86_64/initramfs-linux-15khz.img
APPEND archisobasedir=groovyarcade archisolabel=GA_2019_11

LABEL [NTSC VGA-1 15khz]
MENU LABEL [NTSC VGA-1 15khz]
LINUX /groovyarcade/boot/x86_64/vmlinuz-linux-15khz quiet rd.udev.log-priority=3 splash vga=0x311 video=VGA-1:720x480ec
INITRD /groovyarcade/boot/x86_64/initramfs-linux-15khz.img
APPEND archisobasedir=groovyarcade archisolabel=GA_2019_11

LABEL [PAL DVI-1 15khz]
MENU LABEL [PAL DVI-1 15khz]
LINUX /groovyarcade/boot/x86_64/vmlinuz-linux-15khz quiet rd.udev.log-priority=3 splash vga=0x311 video=DVI-I-1:768x576ec
INITRD /groovyarcade/boot/x86_64/initramfs-linux-15khz.img
APPEND archisobasedir=groovyarcade archisolabel=GA_2019_11

LABEL [PAL VGA-1 15khz]
MENU LABEL [PAL VGA-1 15khz]
LINUX /groovyarcade/boot/x86_64/vmlinuz-linux-15khz quiet rd.udev.log-priority=3 splash vga=0x311 video=VGA-1:768x576ec
INITRD /groovyarcade/boot/x86_64/initramfs-linux-15khz.img
APPEND archisobasedir=groovyarcade archisolabel=GA_2019_11

LABEL [SVGA/LCD Monitor]
MENU LABEL [SVGA/LCD Monitor]
LINUX /groovyarcade/boot/x86_64/vmlinuz-linux-15khz quiet rd.udev.log-priority=3 splash vga=0x317 video=
INITRD /groovyarcade/boot/x86_64/initramfs-linux-15khz.img
APPEND archisobasedir=groovyarcade archisolabel=GA_2019_11

LABEL [DVI-1 15khz pci=nomsi (Use for buggy motherboards)]
MENU LABEL [DVI-1 15khz pci=nomsi (Use for buggy motherboards)]
LINUX /groovyarcade/boot/x86_64/vmlinuz-linux-15khz pci=nomsi quiet rd.udev.log-priority=3 splash vga=0x311 video=DVI-I-1:640x480ec
INITRD /groovyarcade/boot/x86_64/initramfs-linux-15khz.img
APPEND archisobasedir=groovyarcade archisolabel=GA_2019_11

LABEL [VGA-1 15khz pci=nomsi (Use for buggy motherboards)]
MENU LABEL [VGA-1 15khz pci=nomsi (Use for buggy motherboards)]
LINUX /groovyarcade/boot/x86_64/vmlinuz-linux-15khz pci=nomsi quiet rd.udev.log-priority=3 splash vga=0x311 video=VGA-1:640x480ec
INITRD /groovyarcade/boot/x86_64/initramfs-linux-15khz.img
APPEND archisobasedir=groovyarcade archisolabel=GA_2019_11

LABEL [DVI-1 15khz Disable VGA intel i915 (Use for buggy motherboards)]
MENU LABEL [DVI-1 15khz Disable VGA intel i915 (Use for buggy motherboards)]
LINUX /groovyarcade/boot/x86_64/vmlinuz-linux-15khz i915.modeset=0 quiet rd.udev.log-priority=3 splash vga=0x311 video=DVI-I-1:640x480ec
INITRD /groovyarcade/boot/x86_64/initramfs-linux-15khz.img
APPEND archisobasedir=groovyarcade archisolabel=GA_2019_11

LABEL [VGA-1 15khz Disable VGA intel i915 (Use for buggy motherboards)]
MENU LABEL [VGA-1 15khz Disable VGA intel i915 (Use for buggy motherboards)]
LINUX /groovyarcade/boot/x86_64/vmlinuz-linux-15khz i915.modeset=0 quiet rd.udev.log-priority=3 splash vga=0x311 video=VGA-1:640x480ec
INITRD /groovyarcade/boot/x86_64/initramfs-linux-15khz.img
APPEND archisobasedir=groovyarcade archisolabel=GA_2019_11

LABEL [DVI-1 25khz]
MENU LABEL [DVI-1 25khz]
LINUX /groovyarcade/boot/x86_64/vmlinuz-linux-15khz quiet rd.udev.log-priority=3 splash vga=0x311 video=DVI-I-1:512x384ez
INITRD /groovyarcade/boot/x86_64/initramfs-linux-15khz.img
APPEND archisobasedir=groovyarcade archisolabel=GA_2019_11

LABEL [VGA-1 25khz]
MENU LABEL [VGA-1 25khz]
LINUX /groovyarcade/boot/x86_64/vmlinuz-linux-15khz quiet rd.udev.log-priority=3 splash vga=0x311 video=VGA-1:512x384ez
INITRD /groovyarcade/boot/x86_64/initramfs-linux-15khz.img
APPEND archisobasedir=groovyarcade archisolabel=GA_2019_11

LABEL [DVI-2 25khz]
MENU LABEL [DVI-2 25khz]
LINUX /groovyarcade/boot/x86_64/vmlinuz-linux-15khz quiet rd.udev.log-priority=3 splash vga=0x311 video=DVI-I-2:512x384ez
INITRD /groovyarcade/boot/x86_64/initramfs-linux-15khz.img
APPEND archisobasedir=groovyarcade archisolabel=GA_2019_11

LABEL [VGA-2 25khz]
MENU LABEL [VGA-2 25khz]
LINUX /groovyarcade/boot/x86_64/vmlinuz-linux-15khz quiet rd.udev.log-priority=3 splash vga=0x311 video=VGA-2:512x384ez
INITRD /groovyarcade/boot/x86_64/initramfs-linux-15khz.img
APPEND archisobasedir=groovyarcade archisolabel=GA_2019_11

LABEL [DVI-1 31khz]
MENU LABEL [DVI-1 31khz]
LINUX /groovyarcade/boot/x86_64/vmlinuz-linux-15khz quiet rd.udev.log-priority=3 splash vga=0x311 video=DVI-I-1:640x480ey
INITRD /groovyarcade/boot/x86_64/initramfs-linux-15khz.img
APPEND archisobasedir=groovyarcade archisolabel=GA_2019_11

LABEL [VGA-1 31khz]
MENU LABEL [VGA-1 31khz]
LINUX /groovyarcade/boot/x86_64/vmlinuz-linux-15khz quiet rd.udev.log-priority=3 splash vga=0x311 video=VGA-1:640x480ey
INITRD /groovyarcade/boot/x86_64/initramfs-linux-15khz.img
APPEND archisobasedir=groovyarcade archisolabel=GA_2019_11

LABEL [DVI-2 31khz]
MENU LABEL [DVI-2 31khz]
LINUX /groovyarcade/boot/x86_64/vmlinuz-linux-15khz quiet rd.udev.log-priority=3 splash vga=0x311 video=DVI-I-2:640x480ey
INITRD /groovyarcade/boot/x86_64/initramfs-linux-15khz.img
APPEND archisobasedir=groovyarcade archisolabel=GA_2019_11

LABEL [VGA-2 31khz]
MENU LABEL [VGA-2 31khz]
LINUX /groovyarcade/boot/x86_64/vmlinuz-linux-15khz quiet rd.udev.log-priority=3 splash vga=0x311 video=VGA-2:640x480ey
INITRD /groovyarcade/boot/x86_64/initramfs-linux-15khz.img
APPEND archisobasedir=groovyarcade archisolabel=GA_2019_11

LABEL Boot from first Hard Drive
MENU LABEL Continue to Boot from ^First HD
KERNEL chain.c32
APPEND hd1

LABEL [VGA-1 15khz Log]
MENU LABEL [VGA-1 15khz Log]
LINUX /groovyarcade/boot/x86_64/vmlinuz-linux-15khz vga=0x311 video=VGA-1:640x480ec
INITRD /groovyarcade/boot/x86_64/initramfs-linux-15khz.img
APPEND archisobasedir=groovyarcade archisolabel=GA_2019_11

LABEL [SVGA/LCD Monitor Log]
MENU LABEL [SVGA/LCD Monitor Log]
LINUX /groovyarcade/boot/x86_64/vmlinuz-linux-15khz vga=0x317 video=
INITRD /groovyarcade/boot/x86_64/initramfs-linux-15khz.img
APPEND archisobasedir=groovyarcade archisolabel=GA_2019_11
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on November 07, 2019, 04:07:27 pm
I'm very sorry I should have explained it before ! All apologies  :notworthy:

So, this is the file from the DVD which you can't edit, but the one once installed on a hard drive is a lot shorter. Here it is, in my case, installed in virtual box with LCD screen setting :
Code: [Select]
default arch
timeout 0
prompt 0
#UI vesamenu.c32
menu title Groovy Arcade Linux
menu background GA.png
label arch
menu label GroovyArcade
linux ../vmlinuz-linux-15khz
append root=/dev/disk/by-label/GA rw quiet splash rd.udev.log-priority=3
initrd ../initramfs-linux-15khz.img

The interesting line here is append root=/dev/disk/by-label/GA rw quiet splash rd.udev.log-priority=3. This line lists the kernel boot parameters. The file on your hard drive should already be configured the way you wish. If you want to enable edid, the best is to :

First, you should make a backup copy, in case : sudo cp /boot/syslinux/syslinux.cfg /boot/syslinux/syslinux.cfg.ok. You can restore your backup with sudo cp /boot/syslinux/syslinux.cfg.ok /boot/syslinux/syslinux.cfg. If EDID doesn't work, you'll get a black screen, but you can still use SSH (use putty in windows) to connect to it and solve problems.

In case, I'm on keilmillerjr's discord.
Title: Re: Collaborative effort for GroovyArcade
Post by: keilmillerjr on November 07, 2019, 04:49:10 pm
ArcadeMVS discord (chat server): https://discord.gg/tJmWCgf
Title: Re: Collaborative effort for GroovyArcade
Post by: b4nd1t0 on November 13, 2019, 05:27:58 am
sorry for the delay but I have very little time for the tests, however I can confirm that attract is out of sync, I tried to adjust the monitor but without result. The PC is not online and I have no way to access it otherwise, any advice? Obviously my other installation on another hdd is working and attract is at 640x480
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on November 13, 2019, 05:46:31 am
I need more info : which monitor have you chosen in gasetup ? I guess timings just don't fit your monitor, games haves most chances to use different timings.
Title: Re: Collaborative effort for GroovyArcade
Post by: b4nd1t0 on November 13, 2019, 05:55:20 am
the monitor is generic-15, the arcade it doesn't work for me
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on November 13, 2019, 06:23:35 am
and which monitor do you actually own ?

Edit : do you mean the same monitor works in the original Groovy Mame ?
Title: Re: Collaborative effort for GroovyArcade
Post by: b4nd1t0 on November 13, 2019, 06:37:06 am
do you mean the same monitor works in the original Groovy Mame ?
yes, exactly
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on November 13, 2019, 08:14:32 am
ain't the polo28 a tri-sync ?

anyway, I'll dig in the timings of generic_15 and find what could have changed between ves and me (apart from ATI drivers)
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on November 27, 2019, 05:18:13 pm
So, time for monthly news before kernel 5.4.1 and groovymame 0.216 are integrated.

Except unuseful things to mention, I've been working pretty hard on a script to "auto-detect" screen configuration. So this made me reduce the number of entries in the syslinux boot menu, as well as remove EDID menu options. So we're just left with 6 entries: 15kHz, 25 kHz, 31kHz, LCD, NTSC and PAL. Don't just shout yet with "Hey DVI-1/VGA-1/etc is now missing, my screen will never be detected!", and read till the end ;)

This script I told about will first turn on all video outputs (yeah mister sceptical, even the ones that are missing from the boot menu!), make sure you do see the very first message, then test outputs one by one in a clever way. If it detects an EDID, we know for sure a screen is connected and working. If you have a EDID dongle with a switchres edid in it, you shall be blessed! Every time a screen is turned on, a message is displayed for 5 seconds waiting for the user to confirm he sees the message. If no key was pressed, it means no message could be displayed, so no screen is connected. At the end, once all outputs have been tested, time to take decision on which screen seems the best, and what should be configured inside the OS to have it working. Icing on the cake: depending on your GFX card, the script will eventually recommend using EDID emulation.

The sad thing is that it won't hit the 2019.12 release, there is still much to be done. But once this is over, I can work on improving user experience (things like configuring wifi which is a total pain for now, add desktop UI where possible so people don't have to browse through some menus). And I'm still working on a desktop version of the gasetu script. Working rather fine I'd say, but having a tool that works the same on console or desktop implies some rewrites here and there, which takes time, as usual ...

If some people would like to test that auto-detect script, I can provide a link and instructions on how to use it. I did my best to test all possible cases, but I'm pretty sure I missed some.
Title: Re: Collaborative effort for GroovyArcade
Post by: Doozer on November 28, 2019, 04:50:22 am

Well done Substring, thank you for your time and efforts. Much appreciated :)
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on November 28, 2019, 04:57:00 am
Hi Substring,

These days I've been experimenting with Ves around the EDID emulation option too, I still need to check whether forcing the EDID on all outputs (which works great on detectable monitors) actually works or not on non-detectable monitors. I'd like to test your auto-detect script too, I'm really interested.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on November 28, 2019, 06:26:03 am
Regarding EDID emulation, here is my feedback:
- works fine with traditionnal radeon driver
- got no card to test amdgpu driver
- i915 seems not to work
- nouveau seems not to work unless patched (to remove the low dotclock limit warning). I asked Doozer his opinion on a patch I sent him, I'll let him tell his opinion about it. Even though I could get EDID emulation working, I had (much) tearing that I never had with radeon.

To be continued ...

I'll give the testing process once I get enuogh time to write a little tuto ! The script can even suggest kernel command line parameters to add ;)

On a side note, it's sad we're splitting our efforts each on our side regarding EDID emulation. I can tell you it works, that you don't even need to configure X after (at least on a TV that was seen by Linux, I don't have the case where the monitor is not detected by the OS). EDID emulation can be forced system wide, not just specific to a connector. We should really share our experiments and results in a more efficient way and not waste time this way ... Remember the name of the topic : "collaborative effort" ;)
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on November 28, 2019, 07:06:16 am
On a side note, it's sad we're splitting our efforts each on our side regarding EDID emulation.

I'm doing what's in my hand to avoid this splitting of efforts, trust me.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on November 28, 2019, 07:05:04 pm
So, a short doc on how ot use the autoconfigure. A few disclaimers or things to do first:
- it's still beta, don't try it on your main rig
- backup mame.ini, switchres.conf, ga.conf as the script will probably set the monitor
- also backup your xorg.conf for the same reason
- during my tests, I faced a weird issue : forcing HDMI-A-1 to on just turned off VGA-1 on one of my PCs. Why, no idea.
- the script may report KO if it detects it can use EDID but can't find the .bin files in the required places (i.e. /usr/lib/firmware/edid and inside initramfs). If, at least, it turned on your screen and you could confirm seeing the dialog, most of the process is done. I'm still interested in the output
- the script only cares about the best possible monitor for MAME. If you run this on a dual monitor, it will try to guess the setup for the arcade monitor. In other words : LCD panels are the last thing the script cares about, and having 2 arcade monitors plugged is not yet recommended, the script will care only about one of them.

Pre-requisites:
- you need espeak-ng sudo pacman -Sy espeak-ng
- you need easybashgui (which is included in my fork of GA). You may download it with wget https://github.com/substring/packages/releases/download/stable/easybashgui-11.0.1-1-any.pkg.tar.xz and then sudo pacman -U easybashgui-11.0.1-1-any.pkg.tar.xz
- not sure, but could be useful to download and install my patched switchres wget https://github.com/substring/packages/releases/download/stable/switchres-1.53.1-2-x86_64.pkg.tar.xz and then sudo pacman -U switchres-1.53.1-2-x86_64.pkg.tar.xz

The script is very talkative with some 90s quality text-to-speech (despite a tts program in just a few MB is pretty awesome and it's quite audible), this makes the process look even more retro  :lol

I'd be pretty intereted in the final output. It should look like (depending on your rig and your answers, of course) :
Code: [Select]
DP-1: x
DVI-I-1: x
HDMI-A-1: l

drm.edid_firmware=edid/generic_15.bin video=VGA-1:e

Short explanation of the final output :
- connectors are listed with the results of diagnostics. Explanation is available here (https://gitlab.com/groovyarcade/tools/gatools/blob/master/video/video.sh#L505-510). A s may precede x e r o or l if you made a switchres EDID dongle with my version of switchres (witch sets the monitor name instead of the Serial number). Quite useful hehehe
- the script makes a proposition of what you should append to your kernel command line. In the example above (which is a copy/pase of 2 different cases, so the kernel recommandation doesn't correspond to the connectors tests), the script detected a LCD panel on HDMI-A-1. The last line is the result of detecting an arcade monitor which output must be forced at boot, and applying EDID of the generic_15 monitor preset.

Feedback greatly appreciated. There is a groovy.log that should contain much info on what happened, and the result of decisions taken. I'm also interested in that file.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on December 01, 2019, 04:58:04 pm
So, 2019.12 is out, nothing special about the release. Got mame 0.216, linux 5.3.13 (I wanted to wait for the 5.4.1 release but no ETA, and I've got some plans ...).

Now will start the big work to integrate screen auto detection (with the help of user). Luckily, I'll be able to provide beta isos that anyone can burn on a pendrive.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on December 04, 2019, 01:52:44 pm
Guyz, I'm glad to announce the beta for screen autoconfiguration is open ! Grab your iso at https://github.com/substring/os/releases/tag/16-integrate-gatools-screen-detection-at-boot ! Burn it to a USK key start as BIOS mode, not UEFI

Things to know :
- the boot menu is now quite shortened. Fo those of you who have no 31kHz boot, here is what you miss and need to chooe the right option
- I'm mostly interested in the confirmation sc---reen + your setup, I've attached an example. There is a misleading text that would happen if you have no AMD GPU + LCD screen : it will report EDID emulation is not supported and resolution must be forced. This text is misleading, but technically no resolution will be forced
- If you accept, a few options will be set, including mame and switchres, but part of the magic is done when loading the kernel. So settings will be applied if you install GroovyArcade (which you can do of course, should work, but this is not the object of this beta). Still, you should be able to test the frontend and launch a ROM shipped with the iso.
- If you are on a full 15kHz only rig, fear not! The script will talk to you and will turn on your screen, so you'll have to confirm you do see something. That way, the script knows how to setup the OS.

Finally, here is a little video of the ISO booting in Virtual Box. Well, nothing magic, but that's a good example.

https://youtu.be/evxBP5EIxME

Edit : well sound is totally out of sync of the video, it was supposed to speak after informing about screens turning on and off  :lol Virtual Box did bad recording the video, bummer
Title: Re: Collaborative effort for GroovyArcade
Post by: Banane on December 31, 2019, 11:29:21 am
Ive been off for  two months because unfortunately I had other stuff do  ... whoa , A LOT happened.

Thank you so much Substring for pushing this forward   ;D :notworthy:.

Damn, today is new year, hopefully tomorrow I'll download your latest ISO and test the script  :cheers:


Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on December 31, 2019, 02:54:25 pm
Glad to see you back :)

The script is still a little buggy but should work overall.

Got some other great news coming soon (I hope)  :D
Title: Re: Collaborative effort for GroovyArcade
Post by: Banane on January 01, 2020, 10:37:32 am
Happy new year  :cheers: . Really looking forward to your updates  ;D
What "channel" is the best for giving testing feedback ?  This thread here, your github-repo or the 'new' gitlab repo ?  :)

Test-Setup (see attached picture)

Test1 / Script Autoconfiguration: : Just used a SVGA-CRT on VGA of PCIe-R230, selected SVGA/LCD. Result see attached picture. (Connector war detected, video card doesnt support EDID, no monitor detected). The same with the HD6450 with DVI2VGA-Adapter.
Is there a shortcut I can use too see the output to tty1 'behind' the graphical menu ? Its not tty7 (Edited: Oh well, I can parse /var/log/groovy.log ::) )
 

Test2 / GA-Installer on NVMe SSD: :  Autoformat /dev/nvme0n1 doesnt work. Partitions are created but I guess the root partition (e.g /dev/ nvme0n1p3) is not formatted correctly. When I repeat the setup, use the auto applied partition layout from the last step and install to root partition (/dev/ nvme0n1p3) manually, arch is installating correctly and I can boot from HDD.  What script is called here? In what logfile can I see the output (or again, is there a shortcut to see the output on tty1? ). The Installer says its copying the files to /dev/nvme0n13 instead of  /dev/nvme0n1p3 - so I guess its just a parsing error of the script  :applaud: )
-------------------------------------------------------------
(Edited: I'm no developer, but I got this far:

grep -rnw '/' -e 'Copying Groovy'
nano /opt/gasetup/core/procedures/interactive
--> worker_auto_partition()
--> line: mkfs.ext4 -F -O ^64bit -q ${DEVICE}${ROOTNUM}


which leads to /dev/nvme0n13

How about ?:
ROOTPART=$(fdisk -l ${DEVICE} | awk '{print $1}' | grep ${ROOTNUM})
mkfs.ext4 -F -O ^64bit -q ${ROOTPART}

which would lead to /dev/nvme0n1p3
-------------------------------------------------------------






Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on January 02, 2020, 03:49:33 am
Hey Banane thank you for your feedback ! And Happy new year ;)

For test 1, there is a minor bug that has been solved since : the final result should have said "Connector VGA-1 was detected". I've fixed this bug a little while ago, haven't pushed yet the changes. What I'd like you to confirm is :
- have you heard the voice speaking ? You may not have turned your speakers on haha
- has your monitor been turned off, turned on and you could confirm it was your arcade monitor ?
For the "video card doesn't support EDID", it means you're not using a AMD/RADEON card, but this seems false. I think there was also a bug regarding this that I haven't pushed yet ... Now a small question : do you know if your GPU uses the amdgpu or radeon driver ? Don't rely on the lsmod result, I load nouveau i915 amdgpu and radeon from initramfs to get the splash logo. Have a look at dmesg.
Next thing I'd like you to test is starting the frontend right after the monitor setup.
Just for a general information : SVGA/LCD means a monitor tha has EDID (or DDC) capabilities ;)

Regarding test 2, I've already filled an issue on my side regarding the non detection ov NVMe SSD. I wouldn't mind you try the command listed there (https://gitlab.com/groovyarcade/gasetup/issues/4) and give me the result. Regarding the partition name, it's just a display, so it's a minor bug ;) But your fix looks right. I haven't done much in gasetup for a while
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on January 02, 2020, 04:32:22 am
Happy News Year everyone :)

Been working hard on linux kernel patches during December, leaving GroovyArcade a little aside ... I'll go in a few technical details for people who are interested into that.

So, while testing this beta release, I was looking for a way to dynamically force an EDID. After some kernel code reading, a few commands here and there : bingo! This IS possible. But this wasn't possible everytime and got me quite confused, until I narrowed down to the precise case where forcing EDID doesn't exist : using the 15k modelines patched into kernel. It took me a few weeks of debugging + kernel compilation + patching to find the root cause of that. And the root is indeed the 15k patch. Despite it provides some 15kHz resolution, it has 2 major drawbacks : it blocked the EDID on-the-fly loading + the 15k modeline wasn't "advertised" by DRM. Although most people wouldn't care about EDID reloading, the second problem mislead everyone to believe that setting EDID at boot time was the way to go (see http://forum.arcadecontrols.com/index.php?topic=140215.0).

A little patching here and there in the kernel code confirmed that the 15k patch was a little too brutal and had to fit better how DRM processes resolutions. So I've rewritten the 15k patch and results are great : I have plug'n'play X when I use a switchres resolution at boot time! That's a major leap forward for 2 reasons. The 1st reason is that this new patch is much better integrated into the kernel, cleverly handles situations where the kernel fallbacks to old GTF resolutions when none was found. The second reason is that it respects modelines validation (at DRM level, and at driver level), so in the end, DRM advertises the 640x480i (or any other resolution the 15k patch handles) at sysfs level, making it available to any software including X. Xorg gets the 640x480i resolution from the kernel and natively uses it, no need to go anymore the EDID way!

But in Linux we're facing another major problem. Although Radeon GPUs (please note I'm not saynig AMD GPUs, we have no clue on them yet) have always been considered the best for 15k display (and this is true), Intel or NVIDIA are a much different story. 15k resolutions are rejected by the drivers. It's hard to tell if it's because Intel or NVIDIA decided 31.5kHz would be the minimum horizontal frequency, or if it's to avoid some hardware problems (like a DAC that can't handle such low resolutions, or refuses interlace), but I'm also digging on how to make them work. Looks like I could get this done for NVIDIA, gotta test in Intel too. Once again, when this seems like it can be tested, I'll publish a beta ISO :)

So, not much happened on GroovyArcade itself, but there are some major breakthroughs that GA will soon benefit hopefully :)
Title: Re: Collaborative effort for GroovyArcade
Post by: Banane on January 03, 2020, 07:34:16 am
For test 1, there is a minor bug that has been solved since : the final result should have said "Connector VGA-1 was detected". I've fixed this bug a little while ago, haven't pushed yet the changes. What I'd like you to confirm is :
- have you heard the voice speaking ? You may not have turned your speakers on haha
- has your monitor been turned off, turned on and you could confirm it was your arcade monitor ?
For the "video card doesn't support EDID", it means you're not using a AMD/RADEON card, but this seems false. I think there was also a bug regarding this that I haven't pushed yet ... Now a small question : do you know if your GPU uses the amdgpu or radeon driver ? Don't rely on the lsmod result, I load nouveau i915 amdgpu and radeon from initramfs to get the splash logo. Have a look at dmesg.
Next thing I'd like you to test is starting the frontend right after the monitor setup.

Ive tested it on a regular LCD monitor now, youre right, its just the output which is not correct. The monitor itself is detected, the config is created. I will just wait for your update/pushes  :)
Quote
Regarding test 2, I've already filled an issue on my side regarding the non detection ov NVMe SSD.
I answered the issue in gitlab :). Thanks

Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on January 03, 2020, 09:16:03 am
Wow, thank you for all that positive feedback. My kernel hacking is almost over, so I'll spend more time on groovyarcade now.

Thanks to your report on gitlab, I know that I can safely detect all hard drives. For the worker_auto_partition(), I'll see how to solve that part. Your code has a little problem with devices like mmcblk3 or nvme0n3 if such ever exist. And I wouldn't use fdisk for that, blkid is a much better tool in that case ;) Can you try as root (or just sudo blkid):
Code: [Select]
DEVICE=/dev/sda
ROOTNUM=3
blkid | cut -d ":" -f1 | grep -oE "${DEVICE}[[:alnum:]]?${ROOTNUM}$"

Looks fine on my side.

Title: Re: Collaborative effort for GroovyArcade
Post by: Banane on January 03, 2020, 10:01:26 am
I totally agree, blkid is better, not doing the same mistake again  ;)

Code: [Select]
[arcade@GroovyArcade ~]$ DEVICE=/dev/nvme0n1
[arcade@GroovyArcade ~]$ ROOTNUM=3
[arcade@GroovyArcade ~]$ blkid | cut -d ":" -f1 | grep -oE "${DEVICE}[[:alnum:]]?${ROOTNUM}$"

/dev/nvme0n1p3

Even better - works  :)

And again, big thumps up for the kernel debugging you made (the big message just before)  :notworthy:

I'm fully pleased:
:applaud:

Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on January 03, 2020, 11:49:34 am
Thank you for your encouragements :) this keeps me motivated for GA :)

I'd like to say that, even if they don't say much and some people tend to believe they have other stuff to do, Calamity, Doozer and KeilMillerJr also work as much as they can on their side. It's not becuse they are not as "talkative" as me here that they lost their interest for the project ;) Things are still going, ideas here and there, a few of them are even quite ambitious, but I think we can make it  8)
Title: Re: Collaborative effort for GroovyArcade
Post by: keilmillerjr on January 03, 2020, 07:55:49 pm
Im always interested, and try to follow the conversation every day. Honestly, much of what you and calamity talk about is over my head. Hence me just reading. Hope your new years was good! I took a 1 week break from attract.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on January 05, 2020, 03:10:51 pm
Hey!

New version released at https://github.com/substring/os/releases/tag/16-integrate-gatools-screen-detection-at-boot.

Major changes:
- should detect NVMe drives
- should properly handle partition numbers for whichever disk device
- screen configuration should be fixed

Remaining known bugs:
- if a drive has a space name, it will be split over 2 lines. Just select the one starting with /dev/...
- even if GA was configured with user help, the installer still requires to set the monitor type.
Both of them should be fixed soon (I hope)
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on January 06, 2020, 05:51:10 am
Remaining known bugs:
- if a drive has a space name, it will be split over 2 lines. Just select the one starting with /dev/...
- even if GA was configured with user help, the installer still requires to set the monitor type.
Both of them should be fixed soon (I hope)
fixed and available at the same link above
Title: Re: Collaborative effort for GroovyArcade
Post by: Banane on January 06, 2020, 02:39:38 pm
Thank you very much, the output of the autodetection script is fine now.  Monitor goes off and on and I can start the frontend right afterwards  :)

The NVMe drive issue I commented here : https://gitlab.com/groovyarcade/gasetup/issues/4
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on January 06, 2020, 05:53:32 pm
Issue amended with some comments, but luckily QEMU can emulate NVMe drives, so I could test on my side and it should be fixed by now. Anyway, I've updated the iso, if you can confirm the fix :)
Title: Re: Collaborative effort for GroovyArcade
Post by: Banane on January 08, 2020, 02:33:56 pm
I replied to the issues again. format and creation of filesystem now works fine (stepping forward  ;) ), but there might be another parsing error afterwards (pacstrap, mkinitcpio, grub  or so).

Both boot and root partition stay empty.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on January 08, 2020, 03:53:25 pm
My bad, should be fixed now
Title: Re: Collaborative effort for GroovyArcade
Post by: Banane on January 09, 2020, 01:33:26 pm
Perfect - it is :D. Thank you !
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on January 09, 2020, 03:00:12 pm
Nice ! If you ever have time to test with arcade monitors and different GFX cards, I'd appreciate ;)
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on January 09, 2020, 05:05:31 pm
New monthly release at https://github.com/substring/os/releases/tag/2020.01 !

All updates are listed on the release, but here are the main features :
- linux 5.4.8
- fixed installation on NVMe drives (thank you Banane for your help)
- interactive monitor setup at boot. You can't beat this with Windows hahaha
Title: Re: Collaborative effort for GroovyArcade
Post by: arfink on February 07, 2020, 07:11:41 am
I'm interested in trying this out, is it still limited to Radeon cards? Also how is sync being handled? Can I expect a csync signal on the VGA hsync line?
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on February 07, 2020, 07:42:03 am
I'm interested in trying this out, is it still limited to Radeon cards? Also how is sync being handled? Can I expect a csync signal on the VGA hsync line?

Hey there !

Radeon cards: yes and no. They are the best so far because they allow low dotclocks, whereas Intel and Nvidia refuse any modeline which pixel clock is lower than 25MHz, which makes it hard for a genuine 15kHz without some dirty tricks. Intel are probably the worst case as it's hard to have a full control of the hardware chain between a iGPU and the VGA connector. Resultts can pretty much vary. Although I've made a patch to circumvent the 25MHz limit, this can have side effects on some specific hardware, so it's pretty risky as of now, and not shipped.

Sync is handled like normal VGA sync, so you have both HSync and VSync on  their respective line.

One more word to make the difference with windows setups : no need to configre modelines one by one. Just configure your monitor type, groovymame will always choose the closest resolution to th original hardware. Look at the video I made earlier concerning autoconfiguration, you'll see it's pretty easy for a basic setup. Configure your screen, then you're ready to play free roms shipped with GA :)
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on February 07, 2020, 08:25:21 am
Well, the situation with Intel and Nvidia on Linux is probably not as dark as painted by Substring, specially with Nvidia. Intel Iris has been reported to work with low dotclocks just fine. The 25 MHz limitation is not a problem as long as you use super resolutions in GM, which is the way to go nowadays anyway.

The problem, from the user point of view, is more in the fact that GA was designed assuming that you had no low dotclock limitations, so it will boot on 640x480 by default, and forcing it to boot on a double width mode such as 1280x480 in order to bypass dotclock limitations requires some non-trivial user input, as it is now.

So I'd say GA supports all GPUs, it's only that with Radeons things are more plug and play.
Title: Re: Collaborative effort for GroovyArcade
Post by: arfink on February 07, 2020, 02:27:35 pm
Maybe I'm an idiot, but what's a good way to get csync from a GA setup? Even with the old ga I couldn't do it and it was frustrating because that's what my monitor wants.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on February 07, 2020, 04:15:52 pm
I'm.not so much into signals, but how isnit different from combining hsync and vsync ?
Title: Re: Collaborative effort for GroovyArcade
Post by: arfink on February 07, 2020, 04:53:45 pm
Everything I've read online is people getting all armchair-expert and saying it's not as simple as just bridging the H and V sync lines, but haven't been about to figure out why or how these people expect it to be done properly.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on February 07, 2020, 05:48:04 pm
well, for 10, my spanish VGA2SCART does the most basic CSYNC and it does work.

@Calamity of course nvidia and intel can work, but never at the original resolution, or even something hardly close. Unless fancying with super resolutions the same mess as on windows, but I don't think it's really usable the same way as on windows, are thse GPUs worth ?
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on February 07, 2020, 06:31:08 pm
Quote from: Substring
@Calamity of course nvidia and intel can work, but never at the original resolution, or even something hardly close. Unless fancying with super resolutions the same mess as on windows, but I don't think it's really usable the same way as on windows, are thse GPUs worth ?

Super resolutions work the same way on Linux, and it's anything but a mess. Intel gpus are crap and Nvidia is a horrible company but they can run GM on Linux with zero compromises. You do have compromises regarding frame buffer and desktop resolutions, which will make setup harder unless you know how to bypass the issues.

Since you can scale horizontally to meet dotclock requirements, as long as you keep the vertical resolution, you're still "pixel perfect". One might have a valid objection to using super resolutions because of fractional scaling, but in Linux you can be smarter by just setting -dotclock_min 25.0, which will automatically promote the horizontal resolution to the first multiple that meets the dotclock, and still use integer scaling. Signal-wise, the result is identical to using "native" resolutions, it's absolutely the same thing. And the advantage is that geometry is better in general since the granularity for adjusting blanking gets much finer.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on February 07, 2020, 07:22:01 pm
FEBRUARY 2020 UPDATE

A major change will hit the reopsitory:
KERNEL: this one is a big change. I've started rewriting the 15kHz patch to make it more flexible, more "kernel compliant" and respectful of resolutions handling. This opens the kernel for easier hacking later, but has a major drawback for people who have an existing rig with groovyarcade: upgrading to 5.5.x means editing /boot/syslinux/syslinux.cfg and manually edit the video=... param. Here is the rule:
  - remove c or z, replace it with S
  - you must specify if the resolution is interlace b adding an i after the resolution
  -> examples:
      video=320x240ec becomes video=320x240eS
      video=640x480ec becomes video=640x480eiS
See https://github.com/D0023R/linux_kernel_15khz#since-55

feel free to ask any question

Title: Re: Collaborative effort for GroovyArcade
Post by: Recapnation on February 08, 2020, 08:00:11 am
but in Linux you can be smarter by just setting -dotclock_min 25.0, which will automatically promote the horizontal resolution to the first multiple that meets the dotclock, and still use integer scaling. Signal-wise, the result is identical to using "native" resolutions, it's absolutely the same thing.

I don't see myself ever using LX, but really glad to read that!
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on February 08, 2020, 09:08:54 am

I don't see myself ever using LX, but really glad to read that!

Not trying to convince you, but I'm curious to know why, what you'd expect from an arcade linux distro, and what could make you consider giving a try.
Title: Re: Collaborative effort for GroovyArcade
Post by: Recapnation on February 09, 2020, 07:08:25 am
Here's just a few reasons:

(http://geedorah.com/postback/extra/misc/not_on_linux_a.png)
(http://geedorah.com/postback/extra/misc/not_on_linux_b.png)
(http://geedorah.com/postback/extra/misc/not_on_linux_c.png)


You really need a 15-kHz set-up to properly play some of the best action games for WIN (much like you need another for 31-kHz, but I'll stop there), not to mention some key emulators MAME just can't compete with at the moment and have no LX version (how's Retro Arch on LX?). So there's no point (for now, at least) in messing also with LX for anyone interested in this stuff (and I really see no reason for not being interested if you are in MAME, but maybe that's just me).
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on February 09, 2020, 07:48:17 am
Which key emulators are missing ?

Regarding linux mame that can't compete vs win mame, i'm not so sure. Sadly no one with GILT has tested input lag in linux. But although linux seemed to have always been 1 frame behind windows, i think we've found the reason.

Now, a few cons fir linux if you have a good 15k setup (which means Radeon gpu):
- takes less than 10 minutes to install, configure and play your first rom. You can even test without installing
- no need for super resolutions, all mame games are played at native resolution
- no limits on the number of 15k possible resolutions, except if they come from your hardware
- no need to boot in safe mode, tweak anything that is driver related

What one could tell me is that the linux task scheduler is not made for gaming, which can result in worse performance than windows. This has been proved. Nevermind, i can add a real time kernel to linux and test again. But please, no prejudices, just facts. Missing emulator is a fact, mame in linux sounded more like a prejudice.

I'm really not stating that linux is better than windows, i need some true facts that would lead me on how to shrink the gap
Title: Re: Collaborative effort for GroovyArcade
Post by: Recapnation on February 09, 2020, 09:13:35 am
I never said anything regarding MAME for LX vs. MAME for WIN (I even thought that it was already proven that they're equal when measuring input lag, at this point). I'm in no position to discuss about that, and honestly, my hope is to never be. But if you ask me why WIN is better than LX (in the context of "15/31-kHz gaming", what else), I have reasons for the whole day.

As for key emulators without LX version, you need the Retro Arch cores for decent FC/NES, SFC/SNES, MCD and PCE emulation. Some would say that even PS and GBA. Not sure how the LX version of RA performs on 15-kHz systems. PC-88 Mark II SR, PC-9800 series and FM Towns do require standalone emulators as of now. Sega's Model 2 and Model 3 (and Sony's ZN?) seem to also benefit from standalone emulators against MAME.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on February 09, 2020, 09:26:32 am
I never said anything regarding MAME for LX vs. MAME for WIN (I even thought that it was already proven that they're equal when measuring input lag, at this point). I'm in no position to discuss about that, and honestly, my hope is to never be. But if you ask me why WIN is better than LX (in the context of "15/31-kHz gaming", what else), I have reasons for the whole day.

As for key emulators without LX version, you need the Retro Arch cores for decent FC/NES, SFC/SNES, MCD and PCE emulation. Some would say that even PS and GBA. Not sure how the LX version of RA performs on 15-kHz systems. PC-88 Mark II SR, PC-9800 series and FM Towns do require standalone emulators as of now. Sega's Model 2 and Model 3 (and Sony's ZN?) seem to also benefit from standalone emulators against MAME.

RA works fine in Linux for 15kHz. Ben Templeman (aka alphanu) developped the 15kHz for both win and linux. It's based on super resolutions, not the xrandr lib but shell calls to the xrandr binary (last time I checked), but it does work. More on his YT channel (https://www.youtube.com/channel/UCT73WExrpXVzgeo33hOvvYw/videos).

Regarding Nintendo consoles, higan runs on Linux. Sega consoles emulation is WIP, haven't tested it tbh.

Sega Model 3: supermodel runs on linux
Sega Model 2: windows only unless you go the mame way

I was expecting some "user experience is dreadful on linux" ;) Which is true, but I'm doing my best to make things as easy as windows to be used.
Title: Re: Collaborative effort for GroovyArcade
Post by: Recapnation on February 09, 2020, 10:11:55 am
Yeah, sorry for not being of help there; I wish you luck.

Higan is not the one to pick for action games (or for a low-res display, last I checked). RA's BSNES cores with Brunnis' fixes for better lag figures.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on February 09, 2020, 10:19:19 am
Anyway, thank you for your opinion  :)
Title: Re: Collaborative effort for GroovyArcade
Post by: sterbehilfe1980 on February 10, 2020, 10:10:11 am
very cool project!  :applaud: will give the latest release this weekend a try. i got a AMD RX560 and a iiyama freesync monitor with W10 in my cab...will freesync work with groovyarcade? because once you go freesync you cant go back!  :notworthy:
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on February 10, 2020, 11:35:58 am
1st things first : no idea how freesync will behave with Linux. But AMD docs (https://www.amd.com/en/support/kb/faq/gpu-754) specify how one can reach that. The best is probably to remotely do this through SSH while the front end is running.

I'd be quite interested in the results of the various commands you're supposed to run to check and/or enable.

By the way, Calamity added a low input lag in MAME since 0.217 iirc that can be activated with -lowlatency on command line. Works best with VRR monitors.
Title: Re: Collaborative effort for GroovyArcade
Post by: sterbehilfe1980 on February 10, 2020, 12:54:49 pm
1st things first : no idea how freesync will behave with Linux. But AMD docs (https://www.amd.com/en/support/kb/faq/gpu-754) specify how one can reach that. The best is probably to remotely do this through SSH while the front end is running.

I'd be quite interested in the results of the various commands you're supposed to run to check and/or enable.

By the way, Calamity added a low input lag in MAME since 0.217 iirc that can be activated with -lowlatency on command line. Works best with VRR monitors.

thanks for the input. i researched your link and it looks like that amd is at the moment only supporting freesync with displayport. my monitor only has a HDMI port  :hissy: will try groovyarcade anyway...curious to see what you guys allready archived.
Title: Re: Collaborative effort for GroovyArcade
Post by: psakhis on February 11, 2020, 03:52:33 am
Here's just a few reasons:

(http://geedorah.com/postback/extra/misc/not_on_linux_a.png)
(http://geedorah.com/postback/extra/misc/not_on_linux_b.png)
(http://geedorah.com/postback/extra/misc/not_on_linux_c.png)


You really need a 15-kHz set-up to properly play some of the best action games for WIN (much like you need another for 31-kHz, but I'll stop there), not to mention some key emulators MAME just can't compete with at the moment and have no LX version (how's Retro Arch on LX?). So there's no point (for now, at least) in messing also with LX for anyone interested in this stuff (and I really see no reason for not being interested if you are in MAME, but maybe that's just me).

Off topic.
Can you write game title's?   :o

I purpose new topic about CRT Emudriver compatible and non emulated games at low freqs (240p imho).

Thx!
Title: Re: Collaborative effort for GroovyArcade
Post by: arfink on February 12, 2020, 04:37:22 pm
Here's just a few reasons:

You really need a 15-kHz set-up to properly play some of the best action games for WIN (much like you need another for 31-kHz, but I'll stop there), not to mention some key emulators MAME just can't compete with at the moment and have no LX version (how's Retro Arch on LX?). So there's no point (for now, at least) in messing also with LX for anyone interested in this stuff (and I really see no reason for not being interested if you are in MAME, but maybe that's just me).

Off topic.
Can you write game title's?   :o

I purpose new topic about CRT Emudriver compatible and non emulated games at low freqs (240p imho).

Thx!

Interestingly enough, most (all? I haven't tested them all) of these games shown are very easy to run on Linux using Proton or Wine with virtually no performance hit, and they should run 15khz no problem too. I'm still dragging my heels on a proper Radeon but there's absolutely no reason these shouldn't work in Linux.
Title: Re: Collaborative effort for GroovyArcade
Post by: rewind22x on February 27, 2020, 02:39:22 am
Just wanted to say thanks for this build.  I'm currently trying to get this to work in an arcade cab.

The 2020.1 build works awesomely with LCD screens.  Currently have it in my arcade1up cab, installed on an Intel cpu / AMD gpu PC, only running MAME.  I tried with the crt cab, but couldn't get it working out of the box.  2020.2, however, does show signs of progress.  I'm able to get to the frontend, everything looks good.  But when i launch a game in MAME, it just goes to black screen.  Probably a resolution error on my part.  Haven't had a lot of time lately to check my settings.  One thing that did break (at least on the three systems I've installed 2020.2 on ) is the history.dat plugin.  Can't get scores to save at the moment.  I'm not looking for a fix or anything, just thought I'd let you know, since it did work in the previous build.

Again, thanks for the images.  I hope you continue to develop this project.  I'm not a linux zealot/windows hater, but I love having a purpose built image that boots right into what I want and not have to spend time ripping out GUI's and dealing with licenses.

Another wish I have is better wifi support.  That seems to be an Arch Linux/adapter issue though.  I can get mine to work, but it won't configure with gasetup.  Need to enable it via the shell.

Cheers!
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on February 27, 2020, 03:27:15 am
Hi rewind22x,

With regards to the black screen after launching MAME, try setting "dotclock_min 25.0" in mame.ini. This will force super resolutions and probably fix the issue.

Wifi support in GA has always been a problem. Hopefully this will be addressed in future versions.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on February 27, 2020, 06:23:28 am
Hey rewind22x,

Thank you for sharing your experience with us.

Can you give more details about your rig ? That would help diagnose resolutions issue + which config you chose at boot (15/25/31/svga). 2020.1 had some bugs when applying autosetup parameters.

Regarding wifi, yeah it's a real problem for now. Forget any security stronger than WPA, the default network manager can't handle WPA2 or later. I will explore other alternatives with one main requirement : hase a nice GUI for people who like the text setup, and easily editable config files that allow me to script configuration. That's a major feature that will take much time to evaluate and test all network managers with their possible GUIs.
Title: Re: Collaborative effort for GroovyArcade
Post by: rewind22x on February 27, 2020, 11:29:36 am
ASRock B360M-HDV
Intel Core i3-9100F
16 GB DDR4 RAM
AMD Radeon HD 7570
Wells Gardner K7000 (as far as I can tell)
J-Pac
GA 2020.2

It's been a week or so since I set things up, so my memory is probaby off.  But on first boot, I selected 15khz, got into the setup.  It did the autodetect, found the display (DVI > VGA > JPAC > Monitor.  Configured the monitor to Wells Gardner K7000, horizontal, 4:3.

I tried the dotclock settings (both manually editing the mame.ini and using the option in gasetup) but no luck.  The screen goes completely black, like it loses power.  I just tap ESC until I hear the AttractMode music, then hit ESC again, press the down arrow and then Enter.  That gets me to gasetup, which activates the monitor and then I relaunch AttractMode.

I will try installing from scratch tomorrow.  The cab is at work, kind of a 'employer sponsored' pet-project.  We had a Galaga Arcade1Up cab that we gave away at the company xmas party.  It was set up in front of my office door and was pretty popular.  So I convinced my boss we needed a full size cab in the office.  We found someone selling a Marvel vs Capcom cab on craigslist and bought it.  The cab itself is kinda beat, but after some TLC, should look pretty good.  I got it working with Retro-Pie + a Rpi 3+ but wanted something more powerful and reliable.

If you guys have any other ideas, I'd be glad to try them.  I do appreciate the work being put into this project and am fully aware it's a work in progress.  I've had 2020.1 running on my arcade1up cab at home (LCD) and it's been rock solid... except for the black-screen issue.  The joysticks/buttons will not wake it up.  A keyboard press does.  So I tell my kids to just tap the Select button until it launches a game and then the screen appears and they can then decide to play or exit and pick another game.  The JPAC shows up as a keyboard, so no issues with waking on the full size cab here at the office.  Half tempted to just use an iPac2 in the arcade 1up, but at this point, I'm done putting more money into it... until I'm not. lol
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on February 27, 2020, 12:15:13 pm
This setup should just work out of the box, without even forcing horizontal or 4:3.

Check mame.ini and report the monitor parameter, it could have gone wrong, some older parts of gasetup (the text based tool to configure) may interfere with code I've added. Mame's log (it's up to you to manually start mame, check Calamity's signature) could help understanding which screen resolution was selected, and check if it fits in your screen specs.

Now regarding screen blanking ... So far I couldn't remove it. The Xorg options I tried didn't change a thing, I should dig this further.

Now thanks to your feedback, I could set some priorities on my todo ;) I'm on holidays atm, will get back into coding Sunday ;)
Title: Re: Collaborative effort for GroovyArcade
Post by: rewind22x on February 27, 2020, 04:58:32 pm
Crap, I spaced an important detail.

You are right when you said it worked out of the box.  I just checked the cab out over my lunch break.  I did the 'Force XORG' fix, which borked getting into AttractMode.  Then I went through the Monitor/Orientation/Aspect Ratio setup.  Went back into the fixes and forced the "dot_clock" fix, along withe the "screen tearing" fix. Fired up AttractMode and got it back.  On a whim, i opened a game and it showed up.  Couldn't believe it.  I then fired up another.  It had vertical sync issues, but it still appeared.  Another issue appeared though, upon game exit, AttractMode was half its horizontal width and forced to the left of the screen.  Exiting to gasetup and reopening AttractMode fixes that.  I thought about a plugin that needed to be enabled to restore AttractMode after a game is run that changes the resolution, so I opened the settings and then AttractMode froze.  And then my memory jogged. I remember having this issue with AttractMode freezing.  I did some research and fixed it by setting a progressive video resolution.  But then opening MAME games resulted in a completely black screen.  I never thought to see the link.

So anyway, I'll do a fresh install tomorrow (if i have the usual sleepy Friday at work) and keep track of what I'm seeing, as I've probably jacked things to a point where I'm not sure what's broken or whats fixed.  Thanks again for the help.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on February 28, 2020, 02:13:54 am
So your steps show a fundamental difference between the original groovyarcade and my fork : i went the xorg.conf-less way. In 2020, Xorg hardly needs a xorg.conf, it's even not recommended anymore to have one. This also means i'm missing some inputs configuration (like wiimotes), but noone complained so far ;)

Regarding your rig, you shouldn't need the dot clock fix, you gfx card can handle low pixel clocks. Just for a test : you should be able to launch any game from the bare iso once screen autosetup is done, without installing to a HDD. Just follow the autosetup and press a key when necessary, then once in gasetup, just start the first default option. It should launch AM flawlessly, and you can give a go to default roms. They should all work.

I feel more concerned about that game not restoring the default resolution once you've quitted mame. Can you give me its name ?
Title: Re: Collaborative effort for GroovyArcade
Post by: rewind22x on February 28, 2020, 11:34:37 am
OK, had some time this morning.  I read your post and booted from the USB installer.  Here's the steps I took and what I observed:

First screen is split and offset (left side aligns center then wraps around)
Choose 15khz
I press "enter' when the prompt screen appears. In the end, it reads: -Connection DVI-I-1 was selected / The arcade monitor couldn't be natively detected, the output will be forced at boot / Do you want to validate these settings?  to which I select YES.
Choose Generic 15khz monitor
Get to gasetup, launch AM
Looks good, launch a game
Black screen/loses any picture
Exiting to AM is also black screen, but i can hear audio
Exiting AM to gasetup restores picture, able to launch AM once again.
Tried multiple games (default roms), all the same result
Changed the monitor to K7000 and 15khz arcade, same result
AM will freeze within a couple of minutes

Is there anything I should be checking with regard to the monitor?
Title: Re: Collaborative effort for GroovyArcade
Post by: Banane on February 28, 2020, 06:41:35 pm
Hey Rewind22x, maybe this leads into a wrong direction, but whats the status of your J-PAC sync light  when the screen switches off ?
Out of the sudden Im having trouble with this ....could be related.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on February 29, 2020, 02:09:10 pm
OK, had some time this morning.  I read your post and booted from the USB installer.  Here's the steps I took and what I observed:

First screen is split and offset (left side aligns center then wraps around)
Choose 15khz
I press "enter' when the prompt screen appears. In the end, it reads: -Connection DVI-I-1 was selected / The arcade monitor couldn't be natively detected, the output will be forced at boot / Do you want to validate these settings?  to which I select YES.
Choose Generic 15khz monitor
Get to gasetup, launch AM
Looks good, launch a game
Black screen/loses any picture
Exiting to AM is also black screen, but i can hear audio
Exiting AM to gasetup restores picture, able to launch AM once again.
Tried multiple games (default roms), all the same result
Changed the monitor to K7000 and 15khz arcade, same result
AM will freeze within a couple of minutes

Is there anything I should be checking with regard to the monitor?

I really need to see your mame.ini, your /var/log/groovy.log, /var/log/Xorg.0.log + a mame log to see what switchres does
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on February 29, 2020, 03:27:01 pm
@rewind, also post the output of xrandr. That black screen can happen for 2 reasons:

1. You have another output active as primary and GM is sending video to that one. This is likely the case, since you're using a jpac and your analog connection goes undetected.

2. A low dotclock issue
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on March 01, 2020, 12:00:25 pm
looks like there is a bug when using RADEON/AMD cards + monitors that don't have the required load input. Will be fixed asap.
Title: Re: Collaborative effort for GroovyArcade
Post by: beernut on March 05, 2020, 11:06:59 am
A suggestion of a tool to add to your distribution:

Joymap.  Basically joy2key but way easier to use if you need to only map say button17 and 22.  No need for a super long string of blank mappings which are easy to loose track of.

https://github.com/wizlab-it/joymap
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on March 05, 2020, 04:55:15 pm
Hey thanks ! Will take a look at it :)
Title: Re: Collaborative effort for GroovyArcade
Post by: rewind22x on March 06, 2020, 12:34:13 pm
A suggestion of a tool to add to your distribution:

Joymap.  Basically joy2key but way easier to use if you need to only map say button17 and 22.  No need for a super long string of blank mappings which are easy to loose track of.

https://github.com/wizlab-it/joymap

This may also kinda solve the black-screen/power save issue.  A JPAC configuration will wake because GA thinks a keyboard is being pressed.  If this will take the "button" inputs and let you assign it to the MAME equivalent keyboard button, it may possibly allow it to wake.

Still kinda weird that there's no fix for it.  I've looked all over the web for a solution, and while there are plenty of methods, none seem to work.

I still haven't had a chance to test anything on my cab.  Been busy at the office and some sick kids at home.  Hopefully will get a chance to get some info for you guys early next week.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on March 06, 2020, 12:52:15 pm
Antimicro is already included as well a qjoypad ;)
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on March 06, 2020, 01:20:03 pm
just found for DPMS : add to ~/.xinitrc :

Code: [Select]
xset -dpms
xset s off
Title: Re: Collaborative effort for GroovyArcade
Post by: rewind22x on March 07, 2020, 12:07:15 pm
just found for DPMS : add to ~/.xinitrc :

Code: [Select]
xset -dpms
xset s off

Finally!  I swear I entered the same commands in, but i don't think it was within this file.  This worked on my LCD cab at home.  Screen still goes black (wasn't the problem, actually was desired to save the monitor) but will turn back on with a joystick movement.  Bravo!

edit:  i have two lcd setups at home. This worked on 2020.2.  I found this did not work on 2020.1.  In addition, 2020.1 was missing entries in the file, but even when i copied the file over from 2020.2 it still didn't work.  The only reason I'm still on 2020.1 on that setup (Arcade1Up cab) is due to the hi-score still working.

Looking forward to the next build Substring!
Title: Re: Collaborative effort for GroovyArcade
Post by: lettuce on March 08, 2020, 09:35:14 am
Damn this looks impressive and the way to go for anyone trying this in the year 2020?, good work Substring.

I have my 15KHz monitor connected to a J-PAC (to cut out any nasty Signals form the PC) and then going to my PC which has a HD4670 that was flashed with ATOM-15 BIOS about 5 years ago, are these custom BIOS for the GPU even needed nowadays, as didn't super wide resolutions method replace the need for that?.

Considering my setup should this just be plug and play with you ISO image, also can it be installed form a USB stick?
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on March 08, 2020, 09:43:23 am
Damn this looks impressive and the way to go for anyone trying this in the year 2020?, good work Substring.

I have my 15KHz monitor connected to a J-PAC (to cut out any nasty Signals form the PC) and then going to my PC which has a HD4670 that was flashed with ATOM-15 BIOS about 5 years ago, are these custom BIOS for the GPU even needed nowadays, as didn't super wide resolutions method replace the need for that?.

Considering my setup should this just be plug and play with you ISO image, also can it be installed form a USB stick?
First of all : expect a new release today or in the coming days.

Your setup should work just fine. I have a jpac + hd5450 (but bios is not patched), works pretty fine. Anyway, you can just flash the iso to a USB stick and try it without installing it.
Title: Re: Collaborative effort for GroovyArcade
Post by: lettuce on March 08, 2020, 09:48:16 am
First of all : expect a new release today or in the coming days.

Your setup should work just fine. I have a jpac + hd5450 (but bios is not patched), works pretty fine. Anyway, you can just flash the iso to a USB stick and try it without installing it.

So using the USB method it doesn't install it as an OS om the PC???

So having a flashed BIOS on a GPU is no longer need for use with a 15KHz monitor?
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on March 08, 2020, 10:59:47 am
Flashing the video BIOS is a safety for monitors so that at boot time it's 15kHz, not 31. That's all. Your JPAC also has such a protection. Once the linux kernel loads, it handles resolutions.

The USB method is just to test, changes are not permanent.
Title: Re: Collaborative effort for GroovyArcade
Post by: arfink on March 10, 2020, 04:24:42 am
I'm interested in trying your build, I just received my Radeon HD card today. However, my monitor will require composite sync, is that supported here? I couldn't get composite sync to work with old GA builds using Nvidia, just wanted to know it's ok with Radeon.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on March 10, 2020, 05:01:26 am
I'm interested in trying your build, I just received my Radeon HD card today. However, my monitor will require composite sync, is that supported here? I couldn't get composite sync to work with old GA builds using Nvidia, just wanted to know it's ok with Radeon.

Technically speaking, c-sync is possibe, but not out of the box. This also seems to depend on GFX cards, kernel drivers show that only radeon/amd cards seem to support it. All in all: if your GFX card supports it, linux can use it. But there is a major BUT: nothing  in GA is made yet to handle csync. That means none of the kernel fixed resolutions for 15k, nor any script.

Now 2 points:
- can't you output csync by yourself ? This is monitor-dependant. Sometimes just mixing hsync and vsync will work, some time electronics must be involved.
- you're not the first one asking for csync. Although it implies quite some changes, that's something I may consider (but will take months before I spend time on it).

Also remember that it means that switchres must be able to handle csync, which is not (yet ?) the case on Linux. So I think that, for now, the best option is to go the hardware hack path.
Title: Re: Collaborative effort for GroovyArcade
Post by: arfink on March 10, 2020, 06:10:40 am
I'll try just tying the wires together to start, if that doesn't work I have another monitor that's HV sync I will try instead.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on March 11, 2020, 09:32:02 am
2020.03 is out :) Don't upgrade systemd, 245 has issues with the splash boot
Title: Re: Collaborative effort for GroovyArcade
Post by: arfink on March 11, 2020, 04:54:41 pm
2020.03 is out :) Don't upgrade systemd, 245 has issues with the splash boot

I'll give it a try once it's done downloading. I'm rigging up my VGA to RGB cable for my IIgs monitor right now as a first test subject.
Title: Re: Collaborative effort for GroovyArcade
Post by: lettuce on March 14, 2020, 10:02:46 am
2020.03 is out :) Don't upgrade systemd, 245 has issues with the splash boot

So if im want to put this on a USB drive (as i dont have a cd drive on my arcade PC) how do i go about going that with the iso file on your github page?
Title: Re: Collaborative effort for GroovyArcade
Post by: arfink on March 14, 2020, 02:15:23 pm
Are you going to try to burn the USB from Windows or from Linux? If in Windows, please use Rufus.

https://rufus.ie/

If you are doing it in Linux, that gets a little more complicated and you'll want to see if your distro has a USB writing tool built in. Many do.
Title: Re: Collaborative effort for GroovyArcade
Post by: arfink on March 14, 2020, 02:25:08 pm
Well, I seem to be having some weird issues getting this to work. When I boot off the USB, the automatic detection actually works about 50% of the time. If it somehow auto-selects a 240p mode my monitor (an Apple IIgs RGB color monitor) will display without issues, however sometimes it will seemingly pick a 480i mode, which the IIgs monitor doesn't know how to handle, so the image is too tall but is otherwise clear and synced. Speaking of sync, this monitor wants composite sync, but is happy with H and V sync just tied together, no issues there.

Once booted successfully I can set things up in gasetup to force 320x240 mode for X, etc, and it plays nicely. However, once I install to the HDD it doesn't remember my settings and I'm not able to get it to display. It picks the wrong output port (DVI-1, instead of VGA-1) and uses the wrong sync, even when I tell it otherwise. Not sure what I'm doing wrong here.

Also, I'm fairly sure the old Phenom II I'm running doesn't have enough muscle for this version of Mame, as World Rally drops to 50% speed most of the time. :P
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on March 14, 2020, 02:42:03 pm
2020.03 is out :) Don't upgrade systemd, 245 has issues with the splash boot

So if im want to put this on a USB drive (as i dont have a cd drive on my arcade PC) how do i go about going that with the iso file on your github page?
You can burn it on a USB pen, no problem, that's what I do.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on March 14, 2020, 02:46:33 pm
Well, I seem to be having some weird issues getting this to work. When I boot off the USB, the automatic detection actually works about 50% of the time. If it somehow auto-selects a 240p mode my monitor (an Apple IIgs RGB color monitor) will display without issues, however sometimes it will seemingly pick a 480i mode, which the IIgs monitor doesn't know how to handle, so the image is too tall but is otherwise clear and synced. Speaking of sync, this monitor wants composite sync, but is happy with H and V sync just tied together, no issues there.

Once booted successfully I can set things up in gasetup to force 320x240 mode for X, etc, and it plays nicely. However, once I install to the HDD it doesn't remember my settings and I'm not able to get it to display. It picks the wrong output port (DVI-1, instead of VGA-1) and uses the wrong sync, even when I tell it otherwise. Not sure what I'm doing wrong here.

Also, I'm fairly sure the old Phenom II I'm running doesn't have enough muscle for this version of Mame, as World Rally drops to 50% speed most of the time. :P
So far, you should never boot in 240p unless you flashed an ATI card with ATOM15. When Linux takes the hand, it's 480i all the way unless you manually edit kernel parameters after installation.

You shouldn't force anything for X, GA is meant to be xorg.conf-less now. If you need a resolution, you need a video=<connector>:320x240S or video=<connector>:320x240Se if your monitor wasn't detected by the GX card. I'll remove any setting that touches X conf because it can mess up your configuration.

Please enclose the result of dmesg for your HDD install.
Title: Re: Collaborative effort for GroovyArcade
Post by: arfink on March 14, 2020, 03:15:14 pm
Well, I seem to be having some weird issues getting this to work. When I boot off the USB, the automatic detection actually works about 50% of the time. If it somehow auto-selects a 240p mode my monitor (an Apple IIgs RGB color monitor) will display without issues, however sometimes it will seemingly pick a 480i mode, which the IIgs monitor doesn't know how to handle, so the image is too tall but is otherwise clear and synced. Speaking of sync, this monitor wants composite sync, but is happy with H and V sync just tied together, no issues there.

Once booted successfully I can set things up in gasetup to force 320x240 mode for X, etc, and it plays nicely. However, once I install to the HDD it doesn't remember my settings and I'm not able to get it to display. It picks the wrong output port (DVI-1, instead of VGA-1) and uses the wrong sync, even when I tell it otherwise. Not sure what I'm doing wrong here.

Also, I'm fairly sure the old Phenom II I'm running doesn't have enough muscle for this version of Mame, as World Rally drops to 50% speed most of the time. :P
So far, you should never boot in 240p unless you flashed an ATI card with ATOM15. When Linux takes the hand, it's 480i all the way unless you manually edit kernel parameters after installation.

You shouldn't force anything for X, GA is meant to be xorg.conf-less now. If you need a resolution, you need a video=<connector>:320x240S or video=<connector>:320x240Se if your monitor wasn't detected by the GX card. I'll remove any setting that touches X conf because it can mess up your configuration.

Please enclose the result of dmesg for your HDD install.

Hrmmm, well you're right, apparently gasetup can mess with x conf. I was careful to reinstall without touching any of the gasetup options that mess with x conf and now it works off the HDD. Still running slow, but as I said before, I suspect that's more to do with my hardware setup than anything else. I'll continue to play with it and try to take some pics, the IIgs monitor is a nice 12" tube and seems to work great with GA so far.
Title: Re: Collaborative effort for GroovyArcade
Post by: arfink on March 14, 2020, 04:23:26 pm
What is the preferred way to load ROMs and edit the file system on this?
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on March 14, 2020, 05:32:22 pm
What is the preferred way to load ROMs and edit the file system on this?
I'm not sure I understand.

I prefer doing all through SSH, but there are network shares to drop roms
Title: Re: Collaborative effort for GroovyArcade
Post by: arfink on March 14, 2020, 06:54:15 pm
What is the preferred way to load ROMs and edit the file system on this?
I'm not sure I understand.

I prefer doing all through SSH, but there are network shares to drop roms

Durr. OK, figured that out. With that figured out, the only other things I'm currently chasing are:

1- AttractMode doesn't seem to be very stable with an interlaced resolution, from what I'm reading online, and in fact I find it hangs up often. Is it possible to run it in 240p?
2- The newest and hottest GroovyMAME is obviously too much for my puny Phenom II, so I'll be shopping for a better box soon. Oh well. :P

Other than that, I can't really complain. It's slick. I'm sure I'll find more stuff to bump my head against as I use it more. Meanwhile, it's time for some Neo Turf Masters.
Title: Re: Collaborative effort for GroovyArcade
Post by: arfink on March 14, 2020, 11:09:07 pm
Here's some indication of how nicely this is working out for me, and thanks again to all the contributors for their hard work. You made this project incredibly easy for a newb like me.

(https://i.redd.it/v3i6985i1rm41.jpg)
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on March 15, 2020, 02:29:51 am
I'm glad you've been through that easily :)

AM can run at 240p. The kernel even has a 640x240 progressive. Someday I think I'll add 384x288@50Hz, which is the best 4:3 progressive resolution you can have.
Title: Re: Collaborative effort for GroovyArcade
Post by: arfink on March 15, 2020, 10:41:28 am
I'm glad you've been through that easily :)

AM can run at 240p. The kernel even has a 640x240 progressive. Someday I think I'll add 384x288@50Hz, which is the best 4:3 progressive resolution you can have.

How does one get it to run at that res? Do you need a theme that's specifically for that res? If that's all it takes, I guess I'm gonna go theme shopping.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on March 15, 2020, 06:48:29 pm
Which res exactly?
Title: Re: Collaborative effort for GroovyArcade
Post by: keilmillerjr on March 16, 2020, 06:42:04 am
I can confirm that attract runs fine at 640x480 interlaced using multiple platforms.

All themes will stretch to the attract window, regardless if you design your theme and set a fixed pixel dimension. The larger issue is when people design a theme without multiple resolutions in mind (not responsive). If you like neogeo, check out my picknmix theme in my attract fork on gitlab.

Easiest way to add files to GroovyArcade is to connect a usb disk and use the command line. It is linux. If GroovyArcade doesnt auto mount your disk, check out the disk mounting section of my wiki.

https://arcademvs.org/unix/disk-mounting/
Title: Re: Collaborative effort for GroovyArcade
Post by: rewind22x on April 06, 2020, 12:46:13 am
Just wanted to drop in and give thanks for the latest build (GA 18-reorg) really like that it's focused on MAME only.  The hiscore issue that i experienced with previous builds has been resolved.  Doing a little more testing, but will probably install this build on my arcade1up soonish.  Haven't been able to do any testing on the crt cabinet at the office since a week before the pandemic hit.  I go into the office once or twice a week, but just to do some work and then get out of there.  I'm bummed thought, I really want to test this out.  I will try to next time I'm in, at least just test booting from the usb and launching.  That has always failed unless I add some custom settings.

Anyway, thanks again Substring, and anyone else contributing!  Stay safe.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 06, 2020, 05:25:05 am
18-reorg is a WIP, but it's almost the complete April release. Quite much has been done since the March release, I'll give more details once the GM 0.220 and Linux 5.6 are ready, they'll be the kick off for the April Iso. So better wait for thi stable ISO before installing a new cab ;)

What I'd like to state before all, what I strongly believe in, what this GA fork is meant to be: it's open source, team work, collaboration, users tests and feedback. Some members gave much time to the next release, all this work wouldn't be possible without their help (and the covid quarantine ^^). I'll name them very soon :)

And again, thank you for your kind words. GroovyArcade is made for you, for non IT people, even for Linux haters. It focuses on simplicity, 0 knowledge in MAME/Linux. Install, play, don't waste time on configuration!
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 12, 2020, 10:33:09 am
2020.04 IS FINALLY OUT

Grab it here (https://github.com/substring/os/releases/tag/2020.04) !

Quite some changes in this one, hard to list everything without making a full copy/paste of the release itself :
- Attract Mode interlaced is fixed!  Thank you so much oomek!!!
- removed everything that was not mame, so we focus on MAME only
- MAME high scores fixed
- reworked folders structure to gather all useful files in a single place that can be accessed through network. You'll find roms, config files for frontends or emulators, roms. For Windows 10 compatibility, it now requires a user/password: arcade/arcade
- reworked the main menu where I'll remove some unnecessary options with time, rewrite some. The boot resolution menu has been modernized, small bug for now if you have multiple GPUs
- first steps for Intel and Nvidia compatibility. AMD/ATI cards are still better anyway
- mame 0.220, linux 5.6.3

And many thanks to SteelRush, Banane and ghost13500 for the time they've spent with advice, testing, feedback, etc ... for this release. That's the meaning of collaborative at its best !

And I should thank covid19 for allowing us to have more time on our personnal projects at home  ;D
Title: Re: Collaborative effort for GroovyArcade
Post by: donluca on April 12, 2020, 03:53:32 pm
Amazing release, well done!

Although I've not been using GroovyMAME for quite I while (I'm slowly getting all the arcade boards I want) it's nice seeing this progress.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 12, 2020, 04:47:58 pm
Amazing release, well done!

Although I've not been using GroovyMAME for quite I while (I'm slowly getting all the arcade boards I want) it's nice seeing this progress.

Luckily, if you feel like putting your hands into it, you can just flash a USB stick with it to give it a try ;) No need to install to HDD to see if it works or not with your PC ;)
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 13, 2020, 08:00:59 am
For people installing 2020.04, I strongly recommend you
Code: [Select]
sudo pacman -Sy galauncher once installed, otherwise MAME roms will kep an ugly zipfile name
Title: Re: Collaborative effort for GroovyArcade
Post by: TD-Linux on April 25, 2020, 02:25:50 am
Thanks for this build! The syslinux and EFI boot support on the livecd was really handy. As is the gitlab repo for submitting patches :) I'm running on an udoo bolt attached to an arcade CRT.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 25, 2020, 10:23:25 am
Always wanted a udoo bolt ... How does it work ? Are you using a HDMI2VGA ? No low dotclock problem ?

Regarding uefi : well, it boots on UEFI, but that's all for now, there is really much work to do on uefi:
- add the syslinux menu to uefi
- change partitionning from MBR to GPT ... That may not be mandatory, but it's more uefi stylish let's say

All of this means really much work. It's in my todo list, but not top priority I must say.

Afterall, how does your udoo bolt perform with GA ? I'm very curious.
Title: Re: Collaborative effort for GroovyArcade
Post by: TD-Linux on April 26, 2020, 03:35:18 am
The performance is great, however it really behaves identically to most SBCs. For some reason the livecd wouldn't boot in BIOS mode, so I booted it in UEFI, installed to the emmc with BIOS boot, and then switched back to BIOS boot.

I'm using a Tendak HDMI to VGA converter. I wouldn't recommend this one as it draws too much power off the HDMI port for the udoo. I had to crack it open and give it 5V directly.

Yes, the udoo has a 25MHz minimum dotclock, as well as no support for interlaced modes (they get scanned out as though they were progressive). The latter might be fixable. The former is easily solved with groovymame switchres's minimum dotclock setting, however groovyarcade is missing edids that enforce the minimum dotclock.

One downside is the 19V power. It would be nice if it could run off JAMMA power.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 26, 2020, 08:06:18 am
The EDID lead has been left aside in the 2020.04 release, so we xan focus on resolutions. There is one resolution that meets ypur dotclock requirements (but it's interlace): 1280x480iS. I think we should add 1280x240 for people who are allergic to interlace or whose hardware cat handle it
Title: Re: Collaborative effort for GroovyArcade
Post by: ronbin on April 26, 2020, 10:29:29 am
Hello
I don't know if this is the right place for posting this... apologies in advance. Just installed groovyarcade and configured it for my 31khz CRT pc monitor. I've modified mame.ini file with those options
Code: [Select]
unevenstretch             0
effect                    scanlines.png
monitor                   vesa_1024
interlace                 0
doublescan                0
And every arcade game boots perfectly. Some examples
Code: [Select]
SwitchRes: [gng] (1) horizontal (256x224@59.590000)->(512x448@59.590000)
SwitchRes: [sfiii3n] (1) horizontal (384x224@59.599491)->(768x448@59.599491)
SwitchRes: [mk] (1) horizontal (400x254@54.706841)->(800x508@54.706841)
Even console games
Code: [Select]
groovymame genesis -cart /home/roms/SegaGenesis_roms/Sonic\ The\ Hedgehog\ \(USA\,\ Europe\).zip
SwitchRes: [genesis] (1) horizontal (256x224@59.922745)->(512x448@59.922745)
But when I try to load same game with another emulator (mednafen), switchres doesn't work as I expected.
Code: [Select]
switchres genesis --calc --xrandr --monitor vesa_1024 --nodoublescan --nointerlace --emulator mednafen --rom /home/roms/SegaGenesis_roms/Sonic\ The\ Hedgehog\ \(USA\,\ Europe\).zip
# genesis 1280x440@60.00 29.3400Khz
ModeLine          "1280x440x60.00" 46.239840 1280 1304 1424 1576 440 457 460 489 -HSync +VSync

Why doesn't switchres create same modeline for groovymame and mednafen? I would like to use mednafen for sega saturn emulation...
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 26, 2020, 11:26:35 am
I've removed anything console related in my fork of GA for many reasons. One of them being the total randomness of consoles modelines. If you're using VeS' groovyarcade, ask him, but don't expect answers
Title: Re: Collaborative effort for GroovyArcade
Post by: ronbin on April 26, 2020, 12:40:47 pm
OK, thanks for your answer. I'm using your iso, great job by the way.
As I said before, maybe this isn't the right thread to discuss my problem, sorry (I think it's standalone switchres' fault, I shoul ask Calamity).

Thanks again!
Title: Re: Collaborative effort for GroovyArcade
Post by: TD-Linux on April 26, 2020, 01:13:04 pm
The EDID lead has been left aside in the 2020.04 release, so we xan focus on resolutions. There is one resolution that meets ypur dotclock requirements (but it's interlace): 1280x480iS. I think we should add 1280x240 for people who are allergic to interlace or whose hardware cat handle it

Unfortunately you still need an edid if you want to have a config-less Xorg, because the very first thing Xorg does is set the preferred mode from the kernel-supplied edid (at least this is the case for the amdgpu X driver), resulting in a resolution of 1024x768 for example if there was no monitor supplied edid.
Title: Re: Collaborative effort for GroovyArcade
Post by: arfink on April 26, 2020, 01:27:28 pm
I've removed anything console related in my fork of GA for many reasons. One of them being the total randomness of consoles modelines. If you're using VeS' groovyarcade, ask him, but don't expect answers

So I suppose asking about support for modelines for WINE games is out of the question? :P I just really want to make a vertical shmup MAME setup that can also play ZeroRanger.
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on April 26, 2020, 02:46:25 pm
Yes, the udoo has a 25MHz minimum dotclock, as well as no support for interlaced modes (they get scanned out as though they were progressive). The latter might be fixable. The former is easily solved with groovymame switchres's minimum dotclock setting, however groovyarcade is missing edids that enforce the minimum dotclock.

Hi TD-Linux,

If you have any idea of how the interlaced support could be added to integrated Vega GPUs, I'm all ears. I have a 2400G sitting on the shelf.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 26, 2020, 03:07:11 pm
The EDID lead has been left aside in the 2020.04 release, so we xan focus on resolutions. There is one resolution that meets ypur dotclock requirements (but it's interlace): 1280x480iS. I think we should add 1280x240 for people who are allergic to interlace or whose hardware cat handle it

Unfortunately you still need an edid if you want to have a config-less Xorg, because the very first thing Xorg does is set the preferred mode from the kernel-supplied edid (at least this is the case for the amdgpu X driver), resulting in a resolution of 1024x768 for example if there was no monitor supplied edid.
That's not true anymore. Since kernel 5.5, I've rewritten (almost from scratch) the kernel patches. And now the resolutions you specify as a kernel argument are added in in a way that respects kernel internals. In other words, they are now added to DRM modes and made public to X. The iso you're using here is xorg.conf-less for 2 months now :)

EDID comes handy when you need resolutions that are not supported by the kernel, which seems your case as of now.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 26, 2020, 03:12:05 pm
I've removed anything console related in my fork of GA for many reasons. One of them being the total randomness of consoles modelines. If you're using VeS' groovyarcade, ask him, but don't expect answers

So I suppose asking about support for modelines for WINE games is out of the question? :P I just really want to make a vertical shmup MAME setup that can also play ZeroRanger.
Supporting this in a vanilla iso and giving you help are 2 different things ;)
What comes to my mind:
- add a system to AM
- adding a wine galauncher (see /opt/galauncher and /opt/galauncher/emulators) could be useful
- if you go the galauncher path, you'd need a small "game to modline" file you'd parse.
- if you don't care about galauncher, your AM emulator should call switchres with --emulator and --rom I guess
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on June 03, 2020, 10:52:49 am
Quick update : no may iso due to the late release of Mame 0.221, so straight to a June release. No great visible changes, just some files are now in packages rather than shipped in the OS (and can't be updated later)

Using the groovymame-config package, you should now always have a history.dat and mameinfo.dat up to date with the GM version. Who'd want to update to this package will get their mame.ini reinitialised, thus loosing the monitor configuration.

Coming soon should be the 5.7 kernel with a new 1280x240 resolution for GPUs that require a 25MHz clock but that can't do interlace.
Title: Re: Collaborative effort for GroovyArcade
Post by: jcapone on June 13, 2020, 12:20:27 pm
Noob here. Just installed your latest ISO. Looks great so far.

My question, how do I program my USB zero delays? I can't search to see if previously answered
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on June 15, 2020, 08:51:19 am
Hi !

How do you want to configure it ? Is it seen as a keyboard or a HID device ?

As for now, the OS is configured for default mame inputs, so keyboard only. You must manually reconfigure inside AM and MAME your inputs if they differ.
Title: Re: Collaborative effort for GroovyArcade
Post by: keilmillerjr on June 16, 2020, 07:32:22 am
Noob here. Just installed your latest ISO. Looks great so far.

My question, how do I program my USB zero delays? I can't search to see if previously answered

Zero Delay is a joystick encoder with fixed firmware. You can not "program" it.