Is there a reason why no game or homebrew seems to use the coprocessor timer handler?
The timer seems to run just fine, anyway. I ran it at an interval of .1 seconds for over an hour. There was a slight delay when setting it, but that was about it.
SetCPUTimer and SetCPUTimerHandler
I'm assuming that these functions set the COP0 Count and Compare registers.
These registers are usually intended for multithreading support, after N cycles the interrupt handler is called and the kernel switches to another thread.
However since multitthread switching is not handled by the EE kernel, these registers would probably go untouched for most applications.
I would not recommend using these registers for a user timer, since they are meant for the kernel and some kernel syscalls might be using them. Instead just use one of the 4 EE timers.
These registers are usually intended for multithreading support, after N cycles the interrupt handler is called and the kernel switches to another thread.
However since multitthread switching is not handled by the EE kernel, these registers would probably go untouched for most applications.
I would not recommend using these registers for a user timer, since they are meant for the kernel and some kernel syscalls might be using them. Instead just use one of the 4 EE timers.
-
ragnarok2040
- Posts: 202
- Joined: Wed Aug 09, 2006 1:00 am
Yeah, SetCPUTimer sets the COP0 Count/Compare and unmasks the interrupt in the Status register when -1 is the argument.
The timers used so far are timers 1, 2, 3, leaving only timer 0. PS2SDK uses timer 1 for a low resolution tickrate, the kernel uses timers 2 and 3. Timer 3 is set to the hsync period, timer 2 is at the max rate. I know timer 3 is for the alarms. I think setting an alarm is actually just a wrapper around setting the timer 3 interrupt handler, heh. I decided to go another way and implement a small inline asm loop for stalling the number of microseconds I needed, instead of using a high-resolution timer interrupt.
I'm relatively sure the kernel doesn't use the COP0 timer interrupt at all. At least, the interrupt is never unmasked. I seem to remember it was the Linux/MIPS maintainer's opinion, at the time, to never use the COP0 timer because of the changing clockrates. Kind of silly, since you can just set a static interval based on the rate. It's just weird that nobody's seemed to use it, especially since I think it has less overhead since it's an interrupt by itself and it's 32-bit which allows for larger intervals between interrupts.
The timers used so far are timers 1, 2, 3, leaving only timer 0. PS2SDK uses timer 1 for a low resolution tickrate, the kernel uses timers 2 and 3. Timer 3 is set to the hsync period, timer 2 is at the max rate. I know timer 3 is for the alarms. I think setting an alarm is actually just a wrapper around setting the timer 3 interrupt handler, heh. I decided to go another way and implement a small inline asm loop for stalling the number of microseconds I needed, instead of using a high-resolution timer interrupt.
I'm relatively sure the kernel doesn't use the COP0 timer interrupt at all. At least, the interrupt is never unmasked. I seem to remember it was the Linux/MIPS maintainer's opinion, at the time, to never use the COP0 timer because of the changing clockrates. Kind of silly, since you can just set a static interval based on the rate. It's just weird that nobody's seemed to use it, especially since I think it has less overhead since it's an interrupt by itself and it's 32-bit which allows for larger intervals between interrupts.
-
ragnarok2040
- Posts: 202
- Joined: Wed Aug 09, 2006 1:00 am
Some new information.
The interrupt vector handler resets the COP0 Count register to 0, before calling the timer handler. It's helpful for setting the right interval, and for calculating the current number of ticks.
The current timer handler for the interrupt just prints out that an interrupt has occurred, and doesn't seem to handle it.
While it's still possible some syscalls might set their own timer handler, I don't think there are any. I went through quite a few of the common ones, that would need some sort of timing, and modified PCSX2 to print out when Count/Compare were touched... after fixing the cpu timer interrupt emulation.
The interrupt vector handler resets the COP0 Count register to 0, before calling the timer handler. It's helpful for setting the right interval, and for calculating the current number of ticks.
The current timer handler for the interrupt just prints out that an interrupt has occurred, and doesn't seem to handle it.
While it's still possible some syscalls might set their own timer handler, I don't think there are any. I went through quite a few of the common ones, that would need some sort of timing, and modified PCSX2 to print out when Count/Compare were touched... after fixing the cpu timer interrupt emulation.