Release PCSX ReARMed r22 - now using the DSP


It appears it likely had to to with invalid files (rtf and txt) in bios/ causing that bug.


The bug was persistently kept once it occured and a pcsx.cfg existed, where it likely caused some corruption/exception. If a pcsx.cfg file got written written (even if you made no changes to the defaults but just issued "Save global config"), and the bug occurred, the controls remained broken (except directional-keys and lower shoulder buttons mapped to "Q" and "P") from then on, regardless whether subsequent launches were in Pandafe or XFCE.


I left my entire appdata folder as is, just removed the foreign files from bios/ and erased pcsx.cfg to get a fresh one.


Subsequently I made config changes (BIOS to PS1-SCPH101), and in game switched to double resolution), and between each saved alteration launched PCSX both from Pandafe and XFCE, but could not reproduce it again. Then also changed controls (set Port 1 and 2 device to Analog SCPH-1150). Still could not reproduce it. I may also had other modifications. But I did not want to try on and on.


Most likely it was the foreign files within bios/


Another hot guess: I once had the experimental toggle "Nubs as keys" on, rescanned and saved the config. Maybe this was the cause?


I also remembered that in the controls assignment the gpio-keys did not show up properly as (A) ( B) (X) (Y) but the OS native keys Home, PageUp, End, PageDown (order mentioned arbitrarily! cannot recall real order now). Once this happened, all key hints always showed up as the native system names, not the Pandora specific key names.


That is as far as I can speculate about the reasons for the bug.


One further very specific mod I had: In addition to the Pandora keys I once had two external controllers configured as additional inputs.


Possibly also was some legacy.


But so far "foreign files in bios/" or "Nubs as keys" seems most probable to me.
 
Last edited by a moderator:
After removing the foreign files from bios/ pndrun obviously doesn't throw the bad BIOS file: errors anymore, but also the input: bad key: errors vanished!

Still possible that it was the external controllers legacy, but the immediate closeness of the 2 forementioned error lines makes me guess the input errors stem from the bios error, possibly an exception, which has not been dealt with. The developers being aware of their code probably now have enough reporting to figure it out, if enthusiastic, or ignore it, as the one rare user which encountered it, now solved it, and documented so publicly ;-)
 
Last edited by a moderator:
I'd appreciate an authoritative answer, what (likely) caused my observed bug, as I only concluded from my limited given knowledge. Thanks.
 
I've checked the BIOS load code and failed to see a way for bad files to cause any side effects there.

I've also checked your config file from the old report, it looks like it wasn't correctly generated for whatever reason. Noticed there was some wrong behavior when loading that file in current version, so added it to my TODO list for the next version, already forgot what was wrong there by now. That's all I have to say about this issue for now.
 
1) So if bad BIOS files can cause no side effects, it must have been

2a) the two identical external controllers (Logitech Wireless Rumblepad 2), or

2b) that I once activated "nubs as buttons", rescanned, then saved as global control config.

If you look at your code, are 2ab possible troublemakers?

3) Ad "corrupted config file". Never touched it by hand, must have originated from the app itself. (Possible from 2ab). As noted, from a certain moment on, gpio-keys in the controller assignment screens were shown with the general purpose keyboard names, and not the Pandora specific key names.
 
Last edited by a moderator:
2ab sound like the most likely, but I don't have time to work on this right now.
 
Last edited by a moderator:
^  Thanks for this response as it takes my "community responsibility" of my shoulders.

From my side this issue is now both sufficiently reported and responded to. Thanks!

The developer has every possible cause & evidence available now,

and if time, need & will gets available, will deal with it accordingly, I guess ;-)
 
Last edited by a moderator:
Runnig "Need for Speed 3" with r21 I get a crash to desktop on SZ 1.71

Last time I ran "Need for Speed 3" was with r19 on SZ 1.55 without any major issues. As soon as I have some time I will have a closer look - more testing, turning SPU DSP off and such.
 
@ekianjo Yea, it's a nice read. Thank you so much for all your hard work on pandoralive.info. Many good articels.
 
I second that. Really in-depth and well researched/written article. Thanks to you and Notaz for putting in the leg-work and putting it across in an engaging and readable manner.
 
Runnig "Need for Speed 3" with r21 I get a crash to desktop on SZ 1.71
This turned out to be a race condition with the DSP which sometimes crashes the whole system because the DSP ends up writing to system registers.. This is not good so I've prepared an update, with a few more fixes thrown in:
* fixed a race condition/crash in threaded SPU mode

* C64x: fixed compatibility with newer c64_tools, enabled L2 cache

* fixed control config corruption on load for devices that are disconnected on startup

* some dma accuracy improvements, might fix occasional glitches in ff7
As always, it's on the repo.
 
Since version 20 I've had a frequent problem with save states in Gran Turismo 2. Often when I load a save state and go into a race, there are moments of graphic corruption that cause frequent drops in frame rate to the point of being seconds per frame. It's most noticeable on the cars, particularly at the start of the race as the camera moves over and in to the vehicle. You see missing polys and vertices shooting off somewhere into the distance.
 
Runnig "Need for Speed 3" with r21 I get a crash to desktop on SZ 1.71
This turned out to be a race condition with the DSP which sometimes crashes the whole system because the DSP ends up writing to system registers.. This is not good so I've prepared an update, with a few more fixes thrown in:
* fixed a race condition/crash in threaded SPU mode


* C64x: fixed compatibility with newer c64_tools, enabled L2 cache


* fixed control config corruption on load for devices that are disconnected on startup


* some dma accuracy improvements, might fix occasional glitches in ff7
As always, it's on the repo.
A quick test confirms: no crashes to desktop with r22 and Need for Speed 3 and 4 so far. Thank you, notaz.
 
Excellent emulator Notaz been following it from the start all games I try work very good except for worms pinball which does not seem to work no matter what I try has any one else had any success with it.
 
Brilliant emulator, playing through FF9 with it atm, no glitches anywhere and having save states makes things so less irritating. :)

One really tiny minor bug I've noticed though, if I close the lid and the Pandora sleeps in game, when I open it again and flip the power button, it continues fine. But if I do it from the emu menu, it returns to a black screen and pressing up/down makes it re-appear. I guess restoring from sleep requires a visual update that comes automatically during emulation. Probably not even worth fixing its so minor.

Thanks for your hard work!
 
Hey notaz,

I noticed a relatively minor but still annoying problem with certain Konami Shmups.

Gradius Gaiden (SLPM-86042), Sexy Parodius (SLPM-86009) and Salamander Deluxe Pack Plus (SLPM-86037) all have issues with the screen size.

The games are not fullscreen, they have large black borders around the playing field which shouldn't be there.

Also, in the Gradius Deluxe Pack (SLPS-00303) Gradius 1 works fine, but Gradius 2 is unplayable because all the enemies are invisible.

Another Shmup game, Arcade Gears: Image Fight & X-Multiply (SLPS-01267) has sound stuttering problems when playing X-Multiply.

Would be awesome if you could look into these issues, especially the screen size problem.
 
Like one of those ?

poplar_hawk_moth_head-shot_0.jpg
 
Back
Top