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

[NathanA]

The problem I have is that holding shift (or any other modifier) on one side doesn't activate it on the other. In the instructions, I see something about a workaround involving numlock state? I'm not sure if this is supposed to address the issue, but if so, I'm not sure how to make use of it. I'm using a Mac, which doesn't have a numlock.

Sounds like all of your issues stem from this keyboard actually showing up to the host as two separate physical keyboards you just happen to be typing on simultaneously. One Shift doesn't uppercase characters on the other, [...]

I...don't think this is a thing.

First, in testing this myself, I can't reproduce the reported issue where "any modifier" (which would be inclusive of Shift, Ctrl, Alt, ...) held down on one side "doesn't activate it on the other". If I have two keyboards -- any two keyboards! not even xwhatsit based 'boards! -- plugged into my computer, I can hold Shift on one, press a letter or number on the other, and that letter comes out capitalized or the symbol for that key on the number key row is outputted. I can hold down Ctrl on one, and C on the other, and I get Ctrl+C outputted. I can hold down Alt on one, press F4 on the other, and (on Windows) have the current window close.

That's because modifier key state is something that is determined and tracked by the host computer, and is not some form of state that the keyboard itself is keeping track of. When you press any of those modifier keys, a scan code is transmitted to the host, and at that point the host is what's keeping track of the state of that modifier. Globally. And then when another key is pressed in concert with that modifier key being held, it is the software running on the host that determines what action should be taken. Ergo, if Shift + S is pressed, it is code running on the host PC that decides to make the S capitalized. The keyboard doesn't send a "capital S" to the host...what the keyboard transmits when someone presses the "s" key is the same regardless of whether any modifier is being held down in concert with it. That is, it sends "shift key scan code" plus "s key scan code". If a capital S doesn't result from that, that's (generally) on the host, not on the keyboard (unless something really funky is going on).

The keyboard is just dumbly reporting to the host what key or keys happen to be pressed at any given time, and leaves it completely up to the computer what to do.

The only exception is the so-called "Fn" key, which is not a normal modifier key. It's really a special QMK layer-selection key that does NOT transmit a scan code to the host PC. Instead, the keyboard controller is monitoring and tracking the state of that key internally within itself.

So sharing of standard modifiers is not a problem, nor has it ever been. The one and only problem has been trying to figure out how to share the state of a specialized QMK layer selection key between two discrete QMK-based keyboards.

That's what the Num Lock based layer selection & sharing feature attempts to solve. So we are (potentially) conflating two completely separate things here. The whole Num Lock thing has nothing whatsoever to do with any of the regular modifier keys; it's just a hack that relies on the fact that Num Lock state is also tracked by the host, and exploits that fact to let one keyboard half "talk" to the other keyboard half in order to tell it what QMK function layer should be selected at that moment (Num Lock off == layer 0, Num Lock on == layer 1).

Hope this helps to clarify.

EDIT: I intended to but forgot to address the comment about "using a Mac, which doesn't have a numlock".

I talked about this in my original post about the Num Lock layer implementation:

The final big disclaimer is that this doesn't work on Macs, at least out of the box, because Macs don't have a native concept of "Num Lock". Fortunately, I did run across a very simple open source utility called SetLedsMac, which allows you to turn on or off any of the lock LEDs on one or more keyboards attached to your system. In and of itself this doesn't solve the problem, but somebody else forked the project and made a version with an added feature that listens for a lock LED change on one keyboard, and rebroadcasts that change to all of the other attached keyboards. So if you have a Mac, all you have to do is install this little utility, et voila! I tested it out, and it worked great for me on Catalina at least.

[Muirium]

I...don't think this is a thing.

It’s a Mac thing. Windows combines all connected keyboards into a single logical device. The Mac does not. Hold Shift on one keyboard and hit 1 on another and a Mac will produce 1, while Windows will produce !

The answer on Mac is to use Karabiner, which works its many magics by making a single synthesized logical keyboard. Otherwise, be wary of keyboards playing split controller tricks, like the Unicomp SSK.

[NathanA]

I...don't think this is a thing.

It’s a Mac thing.

Well, I'll be a mushy membrane.

Pulled the ol' MacBook out, and, sure 'nuff.

That's crazy. I'm nearly 99% sure that no other general purpose operating system partitions USB keyboard input tracking in this way. (I would have said 100%, but the discovery of this weird exception has left me a bit shook; heh.) It also seems to me like it would take more work / you would have to go out of your way to implement it to behave this way, and I can't think of any obvious upside to this implementation.

Windows combines all connected keyboards into a single logical device.

I mean, I obviously have no access to either Windows or MacOS sources, so I can't say this with absolute confidence, but...I'm not sure it's so much that, as it is that Windows just doesn't try to overly complicate things by going out of its way to compartmentalize the handling of each keyboard like that. Though perhaps that seems like splitting hairs, or is more like a six of one / half-dozen of the other kind of thing.

To be clear to onlookers trying to understand the intricacies of what might be going on here, everything previously described about how modifier keys work on keyboards still holds true: it's still "just another scan code", and it is the host that decides how to respond. If you have two keyboards hooked up, and you're pressing Shift on one and a letter on the other, each keyboard is sending a signal to the computer to indicate to it that that particular key is being pressed down...yes, even the one that only has a modifier key being pressed. And it's completely up to the computer to decide how to respond or what action to take. It's just that, when it comes to MacOS, apparently it does not choose to treat modifiers as global flags, but actually tracks each keyboard's own modifier keys separately on a per-keyboard basis.

[Muirium]

Indeed. I don’t know whether this comes from the NeXT or classic Apple side of the modern Mac’s parentage. If I ever fix up my SE/30, I should plug in two ADB keyboards and find out!

(Yes, my vintage Macintosh collection really is that small. I’m not nearly as into them as I am keyboards.)

[shampoo]

Hello.

I just purchased a F62 Kishsaver. If you have one, care to share your layout ? I am curious how you handled the ESC, `/~ key and of course the arrow keys..

Thanks

[Muirium]

Here's how I have my IBM Kishsaver laid out, if you're looking for ideas:

Layer 0

Screenshot 2024-02-01 at 3.46.57 pm.png (93.34 KiB) Viewed 3774 times

Layer 1

Screenshot 2024-02-01 at 3.46.47 pm.png (95.9 KiB) Viewed 3774 times

Load the attached json into Pandrew's QMK configurator to dig around inside.

The key is to pick a good—HHKB!—function layer. The essentials are the arrow keys and Page/End etc. group, which I keep consistent across all keyboards. My layer 1 is packed full of extra stuff I've added over the years, including numpad functions which I hook into other purposes with Karabiner.

The Esc key, meanwhile double-actions as a ~ with that keycode in the editor.

[shampoo]

Here's how I have my IBM Kishsaver laid out, if you're looking for ideas:

Thank you !

[genericusername57]

Hello.

I just purchased a F62 Kishsaver. If you have one, care to share your layout ? I am curious how you handled the ESC, `/~ key and of course the arrow keys..

Thanks

Caps lock+escape for the key that's usually to the right of the 1-key. Arrows is caps lock+HJKL but if the vi-arrows don't come naturally to you, you could also use something like JKLI or WASD. I usually don't have many keys bound to layer 1 since I don't use media keys and stuff like that, as long as I have home/end/delete and the arrow keys (and f-keys) I don't need anything else. Printscreen perhaps. The main thing is to put the layer key on caps lock since it's easily reachable and not otherwise used (caps lock itself is bound to caps+right shift for the rare times I need it). Not sure how Delete is bound from the factory defaults but having it as layer+backspace is a nobrainer for me after having used a MacBook as my only computer for many years

I have a second layer on the right FN/Win-key for things like toggling the solenoid and whatnot but keep the second layer as designed in the factory firmware.

[Muirium]

Caps lock+escape for the key that's usually to the right of the 1-key.

That's an interesting way to type 2.

[genericusername57]

Caps lock+escape for the key that's usually to the right of the 1-key.

That's an interesting way to type 2.

Forgot to mention, I also only use my keyboards upside down

[taraskremen]

Another thing I wanted to mention is that I found that these risers work pretty well with the F62 (and probably with the F77). I followed the directions and left them alone for at least 12 hours before using the board, and they are staying put so far with just their adhesive pads. In addition to slightly elevating the back in the folded state, they give you a choice between two positions, which is handy.

ModelF-Nillkin-risers_4.jpeg

Just wanted to follow up with a quick update on these keyboard feet/risers. They are still holding up very well on the original F62 Kishsaver case and seem to stay on well with the F50 anodized aluminum case. However, they fall right off of the Ultra Compact F62 case with its matte powdercoated finish within a few days. Looks like some other attachment method is needed for the powdercoated cases. I haven't really had time to experiment with these yet, but if anyone tried to use them with powdercoated cases and found something that works, I'm sure some folks here would appreciate tips.

[Ellipse]

I have just updated the zip file in the manual on the project web site with all of the NathanA firmware files. This one zip file includes all of the NathanA vial files, the old QMK files, the source code and build files, and the pandrew utility for Windows and Mac.

The batch files have been renamed and reorganized to replace abbreviations with language that more closely matches that of the project web site keyboard configuration. Once again a major thanks to NathanA for this enormous undertaking.

As always please do review the manual for instructions before doing any firmware flashing or you'll likely run into errors.

Please do share feedback here after testing this firmware!

https://www.modelfkeyboards.com/wp-cont ... -files.zip

[tiltowait]

@NathanA

Weird and frustrating as the Mac situation is (I've still never used my split Model F due to it), it does seem to offer at least one benefit, in that you can independently remap modifiers on a per-keyboard basis. Although ... now that I've typed that, I'm all but certain you could accomplish the same thing while still sharing modifier state across keyboards. And really, how many people are trying to use two keyboards at once? It's definitely an odd design decision.

[krastatt]

The front page of the website ( https://www.modelfkeyboards.com ) says "2/29/24 please have your orders in by then!" Does this date apply to orders for the F122?

[mmm]

The front page of the website ( https://www.modelfkeyboards.com ) says "2/29/24 please have your orders in by then!" Does this date apply to orders for the F122?

Next month it will just say "3/31/24 please have your orders in by then!" if we assume it does the same thing, that it has done the past couple of years. It means absolutely nothing. It's just misleading marketing to create a false sense of urgency. Previously in the thread it has been discussed whether it violates some laws, but I can't remember if there was a conclusion.

[shampoo]

The front page of the website ( https://www.modelfkeyboards.com ) says "2/29/24 please have your orders in by then!" Does this date apply to orders for the F122?

Next month it will just say "3/31/24 please have your orders in by then!" if we assume it does the same thing, that it has done the past couple of years. It means absolutely nothing. It's just misleading marketing to create a false sense of urgency. Previously in the thread it has been discussed whether it violates some laws, but I can't remember if there was a conclusion.

Ordered another keyboard on Jan 27nth.. still waiting on it to be shipped. Not sure what the above rush is for.

[Ellipse]

Currently the order backlog for in stock items is down to about one month, as it has been for the past few months.

Regarding the production delays and deadline discussion, please see my prior posts for more details. One such post from a couple years back:

"Not to belabor the point, but in regards to the project delays and timeline, the main point I have made a few times before is that given all of the factory delays and my own delays in the QC process to get these keyboards out I am unable to keep the deadline unchanged, but I strongly believe that a deadline that is not firm is better than no deadline, which would give a wrong impression that the project is ongoing indefinitely, even after the orders have gone out and the final round is over. I don't want anyone intermittently following the project every few months to miss out on joining the project because it closed with little to no warning. Better to be cautious in my view, even overly so. I fully understand the other points that have been brought up by some of you, but removing the deadline or indicating in any other way that the project is ongoing indefinitely would not be the best option."

[jsheradin]

a deadline that is not firm is better than no deadline

https://en.wikipedia.org/wiki/The_Boy_Who_Cried_Wolf

[genericusername57]

Currently the order backlog for in stock items is down to about one month, as it has been for the past few months.

Regarding the production delays and deadline discussion, please see my prior posts for more details. One such post from a couple years back:

Not to beat too much on a dead horse, but you would solve basically all issues with this by just extending the deadline 3-6 months in advance rather than one.

[NathanA]

@NathanA

Weird and frustrating as the Mac situation is (I've still never used my split Model F due to it), it does seem to offer at least one benefit, in that you can independently remap modifiers on a per-keyboard basis. Although ... now that I've typed that, I'm all but certain you could accomplish the same thing while still sharing modifier state across keyboards. And really, how many people are trying to use two keyboards at once? It's definitely an odd design decision.

Having more than one "keyboard" device plugged into a single computer is not really that weird, and there is precedent for it that predates split keyboard designs that present themselves as two discrete keyboards to the host. One clear example would be dedicated number pads, which have existed for years and years. And of course you would want to be able to "chord" across multiple keyboards plugged into the same host...that just seems obvious to me (but maybe I have "PC user bias"?). Maybe this isn't so much a thing on Mac, but for example, if you had a TKL and a dedicated numpad both plugged into a PC running a Microsoft platform, wanting to be able to hold down Alt on the main keyboard while typing in a specific ASCII code on the numpad to access a character that isn't represented by any discrete key is pretty darn common. So the OS X decision on this front really continues to boggle my mind.

[NathanA]

Please do share feedback here after testing this firmware!

Woot, it looks like DT is back! (At least for now...?)

Took a look at the repackaging you did. First, it's not entirely clear to me why you decided to keep around the old r4 firmware files + their associated "allpads" layouts in addition to the r5 firmwares and all of the new, more specific layouts, since I thought it had been established that the "allpads" ones only came to be because I misunderstood your original request due to us both using certain terms to mean different things & thus we both ended up talking past each other for a bit. But if you want the "allpads" layouts reproduced for r5, I can certainly do that, and then we can just drop distribution of the old r4 firmwares...I doubt anybody is super interested in having them, however, and am not clear on their utility at this point.

Yes, as you discovered, it is possible to rename the batch / shell script files...however, you cannot move them from one directory and into another directory on a different "level" of the directory hierarchy without editing each individual script in order to either adjust or remove the relative path references within them (in this case, "../../" or "..\..\"). It looks like you figured this out, though!

However, it appears you only edited the Windows .bat files in this manner, and not the UNIX .sh files. So all of the ones that you renamed to "linux blahblah.sh" aren't going to work.

I'd suggest that perhaps titling then either "UNIX" or "POSIX" instead of "linux" would be more accurate as well, since they were developed and tested on a Mac, not on Linux. No doubt they will also work just fine on various Linux distributions, but a proper dfu-programmer that's compatible with the particular version and distribution of Linux that you're running would need to be installed first. Since they work "out of the box" on Mac but not on Linux, titling them "linux" is likely to be confusing. (Personally in my opinion, there's no reason to prefix them with "mac", "linux", "unix", "posix", or anything, since the .sh at the end of the filename makes that clear.)

As you no doubt experienced while going through the renaming and editing process, making naming and location changes of the scripts is tedious, time-consuming, and error-prone (*especially* now given how many permutations there now are of the various keyboard models and desired layouts per model), which is just one factor for why the time it takes for me to put together and properly test a release before publishing it has just exploded. If a new model comes out, or if a new layout is requested, or if I end up having to change the name of anything, it involves some combination of making new scripts, editing each individual script, (re)naming it, and (if you are a perfectionist...hi!...and insist on having the script name and keymap file names match) (re)naming and (re)placing the keymap and script files and potentially editing the script files again. Then running them on an actual system in order to make sure that I didn't fat-finger something. So anything I can do to cut that time down and reduce the amount of manual labor, I'm probably going to pursue.

(In fact, while I was going through the package while writing this post, I noticed for the first time that I did in fact screw up both the f50 and f104_ns scripts & failed to notice that I did, so neither of those have been working properly in the r5 release this whole time. Just further reinforces how fragile and error-prone the existing system is.)

I'd previously played around with changing the scripts so that the script determines what firmware (flash) and keymap (EEPROM) files should be flashed based on the name of the script itself, rather than based on values set within the script file. Then there could just be a single script file, and multiple links (all with different names) auto-generated that point to that file. I abandoned this because at the time I was under the impression that Windows didn't have the concept of links at the filesystem level, but I did recently discover that NTFS has apparently supported both hard- and soft-links since Vista. The big problem remains that most file archive formats on Windows don't support storage of NTFS's implementation of symlinks/soft-links, which makes packaging them for distribution difficult. On top of that, while playing around with them, I also discovered that apparently certain versions of Windows (some which may still be in circulation) have some limitations and bugs related to the symlink implementation...certain versions of Windows require you to elevate your privilege level to Administrator to even create symlinks, and certain versions of Windows won't allow you to double-click a symlink in Explorer in order to launch the linked-to file, which is kind of nuts.

The strategy I have settled on as a result is that I will not be packaging pre-generated links at all in future releases. Instead, I will include a script in the root directory (one for *NIX, one for Windows) that will auto-generate and populate the "flash-scripts" directory with all of the links. And because of the limitations that exists for symlinks on Windows, I'll just generate hard links...I'm not a big fan (primarily because they're not easy to readily identify) but for this use-case it'll be fine.

So be forewarned that I will likely publish an updated packaging of r5 relatively soon that does away with all of the flasher script files, and instead only includes a single script for each platform, and another script that generates all of the links to that singular script. That way, I only have to ever edit and update a single script in order to make changes / add features / fix bugs / etc. moving forward. The downside is that if you don't like my naming strategy, and you want different names for the .bat files than what I've chosen, you'll have to rename the keymap .hex files, because the script link names will be auto-generated based on those, and the script link name MUST match the .hex name in order to work at all.

If how this is going to work isn't entirely clear based on my description, hopefully it will make sense when you see it in action.

[Ellipse]

As an update I have posted the latest blog entry which rounds up all of the postings of recent months. Apologies this one came out later than it should have.

https://www.modelfkeyboards.com/blog/

Thanks NathanA for your helpful feedback. Kindly see my replies below:

The allpads option is for those who do not want to have to update anything to switch their board from ANSI to ISO. Currently a user (or factory worker) would have to pick the exact options they want before flashing the file, or flash the file and then switch things around in Vial, which is probably beyond what most folks want to do. Yes please do update things to add this.

Essentially I was hoping for each layout to mirror exactly my QMK keymap files, so there is one batch file that works with ANSI and ISO without modification for the factories to flash, but what you have provided is good so there is no real rush for this.

Thanks for catching linux vs. UNIX and my error with /../.. - I have updated these files and reuploaded the zip file.


For ease of reference here is a portion of the beginning of the blog, summarizing the current statuses of the various aspects of the projects:

Production Status – when are my orders arriving!

The Round 2 Model F and Beam Spring boards should be wrapping up production and assembly over the next few months and arriving to me around mid-year, a delay from the original expectation of being completed around this current time. All these Round 2 boards should be going out at the same time once they arrive on the container ship, so if someone decides to order an additional board and they have two boards on order then they usually get to skip the additional line and have both boards go out in the same shipment and at the same point in line as their first board.

After assembly and packing is completed, we then have 6-8 weeks for the container shipment and arranging local delivery to me. As I always say, we are at the mercy of the factories for their production timeframes. This low volume project is far from the highest priority but I am thankful that the project can exist without economies of scale.

The factories all understand that the quality control is very important for all these parts so we prefer that they get things right even if it delays things.

A few folks have asked me to switch them to in-stock round 1 boards, such as the ultra compact F104, ultra compact FSSK, ultra compact B104, and ultra compact BSSK, if they prefer not to wait. If interested, please email me as I still have some of these boards left but stock is low and they will not be made again.

Model F specific production status details

Round 2 Model F classic style cases: They made the batch of black cases but we still need to finish the other cases and finish assembly. The factory needs to confirm the finalized case colors and texture before powdercoating can start.

Inner assembly (all F104 and FSSK inner assemblies have been produced and assembled, including the barrels, flippers, PCB, inner foam, and clear mylar sheet).

F122: the F122 sample inner assembly still needs to be approved before F122 TIA and BIA production can start. I am currently evaluating the latest F122 keyboard. So far I see no errors with the inner assemblies.

Keycaps: in preparation for the new boards, I ordered several thousand extra key sets and miscellaneous extra keys which were all completed and are currently on hand, so we do not need to wait for keycap production for the new Model F keyboard designs.

Boxes: the new folding style boxes have been approved for production for all Model F and beam spring boards; the artwork remains the same as before. More details on these boxes are below.

Outside protective foam: has been approved for production. These will be end cap pieces similar to those of the latest classic style F77.

While this does not hold up any Model F production, unfortunately there were production issues with the small batch of new keys for ISO Enter, Code, and PC AT Big Enter. The factory is working on remaking this batch (photos shown below). They will be available in pebble, ISSK Blue, black, and dark gray. As always everyone interested in reserving one of these keys (alone or as part of a set) please sign the Google Form: https://docs.google.com/forms/d/1vsamkl ... kDG39r08Q/

If anyone prefers not to wait and wants to switch to a Round 1 Model F board please let me know by email as I still have some units remaining.

Beam spring production status details

The Round 2 boards still need to finish production and assembly, so I hope that they can arrive to me later this year, around mid-year. As mentioned before things have been delayed from the original hope that they be completed earlier. Like with the Brand New Model F Keyboards project, no one aspect has bottlenecked the project and caused the delay but a number of aspects have taken longer than expected. The factory has their new year break for the next few weeks so things will continue after then.

Same as with the Model F noted above: If anyone prefers not to wait and wants to switch to a Round 1 beam spring board please let me know by email as I still have some units remaining.

Beam modules parts A and B:
Recently completed, but there was an error with part B discovered just before the new year break for the factories, so these parts need to be remade. These took over one year to produce, much longer than expected. Over a hundred thousand parts of each type were produced.

Beam module part B’s (the white part’s) assembly with its metal part has been improved for a nicer looking rounded assembly finish on the nub that is below the metal part. The factory has made thousands of these as part of the updated beam modules (all the ones with the press fit washers on top) and they are nice.

Metal parts for the modules:
The new modules from this February batch now sound great and were just approved for production yesterday, so we are just waiting on part B to be remade. A month earlier I noted this: The new modules using the older metal part for beam flipper sound great and are very close to the IBM originals. The tooling for the metal part for the beam flipper was updated last year but the updated tooling designed to get things even closer needs some work to get the modules as good sounding as possible.

The updated press fit washer mold for the beam modules:
Has been completed and approved, and I believe the factory has finished production of these parts if I remember correctly. This is an update over the original glued metal washer design; it allows for quick and toolless disassembly and repair of the beam modules.

Cases:
All but the beige and industrial gray case colors were approved (I want the colors to be even more accurate to the IBM originals so I rejected those two samples). The paint texture finish is not yet finalized.

Capacitive and controller PCBs:
wcass and Rico have finished the PCBs for the various beam spring models and I ordered the updated samples a few days ago. Rico’s Leyden Jar Rev 3 controller is so far working flawlessly in my testing and these will be the default controllers for the B104 and B122 (plus the F122), though the controllers will hopefully have firmware for all the various Model F and Beam Spring models in the future. As mentioned before, after the ATMEGA32’s run out I expect everything to have the Leyden Jar as the factory-installed controller.

Keys:
The PBT double shot keys and wcass xwhatsit controllers were completed last year.

Boxes:
The box designs have been finalized. The art will be just about the same as the Round 1 boxes shown on the project web site, but the boxes themselves will switch to a tab locking foldable design similar to the boxes IBM used for the original IBM Model F XT and AT keyboards (more details below). I have approved the box designs for production.

The outside protective foam:
Will be similar to the end cap style used on the final production round classic F77 Model F keyboards; after the keyboard samples are approved then they can make the cutting tool for this foam.

Inner foam:
The inner foam that goes between the tops of the modules and the top inner assembly will be evaluated with the forthcoming samples.

Working sample status:
The factory still needs to produce fully working samples of each beam spring keyboard model for my approval, and then mass production and assembly of the remaining case parts can start. The tooling for these cases took months longer than expected to complete. The sample cases and their TIA/BIA’s are completed and are now waiting to be powdercoated and assembled.

[Ellipse]

I have just made an additional blog post regarding a potential group buy for the Deskthority site:

Save Deskthority!

As some of you may have heard, the future of the Deskthority mechanical keyboard forum is uncertain after the current owners have offered it for sale. It was suggested that I head up a group buy effort to coordinate a group buy to collect funds for me to purchase the site with the intention of leaving things as they are (additional details are in the Google forms link below). This is a terrific forum and along with geekhack and reddit MK it is a great place for learning and discussion on mechanical keyboards!

“Today I reached out to this site’s proprietor expressing my interest and received a thoughtfully written reply including the information that they are looking for $15k for the site and that an offer for $5k was turned down. My guess is that the final price may settle around $7.5k to $10k if they wish to proceed with a sale. For someone looking to buy the site, server costs for a private dedicated server with 1 gigabit/second guaranteed bandwidth, 64GB RAM, and a 2023 Intel processor would be about $55 to $65 a month including backup storage.

I would be happy to coordinate a group buy for the site (I have coordinated some group buys before!).

Below is the Google forms link I have just created, where I have included additional details.

I would have to collect the funds by Venmo, Zelle, Transferwise (wise), check, etc. so as not to affect my merchant card processor which may not like collecting funds for funds outside my normal area of selling goods.

Please only sign the form if you can realistically send funds in the next month or two.”

https://docs.google.com/forms/d/1FLV9n2 ... ested=true

[NathanA]

The allpads option is for those who do not want to have to update anything to switch their board from ANSI to ISO. Currently a user (or factory worker) would have to pick the exact options they want before flashing the file, or flash the file and then switch things around in Vial, which is probably beyond what most folks want to do.

Okay, I'll do it. I will still argue that either of those current options strikes me as vastly simpler compared to what they had to do before with visiting a web site, changing the layout on there, re-compiling and re-flashing a firmware, etc.

Also in case this isn't clear, for most models, if you flash either ANSI or ISO, the opposite keys still work (extra ISO keys after flashing ANSI, or extra ANSI keys after flashing ISO); if you've found a model that's not true for then let me know and I can fix. The only thing "allpads" does is visually show the pads in the Vial GUI by default. It doesn't change anything about the underlying keymap, which is identical between ANSI and ISO keymap files (or at least should be). So the existing ANSI option seems to me like it should already do exactly what you're talking about, and the factory can simply always select "ANSI" even for ISO orders.

(Personally I'd still argue against having the factory always flash with either ANSI or with an "allpads" layout if ISO is selected by the buyer on the order form, because that seems rather user-unfriendly to anybody who does happen to launch Vial later, and then wonders why the **** they're seeing an ANSI layout on the screen when they swore they ordered ISO...that's just asking for support e-mail that could have been avoided, methinks. Also, for some keyboard models, like BSSK Round 2 for example, you literally *can't* have a single keymap file for both ANSI and ISO models because of the way those boards work...I went ahead and made an "allpads" file for BSSKr2 regardless, but it is the model that doing so makes the least sense for. So if the factory has to distinguish between ANSI and ISO flashes for one keyboard model, why not just streamline things and have them do it for all models, rather than try to explain to them what the various exceptions to the rules are?)

Yes please do update things to add this.

Done.

I'm attaching a slightly updated revision of release 5. This both adds "allpads" layouts for all the models, and also re-does the script generation in the manner I previously described.

When you unpack this release, there won't be any script files..."flash-scripts" directory is completely empty. You have to first run the "link-flash-scripts.bat" file, and this will auto-populate all of the script "files" in the flash-scripts/ directory. What it's actually doing is making links to a singular script that now lives in flash-util/ with all of the other supporting dfu-programmer files and libraries. It's not making multiple actual copies. This means if you edit one of the "files" in flash-scripts, you're simultaneously editing all of them.

If for some reason you want to have link-flash-script make copies instead of links, you could change out the "mklink" command in there to "copy" (and re-order the parameters as needed), but that probably won't do what you want, since the script now looks at its own name in order to determine which firmware and keymap file to flash, rather than to the contents of variables inside the script. So, for example, by just renaming "flash-f62-ansi.bat" to "flash-bssk-iso.bat", running the script will no longer flash F62 firmware with ANSI layout but rather BSSK firmware with ISO layout. If you compare the new version of the script to the old, you'll see that only a small handful of lines at the top changed, so if you don't want that behavior in your own package, you can just continue to use the old version and modify it as you need. Or you could try renaming the various keymap hex files so that they're named whatever you want the scripts to be named before you run link-flash-script, since the names it picks for the script links are taken straight from the hex file names (since with this new version of the script, the hex file name and the script name now have to match).

But this new version has already saved me a ton of time...I only had to worry about generating the new .hex and .vil keymaps for the "allpads" you requested, and didn't have to bother with also making a bunch of new copies of the script and then editing each individual one by hand.

I've also added a new Quick Start guide in the form of a readme.txt file. Hopefully people will find it clear and useful. Unlike most of my posts here where I know I tend to go into excruciating detail, I tried to keep it concise...

To be clear, there's literally no difference between the firmware in this updated package, and the firmware in the prior package. No code has changed in this update; this is just a packaging change. So anybody that's already running r5 doesn't need to update to this, and if they do "update" it anyway, it won't change the behavior of their keyboard at all.

[kbdfr]

Please discuss matters regarding the DT site in the appropriate thread (or at least also post there)
I moved one post NathanA posted here to the thread "Future of DT":
viewtopic.php?p=518792#p518792

It read:

I have just made an additional blog post regarding a potential group buy for the Deskthority site:

Interesting proposal. I'm not entirely sure how some people here might take to the idea of contributing monetarily to a group-buy where they don't end up owning some kind of stake, or where the ownership isn't turned over to some kind of legal holding entity that the community holds in common somehow. Still, if nobody else steps up to the plate, a single owner such as yourself is arguably better than having DT just die a slow death! What remains unanswered is how many contributions you can expect to receive under your proposed terms, and if that number comes up short of what the sellers would accept as an offer, how much you'd have to chip in yourself to make up the difference vs. how much you'd actually be willing (or able) to chip in.

For the record, I had also reached out to the current owners, not to offer to buy, but to offer some of my time pro-bono to diagnose and fix the repeated (and continuing) server crashes, as network and server admin/engineer at regional ISP is actually my day job (though often feels more like a 24/7/365 job ). They haven't (yet?) accepted that offer, though perhaps that's because they're nervous about giving a total stranger back-end access, which is extremely understandable...

[NathanA]

Please discuss matters regarding the DT site in the appropriate thread

Yup sorry; I saw the Ellipse post about that in this thread & posted that response before I saw that thread.

[pilcher]

Can anyone clarify what is meant by "round 1" and "round 2" keyboards? I ordered a classic 104 style keyboard almost a year ago; which round is that?

[Ellipse]

pilcher the classic style F104, FSSK, and beam spring keyboards are in the round 2, which are in production at the factory. A detailed progress and status report of each component of these keyboards is on the project web site updates page. In summary these should be going around approximately around mid-year. For anyone who prefers not to wait they can email me to switch what they ordered with an in stock round 1 compact case equivalent if available.

[NathanA]

Both for the "just in case DT does end up going completely under" scenario, as well as to streamline things a bit (no more double-posting files both to here & to GH) and also to give the firmware a more fixed home on the internet than a web forum thread, I've gone ahead and taken the time to throw together a very basic web page for my version of the Vial firmwares.

I will continue to announce new releases on the forum(s) whenever they are ready, but I only plan to host the actual files on this new server moving forward, and won't be uploading attachments to them here, just linking to them on the new site.

I'll plan to maintain these fixed URLs where the most recent version will always be available for download (at least until I change my mind ):

• http://www.newfxx-firmware.nconx.com/latest (most recent firmware bins + source code bundle)
• http://www.newfxx-firmware.nconx.com/latest-util-win (most recent "pandrew" util for Windows)
• http://www.newfxx-firmware.nconx.com/latest-util-mac (most recent "pandrew" util for Macintosh)

[RedESC]

Both for the "just in case DT does end up going completely under" scenario, as well as to streamline things a bit (no more double-posting files both to here & to GH) and also to give the firmware a more fixed home on the internet than a web forum thread, I've gone ahead and taken the time to throw together a very basic web page for my version of the Vial firmwares.

I will continue to announce new releases on the forum(s) whenever they are ready, but I only plan to host the actual files on this new server moving forward, and won't be uploading attachments to them here, just linking to them on the new site.

I'll plan to maintain these fixed URLs where the most recent version will always be available for download (at least until I change my mind ):

• http://www.newfxx-firmware.nconx.com/latest (most recent firmware bins + source code bundle)
• http://www.newfxx-firmware.nconx.com/latest-util-win (most recent "pandrew" util for Windows)
• http://www.newfxx-firmware.nconx.com/latest-util-mac (most recent "pandrew" util for Macintosh)

That's great. Probably a lot simpler for folks hunting down this firmware rather than hunting for forum posts. Would be good if Elipse could add this to his site as well.