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

[thefarside]

Any additional logos that should be produced? I hope to finalize the production over the coming days.

Would IBM logos cause a legal problem? I’ve purchased reproduction logos on eBay but maybe a business falls under different scrutiny.

[Ellipse]

engr we may start out with just the white text for now, not sure about color pad printing. Everyone please email me if they are looking for different colors for a particular set.

To be safe, I do not want to make other company logos.

Die casting of the Model M style cases continues, after production was approved to start late last month. Here is an interesting video from the factory showing a case as it is cast. There are a number of finishing operations required before the case can look nice and smooth for the powdercoating process.

[AlexB555]

For those interested in a "non-English" overlay (more neutral). This is the template sent, with the proper "atomic mushroom cloud". Numlock is a crypto "1" and Caps Lock is a crypto capital "i". Scroll Lock is more obvious.

An idea: The overlay could be sold in a small bundle with the proper 1,75u Caps Lock, 1u Scroll Lock, and 1u Numlock.

[Ellipse]

Project featured on Linus Tech Tips ShortCircuit:
It was a great honor for the new Model F project to be featured on the Linus Tech Tips ShortCircuit YouTube channel today!

My reply posted in the YouTube comments is below, since it may be tough to find among the many comments:

"Hello, project coordinator here. Thanks Nicholas and the entire ShortCircuit team for putting together a nice video covering the Brand New Model F Keyboard! It is great to get the word out about these great keyboards that definitely take some getting used to!

Kindly see my replies to some of the notes brought up in the video:

The pinginess / reverberation: Some folks that prefer a Model F board without the higher pitch sounds. The best thing about buckling spring keyboards is the a longstanding community that has come up with various repair and maintenance step by step guides and mods, including the Floss Mod and the grease mod, to reduce or eliminate the high-pitch / pinginess while typing. My guess is that the main reason for the pinginess is the super thick steel plates reverberating inside the keyboard.

Why True Red? Well it's the Pantone designation for the particular shade of red. The factory prefers Pantone references when doing the finishing.

Recessed keys: The reason for the extra recessed keys for a couple of the rows is that the Ultra Compact F104 case top in the video is flat and the Model F and Model M design require a curved plate inside the keyboard. One result of this is that the key profiles are all uniform and a key can be installed on the various rows. The Model M style F104, FSSK, and F122 cases are all curved where the keys are, just like the IBM originals, so the keys will stick out more evenly.

Casting: The Ultra Compact cases for the F104 and FSSK were CNC milled and have 3 main parts, while the ultra compact cases for the F62 and F77 keyboards are die cast, while the first rounds of the compact F62/F77 boards were CNC milled. The Model M style case Model F keyboards all have die cast cases.

Regarding the low serials, they are mainly there to allow folks to offer a little extra support to help cover the tens of thousands of dollars in project cost overruns, the near-endless express air mail sample charges over the years, etc. Many folks also like a custom serial because it allows them to pick a date for the production date, like their birthday or an anniversary of some date. In the Model M community forums it is always notable to get a board made the same year you were born, or if you were lucky, on your actual birthday (and actual birth year too!)."

[Ellipse]

Can you believe over 100,000 views for the Model F Keyboard ShortCircuit video? Who would have thought there was so much interest in the Model F! It is great to see.

Due to the significant feedback I received after the video launch with folks not knowing much about the differences between Model M and Model F keyboards I made a quick video:

[NathanA]

Wow, it's been a while since I've checked in here... (life things: crazy @ work, some health issues, etc.; the usual) Clearly a lot has happened in the past year+ and I need to take some time to get caught up. But the good news is that my New F77s still work great & I'm still enjoying them immensely!

I am interested in trying to backport Arkku's updated calibration routines to the private Vial tree I've been...well, "maintaining" is probably not quite the proper word, but y'know what I mean. So I'll hopefully manage to find some time to take a stab at that soon & take it for a spin.

The DAC is 4 times more precise on your keyboard than the new ones, [...]

I'd love to know what you are referring to here? It's news to me that (aside from the matrix mapping) there are significant differences between the original xwhatsit controllers, and the "shrunken" wcass version that found its way into the Ellipse 'boards. What's the source of this claim?

There was discussion about obtaining a unique USB PID code for the controller. I have now obtained the code 4704
https://pid.codes/1209/4704/

This is cool and I'm glad to see it, though as others have already pointed out, although QMK & Vial don't particularly care about the USB VID/PID, unfortunately VIA *does*, and requires a unique VID+PID for a given unique keyboard layout, which means the F62 and F77 cannot share the same VID+PID with each other when paired with VIA (and, indeed, this goes for all of the boards that use an xwhatsit). And although I personally could not give a rip about VIA, others still use it. So not sure what the solution to this is.

It's doubly frustrating since it seems to me that VIA could easily also base "uniqueness" on not just the combination of VID+PID, but could also throw VER in there, too. If it did that, then we could share VID+PID across all xwhatsit-based keyboards, and distinguish between unique layouts / matrices with DEVICE_VER. That such an obvious solution exists and yet they've never been bothered to implement it just increases my disdain for the thing...

[Ellipse]

JIS New Production Key Set:

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

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

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

JIS draft3.JPG (160.57 KiB) Viewed 52013 times

JIS Standard - Copy.png (145.77 KiB) Viewed 52072 times

[sebkaide]

It's really exciting to see XT quality JIS keycaps. Thank you for hard work Ellipse and Zed!

I've noticed a couple of minor things, which I think ultimately come down to style preference. But all in all no mistakes.

Caps Lock: Some of the old Japanese IBM and newer unicomp keyboards have "漢字番号" written on the front. Newer keyboards tend to omit this though.
Heres an image from my Unicomp:

jis-caps.jpeg (590.24 KiB) Viewed 52030 times

Backspace: Most JIS keyboards backspace is stylised as:

Code: Select all

Back
space

The rest I assume is just me misreading the template.

The 半角/全角 漢字 key in the top left by Tab: "漢字" is usually printed on the front. Same thing with "ローマ字" on the カタカナ/ひらがな ローマ字 key in the bottom right.

The =-ほ and _\ろ keys: It's probably just the font but it kind of looks like the - and _ are mixed up?

[Ellipse]

Thanks for the feedback sebkaide

Here are my notes:
I have updated the =-ほ and _\ろ keys in the above post to fix the issue. I moved up the small dash on the =- key and used the em dash for the other key.

Caps Lock - what do folks think about adding it as a third line or appending a / and the text to the second line? As a general note any front printing is moved to the top of the key for all key sets. I say we should add as much as is commonly found on JIS sets but to stay with IBM/Lexmark/Unicomp style JIS and not vintage JIS.

Backspace - Zed thought of keeping the key consistent with the icon 1U backspace keys of other sets (a change from the original) but what does everyone think? I did leave the enter writing on the ISO Enter key though Zed thought it should be icon only to be consistent.

Zed indicated that the extra tab text is for very old style JIS boards only and that Unicomp and IBM/Lexmark boards omit this text. What is the general consensus on this text for JIS users?

[Ellipse]

I have just ordered the metal Beam Spring and Model F badges. They can now be ordered from

https://www.modelfkeyboards.com/product ... ng-extras/

There are 2 options - the Model F style and the Beam Spring style (renderings are shown below). If you would like for me to order additional styles, you will have to cover the tooling charges and commit to ordering 15 badges at a minimum. The MFL logo was not ordered due to lack of interest. The beam spring one has the bottom edge cropped not touching the edge on purpose, since the image would be far smaller if the entire beam spring drawing was visible on the badge.

Badges and LED overlays are the same size as the IBM originals and can fit most Model M or Model F keyboards, with exception for the IBM XT and AT boards that use a larger badge.  These badges are 2cm x 2 cm.  The F122 is the only new production board that has a recessed spot for the badge but you can stick the badges anywhere on any of the Brand New Model F or Brand New Beam Spring keyboard cases.

The factory also has the capability to make the black badges with the raised silver printing as well as the large AT/XT style, so let me know if you want to cover the tooling and order minimums to make any of those styles. I am working with the same factory that produced the badges listed in the below eBay link (not my link). Unfortunately I can't make anything copyrighted/trademarked.
https://www.ebay.com/itm/124836963936

F badge.jpg (251.58 KiB) Viewed 51836 times

Beam badge.JPG (200.43 KiB) Viewed 51836 times

[sebkaide]

With the JIS keycaps: I think if front printing ends up being moved to the top of the key then I think it's probably best to omit the text.

Do any of the sets currently have 3 lines of text? I'd imagine it getting a little crowded.

半角/全角: Looking at some of the IBM/Unicomp keyboards, it's probably a 50/50 split if "漢字" is included. My Unicomp doesn't include it. If it's not possible to include all three lines without crowding or shrinking the text I think its worth leaving it at just "半角/全角".

カタカナ ひらがな: I think the inclusion of ローマ字 as a third line would be ideal even if the text has to be shrunk a little. But still not the end of the world if it ends up not fitting.

Caps lock: As far as I know the "漢字番号" functionality only existed on IBM's version of DOS. I imagine it's on the Unicomp keyboards for historical reasons. I think it's safe to remove it.

Backspace: I think keeping it consistent with the other XT caps is best. Probably the closest to a Japanese model f would be the IBM Pingmaster, which has a 1U arrow icon backspace as well.

Enter key: Japanese IBM is pretty over the place with it. I'm personally pretty fond of the "改行" with arrow. But ultimately it probably makes sense keep it icon only for consistency.

ibm-jis-enter-keys.png (151.83 KiB) Viewed 51759 times

[Ellipse]

Thanks; I updated the ISO Enter key to Icon only.

No other sets have 3 lines but Zed seemed to think it was ok to do so and important to include all 3 lines, based on talks with others on making the JIS layout. The modifier key text height is about 1/3 of the key so 3 lines could fit without shrinking things.

[NathanA]

[...] I wonder if NathanA has compiled his Vial firmware newfxx-vial_20220405.zip with setting

Code: Select all

VIAL_INSECURE = yes

which weren't anything I'd like to keep. If he had mentioned his configuration, I haven't been unable to unearth it from the 253 pages of this thread.

Hi. I literally explained this in my very first post about my first crack at a Vial firmware:

• 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.

I guess the reason it wasn't easy to search for is because I didn't reference it by the name of the C preprocessor constant "VIAL_INSECURE"...oh well.

Was NathanA's Vial firmware for the Model F compiled with setting

Code: Select all

VIAL_INSECURE = yes

?

I'm not overly enchanted by the possibility, that a process running without administrator privileges can change the keyboard's layout without any explicit manual interaction needed.

Vial's security feature does not protect you from this, nor was it intended to. Even if a Vial firmware is built with the security feature, it does not need to be engaged before you can remap keys with Vial.

The only activities that Vial security protects from are these:

• Kicking the keyboard controller over into bootloader mode, to prepare for reflash.
• (Re-)defining macros.

All other programming and configuration activities are permitted without the security feature being engaged. And if you think about it, this makes at least some sense, given that Vial is built on top of VIA and extends the VIA configuration protocol, purposefully maintains backwards-compatibility with the VIA configuration utility, and VIA has no native provision for a similar security feature. Therefore requiring the user to pass a security check before remapping keys would render the VIA utility useless and break compatibility. VIA, on the other hand, does not (or, rather, at least did not back in VIA 1.x / 2.x) support defining macros, nor does it support instructing the controller to reboot itself into bootloader mode, either. So protecting these two arguably more sensitive features with a security feature was both 1) reasonable and 2) doesn't break compatibility with VIA in the slightest.

Vial security is a good idea, and I have nothing against it in principle. There are, however, Reasons(tm) why I left it out of my firmware builds:

• It takes up extra code space, and with all of the QMK and Vial features I had enabled in my builds, flash space was at a premium.
  `
• With as experimental as my Vial firmware builds were, and with as many builds as I was testing on my personal keyboards, I would sometimes manage to crank out a build that broke keyboard functionality in ways that would prevent me from pressing a key combo to kick over to bootloader mode and reflash back to a working firmware. With Vial security turned on in the build, I can't use Vial to reboot into bootloader mode if the key sensing is literally broken, making it impossible for me to hold down the security key combo. And it's a pain to open up the keyboard and short a set of pads on a PCB every time I need to do this. So leaving it off made fixing a keyboard flashed with a broken firmware build way easier and less time-consuming.
  `
• Vial was of course written as a general-purpose QMK extension for use with theoretically as many keyboard models as QMK supports, not just our beloved Model Fs running an xwhatsit controller. And the xwhatsit QMK support written by pandrew has an additional way of instructing the controller to reboot into bootloader mode via a software command over USB, which you can engage with the pandrew utility. And this bootloader mode command is NOT protected by the Vial security feature, since it has nothing to do with Vial. Thus having Vial security enabled doesn't protect you from some bad actor flashing a keylogging firmware to your xwhatsit-based keyboard ANYWAY.

All that said, I may decide to release Vial-security-enabled builds of my firmware binaries at some point in the future. Just don't let its mere presence lull you into a false sense of security if I do.

[Ellipse]

IBM Color matching:
Some folks have been asking what are the exact colors of the IBM Beige and Industrial Gray.

I was able to use an i1 spectrophotometer to make the measurements, which have been sent to the factories making the cases. Of course IBM's paint and plastic colors varied noticeably from case to case so your IBM case probably does not match these cases, so these values are provided to use at your own risk (probably better to take your case to the paint store where they can do an accurate match). Also the texture of paint as well as the uneven dirtiness and wear of the 6110344 case also adds some variance to measurement as my particular spectrophotometer is not geared to measuring textures. The beige on the screen looks quite different on my hardware calibrated monitor compared to viewing the keyboard itself, while the gray is similar.

Here are measurements of my F122 6110344 from 1984 and a brand new 1990s IBM Industrial Gray case. I took 10 samples from different areas of each case and averaged them.

Capture.JPG (14.83 KiB) Viewed 51641 times

Capture.JPG (20.84 KiB) Viewed 51641 times

Beige
LAB_L LAB_A LAB_B LAB_C LAB_H
77.028 -1.431 8.603 8.721 99.444

Industrial Gray
LAB_L LAB_A LAB_B LAB_C LAB_H
49.034 -0.727 7.576 7.612 95.464

[NathanA]

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?

Interesting; I haven't tried this so I don't know the answer the question about whether a user-defined combo can be used to enter bootloader mode; it's never even occurred to me to try.

But regarding the LShift + RShift + B entering bootloader mode on other firmwares: that was not implemented as a user combo. That is a feature of QMK called Command (formerly: Magic) Keys. It is enabled with `COMMAND_ENABLE = yes` in rules.mk. A particular set of modifier keys are defined as engaging the special "Command Keys layer", which cannot be defined except at compile time. By default those keys are LShift + RShift, and there are several additional built-in command keys aside from 'B' for bootloader.

I built my Vial firmwares with COMMAND_ENABLE set to no, which is why this combo doesn't work. I did this for a reason similar to why I disabled Vial security: my builds of Vial firmware were forced to go on a diet to fit within the 32u2's paltry flash capacity. Since the primary Command Keys functions that 99% of us were concerned about (namely: bootloader mode and EEPROM reset) can also be assigned to individual keys on a function layer, this seemed redundant, and so I determined that keeping e.g. the MouseKeys and ExtraKeys features around was more important than Command Keys. So it was put on the chopping block.

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?

IIRC, there is a bug in the Vial firmware, related to a #define or enum, which NathanA explained a while ago: the actual reset/bootloader keycodes have +1 codes, thus the code which should be 0x5C00 may actually be 0x5C01 or so. Please get back up this thread to get the actual explaination and fix...

Thanks for caring! If my hexadecimal arithmetic skills are in the right ballpark, this would mean, "Reset" (0x5C00) would actually be 0x5BFF.

Actually, no: note that the "bug" in question only offsets by -1 keycodes that are 0x5C93 and beyond. So 0x5C00, being < 0x5C93, would not be affected, which is why assigning that code to a key and then pressing it caused the board to reset and enter bootloader mode successfully, as expected. I don't know how to explain your experience with 0x5BFF. As far as I can tell, that code is undefined/unassigned.

In any event, the whole deal with this "bug" has turned out to be a giant nothingburger. I tried "fixing" it, but quickly learned/realized that what was done here was done intentionally & by design. (In fact, there is a via_ensure_keycode.h header full of assertions that will get tripped if you try to "fix" the quantum_keycodes.h "error"...this exists as a test to ensure no QMK developer breaks keycodes in the future that VIA/Vial know about.)

The basic problem is that the VIA configuration app (as well as the Vial one) *assumes* that specific keycodes will always generate the same action. There is no way for VIA or Vial to "interrogate" the keyboard firmware in order to determine what action the firmware has decided to map a particular keycode to, so the VIA config app *must* assume & embed these assumptions as static mappings within itself. For the most part, it's safe for VIA/Vial to make these assumptions, as the vast majority of codes in QMK never change once they have been defined. But the block of keycodes in quantum_keycodes.h from 0x5C00 and beyond are labeled in the comments as "loose keycodes", implying they could change at anytime and one should never assume their function.

I haven't gone back and exhaustively researched the exact history that led to this, but since the two different definitions of MI_VEL_1 are encased within a preprocessor #ifdef checking for "VIA_ENABLE", it's safe to assume that at one point in QMK's history, EEPROM_RESET (for example) actually was 0x5CDE originally. And then somebody checked in a change that caused everything to get offset by +1 past 0x5C93. (My guess is that MI_VEL_0 didn't originally exist and those codes started with MI_VEL_1, and that MI_VEL_0 was added later, which in turn caused this chaos.) Since VIA had apparently already added knowledge of some of these "loose keycodes" to itself before this point (in apparent violation of the "loose" dictate), this #ifdef was added in order to make VIA firmwares return all of these keycode constants back to their original values (so that keys assigned these codes would show up with the "correct" label within the VIA config app), while NON-VIA firmwares continued down the road of treating 0x5C00 - 0x5FFF as "loose"...though the existence of via_ensure_keycode.h implies that they will be trying to make sure this kind of thing doesn't happen in the future, and that any codes within that "loose" range that VIA becomes "aware" of will then be effectively set in stone.

All this to say that if you are running a VIA/Vial firmware, codes that the app is unaware of will show up as the "raw" hex values & those might actually be different than non-VIA QMK firmware! and that's normal! while you can assume that any codes that are displayed as a name instead of a number are in fact correct for the particular firmware that you are running. In other words: nothing to see here, move along.

[NathanA]

I am interested in trying to backport Arkku's updated calibration routines to [my] private Vial tree [...]

I have Arkku's code running on a copy of Vial-enabled QMK firmware now...in fact, I'm typing this out right now on a keyboard that's running it! However, this marriage is still far from perfect...

• The Arkku calibration routine adds a whopping 3K of additional code to QMK, compared to pandrew's. My builds of Vial were already on the tight side, with only ~1K of space to spare. As a result, so far it's not proven possible to incorporate this without sacrificing something else. I finally got it to fit by cutting out both the solenoid support (I don't use one) as well as NKRO support (I'm not a gamer and 6KRO is enough for me). Probably could have cut some other features instead of those, but I use most of the rest. I recognize that solenoids and NKRO are both popular with a lot of people who use these boards, though, so the compromises I chose are likely not the ones that others would choose...
  `
• If I build with the calibration-saved-to-EEPROM feature (CAPSENSE_CAL_AUTOSAVE), the keyboard only works on first boot, with a virgin/zeroed-out EEPROM. The moment I reboot the keyboard, it stops sending scancodes back to the host. (Though Vial and pandrew util can both still see it and talk to it, etc.) This implies to me that something is going wrong either during the saving of the calibration data (saving to the wrong place in EEPROM), or with loading it on boot (looking for it in the wrong place in EEPROM), as if the data is garbage. In fact, if I take a look at the Keypress Monitor within the pandrew utility to see what the firmware decided on using as the threshold point during calibration, I see that it usually picks 140/141 initially, but after I reboot, it will show something astronomically high, like 268. Which explains why keystrokes stop triggering. Wiping EEPROM -- and thus the saved settings -- gets it working again, until next reboot. So for now, I have calibration saving turned off. I'm using Arkku's latest code from his QMK fork dated September 11 2022. My best guess at this time is that something is going wrong with the EECONFIG offset computation, which was one of the last major code changes he committed. I have not yet tried reverting that.
  `
• A minor issue to be sure compared to the previous two, but for some reason, keystrokes do not register at all on the pandrew utility Keystroke Monitor with this firmware. The Signal Level Monitor, however, works just fine...

So, chipping away at it. Since I don't know how long it will take me to debug these issues, I'll most likely still post at least one more complete Vial build here with the standard pandrew calibration routine, just in order to pull together all of the latest fixes for it.

[jsahmiens]

Ellipse, would you consider manufacturing springs of differing weights for your project?

I've always found the Model M actuation weight to be perfect, but Model F's a bit too light for my liking. Of course I stuck with Model F due to its superior key feel and construction. If you offered Model F replacement springs in heavier weights (and perhaps lighter) for your New Model Fs, I (and others I'm sure) would be interested

[NathanA]

I've always found the Model M actuation weight to be perfect, but Model F's a bit too light for my liking.

Not that it would be easy or quick, but I suppose you could try buying a bunch of Model M springs and flippers, removing the springs from the flippers, and attaching them to the flippers of your Model F...

[o2dazone]

I'm glad the stabilizer bar silencing trick worked. TBH all credit goes to those that initially did it on mx style stems. I'm just standing on the shoulders of giants

My F77 BIG ass

I'm sharing an easy read on about my last F77 layout customisation, just for killing time during these lazy summer days being spent on the beach under umbrellas in sunshine Italy days (The most unfortunate will have to settle for the leaden skies of Brighton, as for my son portrayed in the photo under another type of umbrella. guess who.)
question_of_ass.jpg

It goes without saying, in life you need luck, and a big ass is all you need to face the adversities that fate throws at us.
Now that we're on the subject, let me get into the details and, as usual a pic is worth more than one thousand words, also bad ones, (sorry in advance for the poor quality. I had my smartphone at hand - lazy days, remember?).
F77_bigAss_enter.gif
Process in detail here:

Spoiler:

001.jpg
002.jpg
003.jpg
I set out at full speed with some vices..... fo find out lately that with Ellipse's F repros you don't need them at all. Plates slide in and out like a charm.
004.jpg
Starting situation once I opened it up.
My GOAL was to replace the uncomfortable 1U backspace and place in my Big ASS Enter coming from an F AT (already modded to ANSI layout with 2xALT keys)
005.jpg
Setting that big washer in that location did the trick to stabilize the enter key, endowed with a wire stabilizer.
to note that the space bar wire was modded too to cancel the rattling noise (thanks o2dazone), which I don't mind too much though. As indeed, I didn't mind to put that ancient badge on. ahaha

Now I'm very HAPPY with my second hand Model F77 (sorry Joe), VIAL enabled. Here my map layout, not quite matching the physical keys:
Vial_01.JPG
Vial_02.JPG
Thanks for reading

p.s.

Spoiler:

also the dust cover (mmhh) thanks.... ahah
006.jpg

[Ellipse]

jsahmiens here is my old note on Higher force springs - these are still available.

Is anyone interested in higher-force springs? I have a sample set of ~120 springs that were rejected as they required a little more force to process. The whole lot is available to one person so they have enough to fill a keyboard with them; please PM me if interested. Pricing will be based on best offer, with a minimum of $1 per spring. Flippers not included. Due to slight variations in the diameter of the flipper nubs I can’t guarantee this will work with original flippers (none of my springs are recommended to be installed on original flippers, as noted a while back). These ~120 springs are a slightly tighter fit than the production springs, so you have to press them a little more forcefully onto each nub. I would describe the sound as approximately the same as the production springs, maybe slightly quieter but still audible.

I also have 230 QC rejected springs without flippers (sound characteristics are off – too high pitch) available in batches of 80, 120, or you can take the whole lot. If you prefer a changing to a higher pitch spring this is the only batch available. Again, only recommended for new Model F flippers but will possibly work with originals. Pricing is the same $1 per spring.

[RedESC]

jsahmiens here is my old note on Higher force springs - these are still available.

Is anyone interested in higher-force springs? I have a sample set of ~120 springs that were rejected as they required a little more force to process. The whole lot is available to one person so they have enough to fill a keyboard with them; please PM me if interested. Pricing will be based on best offer, with a minimum of $1 per spring. Flippers not included. Due to slight variations in the diameter of the flipper nubs I can’t guarantee this will work with original flippers (none of my springs are recommended to be installed on original flippers, as noted a while back). These ~120 springs are a slightly tighter fit than the production springs, so you have to press them a little more forcefully onto each nub. I would describe the sound as approximately the same as the production springs, maybe slightly quieter but still audible.

I also have 230 QC rejected springs without flippers (sound characteristics are off – too high pitch) available in batches of 80, 120, or you can take the whole lot. If you prefer a changing to a higher pitch spring this is the only batch available. Again, only recommended for new Model F flippers but will possibly work with originals. Pricing is the same $1 per spring.

Personally I see higher force springs as an interesting novelty although I could live without them. Would be something I'd like to try out and maybe swap out a whole board if I liked them but I wouldn't be in a mad rush to get them right off the bat.

[NathanA]

[...] although QMK & Vial don't particularly care about the USB VID/PID, unfortunately VIA *does*, and requires a unique VID+PID for a given unique keyboard layout, which means the F62 and F77 cannot share the same VID+PID with each other when paired with VIA [...] So not sure what the solution to this is.

While mulling over potential options and work-arounds to this problem, I eventually realized that, at least when it comes to this particular keyboard & project, there actually IS no problem! That's because the VIA JSON definitions that darkcruix came up with for these 'boards were never officially submitted to the VIA maintainers, and thus VIA has never "natively" been aware of them and has always required the user to sideload them after launching VIA. This being the case, it doesn't matter if two different keyboard models share the same USB VID+PID, because realistically a user with either an F62 or an F77 is only going to bother to load one definition file or the other after launching the VIA app.

And so I'm just not going to worry about it, and embrace the new USB IDs. With that now settled, I am releasing an update to my Vial firmware builds. Announcing Release 3 of NathanA's Vial firmware builds for the Model F Labs F62 and F77.

This release is (finally) just essentially a roll-up of all previous fixes (plus some additional ones) that have been informally distributed since the last full release, which was in November 2021. As such, it is still based on the same development branches of both QMK+Vial and pandrew's capsense implementation for QMK as past releases were, and so barring some catastrophic showstopper is likely to be the last such release I'll bother to do. Here are a list of changes:

1. NKRO support is now enabled in the build (but still remains off by default after first boot)
2. The new USB PID:VID of 1209:4704 is now used by both F62 and F77 firmwares
3. Some F77 right block Option 4 and Option 5 Vial keymaps are now included in the distribution
4. All base layer (0) keys have a default assignment other than KC_NO, preventing the "dead key" issue with some of the optional pads
5. With the F77, the issue where the "split backspace" layout option setting is not remembered/saved has been fixed

Additional notes and details:

• Re: #1, to actually enable NKRO, you have to assign the NKRO Enable/Disable toggle function (0x5C14) to some key on some layer, and then press it. (Many of the VIA and Vial keymap files distributed with the firmware already have this assigned.) You should only have to do this once (the NKRO state will be saved to EEPROM) unless of course you press it again to disable it.
  `
• As for #2, note that since the keyboard identifiers have changed that both VIA and Vial use to identify your particular keyboard, all of the VIA and Vial keymap files from past releases will not work properly with this latest firmware. All of the keymap files included here have been updated with the proper matching identifiers, so make sure to use the keymaps included here & just throw the old ones out. (This also goes for the VIA keyboard definition/layout JSONs, in the 'src' subdirectory.) I've also made updated builds of the pandrew capsense debug util as well that support these IDs.
  `
• I did not attempt to be anywhere close to exhaustive with covering all possible keymap and layout variations when it came to putting together Option 4 and Option 5 keymaps for the F77 right block. These are largely just slightly expanded sets of the keymaps that already had been individually posted earlier in this thread. If you have an F77 with something other than a standard ANSI layout, you can use the included Option 4 & 5 keymaps to help jumpstart a similar keymap for your ISO/HHKB/etc. board.
  `
• The fix for #5 was a recent discovery: the VIA_EEPROM_LAYOUT_OPTIONS_SIZE constant needed to be increased to 2 (bytes) from its default of 1. There are too many VIA/Vial layout options for the F77 to be able to fit into a single byte of EEPROM space, which is why enabling the "Split Backspace" layout setting on an F77 board never "stuck"; all previous publicly-distributed VIA and Vial firmwares for the F77 suffer from this issue.

IMPORTANT INSTALLATION INSTRUCTIONS:

If you are upgrading from a past VIA or Vial firmware, it is recommended that you go into the VIA or Vial config app on your PC, and export/save your current keymap, especially if it isn't one of the stock ones! The keymap stored in the keyboard's memory will be lost as part of this upgrade, so if you don't do this, you'll lose any work you have put into customizing your keymap & be forced to do that all over again from scratch!

The keyboard controller's nonvolatile memory (EEPROM) will need to be wiped during the upgrade, as the layout of settings stored in EEPROM have changed in this version as a consequence of some of the under-the-hood changes (e.g., item #5 in changelog).

1. Launch your weapon of choice (VIA or Vial) and backup your current keymap!!
2. Put your keyboard into bootloader mode
3. Launch QMK Toolbox
4. Click the "Clear EEPROM" button
5. Click the Open button, navigate to the "newfxx-vial-package_r3" folder, then to the "bin" subfolder, and select the "eeprom_eraser.hex" file
6. Make sure "MCU" is set to "atmega32u2"
7. Click the Flash button
8. Click the Open button, navigate back to the same directory as back in step #4, and select whichever firmware corresponds to your particular model of keyboard ("newf62" or "newf77")
9. Click the Flash button
10. Your keyboard should now be running the updated firmware, so re-launch VIA or Vial, and restore the keymap that you backed up back in step #1. Because of the different USB IDs, Vial will likely warn you that the "Saved keymap belongs to a different keyboard" and ask you to confirm that you want to proceed; say Yes. (And feel free to make a fresh backup after the restore is finished, so that it doesn't have to show the same confirmation dialog should you ever need to re-load your keymap again in the future.)

(If you have done absolutely ZERO customization of your keymap above and beyond one of the defaults that you initially loaded the last time you flashed firmware, then you can ignore step #1 and then in step #10 simply pick the stock keymap that you want to go back to from the options distributed within the "keymaps" folder.)

As mentioned previously, on account of the USB ID changes, the pandrew-util needed to be updated. Given the size of the compiled binaries, I am now distributing these separately from the main firmware package. I have also built a Mac version this time around, too, in addition to the Windows one; both are distributed separately. The Mac version I built will actually work on MacOS X going all the way back to 10.7 Lion, but I've also had opportunity to test it on the latest stable version of MacOS (13 Ventura) running on Apple Silicon & confirmed it works there, too. This build of the utility will also work with previous versions of the Vial firmware as well as the stock QMK firmware that Ellipse flashes on the controllers from the "factory".

The firmware itself is contained in the attached newfxx-vial-package_r3.7z archive. The Windows and Mac builds of the pandrew-util had to be split since this forum only allows for file attachments that are 5MiB or less. Since the forum software also enforces file extension limits, I had to rename the split 7z archives for the pandrew-util binaries before upload; after downloading, you will need to rename these from ".001.7z" and "002.7z" to ".7z.001" and ".7z.002" before 7Zip will be able to deal with them.

As always, I am also including some unified diff files along with a crude build script that shows step-by-step how to reproduce these firmware files, should you want to use them as a starting point for making your own changes (and also just so that there's full transparency for the code that's running on your keyboard!). If you set up a standard QMK build environment, and then unpack the 7z archive in your home directory on your *nix of choice, you can just execute ~/newfxx-vial-package/build.sh to fire off the build. Note that this script will NUKE any existing 'qmk_firmware' directory in your home directory, so if you already have a QMK source/build tree set up there that you want to keep, then either modify the script first, or move your existing tree out of the way before running it!!

Code: Select all

wget "https://deskthority.net/download/file.php?id=78694" -O ~/newfxx-vial-package_r3.7z
7z x ~/newfxx-vial-package_r3.7z -o`echo ~`
~/newfxx-vial-package/build.sh

Enjoy!

[Arkku]

The DAC is 4 times more precise on your keyboard than the new ones, [...]

I'd love to know what you are referring to here? It's news to me that (aside from the matrix mapping) there are significant differences between the original xwhatsit controllers, and the "shrunken" wcass version that found its way into the Ellipse 'boards. What's the source of this claim?

Ah, the source is simply the value of CAPSENSE_DAC_MAX in the source code, i.e., 1023 vs 4095, which corresponds to 10- vs 12-bit resolution.

[Arkku]

The Arkku calibration routine adds a whopping 3K of additional code to QMK, compared to pandrew's. My builds of Vial were already on the tight side, with only ~1K of space to spare.

Hmm, this does not correspond to what I remember the difference being. Are you comparing with the same configuration and same base QMK version, i.e., the only difference in the build is the matrix.c file? The base QMK is different in the public repositories, so that might be one explanation. Another possibility that comes to mind is the util_comm.c file - disabling the util support entirely might help. Also check that no debug stuff is enabled in config.

I finally got it to fit by cutting out both the solenoid support (I don't use one) as well as NKRO support (I'm not a gamer and 6KRO is enough for me).

Pet peeve, but I think the idea that gamers would need NKRO is IMO just plain false and clever marketing from gaming keyboard manufacturers: I think they intentionally confuse the idea of the lack of NKRO to mean 2KRO (i.e., traditional matrix-based keyboards). But true 6KRO + modifiers (such as is the case with capsense keyboards) really should be more than enough for gaming. In gaming use the other hand is typically on the mouse, so you are left with 5 fingers on the keyboard... it's hard to see why you would need more than even 5KRO, i.e., how often do you press more than one key per finger. And actually the 6KRO doesn't count modifiers, so shift, alt, ctrl and win keys don't count towards the 6 that you can press at a time, and typically the gaming keybinds include at least shift and ctrl.

The only situation in gaming where I think 6KRO might not be enough is if you have two players on one keyboard (like Star Control 2 Super Melee, which I consider the ultimate key rollover benchmark), but even there 8KRO would be the answer (or just having both players use shift as one of the keys, since it doesn't count towards the 6). And in the era of USB where everyone can have their own keyboard or controller, even this is a contrived example.

So, I would implore people to not make their USB reports larger, less compatible, and (theoretically) slower just for sake of this NKRO that you don't need. Do the NKRO demo once where you mash all the keys downs with your palms, take a screenshot or record a video for bragging rights, then make your keyboard work better by switching back to something between 6KRO and 10KRO.

(FWIW my AAKBD firmware can do 7KRO + modifiers with full compatibility to boot mode reports since the report has one unused byte that can be repurposed for an extra key "for free".)

I'm using Arkku's latest code from his QMK fork dated September 11 2022. My best guess at this time is that something is going wrong with the EECONFIG offset computation, which was one of the last major code changes he committed. I have not yet tried reverting that.

You are most likely right: I never actually tested the QMK after making those changes (other than checking that it builds), since I'm not using the QMK firmware myself... There are safeguards against garbage data so it _should_ just fall back to not using the saved calibration results in case the data doesn't pass validation. It could be that it gets stuck in some loop in that case, I will try to look into it.

A minor issue to be sure compared to the previous two, but for some reason, keystrokes do not register at all on the pandrew utility Keystroke Monitor with this firmware. The Signal Level Monitor, however, works just fine...

If I recall correctly it might be that the scanning speed is just very low for the utility (since I didn't want to have the microcontroller spend resources on something rarely used), and it works if you hold the key down for a long time. But this is vague memory, and could be it has also broken.

Overall, sorry about the issues, but most of my development efforts go into the AAKBD firmware and the QMK backport is just in case someone finds it useful. It would be great if some actual QMK user could pick up further development of it, but I will try to help solve these issues since I understand it's not very motivating to pick up development of broken code.

[Ellipse]

NathanA have you managed to get the pandrew Signal Level Monitor utility working with Via/Vial? I like to use the Signal Level Monitor part of the utility to test each keyboard before mailing it.

A question for everyone - I was wondering, what is the current status on the xwhatsit QMK refactoring and submission to the QMK folks? Are things production ready? And does it work with the pandrew utility? Outside of wolfman's most recent updates in this thread, I have not been able to get in touch with pandrew and wolfman recently.

I ask because I would like to add QMK support to some of the new keyboards, add them to the pandrew QMK configurator, and I'd like to wrap up the auctions and QC the auctioned boards and sample boards (Classic Case F104/FSSK, F50, F Ergo, F15). Are there any code changes needed in the individual keyboard firmware folder files for the refactored code running on the latest QMK branch?

One of the important things for diagnostics is adding support for these additional keyboards to the compiled pandrew utility - specifically the Signal Level Monitor part. I tried to troubleshoot my inability to compile the Windows pandrew utility with pandrew using Ubuntu but we weren't able to figure it out.

After confirming the QMK details on which version can be used, I would also like to host a copy of the QMK configurator web site. The good news is that snacksthecat managed to set up the configurator and wrote up a nice guide.

"The only hitch that I've run into is that it seems to need to be rebooted every so often and the service light is always yellow (degraded). Maybe those things are related, but pandrew doesn't seem to have the issue. Anyways...
Part 1 explains how to setup the configurator and add unofficial keyboards
https://www.keyboardjunk.com/p/setup-a- ... se-part-1/
Part 2 explains how to setup SSL and use your own domain name
https://www.keyboardjunk.com/p/setup-a- ... se-part-2/
"

[NathanA]

The Arkku calibration routine adds a whopping 3K of additional code to QMK, compared to pandrew's. My builds of Vial were already on the tight side, with only ~1K of space to spare.

Hmm, this does not correspond to what I remember the difference being. Are you comparing with the same configuration and same base QMK version, i.e., the only difference in the build is the matrix.c file?

Correct, essentially: I take my existing build tree, and replace matrix.c, matrix_manipulations.h, post_config.h, and util_comm.c with yours. I did have to make some changes to get it to actually compile without errors, but they were very minor, and related to the older version of QMK I'm using.

So I am doing apples-to-apples comparison of resulting binary sizes where the only code that's changing is the xwhatsit keyboard support code. Same makefiles and config.h with same #defines, etc. even.

The base QMK is different in the public repositories, so that might be one explanation.

Specifically, I am cloning the Vial repository, and then checking out a revision that's close in time to the release of the 0.4.1 version of the Vial config utility.

Another possibility that comes to mind is the util_comm.c file - disabling the util support entirely might help.

I did try to not replace util_comm.c, and instead just patched up the one or two defunct function calls in the original, as you did in early versions of your QMK port. This actually did shrink the resulting binary by 200-300 bytes or so I think? (I'll have to re-check. It might have been as much as 400-500!) So unfortunately not enough to help all by itself. Once I stripped more QMK features out in order to get a binary small enough to fit into the 32u2's flash, I also discovered that using the old util_comm.c with your latest matrix.c broke the signal level monitor and keypress monitor tests entirely (got comm errors), so that was a non-starter.

Also check that no debug stuff is enabled in config.

It's possible I'm missing something somewhere, but I have...:

• link-time optimization enabled
• NO_PRINT and NO_DEBUG defined (by virtue of having LTO enabled)
• CAPSENSE_CAL_DEBUG is 0 (1 didn't seem to add that much anyway)
• CONSOLE_ENABLE is 'no'

If there are further build optimizations I can make and/or debug switches I can turn off elsewhere, I'm all-ears...

There are safeguards against garbage data so it _should_ just fall back to not using the saved calibration results in case the data doesn't pass validation.

It seems that the safeguards are not kicking in, just based on the fact that I see it read in garbage data and set the threshold values for all keys to some crazy-high number...

Overall, sorry about the issues,

Gosh, don't apologize, for you have nothing to apologize for! You seemingly enhanced the capsense calibration routine, and then released it to everybody for free! Even if there are some bugs, that you also bothered to backport it to QMK even though you don't use QMK yourself gives those of us who do and who want to try your code for themselves a huge head start!

[NathanA]

The DAC is 4 times more precise on your keyboard than the new ones, [...]

I'd love to know what you are referring to here? It's news to me that (aside from the matrix mapping) there are significant differences between the original xwhatsit controllers, and the "shrunken" wcass version that found its way into the Ellipse 'boards. What's the source of this claim?

Ah, the source is simply the value of CAPSENSE_DAC_MAX in the source code, i.e., 1023 vs 4095, which corresponds to 10- vs 12-bit resolution.

Ah! Thanks for that. It appears that the controllers with 12-bit resolution are the "through-hole" designs, which I believe are actually different from the original xwhatsit & derivative designs in a few substantial ways (uses 32u4 instead of 32u2 SoC, for one!).

[NathanA]

NathanA have you managed to get the pandrew Signal Level Monitor utility working with Via/Vial? I like to use the Signal Level Monitor part of the utility to test each keyboard before mailing it.

Yes.

The pandrew utility has worked with the Vial firmwares I've released ever since the very first one, back in October 2021.

(I know I can be...verbose at times in my writing, but I swear: sometimes it's like nobody even bothers to read it! )

The only catch is that you have to use a slightly updated version of the utility, on account of the different USB IDs my Vial firmwares have used over time (which had to be updated yet again since for the most recent release I have finally switched to your 4704 USB PID that you registered with pid.codes!). I have included a compatible version of the pandrew utility with every release of Vial firmware I have posted here. (Though yesterday's release is the first time I've posted a copy of a compatible Mac version. Previously, I only bothered building for Windows.)

In fact, for the last 2 releases, the copies of the pandrew utility I've posted are not only compatible with my Vial firmwares, but also with the regular QMK releases from yourself and from pandrew's web QMK Configurator. I have this updated pandrew util version scanning for all of the known-compatible USB IDs used by all these firmwares. So you don't have to keep copies around of multiple versions of the utility, or use a different one depending on what firmware you're running.

For whatever reason, I was never able to make the pandrew utility work with darkcruix's VIA firmwares (or the VIA firmwares that you include in your QMK firmware ZIP file), even when I include those USB IDs in the approved list. Since Vial firmwares also support the VIA utility, though, I didn't see much reason to spend a lot of time debugging this, since if you are a die-hard VIA user, you can still flash to Vial firmware, continue to use the VIA utility to configure your keyboard, and also gain a working pandrew utility.

[NathanA]

Another possibility that comes to mind is the util_comm.c file - disabling the util support entirely might help.

I did try to not replace util_comm.c, [...] I also discovered that using the old util_comm.c with your latest matrix.c broke the signal level monitor and keypress monitor tests entirely (got comm errors), so that was a non-starter.

Oh, duh: I just realized what probably explains this: I need to update the "old" util_comm.c to account for moving of KEYBOARD_FILENAME to PROGMEM. (Looks like you did this anyway in check-in with hash a52ff53877bdae028be88354c0825610100f5912)

Anyway, since it is highly useful, I'd prefer not to disable util support in my Vial builds.

EDIT: yup, that was totally it... pandrew-util could not identify the keyboard on account of the relocation of KEYBOARD_FILENAME & I just didn't account for that when reverting to original util_comm.c. Even so, regardless of which util_comm.c implementation I include, the Keypress Monitor does not register any keystrokes when using your matrix.c. And it doesn't matter if I hold down a key for under a second or for 30 seconds: it never registers...

[NathanA]

There are safeguards against garbage data so it _should_ just fall back to not using the saved calibration results in case the data doesn't pass validation.

It seems that the safeguards are not kicking in, just based on the fact that I see it read in garbage data and set the threshold values for all keys to some crazy-high number...

Quick update on this: I tried rolling back the EECONFIG offset computation bits, and this did stop making the Keypress Monitor show non-sane high threshold numbers on subsequent boots (after saving and reloading the calibration data).

But then I started wondering if the calibration saving was actually working, or if it was actually just re-running the calibration routine at every boot now. So I picked some arbitrary bogus threshold number (e.g., 222), then modified save_matrix_calibration() to populate a temporary array of length [CAPSENSE_CAL_BINS] with every element set to this bogus constant, and then save the contents of this array to the calibration data block instead of the actual computed calibration thresholds. pandrew-util never shows the bogus threshold constant I came up with after 2nd and subsequent boot-ups, only sane thresholds.

This would seem to imply that without the EECONFIG offset fix, the values from EEPROM that load_matrix_calibration() is reading into the header struct are in fact not passing the validation checks, and that with the offset fix, they are passing validation. It looks like you are checking to make sure that the row and column numbers match the expected keyboard type and are even computing a rudimentary checksum based on the keymap, so it would be pretty amazing if the stars were aligning 100% of the time for these values to somehow magically always prove to be "correct" but for the data to have either been read from or written to the wrong starting offset. So this makes me think there's some subtle size computation or pointer arithmetic error somewhere...but at a quick glance, everything that load/save_matrix_calibration() is doing seems reasonable and straightforward...hmm... OH and you also store the header twice: once at the beginning, and once at the end, and both copies are still passing validation!

EDIT: Hmm I wonder if some other component within this QMK build -- VIA or Vial perhaps? -- is overwriting the part of the EEPROM you are storing the calibration data in, but past the point of your checksum header and also without touching the duplicate header at the end?

EDIT 2: I'm starting to think that must be what's going on. A cursory glance at quantum/via.h suggests that VIA defines the offset for its own magic number as EECONFIG_SIZE, so VIA itself is assuming that it can safely store its own stuff in EEPROM immediately after the end of the EECONFIG block. So it sounds like both you and VIA are in contention for that section of the EEPROM.