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

[Arkku]

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

This seems like a likely explanation, especially if it writes to the middle of the calibration data but doesn't happen to hit the headers.

[Ellipse]

Here is a video of a thoroughly modded new Model F keyboard - floss mod, stripped paint off of the die cast aluminum compact case, lubed Unicomp keys, etc.

[Ellipse]

Firmware update:

I am now expecting to base the project firmware off of the latest NathanA updates to the pandrew QMK firmware, which allow the use of the pandrew utility and its signal level monitor, Vial, and the online version of the vial configuration tool. This tool is great - I was able to connect the keyboard running NathanA's updated firmware to the web site vial.rocks to reconfigure the keyboard without having to download anything or flash any firmware. Both the vial program and the vial web site both recognize any keyboard because they read the layout from the keyboard firmware - no need to load a json file or pick your keyboard and controller from a dropdown menu. So much easier. Are there any options on the QMK configurator that are missing from Vial?

In addition, I can report that the NathanA updated firmware (made from the same version of QMK that pandrew uses) is more stable than the firmware I generated from a later version of QMK, but still made before the big QMK updates. The latter one had some issues with repeated and missing keys, even after I removed and retightened both ground screws and removed and replaced two springs from frequently-transposed/switched keys. I also tested the Arkku calibration setup in the NathanA firmware and that also worked well.

Currently the firmware works without any issues on the round 2 FSSK/F104 boards. Again a big thanks to NathanA!

[Ellipse]

More firmware news:

wolfman is wrapping up the approval process for the refactoring to get the xwhatsit accepted into the main QMK project. Here are the details: https://github.com/qmk/qmk_firmware/pull/21193

Everyone feel free to test out this refactored firmware and let us know the feedback!

[Muirium]

Yay!

Proper QMK support for all of Pandrew's thankful Model Fs—yours or IBM originals—is a worthy goal indeed. Glad to hear it's going well!

Any word on RP2040 support for QMK? I know you're rightly interested in the topic.

[xyzzy]

This release is (finally) just essentially a roll-up of all previous fixes (plus some additional ones) that have been informally distributed since the last full release, which was in November 2021.

After a few days of extensive usage, I can confirm it works flawlessly on my setup (early Model F62, macOS).

The keyboard had the previous version of the vial-compatible firmware installed and it has always been quite unstable on my system. Often some or all of the keys from the top row would stop registering and I had to disconnect and reconnect the USB cable to make it work again. Sometimes it would work for a few minutes before some keys started to fail, sometimes for a few hours or even days.

No problem whatsoever with this new version, everything - so far - appears to be working 100%, and it's been of great help to also find included Pandrew's QMK util compiled for macOS.

Thanks for the great work!!

[Muirium]

it's been of great help to also find included Pandrew's QMK util compiled for macOS.

Got a link? A wee search in this notoriously busy thread finds this, but the attached .7z files won't extract for me.

Edit: concatenated them and the resulting file extracts now. Got it. Interested to see if it plays well with my IBMs. The version of the utility I've been using is ages old now.

[NathanA]

Got a link? A wee search in this notoriously busy thread finds this, but the attached .7z files won't extract for me.

Yes that's the right link. I see that you managed to get it extracted, but I'm also curious to know what app you are using to try to extract them that was failing to deal with them while they remained separate. The actual 7-Zip GUI app on Windows as well as the '7z' command-line version can both deal with multipart 7z files.

Though I mentioned it in the actual (admittedly lengthly) post, it bears repeating since I know people have managed to gloss over it in the past: this forum both limits attachment sizes to 5 megabytes -- which necessitated the splitting -- AND also checks file extensions against approved/whitelisted extensions. 7-Zip makes multipart archives with extensions in the format .7z.001 ... .7z.NNN, where NNN is the number of parts. But obviously .001, .002, etc. are not "approved" file types on this forum, so I had to rename them to .001.7z, .002.7z, and so on before uploading. But 7-Zip doesn't recognize those files as multipart archives that should be paired together, so you need to rename them BACK such that the part # is at the very end of the file name AFTER the .7z bit.

I created the multipart archive using '7z' itself, and had no idea what the internal format of such a file was...I'd not tried simply concatenating all of the parts together into a single monolith before, and would not have assumed or guessed that that would have worked, since I figured it likely at least put some header-y bits at the beginning of each part...as the kids say, "TIL".

[Muirium]

Ah, they were forcibly renamed. That'll be what went wrong, and what I inadvertently fixed.

I use this popular all-in-one unarchiver on Mac, which recognised and claimed your split files so they got icons and launched it on opening. But it failed to actually open them. I ran 'cat' on Terminal, dropped your files onto the window then typed > Pandrew.7z which duly unarchived just fine in the same app.

I'd advise uploading things to GitHub or elsewhere rather than DT's notoriously picky attachment system. We're a lousy fallback! And, like all things admin here, it's not getting fixed any aeon soon.

[NathanA]

I'd advise uploading things to GitHub or elsewhere rather than DT's notoriously picky attachment system.

I've specifically been actively trying to avoid doing exactly this for most of this project, in part because QMK has already been forked all to hell by countless others, and it's already extremely confusing trying to track all of the moving parts. My firmware builds have largely been "a bit of this, a dash of that, with a pinch of this other thing thrown in", borrowing from many separate existing repositories (spread across different repo servers, not just on Github): I'm more playing the part of "software editor" than developer, picking what seems to be the best parts from various other source trees and stitching them together into hopefully some sort of cohesive and usable whole.

Since there isn't a whole lot of original development happening on my part, I figured that the better thing to do in this case would be to "show my work" by including a build script that pulls from all of the different sources I'm pulling from and reconstructs the entire shebang on your side. That way, it's clear exactly what I did to arrive where I'm at, proper attributions are made to all of my sources, and so on.

But I'm sensing that my hand may soon be forced into a more conventional approach. This was manageable as long as the project was basically contained to the F62 and the F77. Now with a bunch more models coming on-line, this is probably going to get a whole lot messier to maintain this way, and my current approach likely won't scale to meet it.

[Muirium]

QMK has already been forked all to hell by countless others

Fork it! Fork it good!

[Ellipse]

Muirium there is actually an RP2040 project underway - Rico's Leyden Jar controller - which I plan on using for some of the Model F and beam spring keyboards requiring more columns. The controller has worked flawlessly in my testing, and it is quite stable.

https://github.com/mymakercorner/Leyden_Jar

RP2040, QMK, and even PS/2 support is planned! https://www.keebtalk.com/t/the-leyden-j ... s/17489/25

[NathanA]

I'm very excited about the RP2040 project, as I am feeling the pain of the ATmega's limitations more and more everyday.

That said, not *super* excited about the prospect of soldering in my own if I want to replace the controller on my existing boards...you know how some people who are poor dancers say that they have two left feet? Well, when it comes to soldering, I have two left hands. There's a reason I dabble in software tinkering instead of hardware.

What I would give to have Elzar's four upper appendages while trying to solder something; heh.

[Muirium]

Yeah, as the proud first guinea pig to solder Xwhatsit’s original Model F prototype into a Kishsaver, I know exactly how you feel. He increased the size of the holes for the production version at my request. It was quite a job. Felt like defusing a bomb!

Quite why we’re copying IBM’s cost saving downgrade from the much more elegant beamspring controller card I don’t know.


@Ellipse:

Cool. So that’s what the Leyden Jar is. Thought you guys were talking about steampunk flux capacitors.

What I’d really like to see is RP2040 support for QMK powered controllers (for regular non-capsense keyboards, too) and especially converters for PS/2 vintage keyboards, with a modern interface to match.

Soarer's is pretty much the (command line driven) Vial of its day.

I think what would be extra cool, and way more self-explanatory, would be a modern rethink using modern (not 8-bit!) hardware with the same excellent defaults as Soarer but maybe an onboard web page for configuration. I’m not technical enough to know if this is a terrible idea! (Grumble grumble web stack?) But tweaking layouts on any host system with a web browser seems the ideal user experience to me.

[NathanA]

What I’d really like to see is RP2040 support for QMK powered controllers (for regular non-capsense keyboards, too) and especially converters for PS/2 vintage keyboards, with a modern interface to match.

The Leyden Jar firmware source is built on top of QMK, just as pandrew's xwhatsit-for-QMK is.

This appears to have been possible because QMK already supports the RP2040. Support for the RP2040 was in fact checked into QMK master on June 30, 2022. It has since been merged into the Vial fork of QMK.

There are (non-cap) keyboard designs based on the 2040 that are already checked into QMK master & have been for some time...

Not sure how much of a chore making a PS/2-to-USB adapter in QMK would be. I know that at least the last time that I looked into it, QMK had support for acting as a PS/2 *host*, but not as a PS/2 *device*. The intent behind the host mode appeared to mostly be in order to allow for some USB keyboards to offer the option of playing host to a PS/2 mouse, which it would then adapt to USB for you (one USB cable to the computer for both your QMK keyboard and PS/2 mouse). Not clear to me how many (if any) keyboards out there actually implemented this...

Well heh, look at that why don't you...it would appear that I really should Google things first, and it would also appear that the PS/2 input/host support in QMK also supports keyboards and not just mice, as evidenced by the fact that the very device you said you were wanting to see materialize already exists: https://www.tinkerboy.xyz/product/tinke ... converter/ (EDIT: to be clear this doesn't appear to be RP2040-based, so still not the best of all worlds; still, since RP2040 is natively supported by QMK now, this acts as a proof-of-concept / nothing on the software side is stopping anybody from re-designing this hardware to use said chip)

All that said, I don't believe QMK has ever added support for PS/2 *output* / device-mode, so it's not clear to me how the Leyden Jar designer intends to actually implement this. There's a PS/2 daughterboard designed that can plug into the contacts normally occupied by the solenoid (so does that mean you can't have both solenoid and PS/2 simultaneously? would seem to suggest so...), but no actual software support for it yet, at least that I can see. Might have to implement entirely from scratch if there is no existing support in QMK to take advantage of. Also, this design won't permit for a single cable from the keyboard + an inline passive USB-to-PS/2 adapter, as many USB-first commercial keyboards that support both protocols have done: you'll need a second, separate PS/2 cable snaking out of the chassis, separately attached to the aforementioned daughterboard. Not the end of the world I suppose, but not as elegant or convenient as an adapter...

[Muirium]

^ This is why I ask. Evidently, the current situation is complex and confusing. Thanks for parsing it for me.

AT / PS/2 is something I only ever want to *convert* to something else. Zero interest in the other direction from me. Rollerball mice aren't my thing at all. I like the big old vintage cables on my AT boards, but they're ultimately plugging into a Thunderbolt dock, so…

My real dream converter would be a single metal box with AT, PS/2, ADB and NeXT ports across one side, a USB C socket on the adjacent side*, and some mounts so I can screw it to the underside of my desk. I've been thinking about running several Teensies in parallel off a single USB hub like that for ages. Only, I think I’m finally almost out of Teensies.

*Actually, for adaptability's sake, I'd put USB host ports on the side and the back, with the understanding that only one of them should be used at a time. The places I'd want to install a little box like this are cramped, so appropriate port geometry is much easier on cables.

[NathanA]

My real dream converter would be a single metal box with AT, PS/2, ADB and NeXT ports across one side, a USB C socket on the adjacent side*, and some mounts so I can screw it to the underside of my desk.

So, basically, the exact opposite of this thing :

https://www.tindie.com/products/dekunuk ... computers/
https://www.youtube.com/watch?v=tbHr7ULpusM

[Muirium]

Pretty much! Chunky little fella, ain't he?



What I've in mind is a lot smaller. No bigger than my Soarer box:



Ideally much more slimline, what with needing no knob: I'd run the converters in parallel from a USB hub inside.

[depletedvespene]

More firmware news:

wolfman is wrapping up the approval process for the refactoring to get the xwhatsit accepted into the main QMK project. Here are the details: https://github.com/qmk/qmk_firmware/pull/21193

Everyone feel free to test out this refactored firmware and let us know the feedback!

Will this include all physical layout variants of both (F62 and F77) form factors? If so, I'll test it on my F77 (which, you'll remember, has every splittable key split).

[Ellipse]

Firmware updates continued:
Is anyone able to help Rico add support for the pandrew utility and its signal level monitor to the Leyden Jar controller?
https://github.com/mymakercorner/Leyden_Jar
The pandrew utility is great for testing all of the keys at one time to quickly visualize any controller or key issues.

Currently the Leyden Jar is working very well in testing; I have noticed no issues so far. The controller is very solid. I hope to test the Rev3 version soon, once it arrives from JLCPCB. It works well in Vial as well, where you can click check marks to easily switch on and off various options such as NKRO.

depletedvespene - wolfman started with F62 for the refactoring submission, as they wanted only one keyboard at a time and count each variation separately, but the f77 should be able to be added if you download and modify the code: https://github.com/matthew-wolf-n4mtt/q ... del_f_labs

Once the NathanA firmware files are tested working on the 3 new boards (F50, F15, and Model F Split Ergonomic) then I hope to mail out the boards.

I have also done some more research on the connection of the two split boards. The hid-remapper project coordinator confirmed that we can use a USB hub to connect the two boards to share function layers (for example, pressing FN on one board to activate the function layer on both boards). hid-remapper can be updated through a web site, no software downloads needed.

I plan on ordering QTY 50 of the v1 custom hid-remapper RP2040 board from JLCPCB, along with 50 usb hubs (plus a few extras of each to be safe). https://github.com/jfedor2/hid-remapper ... tom-boards

[Muirium]

Got a link? A wee search in this notoriously busy thread finds this, but the attached .7z files won't extract for me.

Yes that's the right link. I see that you managed to get it extracted, but I'm also curious to know what app you are using to try to extract them that was failing to deal with them while they remained separate. The actual 7-Zip GUI app on Windows as well as the '7z' command-line version can both deal with multipart 7z files.

Can confirm the util works just peachy with my original Xwhatsit controller powered IBM 4074, running Pandrew's QMK of course. This is on M1, current MacOS 13.5.1

A couple of requests, if Pandrew or anyone is able:

• Universal binary to run native on ARM. It's currently x86_64 only, so running in Rosetta. Apple will kill that at some point, as they did with PowerPC
• Dark mode support. Not a biggie, but a nice to have

[NathanA]

A couple of requests, if Pandrew or anyone is able:

• Universal binary to run native on ARM. It's currently x86_64 only, so running in Rosetta. Apple will kill that at some point, as they did with PowerPC
• Dark mode support. Not a biggie, but a nice to have

That my particular MacOS copy of the util has neither Apple Silicon binary bits nor Dark Mode support is nobody's fault (least of all pandrew's!) BUT my own.

The absence of both features comes down to me wanting to try to target as wide a swath of supported systems (both hardware- and software/OS-wise) as possible. Though I'm sure most people here are largely interested in using their 40+ year-old keyboards on contemporary machines, there is surely a measurable percentage of people who would also like to be able to use them on legacy/"retro" systems, too. Of course, the USB-adapted 'boards will happily work on just about any host that has a USB port, no matter how old, but also having all of the software tooling needed to make changes or debug problems available to you on the same machine is a nice cherry on top, assuming it's practical to do.

The pandrew util for Windows is already compatible all the way back to Windows 7, released in 2009. On the MacOS side, producing a build of the app that runs perfectly on versions as old as Lion (10.7), released in 2011, ended up being (relatively) straightforward. So that's what I did. (Frankly, because I'm a sick man, I had actually hoped to get this working on Snow Leopard [2009], bringing legacy MacOS support as far back in time as Windows support, but it turned out that this was going to require way more work to accomplish than I was willing to put into it...at least at the time ) To get it to run under Rosetta 2, it has to be 64-bit x86-64, so there are a few Lion-compatible machines that can't run this build due to them having no 64-bit support (e.g., first-gen Core Solo/Duo based Macs), but many of those (except for the laptops) can have a Core 2 CPU dropped into 'em, anyway.

To support Apple Silicon natively, I'd "just" need to build with at least Xcode 12.x, which only supports targeting as far back as Mavericks (10.9). pandrew wrote his app against the cross-platform Qt 5.x framework, and Qt handles most of the nitty-gritty platform support details for you. If you build against a new enough version of the Qt5 libraries, you get Dark Mode support effectively "for free". And if you use an even newer version still, Qt5 also has official support for being built to run on Apple Silicon. That version of Qt5, though, only supports running on as far back as High Camp (10.13). So building a version of the app that fulfills both requests is absolutely doable, and probably with not that much effort. So perhaps in the future I'll release separate versions for older and newer Macs.

For whatever it's worth, I do sense that Rosetta 2 might be sticking around longer than the original Rosetta...

It was funny to me how, back during the PPC > x86 transition, Apple & Jobs announced a "2-year transition" and (probably to avoid the Osbourne Effect, heh) also that there were still "great PowerPC products in the pipeline yet to be introduced" (Jobs literally said this on stage! Spoiler: they never shipped another single PPC product after this ), yet they ended up transitioning the entire line-up within a year, and the VERY NEXT VERSION of MacOS after that (Snow Leopard) killed off PPC support entirely, leaving people who had just bought a G5 prior to the transition announcement high and dry with regard to future software support & stuck on Leopard for all eternity...I mean, I can imagine that there were still G5 desktops and G4 laptops out there still under extended hardware warranty that literally couldn't get software updates! Rosetta was ripped out of the following OS version (Lion). Apple *clearly* couldn't ditch PPC fast enough...

The ARM64 transition has gone pretty smoothly, but it's clearly taken them longer than they'd hoped to transition the entire product line ("thanks, Covid..." ), and they are still releasing major OS upgrades for the past Intel machines. If we use the past as our guide, we can probably expect Rosetta 2 to stick around for at least one OS release following the complete discontinuation of support for Intel machines, and that still has yet to happen...think about the number of larger Apple customers who perhaps currently have an investment in Xeon Mac Pros, which were still being manufactured and sold up until a couple of months ago...I give Rosetta 2 at least two more years of active service, if not three.

[Muirium]

Spoiler: they never shipped another single PPC product after this

G5 Quad, baby! At least that one came true, unlike the wholly mythical 3 GHz G5 he’d promised quite without IBM!

This Nitrozac comic from the time summed up Apple’s attitude to PowerPC precisely:



Trouble is: they have exactly the same attitude towards Intel. Build those universal binaries!

Notably, Xwhatsit’s Qt based (and strictly Intel only) config software for his controller can’t run on modern Macs at all. Apple is a moving target.

[NathanA]

Spoiler: they never shipped another single PPC product after this

G5 Quad, baby!

Well...dadgum. That'll teach me to shoot my mouth off. *

* ...eh, let's be honest: probably not. But we can hope.

EDIT: to be fair, it appears that this, along with a minor Powerbook G4 refresh, was the last PPC Mac to ship, in October, so a couple-three months following WWDC. But that this was before they had yet shipped a single Intel-based Mac. So I guess they did ship a new PPC product following that conference, but they never shipped another PPC product after they introduced the very first Intel model (the Mini in January '06)...every Mac following that was another Intel model. So it's not like they were interleaving Intel and PPC hardware releases together. There was still a pretty clear demarcation line there, release-schedule-wise.

Makes one wonder who on earth bought the quad G5 machines, knowing that Intel was just around the corner; heh.

Notably, Xwhatsit’s Qt based (and strictly Intel only) config software for his controller can’t run on modern Macs at all.

Wait: why is that, specifically?

I'm going to make some edjamacated-like guesses here: the Mac binaries floating around are 32-bit-only. Am I getting warm?

If it's Qt-based, and if it's open-source, what's preventing somebody from simply rebuilding it with a more modern toolchain?

I just took a look at the .pro file in the source tree, and it looks like it also targets Lion as a minimum version, and also uses libhidapi as the mediating portability layer for talking to the USB bus, same as pandrew's util. Seems like it should be a relative slam-dunk to rebuild this to run on "modern Macs". I'm just guessing nobody's bothered to do it, since most people have probably moved on to QMK by now...?

If I ever find myself bored, I might just give it a shot myself, for kicks.

[Muirium]

You’re quite welcome to try. I for one can’t be bothered setting up and learning how to use a Qt build environment. I suspect it is just the 32 bit barrier, but even in the golden age of Xwhatsit: his software was the crashiest app I’ve ever used on a Mac. It always presented random phantom keyboards on launch, and if you picked one: BOOM. Think it always triggered the operating system’s “unexpectedly quit” crash reporter on exit, too. Not the most polished experience.

As for transitions: Apple’s following the same path. Seen any new Intel Macs since the M1? They’ll be as dead to them as Motorola in no time.

[NathanA]

If I ever find myself bored, I might just give it a shot myself, for kicks.

Bah. My build environment for Mac Qt5 apps is still set up from the last time I did this, so...fine.

Here you go. I don't actually have a keyboard flashed with xwhatsit firmware, nor do I actually have an M1/M2 Mac at my disposal right now to test this on even if I did, so somebody else will have to be the guinea-pig. I can at least confirm that it launches, and tells me it can't detect a keyboard.

You’re quite welcome to try. I for one can’t be bothered setting up and learning how to use a Qt build environment. I suspect it is just the 32 bit barrier, [...]

I'm now no longer sure. You didn't go into detail about how its incompatibility with your current machine manifests itself, so I was just taking a stab in the dark. If the OS tells you it can't run it, that's one thing, and points to 32-bitness. If the app does at least launch, though, but just crashes out or behaves incorrectly, that's something entirely different.

In fact, I found this thread (that I apparently participated in and totally forgot about...) while searching around for any clues as to the actual problem, and the OP for that thread had an M1 Mac that it sounded like xwhatsit's ibm_capsense app actually did indeed launch on. It just couldn't detect the keyboard (which -- spoiler alert -- wasn't loaded with xwhatsit firmware to begin with). Soooo...

As for transitions: Apple’s following the same path. Seen any new Intel Macs since the M1? They’ll be as dead to them as Motorola in no time.

Oh, I'm not disputing that at all. I just remembered Jobs' comment, forgot about the quad G5, and thought it was funny. But I'm also recognizing that this transition is quite plainly taking longer than the last one. For example, MacOS only went through 1.5 versions that were dual-platform before PPC got the rug yanked out from underneath it (Tiger had already been released at retail before the Intel transition was announced; Leopard was the only retail upgrade disc that supported both platforms on one disc...now, Apple was not exactly running on their one-major-release-per-year cadence/release-cycle for MacOS yet by this point, granted!). But this go-round, MacOS has already seen three full version releases (Big Sur / Monterey / Ventura) where both x86-64 and aarch64 are still supported side-by-side, and we already know that the one about to come out (Sonoma) still retains Intel support, too, so that's *four*! And since they only stopped manufacturing their last Intel machines (and not just any model, but the freakin' Mac Pro!) a couple of months ago, I'm not so sure that they won't have at least one more version of MacOS that supports both even after Sonoma. Which means Intel hardware support likely won't be killed off until MacOS 16 (2025), which quite possibly also means that Rosetta 2 won't die until MacOS 17 (2026)!

[Muirium]

I don’t have an Xwhatsit (firmware) powered board among my little fleet of Xwhatsit (hardware) powered IBMs to test this. Kinda says it all, really. It was a godsend but contained a curse. Then Pandrew came along and bettered it completely. Even Arkku’s firmware didn’t last long on my IBMs as it was having (different) issues. These boards are much too important to me to accept anything less than 100% reliability.

Which means Intel hardware support likely won't be killed off until MacOS 16 (2025), which quite possibly also means that Rosetta 2 won't die until MacOS 17 (2026)!

I’ll check in on this when they do drop Intel. I expect it will be soon. No love lost there at all.

[NathanA]

Which means Intel hardware support likely won't be killed off until MacOS 16 (2025), which quite possibly also means that Rosetta 2 won't die until MacOS 17 (2026)!

I’ll check in on this when they do drop Intel. I expect it will be soon.

I guess it all depends on what one considers to be "soon". I am predicting 2025, but the absolute *soonest* that they could possibly drop it is late 2024. We *know* this to be the case, because Apple has already publicly committed that MacOS 14 "Sonoma", which is currently in beta right now, will continue support Intel. New major versions of MacOS typically come out of beta in October/November. So they literally can't drop support for Intel (without going back on their word, at least) until October/November 2024, with the release of MacOS 15. So if "over a year" is considered "soon", well...I guess that's one possible interpretation of "soon"?

[Muirium]

Something like that. I wouldn’t count antique OS version history as any guide—Tiger was one hell of a long lived cat—as Apple switched gears to annual releases, come what may, after the Leopard debacle. “Leopard = Longhorn” really was a thing on nerdy lips back then.

Anyway, I’d just build it for the current OS version (and its two architectures) and forget all about Sky High Sierra and Yosemite Sam. Any Mac user nerdy enough to play with QMK is running current software. My two older Macs run Snow Leopard (a 2006 Mac Mini) and Tiger (my original Mac: a 2003 PowerBook 12 inch). I’m not seeking support for them, the M1 can do the job quite nicely.

[NathanA]

Something like that. I wouldn’t count antique OS version history as any guide—

It's not really even a matter of me looking at the past to use as a guide for this instance. I'm looking at what Apple has publicly communicated about their intentions for MacOS Sonoma. This yet-to-be-released version still supports Intel...this part isn't even up for conjecture or dispute. So unless Apple decides to break their very public promise, the software support for Intel continuing on for the next 400ish days is already in the bag.

Therefore, Intel support might extend further out than one more year, but whether or not that happens, we already know for a fact it is going to be at least one more year. That's all I'm saying.
`

sonoma-compat.png (988.5 KiB) Viewed 28412 times

`

Any Mac user nerdy enough to play with QMK is running current software.

If this were GH, that statement would probably be true. And likely even for most people here, it's true. But I do get the sense that the DT audience here is made up of a larger cross-section of people who are also at least tangentially interested in "vintage tech" when compared other online keyboarding communities, and I guess that's to be expected given that there is just a plain larger interest in vintage keyboards here relative to elsewhere. After all, right now we are talking to each other in a thread that's largely about reproductions of keyboards that were made in the early 80s and freaking weigh nearly 10 pounds. And even I get a hankerin' on occasion to use my "new" F boards on some of my older machines.

The way I looked at it was, if I can extend the range of base OS compatibility with minimal effort in order to benefit the widest possible set of users, then why not do it? Also, the app we are talking about here is just a debugging/troubleshooting app anyway, where I would argue the "aesthetics" are absolutely secondary to its utility. It's not like we are talking about the Vial app here. (Oh dear, that gives me a very, very sick idea... )

Add to all of this that my own collection of Macs only contains machines that are at least a decade old already. So my own options for machines to both build and test on is limited. If I want to test on an Apple Silicon Mac in person, I have to borrow a friend's. My "newest" Mac that I own? Retina MacBook Pro 2012. So...

Like I said, I'll look into building a native aarch64 release. It's just going to take a little time given what I have to work with. I do have a functioning Catalina install on the rMBP, and I believe Xcode 12 (latest version of Xcode that will run on Catalina) is when building for Apple Silicon hardware targets was introduced. But I'm also looking into the available tools (e.g., OpenCore Legacy Patcher) for installing Ventura on a Mac of this vintage.