Release Pcsx-Rearmed

[Prometheus]

The reason I'm wondering is because of how The Misadventures of Tron Bonne behaves, really. :lol: That said, it's probably related to the sound stuff instead, though*.

So far it was suffering from cdrom emulation inaccuracies, try it on r5 when it's out, where latest PCSX-Reloaded code will be merged. What is it's problem on PC emus?

I'll try it as soon as r5 is available.

As for its problems on other emulators, it usually comes down to hanging after the first bit of speech in the first level finishes (with the corresponding animated face continuing to blink, as if waiting to speak again), or, hanging after the second bit of speech instead (if you time it right, you can skip the speech before it hangs). In some it will manage to get through the opening stage, but will eternally hang after it fades to black when it gets to loading the first boss. On some, it will crash or hang if you try to pause it, too.

(I should note that I haven't been able to try it on PCSX-Reloaded yet, though - for some reason it doesn't want to work on my Macintosh, and I don't have access to my Linux box right now. I'll have to give it a look there, and see what happens.)

Also Bleem would run burned and pirated CDs, wouldn't it?

Funnily enough, if I'm remembering it right, I seem to recall that Sony actually threatened more legal action when they tried to have it detect genuine discs so that it wouldn't run pirated ones.

 

[ari64]

You can't prove that things like this are only there to fault emulators. Exactly what reason would this game have to thwart an emulator like Bleem that was never officially capable of running CD images to begin with? There are other plausible reasons for why this code was used. Maybe the programmer didn't really understand what the instruction did. Without any comment from the developers no one can really say.

Well that sequence I posted is repeated multiple times with varying ADDI offsets, they look deliberately added to me.
Also Bleem would run burned and pirated CDs, wouldn't it?

BGEZAL/BLTZAL is often used for PC-relative constant pools. You would expect it to add an offset, and the offsets will vary depending on the location.

 

[bonapart]

Notaz: good work ;-) we found 2 unworking games (Mat_Hoffman's_Pro_BMX,G police)

1)Maemo copy of pcsx(r4 from git), frameskip - ntsc, using bios
error log: http://paste.kde.org/3456/

2)from maemo forum (don't know settings used, should be r4 from git too) :
Couldn't get G police to start
Error message in terminal window says:

Disabled speculative precompilation
Jump in the delay slot. This is probably a bug
Compile at bogus memory address: 10a3ed8

hope this will help to make recompiler better.

 

[hlidegp2x]

You can't prove that things like this are only there to fault emulators. Exactly what reason would this game have to thwart an emulator like Bleem that was never officially capable of running CD images to begin with? There are other plausible reasons for why this code was used. Maybe the programmer didn't really understand what the instruction did. Without any comment from the developers no one can really say.

Well that sequence I posted is repeated multiple times with varying ADDI offsets, they look deliberately added to me.
Also Bleem would run burned and pirated CDs, wouldn't it?

BGEZAL/BLTZAL is often used for PC-relative constant pools. You would expect it to add an offset, and the offsets will vary depending on the location.

right, the posted code sounds like putting the address of PC-relative variable or array or function in a pointer. It also might have be done by a compiler.

 

[notaz]

When will rc5 be out?

When it's done
And it's r5 not rc5, standing for "release 5".

I made a donation the other day to you but it got rejected? Did you reject it?

Whoops, I was supposed to "claim the payment" because of currency conversion I guess, and I missed those reminder emails somehow. I'll deal with it properly in case you want to resend.

In some it will manage to get through the opening stage, but will eternally hang after it fades to black when it gets to loading the first boss.

Near some cave I guess? Just tested it out of curiosity, but haven't really looked why it happens.

Notaz: good work ;-) we found 2 unworking games (Mat_Hoffman's_Pro_BMX,G police)

I'll have a look. Do you have newer version of your patch? If not I'll merge parts of your old one (that I'm happy with).

 

[notaz]

Now that Tomb Raider 2 cdrom issues are sorted, it hits this:

  619ac: JAL    61fc4
  619b0: ADDIU r3,r31,604
  ...
* 61fc4: SW r4,r2+38
  ...
  62088: JR r3
  ...
new_dynarec.c:8747: new_recompile_block: Assertion `rs1[i+1]!=31&&rs2[i+1]!=31' failed.

I'm getting real tired from this. 2.5 months and I still can't see the end of games hitting missing features of this recompiler. Ari64, let me know if you ever implement this, I'm feeding this to the interpreter now.

 

[ari64]

I'm getting real tired from this. 2.5 months and I still can't see the end of games hitting missing features of this recompiler. Ari64, let me know if you ever implement this, I'm feeding this to the interpreter now.

What's missing other than the r31 stuff?

Anyway, this is rare enough that feeding it to the interpreter probably won't hurt.

 

[Prometheus]

Near some cave I guess? Just tested it out of curiosity, but haven't really looked why it happens.

That's right - you start approaching the ruins, and then it fades out, never to return. :lol:

 

[notaz]

What's missing other than the r31 stuff?

Nothing known at the moment (went through broken games in compat list), but I thought the same when I did r1 release more than moth ago..

Anyway, this is rare enough that feeding it to the interpreter probably won't hurt.

TR2 uses it quite a bit though, 14 instances in first attract mode level (don't know how much executed though).

 

[bonapart]

Notaz: just some small changes (http://paste.kde.org/3540/)
it there any plans to write brg888_to_rgb555 function for maemo?

 

[Exophase]

Anyway, this is rare enough that feeding it to the interpreter probably won't hurt.

How much work is it to handle in the recompiler? It's just reordering the return address set to happen before the delay slot instruction right?

 

[hlidegp2x]

Anyway, this is rare enough that feeding it to the interpreter probably won't hurt.

How much work is it to handle in the recompiler? It's just reordering the return address set to happen before the delay slot instruction right?

Much easier. This RA happens to be a constant so you can have it this way :

JAL address; ADDIU Rd, RA, imm16 ---> emit_store_mips_register_with_immediate(rd, pc + 8 + imm16); emit_call(address);

where pc is the address of JAL

 

[notaz]

That's right - you start approaching the ruins, and then it fades out, never to return. :lol:

I think I have a fix for this, it's P.E.Op.S. SPU plugin related. As plugin based PC emus also use this they are also affected. I'll see if this breaks any other games.

it there any plans to write brg888_to_rgb555 function for maemo?

yes

Much easier. This RA happens to be a constant so you can have it this way :

JAL address; ADDIU Rd, RA, imm16 ---> emit_store_mips_register_with_immediate(rd, pc + 8 + imm16); emit_call(address);

where pc is the address of JAL

Not with Ari64's recompiler, where various register allocation/prefetch, address generation, loop preloading things are going on. It's real easy to fuck it up, take a look at this function that assembles JAL to see what makes me so paranoid.

 

[Prometheus]

I think I have a fix for this, it's P.E.Op.S. SPU plugin related. As plugin based PC emus also use this they are also affected. I'll see if this breaks any other games.

I'm damn near speechless at the thought of that (since this game has been a pain in emulators since forever ). Thankyou so much - I'm very interested to see how this goes.

 

[hlidegp2x]

Not with Ari64's recompiler, where various register allocation/prefetch, address generation, loop preloading things are going on. It's real easy to fuck it up, take a look at this function that assembles JAL to see what makes me so paranoid.

oh god! ok that's the worst situation for a code maintenance : no modularity, no factorizing . Ari64, are you a mathematician or an electronics engineer ? because that kind of coding way is very typical for them and drives programmers crazy!

 

[ari64]

How much work is it to handle in the recompiler? It's just reordering the return address set to happen before the delay slot instruction right?

Yes. The only additional thing would be to make the register cache aware of this, so that it doesn't try to load the old value.

Much easier. This RA happens to be a constant so you can have it this way :

JAL address; ADDIU Rd, RA, imm16 ---> emit_store_mips_register_with_immediate(rd, pc + 8 + imm16); emit_call(address);

where pc is the address of JAL

If you want to do constant propagation then set the constant flag during register allocation. The ADDIU instruction is already designed to handle this, but the JAL would need to be changed.

One thing to note is that in addition to putting the return address into r31, it also puts it into a hash table so that it can be looked up upon return. This avoids a potentially expensive cache miss. If r31 is being overwritten, then the call isn't likely to be paired with a return, so there is no need for this and the hash table insertion can be skipped.

Not with Ari64's recompiler, where various register allocation/prefetch, address generation, loop preloading things are going on. It's real easy to fuck it up, take a look at this function that assembles JAL to see what makes me so paranoid.

Well of course there is register allocation and prefetch. It's rather important if you want to generate efficient code, and not have a slow emulator. Wasn't that the whole point of using this instead of the psx4all recompiler?

oh god! ok that's the worst situation for a code maintenance : no modularity, no factorizing . Ari64, are you a mathematician or an electronics engineer ? because that kind of coding way is very typical for them and drives programmers crazy!

huh? It's not like there is anything in that function which is unnecessary. First thing it does is generate the delay slot. Then loads any registers that might be needed by the branch (such as the cycle count). Then it writes the return address, and, depending on the host cpu architecture, puts it into the hash table, or prefetches the existing hash table entry. Then it checks the cycle count, and generates the branch. If the branch is into the delay slot of another branch, there is a special case for that. Finally, it passes the address of the branch to the linker.

How would you make it simpler? Sure you can drop the hash table stuff, but it will just result in more cache misses and make the emulator slow. You can drop the branch-into-delay-slot stuff, but it just results in more recompiling and wasting memory. There's not much else that can be factored out. The delay slot handling, cycle counting, and register loading are already seperate functions. The address generation is in a seperate function so we don't duplicate this code in every load and store function. How would you design any of this differently?

 

[hlidegp2x]

oh god! ok that's the worst situation for a code maintenance : no modularity, no factorizing . Ari64, are you a mathematician or an electronics engineer ? because that kind of coding way is very typical for them and drives programmers crazy!

huh? It's not like there is anything in that function which is unnecessary. First thing it does is generate the delay slot. Then loads any registers that might be needed by the branch (such as the cycle count). Then it writes the return address, and, depending on the host cpu architecture, puts it into the hash table, or prefetches the existing hash table entry. Then it checks the cycle count, and generates the branch. If the branch is into the delay slot of another branch, there is a special case for that. Finally, it passes the address of the branch to the linker.

How would you make it simpler? Sure you can drop the hash table stuff, but it will just result in more cache misses and make the emulator slow. You can drop the branch-into-delay-slot stuff, but it just results in more recompiling and wasting memory. There's not much else that can be factored out. The delay slot handling, cycle counting, and register loading are already seperate functions. The address generation is in a seperate function so we don't duplicate this code in every load and store function. How would you design any of this differently?

I was speaking about the way all the source file is coded : very long functions and no design pattern. I don't mean your code is unefficient but very hard to maintain or to be understandable by the others. I had to maintain similar codes in work which were coded by electronics engineers who coded similarly. It was always a nightmare to try to change something deeply and most time you need to rewrite from the scratch, so I understand Notaz's feeling about the difficulty to bring a change without breaking something. But take it easy, that you could code a working recompiler this way is pretty amazing indeed.

 

[notaz]

Not with Ari64's recompiler, where various register allocation/prefetch, address generation, loop preloading things are going on. It's real easy to fuck it up, take a look at this function that assembles JAL to see what makes me so paranoid.

Well of course there is register allocation and prefetch. It's rather important if you want to generate efficient code, and not have a slow emulator. Wasn't that the whole point of using this instead of the psx4all recompiler?

Sure, just hlide and Exophase kind of implied it should be doable without too much effort and I wanted to show why I chose to fall back to interpreter this time.

 

[tarwin]

I've problems loading FF7 and FF9 on r4 and am wondering how you guys got it to work?
Both games only show a black screen. I've toyed around with the setting, supplied a real bios (1001 and 7502) but nothing changes...

I trying to run it on a pandora with HF5-Beta2 on it.

Any tips?

The other games i've tried, G-Police and FF4 and FF5 work fine. Sound in G_police stutters a bit.

-T

 

[god_at_hell]

I have to say .. great emulator . I didn't expect this when i got my Pandora. Thx notaz and Ari64

Most of the games i tested so far made no problems. The biggest errors i encountered were with "The X-Files (US)" and "Dead or Alive (US)".
The first game runs, but the visuals are messed up. The picture is split in 18 columns and beginning with the second column they are disordered. The whole picture is a great puzzle . This happens with every gpu plugin.
Dead or Alive runs fine, but crashes at or after the first fight.

@tarwin: My version of FF7 works like a charm without any special settings... maybe your image is faulty.