What is Play! ?
Play! is an attempt at creating a PlayStation 2 emulator for the Win32, OSX, iOS and Android platforms. For more information about this project please visit the "About" section of this site.

Development Log

Android WIP - Continued
Posted on 2015-05-31 22:29:00
The latest Android weekly is now able to run Final Fantasy X! Here's a video showing a battle running on a Xiaomi Mipad:

There's still a lot of work to be done, but we're getting there! Grab the latest weekly on the weekly build repository!


Android WIP
Posted on 2015-05-21 22:07:48
Play!'s Android port is getting along well. Some commercial games are now playable (with limited speed) on an actual device!

Compatibility is very low (only a few games have been reported to work), but if you wanna try some games, you can grab the latest build on the weekly build repository. Enjoy!

Play! Weekly Builds - OSX builds
Posted on 2015-03-29 19:33:18
Hi again,

Mac OSX builds are now available on the weekly build repository.

Again, don't hesitate to report any issues you might find on the official GitHub page.

Happy testing!

Play! Weekly Builds
Posted on 2015-03-22 19:30:32

Development of the emulator is still going forward and in order to make the latest additions available to everyone, weekly builds will now be available in that space:

Only Windows builds are available at the moment, but OSX and Android builds will follow soon.

Don't hesitate to report any issues on Play!'s GitHub page.


PsfPlayer v1.02
Posted on 2014-07-03 20:51:02
I've posted an update to PsfPlayer today which puts back in Windows XP support, adds high DPI awareness and fixes some bugs in order to support more PSF sets. It's available on the downloads page.

The downloads page was also updated to include links to the official Play! Git repositories. You can witness the work that's still ongoing on the PS2 emulator over there.

I know I haven't been updating this site much, but I'll try to post a status update soon.

PsfPlayer v1.01 and a bit more
Posted on 2013-08-07 01:00:26
Small update on PsfPlayer today. I fixed a bug that prevented any tracks from the Berwick Saga PSF set from playing. This version also fixes a problem that could occur when reading some ZIP files that had extra information in their directory headers. Warning: PsfPlayer now requires Microsoft Windows Vista and + since it was built using Visual Studio 2012. As usual, you can get the latest version on the downloads page.

In other news, I had a copy of "Final Fantasy XI: Seekers of Adoulin" data disk laying around on my desk, so I decided to see if I could create a PSF set containing the new tracks for the game. The results were positive. Enjoy!

Untamed Arms
Posted on 2013-03-12 22:00:53
So, I've been busy working on various projects including my emulator and I recently got Wild Arms: Alter Code F to run. I ran into lots of problems as always, but I finally got it to work without any patches.

Screenshot #000238 Screenshot #000239 Screenshot #000240
Screenshot #000241 Screenshot #000242 Screenshot #000243

As you can see, the title screen is working perfectly, but that's the easy part.

If we leave the title screen running for a while, it's going to change to an introduction movie, as seen in the second screen shot. I did my best to make movie playback more stable, but it's still problematic. I removed all the threading stuff that was present in my IPU emulation module and made it a bit more error resilient by trapping VLC and bit-stream errors. I also enabled SPU emulation and fixed some problems with what I think is the "streaming mode" because the movie playback engine in the game is trying to keep up with the SPU somehow and requires proper feedback from it. I also improved the movie decoding speed by forcing DMA transfers to the IPU to always execute when the input FIFO is not completely full. The end result is something that kinda works, but still suffers from corrupted macroblocks and other random hiccups. But I don't need to disable movie playback with a patch to go further in the game, which is a good thing.

Before getting to the point of the third screen shot, I had to fix a problem with the instruction cache not being flushed properly. I forced it to be flushed when a recompiled area is being loaded with data directly from the IOP CDVDFSV module. I don't know why, but a lot of games seem to enjoy loading code overlays...

The rest of the screen shots are from actual in-game action. Looks kinda crappy for now, probably because of incorrect flag handling on the VU, but my next goal is to see how I can fix that without breaking other games.

PsfPlayer v1.00
Posted on 2012-11-28 01:07:49
Hello again, here's a new PsfPlayer version. This utility made it to the glorious stage of being a 1.00 version. Why? Because most of the annoying bugs that was making the player sub-standard are now fixed. There shouldn't be any weird sounding samples in the Final Fantasy PSF sets and sudden slowing down when playing streamed tracks.

Get it now on the downloads page!

PsfPlayer v0.55
Posted on 2012-08-12 15:13:20
I have updated the PsfPlayer utility with some minor bug fixes and additions, such as fixed playback speed for PlayStation2 Square-Enix games such as Final Fantasy 10, 11 and 12 and Kingdom Hearts, better looking playback control buttons and visual feedback for the currently playing item in the playlist.

The fixed playback speed part is a nice side-effect coming from changes I've made to the root counters emulation in Play! when I was working on Unreal Tournament.

In any case, you can grab it on the downloads page.

A Question of Perspective
Posted on 2012-04-21 14:12:57
So, after that last update, I got around implementing a better way of simulating the Q register and MAC flags pipeline without updating the status of the pipeline at every instruction. It gave a nice speed boost, but it's going to get trickier to make the MAC flags emulation accurate with that kind of system. But I think I'm going to leave it as is for now since it gives pretty good results nevertheless.

After that, I decided to make Unreal Tournament work on the emulator. It was one of the first games to be released on the PlayStation 2, so I thought it would be rather simple to run.

First, I ran into some issues with my high level emulation of the CDVDFSV IOP module because the version used by this game was using a different structure layout than the one I was providing. I also had to implement event flags in the IOP BIOS because the iLink (a.k.a. Firewire) module was using them heavily. I also got rid of the LIBSD high level emulation part because it wasn't complete and also because I thought it would be ok for the games to call their own version directly since the SPU hardware is emulated properly right now.

Screenshot #000233 Screenshot #000234 Screenshot #000235

I also had to implement the "LoadExecPS2" system call because this game uses a strange scheme to switch from the main menu to the game. When you start a new game in Unreal Tournament, the game is completely reloaded from scratch with parameters that tells the program to load a specific map and select specific game options that the player chose in the main menu. I guess they did that because they didn't want to deal with memory leaks or memory fragmentation problems.

I then finally took some time to look into the texture perspective correction problem I had for a long time. It wasn't too hard to fix after all and 3D games looks much nicer now, as shown in these screen shots from Half-Life:

Screenshot #000236 Screenshot #000237

But a few fundamental problems persist my emulator that prevents Unreal Tournament from running properly. The first problem is the usage of paletted textures which I handle by converting the index map into an RGBA map that I send to the video card driver. This is a problem for this game because they change the palette many times in the same frame causing the cached texture to be flushed every time they use it with a different palette. The solution to this problem would be to do the index->RGBA conversion in a pixel shader and only upload the index map to the video card.

The other problem is that the game also uses a kind of texture caching system that works with a 1024x1024 texture they update every time a new texture is needed for their render. So, each time they update their cache, I have to invalidate mine and upload the new 1024x1024 texture when it's needed. Computing dirty rects and updating only the dirty parts of the textures would probably fix this problem, but it could also be a problem depending on the area where that final texture is stored on PC (either in system or video RAM).

I quite happy of the results anyways. This game helped me clean some parts of the emulator which weren't very good. This will surely help when I'll be making other games work.

<< Older Log Entries Newer Log Entries >>