Gamate BIOS downloader filename issue causing extraction errors

[movisman]

Hi there,

I just updated my MiSTer and noticed you added the Gamate BIOS in a very recent commit.

However when running the updater, you get this error when it tries to unzip the Gamate BIOS:

`##################################################################

STARTING BIOS RETRIVAL FOR: Gamate

Downloading https://archive.org/download/mister-console-bios-pack_theypsilon/MiSTer_Console_BIOS_PACK.zip/Gamate.zip Archive: /media/fat/BIOS/Gamate.zip

End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive. note: /media/fat/BIOS/Gamate.zip may be a plain executable, not an archive unzip: cannot find zipfile directory in one of /media/fat/BIOS/Gamate.zip or /media/fat/BIOS/Gamate.zip.zip, and cannot find /media/fat/BIOS/Gamate.zip.ZIP, period. cp: cannot stat '/media/fat/BIOS/Gamate/gamate_bios.rom': No such file or directory

################################################################## `

I had a quick look at the code and it looks like line 172 is trying to unzip 'gamate_bios.rom', but the filename inside the zip is 'gamate_boot.rom'.

Also, on line 170 it suggests it will rename the file boot.rom, but according to github page: https://github.com/MiSTer-devel/Gamate_MiSTer

I believe it should be boot0.rom?

Thanks a lot!

[theypsilon]

Hey, thanks for letting me now. I think it should be fixed now. Could you please confirm?

[movisman]

Hey, no worries at all! Unfortunately, from today I am on holiday so I won't be able to access my MiSTer to test anything until Friday 24th. Hopefully someone else may be able to confirm it now works in the meantime?

One thing - I see the filename still looks like it is being renamed to boot.rom - am I right in thinking this should be boot0.rom? https://github.com/MiSTer-devel/Gamate_MiSTer - seems to suggest so?

Thanks!

[theypsilon]

All good! No worries, for this one boot.rom is fine. If you experience the same problem when you are back, please reopen. Enjoy your vacation!

[movisman]

Great, no problem - will do! Thanks as always for your help.

[movisman]

Hi there!

I just had chance to run the update_all.sh script again, and actually I noticed that this time, the BIOS GETTER didn't run at all (it always has previously). No errors in the log. I was hoping it would run and pick up the Gamate BIOS.

Is it related to this recent commit? https://github.com/theypsilon/Update_All_MiSTer/commit/eaf22899cdc7d182ff51cc63784b7fa36acf22db

I do use the downloader script, and apart from enabling the downloading of JT Beta Cores, everything else is left as default. My update_all.ini is very minimal, and so the BIOS GETTER should run.

Any ideas?

Thanks!

[theypsilon]

Hey man. That's normal, BIOS GETTER is getting replaced by the Bios DB that it's probably already running in your setup. Check this post for more info: https://www.patreon.com/posts/bios-db-release-68197436?cid=86441540

[movisman]

Hey, thanks for coming back to me.

Ah I see, thanks for the heads up re: migrating to the BIOS DB.

Is there any evidence 'on screen' during update_all that the BIOS DB update is actually running, or is it meant to be invisible now? I don't see anything happening and there is nothing in the log.

The reason I ask, is my Gamate BIOS folder still isn't appearing in /media/fat/BIOS, and there is no boot.rom in /media/fat/games/Gamate. I'm not sure why the updater would not be picking this up, even after the move to the BIOS database method. I can see the file listed here: https://github.com/theypsilon/BiosDB_MiSTer/blob/main/bios_definitions.json

So in theory, if it doesn't exist on my file system, it should grab it, unless my local DB cache 'thinks' i've already got it, is that right?

I did clear out the /media/fat/Scripts/.config/downloader folder and ran update_all again, but it still didn't grab that Gamate BIOS.

Any ideas? Do you know if I need to clear anything else out?

Thanks!

[theypsilon]

Is normal that nothing shows up on BIOS folder, but boot.room should appear in games/Gamate for sure. Could you please share your Scripts/.config/downloader/downloader1.log?

[movisman]

Got it - so would the BIOS folder now be considered 'legacy' (eg. it can just be deleted) as it was only used by BIOS-GETTER? Will this folder eventually be cleaned up by the newer BIOS DB method (once it has been in production for a while) or will it always be down to the user to delete this folder?

Attached is a downloader1.log I ran for you just now. Only a few updates since yesterday to a couple of cores and a readme.md file.

When downloader runs via update_all i'm not seeing any evidence of any BIOS related activity/updates - not sure if the process is supposed to be totally invisible now though (to the user).

I have very little to no customisation configured with update_all, so if files need to be deleted, removed, changed, etc, i'm more than happy to do so.

Thanks!

downloader1.log

[theypsilon]

Hey, I've just pushed a fix for a bug that will solve this problem for you. Thanks a lot for sharing the log!

[movisman]

Hey, that's great thank you so much! And thanks for looking at this so quickly. To confirm, I can now see that the BIOS DB is queried when the downloader is run :) Also, it picked up the Gamate BIOS which was missing for me and placed it in the correct area.

However, one thing to note, on first run of querying BIOS DB it did give this message:

Not installed due to overwrite protection:
•bios_db: games/MegaCD/Europe/cd_bios.rom, games/MegaCD/Japan/cd_bios.rom, games/MegaCD/USA/cd_bios.rom

* Delete any protected file that you wish to install, and run this again.

I'm not sure why this would appear, as those files have the same file attributes as all of the other files.

So, I deleted the files, ran downloader again and it redownloaded the files. Now, on subsequent runs the above message does not appear.

Question from me is - initially, why would the downloader think there is overwrite protection on those files, even though they were set to 755 file attributes? Very minor issue, but I guess other people who have had the MegaCD BIOS in place for a while (mine were in place since 08/21) might get the same message. Easy fix of course but thought i'd mention it.

Final question, one I mentioned above which was just about the BIOS folder itself. Would the BIOS folder now be considered legacy / unused now, as it was only used by BIOS-GETTER? Will this folder eventually be cleaned up by the newer BIOS DB method (once it has been in production for a while) - or will it always be down to the user to delete this folder? I guess every MiSTer user who runs update_all will have the BIOS folder under /media/fat, but if it is now useless, i'm wondering if the DB script can clean this up. Or maybe that's not a good idea. Just a suggestion!

Thanks a lot!

[theypsilon]

I'm glad it worked!

About the BIOS folder, I think if I deleted it some people would complain, so I'd rather let that decision to the users. It's kind of useless, unless you like to use different bioses than the default ones, but it doesn't take much space anyways. In that BIOS folder there were some bioses that were never installed under games, but now in hindsight I realize almost nobody used them.

About the overwrite protection, is not about the filesystem. It's just that I handle bioses files in a different way. Some users use custom bioses and they would be pissed if I overwrite them automatically. So what I do instead is showing this message, so that if you want to install the bios I provide, you need to delete the one you currently have first. I only show that message when the bios currently present is different than the one I'm installing.

[movisman]

I'm glad it worked!

Yes, thank you so much!

About the BIOS folder, I think if I deleted it some people would complain, so I'd rather let that decision to the users. It's kind of useless, unless you like to use different bioses than the default ones, but it doesn't take much space anyways. In that BIOS folder there were some bioses that were never installed under games, but now in hindsight I realize almost nobody used them.

Got it and understood - this is what I thought your feeling about it would be, which makes sense. Some users might indeed complain. I just use the default BIOS files you provide as they all work great, so i'll just remove the folder from my filesystem as I like to keep it tidy where possible.

About the overwrite protection, is not about the filesystem. It's just that I handle bioses files in a different way. Some users use custom bioses and they would be pissed if I overwrite them automatically. So what I do instead is showing this message, so that if you want to install the bios I provide, you need to delete the one you currently have first. I only show that message when the bios currently present is different than the one I'm installing.

Right, that makes total sense - I forget about users who might use custom BIOS files. Thanks for explaining. So in my case, even though those BIOS files I mention above were originally provided by update_all (or rather, BIOS-GETTER) back in August last year when I reinstalled my MiSTer - the files in the DB have been updated or changed by yourself since then (or at least the hash/size is technically different), hence why I received that message. So if I want to 'keep up to date' with BIOS files (which is my preferred option), I just need to delete files the updater flags as protected during update, and then re-run the script.

I'm one of those users who, while I like to tinker with my MiSTer.ini file and a few other files, is happy for BIOS files, old MAME/HBMAME files, orphan/legacy folders etc to be overwritten / updated / cleaned up by the updater. I am probably in the minority there though 😂

Thanks again!