What is Play! ?
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.

Compatibility Status
Fetching compatibility status...

Development Log

Make 'Ys I & II Eternal Story' able to boot.
Posted on 2005-12-18 00:00:00
Worked a little bit on the "CDVDFSV" IOP module emulation, but didn't do anything significant. I looked around in the code, and I came to the conclusion that it might not be the problem of this being unable to boot: All it does is read some sectors, then check for "SLPS_999.99" and "SYSTEM.CNF" files and do something with the sector position of SYSTEM.CNF. But nothing more than that.

So I turned my attention to a thread that's created by the program later on in the initialization phase. This thread seems to be responsible for initializing a couple of IOP modules at first, sleep for a while and wait to be woken up by the main thread after each vsync. But for some reason this thread fails and is destroyed. So this could be the source of the problem. I tried to change some stuff but without any success... I'll be investigating on this case.

There won't be any updates for a week because I'll be away to visit family for christmas. I'll hopefully have a lot to say when I come back.

Make 'Ys I & II Eternal Story' able to boot.
Posted on 2005-12-17 00:00:00
Changed some stuff to be able to start working on implementing some "CDVDFSV" functions:

- First, the arguments to a SIF RPC call can apparently be modified. For example, the "SearchFile" function will issue a RPC call and read back the arguments buffer to obtain the block address and file size. I dunno how this is possible though... To perform a RPC call, the library first DMAs the argument buffer into the IOP side and sends the command information after. The library never requests the argument buffer back in any way, so maybe the IOP DMAs it back on the EE side. Or maybe it's something specific to this particular function only.

- I also moved the ownership of the ISO9660 object from the "FILEIO" module implementation to the base PS2VM class. This will allow all IOP modules and other potentially interested modules to access the disk without having to know the "FILEIO" module which is a bit more hidden.

These changes should allow me to go further in the implementation of the "CDVDFSV" stuff.

Make 'Ys I & II Eternal Story' able to boot.
Posted on 2005-12-16 00:00:00
Implemented sub-function "kputs" of "Deci2Call" and system call "osPollSema".

Added stubs for "MCSERV" and "DBCMAN". But that didn't change much.

Debugged a bit further in the code and found out some things. This game graphics will probably just be rendered into a local framebuffer and that framebuffer will be uploaded into the GS after each frame is done. That framebuffer is cleared in an initialization phase. The display list that is used to render that framebuffer is also set at the same time. So, the program shouldn't do much on the GS side of things.

I also found out that it uses the "CDVDFSV" IOP module to read a file instead of the much simplier "FILEIO" module (IMHO). But this seems to be working with direct block accesses and such which isn't totally like what I initially thought it would work. Well, I'll investigate a bit more on this...

Make 'Ys I & II Eternal Story' able to boot.
Posted on 2005-12-15 00:00:00
Fixed the interrupt handling stuff a bit... It should be more stable now.

Rewrote most of the GIF module. Added support for the RGBAQ, UV and XYZF2 register addressing modes in the GIF packet.

Fixed a bug with ORI that was mixing a bit the cards on the GIF problems. Fixed XORI at the same time.

Even though now it sends some primivites, all it seems to draw is an empty rectangle. The texture it sends are just pixels set to 0.

I investigated the other system calls I haven't implemented, and it seems to send a message to the console using the "Deci2Call" system call saying that the version of the "MCSERV" IOP module is too old. Guess there's more work to do on this side then.

Make 'Ys I & II Eternal Story' able to boot.
Posted on 2005-12-14 00:00:00
Implemented "GsSetIMR", "EnableIntc", "AddIntcHandler", "WakeupThread" system calls.

Modified some parts to fire a VSYNC interrupt each time the bit for this thing in the CSR is written. The interrupt thing isn't totally correct as it seem to screw the program counter if we use a different timing... So that'll require some work later.

Expanded the current interrupt handler to be able to call the registered INTC channel 2 handlers.

With those, it goes a bit further, but some more problems surfaced.

First, the program is writing some stuff in the SPR (scratch pad RAM) area. This area is accessible through virtual memory addresses 0x70000000 ~ 0x70003FFF, but with the current memory address translator, it conflicted with the hardware registers area since all memory addresses were ANDed with 0x1FFFFFFF to obtain the physical counterpart. I had to tweak the memory translation function to take this particular case in consideration.

It DMAs some stuff to the GIF, but in some cases it uses the source chain DMA mode which wasn't supported. I started the implementation of this mode and I added support for the "END" and "CNT" DMA tag IDs. This seems to be fine, but now the problem seems to be the GIF emulation. The current implementation doesn't play very well with what the DMA feeds to it because it's not very well implemented. I'll probably rewrite most of this part tomorrow.

Also, some textures seem to be used later on, but I couldn't really check what they were since they are 8-bits ones...

Make 'Ys I & II Eternal Story' able to boot.
Posted on 2005-12-13 00:00:00
Implemented instruction MTC0.

Completed the rewrite of the interrupt handler for the DMAC stuff. Everything seems to still work fine after testing with other demos.

Implemented "DisableDmac" and "RemoveDmacHandler" system calls. Fixed some stuff too in "EnableDmac".

Added a panel for the SCU (COP0) in the register view window in the debugger.

Tomorrow: VSYNC interrupts.

Make 'Ys I & II Eternal Story' able to boot.
Posted on 2005-12-12 00:00:00
Started to cleanup/rewrite the interrupt handling stuff. This time, instead of having the interrupts handled by some high level/native routine, the processing will be done by an handler written in MIPS assembly that will be executed by the virtual machine, kind of how they would be handlded if the BIOS would be there. Writing this handler is a bit tedious, but I should be done making what was working before work tomorrow.

Make 'Ys I & II Eternal Story' able to boot.
Posted on 2005-12-11 00:00:00
Tidied up the OS stuff a lot and added basic threads support with semaphore wait and signal. Even with that, it doesn't make the main thread go to a different place.

Tomorrow, I'll work on tidying the current interrupt handling stuff (implement RemoveDmacHandler, DisableDmac) and add support for the vertical retrace interrupt. This should allow it to go a bit further.

Make 'Ys I & II Eternal Story' able to boot.
Posted on 2005-12-10 00:00:00
Fixed system call "EnableDmac" that was writing 1 into the mask value for the specified channel even though this mask bit was already set. That's what was causing the interrupt to be disabled.

Fixed the return value of function "Initialize" of the LOADFILE module.

Implemented instruction POR.

Added a stub for the SYSMEM IOP module that returns a dummy pointer upon the call of its "Allocate" function.

Now, it changes the resolution of the display, but it gets stuck waiting for a memory value to change. Probably waiting for a vertical sync to trigger its interrupt handler.

Tomorrow, I'll try to make a list of unimplemented system calls that this program call, and I'll investigate a bit more the hanging problem.

Make 'Ys I & II Eternal Story' able to boot.
Posted on 2005-12-09 00:00:00
I've cleaned up the custom system call stuff and added a little bootstrap for custom ones. This required the implementation of the ERET instruction.

I've also added the "GetMemorySize" system call.

If we let the thing run right now, it hangs up at binding an IOP module. The problem isn't really with the SIF protocol, or the functions used because they are exactly the same as the ones the demos were using. The problem is that the DMA interrupt is masked for some reason and the SIF response packet cannot be received normally.

I haven't thought about the threads yet, but only one thread is being created, and it doesn't seem to do much, so I dunno if it's worthwhile to go and implement them for the moment.

Tomorrow, I'll try to find out why the DMA interrupt is being masked.

<< Older Log Entries Newer Log Entries >>