OK, so first of all I did a little more analysis of the 'lost keypress' problem, and have confirmed that it is in fact a scenario in which a keypress occurs so rapidly that it registers on the first test (i.e. "did we get any keypresses at all?") but, by the time the column scan has cycled through VIA #2 Port B, there's no row reporting it. This isn't really a problem after all, because it only happens when a key is accidentally 'clipped' during rapid typing - so I'll just exit the routine and ignore the situation.
There is a way to mitigate the issue, although it can't cure it completely - if I cycle through the columns and read Port A for each one very quickly, storing the response in ZP, and then go back over each response afterwards to see if any did actually register a keypress, there would be a much smaller probability of one going missing because keyscan processing would be happening against stored, static, values rather than the dynamic state of the VIA. But that would need 8 bytes of ZP, and even then couldn't completely guard against the problem - the row responses on Port A might still change in the brief time it takes to read each value as the column in Port B changes. Well, I'll keep it in reserve in case the issue manifests as a bigger problem later.
There is a way to mitigate the issue, although it can't cure it completely - if I cycle through the columns and read Port A for each one very quickly, storing the response in ZP, and then go back over each response afterwards to see if any did actually register a keypress, there would be a much smaller probability of one going missing because keyscan processing would be happening against stored, static, values rather than the dynamic state of the VIA. But that would need 8 bytes of ZP, and even then couldn't completely guard against the problem - the row responses on Port A might still change in the brief time it takes to read each value as the column in Port B changes. Well, I'll keep it in reserve in case the issue manifests as a bigger problem later.
I've been testing the keyscan routine as I go along, and encountered a couple of glitches - a weird cursor-redraw issue where the cursor unexpectedly dropped to the bottom of the screen sometimes, and a peculiar effect during CRLF processing when the Enter key is pressed in which the cursor drops two or three lines down the screen instead of just one. The redraw glitch turned-out to be a simple case of a CMP where I should have had a CPX, but the CRLF bug is a little more complex and requires some deeper thought.
Once I've cracked that, it's really just a case of writing the specific handler routines for each action key - some, like the Cursor arrow keys, are essentially quite straightforward (just alter the cursor position variables appropriately) whilst others will need slightly more sophisticated logic, like the Backspace key (which is a combination of a cursor position change and an update to the text buffer to remove a character). That's what I'm working on right now, in between fixing the occasional hidden gotcha in existing code as I go along.
Once I've cracked that, it's really just a case of writing the specific handler routines for each action key - some, like the Cursor arrow keys, are essentially quite straightforward (just alter the cursor position variables appropriately) whilst others will need slightly more sophisticated logic, like the Backspace key (which is a combination of a cursor position change and an update to the text buffer to remove a character). That's what I'm working on right now, in between fixing the occasional hidden gotcha in existing code as I go along.
I've also been thinking about the dirty-row processing mechanics, principally to see if there's a way to reduce the 25-byte ZP table back down to 4 without taking a performance hit. You might recall that I originally had each dirty-row flag as a single bit, thus requiring just 4 bytes to hold all 25 flags, but abandoned the idea because the logic to determine which bit of which byte to set or clear was too slow. Well, I think I've come-up with a way to make it quite efficient, and will give it a go once keyboard handling is finished - it's worth a couple of hours of fiddling to see if it'll fly, if the payoff is 21 bytes of ZP space freed-up.
No comments:
Post a Comment