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

[Ellipse]

Here are some additional photos of the various compact case colors, including the new color options. All feature the new, more durable powdercoating instead of the old anodizing from the earlier batch.

20220427_213639.jpg (2.71 MiB) Viewed 10255 times

20220427_213650.jpg (3.5 MiB) Viewed 10255 times

20220427_213654.jpg (3.96 MiB) Viewed 10255 times

20220427_213659.jpg (4.58 MiB) Viewed 10255 times

[NathanA]

Regarding the timing of the PROG shorting work, I just left PROG shorted to ground and then plugged in the USB. From your description it sounds like the PROG shorting needs to be intermittent during power-up. That will be hard to do by myself with, for example, a paperclip and then plugging in the USB. I will get help and report back. Meanwhile, do you happen to know if there is a specific timing window for shorting prog?

Sorry, I had been traveling when you posted and so didn't have my keyboard to test with (contrary to rumors you may have heard I do not lug my F77 with me wherever I go ). I do remember really, really struggling with getting the bootloader to come up into DFU mode using the PROG pad the very first time I tried it, and while trying to figure out what I must be doing wrong, I thought I had remembered reading or seeing/hearing someplace (Youtube?) that you needed to stop bridging PROG within some set period of time after applying power. However, looking over the datasheet for the ATmega32U2, I'm not finding any evidence of this requirement. And just today I tried putting my keyboard into DFU mode multiple times by jumping PROG, and I kept it bridged for several seconds each time and it still worked every time...piece of cake. So not only is my memory clearly faulty, I also cannot explain why I had so much trouble that first time.

Just to be clear, though: you say you are "grounding" PROG. What specifically do you mean by that? "PROG" is not a pin on the microcontroller chip, but is in reference to two exposed pads on the PCB, one of which is attached to the MCU's "HWB" (for "hardware boot") pin, and the other of which is grounded. All you have to do is connect those two pads together, which pulls HWB low, and then apply power while it's being pulled low. If you're thinking you need to take both of those pads and then join them & connect them both together to some other ground plane...no.

I am concerned I have overwritten the atmega32u2 USB bootloader code if indeed I flashed the wrong xwhatsit firmware. Does anyone know if the QMK configurator / QMK Toolbox flashing process exposes that risk (or is the bootloader code left untouched by firmware flashing)?

QMK uses dfu-programmer behind the scenes. NathanA dug into this a few posts ago. Reading the dfu-programmer man page, I'd say that overwriting the bootloader should be difficult, potentially impossible, or at least impossible to not notice.

This is correct. I do believe it is impossible to instruct the Atmel DFU bootloader to overwrite itself, which is essentially what would need to happen for this to be a possibility. About the only way I could conceive of wiping out or scrambling the bootloader without directly wiring up a JTAG or ISP to the chip itself would be if you burned some code to the MCU's flash that in turn tried to write to the section of flash that contains the bootloader, and there's no way I can see any QMK binaries actually causing bootloader corruption like that, intentionally or unintentionally. The most likely explanation is that there is something that you aren't quite doing correctly when it comes to physically kicking it into DFU mode.

Then downloaded VIA, loaded "Via program - load this if you have the F77" and made the changes.

Unplugged and plugged back the keyboard. It's not recognized. Now I see "Brand New Model F Keyboards" in " ioreg -p IOUSB" but no key presses.

Hi, new owner of the F62 kishsaver. I tried using the VIA hex as well but no key input detected, so the file is outdated and there's no way to have it work currently?

At this point it seems exceedingly clear to me that Ellipse either needs to rebuild his VIA hex files so that they are safe to use with the latest revision of the wcass controller, or if he is incapable of doing that, pull them from the download entirely, in order to prevent others from soft-bricking their keyboards this way. This is getting ridiculous.

How are folks programming the right side blocks 3, 4 and 5? If anyone has made JSON files that are the same as the ones I provided, but with adjustments for the right side blocks 3/4/5 please do share! I guess the secondary legends are set up as a function layer, or maybe a tap layer to mimic the functionality of the Num Pad key?

Right side block option #3 which mimics a standard number pad as much as possible is my preferred layout, and I already distributed both a VIA .json and a Vial .vil of that layout with my copy of Vial firmware that I posted here last year, but only in a form that assumes you also have HHKB split right-shift (named "zF77_-_HHKB_split_shift,_everything_else_ANSI_-_Option3").

The secondary legends are active with Num Lock off, just like a regular number pad. But I also added the secondary functions to the second function layer, so that they can be accessed one-off while Num Lock is on. I also mapped Scroll Lock to Fn > NumLock, Print Screen to Fn > -, and Pause to Fn > +

(It's not clear to me that it would be possible to make the secondary legends for right side block options 4 and 5 usable with Num Lock off just by editing the layout...this might require some changes to QMK itself. Will have to look more deeply into this. This "just works" out of the box with option #3 since all of those scan codes already existed for the standard 101-layout numpad.)

Making separate versions of layout files with all 5 possible right side block options is going to result in an exponential explosion of the number of layout files (since you also have to make versions of these for every other conceivable main block layout, too, since the main block and the right block can't be configured in bulk separately...so, not only keyboards with non-split right-shift, but also proper HHKB with split backspace, ISO, etc.). Because of this, it seems like the only civilized way of dealing with this is to standardize on either VIA or Vial (I vote for the latter, likely unsurprising to many at this point) rather than on basic QMK, and then distribute just the .json or .vil files containing the layouts, like I did when I packaged up my copy of Vial. Otherwise you are going to have to multiply the number of hex files you are building and distributing even beyond the crazy number that you are already having to juggle today. If VIA or Vial were the standard moving forward (& preloaded on keyboards that you ship out), then both you *and* your users would only have to deal with *two* total hex files: one for the F62, and one for the F77. Not one hex for every conceivable layout, which just strikes me as pure madness. Then they would load the layout of their choice into the keyboard using VIA/Vial after flashing the main hex. This would just be way more user-friendly for the vast majority of people, and also makes things way less confusing whenever a firmware update comes out. And if somebody genuinely prefers raw QMK, they still have the option of building and flashing that themselves after they receive their board.

I've been thinking about making a Youtube video on flashing and running Vial on the Model F Labs boards. I just haven't had the spare time to put that together yet.

[Croktopus]

I've been thinking about making a Youtube video on flashing and running Vial on the Model F Labs boards. I just haven't had the spare time to put that together yet.

haha i would love that, as one more person who has a metal brick in the shape of an f77 right now. pretttty sure i followed the tutorial video exactly, and used the provided files correctly. or if you could just upload a vial hex somewhere that would be dope, maybe you already did and i just am too bad at searching though

[NathanA]

[...] as one more person who has a metal brick in the shape of an f77 right now. pretttty sure i followed the tutorial video exactly, and used the provided files correctly.

Did you just recently receive your keyboard, and did you try to flash VIA to it? That would cause it to turn into "a metal brick". As previously discussed, the design of the controller board underwent a slight revision mid-production, and that revision requires a change to the firmware. The QMK hex files got updated to support the new version of the controller board, but the VIA ones still have not for some inexplicable reason, and thus the VIA hex files are incompatible with the current batch of keyboards being shipped out. This has been leading to people soft-bricking their keyboards (because there is no warning attached to the VIA firmwares in Ellipse's download, and also because who is going to read through a 240-page thread before trying to go through the official instructions?).

Since the keyboard in this state can't detect any keypresses, and since the pandrew utility is not compatible with either darkcruix's or Ellipse's VIA builds, there is no way to kick the keyboard back into bootloader mode in order to correct this issue short of opening it up (again, see recent previous posts).

or if you could just upload a vial hex somewhere that would be dope, maybe you already did and i just am too bad at searching though

• Link to my original post with first working copy of Vial firmware for F77 attached
  (don't download this one as it's also not compatible with the updated controller board design; just linking to it for the notes/documentation/general info about Vial)
  `
• Link to my post with updated copy of Vial firmwares that are compatible with new controller
  (this is a complete package that contains copies of all the various layout files, and which is updated to support the revised controllers so is safe to flash to the most recent batch of keyboards)
  `
• Link to the most recent version of Vial firmware I've made specifically for the F77
  (fixes a couple of minor issues, but this is NOT a complete package, so I advise you download the package from the previous link plus this one, but use the hex file from this last link)

I eventually intend to post an up-to-date complete package that again encompasses both the F62 and F77 and which includes all of the fixes up to this point in time.

[gwils]

Hello, I have recently received my F77, and I am astounded by its quality. Thank you!
I am experiencing a problem, with which I would appreciate some assistance. I have read the troubleshooting section of the manual already.

My 'R' key seems to register strangely in relation to other keys. It is as though the R has a slight delay (I don't know whether it is delayed or not, but that's how it "feels").

Example 1:
If I type "ORG", I strike R and G with two separate fingers, almost simultaneously, but with the R first. On every other keyboard this will type "ORG", but on my Model F, it types "OGR". Slowing down fixes the issue.

Example 2:
If I want to type a capital R, I will hit shift and R with two separate fingers, almost simultaneously, but with shift first. I want an uppercase R, but I will usually get a lower-case r. This does not happen with other keys. Delaying the R press slightly fixes the issue.

I have not noticed this kind of key ordering problem with any other keys. I have tried Example 2 with other keys, including those on the same row as R and the same column as R, and they don't have the same problem. It is as though something is up with the R key in particular. This happens on multiple computers.

Please help, and thank you again.

[Ellipse]

My apologies for not following up on the Via issues.

Any ideas on the following compile error? I am following darkcruix's Via compile instructions which have worked in the past.

Compiling: quantum/bootmagic/bootmagic_lite.c quantum/bootmagic/bootmagic_lite.c: In function ‘bootmagic_lite’:
quantum/bootmagic/bootmagic_lite.c:44:19: error: ‘BOOTMAGIC_LITE_ROW’ undeclared (first use in this function)
uint8_t row = BOOTMAGIC_LITE_ROW;
^
quantum/bootmagic/bootmagic_lite.c:44:19: note: each undeclared identifier is reported only once for each function it appears in
quantum/bootmagic/bootmagic_lite.c:45:19: error: ‘BOOTMAGIC_LITE_COLUMN’ undeclared (first use in this function)
uint8_t col = BOOTMAGIC_LITE_COLUMN;
^
[ERRORS]
|
|
|
make: *** [builddefs/common_rules.mk:456: .build/obj_xwhatsit_brand_new_model_f_f77_wcass_default_fff892d/quantum/bootmagic/bootmagic_lite.o] Error 1
a@ubuntu:~/qmk_firmware$


To quote darkcruix's notes:

"Design changes on the Firmware:
The code changes on the QMK firmware are minimal. Initially the util_comm.c needs to be adjusted
…
void raw_hid_receive_kb(uint8_t *data, uint8_t length) {
if (0 != memcmp(data, magic, sizeof(magic))) {
return;
}
…

Within the specialized firmware itself the following adjustments are required:
config.h: - here: standard F62 variant
#pragma once
#include "config_common.h"
#undef PRODUCT
#undef MANUFACTURER
#undef DESCRIPTION
#undef PRODUCT_ID
#define MANUFACTURER Brand New Model F Keyboards
#define PRODUCT Brand New Model F Keyboards - F62
#define DESCRIPTION Brand New Model F Keyboards F62
#define VENDOR_ID 0x0481
#define PRODUCT_ID 0x00F0
#define TAPPING_TERM 200
#define TAPPING_TOGGLE 2
#undef BOOTMAGIC_ENABLE
#undef BOOTMAGIC_LITE


(important – need to remove above items under USB Device Descriptor section – cannot have duplicates) 

rules.mk:
VIA_ENABLE = yes
COMMAND_ENABLE = no
NKRO_ENABLE = no
LTO_ENABLE = yes
MOUSEKEY_ENABLE = yes
EXTRAKEY_ENABLE = yes # Audio control and System control
CONSOLE_ENABLE = no # Console for debug
"

[Croktopus]

I eventually intend to post an up-to-date complete package that again encompasses both the F62 and F77 and which includes all of the fixes up to this point in time.

haha yeah i tried downloading one of those links with a 2 part 7z file earlier and none of the unzippers could handle it for some reason idk. but ill try that latest one when i get home, thanks for the link!

i did eventually find the qmk configurator link so my f77 is working again. not a huge fan of the bootsel pads on the hidden side of the pcb, especially when the ribbon cable seems to be thick solid core wire - feels like im gonna break something trying to flash a new firmware lol, but that should be alright now

[Croktopus]

My apologies for not following up on the Via issues.

Any ideas on the following compile error? I am following darkcruix's Via compile instructions which have worked in the past.

Adding this code to your config.h should solve that compile error:

#define BOOTMAGIC_LITE_ROW 0
#define BOOTMAGIC_LITE_COLUMN 0

i believe the source of that error is that enabling via also enables bootmagic lite, or its own version of bootmagic lite, according to the docs here https://www.caniusevia.com/docs/configuring_qmk

beyond that, im not sure im not that familiar with the bones of qmk, but i hope that helps

[NathanA]

haha yeah i tried downloading one of those links with a 2 part 7z file earlier and none of the unzippers could handle it for some reason idk.

Yeah, the DT forum forces me to do multipart on account of attachment size limits. It would all fit in one file if it weren't for that pandrew utility, which is like 17 megs uncompressed (I think it has the QT library statically linked to it). I'd like to also build & include a macOS version of my modified pandrew utility in the future, which would further increase the archive size...perhaps I should just separate out the pandrew utility builds into a separate archive.

Anyway, as long as you have both archive parts in the same directory, and you also rename them from 001.7z > 7z.001 and 002.7z > 7z.002 (I had to rename them to upload, because the DT forum software also enforces filename extension limits!! ...and I pointed this out in my October 2021 post), then you should have no trouble unpacking these with 7-Zip by opening up the 7z.001 file. Not sure if you are on Windows, Mac, or Linux...on Windows there is of course a 7-Zip GUI. On Linux, you can use '7z' (on Debian or Ubuntu, install package 'p7zip-full'). On Mac, there might only be a CLI version available but it would work identically to the Linux one.

not a huge fan of the bootsel pads on the hidden side of the pcb, especially when the ribbon cable seems to be thick solid core wire - feels like im gonna break something trying to flash a new firmware lol

I am 1,000% with you. Even if the pads couldn't practically be relocated to the exposed side for some reason, then put a button on them, or at the very least a 2-pin jumper block...something!

My apologies for not following up on the Via issues.

Any ideas on the following compile error? I am following darkcruix's Via compile instructions which have worked in the past.

Adding this code to your config.h should solve that compile error:

#define BOOTMAGIC_LITE_ROW 0
#define BOOTMAGIC_LITE_COLUMN 0

*ding*! *ding*! *ding*! Winner winner chicken dinner; you beat me to it. I had to do the same thing to get Vial to build, and for the same reason, because at the firmware level, Vial is actually built atop VIA. (Completely different story on the computer/host utility side, but I digress.)

The various xwhatsit config.h files in fact already have #defines for BOOTMAGIC_LITE_ROW/COLUMN in them, but they're just commented out. In the f77/wcass config.h, for example, they're at lines 251-252:

Code: Select all

/* Bootmagic Lite key configuration */
// #define BOOTMAGIC_LITE_ROW 0
// #define BOOTMAGIC_LITE_COLUMN 0

Simply un-comment them by removing the "//" from the beginning of those two lines. Since BOOTMAGIC_ENABLE is still set to 'no' in rules.mk, these options (which select the key to use as the Bootmagic key) aren't actually doing anything, but a VIA/Vial compile wants them defined nonetheless.

One other change you may have to make to get the xwhatsit driver to build with the most recent QMK master snapshot is to edit util_comm.c and change...

Code: Select all

#include <tmk_core/common/eeprom.h>

...to...

Code: Select all

#include <platforms/eeprom.h>

...due to that header file being recently relocated.

Finally, the build instructions in the modelfkeyboards.com manual says to set...

Code: Select all

TAP_DANCE_ENABLE = yes

...in rules.mk, which (IMO) is wrong...not only is that not necessary, but if you do that and nothing else, your QMK build will fail, because QMK's tap dance feature requires that you add a tap_dance_actions[] array to your keymaps.c file that describes your tap dances. So don't just blindly set TAP_DANCE_ENABLE to yes in rules.mk unless you WANT that feature and know how to configure the dances that you want to use in your keymap definition.

[Ellipse]

Thanks NathanA and Croktopus - your fixes worked! I have updated all the Via firmware in the same link below and have updated the manual to remove the Tap Dance as you have noted. In my testing with a keyboard with the latest controller, Via is working with the new firmware.

Link to the firmware files:  https://www.modelfkeyboards.com/wp-cont ... -files.zip

[macclack]

Hello, I have recently received my F77, and I am astounded by its quality. Thank you!
I am experiencing a problem, with which I would appreciate some assistance. I have read the troubleshooting section of the manual already.

My 'R' key seems to register strangely in relation to other keys. It is as though the R has a slight delay (I don't know whether it is delayed or not, but that's how it "feels").

Example 1:
If I type "ORG", I strike R and G with two separate fingers, almost simultaneously, but with the R first. On every other keyboard this will type "ORG", but on my Model F, it types "OGR". Slowing down fixes the issue.

Example 2:
If I want to type a capital R, I will hit shift and R with two separate fingers, almost simultaneously, but with shift first. I want an uppercase R, but I will usually get a lower-case r. This does not happen with other keys. Delaying the R press slightly fixes the issue.

I have not noticed this kind of key ordering problem with any other keys. I have tried Example 2 with other keys, including those on the same row as R and the same column as R, and they don't have the same problem. It is as though something is up with the R key in particular. This happens on multiple computers.

Please help, and thank you again.

FWIW I'm having the same issue with my right shift key. Not sure how to fix this

[Ellipse]

Oddly enough I have seen issues with key ordering while typing resolved 100% after the keyboard is opened up and the ground screws for the controller are tightened, and maybe an extra layer of polyimide or electrical tape is added to the bottom of the controller. Clean off the metal controller ground contacts too beforehand.

[NathanA]

In my testing with a keyboard with the latest controller, Via is working with the new firmware.

Excellent!

[gnarlsagan]

I finally received the rest of my order, mostly keycaps, originally placed on January 26th, 2016. Crazy Ellipse has stuck it out this long and delivered such a high quality product.

[Boojakascha]

Hi there
I have a suggestion to add something about stabilizers and ISO enter keys. In the product description of the stabilizers https://www.modelfkeyboards.com/product ... keys-each/ it tells me to use the black ones. The manual however doesn't. The Key installation tutorial (xEm2mewsmrA) doesn't cover stabilizers. Just the "IBM Model F Quality Control Secrets" do (xEm2mewsmrA). I suggest to add descriptions in the manual and video info text. I can't be the first European who messed this up, or am I? Those inserts are a pain to remove, once installed.

Edit: also the manual "key gets stuck" portion "I" doesn't cover the Enter keys, which definitely get stuck with the white stabilizer.

Edit2: Furthermore I am almost positive that one of my white stabilizers is actually a black one (pegs different) Has this been reported before?

Edit3: No... I am realizing I have 2x3 kinds of stabilizers, but just two kind are documented. Could somebody tell my which one of those I would use for the ISO Enter key?

Edit4: Well, I found the drop down "Initial setup of your New Model F Keyboard + all instructional videos" with point 7 now, but it also doesn't mention the third kind of stabilizers... the white vertical ones. Do you know what those are? In my mind the video description should refer to this text as the video is referred to much sooner.

With kind regards
Ben

[Wintermute1974]

German users, the ISO DE keyboards with DE keycaps are shipping! I got my F77 via DHL yesterday.

[Boojakascha]

German users, the ISO DE keyboards with DE keycaps are shipping! I got my F77 via DHL yesterday.

be cautious with the ISO enter stabilizer

In drop down "Initial setup of your New Model F Keyboard + all instructional videos" at 7. it tells you what to do.

[Wintermute1974]

be cautious with the ISO enter stabilizer

Thanks for the tip. I have yet to install the keycaps, and I am puzzled by the black stabilizer that is intended for the ISO enter key: Does the 'ear' end up at a 45° angle to the barrel? It does not seem to fit any other way. The manual threatens you with complete keyboard disassembly, if you get this wrong.

[shampoo]

Hello!

I just had a key die on me. I did the usual things to try and bring it back.. In the end, replacing the keycap fixed it. Any ideas what caused this ? I reset the keycap several times with no luck. Replacing the broken key with a working key fixed it. Luckily I had a backup keycap..


Oh ya, and the rest of my order arrived. Thanks!

Thanks

J

[wobbled]

Hello!

I just had a key die on me. I did the usual things to try and bring it back.. In the end, replacing the keycap fixed it. Any ideas what caused this ? I reset the keycap several times with no luck. Replacing the broken key with a working key fixed it. Luckily I had a backup keycap..


Oh ya, and the rest of my order arrived. Thanks!

Thanks

J

It's probably the little nub on the underside of the key that slots into the spring that has broken away partially or completely.

[shampoo]

It's probably the little nub on the underside of the key that slots into the spring that has broken away partially or completely.

I just had a look with a magnifying glass and it looks like you are correct.

Thanks!

J

[Boojakascha]

be cautious with the ISO enter stabilizer

Thanks for the tip. I have yet to install the keycaps, and I am puzzled by the black stabilizer that is intended for the ISO enter key: Does the 'ear' end up at a 45° angle to the barrel? It does not seem to fit any other way. The manual threatens you with complete keyboard disassembly, if you get this wrong.

I now bit the poison pill and tried.

I did it as pictured here, but 180 ° rotated (as the text said) with the black vertical ones.
https://www.modelfkeyboards.com/wp-cont ... nserts.jpg

Left I have the long peg, top and right the small peg and bottom none. I had to press like if I wanted to break the poor thing.

Does anybody know what the vertical white ones are??

[trait]

Just received my Kishsaver and didn't realize I ordered the regular size one instead of the ultra compact.

Does anyone know if the solenoid will fit in the ultra compact Kishsaver?

Might sell my regular Kishsaver and get the compact one, but I want to try out the solenoid.

[allysure]

Reading all the posts here and feeling a little FOMO. Should have opted for the low serial number option...This hobby teaches me patience more than anything else in life.

[Ellipse]

Yes the stabilizers are tricky - as noted in the manual the black inserts are for the "vertical" keys like ISO Enter and 2U num pad + and Enter keys. They go in so that the larger "ear" is on the left hand side of the barrel (the 9 o'clock position). For the 2U num pad + and Enter keys they go in so that the larger ear is to the right hand side, as pictured in that linked photo (3 o'clock position).

There should be no opposite color stabilizer inserts - probably a factory mistake.

trait the solenoids work externally with the compact cases as they can't fit inside.

https://www.modelfkeyboards.com/questio ... a-compact/

I’d probably mount it near the USB cable port in the back of the compact case Model F. It would definitely look cool with an external mount! You could see the solenoid in action with each actuation!

Please do share photos if anyone has their solenoid set up with a compact case Model F!

[Boojakascha]

There should be no opposite color stabilizer inserts - probably a factory mistake.

I see, thank you, Joe.

The manual on your site isn't bad at all. I think I was just tired. My major hurdle was not realizing it was drop down and thus won't work with Ctl&F prior expanding and falsely assuming that the videos were all the information there is, missing much of the written explanations. Similarly on the "bucklingspring" I didn't realize the title was the link. I always clicked at the author name (as it was visibly a link) and was looped back and never reached https://www.bucklingspring.com/technica ... downloads/ thought it was temporarily under construction or removed...

Very happy with the product, thanks a lot =) I finished the QMK re-programming yesterday night and I am super pleased.

[sedevidi]

Yes the stabilizers are tricky - as noted in the manual the black inserts are for the "vertical" keys like ISO Enter and 2U num pad + and Enter keys. They go in so that the larger "ear" is on the left hand side of the barrel (the 9 o'clock position). For the 2U num pad + and Enter keys they go in so that the larger ear is to the right hand side, as pictured in that linked photo (3 o'clock position).

Hum... So, for ISO Enter and 2U num pad: should the black insert have its larger ear on the left or on the right?
Or maybe it is:
ISO Enter = left 9 o'clock
vs.
2U num pad = right 3 o'clock

[Boojakascha]

Hum... So, for ISO Enter and 2U num pad: should the black insert have its larger ear on the left or on the right?
Or maybe it is:
ISO Enter = left 9 o'clock
vs.
2U num pad = right 3 o'clock

Yes, you are correct, it's case sensitive.
For ISO enter:
Left long peg, top and right the small peg and bottom none

[Ellipse]

Update on backlog progress for shipping:

As an update, more than 570 keyboards from the current container shipment have shipped after the container shipment arrived and was organized in the past month or so, along with several hundred non-keyboard orders and remaining parts from split shipping requests.

We are still waiting on the factory for some of the remaining international key sets and custom keys (many have arrived and have been going out) so that is why the "all in stock" orders continue to take priority; the split shipping option is no longer available.

Please note that not all orders that are all in stock can ship right away, as there is still a backlog I have to go through.

There are about 1255 ordered keyboards remaining to ship (about 3800 new Model F keyboards have been ordered in total so far for this project). My expectation remains as before, that I can expect to move through the rest of the backlog in May, June, and July. As noted before, it is not possible to project the timeline 100% based on last month's progress as each order takes a different amount of time and orders with many individual extra keys will take much longer to process, and many of the remaining orders are disproportionately ones that have such keys while the "all in stock" orders have been able to go out already.

[Ellipse]

Someone just sent me some interesting information on the original functionality of some of the IBM terminal keys:

"I found a great video demonstrating what some of IBM’s terminal keys did on a real system.



The title on YT is “IBM 3178 Terminal Operations and Use demonstration” by Carl Claunch

https://www.youtube.com/watch?v=0FelFoLkWNk



A side note, the “Reset” key works the same as the “Error Reset” key found on other terminals. It dates back to the punch card days; I can link you a manual that details further if you wish.



The IBM 3101’s keyboard has a compartment for storing documentation. Perhaps you could ask if someone still has a pamphlet they might have found in there."