|
|
|
|
|
|
| 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-01-22 00:00:00 |
| Merged some more stuff from the experimental MPEG2 decoder and completed the decoding/processing of the macroblock. Next thing to do is to write all the Y/Cb/Cr data to the output FIFO buffer and handle the DMA transfer that copies the data from the FIFO to the RAM/SPR. |
|
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-01-21 00:00:00 |
|
Didn't complete the DCT coefficient decoding as planned today. Initially, I wanted to fork the tables from the experimental MPEG2 decoder into the emulator, but I decided that it would have been useless to do so in case need for change (due to a bug or something else) arises. Maintaining two different versions of the same thing can be annoying.
So I changed the class hierarchy a little bit and moved some tables to the Framework source tree so that both the MPEG2 decoder and emulator can use the same instance of them. I'll go on ahead with the block decoding tomorrow. |
|
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-01-20 00:00:00 |
|
Been working on the decoding of the blocks. I added the inverse scan processing and added a temporary IDCT step.
But after testing a bit more, I found a little problem with the decoding an "escape" DCT coefficient VLC code. The MPEG-2 ISO standard says the 6-bits following this code shall be the value for "run" and and next 12-bits the value for "level". But that didn't fit quite well with the bit stream I was testing my code with. After some search I found out that my bit stream was not an MPEG-2 compilant stream but rather an MPEG-1 one. The definition of "escape" is different with this standard (8-bits for "level" instead of 12-bits). There's supposedly a 16-bits variant of this, but I wasn't able to find much information about it. The 8-bits version works fine with the stream I've tested. I'll need to add some bit stream version detection later on, because the standards are incompatible on this precise thing and maybe more. A major difference between an MPEG-1 and MPEG-2 stream is that the MPEG-2 stream is required to have a "sequence_extension" block while the MPEG-1 mustn't have one. I'll be using this difference to detect which type of bit stream it is. The MPEG decoder library running on the PS2 probably uses this too to set the MP1 bit of the IPU_CTRL register properly. After some other minor fixes with the coefficient decoding, my experimental MPEG-2 decoder can succesfully decode all the blocks present in this small test MPEG-1 bit stream. I've tested the movie being played in the game too (which is also an MPEG-1 bit stream), but this one uses some B-pictures with motion vectors, which I haven't bothered to touch yet, and won't work properly. I'm going to leave the experimental decoder for a while and try to add the BDEC command emulation in the the emulator. I didn't do much yet though... Just added the function skeleton of the function that will do the block decoding and added the DC predictor reset functionality. I'll try to get the decoding of DCT coefficients of an intra macroblock working tomorrow. I'll add the post-processing of the block (dequantise, inverse scan, IDCT) afterwards. The test bit stream I've been using is available here. |
|
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-01-18 00:00:00 |
|
Added decoding of P-pictures information in my experimental MPEG2 decoder. I was able to see more blocks getting decoded and see that my DCT coefficient VLC table seems to be working right.
Added the dequantisation step. Next, I gotta un-zigzag the dequantised block and execute an IDCT on it. Un-zigzaging isn't a problem, but the IDCT is a bit more. I'll have to find a decent algorithm that does a fast and nice job. I'll be doing some research about that tomorrow. |
|
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-01-17 00:00:00 |
|
Been working on decoding the DCT coefficients of a block in my experimental MPEG2 decoder. It's not very conclusive though, because all blocks of the first picture have all thier coefficients, except for the DC one of the luminance channel, set to 0. So, all I'm decoding are end of block codes.
There's two things I can do next. Keep working on the processing of the blocks (unzig-zag, inverse quantisation, IDCT) or check and support the next pictures to make sure my DCT coefficient decoding works correctly. I think I'll go on ahead with the next pictures and check if thier decoding is accurate. |
|
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-01-16 00:00:00 |
|
Added support for the "Macroblock Type" for an I-picture variable length code table to the VDEC command.
It now issues a BDEC command which is supposed to decode 4 Y (luminance), 1 Cb (chrominance blue) and 1 Cr (chrominance red) blocks and perform an IDCT (inverse discrete cosine transform) on them. The resulting coefficients are stored in the out FIFO and then transfered by the DMAC through DMA channel 3. This is the second most complicated command of the IPU. I don't know if that's going to take long though... I'll try to have at least the decoding of the DCT coefficients done tomorrow. |
|
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-01-15 00:00:00 |
|
Implemented instruction PADDH, even though it wasn't necessary because I stepped too fast in the code and didn't see the issue of the VDEC command pass by.
Implemented IPU command VDEC and added the "Macroblock Address Increment" table support to this command. Next, it wants to use VDEC to decode the "Macroblock Type" field present in the macroblock_modes structure for an I picture. That should be done tomorrow. |
|
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-01-14 00:00:00 |
|
Got something to work for DMA resuming/pausing. I decided to use an unused bit in CHCR to know if the reading of DMA tags has started in source chain mode.
Also made the BCLR IPU command to use the value of BP to set the FIFO bit pointer correctly. Now, it seems to be able to continue its processing after transferring the default intra-quantization matrix. It's able to decode the sequence header, GOP header and picture header properly. It's getting to the point of decoding the first slice, but I haven't tested it further. It'll probably use the VDEC command to decode the "Macroblock Address Increment" and "Macroblock Type" fields and I haven't gotten there with my experimental MPEG-2 decoder program yet. |
|
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-01-13 00:00:00 |
|
Been looking after the FIFO filling problem today... My idea consisted in giving a way to the devices that receive DMA transfers to tell the DMAC that they can't take anymore data and that they'd wish to suspend the transfer. Since the DMA transfers don't run in parallel with the CPU in the emulator, contrarily to what it does in reality, we'd also need to have a way for the devices to tell the DMAC to resume the transfer when they are ready. That's what causing me trouble...
Resuming would be fine if we were only using the normal mode, but we have to support the source chain mode too... So in source chain mode, when we suspend a transfer and finish it after, we need to know if we were done reading DMA tags or not. This can be done by maintaining the most significant 16-bits of the latest tag into the CHCR register and checking it after the transfer is finished. But the source chain mode is also supposed to start a transfer, before processing tags, if the initial QWC is not equal to zero. This initial transfer can also be suspended and resumed, and applying the same decision to decide wether there's more tags to process or not will not work because no previous tags has been read and the higher 16-bits of CHCR are uninitialized. But we could work around this problem by setting a bogus tag value that would cause us to check for the next tag after the transfer. I was also wondering if the MADR and QWC registers were changed while a transfer was currently on-going, but I'm pretty sure they do. TADR is apparently changing only at the end of the current transfer, so that could cause us some problems... It's more bothersome than I thought it would be. I'll think this over and come up with something implemented tomorrow. |
|
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-01-12 00:00:00 |
|
Kinda a lazy day today.
Made some minor changes to the VM main class to isolate the currently working resetting stuff and added a function to allow the UI to call this function... But I still need to ponder on what resetting will really do and how it will be used by other UI stuff. Tried to implement the reading of the IPU_BP register, but came against a problem while debugging the code that was using this register... The IFC field of this register is only 4 bits long which allows a maximum FIFO buffer size of 240 bytes and the total size of the DMA transfer is 22016 bytes... Well, after looking around in the documentation, I think the DMA transfer will be held by the DMAC if the IPU FIFO buffer gets filled and will continue to feed it when there will be space. But implementing that will require some changes on how the IPU/DMAC modules work together though... And I finally got my hands on the MPEG-2 ISO specifications. |
| << Older Log Entries | Newer Log Entries >> |