Dear Homebrewers: Halt!

While developing a Virtual Boy emulator in Java, I finally hit critical mass where the simulation was a little more demanding than my environment could process in time. Sometimes this would happen when using breakpoints, but it came out in force after implementing audio, and that’s no fun. I have an idea of what to do about it, so don’t worry about me… You’ve got your own things to worry about!

tl;dr: if you’re developing for Virtual Boy, use the [font=Courier New]HALT[/font] instruction.

When your program needs to wait for an interrupt to occur, it’s common practice to check on a global variable until an interrupt handler comes along and changes that variable. This works, but is not recommended because the CPU is busy chugging away wasting time. Even worse, it’s wasting power, which is kind of a deal on Virtual Boy with its six AA batteries. Worst of all, it’s slowing down my emulator!

The better way to wait for interrupts is with a dedicated CPU instruction called [font=Courier New]HALT[/font]. This instruction suspends CPU activity entirely until some external component (such as the video processor) requests an interrupt, at which point the CPU comes back to life and handles the request. Power isn’t consumed for spin waiting this way, and no processing takes place until the interrupt does its job.

If your development tools don’t provide ready access to the [font=Courier New]HALT[/font] instruction in your programs, you can access it yourself with this simple yet janky C function:

void halt() {
    static const long code = 0x181F6800L;
    ((void(*)())&code)();
}

Use the [font=Courier New]HALT[/font] instruction any place where you need to wait for an interrupt and don’t have anything else to process while doing so. This will ensure better performance in emulation efforts going forward as well as make the world a better place in general…