|
|
|
|
|
|
| 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-14 00:00:00 |
|
Completed the class wrappers for the partial DMAC rewrite I started yesterday. This oddly seems to have created another instability while playing the first movie, which was caused by a lack of available data to be transfered. I tweaked a bit the "risky" condition of executing a BDEC command to check the amount of quadwords remaining to transfer. This fixed the problem.
I implemented the "ExitThread" system call and added some code that calls this system call in the BIOS area which is called when a thread procedure returns. This fixes the crashing problem when the first movie was done playing and when the decoder thread needed to terminate itself. But it didn't fix the random crashes in the intro movie. I'll try leaving the movie running in a debug build this night to see if I can trap the crash and hopefully fix it tomorrow. |
|
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-02-13 00:00:00 |
|
While doing some debugging to fix the problem I wanted to work on today, I found out that the first movie couldn't play properly because of the DMAC fix I made yesterday (which wasn't really something reliable anyways). So, I figured I'd need to change some things about the mecanics that control the source chain mode. I found out a solution that accomodates both movies and made the appropriate changes. I haven't finished completing the new classes wrappers for this new solution though, so I'll be completing this tomorrow.
As for the problem I was supposed to fix today, I think it's caused by a thread returning from its root function. Since I set RA to zero when I create new threads, it's most likely that the PC would be set to zero too when the thread complete its execution hence causing the problem I was having. Fixing this should be a matter of making RA point to an address memory in the BIOS address space that will contain some code to terminate the thread and re-schedule. This shouldn't be hard to do, and I should have this completed tomorrow too. I don't know why this could happen during the middle of a movie though... It seems to be quite random too as I've been able to see a bit more of the movie today while testing:   
This event doesn't seem to be related to the new DMAC fix since I was able to make it hang at the same place as yesterday. Well, we'll see what fixing the thread thing will do and we'll probably be able to gain better insight at that time... |
|
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-02-12 00:00:00 |
|
After some more debugging, I was able to find out what was causing the problem.
A DMA transfer in source chain mode wouldn't stop properly if it was started with a current DMA tag that is a terminal tag. So, what was happening is that a DMA transfer would be started with a REFE tag in CHCR, wouldn't stop right after and would keep going beyond the REFE tag in memory, which, of course, messed up MADR and TADR and would affect the values of BlockPos0 and BlockPos1 ultimately. I made a quick fix, which seems to take care of the problem and the movie is allowed to go further:  
There's still a problem though that makes the virtual machine hang after playing the movie for a while. I think it's a CPU bug, but I haven't been able to reproduce the problem in a debug build, so I don't know what it really is... I think I've seen something similar happen with the DigiCube logo movie, so I'll check if I can do something about this tomorrow. |
|
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-02-11 00:00:00 |
|
I made some debugging today and gained a better understanding of the problem that makes the movie playing unstable. The program maintains 2 block positions which are used to compute the position of data writing in the buffer using this formula:
Position = ((BlockPos0 + BlockPos1) * 0x800 + DataStored) % 0x80000 So, at one time, the system stream parser call the user-defined handler to dump the video data into the video buffer, and writes it at the position computed using the formula. Then the next time this handler is called, the variables BlockPos0 and BlockPos1 have totally different values which causes the position not to be adjacent to the end of the previously written data but rather at a completely different place. I checked out what was changing these values and it seems that the user-defined handler used to resume the data transfer to the in-FIFO when it was previously aborted (used when transfering the default quantisation matrix for example) is causing the problem. It also only occurs on a very specific condition which would probably explain why it was kinda random. I don't really understand the formulae behind the change of the BlockPos0 and BlockPos1 values, so I have no clue if the change is meaningful. In any case, I'll be working on fixing this tomorrow. |
|
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-02-10 00:00:00 |
|
Fixed a copy and paste error in MTSAB that was causing some more of the garbage in the decoded pictures.
Fixed a bug with first coefficient decoding in non-intra blocks that was causing the remaining of the corrupted blocks that would appear sometimes. The decoded images are now near perfection. So, I shouldn't have to touch anything more inside the IPU processing functions.  
The movie playback is still unstable though, and I'm currently looking into fixing this. Hopefully, I'll have screenshots that show more interesting stuff tomorrow. Fixed a little bug with the "kputs" function of the "Deci2Call" system call. Added the processing of the "PRIM" and "PRE" fields in the GIF tags. Those were used to render the "Team-Digi" logo and the main title screen. This addition fixed them.  
There isn't much more to fix now. After the movie playback has been fixed, I'll need to work on fixing the alpha blending formulae, and then, fix the ingame crash. Once all of this is done and once the game becomes playable, I'll add the reset functionality discussed at the beginning of this development. |
|
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-02-08 00:00:00 |
Found out what was causing the columns to be swapped. It was PPACB that was giving a reversed result, so I fixed it.
 
Now everything is fine for intra macroblocks, but some frames remain screwy when they're using predicted macroblocks. For example, the frame with the DigiCube logo which comes from an I-picture looks as it's supposed to look, while previous ones have some visible artifacts due to bad predictions. Some artifacts are visible too in the second picture above. I think the problem lies in the dequantisation of these blocks. I haven't really tested them in my experimental MPEG-2 decoder, so I'll be checking if everything is alright on this side tomorrow. If it's not caused by problems from the MPEG-2 decoding functions in the IPU, then it's probably related to the newly implemented MMI instructions. Also made some minor changes: - Isolated the computation of the lookup table for the Cr and Cb indices, used in the CSC command, in a function and made it so it's called only one time and not each time a CSC command is executed. - Added some Y position compensation in the GS handler when using an interlaced mode (fixes jumpy screen). But I'm not sure this is the appropriate way to do this though... |
|
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. |
| << Older Log Entries | Newer Log Entries >> |