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

[darkcruix]

Tried the SCUMYC layout for the first time and I start to get used to it.

IMG_4656.JPG (1.28 MiB) Viewed 30971 times

[shampoo]

Anyone ever look at making this wireless ? Ideally with the ability to switch between hosts ?

I think the idea was/is that adding the wireless option is "easily" done by yourself (just add a battery, charging circuit, bluetooth module and write a driver for QMK to interface with the bluetooth module); in short: it's too much work for a one-person keyboard factory.

Adafruit does sell this: https://www.adafruit.com/product/2995 and it has the ability to be a wireless keyboard: https://learn.adafruit.com/adafruit-fea ... idkeyboard

I'm crazy busy, but maybe over the winter if I have more time I'll take a stab at it.

[TerminalJunkie]

Tried the SCUMYC layout for the first time and I start to get used to it.

How do you have the keys mapped? My bottom row is Opt, MacFn, Cmd, Ctrl, Space, CapsLock, nothing, nothing, and MO(1).

20776BDB-8AD8-45D1-8A0F-4EB4DD5EBB7F.jpeg (1.9 MiB) Viewed 30957 times

[Muirium]

Correct Mac keyboard modifier sequence always ends in Option and Command right next to the spacebar.

I'm crazy busy, but maybe over the winter if I have more time I'll take a stab at it.

I’ve had one of those exact Adafruit boards for many years and still haven’t gotten around to it. Good luck!

[darkcruix]

Correct Mac keyboard modifier sequence always ends in Option and Command right next to the spacebar.

I'm crazy busy, but maybe over the winter if I have more time I'll take a stab at it.

I’ve had one of those exact Adafruit boards for many years and still haven’t gotten around to it. Good luck!

Apple had some weird designs in the past ... I only want the Cmd next to the space bar ... I prefer my Alt at the end of the Space Bar and my Control at the Caps position...
https://en.wikipedia.org/wiki/Apple_key ... _M0116.jpg

[tiltowait]

For mapping, I have the basic Apple bottom row with the key right of right shift being MO1. The only custom I have are Tab + HJKL for arrow keys, Tab + YUIO for Shift+Arrow keys, and Tab + M for enter.

ETA: Something I keep meaning to ask: Does the keyboard need to draw 500 mA of current? I ask, because I'm able to run my xwhatsit beamspring at 100 mA without trouble.

[phughes]

Just recieved my UK layout F77 today and have assembled the keys.

It truly is remarkable! Ellipse - you have created an incredible product against all odds.

Thankfully the extra mileage to the UK didn't affect the keyboard at all and it all worked with no tweaks. The £80 ($97) customs charge was a bitter pill to swallow - but expected. I was dreading the final journey from the UK depot with Parcel Farce as they're known to be not be particularly delicate. I'd have been gutted if it had been damaged in the final 100 miles of its journey.

If any of my co-workers complain about the noise, at least I can batter them with it

Thanks again Ellipse for bringing some joy into my office environment.

Paul

[Ellipse]

I received some interesting Vial news today: "There's even a web configurator so there's no need to install client software if you don't want to/if you're on someone else's computer: https://vial.rocks – instant keyboard configuration and experimentation from a web page! "

Seems to be useful for updating your Vial configuration after installing it.

[Sheepless]

Yes I think you are right! That key may have been damaged in shipping. If there's no way to gently push the stabilizer back into place please send me an email to arrange a replacement key.

The replacement key arrived today, and I'm glad to report that it works perfectly. Thanks!

[darkcruix]

I received some interesting Vial news today: "There's even a web configurator so there's no need to install client software if you don't want to/if you're on someone else's computer: https://vial.rocks – instant keyboard configuration and experimentation from a web page! "

Seems to be useful for updating your Vial configuration after installing it.

Looks interesting, but from a security standpoint this sounds ... difficult (without knowing the full implementation). "Silent" access to a device that is used to enter credentials through the internet ...

[Unicorn]

I received my F62 today. It's quite lovely. I'm in the process of installing the keys but the 'A' will not actuate properly. I've reseated the cap a couple dozen times (I've tried laying the board flat and on it's side). I have also replaced the spring. No dice.

Does anyone have a suggestion? Due to a disability, I don't have the hand strength to remove PCB from plate.

[darkcruix]

Tried the SCUMYC layout for the first time and I start to get used to it.

How do you have the keys mapped? My bottom row is Opt, MacFn, Cmd, Ctrl, Space, CapsLock, nothing, nothing, and MO(1).

20776BDB-8AD8-45D1-8A0F-4EB4DD5EBB7F.jpeg

How did you implement MacFn ?

[Muirium]

I do it with Karabiner (remap Insert to Fn on the host). Don’t know if there’s a way on the board itself.

[TerminalJunkie]

I do it with Karabiner (remap Insert to Fn on the host). Don’t know if there’s a way on the board itself.

Same.

[OxC0FFEE]

I do it with Karabiner (remap Insert to Fn on the host).

Can you share how you do it in Karabiner? I tried, but it's not sending the right code. I've probably stuffed it up somehow.

[OxC0FFEE]

Looks interesting, but from a security standpoint this sounds ... difficult (without knowing the full implementation). "Silent" access to a device that is used to enter credentials through the internet ...

A site can't access the keyboard firmware without consent (there's a browser popup). Vial's open-source so it could be audited for security issues.

That said, it certainly has the potential for good pranks, should a coworker/friend with Vial firmware leave their machine unattended

[Ellipse]

Unicorn the flipper may have become stuck as these keyboards are unfortunately bounced around in shipping - please use tweezers to move around the flipper inside the barrel so that it can move freely.

I wanted to post (with permission) another customer photo, this time featuring a unique layout and the Mopar Blue keys - I have not seen more than a handful of photos so far with these keys.

The top row of keys on the right side block is planned for media keys once they are ordered and shipped, I was told.

mopar blue.jpg (2.09 MiB) Viewed 30402 times

[Bjerrk]

Unicorn the flipper may have become stuck

Unicorn_the_flipper.png (302.81 KiB) Viewed 30377 times

[Kugelkopf]

Having spent more than a week with my new acquisition it might be the right time to share some experiences from the perspective of a user who is less of a keyboard geek than many others populating this forum, uses a national variant of the keyboard (German in this case) and not only OS X, but also an outdated OS X version. I'm trying to collect all steps to get such a combination going in one place.

Arrival

Don't start to wear those pyjamas trousers with the stretched out waistband after tracking stated "Customs Clearance Processing Complete"! Don't let yourself be lulled into a false sense of security by sound statements like "Departed Facility" and "Arrived at Facility" without any information on the nature and location of the "Facility" in question. And be aware of the fact, that parcels accompanied by a customs bill may be delivered at unusual times.

In our case Joe's parcel, presumed to still hang around 600km away, arrived early on a sunny Saturday, a day of the week our family tends to sleep well into the mid-morning. Luckily, the bell was heard — who can sleep fast after Joe's shipment notification has arrived — and only after mobilisation of all family members the exact ransom sum could finally be scraped together to get hold of the parcel without loosing hold of one's trousers. As turned out later, the first tracking status indicating arrival at our city and imminent delivery had been issued at 6:35 a.m. in DHL tracking. The original tracking by Asendia uses times that seem to belong to the time zone of Izhevsk, Russia.

So after nearly four years of subliminal anticipation the F77 had finally arrived. I'm not a friend of unboxing reports, but thought it might be interesting for Joe to see how his parcels look, when they arrive at foreign destinations:
 

Ankunft.jpg (299.49 KiB) Viewed 30151 times

The coloured ornaments are especially precious: no custom charges but 76.20€ taxes and 6€ handling fee by DHL (around 82US$ in total — I've been surprised to learn how much are import charges in GB these days). The handling fee is pocketed by DHL for advancing the charges upon import and collecting them at the recipient's door upon delivery. Cash required, no change.

Five hours after the incident another DHL courier showed up with a domestic parcel at the usual time of the day.

Assembly

Documentation of the new Model F and it's essential parts has been compiled in an amazing effort by various voluntary contributors. Without diminishing the results achieved, one can state that a coherent and structured representation of all the pieces of information isn't the strongest point of the project.

The Model F came preinstalled with the space bar. Except for one (of course), all remaining keys could be installed without notable problems following Ellipse's gravitation assisted method with the keyboard hold vertically with the space bar up. The last one finally worked after adjusting it's spring as described at https://www.modelfkeyboards.com/manual/

Avoid to start installing stabilisers before fully reading "Initial setup of your New Model F Keyboard + all instructional videos". Stabilisers are covered somewhat out of assembly order in section 7. They are also omitted from the "correct key installation procedure video". Guided by the latter and a certain amount of impatience I had started to give one of the white stabilisers a try only to find out, that something was wrong. It goes without saying I had installed it at the ISO Enter position, the only one, that needed a black stabiliser.

Inspired by the method first described by fellow forum participant "DrivenKeys" on page 193 of this thread, but too lazy to do the required paper work, I was able to remove the stabiliser using a customary anchor (5mm diameter). I won't generally recommend this procedure, however: resolute natures might burst the barrel while even moderate tightening may cause slight damage to the stabiliser due to the bolt coming out laterally.

Stabilisierer0.jpg (30.53 KiB) Viewed 30151 times

Fig. 2: tools used for removing an incorrectly installed stabiliser. The stabiliser has suffered a few inner scratches, though.

First impression
 

20220624-F77-30.jpg (336.74 KiB) Viewed 30151 times

Fig. 3: the F really ties the desk together

In my opinion the typing experience of a IBM Selectric remains unrivaled. Hence my motivation to embark the Model F project was partially unjustified in that respect. It can't nevertheless be overseen, that this is a gorgeous keyboard. The project's result is even more remarkable considering that it has been achieved by a single dedicated person. Congratulations, Joe! I regard it also as a value of it's own, that the heart and soul of a dedicated capable person obviously went into these keyboards. Summing up, I'm therefore quite happy to be (a small) part of it and the final result makes my desktop shine.

Software configuration: Non-US keyboard layouts, OS X

The preinstalled layout of the F77 isn't perfectly suitable for OS X users. They will thus want to flash a different layout to their keyboard. While veteran keyboard geeks might find the following lines ridiculous, they might help some novice Model F lovers.

Like all recent Model F keyboards mine came with QMK preinstalled. Consequently, it can be sent to bootloader mode by pressing the keys "left shift" + "b" + "right shift" simultaneously. The keyboard controller will not process any keypresses afterwards, but will accept new software flashed to it's memory. The keyboard will resume normal operation after a power disruption, as caused by unplugging it from the computer for a short period of time. Other methods described in the Model F documentation to enter bootloader mode are not required with QMK equipped keyboards, but can be used alternatively.

To be able to reconfigure the keyboard layout, new data will have to be transmitted to the keyboard controller. With QMK, a file is required containing the new layout as well as the firmware run by the controller. The easiest way to produce such a file is to follow the Model F documentation and visit the QMK web configurator. Follow https://www.modelfkeyboards.com/manual/ to find it's latest location. At the time of writing it is

http://35.164.28.200:5000/#/xwhatsit/br ... LAYOUT_all

F77 owners will want to change the keyboard to "xwhatsit/brand_new_model_f/f77/wcass" in the dropdown menu at the top of the page. To account for different layouts of the various Model F versions, a more specific layout can be uploaded to the configurator. For my Model F, I picked "F77_-_HHKB_2U_backspace_-_0-9.json" from the "QMK" directory of the "QMK-layout-files" directory that I had downloaded following Ellipse's documentation. The display then looked like this:

F77_-_HHKB_2U_backspace_-_0-9.png (20.93 KiB) Viewed 30151 times

OS X users will instantly notice the layout has to be altered to comply with Mac standards. Owners of keyboards coming with a wide right shift key like mine may also take note, that this layout, if flashed as is to the keyboard, will eliminate the ability to enter bootloader mode by pressing "left shift" + "b" + "right shift": "right shift" is assigned to an empty barrel that will hardly generate any signal!
 

Belegung.jpg (121.07 KiB) Viewed 30151 times

Fig. 5: new Model F as delivered. Blue arrows denote empty barrels to be furnished with stabilisers.

Model F owners who have been thoughtful enough to take a picture before installing the keys or are blessed with an exquisite memory you will be able to assign "N/A" to all positions, where their keyboard offers only empty barrels. I just wanted to adjust the Opt and Command keys and came up with the following layout:
 

LayoutMac.png (18.83 KiB) Viewed 30151 times

Fig. 6: layout with standard "command" key positions and "N/A" assigned to all positions, where my keyboard offers only stabilisers. "Right Ctrl" has been sacrificed in favour of "MO 1".

Novice keyboard programmers may recall, keycap legends are meant for the human user only. The keyboard will instead send a distinct keycode to the computer when being pressed. It's the computer's job to translate this keycode into the final character code. Thus there is no reason to be worried, because the layout displayed differs significantly from the keycap legends of a German keyboard, e.g.

Here I had to sacrifice "left Control" for "MO 1" to be able to switch layers. The missing "Esc" went to layer one. After everything looked fine, I "baked" and downloaded my personalised firmware.

To transfer the downloaded hex file to the keyboard's controller now a dedicated piece of software is needed. While the "Flip" software mentioned in the documentation isn't available for OS X, "QMK Toolbox" as also noted in the documentation, offers a great alternative — provided you're running a recent OS X version. Users of older OS X variants will notice, that their download wasn't that useful at all, since the software will resist to start. (The same goes for Pandrew's "utility" mentioned in the docs, which makes it even more important, to avoid flashing a layout without left shift, right shift or "b".)

Users who have already installed Mac Ports can easily add "dfu-programmer" by typing "sudo port install dfu-programmer" into the terminal. The following example has been produced last week under "Mavericks":

Code: Select all

Mac-mini:~ Kugelkopf$ sudo port install dfu-programmer
--->  Computing dependencies for dfu-programmer
--->  Fetching archive for dfu-programmer
--->  Attempting to fetch dfu-programmer-0.7.2_0.darwin_13.x86_64.tbz2 from http://packages.macports.org/dfu-programmer
--->  Attempting to fetch dfu-programmer-0.7.2_0.darwin_13.x86_64.tbz2.rmd160 from http://packages.macports.org/dfu-programmer
--->  Installing dfu-programmer @0.7.2_0
--->  Activating dfu-programmer @0.7.2_0
--->  Cleaning dfu-programmer
--->  Scanning binaries for linking errors
--->  No broken files found.                             
--->  No broken ports found.

Mac-mini:~ Kugelkopf$ dfu-programmer
dfu-programmer 0.7.2
https://github.com/dfu-programmer/dfu-programmer
Type 'dfu-programmer --help'    for a list of commands
     'dfu-programmer --targets' to list supported target devices

Communication between computer and the keyboard's MCU may be validated typing:

Code: Select all

Mac-mini:~ Kugelkopf$ sudo dfu-programmer atmega32u2 get manufacturer
Password:
dfu-programmer: no device present.

This is the expected message, if the keyboard isn't already in bootloader mode (or not connected to the computer). After having entered bootloader by "left Shift" + "b" + "right Shift" this message becomes:

Code: Select all

Mac-mini:~ Kugelkopf$ sudo dfu-programmer atmega32u2 get manufacturer
Manufacturer Code: 0x58 (88)

Mac-mini:~ Kugelkopf$ sudo dfu-programmer atmega32u2 erase
Checking memory from 0x0 to 0x6FFF...  Not blank at 0x1.
Erasing flash...  Success
Checking memory from 0x0 to 0x6FFF...  Empty.

Mac-mini:~ Kugelkopf$ sudo dfu-programmer atmega32u2 flash xwhatsit_brand_new_model_f_f77_wcass_default_fff892dmac.hex
Checking memory from 0x0 to 0x567F...  Empty.
0%                            100%  Programming 0x5680 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
0%                            100%  Reading 0x7000 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
Validating...  Success
0x5680 bytes written into 0x7000 bytes memory (77.23%).

Here I have flashed a new custom firmware generated as outlined above and called "xwhatsit_brand_new_model_f_f77_wcass_default_fff892dmac.hex". Note that the above "erase" command did not clear the EEPROM. Anybody wanting to do so should consult the Model F documentation and use the file "eraser.hex", e.g. Vaguely hoping, Ellipse's pristine original setup would not have populated the EEPROM with anything puzzling that better should be deleted, I haven't done so. Until now I have not detected any issues. But this may vary according the history of modifications made to the controller before, e.g.

Fundamental differences regarding how long older software should stay publicly available let me get rid of "brew" years ago. I can't tell whether "brew" would allow to install "dfu-programmer" on older OS X versions (before "Catalina", e.g.), but wouldn't be surprised, if not.

Users of "Catalina" or newer OS X versions in turn can simply download "QMK Toolbox" using the link given in the Model F manual. Looking inside "QMK Toolbox.app", they will spot "dfu-programmer" inside "Contents/Resources". "QMK Toolbox" is just a wrapper with a GUI that is using "dfu-programmer" (and some other utilities) internally.

Contrary to "dfu-programmer" Pandrew's utility offering an alternative way to enter bootloader without disassembling the keyboard not only doesn't run, but also fails to instal with Mac ports under "Mavericks".

Issues

The biggest issue and nearly a show stopper is the Model F's inability to choose among different options during OS X startup. It looks like keypresses are ignored during system startup and this prevents to select OS X (or other OS) variants, enter recovery or single user mode etc. Unfortunately, I'm one of those clients who don't embrace the idea to pay again (annually) for purchased Adobe products that work perfectly well. Some work requires a newer OS X version, though, which is why I'm forced to switch back and forth between different OS variants frequently. Mantaining a second keyboard solely to enter a single "Opt" keypress during system boot to enter the startup manager doesn't seem to be an acceptable solution in the long run.

Entering

Code: Select all

sudo nvram manufactering-enter-picker=true

served to alleviate the problem (under recent OS X variants one or two additional steps might be necessary to allow changing nvram settings, I've only tested Mavericks) as it brings up the startup manager each time the computer is rebooting, but doesn't help with recovery mode, etc.

I've found some hints in QMK forums, that timing details during startup might cause keystrokes to be ignored, but on the other hand the Model F was pretty quickly relaying input to the computer following a temporary disconnection. So I wonder, if anybody else has seeing this and if there is any existing or planned remedy at hand?

The second "issue" should be easy to solve: the veteran Model F layout contains a relatively small number of keys compared to more recent designs. Frequent vi users will immediately spot the lack of an "Esc" key with my custom layout. I was therefore delighted to learn, that, contrary to what I had read before, "Fn" ("MO 1" in the layout) worked quite well under OS X. Nevertheless, I'm considering splitting my 2.75U(?) right shift key, installing a 1.75U right shift, 1U Esc combination instead. Would the 1.75U shift key fit into the (presently empty) position to the left of the now active left shift barrel? Would it smoothly work next to another 1U key to the right?

[Muirium]

Going by your picture, your right Shift is the regular (egregiously long) 2.75u key. HHKB style right Shift requires different barrel placement: 1.75u then 1u; not 1u then 1.75u as you have. IBM did this to support JIS layout with the same barrel frame, so I gather, as HHKB style split Shift just wasn’t on their radar.

You could experiment with single unit caps instead, which would let you test drive the layout. But it’ll be ugly without the right caps, which need the right barrel spacing.

Good placement for the Fn key, by the way. I do something similar with my QMK powered Fs, including the OG Kishsaver whose layout looks like this:



Even HHKB imperialists like me can live with Fn under Right Shift if it gets us Model F.

Speaking of which: pretty sure both my Kishsaver and the AT can enter boot options on all USB Macs I’ve tried them on; even geriatric PowerPC! Don’t often need it myself, but I don’t recall any keyboard blocking it when required.

[pveentjer]

@Kugelkopf I'm also a VIM user. I waiting for my keys to arrive; but as soon as I have them, I'll probably reconfigure the caps-lock key as the esc (or ~`) key since caps-locks is one of the most useless keys on a keyboard.

[Kugelkopf]

Going by your picture, your right Shift is the regular (egregiously long) 2.75u key. HHKB style right Shift requires different barrel placement: 1.75u then 1u; not 1u then 1.75u as you have. IBM did this to support JIS layout with the same barrel frame, so I gather, as HHKB style split Shift just wasn’t on their radar.

You could experiment with single unit caps instead, which would let you test drive the layout. But it’ll be ugly without the right caps, which need the right barrel spacing.
...

These are exactly the details I was after. On Ellipse's "Custom Legend Keycaps" page I had seen a 1.75U shift keycap, but barrel positions are not mentioned, so thanks a lot for clarifying! I hereby admit that I really like the F's design, thus I'll probably do without uglifying keycap arrangements, though my ultra wide right shift key would be the perfect split candidate. I'm considering ordering the shorter space bar offered by Ellipse and use the unused barrel hidden under the normal space bar for "Esc", but will perform some vi testing before making a final decision. Delving into QMK or Vial and implement one or two tap dances might be an option, too. In fact, I'm considering to implement a "TeX" layer, where curly and square brackets, not to mention backslash are easily reachable. Obviously, Don Knuth hadn't German keyboards in mind, when he designed TeX's control sequences (most European layouts may perform equally poor, I guess): "\" is Opt + Shift + "7" here, which disrupts the flow of typing.

...
Speaking of which: pretty sure both my Kishsaver and the AT can enter boot options on all USB Macs I’ve tried them on; even geriatric PowerPC! Don’t often need it myself, but I don’t recall any keyboard blocking it when required.

Your remark is very interesting and caused me to perform a few more tests. Here are the results:

2.5GHz Mac Mini (late 2012), SSD: 100% failure
2.4GHz Mac Mini (mid 2020), HDD: 33% failure (waiting until Mr. Job's guitar just had died away before starting to type resulted in nearly 100% success)
400MHz G4 (mid 2000): 100% failure.

So running our latest Mac with

Code: Select all

manufactering-enter-picker=true

seems to be the only workaround for us, to keep using the F. I had read about similar problems due to slow QMK startup (cf. https://github.com/qmk/qmk_firmware/issues/1149, e.g.) and was wondering, when the signal calibration is done in the Model F's QMK variant. Maybe, whatsit's original firmware could be an option, should our issue turn out to be reproducible with others and no working solution with Model F's QMK firmware become available. On the other hand, I like the present QMK firmware with more than just one signal threshold. So if our issue is confirmed, I would prefer to run a corrected version of the present firmware. Otherwise it would be interesting to investigate, what is special with our Macs. I'm not familiar with Win or *nix boot options, but if they allow to enter keystrokes shortly after reestablishing power to the keyboard, they might be affected as well, should there really be any timing issue.

[BuGless]

I'm considering ordering the shorter space bar offered by Ellipse and use the unused barrel hidden under the normal space bar for "Esc", but will perform some vi testing before making a final decision. Delving into QMK or Vial and implement one or two tap dances might be an option, too.

You might want to look at my setup (already slightly outdated, because I tweak it every few days, as I discover that some things are (im)practical in daily use) as described in viewtopic.php?p=504943#p504943 for ideas.
As an avid vi user, it is geared towards vi use.

[nulani]

My second keyboard arrived today along with the printed keycaps I originally ordered with the first - took advantage of the offer of having the keyboard shipped early with blank or without keycaps back in 2020.

Wasn't too sure about the beige colour, but now that I've seen it in person, I quite like it. The red and blue ones I've seen pictures of do look gorgeous though.

Did have trouble with a couple of keys where the springs had come lose in transit - tab and L - and I expect "V" is a bit loose to as I'm having trouble with it currently while typing this. Managed to fix Tab by wrestling with the spring a little, no such luck with L. Ended up disassembling the board and replacing the flipper with one of the spares as I had absolutely no luck with reinserting the spring. That sorted the problem. Might have to repeat the procedure with "v" unless I can get it behave properly the same way I did with Tab. Or get better at wrestling with the springs without disassembly.

Gap between the lower and upper part of the case is quite a bit more pronounced on the new one than the old gray one - the portion below the spacebar bends a little. Not something that is noticeable in the day to day.

PXL_20220630_135218155.MP.jpg (297.19 KiB) Viewed 29747 times

[Ellipse]

nulani the 12 o'clock angle of reinstalling the spring and using the tweezers several times as shown in the quality secrets video are two very important requirements - in my experience I have never had to take apart any boards to replace a bad spring, unless the flipper was physically stuck and could not be moved into position with tweezers. Also some folks forget the last step - switch the spring with another installed spring, or replace the spring with a spare.

Regarding the gap in the cases, each case part comes out of the die cast molds slightly different and the factory uses a rubber mallet to lower the top case part that is a little too high (end users can do this too, carefully).

[TerminalJunkie]

Keyboard blacksmithing!

[yac]

My keyboards are en route, extremely excited but a lot to catch up on. I for one feel it was clearly communicated that it would not be a turn-key product, and that some work (and hence, learning) was needed in order to have a flawless experience. Hopefully the number of dissatisfied customers will be low, and they'll have no problems selling their keyboards once the project concludes if they so choose.

I have an original XT Model F and it also has had an issue with a spring, that was fixed in about the same way as you fix Ellipse's boards. IBM also had the advantage that they were already producing for the military,

My plan is to compare the new springs and flippers with the IBM ones. I don't expect to detect a real difference with the keycaps, mostly interested in the feel when i type on it, and somewhat interested in the sound. Did anyone move springs and flippers over from old Model F keyboards and if so what were your experiences?

Also i'm looking for an experienced shop to cryo treat the springs, ultra slow ramp down and a really long soak time, so looking for recommendations there as well.

[Kugelkopf]

So following Flash New Model F with VIAL firmware I have installed a Vial compatible firmware meanwhile. The main reason was to give tap dances a try (note the correct representation of the ISO enter key compared to my earlier post with QMK, that needed several "N/A" assignments):
 

Bildschirmfoto-2022-06-30-um-21.41.42.png (18.27 KiB) Viewed 29580 times

I have installed TD(0) which accesses "Esc" by tapping twice and TD(1) to send the clumsy "Shift" + "Alt" + "7" combination that produces "\" with German (and probably other languages using more than 26 latin characters) layouts. I choose to seize "j" for this purpose, which has the advantages of easy typing while the standard result, the letter "j" is sparsely used. I'm not aware of any text requiring "jj". I'm going to test this layout during the next weeks.

However, using a tap dance to facilitate typing '\' is only a first shot at improvements useful for "TeX" users with non-English layouts. It would be nice, if curly and even square braces could be accessed without having to reach out for "Opt/Alt". This could be achieved with a switchable layer, but due to memory space limitations Vial only offers three layers with new Model F's Atmels. Without a solenoid layer 2 only contains three different "Reset" keys, that could be removed, should combos work. In fact, I liked the original QMK's "LShift" + "RShift" + "b" combination to enter bootloader mode. I didn't succeed, however, in reestablishing this combination using Vial so far. Setting up the combination in Vial's "Combo" tab worked fine, but seemed to just generate an ordinary chip reset without entering bootmode.

If I believe Vial, the combo had sent the same key code (0x5C00) as the "r" key defined on layer 2. Contrary to the former, the latter does enter bootloader mode, though. Hence I wonder, if combos can be used at all to enter bootloader mode running Vial firmware?

BuGless's method to activate function keys sounds interesting, too, and could free up layer 1, but it would still be interesting to learn, what prevents the F's controller to enter bootloader mode when receiving a "reset" issued using a combo.

[Bjerrk]

My plan is to compare the new springs and flippers with the IBM ones. I don't expect to detect a real difference with the keycaps, mostly interested in the feel when i type on it, and somewhat interested in the sound. Did anyone move springs and flippers over from old Model F keyboards and if so what were your experiences?

I didn't move any springs over -- and for one reason: they're very different in terms of weighting. You can even feel it when handling individual springs outside the keyboard: the Ellipse ones definitely seem to have a lower spring constant. The Ellipse Model F has quite a low actuation force!

The flippers, on the other hand, I've found to be quite interchangeable. They do not look completely identical, but I've swapped some Ellipse flippers into a Model F XT, and I can't even tell which keys have which flippers when typing on it.

[BuccoBruce2]

I followed the manual and don't see anything about rollover besides the pre-programed command for it, as a troubleshooting step I imported F77_-_ANSI-ISO_-_PrintScr.json with QMK configurator and complied it without making any modifications and n key rollover still doesn't work, n key rollover is working fine with the precompiled QMK firmwares by the way.

Just to double-check, after flashing the hex file you got from QMK Configurator, you tried LShift+RShift+N to enable NKRO first before testing to see if NKRO was working? (It is off by default.)

If yes, it sounds to me like the rules.mk file(s) on the pandrew beta QMK Configurator site does not include "NKRO_ENABLE = yes". Unfortunately, this is seemingly impossible for a regular user to verify as the web QMK Configurator doesn't expose any of the source files from the build tree to you. Only person who could check & confirm this would be whoever is running that server (pandrew?). Doubly unfortunate is that if this is in fact the case, there is also nothing that a regular user can do about it short of petitioning the server admin to change this.

It's also possible, though, that NKRO_ENABLE is set to yes, but that COMMAND_ENABLE is set to no, which would disable the built-in set of "magic keys" (the set of shortcuts that are triggered when you hold down both shift keys). If so, that would explain why LShift+RShift+N is not effective. What you could do to both test this as well as work around it it is to add a "Toggle NKRO" key to your keymap before compiling (in QMK Configurator this is listed under Keyboard Settings tab > "Togg NKRO"). I might suggest putting it on the N key under layer 2. Assuming the default layer selectors of Fn (for layer 1) and Space (for layer 2), this would allow you to toggle NKRO on/off via Fn+Space+N.

I realized some time ago that I myself did not have NKRO enabled on my Vial firmware builds that I've posted here in the past. I have since fixed that for myself but haven't posted an updated version. If you're at all interested in giving it a try, I'll package it up for you.

Just got my F77. Am I missing something here or has this not changed yet? No matter what I do, I cannot get NKRO working with my custom keyboard layout. I tried using both "LAYOUT_all" with the appropriate KC_NO mappings as well as "LAYOUT_iso_hhkb_split_shift_split_backspace" which best matches my keyboard. I tried mapping the "Togg NKRO" function as well as the separate On/Off ones to unused layer 2 keys, they do nothing. With or without those keys mapped, the standard LShift+RShift+N MAGIC key combination does not work either. LShift+RShift+N worked out of the box. I am using the correct direct link to the "F77 specific" configurator.

I clicked the "Download Source" button and "COMMAND_ENABLE" is set to on for the "main" rules.mk - so the MAGIC keys should still work unless it is making a layout specific rules.mk without it. The Download Source button seems to return a "base" source tree that has my layout in the root directory as a .json file - before anything has been compiled from it. There's a download keymap.c button, but that returns a .json file as well with this instruction:

Code: Select all

This file is a configurator export. You can compile it directly inside QMK using the command `bin/qmk compile xwhatsit-brand_new_model_f-f77-wcass-bucc.json

I don't need any handholding for setting up a build environment, I've just never compiled QMK myself before.