PS2PSXe Downloads and Updates

[ffgriever]

This emulator is designed to support PSX (PS1 Games) Backups and play them on your PS2 via USB, Network, or Internal HDD.

Below you will find the most recent versions.
r202 was the last revision made by the developer ffgriever in 2011.
I recommend ps2psxe_jay-jay_bundle_v2 version attached below.

---

PS2PSXe Game Compatibility List: http://psx-scene.com/forums/f292/ps2...e-list-105342/ (PS2PSXe Compatibility Game List)

Tutorial? A better tutorial is being worked on here: http://psx-scene.com/forums/f292/ps2...uction-105353/

Got Questions? Click Here to start a new Topic and ask a question about PS2PSXe: http://psx-scene.com/forums/official-ps2psxe-forum/

---

Edit @ September 16, 2011 by ffgriever

Please re-download the lang file (if you're going to translate the gui, otherwise it's not needed at all). The last one contained invalid characters in few lines.
!!!The lng file has to be utf8 encoded to work properly!!!

Edit @ September 13, 2011

Here is a newer version of the preview with sound and some fixes, rev188: http://psx-scene.com/forums/f164/ps2...tml#post917494

There is also early version of hardware sound emulation, rev198. Just replace the executable and directory (important, the new irx is necessary) in rev188 package: http://psx-scene.com/forums/f164/ps2...tml#post923054

Note that it has yet no support for XA playback. Everything else should work fine.

----------------------------------------
So as I wrote. Public PS2PSXe preview. Only command line version attached. Unfortunately I wasn't able to get current sources to work properly (I'm halfway with some major changes and it will take awhile to complete them).

---

Click Here to start a new Topic and ask a question about PS2PSXe:
http://psx-scene.com/forums/official-ps2psxe-forum/

[ffgriever]

I've attached the ps2client and ps2link version I'm using to the first post.

[ffgriever]

I know I wrote you should not expect any updates and such... But I screwed oh so much. Remember? I wrote the current version doesn't even build, right? So I checked out the version just before the changes. The problem is that I did it in directory that already contained the new files. For some reason one of the files from GTE recompiler (it's not finished) didn't get overwritten. So it contained code that was totally off (everything has changed in the implementation to match all the new stuff).

I'm totally amazed it worked at all! By all means, it shouldn't .

Anyway, I've added rev168a to the first post.

Edit:

The IOP error shown on the screen occurs usually when you try to reset ps2 link while the game reads something (or the read buffer is being filled). Enter menu, press pause... whatever that will stop the reading (games usually do not read anything while in menu or paused). Then reset. These kind of errors should be less frequent then on resets.

[ffgriever]

The framerate... If you have been using the preview release, then you already know, that it's strongly game dependent. For some games it is possible to achieve 400% the nominal speed, others have problems reaching 50%. It haven't changed since then. Also, there is a slight problem. I'm not even going to implement frameskipping, as it doesn't do any good. The speed increases only on some simple games that were already working fine. If a game works at, say, 40fps (80% for PAL games), using frameskipping gives you additional 2-3 fps, while screws everything around (gaming experience included). The GPU code is constructed in a way, that doesn't block emulation for drawing. Packets are constructed when they're received by emulated GPU, then they're executed while next part of code is beeing emulated (next frame is being calculated by the psx). Since constructing packets is not that time consuming (it's really mostly translating PSX GPU packets into PS2 GPU packets), skipping this part doesn't give too much (remember that you still have to emulate all the vram writes, reads and moves, even if skipping the frame). It worked really well for software plugin (it could speed up by 70%), but since it was way too slow anyway (hardly reaching 15-20 fps), it didn't matter. That leaves me with the CPU code to optimize further. Sure, it's the same instruction set, you might say, but it's impossible to just "run" psx code as is. There is a different hardware, different memory mappings, I need to call some compiled c code for many hardware functions (that leaves usage of all temporary registers out, as saving them and loading at every function call is terribly slow). So a real recompiler was necessary anyway... Just as on any other cpu. I'm just trying to guess best possible saved registers allocation for current block and blocks it is connected to (jumps, branches). It isn't perfect, though .

One quite interesting thing was not to check every read/write for hardware access, but simply let the PSX code read/write to the addresses it wants (just moved from 0/a/8 to new hardware mapped 4/5 space) and trap the necessary hardware addresses in exceptions (not all, as for some of them there was an even quicker and better way), while letting it read/write "real" PSX memory directly by modified TLB. I know, the exceptions are terribly slow, but there is a catch. You wouldn't know, but changing PS2 memory mapping to match PSX as close as possible, trapping the PSX hardware reads/writes through modified TLB and exceptions, it is still much faster than making checks at every read and write operation. It might look insane (codewise), but works (and works great). Mostly because every read/write operation takes only ~4 (or, and, lui + r/w instruction - well, it might be sll/srl/or+r/w with the same effect -, not even a need to invalidate the recompiled code for self modifying psx code, as it will be done almost automatically whenever needed by some clever TLB use) instructions instead of ~10-20 (for sw in some circumstances, as normally there is a lot of checks, one of them being the necessity to invalidate recompiled code while not really writing anything to emulated memory). Anyway, there is still a room for optimization (more some global optimizations for recompiled code... yet it might take too much time to recompile, thus wasting the positive effect in some games, when the recompiler will be running out of memory for recompilation too often and will have to start anew). But for now I'm quite pleased with what I get (except for terrible sound ). Most of the games I play run faaaar above 100%.

[ffgriever]

I've finally fixed the freaking sound issues. Now, as long as the framerate is quite decent, the sound is almost perfect (though it's still too much CPU consuming yet - I'll work on it later, as for now I'm glad it finally works fine). I've got some issues to be fixed in this week's schedule. If I'll manage to do that, I'll post a new version. Framerate limiter, working sound (which also fixes some games, like Valkyrie Profile), a lot of gfx fixes, some cpu fixes. Plus one more, quite important. Now NTSC games that use a lot of 2D graphics, will look fine (if launched in NTSC mode, earlier only PAL games launched in PAL mode were looking fine). So no more black borders and stuff, as long as I'm launching NTSC games in NTSC mode and PAL games in PAL mode. I'll fix crossmodes later (now they're trying to maintain original aspect ratio, which screws the gfx a little bit, so I'll add the option to ignore original aspect ratio yet make the games look a little bit better... A real fix may come later).

[ffgriever]

Unfortunately, the new SPU emulation isn't that good as I thought it was. In some games it works almost perfect, while in others it's still a crap. The main problem right now is that it's software spu, so it requires a lot of cpu resources to emulate the sound (depends on number of voices that are playing and speed of the game... the slower the game works, the more sound it has to process, and the processing takes more time, thus slowing the game further, making even more sound processing to be necessary - but at least it scales quite fluent to the framerate). It has one advantage though. The sound is fine at both very fast and very slow fps (and perfect at exact 100% rate). The previous (hardware one, the PSX's SPU and PS2's SPU2 are very, very similar, almost the same), worked good only when the fps was exactly at 100%. If it was too fast, the sound has been becoming a cacophony, when too slow, there was a lot of stuttering, clicks and weird sounds.

I think the hardware sound emulation (more like translation) is the one I'm going to concentrate on in the future, as it almost doesn't decrease framerate at all... But right now I don't know how to properly handle cases when a game works too slow (the sound really hurts my ears )... When it's too fast, it's not a problem (frame limiter, though even now, when the limiting is not perfect, some clicks happen).

Yet I'll publish my current build anyway (both versions with sound and without sound - something like "null plugin" on pc emulators... here the plugin can be changed only at compile time ).

[ffgriever]

I was sending everything through IOP though. That required additional buffer to queue SPU stuff before sending it to IOP once in a while (otherwise the speed was suffering terribly). I forgot I could access the hardware registers directly, getting interrupts is also not a problem... Unfortunately they're not exact same, though I have a good grasp of the changes (couldn't find SPU2 docs, so I was comparing to SPU2 plugin for pcsx2 - not really the best way, but it worked to some extent... also checked already available libs). Anyway, it might simplify things a little bit.

[ffgriever]

It's a doc that anyone interested in PSX have certainly read at least once . As for the thread. There is no way to switch SPU2 into SPU (at least not one that I know of) without switching entire IOP into PSX compat mode... But then it's of no use to me, as all the ps2 devices seem to be no longer accessible (or the hardware registers are mapped elsewhere). It has one advantage though. Most of the hardware doesn't have to be emulated then, including most cpu hungry CPU emulation . But then again, the purpose of this emu is to use all of the PS2 capabilities (usb/hdd/lan, improved graphics), otherwise it is pointless (there is already a built in one that, even though it has some problems and doesn't do as well as the real PSX, works great). Thus the cpu is being emulated on EE (recompiled code), just as in any other emu, while the IOP serves its role .

PS.
The emulator used in BBNAV to launch mini PSX games does the same thing. It seems it emulates everything on EE. This made me believe, that there is really no way to maintain PS2 capabilities in PSX mode (otherwise sony would do that in their emulator, but instead they've chosen to do a software emu) - as a side note: the simple titles that were using their emu already do work great on mine at a huge speed way over 100 fps . I'm quite interested, how their emu (the software one, that is running in ps2 mode) would do with a little bit more complicated games like tekken, driver and such.

Anyway, whether accessing from EE or IOP, I still need to use intermediate buffers for commands to scale it properly for too fast game eg. when emulating one psx frame takes the time of half ps2 frame, then the voices will still be enabled and disabled at wrong places, because it will do everything in half the time it originally should and ps2 will stall for the rest of the time. Sure, the difference won't be that big, it will still be quite accurate (to 1/50 or 1/60 second), so most users wouldn't probably notice it anyway. Yet to make it really proper, you would have to save every command along with the psx cpu cycle it occured on. Once the buffer reaches some length (spread in ms or cycles or at the end of every frame), it should be scaled based on the real time that have passed. But that would introduce a latency between the time sound was to appear and when it will be actually audible... This might probably be even worse than letting the other thing happen (though that would be max 20ms, so not such a big deal). I'm not sure now which one would be better. Will have to decide on one of them before trying it again (right now I'm using ~50-100ms realtime buffer for commands in the hardware SPU - depending on the speed and the latency is sometime pretty annoying... the latency is even bigger in software spu emulation).

@all
Polishing off the launcher/configurator. It's very simple, text based (simple menu consisting of text), built on top of the MCA, so it looks quite nice anyway. I simply don't want to waste too much time on it, as it is meant to be temporary solution.

[ffgriever]

There is not that much of progress. I've fixed some gpu stuff, tweaked counters a little bit, added sound... But during recent two years I barely worked on the project. It's only last two weeks or something like that... All of the sudden I felt like doing some coding. Thank god the code is quite clear most of the time (except for some gpu stuff). After such a long time I feel like I'm reading someone else's code

I don't think it should be called a beta, because there is still a whole tone of issues I know about. But does it really matter? It's an improvement anyway.

[ffgriever]

Just in case anyone is still interested...

I was going to fix some stuff here and there before uploading the new preview, but I didn't have time to do that. Also, since I won't probably be working on the project at all in upcoming weeks, I decided to post another preview version. But this time I've included a simple GUI (based on MCA). I didn't have time to test it. I know it has some bugs. One of them is that if you launch it with uLE, the digitize pad option will not work until you'll launch the gui once again using the built in "exit to" ability (just as in MCA, press select in main menu). Some options do not work, others are not finished.

I recommend using PAL mode for PAL games and NTSC mode for NTSC games. Remember to put a proper bios in the bios directory. The bios version shouldn't matter that much. The PS2PSXe seeks for scph7502.bin by default, but it's configurable.

It is still possible to use the emu with ps2client/redshell. There are two versions: ps2psxe.elf has sound emulation compiled in; ps2psxen.elf is compiled without sound emulation (thus is faster). All switches are the same as in previous preview, but there are few more:

-limit - enables frame limiter

-nothread - disables threaded mode. In threaded mode the sound emulation is usually faster but less accurate.

-spuirq - some games require it (like valkyrie profile) - might be slower


All files included are necessary to start the emu (remember, the gui is just a launcher!).

Oh, there is a reset combo L1+L2+R1+R2+UP. It will try to relaunch the gui (it has to be in the same dir as the emu). The screenshot combo also works (AFAIR, Ls+Rs+Circle+Triangle).

!!!The lng file has to be utf8 encoded to work properly!!!