GroovyArcade live-CD 2022 (collaborative effort)

[Banane]

Happy new year  . Really looking forward to your updates 
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)

• Board: Asrock a320m-hdv
• CPU: AMD Ryzen 5 2400G (integrated AMD Radeon Vega 11)
• Graphic: 1x 2GB Sapphire Radeon R5 230 PCIe, using VGA-Out, 1x HD6450 1GB PCIe, using DVI2VGA-Adapter
• HDD: 970 EVO Plus NVMe M.2 SSD, 250GB
• Monitors:   Computer CRTs  +  several arcade monitors (Hantarex, WellsGardner etc.)

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 ? Itīs not tty7 (Edited: Oh well, I can parse /var/log/groovy.log )
 

Test2 / GA-Installer on NVMe SSD: :  Autoformat /dev/nvme0n1 doesnīt 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 itīs copying the files to /dev/nvme0n13 instead of  /dev/nvme0n1p3 - so I guess itīs just a parsing error of the script  )
-------------------------------------------------------------
(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
-------------------------------------------------------------

[Substring]

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 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

[Substring]

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

[Banane]

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.

Iīve tested it on a regular LCD monitor now, youīre right, itīs just the output which is not correct. The monitor itself is detected, the config is created. I will just wait for your update/pushes 

• I can start the frontend afterwards with no problem.
• Monitor war turned on and off - with an arcade monitor I can test later
• There is no voice speaking, no. Speakers are turned on
• Radeon driver was used (lspci + dmesg)

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

[Substring]

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.

[Banane]

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) 

I'm fully pleased:

• the attract mode interlaced mode bug has been pointed out - there is a workaround
• the distro with groovyMame based on my favroute linux distro is still maintained, a community seems to grow
• you even dig deeper into the driver / kernel topics

[Substring]

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 

[keilmillerjr]

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.

[Substring]

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)

[Substring]

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

[Banane]

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

[Substring]

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

[Banane]

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.

[Substring]

My bad, should be fixed now

[Banane]

Perfect - it is . Thank you !

[Substring]

Nice ! If you ever have time to test with arcade monitors and different GFX cards, I'd appreciate

[Substring]

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

[arfink]

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?

[Substring]

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

[Calamity]

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.

[arfink]

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.

[Substring]

I'm.not so much into signals, but how isnit different from combining hsync and vsync ?

[arfink]

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.

[Substring]

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 ?

[Calamity]

@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.

[Substring]

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

[Recapnation]

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!

[Substring]

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.

[Recapnation]

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).

[Substring]

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

[Recapnation]

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.

[Substring]

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.

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.

[Recapnation]

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.

[Substring]

Anyway, thank you for your opinion 

[sterbehilfe1980]

very cool project!  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! 

[Substring]

1st things first : no idea how freesync will behave with Linux. But AMD docs 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.

[sterbehilfe1980]

1st things first : no idea how freesync will behave with Linux. But AMD docs 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  will try groovyarcade anyway...curious to see what you guys allready archived.

[psakhis]

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?   

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

Thx!

[arfink]

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?   

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.

[rewind22x]

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!