Live data from Hacker News

A USB Interface to the "Mother of All Demos" Keyset

righto.com

81–90 of 92 posts

Re: A USB Interface to the "Mother of All Demos" Keyset

#81
post #57

Earlier quoted context omitted.

Hi Don. I think this stuff is great, and applaud your work, so don’t think of this as a slight (depending on the answer, of course): how practical is this? Again, if the answer is approximately “not at all practical”, that’s fair, but I guess I could also see it fitting somewhere on a spectrum like emacs vs vi, QWERTY vs Dvorak, etc…

I’m doing it for the looks and feels. Making it public and open so others can take a look and feel free. (Ha ha, I got a billion of 'em!) ;) It does have a distinctive visual look and physical feel. And while it’s not as sleek or ergonomic as the latest Logitech mouse (who gave him an office at their headquarters from 1992 to 2007), it’s pretty great to actually touch and hold -- just to grasp firsthand how far input…

I might be misunderstanding, but are you talking solely about the most here? I'm mostly curious about the chorded "keyboard"(?) as an input device - have you spent time with it as a daily driver? How does it compare to a traditional keyboard? I would guess a keyboard would be easier for a beginner, because ~1 key per symbol, and the keycaps are all printed (though I'm sure many of us remember our untrained selves scanning the entire keyboard intently, looking for whatever letter had eluded us) - so chorded input would be more of a learning wall than a learning curve, but once that's achieved... is chorded input ~100% speed of a QWERTY kb, or 10%, or 150%? Is it more or less tiring, physically and mentally? Very interested in your experience.

Re: A USB Interface to the "Mother of All Demos" Keyset

#82
Custom mechanical keyboard firmware like QMK [1] and ZMK [2] support custom chords called "combos". Basically if the combo's set of keys is hit (within some timeout which defaults to 50 ms) then a specific keycode is sent. You then get a fun game of identifying low probability combos and mapping then to useful keycodes. You also start realizing there's some prime real estate to take advantage of. Two-key combos require some thought cause bigrams can be surprisingly common. Three-key combos are basically open though.

In migrating from the ZSA Voyager to a 36-key keyboard (Chocofi) I've relied on combos as I don't like overloading keys with tap-versus-hold behavior as I can never get the timing down. For example my left index, middle, and ring finger mashed down on the home row (resting position) is escape in my current layout (Colemak mod DK which means keys R, S, and T). It's three fingers but hardly any extra effort. I've managed to do away with a symbol layer and have been quite happy with the result. If anyone is curious here is my "36-key training layout" for the ZSA Voyager [3] and my current Chocofi layout [4].

1: https://docs.qmk.fm/features/combo

2: https://zmk.dev/docs/keymaps/combos

3: https://configure.zsa.io/voyager/layouts/d7L0v/latest/0

4: https://github.com/vietjtnguyen/zmk-chocofi/blob/main/config...

Re: A USB Interface to the "Mother of All Demos" Keyset

#83
post #36

The original chording keyboard was from Baudot, around 1897.[1] The original plan was for the sender to send 5-bit teletype characters with a 5-bit keyboard. This was deployed, not just a prototype. [1] https://collection.sciencemuseumgroup.org.uk/objects/co33197...

Here is a great run down of that history:

https://computer.rip/2024-02-25-a-history-of-the-tty.html

Early versions had to be mechanically synced at the sending and receiving side. The typists had strict timings so the other end could receive it. This led to a version of punch cards that could be pre-typed and then fed in automatically, reducing the skill needed of the operator. The linage to teletypes were almost obvious.

Very good read, don't want to spoil too much.

Re: A USB Interface to the "Mother of All Demos" Keyset

#84
post #83
post #36

The original chording keyboard was from Baudot, around 1897.[1] The original plan was for the sender to send 5-bit teletype characters with a 5-bit keyboard. This was deployed, not just a prototype. [1] https://collection.sciencemuseumgroup.org.uk/objects/co33197...

Here is a great run down of that history: https://computer.rip/2024-02-25-a-history-of-the-tty.html Early versions had to be mechanically synced at the sending and receiving side. The typists had strict timings so the other end could receive it. This led to a version of punch cards that could be pre-typed and then fed in automatically, reducing the skill needed of the operator. The linage to teletypes were almost obv…

The form of a keyboard had to be invented. Early printing telegraphs used a piano-like keyboard, with white and black keys.[1]

(Keeping both ends in sync was a huge problem. The machine shown was synched by having the sending operator send AAAAAAAAA while the receiving operator made adjustments. If the machines got out of sync, the receiving operator opened the line switch, which stopped local echo at the sending end. Then both ends had to repeat the AAAAAAAAA drill.

It took a long time, from 1846 to 1907, until Howard Krum finally came up with a mechanism that didn't have sync problems. Krum had the advantage that steel and stamping were available. The clock industry had figured out how to mass-produce mechanisms. Mechanism design then got out of the handmade brass era. This was, in its day, an advance comparable to going from tubes to ICs.)

[1] https://www.youtube.com/watch?v=zJCfhbPAv9c

Re: A USB Interface to the "Mother of All Demos" Keyset

#85
post #80

Earlier quoted context omitted.

Oh, that (waiting for all fingers to be detected) does indeed change how I would approach the scenario, and blew past me in my initial reading. That all said, even with 100ms cycles I would hardware debounce the inputs, capture the keystrokes with an ISR to set some semaphore variables, and then create a 100ms loop that checks the current value (and resets) those semaphore variables. Eliminating switch bounce allows…

Yeah, the 100ms wait after stability probably avoids any need to debounce. You need to debounce if you want to detect both keypress and keyrelease events reliably, though. For mass-production products it's cheaper to add 100 lines of code to your firmware than to add a resistor to your PCB, much less a diode, capacitor, and two resistors, but for prototypes and low-volume designs it's less clear. WRT ISRs, plausibly…

You're right, I should have chosen better words.

I merely meant setting a flag bit from 0 to 1, later to be picked up by your loop. Since actual semaphore was communicated with flags...

I have yet to see the perfect software debounce algorithm. I've come to believe that it is a Sisyphean task. Meanwhile, Schottky diodes are extremely well-suited to the task.

You might consider 100 lines worth of complexity to make a switch work to be free, but I won't lose any sleep believing otherwise.

Re: A USB Interface to the "Mother of All Demos" Keyset

#86
post #67

Earlier quoted context omitted.

The most successful chorded keyboard of all time is the Perkins keyboard used to produce braille. If you already know braille, it's much quicker to learn than touch typing on a regular keyboard because they keys correspond directly to dots in the braille character cell. And surprisingly, this advantage of not having to look at it also applies blind smartphone users, who can use an on-screen Perkins keyboard as an inp…

Not that I’ve seen a blind user using Perkins in real life, but the videos I’ve seen all seem to demonstate the “screen away” mode referenced in this article: turn the phone away from you but cradled in two hands, position your fingers on the screen in roughly the correct position, then you’re ready to start typing. To a blind user, the screen becomes the operating mechanism, and the perception mechanism is typically…

Yes exactly. It's more of a way to make use of many of the other pre-existing functions of the smartphone without having to have a purpose built device. Although there is at least one hardware addon i'm aware of for blind users:

https://www.iamhable.com/en-am

Re: A USB Interface to the "Mother of All Demos" Keyset

#87
post #2

Author here if there are any questions...

Hey, great to see this, thank you so much, Ken! I'm lucky to own an original Engelbart mouse and chord keyset too, and I want to make usable replicas by 3d scanning them, making 3d printable models, and embedding metal and electronic parts so they work via bluetooth! The first step is to take it apart, measure and weigh the pieces, 3d scan it, and make a realistic 3d printable all plastic model (like an easy-to-print…

I would suggest being sure to use a cpu platform well supported by ZMK to make your HID software easier. The esp32-s3 doesn't appear to have Bluetooth support in ZMK yet. People who want Bluetooth support are being encouraged to use the nrf52 platform. People who want usb only might be better with a rp2040 as there is better support in ZMK for that platform than anything esp32.

Re: A USB Interface to the "Mother of All Demos" Keyset

#89
post #84
post #83

Earlier quoted context omitted.

Here is a great run down of that history: https://computer.rip/2024-02-25-a-history-of-the-tty.html Early versions had to be mechanically synced at the sending and receiving side. The typists had strict timings so the other end could receive it. This led to a version of punch cards that could be pre-typed and then fed in automatically, reducing the skill needed of the operator. The linage to teletypes were almost obv…

The form of a keyboard had to be invented. Early printing telegraphs used a piano-like keyboard, with white and black keys.[1] (Keeping both ends in sync was a huge problem. The machine shown was synched by having the sending operator send AAAAAAAAA while the receiving operator made adjustments. If the machines got out of sync, the receiving operator opened the line switch, which stopped local echo at the sending end…

Great video.

Re: A USB Interface to the "Mother of All Demos" Keyset

#90
post #80

Earlier quoted context omitted.

Yeah, the 100ms wait after stability probably avoids any need to debounce. You need to debounce if you want to detect both keypress and keyrelease events reliably, though. For mass-production products it's cheaper to add 100 lines of code to your firmware than to add a resistor to your PCB, much less a diode, capacitor, and two resistors, but for prototypes and low-volume designs it's less clear. WRT ISRs, plausibly…

You're right, I should have chosen better words. I merely meant setting a flag bit from 0 to 1, later to be picked up by your loop. Since actual semaphore was communicated with flags... I have yet to see the perfect software debounce algorithm. I've come to believe that it is a Sisyphean task. Meanwhile, Schottky diodes are extremely well-suited to the task. You might consider 100 lines worth of complexity to make a…

Most of software is Sisyphean. 100 lines of code doesn't add any cost to your BOM, just NRE, and it's easier to simulate.
Post reply on HN