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

[pilcher]

As promised, here is a write-up of the modifications that I made to my classic F104 to replace the built-in cable with a USB-C port.

https://github.com/ipilcher/f104-usb-mo ... /README.md

[Oelmuvun]

My F104 came in yesterday!

Surprisingly the box showed up in pretty reasonable shape externally, I was expecting a lot worse.
Despite two springs being bent over their barrels and one keycap somehow smashed a bit, everything popped together and worked straight away. I didn't have to troubleshoot any springs, nor were any missing.

I did spend a bit of time pulling hair in the terminal until I found the link for pilcher's guide to building the pandrew utility on Fedora. Thanks for that, it was a lifesaver, especially when I had not realized that the blank key between R-Alt and R-Ctrl was the Fn key and needed a way to test it. I am really tempted to split the R-Shift and move Fn up beside it so I can get R-Win back, but I want to enjoy this for a bit before I start causing problems.

As far as using the F104 goes I haven't really had a whole lot of time to properly sit down with it, but it feels just like my Model F 'XT' and 'AT' switches.... Except in a useful layout! I always liked the Model F switches when using my IBM 5150 more than the Model M despite the increased noise, and I certainly like the Model M more than Cherry MX Blue switches w/ Black springs.

Big thanks to Ellipse and everyone involved in the firmware and such for these boards!

PXL_20241030_222413549.2.jpg (908.85 KiB) Viewed 15131 times

PXL_20241030_223137439.2.jpg (784.78 KiB) Viewed 15131 times

PXL_20241030_223446658.2.jpg (887.31 KiB) Viewed 15131 times

PXL_20241030_230250927.2.jpg (810.79 KiB) Viewed 15131 times

PXL_20241031_232744600.2.jpg (967.43 KiB) Viewed 15131 times

PXL_20241031_234615626.2.jpg (667.94 KiB) Viewed 15131 times

[Ellipse]

My F104 came in yesterday!

Surprisingly the box showed up in pretty reasonable shape externally, I was expecting a lot worse.
Despite two springs being bent over their barrels and one keycap somehow smashed a bit, everything popped together and worked straight away. I didn't have to troubleshoot any springs, nor were any missing.

I did spend a bit of time pulling hair in the terminal until I found the link for pilcher's guide to building the pandrew utility on Fedora. Thanks for that, it was a lifesaver, especially when I had not realized that the blank key between R-Alt and R-Ctrl was the Fn key and needed a way to test it. I am really tempted to split the R-Shift and move Fn up beside it so I can get R-Win back, but I want to enjoy this for a bit before I start causing problems.

As far as using the F104 goes I haven't really had a whole lot of time to properly sit down with it, but it feels just like my Model F 'XT' and 'AT' switches.... Except in a useful layout! I always liked the Model F switches when using my IBM 5150 more than the Model M despite the increased noise, and I certainly like the Model M more than Cherry MX Blue switches w/ Black springs.

Big thanks to Ellipse and everyone involved in the firmware and such for these boards!

PXL_20241030_222413549.2.jpg
PXL_20241030_223137439.2.jpg
PXL_20241030_223446658.2.jpg
PXL_20241030_230250927.2.jpg


PXL_20241031_232744600.2.jpg
PXL_20241031_234615626.2.jpg

Thanks for sharing your review Oelmuvun and glad everything went ok. As always, with a future order of yours, everyone feel free to add an order note for me to replace any keys damaged in shipping as I have spares.

And a big thanks to pilcher who has published both a guide to compiling the pandrew utility on Linux as well as a guide to modding the new Model M style cases to accept a flush-mount USB-C port. I have added these links to the manual. How did you avoid breaking the blade while cutting through the aluminum case?

https://gist.github.com/ipilcher/9a14d8 ... 71a282fa74

https://github.com/ipilcher/f104-usb-mo ... /README.md

[pilcher]

And a big thanks to pilcher who has published both a guide to compiling the pandrew utility on Linux as well as a guide to modding the new Model M style cases to accept a flush-mount USB-C port. I have added these links to the manual. How did you avoid breaking the blade while cutting through the aluminum case?

I'm not sure what blade you're referring to. I used a hacksaw to cut the vertical sides of the hole in the case and then I simply broke the resulting "tab" out with a pair of pliers. (I actually expected that the tab would just bend, and I would have more cutting and filing to do to remove it. It was a pleasant surprise when it snapped off.)

[Ellipse]

I was asking about the hacksaw blade itself. I wasn't sure those were capable of cutting through 1-2mm of aluminum for the vertical sides you mentioned.

[nac5605]

Are you still waiting on getting those beamspring samples in, Ellipse?

[pilcher]

I was asking about the hacksaw blade itself. I wasn't sure those were capable of cutting through 1-2mm of aluminum for the vertical sides you mentioned.

Ah, gotcha. No problem with the hacksaw blade. I've cut through steel that is a lot tougher than this case plenty of times.

[resonator]

Secondly, I started noticing some prevalent off-center binding/scratchiness on a some of the unstabilized keys after a little over a week of use. I noticed there was a bit of light colored debris around the corner edges of the barrels from the keycap stem rubbing against them, and they did feel a bit sharp. I resolved this by just gently smoothing the corner edges of the barrels with the side of a flathead screwdriver blade. I don't know if this would've eventually worked itself out with more use/breaking-in but I haven't had the issue reoccur on any of the previously affected keys since doing that.

I have the same issue. It's only affecting the tab and caps-lock keys, but I map caps to ctrl and spend most of my time in a terminal, so those two keys get used a lot.

My experience is that it doesn't improve with time. If anything mine have gotten worse. I just tried wiping a little dialetric grease on the stem of one of the keys. It has helped for now, but I don't expect it to last given how the scratchiness is from the stem scraping along the top edge of the barrel. I expect the grease will be scraped off in short order.

I'm surprised that the key above enter which I have (mapped to backspace) doesn't have the same issue. It gets just as much use as tab (if not more) and it's just fine.

You don't sell stepped keys, do you Ellipse? I think that'd solve my problem by forcing me to press the keys in their centre. Or I could try replacing the barrel but I don't really feel like pulling my whole keyboard apart.

[Ellipse]

Yes nac5605 - the factory is still working on this.

resonator you may want to burnish the back of the key stem and/or try the wiggle method for these keys. In my testing I have been unable to reproduce the issue you are describing. I do not think it is an issue with the key contacting the top of the barrel but instead a limitation of the Model F design with a good amount of plastic surface area sliding against each other (the barrel and key). The 1.75U key is the largest non-stabilized Model F key and all Model F keys require slightly more force closer to the edges to actuate, unless the key has a nice old style wire stabilizer. This is true on my original Model F and Model M keyboards as well. You may want to also consider foam padding/o ring/etc. inside the key if this continues to be a bother. Filing down the barrel top 0.5mm may also help, but it is not recommended as the key would bottom by contacting the PCB with additional force.

There are stepped Caps Lock keys available on the Extra Keys page. You may also want to order a spare 1.75U nonstepped key as maybe your key is near the outer bounds of the acceptable tolerance range of these keys.

[genericusername57]

My experience is that it doesn't improve with time. If anything mine have gotten worse. I just tried wiping a little dialetric grease on the stem of one of the keys. It has helped for now, but I don't expect it to last given how the scratchiness is from the stem scraping along the top edge of the barrel. I expect the grease will be scraped off in short order.

I solved this on my F62 by polishing the keycap stems a bit on a 5000 grit sharpening stone (for knife sharpening). For me it was the arrow shape on the sides that was noticeably rough and with sharp edges. I had more than a few keys that were pretty scratchy when pressed off-center, including some 1U keys. They're now a lot smoother and while I haven't exactly analyzed it too much I kind of feel that they've gotten smoother over time as well. I did try some grease on one key but just like you said it doesn't really work over time so I would advise against it.

I also carefully squeezed some of the stems together to make them a bit more narrow, but I'd advise extreme caution in doing this as my Tab key stem didn't flex at all - it just snapped clean off with a little bit of pressure. I'm not sure if it's a manufacturing defect as all the other keys are perfectly bendable, it's just the Tab key that was brittle. It gave me a reason to order some colored modifiers from Unicomp though which I think looks nicer (and since the break was so clean I could mend it with epoxy).

[resonator]

I've tried some experiments. I first confirmed that using another keycap was fine, which it was. I inspected both keycaps to find any subtle differences but nothing stood out so I started trying things.

The first was burnishing the back of the stem. I used the handle of some stainless steel scissors which I had at hand. It made no difference.

Then I tried the wiggle method. No difference.

Next I tried to smooth the back of the stem on some 1500g sandpaper. No difference.

Then I tried smoothing the chamfer on the back edge of the stem. No difference.

Then I tried smoothing the triangular bumps on the edge. No difference.

And then I tried to spread the stem... and it broke. It didn't break off, but it cracked. It still worked but it didn't make a difference.

So I've swapped in the other keycaps. They have the wrong legends but they work nicely. I think I'll need to order some more caps.

[YALE70]

I've tried some experiments. I first confirmed that using another keycap was fine, which it was. I inspected both keycaps to find any subtle differences but nothing stood out so I started trying things.

The first was burnishing the back of the stem. I used the handle of some stainless steel scissors which I had at hand. It made no difference.

Then I tried the wiggle method. No difference.

Next I tried to smooth the back of the stem on some 1500g sandpaper. No difference.

Then I tried smoothing the chamfer on the back edge of the stem. No difference.

Then I tried smoothing the triangular bumps on the edge. No difference.

And then I tried to spread the stem... and it broke. It didn't break off, but it cracked. It still worked but it didn't make a difference.

So I've swapped in the other keycaps. They have the wrong legends but they work nicely. I think I'll need to order some more caps.

Give my screwdriver trick with the barrels a shot and let me know if that makes a difference for you. Just rub the flat side against the corner edges of the barrel a couple of times to smooth out the sharpness and it should hopefully improve the key feel. On most of the keys I've done this on; the binding hasn't reoccurred but sometimes it takes more than one pass. I've found this seems to have had a bigger impact than just trying to smooth the corner edges at the base of the key stem, though they seem to work well in conjunction.

I think the larger unstabilized keys like "Tab", "Caps Lock" and "Ctrl" are still going to feel a little scratchy regardless when pressed off-center because of the additional leverage placed against the key stem/barrel compared to the single unit keys - but this should hopefully still improve them a little.

20241106_115942.jpg (947.56 KiB) Viewed 14019 times

[resonator]

Give my screwdriver trick with the barrels a shot and let me know if that makes a difference for you.

I gave it a try, but it's not the answer. The edge of the barrel was very smooth to begin with. The replacement keys I swapped in yesterday are much smoother in feel, but they make a slight hiss sound as they're pressed. The sound that the screwdriver made while I was burnishing the edge was the same, so I'm confident that the sound that I'm hearing is due to rubbing in that area. Also, very few of my other keys have this scratchy sound. It's interesting that the worst are 'E' and 'F'. Those are the keys my left hand relaxes on, and it's also the hand I use to find the home keys. I expect they see a lot of lateral movement compared to the other keys.

I tried burnishing the back of the replacement keys to see if that improved things. It actually made them worse, but I suspect not from the burnishing but because the stem was narrowed. I'm suspicious that the wiggle method will actually make this problem worse, not better, but I can't say anything for sure since I've not actually fixed any keys yet.

I then swapped the smooth delete (above enter HHKB style) with the scratchy tab. The delete key was worse in the tab position and the tab key was better in the delete position, but neither key was perfect. This tells me that the issue is cause by a combination of barrel and key. That also explains why the replacement keys weren't perfect in the tab and ctrl (capslock) positions, but were much better.

[NathanA]

Calling F62 owners as firmware testers

I'm adding scumyc layout support to the Vial firmware, but I'm doing it by adding it as a layout option in the main F62 firmware, rather than treating the scumyc board as a completely separate model the way that it has been done in QMK up to this point.

I would much appreciate it if both any standard F62 owners and any F62 scumyc owners who are feeling adventurous would flash their keyboards with this test firmware, and report back to me any problems you end up running into.

Specifically, I want to check both that:

• ...this firmware actually works properly on scumyc boards, and also that...
• ...I didn't break regular F62 boards in the process

Thanks much!

[resonator]

I tried it out on my scumyc. The firmware is fine, but the script to flash it on an arm Mac wasn't. I'm not sure why flash-util/dfu-programmer contains `dfu-programmer.macosx`. I hacked the script to rely on $PATH to find the correct binary. I also have no idea why it was stalling while "Waiting for the keyboard". The command was fine and returned 0. I pulled out the redirects to /dev/null to find out what was going on, and it started working. I didn't bother trying to understand it further than that.

[Ellipse]

Here is the Apple/Mac F1-F15 set, updated as requested to be similar to the latest Mac design:

Apple-Mac F1-F15.PNG (33.37 KiB) Viewed 13402 times

[NathanA]

I tried it out on my scumyc. The firmware is fine,

Good to hear; thank you! I take it, then, that you had no problem with any of the bottom row keys, and that key remapping in Vial worked fine (the correct key got remapped to the correct value)?

but the script to flash it on an arm Mac wasn't. I'm not sure why flash-util/dfu-programmer contains `dfu-programmer.macosx`.

As I was reading through your post, I realized there was a packaging error in this test firmware ZIP file...

flash-util/dfu-programmer is supposed to be a symlink to flash-util/dfu-programmer.macosx. But I was in a hurry, arranged the files to be zipped up in Windows instead of on Linux as I usually do, and forgot all about the symlink. Though NTFS on Windows does have a similar concept, I started the preparation by unpacking my original 7-Zip package on a Windows host, and the 7-Zip Windows app doesn't know what to do when it sees a UNIX symbolic link in a 7z archive. So the "dfu-programmer" entry in that directory ended up being an actual file with contents that represented what it would have been pointing to if it were a proper symbolic link. That broken link then got ZIPped up when it was in that state.

So, that's a good lesson/reminder to me not to get lazy with the packaging!

The symlink exists in the first place (and the actual MacOS binary renamed to dfu-programmer.macosx) because if you are running Bourne shell scripts, you could be running them on any one of a baker's dozen different *NIX systems, and although I include dfu-programmer binaries for both Windows and Mac in the package for convenience's sake, I'm not going to build & include statically-linked dfu-programmer binaries for every conceivable modern-day OS in existence. MacOS (I refuse to lowercase the 'm', heh) is obviously the UNIX with the lion's share of active personal/desktop users, so that's the one I distribute a binary for. If you are running anything else, you are expected to make sure a functioning dfu-programmer is already installed on your system & available in your PATH, delete that symlink, and re-point it to dfu-programmer.stock which will call your native version of dfu-programmer, as outlined in the README.

In any case, thanks so much for the testing & report!

EDIT: Turns out the built-in ZIP archive handler in Windows Explorer also doesn't know what to do with UNIX-style symbolic links, and the same thing ends up happening. Anyway, while I continue to plug away at the next full release of the Vial firmwares, I have fixed the ZIP package on the server for this scumyc test firmware, so that others who might want to use on MacOS don't run into the same problem with the supplied flash script.

[resonator]

I take it, then, that you had no problem with any of the bottom row keys, and that key remapping in Vial worked fine (the correct key got remapped to the correct value)?

Yeah, the Matrix showed that the correct key registered for each of the buttons. However, I only have the first and forth buttons in the cluster right of space connected. I can't verify whether the second and third buttons are correct.

As I was reading through your post, I realized there was a packaging error in this test firmware ZIP file...

No worries at all. It wasn't too difficult to get past.

[NilesLinus]

Tl;dr: Do the original zinc F77 models being sold right now in November '24 come with updated firmware that allows users to remap keys and assign macros easily and get back to using the product in their projects immediately, or is this keyboard a technological experiment and goat rodeo in the guise of a retail-ready product?

———

Man, I'm beginning to think this project needed a technical editor and content designer. Most of the online documentation is a mess. Just ordering from the website is an unnecessarily convoluted and scattered experience. But assuming you clear that hurdle and receive your keyboard, then the real mental gymnastics begin.

At certain points we're told to follow a series of steps precisely, only to find out that key pieces of information that would make that instruction possible are either ambiguous or seemingly missing. Certain portions of videos appear to have been outright redacted, or at least that's my working theory. Later we see warnings to not follow certain instructions at all, insofar as they have now become deprecated. I wish we'd known that before we spent time and energy trying to make sense of that outdated material. In the end, the necessary content is so spread out across multiple resource sites and stakeholders that the end users lose their way. When it's all said and done, there's no way out of this corn maze, and the visitors are eaten by the scarecrows.

I have to think that the average customer just wants a really great keyboard for their projects, but doesn't want the keyboard to become an extended technical project in and of itself. That might be a reasonable undertaking for a computer software engineer or other technical expert, who might even find the challenge fun, but for the rest of us the keyboard is meant to be an effective tool that allows us to pursue other goals. It cannot become the goal itself.

I realize I'm venting, so I'll take a breath and ask my most basic question. Chyrosran's expletive-strewn (and frankly hilarious) YouTube review of the extremely awesome F77 leads me to believe that programming the keyboard is a nightmare of insurmountable proportions. Later he references a video that is meant to make it all very simple, but does not tell us where to find that video. (That really wasn't his job anyway.) So do recent purchasers of the original F77 keyboards need to reinstall firmware before remapping keys, or is that already done for us at time of purchase as it should be? And if the customer has to do it, where is the single-point location that aggregates all the essential information and orders it an easy-to-follow, numbered, idiot-proof task list? And will this process be as well explained for us MacOS users as it is for Windows users?

I am in no way a helpless novice when it comes to negotiating software issues. In fact, most days I'm rather intuitive (or at least blissfully lucky) in my ability to find workable solutions to technical problems. But right now I just want to rearrange a few keys, attach some macros, and get back to my bloody work. I'm starting to worry this product isnt retail-ready, which if true begs the question of why it's on the market at a very lofty price point. I hope I'm wrong because the hardware itself is fantastic.

Can somebody help‽

[resonator]

Can somebody help‽

What you want is NathanA's Vial firmware. I'd suggest starting there and working backwards. I'm not sure what's currently shipping. I'm sure some else can help with that.

I totally agree with your rant, by the way. The walls of text are intimidating and so unnecessary. I'd love to see someone delete half of it.

[NathanA]

[...] or is this keyboard a technological experiment and goat rodeo in the guise of a retail-ready product?

I totally agree with your rant, by the way. The walls of text are intimidating and so unnecessary. I'd love to see someone delete half of it.

I've touched on this in past responses I've made whenever similar critiques have been put forth, and I try to remain as non-partisan and as even-handed as possible when I jump in.

My short (hopefully fair to all parties) take is this: though there are definitely times when Ellipse has done himself no favors, and though I do have sympathy for people with similar takes on at least some parts of the project and his handling of some things, at the end of the day, this thread is in the "Group buys" section of a third-party web-based forum (more than one, actually, and it's in the "Group buys" section on all of them) for a reason, and people would do well to keep that in mind. And -- at least this is my personal read on things -- that reason is because this is largely a one-man-band operation, and very emphatically not a "retail" product. Where the lines get blurred, and where people I think can easily come away with the wrong impression (especially those who have never been exposed to the loosely-associated MK community and the MK "group buy" culture, which just is what it is, for better or worse), is that Ellipse runs his GBs as more like a retail product fulfillment business than most GB operators do, dedicated web site & order collection and fulfillment & all.

Does this excuse any shortcomings? Not at all. But hopefully at a minimum it helps to set and tamper expectations, and help frame them in at least what I think is a proper context. Just like with Kickstarters and similar, there is never any guarantee that whatever you fund will even be successful, and there have been multiple GBs in this community that have gone down in flames where participants lost prepaid monies without ever getting anything in return. That's inherently part of the risk. (I'm not arguing it's good, right, should be that way, etc. And in fact as Kickstarters and the like have matured over the years, I have observed that people's expectations of them have also grown over time & as a result most projects are getting held to higher and higher standards as the years progress, which is definitely good. After all, if people say they're going to make such and such a thing and it's going to do X, Y, and Z, they should be true to their word. Keep in mind, though, that there is always a cost to such things: if the cultural expectation becomes that, in order to reduce or eliminate risk as much as possible, those behind such a campaign have to be already firmly-established, professional companies who has been around for years and have positive cash flow on their books, then you have just effectively re-corporatized everything and eliminated the risk-takers and outside-the-box thinkers, which was the whole point of Kickstarter-esque campaigns in the first place!)

So there are group-buy runners who have done considerably worse at the handling of their projects, as well as some who have done better at it, than Ellipse. At least he managed to deliver the product he said he would, and the end result is (arguably) an amazing achievement from a physical manufacturing, research, and logistics perspective, especially at this scale. He is also the only one that both has even merely expressed an interest in increasing the total market supply of keyboards with this switch tech, but more than that is actually doing it. So for those reasons, I can cut him a lot of slack. It's also clear to anyone who understands the back-story that this project couldn't even have been conceived of without the existence of the xwhatsit controller, and Ellipse has admitted on multiple occasions that he doesn't understand the EE or software sides of things. (What he excels at is the manufacturing & supply chain stuff, and all of the materials research and such leading up to that.) All of the development on the electronics and software sides has been effectively crowdsourced and has evolved considerably since the first boards shipped, which I am sure is a direct contributing factor to the state of the manual, the confusion surrounding the state of the firmware & Chyrosran's now-infamous rant, etc. It was in fact that rant, my own disdain for the messiness of the firmware situation, plus my awareness of the Vial project, that caused me to jump in and see if I could help at all with trying to streamline that.

If anyone is unsatisfied with the resulting experience & thinks that they can do better, I truly would love for them to try...the more the merrier IMO, and increased competition in this space can only be a good thing! That he has produced and sold as many of these as he has would certainly seem to indicate there is some kind of market for it, so honestly I am a little surprised that other copycat projects haven't popped up by now. (I mean, there are things like the FSSK/FEXT, but that is way more of a "DIY" experience than Ellipse's is, and nobody else seems to be tackling the whole enchilada: barrels + springs + flippers + electronics + enclosures + assembly.) C'mon, people: the patents on these keyswitches have long since expired! Chop-chop!

Anyway, sorry, I went for longer than I intended, as usual...to get back to the original question:

So do recent purchasers of the original F77 keyboards need to reinstall firmware before remapping keys, or is that already done for us at time of purchase as it should be?

I honestly have zero read on what the situation is with what ships on the last remaining stock of F62/F77, if you were to buy one straight from him right now. It may indeed be that whatever was flashed on them at the factory is what they still have on them, and they aren't getting updated before they go out the door. (For other, more recently produced models, the situation is much more clear cut, because the Vial firmware is the only one that has ever existed for many of them.)

Here is the "quick" explanation for how things started & got to where we are today:

• When the boards started shipping, the only firmware that existed to drive the keyboard controller was xwhatsit's "IBM capsense" firmware, paired with his client-side configuration software. With this combo, the keyboard is indeed at least relatively easily reprogrammable. Where the old xwhatsit software fell short was in the fiddly capsense matrix calibration.
• AFTER the boards started shipping, the amazing pandrew came on the scene with a completely original implementation of a capsense matrix routine for QMK, which allowed QMK to get ported to the xwhatsit controller hardware. It largely solved the calibration problem, and QMK is awesomely flexible, but is also extremely user-unfriendly. You basically have to locally host a cross-compile toolchain and QMK source build tree just to adjust your key mappings, as the mappings are hard-coded in code & so you have to re-flash the firmware every time you want to change things.
• darkcruix came out with a VIA port after that; VIA is an extension to QMK that, combined with a client-side app, allows for live key remapping, amongst other things. But the app itself isn't open-source and has some annoying limits.
• Vial is an open-source alternative to VIA. I have worked to build Vial firmwares for all Ellipse boards designed to-date that use some variant of the xwhatsit controller under-the-hood.

The whole xwhatsit > QMK > VIA thing is what set Chyrosran (understandably) off, especially given that he got one of the first boards off the assembly line, that the software that exists just to re-flash the controller is itself not very user-friendly, that methods for kicking the keyboard controller into firmware-download mode have changed over time (leading to the documentation inaccuracies) and can become a problem if you happen to flash the wrong firmware to your controller because it's not clear to you which one to use, etc. I hope I have managed to streamline at least some of that for the more casual user.

You should be able to tell if your keyboard is running the most current firmware simply by trying to run the Vial app. If Vial cannot detect your keyboard while it's plugged in and working, then you aren't running the latest (Vial-based) firmware. In that case, you can download the latest release from here, read through the README, and follow the flashing instructions. And I very happily welcome any feedback, especially if I have not made something clear.

[NilesLinus]

Thank you for this clearly written and sensible response. I'm going to parse it carefully and hope for a little luck with my particular unit.

And in case I wasn't explicit enough, I have great respect for what Ellipse is trying to do with this very cool project. How a single person figures out the black box of Chinese manufacturing is an accomplishment by itself.

[Ellipse]

NilesLinus while I appreciate your longstanding support of the project, it appears that some of your comments are inaccurate and years out of date, as I can see that you were part of the very first batch of orders from many years ago; a lot has changed since then! It is clear that you did not recently review the web site fully before commenting, as some of your comments are specifically answered in the manual and elsewhere, such as your questions about Vial firmware. Thanks to NathanA, the xwhatsit controllers switched over to Vial exclusively about a year or so ago. The manual notes that the 62/77 keyboards remain on QMK unless you request in the order notes that I flash Vial on it (these boards arrived well before the NathanA Vial upgrade).

The good news is that the manual has been updated and is now a step-by-step guide to setting up and maintaining your new Model F keyboard. Additionally, there is an hour long step-by-step setup video included in the manual. I have received lots of feedback over the past year from those brand new to the hobby, who are not on the forums, and even newcomers have told me they were able to follow the setup guide easily and there was no trouble in setting things up. No one has to go all over the place to find information anymore as everything you need to know to set up and maintain your new Model F is organized in the manual now.

I recommend everyone looks through the web site, especially the product pages which have been updated to be more descriptive; the product pages now explain each of the recommended add-ons.

Instead of making generalizations, the best way to be helpful is to refer to specific portions of the project web site and what they should be changed to if they are unclear. I am quite firm on the explanation of how and why the project is run as it is run (see the top of the manual for details) but other than that I have been open to many suggestions, including some of the most noticeable suggestions to offer ultra compact modern style case Model F keyboards; a number of folks on the forums and privately through email have supported the project by contributing firmware/software, written content, and advice regarding engineering, marketing, and manufacturing, without which this project certainly would not have existed at all. My biggest current request is if someone could offer specialized advice on marketing as that is arguably the most important way to grow the project.

NathanA has put together a terrific summary of things above so I do recommend reviewing it.

[RainehDaze]

Hurrah, got my F104!



Mostly good news, I still need to fiddle with some things a bit more, I think. Not really sure what to do exactly with one of my extra ` keys. I'd make it a dedicated compose key, but sadly that cap is 1.5U only. Maybe I can put a sticker on a blank cap, I just need to get the sticker first…

[Ellipse]

Glad your keyboard arrived safely RainehDaze! That is a nice custom setup with the spring logo keys and HHKB style layout!

[RainehDaze]

Glad your keyboard arrived safely RainehDaze! That is a nice custom setup with the spring logo keys and HHKB style layout!

Yup, got used to it with the F77 and I really didn't want to give up having the function key there for easy access to media shortcuts (or, of all things, macros to write a couple of old english letters). As for the buckling spring keys… too many blanks in a printed set is boring, right?

[Ellipse]

The Chyrosran22 keyboard has now shipped! Below is a photo of this keyboard. Chyros has a beige UK ISO F104 keyboard with a solenoid, some keys from the Mopar Blue addon set, stepped Caps Lock, and the Model M-specific add-on keys Tab, Print Screen, and Pause/Break.

2024-11-12_20-55-58.jpg (815.64 KiB) Viewed 12744 times

I have also put together a summary of the various updates since Chyros's F77 review, for those wondering what has been going on with the project in recent years:

No more QMK web site:  The old QMK is gone, not even an option on these keyboards any more.  The firmware is now exclusively Vial, thanks to DT forum member NathanA.  Can use the Vial program for offline use or go to the web site Vial.rocks using a Chrome-based browser.  You don't have to load any configuration files as the keyboard is recognized natively by both those options.  The latest firmware is flashed on each 104/SSK, so it is not necessary to flash anything to change your keymap options.  New firmware is now flashed with a bat file or .sh file for linux instead of directly flashing a hex file.  This means that it's a few steps now, but all you have to do to flash new firmware is install the atmega drivers, download the QMK-layout-files.zip file from the manual, and double click the bat file that you want to flash.  The bat files are named to correspond with the keyboard, round, and layout, for example "f104 r2 ansi HHKB Split Backspace.bat" is for the round 2 Model M style f104 keyboard with ANSI style layout (ANSI style Enter and left shift), HHKB style modifications (split right shift and swapped caps/ctrl), and split backspace.  The bootloader mode is accessible by a key combination or more easily by clicking the Enter Bootloader button in the pandrew utility available in that same zip file mentioned above.  

All in stock instead of made to order:  The F104 and FSSK variations are now all in stock.  Shipping started in September and the backlog will continue shipping this month and should wrap up next month.  As opposed to the made-to-order nature of the prior projects, I made many extra keyboards so that everyone can still order from current stock in the near future and get a keyboard from this completed batch.

Clear order status now at the top of the Updates page:  The top of the Updates page now describes a detailed order status for each item, for those eager to see when their keyboard is expected to finish assembly and/or ship.  I also detailed all of the reasons behind the tooling and production delays (one main issue was getting the cases right - delays were due to both the time to complete the tooling to make the new die cast molds for the cases as well as making sure the production quality of the cases met my standards).  

Case material is now die cast aluminum instead of die cast zinc but the keyboard is still very heavy because the layout is bigger.  This allowed the package weight to remain about the same so I didn't have to pass along a shipping cost increase.  The case was designed to look like the Model M on top, but with the bottom being modified to be more like the XT bottom cases (just a curved metal plate) so I didn't have to make a mold for the bottom cases and so the thicker Model F inner assembly could fit in a Model M-sized case.  The case bolts are now countersunk and T8.  There is now a spot inside each keyboard case to mount both the solenoid and driver.  There is a choice of 12 LED overlay options.

Controllers:  The F104/FSSK controllers are still the ATMEGA32 based open source design, but they now support 3 LEDs and a solenoid at the same time, thanks to updates by pandrew and wcass.  The RP2040 based open source controller developed by forum member Rico ("the Leyden Jar controller") is not used with the 104/SSK, but it was completed and is being used in all of the 122 keyboards as this controller supports 18x8 matrix (2 extra columns) compared to the ATMEGA controllers which support a 16x8 matrix.  It is also exclusively Vial, no QMK.  There are plans to extend support of this controller to the other new Model F keyboards for future compatibility once the ATMEGA chip goes away.  Two of the most talked about new features planned but not yet implemented are PS/2 support and the ability to connect one Leyden Jar controller to another Leyden Jar controller for the purposes of using the controller in a split keyboard like the Split Ortholinear Model F Keyboard.  This controller has the advantage of more memory for complex macros and layers, but I have not seen any real-world performance differences.  The optional solenoid can be powered on and off by a key combination.

NKRO:  NKRO remains disabled by default for compatibility reasons; the manual describes a Vial option that can be set up to toggle NKRO.

Reorganized manual:  The manual has been thoroughly updated and reorganized based on feedback over the past few years.  An hour-long, step-by-step setup video has been created and the included green booklet now instructs everyone to follow the video and manual exclusively to set up their keyboard.  The manual is now comprehensive and it includes every setup, maintenance, and troubleshooting step needed for a new Model F keyboard, so folks won't have to spend hours trying to think of their own way to do something.  One no longer needs to visit any other web sites or consult any other manuals unless you want to do something advanced like compiling your own firmware.  I have also been more vocal about the project philosophy, writing it up at the top of the manual and discussing it elsewhere, which explains the reasons behind the project philosophy focusing on teaching everyone how to maintain their Model F for life instead of relying on Genius Bar type folks to answer every question for you for the one-year warranty period and then encourage you to buy the newer model because it is impossible to repair the current product in a cost effective way.  My position is that the current manual is the only place you need to go for the Model F and almost every possible issue can be fixed on your own by reading the manual from start to finish instead of emailing me directly for any issue.  I also created a "Model F vs. Model M - what are the differences" video and put it on the home page as that appears to have been a big help.  Other small changes for clarity:  for example, Right Ctrl is now Right Ctrl and not Fn as it was before (the key between right Alt and Right Ctrl is now the Fn key).

Big price drops on previous Model F project:  It has been 9 years (!) since the Brand New Model F Keyboards project started and now the original models have been discounted by a couple hundred dollars as that project draws nearer to a close, so those with smaller spending abilities can pick up a smaller layout new Model F for as low as $175.

Status of F122 and Round 2 Beam Spring projects:  Hopefully around year end (or maybe early next year) the next container ship will be here or on its way here for the next batch, which will contain the F122 and Round 2 beam spring keyboards. The factory is wrapping up assembly this month on the F122 keyboards, which have all finished production, and they are finishing up the final prototypes of each beam spring keyboard model for my review. The beam spring project has taken far longer than expected but since we may only do one production run, I want to make sure everything is correct.

Current factory set Fn keys:

Hold down Fn+Spacebar+
T–>Toggle the Solenoid On/Off Any key HPT_TOG
+= Increase Solenoid dwell time HPT_DWLI
-_ Decrease Solenoid dwell time HPT_DWLD
E–>EEPROM Reset
R–>Reset (enter bootloader)
D–>Debug

Hold down the keys Fn+

Esc–>Power
F1–>Brightness Down
F2–>Brightness Up
F6–>Media Stop
F7–>Media Prev
F8–>Media Play
F9–>Media Next
F10–>Media Mute
F11–>Vol Down
F12–>Vol Up
Print Screen–>Eject

[NathanA]

The Chyrosran22 keyboard has now shipped!

This oughta be fun.

The bootloader mode is accessible by a key combination or more easily by clicking the Enter Bootloader button in the pandrew utility available in that same zip file mentioned above.

As an additional reminder, you can also enter bootloader mode straight from within Vial itself. So you don't even have to leave the Vial app and go to another one to do that.  

NKRO:  NKRO was disabled by default for compatibility reasons last time but I believe NathanA has enabled NKRO by default for these keyboards, so there is no setting to turn on and off NKRO to my knowledge.

This is not correct; I already addressed this a couple of weeks back, over here.

There isn't a NKRO toggle key included by default on most key maps, but I plan to change that by adding one to all of the included keymaps in the next release. In the meantime, anyone can very easily add an NKRO toggle key to their keyboard using Vial. I recommend 'N' key on layer 2 (Fn+Spacebar+N), which is the key I will be using when I populate the default keymaps with it.

[Ellipse]

Thanks NathanA; I have updated the manual and my above posting.

[NathanA]

Not really sure what to do exactly with one of my extra ` keys.

Following up on my super-informal poll from several weeks back, regardless of what you choose to change it to, which of those two keys do you expect you would change: the far-left one, or the far-right one?