UniPCemu using all SDL versions uses the SDL 1.2-compatible code to setup the window.
So if it crashes with fullscreenwindow enabled, somehow the SDL2 code can't handle the GPU acceleration or something like that?
It only uses the known compatible code and checks all variables returned from SDL1/2/3 for NULL values (from what I remember), so that should be OK.
Though it calls some extra SDL2/3 functions when enabling the fullscreen window option (basically telling SDL2/3 to scale the window to the desktop).
superfurywrote on 2025-02-22, 09:05:Perhaps it somehow fails setting up the GUI through SDL? But that shouldn't happen?
Or perhaps a SDL library issue? Can't verify […] Show full quote
peterfireflywrote on 2025-02-21, 18:42:The current directory when I launch it is writable.
Setting UNIPCEMU to that very same directory makes no difference (whether I […] Show full quote
superfurywrote on 2025-02-21, 16:34:That'd weird. I run it on SDL 2.30.9 / SDL_net 2.2.0 (on Windows 10) without any crashes there? Though that's on Windows 10/11 M […] Show full quote
That'd weird. I run it on SDL 2.30.9 / SDL_net 2.2.0 (on Windows 10) without any crashes there? Though that's on Windows 10/11 MSYS2/mingw64 builds...
Edit: Just checked Ubuntu 18.04.6. It runs fine there.
Can't check latest Ubuntu inside Virtualbox, as it crashes during the first boot (with the graphic driver complaining about being unable to run properly). I don't get any segmentation fault.
Perhaps you could set the UNIPCEMU environment variable and point to a writable location (the current directory isn't writable)?
The current directory when I launch it is writable.
Setting UNIPCEMU to that very same directory makes no difference (whether I add a trailing / or not). I still get a segmentation fault.
Maybe it doesn't like WSL2 -- but in that case it is still doing something wrong. GUI programs run fine under WSL2 unless they are buggy.
Perhaps it somehow fails setting up the GUI through SDL? But that shouldn't happen?
Or perhaps a SDL library issue? Can't verify with the latest Ubuntu (due to video driver issues on the latest versions). The GUI doesn't have different code inside UniPCemu accross platforms, so perhaps something else is causing it? Does it also happen without command line parameters or putting something else in there instead? So is it caused by the fullscreenwindow parameter itself or by parameter parsing in general?
Said parameter itself when matched will just set a flag to 1 to make the video layer initialization call some extra SDL functions to perform some automatic scaling. That's inside emu/gpu/gpu.c, inside the common emulator framework, function updateWindow.
It just performs an alternate path on the PSP (IS_PSP defined). All other code is used for all platforms.
It runs fine on my older Ubuntu installation, with and without the parameter.
Maybe a WSL+SDL2+scaling problem inside SDL2?
Maybe it doesn't like Wayland?
Dunno yet. I intend to set up VS Code properly for building and compiling the code and once that's done, it should be easy to track down the bug.
(I'll post the relevant files here so you can play with them, too. You've got debugging set up for Visual Studio and Windows targets, I believe, but not for Linux targets. Is that correct?)
superfurywrote on 2025-02-22, 09:05:Perhaps it somehow fails setting up the GUI through SDL? But that shouldn't happen?
Or perhaps a SDL library issue? Can't verify […] Show full quote
The current directory when I launch it is writable.
Setting UNIPCEMU to that very same directory makes no difference (whether I add a trailing / or not). I still get a segmentation fault.
Maybe it doesn't like WSL2 -- but in that case it is still doing something wrong. GUI programs run fine under WSL2 unless they are buggy.
Perhaps it somehow fails setting up the GUI through SDL? But that shouldn't happen?
Or perhaps a SDL library issue? Can't verify with the latest Ubuntu (due to video driver issues on the latest versions). The GUI doesn't have different code inside UniPCemu accross platforms, so perhaps something else is causing it? Does it also happen without command line parameters or putting something else in there instead? So is it caused by the fullscreenwindow parameter itself or by parameter parsing in general?
Said parameter itself when matched will just set a flag to 1 to make the video layer initialization call some extra SDL functions to perform some automatic scaling. That's inside emu/gpu/gpu.c, inside the common emulator framework, function updateWindow.
It just performs an alternate path on the PSP (IS_PSP defined). All other code is used for all platforms.
It runs fine on my older Ubuntu installation, with and without the parameter.
Maybe a WSL+SDL2+scaling problem inside SDL2?
Maybe it doesn't like Wayland?
Dunno yet. I intend to set up VS Code properly for building and compiling the code and once that's done, it should be easy to track down the bug.
(I'll post the relevant files here so you can play with them, too. You've got debugging set up for Visual Studio and Windows targets, I believe, but not for Linux targets. Is that correct?)
Only simple debugging is added using gdb. Simply replace the (re)build target with (re)debug.
There's also a (re)profile target, whose results are analyzed witn the analyze(2) target, which call gprof to analyze the profiler's results.
analyze(2) are depending on the profile target for ease of use.
The difference between analyze and analyze2 is that they dump to profiler.txt and profiler2.txt respectively for comparison purposes.
Of course, in all cases the output is at the ../../projects_build/UniPCemu folder.
The reason the build folder is outside (parallel to) the repository is to keep the source folders as clean as possible (when browsing using Windows Explorer etc.). It also eases finding a file using explorer etc.
Not sure if it helps, but on Linux I call SDL_CreateRenderer with SDL_RENDERER_SOFTWARE and SDL_RENDERER_ACCELERATED for all other platforms.
I also have code that checks the result of SDL_CreateRenderer and if that fails will try with SDL_RENDERER_SOFTWARE, but for Linux and NVidia drivers, that wasn't good enough.
superfurywrote on 2025-02-22, 09:05:Perhaps it somehow fails setting up the GUI through SDL? But that shouldn't happen?
Or perhaps a SDL library issue? Can't verify […] Show full quote
Perhaps it somehow fails setting up the GUI through SDL? But that shouldn't happen?
Or perhaps a SDL library issue? Can't verify with the latest Ubuntu (due to video driver issues on the latest versions). The GUI doesn't have different code inside UniPCemu accross platforms, so perhaps something else is causing it? Does it also happen without command line parameters or putting something else in there instead? So is it caused by the fullscreenwindow parameter itself or by parameter parsing in general?
Said parameter itself when matched will just set a flag to 1 to make the video layer initialization call some extra SDL functions to perform some automatic scaling. That's inside emu/gpu/gpu.c, inside the common emulator framework, function updateWindow.
It just performs an alternate path on the PSP (IS_PSP defined). All other code is used for all platforms.
It runs fine on my older Ubuntu installation, with and without the parameter.
Maybe a WSL+SDL2+scaling problem inside SDL2?
Maybe it doesn't like Wayland?
Dunno yet. I intend to set up VS Code properly for building and compiling the code and once that's done, it should be easy to track down the bug.
(I'll post the relevant files here so you can play with them, too. You've got debugging set up for Visual Studio and Windows targets, I believe, but not for Linux targets. Is that correct?)
Only simple debugging is added using gdb. Simply replace the (re)build target with (re)debug.
So you can only debug via gdb right now?
Sounds like there's a nice upgrade in your near future, then 😀
There's also a (re)profile target, whose results are analyzed witn the analyze(2) target, which call gprof to analyze the profiler's results.
'perf' on Linux is usually better. It has been supported under WSL2 for a couple of years (because the profiling counters are virtualized properly now) but the 'perf' command line program usually requires some manual work to get up and running.
analyze(2) are depending on the profile target for ease of use.
The difference between analyze and analyze2 is that they dump to profiler.txt and profiler2.txt respectively for comparison purposes.
Sounds good. I intend to a similar target for coverage analysis.
Have you tried gcc/clang's sanitizers? They are very useful, when combined with tests with good coverage.
Of course, in all cases the output is at the ../../projects_build/UniPCemu folder.
The reason the build folder is outside (parallel to) the repository is to keep the source folders as clean as possible (when browsing using Windows Explorer etc.). It also eases finding a file using explorer etc.
Put the build folder in the top-level directory in the repo (and exclude it from git with .gitignore).
Configure VS Code so it understands the include paths and the build targets (and options). That let's you compile (and run) from inside the editor. No need to launch via explorer.
Dunno yet. I intend to set up VS Code properly for building and compiling the code and once that's done, it should be easy to track down the bug.
(I'll post the relevant files here so you can play with them, too. You've got debugging set up for Visual Studio and Windows targets, I believe, but not for Linux targets. Is that correct?)
Only simple debugging is added using gdb. Simply replace the (re)build target with (re)debug.
So you can only debug via gdb right now?
Sounds like there's a nice upgrade in your near future, then 😀
There's also a (re)profile target, whose results are analyzed witn the analyze(2) target, which call gprof to analyze the profiler's results.
'perf' on Linux is usually better. It has been supported under WSL2 for a couple of years (because the profiling counters are virtualized properly now) but the 'perf' command line program usually requires some manual work to get up and running.
analyze(2) are depending on the profile target for ease of use.
The difference between analyze and analyze2 is that they dump to profiler.txt and profiler2.txt respectively for comparison purposes.
Sounds good. I intend to a similar target for coverage analysis.
Have you tried gcc/clang's sanitizers? They are very useful, when combined with tests with good coverage.
Of course, in all cases the output is at the ../../projects_build/UniPCemu folder.
The reason the build folder is outside (parallel to) the repository is to keep the source folders as clean as possible (when browsing using Windows Explorer etc.). It also eases finding a file using explorer etc.
Put the build folder in the top-level directory in the repo (and exclude it from git with .gitignore).
Configure VS Code so it understands the include paths and the build targets (and options). That let's you compile (and run) from inside the editor. No need to launch via explorer.
Well, one thing I sometimes need to do is reset stuff locally on the repository or fix some local issues I caused messing with commits.
If I then remove the repository, I'll also lose all files UniPCemu uses (disk images, settings.ini, soundfonts, ROMs, notes I made in text files, other data etc.). And Windows is dumb enough that it also blindly follows symbolic links when deleting it. So a symbolic link in the repo or putting it inside the repository is a big no in this case, as Windows will happily delete everything inside of it without ignoring symbolic links. That's why I actually setup all build systems (except Android Studio, where that's not possible) to put compiled files and EXE into a folder (projects_build with a subdirectory of the project name) and make it run from there instead, keeping the files I actively test with safe from being deleted.
Only simple debugging is added using gdb. Simply replace the (re)build target with (re)debug.
So you can only debug via gdb right now?
Sounds like there's a nice upgrade in your near future, then 😀
There's also a (re)profile target, whose results are analyzed witn the analyze(2) target, which call gprof to analyze the profiler's results.
'perf' on Linux is usually better. It has been supported under WSL2 for a couple of years (because the profiling counters are virtualized properly now) but the 'perf' command line program usually requires some manual work to get up and running.
analyze(2) are depending on the profile target for ease of use.
The difference between analyze and analyze2 is that they dump to profiler.txt and profiler2.txt respectively for comparison purposes.
Sounds good. I intend to a similar target for coverage analysis.
Have you tried gcc/clang's sanitizers? They are very useful, when combined with tests with good coverage.
Of course, in all cases the output is at the ../../projects_build/UniPCemu folder.
The reason the build folder is outside (parallel to) the repository is to keep the source folders as clean as possible (when browsing using Windows Explorer etc.). It also eases finding a file using explorer etc.
Put the build folder in the top-level directory in the repo (and exclude it from git with .gitignore).
Configure VS Code so it understands the include paths and the build targets (and options). That let's you compile (and run) from inside the editor. No need to launch via explorer.
Well, one thing I sometimes need to do is reset stuff locally on the repository or fix some local issues I caused messing with commits.
If I then remove the repository, I'll also lose all files UniPCemu uses (disk images, settings.ini, soundfonts, ROMs, notes I made in text files, other data etc.). And Windows is dumb enough that it also blindly follows symbolic links when deleting it. So a symbolic link in the repo or putting it inside the repository is a big no in this case, as Windows will happily delete everything inside of it without ignoring symbolic links. That's why I actually setup all build systems (except Android Studio, where that's not possible) to put compiled files and EXE into a folder (projects_build with a subdirectory of the project name) and make it run from there instead, keeping the files I actively test with safe from being deleted.
Your build directory doesn't have to be the current directory when you run the program.
Sounds like there's a nice upgrade in your near future, then 😀
'perf' on Linux is usually better. It has been supported under WSL2 for a couple of years (because the profiling counters are virtualized properly now) but the 'perf' command line program usually requires some manual work to get up and running.
Sounds good. I intend to a similar target for coverage analysis.
Have you tried gcc/clang's sanitizers? They are very useful, when combined with tests with good coverage.
Put the build folder in the top-level directory in the repo (and exclude it from git with .gitignore).
Configure VS Code so it understands the include paths and the build targets (and options). That let's you compile (and run) from inside the editor. No need to launch via explorer.
Well, one thing I sometimes need to do is reset stuff locally on the repository or fix some local issues I caused messing with commits.
If I then remove the repository, I'll also lose all files UniPCemu uses (disk images, settings.ini, soundfonts, ROMs, notes I made in text files, other data etc.). And Windows is dumb enough that it also blindly follows symbolic links when deleting it. So a symbolic link in the repo or putting it inside the repository is a big no in this case, as Windows will happily delete everything inside of it without ignoring symbolic links. That's why I actually setup all build systems (except Android Studio, where that's not possible) to put compiled files and EXE into a folder (projects_build with a subdirectory of the project name) and make it run from there instead, keeping the files I actively test with safe from being deleted.
Your build directory doesn't have to be the current directory when you run the program.
Well, the Makefiles just use two paths: the source code path (which is unmodified) and build path (where the executable and .o etc. files are put). You can of course modify the build path in the Makefile.linux file, it's basically a definition somewhere in there (it's the BUILD_DIR definition at the start of the Linux Makefile).
The default that's there now is:
1BUILD_DIR = ../../projects_build/$(BUILD_NAME)
BUILD_NAME comes from the Makefile.files file (in this case it's "UniPCemu" (without quotes)).
That's the default at least. It works that way on every platform Makefile that's in there. I could make it overridable by surrounding it with an ifneq to allow the user to override the build path. But that's the default build directory right now (since I work mainly on Windows, with Linux(Ubuntu) more for validation it still runs and for testing some network functionality (w/ linux-specific apps)).
Also, regarding the 'text being cut off', that doesn't really happen in your screen capture.
The buttons are literally 3 characters wide ("Sti" (being Sticky keys), "Set" (being Settings menu), "NCS" (Num lock, caps lock, scroll lock status) and the bottom right corner (with sometimes an extra indicator to the left of it) is displaying the current input mode ( "D" for direct input, "O" for PSP-style input using the keyboard, "K" or "M" or "G" for PSP-style keyboard/mouse/gaming input. There's even a special one for touch inputs to display that you're using lightpen inputs ("L" for lightpen active, "P" (to the left of "L") for lightpen pressed while active).
Although somehow the SDL2 render in fullscreen actually cuts off one character (8 pixels I think) and displaces the screen one character (8 pixels) to the right in fullscreen modes somehow.
That doesn't happen on SDL3, which uses code that's as close as possible.
Both are supposed to act like SDL3 (using letterboxing correctly), but SDL2 doesn't seem to do that correctly?
A 16:9 screen aspect (PSP) on 16:9 screen (1080p) screen somehow gets half a row at the bottom cut off from what I can see, on SDL2 at least? Although something else might be going on inside it (using 2.30.9 right now on SDL2).
Modified SDL2 to use the fullscreen window mode instead of exclusive fullscreen. That should fix the issue with part of the screen not rendering in fullscreen at least.
The existing parameter option still works the same, but minus Windows taskbar (just occupying the desktop).
And the normal windowed mode still exists too, when neither of the two is used (the default startup and non-fullscreen mode without the parameter).
Interestingly, SDL 1.2.15 seems to also have a weird fullscreen mode, although stretching everything to wide-screen? So for example 640x480 is stretched to fill a widescreen aspect ratio on my widescreen (16:9) monitor. But on that version, it can't be controlled afaik.
OK. Only a handful of instructions follow the 0F A8 that was last logged (the next length change isn't logged, so it crashes before that):
0F A8 PUSH GS (fixed instruction length)
0F A9 POP GS (fixed instruction length)
0F AA RSM (fixed instruction length)
0F AB BTS r/m16/32 (longer instruction length)
Since the BTS instruction is protected like all others, one of the earlier instructions must be the cause.
PUSH GS and POP GS are protected in the same was as BTS is, as it prevents any execution by faulting.
So the only cause can be the RSM instruction in this range.
Then I looked into the RSM instruction execution handler:
It's clearly visible what happens in this case, as it's not in SMM mode:
- It first checks the active step of the instruction. If it's running already, it's resumed at the nearest resume point. No problem here.
- It checks if the CPU is in System Management Mode. In the case of the sifter this isn't the case (unless it's actually interrupted by the SMM handler in some way, which would resume the sifting process properly).
-- It finds the CPU isn't in SMM. So it calls the #UD handling of the instruction.
-- Instead of aborting the instruction handling (and letting the #UD handling take over as intended), it continues onwards with the instruction execution.
- It lets the debugger and logger disassembler know the instruction name.
- It starts executing the RSM instruction. Of course this isn't supposed to happen when not in SMM mode, so the execution in (in this case) protected mode will effectively read VRAM values from the 'savestate map' that's supposed to be at it's address (the SMM protected memory area, which is in this case still locked down by the motherboard chipset). Since the area is locked down, it would read 0xFF bytes from the area. But since the SMM isn't actually active (the SMM pin isn't raised, since it isn't really in SMM), it starts reading from whatever is there. Since SMM isn't active and the video card has it's Video RAM mapping enabled (in this case at B8000-BFFFF, since it's in normal VGA text mode)), it starts reading it's CPU state from what it assumes is the SMRAM, which has the video card mapped onto it (or nothing if it's not mapped to the video card at the used addresses).
Of course this isn't supposed to happen, it's supposed to throw the #UD exception and abort the execution and disassembly of the instruction.
Just rolled out a bugfix in the git repository which fixed said issue.
That should (in theory) allow Baresifter to continue running properly.
Edit: And it does now. Instead of crashing at 0F AA, I now see:
118:30:40:69.07344: EXC 06 OK | 0F A6 218:30:40:70.05536: EXC 0E OK | 0F A8 318:30:40:71.07824: EXC 06 OK | 0F AA 418:30:40:71.07824: EXC 0E OK | 0F AB 00