Development of module-script generator for lr-mess, lr-mame and mame standalone
-
I discovered that all coco types can have extra 1024 k ram added. (just like dragon 32)
Perhaps the coco1 will benefit from that, not having display errors.I will add some lines for coco/coco2/coco3 to test in the section :
- systems : with extra options
- systems : full/semi autoboot
edit : done
https://github.com/FollyMaddy/RetroPie-Share/commit/fdd150c6cf0106954646b1254ba1fdbc3be8beb0
-
@folly OK. Tested both the CLOAD manual RUN and CLOADM auto EXEC for Coco2.
Works great! Fine tuning this a little would be to have them all under the same folder coco2, and the options listed in the emulator selection box, so that you don't have to have separate rom folders for each variation.
Is that possible? If so, that would be the best way to cover this from a gamer point of view. I press a button, jump into the emulator selection menu. Select my default (lets say CLOADM auto EXEC for all machine based cassettes) and emulator for specific rom (let's say CRT for a cartridge I want to play), and off I go.
-
Also... the other variation are the OS/9 based games like Flight Simulator II. Those need to have coco in OS/9 mode which is a simple "DOS" typed command. Once the user does that, the game will auto load and play.
So you basically have 5 useable variations as choices for runcommand:
1.normal without any auto loading commands if the user actually wants to use the Coco Basic.
2. Cassette - CLOAD manual RUN - Basic driven cassette games
3. Cassette - CLOADM:EXEC auto EXEC - Machine language driven cassette games with auto exec comand
4. Cartridges - CRT just as it is...plays the cart
5. OS/9 based games - requires a simple "DOS" command at the prompt - autoloads the game itselfFloppy commands - can't be done as, like you pointed out, it uses double quotes. Must be manual input. This is ok as you have to DIR in order to see if its a BAS or BIN file for the correct LOAD command anyway. Old school fun!
-
@jamrom2 said in Development of module-script generator for lr-mess and mame standalone:
@folly OK. Tested both the CLOAD manual RUN and CLOADM auto EXEC for Coco2.
Works great! Fine tuning this a little would be to have them all under the same folder coco2, and the options listed in the emulator selection box, so that you don't have to have separate rom folders for each variation.
Is that possible? If so, that would be the best way to cover this from a gamer point of view. I press a button, jump into the emulator selection menu. Select my default (lets say CLOADM auto EXEC for all machine based cassettes) and emulator for specific rom (let's say CRT for a cartridge I want to play), and off I go.
Thanks for testing !
Yes that is possible.
I did it so we could copy the compatible games for each option.
But, indeed, having all separate rom directories isn't perhaps the best way.
It's off-course always possible to separate them inside the normal rom directory.
Oh yea, the themes don't match either.Come to think of it, overall, it will be an improvement.
Ok, I will change every option to the normal rom directories.Make sure you de-install the module-scripts from within the normal parts of the RetropPie-Setup (manage-packages-experimental-packages).
And I advice you to remove the old generated autoboot module-scripts and the old rom directories.https://github.com/FollyMaddy/RetroPie-Share/commit/fe7efedc915c509feaa32a9bf530b5811d37e2ff
-
Ok, sounds good. Looking forward to it.
-
You can test.
Took me a bit longer as I had a crash.
Above that, coco3 did not accept extra ram when the floppy controller is used.
It seems it's only possible to add one device in the slot.
But thedos os-9
autoboot works ! -
@folly happy to. Where is the script? same as above?
-
-
Just finished testing a bunch of different .Coco 2 cass and .ccc games. Works perfectly! Everything is in one list, and all that needs to be done is to select the correct version of the emulator to run the game.
The auto feature is perfect. Aside from the fact that "RUN" needs to be entered for BASIC built games. There is no input required. Very good! That's exactly what a gamer using Retropie wants... one click of a button and the game comes up.
You just game the Tandy and Dragon systems a whole new life!
-
Yes, some improvements, we did it again.
Yesterday I discovered some nice stuff.
With the next update it's possible to add, somewhat, multiple commands in the "comma separate menu lines".
That way it should be possible to add small multi command script lines within the menu lines without having to make separate functions.
Hopefully it will be useful ;-) -
@folly I'm looking forward to what masterful scripting you come up with next!
-
-
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 ;-)
-
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.shI 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%",rIf 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 testlineshow 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. - 2 for
-
@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?
-
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 fordragon32
:
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. -
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.
-
@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.
-
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.
-
/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.
-
@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.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.