Difference between revisions of "ARM9 SWI Functions"
Jump to navigation
Jump to search
(IntrWait bugged?) |
|||
| Line 33: | Line 33: | ||
| swiIntrWait | | swiIntrWait | ||
| ?? | | ?? | ||
| − | | same as DS | + | | same as DS (but bugged? see note) |
|- | |- | ||
| 0x05 | | 0x05 | ||
| swiVBlankIntrWait | | swiVBlankIntrWait | ||
| ?? | | ?? | ||
| − | | same as DS | + | | same as DS (but bugged? see note) |
|- | |- | ||
| 0x06 | | 0x06 | ||
| Line 217: | Line 217: | ||
The two ignored function do return without doing anything (they are rejected before calling the SWI function table). The other unused functions do hang in an endless loop. | The two ignored function do return without doing anything (they are rejected before calling the SWI function table). The other unused functions do hang in an endless loop. | ||
| + | |||
| + | '''Note:''' swiHalt does correctly use CP15 to halt the ARM9 processor. But, swiVBlankIntrWait and swiIntrWait do use port 0x4000301 (which would be correct on ARM7, unknown if the same mechanism is actually supported on ARM9, if it isn't supported then the functions would more or less behave as desired - wait for IRQ flags to get set - but without actually switching the CPU into low-power mode). | ||
== See Also == | == See Also == | ||
* [[ARM7 BIOS]] | * [[ARM7 BIOS]] | ||
Revision as of 11:22, 18 July 2013
ARM9 BIOS SWI Function
These are the functions provided by the ARM9 BIOS.
| ID | Name | Args | Changes |
|---|---|---|---|
| 0x00 | N/A (hangs) | none | formerly SoftReset |
| 0x01 | swiDecompressLZSSwithCallbackWrite8bitUnits | ?? | formerly jump to 0 |
| 0x02 | swiDecompressLZSSwithCallbackWrite16bitUnits | ?? | formerly jump to 0 |
| 0x03 | swiWaitByLoop | ?? | same as DS |
| 0x04 | swiIntrWait | ?? | same as DS (but bugged? see note) |
| 0x05 | swiVBlankIntrWait | ?? | same as DS (but bugged? see note) |
| 0x06 | swiHalt | ?? | same as DS |
| 0x07-0x08 | N/A (hangs) | ?? | same as DS / formerly jump to 0 |
| 0x09 | swiDivide | ?? | same as DS |
| 0x0A | N/A (hangs) | ?? | same as DS / formerly jump to 0 |
| 0x0B | swiCopy | ?? | same as DS |
| 0x0C | swiFastCopy | ?? | same as DS |
| 0x0D | swiSqrt | ?? | same as DS |
| 0x0E | swiCRC16 | ?? | same as DS |
| 0x0F | N/A (hangs) | ?? | formerly IsDebugger |
| 0x10 | swiUnpackBits | ?? | same as DS |
| 0x11 | swiDecompressLZSSWram | ?? | same as DS |
| 0x12 | N/A (ignored) | ?? | (formerly swiDecompressLZSSVram) |
| 0x13 | swiDecompressHuffmanWithCallbackWrite32bitUnits | ?? | same as DS |
| 0x14 | swiDecompressRLEWram | ?? | same as DS |
| 0x15 | swiDecompressRLEwithCallbackWrite16bitUnits | ?? | same as DS |
| 0x16 | swiDecodeDelta8 | ?? | same as DS |
| 0x17 | N/A (hangs) | ?? | same as DS / formerly jump to 0 |
| 0x18 | swiDecodeDelta16 | ?? | same as DS |
| 0x19 | swiDecompressLZSSwithCallbackWrite16bitUnits | ?? | same as SWI 0x02 / formerly jump to 0 |
| 0x1A-0x1E | N/A (hangs) | ?? | same as DS / formerly jump to 0 |
| 0x1F | swiCustomPost | ?? | same as DS |
| 0x20 | swiInit_crypto_heap | ?? | new |
| 0x21 | swiRSA_decrypt | ?? | new |
| 0x22 | swiRSA_decrypt_signature | ?? | new |
| 0x23 | swiRSA_decrypt_der | ?? | new |
| 0x24 | swiSHA1_Init | ?? | new |
| 0x25 | swiSHA1_Update | ?? | new |
| 0x26 | swiSHA1_Final | ?? | new |
| 0x27 | swiSHA1 | ?? | new |
| 0x28 | swiSHA1_Compare | ?? | new |
| 0x29 | swiSHA1_Random | looks like it's trying to generate a random number using SHA1 | new |
| 0x2A | N/A (hangs) | ?? | formerly jump to garbage |
| 0x2B | N/A (ignored) | ?? | formerly jump to garbage |
| 0x2C-0x3F | N/A (hangs) | ?? | formerly jump to garbage |
| 0x40-0xFF | Mirrors of 0x00-0x3F | ?? | formerly jump to garbage |
The two ignored function do return without doing anything (they are rejected before calling the SWI function table). The other unused functions do hang in an endless loop.
Note: swiHalt does correctly use CP15 to halt the ARM9 processor. But, swiVBlankIntrWait and swiIntrWait do use port 0x4000301 (which would be correct on ARM7, unknown if the same mechanism is actually supported on ARM9, if it isn't supported then the functions would more or less behave as desired - wait for IRQ flags to get set - but without actually switching the CPU into low-power mode).