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-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.

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

Implemented VU instructions ITOF0, IOR, ISW. The code generated for ITOF0 is a bit ugly, but I'll come back to it when working on optimizations.

Tomorrow, I will work on FMAND.

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

Fixed some stuff in the VUF (Vector Unit Float) code generator class. More specifically, I learnt about the difference of SSE and SSE2 today and about how SSE has 128-bits SIMD operations on floating-point values only and SSE2 has both floating-point and integer 128-bits SIMD operations... Quite odd, but I have no choice but to comply to this "standard". So I removed the use of SSE2 instructions to fallback to equivalent (MOVDQA -> MOVAPS, MOVDQU -> MOVUPS) instructions on the SSE in order to keep only one instance of the code.

Implemented VU instructions SUB, SUBbc and IBEQ.

There's three instructions that are left to implement. ISW should be a piece of cake, ITOF0 shouldn't be hard either when I figure out a way to convert floating point numbers to integers using the SSE... But FMAND will require some important changes. I'm still not sure about the idea to use though... We'll see tomorrow.

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

Not much today. Implemented VU lower instructions MTIR and IBGEZ.

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

Completed the double buffering stuff in the VIF implementation.

Fixed a bug with ILW.

Added VIF decompression method V4-5.

The two first changes made the two previous scenes are differently and in a better way I think.

This new scene uses a different VU microprogram again. I filled the necessary reflection table entries to allow the diassembly.

There isn't as many missing instructions as the previous one though, but it uses a status flag testing instruction... I don't really know how I'm going to implement this one, but I know I don't wanna go into saving the status flag register each time a FMAC instruction is executed. But to achieve this, some kind of analysis will be required...

Well, I'll think about it and try to come up with something tomorrow...

<< Older Log Entries

Newer Log Entries >>