Well, I think I see two problems, one is probably pretty serious though.

1. You need that EI in your interrupt routine, interrupts start with interrupts disabled so that your calculator doesn't endlessly interrupt and stack overflow.

2. This one you're not going to like, but it's a fact of life. The interrupt routine takes 19 t-states to complete. So take your current interrupt t-states and add 19 to them. This would imply that the next interrupt will be firing before the current one finishes, so while that won't stop the interrupts from working, it just means that it will instantly reloop without executing regular instructions.


The way you set up the crystal timers looks good though, I'd just put that EI after the OUT to ($32).

Edit:
   Also, once the interrupt occurs, I don't think you can throw it away. This means when you go to the next row, things might get a little ugly since you have the interrupt waiting to occur at the next EI.

Edit2:
   Well, it kind of works. You don't need to output to ($30) again. And while I believe you did it for the wrong reason, that second output to ($31) is actually necessary. This is because if you let the crystal timer expire twice, your interrupts die, which means yours will die if you don't intervene within 200 t-states. So the second OUT ($31), A renews this timer for you. Just remember that your EI \ RET is going to instantly go back to your interrupt routine though.

1. The first interrupt occurs from hardware timers as opposed to crystal timers.  I assume that it's normal and that there's nothing I can do about it?

You could turn the regular interrupts off. "XOR A \ OUT (03), A". After the out, you won't have another normal interrupt until you restart port 3.

2. The 84+ uses two of the three timers.  Which of the three is free to use?

All three are always free to use. The OS does use two timers, but that is only during USB stuff. I'm not really sure how the rumor got started that you can only use one of them, because you can use all three at any time. I guess the only time you couldn't is if you are in a hook, but you shouldn't use them in a hook anyways.

Well, I see one of two things happening:
1. Your interrupt routine is relapsing in on itself. I don't think this is the problem, as it would probably cause a crash, but we can't rule it out.
2. You are restarting this whole sequence before it finishes. This would make sense as it is cleanly drawing stuff and just stopping.

The reason for this is because your calculator is not as good hardware wise as wabbitemu. I don't think wabbitemu emulates the 19 t-state delay I talked about and wabbitemu's screen only requires 60 t-states of delay after a write, (and I'm not positive, but I think this is regardless of speed), so what that means is that your program is finishing much quicker on wabbitemu and therefore has time to finish updating the screen.

Or I could be completely wrong.