We'll see how many we need, let's do this:Like one of those ?
http://www.feeldesain.com/30000-swarming-paper-moths.html
Last edited by a moderator:
Release PCSX ReARMed r22 - now using the DSP
- Thread starter notaz
- Start date
http://www.feeldesain.com/30000-swarming-paper-moths.html
No problem, take your time. I just wanted to report these issues to help with further improvement of an already awesome emulator.
It's not like I couldn't live without these games.
Learned a painful save state lesson yesterday, round-robin save in as many slots as you can, as after saving FF IX at one point, PCSX crashed back to the pandora menu. When I reloaded the save state, it appeared to be okay, but the moment I changed areas, or went into the item menu, the save data was clearly corrupt. Either that or someone had stolen all my items and half the UI.
Spent about an hour getting back to the same point (mostly it was just one easy boss fight and an awful lot of dialog), but halfway through that it did the same thing again. However this time the save state seemed ok.
Spent about an hour getting back to the same point (mostly it was just one easy boss fight and an awful lot of dialog), but halfway through that it did the same thing again. However this time the save state seemed ok.
Rockthesmurf
Advanced Member
[random thoughts]
I wonder if the problem is that Linux isn't writing to the SD card directly, instead it is buffering it up and writing at a more optimal point (optimal from performance/SD life/battery life) when there is possibly more data waiting to be written. So ultimately the data being written to the SD isn't in a consistent state until it has all been flushed to the card (until it is consistent, it could be thought of as being corrupt). Typically the flush happens from time to time, data is kept in sync, everything runs well, but in the case of a crash, the data not yet written to the SD doesn't ever get written, so the contents on the SD is left in the intermediate/corrupt state.
Does that sound like what is going on? I don't really know how filesystems/linux/SD/electable media works, just speculating.
If the above is all true, I guess either Linux can be told not to buffer up data, or, perhaps it is possible to forcibly get the data to flush, in which case I wonder if there is any sense in the emulator asking for a flush after a save has been made (typically putting code like this at the application level seems wrong, but if the application in question can crash by its nature maybe it safe guarding the data it writes isn't so bad).
[/random thoughts]
I wonder if the problem is that Linux isn't writing to the SD card directly, instead it is buffering it up and writing at a more optimal point (optimal from performance/SD life/battery life) when there is possibly more data waiting to be written. So ultimately the data being written to the SD isn't in a consistent state until it has all been flushed to the card (until it is consistent, it could be thought of as being corrupt). Typically the flush happens from time to time, data is kept in sync, everything runs well, but in the case of a crash, the data not yet written to the SD doesn't ever get written, so the contents on the SD is left in the intermediate/corrupt state.
Does that sound like what is going on? I don't really know how filesystems/linux/SD/electable media works, just speculating.
If the above is all true, I guess either Linux can be told not to buffer up data, or, perhaps it is possible to forcibly get the data to flush, in which case I wonder if there is any sense in the emulator asking for a flush after a save has been made (typically putting code like this at the application level seems wrong, but if the application in question can crash by its nature maybe it safe guarding the data it writes isn't so bad).
[/random thoughts]
sebt3
homebrew player (P. & C.)
either the command "sync", or more specifically from C "fsync(FileDesc)".the former is also possible using the "sdparm" command and there's probably a way to do so in the code.
(dont know if either commands are available on pandora though)
hollowshell18
Still Fresh
- Joined
- Jun 20, 2013
- Messages
- 9
The changes to SPU emulation are absolutely wonderful. The Final Fantasy games sound perfect now.
Thank you for all of your hard work on this project Notaz.
Thank you for all of your hard work on this project Notaz.
When i play Wild Arms 2 (SCUS-94484), on the map area, where you can scan for cities and co: when you are on the right spot and scan for it, the game stalls and the sound repeats in a loop or the emulator crashes and exits. No idea if this is the right spot to mention it or if it's a known issue. No idea if this problem happened before. Was just thinking of letting someone know or if someone knows a setting to work around this problem
ekianjo
Hardcore Member
Try with the DSP off and see if this fixes the crash or not.
levi
Still fresh, damnit!
Does it log anything useful in the pndrun.out log file?
I have no idea what to look out for in that file. But the line: "segmentation fault" after "branch in delay slot..." looks suspicious. Sometimes, it says "terminated" instead. Depending on if it crashes or just hangs, i guess. After the segmentation line is also: hugetbl: 0 pages allocated.
Last edited by a moderator:
Linux-SWAT
Forum Addict!
- Joined
- Feb 13, 2010
- Messages
- 9,194
Are you running a recent firmware update ?
If yes, you should provide a savestate + instructions to trigger the bug.
Maybe someone will take a look at it .
If yes, you should provide a savestate + instructions to trigger the bug.
Maybe someone will take a look at it
.I'm using the latest firmware and the newest version of pcsx-rearmed (also 1ghz pandora version, if that matters).
Here is the link to the savestate: https://mega.co.nz/#!eBB2EZZI!fVLZO-K9SG37WyhhrkaY-a1xWyAMgzoj1_vr0xQayXU
Instruction:
Load CD1 -> load savestate -> press "A" (Square) -> bug/crash
Hope this helps more.
Here is the link to the savestate: https://mega.co.nz/#!eBB2EZZI!fVLZO-K9SG37WyhhrkaY-a1xWyAMgzoj1_vr0xQayXU
Instruction:
Load CD1 -> load savestate -> press "A" (Square) -> bug/crash
Hope this helps more.
So, I'm nearing the end of Disc 1 in FF IX, decide to copy some more PSX games to my SD card, start getting errors, try a few I did copy, then loaded up FF IX again, and all of my round robin saves were gone, just three remained from near where it lost my initial save point.
I think the SD card is to blame rather than the emulator. :/
After quite a bit of despair, I googled for save games, and found a site with loads of them on, so I can at least carry on near to where I left off.
I think the SD card is to blame rather than the emulator. :/
After quite a bit of despair, I googled for save games, and found a site with loads of them on, so I can at least carry on near to where I left off.
Small update, it happened again, this time I'm sure it's not the SD card.
It's an extremely rare event, but basically the symptoms are... save game state, and the moment it resumes it crashes back to the PND launcher. Restarting it and loading the save state results in a frozen game.
Only lost about 30 minutes of playtime this go, due to round-robin saves.
It's an extremely rare event, but basically the symptoms are... save game state, and the moment it resumes it crashes back to the PND launcher. Restarting it and loading the save state results in a frozen game.
Only lost about 30 minutes of playtime this go, due to round-robin saves.
notaz
Certified Guru
How do you know it's not SD card? Could you check dmesg output (just start a terminal and type dmesg).
I checked dmesg, no errors anywhere, SD card related or otherwise. :/ I recently put in a new genuine branded SD card, so it's probably not that, obviously it still could be but I suspect not. Unless after saving the emulator then reloads the saved data I'd have thought it doesn't care what it wrote out.
It's definitely saving it, then resuming the game, then crashing once it's resumed the game. It might be a bug in PSX-Reloaded itself related to the pausing and resuming of emulation state, or it might be the port crashing. Is it possible for it to crash immediately after saving and not flush the file buffers?
It isn't the end of the world, if you round-robin save, which I do regularly anyway.
It's definitely saving it, then resuming the game, then crashing once it's resumed the game. It might be a bug in PSX-Reloaded itself related to the pausing and resuming of emulation state, or it might be the port crashing. Is it possible for it to crash immediately after saving and not flush the file buffers?
It isn't the end of the world, if you round-robin save, which I do regularly anyway.
notaz
Certified Guru
Yeah from your description it looks like something bad happens during data writeout. However I haven't ever seen this happen, and nobody reported it before you. You could check /tmp/pndrun_pcsx_rearmed.out , maybe it has some hints. Not overclocking too much?
Thought I'd replied to this already, guess I didn't click post.
I overclock to 1100, I guess I could just run it at 1000, probably wouldn't notice the difference at all. It's a rare event that it corrupts, and I'm saving often, sometimes 20 times a day, so it could be anything causing it.
If the issue was during data writeout though, would it not crash before it returns to the game?
I overclock to 1100, I guess I could just run it at 1000, probably wouldn't notice the difference at all. It's a rare event that it corrupts, and I'm saving often, sometimes 20 times a day, so it could be anything causing it.
If the issue was during data writeout though, would it not crash before it returns to the game?
notaz
Certified Guru
Writes on Linux are buffered, kernel reports write success before writes actually happen unless special code is used.
