Skip wait cycles in fast keyboard polling code in IRQ handler

[rbergen]

The fast keyboard polling code in the IRQ handler currently doesn't skip the waiting cycles as it counts down POLLTGT from POLLRES to 11. Instead, it treats values > 11 as scanning rows. This makes KBDROWPOLL attempt to scan key rows with indices > 9, which don't exist. I've also moved the decreasing of POLLTGT to just before the evaluation of POLLTGT's value, which means it only needs to be included once in the fast keyboard poll section of the IRQ handler. It is also more consistent with the structure of the slow keyboard polling code.

[ChartreuseK]

Looks good! Can't believe I typoed the number in hex when it should be decimal. Wondering if maybe that was a remnant of some of the early fast keyboard scanning attempts I made or just a goof that didn't break anything. I just want to setup my PET again and do a test first myself and then I'll merge.

[rbergen]

I actually only noticed the #$11 thing 3 months after making the other changes, myself. :) And yes, please do test. I have tested the code, but not in the context of PETTERM as such. I extracted the serial driver code from PETTERM for use in a friend's PET project that I contributed to. I discovered and initially fixed the bug in that setting.