search

hrydgard / ppsspp

A PSP emulator for Android, Windows, Mac and Linux, written in C++. Want to contribute? Join us on Discord at https://discord.gg/5NJB6dD or just send pull requests / issues. For discussion use the forums at forums.ppsspp.org.
https://www.ppsspp.org
Other
11.18k stars 2.17k forks source link

Riviera : Yakusoku no Chi -Special Edition crashes on PSP 1000 model #6113

Closed daniel229 closed 9 years ago

daniel229 commented 10 years ago

PSP 2000/3000 fine. last build works is 0.81-1232-gc709315,since 0.81-1249-g8e22554,It crashes. 01 02

stack trace 03

thedax commented 10 years ago

For reference: https://github.com/hrydgard/ppsspp/compare/c709315...8e22554

unknownbrackets commented 10 years ago

Seems like clutAddr is 0x09FFFFFF. That should not be a valid clut address. The US version does not crash...

-[Unknown]

unknownbrackets commented 9 years ago

Does this still happen? Anything interesting show in the log leading up to the crash?

-[Unknown]

daniel229 commented 9 years ago

Still crash,stacktrace no different. debuglog(rename jpg to 7z) ppsspplog

unknownbrackets commented 9 years ago

Hmm: ISOFileSystem.cpp:569 Reading beyond end of file, clamping size 2968576 to 2967872 ISOFileSystem.cpp:569 Reading beyond end of file, clamping size 524288 to 302248

If you can, try re-ripping it to be safe? I heard once that some early ripping tools had a bug once that caused isos to be truncated by a small number of bytes. Though, it's possible this is correct (it will truncate on firmware.)

Dialog\SavedataParam.cpp:648 Savedata loading with detected hashmode 5 instead of file's 3

Do you have to load savedata to get the crash? If it's easy to get it without savedata, can you try it with an empty SAVEDATA directory just to rule it out?

I guess I should check if a clut read starting at a valid address actually crashes on the PSP. Maybe it's just a bug in the game and actually happens to work on real hardware...

-[Unknown]

daniel229 commented 9 years ago

I can't re-ripping it,but the non-Special Edition works. also report 03:48:203 idle0 W[FileSys]: FileSystems\ISOFileSystem.cpp:569 Reading beyond end of file, clamping size 32768 to 3176 03:48:203 idle0 W[FileSys]: FileSystems\ISOFileSystem.cpp:569 Reading beyond end of file, clamping size 32768 to 5976

Empty savedata still crash.

unknownbrackets commented 9 years ago

Are there any graphical artifacts if you change this (GPU/GLES/TextureCache.cpp):

void TextureCache::LoadClut() {
    u32 clutAddr = gstate.getClutAddress();
    if (Memory::IsValidAddress(clutAddr)) {

To:

void TextureCache::LoadClut() {
    u32 clutAddr = gstate.getClutAddress();
    if (Memory::IsValidAddress(clutAddr) && Memory::IsValidAddress(clutAddr + gstate.getClutLoadBytes() - 1)) {

Or, does that still crash / have wrong graphics?

-[Unknown]

daniel229 commented 9 years ago

That fixes it and not seeing any graphical artifacts.

unknownbrackets commented 9 years ago

So, according to my tests:

  1. Access outside valid VRAM does not crash. For example, loading clut from 0x04800010 works just fine.
  2. Some invalid access is still considered invalid; for example, 0x05000010 crashes.
  3. When accessing invalid RAM and it works, it reads zeroes from the invalid region.
  4. Reading from 0x0C000000 DOES crash, though. So does reading 0x0BFFFFF0 for one block (one block = 0x20 bytes.)

I don't have a PSP-1000, so I can't verify how it behaves on 0x09FFFFFF (this works on my PSP-2000, where the hardware address 0x0A000000 is valid, even if not allocatable by games by default), but it seems like it would crash. But maybe not. Either way, the VRAM is enough to say it's reasonable to support this behavior and use zeros.

-[Unknown]