Play! - Development Log

Play! is a PlayStation2 emulator for Windows, macOS, UNIX, Android, iOS & web browser platforms. For more information about this project please visit the "About" section of this site.

Fetching compatibility status...

Prepare the v0.20 Release
Posted on 2006-03-28 00:00:00

Cleaned about half of the VUI128 code generator module. I'm going to complete the second half tomorrow.

Prepare the v0.20 Release
Posted on 2006-03-27 00:00:00

Moved all the code generator classes in the CodeGen namespace and removed all dependencies of the CCacheBlock class to these classes.

Fixed a bug with VUI code generation for MMX targets.

Fixed a small bug that was caused by not setting the MIPS CPU context to zero upon reset.

Changed the way the general purpose registers are stored : Instead of having 4 different arrays of 32 * 32-bits integers, where each array represents one section of a register, GPRs are stored using 32 * 128-bits integers. This will allow us to improve the VUI (Vector Unit Integer) code generator by using movq and movdqa directly instead of having to push all the register sections on the stack before loading it in a (X)MM register.

Converted DADDU to use the new code generator.

Tomorrow, I'll work on cleaning up the VUI code generator.

Prepare the v0.20 Release
Posted on 2006-03-25 00:00:00

I've started working on the new code generator, and rewriting some instructions to use it. I've also optimized some of the epilogue code too.

I also made the tick function unnecessary to call in release builds by moving the vblank control stuff into the main loop.

These changes made Ys go from 6~7 FPS to 9~10 FPS.

Converting all the instructions to use the new code generator could take a while though. I'll try to have the most commonly used instructions implemented for this development and I'll get rid of the old code gradually.

Prepare the v0.20 Release
Posted on 2006-03-24 00:00:00

I've been reading quite a bit about the code generation topic over the past days and decided to scrap my previous idea and go with another one which should do the trick. My idea is to keep track of the virtual stack and generate code based off the information present on this stack. I'll start playing with it tomorrow.

I've optimized the emitted code for the prologue and epilogue of an instruction and removed 5 instructions. There's a visible speed increase, but nothing really significant (maybe an half of a frame).

Prepare the v0.20 Release
Posted on 2006-03-22 00:00:00

I've been working on an attempt to make a different and better code generator (not for the VUF module though). The principle seems to be working, but I'm going to experiment with it a bit more before implementing it for real in the emulator.

Prepare the v0.20 Release
Posted on 2006-03-21 00:00:00

The goal of this development is to clean up everything before the next release.

I also want to improve the code generation in this development to make the emulator faster. My goal is making Ys run at 15 frames per second on my computer with the current cycles per second setting (2x speed) but I wonder if that's even possible. There's certainly a lot of stuff that could be improved though.

There's also a lot of minor stuff I wanna fix/add before releasing this new version.

As for today's work, I converted the remaining VU functions that were using the FPU code generator to the VUF code generator. This didn't have a visible impact on the running speed of the "Slave of the VU" demo though.

Tomorrow, I wanna experiment with a register allocation method in the VUF code generator, even though only one primitive would benefit from it.

Make "Slave of the VU" work.
Posted on 2006-03-20 00:00:00

Fixed the problem with the rendering of the soccer player voxel. It was caused by a really stupid bug that prevented the display lists from being sent when being generated using the second buffer context of the VU, hence making one display list out of two being unable to render.

(The second picture might seem screwy but a special wave effect is supposed to be in effect.)

Also added a little check to prevent the VU program cache to invalidate itself if the microprogram being uploaded is the same as the one currently present in the microprogram memory.

With those fixed, we can now move onto another development.

Make "Slave of the VU" work.
Posted on 2006-03-18 00:00:00

Fixed the text rendering. It was due to the use of XYZ3, which wasn't implemented, instead of XYZ2 for some vertices.

Fixed the colors on the soccer player. The colors weren't showing because the alpha value was equal to 0x80 and this number was multiplied by 2 and fed to glColor4ub which would receive 0x00 instead of a clamped value.

The soccer player is still screwy though. I'll keep investigating in order to find the problem.

Make "Slave of the VU" work.
Posted on 2006-03-17 00:00:00

I finally decided that it would be better to implement the flag calculation at each instruction instead of relying on analysis tricks to skip them... I don't think there would have been a way of getting it to work without more "complex" analysis (like data-flow analysis), and that wouldn't be really practicable at the instruction level. But if I ever get around using a more "standard" dynamic recompilation approach to the CPU emulation, determining the necessity of flag calculation would surely be something to put in there... But that's not for today...

So, I added zero and sign flags calculation to the ADD instruction and implemented the FMAND instruction. I tweaked some things in the VU float code generator too.

This is not really what the third scene of this demo should look like, but it's a start. I had to force the triangles to render white to get this too. The little rotating/zooming soccer player is rendered using colored triangles (no textures involved). The text is obviously totally screwed up and I'll look into fixing this problem tomorrow.

Make "Slave of the VU" work.
Posted on 2006-03-15 00:00:00

I've started to work on the analysis required to check if an update to the MAC flags is required upon the exection of a MAC flag changing instruction, but the current version can fall into an infinite loop if a basic block with a loop to itself is encountered. I'll be working on refining my idea tomorrow.

<< Older Log Entries

Newer Log Entries >>