Development of module-script generator for lr-mess, lr-mame and mame standalone

Folly

Here you can see the changes I made to the docsview.sh and trying to convert it to a base for our front-end.
https://github.com/FollyMaddy/RetroPie-Share/commit/07daf2f032dbdd3a06fb030ae2443151bf28e14a

You will see :

I just changed the page string and the pages array into system and systems.
I changed the command to get the mame system information into the array.
I turned of some docsview choices.

Folly

@DTEAM @valerino

Perhaps very premeture, but we can already create with the front-end script.
https://raw.githubusercontent.com/FollyMaddy/RetroPie-Share/main/00-workdir-00/add-mamedev-systems.sh

Download to RetroPie-Setup :
( Edit : renamed the file on github as add-mamedev-systems-test1.sh which is saved with this command as add-mamedev-systems.sh )

wget -q -nv -O /home/$(ls /home)/RetroPie-Setup/scriptmodules/supplementary/add-mamedev-systems.sh https://raw.githubusercontent.com/FollyMaddy/RetroPie-Share/main/00-workdir-00/add-mamedev-systems-test1.sh

Go to -> configuration / tools -> select (192) add (wait 20 sec.) -> view systems -> select a system -> it will generate and install (and will go back to the systems list again)
~~Then you still have to restart the RetroPie-Setup to see the new module-scripts.~~
Refresh added in third commit.

Commit 1 :
This is what I changed to fix the ownership problem :
Perhaps a bit unconventional but I changed the generate-systems-lr-mess_mame-2v0-alpha.sh so it will create in /home/<user> .
(many times it will become the normal /home/pi though)
It will also change the ownership to the normal <user> .
https://github.com/FollyMaddy/RetroPie-Share/commit/6fa291756f11611204d2ce3262b52e203f0737e4

Commit 2 :
Perhaps I also have to fix also the created directory in line 84.
I have to check this (fixed this too) :
https://github.com/FollyMaddy/RetroPie-Share/commit/53265236288a829382dfa6820313c23bb1215b12

Edit : I will search for a better user/ownership solution.
It works for now, but it's not the perfect solution, I think.

Commit 3 :
Added refresh, so no need to restart RetroPie-Setup :
https://github.com/FollyMaddy/RetroPie-Share/commit/8a3c7d6487b7371652f41a956733e989d158e93f

Commit 4 :
Moved refresh to somewhere else, added clear, added unconventional way of installing the generated module-scripts directly :
https://github.com/FollyMaddy/RetroPie-Share/commit/debe1edd0fae83e8572ff9678a1fc2295ebff1ea
It is obvious to see I have to get the module_id with the ls command.
If the generated-script is within the front-en module we can just use those strings to install the generated-script.

DTEAM

@folly
Wow, you are fast. I don't have time to test it right now, but I will do it ASAP. Great job!

Folly

Yesterday I used the retropie_packages.sh within the front-end-module.
It was possible to directly install the generated module-scripts after generation.
So that is nice to know.

I see the possibilities here :

show systems in dialog menu
select systems
refresh modules after generation
install generated modules directly after generation

But I also encounter some limits with the approach, that I took, with running the generation-script with curl from the front-end-test module,
because strings can't be exchanged easily between the front-end and the generator-script back and forth.
So perhaps it's better to implement the generator-script within the front-end module-script.

I also have some concern about the filling of the array's.
I would like to display the systems descriptions instead of the systems names to get a better idea on what we choose/install.
Integrating the generation-script could be the better approach in this case.
Along with filtering can take more time as we build more things into it.
So I have to think about that.
Perhaps there is a way of doing this one time, making fixed array's that are faster, once created.
And then add a refresh option, so things can be refreshed/updated on demand.

Well I have to think that a bit, hopefully I don't make it too difficult for myself and others.

DTEAM

@folly
I Folly, normally I'm fast to reply, but now, I'm busy with real life stuff. I’ll check what you did this tuesday. It looks awesome. regards

Folly

@dteam

No problem, I understand.

Folly

@DTEAM @valerino

As a test-2, I integraded the generation-script within the front-end module-script.

I already notice, that this approach will probably will be much better.

I saved the file on github as add-mamedev-systems-test2.sh.
With this command it is saved/overwritten as add-mamedev-systems.sh

wget -q -nv -O /home/$(ls /home)/RetroPie-Setup/scriptmodules/supplementary/add-mamedev-systems.sh https://raw.githubusercontent.com/FollyMaddy/RetroPie-Share/main/00-workdir-00/add-mamedev-systems-test2.sh

Here you can see most changes of test-1 vs test-2 :
https://github.com/FollyMaddy/RetroPie-Share/commit/a53ebf77ff2f556558785469e2a1220e6ae5f56c

DTEAM

@folly

I did Test-2 with astrocde and It works! It's alot of systems when Arcade and MESS are togheter .

I also have some concern about the filling of the array's.
I would like to display the systems descriptions instead of the systems names to >get a better idea on what we choose/install.

A site like Arcade Database is able to connect systems descriptions and the systems names. They have a Mame Dat Editor

A database probably exist to match that. I'll try to found It.

Folly

@dteam

To scroll faster you can use the home,page-up, page down and end keys too.

In the future it should become more easy when we filter it.
And we could also add a choice menu of systems that are already tested and working like we did with the desired-script.

But for now I an focusing on the basic structure things before I add more.
That way I can improve some stuff an reduce the size a bit so it becomes more easy to add stuff later. (I hope)

Do you understand the changes I made ?

A site like Arcade Database is able to connect systems descriptions and the systems names. They have a Mame Dat Editor

A database probably exist to match that. I'll try to found It.

Perhaps, we can use your suggested site.
Let me know what you find.
But first I want to try and get the most information out of mame standalone.

Here you can see, there is already a lot of info in mame already :

/opt/retropie/emulators/mame/mame -listdevices svision      
Driver svision (Super Vision):
   <root>                         Super Vision
     cart_list                    Software List
     cartslot                     Generic Cartridge Slot
     custom                       Super Vision Custom Sound @ 4.00 MHz
     lspeaker                     Speaker
     maincpu                      WDC W65C02 @ 4.00 MHz
     palette                      palette
     rspeaker                     Speaker
     screen                       Video Screen

DTEAM

@folly said in Development of module-script generator for lr-mess and mame standalone:

But for now I an focusing on the basic structure things before I add more.
That way I can improve some stuff an reduce the size a bit so it becomes more >easy to add stuff later. (I hope)

Do you understand the changes I made ?

Yes, I know. I understand your process.

Perhaps, we can use your suggested site.
But first I want to try and get the most information out of mame standalone.

👍🏻

Folly

@dteam said in Development of module-script generator for lr-mess and mame standalone:

@folly said in Development of module-script generator for lr-mess and mame standalone:

Perhaps, we can use your suggested site.
But first I want to try and get the most information out of mame standalone.

👍🏻

Did I interpret something wrong ?

I really don't know much about these .dat files.
Perhaps you can explain a bit more on how we should use them.

Edit :
I think you mean we can use this site to filter in such a way that we know what systems are of the handheld genre. Am I correct ?

DTEAM

@Folly

Question unrelated to the thread, do you know if there is a dump of taito_type_x_bios.bin. I'm looking for Raiden 3. I don't think so from what I've read on the internet, but it's from 2020. We never know!

DTEAM

@folly

Did I interpret something wrong ?

No, I like what you proposed with MAME file

/opt/retropie/emulators/mame/mame -listdevices svision      
Driver svision (Super Vision):
   <root>                         Super Vision
     cart_list                    Software List
     cartslot                     Generic Cartridge Slot
     custom                       Super Vision Custom Sound @ 4.00 MHz
     lspeaker                     Speaker
     maincpu                      WDC W65C02 @ 4.00 MHz
     palette                      palette
     rspeaker                     Speaker
     screen                       Video Screen

Folly

@dteam said in Development of module-script generator for lr-mess and mame standalone:

@folly

Did I interpret something wrong ?

No, I like what you proposed

Ok.
I go on with this.
I we get stuck, or if we want to extract more info somehow,
we can always use this site.
But you have to know that extracting information from .dat (i think these are .xml) can be a pain in the ass.

Folly

@dteam said in Development of module-script generator for lr-mess and mame standalone:

@Folly

Question unrelated to the thread, do you know if there is a dump of taito_type_x_bios.bin. I'm looking for Raiden 3. I don't think so from what I've read on the internet, but it's from 2020. We never know!

Do you know what the system is ?

DTEAM

@folly said in Development of module-script generator for lr-mess and mame standalone:

taito_type_x_bios.bin

taitotx.cpp with MAME

https://github.com/mamedev/mame/blob/master/src/mame/drivers/taitotx.cpp

ROM_START( raiden3 )
	ROM_REGION( 0x10000, "maincpu", ROMREGION_ERASEFF )
	ROM_LOAD("taito_type_x_bios.bin", 0x00, 0x10000, NO_DUMP ) // size unknown.
	/* bios, video bios etc. not dumped */

I found my answer !!

It's sad

Folly

@dteam said in Development of module-script generator for lr-mess and mame standalone:

@folly said in Development of module-script generator for lr-mess and mame standalone:

taito_type_x_bios.bin

taitotx.cpp with MAME

https://github.com/mamedev/mame/blob/master/src/mame/drivers/taitotx.cpp

I can only find taitotz in 0.229

Search for "motherload-of-dumps"

Don't know but perhaps you have some luck.
Let me know.

Yes, I see you have the answer " not dumped".
But who knows perhaps it will pup up within some months !

Folly

I fixed the empty system lines and it now uses the retropie user string.

https://github.com/FollyMaddy/RetroPie-Share/commit/3fec0af846554ccd37d0d54bc41f2d1c98d347ff

Folly

@DTEAM @valerino

As a test-3, I added the option to install handhelds.

It's not directly the structure on how we want it in the future.
But I did this to see how the array's have to look if I want to make a choice on a description.
I also wanted to see if, perhaps, I could make things simpler.

It is not going very fast.
I will take a large amount of small steps to get it how we want it.

wget -q -nv -O /home/$(ls /home)/RetroPie-Setup/scriptmodules/supplementary/add-mamedev-systems.sh https://raw.githubusercontent.com/FollyMaddy/RetroPie-Share/main/00-workdir-00/add-mamedev-systems-test3.sh

Here you can see most changes of test-2 vs test-3 :
https://github.com/FollyMaddy/RetroPie-Share/commit/d48643325fc39c3bf808dadc0d5eeea9e5682740

Folly

@valerino

While making things in test3 i learned a bit more on how the array's are structured.
As you can see, it isn't a nice structure.
In the function choose_system_add() you will also see that all info read into $system_read will be inserted in both systems_read() and options().
So in this example, basically doubling the info, which will, presumably, take more time to execute.
Also injecting the numbers seems to be a bit odd, we already have the cell numbers in the array.
So it would also be nice if we could use those cell numbers, without injecting them again.
So I am trying to find a solution to this problem ( you can see how it is structured in this manual approach in function choose_dteam_add() ) :

local systems_read=( "ablmini" "alnattck" "gnw_ball" "jak_batm" "kbilly" "taddams" "rzbatfor" )
local options=( "0" "All in One Handheld and Plug and Play" "1" "Classic Handheld Systems" "2" "Game and Watch" "3" "JAKKS Pacific TV Games" "4" "Konami Handheld" "5" "Tiger Handheld Electronics" "6" "Tiger R-Zone" )
.
.
local choice=$("${cmd[@]}" "${options[@]}" 2>&1 >/dev/tty)

I want the arrays to be arranged like this :
(representation : converting it into a csv)
ROW1,ROW2
All in One Handheld and Plug and Play,ablmini
Classic Handheld Systems,alnattck

As you can see it's, right now it is arranged like this, so info doesn't match :
ROW1|ROW2
All in One Handheld and Plug and Play,1
Classic Handheld Systems,ablmini
Game and Watch,2

Perhaps too difficult, but it would be nice if we could extract into 2 dimensional array's or make fixed 2 dimensional array's.
Something like this :
https://stackoverflow.com/questions/16487258/how-to-declare-2d-array-in-bash
Then we would be able to link the information better, put all the extracted info into one 2-dimensional-array and have a better overview.

Hopefully you understand what I am talking about.

Do you have an idea ?

@DTEAM , Ofcourse, you are welcome to look at it too.
If you want some explanation about how basic array's work, just let me know.