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

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

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

Implemented VU instructions MADDAi, MSUBi, MULA, MADDA and MADD.

Fixed a little bug with LOI.

This scene uses antialiased lines to render itself. On the PS2, the anti-alisaing process seems to be tightly coupled with the alpha blending process. If I also check the picture on this site, the lines seem to blended using an additive formula. An additive formula is set prior to rendering the lines when executing the demo. So, I decided to enable alpha blending when antialiasing is enabled in the renderer.

This is the result:

Again, I don't really know if it gives the right thing, but it seems similar to the only screenshot I've seen of this demo. Speed wise, it seems to do better than the first scene at the beginning, but as the number of lines grow, the thing becomes slower and slower...

Tomorrow, I'll check if I can execute the last scene of this demo.

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

Implemented upper instructions MULbc, SUBi, ABS, MAXbc, MULAi, MSUBAi.

While implementing MAXbc, I decided that it was the time to make some use of the host's computer vector unit (a.k.a. SSE) since it would have been bothersome to implement MAXbc with FPU instructions.

I don't see much problems using the SSE to do the job of the VU, except for the flags that are supposed to be updated for each of the FMAC units in the VU and some other instructions that aren't supported by the SSE instruction set (ABS for instance).

So, all further instructions will be implemented using the SSE. I'll go back on the ones I've already implemented using the FPU that might work using the SSE in the optimization development.

I'll continue implementing the missing instructions tomorrow.

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

Modified the executable to make it execute the second scene right after its initialization. This other scene uses a different microprogram which contains a lot more unimplemented instructions though...

Today, I added the missing entries in the reflection tables for the unhandled instructions in this new microprogram. Tomorrow, I'll start implementing them.

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

Added the necessary code to allow some basic debugging and to make the VU1 stop once it hits an instruction with the E (end) bit set.

Implemented VU lower instruction XGKICK.

Implemented VIF code MSCAL.

These changes allow the program to display some stuff:

I have absolutely no clue if that's the right thing it should be displaying though. There's a small particle emitter around the middle of the screen that doesn't do anything, but perhaps it is controllable using the analog stick on the controller.

Another problem is the speed. The thing runs at an awful 2~3 FPS on my computer. One half of the slow speed is probably due to the insane amount of particules on the screen (the program claims to render 4,091,800 particles per second) and the other half to the VU microprogram execution which is executed to generate display lists for all these particles.

Also, if I let the program running, it'll hang... This is probably due to it changing microprograms to render a different scene.

Tomorrow, I'll try to change the executable to make it execute the other scenes directly and see what it gives.

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

Implemented lower instructions DIV, WAITQ, LOI, ISUBIU and IBNE.

Implemented upper instructions ADDbc, FTOI0, MULq, MUL, MULi and FTOI4.

The only instruction that remains to be implemented is XGKICK. After checking what's in the memory at the address pointed by the operand of XGKICK, I saw that what's in there is actually just a normal GIF packet starting with a GIF tag. So implementing XGKICK will just be a matter of relaying the address of the GIF packet in the VU memory to the GIF implentation for processing.

But before implementing this instruction, I need to figure out a way to allow running the VU for more than 1 instruction to allow more interesting debugging with breakpoints. I'll be working on that next.

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

Implemented VU lower instructions XTOP, ILW, IADDIU, LQ, SQI, LQI and IADD.

Implemented VU upper instructions MULAbc, MADDAbc, MADDbc and ADD. Those were just a matter of isolating the current implementation for these instructions from the COP2 implementation in a shared module and calling the functions.

I found a solution for the branching problem too. Instead of having the actual branching instructions trigger the branch checking code, I'll check if there's a branch instruction 8 instructions prior to the one currently being compiled and trigger the branch checking code if one is found.

I also added a quick and dirty RLE compression scheme for saved states. Any other method would probably way more efficient, but the RLE compression will be fine for the moment as it always generates files smaller than the actual size of the states.

Tomorrow, I'll continue implementing the instructions in the VU.

<< Older Log Entries

Newer Log Entries >>