F104+SSK+122+62+77+50+Ergo orders now open! New Kishsaver+Industrial Model F Keyboards

[NathanA]

All you need to do to enable ps/2 support is to find two unused gpio pins on the atmega32u2 chip. you can route them to a jst header on the pcb, [...]

Yes, performing the PS/2 on a different set of GPIO pins (assuming any are still available) would of course work, but the way I read the requirements was that Ellipse was hoping one could hook up to PS/2 without needing to open up the keyboard just by using a passive adapter on the host-end of the preexisting USB cable...

[gipetto]

Yes, performing the PS/2 on a different set of GPIO pins (assuming any are still available) would of course work, but the way I read the requirements was that Ellipse was hoping one could hook up to PS/2 without needing to open up the keyboard just by using a passive adapter on the host-end of the preexisting USB cable...

That would be ideal of course but this way adds an extra feature for negligible hardware cost. I suspect those who want to use ps/2 won't be swapping to usb too often due to the need to reflash. there are methods for switching for example latching relays but i do not think the complexity and demand for a control gpio pin or toggle switch is worth the bother of implementation.

[trait]

I accidentally ordered a Kishsaver instead of an Ultra Compact but didn't realize it till I opened my order up a couple weeks ago. I put the keycaps on my Kishsaver just to try it out, but haven't used it for more than a few minutes.

Emailed Ellipse, but he unfortunately doesn't do exchanges. I'm going to sell this one so I can buy the Ultra Compact model. It comes with the first aid kit (see item list below).

Is anyone here interested in this HHKB, low-serial, Beige Kishsaver? I'm selling it for the same price I bought it (including shipping), $536USD (assuming you are in Canada or the Northern US—may need to increase shipping price depending on your location).

If you want to pay through consumer PayPal, I'll have to increase the price to cover fees.

If anyone's interested, I can send you pics and/or vids to confirm its working.

You can also message me on reddit: Dasein1980 if you like.

[Jean-Loup]

Thank you so much NathanA for your very detailed reply to my questions. This reply is going to be a great resource for me when it finally comes times to get my kit assembled. I've just ordered a couple of blank coloured keycaps which I think will make the layout a little more fun. I've waited over five years, so waiting another month or two is nothing.

You provide a lot of really useful and interesting information. But there is a detail that puzzles me. You suggest that using Andrei's online QMK configurator and following the steps shown in the MechMerlin YouTube video should be straightforward and allow for the customisation of the layout of the keyboard and subsequently its flashing.

But then you suggest using VIA or Vial, adding that the benefit is that you only have to flash the keyboard once, and you can then make as many changes to the board.

A) I don't get how this is possible? I thought that the only way to make changes to layout at the keyboard level (and not the computer level) was by flashing the keyboard itself. Is there an idiot-proof explanation of why VIA/Vial only need to flash once, regardless of future layout modifications?

B) Furthermore, you state that if using VIA or Vial you, "[...] never have to flash it again (unless e.g. a firmware update comes out that fixes a bug that's annoying you)." Is there a flashing method that is more "stable", e.g., is there a firmware flasher which is more prone to bugs, for whatever reason, or---conversely---one particularly reputed for its lack of bugs? I assume that you're not talking about the VIA or Vial software bugs potentially present on the desktop app and how this might affect stability running the _app_ on a mac (or windows or linux or whatever), but of the actual stability of the code which somehow powers the flashing of the keyboard itself?

Best regards,

[Ellipse]

Someone recently found out the cause of an error with a specific key combination in QMK - I am quoting their reply below:

"There was a question on your Q&A forum (not by me) about the keyboard seemingly locking up when you press left-shift + right-shift + Esc all at the same time. I figured it out, compiling my own QMK: the default firmware you get when you compile it from the beta-QMK website configurator actually compiles with: COMMAND_ENABLE = yes in the rules.mk. To prevent these lockups, you need to define COMMAND_ENABLE = no in the rules.mk. I've created my own keymap using that, no lockups (and thus also no hidden magic keys any longer which were not explicitly in the keymap already)."

https://www.modelfkeyboards.com/questio ... shift-esc/

[sedevidi]

But then you suggest using VIA or Vial, adding that the benefit is that you only have to flash the keyboard once, and you can then make as many changes to the board.

VIA or Vial use a desktop application to configure the keyboard, then send the configuration in the keyboard's EEPROM. The keyboard then works with its QMK+VIA or Vial program stored in Flash, and the configuration stored in EEPROM. No need to re-flash the keyboard.

When using plain QMK, without VIA or Vial, the configuration is stored in the program itself: in the Flash memory. Any configuration changed implies to re-flash the whole thing.

QMK and its extensions (like VIA, Vial, tap-dance, etc.) can contain bugs, that are flashed within the keyboard, and may trigger when using some key combo or whatever. Bugs would usually result in keyboard program crash, resulting in unresponsive keyboard (return to it's bootloader) or a slight delay (rebooting the QMK program in the keyboard).

Flash application (those which write the flash inside the keyboard) MUST be 100% fail-safe, and probably are, because any error during flashing have a good chance to render the keyboard unuseable. The controller inside the keyboard have a bootloader which must never be overwritten, and I have seen no indication of bricking a keyboard while flashing. Those software are old and tested enough to be OK.

[sedevidi]

I still have a problem with the LeftCtrl key, which does not register everytime: LeftCtrl+AnotherKey is sometimes (too often) registered as just AnotherKey...
I had a problem with RightShift, which I solved by re-seating the spring (the key sometimes didn't go UP).

I'd like to see the Signal Levels with the pandrew utility many refer to above, but I can't find a Linux version of it (only Windows and Mac). Does it exist somewhere?

I use the Matrix Tester in the Vial GUI, which is nice, and shows me that the LeftCtrl registers DOWN and UP events just as cleanly and regularly as any other key. Since it's a Ctrl key, it's only useful with other keys, which may be the actual problem, that I may be able to see with a signal level monitor...

TIA!

[Sheepless]

My F77 arrived a few hours ago. Quite by chance, I had two new keyboards arrive the same day, and I admit I've spent more time with the modern Hall Effect shiny one than the classic buckling spring chonk, but I did get the F77 working. I have one troublesome key: enter was both non-responsive and binding, but a lot of fiddling (as per the manual) has helped. It's still not 100% though, so it may be chopstick time tomorrow.

The main disappointment is the solenoid, which sounds puny regardless of the throw. It looks like a lot of trial and error is needed to get it sounding worthwhile, and I'm not sure it's worth the effort for a feature I'd probably use twice a year for amusement.

[Ellipse]

Sheepless did you take a look at the solenoid setup video and instructions on the project web site, including expanding the throw of the solenoid bracket to maximize the force/sound? Also are you using the factory-provided firmware? As noted in the manual, the QMK configurator web site will produce firmware that by default results in low/no solenoid sound. If the solenoid does not sound as it does in the video then there may be a setup error or other issue.

[Sheepless]

Yep, I'm using the factory-provided firmware and I've tried both extremes of solenoid throw. I suspect the mounting didn't help: I had tried the low-effort approach of sticking the solenoid to the case using a double-sided sticky pad, but this probably cushioned the vibration too much. I need to try either screwing the solenoid to the case, or maybe using hot glue.

[Ellipse]

Not sure if you have the classic or ultra compact version of the case but each solenoid includes a mounting kit to securely mount the solenoid inside the classic cases. I would not recommend the other mounting options you describe. For a higher end mounting someone also published a deluxe 3d printed solenoid holder. https://www.modelfkeyboards.com/brand-n ... -and-more/

On a somewhat related note, has anyone installed the new production solenoid in another keyboard, like an IBM original F or beam spring keyboard? Hopefully we can see some photos of the solenoid mounting.

[sedevidi]

I still have a problem with the LeftCtrl key, which does not register everytime: LeftCtrl+AnotherKey is sometimes (too often) registered as just AnotherKey...

The problem seems to be solved after I hit the key many times vigourously, with the keyboard in the vertical position, space bar DOWN. I suspected there could have been dust or something under the flipper, which I hoped to remove by flipping it with the open side down...

I didn't find this method in the manual, though...

[sedevidi]

I now have a functionnal right block option #3 (old-style numpad), which is great, and resurface muscle memory from the last century: my fingers want to Shift+[direction key in layer 0] to type number... I added numpad number in layer 2 (Fn+[direction keys] type numbers), but I have to think in order to use it, whereas my fingers prefer Left Shift instead of Fn...

Is there a QMK way to do this: layer 0 numpad left/4 key would ouput "Left" when Shift is UP, and "4" when Shift is DOWN.

[Sheepless]

Not sure if you have the classic or ultra compact version of the case but each solenoid includes a mounting kit to securely mount the solenoid inside the classic cases. I would not recommend the other mounting options you describe. For a higher end mounting someone also published a deluxe 3d printed solenoid holder. https://www.modelfkeyboards.com/brand-n ... -and-more/

Classic case. Now that I've revisited it after some sleep, I've correctly mounted the solenoid using the mounting kit, and the sound is very satisfactory.

One thing worth noting: if you're using just the default cork bumpers, there's very little clearance between the desk and the external mounting screw for the solenoid. So I'm now using rubber feet at the back, to avoid any risk of scratching the desk.

[Shihatsu]

Elipse, did you miss my question:
viewtopic.php?p=503738#p503738

To all: Where can I find a documentation about disassembling an ultra compact F77? I want to mount some feet and want to know how to remove the bottom of the case. And yeah, I know that I have to unscrew the screws, thank you cpt. obvious

[Ellipse]

To disassemble the compact cases, I like to put the case upside down on the 2 foam packaging pieces it came with, spaced so the foam goes just up to the line of the barrels but remains flat against the case (the foam should extend out of the left and right sides of the case). Then use a T8 screwdriver to remove all the screws. Lift up the bottom case plate and then you can mount feet on that plate.

[Ellipse]

ISO Black, Dark Gray, and Industrial SSK Blue key sets, Code Keys, Big PC AT style Enter Keys?

I am looking into making a mold for the ISO Enter key (currently we are using Unicomp keys for this key as noted before, and they cannot make the additional colors for black and for gray and blue to match my project's key colors). This would allow for key sets with ISO Enter to be made in additional project colors black, 60% dark gray, and Industrial SSK Blue. I will probably make the key non-stepped just like the other keys are all non-stepped.

If you are interested please fill out the Google form below to note which sets you'd like. To help pay for the mold each set will cost $20 extra, a total of $99 instead of $79 for each set. The key could also be ordered for $20 individually.

https://docs.google.com/forms/d/1vsamkl ... kDG39r08Q/

Since I am making a mold would any other keys be worth adding that have not been made before? I don't think the big PC AT enter key or code key would have enough interest to merit $1000 extra for the mold costs but it would be lower than having a completely separate mold.

[Alexalder]

I received my keyboard today after two years.
The keycaps are very low quality and a few are broken right out of the box.
The stabilizers are missing
Once correctly installed many keys feel weird and shallow.
What's going on? Who should i write to?
Thanks

[thefarside]

Since I am making a mold would any other keys be worth adding that have not been made before? I don't think the big PC AT enter key or code key would have enough interest to merit $1000 extra for the mold costs but it would be lower than having a completely separate mold.

+1 vote for a PC AT/big ass enter key!

[skitsykitsy]

Hi everyone, been lurking for awhile and finally received the F77 repro. today. As someone who has only owned a (Unicomp) Model M in the last decade, I'm having trouble getting mine up and running, so any help would be appreciated. This is the first time I'm getting my hands dirty with a Model F. I've read the manual and consulted Ellipse's videos.

I suspect it's due to jostling in shipping, if not my own lack of competence (I was not impressed by the way the courier handled the package...) but the spring has come free of the 4 key flipper from the number row entirely.
I've had no luck reattaching the spring and I can't quite understand what I'm seeing in tutorials/guides. I can't get the dang spring to reattach to the node on the flipper. I'm trying to use a pair of tweezers -- is there a trick to it? Are chopsticks the superior tool? Does it need to be turned clockwise? I'm worried if I push and poke too much I'll drop the spring into the inner assembly or break something, but part of me wonders if I shouldn't just pop it open and reseat the spring that way...?

Also, is it normal for larger stabilized keys to feel stiff and fail to register except if pressed directly above the spring/barrel, or have I put those on wrong too?

Aside from these things, this keyboard is a thing of beauty; built like a truck, joy to type on, sings so nicely. Will be purchasing spare parts soon. Thanks for this, Ellipse! Pleasure doin' business with you.

[Ellipse]

Here's a nice and detailed Model F review from late last year - I had not come across it until today:

skitsykitsy I recommend the wiggle method described in the manual for any hard to press wider keys. The spring does have to be precisely positioned so it can be attached to the flipper nub. Maybe the spring was somehow damaged?

[NathanA]

A) I don't get how this is possible? I thought that the only way to make changes to layout at the keyboard level (and not the computer level) was by flashing the keyboard itself. Is there an idiot-proof explanation of why VIA/Vial only need to flash once, regardless of future layout modifications?

B) Furthermore, you state that if using VIA or Vial you, "[...] never have to flash it again (unless e.g. a firmware update comes out that fixes a bug that's annoying you)." Is there a flashing method that is more "stable", e.g., is there a firmware flasher which is more prone to bugs, for whatever reason, or---conversely---one particularly reputed for its lack of bugs? I assume that you're not talking about the VIA or Vial software bugs potentially present on the desktop app and how this might affect stability running the _app_ on a mac (or windows or linux or whatever), but of the actual stability of the code which somehow powers the flashing of the keyboard itself?

sedevidi covered a lot of this pretty well, but I wanted to respond because in the way that you worded your questions, it made me think that you might be laboring under the impression that the controller board in the keyboard is a fixed-function device...that is to say, the hardware that it is made of is a simple circuit that by its design is only capable of doing one thing: listening for key presses and translating them to computer input. And so in your mind perhaps it is no more sophisticated than, say, a basic handheld calculator that is only capable of elementary arithmetic. Thus, you may be thinking that there are only two pieces of software to consider which may have "bugs" in it: the desktop configuration app, and the app you run on your desktop to "flash" the keyboard.

What you're missing if you are under that impression is that there is a third piece of software to consider: the software running within the keyboard itself. We call it "firmware" for historical morphological reasons that aren't relevant at the moment, but it's just as much software as the app is that you are running on the host computer. The controller in the keyboard isn't some extraordinarily basic electrical circuit: it is itself a miniature embedded computer system, complete with its own CPU and memory!

Loading software (...firmware...) onto such embedded systems is often referred to as "flashing" it. When you "flash" your Model F keyboard, you aren't simply changing key mappings around. You are actually sending an entirely new software package to run on it that replaces whatever software is already loaded in its memory. Though the analogy breaks down at a certain point given the relative (and stark) differences in complexity between the two machines, you can think of the keyboard "firmware" like the equivalent of the macOS + the set of apps that run on your computer.

That the keyboard's controller is itself a tiny computer system that runs software is why it is so flexible and powerful...as well as why it can also be affected by software flaws or "bugs". (Of course, fixed-function hardware can also have "bugs", but we just tend to call those "design flaws", and of course they can't be fixed simply by re-writing an algorithm like you can with software...once the hardware with the flawed design ships, you're generally stuck with it, flaws and all!)

The name of the software package that runs directly on the keyboard controller is called QMK. It is very powerful and feature-ful as far as software-based keyboard controllers are concerned. But one downside to it is that the keyboard layout (the mapping of what key in what position outputs what value) is entirely "static" within the QMK software: to change it, you have to do the equivalent of re-writing some of the algorithms in that software and then copying (flashing) that new software into the keyboard controller's memory. Again, the analogy is far from perfect (what analogy isn't...), but perhaps you remember how the original iPhone couldn't have apps added to it when it first shipped? (The App Store didn't exist for the first year of its life.) The apps it had were the apps it had. To have new apps added to the phone or to change the way existing apps worked, you had to get an update to the entire iPhone OS from Apple (which, incidentally, they also used to call "firmware"). QMK (from the average user's perspective) is kinda like that.

So, yeah, if you are using plain-jane QMK, every time you want to change the keyboard layout (or anything about its functionality, really), you have to wipe the software that is on the keyboard and load on a new version of it from scratch that already contains all of the changes in it that you want, prepared in advance. VIA (and Vial), on the other hand, is a version of QMK that divorces the keyboard layout from the operating software itself: rather than embedding the layout in the actual software, it makes the key layout more like a "setting" that you can change without requiring you to do a complete software reload.

[NathanA]

Someone recently found out the cause of an error with a specific key combination in QMK - I am quoting their reply below:

<snip; summary: disable COMMAND_ENABLE>

Yes indeed, and I've been building my Vial hexes with COMMAND_ENABLE = no since the beginning for similar reasons.

The one thing to keep in mind when you run QMK with no COMMAND_ENABLE is that doing so disables the built-in LShift+RShift+B key combo to enter bootloader mode, so you can't rely on that key combo existing when explaining to people how to get into bootloader mode (though IMO this is a fine trade-off since I, too, don't like to be surprised by built-in key combos that I didn't set up myself and which cannot be changed). This also means that if you want to be able to get back into bootloader mode via a key combo that you have to be absolutely sure that you assign RESET to some key on some layer, or else the only way to get into bootloader mode is through the pandrew utility or by opening up your keyboard and shorting pads on the PCB. This is especially crucial for VIA users since the pandrew utility does not work with VIA. (Though I have patched the pandrew utility to work with Vial, and also Vial has a "Reboot to bootloader" feature built right into it, too. )

[NathanA]

I now have a functionnal right block option #3 (old-style numpad), which is great, and resurface muscle memory from the last century: my fingers want to Shift+[direction key in layer 0] to type number... [...] Is there a QMK way to do this: layer 0 numpad left/4 key would ouput "Left" when Shift is UP, and "4" when Shift is DOWN.

Now, wait just a minute: isn't this EXACTLY what you originally complained that you DIDN'T want, because you wanted to be able to do Shift+[direction key] to select text or other objects when Num Lock is off? And this is the whole reason why we came up with a way to do "pseudo" Num Lock in the first place? And now you are saying that you want to go back to that??

This would basically require that Shift act as MO(x) when used in combination with key pad keys, but act as true Shift when used in combination with other keys. I am not aware of a way to do this with QMK. (Of course, that doesn't mean that there is no way...)

If you actually DO want the numpad to work this way, since we established that your Linux distribution already does this with standard numpad keys, it seems to me that the easiest way to achieve this is just to go back and re-implement the number pad with actual Num Lock and the normal numpad key mappings, instead of pseudo-NumLock method using layers. With actual Num Lock, no layers are required and problem "solved"!

EDIT: I suppose one hacky way you could accomplish this is by making both Shift keys into MO(x) keys instead of actual Shift, and then doing "pseudo-Shift": add ALL the other keys to all of the other key positions on all layers (instead of leaving them as KC_TRANS), but on the upper layer, apply a LSFT modifier to them all! But that seems like a lot of work for dubious benefit if natural Num Lock already does exactly what you want it to do.

I'd like to see the Signal Levels with the pandrew utility many refer to above, but I can't find a Linux version of it (only Windows and Mac). Does it exist somewhere?

I'm not aware of anyone that has built and distributed binaries for Linux (given the utility has dependencies on things like Qt, it can be non-trivial to build a statically-linked version of it that works on all Linux distributions). But of course the source code for it exists, and there are Linux build instructions included by pandrew in the README. If you can tell me which precise distribution of Linux (and version of that distribution), I can likely build you a copy (though no guarantees on how quickly I can get around to it). Or can direct you to where to get the source and then you can build it yourself.

Nota to everyone: using Vial is a real joy, as it allows to really modify the keyboard settings in real time. Just a change a key, and use it. Save the config in a file if need be, but Vial will read the whole settings from the keyboard upon startup.

This is what I keep trying to tell people. To be fair, VIA also gives you the same freedom. But the Vial implementation is (in my opinion) way better and also has a lot more features than VIA does. I can't think of anything that you lose by switching to Vial from VIA, and there are tons of benefits you gain...

[NathanA]

Also, is it normal for larger stabilized keys to feel stiff and fail to register except if pressed directly above the spring/barrel, or have I put those on wrong too?

Absolutely not normal. Should be smooth as butta. Otherwise what's the point of the stabilizers.

Are you sure you used the correct stabilizers for those keys? There are different ones for the horizontally-long keys (Enter, Shift, 2U Backspace) than there are for vertically-long keys (numpad +, numpad Enter). The stabilizers for the horizontally-long keys are white & the hole looks centered; the ones for the vertically-long keys are black & the hole looks offset. They are not interchangeable with each other. EDIT: now that I think about it I'm not even sure you'd be successful fitting the wrong key on the wrong stabilizer, so I'm guessing this isn't your problem.

[jafd]

Got my Kishaver today (finally!). So far so good, only two things I'm seeing:

1) Enter gets stuck if a stabilizer is used (yes, used the right kind)

2) This thing would really shine if it had feet!

[skitsykitsy]

Also, is it normal for larger stabilized keys to feel stiff and fail to register except if pressed directly above the spring/barrel, or have I put those on wrong too?

Absolutely not normal. Should be smooth as butta. Otherwise what's the point of the stabilizers.

Are you sure you used the correct stabilizers for those keys? There are different ones for the horizontally-long keys (Enter, Shift, 2U Backspace) than there are for vertically-long keys (numpad +, numpad Enter). The stabilizers for the horizontally-long keys are white & the hole looks centered; the ones for the vertically-long keys are black & the hole looks offset. They are not interchangeable with each other. EDIT: now that I think about it I'm not even sure you'd be successful fitting the wrong key on the wrong stabilizer, so I'm guessing this isn't your problem.

Yeah, I'm using the white stabs -- after trying to write a blog with the keyboard in this way, I have to admit it's not as tolerable as I thought it was. It's taking 7+ attempts to ctrl-c/ctrl-v and backspace isn't working too well either.

I followed the instructions of ensuring the "ears" were to the side, but the instructions don't specify which way up the stabilizer bars are supposed to go? I may have put them in upside down, but I picked the orientation I did because I thought the stabs would fall straight through otherwise. I may have done a dumb-thing...?

Actually, come to think of it, there are no stabs for the control keys, and the Enter key is perfect despite being a long, stabilized key. I'm at a loss.

[NathanA]

I followed the instructions of ensuring the "ears" were to the side, but the instructions don't specify which way up the stabilizer bars are supposed to go? I may have put them in upside down, but I picked the orientation I did because I thought the stabs would fall straight through. I may have done a dumb-thing...?

The top of the stabilizer is the side that is visible in the picture of the stabs from the ordering page: https://www.modelfkeyboards.com/product ... keys-each/

[skitsykitsy]

I followed the instructions of ensuring the "ears" were to the side, but the instructions don't specify which way up the stabilizer bars are supposed to go? I may have put them in upside down, but I picked the orientation I did because I thought the stabs would fall straight through. I may have done a dumb-thing...?

The top of the stabilizer is the side that is visible in the picture of the stabs from the ordering page: https://www.modelfkeyboards.com/product ... keys-each/

Aha, yeah, then I have them in the correct orientation. And as I mentioned above, the enter key is wonderfully smooth but backspace (and the non-stabbed ctrl keys) are nightmares.

[NathanA]

Aha, yeah, then I have them in the correct orientation. And as I mentioned above, the enter key is wonderfully smooth but backspace (and the non-stabbed ctrl keys) are nightmares.

Right, if your Ctrl is acting up that's got nothing to do with stabs. Do any other 1.5U keys (like Alt or Tab or Backslash) work fine? If so can you try swapping Ctrl with one of them and see if the problem follows that position on the keyboard, or the key itself? (Also try putting the working 1.5U key in the Ctrl barrel and see if it has problems when relocated there?)

Assuming that you are using 2U Backspace, maybe try taking the key off and then putting any 1U key in the barrel with the spring+flipper for Backspace & see if that moves freely (basically, is problem possibly with the barrel, not the stab or the keycap)?
Likewise, do you have any Model Ms kicking around that you can borrow a Backspace from to test on your keyboard?

Also as far as Backspace goes I assume you sourced all of your stabs from Ellipse and not from e.g. Unicomp. One thing I was going to post about but hadn't yet gotten around to is that it's come to my attention that Unicomp stab hole diameter is ever-so-slightly smaller than Model F ones, and the pegs on the stabilized Model F keys ever-so-slightly larger in diameter than the same Unicomp keys, and an Ellipse key will *absolutely* get stuck down if you mount it within a Unicomp stab and then press it.