cdvdman imported functions
cdvdman imported functions
I was reading through the source to libcdvd and traced some of the functions, like CdInit(), to cdvdman.h in ps2sdk. From there I noticed that CdInit is the same as sceCdInit which is imported from elsewhere. I was wondering where this function is imported from?
Okay. You have to understand the mechanism used into the PS2. Here is a quick scheme.
You have two processors. The "main" one, the 'EE', and a "slave" one, the 'IOP'. On the IOP, you have modules, called 'IRX' files. Lot of modules exists into the BIOS, and 'CDVDMAN' is one of them.
When the EE wants to call back an IOP's IRX function, it has to use 'RPC' (Remote Procedure Call).
Now, inside ps2sdk, you can find a file, called libcdvd.c, which contains the reversed RPC to call CDVDMAN's functions. That's when EE wants to call CDVDMAN.
When an IOP's IRX wants to call CDVDMAN's functions, it has to go thru another (simple) mechanism: function imports. You (more or less) only have to include the file cdvdman.h, which will build up some code for you, that will create "stubs" into the IRX. These stubs, in asm, looks like:
(you can see the file cdvdman.s for a complete sample of what such a stub would look like)
The "4" here is the import number that will get called "for real".
So, in short, when you want to call an IRX from another IRX, say, foo.irx wants to call CDVDMAN, then foo.irx has to contain the cdvdman.s stub (or parts of it). Then, to create the stub file, you have to know the list of imports of the imported irx. Such a list could be, like:
Finally: usually, sce-prefixed function names are immediately aliased to their non-prefixed equivalents. For example, see cdvdman.h:
Hope I was clear...
You have two processors. The "main" one, the 'EE', and a "slave" one, the 'IOP'. On the IOP, you have modules, called 'IRX' files. Lot of modules exists into the BIOS, and 'CDVDMAN' is one of them.
When the EE wants to call back an IOP's IRX function, it has to use 'RPC' (Remote Procedure Call).
Now, inside ps2sdk, you can find a file, called libcdvd.c, which contains the reversed RPC to call CDVDMAN's functions. That's when EE wants to call CDVDMAN.
When an IOP's IRX wants to call CDVDMAN's functions, it has to go thru another (simple) mechanism: function imports. You (more or less) only have to include the file cdvdman.h, which will build up some code for you, that will create "stubs" into the IRX. These stubs, in asm, looks like:
Code: Select all
CdInit:
j $31
li $0, 4
The "4" here is the import number that will get called "for real".
So, in short, when you want to call an IRX from another IRX, say, foo.irx wants to call CDVDMAN, then foo.irx has to contain the cdvdman.s stub (or parts of it). Then, to create the stub file, you have to know the list of imports of the imported irx. Such a list could be, like:
Code: Select all
4 sceCdInit
5 sceCdStandby
6 sceCdRead
7 sceCdSeek
8 sceCdGetError
9 sceCdGetToc
...
Code: Select all
#define CdInit sceCdInit
#define CdStandby sceCdStandby
#define CdRead sceCdRead
#define CdSeek sceCdSeek
#define CdGetError sceCdGetError
#define CdGetToc sceCdGetToc
...
Hope I was clear...
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.