Release Pcsx-Rearmed

[DaveC]

DaveC, you asked this before and I answered 'to my knowledge' (very limited) that the .sub data was subchannel and contained the audio. Wizardstan is giving the correct tech level answer. I also with paranoia ever present figured you were subtly hinting I should not be posting long lists of sleep deprivation to notaz based on versions of games not officially supported

However as a test for the last 10 minutes, I just removed .sub from PAL Vagrant Story (CloneCD rip) and ran it via r3 and then r2 versions of notaz emu. It fails to run beyond the 'new game' choice and sits on 'now loading' with no fps changes but the HDD flashing in both revisions. If you replace the .sub file it runs again. Oh and...

Vagrant Story (PAL SLES 02754) (.img needs .sub) - (r3) Has a warbling to the music that is annoying and absent in r2.

I will check other games if removal of .sub makes a difference. For now I need yesterdays breakfast.

Ok so I guess that means that you DO need the subchannel data for this emu and it supports it. Thanks, it is good to know.

 

[Chaser]

Seems it varies Dave and you'll need to test each game. Vagrant Story, ColinMcCrae and Tekken3 to a lesser degree (suffers gfx issues in intro movie) dont like it left out but Abes Oddysee, FFVII and RR4 dont seem to be affected. Could save 20-30mb per game that it can be left out of though.

 

[Chaser]

Sorry to double post but theres something I was wondering the other day.

r3 has introduced previews of save states, and others have mentioned being able to rename Psx4Pandora memcards to work with Pcsx-Rearmed but I was wondering if in either emu, there is any form of mem card manager function?

Either like the PSX own version for simply viewing the memcard files, copying, moving between 1-2, deleting or anything more elaborate or basic.

Or if perhaps one could be implemented in a more full blown way, such as the like the PS3 can do. Wherein you can create as many virtual memcards as wanted, named as you wish and load the appropriate one before selecting your chosen game, all from within the emu. As I imagine at present, you will need to use the file manager to browse to the memcards or savestates manually, to delete unwanted states, or create new cards and rename the old ones as they become full.

Similar to this thread I've just found http://www.gp32x.de/board/index.php?/topic/58112-pcsx4all-memory-card-managment/page__pid__933086__st__0&#entry933086 whilst re-wondering this idea.

Whats the current way of managing these files/savestates and is there any chance of implementing something polished like PS3?

I just decided to test if Psx4Pandora b5 can load the bios and memcard manager and it cant and as Pcsx-Rearmed doesnt yet have bios functionality it also appears to not be do-able at present 'unsupported file type/image' is the result.

Is something functional a possibility notaz or are the current memcards of infinite capacity anyway?

 

[OilySalmon]

Blahblahblah

Yeah, that's just frontend-level stuff. It would be pretty easy to impliment basic memcard management. (Depending on how memcards are currently stored.

 

[Mjlink]

Thanks for this Notaz. I will get you a donation for this goodness.

 

[Dunny]

Thanks for this Notaz. I will get you a donation for this goodness.

Ditto, as soon as R-Type Delta runs well enough to play!

D.

 

[notaz]

Ari64, yet another issue (BIOS does this):

  bfc05f1c: SB r0,r3+0
str r2,fp+132
<->
mov r8,#0
cmp r3,$2097152
bvc 0
mov r1,r3
strb r8,r1+0
ldrb lr,r0,r3 lsr #12
cmp lr,$1
bne 0
str r6,fp+148
  bfc05f20: LBU r0,r3+0
<->
cmp r3,$2097152
bvc 0
mov r8,r3
ldrb r8,r8+0
str r6,fp+148
  bfc05f24: SB r0,r2+0
<->
cmp r2,$2097152
bvc 0
mov r1,r2
strb r8,r1+0
ldrb lr,r0,r2 lsr #12
cmp lr,$1
bne 0

The dummy read at bfc05f20 writes to allocated r0, which corrupts next write.. (the BIOS is doing some FIFO stuff there). I've hacked around this in load_assemble/do_readstub, but I guess many other instructions could do this too, so we need a more general fix.

Damn emulating BIOS on Ari64's recompiler is a tough thing to do. It does fair bit of self-tests and uses some r3000 specific stuff that's not on r4300..

 

[jonlad1]

I take it you're working on implementing the BIOS now

Cool B)

 

[ari64]

The dummy read at bfc05f20 writes to allocated r0, which corrupts next write.. (the BIOS is doing some FIFO stuff there). I've hacked around this in load_assemble/do_readstub, but I guess many other instructions could do this too, so we need a more general fix.

Whoops. Most instructions get ignored if they write r0 (ie: if(rt1)...) but I figured that loads needed to check for pagefaults and I/O. I guess I forgot to skip the actual load. I don't think I missed any other cases, but I'll double-check.

BTW I suppose it would be possible to get rid of those mov instructions. Originally there were xors there to swap the endianness.

Damn emulating BIOS on Ari64's recompiler is a tough thing to do. It does fair bit of self-tests and uses some r3000 specific stuff that's not on r4300..

I presume these are cop0 instructions?

 

[notaz]

Damn emulating BIOS on Ari64's recompiler is a tough thing to do. It does fair bit of self-tests and uses some r3000 specific stuff that's not on r4300..

I presume these are cop0 instructions?

Yeah, namely RFE that's only in MIPS-I and some painful thing that makes RAM writes ineffective (BIOS wants to see that working).

 

[Prometheus]

I've *finally* got some time to try PCSX-ReARMed out! I might have some info for you shortly, notaz. My apologies.

EDIT: Ok, I've tried a handful of my collection, and I have some badly-behaved games here that you might want to know about;

The Misadventures of Tron Bonne (PAL) - A consistent offender in all emulators, and a game which has yet to work out of the box on any PSX emulator (and which simply can't work on all but one of them, to my knowledge). This game hangs before the second of the company logo videos finishes displaying and never comes out of it.

Klonoa: Door To Phantomile (PAL) - Displays garbage for its opening video, won't respond to buttons, and gets stuck in a loop of showing other videos it shouldn't (also in garbage form) after the intro video is supposed to finish.

Mega Man Battle & Chase (PAL) - Crashes after displaying semi-garbage company logo videos.

MegaMan Legends (PAL) - Crashes after showing semi-garbage company logo videos.

I'm happy to report that Mega Man 8 (PAL), and its Japanese version, Rockman 8 - Metal Heroes (NTSC), work perfectly in-game, although the NTSC one is a teeny tiny bit slower than it should be. The only problem with these two is that their FMVs do not play.

Is there anything I can provide that would help, here?

EDIT 2: I should note that I was running at 850MHz for all of these. I noticed that setting it in the emulator itself didn't help, and that I had to do so from Xfce beforehand, and also make the clock speed setting in the emulator match it, or it would run slowly.

 

[ari64]

I've looked over the code and all the ALU instructions seem to be correct, but it looks like r0 can get written in MFC0, and also in your cop2 functions. This is easy to fix.

By the way, what is going on with r6 in the above example? It gets written twice. I don't recall seeing that bug before.

Yeah, namely RFE that's only in MIPS-I and some painful thing that makes RAM writes ineffective (BIOS wants to see that working).

Oh yuck. Maybe you can hack around this using the interpreter?
Blocking writes in the dynarec would require using something like the TLB pagefault code to catch the writes before they happen. I guess that's doable since most of the code is already there, but it would still be a bit messy.

 

[hlidegp2x]

Damn emulating BIOS on Ari64's recompiler is a tough thing to do. It does fair bit of self-tests and uses some r3000 specific stuff that's not on r4300..

I presume these are cop0 instructions?

Yeah, namely RFE that's only in MIPS-I and some painful thing that makes RAM writes ineffective (BIOS wants to see that working).

Do you mean you are blocked when recompiling BIOS because it's trying to write in RAM when writing in RAM is disabled ? (nasty test leading to a forever loop when RAM fails to be read-only)

if so, no need to handle it through interpreter or recompiler, there are only two lines to write to nuke it, unless some games also do that nasty test.

EDIT:

this is an excerpt from an old psx emulator I tried to code on PSP until Sony released its own official PSX emulator.

   void emulator_t::memory_reset()
   {
       in_debug printf("nmemory_reset : reset in progress");
   
       FILE *in = fopen("./bios/scph1001.bin", "rb");
   
       ...
   
       in_debug printf("nmemory_reset : reading a BIOS file into PSX ROM");
   
       fread((char *)rom_data->b, rom_data_size, 1, in);
   
       fclose(in);
   
       in_debug printf("nmemory_reset : patching PSX ROM");
   
       // patch BIOS to remove a read-only RAM protection
       std::fill(rom_data->b + 0x022c, rom_data->b + 0x0368, 0);
       std::fill(rom_data->b + 0x1940, rom_data->b + 0x1a50, 0);
   
      ...
   }

it worked with scph1001.bin and with the european bios file the name of which I don't remember (first digit is 7 i think) when i tried it.

that way you don't need to check a special address and special values to enable/disable RAM writing in interpreter/recompiler.

EDIT 2:

to implement RFE is quite simple :

 // regs[target_c0_status] = (regs[target_c0_status] & 0xffffffc0) | ((regs[target_c0_status] >> 2) & 0x0f);

note that target_c0_status is COP0 data register $12.

 

[notaz]

Is there anything I can provide that would help, here?

Not really, except maybe trying things on PC version of PCSX to see how likely it is for them to get fixed.

EDIT 2: I should note that I was running at 850MHz for all of these. I noticed that setting it in the emulator itself didn't help, and that I had to do so from Xfce beforehand, and also make the clock speed setting in the emulator match it, or it would run slowly.

Strange, it might happen if you are going to 900 or above since firmware script limits to that (need to get ED to fix this).

I've looked over the code and all the ALU instructions seem to be correct, but it looks like r0 can get written in MFC0, and also in your cop2 functions. This is easy to fix.

Thanks

By the way, what is going on with r6 in the above example? It gets written twice. I don't recall seeing that bug before.

Oh it's my debug writebacks so that I can compare state against the interpreter, should've filtered that out before posting.

this is an excerpt from an old psx emulator I tried to code on PSP until Sony released its own official PSX emulator.

Thanks for the info, I'd like to support all bios though, so not sure hacking them is the best solution but I'll have this in mind.

to implement RFE is quite simple :

 // regs[target_c0_status] = (regs[target_c0_status] & 0xffffffc0) | ((regs[target_c0_status] >> 2) & 0x0f);

Right, already implemented it too.

 

[hlidegp2x]

this is an excerpt from an old psx emulator I tried to code on PSP until Sony released its own official PSX emulator.

Thanks for the info, I'd like to support all bios though, so not sure hacking them is the best solution but I'll have this in mind.

I tried it for several BIOSes, probably not for all BIOSes though and it works (apparently this piece of code never changed). Honestly I'm pretty sure everybody is using scph1001.bin renamed as bios.bin anyway.

 

[Exophase]

One other non-hack method that could help is to make the RAM protect option part of the compile-time state instead of the run-time state, and flush translation cache when it's modified. When it's disabled you would change the type of store instructions you emit to ones that explicitly protect against RAM writes.

This sort of approach can work for other parameters that are infrequently changed as well.

 

[gruso]

Thanks for this fantastic project, Notaz. I'm happily running MDK, Medal of Honor and GT2. Still keeping PSX4all on hand for Heart of Darkness.

 

[Holliefant]

Heart of Darkness is working with PSX4all? I heard it didn´t and didn´t try myself... Good to know

 

[gruso]

I should have said PSX4pandora but I'm sure you knew what I meant! Version is psx4pandora10b5.pnd, in case it matters.

 

[stustaff]

Wow!

This is pretty cool, just dropped one of my favourite games in this Psx-rearmed and it works perfectly at 600mhz framerate of about 45-60 with no changes.

Sound perfect even the voice at the start and graphics are spot on!

Thanks for this.