Unable to launch a PSX game using a command

[Waifu4Life]

So I've been working on a project with a PC launcher called Playnite. With the help of the MiSTer Scripts Remote and Tapto, I can launch my MiSTer games via my PC. Here's a video example for NES games: https://www.youtube.com/watch?v=AMr6OmZpFi8

I managed to launch every game from any consoles including consoles with optical media such as Saturn, PCE CD and Mega CD, but for some reason, PSX games won't launch, I just get a black screen. I think it may be a BIOS loading issue since the BIOS normally load when manually choosing a game via MiSTer, but I'm not sure.

Here's a command to load a Saturn game (which works):
curl --request GET --url http://192.168.2.100:7497/api/v1/launch/Games/Saturn/Bug!/Bug!.cue
Here's one for a PSX game (which does not work):
curl --request GET --url http://192.168.2.100:7497/api/v1/launch/Games/PSX/Bomberman/Bomberman.cue

Anyone has an idea of why it's not working with this system alone?

[birdybro]

@wizzomafizzo might know. You might need to launch it as an MGL instead with a delay, because the core needs to allow the BIOS to initiate. Also you can try it with the startup BIOS disabled.

[Waifu4Life]

@wizzomafizzo might know. You might need to launch it as an MGL instead with a delay, because the core needs to allow the BIOS to initiate. Also you can try it with the startup BIOS disabled.

Hi there, thank you for the reply. I'm already chatting with Wizzo on his discord. As for your BIOS suggestion, I can't see such a setting in the PSX core.

[wizzomafizzo]

@birdybro do you know if we have documentation available that can guide a user through viewing the main logs if they're not familiar with using SSH?

I have done some troubleshooting but we cannot get any generated MGL to work. I'm not sure yet but my hunch is this is a config issue with the PSX core not a specific script problem

This may be unrelated. But I actually quite frequently get reports that the PSX core mgl launching has stopped working. In every case before it "fixed itself" after running an update. Though I don't think there's ever been a psx core update during that whole period

[Waifu4Life]

@birdybro do you know if we have documentation available that can guide a user through viewing the main logs if they're not familiar with using SSH?

I have done some troubleshooting but we cannot get any generated MGL to work. I'm not sure yet but my hunch is this is a config issue with the PSX core not a specific script problem

This may be unrelated. But I actually quite frequently get reports that the PSX core mgl launching has stopped working. In every case before it "fixed itself" after running an update. Though I don't think there's ever been a psx core update during that whole period

Hi there,

Thank you for replying here, will be easier than on Discord. If it helps, here's some info regarding my setup.

1- I don't use any Update scripts, mainly because I don't want everything available on MiSTer. I only play Japanese game consoles/handhelds and a handful or Japanese arcade cores. When a core, Main MiSTer or Menu gets an update, I just download from my PC and transfer vis FTP.

2- The only scripts running on my MiSTer setup are: timzeone.sh, remote.sh, tapto.sh and because you asked to install it, favoties.sh.

3- Speaking of which, this is the resulting MGL file of adding a PSX game to favorite:
<mistergamedescription> <rbf>_All/_Console/PSX</rbf> <file delay="1" type="s" index="1" path="/media/fat/games/PSX/Bomberman/Bomberman.cue"/> </mistergamedescription>

4- I'm running: PSX_unstable_20240706_06d0f9.rbf and MiSTer_unstable_20240711_135204

Hope this helps

[birdybro]

Can you try to run the normal stable build instead? This core frequently can have marginal timing issues even when it meets timing in the unstable builds.

@birdybro do you know if we have documentation available that can guide a user through viewing the main logs if they're not familiar with using SSH?

I have done some troubleshooting but we cannot get any generated MGL to work. I'm not sure yet but my hunch is this is a config issue with the PSX core not a specific script problem

This may be unrelated. But I actually quite frequently get reports that the PSX core mgl launching has stopped working. In every case before it "fixed itself" after running an update. Though I don't think there's ever been a psx core update during that whole period

https://mister-devel.github.io/MkDocs_MiSTer/advanced/console/

Does increasing the delay in the MGL help?

[Waifu4Life]

Can you try to run the normal stable build instead? This core frequently can have marginal timing issues even when it meets timing in the unstable builds.

MiSTer, PSX or both?

[birdybro]

The stable PSX core.

[Waifu4Life]

The stable PSX core.

OK, so I replaced the unstable core for PSX_20240418.rbf, rebooted and now I am able to boot PSX games from Playnite. Mind you, Favorites.sh still won't boot any games. I personally don't plan to use this script, but if you guys want me to run some tests with it to help with your PSX MLG problem, I don't mind helping.

[birdybro]

Nice. Yeah the unstable builds can come with issues like that. When we do new releases of these kinds of cores that push the limits of the system we often run multiple seeds of builds for many hours to get one that has the "best quality of fit" and then test it for known marginal timing issues (issues with timing in the design that are not caught by timing analysis or that only occur "on the margins", roughly speaking).

[Waifu4Life]

Nice. Yeah the unstable builds can come with issues like that. When we do new releases of these kinds of cores that push the limits of the system we often run multiple seeds of builds for many hours to get one that has the "best quality of fit" and then test it for known marginal timing issues (issues with timing in the design that are not caught by timing analysis, roughly speaking).

Well, if I ever get issues with a core in the future, I'll try a stable version to see if it solves the issues.
Thanks again!

[wizzomafizzo]

Thanks @birdybro
I'll remember this if it comes up again!

[mainrs]

When we do new releases of these kinds of cores that push the limits of the system we often run multiple seeds of builds for many hours to get one that has the "best quality of fit"

What exactly does this mean? I thought FPGAs are programmed by describing the electric circuits that one wants to model. Does still still involve a complication step? And can said compilation step be seeded with different seeds, resulting in slightly different cores and therefore different performance per core?

I'm just trying to learn what hardware I'm using :)

[birdybro]

The rbf file is a binary that tells a chip on the fpga how to flash the FPGA with the correct logic.

Think of the FPGA in the DE10-Nano as sort of a really more complex chunk of memory which instead of the 1s and 0s being arranged in a simple array it's got them wired up in ways where they are now flip flops (digital logic building blocks).

The process of turning the hardware description language code into this binary is a compilation step, part of that takes into account what the target FPGA chip is and what it's particular architecture is.

The compiler has multiple steps, one of them is the fitting algorithm, this attempts to make the logic all fit while still achieving proper timing between each connected point. I believe it uses something similar to a simulated annealing algorithm - https://en.wikipedia.org/wiki/Simulated_annealing - so you pick a seed starting point, and it will pseudo-randomly place stuff and keep refining till it can achieve the desired outcome (if it can).

Another important step is timing analysis, how long it takes to get data from point a to point b. When you have a very large core that stresses the limits, you will often have multiple seeds that either fail to meet timing requirements or silently fail. Marginal timing issues in FPGA are sorta analogous to what is called "undefined behavior" in software development lingo. Marginal timing issues occur when you have signals not getting to the place on time but not in a way that the timing analysis done by the compiler can detect, so it says meeting timing is fine. It's "timing problems on the margins", so it's the kind of bugs that can rarely come up.

Compiling through multiple seeds and picking the "best quality of fit" (the IDE has a script that analyzes the timing analysis results and assigns a quality of fit number to it) can reduce the chance of marginal timing issues in cores that are pushing the FPGA to the limits. Going above 80-90% logic makes it a lot harder for the compiler to solve the traveling salesman problem.

It's kinda complicated and this is kind of a very surface level explanation all things considered.