![]() |
![]() |
![]() |
![]() |
![]() |
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-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. |
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-01-11 00:00:00 |
Documentation was right about the FDEC command: FB bits must be skipped before reading the 32-bits value. The library keeps the last result of FDEC and returns it when a request to execute this command is issued, rather than returning the result of the current command.
Now it is able to go through the bits of the MPEG-2 sequence header structure and save the values it needs. Then it comes to checking the "load intra quantization matrix" bit, which is set to 0 in the case of this movie, and does a bit of gymnastic to be able to load the default matrix once again... - Since the FIFO already has some data in it, the library can't just write the matrix in the FIFO because it would be stored at the end of the buffer. So what it does is call one of those custom handlers to save the state of the IPU DMA channels and of IPU_CTRL and IPU_BP. - Once that's done, the FIFO buffer is reset and the library DMAs (using normal mode) the matrix and sends the SETIQ command. - Another custom handler is called that restores the state of the IPU saved previously and processing continues "normally". But this process doesn't work properly yet. I've added the normal mode for DMA channel 4, added reading for the missing registers for this channel. Tomorrow I'll be checking on making the values present in IPU_BP accurate to make the library routine able to restore its state properly. |
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-01-10 00:00:00 |
Rigged up something so that the DMA enabler function gets called. My solution was to raise the BUSY bit of registers IPU_CMD and IPU_CTRL when a FDEC command is issued when no data is present in the FIFO so that a waiting loop gets executed and that the DMA enabler function get called. Once some data get sent through DMA, the FDEC command is executed again returning the wanted result and clearing the BUSY bits.
Now that this seems to work, I need to figure out what FDEC does really. What I'm sure about is that it returns the first 32-bits present in the FIFO, but I'm not quite sure what the BP parameter should do: - The FDEC command is executed the first time to find out if an MPEG marker is present at the current position. The values for BP provided for this is 0 for the first time and 8 otherwise. - Then the actual marker is fetched and a value of 32 is provided for BP. What I'm not sure about is if the FIFO bit stream pointer should be incremented after or before... The documentation says before, but it wouldn't work good with the second use of FDEC. I'll be studying this more in details tomorrow. |
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-01-09 00:00:00 |
Potentially found how DMA transfers can be started. Apparently, you must supply to the MPEG decoding library 4 (or 5?) functions to handle several exception cases. There's one to display an error message and others to cope with the lack of data in the IPU FIFO. Well, that's what I think at least, since the function pointers provided to the MPEG decoding library/function are those that set the STR bit of the 4th channel.
But I'm not quite sure how to get them called though, because the library will still go ahead and issue an FDEC (get fixed length code) command. It probably has something to do with a triggering an error in the IPU... More about this tomorrow. |
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-01-08 00:00:00 |
Continued to search for the IPU data producer/DMA problem, but found nothing that could solve this yet.
But while looking through the movie player code, I was able to find something that checks the status of a button to skip the movie scene. I patched the executable so that it always skips the movies and that enabled the program to go further. We are able to play the game with this patch, even though it's a bit limited : it crashes as soon as we hit an enemy, and there's also a couple of problems with the GS handler. Also note that to be able to see that much of the game, a little hack in the GS handler was required to force an alpha blending formulae. There's multiple layers of rectangle areas that have transparent area to let the underneath layer show something. I think there's one for the status text, one for fancy the border with Feena and Reah and one for the game. The reason everything looks translucent is also because of this hack. There's also a little bug with the character sprites that make them show an extra frame when moving around (certainly due to a CPU problem). But I don't really want to concentrate on this for the moment... I'd like to have the IPU done at a decent level before fixing any problems with the game. So I'll be continuing my search for the solution tomorrow. |
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-01-07 00:00:00 |
Implemented IPU commands SETVQ (load VQ CLUT) and SETTH (load threshold values for dither).
Implemented system calls DisableIntc and RemoveIntcHandler. I added the code to handle the DMA channel 4 (toIPU) thinking that the channel would be enabled, but none set the STR bit of the CHCR to 1. The data (MPEG2 data from the disk) and DMAtags to be sent are prepared properly, but it isn't sent for some reason. I checked around for code that sets the STR bit and found something involving some mechanic using semaphores. I'll be checking this more in details tomorrow. |
Make 'Ys I & II Eternal Story' playable.
Posted on 2006-01-06 00:00:00 |
Started the work on the IPU emulation class. Stream data is now accumulated from writes to the IPU_IN_FIFO register. Implemented commands BCLR (in-FIFO reset) and SETIQ (load quantization matrix). The matrices loaded don't come from the movie file though... They come from the data segment of the executable. This is probably done to reset the IPU properly. |
<< Older Log Entries | Newer Log Entries >> |