![]() |
![]() |
![]() |
![]() |
![]() |
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' playable.
Posted on 2006-02-07 00:00:00 |
Implemented PSRAH and finished QFSRV.
Tried to fix the data filling problem with setjmp and longjmp, but it didn't work at all. I tried one of my other solutions that consists on evaluating the risk of being out of data while executing a command, to not process the command immediately if there's a one, and cause the program to send some more data. It fixes the infinite loops, but the movie playing still seems to be screwy from times to times... But I did that now to make sure that the decoded frames weren't corrupted by this problem and that the bad frames weren't caused by this. I'll come with a more complete solution when I'll finally get around fixing the frames. Fixed a bug with CSC that caused the red and blue bytes to be inverted in the pixel. That was causing the logo to be red instead of blue. Fixed a block output order problem with BDEC that was causing a part of the screwed up picture. Now, that's what I get: Oddly, I get both frames while playing the movie and it seems to jump from one to the other randomly. But the right one is perfect and the difference with the left one seems to be that the macroblock columns are reversed by pairs (ie.: columns 0 and 1 appear as 1 and 0). If we look closer, we can see that this only affects Y blocks because the Cb component seems to remain at the same place. It doesn't seem to be a problem with the MMI instructions either because the bad frame seems to occur only on I pictures and the good one occurs on predicted (P or B) pictures (taking the hypothesis that the MMI isn't used much on I pictures)... Well, I'll be investigating this tomorrow... |
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-02-06 00:00:00 |
Implemented one of the two missing instructions: PSLLH. The other one is PSRAH and should be easy to implement too. I've seen some uses of the QFSRV instruction with SA not equal to zero, so I'll need to fix that too.
I'll try to have PSRAH and QFSRV done tomorrow. I've also found out what was causing the infinite loop... The problem is that the FIFO gets totally emptied and that the DMAC has finished to transfer what it had to transfer to the IPU. What would probably happen normally is that the MPEG decoding library would wait till the BUSY bit of the CTRL register is cleared, but would end up calling the custom handler for restarting the DMA transfer since the command is hung. But allowing this kind of behavior means that some commands could be interrupted at anytime during its processing since all the processing is done at one time by one function call... If VDEC was the only command that could be interrupted, it wouldn't be too bad, but BDEC needs to be interrupted too. I have some ideas as to how to deal with this (longjmp/setjmp being the most tempting one), but I'll ponder this a little bit more before doing anything... |
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-02-05 00:00:00 |
Added a stub for the LIBSD IOP module and implemented a function that's supposed to report an increasing number of bytes each time you call it. It's really cheaply done right now, but it allows the sound processing functions to drain the sound buffer properly.
Added support for the NEXT command in DMA tags. Fixed a little bug that was causing a function to misinterpret the MP1 bit of the IPU_CTRL register. That was causing the DCT coefficient decoder to fetch the escape code in the MPEG-2 way and not in the MPEG-1 way. The game can now continue the processing of the movie files and is starting to show more interesting stuff: It's still a bit screwy though. We gotta keep in mind that the QFSRV instruction isn't implemented properly. There's also more unimplemented instructions that showed up. So, I'll be fixing these tomorrow. The movie playing isn't very stable either... It won't end properly, as in, it will hang at the end of the movie, and some movies make the emulator hit an infinite loop. I'll be checking those after I'll have perfected the graphics in the movie playback. |
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-02-04 00:00:00 |
I think I found what was causing the data production problem.
The program allocates a buffer of 0x50000 bytes at the beginning and always fills it with 0x10000 bytes (32 sectors) worth of data from the PSS file at each iteration of the movie playing loop. A pointer to this buffer is then handed to a library function that has the task of parsing the MPEG system stream. When this library finds video or sound data in the buffer, it calls user-provided functions that has the responsability to store the data in other buffers. The problem lies on the sound side of things. It seems that the sound buffer isn't drained properly and this keeps the MPEG system stream parsing function from continuing properly. So no more data can be read from the DVD because the DVD read buffer is full and the video decoder thread doesn't have any data to play with. I'll be looking into the sound playing functions to see if I can make it drain the buffer properly tomorrow. I'll probably need to add a stub for the LIBSD IOP module to achieve this. |
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-02-03 00:00:00 |
Added support for DMA channel 9 (toSPR) because it was required by the motion compensation code to load the blocks from RAM to SPR.
Implemented instructions MTSAB, PEXTLB, PEXTUB, PSRLH, PCGTH. PEXTLB and PEXTUB were again a bit annoying to make work on the SSE target because of the register length difference. The program also uses the instruction QFSRV that's supposed to shift a 256-bits word (which is a combinaison of 2 normal 128-bits registers) right by the amount specified in SA (which is set using MTSAB and MTSAH). That's probably used to offset a block horizontally having the two lines of two adjacent blocks stored in the registers. Because it would be a bit annoying to implement right now and because the value of SA used when I came across the instruction was 0, I just implemented it as if it only could do the shift with SA equal to 0. I'll come back to this instruction when the movie will be able to play completely. Also isolated all the integer VU (MMI) stuff in one seperate module and decided that this module would have its own virtual stack much like the FPU stuff uses it's own stack. I'd also like to isolate all the stuff that generates executable code in a different class than the one that holds the memory space for the instructions, but I'll probably be doing that in the code generator optimization step that I'll undertake later on. I tried to check a bit the data production problem, but didn't find anything significant for the moment. I'll be investigating on this tomorrow. |
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-02-01 00:00:00 |
Found out the place where the program was noticing itself about the rendered frame. It installs an DMAC handler on the GIF channel which is to be called when the frame display list has been done transferring. So, I added support for interrupts on this DMA channel.
But that wasn't enough to make it go further with the decoding. The interrupt handler for the v-blank line was checking the FIELD bit of the CSR and wouldn't set a memory address that would allow the DMAC interrupt handler to do its job properly without having rendered a frame on both even and odd fields of the screen. So, I made the FIELD bit change its value at each v-blank and that did the trick. Bit of a downside about this new thing is that everything else that the game is rendering seems to take this bit in consideration and that it will increment the vertical position of the primitives by one if rendering on an odd field. Added the motion code table to the VDEC command. Added the coded block pattern value decoding in the BDEC command. Now, the decoding can continue properly... But it's hitting another problem later because it seems to be out of data to work on and no one will DMA any more data to the IPU. But before that, it seems to make heavy use of unimplemented MMI instructions to accomplish, what I think is, motion compensation. I'll be working on implementing the MMI instructions tomorrow. |
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-01-31 00:00:00 |
Tested/finalized the CSC IPU command.
Added support for the "destination x position" and "destination y position" members of the TRXPOS register when transfering image data to the GS. These were used when the decoded MPEG macroblocks are transfered to the GS. Made some other minor/esthetic changes in the debugger and in the DMAC module. The game can now display the first frame of the movie, but it won't go any further because there seem to be a problem with the game knowing this frame has been displayed. The interrupt handler for the v-blank line is the one responsible for displaying the frame, so the problem might lie somewhere in its code. I'll investigate on this case tomorrow. |
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-01-30 00:00:00 |
Implemented the CSC command, but didn't have time to test it.
Fixed another small bug with the DCT coefficient decoding that was visible in that last screen shot. Tomorrow, I'll be testing the CSC command and see what's next to be done. |
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-01-29 00:00:00 |
Finally got around ironing the most important bugs with the decoder (ie.: more system marker fixes, quantiser tables stupidity fixes, bad variable addition problems).
I've tried it with a movie from the game that has an interesting I-picture at the beginning and here's what it gives. I should able to add the CSC command emulation tomorrow. |
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-01-28 00:00:00 |
Fixed some more decoding problems in the experimental decoder. Those were due to some system layer markers/data being present at the middle of anywhere (at the middle of a macroblock data bit stream for instance). I created a new specialization of the bit stream processing class and added the parsing of the system layer markers into it.
Now that's fixed, I've been able at last to see the first interesting I-picture of an MPEG bit stream... And it doesn't look very good. I've been playing with the source code of some other MPEG-2 decoder so that it dumps all the decoded blocks into stdout and I can see major differences between thier values and mine... There was a little problem with the default quantization matrix which wasn't of the good type (16-bits integers instead of 8-bits ones), but fixing that doesn't make the picture a lot better. I'll try to make it better tomorrow. |
<< Older Log Entries | Newer Log Entries >> |