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

Folly

I have found neath way to push special characters trough the whole system so they will end up in the emulators.cfg as ascii hex-code and are accepted to be executed.

As explained earlier, some special characters can't be added the normal way with escaping the char with multiple \ .
This is because the csv lines are quoted with " and the delimiter , is used to separate the "cells", also an extra * delimiter is used within "cells" to create a virtual 3D "worksheet".
Above that, runcommand.sh has also a problem with " .
That is why some of these characters aren't accepted the normal way.

My solution enables us to add autoboot lines that contain * or " or , or other characters that are problematic.
Adding specials characters is possible using ascii hex-code, see examples :
" => \'\\\x22\'
* => \'\\\x2a\'
, => \'\\\x2c\'
(link to more codes : https://www.cyberciti.biz/faq/unix-linux-sed-ascii-control-codes-nonprintable/)

I think and hope it's a very stable solution.

So now we can work on adding some more working autoboot lines ;-)

Folly

@jamrom2

I updated the script with a few autoboot lines to test.
https://github.com/FollyMaddy/RetroPie-Share/blob/347031e45496394e547e53435f86ec3f9c9892ab/00-workdir-00/add-mamedev-systems-0237.sh

I added some that use special charachters :

2 for electron
1 for coco2
1 for coco3
1 for dragon32

The coco2/coco3/dragon32 lines are for -flop1 and do an autoboot with :
load"%BASENAME%",r or run"%BASENAME%"

Take for example pacman.zip the %BASENAME% generated in the runcommand loading process becomes pacman.
So initially I wanted to add .bas to that will create this load command :
load"pacman.bas",r
(with this file it worked OOB for me)
But working with dragon32 I saw that you can also run .bin files with the run command.
To make it more flexible and universal the best way, I think, is to add the full .bas or .bin filename to the .zip file.

Example (used with coco3/dragon32 and -flop1) :

filename is called : pacman.zip
filename on the disk : pacman.bas
rename pacman.zip to pacman.bas.zip
then the basename is : pacman.bas
the basename is then used in the autoboot command

So now we are very flexible as we can run .bas,.ldr or .bin or whatever runs with the command used for -flop1 :
run"%BASENAME%"
or
load""%BASENAME%",r

If the filename is compatible with above loading commands then we just have to check what filename is on the disk and rename the filename, that we are running with emulationstation.

Hope you understand how it works.

Happy testing :-)

Btw.
The names in the emulators.cfg still contain the ascii hex-code, for now there is no way around this.
and ...
I forgot this testline show konamih array !!! (I remove it later)
If entered, it loads the database and then waits for a user input. ( no crash, although you would think so !!!)
Typing, for example, @konamih , @tigerh (or something else) will output all the konmaih or all tigerh one by one and then return to the menu again.

jamrom2

@folly that's actually a really good idea as long as it's read that way by runcommand.sh.

Do you have to add any additional coding to the run command.sh file or does it just accept the ASCII code?

Folly

@jamrom2

It accepts it.
It just works out of the box.

What I just found is even better.
We are able to use symbolic links.
Here is an example for dragon32 :
Here I use the file balldozr.zip (from dragon_flop).
Running it in dragon32 and using "DIR" we see that we have to make sure we run balldoze.bin .
In order to get it working we could rename balldozr.zip to balldoze.bin.zip .
But we can also make a symbolic link to balldozr.zip, which is called balldoze.bin.zip .
That is perhaps even better as :

we keep the original file
we can make more links to one file if it contains more games on the disk
symbolic links don't use a lot of space
if we have gamelists with media we still can see this if we hover above the original file in emulationstation
we could just make a sub-directory just next to the original game that contain the symbolic links so it will be displayed, in emulationstation, just above each other.

You can make symbolic links quite easy in the terminal.
With this example the symbolic link comes in the same directory as the original file.

#go the directory where balldozr.zip is
cd /home/pi/RetroPie/roms/dragon32/dragon_flop
#make a symbolic link with the name balldoze.bin.zip
#the full path of the original file is necessary, that way we create a soft-link with full link information
#this link can then be copied to a sub-directory 
ln -s ~/RetroPie/roms/dragon32/dragon_flop/balldozr.zip balldoze.bin.zip

Now you just run balldoze.bin.zip with the installed run"%BASENAME%" autobootline of dragon32.

Folly

@jamrom2

I made a sub-directory balldozr-auto-run and copied the link to that directory.

pi@raspberrypi:~/RetroPie/roms/dragon32/dragon_flop $ find -name "ball*"
./balldozr-auto-run
./balldozr-auto-run/balldoze.bin.zip
./balldozr.zip

In emulationstation it will look like this (original file is bright, sub directory is normally gray and now highlighted):

Perhaps it goes to far for you but we can even automate it a bit, creating the sub-directories for all original files containing the symbolic links with the original filename, so we don't have to do it all manually.

pi@raspberrypi:~/RetroPie/roms/dragon32/dragon_flop $ cd /home/pi/RetroPie/roms/dragon32/dragon_flop
pi@raspberrypi:~/RetroPie/roms/dragon32/dragon_flop $ for zip in *.zip;do mkdir -p "$(basename $zip .zip)-auto-run";ln -s "$(pwd)/$zip" "$(pwd)/$(basename $zip .zip)-auto-run/$zip" ;done

After that we can run one by one and rename the soft-links one by one.

If we have done that, then we have data and it would also be possible to automate the whole process.

jamrom2

@folly ok... I haven't loaded this yet, but reading all this over a few times I think we can organize it much like the DOS games are.

Have you tried DOSbox_Staging? It's similar to what you are doing with this. What happenes is you put your actal games in another folder (I called mine DOS) and then all the config files in another that have an [autoexec] section in them that tells DosBox where to find the game file and how to run the game.

Maybe this can be the case with these as well. Is there a way to have a file sitting in the Dragon32 rom folder acting as a pointer. Much like you did with this, but not the actual game file. Maybe an *.sh file that MESS can read as the starting point. It then tells MESS where the game is to run and the command needed to run it.

I say this because it will be confusing to many to have to specifically name each game and to have subdirectories in the ROM folder.

Originally DosBox ran this way untl it was figured out that all that was needed was just a config file. ES then sees only the .cfg files and you can build your game list with graphics on that... keeping it clean and organized. Meanwhile... the game itself is in a completely hidden folder ES never sees.

jamrom2

So the "balldozer.bin.zip" would be in the main Dragon32 ROM folder as a link only. Pressing on that will point to the game that would be in a completely separate rom folder named "Dragon32game" or something like that... so the two are separated and ES will only use the link folder as the pointer.

jamrom2

/home/pi/RetroPie/roms/dragon_flop

Would be perfect for storing the actual games. ES does not have that as a theme folder and it's basically hidden from it.

Then the link can still be created from there, but placed in /home/pi/RetroPie/roms/dragon32. es_systems.cfg would not need to be adjusted either as it will read the .zip file... or whatever format we can use.

Folly

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

@folly ok... I haven't loaded this yet, but reading all this over a few times I think we can organize it much like the DOS games are.

Have you tried DOSbox_Staging? It's similar to what you are doing with this. What happenes is you put your actal games in another folder (I called mine DOS) and then all the config files in another that have an [autoexec] section in them that tells DosBox where to find the game file and how to run the game.

Maybe this can be the case with these as well. Is there a way to have a file sitting in the Dragon32 rom folder acting as a pointer. Much like you did with this, but not the actual game file. Maybe an *.sh file that MESS can read as the starting point. It then tells MESS where the game is to run and the command needed to run it.

I say this because it will be confusing to many to have to specifically name each game and to have subdirectories in the ROM folder.

I have used other DOSbox emulators, and I know you can make .conf files.
And indeed you push your original files outside the normal rom directory so emulationstation will not see them.
I had eXoDos which worked somewhat the same.

Well, the original file doesn't have to be in the normal rom folder.
As long as the link is ok and in the normal rom folder then it will be no problem.

Sub-directories aren't necessary too, but it helps to see where the .bas or .bin files belong to.
Otherwise it's getting a "mess".

With this, I think, it's not possible to make config files and it's not ideal to make .sh files either.
This is because we always have to run the game before we know what .bas or .bin we have to run.
Making a config file or .sh file will not change anything because always have to look first into the "disk" in order to know which file has to be run.

EDIT:
You have to remember, there are many other systems that can benefit from the autoboot option.
But not all game files are in the same format.
So theoretically, if we could make a script that would extract the filenames then it's for every system different making such a project so huge that it is impossible to make, I think.

Folly

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

So the "balldozer.bin.zip" would be in the main Dragon32 ROM folder as a link only. Pressing on that will point to the game that would be in a completely separate rom folder named "Dragon32game" or something like that... so the two are separated and ES will only use the link folder as the pointer.

Should work.

Folly

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

/home/pi/RetroPie/roms/dragon_flop

Would be perfect for storing the actual games. ES does not have that as a theme folder and it's basically hidden from it.

Then the link can still be created from there, but placed in /home/pi/RetroPie/roms/dragon32. es_systems.cfg would not need to be adjusted either as it will read the .zip file... or whatever format we can use.

You can store the original files in /home/pi/RetroPie/roms/dragon_flop if you want, should be no problem if the links are correct and in the normal rom directory.

There is no need to adjust es_systems.cfg. because it will see the link with .bas.zip or .bin.zip just as a .zip file.

I tested this and it should work OOB.

EDIT:
Remember you first have to place your original files in your desired folder.
After that you have to make the links.
After that you can't move your original files otherwise you get broken links.

jamrom2

@folly

Ok. Got it working for Dungeon Raid. I did the same as you, created the link in the \dragon32 folder to point at a separate folder in roms called \roms\dragon_flop.

It's a little tricky to figure out at first, but once the link is created, it's easy just to keep making them. Like you said, you need to first do a DIR to see exactly what the game name the the system actually sees. Has nothing to do with what the file is named in the zip folder.

It worked great with the new naming/runcommand option.

Odd thing I did notice... there is no artifiacting active in these games. I noticed it on a few of them even .cas based. I pulled up the MESS menu and artificating in active... but not displayed.

Folly

@jamrom2

Seems we are on the right track !

I don't know what artifacting is.
Never used it, I think.
I will have a look.

Edit :
I tried mame and lr-mess with and without autoboot runcommand and with and without links and original files.
I always can select artifact :

off
standard
reverse

Don't see any difference though ;-)
I don't think it has something to do with my script.

Do you have experience with "artifacting", and how it should affect the display ?

Folly

@DTEAM

Do you have experience with the "artifacting" setting ?

Btw.
I added some handheld/plug&play things in section 26 then (5-12).
I think you will like it.

https://github.com/FollyMaddy/RetroPie-Share/blob/e58a07b0e375c8cbe319a6c1fbf17808e97c8c72/00-workdir-00/add-mamedev-systems-0237.sh

If you want to test then it's probably best to backup the specific directories. ;-)
(or change the destiny directory, in the form, to a test directory !!!)
Some lines can take a while as you know how much is in there.
After the dl's, the ownership of the files are changed so it's best to not interrupt the process.
This is basically the same process as with the google-drive dl's.
We can just add more, later on, as it leans fully on the database, so it's quite easy now.

Btw. @jamrom2 you are free to test too !

DTEAM

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

Do you have experience with the "artifacting" setting ?

Unfortunately No.

See here for some tips like Test your games at lower settings and set a max FPS if possible

jamrom2

@dteam @Folly
So Artifacting was a term used to describe creating colors that didn't exist in old PC's. It was a way to make color graphics before VGA and RGB style monitors were around. In today's tech language, artifacting usually means a bad graphics card or something like that.

Here is a discussion on it over at the Atari Age forum using an actual Atari 800 computer. The A800/400/XL used artifacting especially in Hi-Res mode for games like Choplifter and A.E.

https://atariage.com/forums/topic/275882-atari-800-ntsc-artifacting/

Here is a thread with very good examples from rkoster on our forum. I helped him with this and he had me testing all kinds of stuff on the lr-atari800 emulator. But scroll down and you'll see the examples, especially U3 Exodus.

https://retropie.org.uk/forum/topic/22392/lr-atari800-5200-artifacting-basic-and-other-guidance

What I see in Mess in relation to Dragon32 is that it's not displaying the artifacting at all. So you get black and white lined graphics. They should be some form of color.

The MESS menu shows that the artifacting is active, but has no effect on the actual graphics.

Folly

@jamrom2

That is indeed very different than what I/we were thinking.

I found also a nice resource explaining what it is :
http://cocovga.com/documentation/artifact-emulation/

jamrom2

@folly

Definately an issue, but I don't see where it's coming from. East game to compare is to run Canyon Climber. Coco is displaying properly with colors and all, Dragon32 is not.

I wonder if the games have to be Dragon32 specific? I don't recall that being an issue between these two systems. The were interchangeable.

jamrom2

I think I might know what's causing this...

Dragon32 was for PAL format, while TRS-80 was NTSC. It might be that the games themselves are not triggering the artifiacting. I took the Balldozer game, which is for Dragon32 and tried it in the Coco2. It failed with a graphical error. Tells me the programs themselves might be machine specific.

Berserk works on both, but no artifiacting on the Dragon32. It's black and white only.

Folly

@jamrom2

I think it's also for NTSC only.
The NTSC composite signal VS the PAL composite signal is very different in how the colors are transmitted.
Could be a plausible reason.

Have you tried these ?, perhaps they work different :
Driver d64plus (Dragon 64 Plus): @non-arcade@computer
Driver dragon64 (Dragon 64): @non-arcade@computer
Driver dragon64h (Dragon 64 (HD6309E CPU)): @non-arcade@computer

EDIT :
Look into the slider controls.
Screen refresh 50Hz is for PAL
60Hz is for NTSC.
Try changing setting from 50 on 60.