In the next version I can also include a newlib build.
The SS (Sega Saturn) module requires 64 bit, so I noticed that this module has never been included. But, I did try to compile SS with 32 bit PPC and it does actually build. I tested a random ROM but it is very slow. The documentation even states that SS is in progress and requires a quad core processor. PSX also really requires a dual core and this is only just playable.
If liberty means anything at all, it means the right to tell people what they do not want to hear. George Orwell.
Even if slow Saturn will be pretty interesting to test :) Btw did you understand why iconification gadget doesn't appear at startup? Eventually I could open a report into the SDL tracker if you think it can be related to it
64*64 is too small. There is a limit that window must be at least 100*100 for iconification gadget to be added. I don't know what is the actual limit in the OS but if window is too small, it doesn't work.
The Italian documentation (README) will always be one version behind the English documentation. I am not sure how I feel about this, since otherwise I would have to rely on your input before updating a new version. If you are happy you can translate the following: "The Italian documentation is likely to be a revision behind the English documentation. You should also consult the English documentation".
@mufa
Thanks for the information wrt. a test-able ROM. I notice that CLIB2 on my X5020 does not seem to show any noticeable difference in terms of FPS CLIB2 1.186 version VS the previous 0.135 newlib version.
Perhaps I will upload a new version that will include: 1 - Fix to the minimise gadget (thank you Capehill) 2 - Inclusion of the SS module, despite it being ridiculously slow and requiring a quad core CPU 3 - Improvements to the English documentation which removes some redundant/false information and additions to other options to possibly improve performance.
If anyone is using 1.186 and seeing bad performance with PSX I would be interested to know because - for me - the PSX is playable. I did say before, though, that the X1000's performance is not so great at all.
If liberty means anything at all, it means the right to tell people what they do not want to hear. George Orwell.
Yes it's a good idea, i will add this on my current documentation. For now if you send me the latest readme you are working on i can update my readme according to your latest changes
Today I went to Mednafen to try it out, first of all this porting is really good and I am glad you did it even if the configuration is not very user friendly.
For me the focus was on the PSX emulation and I tested it, unfortunately I realized that it is terribly slow compared to the old port FPSE on Os4Depot.
I followed your instructions and also created a “psx.cfg” in the “.mednafen” directory, the config is also used this is the content I added to the config.
The compatibility with most PSX games is excellent and the old port FPSE can't even do this without errors. Is there anything else I can do to make the PSX emulation run faster via Mednafen?
Maybe we should all get together and port a current version of FPSE for AmigaOs4.1, or are we unfortunately no longer able to do this and simply lack capable developers?
Edited by Maijestro on 2024/12/29 19:56:07
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Is it slower because you are running it in window mode ? I always have in mind that full screen should be faster because only one screen needs to refresh whereas in window mode, mednafen AND workbench have to be refreshed slowing things down, but maybe I got it wrong ??
Thanks for the help, but lowering the resolution did not help. Switching from fixed mode to full screen does not make Mednafen or PSX emulation work any faster.
Driver: OpenGL
Display Mode: 1920 x 1080 x 24 bpp @ 60Hz (Window: 640 x 480)
Shader: none
Fullscreen: None
Special Scaler: None
Scanlines: Off
Destination Rectangle: X0, Y0, W640, H480
OpenGL Implementation: ptitSeb GL4ES wrapper 2.1 gl4es wrapper 1.1.5
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Yeah, I have never noticed a big difference between fs and window, perhaps a little.
BTW, I know the configuration is complex. It looks like you are creating a configure file first and then running thr PSX game. It may be that Mednafen overwrites it with default values, disregarding yours.
Don't know if it is in the documentation, but it is best to run a PSX game first, let Mednafen generate the configuration, then modify the rather large config.
Even with the period values, the sound is not perfect, but just noticed that the values I mention in the readme are the ones that worked best for me.
I will soon get around to rebuilding the whole thing with, what I believe, will be a much faster version of clib4, or try newlib again. Regardless, Mednafen is always going to be CPU intensive, as the owners concede themselves in their documentation.
Edited by rjd324 on 2024/12/29 1:36:59
If liberty means anything at all, it means the right to tell people what they do not want to hear. George Orwell.
BTW, I know the configuration is complex. It looks like you are creating a configure file first and then running thr PSX game. It may be that Mednafen overwrites it with default values, disregarding yours.
Don't know if it is in the documentation, but it is best to run a PSX game first, let Mednafen generate the configuration, then modify the rather large config.
That's right and that's how I did it, as I understand it the PSX.config serves as an additional configuration and Mednafen searches for it at startup I see it in the shell output. If this additional config is not found the default settings of Mednafen are used for the PSX emulation.
Quote:
Even with the period values, the sound is not perfect, but just noticed that the values I mention in the readme are the ones that worked best for me.
I will soon get around to rebuilding the whole thing with, what I believe, will be a much faster version of clib4, or try newlib again. Regardless, Mednafen is always going to be CPU intensive, as the owners concede themselves in their documentation.
It could of course also be a “frameskip” problem, which makes running the games seem slow, including bad sound. However, I have not been able to find this in the config. In old FPSE I have to set frameskip 3 for Tekken 3, otherwise there are also problems with the sound.
Perhaps even an X5000 is reaching its limits here, as the system requirements for Mednafen PSx Emulation are described in the documentation.
“A dual-core Phenom II or Athlon II with 3 GHz or higher, or a rough equivalent (in terms of single-core IPC), is recommended for the PlayStation 1 emulation of Mednafen (note that this recommendation does not apply to unofficial ports or forks, which may have higher CPU requirements). For better performance, the binary should be compiled for a 64-bit target (e.g. x86_64) and not 32-bit, if available."
Of course I am always open for tests, but even if Mednafen should run at an acceptable speed the next problem would be the input device configuration, just thinking about it makes my hair turn gray
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Right. The x5000 is not even at the limits for Mednafen, and yet I personally describe the PSX side of it to be "barely playable", which means it runs at the absolute minimum for me to enjoy playing my old PSX games, but if it was 1 fps slower, it wouldn't be worth it.
If liberty means anything at all, it means the right to tell people what they do not want to hear. George Orwell.