IBM Model-F-like keyboard designs

[RickCHodgin]

The key spacing I'm going to go with is a key with a fingertip surface area that's 0.6" x 0.6" (15.24 mm x 15.24 mm) for standard keys, with a full key stride (between keys) of 0.75" (19.05 mm). This will produce a core keyboard size of 11.25" x 4" (285.75 mm x 101.6 mm).

Visualized here:


This 0.6" x 0.6" fingertip surface area is 0.1" wider and taller than the traditional IBM Model F keyboards from the 1980s. The overall key size is the same, however. As such, they will have slightly steeper sides. Each key will retain the traditional / familiar height and orientation, however, except that I also intend to introduce some curvature on the front-to-back axis, in addition to the existing side-to-side axis.

Other key widths are given as:

Code: Select all

Tab               1.10"
Caps lock         1.39"
Left shift        1.78"
Left ctrl         1.29"
Left aux left     0.89"
Left aux right    0.89"
Space left        1.29"
Space middle      1.29"
Space right       1.29"
Right aux left    0.89"
Right aux middle  0.89"
Right aux right   0.89"
Right ctrl        1.29"
Right shift       1.78"
Enter             1.39"
Backslash         0.89"
Escape            0.89"
Escape 2          0.89"
Escape 3          0.89"
T7                0.89"

I've also decided that for the initial product releases, I will not ship a larger combined key for the 0 on the numpad key, nor for the Enter key on the numpad, or the plus sign on the numpad.

UPDATE Jul.04.2017: I have decided to use a 0.73" wide x 0.75" high key stride. This is 0.002" different than the original IBM Model-F keyboards per key.

Thank you,
Rick C. Hodgin

[Chyros]

Personally, I'd keep the main alphanumeric as standard as possible. With this many keys, and no real space restrictions, there is no reason to redesign the main block IMO. Making it so that stabilised positions have sensing pads under them (for customisation, as IBM did) would be good, though.

[Wingklip]

If you could make this as the font I would kill for one

https://www.myfonts.com/fonts/kinobrand/nixin/

[RickCHodgin]

If you could make this as the font I would kill for one
https://www.myfonts.com/fonts/kinobrand/nixin/

I have an editor. You'll be able to buy custom keycaps with any text on them you want, in any font and font size you want. You'll also be able to upload a custom black and white bitmap for completely custom shapes.



Thank you,
Rick C. Hodgin

[Wingklip]

These are Standard buckling spring caps right?

[RickCHodgin]

These are Standard buckling spring caps right?

I plan them to be, but the needs of manufacturing may require they only be similar, and not directly interchangeable. However, I will strive greatly for interchangeability.

Thank you,
Rick C. Hodgin

[Chyros]

Damn, you want to be able to make custom keycaps? Oo

Holy guacamole =D .

[rsbseb]

Nice work Rick, keep it up. This is a cool project and I hope you remain in a position to see it through to completion.

Damn, you want to be able to make custom keycaps? Oo

Holy guacamole =D .

SBS should have options for custom caps after the first round

[XMIT]

Damn, you want to be able to make custom keycaps?

On the contrary, I think a lot of you don't realize just how trivial it is to make your own dye-sublimated caps, and what a ripoff they are.

Here's what you need, as an example:

Epson inkjet printer
Heat transfer inks
Heat transfer paper
An oven
Scissors
A silicone mold to hold the transfers against your subject with some pressure in the oven

Full color legends really aren't that hard to do.

[rsbseb]

Damn, you want to be able to make custom keycaps?

On the contrary, I think a lot of you don't realize just how trivial it is to make your own dye-sublimated caps, and what a ripoff they are.

Here's what you need, as an example:

Epson inkjet printer
Heat transfer inks
Heat transfer paper
An oven
Scissors
A silicone mold to hold the transfers against your subject with some pressure in the oven

Full color legends really aren't that hard to do.

I agree, dye sub is over rated in the sense that a premium is charged for it. I am convinced that IBM made the move to cylindricals to facilitate the easier application of dye-sub legends because it was less expensive, ultimately leading to a long run of monotone keyboards and the unnecessary obsolescence of spherical caps.

Dye-sublimation is a great technology but it's implementation is fairly straight forward, you could even skip the printer and pad print directly onto the caps from what I understand, that is about as low tech and trivial as it gets. There are tons of full color promotional items out there using the technology, it is versatile and easy to do with minimal setup for any given application.

[RickCHodgin]

The keys I manufacture and sell will have the key letters and shapes machined into the surface with a flat end-mill, and then will have the reservoirs filled with a thick polymer ink (up to four colors per key, each in isolated wells). This ink can be touched-up later as it begin to wear away through use by something like dipping the tip of a paper clip into the paint, and touching it to the key surface, wiping away the excess, and then exposing to UV light to cure (or strong direct sunlight for a few hours).

I intend also to produce custom 3D key mold tops, which will allow 4 mm of material to be machined into a 3D shape using a tiny ball end mill. This will produce a key that's about 2-3 mm higher than other keys at its apex.

When custom keys are designed, or custom 3D key mold tops, an accurate 3D simulation will show you in advance what the key will look like. You can rotate it in a 3D preview, and alter the pattern as needed to get it just the way you like.

All of this is subject to James 4:15 constraints though (I mean, this is my plan, but we'll all have to see what life has in store for me).

Thank you,
Rick C. Hodgin

[RickCHodgin]

I've been able to settle on the official key size. It will 0.73" wide by 0.75" tall, which is within 0.002" of the original IBM keycap sizes (at 18.5mm x 19.0mm, which is 0.728" x 0.748"). The key top landing zone for your fingers will be a little bigger at 0.60" x 0.60" (compared to about 0.47" x 0.55").

I've worked out the design layouts and key codes for the Model Ds and Model Gs, Model Es are next.

I've worked out the keyboard hardware logic and am coding the driver and edit screens. I was originally going to allow full key rollover, but I think I'll limit those to auxiliary keys (shift, ctrl, alt, aux keys) and just do the rest by row/col. I'll also create a simulated on-screen keyboard to use for testing the full driver stack until the keyboard is complete and input comes from the real hardware.

I have been researching and designing the hardware for the 3D manufacturing tools I'm creating. I'm about read to start coding their drivers as well. I am working with someone at my local makerspace club on using Arduino hardware to build the prototype, as I'm still having trouble getting support from Lattice Semiconductor on their ECP5 FPGA. It's been the most frustrating part of this project to date, but I still think it's workable. If not, I'll switch to another FPGA vendor.

Things are progressing. It's just a tremendous amount of work. It's good to see steady progress though. I'm reminded of a famous quote, "I love it when a plan comes together."

Thank you,
Rick C. Hodgin

[Chyros]

Are you doing this fulltime? Oo

[RickCHodgin]

Are you doing this fulltime? Oo

It's my primary focus, but I have a regular full-time job, and a few other things which periodically take precedence. I view these keyboards as the spring board for all of my other software and hardware goals.

Thank you,
Rick C. Hodgin

[RickCHodgin]

Here are the keyboard layouts and key assignments:

Model G -- General Purpose






Model D -- Developer






Full Model Visualizations


Thank you,
Rick C. Hodgin

[RickCHodgin]

New UK Machines logo:



And a link to the keymaps file outlining the design of each keyboard logically:

Thank you,
Rick C. Hodgin

[fruitalgorithm]

I'm working on the UI software right now. The GUI is being written in Java so it will run essentially the same on any machine.
A thin OS-specific driver to interface with the keyboard will be written in C++. That driver will be able to take a file generated from the GUI to populate macros and key assignments for various operations.

Writing even small drivers is a pain as you have to maintain and adjust them for OS updates. You could go with a much simpler solution. I quite like how the Kinesis Advantage 2 does it.

View and edit layouts
With SmartSet, all your custom layouts are saved and stored as basic .txt files directly to the keyboard. These files can be opened with any text editing program, on any operating systems. Edit your remaps or macros from the text file or insert new actions using the keyboard HID codes. You can also run a quick Status Report to confirm current keyboard settings.

Share and backup layouts
Since each layout on the Advantage2 is stored as a basic text file (typically less than 1KB), they are super easy to save, backup or even share with a friend. The days of rebuilding your custom layout from scratch are over.

A simple open file format will not only make it easier for you, it also enables others to write their own tools to generate them.

Or do you have plans for features, that wouldn't be possible with an implementation like this?

Designing and building not one keyboard but a whole family of boards is quite the challenge. I wish you success.

[RickCHodgin]

Or do you have plans for features, that wouldn't be possible with an implementation like this?

The keyboard driver will actually be a very small part of the overall design. It will only need to communicate with the USB port. The code to do that between OS versions shouldn't change much (if at all).

The bulk of the keyboard processing will take place in the layers above that. That higher level code will be written in Java, and can be updated regularly with new versions. And, the source code for all of this will be available. People will be able to take the full product (hardware and software) and create their own manufacturing company and/or modify any component of it as they see fit.

It's a lot of work to do a project like this. I'm very keen on getting through the entire process from idea to sales. But most people would rather just buy something already made and basically pay someone else for the labor involved in making and maintaining the thing so they can just move on to the next thing in their life.

Thank you,
Rick C. Hodgin

[fruitalgorithm]

Needing a driver means the keyboard can't be used with iOS or Android. It also means it can't be used in corporate environments where end users have to get permission to install software. This keyboard also looks like it's designed to last a while. Are you prepared provide a decade of driver updates for macOS, Linux, and Windows?

I haven't yet noticed any feature on your keyboards that would necessarily need a driver. Or is the driver only needed for adjusting configurations and the keyboard would work fine without it installed?

[RickCHodgin]

Are you prepared provide a decade of driver updates for macOS, Linux, and Windows?

This is my company's flagship product. I plan for it to be the propellant that drives every thing I have forward in software and hardware. I plan to support it or its derivatives for decades to come.

...is the driver only needed for adjusting configurations and the keyboard would work fine without it installed?

The keyboard needs a driver to setup custom / macro programming. Once setup it can work as a generic USB keyboard just by plugging it in.

Thank you,
Rick C. Hodgin

[RickCHodgin]

I haven't yet noticed any feature on your keyboards that would necessarily need a driver.

The Model Ds each have three trackpoints. When connected generically it will report one. When a driver is present, it allows all three to act independently, allowing for combinations to do certain things: left+center is one set of abilities, center+right is another, and left+right is a third.

This independent / simultaneous expression allows for custom navigation through a 3D app, for example, by receiving multi-axis trackpoint stick positions, and computing through a custom add-on DLL the necessary callbacks into the 3D app to give it navigation data. The same would be true to allow custom editing, mixing, and playback abilities in soundboard apps, etc., and in gaming, etc.

The custom driver also has contextual awareness, meaning whatever app has keyboard focus allows for a common keystroke to exhibit the desired behavior. Alt+T,O for Options in one app, Alt+E,P for Options in another, so you define a single "Options" key and no matter what app you're in you just press the key and it sends out the appropriate keystrokes. It would detect the running process and alter the keystrokes emitted based on how it's been setup.

The driver also has the ability to enable a heads-up display, which allows for a desktop window to show you what keys are defined in a particular area of the keyboard (the area last pressed) so that you can have a type of cheat-sheet that's always available, and is continuously contextual.

Et cetera.

There are a lot of reasons to have a custom driver.

Thank you,
Rick C. Hodgin

[hoaryhag]

How you like me now, brah. C-C-Coo-Coo-Cool.

IBM interchangeable keys would be icing. I might miss the audible feedback of an F with a silent buckling spring, but if you can pull it off I would love to give it a chance. I wish you the best in your endeavors.

PMS: Sacrilegiously, I'm glad your F battleship bit the soldering iron in the name of UKM.

[RickCHodgin]

I might miss the audible feedback of an F with a silent buckling spring, but if you can pull it off I would love to give it a chance.

It won't be completely silent, but it will be pretty silent. I still don't have the full-scale mockup completed, so it's all still theoretical. My goal is to have the same feeling, and for it to be no louder than the Model F/M's, but preferably more silent than the KPD-8923s, which are the keyboards I use daily.

I wish you the best in your endeavors.

Thank you. A lot of people are looking at this project. They think I've bitten off far more than I can chew. Sometimes I think they may be right. I have a list of things to get from A to B, and I'm just going through them one by one.

Thank you,
Rick C. Hodgin

[wobbled]

What's the 'end game' for this project? Are they going to be boards for personal use or will you be selling them via GB's?
Also what would happen if you replied without signing it with your name?

[RickCHodgin]

What's the 'end game' for this project? Are they going to be boards for personal use or will you be selling them via GB's?

I plan to manufacture sell the full product line. The products are currently being developed with the intend being on production manufacturing. There will be a website to place orders, as well as the ability within the keyboard driver itself to design and order custom keycaps.

I plan to have my company manufacturer and sell these products world-wide.

Thank you,
Rick C. Hodgin

[RickCHodgin]

Also what would happen if you replied without signing it with your name?

I don't know. Let's find out.

[Chyros]

Oh, so it's going to use SILENCED buckling springs? Even more video review material ^^ .

[RickCHodgin]

Oh, so it's going to use SILENCED buckling springs? Even more video review material ^^ .

Maybe I should write a summary post for those who haven't read through the information that's been conveyed in this thread.

[wobbled]

That's awesome Rick, I'll definitely be picking up one of the behemoth looking ones! Even if it is more keys than I'll ever know what to do with. I'm sure Thomas on the other hand has each individual key already planned out while still having the need for his macro pad.

[RickCHodgin]

That's awesome Rick, I'll definitely be picking up one of the behemoth looking ones! Even if it is more keys than I'll ever know what to do with. I'm sure Thomas on the other hand has each individual key already planned out while still having the need for his macro pad.

I've been considering what to do with the keys by default. I have some ideas jotted down.

What are some features you all would like to see
by default with the extra keys along the left on the Model Gs, and up on top and along the left and right on the Model Ds?

I have these ideas:

Code: Select all

UKM (one-button access to bring up the GUI Interface and cheat sheets)
Cut (Ctrl+X by default)
Copy (Ctrl+C by default)
Paste (Ctrl+V by default)
Open (Ctrl+O by default)
Close (Ctrl+W by default)
Save (Ctrl+S by default)
Desktop (internal OS code)
Next Window (internal OS code, brings mouse pointer to window as well)
Prev Window (internal OS code, brings mouse pointer to window as well)
Volume up
Volume down
Mute
Record [O]
Play |>
Stop [ ]
Pause ||
Forward >>
<< Rewind
< Skip
Skip >

And a few others that are contextual, such as when Blender is running, a host of single-button commands on the Model D3 312-key keyboard. When Visual Studio is running, some commands for debugging along the top keys, etc.

Ooops... almost typed my "Thank you, Rick C. Hodgin" signature from muscle memory. And I know now that would be bad. LOL