MiSTer updater script
Moderators: Mug UK, Zorro 2, spiny, Greenious, Sorgelig, Moderator Team
Re: MiSTer updater script
Can the script be made to update USB storage?
Re: MiSTer updater script
Which is the structure of the directories/files on the USB?NML32 wrote:Can the script be made to update USB storage?
I think that editing BASE_PATH="/media/fat" variable could be the solution, even if this would break the Linux system update, but it's disabled by default. I think that I'll release a secondary, easy to edit script, but, in the meantime, please tell me if BASE_PATH variable solves the issue.
Thank you.
Best regards.
Locutus73
Re: MiSTer updater script
Thanks, I’ll give that a try when I get home.Locutus73 wrote:Which is the structure of the directories/files on the USB?NML32 wrote:Can the script be made to update USB storage?
I think that editing BASE_PATH="/media/fat" variable could be the solution, even if this would break the Linux system update, but it's disabled by default. I think that I'll release a secondary, easy to edit script, but, in the meantime, please tell me if BASE_PATH variable solves the issue.
Thank you.
Best regards.
Locutus73
Update: I updated path to BASE_PATH="/media/usb0" and it didn't work. I wonder if it has to do with MiSTer booting from SD card and switching to USB?
Re: MiSTer updater script
could the output of this script be made shorter to fit in the scripts menu output screen better?
Replay 2, Mister, FPGA Replay + 68060 Daughterboard
Re: MiSTer updater script
It must be shortened along with other implementations... next release.uigiflip wrote:could the output of this script be made shorter to fit in the scripts menu output screen better?
Regards.
Locutus73
Re: MiSTer updater script
Thank you for the debug session!NML32 wrote:Update: I updated path to BASE_PATH="/media/usb0" and it didn't work. I wonder if it has to do with MiSTer booting from SD card and switching to USB?
I think the culprit is script_pipe=popen(getFullPath(SelectedPath), "r"); in menu.cpp with getFullPath(SelectedPath) returning the full script path only when using the SD... I'll take a look at that.
Good catch, thank you again.
Regards.
Locutus73
Last edited by Locutus73 on Fri Dec 21, 2018 5:39 pm, edited 1 time in total.
Re: MiSTer updater script
Hi @Sorgelig , I don't mean to bother you, but what do you think about the idea of a short update.sh script I expressed here?
http://www.atari-forum.com/viewtopic.ph ... 25#p361331
I think it has the benefits of your ini file idea, plus it is a single file which can be duplicated many times with different settings and it always runs the last version of the actual updater code.
If you like this idea, I would proceed with it.
Thank you in advance.
Best regards.
Locutus73
http://www.atari-forum.com/viewtopic.ph ... 25#p361331
I think it has the benefits of your ini file idea, plus it is a single file which can be duplicated many times with different settings and it always runs the last version of the actual updater code.
If you like this idea, I would proceed with it.
Thank you in advance.
Best regards.
Locutus73
Re: MiSTer updater script
So you want to make a virus like script?Locutus73 wrote:Hi @Sorgelig , I don't mean to bother you, but what do you think about the idea of a short update.sh script I expressed here?
viewtopic.php?f=117&t=34898&start=25#p361331

I think at some point there won't be updates to the script long time when all bugs will be fixed and features implemented. Download it with every run - not sure if it's really needed.
But it's up to you.
-
- Atarian
- Posts: 6
- Joined: Wed Mar 14, 2018 5:53 pm
Re: MiSTer updater script
would be really nice to have some options...
- just update whats there
- update and download new cores
- ask core by core if you want new core
- just update whats there
- update and download new cores
- ask core by core if you want new core
Re: MiSTer updater script
This option is coming.Simongordon wrote:would be really nice to have some options...
- just update whats there
Obviously this is the same option above with a false valueSimongordon wrote:- update and download new cores
this would work just with SSH, not in the Script menu, unless implementing some input processing function which isn’t impossible, but I don’t know if it’s worth the hassle.Simongordon wrote:- ask core by core if you want new core
Regards.
Locutus73
Re: MiSTer updater script
Locutus73,
Thank you for your script. This is a real timesaver and keeping Mister up to date is now much easier. The Mister updates are numerous (thanks to Sorgelig and all the devs) and this is now so simple to grab the latest cores.
Thank you for your script. This is a real timesaver and keeping Mister up to date is now much easier. The Mister updates are numerous (thanks to Sorgelig and all the devs) and this is now so simple to grab the latest cores.
- SmokeMonster
- Atari nerd
- Posts: 46
- Joined: Wed Oct 03, 2018 2:26 pm
- Contact:
Re: MiSTer updater script
This is pretty incredible. Nice work on the script Locutus, and thanks for the scripts menu, Sorge 

Re: MiSTer updater script
I don't think it worth to have question on each core. As amount of cores close to 100, you won't like to have so many questions.
May be if Locutus73 will like then script may check for variable having either word "All" or list (delimited by space for example) of cores.
What i would like to see is option to remove datecode from the name upon update.
May be if Locutus73 will like then script may check for variable having either word "All" or list (delimited by space for example) of cores.
What i would like to see is option to remove datecode from the name upon update.
Re: MiSTer updater script
What may be worth to think is download new(or absent) cores into separate folder like "New".
In this case most users won't need to create their own lists of cores to update and new cores won't appear by themselves in the main folder.
New cores usually require some additional operations like creating new folder and add some games or bios roms. So, user will copy the core from New folder by himself if he would like. Otherwise can keep it there, so it won't clutter the main list.
In this case most users won't need to create their own lists of cores to update and new cores won't appear by themselves in the main folder.
New cores usually require some additional operations like creating new folder and add some games or bios roms. So, user will copy the core from New folder by himself if he would like. Otherwise can keep it there, so it won't clutter the main list.
Re: MiSTer updater script
New version released:
Version 1.3.5 - 2018.12.22 - Solved Atari 800XL/5200 and SharpMZ issues; replaced "reboot" with "reboot now"; shortened some of the script outputs.
Version 1.3.4 - 2018.12.22 - Shortened most of the script outputs in order to make them more friendly to the new MiSTer Script menu OSD; simplified missing directories creation (thanks frederic-mahe).
https://github.com/MiSTer-devel/Updater_script_MiSTer
@esmith13 sorry man, at first I misunderstood your Atari 800XL/5200 reporting, you were right and I was wrong; now the issue is fixed.
Regards.
Locutus73
Version 1.3.5 - 2018.12.22 - Solved Atari 800XL/5200 and SharpMZ issues; replaced "reboot" with "reboot now"; shortened some of the script outputs.
Version 1.3.4 - 2018.12.22 - Shortened most of the script outputs in order to make them more friendly to the new MiSTer Script menu OSD; simplified missing directories creation (thanks frederic-mahe).
https://github.com/MiSTer-devel/Updater_script_MiSTer
@esmith13 sorry man, at first I misunderstood your Atari 800XL/5200 reporting, you were right and I was wrong; now the issue is fixed.
Regards.
Locutus73
Re: MiSTer updater script
Regarding all the interesting ideas: for sure I will implement next a simple option like UPDATE_ONLY_INSTALLED_CORES=true/false that, if set to true, will update only cores on the SD, while if false will update/download all core like now.
Then there is much room of improvement to this simple implementation, let's see the different ideas.
- Variable set with "ALL" or a list of cores: I don't know, it can work, but I don't know if users would like editing the list for adding a new core... maybe.
- Directory called "NEW" for new cores when users don't want to automatically see new cores... why not? It's not a bad idea... should I treat the NEW directory like a secondary target directory with the scan for files and update routine? Consider that I will implement a log file too, so users could use that as a reference for knowing if there are new cores.
- Removing timecode option: it can be done but it needs some code refactoring because I use the local file timecode as a reference for determining if the core must be updated or not; i.e. for menu.rbf I keep both the timecoded file and the menu.rbf file. It's an option we should consider, but do users dislike the timecode? I mean, let's consider together if it's worth the hassle.
Please consider all this considerations just like me thinking out loud, I mean, they are not definitive, please debate them and share ideas.
Many thanks in advance.
Best regards.
Locutus73
Then there is much room of improvement to this simple implementation, let's see the different ideas.
- Variable set with "ALL" or a list of cores: I don't know, it can work, but I don't know if users would like editing the list for adding a new core... maybe.
- Directory called "NEW" for new cores when users don't want to automatically see new cores... why not? It's not a bad idea... should I treat the NEW directory like a secondary target directory with the scan for files and update routine? Consider that I will implement a log file too, so users could use that as a reference for knowing if there are new cores.
- Removing timecode option: it can be done but it needs some code refactoring because I use the local file timecode as a reference for determining if the core must be updated or not; i.e. for menu.rbf I keep both the timecoded file and the menu.rbf file. It's an option we should consider, but do users dislike the timecode? I mean, let's consider together if it's worth the hassle.
Please consider all this considerations just like me thinking out loud, I mean, they are not definitive, please debate them and share ideas.
Many thanks in advance.
Best regards.
Locutus73
Re: MiSTer updater script
The more I think about it, the more the "NEW_CORES" directory idea grows on me...
Locutus73
Locutus73
Re: MiSTer updater script
I can add an option to not display datecode.
Re: MiSTer updater script
Yeah, that too, but that should be an option; I mean, datecode is very useful for letting users reporting bugs/issues knowing what core build they are actually using.Sorgelig wrote:I can add an option to not display datecode.
Speaking of not displaying stuff... why don't you hide "System Volume Information" with the SCANO_DIR option?
And while we are at it, can you suggest something better than getFullPath(SelectedPath) for getting the full path of the selected script? I have to better investigate that, but I suspect that it's causing problems when users use an USB drive and choose a script from there.
Thank you in advance.
Regards.
Locutus73
Re: MiSTer updater script
this is correct way to get the full path.Locutus73 wrote:can you suggest something better than getFullPath(SelectedPath) for getting the full path of the selected script? I have to better investigate that, but I suspect that it's causing problems when users use an USB drive and choose a script from there.
USB is mounted to other folder than SD card. So your script should distinguish where it ran from.
I think the best way is to query the full path from inside the script using standard shell commands. If it run from USB, then update the USB only.
Re: MiSTer updater script
Probably I didn't express myself correctly, the problem isn't inside scripts, the problem is that the instruction script_pipe=popen(getFullPath(SelectedPath), "r"); seems to not finding the script when using USB so nothing is executed. I say "seems" because I didn't make some serious debug yet.Sorgelig wrote:this is correct way to get the full path.Locutus73 wrote:can you suggest something better than getFullPath(SelectedPath) for getting the full path of the selected script? I have to better investigate that, but I suspect that it's causing problems when users use an USB drive and choose a script from there.
USB is mounted to other folder than SD card. So your script should distinguish where it ran from.
I think the best way is to query the full path from inside the script using standard shell commands. If it run from USB, then update the USB only.
Regards.
Locutus73
Re: MiSTer updater script
Well, it's possible there is a bug. But it's not FPGA related, so you can debug it yourself. I'm busy by other things.
Re: MiSTer updater script
Sure, I’ll take a look.Sorgelig wrote:Well, it's possible there is a bug. But it's not FPGA related, so you can debug it yourself. I'm busy by other things.
Thanks
Locutus73
Re: MiSTer updater script
New updater release:
Version 1.3.6 - 2018.12.24 - Improved local file name parsing so that the script deletes and updates NES_20181113.rbf, but not NES_20181113_NN.rbf.
It doesn't delete nearest neighbour or whatever version with some string after the timestamp.
https://github.com/MiSTer-devel/Updater_script_MiSTer
Regards.
Locutus73
Version 1.3.6 - 2018.12.24 - Improved local file name parsing so that the script deletes and updates NES_20181113.rbf, but not NES_20181113_NN.rbf.
It doesn't delete nearest neighbour or whatever version with some string after the timestamp.
https://github.com/MiSTer-devel/Updater_script_MiSTer
Regards.
Locutus73
Re: MiSTer updater script
Hi Locutus73!
Now that we can use the script menu in the OSD, I think I will use your one-line command update trick to create a script file that will always download and use your latest updater. Since I use the default options, is this a safe way to launch the updater? Can the OSD menu launch a script that launch another script without problems?
Thanks.
Now that we can use the script menu in the OSD, I think I will use your one-line command update trick to create a script file that will always download and use your latest updater. Since I use the default options, is this a safe way to launch the updater? Can the OSD menu launch a script that launch another script without problems?
Thanks.