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

[Obin]

The Keyboard Oracle has decided: thy problem is not electrical or software, yet mechanical 'i nature. The path to the wholeness may be found by reseating the keycap or by replacing the spring.

I feel like these boards should come with a bunch of springs (don't need to be with flippers) free of charge so you can replace the defects that inevitably seem to crop up.

I already had to replace four springs on my F77 and yes, I tried to reseat the keycaps, pinch the keycaps, reseat the springs in the correct orientation, and when I switch them with other springs, the defects move with the springs so it's clearly the springs and I'm not just "holding it wrong". Thankfully I had bought the first aid kit so at least I had some springs to replace them with, but you shouldn't need to buy an additional first-aid-kit to resuscitate your dead on arrival product.

It's also notable that all of these springs except one worked at first and then failed after only a few months of use. I really hope that it's just material defects and QC issues and not general wear that would make all of the springs fail one by one. Hopefully at some point I've caught all the defective ones and the board will just work.

If this was an EU product I could demand the springs or send it back and make Ellipse replace the springs for me. Only in the US it's well, you can buy this additional product to fix the original product that never worked right, or in this case look through my convoluted stream-of-consciousnes "manual" where you can do a bunch of stuff before it tells you to buy this additional product....

[Muirium]

^ True! It's stuff like this, and yes the high price of entry, that's kept me out of ordering any brothers for my OG Kishsaver. The original's been a low-maintenance joy since before this project even started. IBM was IBM, of course. Model F Labs isn't, so spares in the box become a necessary concession to imperfection.

I don't recall seeing such a mod before - is this common with left-handed number pad keyboards?

Not super common, but it's not unheard of.

Hi all! Owner of the pictured F50 here. It is indeed not a very common layout, which is surprising to me, and my case for it is entirely based in ergonomics. According to ergonomic principles, most full-size and TKL keyboards are actually designed (though not intentionally) to work best for left-handed people. This is because the navigation cluster and the numpad were developed before mice and other pointing devices became commonplace. Back in the day, those were the "pointing" devices, but as point-and-click GUIs became more commonplace and mouse use became the norm, for some reason keyboard designs did not adapt to the new paradigm.

I am a right-handed software developer, and I spend the majority of my time behind a computer typing on the keyboard. To be efficient and ergonomic for typing, the keyboard should be horizontally centered such that the space between the middle-most home row keys (G and H in the QWERTY layout) is aligned with the center of the user. To do this with a full-size keyboard for a person who uses the mouse with the right hand would mean positioning the mouse so far away from the typical typing position that it requires awkward (un-ergonomic) movements to reach it, and even more awkward ones to move it. If you use a mouse with the left hand, however, this setup is perfect, because it allows you to position the mouse within easy reach and to move it without awkward shoulder rotations. I tried to teach myself how to use the mouse with the left hand for this reason, but it never felt natural to me, and I decided to adapt the keyboard setup instead.



Having the numpad and arrow cluster on the left is very comfortable once I got over the slight learning curve. I've seen some keyboards that just relocate the numpad as-is to the left, but this is not ideal, because the Plus and Enter keys on this layout were designed to be easily accessed with the pinky finger, and sometimes it is easier to use the thumb instead of a finger for the Zero key. Reversing the numbers themselves, on the other hand, does more harm than good, since many of us have a pretty good intuitive understanding of how a keypad should look and feel, and that numbers should increase from left to right. Plus, swapping the 6 and 4 keys makes a lot of hard-coded navigation awkward. The rest is pretty straightforward: Minus above Plus; Divide above 8, as in normal numpads. Num Lock is in the furthest place because of how infrequently it is used relative to the other keys. In my completely biased opinion, this should have been the standard full-size layout since the early '90s.

Anyway, here is the complete setup. And, yes, I did run out of matching keys to use for the F cluster. I plan to replace the lower three with relegendables in the future. For now they are mapped as Ctrl, Alt/Option, and Command/OS. The key to the left of the Up arrow is Left Shift, and the key to the right activates the second layer when held, which I have not completely mapped yet.

I hear you. As a 60%er myself, whenever I use a full-size keyboard I’m struck by just how much of it juts out at the right. I've never been a fan of all that forced asymmetry. This was something I noticed before I discovered the keyboard scene, as I remember my joy at my 12" PowerBook's symmetry, and picking up a compact Apple desktop keyboard when they shipped one without the numpad. Something about smaller formats really spoke to me, before I was aware of any of the terms.

Where we diverge is in the need to add dedicated keys back to 60%. Every one of those cursor keys, function keys, even the /*-+Enter on the numpad are present on the HHKB function layer by default. That's exactly where I use them. And, for me, it's the ideal place to keep them tucked away and out of my way! Symmetry remains, and I can type just as comfortably with the keyboard on my lap.

Well, alright, just as comfortably with the HHKB on my lap. The Kishsaver's a bit brutal for long sessions there! But 60% is ideally suited to moving around as a single unit, including my own laid-back take on ergonomic typing.

If I lived on the numpad and function row, though, I'd likely do something quite like you have done. Truth is though I don't, and I really don't want to expand my collection with a new quest: matching numpads for all of my compact keyboards!

[Ellipse]

taraskremen this is a great post! It makes sense to keep the mouse and num pad block as you have described. However some old timers with decades of keyboard usage like myself might have too much muscle memory to change the num pad location!

On the subject of relegendables, I have not seen too many photos of custom-printed relegendable keys in use on the Model F keyboards - everyone please do share some photos and descriptions of these keys! Are they primarily for application-specific options or more for flexibility to change up the keys every now and then without ordering preprinted keys?

Obin these keyboards are covered under a limited warranty but many folks want extra parts for repairs long into future years to keep these keyboards running. It is unusual for springs to fail after a few months of usage. I don't recall such instances being reported frequently. By failing did they not actuate the key or was the key feel not up to the rest of the keys?

Thousands of folks have these keyboards, many of whom do not have the first aid kit and have not reported issues of failed keys after several months as you have reported.

Did you follow the latest version of the manual or are these issues from previous years? The manual was thoroughly updated recently to improve organization, and a step by step video guide was also created (it is on the project web site manual page). There is a specific guide to fixing springs as well.

If someone is fixing springs in ways not shown in the video then they may have damaged the springs while attempting to repair them. For example if one pulls the springs instead of twisting counterclockwise to remove them as indicated in the new manual then the springs will be damaged beyond repair. Installing a key without the spring properly positioned can cause the key to squish the spring and cause the spring to have a permanent bend which makes the spring unusable (has happened to me!). For a key to work well, the spring usually has to be pushed down a lot with the tweezers without bending the spring, as shown in the above-mentioned video. Also the keys should be installed with the keyboard held vertically, space bar end up, and it may take a few tries to properly install the spring to the flipper. Sometimes when I install a spring and hold the keyboard vertically, the spring does not rest close to the 12 o'clock position of the barrel and I have to remove and reinstall the spring or it will seem like the spring is at fault. If a reinstalled spring is too far away from this edge of the barrel, the key will not actuate properly and it may actuate weakly or intermittently in my own experience.

[genericusername57]

You can always have a friend order a keyboard and you can order a first aid kit to ship with it at no extra cost if funds are tight.

I'm sure you realise how it would be hard for me to convince someone I know to get a several hundred euro keyboard to make it a bit cheaper for me to buy spare parts for said keyboard because mine isn't working correctly

If you'd sell spare springs in bulk for a reasonable price it would be a bit easier to motivate but I'm sure you can appreciate how $1 for a spring can be seen as excessive. $10-20 for a pack of 100 is more in line with what springs for MX switches cost.

[Ellipse]

genericusername57 since you bought the keyboard secondhand I can't say what happened to the keyboard but I have seen a number of reports from folks buying secondhand and it had some undisclosed issues. Springs can easily be damaged during installation or key removal or through improper repair attempts not following the setup/maintenance video without even realizing it in some cases.

Often times it is difficult to see why a spring does not work well until after I remove the spring and see that it is slightly bent, or maybe there is some liquid residue from a spilled drink underneath the flipper (even water would cause issues if it is below the flipper).

You can definitely recommend a Model F to friends and family members even though it requires maintenance to keep it running, hopefully for many more years. Paying for the parts alone as part of the first aid repair kit or separately is far less costly than paying a repair shop for parts and labor or discarding the product entirely when one part breaks. These keyboards are fully repairable and can be fully disassembled with just screwdrivers and pliers, unlike many other keyboards. The main philosophy of the project is to encourage users to learn how to take control of the repairs and maintenance of their keyboards, one benefit of which is to allow the keyboards to be priced as low as possible and to avoid the need for repair and phone staff.

The pricing is quite reasonable for all extras and has even gone down for some extras like the keys and key sets. Everyone gets the fully discounted price for all items regardless of quantity ordered, except for the transparent relegendable keys which have quantity discounts. Some folks may not fully realize that the price of any custom-made item is not based on the material cost or the variable production cost - one needs to allocate the overhead costs. Comparing it to a mass produced item like an MX style switch which is probably made in the tens (or hundreds?) of millions each year misses the important detail that this project does not have the economies of scale of such an item. With a small-scale project like this one you are also paying more to allocate all of the additional project costs on a (lower quantity) per-unit basis: quality control and assembly costs, tooling and mold costs, express/air mail shipping costs, sample/prototype costs, project cost overruns, other fixed costs, and so forth.

[taraskremen]

Where we diverge is in the need to add dedicated keys back to 60%. Every one of those cursor keys, function keys, even the /*-+Enter on the numpad are present on the HHKB function layer by default. That's exactly where I use them. And, for me, it's the ideal place to keep them tucked away and out of my way! Symmetry remains, and I can type just as comfortably with the keyboard on my lap.

Well, alright, just as comfortably with the HHKB on my lap. The Kishsaver's a bit brutal for long sessions there! But 60% is ideally suited to moving around as a single unit, including my own laid-back take on ergonomic typing.

If I lived on the numpad and function row, though, I'd likely do something quite like you have done. Truth is though I don't, and I really don't want to expand my collection with a new quest: matching numpads for all of my compact keyboards!

I am also a huge fan of compact keyboards and love the HHKB layout. I went the split ergo route for a while and still use the Redox from time to time, and when I'm not using the F62 or HHKB, my go-to is the Preonic. While it is nice to have that minimalist form factor and have access to the numpad and navigation keys from multiple layers, sometimes I just want to be able to one-handedly scroll something with an arrow key or use Home or End to navigate something I am reading without doing finger yoga or trying to remember to what exactly I mapped a key I almost never use on layer 9. From time to time I also have to deal with computational spreadsheets, and the numpad is pretty essential for efficiency there. I wouldn't say I really need it 90% of the time, but for that other 10% having it there makes life so much easier. The F50 is a bit overkill for what I was looking for, but it seemed to be the only way to get an external numpad with buckling spring switches to match the F62.

[Muirium]

Yeah, I hear you. If I worked numbers for a living, I’d have a numpad, too. Or maybe twenty. Gotta match ‘em all!

I’ve certainly been through the cycle with my 60% boards: adding layers and layers within layers, only to inevitably forget vital keys. Nowadays my HHKB (and Kishsaver, etc…) has one function layer and one function key, very much like it was designed. I moved my extended stuff to the host with Karabiner and started using the same set of mods across all my keyboards, including the laptop’s built-in. That did the trick. Muscle memory is king. Learn by doing. Often!

[Ordinary Witch]

I went from full-size keyboards to a TKL board and then right back to full-size, before I started binging chyrosran22's videos and finding out that massive keyboards tickle my brain. When the F122 is done and I get mine, I'll even have function layers to play with.

the biggest reason I like >100% keyboards is specifically because I don't need so many modifiers. Would rather have the most common functionality accessible at an instant, and sometimes that instant functionality doesn't exist even on full-size keyboards. Other times I just want extra keys to assign to random OS functionality or for games so that there's no chance for key conflicts.

There's also just something satisfying about a big, loud, blocky board that takes up significant space on the desk. most keyboard youtubers these days push the ultra-samey "60% thock" stuff a bit too much (cough hipyo tech cough)

[AlpsComeback]

I've been wanting to use my F77 lately, but I've noticed that the QMK support still hasn't been merged into the official QMK github repo. Does anyone know why it's taking so long and when it will be in the official repo?

[NathanA]

I've been wanting to use my F77 lately, but I've noticed that the QMK support still hasn't been merged into the official QMK github repo. Does anyone know why it's taking so long and when it will be in the official repo?

*sigh*

Like any software project -- open source or not -- the project owner / maintainer has certain standards to uphold. This includes things like the way your code is factored, how it interfaces with existing modules / calls into existing code, whether memory allocation/efficiency/safety+security standards are being upheld, even down to code formatting being consistent with what's already in the repo, etc.

They aren't simply going to accept outside contributions blindly, lest average code quality in the project slowly erode over time. No open source project worth its salt would. It's also not their job, nor responsibility, to clean up your code for you. So if somebody wants their code to be accepted badly enough, they need to take whatever feedback they get from the maintainers, and try to bring that code up to the project's standards first.

Projects like this are also something of a moving target, so the longer you wait to make your code conform to their requirements, the more likely it is that something will have changed in the meantime. If you submit a contribution & get some feedback about things that must be changed before it is accepted, and then you only get around to it, say, six months later, core parts of the project that your contribution heavily depends on may now be different...existing functions/APIs may have been deprecated and new ones added in their place, etc. So now you have to basically "port" your contribution to the latest version, on top of everything else. And once you have finished with that and re-submit, you'll more than likely receive even more feedback about things in your code that need to be changed, etc.

It's been well-established that the original author of the code for the xwhatsit/capsense support in QMK has not had the time to dedicate to this. There have been other volunteers who have said they've taken up the gauntlet, but it's not clear to me what the current status of those efforts is.

On top of that, there is some debate about whether the goal of using a more current version of QMK on these keyboards is juice that's even worth the squeeze, given the limitations of the ATmega micro platform that the controller board is using at its core. The QMK codebase has only been getting larger (some might even say more bloated?) over time. Some of the newer features are nice, to be sure, but it's seemingly not possible (at least without a LOT of creative re-optimization) to get all of them to simultaneously fit within the tiny ATmega's memory space. This either results in instability, or in the worst case, a firmware file that's too large to even fit into flash to begin with.

All that said...how is the lack of support from the official QMK repo somehow "preventing" you from using your keyboard? My F77 somehow works just fine in spite of this; after all, I'm typing this response on it. Sarcasm aside, is there a particular newer QMK feature that you are hoping to use that the capsense fork doesn't have?

[AlpsComeback]

I've been wanting to use my F77 lately, but I've noticed that the QMK support still hasn't been merged into the official QMK github repo. Does anyone know why it's taking so long and when it will be in the official repo?

*sigh*

Like any software project -- open source or not -- the project owner / maintainer has certain standards to uphold. This includes things like the way your code is factored, how it interfaces with existing modules / calls into existing code, whether memory allocation/efficiency/safety+security standards are being upheld, even down to code formatting being consistent with what's already in the repo, etc.

They aren't simply going to accept outside contributions blindly, lest average code quality in the project slowly erode over time. No open source project worth its salt would. It's also not their job, nor responsibility, to clean up your code for you. So if somebody wants their code to be accepted badly enough, they need to take whatever feedback they get from the maintainers, and try to bring that code up to the project's standards first.

Projects like this are also something of a moving target, so the longer you wait to make your code conform to their requirements, the more likely it is that something will have changed in the meantime. If you submit a contribution & get some feedback about things that must be changed before it is accepted, and then you only get around to it, say, six months later, core parts of the project that your contribution heavily depends on may now be different...existing functions/APIs may have been deprecated and new ones added in their place, etc. So now you have to basically "port" your contribution to the latest version, on top of everything else. And once you have finished with that and re-submit, you'll more than likely receive even more feedback about things in your code that need to be changed, etc.

It's been well-established that the original author of the code for the xwhatsit/capsense support in QMK has not had the time to dedicate to this. There have been other volunteers who have said they've taken up the gauntlet, but it's not clear to me what the current status of those efforts is.

On top of that, there is some debate about whether the goal of using a more current version of QMK on these keyboards is juice that's even worth the squeeze, given the limitations of the ATmega micro platform that the controller board is using at its core. The QMK codebase has only been getting larger (some might even say more bloated?) over time. Some of the newer features are nice, to be sure, but it's seemingly not possible (at least without a LOT of creative re-optimization) to get all of them to simultaneously fit within the tiny ATmega's memory space. This either results in instability, or in the worst case, a firmware file that's too large to even fit into flash to begin with.

All that said...how is the lack of support from the official QMK repo somehow "preventing" you from using your keyboard? My F77 somehow works just fine in spite of this; after all, I'm typing this response on it. Sarcasm aside, is there a particular newer QMK feature that you are hoping to use that the capsense fork doesn't have?

Thanks for the thorough response. I understand that there are a lot of moving parts to a project like QMK. I've had my F77 for three years now though, and was hoping the official QMK repo would have support for it by now. It also makes it more difficult to use one QMK branch for my F77 and the main QMK branch for my other supported keyboards. That note about literal space limitations within the ATmega chips was something I wasn't aware of, so that's good to know.

I was able to get the fork with F77 support working a long while ago, but upon trying it again recently, something kept going wrong. The instructions I was looking at may have been out of date. I can give it another shot going off the instructions linked on modelfkeyboards.com, but it feels somewhat piecemeal with different parts of it on different websites.

Is this Google doc from modelfkeyboards.com the most up-to-date set of instructions available?

[NathanA]

It also makes it more difficult to use one QMK branch for my F77 and the main QMK branch for my other supported keyboards.

Ah, okay...if you have a bunch of different QMK-powered keyboards & you're trying to maintain a common code base and feature-set amongst all of them, then that makes sense.

That note about literal space limitations within the ATmega chips was something I wasn't aware of, so that's good to know.

There are of course many ATmega-powered keyboards out there that QMK supports, with traditional (non-capsense) matrices. The capsense support code itself is not obese by any means, but it does add not-insignificant additional heft to the code size. So the capsense boards that also use ATmega are already at a disadvantage, resources-wise. Add to this that the Xwhatsit controller design was based off of the ATmega32U2, which has fewer USB endpoints and 40% of the SRAM (1K vs. 2.5K) when compared to the more widely used (though slightly more expensive) ATmega32U4. This leads to some tight runtime space and fewer possible simultaneous features (e.g., things like ExtraKeys / MouseKeys / Command keys / debug console / etc.). Since the 32U4 is not pin-compatible with the 32U2, most of the Xwhatsit redesigns have favored keeping the 32U2 for the sake of simplicity rather than taking the opportunity to re-design around a beefier micro. So now we are kind of stuck with it, at least for the keyboards already built and sold so far.

When building Vial-enabled firmwares, I ran into the SRAM constraints early on: basing off of the Vial 0.4-era codebase proved to be no problem, but when I tried to update to newer Vial build trees, I would experience crashes and instability, likely due to lack of available SRAM / stack overflow. The only way to work around it without really diving deep into the code and rewriting a bunch of stuff is to start disabling features in the build...features that were already working just fine in previous versions on the same keyboard controller. It got even worse with more recent code, where now building with the same feature-sets as before results in a firmware binary that is too big to even fit into flash.

The resource constraints issue doesn't seem to merely be limited to trying to build with VIA/Vial support (which admitted add a hefty amount of code all on their own to the build!), as there are reports of people trying to take the capsense code, merging it with current QMK master, building & flashing, and running into instability that also smacks of stack overflow in scenarios where this previously was not an issue.

The glimmer of hope on the horizon is that Rico from this community has been diligently working on a new capsense controller design based around the Raspberry Pi RP2040 micro, which is *significantly* more powerful than the aging ATmega line, and an amazing price to boot. Resource-wise, it eats current QMK+Vial for breakfast. The unfortunate part is that you'll have to completely swap out your controller on your keyboard if you want to take advantage of this when the time comes, of course. So get prepared to break out your soldering iron...(ugh)

I was able to get the fork with F77 support working a long while ago, but upon trying it again recently, something kept going wrong. The instructions I was looking at may have been out of date. I can give it another shot going off the instructions linked on modelfkeyboards.com, but it feels somewhat piecemeal with different parts of it on different websites.

Is this Google doc from modelfkeyboards.com the most up-to-date set of instructions available?

If all you want is just basic QMK, then yeah, basically just clone the purdea.ro git repo and build straight from that. Really should work out of the box, and there's nothing piecemeal about it.

I'd guess that the "piecemeal" vibe you were getting probably largely came from other people (perhaps such as myself, heh) coming up with their own "remixes" of QMK firmwares and sharing them with the public. If you wanted to build something with Vial support, for example, you'd have to clone from the Vial repo, likely roll back to an earlier commit that will work stably on the Xwhatsit and fit within the resource constraints of its microcontroller, pull the capsense files from the purdea.ro repo and merge them with the Vial tree, and then build.

When I do releases of these, I include a basic shell build script that shows exactly what sources I'm pulling from and how all of the parts fit together. So if you want to do something more sophisticated than simply build from the capsense QMK fork, you could take a look at my build script for some inspiration, I suppose.

My most recent public release is posted here. Though I'm gearing up to do another release, likely in a matter of days (once I hear back from Ellipse that the new boards I added support for all seem to work fine with it).

[Arkku]

The QMK codebase has only been getting larger (some might even say more bloated?) over time. Some of the newer features are nice, to be sure, but it's seemingly not possible (at least without a LOT of creative re-optimization) to get all of them to simultaneously fit within the tiny ATmega's memory space. This either results in instability, or in the worst case, a firmware file that's too large to even fit into flash to begin with.

Indeed, and this is one reason why I made my own firmware… QMK has a lot of stuff implemented by the community, which is both its strength and weakness. These simple microcontrollers also don't have any memory protections, so if you exceed the amount of RAM it will just overwrite other stuff and cause random issues, and likewise if you run out of EEPROM (or the specific features you enabled don't play well together) the settings may overwrite one another.

The capsense calibration of these keyboards requires more code and more RAM than "normal" keyboards, so it complicates things further. In fact I'm positively surprised that you were able to fit the Vial stuff at all!

Anyway, my point is, let's cut some slack to people working on the QMK firmware, it's not as easy with these constraints as one might think. =)

[sedevidi]

'k. Here's my implementation of having the (host) Num Lock status act as a selector (Fn key) for Layer 1.

I finally installed your latest firmware version... I had to tweak your .sh script to suit Debian's very old dfu-programmer 0.6.1. See my changes in the attached file (many variables to enable tweaks, don't redirect everything to /dev/null, etc.)
I still have to re-apply my keymap, because yours does not fit my habits. I'm trying, I swear!
Old Vial software 0.5.2 still works with this version.
Many thanks for your efforts!
What triggered the upgrade for me was too many swapped keys while typing (may be the old matrix scanning), some bugs (sometimes the Shift+Key mapping misses the "shift" part), and the H key which could benefit from better binning.

[Fond Lion]

Ellipse, could you please answer the following questions about the keycaps?

• What's the difference between "US Printed (Pearl/Pebble)" and "Extra Bold Legends US ANSI (Pearl/Pebble)" keycaps? Do both use Zed's XT reproduction font?
• Regarding keyboards with split backspace and split right shift:
  • Is a 1u blank pearl keycap included for the additional key?
  • Is it possible to get a 1.5u "Backspace" keycap instead of the 1.5u "Delete" keycap?
  • When combined with the IBM SSK keyset, are blank keycaps or XT reproduction keycaps included for the missing keycaps?
• Are text-only "Tab", "Caps Lock", "Shift" and "Enter" keycaps available in default sizes? (According to the product pictures, text-only keycaps for those keys seem to be available in 1.5u size only.)

Thanks in advance!

[hammelgammler]

Hi all! Owner of the pictured F50 here. It is indeed not a very common layout, which is surprising to me, and my case for it is entirely based in ergonomics. According to ergonomic principles, most full-size and TKL keyboards are actually designed (though not intentionally) to work best for left-handed people. This is because the navigation cluster and the numpad were developed before mice and other pointing devices became commonplace. Back in the day, those were the "pointing" devices, but as point-and-click GUIs became more commonplace and mouse use became the norm, for some reason keyboard designs did not adapt to the new paradigm.

I am a right-handed software developer, and I spend the majority of my time behind a computer typing on the keyboard. To be efficient and ergonomic for typing, the keyboard should be horizontally centered such that the space between the middle-most home row keys (G and H in the QWERTY layout) is aligned with the center of the user. To do this with a full-size keyboard for a person who uses the mouse with the right hand would mean positioning the mouse so far away from the typical typing position that it requires awkward (un-ergonomic) movements to reach it, and even more awkward ones to move it. If you use a mouse with the left hand, however, this setup is perfect, because it allows you to position the mouse within easy reach and to move it without awkward shoulder rotations. I tried to teach myself how to use the mouse with the left hand for this reason, but it never felt natural to me, and I decided to adapt the keyboard setup instead.

modelf-compact-f104.jpg

Having the numpad and arrow cluster on the left is very comfortable once I got over the slight learning curve. I've seen some keyboards that just relocate the numpad as-is to the left, but this is not ideal, because the Plus and Enter keys on this layout were designed to be easily accessed with the pinky finger, and sometimes it is easier to use the thumb instead of a finger for the Zero key. Reversing the numbers themselves, on the other hand, does more harm than good, since many of us have a pretty good intuitive understanding of how a keypad should look and feel, and that numbers should increase from left to right. Plus, swapping the 6 and 4 keys makes a lot of hard-coded navigation awkward. The rest is pretty straightforward: Minus above Plus; Divide above 8, as in normal numpads. Num Lock is in the furthest place because of how infrequently it is used relative to the other keys. In my completely biased opinion, this should have been the standard full-size layout since the early '90s.

Anyway, here is the complete setup. And, yes, I did run out of matching keys to use for the F cluster. I plan to replace the lower three with relegendables in the future. For now they are mapped as Ctrl, Alt/Option, and Command/OS. The key to the left of the Up arrow is Left Shift, and the key to the right activates the second layer when held, which I have not completely mapped yet.

modelf-f62-and-f50-on-desk.jpeg

I find it interesting how ergonomics is different for different people, but from a similar perspective than you and Muirium I bought myself the F15, as that’s similar in width than a 60%, with dedicated arrow keys (or HHKB fn key), F keys and even arrow keys for left hand usage. All packaged where you can in addition angle the keyboard more naturally.

The F15 for me is, at least if you don’t want to go ortholinear, nearly the perfect ergonomic layout with no real downside, it’s still really easy to adapt to a laptop keyboard, which most often then not have the arrow keys on the same position. Only drawback I see is if you use Home/Delete very often, which is also positioned similar on most laptops.

Also when gaming, most games are fine to play only with the left half, which makes even more room for the mouse.

I also really thought about buying the Ergodox style as well (which was a bit too expensive for me in the end), but you could argue that if you go ortholinear then you might as well go curved as well, like the Glove80. The lower switch/keycap height makes it a bit more comfortable as well, even if there was a Model F Glove80.

[taraskremen]

I find it interesting how ergonomics is different for different people, but from a similar perspective than you and Muirium I bought myself the F15, as that’s similar in width than a 60%, with dedicated arrow keys (or HHKB fn key), F keys and even arrow keys for left hand usage. All packaged where you can in addition angle the keyboard more naturally.

The F15 for me is, at least if you don’t want to go ortholinear, nearly the perfect ergonomic layout with no real downside, it’s still really easy to adapt to a laptop keyboard, which most often then not have the arrow keys on the same position. Only drawback I see is if you use Home/Delete very often, which is also positioned similar on most laptops.

Also when gaming, most games are fine to play only with the left half, which makes even more room for the mouse.

I also really thought about buying the Ergodox style as well (which was a bit too expensive for me in the end), but you could argue that if you go ortholinear then you might as well go curved as well, like the Glove80. The lower switch/keycap height makes it a bit more comfortable as well, even if there was a Model F Glove80.

The F15 piqued my interest too, and if I didn't already have a "base" model F board that I spent months customizing to my liking, I would have bought one. I actually prefer the ortholinear layout over more traditional row-staggered layouts, but very hesitant about the Ergodox one because of a terrible experience with the Ergodox EZ a few years ago that put me in months of physical therapy for DeQuervain's. Ever since then I shunned anything that emphasizes thumb usage. A Redox board with my own modifications (removing some of the thumb cluster and replacing with a 4u-ish space bar) was my solution for a long time until I discovered buckling spring and Topre switches and realized that I prefer both over MX. Now the F62 is my workhorse at home and a silent HHKB for those times when I need to consider the auditory senses of others. A Preonic-like board with buckling spring switches would be very interesting to see.

The Glove80 reminds me of the Kinesis Advantage, with which I had the same issues as with the Ergodox EZ. Over the past few years I managed to stave off the DeQuervain's by varying the height of the palm/wrist rest throughout the day/week, per the physical therapist's recommendation, so any board that forces my hand into the same shape/position looks like a bad idea to me. As you said, ergonomics means different things to different people. RSI can be aggravated or lessened by the smallest changes in positioning or technique, but the idea is always the same: avoid making the same motions over and over. Having two different setups to rotate through helps too.

[Ellipse]

Final sale on the out of production keyboards (F62 / F77 / Round 1 F104 FSSK B104 and BSSK)

Currently the keyboards are discounted about 50% or more and some now sell for less than $200. If you have been holding off joining the project due to lack of funds or because these boards were not affordable now is the time to get a new Model F or beam spring! A lot of folks who have a new Model F are picking up a spare to use at another computer or to keep for future usage.

After 8 years (doesn't time fly! Does 2015 seem a long time ago to everyone here?) these earlier projects are finally winding down. Now is the last chance to get these keyboards. Currently all variations are in stock and expected to ship within 1-4 weeks as I move through the backlog.

Once most of the stock sells out over the coming months, pricing is expected to go back up for those who want any of the final remaining boards. So far more than 4,600 Brand New Model F and Beam Spring keyboards have shipped, with many more in the queue as we wait for the factory to wrap up production.

I also have a number of factory soldered controllers+ribbon cables+capacitive PCBs for the F62 and F77 models. If you are looking to upgrade your keyboard to have the latest USB-C controller or if you want to pick up a drop-in spare replacement please feel free to order the controller plus 30 units of the store item $1 increments which includes the PCB and factory labor costs.

Fond Lion kindly see my replies below:

Yes, both made by Zed. The font of the very first batch of production keys ended up being bolder than the originals (we weren't sure of the extent of the dye migration/bleed of the sublimation ink) so Zed adjusted the thickness. I still have some extra bold legend key sets available in the shop if you prefer the biggest legends or want one of the first few dozen Model F XT quality keysets produced.

Yes each full key set includes 2 pebble blank and 2 pearl blank. The blue sets have 4 blue blank and the gray sets have 4 gray blank.

Yes the Backspace key and many other keys can be ordered through the Extra Keys page.

You get printed right side block keys with the IBM SSK set or blank keys depending on what was included (you can't pick). I have about 5 IBM SSK key sets left.

Only the pictured keys and sizes on the Extra Keys are available. I do have text only 1.75U stepped caps lock keys available but not the others you listed. These keys can likely be produced with a tooling fee; please email me for details.

And now for something completely different - a production photo I just came across of the various bottom inner assemblies for all but the Round 2 Model F boards.

BIA.jpg (1.86 MiB) Viewed 141947 times

[AlpsComeback]

If all you want is just basic QMK, then yeah, basically just clone the purdea.ro git repo and build straight from that. Really should work out of the box, and there's nothing piecemeal about it.

I'm trying my darndest but I keep running into issues.

• I started by nuking any qmk executable I had on my system, just to be sure it wasn't being used. I then, as directed by the Google doc, ran

  Code: Select all

  python3 -m pip install --user qmk
  qmk setup
  

  (i run a variant of arch btw) and had it clone into a completely fresh directory.
• After that, while in the git repo directory, I ran

  Code: Select all

  git remote add pandrew http://purdea.ro/qmk_firmware/
  git fetch pandrew
  git checkout -b wip pandrew/wip
  

  in that order, all worked fine
• I then tried to run

  Code: Select all

  make xwhatsit/brand_new_model_f/f62:default
  

  but I got this error:

  Code: Select all

  Compiling: keyboards/xwhatsit/matrix.c                                                             In file included from keyboards/xwhatsit/matrix.c:17:
  keyboards/xwhatsit/matrix.c: In function 'dac_init':
  quantum/quantum.h:195:50: error: array subscript 0 is outside array bounds of 'volatile uint8_t[0]' {aka 'volatile unsigned char[]'} [-Werror=array-bounds=]
    195 | #    define writePinLow(pin) (PORTx_ADDRESS(pin) &= ~_BV((pin)&0xF))
        |                                                  ^~
  

  There were many more variations of this "array subscript 0 is outside array bounds" error, so I suspect getting rid of the first one will get rid of them all. Was there a step I missed somewhere? I'm happy to move this to a DM too if someone wouldn't mind helping me out.

[taraskremen]

I'm trying my darndest but I keep running into issues.

• I started by nuking any qmk executable I had on my system, just to be sure it wasn't being used. I then, as directed by the Google doc, ran

  Code: Select all

  python3 -m pip install --user qmk
  qmk setup
  

  (i run a variant of arch btw) and had it clone into a completely fresh directory.
• After that, while in the git repo directory, I ran

  Code: Select all

  git remote add pandrew http://purdea.ro/qmk_firmware/
  git fetch pandrew
  git checkout -b wip pandrew/wip
  

  in that order, all worked fine
• I then tried to run

  Code: Select all

  make xwhatsit/brand_new_model_f/f62:default
  

  but I got this error:

  Code: Select all

  Compiling: keyboards/xwhatsit/matrix.c                                                             In file included from keyboards/xwhatsit/matrix.c:17:
  keyboards/xwhatsit/matrix.c: In function 'dac_init':
  quantum/quantum.h:195:50: error: array subscript 0 is outside array bounds of 'volatile uint8_t[0]' {aka 'volatile unsigned char[]'} [-Werror=array-bounds=]
    195 | #    define writePinLow(pin) (PORTx_ADDRESS(pin) &= ~_BV((pin)&0xF))
        |                                                  ^~
  

  There were many more variations of this "array subscript 0 is outside array bounds" error, so I suspect getting rid of the first one will get rid of them all. Was there a step I missed somewhere? I'm happy to move this to a DM too if someone wouldn't mind helping me out.

I am not terribly familiar with the QMK codebase, but it looks like it may be a compiler compatibility issue. Have you tried compiling with other GCC versions or on a different platform?

[AlpsComeback]

I am not terribly familiar with the QMK codebase, but it looks like it may be a compiler compatibility issue. Have you tried compiling with other GCC versions or on a different platform?

Yeah it turned out to be a compiler issue. While not listed anywhere in the instructions I found, upon running QMK setup, it does recommend avr-gcc 8 or lower. It may be worth it to reiterate that in the instructions, as I overlooked that multiple times. I may spend some time to streamline the QMK instructions, since I feel like they're not super readable and would love to prevent future users from going through the hassle that I did.

Also, in the QMK instructions that Andrei put together, it says that you can run `qmk compile` and `qmk flash`, but neither command worked and yielded an "error: argument invalid choice". I was able to run the `make` commands just fine though. No idea if that's a problem on my end or if it's just a part of the instructions that is now out of date.

Nonetheless, thank you for your help!

[:Dön:]

Hello.
I used a translator for the text, so there may be some parts that do not make sense. Please understand.
Zed and I did the print design for the previous JIS. (I provided the Japanese part).

The new print style is not very nice looking in my opinion. I am Japanese and the Japanese font in the new design looks very distorted. I would like to make the design more readable as Japanese if possible.

JIS New Production Key Set:

After a number of requests, I have decided to proceed with making the JIS sets. Previously these sets, as well as the APL sets, were Unicomp sets. APL will remain Unicomp (unless someone wants to make the template as was done for the couple recent new layout submissions). I will be making the JIS front print option (not shown below in my draft).

Can folks please check to correct my JIS mistakes and let me know what to fix before sending to the factory?

The first image shows what I updated, and the second image shows what Zed was working on (Zed is taking a well-deserved rest from the key set designs). All text will be black - no green text as shown in the Zed draft.
JIS draft3.JPG
JIS Standard - Copy.png

[LuX]

Any news on ortholinear keyboard shipping? Haven't gotten any shipping notification yet, so just wondering if you are slowly sending them out or if my order is stuck or something.

[Ellipse]

LuX I am still moving through the backlog - apologies for the delay. I hope to clear the current backlog over the coming weeks.

AlpsComeback that would be great! Please keep us posted.

As an update the corrected pad printing jig was just completed and the factory is now able to move to the next step to further adjust the custom-made pad printing machine for this pad printing. The process has taken far longer than expected. The first jig had some errors and had to be redesigned. As always please do sign the interest form to reserve your pad printed set. https://docs.google.com/forms/d/1873Q9w ... h4XtN1DfNk

We are still not decided on UV coating vs uncoated for the pad printing. I think the uncoated looks nicer and closer to the IBM originals but the UV coating may add some extra longevity to the keys which of course wear down with usage.

[AlpsComeback]

So after starting the documentation for QMK, I discovered Vial more or less accidentally. Well Vial scores top marks because it's basically everything I use QMK for except in a much easier to use GUI package. For some reason I just glossed over Vial in the past, but I finally tried it and I can see why it's the recommended choice now. Definitely the best option!

[depletedvespene]

…
If I lived on the numpad and function row, though, I'd likely do something quite like you have done. Truth is though I don't, and I really don't want to expand my collection with a new quest: matching numpads for all of my compact keyboards!

To each his/her/its/their own, of course... in my particular case, I've found that the most good-enough compromise is to have a regular numpad to the left of the main keyboard and only (through remapping) swap the 0 and . keys. I tested several other options, but muscle memory inhibited most. The problem with this, of course, is to have a 1U 0 and a 2U .. That's why on my "dream" numpad (of which I've talked before) both keys would be 1.5U in size.

[o2dazone]

I converted my f62 black case to an f62 ultracompact beige/off-white case today - I love my deathstar sized case, but I found myself preferring the form factor of my HHKB. Still fiddling with various feet for the right angle

IMG_4264.jpeg (2.47 MiB) Viewed 140515 times

IMG_5377.jpeg (3.38 MiB) Viewed 140515 times

IMG_5379.jpeg (2.49 MiB) Viewed 140515 times

IMG_5380.jpeg (2.49 MiB) Viewed 140515 times

IMG_5382.jpeg (2.36 MiB) Viewed 140515 times

IMG_5384.jpeg (2.27 MiB) Viewed 140515 times

IMG_5385.jpeg (2.05 MiB) Viewed 140515 times

IMG_5388.jpeg (4.42 MiB) Viewed 140470 times

Overall very happy. The steel tabs that sandwich the barrel plate to the steel plate and pcb is a little finicky but otherwise pretty straight forward install.

[Ellipse]

Nice photos o2dazone! Thanks for sharing them. This may be the first photos of the HHKB style Model F with an actual HHKB!

The TIA and BIA should be in line; it looks like in one of your photos the two inner assembly plates were not slid all of the way so that they can't slide any more. The manual shows a photo of the tab alignment: https://www.modelfkeyboards.com/wp-cont ... gnment.jpg

[o2dazone]

Thank you! I learned the hard way about the assembly plate misalignment when attempting to put the top shell on haha

[thefarside]

Regarding the pad printed keys, could you post a picture of the UV vs. non UV example?