Leo Wrote:Does interrupts get queued when they are disabled, until the next EI?
Or they are simply ignored?
Because, if they are ignored, some timing events(such as the lcdc int)can get out of sync!!!
For the GameBoy, there are three pieces of info that determine which interrupt to perform and when. The Interrupt Enable aka IE register (0xFFFF), the Interrupt Flag aka IF (0xFF0F), and some sort of boolean (most people refer to it as the IME) that's flipped to tell the CPU if interrupts are permitted or not (used in the DI, EI, and RETI opcodes). Before executing an opcode, the CPU checks the IME. If it's set, you go to your interrupt handling, if not, you process opcodes normally. Remember, simply because the IME is set doesn't mean an interrupt has occurred. You need to examine the Interrupt Enable and Interrupt Flags in your interrupt handling.
The IE register tells the CPU which interrupts are enabled; you do this by checking bits 0-4 of the register. If a certain interrupt is enabled, you then have to check if the emulated hardware has "tripped" the interrupt, i.e. it has set one of the bits of the IF register (it also only uses bits 0-4). If both the correct bits in IE and IF are set, you execute the interrupt and reset the bit in IF. The IME is also reset, so other interrupts cannot happen until the current one is finished. During your interrupt handling, you should only handle one interrupt at a time. Usually after the interrupts, the game code calls RETI so that any other interrupts can take place.
If the game code generates one or more interrupts at the same time, you could say they are queued, since the IF register keeps track of which interrupts are generated by hardware. The GB hardware has a hierarchy of which interrupt it will handle first in this order: V-Blank, LCDC, Timer Overflow, Serial, and High-to-Low for P10-P13 (e.g. gamepad input). So it goes something like this if two or more are generated at the same time:
Handle interrupt with greatest priority -> Disable interrupt handling since one is being processed right now -> Reset corresponding IF bit so we only handle the interrupt once until it's generated again -> Push PC to stack, Jump to interrupt location (e.g. 0x40) -> Process Interrupt -> Return from interrupt, re-enable interrupts usually with RETI -> Repeat, handle the next interrupt with the greatest priority.
Here's some psuedo code to wrap your head around
Code:
handle_interrupts()
{
if(IME)
{
//V-Blank
if(Bit 0 of IF == 1 && Bit 0 of IE == 1)
{
Push stuff to stack, increment cycles by 32
Set Program Counter to 0x40
Set Bit 0 of IF to 0 since the interrupt has been handled
Set IME to false, disabling interrupt handling, game will reset it by itself via RETI, usually
}
//LCDC
else if(Bit 1 of IF == 1 && Bit 1 of IE == 1)
{
Same as above, but we set the Program Counter to 0x48
}
//Timer overflow
else if(Bit 2 of IF == 1 && Bit 1 of IE == 1)
{
Same as above, but we set the Program Counter to 0x50
}
... More code ...
}
}Note the use of else-ifs since we must handle one interrupt and one interrupt only at a time. This allows the GB to keep everything in-sync, assuming the people who programmed the ROM knew what they were doing, of course :p
As for GUIs, FLTK FTW! I dabbled with it; it's pretty light on resources and it doesn't take much code to get going, good for simple projects. That said, it doesn't have nearly as many features as GTK, wxWidgets, or Qt. I second Qt if you really want to make GUI-based programs. I haven't programmed in it myself, but I do use a lot of programs written in it, and there's much to be impressed by.