...and that right there can be a problem. For my workbench computer's tiny keypad, I used 30ms debounce time in the software. That was probably a lot longer than a new button would need, but eventually the button I press most started bouncing longer than that. I initially increased the debounce time (in software), but finally just replaced the button.

We've all seen calculators and various other pieces of equipment where software debouncing (if they even had any) had become inadequate and there were no replacement switches available anymore. With some calcs, if they're valuable enough, you can open them up and clean and doctor-up the contacts, while with others there may be too much risk of damaging something else in such an effort.

Whatever path you take, it would be good to leave options open to easily change the debouncing periods in the future. And for various programs or user preferences, it would be good to be able to easily modify the time-before-repeat and the repeat rate for when a key is held down, and of course not all keys will be treated the same, like the shift key and probably function keys which you would not want auto-repeating.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Right. I'm reasonably sure Cherry MX keyswitches will live up to their specs, as they're designed for heavy-duty office typing and there are quite a few old Cherry keyboards floating around with happy users. A random cheap switch is more likely to degrade with use. Still, that sort of flexibility is why I left the debouncing timeout in a software-programmable register.

I managed to throw together a simplified controller this afternoon. This reduces the part count to eight 74HC ICs (down from sixteen, of which two are not 74-series), considerably reduces the size of the PCB, and changes the input clock to 32kHz rather than 8MHz (so you could reasonably combine this with an RTC, and have the latter provide the oscillator). I even managed to route the tracks without using any vias.

Three of these ICs are needed just to interface to the row and column lines, and were thus carried over from the full design. A further three act as a column sequencer (presettable 4-bit counter), an output buffer (tristate octal inverter), and a bus signal interpreter (quad 2-input NOR). The two remaining are an interrupt generator (8-input NAND) and a dual flipflop to permit the counter and the interrupt to be switched off during the software scan. And that yields a similar type of operation to the BBC Micro's keyboard, except that the six rows can be read simultaneously instead of having to scan individual keys (after finding a column that has a key pressed).

With 16 columns being scanned at 32kHz, an interrupt is still generated within 0.5ms as with the full controller. However, the interrupt must then be serviced with a full scan, which takes some time because the RC filters have to be allowed to settle at each column. The simplified controller also cannot detect when a key is released by itself. So the CPU overhead is somewhat higher and the latency slightly higher than with the full controller, but it still supports N-key rollover (unlike the BBC Micro).

I haven't worked out the precise difference in cost yet. But I think it's going to look very small next to the cost of the keymatrix. Mouser lists MX Blues at about €0.70 each in quantities of 50+, or linear switches at €0.60 each, so a full 96-key board with diode packs will be in the region of €100.

Some interesting keyboard layouts that can be accommodated by a 96-key matrix:

- IBM PC-AT, "tenkeyless" variant, in either ANSI, ISO or JIS layouts, with the full set of navigation and function keys. JIS is much like ISO, but with three extra keys around the spacebar to deal with the multiple writing systems of Japanese; in this form it needs 87 keys if I've counted them correctly. Build a keymatrix in this form, fit a standard set of Cherry MX keycaps, and add a microcontroller to perform scancode and protocol translation to PS/2 or USB; it'll probably outperform any standard PC keyboard in terms of latency.

- BBC Master, which adds a 19-key numpad to the existing BBC Micro layout, yielding 92 unique keys if we include BREAK (which, on the real thing, is actually hardwired to /RST and not to the keymatrix). The two Shift keys are wired to the same location on the matrix, so count as one.

- Symbolics "space cadet". Yes, really! It has 100 keys, but the incredible seven modifier keys are duplicated on each side, and I've seen no evidence that these duplicates can be distinguished by the host computer. If we gang them together, that reduces the number of keys actually needed to 93, comfortably within our limit. So if you hanker for the ability to directly type APL symbols…

- Most scientific calculators currently on the market have about 50 keys, if you include the D-pad that many of them have acquired along with visual equation editors. Several functions are usually multiplexed onto each key.

- Sharp PC-E500S "pocket computer". This foregoes the traditional rows of numeric and function keys above the alphabetic keys, in favour of a numeric keypad and scientific calculator keys to the right. Most ASCII symbols are relegated to non-standard modifier combinations. The resulting L-shaped layout conveniently leaves room for the screen. This is probably what I'll try to adapt for my "desk calculator" project, but hopefully with better access to punctuation.

My HP-71B hand-held computer only has 55 keys, with two shift keys (f and g), and a number key pad. Everything is re-assignable, with three kinds of assignments possible, and you could have lots of different key-assignment files and copy one or another into the KEYS file for one application or another, usually for typing shortcuts. The keyboard is about 2/3 normal size (the entire HP-71B being only the size of a large calculator), and with narrow fingers, I was able to touch-type 30wpm on it back when I was doing it a lot.




If you really want a minimalist (one-handed!) keyboard yet one you can type really fast on, check out the FrogPad:
https://www.youtube.com/watch?v=RNsrfaHl9kI
I wish it had caught on. I'm sure one reason it didn't was that the patent holders were too greedy and wanted nearly $200 for this thing! I wanted one, to save room on my desk, but couldn't justify the price for a keyboard.

Then there are the 40% keyboards which are made to make you faster:
https://www.youtube.com/watch?v=AKGXZ1ReU54

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

That HP-71B does look interesting. I'm reading the manual, and there are plenty of ideas there for how to handle a sophisticated mode of calculator input.

The FrogPad, though, looks like an absolute nightmare to me. Setting aside all the muscle memory I've built up around QWERTY… The hardware looks easy enough to build (though 20 keys would make my 16x6 controller design frankly overkill), but the poorly-written manual reveals some disturbing engineering considerations, baked into the software/firmware to convert keypress patterns into normal keystrokes. In particular, it states that single (non-chorded) keystrokes have a non-configurable 500ms latency to disambiguate them from chorded keystrokes. And these are exactly the same keystrokes that are claimed to make up 86% of English text. I assume that the key-up event, or a key-down that isn't one of the modifier keys, terminates that chording timeout, but that just means you have inconsistent keystroke latency.

IMHO, be glad you saved your money.

and the basic manual hardly scratches the surface as to the power of the 71 had, some of which came through really outstanding LEX (Language EXtension) files contributed by the user groups. I have about 350KB of memory in mine, half ROM and half RAM. I'd still say the 71 is not as practical to use as a calculator as the 41 is though. The 71 is more of a hand-held computer. The 41's keyboard is not suitable for fast typing like the 71's is though, even though I use my 41cx's text editor for entering notes, phone numbers, and Daytimer information. I have an 80-column monitor that works for both though.

I had not seen the 500ms latency part of the FrogPad. If you're not selling them (which would violate the patent), you could take the idea and refine it to your likes.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I wonder what that 500ms might mean - the chap in the video was typing really fast.

A side-effect of attaching such a thing to a standard PC is that it has to translate the chorded keystrokes into normal ones. But on the FrogPad a single keypress can't be converted into a keystroke instantly, because there might be a second keypress forming part of the same chord following a few milliseconds later. Worse, the primary modifier key (with the green square, selecting the green character rather than the white one) is actually the space bar when pressed alone, so the ambiguity exists whichever key happens to be pressed first. And the recommended method of typing the most common keys will naturally lead to a second or even third key in a sequence being pressed before the first one has been released.

For example, suppose you want to type the word "hotel". The first four letters are "primary" as they occur very frequently in English, so you type them with single keypresses from the home position. The L is the secondary letter on the H key, so you have to press it together with Space (the latter with your thumb). Then you have to press Space by itself to move on to the next word.

If you do this slowly and deliberately while watching the screen, the wording in the manual suggests you would see H-O-T-E and the space appearing only when you release the key, or half a second after you pressed them, whichever comes first. If you overlapped the keypresses, you would probably see the first letter appear when the second letter was pressed. Only the L would appear immediately when both keys were correctly pressed. That would drive me crazy!

The layout of this keyboard and the above behaviour also makes it unsuitable for gaming or coding. That in itself is also a dealbreaker for me. But I do note that it was originally designed for use with mobile phones, where compactness is a virtue and the need to enter anything other than normal text is uncommon.

Clearly there is a lot of learning necessary; nevertheless, the person demo'ing it in the video was doing over 80wpm, which is considerably faster than I can do on a full-sized keyboard.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Learning how to use that keyboard would not help me for the things I actually do with a keyboard a lot of the time. I would need to have a normal keyboard to hand to do those things. Hence, no advantage. The apparent latency quirk is just something bizarre to note in passing, given the emphasis I've put on minimising latency in my own design. Half a second is clearly too long for the purpose of detecting key-down events that are nominally simultaneous; something in the region of 100ms would be significantly better. Even this is three times the average latency of the "typical" PC keyboard.

FWIW, my day job, such as it is, involves research into reducing Internet latency (and thus improving perceived reliability) under congested conditions. Already we have technology which succeeds quite well at limiting the added delay to 5ms (versus the 800ms I often see my ISP adding at busy times) whilst actually increasing useful throughput relative to the untreated network. To me, 100ms is actually quite a long time.

Finally got around to sketching a key layout, to see how it might fit together in practice. As a warmup, I started by trying to replicate something more familiar:

The typeface isn't quite right, but I'm sure many of you recognise that for what it is. Things get somewhat more interesting when I let my creativity out to roam:

The three orange and three blue shift keys are all ganged together, so only take up two spots on the keymatrix in total. Together they facilitate a calculator-style extended keypad on the right, an alphabetic and symbolic group to the lower left, some navigation keys, and 27 function keys that are not yet assigned functions. The large gap to the upper left seems like a convenient place to put a display.

Close examination of the secondary legends should demonstrate that I'm going for an engineering/programming emphasis with my calculator, rather than the financial/statistical emphasis of most existing "scientific" calculators. The upper half of the keypad allows specifying SI prefixes (deka, hecto, kilo, etc. - and of course deci, centi, milli as well), while the units those prefixes apply to can also be specified via the alphabetic keys, thus allowing robust dimensional analysis to be implemented (often very useful for checking the correctness of an equation). The reciprocal units are specified by including the blue shift with the orange, as illustrated by the hertz and siemens legends on the same keys as seconds and ohms respectively. I should also be able to find a way to incorporate the English engineering unit systems as scaled versions of the SI ones, consequently getting straightforward unit-conversion functionality almost for free.

At the same time, all of the printable ASCII character set is included in one way or another, so using this keyboard to enter a general-purpose programming language should be quite feasible. The numbers and +/- symbols require moving to the keypad, but all of the brackets are present on just two keys with appropriate modifiers. (The green legends indicate using both of the shift keys together.)

This should actually be quite fun…

The Beeb's keyboard handler does some n-key rollover, it handles two and a half keys - two keys and a third check to simplify overflow from two keypresses.

The code can get a bit complicated, and as a bit of archeology, the BBC MOS 0.10 got it wrong. (Somewhere it's documented as working "by accident".) But once you understand what's happening it's fairly straightforward, and I've written a USB keyboard driver based on it.

_________________
--
JGH - http://mdfs.net

Technically that would be "2-key rollover with anti-ghosting", rather than N-key rollover. The latter specifically refers to the ability to handle *any* number of keys pressed simultaneously. For comparison, the standard USB-HID protocol supports 6-key rollover.

That's what I was trying to remember!

_________________
--
JGH - http://mdfs.net