Emulator

Also here.. same revision, Windows Vista x64 SP1, SSE, 2 and 3.
System:
Intel Core 2 Quad Q6600
2GB memory
Leadtek Winfast PX8800GT ZL (8800GT, 512MB)
Crashes instantly every time.

Same here. Windows Vista SP1 32-bit, Intel Core 2 Quad Q6600 @ 3.00 GHz, SSE2&3, 4 GB
RAM, NVIDIA GeForce 9800 GT. However, I can't move around at all; the TLB happens
just when the HUD appears.

which version are you all using ? PAL i guess ?

NTSC

see issue 103. If your game gets a TLB error after booting, it is probably actually
some other error, just being reported as a TLB error.

My bad again. Reminder to self: don't forget to switch plugins to debug version when
debugging. This is not jited code it's in ogl plugin >>

oops forgot to precise:
The code that overwrite this gc-code address is in the texture hash stuff in
textureMnrg iirc. It's the hash value that overwrite the gc-code.

Seriously who could guess that a consumer videoplugin can write stuff in GC ram.
Anyway, I understand why now :p

Strange. Does MP try to texture out of code memory for some reason? :P Probably
should come up with a saner alternative to the texture hash overwrite scheme...

Yup the current implementation of the texture cache is a bit "border line" but it's
ok when you now that :p
Anyway, the bug happens before IMO maybe an wrong CPReadPointer with an ambiguous
GXopcode for value.

This texture cache bug could be useful actually.
I'm thinking about adding a special debug ptr table for this hash write.

• add hash write ptr in this global table
• in interpreter mode: compare for each instruction ptr with those in the table then
  assert some info if it turn bad

Will this ever be fixed? Its been awhile...

yes, this has been fixed

Last I tried Metroid Prime 1 on Dolphin, there was no crash.

Metroid Prime PAL versión does crash after de first cutscene (Samus Landing), no
gameplay.

No, it doesn't crash, if you set the GL plugin to use Safe Texture Cache. This may
become the default soon, but it's still somewhat unreliable for videos.

ector, I didn't read the change you made but, was it really a bug in texture cache mng?
If not, I thought texture hash was written in the texture data so it shouldn't be a
problem though. I mean, program PC shouldn't fall in this data address. So, in that
case, this bug is bypassed by "Safe Texture Cache" but not fixed yet... Or I miss
something :p

Definitely much much better, i've yet to see it crash. It does bring up some panics
upon loading states, but the state loads anyway.

Also when loading some times sound issues happen, like sound loss, or sound repeating
itself.

mb2, there is indeed some sort of collision between the jit and the texture cache.
Haven't yet determined exactly how it can happen, but the metroid disc has lots of
.rel files on it, which is dynamically loadable code.

Ok, very plausible explanation for me. I let you close this issue when you feel like it.

Not sure, but is the Safe Texture Cache also responsible for fixing the fonts?
Just tried it on r2339, without it I can barely/not read the text, with it activated
the game is rather playable (no crashes that were reported by other people earlier).

It appears so. For me, MP1 has bad fonts with unsafe TC, and good fonts with safe TC.

can this be considered "fixed" since the creation of safe(r) texture cache? :}

STC kills game performance and makes it crash in other ways, but i guess u can close
this, isn't there another way to fix this?

Aren't this all was already fixed?

If having to enable STC for it not crash is considered a fix, i guess.