I tryed to load "npm-2301.irx" (or something like that, I forgot exact name) along when IOPRPXXX.IMG is loaded. NapLink client didn't detect anything, so I believe that module requires some RPC support or can not be loaded in such environment.
My current vision of C/DVD emulator installation is to write virtual device driver & IOP reboot hijack program. When EE will try to reboot IOP the hijack program will change path to IOP image, so modified image will be loaded by "UNDL" instead of real one. For example it can change original path like "cdrom0:\IOP\IOPRP300.IMG" to something like this "image0:\IOPRP300.IMG". My virtual device will contain image with both "CDVDMAN" & "CDVDFSV" replaced by special emulation modules. It look pretty simple with except I can load debug-support modules into real games. Of course I can do many important tests using my program as "host game", so I can load extra debug related modules without problems.
Here is the catch, you can't load modules while in the middle of an interrupt. And while this method will allow you to catch the IOP reset request made, another method should really be looked into. It is possible to catch the request from the EE, and not even need my particular method that I experimented with. It involves patching the Sif interrupt on the EE which is triggered on sif commands and the like.
Something just occurred to me that would allow true injection /without/ creating a new image. The only catch is that you would have to read the IOP image into the EE RAM first, and then extract the modules into the IOP one by one. Or you can manually load the image yourself. Either way the exact format of the image is essential to be known in order to pull this off.
Romz, e-mail me ASAP and let's work out something for CVS access so you can make changes. It might be a little bit of work, since I use SSH for write-enabled accounts, but it should be possible to give you some control over HDDemolisher's CVS tree.
Here is the catch, you can't load modules while in the middle of an interrupt.
This reminds me of similar problems I've seen on M68K platforms, where interrupt driven code had to access OS functions not legal to call from within interrupts (due to interrupt masking, as those functions themselves needed to be interruptable). We came up with various ways to do this sort of thing, and I hope something similar can be done with MIPS as well. Basically our solutions boiled down to two main methods.
Unfortunately I'm not well enough informed on the interrupt/exception model of MIPS processors to describe this in proper MIPS terms. So I have no choice but to use the terms I'm familiar with. Hopefully you'll see what I mean anyway.
Method 1: Without returning from the current interrupt, modify interrupt mask and other special registers, after saving current state, so as to simulate a non-interrupt state while calling system functions. Afterwards, restore the interrupt state and proceed as usual. The drawback of this method is that special measures may need to be taken to avoid harmful reentrancy, either for the functions used directly, or for functions used by normal interrupts that may occur due to the patched state.
Method 2: Analyze supervisor stack frames tracing back to a point where the CPU was in user mode before the interrupt. At that point, patch the user stack to insert a normal subroutine return frame leading to the originally interrupted code, and repatch its interrupt return frame (on super stack) so as to lead to your own fix_it() function instead. Then proceed as usual. As you exit from the interrupt handler, that will lead (possibly after additional exits) to your fix_it() function, running in a perfectly normal pre-interrupt state. And when its work is done it can simply make a normal function return to the originally interrupted code.
Like I said, that was for M68K, and the details will surely be quite different with MIPS, but the same principle should be applicable for any CPU type.
ok, I've attached some code which uses hermes' timer interrupt as an example instead of the sbus interrupt, but the principle is the same. It loads sioman and padman on the timer0 interupt, set to an interval of 1 second. I think It could be a little useful.
I would really like to help you in this project. I can write C code and I have programmed some things for a TMS370 microcontroller some time ago (so I am familiar with interrupts and so on). However, I have no idea about MIPS and PS2 architecture.
If you think I can be useful for the project even I don't know so much about PS2 programming, please give me some references to tutorials or documents or tell me where to look next. I tried to learn PS2 programming myself before and I got stuck, so please don't send me back to Google .
If you think I can be useful for the project even I don't know so much about PS2 programming, please give me some references to tutorials or documents or tell me where to look next. I tried to learn PS2 programming myself before and I got stuck, so please don't send me back to Google .
If you want to learn more about programming for PS2, visit ps2dev.org It will be your starting point to PS2 programming. This project includes the programming for both R5900 (EE) and R3000 (IOP). I don't know much about the programming for the EE but for my opinion the programming for the IOP is kinda like a virtual device driver development for Win9x.
PS: I contacted Krevnik to get write-enabled access to project's CVS so I'll place pseudo source code for "CDVDMAN" modules here as soon as all technical problems will be solved.
I already tried ps2dev.org, but I found no clear info.
Well, maybe the only way to learn is reading other's code, but I would like to have some hardware knowledge before getting into code. Are there any really helpful docs? Maybe the ones that come with the PS2 Linux distribution, or Sony's SDK. Also, I am not very good at reverse engineering things.
I have a few 'in the works' tutorials at my (temporary) website. These should get you going with regards to the compiler set, see http://uk.geocities.com/kil_frenzy/ . The most docs in the linux or sdk distro are helpful, but most information can be found at ps2dev, either in their doxygen docs or forums.
I managed to load "npm-2301.irx" after IOP reset and it works. Thanks for your advice, TiduS`. Now I have "host" device and "tty" output so it's easy to reload IOP with new images for me.