|
|
|
|
|
|
|
Make "PS2 Invaders v1.6" by "InPulSe Team" work.
Posted on 2005-10-10 00:00:00 |
|
After further reading, I think I've finally understood the SIF RPC communication protocol... Here
is a simplified description of the binding process: - A client on the EE sends a BIND command through the SIF1 DMA channel. - The SIF0 (on the IOP side) DMA channel triggers an interrupt when the transfer is done, invoking the SIF library interrupt handler. - The interrupt handler looks up for the server to be bound with the client using the SID member of the packet. - The server is found and the library copies the packet queue address (amongst other things) of this server in a new REND (request end) packet. - This REND packet is sent back to the EE. - The EE interrupt handler for the SIF0 (on the EE side) DMA channel is invoked. - This handler copies the server packet queue address back to the client's binding information structure and signals a semaphore to indicate that the request is finished. The method invocation process is similar to the binding process. I think what confused me was that there was the server code present on the EE side for some reason. There's also the fact that it will also listen to bind and call requests. Maybe the binding can be done from the IOP to the EE too... With that understood, I was able to fix my code. I'm now able to acknowledge bind requests and I'm working on calling requests. I've had to use another dirty hack for the extra DMA transfer needed for transfering the marshalled arguments for the call request. I can't be bothered to implement those DMATag things right now. I'll finish the call request acknowledgement tomorrow. Now I'm facing a design issue though... The proper and more compatible way to implement everything on the IOP side would be to start from booting the BIOS, loading each modules, and executing the code for all of them. But the hardware registers on the IOP side seem far worse than on the EE side... And there's a lot more of interrupt lines, more DMA channels, and most of this stuff isn't very well documented. On the other side, emulating the modules on an higher-level by catching each SIF call requests and dispatching them to native code that will do the same job without dealing with lower level accuracy is the easiest thing to do. But many custom made IRX modules exist and there's no way someone could implement an high-level emulation for each of them. To give an example, almost every game uses a custom made IRX module for music and sound. And some seem to ship with already existing modules, but I have no idea if those have any changes compared to the ones included in the BIOS. I think nSX2 and PCSX2 use the latter idea, but I'm not really sure about the way they deal with those custom IRX modules. I'm leaning towards this method too, and I've started to implement it this way... More stuff to ponder about... |