beetle-psx-libretro
beetle-psx-libretro copied to clipboard
libretro
Add support to optimised Bios?
Can you, add support for this bios? https://forums.libretro.com/t/psx-bios-from-psp-6-60-optimised-to-play-games-more-smoothly-but-how/16976
Bumping this. All of the ps1 cores could use this as either a fallback or a 'first try this' replacement of the original bioses, since this one is also region free. Currently i don't know if it would work even if you copied it thrice and renamed it to the regions names of the others (because crc).
i don't know if it would work even if you copied it thrice and renamed it to the regions names of the others (because crc).
From the perspective of the libretro core initialization, the renaming strategy it will "work". You'll simply get a warning on the log about unexpected SHA1 values - (https://github.com/libretro/beetle-psx-libretro/blob/master/libretro.cpp#L190-L199).
From the perspective of the core running, it may "work" most of the times. Specifically, there's a function called MemPoke which can write to the BIOS (https://github.com/libretro/beetle-psx-libretro/blob/master/libretro.cpp#L1138-L1146).
It's not clear to me if a non-debug build can ever call it but the point is: if the BIOS files differ significantly in the addresses where mednafen wants to write on, that could cause problems.
@rz5 I've been using aforementioned bios for some time (about 2 months), no problems so far, but given the size of ps1 library my experience is statistically irrelevant. I havrn't had the need to run debug cores yet, so can't tell if there are any issues with that. I've been using the following patch to always force "optimised" bios which I renamed to scph6600.bin:
diff --git a/libretro.cpp b/libretro.cpp
index 5c4c3d2..3ba01a6 100644
--- a/libretro.cpp
+++ b/libretro.cpp
@@ -114,6 +114,7 @@ static bool firmware_is_present(unsigned region)
/* SHA1 and alternate BIOS names sourced from
https://github.com/mamedev/mame/blob/master/src/mame/drivers/psx.cpp */
+ /*
if (region == REGION_JP)
{
bios_name_list[0] = "scph5500.bin";
@@ -155,7 +156,18 @@ static bool firmware_is_present(unsigned region)
bios_name_list[8] = NULL;
bios_name_list[9] = NULL;
bios_sha1 = "F6BC2D1F5EB6593DE7D089C425AC681D6FFFD3F0";
- }
+ }*/
+ bios_name_list[0] = "scph6600.bin";
+ bios_name_list[1] = NULL;
+ bios_name_list[2] = NULL;
+ bios_name_list[3] = NULL;
+ bios_name_list[4] = NULL;
+ bios_name_list[5] = NULL;
+ bios_name_list[6] = NULL;
+ bios_name_list[7] = NULL;
+ bios_name_list[8] = NULL;
+ bios_name_list[9] = NULL;
+ bios_sha1 = "96880D1CA92A016FF054BE5159BB06FE03CB4E14";
bool found = false;
size_t i;
@@ -2345,9 +2357,9 @@ static MDFNSetting PSXSettings[] =
{ "psx.region_autodetect", MDFNSF_EMU_STATE | MDFNSF_UNTRUSTED_SAFE, "Attempt to auto-detect region of game.", NULL, MDFNST_BOOL, "1" },
{ "psx.region_default", MDFNSF_EMU_STATE | MDFNSF_UNTRUSTED_SAFE, "Default region to use.", "Used if region autodetection fails or is disabled.", MDFNST_ENUM, "jp", NULL, NULL, NULL, NULL, Region_List },
- { "psx.bios_jp", MDFNSF_EMU_STATE, "Path to the Japan SCPH-5500 ROM BIOS", NULL, MDFNST_STRING, "scph5500.bin" },
- { "psx.bios_na", MDFNSF_EMU_STATE, "Path to the North America SCPH-5501 ROM BIOS", "SHA1 0555c6fae8906f3f09baf5988f00e55f88e9f30b", MDFNST_STRING, "scph5501.bin" },
- { "psx.bios_eu", MDFNSF_EMU_STATE, "Path to the Europe SCPH-5502 ROM BIOS", NULL, MDFNST_STRING, "scph5502.bin" },
+ { "psx.bios_jp", MDFNSF_EMU_STATE, "Path to the PSX ROM BIOS", "SHA1 96880d1ca92a016ff054be5159bb06fe03cb4e14", MDFNST_STRING, "scph6600.bin" },
+ { "psx.bios_na", MDFNSF_EMU_STATE, "Path to the PSX ROM BIOS", "SHA1 96880d1ca92a016ff054be5159bb06fe03cb4e14", MDFNST_STRING, "scph6600.bin" },
+ { "psx.bios_eu", MDFNSF_EMU_STATE, "Path to the PSX ROM BIOS", "SHA1 96880d1ca92a016ff054be5159bb06fe03cb4e14", MDFNST_STRING, "scph6600.bin" },
{ "psx.spu.resamp_quality", MDFNSF_NOFLAGS, "SPU output resampler quality.",
"0 is lowest quality and CPU usage, 10 is highest quality and CPU usage. The resampler that this setting refers to is used for converting from 44.1KHz to the sampling rate of the host audio device Mednafen is using. Changing Mednafen's output rate, via the \"sound.rate\" setting, to \"44100\" will bypass the resampler, which will decrease CPU usage by Mednafen, and can increase or decrease audio quality, depending on various operating system and hardware factors.", MDFNST_UINT, "5", "0", "10" },
diff --git a/mednafen/settings.cpp b/mednafen/settings.cpp
index 39b7f49..f649caf 100644
--- a/mednafen/settings.cpp
+++ b/mednafen/settings.cpp
@@ -111,11 +111,11 @@ bool MDFN_GetSettingB(const char *name)
std::string MDFN_GetSettingS(const char *name)
{
if (!strcmp("psx.bios_eu", name))
- return std::string("scph5502.bin");
+ return std::string("scph6600.bin");
if (!strcmp("psx.bios_jp", name))
- return std::string("scph5500.bin");
+ return std::string("scph6600.bin");
if (!strcmp("psx.bios_na", name))
- return std::string("scph5501.bin");
+ return std::string("scph6600.bin");
if (!strcmp("psx.region_default", name)) /* make configurable */
return "na";
/* FILESYS */
@asavah - Thanks for sharing the results. So it does seem to not fail catastrophically, good.
In regards to "adding support" to said BIOS...if people aren't satisfied with the renaming workaround then some questions need to be answered before support is to be considered:
Do all versions of pops (Sony's PSX emulator for the PSP) have the same BIOS? If not, pick only one. What is its SHA1 value?
What should the file name be called? asavah called his dump scph6600.bin but I assume that's inspired by his PSP firmware version. Perhaps this should be discussed with other PSX developers so a name can be chosen by convention.
As for it being first choice vs fallback, on beetle-psx I vote for it to be a fallback. The upstream project was developed around specific firmware versions and its documentation does state that working around it will "likely cause emulation glitches", so that's one reason. Another reason is IMO users who favor compatibility and accuracy pick this core over pcsx-reARMed, which implies using the 'slower' firmware sourced from actual non-slim PlayStations.
I attempted to add this to pcsx_rearmed: https://github.com/libretro/pcsx_rearmed/pull/339
works for me!
I think mednafen/beetle will take a bit more work since it's apparently not as cavalier about regions and defaults. Which in practice means that in Retroarch people that want to use this should just delete, move or rename their old psx bios and drop this one, because otherwise beetle will (probably) just use them instead, if the fallback approach is used.
BTW there is also upstream.
https://github.com/notaz/pcsx_rearmed
not sure if it has libretro capabilities.
For those who can compile, checkout the r5/pops-bios-support branch and test. (https://github.com/libretro/beetle-psx-libretro/tree/r5/pops-bios-support).
It's fallback detection, so it'll only try to detect psxonpsp660/PSXONPSP660.bin if it fails to detect the appropriate region-specific bios files first.
Check if there is no problem with the skip bios option too, since this version has no playstation splash screen.
@i30817 I can confirm that the skip bios option also works with this BIOS. This doesn't have the Sony screen but it does have the PS logo screen.
Would be interesting to test this with 'skip bios' turned off and testing a libcrypt game to see if nothing is wrong.
Did you ever figure out if the writepoke function wrote to the same locations on this bios?
@i30817 - Haven't figured it out, no. That would require me re-enabling what seems to be mednafen debug code which, like I wrote before, doesn't seem to be called during normal gameplay.
With gdb, I set breakpoints at that specific function and on all instances where BIOSROM->Write is called. Also set a watchpoint on BIOSROM itself to break execution if it's ever written and played a couple of games.
Neither the breakpoints nor the watchpoint ever stopped the core, so I suppose it's all good.
I've also stumbled upon Nocash's notes (https://problemkaputt.de/psx-spx.htm#biospatches) on BIOS patches present in several commercial games. I don't know how this BIOS, those patches and these games all interact, if it can constitute a problem or not. I've tested Pandemonium 2 and it seemed fine.
The document seems to imply it's common, which makes me wary and at the same time puzzled, if the 'writepoke' function isn't used. Is there a different 'kernel' to patch than the bios? Or is mednafen using another function to patch as in-memory copy of the bios and that 'writepoke' was just for testing writing to the actual file-bios a long time ago?
Or maybe mednafen does what No$ suggests and spoof the patches upload functions and replace the patches by HLE that doesn't interfere with it and is compatible with bios replacements. That would be sane but considering the mednafen authors ideas about 'accuracy' i find myself a bit doubtful.
Maybe the patches are so common that the PSP ps1 bios already deals with them somehow for compatibility.
If I'm understanding it correctly, it's not that the games themselves altered the BIOS (since it's read-only, even though beetle-psx writes to it to skip the BIOS splashscreens).
What games actually do is alter jump tables, which I assume are stored in RAM and filled by the BIOS when the system boots up. These jump tables contain addresses to functions inside the BIOS; by changing the table, you can change which function gets called.
So if a game starts out by storing a BIOS function replacement in RAM and changing the jump table's entry that corresponds to that BIOS function such that it now points to the replacement, you effectively patched that function for the duration of the game.
If what I wrote above is true, then this new fancy BIOS shouldn't be a problem.
@i30817 - Nothing in particular. I feel it should be discussed some more by others.
Topics of discussion can be changing the way we detect BIOS files to match how pcsx-reARMed does it.
On beetle-psx we have a lists of expected file names; for a specific game region, we have a matching filename list.
Then we do a loop through the list - on each iteration, we put the system directory one of the filenames, then we check if that file actually exists. If it does, we're done looping.
If no matches were found, then detect the fallback BIOS. A limitation of this approach is that filenames are case-sensitive. And I only try to detect filenames which are either all lowercase, all upper or all upper with a hyphen. So it currently wouldn't detect e.g. Scph-5001.bin.
On pcsx-reARMed, what happens is that, by usage of dirent.h functions, we have a way to 'open' the system directory, get one filename that actually exists at a time and compare it ignoring case to a list of expected filenames.
The way pcsx does it seems better to me as it is simpler, but I am unaware of how portable the dirent.h functions are. I know libretro-common offers it.
Another thing I'd like to push is for these BIOS files be inside system/psx instead just inside system with the rest of my other 20 files. But a small organizational change like that would make all users who update the core see the missing firmware error message...
So, in short, I'd like to hear more thoughts from people who care about this.
Maybe ask around wherever other RA devs hang around, they can't all be monitoring this repo.
Anyway, my amateur, non-coding opinion on those issues is that they're orthogonal to the speedier bios and thus as a barbarian user and can say 'plz merge' and suggest design and maybe PR other ideas later.
Choosing which bios as preference over others is the only issue i'd call 'nice to have consensus' in the terms of libretro, so pecularities of bios organization on the filesystem don't blindside the user with inconsistency on the bios used across cores. This will almost certainly be decided with the non-risky approach of 'the new bios is the fallback', so if any, maybe it's PRs on reARMed that need to be opened if it doesn't follow that idea.
On beetle-psx we have a lists of expected file names; for a specific game region, we have a matching filename list. Then we do a loop through the list - on each iteration, we put the system directory one of the filenames, then we check if that file actually exists. If it does, we're done looping.
IMO it would be good enough to stick PSXONPSP660.BIN at the top of this loop. i think if the user has sort out the PSXONPSP660.BIN bios, then they almost certainly want to use it ahead of any others they have in that directory. this is also how libretro's fork of pcsx_rearmed does it, IIRC https://github.com/libretro/pcsx_rearmed/pull/339/files
@rz5 In rustation I just open the system_directory as returned by the frontend, iterate over all the files, stat them to see if they have the correct size of exactly 512kB and then sha256-them to match them against an internal database of known BIOSes. This way I'm not tied to a particular filename.
Has this news BIOS been dumped for all regions or just NA? Because obviously you need a different BIOS for different regions (JP, NA and EU).
Has this new BIOS been dumped for all regions or just NA? Because obviously you need a different BIOS for different regions (JP, NA and EU).
it's region free :) i don't know if that means that PSPs from all region have the same POPS BIOS in the 660 firmware... i guess so.
@dankcushions
IMO it would be good enough to stick PSXONPSP660.BIN at the top of this loop. i think if the user has sort out the PSXONPSP660.BIN bios, then they almost certainly want to use it ahead of any others they have in that directory.
This is very close to bikeshedding territory but I'm not so sure honestly. In my experience people tend to download BIOS packs from random places and stuff them in their system directory without further understanding. I think it's probably safer to use mednafen's "officially supported" BIOS first if it's available, as it's the one that's properly tested and known to work. Especially if this newer BIOS messes with timings in order to run games faster, it would require very extensive testing to figure out how compatible it really is.
I don't feel super strongly about it though. And I'm not really sure how you'd easily override the default as a user if you really wanted to use this BIOS instead of the default without moving files around.
it's region free :) i don't know if that means that PSPs from all region have the same POPS BIOS in the 660 firmware... i guess so.
Oh, that's actually nice. I assume it detects the region of the game and a dapts to that. I had never considered that. It would be cool to have an open source generic BIOS replacement, if somebody is looking for a side project...
sure, i don't really care as I would delete the BIOS' i didn't want :) i don't feel that strongly and your arguments about the known-quantity official BIOS' are good. happy for it to be the last one in the list/fallback, as long as it's supported :)
It would be cool to have an open source generic BIOS replacement, if somebody is looking for a side project...
pcsx_rearmed/loaded has a good attempt, as of late: https://github.com/notaz/pcsx_rearmed/pull/137. i guess it's one of those things where if it doesn't work 100% of the time, you almost don't want to surface it to users, for want of avoiding bug report noise.
Has anyone considered the prospect of just having a core option to use the PSX on PSP bios if present? Personally I'd rather be able to keep it present but only activate it for specific games. That way games that -don't- work correctly with it aren't affected (such as Bushido Blade). Since the bios is region free, it can just be a single filename (presumably psxonpsp660.bin) and a single toggle for the core option. If you want to future-proof it, there's always the possibility people will want to be able to use others in a similar fashion in the future (nocash, ps3, the open bios, etc, all of which are region free), at which point the toggle becomes a selection. Still seems like the only universally beneficial approach.
is there a source for bushido blade (or another other) issues with the PSP BIOS? i can find references online for it running on PSP: https://wololo.net/talk/viewtopic.php?t=3888
It's easy to test: boot the game, go to "Movie" menu and launch the "Demo" FMV, you'll get a black screen with the PSP BIOS.
@Sanaki this adds an option to override the BIOS with either psxonpsp660.bin or ps1_rom.bin when enabled, and falls back to the region specific ones if the selected region-free BIOS is not found.
Seems to work perfectly. Thank you. Though oddly enough the demo FMV mentioned does play on it for me. Checked strace though, and it definitely -is- using the PSP bios, so not sure what setting made the difference there.
The core option works fine (at least with the PSP BIOS, haven't tried with the PS3 one yet), thanks for this 👍
Not a fan of the "it can improve performances" in the description as I've still never seen any proof of that. I've compared a few 30 and 60fps games with slowdowns and no matter if I used scph5501 or psxonpsp660, they had the same slowdowns at the same spots, etc. Internal FPS or not (while fast-forwarding), same results.
Though oddly enough the demo FMV mentioned does play on it for me.
Strange yeah, still showing a black screen for me with the PSP BIOS, tried with and without HAVE_HW=1 🤔 Maybe a Windows only issue?
Guess that's fair enough. Changed the description accordingly.
Also have the same black screen using the PSP BIOS with Bushido Blade using Windows 10.