Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Lightguns Arcade1Up --- Bug Reports --- Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news

  

Author Topic: Collaborative effort for GroovyArcade  (Read 2500 times)

0 Members and 1 Guest are viewing this topic.

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 127
  • Last login:Today at 03:26:55 am
  • I want to build my own arcade controls!
Collaborative effort for GroovyArcade
« 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 repo https://gitlab.com/substring45/test mirrored at https://github.com/substring/test (gitlab automatically pushed to github). I'll explain later why i'm using both.

So the aim of this repo is to:
  • give a base repo to GA iso
  • be able to "easily" build GA on your computer (in my case, I'm not using Arch Linux but Ubuntu)
  • setup some automatic build process -> CI kicks in!
  • be able to easily add some packages to GA
  • and mostly give a hand to ves who's been doing GA all alone

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):
  • Add the whole gasetup thing, make it a package + a repo
  • include the 15kHz linux kernel (which also means rebuild the initramfs)
  • setup an AUR repo for easier updates. One point regarding that : anything required to setup a AUR repo is in the github releases page (this is why gitlab mirrors to github, and the CI does the releases to github, saving a server for now)
  • write documentation, despite the .gitlab-ci.yml is quite self explanatory when reading the jobs
  • make sure it can be booted from USB (.iso is so 90s :D). It should be bootable, but i just couldn't test yet
  • clean the repo, a few files are unnecessary
  • improve the CI to only auto build the master branch when any commit is pushed, build other branches manually (with probably a basic makepkg --nobuild for a basic check) and release when tagged

For curious people
  • check the buildContainer.sh + buildGA.sh scripts, they do the main job. There is also a docker file that' I've been using with the builder.sh to build locally. The CI is natively built in an arch linux docker image
  • read the packages_*.lst files + the package folder. packages_arch.lst are (for now) arch packages that are patched on the fly when it's time to build them. mame is patched with groovymame and becomes a groovymame package. Same goes for liunx -> linux-15kHz. packages_native.lst are genuine arch packages that are installed. packages_aur.lst are AUR packages built and then installed in the iso. packages_local.lst is packages_arch.lst once patched, and lists packages to install in the iso (mame+linux -> groovymame+linux-15khz)
  • buildContainer.sh 's job is to build all packages, and then create the necessary files for an AUR site. I've tested locally, works great. See the web-repo folder on how to host
  • buildGA.sh downloads and unpacks the default ARCH iso, unsquashfs the arch suquashfs file, installs everything in it through chroot, then re-squashfs the folder, patches some names here and there for grub, and rebuilds the iso
  • the pipeline that built the 2019-04 tag and deployed the release to github : https://gitlab.com/substring45/test/pipelines/55863348

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

Credits go to Calamity, ves and doozer for their respective work on groovymame, groovyarcade, and linux 15kHz patches.
« Last Edit: April 09, 2019, 07:27:34 am by Substring »

keilmillerjr

  • Trade Count: (+5)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1708
  • Last login:Today at 07:00:27 am
  • Web Developer.
Re: Collaborative effort for GroovyArcade
« Reply #1 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.

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 127
  • Last login:Today at 03:26:55 am
  • I want to build my own arcade controls!
Re: Collaborative effort for GroovyArcade
« Reply #2 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, it should have all the info to locally build, but I may have missed some parts/pre-requisites

cools

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 604
  • Last login:Today at 03:20:51 am
  • Arcade Otaku sysadmin...
    • Arcade Otaku
Re: Collaborative effort for GroovyArcade
« Reply #3 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.
Please don't PM me with support questions. Ask in public so everyone can learn!

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 127
  • Last login:Today at 03:26:55 am
  • I want to build my own arcade controls!
Re: Collaborative effort for GroovyArcade
« Reply #4 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 ?

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6723
  • Last login:Today at 01:56:57 am
Re: Collaborative effort for GroovyArcade
« Reply #5 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.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

keilmillerjr

  • Trade Count: (+5)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1708
  • Last login:Today at 07:00:27 am
  • Web Developer.
Re: Collaborative effort for GroovyArcade
« Reply #6 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.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6723
  • Last login:Today at 01:56:57 am
Re: Collaborative effort for GroovyArcade
« Reply #7 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).

Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 127
  • Last login:Today at 03:26:55 am
  • I want to build my own arcade controls!
Re: Collaborative effort for GroovyArcade
« Reply #8 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:
- 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.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6723
  • Last login:Today at 01:56:57 am
Re: Collaborative effort for GroovyArcade
« Reply #9 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:
- 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.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 127
  • Last login:Today at 03:26:55 am
  • I want to build my own arcade controls!
Re: Collaborative effort for GroovyArcade
« Reply #10 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 ? If yes, I'll write a small PKGBUILD and have it compiled with GA.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6723
  • Last login:Today at 01:56:57 am
Re: Collaborative effort for GroovyArcade
« Reply #11 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 ? If yes, I'll write a small PKGBUILD and have it compiled with GA.

Last version posted by me was this one. IIRC Ansa took that one and fixed some bugs, etc., not sure.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 127
  • Last login:Today at 03:26:55 am
  • I want to build my own arcade controls!
Re: Collaborative effort for GroovyArcade
« Reply #12 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. It looks rather easy

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6723
  • Last login:Today at 01:56:57 am
Re: Collaborative effort for GroovyArcade
« Reply #13 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. 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.).
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 127
  • Last login:Today at 03:26:55 am
  • I want to build my own arcade controls!
Re: Collaborative effort for GroovyArcade
« Reply #14 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. 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 ...

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6723
  • Last login:Today at 01:56:57 am
Re: Collaborative effort for GroovyArcade
« Reply #15 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.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 127
  • Last login:Today at 03:26:55 am
  • I want to build my own arcade controls!
Re: Collaborative effort for GroovyArcade
« Reply #16 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).

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6723
  • Last login:Today at 01:56:57 am
Re: Collaborative effort for GroovyArcade
« Reply #17 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.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 127
  • Last login:Today at 03:26:55 am
  • I want to build my own arcade controls!
Re: Collaborative effort for GroovyArcade
« Reply #18 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)
« Last Edit: April 14, 2019, 05:42:47 pm by Substring »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6723
  • Last login:Today at 01:56:57 am
Re: Collaborative effort for GroovyArcade
« Reply #19 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.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 127
  • Last login:Today at 03:26:55 am
  • I want to build my own arcade controls!
Re: Collaborative effort for GroovyArcade
« Reply #20 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!

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6723
  • Last login:Today at 01:56:57 am
Re: Collaborative effort for GroovyArcade
« Reply #21 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.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 127
  • Last login:Today at 03:26:55 am
  • I want to build my own arcade controls!
Re: Collaborative effort for GroovyArcade
« Reply #22 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 !

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 127
  • Last login:Today at 03:26:55 am
  • I want to build my own arcade controls!
Re: Collaborative effort for GroovyArcade
« Reply #23 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

cools

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 604
  • Last login:Today at 03:20:51 am
  • Arcade Otaku sysadmin...
    • Arcade Otaku
Re: Collaborative effort for GroovyArcade
« Reply #24 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.
Please don't PM me with support questions. Ask in public so everyone can learn!

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 127
  • Last login:Today at 03:26:55 am
  • I want to build my own arcade controls!
Re: Collaborative effort for GroovyArcade
« Reply #25 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

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6723
  • Last login:Today at 01:56:57 am
Re: Collaborative effort for GroovyArcade
« Reply #26 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.

Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 127
  • Last login:Today at 03:26:55 am
  • I want to build my own arcade controls!
Re: Collaborative effort for GroovyArcade
« Reply #27 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.
« Last Edit: April 16, 2019, 03:29:49 pm by Substring »

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 127
  • Last login:Today at 03:26:55 am
  • I want to build my own arcade controls!
Re: Collaborative effort for GroovyArcade
« Reply #28 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.

keilmillerjr

  • Trade Count: (+5)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1708
  • Last login:Today at 07:00:27 am
  • Web Developer.
Re: Collaborative effort for GroovyArcade
« Reply #29 on: May 21, 2019, 11:51:34 am »
Free bump for awesome project!

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 127
  • Last login:Today at 03:26:55 am
  • I want to build my own arcade controls!
Re: Collaborative effort for GroovyArcade
« Reply #30 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

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 441
  • Last login:Today at 07:45:02 am
  • Z80 ERROR
Re: Collaborative effort for GroovyArcade
« Reply #31 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.

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 127
  • Last login:Today at 03:26:55 am
  • I want to build my own arcade controls!
Re: Collaborative effort for GroovyArcade
« Reply #32 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).

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 441
  • Last login:Today at 07:45:02 am
  • Z80 ERROR
Re: Collaborative effort for GroovyArcade
« Reply #33 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.

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 127
  • Last login:Today at 03:26:55 am
  • I want to build my own arcade controls!
Re: Collaborative effort for GroovyArcade
« Reply #34 on: June 05, 2019, 01:22:00 pm »
The real command is su arcade -c startx -- vt7. I've attached the xorg log

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 127
  • Last login:Today at 03:26:55 am
  • I want to build my own arcade controls!
Re: Collaborative effort for GroovyArcade
« Reply #35 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

ves

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 224
  • Last login:June 05, 2019, 05:20:24 pm
Re: Collaborative effort for GroovyArcade
« Reply #36 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"
 

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 127
  • Last login:Today at 03:26:55 am
  • I want to build my own arcade controls!
Re: Collaborative effort for GroovyArcade
« Reply #37 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. 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)
« Last Edit: June 05, 2019, 06:03:30 pm by Substring »

keilmillerjr

  • Trade Count: (+5)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1708
  • Last login:Today at 07:00:27 am
  • Web Developer.
Re: Collaborative effort for GroovyArcade
« Reply #38 on: June 16, 2019, 05:05:56 pm »
Thank you for the iso. Will test soon. Interesting coun issue with groovymame.

keilmillerjr

  • Trade Count: (+5)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1708
  • Last login:Today at 07:00:27 am
  • Web Developer.
Re: Collaborative effort for GroovyArcade
« Reply #39 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 don’t do that taboo). Not sure what would be the proper thing to do for the latter case.

Thank you substring. Keep the updates going!