I finally worked up the courage to flash the keyboard, and now everything works wonderfully. Thank you so much for your help!NathanA wrote: ↑14 May 2022, 02:31So making the first option work (simulated Num Lock using QMK layers) turned out to be easier than I thought.
Of course, I did it within Vial. Should also be possible to do in VIA, too, if you prefer. I'm attaching my Vial layout file in case you want to give it a go. To use it, you will first need to download my Vial hex files (first flash eeprom_erase.hex, wait 5 seconds after it's finished, unplug/replug keyboard, then flash the F77 hex file), then download the Vial app, and finally run Vial and then File (menu) > Load Saved Layout... and load in the attached "vil" file (linked at the end of this post).
Default state is Num Lock is off & keypad functions match right block option #4 nav commands. If keyboard gets unplugged/replugged while Num Lock is on, it won't remember that and will default back to nav commands. Since this doesn't rely on the PC's Num Lock status, it will now be impossible for software to either toggle Num Lock or for you to trust what it claims the actual status of Num Lock is on your keyboard (it won't have any way of knowing), so if you forget what state it's in, you won't know whether it's On or Off until you try hitting a key.
This solution should also be reproducible in the web QMK Configurator, too, with the one exception of double-zero: this turned out to be easy to do using VIA/Vial macros, but QMK Configurator doesn't let you define simple macros. If you wanted to do a double-zero key with pure QMK, you'd have to set up a working build environment first and then edit your keymap.c file directly to define said macro before compiling your hex.
Implementation is simple: layer 0 is default layer with all key functions and with the right block set up to transmit the nav command keys. "Num Lock" key is set to TG(1) to toggle layer 1. Layer 1 has all keys fall through to layer 0 (including Num Lock...don't set that to TG(0)...I tried that & it doesn't work) except for the keys in the keypad that should transmit numbers instead, which you need to set to the top-row-above-alpha numbers, not to the numpad numbers (otherwise "real" Num Lock would have to be on for them to transmit numbers!). Everything that was *previously* on layer 1 is moved to layer 2, and whatever key you want to use as Fn on layer 0 has to be changed from MO(1) to MO(2). (Also, set Spacebar on layer 2 to blank instead of MO(2) which is now nonsensical.)
Since while running Vial with all features there isn't enough memory in the controller for more than 3 layers, the few kinda "QMK-meta" keys (like restart in bootloader mode, etc.) can no longer exist on their own layer. So you will have to find some spare keys on the 3rd layer (actually called layer 2, since layer numbers start at 0) to put those on. Previously bootloader mode was set to 'R' for Reset, but you probably don't want to risk accidentally tripping that while trying to engage your Fn layer for everyday tasks. In the layout file that I attached, I chose to put bootloader mode and NKRO toggle on the keypad - and + keys respectively, which should be well out of harm's way. So with this layout, you would now hit Fn and keypad - to get to bootloader mode instead of Fn + Spacebar + R.
Also, since Num Lock is now occupying the space it is assigned in right block option #4 (upper-left key of keypad), the right blank key between right Alt and right Ctrl is now free. So in this layout, that key is now Fn and right Ctrl is an actual Ctrl key.
Getting this working helped me out, too, since now using this keyboard while plugged into a Mac is not nearly so painful...
Hope this helps & have fun!
F104+SSK+122+62+77+50+Ergo orders now open! New Kishsaver+Industrial Model F Keyboards
-
- Main keyboard: New Model F F77
- Main mouse: Logitech MX518
- Favorite switch: Buckling spring/Cherry MX Green
Last edited by HatefulLight on 20 May 2022, 17:53, edited 3 times in total.
- Sheepless
- Location: United Kingdom
- Main keyboard: IBM Model F122
- Main mouse: Logitech G502
- Favorite switch: IBM buckling spring
I've only been able to get my ANSI enter key working reliably by substituting a genuine IBM model M key. The supplied new model F enter key binds. I've repeatedly tried the "wiggle" process described in the manual, to no effect. I also tried, as per the manual, using a piece of foam to reduce the travel of the key, but this didn't help.
Fortunately, I have a number of model M keyboards, so I was able to try two genuine IBM model M enter keys, which both worked beautifully, and so far I've had a couple of days of flawless operation from one of them. If I try the new model F enter key in the model M donor keyboard, it binds immediately.
This looks like a manufacturing defect to me, and I believe I need a replacement enter key.
Fortunately, I have a number of model M keyboards, so I was able to try two genuine IBM model M enter keys, which both worked beautifully, and so far I've had a couple of days of flawless operation from one of them. If I try the new model F enter key in the model M donor keyboard, it binds immediately.
This looks like a manufacturing defect to me, and I believe I need a replacement enter key.
-
- Main keyboard: OG Model M / Repro F77
I've just taken delivery of my new F77, and fitted the foam underlay to it -- but I've got as far as the space bar before realising that the stabiliser wire needs to go in the clips, which are now under the foam layer.
Is this just a matter of cutting a suitable slot in the foam, or have I misunderstood how this fits together?
Is this just a matter of cutting a suitable slot in the foam, or have I misunderstood how this fits together?
-
- Location: UK
- Main keyboard: Filco ZERO green alps, Model F 122 Terminal
- Main mouse: Ducky Secret / Roller Mouse Pro 1
- Favorite switch: MX Mount Topre / Model F Buckling
- DT Pro Member: 0167
- Muirium
- µ
- Location: Edinburgh, Scotland
- Main keyboard: HHKB Type-S with Bluetooth by Hasu
- Main mouse: Apple Magic Mouse
- Favorite switch: Gotta Try 'Em All
- DT Pro Member: µ
-
- Location: USA
- Main keyboard: Model M
- Favorite switch: Buckling spring
- DT Pro Member: -
Uhm. What foam layer?
You're not talking about this foam, are you?
If so, you didn't have to buy that to make your brand new keyboard usable, and you also didn't have to install it manually upon receipt if you did buy it. It is *extra* foam...as in, replacement. For when the foam that's already installed in your keyboard wears out a couple of decades from now.
The foam layer doesn't go between the top plate of the keyboard and the keys, which is where it sounds like you are trying to put it? It goes *inside* the keyboard assembly, *underneath* the top plate, between it and the circuit board, hidden from view.
All you have to do when you receive your brand new keyboard is to put the keys and the stabilizers in the barrels, according to whatever key layout you desire. There's no foam to be installed by hand. Foam is already pre-installed. The foam layers that are sold alongside the keyboard are spare service parts, not a mandatory component that needed to be purchased separately and then put in place as part of the "some assembly required" process. They are offered separately because it's known that over time, the original foam will deteriorate and eventually need to be replaced (and also offered for sale to owners of original nearly-40-year-old keyboards that IBM made whose foam has already rotted out and needs to be replaced).
- robo
- Location: Minneapolis, MN, USA
- Main keyboard: IBM Model M SSK (1993)
- Main mouse: Logitech M570
- Favorite switch: Buckling Spring
- DT Pro Member: -
The comments about foam made me wonder - once the original foam has deteriorated, won't the spare foam have deteriorated too? Or is it more wear than age?
-
- Location: USA
- Main keyboard: Model M
- Favorite switch: Buckling spring
- DT Pro Member: -
Good question; unfortunately, my sense is that nobody knows the actual answer. IBM themselves likely didn't know that the particular foam that they used would deteriorate the way it did and at the rate that it did...either that or they figured the keyboards they manufactured would not be in active service for as long as they have ended up being and so didn't worry themselves about it.
Unlike virtually all other aspects of this keyboard where Ellipse attempted to meticulously re-create as many of the small details as possible down to exact materials used, I am almost positive that the foam being used & sold as spares here is not actually the same as the original IBM foam. It might have similar properties, but fairly certain it isn't the same material. Thus we probably don't actually know if it will survive better than the original stuff, or deteriorate even more quickly.
-
- Location: United States
- Main keyboard: Brand New Model F Keyboards
- DT Pro Member: -
- Contact:
Great NoWinKeys; glad everything arrived safely!
Sheepless please email me some photos of the issue if you don't mind. Thousands of enter keys have gone out and I don't recall having to replace an enter key for getting stuck. I do have a few spares though
robo the main issue is that the foam retains a compression set after it has been installed in the keyboard for a number of years. With the foam I selected originally for the project, when stored uncompressed in a cool dry place it was tested to have a long shelf life. That is why I recommend the first aid kit which includes a spare foam.
NathanA not sure if you saw my post last year about the foam (linked below) but the original foam used for this project was confirmed not the foam that IBM used, but the foam installed in the most recent batch of keyboards is one type of foam to my knowledge that IBM used. The spare foam I send out is still from that earlier, non-original batch and there is currently no option to order spares of the new material of foam. viewtopic.php?f=50&t=11046&p=488162&hilit=foam#p488162
Sheepless please email me some photos of the issue if you don't mind. Thousands of enter keys have gone out and I don't recall having to replace an enter key for getting stuck. I do have a few spares though
robo the main issue is that the foam retains a compression set after it has been installed in the keyboard for a number of years. With the foam I selected originally for the project, when stored uncompressed in a cool dry place it was tested to have a long shelf life. That is why I recommend the first aid kit which includes a spare foam.
NathanA not sure if you saw my post last year about the foam (linked below) but the original foam used for this project was confirmed not the foam that IBM used, but the foam installed in the most recent batch of keyboards is one type of foam to my knowledge that IBM used. The spare foam I send out is still from that earlier, non-original batch and there is currently no option to order spares of the new material of foam. viewtopic.php?f=50&t=11046&p=488162&hilit=foam#p488162
I'd say that storing it in a different place and in different ambiant will have a different result... As Ellipse says: cool dry place, non compressed. I'd add: maybe in a plastic cover that will stop the chemicals from evaporating in the long run?
Well, you're 1000% right... Two parts of my nervous system want two different things. And my brain definitely don't want what my hands want, which I could bring back just by loading the previous simple Vial layout I saved earlier. No need to complicate things.NathanA wrote: ↑20 May 2022, 10:36Now, wait just a minute: isn't this EXACTLY what you originally complained that you DIDN'T want, because you wanted to be able to do Shift+[direction key] to select text or other objects when Num Lock is off? And this is the whole reason why we came up with a way to do "pseudo" Num Lock in the first place? And now you are saying that you want to go back to that??sedevidi wrote: ↑18 May 2022, 10:14I now have a functionnal right block option #3 (old-style numpad), which is great, and resurface muscle memory from the last century: my fingers want to Shift+[direction key in layer 0] to type number... [...] Is there a QMK way to do this: layer 0 numpad left/4 key would ouput "Left" when Shift is UP, and "4" when Shift is DOWN.
(feeling dumb)
I don't want to make you work just for my convenience. And I also can't prevent you from doing itNathanA wrote: ↑20 May 2022, 10:36I'm not aware of anyone that has built and distributed binaries for Linux (given the utility has dependencies on things like Qt, it can be non-trivial to build a statically-linked version of it that works on all Linux distributions). But of course the source code for it exists, and there are Linux build instructions included by pandrew in the README. If you can tell me which precise distribution of Linux (and version of that distribution), I can likely build you a copy (though no guarantees on how quickly I can get around to it). Or can direct you to where to get the source and then you can build it yourself.
Debian bullseye 11.3 (QT 5.15.2) with the additionnal backports repository (QT 6.2.4)
My Left Ctrl is still unreliable, but way better than initially... In the meantime I'll re-read the manual, then reseat/stretch the spring and test the result.
- Muirium
- µ
- Location: Edinburgh, Scotland
- Main keyboard: HHKB Type-S with Bluetooth by Hasu
- Main mouse: Apple Magic Mouse
- Favorite switch: Gotta Try 'Em All
- DT Pro Member: µ
More like "feeling human." We're all full of inner contradictions.
I patch a lot of things like this with Karabiner. "My fingers want" different behaviours in different contexts the keyboard has no means to know. Host-side logic makes most sense for me, as most of them depend on which app is foreground, rather than any (pseudo) mode the keyboard is in.
I forked the qmk firmware and added the changes from the purdea.ro repository as per instruction on the website. I was a bit confused as the purdea code seems outdated quite a bit compared to the official repo. Is there any up to date qmk repo that includes the xwhatsit changes for the f77 and others? In any case I put mine here: https://github.com/helohe/qmk_firmware
Mine includes some custom keymap and a code change to have the solenoid actuate on every key press. I did not test it yet though.
Mine includes some custom keymap and a code change to have the solenoid actuate on every key press. I did not test it yet though.
-
- Location: United States
- Main keyboard: K95 RGB PLATINUM - CHERRY MX RGB BLUE
I just connected my F77 solenoid and noticed the light blinks with each key press, but the solenoid does not move? Can anyone provide specific steps to get the solenoid fully functional? Or is this related to another issue?
I have lost track of what keys are available, and in what colors, languages and so on. Concerning the ISO Enter: Would the mold only be used for black, dark grey and blue, or pearl and pebble, too?Ellipse wrote: ↑18 May 2022, 21:37I am looking into making a mold for the ISO Enter key (currently we are using Unicomp keys for this key as noted before, and they cannot make the additional colors for black and for gray and blue to match my project's key colors). This would allow for key sets with ISO Enter to be made in additional project colors black, 60% dark gray, and Industrial SSK Blue. I will probably make the key non-stepped just like the other keys are all non-stepped.
If you are interested please fill out the Google form below to note which sets you'd like. To help pay for the mold each set will cost $20 extra, a total of $99 instead of $79 for each set. The key could also be ordered for $20 individually.
(…)
Since I am making a mold would any other keys be worth adding that have not been made before? I don't think the big PC AT enter key or code key would have enough interest to merit $1000 extra for the mold costs but it would be lower than having a completely separate mold.
-
- Location: USA
- Main keyboard: Model M
- Favorite switch: Buckling spring
- DT Pro Member: -
Your binary is attached.
You will need to 'apt install' both 'libhidapi-libusb0' as well as 'libqt5widgets5' (though sounds like you likely already have latter installed).
If you want to be able to run the app as non-root user, then you also need to stick a file (call it whatever...e.g., 'modelf.rules') in /etc/udev/rules.d/ with the contents:
Code: Select all
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="ffc0", MODE:="0666"
- Attachments
-
- pandrew-util-vial-compat_debian-bullseye.zip
- (94.69 KiB) Downloaded 98 times
-
- Location: USA
- Main keyboard: Model M
- Favorite switch: Buckling spring
- DT Pro Member: -
No. Which is exactly why the web site instructs you to take the keyboards/xwhatsit directory from pandrew's repository and merge it into your own copy of QMK 'master' branch assuming that you actually want to run the latest QMK code.helohe wrote: ↑21 May 2022, 12:54I forked the qmk firmware and added the changes from the purdea.ro repository as per instruction on the website. I was a bit confused as the purdea code seems outdated quite a bit compared to the official repo. Is there any up to date qmk repo that includes the xwhatsit changes for the f77 and others?
I presume that pandrew's respository is relatively outdated because that version of QMK is likely the one that he started working from when he wrote his xwhatsit controller support. Since that version of QMK has already been "vetted" and is known to work fine, especially with his xwhatsit driver...why change it? 'master' is for people who want to live on the bleeding edge and don't mind having to potentially deal with exotic new and unknown bugs...ones that might interact badly with the pandrew code in as-yet unknown ways. But if you (or anyone else) wants to pull the latest from QMK 'master' and run that on your keyboard, nothing's stopping you. Open source, baby...
ok sounds good then. btw., I had to do one more additional step that was not in the manual: in the file keyboards/xwhatsit/util_comm.c changeNathanA wrote: ↑22 May 2022, 11:29No. Which is exactly why the web site instructs you to take the keyboards/xwhatsit directory from pandrew's repository and merge it into your own copy of QMK 'master' branch assuming that you actually want to run the latest QMK code.helohe wrote: ↑21 May 2022, 12:54I forked the qmk firmware and added the changes from the purdea.ro repository as per instruction on the website. I was a bit confused as the purdea code seems outdated quite a bit compared to the official repo. Is there any up to date qmk repo that includes the xwhatsit changes for the f77 and others?
I presume that pandrew's respository is relatively outdated because that version of QMK is likely the one that he started working from when he wrote his xwhatsit controller support. Since that version of QMK has already been "vetted" and is known to work fine, especially with his xwhatsit driver...why change it? 'master' is for people who want to live on the bleeding edge and don't mind having to potentially deal with exotic new and unknown bugs...ones that might interact badly with the pandrew code in as-yet unknown ways. But if you (or anyone else) wants to pull the latest from QMK 'master' and run that on your keyboard, nothing's stopping you. Open source, baby...
#include <tmk_core/common/eeprom.h>
to
#include <platforms/eeprom.h>
-
- Location: USA
- Main keyboard: Model M
- Favorite switch: Buckling spring
- DT Pro Member: -
Yes, I addressed this in another post a few weeks ago.
Oh, I did not see this. Perfect, thanks
- Clavius
- IBM aficionado
- Location: Netherlands
- Main keyboard: IBM 5155
- Favorite switch: Model F buckling spring
- DT Pro Member: 0193
I tried searching this thread with a couple of keywords but couldn't find an answer. So hopefully not a too common question:
I've ran my F77 for a day since I got it, and noticed that on certain keys and in certain conditions, I get two characters instead of one. This mainly happens to the letter 'M', and only when the letter is typed twice in close succession, like when typing 'hammer' it sometimes comes out as ' hammmer'. Not sure what the correct term for this is. The keys in question all sound normal, and behave normal when pressed slowly, so I'm expecting it to be something related to threshold levels or something.
Did anyone else have this? What is the way to go to sort it out? Thanks!
I've ran my F77 for a day since I got it, and noticed that on certain keys and in certain conditions, I get two characters instead of one. This mainly happens to the letter 'M', and only when the letter is typed twice in close succession, like when typing 'hammer' it sometimes comes out as ' hammmer'. Not sure what the correct term for this is. The keys in question all sound normal, and behave normal when pressed slowly, so I'm expecting it to be something related to threshold levels or something.
Did anyone else have this? What is the way to go to sort it out? Thanks!
-
- Location: United States
- Main keyboard: Brand New Model F Keyboards
- DT Pro Member: -
- Contact:
New Solenoid Installation Video:
MrRobot49 did you try flashing the latest firmware? There was a bug in the older firmware.
yaun feel free to see the full list of extras on the Extra Keys store page on the project web site. The available full key sets are on the Full Key Set product page.
Yes the mold would be used for pearl and pebble too once I run out of supply of the Unicomp stepped keys.
Clavius as noted before the 2 grounding screws on the controllers sometimes need to be retightened as it causes the errors you are describing. Also it may be an issue requiring the re-seating or replacement of a spring.
MrRobot49 did you try flashing the latest firmware? There was a bug in the older firmware.
yaun feel free to see the full list of extras on the Extra Keys store page on the project web site. The available full key sets are on the Full Key Set product page.
Yes the mold would be used for pearl and pebble too once I run out of supply of the Unicomp stepped keys.
Clavius as noted before the 2 grounding screws on the controllers sometimes need to be retightened as it causes the errors you are describing. Also it may be an issue requiring the re-seating or replacement of a spring.
- Sheepless
- Location: United Kingdom
- Main keyboard: IBM Model F122
- Main mouse: Logitech G502
- Favorite switch: IBM buckling spring
tbh it's hard to know what to photograph, since there's nothing obviously visibly wrong with the keycap. The one thing which stands out is a possible misalignment of the stabiliser post. Here are a couple of closeups.
First, a genuine IBM enter:
Note that the stabiliser post is pretty much at 90 degrees to the key body. If anything, there's a very slight lean towards the right.
Contrast this with the new model F enter key:
This leans noticeably to the left. When installing this key, the post appears close to the left side of the stabiliser hole, whereas the IBM key's post is nicely centred.
Going through my IBM kit, I've found three genuine IBM ANSI enters. All of them work perfectly in the F77, regardless of where I hit the key. If I install the new key, I need to take care to hit it on the left, over the stabiliser. Anywhere else, and it fails to register about one time in 6-10 hits. And at this point, sometimes it's game over, and the key won't come back to life until I remove and reinsert the key.
-
- Location: United States
- Main keyboard: Brand New Model F Keyboards
- DT Pro Member: -
- Contact:
Yes I think you are right! That key may have been damaged in shipping. If there's no way to gently push the stabilizer back into place please send me an email to arrange a replacement key.
-
- Main keyboard: New Model F77
- Main mouse: Zowie EC1-A
- Favorite switch: Capacitive Buckling Springs
I got my F77 in the mail a few weeks ago, and it has successfully helped me survive finals week. The experience has been incredible so far. Thank you to Ellipse, the firmware hackers, and everyone else making this project possible!
I switched to the dark blue case for the summer, so here's a few photos of what that looks like.
Out on the deck. The dark blue is a fittingly summery atmospheric blue.
A snippet of my setup. On the off chance anyone is curious, the mouse is a BenQ Zowie EC1-A; the lamp is an Anglepoise Type 75 Mini, another classic spring mechanism in its own right.
I switched to the dark blue case for the summer, so here's a few photos of what that looks like.
Out on the deck. The dark blue is a fittingly summery atmospheric blue.
A snippet of my setup. On the off chance anyone is curious, the mouse is a BenQ Zowie EC1-A; the lamp is an Anglepoise Type 75 Mini, another classic spring mechanism in its own right.
-
- Location: United States
- Main keyboard: Brand New Model F Keyboards
- DT Pro Member: -
- Contact:
Nice looking photos and setup Neightro! Thanks for sharing these photos. I believe this is one of the first Dark Blue powdercoated keyboard photos that has been shared! I like the use of the buckling spring logo key as perhaps the function key - makes for a nice custom touch for the layout.Neightro wrote: ↑23 May 2022, 03:29I got my F77 in the mail a few weeks ago, and it has successfully helped me survive finals week. The experience has been incredible so far. Thank you to Ellipse, the firmware hackers, and everyone else making this project possible!
I switched to the dark blue case for the summer, so here's a few photos of what that looks like.
Out on the deck. The dark blue is a fittingly summery atmospheric blue.
blue-f77-1.jpeg
A snippet of my setup. On the off chance anyone is curious, the mouse is a BenQ Zowie EC1-A; the lamp is an Anglepoise Type 75 Mini, another classic spring mechanism in its own right.
blue-f77-2.jpeg
-
- Location: United States
- Main keyboard: Brand New Model F Keyboards
- DT Pro Member: -
- Contact:
Does anyone have details on the old IBM Model M LED overlays? What kind of plastic were they? Were they printed or dye sublimated? I'd like to make some with the intention of covering the LED holes on the beam 104 keyboards. Zed has worked up a nice reproduction of the IBM originals, plus some more modern-looking ones with alternative color schemes. Since they are printed (?) it's probably doable to offer a bunch of options.
In order to still be able to attach the feet, here is what I did instead: I installed the controller and connections and so on. Then I switched the solenoids spacer bracket (the one that controlls the intensity) to the other side, so that the cable is on top. I then found a sturdy metal ruler that is about the same width as the solenoid. This I fixed with tape to the solenoid from down and from the sides. I.e., so that that the tape does not touch any of the blue covering of the solenoid and so that it only sticks to the metal parts.
I then taped the ruler to the inside of the bottom case so that the solenoid is approximately in the middle, with still enough space for the controller and the feet. This allows me to change the feet whenever I want without having to mess with the solenoid. Also this seems strong enough that the solenoid cant possibly move around.