Cool stuff, like it so far. Two comments:

1) Since you're in Canada, why do you only have a MAX temp warning, why not a minimum one as well?

2) Probably nothing you can do about this one, but....

Mike's timing fixes were intended to help debounce the switches on the volume control knob. His method for doing so was to check the timing of the messages and ignore them if the user changes volume direction too suddenly (as tends to happen with dirty switches).

The first problem I see is that it makes the breakout game harder to play because it won't change direction suddenly as easily as it used to.

I know, I know, I'm the one who suggested that the timing fixes should be in your kernel. I'm not saying to remove them. They are correct in the case of a flickery volume knob. I just wanted to say that this is one side-effect you might want to know about.

I'm wondering, though, just how the knob's switches are interpreted in the first place. Are they interpreted at the kernel level, or are they just getting Up and Down messages from a PIC somewhere? My point is that the current fix seems like a bit of a kludge (no offense, Mike), almost as if the REAL debouncing needed to be done in a PIC somewhere that the software doesn't have access to, and so the only solution was to put a band aid on the symptom of the problem rather than its source. If true, then Mike's current implementation seems like the only proper way to deal with it at this time.

Since your player has brand-new switches, you don't have a glitching knob to test against, so playing with the timings yourself (for instance, making them tighter for the game only) probably would be counterproductive...