What is Play! ?
Play! is an attempt at creating a PlayStation 2 emulator for the Win32 platform. For more information about this project please visit the "About" section of this site. If you're looking for a working and mature PlayStation 2 emulator, I'd advise you to check the other emulators available in the "Links" section.

Development Log

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.

Grandia Optimizations
Posted on 2012-01-09 23:06:36
I added the missing VU instructions that were needed by Valkyrie Profile 2 and also fixed a problem happening because of I wasn't flushing recompiled blocks spanning a memory area that was being rewritten on by the game code. I couldn't get something to display right away because there was a lot of weird black sprites being drawn on the screen... Probably because they are used to clean some render targets or something like that. But after deactivating the black sprites I was able to see the main character being rendered without too many glitches.

Screenshot #000229Screenshot #000230

The main issue was now that there wasn't any level in the background... I have no idea what happened there, but there's simply no level being displayed (and probably loaded). The character also seems to be falling down in the void for a moment, hence the trails you see in the screen shot. But, I didn't let that bother me too much because I first wanted to find out why most of the triangles were being generated with a black color (for the clouds in the main menu for example).

I tried to analyze the VU program that was generating the commands to draw the triangles and found out that it was modulating all the input colors of the geometry with some kind of global ambient color. So, I tried to see where that color was being set in the game code and found a function that is supposed to compute that ambient color value, but I found out soon after that it was never called. I looked around, but I couldn't find anything that would give the correct result.

So, I kinda gave up on Valkyrie Profile 2 for the moment and decided to try Grandia 2 instead which is a bit simpler.

Screenshot #000231Screenshot #000232

There wasn't any major hurdles to get that game running to the point where you can run around in the field. The biggest problem was again the video decoding parts that aren't working at all in this game. I had to patch them out to be able to see the interesting parts of the game... Even then, I had to let the emulator run overnight to get to the first part of the game since the intro movie is unskippable and quite long.

The 3D stuff pretty much worked without any change in the GS handler code which was a bit surprising. I also took the time to fix some problems in my LIBMC emulation that was preventing the game to load and save data to the memory card. The game doesn't run perfectly as there's still weird texture mapping bugs happening when you play for a bit too long but it's not crashing or anything like that.

Seeing that this game was working pretty well, I decided to dive into some optimization related matters to make it work faster. I tackled a few bottlenecks already, one being the need to call a memory read or write routine 4 or 2 times (for quad and double words respectively) in the recompiled code which I could remove by adding memory access routines that can manipulate bigger data sizes. This optimization gave a little boost of 2 fps in Grandia 2, which isn't much, but still nice to have.

I also found out that I could start the execution of a VU microprogram immediately in the MSCAL/MACALF/MSCNT VPU operations to save some time (around 1 or 2 fps). The last thing I did was to get rid of this strange recompiled block addressing scheme I put in place early on in the development of the emulator and replace it with a much simpler 2-level table addressing scheme. This also gave a small fps boost, but not as much as the other 2 optimizations.

The next thing I want to change is the way I emulate the pipeline delays for the Q and MACflags registers. When looking at the recompiled VU code, I saw that there was a register pipeline check generated at every instruction, even for NOPs or blocks that don't even use those registers, which doesn't make much sense since nothing related to them needs to be computed. I'm sure there's a smarter way to deal with this. I don't know if that's going to give a huge fps increment, but I have good hopes that it should help since the VU microprogram execution seems to take a lot of time according to my profiler.

Updates coming soon (or not so soon...)

Valkyrie Menus
Posted on 2011-11-13 14:39:00
As promised, I went back to work on Play!. I continued my work to get Valkyrie Profile 2 to run properly. To make it run a bit better I had to fix a bug in the way interrupts are handled, force basic blocks to be destroyed when the game is writing at their RAM location, make the analog stick work in the DBCMAN IOP module, implement missing system calls in both the EE and on the IOP sides and add support for some more VU instructions.

I also had to implement some hacks to display what's rendered at a specific frame buffer address because this game seems to use the rendering output as a texture to be drawn on a full screen quad, which is something I can't really handle in my OpenGL GS renderer right now. I also had to ignore vertex colors because everything was being drawn with a black color.

All of this allows me to navigate in the title menu without too many problems:

Screenshot #000225Screenshot #000226
Screenshot #000227Screenshot #000228

Some notes about the first and the last screen shots:

The actual title screen of Valkyrie Profile 2 has a white background and some moving clouds. I don't know why we don't see any of them, but I can see the mesh used for the clouds if I enable the wireframe mode. There's also something being rendered off screen in the right which also looks like clouds, but I have no idea why it's being drawn there.

The last screen shot shows the prompt used to skip the first movie. I disabled movie playback in the game, so, that's why we see garbage there. If we let it run, we can see the sub-titles and credits being drawn over the video.

After skipping the video, the game starts preparing for the first cutscene. It was using a lot of missing VU instructions that I had to implement and it also triggered a bug with VCALLMS which I fixed. But after that, the emulator crashes because the game feeding some weird data to the GIF through a DIRECTHL command. I'm looking into it and I hope that I'll be able to see some in-game action after this.

<< Older Log Entries Newer Log Entries >>