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

[NathanA]

I've continued to play around with Vial-enabled builds, trying to find a combination of features that will run stable without disabling/sacrificing too many of them.

At this point, I'm guessing there is either some kind of RAM-contention issue or RAM space violation issue (one part of QMK scribbling over memory space belonging to another part). ATmega32U2 only has 1KiB of SRAM according to the spec sheet, and I have to believe that this microprocessor doesn't have any memory protection features, so neither would surprise me.

There seem to be some strange interactions among the following features:

• Extra Keys
• Mouse Keys
• Tap Dance
• Combos

Depending on which features I keep enabled in the build, I see the following behavior:

• With all 4 enabled, the keyboard only registers a fraction of the keystrokes, and QMK only lasts for a few seconds before crashing out completely (dropping off of the USB bus)
• If I disable Mouse Keys but keep the other 3, the firmware never crashes, but hardly registers ANY keypresses. (To get back to bootloader without opening up the keyboard, I had to use Vial to set ALL of the keys on layer 0 to 'RESET' and then repeatedly mash down randomly on a bunch of keys for several seconds!)
• If I disable Extra Keys but keep the other 3, I get reliable keystroke detection, but after a few minutes of typing, it stops sending regular scancodes and only the KC_APP key continues to do anything until I unplug/replug (?? is this because the main keyboard USB endpoint is perhaps dropping off, but maybe the Menu key is being transmitted as Mouse Right Click or something?)
• If I disable BOTH Extra Keys AND Mouse Keys, then keyboard is perfectly stable and usable
• Likewise, if I keep them both enabled but disable EITHER Tap Dance OR Combos (or both), the keyboard is also perfectly stable

Super bizarre.

I don't have a JTAG debugger (or its equivalent) for the AVR, and to make matters more frustrating, since the 32U2 only supports a total of 4 USB endpoints not counting the master/control endpoint, I can't enable the QMK Debug Console while I also have either Mouse Keys or Extra Keys enabled. (Well, I probably *could*, if I could disable the Raw HID, but the Raw HID endpoints are required for VIA/Vial support.) Looking at the AVR drivers for LUFA, it appears the 32U4 supports 6 endpoints, and I gladly would have paid a few extra $$ for my 'board's controller PCBs to have more capable microcontrollers on them, so this strikes me as an annoying limitation (especially when it comes to developing & debugging software) that likely could have been avoided.

Perhaps it would be best to start a separate thread to discuss Model F controller firmware hacking?

[Muirium]

Perhaps it would be best to start a separate thread to discuss Model F controller firmware hacking?

Yes it would! You seen the page number here already?

For what it’s worth: I went back to Pandrew’s QMK without any VIA/VIAL after bashing into similar flakiness on my OG Kishsaver. Seeing as I’m deep into Karabiner now, advanced functions like you describe are better for me on the host rather than the keyboard. Helps I’ve just one computer I’m always using now, of course, instead of needing to replicate all these tricks across many very different keyboards. That wee M1 changed everything.

[NathanA]

Perhaps it would be best to start a separate thread to discuss Model F controller firmware hacking?

Yes it would! You seen the page number here already?

I take your point, but that also might be an argument for not doing so, since this thread is largely where all of the attention is focused.

For what it’s worth: I went back to Pandrew’s QMK without any VIA/VIAL after bashing into similar flakiness on my OG Kishsaver.

Interesting...I haven't noticed any flakiness with VIA builds, even ones I have made myself.

I'm honestly starting to think that it might be a Vial-unique issue/bug. It's also possible, though, that it's a bug that either only applies to the ATmega32U2, or only readily manifests itself on that MCU. Perhaps one way of "proving" this would be to make a Vial build targeted at another keyboard with a (non-xwhatsit) controller built around the 32U2 and see if the same things happen, but from a brief glance there don't appear to be many keyboards that fit this bill. The 32U2 appears to be popular when it comes to macropads and the like, but not so much on full-blown keyboards (likely due to fewer GPIO lines compared to other MCUs).

And, yeah, Karabiner is cool and all, but host-controlled remapping can only take you so far, even if you are limiting your use of your keyboard to a single computer. In order to be able to accomplish arbitrary key remapping and function layers and such, the external keyboard has to send scancodes for every key.

[Muirium]

Fair points. In turn:

I really dislike VIA the app: the size of the damn thing and its general-purpose design that makes it fiddlier than QMK's own tools. My brief experiments with it were impatient, and I didn't give it a fair shot. VIAL was a similar story. I was mostly having trouble with my Kishsaver's beeper and Beamspring's solenoid firing when they shouldn't. My various attempts at fixing this (with help from a very patient and kind Darkcruix) all failed in various ways, some of them crashing the keyboards; which your own description brought back to mind. So I reverted to Pandrew's QMK.

I thought for a moment that Hasu's HHKB controller is also 32u2, but I checked and it's not. You may be right that it's only really used by these Xwhatsit (and derived) capsense controllers. Speaking of Xwhatsit: I used his firmware for many years, and never had any stability problems like you describe. His editor GUI crashed a lot, mind! And this 3276 was just much too flaky with a single threshold for extended use. But the firmware itself was a rock, and handled a lot of macros on my Kishy with aplomb. Get what you're saying, though, about the limited resources of 32u2 itself.

As for Karabiner: you're quite correct you're limited to working with keys present on the keyboards themselves. I'm fundamentally a 60% layout guy, so I'm used to working with a constrained palette. But if I had an F122, and devised functions for all those extra function keys, I'd be itching to map them somehow on my little boards with lots of finger gymnastics.

[NathanA]

I thought for a moment that Hasu's HHKB controller is also 32u2, but I checked and it's not. You may be right that it's only really used by these Xwhatsit (and derived) capsense controllers.

The "best" option I've found so far are the various replacement controllers from Bathroom Epiphanies for various Costar-manufactured boards (Filco, Cooler Master, et al.). But not only are those no longer being manufactured with very few unsold ones still on the market, but virtually all of the keyboards targeted by them are no longer being manufactured, either.

[NathanA]

I finally have a working build of Vial firmware for my F77!

It does appear that I was running into some sort of software bug. Through trial and error testing, I determined that building against a checkout of the Vial source tree that pre-dates when they did their last quarterly merge with QMK master (on September 12) results in a working firmware. There was a lot that changed, so it's a huge commit, and I haven't taken the time to try to narrow down the culprit yet.

But since the last public update of the Vial GUI (v0.4.1) was back in July, and since that was well before the regression, I figured it would make sense to do a build based on the state of the Vial QMK fork at that point in time. So far, it seems to be working great! So I'm attaching my F77 Vial firmware here for anyone else who might want to give it a spin, as well as provide build instructions.

So far, I'm enjoying Vial a lot more than VIA. It has a bunch of great benefits compared to VIA: besides the lighter-weight GUI utility, it is also much more feature-full. If used with this firmware, you don't have to sideload a JSON..."it just works". It also allows you to configure things like Tap Dance and Combos directly from the GUI itself without recompiling and reflashing, which you can't do with VIA. If anybody else ends up trying this out, I'd love to hear your thoughts and compare notes (though at this point I've barely scratched the surface myself...so far I've just made sure the basics work, reconfigured my layout, etc.).

Some notes:

• I have only compiled one firmware image, targeting my F77 with HHKB-style split right shift and otherwise standard ANSI layout. But I'm attaching the unified diff of all my changes to the QMK/Vial/pandrew sources (they're really quite minimal), and it should hopefully be fairly obvious how to apply the same changes to the source tree of whichever other board variants you might wish to target. Feel free to drop questions for me here if this assumption on my part proves invalid. Also keep in mind that I only own F77s, so I can only advise when it comes to other board models, not actually test.
  `
• Since early April when Ellipse made his most recent QMK builds, there has been additional progress both with pandrew's private QMK fork as well as on the haptic/solenoid driver front. However, as I've said before, I don't have a solenoid, so I have no way to test the difference in performance or experience (if any) between the state of the code as it existed in April, and as it currently stands today. So for my build, instead of using the latest-and-greatest, I made the decision to use the exact same code from pandrew (for the xwhatsit controller driver/implementation) and darkcruix (for the solenoid changes) as Ellipse used when he compiled his firmware. That way, there should be few-to-no surprises for people.
  `
• I happened to notice that pandrew's QMK port piggybacks on top of Zenith's USB Vendor ID. It looks like this in turn was just inherited / blindly carried forward from xwhatsit's original ibm_capsense firmware. Why xwhatsit chose to use that Vendor ID, no clue...maybe he figured that they're a defunct company so what harm could it do. Anyway, I would advocate that we use the USB Vendor ID from pid.codes who gives out Product IDs to open source hardware projects. We will need to follow their instructions for requesting a USB PID from them. I haven't started the process, and it might even be best if I wasn't the point of contact for this (? though if people think it would be helpful for me to spearhead this, I can't promise anything at this point but I'll see what I can do). But for this firmware build, I've gone ahead and changed over to using the pid.codes VID and picked an unused PID.
  `
• I built a special copy of pandrew's utility that works with this firmware! I will attach it to this post. Note that this copy will only work with this firmware (not with the QMK firmwares built by Ellipse, and not with the VIA firmwares none of which work with any version of pandrew's utility anyway AFAICT). And I only compiled it for Windows. But the unified diff I'm attaching also contains the necessary patch to the pandrew util source should somebody want to build Mac or Linux binaries.
  `
• ...that said, the Vial GUI has an option built right into it that allows you to kick the keyboard controller over into bootloader/DFU mode. So if that's all that you use the pandrew utility for, then you don't really need it anymore. (Though it's handy for other things.)
  `
• Vial has a "secure unlock" mode that prevents you from making changes to your keyboard from the PC host until you have pressed a specific combination of keys first to "authenticate" your intention; this is briefly described here. Note, however, that I compiled my Vial firmware with the security feature disabled. If you actually want this feature, then you'll have to build your own.
  `
• All Vial firmwares work with / are backwards-compatible with VIA itself, and this one is no exception. But assuming anybody actually cares to use VIA with this Vial firmware ("but why?"), since the USB VID & PID have changed, the original JSON from darkcruix that Ellipse distributed will not work here. You'll have to use this modified one that I've attached to this post instead.
  `
• There isn't enough EEPROM space on the 32U2 for all of the features + the default # of keymap layers (4) + the default # of tap dance and combos entries (8/ea), so I fixed them at 3 layers and 4 each for tap dance and combos. But after more testing, it looks like there is at least some remaining headroom to expand the count of either one (layers) or the other (TDs & combos), should you desire. Just edit the appropriate lines in config.h before compiling.

In summary, I believe that this is a fairly no-compromises firmware:

• ...it works with Vial (and supports all of its enhanced features vs. VIA)
• ...it also still works with VIA, if you so choose
• ...it is compatible with (a special build of) pandrew's utility
• ...it contains the exact same solenoid implementation and default settings/tweaks for it as Ellipse's

There's a 7zip archive attached with all the bits (split into two, because of forum file size attachment limits, but not named correctly ALSO because of forum file EXTENSION limits...so rename *.001.7z > *.7z.001, same for 002, etc.). This is what's included:

• newf77-vial-0p4p1-ansi_hhkb_splitshift_numeric.hex (the F77 Vial firmware binary itself)
• newf77-via-vial.json (VIA JSON keyboard definition)
• pandrew-util-for-vial.exe (pandrew utility compatible with Vial firmware)
• newf77-vial-0p4p1-patches.diff (unified diff patch against vial-qmk + pandrew sources)

Here are the command-by-command build instructions...if you follow this precisely, you should end up with a firmware image 100% identical to what is attached to this post for download. To start with, make sure that you have a working QMK build environment; if you have successfully built QMK in the past (e.g. by following Ellipse's instructions) then you should be good to go. Just make sure to clear your existing 'qmk_firmware' directory out of your home directory first (move/rename/delete it) before proceeding.

Code: Select all

cd ~
wget "https://deskthority.net/download/file.php?id=71432" -O ~/newf77-vial-package.7z.001
wget "https://deskthority.net/download/file.php?id=71433" -O ~/newf77-vial-package.7z.002
7z x ~/newf77-vial-package.7z.001 -o`echo ~`
wget https://www.modelfkeyboards.com/wp-content/uploads/2020/07/QMK-layout-files.zip -O ~/QMK-layout-files.zip
unzip ~/QMK-layout-files.zip zF77_-_HHKB_Split_Shift,_everything_else_ANSI_-_0-9.json -d ~
git clone http://purdea.ro/qmk_firmware ~/pandrew-qmk
git -C ~/pandrew-qmk reset --hard ecc46a7
qmk clone vial-kb/vial-qmk -b vial
git -C ~/qmk_firmware reset --hard ff5d361
git -C ~/qmk_firmware/lib/chibios reset --hard ffe54d6
git -C ~/qmk_firmware/lib/chibios-contrib reset --hard 61baa6b
rm -r ~/qmk_firmware/lib/chibios-contrib/ext/mcux-sdk
git -C ~/qmk_firmware/lib/googletest reset --hard ec44c6c
git -C ~/qmk_firmware/lib/lufa reset --hard ce10f76
cp -a ~/pandrew-qmk/keyboards/xwhatsit ~/qmk_firmware/keyboards
cd ~/qmk_firmware
patch -p1 < ~/newf77-vial-package/newf77-vial-0p4p1-patches.diff
qmk compile ~/zF77_-_HHKB_Split_Shift,_everything_else_ANSI_-_0-9.json
mv ~/qmk_firmware/xwhatsit_brand_new_model_f_f77_wcass_default_fff892d.hex ~/qmk_firmware/newf77-vial-0p4p1-ansi_hhkb_splitshift_numeric.hex

Enjoy!

EDIT: ...oh yeah, and duh, probably should've mentioned that you also need to go and download the Vial GUI to configure the darn thing after you flash it, obvs.

[highrolller]

Hey everyone, I think I've bricked my model f at with xwhatsit controller. I tried flashing the new beta qmk firmware with qmk toolkit but now the keyboard isn't registering any keys and my pc isn't detecting it... Is there any way I can fix it? Thank you!

[NathanA]

Hey everyone, I think I've bricked my model f at with xwhatsit controller. I tried flashing the new beta qmk firmware with qmk toolkit but now the keyboard isn't registering any keys and my pc isn't detecting it... Is there any way I can fix it? Thank you!

If you don't have a "New Model F" from modelfkeyboards.com, then technically this is the wrong thread. This isn't a general xwhatsit board support thread.

Anyway, if you flash non-working new firmware to your xwhatsit controller, you can kick it into bootloader/DFU mode manually by bridging the two conductive pads marked "PROG" (with a piece of wire, paperclip, etc.) while you plug it into the USB port, and then stop bridging them right after you plug in. QMK Toolbox should detect it and let you flash a different firmware to it at that point. If it doesn't, then you probably just aren't getting the timing right...you shouldn't keep the two pads bridged together for very long after you supply power.

[highrolller]

Hey everyone, I think I've bricked my model f at with xwhatsit controller. I tried flashing the new beta qmk firmware with qmk toolkit but now the keyboard isn't registering any keys and my pc isn't detecting it... Is there any way I can fix it? Thank you!

If you don't have a "New Model F" from modelfkeyboards.com, then technically this is the wrong thread. This isn't a general xwhatsit board support thread.

Anyway, if you flash non-working new firmware to your xwhatsit controller, you can kick it into bootloader/DFU mode manually by bridging the two conductive pads marked "PROG" (with a piece of wire, paperclip, etc.) while you plug it into the USB port, and then stop bridging them right after you plug in. QMK Toolbox should detect it and let you flash a different firmware to it at that point. If it doesn't, then you probably just aren't getting the timing right...you shouldn't keep the two pads bridged together for very long after you supply power.

My apologies for posting it here instead of in the other thread. I really appreciate your help so thank you!

[knight of zero]

My work load really shot up hugely & I got no chance to do anything with this.

Has anyone found a quick-release or a plug that can be used with this combination
of solenoid plus controller to be able to plug in and unplug quickly & easily?

I'm looking to get some solenoids for my compacts.

Is there a subforum or a site showing just the solenoids and
how folks have mounted them & run the cables out of the compact case?

[Ellipse]

I finally have a working build of Vial firmware for my F77!

It does appear that I was running into some sort of software bug. Through trial and error testing, I determined that building against a checkout of the Vial source tree that pre-dates when they did their last quarterly merge with QMK master (on September 12) results in a working firmware. There was a lot that changed, so it's a huge commit, and I haven't taken the time to try to narrow down the culprit yet.

But since the last public update of the Vial GUI (v0.4.1) was back in July, and since that was well before the regression, I figured it would make sense to do a build based on the state of the Vial QMK fork at that point in time. So far, it seems to be working great! So I'm attaching my F77 Vial firmware here for anyone else who might want to give it a spin, as well as provide build instructions.

So far, I'm enjoying Vial a lot more than VIA. It has a bunch of great benefits compared to VIA: besides the lighter-weight GUI utility, it is also much more feature-full. If used with this firmware, you don't have to sideload a JSON..."it just works". It also allows you to configure things like Tap Dance and Combos directly from the GUI itself without recompiling and reflashing, which you can't do with VIA. If anybody else ends up trying this out, I'd love to hear your thoughts and compare notes (though at this point I've barely scratched the surface myself...so far I've just made sure the basics work, reconfigured my layout, etc.).

Some notes:

• I have only compiled one firmware image, targeting my F77 with HHKB-style split right shift and otherwise standard ANSI layout. But I'm attaching the unified diff of all my changes to the QMK/Vial/pandrew sources (they're really quite minimal), and it should hopefully be fairly obvious how to apply the same changes to the source tree of whichever other board variants you might wish to target. Feel free to drop questions for me here if this assumption on my part proves invalid. Also keep in mind that I only own F77s, so I can only advise when it comes to other board models, not actually test.
  `
• Since early April when Ellipse made his most recent QMK builds, there has been additional progress both with pandrew's private QMK fork as well as on the haptic/solenoid driver front. However, as I've said before, I don't have a solenoid, so I have no way to test the difference in performance or experience (if any) between the state of the code as it existed in April, and as it currently stands today. So for my build, instead of using the latest-and-greatest, I made the decision to use the exact same code from pandrew (for the xwhatsit controller driver/implementation) and darkcruix (for the solenoid changes) as Ellipse used when he compiled his firmware. That way, there should be few-to-no surprises for people.
  `
• I happened to notice that pandrew's QMK port piggybacks on top of Zenith's USB Vendor ID. It looks like this in turn was just inherited / blindly carried forward from xwhatsit's original ibm_capsense firmware. Why xwhatsit chose to use that Vendor ID, no clue...maybe he figured that they're a defunct company so what harm could it do. Anyway, I would advocate that we use the USB Vendor ID from pid.codes who gives out Product IDs to open source hardware projects. We will need to follow their instructions for requesting a USB PID from them. I haven't started the process, and it might even be best if I wasn't the point of contact for this (? though if people think it would be helpful for me to spearhead this, I can't promise anything at this point but I'll see what I can do). But for this firmware build, I've gone ahead and changed over to using the pid.codes VID and picked an unused PID.
  `
• I built a special copy of pandrew's utility that works with this firmware! I will attach it to this post. Note that this copy will only work with this firmware (not with the QMK firmwares built by Ellipse, and not with the VIA firmwares none of which work with any version of pandrew's utility anyway AFAICT). And I only compiled it for Windows. But the unified diff I'm attaching also contains the necessary patch to the pandrew util source should somebody want to build Mac or Linux binaries.
  `
• ...that said, the Vial GUI has an option built right into it that allows you to kick the keyboard controller over into bootloader/DFU mode. So if that's all that you use the pandrew utility for, then you don't really need it anymore. (Though it's handy for other things.)
  `
• Vial has a "secure unlock" mode that prevents you from making changes to your keyboard from the PC host until you have pressed a specific combination of keys first to "authenticate" your intention; this is briefly described here. Note, however, that I compiled my Vial firmware with the security feature disabled. If you actually want this feature, then you'll have to build your own.
  `
• All Vial firmwares work with / are backwards-compatible with VIA itself, and this one is no exception. But assuming anybody actually cares to use VIA with this Vial firmware ("but why?"), since the USB VID & PID have changed, the original JSON from darkcruix that Ellipse distributed will not work here. You'll have to use this modified one that I've attached to this post instead.
  `
• There isn't enough EEPROM space on the 32U2 for all of the features + the default # of keymap layers (4) + the default # of tap dance and combos entries (8/ea), so I fixed them at 3 layers and 4 each for tap dance and combos. But after more testing, it looks like there is at least some remaining headroom to expand the count of either one (layers) or the other (TDs & combos), should you desire. Just edit the appropriate lines in config.h before compiling.

In summary, I believe that this is a fairly no-compromises firmware:

• ...it works with Vial (and supports all of its enhanced features vs. VIA)
• ...it also still works with VIA, if you so choose
• ...it is compatible with (a special build of) pandrew's utility
• ...it contains the exact same solenoid implementation and default settings/tweaks for it as Ellipse's

There's a 7zip archive attached with all the bits (split into two, because of forum file size attachment limits, but not named correctly ALSO because of forum file EXTENSION limits...so rename *.001.7z > *.7z.001, same for 002, etc.). This is what's included:

• newf77-vial-0p4p1-ansi_hhkb_splitshift_numeric.hex (the F77 Vial firmware binary itself)
• newf77-via-vial.json (VIA JSON keyboard definition)
• pandrew-util-for-vial.exe (pandrew utility compatible with Vial firmware)
• newf77-vial-0p4p1-patches.diff (unified diff patch against vial-qmk + pandrew sources)

Here are the command-by-command build instructions...if you follow this precisely, you should end up with a firmware image 100% identical to what is attached to this post for download. To start with, make sure that you have a working QMK build environment; if you have successfully built QMK in the past (e.g. by following Ellipse's instructions) then you should be good to go. Just make sure to clear your existing 'qmk_firmware' directory out of your home directory first (move/rename/delete it) before proceeding.

Code: Select all

cd ~
wget "https://deskthority.net/download/file.php?id=71432" -O ~/newf77-vial-package.7z.001
wget "https://deskthority.net/download/file.php?id=71433" -O ~/newf77-vial-package.7z.002
7z x ~/newf77-vial-package.7z.001 -o`echo ~`
wget https://www.modelfkeyboards.com/wp-content/uploads/2020/07/QMK-layout-files.zip -O ~/QMK-layout-files.zip
unzip ~/QMK-layout-files.zip zF77_-_HHKB_Split_Shift,_everything_else_ANSI_-_0-9.json -d ~
git clone http://purdea.ro/qmk_firmware ~/pandrew-qmk
git -C ~/pandrew-qmk reset --hard ecc46a7
qmk clone vial-kb/vial-qmk -b vial
git -C ~/qmk_firmware reset --hard ff5d361
git -C ~/qmk_firmware/lib/chibios reset --hard ffe54d6
git -C ~/qmk_firmware/lib/chibios-contrib reset --hard 61baa6b
rm -r ~/qmk_firmware/lib/chibios-contrib/ext/mcux-sdk
git -C ~/qmk_firmware/lib/googletest reset --hard ec44c6c
git -C ~/qmk_firmware/lib/lufa reset --hard ce10f76
cp -a ~/pandrew-qmk/keyboards/xwhatsit ~/qmk_firmware/keyboards
cd ~/qmk_firmware
patch -p1 < ~/newf77-vial-package/newf77-vial-0p4p1-patches.diff
qmk compile ~/zF77_-_HHKB_Split_Shift,_everything_else_ANSI_-_0-9.json
mv ~/qmk_firmware/xwhatsit_brand_new_model_f_f77_wcass_default_fff892d.hex ~/qmk_firmware/newf77-vial-0p4p1-ansi_hhkb_splitshift_numeric.hex

Enjoy!

EDIT: ...oh yeah, and duh, probably should've mentioned that you also need to go and download the Vial GUI to configure the darn thing after you flash it, obvs.

Thanks NathanA! I have updated the manual on the project web site to reference your post.

[Ellipse]

New announcement: additional colors for the Ultra Compact Cases: Off-White/Beige, Industrial Gray, and True Red

The factory is making a small batch of these colors. The project web site will be updated with these color options over the coming days. Please email/PM me if you'd like to switch out the case for an existing order of yours that has not yet shipped. These will be premium color offerings of about the same upgrade cost as the other premium color options offered ($75).

[vyquad]

What kind of paint does the industrial grey paint use? (and primer and clearcoat if any) im looking to paint my model f xt and want it to match the reproduction paint (minus the powder coating)

[daphnis]

How is the powder coating done?

[Arkku]

re. firmware, if someone is feeling really adventurous, I ported pandrew's QMK firmware to my USB keyboard engine, and it compiles, but since I haven't received my keyboard(s) yet, I'm not able to test it in practice. However, it is obviously open source under the GPL license, and published on GitHub here: https://github.com/arkku/aakbd

So, if anyone wants to give it a go, it would be really interesting to know whether it works. Admittedly there are not a whole lot of benefits of this firmware compared to QMK, except if you happen to be the kind of person who will rather write a couple of lines of C code to customise their keyboard than use a configurator tool. (I will of course do whatever it takes to make this actually working with the keyboards once I receive them. My USB keyboard engine itself does work; I'm using it with a DIY PS/2 to USB converter and an ErgoDox keyboard that I ported from QMK as a proof of concept.)

To compile the firmware, the easiest way is to make file called local.mk and put contents such as:

Code: Select all

DEVICE = modelf77
ISO_LAYOUT = 1
SPLIT_BACKSPACE = 0
SPLIT_RIGHT_SHIFT = 1

Then run "make" and it should hopefully produce a modelf77.hex (or modelf62.hex) that can be flashed. Customisation of the layout happens in "layers.c" and "macros.c", both of which have a template provided with some examples. The basic syntax for remapping is simple, just something like:

Code: Select all

DEFINE_LAYER(1) {
    [KEY(CAPS_LOCK)] = CMD_OR(ESC), // Cmd when held down, or Esc when tapped
};

(The files modelf77/keymap.c and model62/keymap.c contain the base keymaps, so customisation only needs to specify the differences to those. The left-side key names are always referencing those base keymaps, regardless of any other active layers or remappings.)

[NathanA]

re. firmware, if someone is feeling really adventurous, I ported pandrew's QMK firmware to my USB keyboard engine, and it compiles, but since I haven't received my keyboard(s) yet, I'm not able to test it in practice. However, it is obviously open source under the GPL license, and published on GitHub here: https://github.com/arkku/aakbd

So, if anyone wants to give it a go, it would be really interesting to know whether it works.

Nifty!

Unfortunately, I wish I could say it works, but it doesn't yet...or at least it doesn't seem to work for me. Got it to build, but then the AVR just seems to go into a reboot loop of some kind: Windows sees it, but shows the device with error "device cannot start (code 10)", and it just keeps repeatedly falling off the USB bus and coming back every few seconds.

pandrew utility (original version that looks for USB VID 0x0481 and PID 0x0002) doesn't pick up on it, either, so had to crack the keyboard open again to kick it back into DFU mode to resuscitate it. And yes, I did add the additional DEVICE_FLAGS #defines to the makefile & confirmed that the resulting hex file was larger after doing so. (With all of the flashing I've been doing, kinda wishing the PROG pads had a switch or a set of jumper pins wired up to it right about now...)

Couple of small issues with the build, too:

1. I have F77 with ANSI + split right shift layout. Compile bombed out with incorrect # of parameters supplied to macro due to call to LAYOUT_ansi_hhkb_split_shift_regular_backspace in modelf77/keymap.c having a missing comma on the third line after KC_CAPS
2. keys.c will never successfully compile if LAYER_COUNT in layers.c is < 1 (because some variables referenced by functions are never declared since their declarations are sandwiched in between an #ifdef block checking for LAYER_COUNT > 0), and the default is 0.

Hope this helps!

[Arkku]

Unfortunately, I wish I could say it works, but it doesn't yet...or at least it doesn't seem to work for me. Got it to build, but then the AVR just seems to go into a reboot loop of some kind: Windows sees it, but shows the device with error "device cannot start (code 10)", and it just keeps repeatedly falling off the USB bus and coming back every few seconds.

Thank you for testing this, and apologies for the hassle of having to open it up! Unfortunately it is hard to debug without the actual keyboard at hand, so the final fix from me will probably have to wait some months(?) still to get my keyboard. I'm guessing it might be because all the keyboards I've actually tested with use an atmega32u4 whereas this has an atmega32u2, so the USB implementation might be incorrect. I will try later with a plain atmega32u2 that is not connected to anything to see whether I can reproduce the issue with not showing up in Windows.

Couple of small issues with the build, too:

Thanks, these are now fixed. I guess time to consider automated tests to cover different configuration combinations so that I don't break the ones I'm not using. =)

[Ellipse]

I just finished updating the project web site to add the additional ultra compact case color options Industrial Gray, Off-White/Beige, and True Red. You can upgrade an existing keyboard or spare case that hasn't yet shipped, or make a new order. The cost is the same as the other premium cases (all $75 extra).

[robo]

So, umm... I haven't received my F77 yet but from how this thread has evolved (devolved?) into a technical deep dive into multiple keyboard firmware programming toolchains and DSLs, I have a really basic question:

Am I going to be able to just plug in and use my keyboard successfully when it arrives, or is this deeply technical fuckery required? I'm OK with deeply technical fuckery, it's my day job and sometimes my hobby, but frankly I have barely any time for hobbies anymore, and I need a keyboard that works reliably.

FWIW, I use macOS with Karabiner Elements, and have no interest in custom function layers or other customization beyond what Karabiner Elements provides...

[thefarside]

So, umm... I haven't received my F77 yet but from how this thread has evolved (devolved?) into a technical deep dive into multiple keyboard firmware programming toolchains and DSLs, I have a really basic question:

Am I going to be able to just plug in and use my keyboard successfully when it arrives, or is this deeply technical fuckery required? I'm OK with deeply technical fuckery, it's my day job and sometimes my hobby, but frankly I have barely any time for hobbies anymore, and I need a keyboard that works reliably.

FWIW, I use macOS with Karabiner Elements, and have no interest in custom function layers or other customization beyond what Karabiner Elements provides...

It is setup to work out of the box like a normal keyboard. On a Mac I had to go through the keyboard test to verify it was an ANSI keyboard for my F77, and it has worked fine on the various computers I’ve connected it to. I think most people posting with issues are modifying their firmware.

[Ellipse]

Yes robo; please do not worry - the keyboard requires zero programming as everything is set and confirmed by me during the final QC process before mailing each keyboard, based on the options you selected when ordering the keyboard. Most people won't even touch any settings or even change the firmware from what I can gather. Thanks to xwhatsit, pandrew, darkcruix, and the QMK/Via folks plus the other forum members helping out and providing various firmware and controller options, these keyboards definitely have far more features and customizability than most Model F fans would ever be able to use!

And again my apologies for the delays and for the uncertainty around the timelines. As noted before, I think I will be able to go through everyone's orders to mail things out over the coming months of this year into early next year. So far I've tested and mailed out a whole lot of keyboards but we still have a ways to go

[thefarside]

I have a stupid question. Does the HHKB layout have a different barrel plate arrangement than the standard ANSI layout? I ask because I thought I would be cool to have a “Focus” keyboard layout with a big ass enter (from a Model F AT), normal backspace and split right shift.

[thefarside]

Thought I'd share some pictures of the industrial SSK blue set I just received.

I first replaced the modifier keys since I was using blanks and was pleased, but think a darker set would contrast better than the pearl set taken from my Model F AT.

IMG_3330.jpg (2.18 MiB) Viewed 30082 times

Below is a comparison of the D T keys from the top-down:
Model F AT (1st top row)
Repro SSK Blue (2nd)
1988 Model M (3rd)
2020 New Model M (4th)

IMG_3334.jpg (3.66 MiB) Viewed 30082 times

Here's another with the flash turned on to show how much they "pop" in bright light:

IMG_3335.jpg (3.74 MiB) Viewed 30082 times

I don't have an original set of XT keys to compare to but overall I think the quality is excellent.

[daedalus]

I ordered mine not long after the orders opened, now it is here:



Will share more thoughts as I use it more. First impressions is that Ellipse has done a fantastic job with the keyswitches, the keycaps and the keyboard as a whole.

[robo]

OK, thank you for the assurances Ellipse and thefarside!

[NathanA]

Does the HHKB layout have a different barrel plate arrangement than the standard ANSI layout?

Yes, but in fact the only single difference between the two barrel plates is in the right shift area. Everything else is 100% identical.

So with most things, you can change the layout by simply adding or removing flippers and stabilizer inserts. But the right shift key is 2.75u wide, and its plunger and stabilizer stem are arranged in such a way that if you were to split it with a "normal" barrel plate (or indeed with any barrel plate that IBM ever manufactured for any Model F 4094 or F AT, or Model M), your only option is to go with an arrangement of 1u + 1.75u left-to-right.

The HHKB-style barrel plate changes the barrel arrangement underneath the right shift area such that it accommodates 1.75u + 1u left-to-right. The downside to this is that if you have an HHKB-style barrel plate, it is impossible to use a normal right shift key with it: it *must* remain split (unless you were to, say, 3D-print yourself a custom right shift key that would fit!).

I'm not an HHKB layout fan, but I personally think this particular compromise is worth it in order to gain an extra key (which I have mapped to Fn / layer selection). So I ordered the HHKB layout but use the keyboard in ANSI layout with a split right shift. I use the right shift almost exclusively (which I only recently learned apparently makes me "weird"), but I almost always find myself hitting it on the left edge, so it's not a problem most of the time for it to be shorter on the right side. In those one-off circumstances where my right pinky might slide over the area where the right side of a normal shift key would normally be (like, say, if I want to do Shift + \ in order to get | but I overshoot and hit Fn instead), I've programmed Fn to give me the character that I would have normally gotten with Shift + that key (so, Fn + \ also gives me |).

I ask because I thought I would be cool to have a “Focus” keyboard layout with a big ass enter (from a Model F AT), normal backspace and split right shift.

Absolutely doable. If you ordered HHKB-style, just replace the flippers in the penultimate-rightmost space in the top row & the rightmost space in the 2nd row (the 1.5u space where \ | is in ANSI layout) with stabilizer inserts instead, and then pop on the 2u Backspace in the top row and your BAE below that, and stick \ to the right of right shift.

If however you did not order a keyboard with HHKB barrel plate, you are going to be forced to relocate \ to the LEFT of your right shift key, instead of to the RIGHT of it, due to the barrel plate difference.

Also note that you can't simply swap out barrel plates if you later decide you wished you had HHKB/Focus style split right shift instead, because the PCB is of course also different (since the pads underneath the right shift are now in a different place).

[thefarside]

Excellent thanks NathanA! It sounds like I'll have to order an HHKB version to do this and that's ok!

[Gunsight1]

So technical question for you guys. My F77 has started to develop a bit of an frustratingissue over the past couple weeks. Initially it was just 1 key, but it has spread to a second one now. What I am having happen is that the key will stop responding to keypresses until I remove and reinstall the keycap. I dont know if something is slipping out of place or whats up. It started with the left side CTRL key, doing this about every 4-5 days, then when I remove the top and put it back on it works again for a few days. It has started happening with the ' " key now as well, but this time reinstalling the keycap did not immediately correct the issue and I had to reinstall it a couple times before it started working once more, but then that key stopped responding again after a couple keypresses (as I am typing this post actually) and is again not functioning. I donno if this is a problem with the way the keycap is seating on (I am using Unicomp keycaps right now as I opted to get my keyboard ahead while the proper keycaps are still being manufactured), so I donno if the keycap is an issue, or if there is a problem with the spring or flipper? I have not tried replacing those with spares yet, but thought I would ping you guys here for any ideas or guidance.

Thanks!

[Muirium]

Sounds like a flipper issue to me, rather than the caps. I'd open it up and take a look at the flippers. They may need swapped around or replaced.

The only time I've had repeating issues with keys not registering correctly on authentic Model Fs, it's been dodgy flippers. Sometimes replacing the cap can fix it for a little while, as you've described, but it's not a real fix. It's the flipper's fault.

[Arkku]

Since the ISO enter is not available in other colours than pebble (AFAIK), I wonder if anyone has tried mixing pebble with the dark gray? I was thinking of letters in dark gray, and other keys in pebble.