IBM Model-F-like keyboard designs

[RickCHodgin]

I did some shopping and found 18" x 24" copper PCBs, so I'll be designing for that size.

I'm going to use a 4 x 6 array of lasers, allowing for the 18" x 24" copper to be completely etched in about 10 minutes. That's two D1 Illuminators every 10 minutes.

The software will feed six channels about 1KB each per second, with about four strokes per second. I'll have about 0.05 mm pixel resolution, which is about 500 dpi.

Apart from the computer, a single FPGA, two drivers, and four laser drivers will power the device.

Thank you,
Rick C. Hodgin

[RickCHodgin]

I have ordered some preliminary parts for this laser PCB etcher. I will be designing a little mockup, and then having real parts machined.

I'll post some video of the mockup once I get it running (a few weeks most likely).

Thank you,
Rick C. Hodgin

[just_add_coffee]

I'm lurking around, but I wanted to thank you for the updates!

[RickCHodgin]

I'm lurking around, but I wanted to thank you for the updates!

Thank you for the note.

I'm really enjoying this project. In designing my own keyboard circuits, I'm now seeing how Tom Wong and his xwhatsit controllers operate. It's very interesting to see it all unfolding before my eyes.

Here's something else I found that I think is interesting. I was surfing tonight and I came across this awesome keyboard (left-side):


IBM made a 50-key keyboard similar to my planned Model E1 expansion keyboards! It gives me a great sense of "being on the right track" to come across things already done by people which are in line with my proposed ideas.

Thank you,
Rick C. Hodgin

[RickCHodgin]

Also here:


Very nice.

Thank you,
Rick C. Hodgin

[Chyros]

It's really cool seeing this project coming along .

[RickCHodgin]

Based on some of my early development and research, I've ordered a PCI FPGA card to handle the multi-axis controllers for two CNC-like machines I'm creating, one for key shaping, and one for key symbol etching (letters on the keys).

I'll be able to write software on a PC to do the majority of the 3D modeling for scheduling cut passes, and the PCI FPGA card will simply handle scheduling and coordination of each axis and input so that the device works in steps to conduct the full step-by-step operation to get from uncut to fully cut.

Board: http://www.mouser.com/search/ProductDet ... 5GEVNPROMO
PDF docs: http://www.mouser.com/ds/2/225/ECP5Vers ... 020976.pdf

This board plugs in to a PCI Express x1 socket on a conventional full-size PC motherboard. It allows high speed communication between the host PC and the FPGA. In this way, the burden of developing the software can be implemented using conventional development tools in C/C++ and even Java, making the burden of controlling the hardware far more flexible, with even a standard OpenGL 3D simulation of what it's doing available on-screen at some point.

Thank you,
Rick C. Hodgin

[RickCHodgin]

There was some delay in getting the license from Lattice Semiconductor. The person they have assigned to issuing license files was on sick leave last week and wasn't able to process any requests. I received a slurry of replies to my various emails yesterday, including three separate license files for the requests and follow-up requests I had issued.

So, I've received my license now and I was able to get everything setup yesterday. I'm beginning hardware development later this week. I plan to buy some stepper motors and begin coding for the the laser etcher software. I'll also continue work on the keyboard driver software.

----
I'm curious if any of you care to see these work-in-progress posts, or if you would prefer to just have me post again later when I get it all working and there are products ready for sampling?

Please let me know.

Thank you,
Rick C. Hodgin

[Chyros]

No, very much interested in the progress posts! Please keep on making them .

[Scottex]

Yeah, keep it up buddy
Really interesting project you've got here

[ramnes]

Just lurking, not much to say… but please keep posting!

[ohaimark]

Please keep posting. Your in-house process will serve as a useful reference for other ambitious designers.

[zool]

I know you already have your fpga, but in case you get stuck you can alway check out this dude http://store.mesanet.com/ , he makes some really nice fpga's and daughter cards that play nice with linux cnc. I use his stuff in my cnc, I implemented his RS422 little binary protocol for one of my keyboard on the hmi.

On the otherside, when thinking about your drivers and macros etc, if you can somehow think of a good way to do unicode code points rather than scan codes. It something that has been kicked around a little but I don't think anyone has really cracked it yet?

[RickCHodgin]

I know you already have your fpga, but in case you get stuck you can alway check out this dude http://store.mesanet.com/ , he makes some really nice fpga's and daughter cards that play nice with linux cnc. I use his stuff in my cnc, I implemented his RS422 little binary protocol for one of my keyboard on the hmi.

I'm having difficult getting help with my Lattice Semiconductor ECP5 board and toolset. I've been trying to figure out what to do to move forward. For now, i'm going to continue working on the software knowing that the hardware is a relatively small piece of the overall puzzle, just an absolutely critical one.

On the otherside, when thinking about your drivers and macros etc, if you can somehow think of a good way to do unicode code points rather than scan codes. It something that has been kicked around a little but I don't think anyone has really cracked it yet?

What do you mean? I plan to allow standard font inputs, which allow you to specify any UNICODE keystroke, such as Alt+0250 for this character: ú

By doing that, I will then draw that character to a white background and convert its black pixel data to a map which describes the geometry I'll need for the key, and then convert that into strokes of the cutter so the shape is etched. And the preview tool where you set it up will show you exactly what it will look like because the tool will only have a certain resolution for minimum "pixel" sizes.

Looking forward to being able to show everybody what I'm talking about.

Thank you,
Rick C. Hodgin

[zool]

What do you mean? I plan to allow standard font inputs, which allow you to specify any UNICODE keystroke, such as Alt+0250 for this character: ú

I mean for the controller interface, eg so that you can define a "‽" key rather than just an input macro. which for me to get "‽" is ctrl+shift+u 203d not alt+8253 it would be way nicer to have the utf8 "scan codes" eg E2 80 BD.
But I really put this in the too much hassle to worry about category, too many weird cases, but if you happen to come up with a good idea...

[RickCHodgin]

What do you mean? I plan to allow standard font inputs, which allow you to specify any UNICODE keystroke, such as Alt+0250 for this character: ú

I mean for the controller interface, eg so that you can define a "‽" key rather than just an input macro. which for me to get "‽" is ctrl+shift+u 203d not alt+8253 it would be way nicer to have the utf8 "scan codes" eg E2 80 BD.
But I really put this in the too much hassle to worry about category, too many weird cases, but if you happen to come up with a good idea...

Ah I see. The macro ability of physical keystrokes will go through several stages:

(1) Physical keystroke to alternate / logical keystroke mapping.
(2) Logical keystroke mapping to macro expansion:
---(a) single scan code for a hard key
---(b) multiple scan codes for a key sequence, for "username"
---(c) full keystroke combination substitutions, like for a "Copy" key recording Ctrl+C as [Ctrl-down], [C-down], [C-up], [Ctrl-up], or for a more complex thing like , , [e], [r], [n], [a], [m], [e], [tab] with each key having down,up sequences.
---(d) callback to user-developed add-on modules which determine what content to insert or convey by the user app's guidance.

And each of these will be contextually definable by the running process, such that in application 1 the keys can be mapped this way, in application 2 they can be mapped this way, and so on.

I also plan to be able to download some of that information to the keyboard itself, so that it won't have to use a driver on another computer, but can simulate output to a 104-key keyboard, for example, through mapped key combinations on that keyboard such as one of the Illuminator keys shows up as Ctrl+Shift+Alt+F4,F9 which makes it unique and identifiable as a two-key combination in some app (just as an example).

-----
It is a very comprehensive mapping system, and I'm planning to make it all graphical so it's easy to follow via simulation, you can see that physical key number 123 comes in from the keyboard, which is mapped to 018, and that logical mapping to 018 goes to option (b) above where it inserts your username, for example.

Thank you,
Rick C. Hodgin

[FoxWolf1]

What an interesting project! I've long been a fan of the TrackPoint pointing device, as well as of the concept of distributing multiple integrated pointing devices over a larger keyboard so that one is always at hand.

One thing that does occur to me, looking at your layout diagrams, is that there seems to be a large gap in pointer availability around the arrow key/number pad region. I often find myself wishing for a system where a pointing device was present near the arrow keys, for seamless switching between analogue and digital methods of caret manipulation as the situation dictates, and simply because it's a fairly common region for one's hand to occupy.

A couple of potential solutions occur to me. One would be to have a TrackPoint slightly above and to the side of the up arrow, as in certain Access-IS airport keyboards. Another would be to replace the arrow keys with a trackball, but then build mouse-style buttons with arrow key functionality into the ball surround, as on a Focus FK-7000P. Either of these solutions would, unfortunately, involve nixing the bonus keys around the arrows, though, on the plus side, they'd also allow you to achieve the goal of having multiple pointing devices for multi-axis analogue control on "G" series as well as "D" series models.

[Chyros]

Honestly can't wait to have one of these juggernauts on my desk ^^ . Got a good name for it already, too!

[seebart]

Honestly can't wait to have one of these juggernauts on my desk ^^ . Got a good name for it already, too!

This is the one right...

king-keyboard_designs.png (204.41 KiB) Viewed 5769 times

[codemonkeymike]

Honestly can't wait to have one of these juggernauts on my desk ^^ . Got a good name for it already, too!

This is the one right...

king-keyboard_designs.png

I think this is an image of all the possible options that could go below the function row.

[wobbled]

Honestly can't wait to have one of these juggernauts on my desk ^^ . Got a good name for it already, too!

This is the one right...

king-keyboard_designs.png

That's a freaking behemoth

[XMIT]

RickCHodgin did you ever have a look at the "fleXMIT" layout?

keyboards-f2/chinese-usb-hall-effect-ke ... ml#p336107

The fleXMIT layout.

flexmit-keyboard-layout.jpg (156.31 KiB) Viewed 5764 times

My thinking was that, with a large enough matrix, the different sections of the PCB could have completely independent matrix positions, so that you can sort of mix and match them together. The big win (at production scale) is just making one PCB and chopping it up as needed.

Some of this thinking is in place for the Hall Effect keyboards I've been designing.

[cookie]

As a 60% guy this looks to me like an aircraft carrier where 60% boards are supposed to land on, refuel, take a nap and fly off to new missions.

But seriously, I am still very curios to see such an enormous project from start to finish.
This reminds me of this guy here: http://mykeyboard.co.uk/microswitch/ just way cleaner and less improvised.

Btw, would an teensy or atmega even be capable of supporting such a gigantic keyboard?

[RickCHodgin]

One thing that does occur to me, looking at your layout diagrams, is that there seems to be a large gap in pointer availability around the arrow key/number pad region.

That's true. It might be a good idea to have in that area.

...on the plus side, they'd also allow you to achieve the goal of having multiple pointing devices for multi-axis analogue control on "G" series as well as "D" series models.

There might be room between the arrow keys' vertical stack, and the numpad vertical stack, so it would be a key between the numpad 1 and 4 keys, and the key above the right arrow, and the extra bonus key above it. In putting my fingers there, it might be better to be up another row, but we'll see. I'll try some mockups.

It's a good idea.

Thank you,
Rick C. Hodgin

[RickCHodgin]

RickCHodgin did you ever have a look at the "fleXMIT" layout?

I have not. In fact, this entire design is off the top of my head. I haven't researched other keyboards, other than taking apart IBM designs and looking at them. Everything I've been doing is just me thinking it through and asking myself, "How should this work?" Or, "If I were going to do this, how would I do it?" And then I proceed.

I appreciate everybody's feedback on it. My family's given me a lot too. It's the first project of mine they've ever actually been excited about.

My only issues right now are with Lattice Semincoductor. I may have to switch vendors for the hardware portion.

Thank you,
Rick C. Hodgin

[RickCHodgin]

My only issues right now are with Lattice Semincoductor. I may have to switch vendors for the hardware portion.

I had a meeting with some local hardware gurus today. Things are looking up with my plans and goals.

Thank you,
Rick C. Hodgin

[RickCHodgin]

I've been discussing my keyboard plans with several of the people at the hardware guru place, and some of them are pretty excited about the possibility. They especially like my keyboard driver and how it's application-aware, allowing single keystrokes (like a "Settings" key) to be added, which is programmed to then use this key-combination in this app to then pull up settings, and this other key combination in this other app to then pull up settings, and in a third a different one, and so on, and all from the one "Settings" key. Same for print-screen, one-window-print-screen, compile, top of document, end of document, top of page, end of page, etc.

One person also suggested keystrokes that could be setup "App1" and "App2" and so on, and "Next App" and "Prev App" which move the window focus to another window, and also move the mouse so it's centered over that window simultaneously, so they don't have to move the mouse back and forth between multiple monitors and many inches of mouse movement.

A lot of good ideas from the discussions. They are all amazed I'm tackling a project like this because it's so complex.

Thank you,
Rick C. Hodgin

[Chyros]

I think we're all pretty amazed :p .

[RickCHodgin]

I've been working on the keyboard driver and making progress. I have the key processing model designed, and should have a prototype available soon to examine. I'll create an on-screen keyboard which allows you to simulate the key presses from the real device.

The general keystroke flow will go through layers:

Code: Select all

    1)  Physical keypress on device,
    2)  Routes to logical keypress on any supported virtual device, with the
    3)  Logical keypress passing through an application filter to derive macro context, and then
    4)  Expand application-specific logical keypress mapping through into keyboard macros:
        a)  Single key (such as custom key maps to F12)
        b)  Key sequence (such as custom key maps to Ctrl+Alt+Del)
        c)  Text sequence ("Update completed on $DATE() by $USER()")
        d)  Combination sequence (Ctrl+A, Ctrl+X, "Update completed on $DATE()", Enter, Ctrl+V)
        e)  Custom callback into third-party DLL to report one of the a) thru d) above (such as sampling a device or algorithm and returning input from it, such as a card reader, or image scanner for QR codes).

-----
As for the physical manufacturing aspect of the project:

I've gotten in touch with two developers at the local hardware guru place. For my prototype I'm going to switch to an Arduino board to get the interface working between the laser PCB etcher and the software as they are familiar with that design and it can be ramped up rapidly into production.

This will allow me to test out my algorithms on a well-debugged platform, and to create the physical device. And later when I get the FPGA up and running, it will be essentially a swap-out component, with all other hardware and software remaining as designed.

It's a lot of work. It's very rewarding though.

Thank you,
Rick C. Hodgin

[RickCHodgin]

I wanted to get some input on the keyboard design. My goals have been to maximize key count without sacrificing key feedback, feel, or placement. I'm looking at my current core keyboard layout, and the keys B12 and B13 (right shift area) ... I'm wondering if I should combine them into a larger right shift like the left-shift is? Or if the smaller right shift would be okay? Similarly, a key could be gained between the B1 and B2 area (left shift) by making the left shift smaller?



I'm leaning toward combining B12 and B13 into a single key, and re-numbering the other keys. What do you think?

Thank you,
Rick C. Hodgin

UPDATE: I have decided to make the right shift-key wider by default, and to provide two key positions there that can be changed by switching out the keys. The image above now reflects that.