2 replies to this topic

[Andreas B]

I've found some nifty system calls that could be useful.
I'm using GCC, so I'm not completely sure about the hitachi ASM, - please correct me if you can;

.export _syscall
_syscall:
  mov.l #h'80010070, r2
  mov r4, r0
  mov r5, r4
  mov r6, r5
  jmp @r2
  nop

The first argument to syscall(), (r4) is the system call number (int). Following arguments are moved into r4, r5 etc, as arguments for the call itself. I (or you) could make one function per call, but this is the way I did the testing myself.

Example: syscall(0x42D, filehandle); for Bfile_CloseFile_OS(). Now, CloseFile is not that interesting, but there are loads of system calls.

Some calls and their parameters:
0x924 (void) Enters the "----- TEST MODE -----" menu (often easier than the key-combo).
0x4E9 (int stringno) Returns a char pointer to translated string with index given by stringno.
0x236 (void) Resets/reboots. The preferred way to reset by the OS functions.
0xA6B (void) Run the Memory Manager (MEMORY) app.
0x9E1 (void) Run Equation (EQUA) app.
0xAC8 (void) Run System Manager (SYSTEM) app.

These should work on 1.02 and 1.03. I won't advise you to do random system calls

[Manuel Naranjo]

Nice discovery it might be worth to make a function that goes through all the possible values for system calls and make a table out of it.

[Andreas B]

Yep, but it is never smart to run code when you don't know what it does. Just as a warning for those who want to try..
The best way is to get into test mode, dump the flash to an SD card (if you have one) and then disassemble and analyze its code with IDA. The flash memory (ROM) starts at 0x80000000 (and 0xA0000000, but that address is not commonly used in the code).