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

Folly

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.

jamrom2

@folly I'll give those a try soon. Just working on finishing some data input for the Coco Theme

jamrom2

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

dragon64

Found it. It was a bug in MESS as suspected. Apparently it looks like it was fixed, but I don't see where it was implemented into MESS/MAME.

If it was, it didn't change anything as it's still happening. I'm presently running .235. This fix was from 2019, which was many versions before .235.

https://github.com/mamedev/mame/pull/4980

https://mametesters.org/view.php?id=7300

Folly

@jamrom2

I have read the links.
It's a lot of information and it looks like the comparison between original and emulated, NTSC vs PAL is constantly mixed in the discussions.
Very confusing but perhaps I have to read it again.

I did try the NTSC test on coco2, dragon32 and dragon 64 from this site :
https://mametesters.org/view.php?id=7300
You can just add it to mame as an autoboot line :

/opt/retropie/emulators/mame/mame dragon64 -autoboot_delay 3 -autoboot_command '10 PMODE4,1:SCREEN 1,1:PCLS1\\\n20 FOR I=0 to 3071:POKE 3072+I,85:NEXT I\\\n30 FOR I=3072 to 6143:POKE 3072+I,170:NEXT I\\\n40 GOTO 40\\\n'

On all machines it produces blue/orange.
Reading the information correct, for PAL, it should produce black and white.
So, at first sight, it seems, the pull request did not fix this.

I did also try the .bas file from "25A - Blending Colors in PAL.VDK" :
archive.worldofdragon.org/phpBB3/viewtopic.php?f=5&t=5462

Producing these colors on dragon32 seems to work ok.

It also states that programs perform differently between systems.
It makes me wonder, reading the information, if the games are written for NTSC only or for PAL only.
If some NTSC games, running on dragon are in black&white, and on a coco in color, then it would mean that the pull request fix is working.
But it would also means that the test in basic, described earlier, is not a good test or I use the wrong POKE as stated there (are you still with me ?) :

Please note that if you don't have the dos cartridge loaded, you have to change the "POKE 3072," instances to "POKE 1536,".

So I did :

/opt/retropie/emulators/mame/mame dragon64 -autoboot_delay 3 -autoboot_command '10 PMODE4,1:SCREEN 1,1:PCLS1\\\n20 FOR I=0 to 3071:POKE 1536+I,85:NEXT I\\\n30 FOR I=3072 to 6143:POKE 1536+I,170:NEXT I\\\n40 GOTO 40\\\n'

Then I get "gray lines".

It would make sense that you post this into the appropriate forum :
https://forums.bannister.org/ubbthreads.php?ubb=postlist&Board=1
That way people, with more knowledge, can take a look at it.