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

[daniel229]

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

stack trace

[thedax]

For reference: c709315...8e22554

[unknownbrackets]

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

-[Unknown]

[unknownbrackets]

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

-[Unknown]

[daniel229]

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

[unknownbrackets]

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]

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]

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]

That fixes it and not seeing any graphical artifacts.

[unknownbrackets]

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]