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 "quake.elf" work.
Posted on 2005-10-26 00:00:00

The next task is to make a PS2 port of Quake/Quake 2 work. This is only a port of the software rendering engine though, so no "hardware" triangle rasterization is involved in this. It's supposed to use the USB interface for keyboard and mouse input too.

It doesn't work right now because some MMI instructions are missing.

Using the FILEIO IOP module, it writes to stdout (file descriptor no. 1). I'm not really sure about the way to handle these writes, but they're redirected to a text file for now. It also uses this module to load the Quake data files from the host device.

I wanna try to work on that generalised MIPS disassembly system that will solve the problem with disassembling non-standard instructions (ie.: that aren't included in the MIPSIV standard). Right now, the disassembler is only a very big "switch/case" statement so there's no way to modify the content of the table at run-time.

I'd also like this development be the last one before the first release of the emulator.

Make "plasma_tunnel.elf" work.
Posted on 2005-10-25 00:00:00

Decided to use some wierd z component computation scheme. If the z value is below 256, it's scaled down to [-1, 1] as if it was coming from a range of [0, 65536], otherwise it's scaled down normally as if it was coming from a range of [0, 4294967296]. A problem with z values downscaling is that we're sure that we're going to lose some precision and end up getting wierd results (like z-fighting). And if the "below 256" condition starts breaking some stuff, I'll probably remove it even though it would make the "CubeMastah" demo not work anymore. I'm just trying to find the solution that will make the most people happy. The current method works with both demos, so it's fine for now.

This concludes (pretty much) what I had to do for this demo. There's not much I can do about the screen update desynchronization for now. I think it might be a good argument for implementing a "flip when needed" technique, but I'm not quite sure I want to implement this because the condition needed to flip isn't justifiable: You can read the CSR for other reasons than waiting for the v-blank flag to be set... And there's no straightfoward way to obtain the true intend of the read.

Make "plasma_tunnel.elf" work.
Posted on 2005-10-24 00:00:00

Fixed the STQ texture coordinates problem. Apparently, S and T were to be divided by Q to give "normal" texture coordinates.

I've been trying to find out how to accomodate both high and low z values in the z-buffer. The projection matrix set by glOrtho didn't help much, so I crafted my own projection matrix that won't touch the z value given to glVertex. But it all comes down to a precision problem... The z values I need to give to OpenGL must be in the range of [-1, 1] and the z values I receive from the GS are in the range of [0, 0xFFFFFFFF]. Very small numbers divided by 0x7FFFFFFF don't give much and maybe they get rounded somehow and get assimilated to 0. Well, for now "CubeMastah" is broken. I'll investigate a bit more and try to find a viable solution.

I've thought a lot about the recompiler and came to the conclusion that I'll need to improve its design really soon. I haven't come up with another idea yet, so I'll keep thinking about it.

After I find a solution for the z buffering problem, I'll be able to move to another demo.

Make "plasma_tunnel.elf" work.
Posted on 2005-10-22 00:00:00

Implemented instruction BLTZL.

Fixed the GS handler so it can continue taking vertices after 3 vertices has been specified for a triangle primitive.

Added support for PRMODE, PRMODECONT registers and added basic support for the ST register.

Here's the result after those things in:

There's still some problems right now though...

- Texture mapping is wrong. I don't know if it's due to the clamping mode not being set correctly, because it writes something in the CLAMP register when uploading the texture. There's also the Q component of the texture coordinate that I'm not taking in consideration... I have no idea what this component should be doing and if it would have an impact in the case of this demo. But it's not set to 0 though, so maybe there's some important information there... Looking through the code would probably give me some more insight about this component.

- The Z component of the vertices are really big (in the order of 10^9). This goes a bit against the hypothesis I've made while working on the "CubeMastah" demo. I'll need to find a solution that accomodates both demos, as the only thing I'm doing right now is dividing the Z component by 0x10000000 when drawing a STQ/textured triangle.

- The demo takes a lot of instructions to render its scene completely. If we use the hypothesis that the PS2 EE runs at 250MHz and that it's able to execute at most 4166666 instructions for each frame, this demo would still be unable to make it to provide a frame at each 1/60 of second. Because this emulator uses a fixed number of instructions to decide when to swap buffers, we see all of the scene being rendered if I use a small number of instructions (500000 -> 30MHz is the number I was using for all demos). Using a big number is going to penalize other demos and will just make them wait for no reason. A technique used in nSX2 is to swap buffers each time the CSR register is accessed, making sure the programs don't wait too much or that the emulator swap buffers too much, giving interesting results. In most of the demos I've seen, the CSR is accessed only in the loop that waits for the start/end of the v-blank period, but I don't know if the framework used for commercial games works this way too, so I'm not really sure I want to implement something like that.

I'll try to have at least the texture mapping problem fixed for the next time.

Make "plasma_tunnel.elf" work.
Posted on 2005-10-21 00:00:00

This demo simulates some fancy tunnel with pretty colors. It's a port of an existing demo that's available on www.sulaco.co.za. Here's what this demo should be displaying:

Win32 version of this demo running.

First time I executed it, it was doing some wierd stuff with the SIF routines: Sending bad commands (0x08000000), accessing bad registers (0x08000001). Most of the command and register IDs that should have thier most significant byte set at 0x80, had it set at 0x08. I tried to make some changes to the SIF emulation code to be able to process those commands, but another wierd thing was occuring... The structure that needs to be filled for the 0x80000002 (INIT) command wasn't filled properly. Instead of using SW to write the members, it is using SB...

Looking through the program disassembly, I didn't find other stuff using the SIF except the main function calling the RPC initialization routine. The initialization code doesn't make sense at all, and I'm assuming it is broken for some reason. So I'm gonna keep the thing I've changed to the SIF register handling for now, and if I encounter another program that use odd values like those, I'll reconsider.

After fixing the SIF stuff, an unhandled instruction occured (BLTZL). I'll need to implement this one tomorrow. But even if this instruction wasn't there, it was able to execute normally.

It needed the "NEVER" alpha testing condition, so I added this one. I also fixed a small bug with the TEX1 register decoding.

Now though, it's doing stuff that I'm not supporting for the moment. It uses the PRMODE / PRMODECONT registers. PRMODECONT controls from where the primitive properties (texture mapping, alpha blending, etc.) are to be taken (either from the PRMODE register or from the PRIM register) and PRMODE contains the value of those properties. It also sets the PRIM register only once and feeds tons of vertices to the GS to generate primitives, something that I haven't implemented yet.

Those aren't going to be hard to do, so I should have them done tomorrow.

Make "PS2 Invaders v1.6" by "InPulSe Team" work.
Posted on 2005-10-17 00:00:00

Implemented the missing functions (write and opening with read/write/create flags) in the FILEIO module. This makes the high score saving work.

I still don't know what I'm gonna do about the texture upload abuse yet... If I can't think of something better tomorrow, I'll probably be moving towards another demo.

Make "PS2 Invaders v1.6" by "InPulSe Team" work.
Posted on 2005-10-16 00:00:00

Implemented some basic support for pad input handling. Nothing really fancy there... A class that wraps the input API (DirectInput in this case) processes keyboard input messages, translates the key to PS2 pad buttons and sends those messages to the PadMan IOP module.

Fixed some problems too with uninitialized variables in the PadMan module.

Implemented instruction NOR in the MIPSIV core.

With those things done, the game is now playable. Except that it's running really slow:

I know why it's running slow: It's because this demo abuses texture uploading. It'll upload a texture for every "sprite" in this image, except maybe for the font which it does one time. I don't really know how I could make go faster though... Maybe implementing texture caching at the DMA level would work, but it would probably be risky. Maybe the DMA copy loop could be improved too. But besides that, there's not much I can do...

All that remains now is just to make sure that the demo can succesfully write its high score file to the memory card. I'm not planning on making the sound work for now. After this, I'll be able to move to another demo.

Make "PS2 Invaders v1.6" by "InPulSe Team" work.
Posted on 2005-10-15 00:00:00

Fixed the pitch of GS image DMA transfers. This allowed me to revert to the initial fix for the pitch in texture uploading, which should be the right thing to do.

Make "PS2 Invaders v1.6" by "InPulSe Team" work.
Posted on 2005-10-14 00:00:00

Fixed the problem with the main title texture. It had nothing to do with the texture address, but it's a fix I'm really not sure about. The TEX0 register associated with this sprite primitive specifies a texture whose incoming buffer is 320 pixels wide and specifies a texture width of 512. The given width is 512 because it's the nearest power of 2, but the texture is 320 pixels wide in reality. To make the texture upload correctly, I changed the texture upload code so it specifies a texture row size, to OpenGL (using glPixelStore), equal to the given texture buffer width in the TEX0 register.

But this broke sereval demos. One of them use a buffer width of 512 with a texture size of 256. Specifing a pitch of 512 is wrong because the texture present in RAM has a pitch of 256 pixels. So, right now, I'm currently using the minimum value between the buffer width and texture size.

Humm, but thinking this over, I think this could be related a problem in the DMA transfers. You can also specify a pitch while transfering pixels... So fixing this DMA transfer problem would probably allow me to revert to the first fix idea (which is more logical). I'll work on that tomorrow... But anyways, here's the result with the current fix.

I'm not still sure about the way to implement the user input stuff. Sending keyboard messages to the IOP module seems like the easiest idea, but wouldn't work well if I'd want to support joypads because it would need to translate those into keyboard messages. Maybe I'll opt for a solution where the button configuration is located at the UI level and have button messages sent instead of raw keyboard/joystick messages.

Make "PS2 Invaders v1.6" by "InPulSe Team" work.
Posted on 2005-10-13 00:00:00

Implemented instruction BLEZL.

Handled system call "SifDmaStatus", even though I don't really know what it does, because the memory copy code (from EE to IOP) needed to know when the DMA transfer is completed.

Added basic FILEIO module functions (open, close, read). This demo only uses this module for reading/writing high scores into the memory card and also for reading the MOD (Amiga Music Module) off the host device. Those aren't really necessary for now though.

After all this work, that's what I'm getting:

The texture that's supposed to be the title screen is kinda screwed up. Apparently, it's because it's not giving away the right pointer for this texture. I'll have to check that out a little more in depth tomorrow. It also blocks waiting for the start button to be pressed, so I guess I'd better start thinking of the way I'm going to implement user input.

<< Older Log Entries

Newer Log Entries >>