QMK Powered Equivalent to Soarer’s Converter?

[snacksthecat]

Now, I'm such a QMK rube (beyond Pandrew on Xwhatsit hardware) that I don't even know how to assign controller pins and such. Searching the supported keyboard list on QMK Configurator brings up this similar controller for Model Ms but it runs on the STM32 MCU which is completely different silicon as I understand. If you know your way around QMK well enough now, I'd like to run that (or comparable) on my Colossus! Bonus points if it's Configurator friendly!

I could be misunderstanding but wouldn't this be a candidate for the QMK firmware located under keyboards/converter/modelm101?

That one builds a firmware for AT90USB1286

The rub I see with using it with Configurator is I'm not sure if it's possible to override the default pin assignments if you need to match the ones used by your Colossus board:

Pins of the Teensy board you should use by default:

Columns: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Pins: C7 C6 C5 C4 C3 C2 C1 C0 E1 E0 D7 D6 D5 D4 D3 D2
--------------------------------------------------------
Rows: 1 2 3 4 5 6 7 8
Pins: F7 F6 F5 F4 F3 F2 F1 F0
--------------------------------------------------------
Status LEDs: CapsLock +5V ScrollLock NumLock
Pins: B6 5V B5 B4

[Muirium]

I'm sorry to hear that. Having lost both my grandfathers to cancer (one skin, one brain) I know how much it hurts. Apologies for any hurt from my cheap jab.

Apology accepted. Cancer’s the ultimate son of a bitch.

I could be misunderstanding but wouldn't this be a candidate for the QMK firmware located under keyboards/converter/modelm101?

That one builds a firmware for AT90USB1286

The rub I see with using it with Configurator is I'm not sure if it's possible to override the default pin assignments if you need to match the ones used by your Colossus board:

Pins of the Teensy board you should use by default:

Columns: 1 2 3 4 5 6 7 8 9 <a href="tel:10 11 12 13 14 15 16">10 11 12 13 14 15 16</a>
Pins: C7 C6 C5 C4 C3 C2 C1 C0 E1 E0 D7 D6 D5 D4 D3 D2
--------------------------------------------------------
Rows: 1 2 3 4 5 6 7 8
Pins: F7 F6 F5 F4 F3 F2 F1 F0
--------------------------------------------------------
Status LEDs: CapsLock +5V ScrollLock NumLock
Pins: B6 5V B5 B4

I overlooked that one because of it being filed under /converter. I need a controller for this SSK project. But as they’re talking about row and column assignments, then it’s clearly a controller, and simply misnamed. Could have potential!

I know I could define my controller’s pins and matrix in code. I’ve done it before for my ADB converter. But the GUI is calling to me. I want Configurator goodness, greedy me!

[snacksthecat]

I was able to get the whole web stack project up and running but couldn’t make the configurator build a firmware. Something seemed to be going wrong with the network routing between the configurator and the api. Some python package setup step for routing was breaking in the compose log. Anyways, I realized I’m way out of my depth so going to put that little project to bed for good. Fun learning experience with docker, though.

Once I get those blackpill dev boards, I’ll see if I can get the IBMPC port working with VIA, because that work seems to already have been done. On second thought, I'm not sure if I needed to even get those, because I have some Teensy 2.0++ boards myself.

Then at that point maybe I’ll know a bit more about how to configure a keymap to build for VIA and maybe we can get your Colossus board setup with that as a GUI configurator, since that seems to be the only viable option. I think at90usb1286 EEPROM is adequate, at least from a quick and dirty test I did building a VIA firmware with that as the MCU. Although, me thinking things hasn't yielded good results so far.

* The firmware size is fine - 22668/130048 (17%, 107380 bytes free)

I love how all of this seems doable and turns out to be just barely out of reach, don’t you?

[snacksthecat]

Ding ding ding! We have a winner.

I was able to use marfrit's QMK port of the original IBMPC_USB firmware from hasu with VIA as a GIU configurator. (that was a mouthfull)

I was still only able to build the firmware for the at90usb1286 (Teensy 2.0++). It was too large for the atmega32u4 (Teensy 2.0 / promicro). Maybe there is a way to shrink it through settings, but I don't know how.

Let me know if you're interested and I can probably boil down some instructions to get you up and running with that.

Based on that exercise, I'm confident now that it would be possible to do the same with your Colossus board that uses at90usb1286 and again use VIA as a configurator. I can *probably* help with that work as well.

Or if you're not interested in either, I won't be offended. It was fun to learn some new things.

Here's a video of the live configurator in action. Don't make fun of my keyboard, it was the only one I could find.

Note: There's a caveat in marfrit's github fork that the port would need to be extended to support other code sets, but it seemed to work fine with my XT compatible Laser keyboard without any issues:

It supports PS/2 Scan Code Set 2 (as of now) and runs on USB AVR chips.

[Muirium]

Impressive effort!

Looking at VIA’s website, I see this Try Now link that only speaks of requiring USB browser support here on my phone. Is that a web based VIA configurator for use on desktop browsers? I’d much prefer that over the massive local app route. Prime among the things I love Soarer, TMK and QMK for is the lightness of their tools.

[snacksthecat]

Impressive effort!

Looking at VIA’s website, I see this Try Now link that only speaks of requiring USB browser support here on my phone. Is that a web based VIA configurator for use on desktop browsers? I’d much prefer that over the massive local app route. Prime among the things I love Soarer, TMK and QMK for is the lightness of their tools.

Probably not for this use case. It seems that the online app would work for their library of "known" boards (similar to QMK configurator) and automatically load the keymap. But I don't see an option to upload a custom layout JSON, which was necessary for this to work with my converter. Unless I'm missing some way of integrating those layouts into the firmware so that they're recognized automatically when plugging in the board.

Edit: It also looks like there are a variety of settings that could be disabled to reduce the firmware size, maybe enough to fit on a teensy. The one I tried was changing the number of dynamic layers in the config.h from 4 to 3:

Code: Select all

#define DYNAMIC_KEYMAP_LAYER_COUNT 3

But now all the keys are having an identity crisis and don't trigger the right codes. Anyways, it builds for atmega32u4 which is a good sign and maybe either that issue could be fixed or the other settings I mentioned could be taken advantage of in order to reduce it enough.

[snacksthecat]

I've been revisiting getting the web stack to work. I feel like I'm almost there. But when I pull from the master branch of each submodule, something in one submodule doesn't play nice with something in another one.

This has basically been me trying to find a combination qmk_api and qmk_compiler that are compatible with each other AND that build with all of the python package dependencies. I'm probably approaching this all wrong but I've brute forced by very close to getting this plane off the ground. I have a lot of barely coherent notes scribbled down all over the place that probably only make sense to me.



Edit: The firmware files are building! I can see the source zips and binaries in the qmk_compiler directory. But the download doesn't trigger for some reason. Still debugging that.

[snacksthecat]

After many failed experiments I finally got the web stack working and my internet hosted configurator to build and serve up a compiled hex for download. Regarding my last post, all of that backtracking of old versions was a dead end and I was able to build everything using the up-to-date master branch of each submodule. Now that I got this working, I'd like to understand how to add an additional board to the list. I learned a lot about how the configurator/api/compiler work, but I actually don't know very much about using QMK itself.

[Muirium]

I’ve actually, and simultaneously, been addressing all of this in Karabiner. It handles mouse control quite nicely, including defining your own speed and axes, allowing for the diagonals my fingers insisted must exist on the numpad despite the stern explaining to I’d just given them. So now my full-size boards have 8 direction keys for the mouse, all thanks to Karabiner intercepting them sending their native scan codes.

Karabiner isn’t perfect though. But its toggles work instantly, which even QMK Configurator couldn’t do for me. So I’m getting there as well.

[snacksthecat]

Wow, I just read your Karabiner post and that software seems incredibly featureful. But I can't help but poke fun about your earlier comment about being averse to having to install a configurator (though VIA is admittedly bulky and mysterious). I would have thought a tool that applies the rules locally through software would have been out of the question.

As for my quest to stand up a QMK Configurator instance and adding a new keyboard, my latest challenge is that the code was updated at some point to pull the keyboard list from their own website with hardcoded links to some auto-generated json files that they are hosting on https://keyboards.qmk.fm/. Now with the hardcoded links, it seems more complicated. Also it feels like layouts are defined in like 10 different places, which is driving me nuts.

So I've been working on replicating these json files to instead point to my own APIs which mimic the response structures coming from that URL

Now with all of that work it's clear that this is not sustainable. The API response is very verbose and I had to do some of my own hardcoding so it would be a challenge to maintain. But basically I'd like to have an environment to test things in if my ultimate goal is to learn the necessary steps needed to add the ibmpc_usb port to the official configurator. After all, wasn't that the original idea?

Where I am now is that I'm able to the ibmpc_usb keyboard, able to compile it, but can't load a layout. Which. Is. The. Whole. Point. Ugh...

no-layout.PNG (97.34 KiB) Viewed 11375 times

[Muirium]

Wow, I just read your Karabiner post and that software seems incredibly featureful. But I can't help but poke fun about your earlier comment about being averse to having to install a configurator (though VIA is admittedly bulky and mysterious). I would have thought a tool that applies the rules locally through software would have been out of the question.

Believe me, I resisted Karabiner for many years. It was called KeyRemap4MacBook when I first refused it. Obviously I’d never install that! Besides, I never liked the virtual keyboard approach, from a mental cleanliness perspective. Well, until I finally wound up back at an ISO laptop. That infernal, internal keyboard! How could I Soarer my way above that?

I'm used to programmable keyboards. Soarer's, TMK in my HHKB, QMK in my Kishy. After hitting that accursed ` key when reaching for left Shift for the hundredth goddamn time, I knew this built in keyboard was in sore need of some modding. It was time for me to make my peace with Karabiner.

Karabiner definitely isn’t perfect. I loathe its “Simple Modifications” pane, which has gotten much worse now it’s written in SwiftUI. EIGHT fiddly nested drop down menus just to swap my Command and Option keys around! Repeat for every USB native PC keyboard. And the missing Num Lock light support is vexing, too, as my newfound workaround for the Realforce gets clobbered once Karabiner is engaged.

But it’s open source, deeply featureful, and a hell of a lot smaller than that one trick VIA app which must be an Electron beast, bringing a wide surface indeed for attack. So yeah, I’ll pass on that for twiddling with my keyboards! It’s tricky stuff like macros and running host side scripts I really fiddle around with regularly, anyway.

As for your continuing quest: fight the good fight, good sir! I'd still love to see QMK Configurator have the AT/PS2 Converter it deserves. Even with Karabiner doing the fancy stuff, I still need to bring those vintage keyboards to the computer in the first place.

[snacksthecat]

I'm happy to report that I finally got the layout to load in the configurator.

So in terms of checklist items we've:
[x] Brought a dev configurator instance online
[x] Added the ported converter to the list of keyboards
[x] Made it compile a hex successfully
[x] Added a default 127 key layout for the converter
[ ] Tested the hex on an actual keyboard
[ ] Identified which features it can/can't support
[ ] Confirm or add support for XT protocol (not sure if XT or terminal are needed since they're already covered separately)
[ ] Whatever legwork is involved in getting it added to the official configurator

Anyways, here's a screenshot of what it looks like in the configurator. I'm pretty sure there's a simple way of overriding the labels on the funky keys that didn't render ones. You've got no idea how much time I've sunk into getting this far and how happy I was to see it finally working end to end.

layout-success.PNG (96.31 KiB) Viewed 11296 times

[snacksthecat]

I revised a few things and think I've now got this in a place where I'm ready to share it out.

• Added what I consider a sane default layout that should be a good starting place for remapping things
• Setup for 6 layers (default keymap only has the 1st layer defined)
• Added support for compiling for either teensy or promicro
• Did some cursory testing on IBM Model F AT and XT keyboards as well as an AT Filco board

I'd be interested in getting some feedback and input if anyone out there is willing to do some testing. I threw some alerts on the page to make it clear that it's not the actual official configurator site. Any input would be appreciated, but in particular would be suggestions on preset layouts (including layers), reporting any issues, compatibility, etc.

A few notes:

• The converter wiring is the same as Hasu's IBMPC_USB and Soarer's converters (Data: PD0, Clock: PD1)
• Reset is PB6 or PB7 (though I'm not sure if it's supported). Only needed for certain XT boards.
• When you click "download" you'll get a popup saying that you're navigating away from the site with unsaved changes. You can ignore this message as it doesn't actually take you away from the site, just downloads the file like you'd expect.
• I'm not sure if the two unassigned keys can be mapped to anything or not. I don't have a keyboard to test those with.

So anyone who'd like to test it out, let me know what you think and your suggestions. I'll leave the site up and running for the next few days. Here's the link:

(Removed)

configurator-app.PNG (105.76 KiB) Viewed 11251 times

[Muirium]

Okay, cool, feedback time.

Giving your editor a whirl just now. Where is the Print + Scroll + Pause cluster? I'd seriously suggest throwing out the 122 key template for a standard regular full-size keyboard, certainly as the default. There's so many more boards out there like this NMB I'm typing on just now than 122s.

Also: it's vitally important to remember the Reset command (found in the Quantum tab) on every layout you ever flash to a keyboard, so you don't lock out DFU mode. Put it somewhere on the default layout. Pandrew has it, tucked away on layer 2, requiring Fn + Space + R to trigger the bootloader. That's why I want those back right corner keys: I noticed your layout doesn't have it, then I went to put Reset right on the base layer so I have an exit hatch!

Without the Reset key anywhere on the board, you're forced to open up the keyboard to reset the 32u4 to ever put another layout or firmware on it. The Teensy's little button is better than a Pro Micro, obviously, but vintage cases often need cramped placement and so even resetting this board is awkward. I've done just that a bunch recently as TMK's "Magic" keys never did work with it. 7 screws on the back, 2 on the plate, then get out a narrow screwdriver to go jabbing at that little button once again… Or just run scboot if it's on Soarer!

Don't rely on Shift + Shift + B or Pause/Break. They're unreliable on home built or repurposed Soarer converters, I find. (The only place I've found "Magic" to be reliable is Hasu's own hardware in my HHKBs. The irony being they have an easily pressed reset button on the back anyway.)

[snacksthecat]

Good suggestions. I think probably when this was made the original goal was to express all 127 keycodes to offer the most flexibility for remapping every key. I can see how having alternative layouts that more closely match a variety of keyboards would be useful.

In that regard, would it make sense to include F13-F24 in each of the layouts or would that be annoying? Similarly, would it make sense to keep "blending" ANSI/ISO layouts into one or create separate layouts for each?

Since it's a "converter" firmware that's not tied to any specific keyboard, it's a balancing act of giving people all the options without cluttering things with extra keys.

Are there any specific layouts that I should try to reproduce?

Where would be a good place to include a Reset key in the default keymap?

Edit: Now that I think about it, probably makes the most sense to stay true to the original and try to reproduse Hasu’s original layouts and keymaps.

[ Full-key | 83-key XT | 84-key AT | 122-key Terminal ]

That ensures that the input scancodes are all supported and also serves as a good baseline in terms of layout variety.

His layout editor includes extra/repeated keys in other positions with instructions to ignore them if they don’t apply. Based on how QMK configurator works, I’ll probably have to take a more rigid approach, which may not be a terrible thing. So more like a variation on what he’s doing but in the spirit of it.

[Muirium]

Don’t overthink it. Go with a regular Model M like full-size with windows keys and ISO compatible split Return and Shift. Other stuff can wait. Too confusing lumping it all up front.

As for Reset key: definitely have it somewhere. People can modify it of course. I’d put it up away on that block. Doing what Pandrew does with several default layers is a choice, but you must include layer logic and an Fn key when doing that, which also sacrifices a key by default. I’d lean on the KISS principle instead. It’s an editor, let others edit.

[snacksthecat]

Eh, I hear what you're saying but I think it's worth having a "full" layout that has all or close to all of the possible keys.
I'm experimenting with this layout:

layout-full.PNG (37.36 KiB) Viewed 11147 times

My thinking:

• It makes sense to have a default layout with all of the ANSI/ISO key placements, since you can only have 1 default layout per keyboard. Any additional layouts beyond the default populate as all blank when selected. This was a disappointing discovery for me.
• Similarly, I think the additional F row is good to have, even if it's just ignored. It doesn't hurt and can remove a significant limitation for the user. They can be ignored if not needed.
• I agree that the 122 key layout is more of an edge case so doesn't make sense as the default.
• Added a reset button where you suggested.
• The media keys above the numpad are probably confusing on the default layout, since it's not clear what input scancodes those would map to. So I'll probably remove those from the default.
• At this point it's also a bit unclear to me how to create a configurator-compatible layout that doesn't include all of the keys. Might just be missing something simple though.

[Muirium]

That’s much more like it! A second function row to f24 isn’t going to confuse anyone.

I’d just flip around the right Windows and Menu keys, as they’re never that way around on the few modern boards I have with them.

[snacksthecat]

Thanks again for the input, very helpful stuff.

I made some additional adjustments to the "standard" layout and I'm pretty happy with it. I have a few questions though.

layout-standard-with-questions.png (38.72 KiB) Viewed 11092 times

What key is typically found next to the 1.75 right shift and in the bottom right corner of the numpad? Those were unassigned in the ported converter so I wasn't sure if they map to anything.

Also, would be interested in feedback if anyone wants to try mapping a layout and testing it on a keyboard. I've tested on an AT board and everything is working as expected, but I don't have a keyboard to test the circled keys on.

I'll drop the link again for anyone who's willing to help:
(Removed)

[Muirium]

Those circled keys should Just Work™ but yes it’s always good to check. I’m embarrassingly short of ISO keyboards to test it myself, however, for someone who lives in that part of the world.

The reason for those split keys is of course the major national hardware layouts. Spot the splits:

ANSI:




ISO:




JIS:



Individual (non nutty modern custom) keyboards don’t have all those keys split out separately. But they must all be supported, as all three layouts live out there. Hasu supports this in Unimap by simply being repetitive in his default layouts, with the instruction to ignore keys you don’t have. That’s pretty much all you can do. Populate them but don’t be too picky, especially with that kana key I see you’ve put on JIS split Shift! Just leave it \ or some other placeholder. Brazil also splits that key out, as I recall, and maybe others.

[Muirium]

As for numpads, there’s plenty of silly buggers going on there on vintage keyboards.

Behold the Apple Extended Keyboard. On first glance its PC homage layout is quite unremarkable, right down to the Num and Scroll lock lights which DON’T EVEN WORK ON THE MAC WHAT WERE THEY THINKING. But then look at the numpad. Whut? They went to all that cloning effort but just couldn’t stop themselves from goofing around there!?



Even IBM wasn’t always quite sure what to do over there besides the numerics:

[depletedvespene]

Thanks again for the input, very helpful stuff.

I made some additional adjustments to the "standard" layout and I'm pretty happy with it. I have a few questions though.

layout-standard-with-questions.png

What key is typically found next to the 1.75 right shift and in the bottom right corner of the numpad? Those were unassigned in the ported converter so I wasn't sure if they map to anything.

Also, would be interested in feedback if anyone wants to try mapping a layout and testing it on a keyboard. I've tested on an AT board and everything is working as expected, but I don't have a keyboard to test the circled keys on.

I'll drop the link again for anyone who's willing to help:

Spoiler:

http://147.185.239.146:5000/

If I may:

Some annotations.

annotated.png (45.26 KiB) Viewed 11070 times

You got the key between /? and RShift right. The one between =+ and Backspace should be JIS ¥.

The one between LShift and Z should be correct (as long as you got the "correct" \| key: KC_NUBS, not KC_BS).


As for the extra keys in the numpad, I'm afraid there isn't really a consensus, and each user will have wildly different ideas. What I have on my F107 (with a 20 key numpad) is:

My numpad on the F107.

numpadF107.png (54.84 KiB) Viewed 11070 times

Note that I am not using P, and P= as Windows ignores them, and instead I must send the comma from the alpha block and Shift-0 (where the = character is in my national layout). Shift-. produces the colon, which goes where Num Lock normally goes. For the extra key produced by the split numpad0, I produce an uppercase K, which makes sense for my usage case (a C programmer dealing with lots of hex numbers could make it into a lowercase x instead).


I have a fullsize Model M which a 20-key numpad. Once I get a converter that can run TMK or QMK for it, I'll be happy to test this.

[Muirium]

Re: whacky numpads, Cherry says hold my beer.

IMG_3342.jpg (42.6 KiB) Viewed 10980 times

I quite like this one. Integrated lock lights are so much classier than a big dumb window, removed from their function. Num and Scroll Lock are both numpad specific modes, so really should be in there.

From a converter's perspective: there's a whole wee world of variety over in the numpad!

[depletedvespene]

Re: whacky numpads, Cherry says hold my beer.


IMG_3342.jpg


I quite like this one. Integrated lock lights are so much classier than a big dumb window, removed from their function. Num and Scroll Lock are both numpad specific modes, so really should be in there.

From a converter's perspective: there's a whole wee world of variety over in the numpad!

Not that different from the assignments on an IBM numpad on a terminal keyboard.

That said, how to make a proper numpad designed for "modern sensibilities" is a subject worthy of its own thread.

[snacksthecat]

Thanks Muirium for the crash course in layouts and thanks depletedvespene for breaking down each of those keys. Including the scancodes has been especially helpful!

Incidentally one of the only PS2 keyboards I still have is a Japanese layout Filco keyboard, which is what I've been using for testing. I found that the JYEN (0x7d) key next to the backspace is not recognized by the ported firmware. It is working in Hasu's original firmware. I've been comparing the code in each project to see what the differences are both but with my zero knowledge of C programming its proven difficult.

It's quite complicated what is happening with the firmware code. Here is an explanation of what each file is doing (as I understand it):

configurator-sandwich.png (28.71 KiB) Viewed 10922 times

I think that Hasu's unimap concept simplifies things by creating a more streamlined abstraction between the bottom 3 layers, which is probably the point of it.

It's not jumping out at me where the breakdown is happening. Positions in the virtual matrix don't seem to match up with the codes that they should translate to. They obviously do, but it's not in a way that I can currently understand. I'll need to study both projects more until this makes sense to me, but for now some of those circled keys may not work. Everything else seems to function great, though.

[snacksthecat]

I originally posted the comment below asking what I see now is a very obvious question, but the answer slapped me across the face...

Maybe someone here is able to help me connect whatever dots I'm missing.
I added a line to the matrix.c file to print out some debug information when a key is pressed on the keyboard (code set 2).

As an example, when I press "a" on the keyboard, I get this output in the console:

Code: Select all

> Code: 0x1C Row: 1 Col: 12 Map: 0x4B

0x1C is the code set 2 scan code for the "a" key. I understand that much.

row 1 and column 12 are positions on the artificial matrix defined in ibmpc_usb.c. Those are found by passing the code through these functions:

Code: Select all

#define ROW(code)      ((code>>4)&0x07)
#define COL(code)      (code&0x0F)

Finally in the print is the code 0x4B that is found in that row/column combination in the artificial matrix. That is found through this function:

Code: Select all

newcode = map_cs2[ROW(code)][COL(code)];

This is the artificial matrix itself:

matrix-ibmpc_usb_c.png (26.65 KiB) Viewed 10870 times

And I'm not sure if it's relevant but here is the layout definition, where I've circled the "a" key:

layout-ibmpc_usb_h.png (38.61 KiB) Viewed 10870 times

So my question is: what is the meaning of 0x4B?

Duh, it's the corresponding key in the keymap.

[snacksthecat]

Now that I understand how the firmware code works, I created a common layout that is very similar to in Hasu's. Since I completely remapped the matrix to cleanly align with this layout, XT and terminal protocols definitely will not work. I will repeat the same remapping exercise once I nail down AT/PS2. Let me know what you think of this layout. I think everything is where it should be.

unified-keymap.png (39.64 KiB) Viewed 10831 times

[Muirium]

I’d test it with ISO (which would expose the split left Shift) but no amount of rummaging will conjure forth my trusty old AT to PS/2 cable. Only got one lonesome ISO keyboard to try with this, and it’s the wrong plug!

Anyway, it looks good.

[snacksthecat]

Update on progress I've made.

I mapped out the matrix for XT and Terminal, so that covers all 3 protocols that the original firmware supports.

After that I've been working on a few alternate layouts, since the default may not be practical for remapping certain keyboards. I was wondering if anyone could help by peer reviewing these. For each of them I can only have a max of 128 keys in the layout (size of matrix). As far as I can tell it's not possible to repeat a key in the layout to support keyboard variations where certain keys are found in different positions.

Full key - Link
This is what I've shown so far as a "universal" layout. Including just for reference.

full-key.png (55.17 KiB) Viewed 10707 times

IBM XT 83 key - Link
Uncertain about if some of those international keys actually appear on any of the keyboard variations and if any missing ones should be added. Numpad could use a review as well in the same way.

xt-83.png (34.49 KiB) Viewed 10707 times

IBM AT 84 key - Link
Same questions as XT layout.

at-84.png (37.05 KiB) Viewed 10707 times

IBM Terminal 122 key - Link
This is somewhat of a mashup that I derived referencing Hasu's keymap editor and photos of keyboards. He supports the Cherry G80-2551 terminal keyboard in his editor by repeating some of the keys, but I'm not able to do the same thing in QMK configurator, so that would require a separate layout which is probably overkill and this one can be good enough for most cases.

terminal.png (56.93 KiB) Viewed 10707 times

Thanks again!

[snacksthecat]

Added these new layouts to my rogue configurator. As I mentioned earlier, one limitation of QMK configurator is that you can only have 1 default keymap per keyboard. So as soon as you switch off of the default, the new layout loads with all blank keys. Maybe there's a way to restructure the project so that these layouts each fall under separate "keyboards" that all depend on the same converter code but I'm not enough of a QMK ninja to know if that's possible. Anyways, now in the layouts dropdown you should see 4 options: fullkey, xt83, at84, and terminal.

I've attached the json files that can be uploaded to populate the non-default layout with the keymaps as their shown in the screenshots from my last post.

Still doesn't look like anyone's tried building a firmware outside of my own testing. Dropping the link again in hopes someone is willing to try out the firmware.

Link:
(Removed)

keyboard-sanders.png (358.22 KiB) Viewed 10674 times