#9034 - sajiimori - Sat Jul 26, 2003 9:51 pm
I don't know if anybody has done this before on GBA, but I'm attempting to construct a simple preemptive multitasking environment, and I wanted to see if I could get some feedback.
The basic idea is to set up TIMER0 to trigger interrupts upon overflow, and have the interrupt handler save the current CPU state and load the state for the next thread.
The problem is that the BIOS saves the CPU state upon entering an interrupt, and restores it upon exiting. This behavior is incompatable with the idea of writing an interrupt handler whose purpose is to change the CPU state, such as a task switcher.
I can think of two possible solutions:
1) Don't return to the BIOS. Just re-enable interrupts and jump to the new thread. I'm concerned that the BIOS does other cleanup work, besides restoring the CPU state, such as stack unwinding. If so, triggering an interrupt multiple times without ever returning to the BIOS could result in a stack overflow or other bad things.
2) Hijack the CPU state saved in the BIOS and replace it with the state of the new thread, so the BIOS will "return" to a location of my choice. I'm biased toward this idea simply for its coolness factor, but I don't really know how to do it. I would have to know the location and format of the saved state.
It's unfortunate that the BIOS is inflexible regarding this behavior. Any ideas on working around it?
The basic idea is to set up TIMER0 to trigger interrupts upon overflow, and have the interrupt handler save the current CPU state and load the state for the next thread.
The problem is that the BIOS saves the CPU state upon entering an interrupt, and restores it upon exiting. This behavior is incompatable with the idea of writing an interrupt handler whose purpose is to change the CPU state, such as a task switcher.
I can think of two possible solutions:
1) Don't return to the BIOS. Just re-enable interrupts and jump to the new thread. I'm concerned that the BIOS does other cleanup work, besides restoring the CPU state, such as stack unwinding. If so, triggering an interrupt multiple times without ever returning to the BIOS could result in a stack overflow or other bad things.
2) Hijack the CPU state saved in the BIOS and replace it with the state of the new thread, so the BIOS will "return" to a location of my choice. I'm biased toward this idea simply for its coolness factor, but I don't really know how to do it. I would have to know the location and format of the saved state.
It's unfortunate that the BIOS is inflexible regarding this behavior. Any ideas on working around it?