GroovyArcade live-CD 2020

[cools]

just noticed - there is a beta dated 24th April 2014 - did we miss anything?  There is nothing in the forums about it...

Seems to work reasonably well for me. Had some sync problems that looked like dot clock being too low, but setting it to 8 (same as my XP install) didn't help a jot with one of the built in games. Wasn't too troublesome to work out the install method either (pro-tip: you can dd the iso directly to a USB stick to install from, no need for a CD to be burnt).

I'd love to see a vertical splash and vertical console as well.

(Building Groovy on top of Arch Linux isn't proving straightforward, I don't know if I'm missing some packages but I've not been able to compile without errors/failure yet)

[NightSprinter]

Strangely, whether doing so via a burned DVD-RW or USB, the installer seems to completely go into what looks like a Kernel Panic during the actual install step.  When a good ten or so minutes pass, if I'm lucky, it asks if I want to reboot (claiming the install finished).  Rebooting results in the boot loader complaining about a "MISSING OPERATING SYSTEM".

[Edit] Turns out it was being caused by a hard drive going bad.  I removed it.

[Calamity]

[Edit] Turns out it was being caused by a hard drive going bad.  I removed it.

Thanks for reporting this back anyway.

[NightSprinter]

Question for Ansa89, Calamity, and ves: would the GPU of the new AMD A-10 series APU be compatible with the distro?  I was just given a Mini-ITX case and plan to upgrade my setup into an SFF machine.

[NightSprinter]

This for me is a bug report, but does anyone recall ever having the latest beta force network interface eth0 to permanently be stuck at an IP address of 192.168.1.69?  Seems to make things impossible for doing any updates or software installation.

[Calamity]

Question for Ansa89, Calamity, and ves: would the GPU of the new AMD A-10 series APU be compatible with the distro?  I was just given a Mini-ITX case and plan to upgrade my setup into an SFF machine.

No idea, it will all depend on the newest chipset that's supported by the open source driver. My guess is that at least eventually it will be supported.

This for me is a bug report, but does anyone recall ever having the latest beta force network interface eth0 to permanently be stuck at an IP address of 192.168.1.69?  Seems to make things impossible for doing any updates or software installation.

Sounds like GAsetup creating a bad network auto configuration. In my case, and for the wifi to work, I need to run "sudo netctl stop-all", only then the wifi configuration in GAsetup will setup wlan0 fine.




 

[NightSprinter]

Thanks for the info.  Wasn't sure if the ATI driver package can also call the Radeon 7000, R5, R7, and R9 cards, or if they still only rely on the radeonsi driver.

[cools]

Trying the latest GA beta on a new build (Gigabyte H81M-H, i5 4690, 4GB RAM, Crucial M4 SSD) - it gets as far as the progress bar being filled (which takes an awful long time) then just seems to sit there, never moving further. The splash screen is still pulsing though.

I've tried various key combinations I'd normally use to switch to a terminal but no luck. Any suggestions?

[cools]

On my other (older) box however, swapping the 4350 for an X600 has made GroovyArcade work better (I was getting what appeared to be low dotclock issues despite having the setting in mame.ini, but more on that in a second).

Enhancements: adding

Code: [Select]

fbcon=rotate:1
To the end of the kernel boot string in /boot/syslinux/syslinux.cfg rotates the console and the setup screens, which is saving my neck.

Also, I can't see that it's been reported but groovymame is a symlink of groovyume in the beta. This is (semi) bad if you're not aware of it and want to make manual changes to mame.ini, because that file isn't used. So while my X600 seems happy with low dotclocks, my 4350 would probably have been okay with dotclock_min 8 except for the fact that the setting wasn't being used!

[jtslade]

On my other (older) box however, swapping the 4350 for an X600 has made GroovyArcade work better (I was getting what appeared to be low dotclock issues despite having the setting in mame.ini, but more on that in a second).

Enhancements: adding

Code: [Select]

fbcon=rotate:1
To the end of the kernel boot string in /boot/syslinux/syslinux.cfg rotates the console and the setup screens, which is saving my neck.

Also, I can't see that it's been reported but groovymame is a symlink of groovyume in the beta. This is (semi) bad if you're not aware of it and want to make manual changes to mame.ini, because that file isn't used. So while my X600 seems happy with low dotclocks, my 4350 would probably have been okay with dotclock_min 8 except for the fact that the setting wasn't being used!

So will that make all boot up screens and gasetup run in vertical instead of horizontal on an arcade monitor? That would be awesome!

[cools]

It doesn't do the bootup screens, but gasetup and the shell are rotated fine.

[Calamity]

Code: [Select]

fbcon=rotate:1

Thanks for the pointer, that's very cool indeed.

Also, I can't see that it's been reported but groovymame is a symlink of groovyume in the beta. This is (semi) bad if you're not aware of it and want to make manual changes to mame.ini, because that file isn't used.

Yeah, I feel your pain. Hopefully Ves listens to my prayers and makes the live-cd GroovyUME-only. Currently only GroovyUME is included already but Ves is sentimental about the MAME brand so he created that symlink but IMHO it makes things confusing.

[cools]

I see. Would make sense for the live CD. The smaller executable loads more quickly from HDD for me, but once cached there's not a great difference.

[Ansa89]

Communication for linux users: here you can find the 15KHz patches for linux 3.15.

[NightSprinter]

Hey, Calamity, remember when I said that progressive/interlace switching was slow on my monitor?  I just did a test with my Saturn hooked up via RGB and a copy of Sonic Jam (menus and Sonic World are 480i, as well as vs modes, but the games are otherwise 240p).  The monitor seems to switch rather quickly on the console.    So I think that "issue" seems to lay in any possible combination of emulators/driver/OS.  What is your take on this?

[Calamity]

So I think that "issue" seems to lay in any possible combination of emulators/driver/OS.  What is your take on this?

Sure. A console can in theory reprogram the video hardware in an instant. On the other hand doing a mode switch on a modern OS entails lots of "burocracy". Usually the video signal is turned off to hide the process as if it was something embarrassing, so the monitor may enter in a sleep state during a moment.

[Whipon]

I have a little request for ADVMenuPlus:

I have an usb encoder that I use for my mame cab with GroovyArcade.
Thanks to your help now I'm using it perfectly fine in all my games and emulators.

However there is a little issue with it: my axes aren't recognized by AdvMenuPlus:

I did a jstest and my usb joysticks uses the 04 axys for X and the 05 axys for Y.

Is there any way these axys can be supported so my controls fully work?. Maybe a patch or something similar?.

Thanks in advance for any help.

Regards and thanks.

Whipon.

[cools]

Hi cools,

I assume from https://code.google.com/p/groovyarcade/source/browse/?repo=diff that all that needs patching are the kernel, libSDL and the Xorg video driver?

Yes, as far as I know that's all what needs to be patched (kernel, SDL, Xorg driver). Of course if you're using more up to date packages you may need to adapt some of the patches.

Let us know about your progress.

Step 1 done: Arch Linux installed and SDLMAME compiled. http://rogalian.blogspot.co.uk/2014/05/groovymame-installation-on-arch-linux.html
Step 2 to come, recompiling (unpatched) kernel/SDL/Xorg libs.

[cools]

(Current) kernel and SDL are still compatible with the patches. Xorg appears to have moved on, while I can compile the patched driver I'm not so sure it'll actually work with the server 

On the plus side, a GroovyMAME package would be dead easy to do for Arch. Quite like the packaging system it uses.

[NightSprinter]

Yeah, this is a concern.  Do we have patches for the current versions of the ATI and novueau drivers?  I know recent additions to the latter have increased speeds dramatically for at least several recent cards.  That would be beneficial to those that run games outside of emulation on their arcade boxes.

[cools]

Actually looking at the patches however they are straightforward changes so shouldnt be any trouble to update with a newer source.

[NightSprinter]

Where are they at now?  I've only seen an Arch package on the google drive link.

[cools]

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

[NightSprinter]

Ah.  So the ATI 7.2 patches will work fine with 7.3, and same with the current nouveau on the recent version?

[cools]

Maybe the diffs won't but they're easy enough edits to make manually provided the code hasn't changed dramatically.

[NightSprinter]

*nod* That would be the area I'd have trouble with.. 

[cools]

The Ati diff goes cleanly in to newer sources. The Nvidia one doesn't. I'm at the limit of what I can do in a VM, my notes are up to date for it.

The way I've implemented the patches is the Arch Linux approved method, it'd be straightforward to take them and get them into AUR for anyone to use. I'd be okay doing this if I was actually going to use what I was maintaining, but with the lag found in SDL I'm not that interested in doing so. We'll see. Don't want to be treading on anyone's toes either as it's clear that ves is working on something too.

[Calamity]

The Ati diff goes cleanly in to newer sources. The Nvidia one doesn't. I'm at the limit of what I can do in a VM, my notes are up to date for it.

The way I've implemented the patches is the Arch Linux approved method, it'd be straightforward to take them and get them into AUR for anyone to use. I'd be okay doing this if I was actually going to use what I was maintaining, but with the lag found in SDL I'm not that interested in doing so. We'll see. Don't want to be treading on anyone's toes either as it's clear that ves is working on something too.

Hi cools, if you have the time/energy/knowledge to do the AUR packages please go ahead, the important part of the project imho is to keep updated knowledge about how to modify Linux in order to support arcade monitors, and this should be a collective task.

[cools]

Okay, well I'm plenty capable of dragging together the packages. I'll see what I can do. Shame the package name groovy is already taken

[cools]

Made a start. It's pretty painless since all I'm doing is taking existing builds and adding some patches to them. Leave the clever stuff to those that know it

https://aur.archlinux.org/packages/?K=cools&SeB=m

Code: [Select]

$ mkdir ~/builds
$ cd ~/builds
$ curl -L -O https://aur.archlinux.org/packages/li/linux-groovy/linux-groovy.tar.gz
$ tar -xvf linux-groovy.tar.gz
$ cd linux-groovy
$ makepkg -s
# pacman -U linux-groovy-3.15.1-1.pkg.tar.xz
# pacman -U linux-groovy-headers-3.15.1-1.pkg.tar.xz
# pacman -U linux-docs-headers-3.15.1-1.pkg.tar.xz
Edit /boot/syslinux/syslinux.cfg to add a new default entry for linux-groovy

[Calamity]

Hi cools,

Thanks a lot for the packages, they will be useful for a lot of people.

So all basic "groovy" features work for you with these packages?

[Hopefully in the next days I'll be looking into trying to bypass the lag in SDL, let's cross fingers.]

[cools]

That's all the packages built. I know the depends/conflicts aren't perfect yet but I'll get those sorted out soon, hopefully tonight. It's straightforward to update them.

I know the kernel works perfectly as I've tested it on real hardware. The rest I don't know, I can/will test everything bar the NVidia driver though.

[cools]

Success! I've got all but one of the dependencies sorted (you have to force install sdl-groovy after installing sdl, because sdl_ttf depends on sdl, even though sdl-groovy is supposed to provide sdl - not sure what's going on there). Should have time to upload the "final" packages later.

The only parts I'm not sure of at the moment - xorg-xinit is required for startx, or is there another way of firing up an x server? And of course the initial /etc/xorg.conf configuration, I believe this is taken care of by some clever scripts in GroovyArcade.

But yeah, it's just a matter of building the packages, banging some values in some config files and running it.

Wonder if Ves would be interested in packaging up the Xorg/bootloader/frontend selection bits from GroovyArcade...

[cools]

Fixed the sdl dependency issue so nothing needs forcing.

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

[NightSprinter]

I know for anything 15KHz/2xKHz-related, it probably would (but don't quote me on that) due to all of the standard-res games going below 320x240.  If I remember usage correctly outside of LCDs, using modeline generation/switching could potentially benefit higher-res computer monitors.  Given my XM2960 can support both the 15.75KHz frequency and higher ranges from 31.5-65KHz, I can boot up my test box and give it a shot if you want.

[cools]

Up to you. The groovyume package currently depends on the patched ones, so you might have some fun trying to compile it... It's easy enough to edit them out of the PKGBUILD though.

[Calamity]

Great job, Cools!

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

(IIRC) GroovyMAME doesn't need the patched kernel because it runs on top of Xorg. The kernel patches are just to add the 15 kHz modelines so they are available to the console (boot, etc.). Once inside Xorg, GroovyMAME can create whatever mode through xrandr. Actually the kernel modelines aren't used by GroovyMAME.

Besides, the kernel patch allows the ArcadeVGA 3000 card to work properly.

However, the SDL patch is vital to GroovyMAME, but just in the case of games that switch resolutions several times (many).

The patched ATI drivers fix a problem wth v-sync not working upon a mode switch, apart from allowing low resolutions (lower than 320x240, which wouldn't be strictly necessary anyway if some sort of multiple width mode was used).

As a note, not sure if any one realized about this. I'll write a little how-to when I have some time. It allows creating a custom EDID through Switchres. This adds the required custom modeline into a custom EDID which is loaded by the kernel on boot, making the kernel patches redundant. It's limited to one modeline by now, which it's plenty enough for most purposes. The good thing is that this modeline is made based on the same crt_range settings used by GroovyMAME, so you can make the both match in geometry, something that was not possible before. Besides the custom EDID should mask the physical one in the monitor, if any, preventing its factory modes from getting in the middle.

[cools]

I will have a go with that later. I know in the distant past only certain kernel drivers would go low without being patched, but if GM is driving Xorg directly that fixes things. Thanks for the info, I'll see how I get on.

[cools]

Okay, well I have an Intel onboard in the same machine, when I get time I'll give it a go and report back.

On a tangent, you have a Polostar? How does it handle 512p (I think it's running 57hz when doing so)? The Toshiba I have renders it exactly the same height as 480p so I don't have to touch vertical size adjustments at all.

[Calamity]

On a tangent, you have a Polostar? How does it handle 512p (I think it's running 57hz when doing so)? The Toshiba I have renders it exactly the same height as 480p so I don't have to touch vertical size adjustments at all.

512p works just fine at 57 Hz, although it's taller than 480p. The Polostar has three internal presets, and 512p triggers the same one as 480p. Maybe your Toshiba is more like a PC monitor, that is: truly multi-sync, rather than banded-sync like the Polostar.

PD: Anyway my favourite mode for using fractional scaling with the Polostar is 800i, which uses the 25 kHz range.