Release Pcsx-Rearmed

[notaz]

Currently only .z one is supported.

Those PocketISO formats are a mess, using .bz is especially bad idea if the game does any kind of streaming. I'll support them eventually but don't be surprised it the games glitch or don't work at all and don't report me any bugs when using those formats.

 

[mvickers03]

Also wierd that your cut scenes were perfect,, mind letting me know which settings you used.. e.g gpu?

I used default settings @ 1ghz using the settings you gave me, works a charm my friend, what exactly messes up in the cut scenes? I use .iso format.

 

[Lobo]

OK, donation time.

P.S.
I just re-read 29 pages of thread to see if I could get Ari64 Paypal account and it's not there! Donation for him later I guess.

 

[Loon]

Is it possible to use the analog nubs with Pcsx-Rearmed?

If anyone has managed to do this then I'd be most grateful for an explanation of how it was done.

Must admit I'm surprised how well games like wipeout play using the Dpad but it would be great to use the nubs in this sort of game.

 

[God Ginrai]

Is it possible to use the analog nubs with Pcsx-Rearmed?

If anyone has managed to do this then I'd be most grateful for an explanation of how it was done.

Must admit I'm surprised how well games like wipeout play using the Dpad but it would be great to use the nubs in this sort of game.

No, support for that has not been added yet, IIRC. That's already been discussed in this topic.

-God Ginrai

 

[meandu229]

Also wierd that your cut scenes were perfect,, mind letting me know which settings you used.. e.g gpu?

I used default settings @ 1ghz using the settings you gave me, works a charm my friend, what exactly messes up in the cut scenes? I use .iso format.

Mid way through some cut scenes the screen cuts in half vertically and rendering gets messed up until the scene change in the cutscene, but the audio follows aloong perfectly, It sorts looks like it happens when it zooms in on an area, Wierd, maybe I changed something , im gonna complete again to get stealth suit instead of bandana (I forgot wether to give in or not at the torture) so ill see if I can sort it

 

[2dames2]

So what formats are currently supported for the emu? Stop me in my path if this has already been covered!!

 

[MooTheKow]

Notaz - pretty minor bug -- it is doesn't appear to save the last used rom path anymore unless you explicitly do a 'save global config' from the options screen. Looks like this is related to changes when you added per-game configs -- as it looks like you save only save the per-game config by default which does not include the last-used rom folder.

 

[notaz]

And here's the really fun one: "Speed Punks" (known as "Speed Freaks" outside the US) locks up the emulated PS1!

This one does some does strange things (designed to break emulation, perhaps Bleem?), otherwise it makes no sense:

* 8004d22c: ADDI r25,r24,48
  8004d230: BGEZAL r0,8004d238
  8004d234: ADDI r31,r31,-1156
* 8004d238: ADDIU r29,r29,-4
  8004d23c: SW r31,r29+0

It appears what hlide posted here is incorrect - the instruction in delay slot does get $ra value set by branch-link instructions (otherwise the game breaks), this is what by PCSX interpreter and MAME code do too.

Luckily this was quite easy to fix since recompiler already can compile BxxZAL in order:

--- a/libpcsxcore/new_dynarec/new_dynarec.c
+++ b/libpcsxcore/new_dynarec/new_dynarec.c
@@ -5644,12 +5644,16 @@ void sjump_assemble(int i,struct regstat *i_regs)
   //if(opcode2[i]>=0x10) return; // FIXME (BxxZAL)
   //assert(opcode2[i]<0x10||rs1[i]==0); // FIXME (BxxZAL)
 
-  if(ooo)
+  if(ooo) {
     if(rs1[i]&&(rs1[i]==rt1[i+1]||rs1[i]==rt2[i+1]))
-  {
-    // Write-after-read dependency prevents out of order execution
-    // First test branch condition, then execute delay slot, then branch
-    ooo=0;
+    {
+      // Write-after-read dependency prevents out of order execution
+      // First test branch condition, then execute delay slot, then branch
+      ooo=0;
+    }
+    if(rt1[i]==31&&(rs1[i+1]==31||rs2[i+1]==31||rt1[i+1]==31||rt2[i+1]==31))
+      // BxxZAL $ra is available to delay insn, so do it in order
+      ooo=0;
   }
 
   if(ooo) {

 

[notaz]

You should specify the dates the versions were released in the original post so we can be sure we're running the latest version without checking the Pandora.

It's all in git so I won't bother.

I have a save state for Formula 1 1995 which bypasses all the loading screens and goes straight to the race setup menu.

When I load this save state the screen freezes in whatever position it was before entering the emulator's menu. The game logic is still working behind the scenes because I can hear the transition sounds when trying to navigate through the game menu.

Known bug, wasn't able to track it down yet. I think it happesns when you save/load using different GPU plugins.

So what formats are currently supported for the emu? Stop me in my path if this has already been covered!!

it's all in readme:
http://notaz.gp2x.de/cgi-bin/gitweb.cgi?p=pcsx_rearmed.git;a=blob;f=pandora/readme.txt
Note that only 2352 sector ISOs are supported (which are not technically ISOs at all but oh well).

Notaz - pretty minor bug -- it is doesn't appear to save the last used rom path anymore unless you explicitly do a 'save global config' from the options screen. Looks like this is related to changes when you added per-game configs -- as it looks like you save only save the per-game config by default which does not include the last-used rom folder.

It never did this, maybe you are mixing with PicoDrive. Don't think it's a big deal unless you are doing compatibility testing or something.

 

[2dames2]

So what formats are currently supported for the emu? Stop me in my path if this has already been covered!!

it's all in readme:
http://notaz.gp2x.de/cgi-bin/gitweb.cgi?p=pcsx_rearmed.git;a=blob;f=pandora/readme.txt
Note that only 2352 sector ISOs are supported (which are not technically ISOs at all but oh well).

Sweet. cheers notaz.

 

[hlidegp2x]

It appears what hlide posted here is incorrect - the instruction in delay slot does get $ra value set by branch-link instructions (otherwise the game breaks), this is what by PCSX interpreter and MAME code do too.

oh wait! first I never stated it was correct, I just made some (false) speculations by seeing a circuit diagram showing a MIPS I which hasn't a "forward" mechanism (not sure about the real term).

Indeed, now that I remember, a perfect implementation of MIPS has no such read-after-write hazard (the next instruction wanting to read the register modified by the first instruction is not stalled) because if the next instruction tries to read the same target register of one of previous five instructions, it "steals" the value from a previous stage in pipeline, not from register file. Here's a short explanation : link to Pipeline Hazards.

Basically any normal register can be accessed through a "forward" mechanism (including RA), so it makes sense a delay slot can read an altered RA now.

 

[ari64]

And here's the really fun one: "Speed Punks" (known as "Speed Freaks" outside the US) locks up the emulated PS1!

This one does some does strange things (designed to break emulation, perhaps Bleem?), otherwise it makes no sense:

* 8004d22c: ADDI r25,r24,48
  8004d230: BGEZAL r0,8004d238
  8004d234: ADDI r31,r31,-1156
* 8004d238: ADDIU r29,r29,-4
  8004d23c: SW r31,r29+0

It appears what hlide posted here is incorrect - the instruction in delay slot does get $ra value set by branch-link instructions (otherwise the game breaks), this is what by PCSX interpreter and MAME code do too.

Weird. A very small number of N64 games use BGEZAL/BLTZAL, and the few that do place unrelated instructions in the delay slot.

Since Speed Freaks came out after Bleem and VGS, it's likely that was the intent.

 

[Prometheus]

Since Speed Freaks came out after Bleem and VGS, it's likely that was the intent.

Pardon my wondering aloud here, but I wonder how many other titles do things like that?

 

[ari64]

Since Speed Freaks came out after Bleem and VGS, it's likely that was the intent.

Pardon my wondering aloud here, but I wonder how many other titles do things like that?

Not many. Banjo-Tooie on the N64 does some strange things that I suspect were intended to break emulators, but that's the only one I can think of.

 

[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*.

*(I'm far from the most technical person, but it's my understanding that it does some odd stuff. I know it can be run under emulation with extensive tweaking of the options that some audio plugins offer, but I've never managed it.)

 

[ari64]

A lot of games do odd stuff. Usually that just means that the developer found a creative way of using the hardware. Sometimes games have bugs which trigger undefined behavior of the hardware, but don't actually cause any major problems.

When talking about deliberately breaking emulators, I'm talking about code that does nothing useful and exists only to exploit bugs in emulators. It's fairly uncommon, since there were few periods in history where there were usable emulators for current-generation systems. 1999-2001 was one such period of time, with PSX and N64 emulation.

 

[Exophase]

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.

Plus this is such a roundabout way of trying to beat an emulator, especially given that PS1 emulators back then were hardly very compatible. There are far more insidious methods that could be used - this one isn't that terrible to fix once you know about it, and doesn't add any real kind of performance penalty. Something relying on strict timing or cache behavior would be much worse to deal with.

The theory just sounds unlikely to me.

 

[notaz]

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?

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?

 

[jonlad1]

When will rc5 be out?

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